Hata raporlarını okuma

Hatalar, her türlü geliştirme sürecinde karşılaşılabilecek bir durumdur. 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 raporu yakalamayı destekler. Android 4.2 ve sonraki sürümler ise hata raporu alıp e-posta, Drive vb. üzerinden paylaşmak için Geliştirici Seçeneği'ni destekler.

Android hata raporları, metin (.txt) biçiminde dumpsys, dumpstate ve logcat verileri 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, sık karşılaşılan sorunlar açıklanmakta 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ışı ile/veya dumpsys çıkışına ilişkin örnekler de yer alır.

Logcat

logcat günlüğü, tüm logcat bilgilerinin dize tabanlı bir dökümüdür. Sistem bölümü, çerçeve için ayrılmıştır ve diğer her şeyi içeren ana bölümden daha eski 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üğüne göre daha az gürültülüdür ancak 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 bir işlem kimliğini (PID) arayabilirsiniz. Temel biçim şöyledir: 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: information
  • 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 olaylarına neyin neden olduğunu belirlemenize yardımcı olabilir.

Yanıt vermeyen uygulamaları belirleme

Bir uygulama belirli bir süre içinde yanıt vermediğinde (genellikle engellenmiş veya meşgul bir ana ileti dizisinden kaynaklanır) sistem işlemi sonlandırır ve yığını /data/anr konumuna boşaltır. ANR'nin arkasındaki nedeni bulmak için ikili etkinlik günlüğünde am_anr ifadesini arayın.

ANR sırasında CPU'yu kullanan işlemler hakkında daha fazla bilgi içeren logcat günlüğünde ANR in için de grep yapabilirsiniz.

Yığın izlemelerini 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ığını kontrol edin. Unutmayın:

  • Ana iş parçacığı, yalnızca iş parçacığının ANR sırasında ne yaptığını söyler. Bu, ANR'nin gerçek nedeni ile eşleşebilir veya eşleşmeyebilir. (Hata raporundaki yığın masum olabilir. Başka bir şey uzun süre takılmış olabilir ancak ANR'ye neden olacak kadar uzun süre takılmamış olabilir.)
  • Birden fazla yığın izi grubu (VM TRACES JUST NOW ve VM TRACES AT LAST ANR) olabilir. Doğru bölümü görüntülediğinizden emin olun.

Kilitlenmeleri bulma

Kilitlenmeler, iş parçacıkları takıldığından genellikle ilk olarak ANR olarak görünür. Kilitlenme sistem sunucusunu etkilerse watchdog sonunda sistemi sonlandırır ve günlükte aşağıdakine benzer bir giriş oluşturulur: WATCHDOG KILLING SYSTEM PROCESS. Kullanıcı açısından cihaz yeniden başlatılır. Ancak bu, teknik olarak gerçek bir yeniden başlatma değil, çalışma zamanı yeniden başlatmasıdır.

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

Kilitlenmeleri bulmak için VM izleri bölümlerinde, A iş parçacığının B iş parçacığı tarafından tutulan bir şeyi beklemesi ve B iş parçacığının da A iş parçacığı tarafından tutulan bir şeyi beklemesiyle ilgili bir kalıp olup olmadığını kontrol edin.

Etkinlikler

Etkinlik, kullanıcıların bir işlem yapmak için etkileşimde bulunduğu bir ekran sağlayan uygulama bileşenidir (ör. numara çevirme, fotoğraf çekme, e-posta gönderme vb.). Hata raporu açısından etkinlik, kullanıcının yapabileceği tek ve odaklanılmış bir işlemdir. Bu nedenle, kilitlenme sırasında odaklanılan etkinliğin bulunması çok önemlidir. Etkinlikler (ActivityManager aracılığıyla) işlemleri çalıştırır. Bu nedenle, belirli bir etkinlik için tüm işlem durdurma ve başlatma işlemlerini bulmak sorun gidermeye de yardımcı olabilir.

Odaklanılmış etkinlikleri görüntüleme

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

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

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

Cihazın aşırı yüklenip yüklenmediğini belirleme

Cihazın aşırı yüklenip yüklenmediğini belirlemek için kısa süre içinde am_proc_died ve am_proc_start çevresindeki etkinlikte anormal bir artış olup olmadığını kontrol edin.

Bellek

Android cihazlarda genellikle fiziksel bellek sınırlı olduğundan rastgele erişimli bellek (RAM) yönetimi çok önemlidir. Hata raporları, bellek anlık görüntüsü sağlayan bir dumpstate'in yanı sıra düşük bellekle ilgili çeşitli göstergeler içerir.

Yetersiz belleği belirleme

Düşük bellek, bazı işlemleri sonlandırarak bellek boşaltmaya çalışırken diğer işlemleri başlatmaya devam ettiğinden sistemin aşırı yüklenmesine neden olabilir. Düşük bellekle ilgili 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örevler arasında geçişi yavaşlatabilir ve kullanıcının geri dönmeye çalıştığı görev sonlandırıldığından geri dönme girişimlerini engelleyebilir. 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ınan işlemin sonlandırıldığını gösterir. Bundan sonra sistem, hizmetleri sonlandırmaya başlar.

Aşırı yüklenme göstergelerini görüntüleme

Sistem thrashing'in (sayfalama, doğrudan geri kazanma vb.) diğer göstergeleri arasında kswapd, kworker ve mmcqd döngüleri tüketimi yer alır. (Toplanan hata raporunun, aşırı yüklenme 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ı makaleye bakın). Anlık görüntünün yalnızca belirli bir andaki durumu gösterdiğini 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ını hem dinleyebilir hem de yanıtlayabilir. Hata raporları, gönderilen ve gönderilmeyen yayınlar hakkında bilgilerin yanı sıra belirli bir yayını dinleyen tüm alıcıların dumpsys'ini içerir.

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

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

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

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 bilgiler yer alır. Aşağıdakilere 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, manifest girişleri aracılığıyla kaydedilir. ActivityManager, her ResolveInfo için işlem başlatır.

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

Etkin yayınlar, henüz gönderilmemiş olanlardır. Kuyruktaki yüksek sayı, sistemin yayınları yeterince hızlı gönderemediğ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 bölümündeki Alıcı Çözümleyici Tablosu'nu kontrol edin. Aşağıdaki örnekte, USER_PRESENT için dinleme yapan tüm alıcılar gösterilmektedir.

Çakışmayı izleme

İzleme anlaşmazlığı günlüğü bazen gerçek izleme anlaşmazlığını gösterebilir ancak çoğu zaman sistemin o kadar yüklendiğini gösterir ki her şey yavaşlamıştır. ART tarafından sistem veya etkinlik günlüğüne 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österilir.

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

Anlatıcı

Bir sorunun anlatısını oluşturmak (nasıl başladığı, ne olduğu, sistemin nasıl tepki verdiği) için sağlam bir etkinlik zaman çizelgesi gerekir. 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.

Senkronizasyon zaman çizelgeleri

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

Sistem ve etkinlik günlüğü zaman damgaları, kullanıcının bulunduğu saat dilimindedir (diğer zaman damgalarının çoğu da 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ükleyici tamamlandıktan sonraki saniyelerle etiketler. Bu zaman ölçeğini diğer zaman ölçeklerine kaydetmek için suspend exit ve suspend entry 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

Askıya alma sırasında çekirdek günlükleri zaman içermeyebileceğinden, günlüğü askıya alma giriş ve çıkış iletileri arasında parça parça kaydetmeniz gerekir. Ayrıca, çekirdek günlükleri UTC saat dilimini kullanır ve kullanıcının saat dilimine göre ayarlanmalıdır.

Hata raporu zamanını belirleme

Hata raporunun ne zaman alındığını belirlemek için önce dumpstate: begin cihazının 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 belirtilen uyarıları göz önünde bulundurarak iki etkinliği ilişkilendirmek için geriye doğru çalışın. Hata raporu başlatıldıktan sonra birçok işlem gerçekleşse de hata raporu alma işlemi sistemi önemli ölçüde yüklediğinden çoğu işlem pek kullanışlı değildir.

Güç

Etkinlik günlüğünde ekran güç durumu yer alır. Burada 0 ekran kapalı, 1 ekran açık ve 2 ise tuş kilidi tamamlandı anlamına gelir.

Hata raporları, uygulama geliştiricilerin uygulamalarının cihazın açık kalmasını gerektirdiğini belirtmek için kullandığı bir mekanizma olan uyandırma 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.)

Toplanan uyanık kalma kilidi süresi istatistikleri yalnızca uyanık kalma kilidinin cihazı uyanık tuttuğ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 tutuluyorsa 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ünde uygulama sürümleri (ve diğer faydalı bilgiler) yer alır.

İşlemler

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

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

procstats bölümünde, işlemlerin ve ilişkili hizmetlerin ne kadar süredir çalıştığına dair eksiksiz istatistikler yer alır. Hızlı ve okunabilir bir özet için AGGREGATED OVER ifadesini arayarak son üç veya 24 saate ait verileri görüntüleyin. Ardından, Summary: ifadesini arayarak işlemlerin listesini, bu işlemlerin çeşitli önceliklerde ne kadar süreyle çalıştığını ve RAM kullanımını (en az-ortalama-en fazla PSS/en az-ortalama-en fazla USS olarak biçimlendirilmiş) görüntüleyin.

Bir sürecin çalıştırılma 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 bir oom_adj değeri atayarak işlem önemini belirtir. Bu değer, ActivityManager tarafından dinamik olarak güncellenebilir). Çı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, sistem işlemi NetworkLocationService'ye bağlı olduğundan, kalın yazılan girişler gms.persistent işleminin vis (görünür) önceliğinde çalıştığını gösterir.

Taramalar

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

  • BluetoothLeScanner ile ilgili 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
    
  • PID'yi günlük iletilerinde bulun. Bu örnekte, "24840" ve "24851" PID (işlem kimliği) ve TID (iş parçacığı kimliği) değerleridir.
  • PID ile ilişkili uygulamayı bulun:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    

    Bu örnekte paket adı com.badapp'dı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.