Crashlytics ile ilgili sorun giderme ve SSS

Bu sayfada, Crashlytics kullanımıyla ilgili sık sorulan soruların yanıtları ve sorun giderme yardımı yer almaktadı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 yeni sorunlar (ör. varyantlar) için güncellenmiş bir tasarım ve 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 ya da 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 izlerinde hata 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, istisna 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 otomatik olarak daha akıllı etkinlik gruplandırma algoritmamızı 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 rapor göndererek bize bildirin.

İçerik haritası günlüklerini görmüyorsanız

Uygulamanızda izleme kaydı günlükleri görmüyorsanız (iOS+ | Android | Flutter | Unity), Google Analytics için uygulamanızın yapılandırmasını kontrol etmenizi öneririz. Aşağıdaki koşulları karşıladığınızdan emin olun:

• Firebase projenizde Google Analytics'ı etkinleştirmiş olmanız gerekir.

• Google Analytics için Veri paylaşımı'nı etkinleştirmiş olmanız gerekir. Bu ayar hakkında daha fazla bilgi edinmek için Analytics veri paylaşım ayarlarınızı yönetme başlıklı makaleyi inceleyin.

• Uygulamanıza Google Analytics için Firebase SDK'sını eklediniz: iOS+ | Android | Flutter | Unity.
  Bu SDK, Crashlytics SDK'sına ek olarak eklenmelidir.

• Uygulamanızda kullandığınız tüm ürünler için en son Firebase SDK sürümlerini kullanıyorsunuz (iOS+ | Android | Flutter | Unity).

  Apple platformları ve Android uygulamaları için özellikle Google Analytics Firebase SDK'sının en azından aşağıdaki sürümünü kullandığınızı kontrol edin: iOS+ — v6.3.1+ (macOS ve tvOS için v8.9.0+) | Android — v17.2.3+ (BoM v24.7.1+).

Hız uyarılarını görmüyorum

Hız uyarılarını görmüyorsanız aşağıdakilerden birini kullandığınızdan emin olun:

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 metrikleri görmüyorsanız veya güvenilir olmayan metrikler görüyorsanız aşağıdakileri kontrol edin:

• Aşağıdaki SDK'ları kullandığınızdan emin olun:

• 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'ye gönderilebilir. Bu nedenle, kilitlenme içermeyen metriklerin doğruluğu etkilenir. Çünkü Crashlytics yalnızca bu kullanıcıların kilitlenme bilgilerine sahiptir (tüm kullanıcılarınızın bilgilerine değil). Bu durumda, kilitlenme içermeyen metrikleriniz daha az güvenilir olabilir ve uygulamanızın genel kararlılığını daha az yansıtabilir.

  • Otomatik veri toplamayı devre dışı bıraktıysanız cihazda önbelleğe alınan raporları Crashlytics'e göndermek için sendUnsentReports kullanabilirsiniz. Bu yöntemi kullanmak kilitlenme verilerini Crashlytics'e 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?

Kilitlenme içermeyen metrikleri anlama başlıklı makaleyi inceleyin.

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 üyeleri tarafından notla birlikte görülebilir.

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.

  • Proje Sahibi veya Düzenleyicisi, Firebase Yöneticisi, Kalite Yöneticisi, ya da Crashlytics Yöneticisi

• Aşağıdaki rollerden herhangi birine sahip olan proje üyeleri, bir soruna gönderilen notları görüntüleyebilir ancak not silemez veya yazamaz.

  • Proje Görüntüleyici, Firebase Görüntüleyici, Kalite Görüntüleyici, veya Crashlytics Görüntüleyici

Regresyon sorunu 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:

1. Crashlytics, ilk kez "A" kilitlenmesiyle ilgili bir kilitlenme raporu alıyor. Crashlytics, bu kilitlenme için ilgili bir sorun açar (A sorunu).
2. 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.
3. Crashlytics, sorunu kapattıktan sonra "A" sorunuyla ilgili başka bir rapor alır.
   • Rapor, sorunu kapattığınızda Crashlytics bilgisi 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 Crashlytics bilinmeyen 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.

Not: Şubat 2022'den önce Crashlytics, bir sorun herhangi bir uygulama sürümünde yeniden ortaya çıktığında, sorunu kapattığınızda bildiğimiz uygulama sürümlerinde bile bu sorunu gerileme olarak sınıflandırıyordu. Bu durum, Crashlytics'nın bazen regresyonları yanlış tanımlamasına neden oluyordu. Artık yukarıda açıklanan kuralı kullanıyoruz.

Bir sorun gerilediğinde, gerileme tespit uyarısı göndeririz ve Crashlytics kullanıcısının sorunu yeniden açtığını bildirerek 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 almamış kullanıcılarınız var. Daha önceki sürümlerden biri, sorunu kapattığınızda hiçbir kilitlenme raporu göndermediyse ve bu kullanıcılar hatayla karşılaşmaya başlarsa bu kilitlenme raporları, gerileme sorununun tetiklenmesine neden olur.

Regresyon algoritmamız nedeniyle bir sorunun yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "sessize alın".

Not: Şubat 2022'den önce Crashlytics, bir sorun herhangi bir uygulama sürümünde tekrar ortaya çıktığında, sorunu kapattığınızda bildiğimiz uygulama sürümlerinde bile bu sorunu gerileme olarak sınıflandırıyordu. Bu durum, Crashlytics bazen gerilemelerin yanlış tanımlanmasına neden oluyordu. Artık yukarıda açıklanan kuralı kullanıyoruz.

Şubat 2022'den önce çok sayıda yanlış tanımlanmış gerileme görüyorsanız bunların yeniden açılmasını önlemek için yeniden kapatabilirsiniz.

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 kaydedilirken ç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 ile BigQuery arasındaki bağlantıyı oluşturduktan sonra, oluşturduğunuz yeni veri kümeleri Firebase projenizin konumundan bağımsız olarak otomatik olarak ABD'de bulunur.

---

Platforma özel destek

Aşağıdaki bölümlerde platforma özel sorun giderme ve SSS ile ilgili destek sağlanmaktadır: iOS+ | Android | Unity.

Apple platformları desteği

dSYM'ler eksik veya yüklenmiyor

Projenizin dSYM'lerini yüklemek ve ayrıntılı çıkış almak için aşağıdakileri kontrol edin:

1. Projenizin derleme aşamasında, Xcode'un derleme sırasında projenizin dSYM'lerini yüklemesine olanak tanıyan Crashlytics çalıştırma komut dosyasının bulunduğundan emin olun (Komut dosyasını ekleme talimatları için Crashlytics başlatma bölümünü inceleyin). Projenizi güncelledikten sonra kilitlenmeyi zorlayın ve kilitlenmenin Crashlytics kontrol panelinde göründüğünü onaylayın.

2. Firebase konsolunda "Eksik dSYM" uyarısı görüyorsanız Xcode'u kontrol ederek derleme için dSYM'lerin düzgün şekilde oluşturulduğundan emin olun.

3. Xcode, dSYM'leri düzgün şekilde oluşturmasına rağmen eksik dSYM'ler görmeye devam ediyorsanız çalıştırma komut dosyası aracı, dSYM'leri yüklerken takılıyor olabilir. Bu durumda aşağıdakilerin her birini deneyin:

   • Crashlytics'in en son sürümünü kullandığınızdan emin olun.

   • Eksik dSYM dosyalarını manuel olarak yükleyin:

     • 1. seçenek: Eksik dSYM dosyalarını içeren bir zip arşivi yüklemek için dSYMs sekmesindeki konsol tabanlı "Sürükle ve Bırak" seçeneğini kullanın.
     • 2. seçenek: dSYMs sekmesinde sağlanan UUID'ler için eksik dSYM dosyalarını yüklemek üzere upload-symbols komut dosyasını kullanın.

4. Eksik dSYM'ler görmeye devam ederseniz veya yüklemeler hâlâ başarısız olursa Firebase Destek Ekibi ile iletişime geçin ve günlüklerinizi eklemeyi unutmayın.

Kilitlenmeler iyi simgeleştirilmemiş

Yığın izleriniz iyi sembolleştirilmemiş gibi görünüyorsa aşağıdakileri kontrol edin:

• Uygulamanızın kitaplığındaki çerçevelerde uygulamanızın koduna referans yoksa -fomit-frame-pointer'ın derleme işareti olarak ayarlanmadığından emin olun.

• Uygulamanızın kitaplığı için birkaç (Missing) çerçeve görüyorsanız Firebase konsolunun Crashlytics dSYM'ler sekmesinde etkilenen uygulama sürümü için eksik olarak listelenen isteğe bağlı dSYM'ler olup olmadığını kontrol edin. Bu durumda, bu sayfadaki dSYM'ler eksik/yüklenmiyor SSS bölümünde yer alan "Eksik dSYM uyarısı" sorun giderme adımını uygulayın. Bu dSYM'lerin yüklenmesi, halihazırda meydana gelmiş kilitlenmelerin sembolleştirilmesini sağlamaz ancak gelecekteki kilitlenmelerin sembolleştirilmesini sağlar.

macOS veya tvOS için Crashlytics kullanabilir miyim?

Evet, macOS ve tvOS projelerinde Crashlytics uygulayabilirsiniz. Kilitlenmelerin Google Analytics tarafından toplanan metrikleri (kilitlenme içermeyen kullanıcılar, en son sürüm, hız uyarıları ve breadcrumb günlükleri) kullanabilmesi için Firebase SDK'sının Google Analytics için 8.9.0 veya sonraki bir sürümünü eklediğinizden emin olun.

Farklı Apple platformlarında birden fazla uygulaması olan bir Firebase projesinde Crashlytics kullanabilir miyim?

Artık uygulamalar farklı Apple platformları (ör. iOS, tvOS ve Mac Catalyst) için oluşturulmuş olsa bile tek bir Firebase projesindeki birden fazla uygulamanın kilitlenmelerini bildirebilirsiniz. Daha önce, aynı paket kimliğini içeren uygulamaları ayrı Firebase projelerine ayırmanız gerekiyordu.

---

Android desteği

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?

Bazı ANR'lerinizde 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 güncel olmayan 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 Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
  • 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 çökmeler 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 eksikse derleme sisteminizin işaretlerine -Wl,--build-id ekleyin.

  • APK boyutunuzu küçültmek için BuildId'ları istemeden kaldırmadığınızdan emin olun.

  • Bir kitaplığın hem ayıklanmış hem de ayıklanmamış 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ı eşleşmeyebilir. 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 yalnızca Android 11 ve üzeri sürümlerin yüklü olduğu cihazlarda meydana gelen ANR'leri gösterir. Google Play ise Google Play Hizmetleri'nin yüklü olduğu ve veri toplama izninin kabul edildiği cihazlardaki ANR'leri gösterir.

Neden .kt dosyalarından kaynaklanan kilitlenmeleri .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ü kullanıyor
• Karartma etkin durumdayken R8'i kullanır. Uygulamanızı R8'e güncellemek için bu dokümanı inceleyin.

Yukarıda açıklanan kuruluma 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 bölümüne bakın.

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, aslında mevcut .java etiketli sorunların kopyaları olan yeni .kt sorunları görebilirsiniz. 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.

Dexguard ile kilitlenme sorunları yaşamıyorum

Aşağıdaki istisnayı görüyorsanız büyük olasılıkla Firebase Crashlytics SDK'sı ile uyumlu olmayan bir DexGuard sürümü kullanıyorsunuzdur:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

Bu istisna, uygulamanızın kilitlenmesine neden olmaz ancak kilitlenme raporları göndermesini engeller. Bu sorunu düzeltmek için:

1. En son DexGuard 8.x sürümünü kullandığınızdan emin olun. En son sürüm, Firebase Crashlytics SDK'sının gerektirdiği kuralları içeriyor.

2. DexGuard sürümünüzü değiştirmek istemiyorsanız karartma kurallarınıza (DexGuard yapılandırma dosyanızda) aşağıdaki satırı eklemeyi deneyin:

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

Android NDK'ya özel destek

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. Bunu 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 izleme 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.

Not: Android ikili dosyaları için Breakpad simge dosyası oluşturucunun Linux sürümü gereklidir.

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+

  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 düşük 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: 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:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

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ı.

---

Unity desteği

Crashlytics kontrol panelinde Android uygulamaları için sembolleştirilmemiş yığın izlemeleri görme

Unity IL2CPP kullanıyorsanız ve sembolleştirilmemiş yığın izleri görüyorsanız şunları deneyin:

1. Crashlytics Unity SDK'sının 8.6.1 veya sonraki bir sürümünü kullandığınızdan emin olun.

2. Sembol dosyanızı oluşturup yüklemek için Firebase CLI crashlytics:symbols:upload komutunu kullanmaya hazır olduğunuzdan ve bu komutu çalıştırdığınızdan emin olun.

   Bu CLI komutunu, yayın derlemesi veya Firebase konsolunda sembolleştirilmiş yığın izlemelerini görmek istediğiniz herhangi bir derleme oluşturduğunuzda çalıştırmanız gerekir. Daha fazla bilgi için Okunabilir kilitlenme raporları alma başlıklı makaleyi inceleyin.

Crashlytics, IL2CPP kullanan uygulamalarla kullanılabilir mi?

Evet, Crashlytics, IL2CPP kullanan uygulamalarınız için sembolleştirilmiş yığın izlemeleri gösterebilir. Bu özellik, Android veya Apple platformlarında yayınlanan uygulamalarda kullanılabilir. Yapmanız gerekenler:

1. Crashlytics Unity SDK'sının 8.6.0 veya sonraki bir sürümünü kullandığınızdan emin olun.

2. Platformunuz için gerekli görevleri tamamlayın:

   • Apple platformu uygulamaları için: Herhangi bir özel işlem yapmanız gerekmez. Apple platformu uygulamalarında, Firebase Unity Editor eklentisi, sembolleri yüklemek için Xcode projenizi otomatik olarak yapılandırır.

   • Android uygulamaları için: Sembol dosyanızı oluşturmak ve yüklemek için Firebase CLI crashlytics:symbols:upload komutunu ayarladığınızdan ve çalıştırdığınızdan emin olun.

     Bu CLI komutunu, yayın derlemesi veya Firebase konsolunda sembolleştirilmiş yığın izlemelerini görmek istediğiniz herhangi bir derleme oluşturduğunuzda çalıştırmanız gerekir. Daha fazla bilgi için Okunabilir kilitlenme raporları alma başlıklı makaleyi inceleyin.

Yakalanmamış istisnaları ölümcül olarak bildirme

Crashlytics, yakalanmamış istisnaları ölümcül hatalar olarak bildirebilir (Unity SDK'nın v10.4.0 sürümünden itibaren). Aşağıdaki SSS'ler, bu özelliği kullanmayla ilgili gerekçeleri ve en iyi uygulamaları açıklamaya yardımcı olur.

Bir uygulama neden yakalanmamış istisnaları ölümcül olarak bildirmelidir?

Yakalanmayan istisnaları ölümcül hatalar olarak bildirerek, uygulama çalışmaya devam etse bile hangi istisnaların oyunun oynanamamasına neden olabileceğine dair daha gerçekçi bir gösterge elde edersiniz.

Önemli kilitlenmeleri bildirmeye başlarsanız kilitlenme yaşamayan kullanıcı (CFU) yüzdesinin düşeceğini ancak CFU metriğinin, son kullanıcıların uygulamanızla ilgili deneyimlerini daha iyi yansıtacağını unutmayın.

Önemli: Yakalanmayan istisnaların ölümcül olarak bildirilmesi, Android Vitals'ınızı etkilemez. Crashlytics bölümünde bildirilen ölümcül hatalar, uygulama ve oyunlarınızdaki sorunları keşfedip düzeltebilmeniz için yalnızca size görünür.

Hangi istisnalar önemli hata olarak bildirilir?

Crashlytics'nın yakalanmamış bir istisnayı ölümcül olarak bildirmesi için aşağıdaki iki koşulun da karşılanması gerekir:

• Uygulamanızda başlatma sırasında ReportUncaughtExceptionsAsFatal özelliği true olarak ayarlanmalıdır.

• Uygulamanız (veya dahil edilen bir kitaplık) yakalanmayan bir istisna oluşturuyor. Oluşturulan ancak oluşturulmayan bir istisna yakalanmamış olarak kabul edilmez.

Yakalanmamış istisnaların önemli hatalar olarak raporlanmasını etkinleştirdikten sonra artık birçok yeni önemli hatam var. Bu istisnaları nasıl düzgün şekilde ele alabilirim?

Yakalanmayan istisnalarınızla ilgili raporları ölümcül hatalar olarak almaya başladığınızda, bu yakalanmayan istisnaları işlemek için kullanabileceğiniz bazı seçenekler şunlardır:

• Bu yakalanmamış istisnaları nasıl yakalamaya ve işlemeye başlayabileceğinizi düşünün.
• İstisnaları Unity hata ayıklama konsoluna ve Crashlytics kaydetmek için farklı seçenekleri değerlendirin.

Atılan istisnaları yakalama ve işleme

İstisnalar, beklenmedik veya istisnai durumları yansıtmak için oluşturulur ve gönderilir. Atılan bir istisnanın yansıttığı sorunları çözmek için programı bilinen bir duruma döndürmek gerekir (bu işleme istisna işleme adı verilir).

Program bilinen bir duruma döndürülemediği sürece, öngörülen tüm istisnaları yakalayıp işlemek en iyi uygulamadır.

Hangi tür istisnaların hangi kod tarafından yakalanıp işleneceğini kontrol etmek için istisna oluşturabilecek kodu try-catch bloğuna sarın. catch ifadelerindeki koşulların, belirli istisnaları uygun şekilde ele almak için mümkün olduğunca dar olduğundan emin olun.

Unity veya Crashlytics'de günlük istisnaları

Sorunun hata ayıklamasına yardımcı olmak için Unity veya Crashlytics'da istisnaları kaydetmenin birden fazla yolu vardır.

Crashlytics kullanırken en yaygın ve önerilen iki seçenek şunlardır:

• 1. seçenek: Geliştirme veya sorun giderme sırasında Unity konsolunda yazdırın ancak Crashlytics'a bildirmeyin.

  • Debug.Log(exception), Debug.LogWarning(exception) ve Debug.LogError(exception) kullanarak Unity konsoluna yazdırın. Bu yöntemler, istisnanın içeriğini Unity konsoluna yazdırır ve istisnayı yeniden oluşturmaz.

• 2. seçenek: Aşağıdaki durumlarda Crashlytics kontrol panelinde birleştirilmiş raporlama için Crashlytics'ya yükleyin:

  • Olası bir sonraki Crashlytics etkinliğinde hata ayıklamak için bir istisnanın günlüğe kaydedilmesi gerekiyorsa Crashlytics.Log(exception.ToString()) kullanın.
  • Yakalanıp işlenmesine rağmen bir istisnanın yine de Crashlytics'e raporlanması gerekiyorsa Crashlytics.LogException(exception) kullanarak bunu ölümcül olmayan bir etkinlik olarak günlüğe kaydedin.

Ancak, ölümcül bir etkinliği Unity Cloud Diagnostics'e manuel olarak bildirmek isterseniz Debug.LogException kullanabilirsiniz. Bu seçenek, 1. seçenekte olduğu gibi istisnayı Unity konsoluna yazdırır ancak istisnayı da oluşturur (henüz oluşturulmuş veya yakalanmış olsun ya da olmasın). Hata mesajı gösterilir. nonlocally Bu nedenle, Debug.LogException(exception) ile try-catch blokları içeren bir çevreleme bile yakalanmamış bir istisnaya neden olur.

Bu nedenle, Debug.LogException işlevini yalnızca aşağıdaki işlemlerin tümünü yapmak istiyorsanız çağırın:

• İstisnayı Unity konsoluna yazdırmak için.
• İstisnayı Crashlytics'ya ölümcül bir etkinlik olarak yüklemek için.
• İstisnayı oluşturmak için yakalanmamış bir istisna olarak ele alınmasını sağlayın ve Unity Cloud Diagnostics'e bildirilmesini sağlayın.

Yakalanan bir istisnayı Unity konsoluna yazdırmak ve Crashlytics'e ölümcül olmayan bir etkinlik olarak yüklemek istiyorsanız bunun yerine aşağıdakileri yapın:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}