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ğ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örmüyorsanız, Google Analytics için uygulamanızın 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'yı 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 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 özellik de fark edebilirsiniz. İşte nedeni!
2023'ün başlarında, olayları gruplamak için geliştirilmiş bir analiz motorunun yanı sıra güncellenmiş bir tasarım ve yeni sorunlar için bazı gelişmiş özellikler (varyantlar gibi!) kullanıma sunduk. Tüm ayrıntılar için son blog gönderimize göz atın, ancak öne çıkanlar için aşağıda okuyabilirsiniz.
Crashlytics, uygulamanızdaki tüm olayları (çökmeler, ölümcül olmayan olaylar ve ANR'ler gibi) analiz eder ve sorunlar adı verilen olay grupları oluşturur; bir sorundaki tüm olayların ortak bir başarısızlık noktası vardır.
Olayları bu sorunlara göre gruplandırmak için, iyileştirilmiş 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 izi, farklı bir kök neden anlamına gelebilir. Bir sorun içindeki bu olası farkı temsil etmek için artık sorunlar içinde değişkenler oluşturuyoruz - her değişken, bir sorundaki aynı başarısızlık noktasına ve benzer yığın izlemesine sahip olayların bir alt grubudur. Varyantlarla, bir sorun içindeki en yaygın yığın izlerinde hata ayıklayabilir ve hataya farklı kök nedenlerin yol açıp açmadığını belirleyebilirsiniz.
İşte bu iyileştirmelerle deneyimleyeceğiniz şeyler:
Sorun satırında görüntülenen yenilenmiş meta veriler
Uygulamanızdaki sorunları anlamak ve önceliklendirmek artık 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ıklaması
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 sayı, istisna türü ve paket adı gibi daha fazla aranabilir meta veri içerir.
Bu iyileştirmelerin nasıl kullanıma 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 yoksa, daha akıllı olay gruplama algoritmamızı olaya otomatik olarak uygulayacağız ve yenilenen meta veri tasarımıyla yeni bir sorun oluşturacağız.
Bu, etkinlik gruplandırmamızda yaptığımız ilk büyük güncelleme. Geri bildiriminiz varsa veya herhangi bir sorunla karşılaşırsanız, lütfen bir şikayette bulunarak bize bildirin.
Kilitlenme sorunu olmayan değer, uygulamanızla etkileşimde bulunan ancak belirli bir süre boyunca kilitlenme yaşamamış kullanıcıların yüzdesini temsil eder.
İşte kilitlenme olmayan kullanıcı yüzdesini hesaplamak için formül. Girdi 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_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 panosunun sağ üst kısmındaki açılır menüden seçtiğiniz süre boyunca uygulamanızla etkileşim kuran toplam kullanıcı sayısını temsil eder.
Kilitlenme sorunu yaşamayan kullanıcı yüzdesi, ortalama değil, zaman içindeki bir toplamadır .
Örneğin, uygulamanızın üç kullanıcısı olduğunu hayal edin; onlara 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 bu kullanıcılardan hangilerinin o gün 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 |
| Kilitlenme yaşayan kullanıcı | C | B | A |
Çarşamba günü, kilitlenme olmayan kullanıcı yüzdeniz %50'dir (2 kullanıcıdan 1'i kilitlenme yaşamamıştır).
Kullanıcılarınızdan ikisi Çarşamba günü uygulamanızla etkileşimde bulundu, ancak yalnızca birinde (B Kullanıcısı) kilitlenme olmadı.Son 2 gün içinde kilitlenme sorunu olmayan kullanıcı yüzdeniz %33,3'tür (3 kullanıcıdan 1'i kilitlenme sorunu yaşamamıştır).
Son iki gün içinde kullanıcılarınızdan üçü uygulamanızla etkileşimde bulundu, ancak bunlardan yalnızca biri (C Kullanıcısı) kilitlenme yaşamadı.Son 3 gün içinde kilitlenme olmayan kullanıcı yüzdeniz %0'dır (3 kullanıcıdan 0'ı kilitlenme yaşamamıştır).
Kullanıcılarınızdan üçü son üç gün içinde uygulamanızla etkileşimde bulundu, ancak hiçbirinde kilitlenme olmadı.
Notlar, proje üyelerinin sorular, durum güncellemeleri vb. ile belirli sorunlar hakkında yorum yapmasına olanak tanır.
Bir proje üyesi bir not yayınladığında, 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üleyip silebilir ve bir sorun hakkında yeni notlar yazabilir.
Aşağıdaki rollerden herhangi birine sahip olan proje üyeleri, bir sorunla ilgili yayınlanan notları görüntüleyebilir, ancak silemez veya not yazamazlar.
Entegrasyonlar
Projeniz Google Mobile Ads SDK'sının yanı sıra Crashlytics kullanıyorsa, büyük olasılıkla kilitlenme raporlayıcıları, istisna işleyicileri kaydederken müdahale ediyordur. Sorunu düzeltmek için, disableSDKCrashReporting çağırarak Mobile Ads SDK'sında kilitlenme raporlamasını kapatın.
Crashlytics'i BigQuery'ye bağladıktan sonra, Firebase projenizin konumundan bağımsız olarak, oluşturduğunuz yeni veri kümeleri otomatik olarak Amerika Birleşik Devletleri'nde bulunur.
platform desteği
Gerileyen sorunlar
Daha önce sorunu kapattığınız bir sorunda gerileme oldu, ancak Crashlytics, sorunun yeniden oluştuğuna dair yeni bir rapor alıyor. Crashlytics, uygulamanız için uygun şekilde ele alabilmeniz için geri çekilen bu sorunları otomatik olarak yeniden açar.
Crashlytics'in bir sorunu nasıl gerileme olarak kategorize ettiğini açıklayan bir örnek senaryoyu burada bulabilirsiniz:
- Crashlytics ilk kez Crash "A" hakkında bir kilitlenme raporu alıyor. Crashlytics, söz konusu kilitlenme için ilgili bir sorun açar ("A" Sorunu).
- Bu hatayı hızlı bir şekilde düzeltin, "A" Sorununu kapatın ve ardından uygulamanızın yeni bir sürümünü yayınlayın.
- Crashlytics, siz sorunu kapattıktan sonra "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 (yani, sürüm herhangi bir kilitlenme için bir kilitlenme raporu göndermişse), 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 (bu, sürümün herhangi bir kilitlenme için hiçbir kilitlenme raporu göndermediği anlamına gelir), Crashlytics sorunun gerilediğini kabul eder ve sorunu yeniden açar .
Bir sorun gerilediğinde, bir gerileme tespit uyarısı göndeririz ve Crashlytics'in sorunu yeniden açtığını size bildirmek için soruna bir gerileme sinyali ekleriz. Regresyon algoritmamız nedeniyle bir sorunun yeniden açılmasını istemiyorsanız, sorunu kapatmak yerine "susturun".
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 şu durumda olabilir: 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, siz sorunu kapattığınızda bu eski sürümlerden biri hiç kilitlenme raporu göndermemişse ve bu kullanıcılar hatayla karşılaşmaya başlarsa, bu kilitlenme raporları geri çekilmiş bir sorunu tetikler.
Regresyon algoritmamız nedeniyle bir sorunun yeniden açılmasını istemiyorsanız, sorunu kapatmak yerine "susturun".