Bu sayfada, Crashlytics kullanımıyla ilgili sık sorulan soruların yanıtları ve sorun giderme yardımı sağlanmaktadır. Aradığınızı bulamıyorsanız veya daha fazla yardıma ihtiyacınız varsa Firebase Destek Ekibi ile 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. Ayrıca, bazı sorunlarınızda "varyantlar" adlı bir özellik de görebilirsiniz. İşte nedeni.
2023'ün başlarında, etkinlikleri gruplandırmak için geliştirilmiş bir analiz motorunun yanı sıra güncellenmiş bir tasarım ve yeni sorunlar (ör. varyantlar) için bazı gelişmiş özellikler kullanıma sunduk. Tüm ayrıntılar için son blog yayınımıza göz atın. Önemli noktaları ise aşağıda bulabilirsiniz.
Crashlytics, uygulamanızdaki tüm etkinlikleri (ör. çökmeler, önemli olmayan hatalar ve ANR'ler) analiz eder ve sorun adı verilen etkinlik grupları oluşturur. Bir sorundaki tüm etkinliklerin ortak bir hata noktası vardır.
Etkinlikleri bu sorunlar halinde gruplandırmak için iyileştirilmiş analiz motoru artık etkinliklerin birçok yönünü (yığın izindeki çerçeveler, istisna mesajı, hata kodu ve diğer platform veya hata türü özellikleri dahil) inceliyor.
Ancak bu etkinlik grubunda, hataya yol açan yığın izlemeler farklı olabilir. Farklı bir yığın izleme, farklı bir temel neden anlamına gelebilir.
Bir sorundaki bu olası farkı göstermek için artık sorunlar içinde varyantlar oluşturuyoruz. Her varyant, bir sorundaki aynı hata noktasına ve benzer yığın izlemeye sahip etkinliklerin alt grubudur. Varyantlarla,
bir sorundaki en yaygın yığın izlerini ayıklayabilir ve farklı temel nedenlerin hataya yol açıp açmadığını belirleyebilirsiniz.
Bu iyileştirmelerle karşılaşacağınız deneyim:
Sorun satırında gösterilen meta veriler yenilendi Uygulamanızdaki sorunları anlamak ve önceliklendirmek artık daha kolay.
Daha az yinelenen sorun Satır numarası değişikliği yeni bir soruna neden olmaz.
Çeşitli temel nedenleri olan karmaşık sorunlarda daha kolay hata ayıklama Bir sorundaki en yaygın yığın izlerinde hata ayıklamak için varyantları kullanın.
Daha anlamlı uyarılar ve sinyaller Yeni bir sorun aslında yeni bir hatayı temsil eder.
Daha güçlü arama Her sorunda, hata türü ve paket adı gibi daha fazla aranabilir meta veri bulunur.
Bu iyileştirmeler şu şekilde kullanıma sunuluyor:
Uygulamanızdan yeni etkinlikler aldığımızda, bunların mevcut bir sorunla eşleşip eşleşmediğini kontrol ederiz.
Eşleşme yoksa etkinliğe daha akıllı etkinlik gruplandırma algoritmamızı otomatik olarak uygularız 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 bildiriminiz varsa veya herhangi bir sorunla karşılaşırsanız lütfen
rapor göndererek
bize bildirin.
İçerik haritası günlüklerini görmüyorsanız
Ayrıntılı günlükler 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 Veri paylaşımı'nı etkinleştirmişsinizdir. Bu ayar hakkında daha fazla bilgi edinmek için Analytics veri paylaşım ayarlarınızı yönetme başlıklı makaleyi inceleyin.
Özellikle Google Analytics için Firebase SDK'sının en azından aşağıdaki sürümünü kullandığınızdan emin olun: Android — v17.2.3+(BoM v24.7.1+).
Hız uyarılarını görmüyorsanız
Hız uyarılarını görmüyorsanız aşağıdakileri kullandığınızdan emin olun:
Crashlytics SDK 18.6.0 sürümü veya üzeri (ya da Firebase BoM 32.6.0 sürümü veya üzeri).
Kilitlenme içermeyen metrikleri görmeme (veya güvenilir olmayan metrikleri görme)
Kilitlenme sorunu ile karşılaşmayan kullanıcılar ve oturumlar gibi kilitlenme sorunu ile karşılaşmayan kullanıcılarla ilgili metrikleri görmüyorsanız veya güvenilir olmayan metrikler görüyorsanız aşağıdakileri kontrol edin:
Aşağıdaki SDK'lardan birini kullandığınızdan emin olun:
Crashlytics SDK v18.6.0+ (veya Firebase BoM v32.6.0+).
Veri toplama ayarlarınızın, hatasız oturum metriklerinizin kalitesini etkilemediğinden emin olun:
Otomatik kilitlenme raporlamayı devre dışı bırakarak etkinleştirme raporlamayı etkinleştirirseniz kilitlenme bilgileri yalnızca veri toplamayı açıkça etkinleştirmiş kullanıcılardan Crashlytics'a gönderilebilir. Bu nedenle, Crashlytics yalnızca bu kullanıcıların kilitlenme bilgilerine sahip olduğundan (tüm kullanıcılarınızın bilgilerine değil) kilitlenmesiz metriklerin doğruluğu etkilenir. Bu durum, kilitlenme içermeyen metriklerinizin daha az güvenilir olabileceği ve uygulamanızın genel kararlılığını daha az yansıtacağı anlamına gelir.
Otomatik veri toplamayı devre dışı bıraktıysanız cihazda önbelleğe alınan raporları Crashlytics adresine göndermek için sendUnsentReports kullanabilirsiniz.
Bu yöntemi kullanmak Crashlytics'e kilitlenme verilerini gönderir ancak oturum verilerini göndermez. Bu durum, konsol grafiklerinin kilitlenmesiz metrikler için düşük veya sıfır değerler göstermesine neden olur.
Kilitlenme sorunu yaşamayan kullanıcılar nasıl hesaplanır?
Neden yalnızca Android 11 ve sonraki sürümlerde ANR'ler bildiriliyor?
Crashlytics, Android 11 ve sonraki sürümleri çalıştıran cihazlardaki Android uygulamaları için ANR raporlamasını destekler. ANR'leri toplamak için kullandığımız temel API (getHistoricalProcessExitReasons), SIGQUIT veya watchdog tabanlı yaklaşımlardan daha güvenilirdir. Bu API yalnızca Android 11 ve sonraki sürümlerde kullanılabilir.
Bazı ANR'lerde neden BuildId eksik?
ANR'lerinizin bazılarında BuildId eksikse aşağıdaki şekilde sorun giderin:
Crashlytics Android SDK'sının ve Crashlytics Gradle eklentisi sürümünün güncel olduğundan emin olun.
Android 11 için BuildId ve bazı Android 12 ANR'leri eksikse eski bir SDK, Gradle eklentisi veya her ikisini de kullanıyor olabilirsiniz.
Bu ANR'ler için BuildId'leri düzgün şekilde toplamak üzere aşağıdaki sürümleri kullanmanız gerekir:
Crashlytics Gradle eklentisi v2.9.4 veya daha yeni bir sürüm
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ı için yalnızcaBuildIdeksikse büyük olasılıkla paylaşılan kitaplıklar için standart ve varsayılan konumu kullanmıyorsunuzdur. Bu durumda Crashlytics, ilişkili BuildId'leri bulamayabilir. Paylaşılan kitaplıklar için standart konumu kullanmanızı öneririz.
Oluşturma işlemi sırasında BuildId karakterlerini 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 komutunu çalıştırarak BuildId öğelerinin mevcut olup olmadığını kontrol edin. BuildId yoksa derleme sisteminizin işaretlerine -Wl,--build-id ekleyin.
APK boyutunuzu küçültmek için BuildId karakterlerini istemeden kaldırmadığınızdan emin olun.
Bir kitaplığın hem sembolsüz hem de sembollü sürümlerini saklıyorsanız kodunuzda doğru sürümü belirttiğinizden emin olun.
Crashlytics Kontrol panelindeki ANR raporları ile Google Play Console arasındaki farklılıklar
Google Play ile Crashlytics arasındaki ANR sayısı arasında uyuşmazlık olabilir. Bu durum, ANR verilerini toplama ve raporlama mekanizmasındaki farklılıktan kaynaklanmaktadır. Crashlytics, uygulama bir sonraki başlatıldığında ANR'leri bildirirken Android vitals, ANR verilerini ANR gerçekleştikten sonra gönderir.
Ayrıca Crashlytics, Google Play'in Google Play Hizmetleri ve veri toplama izni kabul edilmiş cihazlardan gelen ANR'leri göstermesine kıyasla yalnızca Android 11 ve üzeri sürümlerin yüklü olduğu cihazlarda meydana gelen ANR'leri gösterir.
Crashlytics kontrol panelindeki ve logcat'teki NDK yığın izleri arasındaki farklar
LLVM ve GNU araç zincirleri, uygulamanızın ikililerinin salt okunur segmenti için farklı varsayılanlara ve işlemlere sahiptir. Bu durum, Firebase konsolunda tutarsız yığın izlemeleri oluşturabilir. Bu durumu azaltmak için derleme sürecinize aşağıdaki bağlayıcı işaretlerini ekleyin:
LLVM araç zincirindeki lld bağlayıcısını kullanıyorsanız şunu ekleyin:
-Wl,--no-rosegment
GNU araç zincirindeki ld.gold bağlayıcıyı kullanıyorsanız şunu ekleyin:
-Wl,--rosegment
Yine de yığın izi tutarsızlıkları görüyorsanız (veya her iki işaret de araç zincirinizle alakalı değilse) bunun yerine derleme sürecinize aşağıdakileri eklemeyi deneyin:
-fno-omit-frame-pointer
NDK için kendi Breakpad sembol dosyası oluşturucu ikilimi nasıl kullanırım?
Crashlytics eklentisi, özelleştirilmiş bir Breakpad sembol dosyası oluşturucu içerir.
Breakpad sembol dosyaları oluşturmak için kendi ikili dosyanızı kullanmayı tercih ediyorsanız (örneğin, derleme zincirinizdeki tüm yerel yürütülebilir dosyaları kaynaktan oluşturmayı tercih ediyorsanız) yürütülebilir dosyanın yolunu belirtmek için isteğe bağlı symbolGeneratorBinary uzantı özelliğini kullanın.
Breakpad sembol dosyası oluşturucu ikilisinin yolunu iki şekilde belirtebilirsiniz:
1. seçenek: firebaseCrashlytics
uzantısı aracılığıyla build.gradle dosyanızda yolu belirtin
Uygulama düzeyindeki build.gradle.kts dosyanıza aşağıdakileri ekleyin:
Gradle eklentisi v3.0.0 veya daha yeni bir sürüm
android{buildTypes{release{configure<CrashlyticsExtension>{nativeSymbolUploadEnabled=true// Add these optional fields to specify the path to the executablesymbolGeneratorType="breakpad"breakpadBinary=file("/PATH/TO/BREAKPAD/DUMP_SYMS")}}}}
daha düşük eklenti sürümleri
android{// ...buildTypes{// ...release{// ...firebaseCrashlytics{// existing; required for either symbol file generatornativeSymbolUploadEnabledtrue// Add this optional new block to specify the path to the executablesymbolGenerator{breakpad{binaryfile("/PATH/TO/BREAKPAD/DUMP_SYMS")}}}}}
2. seçenek: Gradle properties dosyanızdaki bir özellik satırı aracılığıyla yolu belirtin
Yürütülebilir dosyanın yolunu belirtmek için com.google.firebase.crashlytics.breakpadBinary özelliğini kullanabilirsiniz.
Gradle özellikler dosyanızı manuel olarak veya komut satırı üzerinden güncelleyebilirsiniz. Örneğin, yolu komut satırı üzerinden belirtmek için aşağıdaki gibi bir komut kullanın:
.kt dosyalarından kaynaklanan kilitlenmeleri neden .java sorunları olarak görüyorum?
Bir uygulama, dosya uzantısını göstermeyen bir karartıcı kullandığında Crashlytics, her sorunu varsayılan olarak .java dosya uzantısıyla oluşturur.
Crashlytics'nın doğru dosya uzantısına sahip 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ünü kullanıyor olmanız gerekir.
Karartma etkin durumdayken R8'i kullanır. Uygulamanızı R8'e güncellemek için bu dokümanı inceleyin.
Yukarıda açıklanan kurulumu güncelledikten sonra, mevcut .java sorunlarının kopyası olan yeni .kt sorunlar görmeye başlayabilirsiniz. Bu durum hakkında daha fazla bilgi edinmek için SSS sayfasını inceleyin.
Neden .kt sorunlarının kopyaları olan .java sorunlarını görüyorum?
2021'in Aralık ayının ortasından itibaren, Crashlytics Kotlin kullanan uygulamalar için destek iyileştirildi.
Yakın zamana kadar, kullanılabilen karartma araçları dosya uzantısını göstermiyordu. Bu nedenle, 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ı destekler.
Bu güncellemeyle birlikte Crashlytics artık uygulama içinde kullanılan her sınıfın Kotlin ile yazılıp yazılmadığını belirleyebilir ve sorunun imzasında doğru dosya adını kullanabilir. Uygulamanızda aşağıdaki kurulum varsa kilitlenmeler artık .kt dosyalarına (uygun şekilde) doğru şekilde ilişkilendiriliyor:
Uygulamanızda Android Gradle 4.2.0 veya sonraki bir sürüm kullanılıyor.
Uygulamanızda karartma etkin durumdayken R8 kullanılıyor.
Yeni kilitlenmeler artık sorun imzalarında doğru dosya uzantısını içerdiğinden, yeni .kt sorunları görebilirsiniz. Bu sorunlar aslında mevcut .java etiketli sorunların yalnızca kopyalarıdır. Firebase konsolunda, yeni bir .kt sorununun mevcut bir .java etiketli sorunun olası bir kopyası olup olmadığını belirlemeye ve bu durumu size bildirmeye çalışırız.
Bir sorundaki notları kimler görüntüleyebilir, yazabilir ve silebilir?
Notlar, proje üyelerinin belirli sorunlarla ilgili sorular, durum güncellemeleri vb. hakkında yorum yapmasına olanak tanır.
Proje üyeleri not yayınladığında, notlar Google Hesaplarının e-posta adresiyle etiketlenir. Bu e-posta adresi, notu görüntüleme erişimi olan tüm proje üyelerine notla birlikte gösterilir.
Notları görüntülemek, yazmak ve silmek için gereken erişim aşağıda açıklanmıştır:
Aşağıdaki rollerden herhangi birine sahip proje üyeleri, mevcut notları görüntüleyip silebilir ve bir sorunla ilgili yeni notlar yazabilir.
Uygulama, Google Mobile Ads SDK'sını da kullanıyor ancak kilitlenmiyor
Projenizde Google Mobile Ads SDK'sının yanı sıra Crashlytics kullanılıyorsa kilitlenme raporlayıcılar, istisna işleyicileri kaydederken çakışıyor olabilir. Sorunu düzeltmek için disableSDKCrashReporting işlevini çağırarak Mobile Ads SDK'sında kilitlenme raporlamayı 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 yer alır.
Platform desteği
Crashlytics, armeabi'yi destekliyor mu?
Firebase Crashlytics NDK, ARMv5'i (armeabi) desteklemez.
Bu ABI için destek, NDK r17 sürümünden itibaren kaldırıldı.
Geri çekilen sorunlar
Regresyona uğramış sorun nedir?
Daha önce kapattığınız bir sorun, Crashlytics yeni bir rapor aldığında gerileme yaşamış demektir. Bu rapor, sorunun tekrar ortaya çıktığını belirtir.
Crashlytics, bu gerileme sorunlarını otomatik olarak yeniden açar. Böylece, uygulamanıza uygun şekilde bu sorunları giderebilirsiniz.
Crashlytics'nın bir sorunu regresyon olarak nasıl sınıflandırdığını açıklayan örnek bir senaryoyu aşağıda bulabilirsiniz:
Crashlytics, ilk kez "A" kilitlenmesiyle ilgili bir kilitlenme raporu alıyor. Crashlytics, bu kilitlenme için ilgili bir sorun açar (A sorunu).
Bu hatayı hızlıca düzeltir, "A" sorununu kapatır ve uygulamanızın yeni bir sürümünü yayınlarsınız.
Crashlytics, sorunu kapattıktan sonra "A" sorunuyla ilgili başka bir rapor alır.
Rapor, sorunu kapattığınızda Crashlyticsbilgisi olan
bir uygulama sürümünden geliyorsa (yani sürüm, herhangi bir kilitlenme için kilitlenme raporu göndermişse) Crashlytics sorunu gerilemiş olarak değerlendirmez. Destek kaydı kapalı kalır.
Rapor, sorunu kapattığınızda Crashlyticsbilinmeyen bir uygulama sürümünden geliyorsa (yani sürüm, herhangi bir kilitlenme için hiçbir kilitlenme raporu göndermediyse) Crashlytics sorunun gerilediğini düşünür ve sorunu yeniden açar.
Bir sorun gerilediğinde, gerileme tespit uyarısı göndeririz ve Crashlytics kullanıcısının sorunu yeniden açtığını bildirmek için soruna gerileme sinyali ekleriz. Regresyon algoritmamız nedeniyle bir sorunun yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "sessize" alın.
Neden eski uygulama sürümlerinde gerileme sorunları görüyorum?
Bir rapor, sorunu kapattığınızda hiç kilitlenme raporu göndermemiş eski bir uygulama sürümünden geliyorsa Crashlytics sorunun tekrar ortaya çıktığını düşünür ve sorunu yeniden açar.
Bu durum şu senaryoda yaşanabilir: Bir hatayı düzelttiniz ve uygulamanızın yeni bir sürümünü yayınladınız ancak uygulamanızın eski sürümlerini kullanan ve hata düzeltmesini içermeyen kullanıcılarınız var. Eski sürümlerden biri, sorunu kapattığınızda hiçbir kilitlenme raporu göndermediyse ve bu sürümü kullananlar hatayla karşılaşmaya başlarsa bu kilitlenme raporları, gerilemiş bir sorunu tetikler.
Regresyon algoritmamız nedeniyle bir sorunun yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "sessize alın".
