Bu sayfada sorun giderme yardımı ve Crashlytics'i kullanmayla ilgili sık sorulan sorulara yanıtlar bulunmaktadır. Aradığınızı bulamıyorsanız veya daha fazla yardıma ihtiyacınız varsa Firebase destek ekibiyle iletişime geçin.
Genel sorun giderme/SSS
Sorunlar tablosundaki bazı sorunlar için farklı biçimler (ve bazen "varyantlar") görme
Firebase konsolundaki Sorunlar tablonuzda listelenen sorunlar için iki farklı biçim görebilirsiniz. Bazı sorunlarınız içinde "varyantlar"
olarak adlandırılan bir özellik de fark edebilirsiniz. İşte nedeni!
2023'ün başlarında, etkinlikleri gruplandırmak için iyileştirilmiş bir analiz motorunu kullanıma sunduk. Ayrıca, güncellenmiş bir tasarımı ve yeni sorunlar (varyantlar gibi) için bazı gelişmiş özellikleri kullanıma sunduk. Tüm ayrıntılar için en son blog yayınımıza göz atın. Öne çıkan özellikler için aşağıdaki yayınları da okuyabilirsiniz.
Crashlytics, uygulamanızdaki tüm etkinlikleri (kilitlenmeler, önemli olmayanlar ve ANR'ler gibi) analiz eder ve sorunlar adı verilen etkinlik grupları oluşturur. Bir sorundaki tüm etkinliklerin ortak bir hata noktası vardır.
Geliştirilmiş analiz motoru, etkinlikleri bu sorunlara göre gruplandırmak için artık yığın izlemedeki kareler, istisna mesajı, hata kodu ve diğer platform veya hata türü özellikleri dahil olmak üzere etkinliğin birçok özelliğini inceler.
Ancak bu etkinlikler grubunda hataya yol açan yığın izlemeler farklı olabilir. Farklı bir yığın izleme (stack trace), farklı bir temel neden anlamına gelebilir.
Bir sorun içindeki bu olası farkı temsil etmek için artık sorunların içinde varyantlar oluşturuyoruz. Her varyant, aynı hata noktasına ve benzer yığın izlemeye sahip bir sorundaki etkinliklerin alt grubudur. Varyantları kullanarak, bir sorundaki en yaygın yığın izlemelerde hata ayıklayabilir ve hataya farklı temel nedenlerin yol açıp açmadığını belirleyebilirsiniz.
Bu iyileştirmelerle elde edeceğiniz sonuçlar aşağıda belirtilmiştir:
Sorun satırında gösterilen meta veriler yenilendi Uygulamanızdaki sorunları anlamak ve önceliklendirmek artık daha kolay.
Yinelenen sorunların daha az olması Satır numarası değişikliği yeni bir soruna yol açmaz.
Çeşitli temel nedenlere sahip karmaşık sorunlarda daha kolay hata ayıklama Bir sorun içinde en yaygın yığın izlemelerde (stack trace) hata ayıklamak için varyantları kullanın.
Daha anlamlı uyarılar ve sinyaller Yeni bir sorun aslında yeni bir hatayı ifade eder.
Daha güçlü arama Her sorun, istisna türü ve paket adı gibi daha aranabilir meta veriler içerir.
Bu iyileştirmelerin kullanıma sunulma şekli:
Uygulamanızdan yeni etkinlikler aldığımızda, bunların mevcut bir sorunla eşleşip eşleşmediğini kontrol ederiz.
Eşleşme olmazsa etkinliğe otomatik olarak akıllı etkinlik gruplaması algoritmamızı uygular ve yenilenen meta veri tasarımıyla yeni bir sorun oluştururuz.
Bu, etkinlik gruplandırmamızda yaptığımız ilk büyük güncellemedir. Geri bildirimde bulunmak isterseniz veya herhangi bir sorunla karşılaşırsanız lütfen
rapor oluşturarak
bize bildirin.
Kilitlenme sorunu yaşamayan metrikleri ve/veya hız uyarılarını görmeme
Kilitlenme sorunu yaşamayan kullanıcılar ve oturumlar gibi metrikler ve/veya hız uyarıları görmüyorsanız
İçerik haritası günlükleri görünmüyor
İçerik haritası günlüklerini görmüyorsanız uygulamanızın Google Analytics yapılandırmasını kontrol etmenizi öneririz.
Aşağıdaki koşulları karşıladığınızdan emin olun:
Google Analytics için Firebase SDK'sının en az aşağıdaki sürümünü kullandığınızdan emin olun: Android — 17.2.3 veya sonraki sürümler(BoM 24.7.1 veya sonraki sürümler).
ANR'ler neden yalnızca Android 11 ve sonraki sürümler için bildiriliyor?
Crashlytics, Android 11 ve sonraki sürümleri çalıştıran cihazlardaki Android uygulamaları için ANR raporlarını destekler. ANR'leri toplamak için kullandığımız temel API (getHistoryProcessExitReasons), SIGQUIT veya güvenlik zamanlayıcısı tabanlı yaklaşımlardan daha güvenilirdir. Bu API yalnızca Android 11 ve sonraki sürümleri çalıştıran cihazlarda kullanılabilir.
Neden bazı ANR'lerin BuildId özellikleri eksik?
ANR'lerinizin bazılarında BuildId eksikse aşağıdaki adımları uygulayarak sorunu giderin:
Güncel bir Crashlytics Android SDK'sı ve Crashlytics Gradle eklentisi sürümü kullandığınızdan emin olun.
Android 11 ve bazı Android 12 ANR'leri BuildId eksikse muhtemelen SDK'yı, Gradle eklentisini veya ikisini birden kullanıyorsunuzdur.
Bu ANR'lerle ilgili BuildId verilerini doğru şekilde toplamak için aşağıdaki sürümleri kullanmanız gerekir:
Crashlytics Gradle eklentisi 2.9.4 ve üzeri sürümler
Paylaşılan kitaplıklarınız için standart olmayan bir konum kullanıp kullanmadığınızı kontrol edin.
Uygulamanızın paylaşılan kitaplıklarında yalnızca BuildId eksikse muhtemelen paylaşılan kitaplıklar için standart, varsayılan konumu kullanmıyorsunuzdur. Bu durumda Crashlytics, ilişkili BuildId öğelerini bulamayabilir. Paylaşılan kitaplıklar için standart konumu kullanmayı düşünmenizi öneririz.
Derleme işlemi sırasında BuildId öğelerini kaldırmadığınızdan emin olun.
Aşağıdaki sorun giderme ipuçlarının hem ANR'ler hem de yerel kilitlenmeler için geçerli olduğunu unutmayın.
İkili dosyalarınızda readelf -n çalıştırarak BuildId var olup olmadığını kontrol edin. BuildId yoksa derleme sisteminizin işaretlerine -Wl,--build-id ekleyin.
APK boyutunuzu küçültmek amacıyla BuildId'leri yanlışlıkla kaldırmadığınızdan emin olun.
Bir kitaplığın sadeleştirilmiş ve sadeleştirilmemiş sürümlerini kullanıyorsanız kodunuzda doğru sürümü işaret ettiğinizden emin olun.
Crashlytics kontrol paneli ile Google Play Console'daki ANR raporları arasındaki farklar
Google Play ile Crashlytics arasında ANR sayıları arasında uyuşmazlık olabilir. Bu, ANR verilerinin toplanması ve raporlanmasındaki farklı mekanizmalardan dolayı beklenen bir durumdur. Crashlytics, uygulama tekrar başlatıldığında ANR'leri bildirirken Android Vitals, ANR gerçekleştikten sonra ANR verilerini gönderir.
Ayrıca Crashlytics, Google Play Hizmetlerine sahip olan ve veri toplama izni kabul edilen cihazlardan ANR'leri gösteren Google Play'e kıyasla yalnızca Android 11 ve sonraki sürümlerin yüklü olduğu cihazlarda meydana gelen ANR'leri gösterir.
Crashlytics kontrol paneli ile logcat'teki NDK yığın izlemeler arasındaki farklar
LLVM ve GNU araç zincirleri, uygulamanızın ikili programlarının salt okunur segmenti için farklı varsayılan ayarlara ve işlemelere sahiptir. Bu durum, Firebase konsolunda tutarsız yığın izlemeleri oluşturabilir. Bu durumu azaltmak için derleme işleminize aşağıdaki bağlayıcı işaretlerini ekleyin:
LLVM araç zincirinden lld bağlayıcıyı kullanıyorsanız şunu ekleyin:
-Wl,--no-rosegment
GNU araç zincirinden ld.gold bağlayıcıyı kullanıyorsanız şunu ekleyin:
-Wl,--rosegment
Yığın izleme tutarsızlıkları görmeye devam ediyorsanız (veya iki işaret de araç zincirinize uygun değilse) derleme işleminize aşağıdakileri eklemeyi deneyin:
-fno-omit-frame-pointer
NDK için kendi Breakpad sembol dosyası oluşturma ikili programımı nasıl kullanabilirim?
Crashlytics eklentisi, özelleştirilmiş bir Breakpad sembol dosyası oluşturma aracı sunar.
Breakpad sembol dosyaları oluşturmak için kendi ikili programınızı kullanmayı tercih ederseniz (örneğin, derleme zincirinizdeki tüm yerel yürütülebilir dosyaları kaynaktan derlemeyi tercih ederseniz) yürütülebilir dosyanın yolunu belirtmek için isteğe bağlı symbolGeneratorBinary uzantı özelliğini kullanın.
Breakpad sembol dosyası oluşturma ikili programının yolunu iki şekilde belirtebilirsiniz:
1. Seçenek: Yolu build.gradle dosyanızdaki firebaseCrashlytics uzantısıyla belirtin
Uygulama düzeyindeki build.gradle.kts dosyanıza aşağıdakileri ekleyin:
Gradle eklentisi v3.0.0+
android {
buildTypes {
release {
configure<CrashlyticsExtension> {
nativeSymbolUploadEnabled = true
// Add these optional fields to specify the path to the executable
symbolGeneratorType = "breakpad"
breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
}
}
}
}
eski eklenti sürümleri
android {
// ...
buildTypes {
// ...
release {
// ...
firebaseCrashlytics {
// existing; required for either symbol file generator
nativeSymbolUploadEnabled true
// Add this optional new block to specify the path to the executable
symbolGenerator {
breakpad {
binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
}
}
}
}
}
2. Seçenek: Yolu Gradle özellikleri dosyanızda bir mülk satırıyla belirtin
Yürütülebilir dosyanın yolunu belirtmek için com.google.firebase.crashlytics.breakpadBinary özelliğini kullanabilirsiniz.
Gradle özellikleri dosyanızı manuel olarak veya komut satırı aracılığıyla güncelleyebilirsiniz. Örneğin, yolu komut satırından belirtmek için aşağıdaki gibi bir komut kullanın:
Neden .java sorunları olarak etiketlenmiş .kt dosyadaki kilitlenmeleri görüyorum?
Bir uygulama, dosya uzantısını göstermeyen bir kod karartma aracı kullandığında Crashlytics, her sorunu varsayılan olarak .java dosya uzantısıyla oluşturur.
Crashlytics'in doğru dosya uzantısıyla sorunlar oluşturabilmesi için uygulamanızın aşağıdaki kurulumu kullandığından emin olun:
Android Gradle 4.2.0 veya sonraki bir sürümü kullanıyor
Kod karartma özelliği açıkken R8 kullanır. Uygulamanızı R8'e güncellemek için bu dokümanları uygulayın.
Yukarıda açıklanan kuruluma geçiş yaptıktan sonra, mevcut .java sorunlarının kopyaları olan yeni .kt sorunları görmeye başlayabilirsiniz. Bu durum hakkında daha fazla bilgi edinmek için SSS bölümüne bakın.
Neden mevcut .java sorunlarının tekrarı olan .kt sorunları görüyorum?
Crashlytics, Aralık 2021'in ortalarından itibaren Kotlin kullanan uygulamalar için sunduğu desteği iyileştirdi.
Mevcut kod karartma araçları yakın zamana kadar dosya uzantısını göstermedi. Bu yüzden Crashlytics, her sorunu varsayılan olarak .java dosya uzantısıyla oluşturuyordu.
Ancak, Android Gradle 4.2.0'dan itibaren R8, dosya uzantılarını desteklemektedir.
Bu güncellemeyle Crashlytics artık uygulamada kullanılan her sınıfın Kotlin dilinde yazılıp yazılmadığını belirleyebilir ve sorun imzasına doğru dosya adını dahil edebilir. Uygulamanız aşağıdaki kuruluma sahipse kilitlenmeler artık .kt dosyalarıyla (uygun olduğu şekilde) doğru şekilde ilişkilendirilir:
Uygulamanız Android Gradle 4.2.0 veya sonraki bir sürümü kullanıyor.
Uygulamanız, kod karartma özelliği açıkken R8 kullanıyor.
Yeni kilitlenmeler artık sorun imzalarında doğru dosya uzantısını içerdiğinden, .java etiketli mevcut sorunların yalnızca kopyaları olan yeni .kt sorunlarıyla karşılaşabilirsiniz. Firebase konsolunda, yeni bir .kt sorununun mevcut .java etiketli bir sorunun olası kopyası olup olmadığını belirlemeye ve sizinle iletişime geçmeye çalışırız.
Kimler bir sorunla ilgili notları görüntüleyebilir, yazabilir ve silebilir?
Notlar, proje üyelerinin sorular, durum güncellemeleri vb. ile belirli sorunlar hakkında yorum yapmasına olanak tanır.
Proje üyesi bir not yayınladığında, bu not, Google hesabının e-postasıyla etiketlenir. Notu görüntüleme erişimi olan tüm proje üyeleri, notla birlikte bu e-posta adresini görebilir.
Aşağıda notları görüntülemek, yazmak ve silmek için gereken erişim açıklanmaktadır:
Aşağıdaki rollerden herhangi birine sahip proje üyeleri mevcut notları görüntüleyebilir, silebilir ve bir sorun hakkında yeni notlar yazabilir.
Kimler bir sorunla ilgili notları görüntüleyebilir, yazabilir ve silebilir?
Notlar, proje üyelerinin sorular, durum güncellemeleri vb. ile belirli sorunlar hakkında yorum yapmasına olanak tanır.
Proje üyesi bir not yayınladığında, bu not, Google hesabının e-postasıyla etiketlenir. Notu görüntüleme erişimi olan tüm proje üyeleri, notla birlikte bu e-posta adresini görebilir.
Aşağıda notları görüntülemek, yazmak ve silmek için gereken erişim açıklanmaktadır:
Aşağıdaki rollerden herhangi birine sahip proje üyeleri mevcut notları görüntüleyebilir, silebilir ve bir sorun hakkında yeni notlar yazabilir.
Uygulama aynı zamanda Google Mobile Ads SDK'sını kullanıyor ancak kilitlenme almıyor
Projeniz Google Mobile Ads SDK'sı ile birlikte Crashlytics kullanıyorsa istisna işleyicileri kaydederken kilitlenme raporu verenler müdahale ediyor olabilir. Sorunu düzeltmek için disableSDKCrashReporting yöntemini çağırarak Mobile Ads SDK'sında kilitlenme raporlarını devre dışı bırakın.
BigQuery veri kümem nerede bulunuyor?
Crashlytics'i BigQuery'ye bağladıktan sonra, oluşturduğunuz yeni veri kümeleri Firebase projenizin konumundan bağımsız olarak otomatik olarak ABD'de yerleştirilir.
Platform desteği
Crashlytics, armeabi'yi destekliyor mu?
Firebase Crashlytics NDK, ARMv5'i (armeabi) desteklemez.
Bu ABI için destek, NDK r17 itibarıyla kaldırılmıştır.
Geri çekilen sorunlar
Geri çekilen sorun nedir?
Daha önce sorunu kapattığınızda ise Crashlytics, sorunun yeniden oluştuğuna dair yeni bir rapor alıyor.
Crashlytics, geri çekilen bu sorunları otomatik olarak yeniden açar. Böylece bu sorunları uygulamanıza uygun şekilde ele alabilirsiniz.
Aşağıda, Crashlytics'in bir sorunu regresyon olarak nasıl sınıflandırdığını açıklayan bir örnek senaryo verilmiştir:
Crashlytics ilk kez Crash "A" ile ilgili bir kilitlenme raporu alıyor. Crashlytics, bu kilitlenme için ilgili sorunu ("A" sorunu) açar.
Bu hatayı hızlı bir şekilde düzeltir, "A" Sorunu'nu kapatır ve ardından uygulamanızın yeni bir sürümünü yayınlarsınız.
Crashlytics, siz sorunu kapattıktan sonra "A" sorunuyla ilgili bir rapor daha alır.
Rapor, sorunu kapattığınızda bildiği bir uygulama sürümünden geliyorsa (yani sürümde herhangi bir kilitlenme için kilitlenme raporu gönderilmişse) Crashlytics, sorunu regresyon olarak değerlendirmez. Sorun kapalı kalacaktır.
Rapor, sorunu kapattığınızda hiçbir zaman Crashlytics'in bilmediği bir uygulama sürümünden geliyorsa (yani sürümde, herhangi bir kilitlenme için hiçhiç kilitlenme raporu göndermediyse) Crashlytics sorunun geri çekileni kabul eder ve sorunu yeniden açar.
Bir sorun geri çekildiğinde, regresyon algılama uyarısı gönderir ve Crashlytics'in sorunu yeniden açtığını bildirmek için soruna bir regresyon sinyali ekleriz. Bir sorunun, regresyon algoritmamız nedeniyle yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "sesi kapatın".
Neden eski uygulama sürümlerinde geri çekilen sorunlar görüyorum?
Rapor, sorunu kapattığınızda hiç kilitlenme raporu göndermemiş eski bir uygulama sürümünden geliyorsa Crashlytics, sorunun geri alındığını dikkate alarak sorunu yeniden açar.
Bu durum, şu durumda meydana gelebilir: Bir hatayı düzelttiniz ve uygulamanızın yeni bir sürümünü yayınladınız ancak hata düzeltmesi yapılmadan eski sürümlerini kullanmaya devam eden kullanıcılarınız var. Şans eseri, bu eski sürümlerden biri sorunu kapattığınızda hiç kilitlenme raporu göndermediyse ve bu kullanıcılar hatayla karşılaşmaya başladıysa bu kilitlenme raporları geri çekilen bir sorunu tetikler.
Regresyon algoritmamız nedeniyle bir sorunun yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "sesi kapatın".