Bu sayfada, sorun gidermeyle ilgili yardım ve sık sorulan soruların yanıtlarını bulabilirsiniz.
Crashlytics kullanımıyla ilgili sorularınız var. Şu durumda:
Aradığınızı bulamıyorum veya daha fazla yardıma ihtiyacınız var,
Firebase desteği.
Genel sorun giderme/SSS
Sorunlar tablosunda 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. Bunun nedeni:
2023'ün başlarında, etkinlikleri farklı gruplar şeklinde gruplandırmak için iyileştirilmiş bir analiz motorunu kullanıma sunduk.
ayrıca yeni sorunlar için güncellenmiş bir tasarım ve bazı gelişmiş özelliklerin (ör.
ekleyin!). Tüm ayrıntılar için son blog yayınımıza göz atın. Önemli noktaları aşağıda bulabilirsiniz.
Crashlytics, uygulamanızdaki tüm etkinlikleri (kilitlenmeler, önemli olmayanlar ve
ve ANR'ler) çalışır ve sorunlar adı verilen etkinlik grupları oluşturur. Tüm etkinlikler
ortak bir hata noktası bulunuyor.
İyileştirilmiş analiz motoru, etkinlikleri bu sorunlara göre gruplandırmak için artık yığın izlemedeki çerçeveler, istisna mesajı, hata kodu ve diğer platform veya hata türü özellikleri de dahil olmak üzere etkinliğin birçok yönünü inceliyor.
Ancak bu etkinlik grubu içinde, başarısızlığa yol açan yığın izlemeler
farklı olabilir. Farklı bir yığın izleme, farklı bir kök nedene işaret edebilir.
Bir sorun içindeki bu olası farkı temsil etmek için,
Sorunlar içindeki varyantlar: Her varyant, bir sorundaki etkinliklerin bir alt grubudur
aynı hata noktasına sahip ve benzer bir yığın izlemeye sahip olan yayıncılar. Varyantlarla,
bir sorundaki en yaygın yığın izlemelerde (stack trace) hata ayıklayabilir
farklı kök nedenler hataya yol açabilir.
Bu iyileştirmeler sayesinde şunları deneyimleyebilirsiniz:
Sorun satırında gösterilen yenilenmiş meta veriler Uygulamanızdaki sorunları anlamak ve önceliklerini belirlemek artık daha kolay.
Daha az yinelenen sorun Satır numarası değişikliği yeni bir sorunla sonuçlanmaz.
Çeşitli temel nedenlerle ilgili karmaşık sorunlarda daha kolay hata ayıklama Bir sorundaki en yaygın yığın izlemelerde (stack trace) hata ayıklamak için varyantları kullanın.
Daha anlamlı uyarılar ve sinyaller Yeni sorun aslında yeni bir hatayı temsil ediyor.
Daha güçlü arama Her sorun, istisna türü ve paket adı gibi daha fazla aranabilir meta veri içerir.
Bu iyileştirmeler şu şekilde kullanıma sunulacaktır:
Uygulamanızdan yeni etkinlikler aldığımızda, bunların mevcut bir uygulamayla eşleşip eşleşmediğini kontrol ederiz
.
Eşleşme yoksa daha akıllı etkinlik gruplandırma algoritmamızı etkinliğe otomatik olarak uygular ve yenilenen meta veri tasarımıyla yeni bir sorun oluştururuz.
Bu, etkinlik grubumuzda yaptığımız ilk büyük güncellemedir. Geri bildiriminiz veya karşılaştığınız bir sorun varsa lütfen bir bildirim göndererek bize bildirin.
Kilitlenme sorunu ile karşılaşmayan kullanıcı sayısı metriklerini ve/veya hız uyarılarını görememe
Kilitlenme sorunu yaşamayan kullanıcılar ve oturum sayısı gibi metrikleri görmüyorsanız
ve/veya hız uyarılarını kullandığınızdan emin olun:
Crashlytics SDK 18.6.0+ (veya Firebase BoM sürüm 32.6.0+).
İçerik haritası günlüklerini görememe
Breadcrumb 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:
Özellikle aşağıdaki dosyanın en az sürümünü kullandığınızdan emin olun:
Google Analytics için Firebase SDK'sı: Android — v17.2.3+(BoM v24.7.1+).
Neden sadece ANR'ler
Android 11 ve sonraki sürümler için bildirildi mi?
Crashlytics, Android 11 ve sonraki sürümleri çalıştıran cihazlardaki Android uygulamaları için ANR raporlamayı destekler. ANR'leri toplamak için kullandığımız temel API (getHistoricalProcessExitReasons), SIGQUIT veya gözetleyici tabanlı yaklaşımlardan daha güvenilirdir. Bu API
yalnızca Android 11 ve sonraki sürüme sahip cihazlarda kullanılabilir.
Why are some ANRs missing
their BuildIds?
ANR'lerinizin bazılarında BuildId eksikse aşağıdaki şekilde sorun giderin:
Güncel bir Crashlytics Android SDK'sı kullandığınızdan emin olun ve
Crashlytics Gradle eklentisi sürümü.
Android 11 ve bazı Android 12 ANR'leri için BuildId'ler eksikse muhtemelen güncel olmayan bir SDK, Gradle eklentisi veya her ikisini birden kullanıyorsunuzdur.
Bu ANR'ler için BuildId öğelerini doğru şekilde toplamak üzere aşağıdakini kullanmanız gerekir
sürümler:
Crashlytics Gradle eklentisi 2.9.4 sürümü ve üzeri
Paylaşılan kitaplıklarınız için standart olmayan bir konum kullanıp kullanmadığınızı kontrol edin.
Yalnızca uygulamanızın paylaşılan kitaplıkları için BuildId eksikse paylaşılan kitaplıklar için standart, varsayılan konumu kullanmıyor olabilirsiniz. Eğer
bu durumda Crashlytics, kullanıcının
ilişkilendirilmiş BuildId Bu nedenle, standart
ortak kitaplıklar için konum.
Derleme işlemi sırasında BuildId'leri 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 dosyalarının olup olmadığını kontrol edin. BuildId yoksa derleme sisteminizin işaretlerine -Wl,--build-id ekleyin.
APK boyutunuzu küçültmek için BuildId öğelerini yanlışlıkla kaldırmadığınızdan emin olun.
Bir kitaplığın sadeleştirilmiş ve sadeleştirilmiş sürümlerini saklıyorsanız
kodunuzda doğru sürüme işaret edin.
Crashlytics kontrol panelindeki ANR raporları ile Google Play Console arasındaki farklılıklar
Google Play ile Crashlytics arasındaki ANR sayıları arasında uyuşmazlık olabilir. Analiz mekanizmalarındaki farklılık nedeniyle bu beklenen bir durumdur.
ANR verilerini toplayıp raporlamamıza yardımcı oluyor. Crashlytics, uygulama aşağıdaki işlemleri yaptığında ANR'leri bildirir:
Android vitals, ANR verilerini ANR gerçekleştikten sonra gönderir.
Ayrıca Crashlytics yalnızca şu anda çalışan cihazlarda meydana gelen ANR'leri gösterir.
Şu özelliklere sahip cihazlarda ANR'lerin gösterildiği Google Play ile karşılaştırıldığında: Android 11 ve sonraki sürümler
Google Play Hizmetleri ve veri toplama izni kabul edildi.
Crashlytics kontrol panelindeki ve logcat'teki NDK yığın izlemeleri arasındaki farklar
LLVM ve GNU araç zincirleri, salt okunur özellik için farklı varsayılan ayarlara ve işlemlere sahiptir
tutarsız yığın izlemelere (stack trace) neden olabilecek şekilde
Firebase konsolunda kontrol edebilirsiniz. Bu sorunu azaltmak için aşağıdaki bağlayıcı flag'lerini ekleyin
uygulayın:
LLVM araç setindeki lld bağlayıcıyı kullanıyorsanız şunları ekleyin:
-Wl,--no-rosegment
GNU araç zincirindeki ld.gold bağlayıcıyı kullanıyorsanız şunları ekleyin:
-Wl,--rosegment
Yine yığın izleme tutarsızlıkları görüyorsanız (veya bu işaretlerden hiçbiri araç zincirinizle alakalı değilse) bunun yerine derleme sürecinize aşağıdakileri eklemeyi deneyin:
-fno-omit-frame-pointer
NDK için kendi Breakpad simge dosyası oluşturucu ikili dosyamı nasıl kullanırım?
Crashlytics eklentisi, özelleştirilmiş bir Breakpad sembol dosyası oluşturucu içerir.
Breakpad simge 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ı
source) belirtmek için isteğe bağlı symbolGeneratorBinary uzantı özelliğini kullanın
yürütülebilir dosyanın yoludur.
Breakpad simge dosyası oluşturucu ikili dosyasının yolunu iki şekilde belirtebilirsiniz:
1. Seçenek: build.gradle dosyanızdaki firebaseCrashlytics uzantısı aracılığıyla yolu belirtin
Uygulama düzeyindeki build.gradle.kts dosyanıza aşağıdakileri ekleyin:
Gradle eklentisi 3.0.0+ sürümü
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")
}
}
}
}
daha 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'ınızdaki bir özellik satırı aracılığıyla belirtme
özellikler dosyası
Yürütülebilir dosyanın yolunu belirtmek için com.google.firebase.crashlytics.breakpadBinary özelliğini kullanabilirsiniz.
Gradle özellik 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:
Neden kilitlenmeler görüyorum?
.java sorun olarak etiketlenmiş .kt dosyadan mı alındı?
Bir uygulama, dosya uzantısını açığa çıkarmayan bir kod karartıcı kullandığında
Crashlytics, varsayılan olarak her sorunu .java dosya uzantısıyla oluşturur.
Crashlytics'ün doğru dosya uzantısıyla sorun oluşturabilmesi için uygulamanızda aşağıdaki kurulumun kullanıldığından emin olun:
Android Gradle 4.2.0 veya sonraki bir sürümü kullanır
Kod karartma açık şekilde R8 kullanır. Uygulamanızı R8'e güncellemek için bu dokümanları inceleyin.
Yukarıda açıklanan ayarları güncelledikten sonra
mevcut .java sorunun kopyası olan yeni .kt sorunları. Bu durum hakkında daha fazla bilgi edinmek için SSS bölümünü inceleyin.
Mevcut .java sorunlarının kopyası olan .kt sorunlarını neden görüyorum?
Aralık 2021'in ortasından itibaren Crashlytics, başvurulara yönelik desteği iyileştirdi
içerik üretir.
Yakın zamana kadar mevcut karartıcı araçlar dosya uzantısını göstermediğinden 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 her bir sınıfın
Uygulama Kotlin dilinde yazılmış olmalı ve sorunda doğru dosya adını içermelidir.
imzası var. Uygulamanızda aşağıdaki kurulum varsa kilitlenmeler artık .kt dosyalarıyla (uygun olduğu şekilde) doğru şekilde ilişkilendiriliyor:
Uygulamanız Android Gradle 4.2.0 veya sonraki bir sürümü kullanıyor.
Uygulamanızda karartma özelliği etkinken R8 kullanılıyor.
Yeni kilitlenmeler artık sorun imzalarında doğru dosya uzantısını içerdiğinden, aslında mevcut .java etiketli sorunların kopyası olan yeni .kt sorunları görebilirsiniz. Firebase konsolunda, yeni bir .kt sorununun mevcut bir .java etiketli sorunun kopyası olup olmadığını tespit edip size bildirmeye çalışıyoruz.
Bir sorunla ilgili notları kimler görüntüleyebilir, yazabilir ve silebilir?
Notlar, proje üyelerinin sorular ve durumlarla ilgili belirli sorunlar hakkında yorum yapmasına olanak tanır.
güncellemeler vb.
Bir proje üyesi not yayınladığında bu not, ilgili kullanıcının Google gönderdiği e-posta ile etiketlenir.
hesap. Bu e-posta adresi, notla birlikte tüm projeler tarafından görülebilir
notu görüntüleme erişimine sahip üyeler tarafından görüntülenebilir.
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üleyip silebilir ve bir sorunla ilgili yeni notlar yazabilir.
Aşağıdaki rollerden herhangi birine sahip proje üyeleri, bir sorunla ilgili olarak yayınlanan notları görüntüleyebilir ancak notları silebilir veya not yazamaz.
Bir sorunla ilgili notları kimler görüntüleyebilir, yazabilir ve silebilir?
Notlar, proje üyelerinin sorular ve durumlarla ilgili belirli sorunlar hakkında yorum yapmasına olanak tanır.
güncellemeler vb.
Bir proje üyesi not yayınladığında bu not, ilgili kullanıcının Google gönderdiği e-posta ile etiketlenir.
hesap. Bu e-posta adresi, notla birlikte tüm projeler tarafından görülebilir
notu görüntüleme erişimine sahip üyeler tarafından görüntülenebilir.
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üleyip silebilir ve bir sorunla ilgili yeni notlar yazabilir.
Uygulama ayrıca
Google Mobile Ads SDK, ancak kilitlenme almıyor
Projenizde Google Mobile Ads SDK'sı ile birlikte Crashlytics kullanılıyorsa
kilitlenmeyi bildirenler de muhtemelen bu işlem sırasında
istisna işleyicileri kaydetmem gerekiyor. Sorunu düzeltmek için kilitlenme raporlamasını devre dışı bırakın:
disableSDKCrashReporting çağırarak Mobile Ads SDK'sını kullanın.
BigQuery veri kümem nerede bulunuyor?
Crashlytics'yi BigQuery'ye bağladıktan sonra, oluşturduğunuz yeni veri kümeleri Firebase projenizin konumundan bağımsız olarak otomatik olarak ABD'de konumlandırılır.
Platform desteği
Crashlytics, armeabi'yi destekliyor mu?
Firebase Crashlytics NDK, ARMv5'i (armeabi) desteklemez.
Bu ABI desteği, NDK r17'den itibaren kaldırılmıştır.
Geri çekilen sorunlar
Geri çekilen nedir
sorun?
Sorunu daha önce kapattığınız ancak bir
Crashlytics, sorunun yeniden oluştuğunu belirten yeni bir rapor alır.
Crashlytics, geri çekilen bu sorunları otomatik olarak yeniden açar. Böylece şunları yapabilirsiniz:
bunları uygulamanıza uygun şekilde ele alın.
Crashlytics'ün bir sorunu nasıl gerileme olarak sınıflandırdığını açıklayan örnek bir senaryo aşağıda verilmiştir:
Crashlytics, ilk kez Kilitlenme ile ilgili kilitlenme raporu alıyor.
"A". Crashlytics, söz konusu kilitlenmeyle ilgili sorunu açar ("A" sorunu).
Bu hatayı hızlı bir şekilde düzeltir, "A" sorununu kapatır ve ardından 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, Crashlytics adlı kullanıcının bildiği bir uygulama sürümünden geliyorsa
sorunu kapattığınızda (sürümün kilitlenme gönderdiğini gösterir)
herhangi bir kilitlenme için raporlayamazsa Crashlytics,
bu sorunu regresyon olarak gösterir. Sorun kapatılır.
Rapor, sorunu kapattığınızda Crashlytics'in bilmediği bir uygulama sürümünden geliyorsa (yani sürüm, hiçbir kilitlenme için hiçbir kilitlenme raporu göndermediyse) Crashlytics, sorunun geri geldiğini düşünür ve sorunu yeniden açar.
Bir sorun gerilediğinde, bir regresyon algılama uyarısı gönderir ve bir
Crashlytics için en az bir regresyon sinyali olup
, sorunu yeniden açtı. Bir sorunun, gerileme algoritmamız nedeniyle yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "sessize alın".
Eski uygulama sürümlerinde neden 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 geri geldiğini düşünür ve sorunu yeniden açar.
Bu durum şu durumda ortaya çıkabilir: Bir hatayı giderdiniz ve
uygulamanızın yeni bir sürümünü yayınladı, ancak kullanıcılarınız hâlâ eski sürümlerini kullanıyor
en iyi uygulamaları paylaşacağız. 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şlarsa bu kilitlenme raporları, geriye giden bir sorunu tetikler.
Regresyon algoritmamız nedeniyle bir sorunun yeniden açılmasını istemiyorsanız "sesi kapat"
anlamaya çalışın.