Hata Raporlarını Okuma

Hatalar, her tür geliştirmede bir gerçektir ve hata raporları, sorunları belirlemek ve çözmek için kritik öneme sahiptir. Android'in tüm sürümleri, Android Debug Bridge (adb) ile hata raporlarının alınmasını destekler; Android 4.2 ve sonraki sürümleri, hata raporları almak ve e-posta, Drive vb. aracılığıyla paylaşmak için bir Geliştirici Seçeneğini destekler.

Android hata raporları, metin (.txt) biçiminde dumpsys , dumpstate ve logcat verilerini içerir ve belirli içeriği kolayca aramanıza olanak tanır. Aşağıdaki bölümler, hata raporu bileşenlerini ayrıntılandırıyor, yaygın sorunları açıklıyor ve bu hatalarla ilişkili günlükleri bulmak için yararlı ipuçları ve grep komutları veriyor. Çoğu bölüm ayrıca grep komutu ve çıktısı ve/veya dumpsys çıktısı için örnekler içerir.

kütük kedi

logcat günlüğü, tüm logcat bilgilerinin dize tabanlı bir dökümüdür. Sistem kısmı çerçeve için ayrılmıştır ve diğer her şeyi içeren main'den daha uzun bir geçmişe sahiptir. UID , Android'in eski sürümlerinde listelenmemiş olsa da, her satır tipik olarak timestamp UID PID TID log-level ile başlar.

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

Bu günlük, ikili biçimli günlük mesajlarının dize temsillerini içerir. logcat günlüğünden daha az gürültülüdür ama 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 şudur: timestamp PID TID log-level log-tag tag-values .

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

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

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

ANR'ler ve kilitlenmeler

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

Yanıt vermeyen uygulamaları belirleme

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

Ayrıca, ANR zamanında CPU'yu neyin kullandığı hakkında daha fazla bilgi içeren logcat günlüğünde ANR in için grep yapabilirsiniz.

Yığın izlerini bulma

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

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

Kilitlenme bulma

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

  • Çalışma zamanı yeniden başlatıldığı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şlatmada ç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 sırayla A iş parçacığı tarafından tutulan bir şeyi bekleyen bir iş parçacığı A modeli için VM izleme bölümlerini kontrol edin.

faaliyetler

Etkinlik , kullanıcıların bir numara çevirme, fotoğraf çekme, e-posta gönderme vb. işlemler yapmak için etkileşimde bulunduğu bir ekran sağlayan bir uygulama bileşenidir. Hata raporu açısından bakıldığında, etkinlik , kullanıcının yapabileceği tek, odaklanmış bir şeydir. Bu da bir çarpışma sırasında odakta olan aktiviteyi bulmayı çok önemli kılıyor. Etkinlikler (ActivityManager aracılığıyla) süreçleri çalıştırır, bu nedenle belirli bir etkinlik için tüm süreç duraklarını ve başlangıçlarını bulmak da sorun gidermeye yardımcı olabilir.

Odaklanmış etkinlikleri görüntüleme

Odaklanmış etkinliklerin geçmişini görüntülemek için am_focused_activity .

Görüntüleme süreci başlar

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

Cihaz çarpıyor mu?

Aygıtın thrash olup olmadığını belirlemek için kısa bir süre içinde am_proc_died ve am_proc_start çevresinde anormal bir etkinlik artışı olup olmadığını kontrol edin.

Hafıza

Android cihazlarda genellikle sınırlı fiziksel belleğe sahip olduğundan, rastgele erişimli belleğin (RAM) yönetilmesi kritik önem taşır. Hata raporları, birkaç düşük bellek göstergesinin yanı sıra bir bellek anlık görüntüsü sağlayan bir döküm durumu içerir.

Düşük belleği belirleme

Düşük bellek, belleği boşaltmak için bazı işlemleri öldürdüğü, ancak diğer işlemleri başlatmaya devam ettiği için sistemin çökmesine neden olabilir. Bellek yetersizliğinin doğrulayıcı kanıtını görüntülemek için ikili olay günlüğünde 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önüş girişimlerini engelleyebilir (çünkü kullanıcının geri dönmeye çalıştığı görev öldürülmüştür). Başlatıcı öldürüldüyse, kullanıcı ana sayfa düğmesine dokunduğunda yeniden başlar 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üleme

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

thrashing göstergelerini görüntüleme

Sistem thrashing'in diğer göstergeleri (sayfalama, doğrudan geri alma, vb.) kswapd , kworker ve mmcqd tüketim döngülerini içerir. (Toplanan hata raporunun thrash göstergelerini etkileyebileceğini unutmayın.)

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

Bir bellek anlık görüntüsü alma

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 Genel Bellek Tahsislerini Görüntüleme bölümüne bakın). Anlık görüntünün yalnızca belirli bir andaki durumu verdiğini unutmayın; sistem anlık görüntüden önce daha iyi (veya daha kötü) durumda olabilirdi.

yayınlar

Uygulamalar, olayları mevcut uygulama içinde 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, bir yayını hem dinlemelerini hem de yanıtlamalarını sağlar. Hata raporları, gönderilen yayınlar ve gönderilmeyen yayınlar hakkında bilgilerin yanı sıra belirli bir yayını dinleyen tüm alıcıların dökümünü içerir.

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

Tarihsel yayınlar, daha önce gönderilmiş olup, ters kronolojik sırada listelenmiştir.

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

Ayrıntı bölümü, son 50 ön plan yayını ve son 50 arka plan yayını ile her yayının alıcıları için eksiksiz bilgiler içerir. Şu özelliklere sahip alıcılar:

  • BroadcastFilter girişi, çalışma zamanında kaydedilir ve yalnızca halihazırda çalışan işlemlere gönderilir.
  • ResolveInfo girişi, bildirim 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üleme

Aktif yayınlar henüz gönderilmemiş olanlardır. Kuyruktaki çok sayıda sayı, sistemin yayınları yetişmek için yeterince hızlı gönderemeyeceği anlamına gelir.

Yayın dinleyicilerini görüntüleme

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 için dinleyen tüm alıcıları gösterir.

Tartışmayı izleyin

İzleme çekişmesi günlüğü bazen gerçek izleme çekişmesini gösterebilir, ancak çoğu zaman sistemin o kadar yüklü olduğunu ve her şeyin yavaşladığını gösterir. ART tarafından sistem veya olay günlüğünde 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 derleme

Derleme pahalı olabilir ve cihazı yükleyebilir.

Derleme, Google Play Store güncellemeleri indirilirken arka planda gerçekleşebilir. Bu durumda, Google Play mağaza uygulamasından ( finsky ) ve dex2oat installd önce görünür.

Derleme, bir uygulama henüz derlenmemiş bir dex dosyası yüklerken de arka planda gerçekleşebilir. Bu durumda, finsky veya installd günlük kaydı görmezsiniz.

Anlatı

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

Zaman çizelgelerini senkronize etme

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

Sistem ve olay günlüğü zaman damgaları, kullanıcıyla aynı saat dilimindedir (diğer zaman damgalarının çoğ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üğü şunları 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, önyükleyici tamamlandıktan sonra günlük öğelerini saniyelerle etiketleyerek farklı bir zaman tabanı kullanır. Bu zaman ölçeğini diğer zaman çizelgelerine kaydetmek için, çıkışı askıya al ve giriş mesajlarını askıya alı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ında süreyi içermeyebileceğinden, günlüğü askıya alma girişi ve çıkış mesajları arasında parça parça kaydetmelisiniz. Ek olarak, çekirdek günlükleri UTC saat dilimini kullanır ve kullanıcı saat dilimine göre ayarlanmalıdır.

Hata raporu zamanını belirleme

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

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 belirtilen uyarıları göz önünde bulundurarak, iki olayı ilişkilendirmek için geriye doğru çalışın. Hata raporu başlatıldıktan sonra çok şey olmasına rağmen, hata raporunu alma eylemi sistemi önemli ölçüde yüklediğinden çoğu etkinlik çok yararlı değildir.

Güç

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

Hata raporları, uygulama geliştiricileri tarafından, uygulamalarının cihazın açık kalması gerektiğini belirtmek için kullanılan bir mekanizma olan uyandırma kilitleriyle ilgili istatistikleri de içerir. (Uyandırma kilitleriyle ilgili ayrıntılar için bkz. PowerManager.WakeLock ve CPU'yu açık tutun .)

Toplu uyanma kilidi süresi istatistikleri, yalnızca uyanma kilidinin cihazı uyanık tutmaktan gerçekten sorumlu olduğu süreyi izler ve ekran açıkken geçen süreyi içermez . Ek olarak, aynı anda birden fazla uyandırma kilidi tutulursa, uyandırma kilidi süresi bu uyandırma 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 faydalı bilgileri) içerir.

süreçler

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

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

procstats bölümü, süreçlerin ve ilişkili hizmetlerin ne kadar süredir çalıştığına ilişkin tam istatistikleri içerir. Hızlı, insan 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 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 Summary: arayın. min-ortalama-maks PSS/min-ortalama-maks USS olarak biçimlendirilmiş kullanım.

Neden bir süreç çalışıyor?

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

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 cihazlar için sistem, BLE taramaları için veri toplar ve bu etkinlikleri başlatan uygulama ile ilişkilendirir. Ayrıntılar için Düşük Enerji (LE) ve Bluetooth taramalarına bakın.