Hata raporlarını okuyun

Hatalar her türlü geliştirmede bir gerçektir ve hata raporları sorunların tanımlanması ve çözülmesi açısından kritik öneme sahiptir. Android'in tüm sürümleri , Android Debug Bridge (adb) ile hata raporlarının yakalanmasını destekler; Android 4.2 ve üzeri sürümler, hata raporları almak ve e-posta, Drive vb. yoluyla paylaşmak için bir Geliştirici Seçeneği'ni destekler.

Android hata raporları dumpsys , dumpstate ve logcat verilerini metin (.txt) biçiminde içerir ve belirli içerikleri kolayca aramanıza olanak tanır. Aşağıdaki bölümlerde hata raporu bileşenleri ayrıntılı olarak açıklanmakta, sık karşılaşılan sorunlar açıklanmakta ve bu hatalarla ilişkili günlüklerin bulunmasına yönelik yararlı ipuçları ve grep komutları verilmektedir. Çoğu bölümde grep komutu ve çıktısı ve/veya dumpsys çıktısı için örnekler de bulunur.

Mantıksal kedi

logcat günlüğü, tüm logcat bilgilerinin dize tabanlı bir dökümüdür. Sistem kısmı çerçeveye ayrılmıştır ve diğer her şeyi içeren ana kısımdan daha uzun bir geçmişe sahiptir. Her satır genellikle timestamp UID PID TID log-level ile başlar, ancak UID Android'in eski sürümlerinde listelenmemiş olabilir.

Olay günlüğünü görüntüle

Bu günlük, ikili biçimli günlük iletilerinin dize temsillerini içerir. logcat günlüğünden daha az gürültülüdür ancak aynı zamanda okunması biraz daha zordur. Olay günlüklerini görüntülerken, bir işlemin ne yaptığını görmek için bu bölümde belirli işlem kimliğini (PID) arayabilirsiniz. Temel biçim şu şekildedir: timestamp PID TID log-level log-tag tag-values .

Günlük düzeyleri aşağıdakileri içerir:

  • V: ayrıntılı
  • D: hata ayıklama
  • ben: bilgi
  • W: uyarı
  • E: hata

Diğer yararlı olay günlüğü etiketleri için /services/core/java/com/android/server/EventLogTags.logtags adresine bakın.

ANR'ler ve kilitlenmeler

Hata raporları, Yanıt Vermeyen Uygulama (ANR) hatalarına ve kilitlenme olaylarına neyin sebep olduğunu belirlemenize yardımcı olabilir.

Yanıt vermeyen uygulamaları belirleme

Bir uygulama, genellikle ana iş parçacığının engellenmesi veya meşgul olması nedeniyle belirli bir süre içinde yanıt vermediğinde, sistem işlemi sonlandırır ve yığını /data/anr dizinine atar. Bir ANR'nin ardındaki suçluyu keşfetmek için ikili olay günlüğünde am_anr değerini grep yapın.

Ayrıca, ANR sırasında CPU'yu neyin kullandığı hakkında daha fazla bilgi içeren logcat günlüğünde ANR in da kullanabilirsiniz.

Yığın izlerini bulma

Genellikle bir ANR'ye karşılık gelen yığın izlerini bulabilirsiniz. VM izlemelerindeki zaman damgasının ve PID'nin araştırdığınız ANR ile eşleştiğinden emin olun ve ardından sürecin ana iş parçacığını kontrol edin. Aklında tut:

  • Ana ileti dizisi size yalnızca ileti dizisinin ANR sırasında ne yaptığını anlatır; bu, ANR'nin gerçek nedenine karşılık gelebilir veya gelmeyebilir. (Hata raporundaki yığın masum olabilir; başka bir şey, çözülmeden önce uzun bir süredir (ancak ANR'ye yetecek kadar uzun değil) takılıp kalmış olabilir.)
  • Birden fazla yığın izleme kümesi ( VM TRACES JUST NOW ve VM TRACES AT LAST ANR ) mevcut olabilir. Doğru bölümü görüntülediğinizden emin olun.

Kilitlenmeleri bulma

Kilitlenmeler genellikle ilk olarak iş parçacıklarının takılması nedeniyle ANR olarak görünür. Kilitlenme sistem sunucusuna çarparsa, bekçi köpeği sonunda onu öldürecek ve günlükte şuna benzer bir girişe yol açacaktır: WATCHDOG KILLING SYSTEM PROCESS . Kullanıcı açısından bakıldığında cihaz yeniden başlatılır, ancak teknik olarak bu gerçek bir yeniden başlatma yerine çalışma zamanı yeniden başlatmasıdır.

  • Çalışma zamanı yeniden başlatmasında sistem sunucusu ölür ve yeniden başlatılır; kullanıcı aygıtın önyükleme animasyonuna döndüğünü görür.
  • Yeniden başlatma sırasında çekirdek çöktü; kullanıcı cihazın Google önyükleme logosuna döndüğünü görür.

Kilitlenmeleri bulmak için, B iş parçacığı tarafından tutulan bir şeyi bekleyen ve A iş parçacığı tarafından tutulan bir şeyi bekleyen A iş parçacığının bir modeli için VM izleme bölümlerini kontrol edin.

Faaliyetler

Etkinlik , kullanıcıların numara çevirmek, fotoğraf çekmek, e-posta göndermek vb. bir şey yapmak için etkileşimde bulunduğu bir ekran sağlayan bir uygulama bileşenidir. Hata raporu perspektifinden bakıldığında etkinlik , kullanıcının yapabileceği tek ve odaklanmış bir şeydir. Bu da kaza sırasında odaklanılan aktivitenin yerinin belirlenmesini çok önemli kılıyor. Etkinlikler (ActivityManager aracılığıyla) süreçleri çalıştırır, böylece belirli bir etkinlik için tüm süreç duraklamalarının ve başlangıçlarının yerini belirlemek aynı zamanda sorun gidermeye de yardımcı olabilir.

Odaklanılan etkinlikleri görüntüleyin

Odaklanılan etkinliklerin geçmişini görüntülemek için am_focused_activity arayın.

Görüntüleme işlemi başlıyor

İşlem başlatma geçmişini görüntülemek için Start proc arayın.

Cihazın darbe alıp almadığını belirleme

Cihazın darbe alıp almadığını belirlemek için am_proc_died ve am_proc_start çevresinde kısa süre içinde anormal bir aktivite artışı olup olmadığını kontrol edin.

Hafıza

Android cihazlar genellikle kısıtlı fiziksel belleğe sahip olduğundan, rastgele erişim belleğini (RAM) yönetmek kritik öneme sahiptir. Hata raporları, belleğin anlık görüntüsünü sağlayan bir döküm durumunun yanı sıra, düşük belleğin çeşitli göstergelerini içerir.

Düşük belleği tanımlayın

Düşük bellek, belleği boşaltmak için bazı işlemleri sonlandırıp diğer işlemleri başlatmaya devam etmesi nedeniyle sistemin çökmesine neden olabilir. Düşük belleğin doğrulayıcı kanıtlarını görüntülemek için ikili olay günlüğündeki am_proc_died ve am_proc_start girişlerinin konsantrasyonlarını kontrol edin.

Düşük bellek ayrıca görev değiştirmeyi yavaşlatabilir ve geri dönme girişimlerini engelleyebilir (çünkü kullanıcının geri dönmeye çalıştığı görev sonlandırılmıştır). Başlatıcı öldürülürse, kullanıcı ana sayfa düğmesine dokunduğunda yeniden başlatılır ve günlükler, başlatıcının içeriğini yeniden yüklediğini gösterir.

Geçmiş göstergeleri görüntüle

İkili olay günlüğündeki am_low_memory girişi, önbelleğe alınan son işlemin öldüğünü gösterir. Bundan sonra sistem hizmetleri öldürmeye başlar.

Çarpıcı göstergeleri görüntüleyin

Sistemin parçalanmasının diğer göstergeleri (sayfalama, doğrudan geri alma vb.) kswapd , kworker ve mmcqd tüketim döngülerini içerir. (Toplanan hata raporunun çarpıtma göstergelerini etkileyebileceğini unutmayın.)

ANR günlükleri benzer bir bellek anlık görüntüsü sağlayabilir.

Bellek anlık görüntüsünü alın

Bellek anlık görüntüsü, çalışan Java ve yerel işlemleri listeleyen bir döküm durumudur (ayrıntılar için bkz . Genel Bellek Tahsislerini Görüntüleme ). Anlık görüntünün yalnızca belirli bir andaki durumu verdiğini unutmayın; anlık görüntüden önce sistem daha iyi (veya daha kötü) durumda olabilirdi.

Yayınlar

Uygulamalar, mevcut uygulama içindeki olayları veya başka bir uygulamaya göndermek için yayınlar oluşturur. Yayın alıcıları belirli mesajlara (filtreler aracılığıyla) abone olarak, yayını hem dinlemelerine hem de yanıt vermelerine olanak tanır. Hata raporları, gönderilen yayınlar ve gönderilmemiş yayınlar hakkında bilgilerin yanı sıra, belirli bir yayını dinleyen tüm alıcıların dökümlerini içerir.

Geçmiş yayınları görüntüle

Geçmiş yayınlar, daha önce gönderilmiş olan yayınlardır ve ters kronolojik sıraya göre listelenir.

Özet bölümü, son 300 ön plan yayınına ve son 300 arka plan yayınına genel bir bakış sunar.

Detay bölümü, son 50 ön plan yayınına ve son 50 arka plan yayınına ve ayrıca her yayının alıcılarına ilişkin tüm bilgileri içerir. Aşağıdaki özelliklere sahip alıcılar:

  • BroadcastFilter girişi çalışma zamanında kaydedilir ve yalnızca halihazırda çalışmakta olan işlemlere gönderilir.
  • ResolveInfo girişi manifest girişleri aracılığıyla kaydedilir. ActivityManager, halihazırda çalışmıyorsa her ResolveInfo için işlemi başlatır.

Aktif yayınları görüntüle

Aktif yayınlar henüz gönderilmemiş yayınlardır. Kuyruktaki sayının büyük olması, sistemin yayınları yetişecek kadar hızlı gönderemeyeceği anlamına gelir.

Yayın dinleyicilerini görüntüle

Bir yayını dinleyen alıcıların listesini görüntülemek için dumpsys activity broadcasts Alıcı Çözümleyici Tablosunu kontrol edin. Aşağıdaki örnek USER_PRESENT dinleyen tüm alıcıları göstermektedir.

Tartışmayı izleyin

Monitör çekişmesi günlüğü bazen gerçek monitör çekişmesini gösterebilir, ancak çoğunlukla sistemin çok yüklendiğini ve her şeyin yavaşladığını gösterir. Sistemde veya olay günlüğünde ART tarafından günlüğe kaydedilen uzun izleme olaylarını görebilirsiniz.

Sistem günlüğünde:

10-01 18:12:44.343 29761 29914 W art     : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s

Olay günlüğünde:

10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]

Arka plan derlemesi

Derleme pahalı olabilir ve cihazı yükleyebilir.

Google Play Store güncellemeleri indirilirken arka planda derleme meydana gelebilir. Bu durumda, Google Play Store uygulamasından ( finsky ) ve installd mesajlar dex2oat mesajlarından önce görünür.

Bir uygulama henüz derlenmemiş bir dex dosyasını yüklerken arka planda da derleme meydana gelebilir. Bu durumda finsky veya installd günlük kaydını göremezsiniz.

Anlatı

Bir sorunun anlatımını oluşturmak (nasıl başladı, ne oldu, sistemin nasıl tepki verdi) olayların sağlam bir zaman çizelgesini gerektirir. Zaman çizelgelerini birden çok günlük arasında senkronize etmek ve hata raporunun tam zaman damgasını belirlemek için hata raporundaki bilgileri kullanabilirsiniz.

Zaman çizelgelerini senkronize et

Bir hata raporu birden fazla paralel zaman çizelgesini yansıtır: sistem günlüğü, olay günlüğü, çekirdek günlüğü ve yayınlar için birden fazla özel zaman çizelgesi, pil istatistikleri vb. Ne yazık ki zaman çizelgeleri genellikle farklı zaman tabanları kullanılarak rapor edilir.

Sistem ve olay günlüğü zaman damgaları kullanıcıyla aynı saat dilimindedir (diğer zaman damgalarının çoğunda olduğu gibi). Örneğin, kullanıcı ana sayfa düğmesine dokunduğunda sistem günlüğü şunları bildirir:

10-03 17:19:52.939  1963  2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0

Aynı eylem için olay günlüğü şunu bildirir:

10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

Çekirdek ( dmesg ) günlükleri farklı bir zaman tabanı kullanır ve günlük öğelerini önyükleyicinin tamamlanmasından sonraki saniyelerle etiketler. Bu zaman ölçeğini diğer zaman ölçeklerine kaydetmek için, çıkışı askıya al ve girişi askıya al mesajlarını arayın:

<6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
…
<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC

Çekirdek günlükleri askıya alma sırasındaki zamanı içermeyebileceğinden, günlüğü askıya alma girişi ve çıkış mesajları arasında parçalı olarak kaydetmelisiniz. Ek olarak, çekirdek günlükleri UTC saat dilimini kullanır ve kullanıcının saat dilimine göre ayarlanması gerekir.

Hata raporu zamanını tanımlayın

Bir hata raporunun ne zaman alındığını belirlemek için öncelikle dumpstate: begin için sistem günlüğünü (Logcat) kontrol edin:

10-03 17:19:54.322 19398 19398 I dumpstate: begin

Ardından, Starting service 'bugreport' mesajı için çekirdek günlüğü ( dmesg ) zaman damgalarını kontrol edin:

<5>[207064.285315] init: Starting service 'bugreport'...

Zaman çizelgelerini senkronize etme bölümünde bahsedilen uyarıları aklınızda tutarak iki olayı ilişkilendirmek için geriye doğru çalışın. Hata raporu başlatıldıktan sonra pek çok olay meydana gelse de, hata raporunun alınması sistemi önemli ölçüde yüklediği için etkinliklerin çoğu pek kullanışlı değildir.

Güç

Olay günlüğü ekran güç durumunu içerir; burada 0 ekran kapalı, 1 ekran açık ve 2 tuş kilidi tamamlandı.

Hata raporları aynı zamanda uygulama geliştiricileri tarafından uygulamalarının cihazın açık kalması gerektiğini belirtmek için kullandıkları bir mekanizma olan uyanık kalma kilitleriyle ilgili istatistikleri de içerir. (Uyanma kilitleriyle ilgili ayrıntılar için PowerManager.WakeLock ve CPU'yu açık tutma konularına bakın.)

Toplu uyanık kalma kilidi süresi istatistikleri, yalnızca bir uyanık kalma kilidinin cihazı uyanık tutmaktan sorumlu olduğu süreyi izler ve ekranın açık olduğu süreyi içermez . Ayrıca birden fazla uyanık kalma kilidi aynı anda tutulursa uyanık kalma kilidi süresi bu uyanık kalma kilitleri arasında dağıtılır.

Güç durumunu görselleştirme konusunda daha fazla yardım için, Android hata raporu dosyalarını kullanarak pil tüketicilerini analiz etmeye yönelik bir Google açık kaynak aracı olan Battery Historian'ı kullanın.

Paketler

DUMP OF SERVICE package bölümü uygulama sürümlerini (ve diğer yararlı bilgileri) içerir.

Süreçler

Hata raporları, başlangıç ​​ve bitiş zamanı, çalışma süresi uzunluğu, ilgili hizmetler, oom_adj puanı vb. dahil olmak üzere işlemlere ilişkin büyük miktarda veri içerir. Android'in işlemleri nasıl yönettiğine ilişkin ayrıntılar için İşlemler ve İş Parçacıkları'na bakın.

Süreç çalışma zamanını belirleyin

procstats bölümü, süreçlerin ve ilgili hizmetlerin ne kadar süredir çalıştığına ilişkin eksiksiz istatistikler içerir. Hızlı, insanlar tarafından okunabilir bir özet için, son üç veya 24 saate ait verileri görüntülemek üzere AGGREGATED OVER arama yapın, ardından Summary: işlemlerin listesini, bu işlemlerin çeşitli önceliklerde ne kadar süreyle çalıştığını ve RAM'lerini görüntülemek için minimum-ortalama-maks PSS/min-ortalama-maks USS olarak biçimlendirilmiş kullanım.

Bir işlemin çalışmasının nedenleri

dumpsys activity processes bölümü, oom_adj puanına göre sıralanmış olarak çalışan tüm işlemleri listeler (Android, sürece ActivityManager tarafından dinamik olarak güncellenebilen bir oom_adj değeri atayarak sürecin önemini belirtir). Çıktı , bellek anlık görüntüsüne benzer ancak sürecin çalışmasına neyin sebep olduğu hakkında ek bilgiler içerir. Aşağıdaki örnekte, kalın harflerle yazılmış girişler gms.persistent işleminin vis (görünür) önceliğinde çalıştığını gösterir çünkü sistem işlemi NetworkLocationService bağlıdır.

taramalar

Aşırı Bluetooth Düşük Enerji (BLE) taraması gerçekleştiren uygulamaları belirlemek için aşağıdaki adımları kullanın:

  • BluetoothLeScanner için günlük mesajlarını bulun:
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • Günlük mesajlarında PID'yi bulun. Bu örnekte "24840" ve "24851", PID (işlem kimliği) ve TID'dir (iş parçacığı kimliği).
  • PID ile ilişkili uygulamayı bulun:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    

    Bu örnekte paket adı com.badapp .

  • Sorumlu uygulamayı belirlemek için Google Play'de paket adına bakın: https://play.google.com/store/apps/details?id=com.badapp .

Not : Android 7.0 çalıştıran cihazlarda sistem, BLE taramaları için veri toplar ve bu etkinlikleri başlatan uygulamayla ilişkilendirir. Ayrıntılar için bkz. Düşük Enerji (LE) ve Bluetooth taramaları .