Bu sayfa, sorun giderme yardımı ve Crashlytics'i kullanma hakkında sık sorulan soruların yanıtlarını sağlar. Aradığınızı bulamıyorsanız veya ek yardıma ihtiyacınız varsa, Firebase desteği ile iletişime geçin.
Genel sorun giderme/SSS
Kilitlenmeyen kullanıcılar, içerik haritası günlükleri ve/veya hız uyarıları görmüyorsanız, uygulamanızın Google Analytics yapılandırmasını kontrol etmenizi öneririz.
Firebase projenizde Google Analytics'i etkinleştirdiğinizden emin olun.
Firebase konsolunun Entegrasyonlar > Google Analytics sayfasında Google Analytics için Veri paylaşımının etkinleştirildiğinden emin olun. Veri paylaşımı ayarlarının Firebase konsolunda görüntülendiğini, ancak Google Analytics konsolunda yönetildiğini unutmayın.
Firebase Crashlytics SDK'ya ek olarak, Google Analytics için Firebase SDK'sını uygulamanıza eklediğinizden emin olun ( iOS+ | Android ).
Tüm Firebase SDK'larınız ( iOS+ | Android ) için en son sürümleri kullandığınızdan emin olun.
Özellikle, Google Analytics için Firebase SDK'nın en azından şu sürümlerini kullandığınızdan emin olun: iOS+ — v6.3.1+ (macOS ve tvOS için v8.9.0+) | Android — v17.2.3+(BoM v24.7.1+) .
Kilitlenme olmaması değeri, uygulamanızla etkileşime giren ancak belirli bir zaman diliminde çökme yaşamayan kullanıcıların yüzdesini temsil eder.
İşte çökmesiz kullanıcı yüzdesini hesaplama formülü. Girdi değerleri Google Analytics tarafından sağlanmaktadır.
1 - ( CRASHED_USERS / ALL_USERS )
Bir kilitlenme meydana geldiğinde, Google Analytics bir
app_exceptionolay türü gönderir ve CRASHED_USERS , bu olay türüyle ilişkili kullanıcı sayısını temsil eder.ALL_USERS , Crashlytics kontrol panelinin sağ üst köşesindeki açılır menüden seçtiğiniz zaman aralığında uygulamanızla etkileşim kuran toplam kullanıcı sayısını temsil eder.
Uygulamanız için app_exception olaylarının sayısını Analytics kontrol panelinde görüntüleyebilirsiniz. Kilitlenmelerin işlenme biçimindeki küçük farklılıklar nedeniyle, Analytics panosunda görüntülenen app_exception numarasının bazen kilitlenmeyen kullanıcı hesaplamasında kullanılan sayıdan farklı olabileceğini unutmayın.
Kilitlenme olmayan kullanıcı yüzdesi, bir ortalama değil, zaman içindeki bir toplamdır.
Örneğin, uygulamanızın üç kullanıcısı olduğunu hayal edin; bunlara Kullanıcı A, Kullanıcı B ve Kullanıcı C diyeceğiz. Aşağıdaki tablo, uygulamanızla her gün etkileşim kuran ve bu kullanıcılardan hangilerinin o gün bir kilitlenme yaşadığını gösterir:
| Pazartesi | Salı | Çarşamba | |
|---|---|---|---|
| Uygulamanızla etkileşim kuran kullanıcılar | A, B, C | A, B, C | A, B |
| Kaza geçiren kullanıcı | C | B | A |
Çarşamba günü, kilitlenmeyen kullanıcı yüzdeniz %50'dir (2 kullanıcıdan 1'i çökme yaşamadı).
Kullanıcılarınızdan ikisi Çarşamba günü uygulamanızla etkileşim kurdu, ancak yalnızca birinde (Kullanıcı B) hiç kilitlenme olmadı.Son 2 gün için, çökme yaşanmayan kullanıcı yüzdeniz %33,3'tür (3 kullanıcıdan 1'i çökme yaşamadı).
Kullanıcılarınızdan üçü son iki gün içinde uygulamanızla etkileşim kurdu, ancak yalnızca birinde (Kullanıcı C) kilitlenme olmadı.Son 3 gün için, çökme yaşanmayan kullanıcı yüzdeniz %0'dır (3 kullanıcıdan 0'ı çökme yaşamadı).
Kullanıcılarınızdan üçü son üç gün içinde uygulamanızla etkileşim kurdu, ancak hiçbirinde kilitlenme olmadı.
Entegrasyonlar
Projeniz Google Mobile Ads SDK'sı ile birlikte Crashlytics kullanıyorsa, büyük olasılıkla kilitlenme raporlayıcıları istisna işleyicileri kaydederken araya giriyor. Sorunu çözmek için, disableSDKCrashReporting arayarak Mobile Ads SDK'sındaki kilitlenme raporlamasını kapatın.
Crashlytics'i BigQuery'ye bağladıktan sonra, oluşturduğunuz yeni veri kümeleri, Firebase projenizin konumundan bağımsız olarak ABD'de otomatik olarak konumlandırılır.
Platform desteği
tutucu41 l10n-yerGerileyen sorunlar
Sorunu daha önce kapattığınızda bir sorun geriliyor ancak Crashlytics, sorunun yeniden oluştuğuna dair yeni bir rapor alıyor. Crashlytics, bu gerileyen sorunları otomatik olarak yeniden açar, böylece bunları uygulamanıza uygun şekilde çözebilirsiniz.
Crashlytics'in bir sorunu regresyon olarak nasıl kategorize ettiğini açıklayan örnek bir senaryo:
- Crashlytics ilk kez Crash "A" hakkında bir kilitlenme raporu alıyor. Crashlytics, bu kilitlenme için ilgili bir sorun açar ("A" Sorunu).
- Bu hatayı hızla düzeltirsiniz, "A" Sayısını kapatırsınız ve ardından uygulamanızın yeni bir sürümünü yayınlarsınız.
- Sorunu kapattıktan sonra Crashlytics, "A" Sorunu hakkında başka bir rapor alır.
- Rapor, sorunu kapattığınızda Crashlytics'in bildiği bir uygulama sürümünden geliyorsa (sürümün herhangi bir kilitlenme için kilitlenme raporu gönderdiği anlamına gelir), Crashlytics sorunu gerilemiş olarak kabul etmez. Konu kapalı kalacaktır.
- Rapor, sorunu kapattığınızda Crashlytics'in bilmediği bir uygulama sürümünden geliyorsa (yani sürümün herhangi bir kilitlenme için herhangi bir kilitlenme raporu göndermediği anlamına gelir), Crashlytics sorunun gerilediğini kabul eder ve sorunu yeniden açar. .
Bir sorun gerilediğinde, Crashlytics'in sorunu yeniden açtığını size bildirmek için bir gerileme algılama uyarısı gönderir ve soruna bir gerileme sinyali ekleriz. Regresyon algoritmamız nedeniyle bir sorunun yeniden açılmasını istemiyorsanız, kapatmak yerine sorunu "sessiz hale getirin".
Bir rapor, sorunu kapattığınızda hiç kilitlenme raporu göndermemiş eski bir uygulama sürümünden geliyorsa, Crashlytics sorunun gerilediğini kabul eder ve sorunu yeniden açar.
Bu durum aşağıdaki durumda gerçekleşebilir: Bir hatayı düzelttiniz ve uygulamanızın yeni bir sürümünü yayınladınız, ancak hala eski sürümlerde hata düzeltmesi olmayan 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şlarsa, bu kilitlenme raporları gerileyen bir sorunu tetikler.
Regresyon algoritmamız nedeniyle bir sorunun yeniden açılmasını istemiyorsanız, kapatmak yerine sorunu "sessiz hale getirin".