Crashlytics ile ilgili sorun giderme ve 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ı ileri seviye ö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 yığın izindeki çerçeveler, istisna mesajı, hata kodu ve diğer platform ya da hata türü özellikleri dahil olmak üzere etkinliğin birçok yönünü 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 izlemelerde (stack trace) hata ayıklayabilir ve farklı temel nedenlerin hataya yol açıp açmadığını belirleyebilirsiniz.

Bu iyileştirmelerle karşılaşacağınız deneyimler:

• 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), uygulamanızın Google Analytics 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şsinizdir. 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ızdan emin olun: 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ğıdakileri 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 kilitlenme sorunu ile karşılaşmayan metrikleri görmüyorsanız veya güvenilir olmayan metrikler görüyorsanız aşağıdakileri kontrol edin:

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

• Veri toplama ayarlarınızın, hatasızlık 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 özelliği etkinleştiren kullanıcılardan gelen kilitlenme bilgilerine sahiptir (tüm kullanıcılarınızdan gelen bilgilere 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 cihaz üzerinde ö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 notları silemez veya not yazamaz.

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

Regresyona uğramış sorun 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ız için uygun şekilde ele alabilirsiniz.

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 dahilinde 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. Sorun 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.

Bir sorun gerilediğinde, gerileme algılama 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.

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

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üresi 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 başlıklı makaleyi 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ürseniz 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 simgeselleştirilmesini sağlamaz ancak gelecekteki kilitlenmelerin simgeselleş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 Google Analytics için Firebase SDK'sının 8.9.0 veya sonraki bir sürümünü eklediğinizden emin olun.

Crashlytics'ı farklı Apple platformlarında birden fazla uygulaması olan bir Firebase projesinde 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.

Neden yalnızca Android 11 ve üzeri 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?

ANR'lerinizin bazılarında BuildId eksikse aşağıdaki şekilde sorun giderin:

• Güncel bir Crashlytics Android SDK ve Crashlytics Gradle eklenti sürümü kullandığınızdan emin olun.

  Android 11 için BuildId ve bazı Android 12 ANR'leri eksikse eski bir SDK, Gradle eklentisi veya her ikisini de kullanıyor olabilirsiniz. Bu ANR'ler için BuildId'leri düzgün şekilde toplamak istiyorsanız 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+

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

• Derleme 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 kilitlenmeler 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 yoksa 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 sembolleri kaldırılmış hem de kaldırılmamış 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ı arasında uyuşmazlık olabilir. 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, Google Play'in Google Play Hizmetleri'nin yüklü olduğu ve veri toplama izninin kabul edildiği cihazlardaki ANR'leri göstermesine kıyasla yalnızca Android 11 ve sonraki sürümlerin yüklü olduğu cihazlarda meydana gelen ANR'leri gösterir.

Neden .kt dosyalarından kaynaklanan kilitlenmeler .java sorunları olarak etiketleniyor?

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ünü kullanıyor olmanız gerekir.
• Karartma etkin durumdayken R8'i kullanır. Uygulamanızı R8'e güncellemek için bu dokümanı inceleyin.

Yukarıda açıklanan kurulumu 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 yalnızca 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 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ı için gerekli olan 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

Crashlytics Gradle eklentisi v3'e nasıl yükseltilir?

Crashlytics Gradle eklentisinin en son sürümü, Gradle'ın ve Android Gradle eklentisinin daha düşük sürümleri için desteği bırakarak SDK'yı modernize eden önemli bir sürümdür (v3.0.0). Ayrıca bu sürümdeki değişiklikler, AGP v8.1+ ile ilgili sorunları çözer ve yerel uygulamalar ile özelleştirilmiş derlemeler için desteği iyileştirir.

Minimum koşullar

Crashlytics Gradle eklentisi v3'ün minimum gereksinimleri şunlardır:

• Android Gradle eklentisi 8.1+
  Bu eklentiyi, Android Studio'nun en son sürümünde Android Gradle eklentisi Yükseltme Asistanı'nı kullanarak yükseltin.

• Firebase'in google-services Gradle eklentisi 4.4.1+
  Projenizin Gradle derleme dosyasında en son sürümü belirterek bu eklentiyi yükseltin. Örneğin:

plugins {
  id("com.android.application") version "8.1.4" apply false
  id("com.google.gms.google-services") version "4.4.4" apply false
  ...
}

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.4.4' apply false
  ...
}

Crashlytics uzantısında yapılan değişiklikler

Crashlytics Gradle eklentisinin 3. sürümünde, Crashlytics uzantısında aşağıdaki zarar veren değişiklikler yapıldı:

• Uzantı, defaultConfig android bloğundan kaldırıldı. Bunun yerine her varyantı yapılandırmanız gerekir.

• Desteği sonlandırılan mappingFile alanı kaldırıldı. Bunun yerine, birleştirilmiş eşleme dosyası artık otomatik olarak sağlanıyor.

• Desteği sonlandırılan strippedNativeLibsDir alanı kaldırıldı. Bunun yerine, tüm yerel kitaplıklar için unstrippedNativeLibsDir kullanmanız gerekir.

• unstrippedNativeLibsDir alanı kümülatif olacak şekilde değiştirildi.

  Birden çok dizin içeren bir örneği görüntüleme

  buildTypes {
    release {
      configure<CrashlyticsExtension> {
        nativeSymbolUploadEnabled = true
        unstrippedNativeLibsDir = file("MY/NATIVE/LIBS")
      }
    }
    productFlavors {
      flavorDimensions += "feature"
      create("basic") {
        dimension = "feature"
        // ...
      }
      create("featureX") {
        dimension = "feature"
        configure<CrashlyticsExtension> {
          unstrippedNativeLibsDir = file("MY/FEATURE_X/LIBS")
        }
      }
    }
  }

  uploadCrashlyticsSymbolFilesBasicRelease görevi yalnızca MY/NATIVE/LIBS içindeki sembolleri yükler. uploadCrashlyticsSymbolFilesFeatureXRelease ise hem MY/NATIVE/LIBS hem de MY/FEATURE_X/LIBS içindeki sembolleri yükler.

• Kapatma alanı symbolGenerator, iki yeni üst düzey alanla değiştirildi:

  • symbolGeneratorType, "breakpad" (varsayılan) veya "csym" dizesi.
  • breakpadBinary, yerel dump_syms ikili geçersiz kılma dosyası.

Uzantıyı yükseltme örneği

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGenerator(
                closureOf<SymbolGenerator> {
                  symbolGeneratorType = "breakpad"
                  breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              )
            }
          }
        }
      

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGeneratorType = "breakpad"
              breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGenerator {
                breakpad {
                  binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              }
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

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. Bu sorunu azaltmak için derleme işleminize 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 işleminize aşağıdakileri eklemeyi deneyin:

-fno-omit-frame-pointer

NDK için kendi Breakpad sembol dosyası oluşturucu ikili programımı 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 programını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.

Breakpad sembol dosyası oluşturucu ikili programının 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 veya üzeri

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

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 aşağıdakileri 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 çalıştırdığınızdan emin olun.

   Bu CLI komutunu, her sürüm derlemesi oluşturduğunuzda veya Firebase konsolunda sembolleştirilmiş yığın izlemeleri görmek istediğiniz her derleme için ç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 izlemelerini 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 üzere Firebase CLI crashlytics:symbols:upload komutunu ayarladığınızdan ve çalıştırdığınızdan emin olun.

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

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

Yakalanmayan istisnaları ölümcül 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.

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.

Yakalanmayan 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 görünmeye başladığında, 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ın bilinen bir duruma döndürülememesi haricinde, ö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. Belirli istisnaları uygun şekilde işlemek için catch ifadelerindeki koşulların mümkün olduğunca dar olduğundan emin olun.

Unity veya Crashlytics'de istisnaları günlüğe kaydetme

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.

  • Hata içeriğini Unity konsoluna yazdıran ve hatayı yeniden oluşturmayan Debug.Log(exception), Debug.LogWarning(exception) ve Debug.LogError(exception) kullanarak Unity konsoluna yazdırın.

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

  • Bir istisna, olası bir sonraki Crashlytics etkinliğinde hata ayıklamak için günlüğe kaydedilmeye değerse Crashlytics.Log(exception.ToString()) kullanın.
  • Yakalanıp işlenmesine rağmen bir istisnanın yine de Crashlytics'e bildirilmesi gerekiyorsa bunu ölümcül olmayan bir etkinlik olarak günlüğe kaydetmek için Crashlytics.LogException(exception) kullanın.

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). nonlocally hatası veriyor. Bu nedenle, Debug.LogException(exception) ile try-catch bloklarının bulunduğu bir çevre 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.
• Özel durumu Crashlytics'ya önemli bir etkinlik olarak yüklemek için.
• İstisnayı oluşturmak için yakalanmamış bir istisna olarak ele alınması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
    //
}

Uygulama, Google Mobile Ads SDK'sını da kullanıyor ancak kilitlenme sorunu yaşamıyor

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?

Firebase, verileri BigQuery için veri dışa aktarma işlemini ayarlarken seçtiğiniz veri kümesi konumuna aktarır.

• Bu konum hem Crashlytics veri kümesi hem de Firebase oturumları veri kümesi (oturum verilerinin dışa aktarılması etkinleştirilmişse) için geçerlidir.

• Bu konum yalnızca BigQuery'ya aktarılan veriler için geçerlidir ve Firebase konsolunun Crashlytics kontrol panelinde veya Android Studio'da kullanılmak üzere depolanan verilerin konumunu etkilemez.

• Veri kümesi oluşturulduktan sonra konumu değiştirilemez ancak veri kümesini farklı bir konuma kopyalayabilir veya veri kümesini farklı bir konuma manuel olarak taşıyabilirsiniz (yeniden oluşturma). Daha fazla bilgi için Mevcut dışa aktarma işlemlerinin konumunu değiştirme başlıklı makaleyi inceleyin.

BigQuery için yeni dışa aktarma altyapısına yükselttikten sonra sorun mu yaşıyorsunuz?

Crashlytics, Ekim 2024'ün ortalarında Crashlytics verilerinin BigQuery'ye toplu dışa aktarımı için yeni bir altyapı kullanıma sundu.

Tüm Firebase projeleri, 2 Mart 2026 itibarıyla yeni toplu dışa aktarma altyapısına otomatik olarak yükseltildi.

Eski ve yeni dışa aktarma altyapısı arasındaki önemli farklar

• Yeni altyapı, Crashlytics veri kümesi konumlarını destekler.

  • Ekim 2024'ün ortalarından önce dışa aktarma etkinleştirildi ve yeni dışa aktarma altyapısına yükseltildi: Artık isteğe bağlı olarak veri dışa aktarma konumunu değiştirebilirsiniz.

  • Dışa aktarma, Ekim 2024'ün ortasında veya daha sonra etkinleştirildi: Kurulum sırasında veri dışa aktarma için bir konum seçmeniz istendi.

• Yeni altyapı, dışa aktarmayı etkinleştirmeden önceki verilerin geri doldurulmasını desteklemez.

  • Eski altyapı, dışa aktarmayı etkinleştirdiğiniz tarihten önceki 30 güne kadar geri doldurmayı destekliyordu.

  • Yeni altyapı, son 30 güne kadar doldurma işlemlerini veya dışa aktarmayı etkinleştirdiğiniz en son tarihi (hangisi daha yakınsa) destekler.BigQuery

• Yeni altyapı, Firebase projenizdeki Firebase uygulamalarınız için ayarlanan tanımlayıcıları kullanarak BigQuery toplu tablolar oluşturur.

  • Eski altyapı, verileri uygulamanızın ikili programındaki paket kimliklerine veya paket adlarına göre adlandırılmış toplu tablolara yazıyordu.

  • Yeni altyapı, verileri Firebase projenizde kayıtlı Firebase uygulamalarınız için ayarlanan paket kimliklerine veya paket adlarına göre adlandırılmış toplu iş tablolarına yazar.

Eski toplu iş tablosu adınız Firebase uygulama tanımlayıcınızla eşleşmiyorsa

Eski toplu iş tablosu adınız, kayıtlı Firebase uygulamanız için ayarlanan paket kimliği veya paket adıyla eşleşmiyorsa, dışa aktarılan toplu iş verilerinizde daha fazla kesinti olmaması için bu seçeneklerden birini uygulayın.

Dışa aktarma altyapısının, verileri BigQuery tablolarına yazmak için tanımlayıcıları nasıl kullandığını anlama

İki dışa aktarma altyapısının Crashlytics verilerini BigQuery toplu iş tablolarına nasıl yazdığı aşağıda açıklanmıştır:

• Eski dışa aktarma altyapısı: Uygulamanızın ikili programındaki paket kimliğine veya paket adına göre adlandırılmış bir tabloya veri yazdı.

• Yeni dışa aktarma altyapısı: Verileri, paket kimliğine veya paket adına göre adlandırılmış bir tabloya yazar. Paket kimliği veya paket adı, Firebase projenizde kayıtlı Firebase uygulamanız için ayarlanır.

Maalesef bazen uygulamanızın ikili programındaki paket kimliği veya paket adı, Firebase projenizde kayıtlı Firebase uygulamanız için ayarlanan paket kimliği veya paket adıyla eşleşmez. Bu durum genellikle, uygulama kaydı sırasında gerçek tanımlayıcıyı girmeyen kullanıcılar için yaşanır.

Bu sorun, yükseltme yapılmadan önce düzeltilmezse ne olur?

Bu iki konumdaki tanımlayıcılar eşleşmiyorsa aşağıdakiler gerçekleşmiştir:

• CrashlyticsVerileriniz artık yeni bir BigQuery toplu iş tablosuna yazılıyor. Bu tablo, paket kimliğine veya Firebase projenizde kayıtlı Firebase uygulamanız için ayarlanan paket adına göre adlandırılan yeni bir tablodur.

• Uygulamanızın ikili programındaki tanımlayıcıya göre adlandırılmış mevcut "eski" tablolara artık veri yazılmıyor.

Eşleşmeyen tanımlayıcılarla ilgili örnek senaryolar

BigQuery toplu tablo adlarına, uygulamanın platformunu belirtmek için otomatik olarak _IOS veya _ANDROID eklenir.

^{* Uygulamanızın ikilisindeki tanımlayıcı, bir Firebase uygulaması için ayarlanan tanımlayıcılardan biriyle eşleşiyorsa yeni dışa aktarma altyapısı bu tanımlayıcı için yeni bir tablo oluşturmadı. Bunun yerine, söz konusu uygulamaya veri yazmaya devam eder. Diğer tüm uygulamalar yeni tablolara yazılır.}

^{** Uygulamanızın ikilisindeki tanımlayıcılardan biri, Firebase uygulaması için ayarlanan tanımlayıcıyla eşleşiyorsa yeni dışa aktarma altyapısı yeni bir tablo oluşturmaz. Bunun yerine, bu tabloyu korur ve tüm uygulamaların verilerini tabloya yazmaya başlar.}

Kesintiyi azaltma seçenekleri

• 1. SEÇENEK:
  Yeni dışa aktarma altyapısı tarafından oluşturulan yeni tabloyu kullanın. Eski tablonuzdaki verileri yeni tabloya kopyalarsınız.

  1. Google Cloud konsolunda, altyapı yükseltmesi sırasında oluşturulan yeni tabloya eski tablonuzdaki tüm verileri kopyalayın.

  2. Toplu iş tablonuza bağlı alt akış bağımlılıklarınız varsa bunları yeni tabloyu kullanacak şekilde değiştirin.

• 2. SEÇENEK:
  Eski tablonuza tekrar yazacak şekilde yeniden yapılandırın. Bunu yapmak için BigQuery yapılandırmasında bazı varsayılanları geçersiz kılmanız gerekir.

  1. Firebase konsolunda, toplu iş tablosu adı ve tanımlayıcısı eşleşmeyen uygulamayı bulun ve Firebase uygulama kimliğini (ör. 1:1234567890:ios:321abc456def7890) not alın:
     settings Proje ayarları'na gidin, ardından tüm Firebase uygulamalarınızı ve bilgilerini görmek için Uygulamalarınız kartına gidin.

  2. Google Cloud konsolunda, altyapı yükseltmesiyle oluşturulan yeni "veri aktarımı yapılandırması"nı, verilerin eski tablonuza yazılacak şekilde değiştirin:

     1. "Veri aktarımı yapılandırmanızı" görüntülemek için BigQuery > Veri aktarımları'na gidin.

     2. Kaynağın bulunduğu yapılandırmayı seçin Firebase Crashlytics with Multi-Region Support.

     3. Sağ üst köşedeki Düzenle'yi tıklayın.

     4. Veri kaynağı ayrıntıları bölümünde gmp_app_id ve client_namespace listelerini bulun.

        BigQuery içinde Firebase Uygulama Kimliği, gmp_app_id olarak adlandırılır. BigQuery içindeki client_namespace değeri varsayılan olarak uygulamanın karşılık gelen benzersiz paket kimliği / paket adıdır ancak bu varsayılan yapılandırmayı geçersiz kılacaksınız.

        BigQuery, her bir bağlı Firebase uygulamasının yazdığı toplu tablo adında client_namespace değerini kullanır.

     5. Varsayılan ayarları geçersiz kılmak istediğiniz Firebase uygulamasının gmp_app_id değerini bulun. client_namespace değerini, Firebase uygulamasının yazmasını istediğiniz tablonun adıyla değiştirin (genellikle bu, uygulamanın eski dışa aktarma altyapısıyla yazdığı eski tablonun adıdır).

     6. Yapılandırma değişikliğini kaydedin.

  3. Eski tablonuzda veri eksik olan günler için bir geri doldurma planlayın.

  4. Doldurma işlemi tamamlandıktan sonra, yeni dışa aktarma altyapısı tarafından otomatik olarak oluşturulan yeni tabloyu silin.