Hata raporlarını okuma

Hatalar her türlü geliştirmede karşılaşılan bir durumdur ve hata raporları, sorunları tespit edip çözmek için çok önemlidir. 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ümler, hata raporlarını alıp e-posta, Drive vb. üzerinden paylaşmak için Geliştirici Seçeneğini destekler.

Android hata raporları, metin (.txt) biçiminde dumpsys, dumpstate ve logcat verilerini içerir. Bu sayede belirli içerikleri kolayca arayabilirsiniz. Aşağıdaki bölümlerde hata raporu bileşenleri ayrıntılı olarak açıklanmakta, yaygın sorunlar ele alınmakta ve bu hatalarla ilişkili günlükleri bulmak için yararlı ipuçları ve grep komutları verilmektedir. Çoğu bölümde grep komutu ve çıkışı ve/veya dumpsys çıkışı için örnekler de bulunur.

Logcat

logcat günlüğü, tüm logcat bilgilerinin dize tabanlı bir dökümüdür. System (Sistem) kısmı, çerçeve için ayrılmıştır ve diğer her şeyi içeren main (Ana) kısmından 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 listelenmeyebilir.

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

Bu günlük, ikili biçimli günlük mesajlarının dize gösterimlerini içerir. logcat günlüklerine kıyasla daha az bilgi içerir ancak okunması biraz daha zordur. Etkinlik günlüklerini görüntülerken, bir işlemin ne yaptığını görmek için bu bölümde belirli bir işlem kimliği (PID) arayabilirsiniz. Temel biçim şudur: timestamp PID TID log-level log-tag tag-values.

Günlük düzeyleri şunlardır:

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

 

Diğer yararlı etkinlik 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 etkinliklerine neyin neden olduğunu belirlemenize yardımcı olabilir.

Yanıt vermeyen uygulamaları belirleme

Bir uygulama, genellikle engellenen veya meşgul olan bir ana ileti dizisi nedeniyle belirli bir süre içinde yanıt vermediğinde sistem, işlemi sonlandırır ve yığını /data/anr adresine aktarır. ANR'nin nedenini bulmak için ikili etkinlik günlüğünde am_anr için grep çalıştırın.

ANR sırasında CPU'yu neyin kullandığı hakkında daha fazla bilgi içeren logcat günlük dosyasında ANR in için grep de yapabilirsiniz.

Yığın izlemeleri bulma

Genellikle ANR'ye karşılık gelen yığın izlemeleri bulabilirsiniz. Sanal makine izlemelerindeki zaman damgasının ve PID'nin, araştırdığınız ANR ile eşleştiğinden emin olun, ardından işlemin ana iş parçacısını kontrol edin. Unutmayın:

  • Ana iş parçacığı, yalnızca ANR sırasında iş parçacığının ne yaptığını gösterir. Bu durum, ANR'nin gerçek nedenine karşılık gelebilir veya gelmeyebilir. (Hata raporundaki yığın masum olabilir; başka bir şey, takılı kaldıktan sonra uzun bir süre (ancak ANR'ye neden olacak kadar uzun değil) takılı kalmış olabilir.)
  • Birden fazla yığın izleme grubu (VM TRACES JUST NOW ve VM TRACES AT LAST ANR) 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 sunucusunu etkilerse gözetleyici sonunda sunucuyu öldürür. Bu da günlüğe şuna benzer bir giriş yapılmasına neden olur: WATCHDOG KILLING SYSTEM PROCESS. Kullanıcı açısından cihaz yeniden başlatılır ancak teknik olarak bu gerçek bir yeniden başlatma yerine çalışma zamanında yeniden başlatmadır.

  • Çalışma zamanında yeniden başlatma işleminde sistem sunucusu kapanır ve yeniden başlatılır. Kullanıcı, cihazın önyükleme animasyonuna döndüğünü görür.
  • Yeniden başlatma sırasında çekirdek kilitlenir ve kullanıcı cihazın Google önyükleme logosuna döndüğünü görür.

Kilitlenmeleri bulmak için sanal makine izleme bölümlerini kontrol edin. A iş parçacığı, B iş parçacığı tarafından tutulan bir öğeyi beklerken B iş parçacığı da A iş parçacığı tarafından tutulan bir öğeyi bekliyor.

Etkinlikler

Etkinlik, kullanıcıların bir numara çevirmek, fotoğraf çekmek, e-posta göndermek gibi işlemler yapmak için etkileşimde bulunduğu bir ekran sağlayan bir uygulama bileşenidir. Hata raporu açısından etkinlik, kullanıcının yapabileceği tek ve odaklanmış bir işlemdir. Bu nedenle, kilitlenme sırasında odakta olan etkinliği bulmak çok önemlidir. Etkinlikler (ActivityManager aracılığıyla), işlemleri çalıştırır. Bu nedenle, belirli bir etkinlik için tüm işlem duraklamaları 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 simgesini arayın.

Görüntüleme işlemi başlar

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

Cihazın aşırı yük altında olup olmadığını belirleme

Cihazın aşırı yüklenme durumuna girip girmediğini belirlemek için kısa süre içinde am_proc_died ve am_proc_start civarında etkinlikte anormal bir artış olup olmadığını kontrol edin.

Bellek

Android cihazların fiziksel belleği genellikle sınırlı olduğundan, rasgele erişim belleğini (RAM) yönetmek çok önemlidir. Hata raporları, bellek yetersizliğiyle ilgili çeşitli göstergelerin yanı sıra bellek anlık görüntüsü sağlayan bir dumpstate içerir.

Düşük belleği belirleme

Düşük bellek, bellek boşaltmak için bazı işlemleri sonlandırdığı ancak diğer işlemleri başlatmaya devam ettiği için sistemin aşırı yüklenmesine neden olabilir. Hafızanın düşük olduğunu doğrulayan kanıtları görüntülemek için ikili olay günlüğünde am_proc_died ve am_proc_start girişlerinin yoğunluğunu kontrol edin.

Düşük bellek, görev geçişini yavaşlatabilir ve geri dönme girişimlerini engelleyebilir (kullanıcının geri dönmeye çalıştığı görev sonlandırıldığı için). Başlatıcı sonlandırıldıysa 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üleme

İkili etkinlik günlüğündeki am_low_memory girişi, son önbelleğe alınmış işlemin sona erdiğini gösterir. Ardından sistem, hizmetleri kapatmaya başlar.

Aşırı bellek kullanımı göstergelerini görüntüleme

Sistemde aşırı bellek kullanımının diğer göstergeleri (sayfalama, doğrudan yeniden kazanma vb.) arasında kswapd, kworker ve mmcqd tüketim döngüleri yer alır. (Toplanan hata raporunun, aşırı bellek kullanımı göstergelerini etkileyebileceğini unutmayın.)

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

Anı anlık görüntüsü alma

Bellek anlık görüntüsü, çalışan Java ve yerel işlemleri listeleyen bir dumpstate'tir (ayrıntılar için Genel Bellek Ayırmalarını Görüntüleme başlıklı makaleyi inceleyin). Anlık görüntünün yalnızca belirli bir zamandaki durumu yansıttığını unutmayın. Sistem, anlık görüntüden önce daha iyi (veya daha kötü) durumda olabilir.

Yayınlar

Uygulamalar, mevcut uygulama içinde veya başka bir uygulamaya etkinlik göndermek için yayınlar oluşturur. Yayın alıcıları, belirli mesajlara (filtreler aracılığıyla) abone olarak yayınları hem dinleyebilir hem de yanıtlayabilir. Hata raporları, gönderilen ve gönderilmeyen yayınlar hakkında bilginin yanı sıra belirli bir yayını dinleyen tüm alıcılara ait dumpsys dosyasını içerir.

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

Geçmiş yayınlar, daha önce gönderilmiş ve ters kronolojik sırayla listelenen yayınlardır.

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

Ayrıntı bölümünde, son 50 ön plan yayını ve son 50 arka plan yayını ile her yayının alıcıları hakkında eksiksiz bilgi bulunur. Aşağıdakilere sahip alıcılar:

  • BroadcastFilter girişi, çalışma zamanında kaydedilir ve yalnızca çalışan süreçlere 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.

Etkin yayınları görüntüleme

Henüz gönderilmemiş yayınlar etkin olarak kabul edilir. Sırada çok sayıda yayın varsa sistem, yayınları yetişecek kadar hızlı dağıtamıyor demektir.

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'teki Alıcı Çözücü Tablosu'nu kontrol edin. Aşağıdaki örnekte, USER_PRESENT için dinleyen tüm alıcı gösterilmektedir.

Çekişmeyi izleme

Monitör çekişmesi günlük kaydı bazen gerçek monitör çekişmesini gösterebilir ancak çoğu zaman sistemin o kadar yüklü olduğunu ve her şeyin yavaşladığını gösterir. Sistem veya olay günlüğünde ART tarafından kaydedilen uzun izleme etkinlikleri 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 planda derleme

Derleme işlemi pahalı olabilir ve cihazı yükleyebilir.

Google Play Store güncellemeleri indirilirken derleme işlemi arka planda gerçekleşebilir. Bu durumda, Google Play Store uygulamasından (finsky) ve installd gelen mesajlar dex2oat mesajlarından önce görünür.

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

Anlatım

Bir sorunun hikayesini (nasıl başladığı, ne olduğu, sistemin nasıl tepki verdiği) oluşturmak için sağlam bir zaman çizelgesi gerekir. Birden fazla günlükteki zaman çizelgelerini senkronize etmek ve hata raporunun tam zaman damgasını belirlemek için hata raporundaki bilgileri kullanabilirsiniz.

Senkronizasyon zaman çizelgeleri

Hata raporları birden fazla paralel zaman çizelgesini yansıtır: sistem günlüğü, etkinlik günlüğü, çekirdek günlüğü ve yayınlar, pil istatistikleri vb. için birden fazla özel zaman çizelgesi. Maalesef zaman çizelgeleri genellikle farklı zaman tabanları kullanılarak raporlanır.

Sistem ve etkinlik günlüğü zaman damgalarının saat dilimi, diğer zaman damgalarının çoğunda olduğu gibi kullanıcıyla aynıdır. Ö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ı işlem için etkinlik 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 farklı bir zaman tabanı kullanır ve günlük öğelerini, önyükleme yöneticisinin tamamlanmasından itibaren geçen saniyelerle etiketler. Bu zaman ölçeğini diğer zaman ölçeklerine kaydetmek için askıya alma çıkışı ve askıya alma girişi 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 alınmış durumdaki süreyi içermeyebilir. Bu nedenle, günlükleri askıya alma girişi ile çıkış mesajları arasında parçalara ayırarak kaydetmeniz gerekir. Ayrıca, çekirdek günlükleri UTC saat dilimini kullanır ve kullanıcı saat dilimine ayarlanmalıdır.

Hata raporu süresini belirleme

Bir hata raporunun ne zaman alındığını belirlemek için önce 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ının çekirdek günlüğündeki (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 etkinliği ilişkilendirmek için geriye dönük olarak çalışın. Hata raporu başlatıldıktan sonra çok fazla işlem gerçekleşse de hata raporu alma işlemi sistemi önemli ölçüde yüklediği için çoğu işlem çok yararlı değildir.

Güç

Etkinlik günlüğü, ekran güç durumunu içerir. 0, ekran kapalı, 1 ekran açık ve 2, tuş kilidi tamamlandı anlamına gelir.

Hata raporları, uygulama geliştiricilerin uygulamalarının cihazın açık kalması gerektiğini belirtmek için kullandığı bir mekanizma olan uyanma kilitleriyle ilgili istatistikleri de içerir. (Uyanık kalma kilitleri hakkında ayrıntılı bilgi için PowerManager.WakeLock ve CPU'yu açık tutma başlıklı makaleleri inceleyin.)

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

Güç durumunu görselleştirmeyle ilgili daha fazla yardım için Android hata raporu dosyalarını kullanarak pil tüketicilerini analiz eden Google açık kaynak aracı Pil Geçmişi'ni kullanın.

Paketler

DUMP OF SERVICE package bölümünde uygulama sürümleri (ve diğer yararlı bilgiler) bulunur.

İşlemler

Hata raporları, başlangıç ve bitiş zamanı, çalışma süresi, ilişkili hizmetler, oom_adj puanı vb. dahil olmak üzere işlemlerle ilgili çok fazla veri içerir. Android'in işlemleri nasıl yönettiği hakkında ayrıntılı bilgi için İşlemler ve İş Parçaları başlıklı makaleyi inceleyin.

İşlem çalışma süresini belirleme

procstats bölümünde, işlemlerin ve ilişkili hizmetlerin ne kadar süredir çalıştığına dair eksiksiz istatistikler bulunur. Hızlı ve kullanıcı tarafından okunabilir bir özet için son üç veya 24 saate ait verileri görüntülemek üzere AGGREGATED OVER'ü, ardından işlem listesini, bu işlemlerin çeşitli önceliklerde ne kadar süredir çalıştığını ve RAM kullanımlarını min-ortalama-maksimum PSS/min-ortalama-maksimum USS biçiminde görüntülemek için Summary:'ü arayın.

Bir işlemin çalışma nedenleri

dumpsys activity processes bölümünde, oom_adj puanına göre sıralanmış, şu anda çalışan tüm işlemler listelenir (Android, işleme ActivityManager tarafından dinamik olarak güncellenebilen bir oom_adj değeri atayarak işlemin önemini belirtir). Çıkış, bellek anlık görüntüsüne benzer ancak işlemin çalışmasına neyin neden olduğuyla ilgili ek bilgiler içerir. Aşağıdaki örnekte, kalın yazılmış girişler, sistem işlemi NetworkLocationService'sine bağlı olduğu için gms.persistent işleminin vis (görünür) önceliğinde çalıştığını gösterir.

Taramalar

Aşırı Bluetooth Düşük Enerji (BDE) taraması yapan uygulamaları belirlemek için aşağıdaki adımları uygulayın:

  • BluetoothLeScanner için günlük mesajlarını bulma:
    $ 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'tır.

  • Sorumlu uygulamayı belirlemek için Google Play'de paket adını arayı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 Düşük Enerji (LE) ve Bluetooth taramaları başlıklı makaleyi inceleyin.