Bu sayfada sorun giderme yardımı ve Crashlytics'in kullanımıyla ilgili sık sorulan soruların yanıtları sağlanmaktadır. Aradığınızı bulamıyorsanız veya ek yardıma ihtiyacınız varsa Firebase desteğiyle iletişime geçin.
Genel sorun giderme/SSS
Kilitlenme sorunu yaşamayan kullanıcıları, içerik haritası günlüklerini ve/veya hız uyarılarını göremiyorsanı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.
Uygulamanıza ( iOS+ | Android ) Firebase Crashlytics SDK'sına ek olarak Google Analytics için Firebase SDK'sını da eklediğinizden emin olun.
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 aşağıdaki 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+) .
Firebase konsolundaki Sorunlar tablonuzda listelenen sorunlar için iki farklı biçim fark edebilirsiniz. Ayrıca bazı sorunlarınızda "varyantlar" adı verilen bir özelliği de fark edebilirsiniz. İşte nedeni!
2023'ün başlarında, etkinlikleri gruplamak için iyileştirilmiş bir analiz motorunun yanı sıra güncellenmiş bir tasarım ve yeni sorunlar için bazı gelişmiş özellikleri (varyantlar gibi!) kullanıma sunduk. Tüm ayrıntılar için son blog gönderimize göz atın, ancak öne çıkanları aşağıda okuyabilirsiniz.
Crashlytics, uygulamanızdaki tüm etkinlikleri (çökmeler, ölümcül olmayanlar ve ANR'ler gibi) analiz eder ve sorun adı verilen etkinlik grupları oluşturur; bir sorundaki tüm olayların ortak bir başarısızlık noktası vardır.
Olayları bu sorunlar halinde gruplandırmak için, gelişmiş analiz motoru artık yığın izlemedeki çerçeveler, istisna mesajı, hata kodu ve diğer platform veya hata türü özellikleri dahil olmak üzere olayın birçok yönüne bakıyor.
Ancak bu olay grubu içinde hataya yol açan yığın izleri farklı olabilir. Farklı bir yığın izleme, farklı bir temel neden anlamına gelebilir. Bir sorun içindeki bu olası farklılığı temsil etmek için artık sorunlar içinde değişkenler oluşturuyoruz; her değişken, aynı hata noktasına ve benzer yığın izine sahip bir sorundaki olayların bir alt grubudur. Varyantlarla, bir sorun içindeki en yaygın yığın izlerinde hata ayıklayabilir ve hataya farklı temel nedenlerin yol açıp açmadığını belirleyebilirsiniz.
Bu iyileştirmelerle karşılaşacağınız deneyimler şunlardır:
Sorun satırında görüntülenen yenilenen meta veriler
Artık uygulamanızdaki sorunları anlamak ve önceliklendirmek daha kolay.Daha az yinelenen sorun
Satır numarası değişikliği yeni bir sayıya yol açmaz.Çeşitli kök nedenlere sahip karmaşık sorunların daha kolay hata ayıklanması
Bir sorundaki en yaygın yığın izlerinde hata ayıklamak için değişkenleri kullanın.Daha anlamlı uyarılar ve sinyaller
Yeni bir sorun aslında yeni bir hatayı temsil eder.Daha güçlü arama
Her sayı, istisna türü ve paket adı gibi daha fazla aranabilir meta veri içerir.
Bu iyileştirmelerin nasıl sunulduğu aşağıda açıklanmıştır:
Uygulamanızdan yeni etkinlikler aldığımızda bunların mevcut bir sorunla eşleşip eşleşmediğini kontrol edeceğiz.
Eşleşme olmazsa, daha akıllı olay gruplandırma algoritmamızı etkinliğe otomatik olarak uygulayacağız ve yenilenen meta veri tasarımıyla yeni bir sorun yaratacağız.
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 bir rapor göndererek bize bildirin.
Kilitlenmeme değeri, uygulamanızla etkileşime giren ancak belirli bir süre boyunca kilitlenme yaşamayan kullanıcıların yüzdesini temsil eder.
İşte kilitlenme yaşanmayan kullanıcı yüzdesini hesaplamak için kullanılan formül. Giriş değerleri Google Analytics tarafından sağlanır.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
Bir kilitlenme meydana geldiğinde, Google Analytics bir
app_exceptionetkinlik türü gönderir ve CRASHED_USERS , bu etkinlik 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 dönem boyunca uygulamanızla etkileşime geçen toplam kullanıcı sayısını temsil eder.
Kilitlenme yaşamayan kullanıcı yüzdesi, ortalama değil, zaman içinde elde edilen bir toplamdır .
Örneğin, uygulamanızın üç kullanıcısı olduğunu düşünün; bunlara A Kullanıcısı, B Kullanıcısı ve C Kullanıcısı adını vereceğiz. Aşağıdaki tablo, her gün hangi kullanıcıların uygulamanızla etkileşim kurduğunu ve o gün bu kullanıcılardan hangisinin 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ü kilitlenme yaşamayan kullanıcı yüzdeniz %50'dir (2 kullanıcıdan 1'i kilitlenme yaşamadı).
Kullanıcılarınızdan ikisi Çarşamba günü uygulamanızla etkileşime geçti ancak yalnızca birinde (Kullanıcı B) herhangi bir kilitlenme yaşanmadı.Son 2 gün içinde kilitlenme yaşamayan kullanıcı yüzdeniz %33,3 (3 kullanıcıdan 1'i kilitlenme yaşamadı).
Kullanıcılarınızdan üçü son iki gün içinde uygulamanızla etkileşimde bulundu, ancak yalnızca birinde (Kullanıcı C) herhangi bir kilitlenme yaşanmadı.Son 3 gün içinde kilitlenme yaşamayan kullanıcı yüzdeniz %0 (3 kullanıcıdan 0'ı kilitlenme yaşamadı).
Kullanıcılarınızdan üçü son üç gün içinde uygulamanızla etkileşimde bulundu ancak sıfırında herhangi bir kilitlenme yaşanmadı.
Kilitlenme yaşanmayan kullanıcıların değeri farklı zaman dilimlerinde karşılaştırılmamalıdır. Tek bir kullanıcının kilitlenme yaşama olasılığı, uygulamanızı ne kadar çok kullanırsa o kadar artar; dolayısıyla kilitlenme yaşamayan kullanıcıların değeri muhtemelen daha uzun süreler boyunca daha küçük olacaktır.
Notlar, proje üyelerinin sorular, durum güncellemeleri vb. ile belirli konular hakkında yorum yapmasına olanak tanır.
Bir proje üyesi bir not yayınladığında, bu not kendi Google hesabının e-posta adresiyle etiketlenir. Bu e-posta adresi, notla birlikte, notu görüntüleme erişimi olan tüm proje üyeleri tarafından görülebilir.
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 sorunla ilgili yeni notlar yazabilir.
Aşağıdaki rollerden herhangi birine sahip olan proje üyeleri, bir konuya gönderilen notları görüntüleyebilir ancak notu silemez veya yazamaz.
Entegrasyonlar
Projeniz Google Mobile Ads SDK'sının yanı sıra Crashlytics kullanıyorsa kilitlenme raporlayıcılarının istisna işleyicileri kaydederken müdahale etmesi muhtemeldir. Sorunu düzeltmek için, Mobile Ads SDK'sındaki kilitlenme raporlamasını disableSDKCrashReporting çağırarak kapatın.
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 bulunur.
Platform desteği
Gerileyen sorunlar
Daha önce konuyu kapattığınızda bir sorun geriledi 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 giderebilirsiniz.
Crashlytics'in bir sorunu regresyon olarak nasıl kategorize ettiğini açıklayan örnek bir senaryoyu burada bulabilirsiniz:
- Crashlytics ilk kez Crash "A" hakkında bir kilitlenme raporu alıyor. Crashlytics söz konusu kilitlenmeyle ilgili bir sorun 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.
- 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üne aitse (yani sürüm herhangi bir kilitlenme için bir kilitlenme raporu göndermişse), Crashlytics sorunu geriletilmiş olarak değerlendirmez. Konu kapalı kalacaktır.
- Rapor, sorunu kapattığınızda Crashlytics'in bilmediği bir uygulama sürümüne aitse (bu, sürümün herhangi bir kilitlenme için hiçbir zaman kilitlenme raporu göndermediği anlamına gelir), Crashlytics sorunun gerilediğini varsayar 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öndeririz ve soruna bir gerileme sinyali ekleriz. Regresyon algoritmamız nedeniyle bir konunun yeniden açılmasını istemiyorsanız, konuyu kapatmak yerine "sessizleştirin".
Bir rapor, sorunu kapattığınızda hiç kilitlenme raporu göndermemiş eski bir uygulama sürümünden geliyorsa Crashlytics sorunun gerilediğini varsayar ve 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 hâlâ eski sürümlerde hata düzeltmesi olmayan kullanıcılarınız var. Şans eseri, sorunu kapattığınızda bu eski sürümlerden biri hiç kilitlenme raporu göndermediyse ve bu kullanıcılar hatayla karşılaşmaya başlarsa, bu kilitlenme raporları gerileyen bir sorunu tetikleyecektir.
Regresyon algoritmamız nedeniyle bir konunun yeniden açılmasını istemiyorsanız, konuyu kapatmak yerine "sessizleştirin".