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ı 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 veya 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 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), 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'lardan birini 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 Crashlytics hizmetine kilitlenme verilerini 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.

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

dSYM'ler eksik/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 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 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 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 ü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 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 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ü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 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, yeni .kt sorunları görebilirsiniz. Bu sorunlar aslında mevcut .java etiketli sorunların yalnızca kopyalarıdır. 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

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

Crashlytics Gradle eklentisinin en son sürümü, Gradle ve Android Gradle eklentisinin daha düşük sürümleri için desteği sonlandırarak 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 veya daha yeni bir sürüm
  Bu eklentiyi, projenizin Gradle derleme dosyasında en son sürümü belirterek 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.

• Kapanış 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. 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.

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ünde 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 ş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 ç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 izlemelerini 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 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, her sürüm derlemesi oluşturduğunuzda veya Firebase konsolunda sembolleştirilmiş yığın izlemelerini 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 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.

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 etkinliğin hata ayıklaması için bir istisnanın günlüğe kaydedilmesi gerekiyorsa Crashlytics.Log(exception.ToString()) kullanın.Crashlytics
  • Yakalanıp işlenmesine rağmen bir istisnanın Crashlytics'e raporlanmaya devam etmesi 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). Hata mesajı gösterilir. nonlocally Bu nedenle, Debug.LogException(exception) ile try-catch blokları içeren 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ı 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
    //
}

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?

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 nasıl geçilir?

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

• Toplu dışa aktarmayı Ekim 2024'ten sonra etkinleştirdiyseniz Firebase projeniz otomatik olarak yeni dışa aktarma altyapısını kullanır. Herhangi bir işlem yapmanız gerekmez.

• Toplu dışa aktarma özelliğini Ekim 2024'ten önce veya Ekim 2024'te etkinleştirdiyseniz herhangi bir işlem yapmanız gerekip gerekmediğini belirlemek için bu SSS'deki bilgileri inceleyin.

Tüm Firebase projeleri, 9 Ocak 2026'dan itibaren yeni toplu dışa aktarma altyapısına otomatik olarak yükseltilecek. Bu tarihten önce yükseltme yapabilirsiniz ancak BigQuery toplu tablolarınızın yükseltme için ön koşulları karşıladığından emin olun.

Yeni altyapıya geçebilirsiniz ancak BigQuery toplu tablolarınızın yükseltme için ön koşulları karşıladığından emin olun.

Yeni altyapıda olup olmadığınızı belirleme

Toplu dışa aktarma özelliğini Ekim 2024'ün ortasında veya daha sonra etkinleştirdiyseniz Firebase projeniz yeni dışa aktarma altyapısını otomatik olarak kullanır.

Projenizin hangi altyapıyı kullandığını kontrol edebilirsiniz: Google Cloud konsoluna gidin. "Veri aktarımı yapılandırmanız" Firebase Crashlytics with Multi-Region Support olarak etiketlenmişse projeniz yeni dışa aktarma altyapısını kullanıyor demektir.

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

1. adım: Yükseltme için ön koşul

1. Mevcut BigQuery toplu tablolarınızın, Firebase projenizde kayıtlı Firebase uygulamalarınız için ayarlanan paket kimlikleri veya paket adlarıyla eşleşen tanımlayıcılar kullandığını kontrol edin. Eşleşmezlerse dışa aktarılan toplu verilerinizde kesintiler yaşayabilirsiniz. Çoğu proje uygun ve uyumlu durumda olur ancak yükseltmeden önce kontrol etmeniz önemlidir.

   • Firebase projenize kaydedilen tüm Firebase uygulamalarını Firebase konsolunda bulabilirsiniz: 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.

   • Tüm BigQuery toplu tablolarınızı Google Cloud konsolunun BigQuery sayfasında bulabilirsiniz.

   Örneğin, yükseltme sırasında sorun yaşamayacağınız ideal durumlar şunlardır:

   • com_yourcompany_yourproject_IOS adlı bir toplu iş tablonuz ve Firebase projenize kaydedilmiş com.yourcompany.yourproject paket kimliğine sahip bir Firebase iOS+ uygulamanız var.

   • com_yourcompany_yourproject_ANDROID adlı bir toplu iş tablonuz ve Firebase projenize kaydedilmiş com.yourcompany.yourproject paket adına sahip bir Firebase Android uygulamanız var.

2. Kayıtlı Firebase uygulamalarınız için ayarlanan tanımlayıcılarla eşleşmeyen toplu tablo adlarınız varsa toplu dışa aktarma işleminizin kesintiye uğramaması için manuel olarak yükseltmeden veya 9 Ocak 2026'dan önce bu sayfadaki talimatları uygulayın.

2. adım: Yeni altyapıya manuel olarak yükseltme

Toplu dışa aktarma özelliğini Ekim 2024'ün ortasından önce etkinleştirdiyseniz Crashlytics veri dışa aktarma özelliğini Firebase konsolunda kapatıp tekrar açarak yeni altyapıya manuel olarak yükseltebilirsiniz.

Ayrıntılı adımlar aşağıda verilmiştir:

1. Firebase konsolunda Entegrasyonlar sayfasına gidin.

2. BigQuery kartında Yönet'i tıklayın.

3. Dışa aktarmayı devre dışı bırakmak için Crashlytics kaydırma çubuğunu kapatın. İstendiğinde veri dışa aktarma işlemini durdurmak istediğinizi onaylayın.

4. Dışa aktarmayı yeniden etkinleştirmek için Crashlytics kaydırma çubuğunu hemen tekrar açın. İstendiğinde verileri dışa aktarmak istediğinizi onaylayın.

   Crashlytics verilerinizin BigQuery konumuna dışa aktarılması artık yeni dışa aktarma altyapısı kullanılarak yapılıyor.

Mevcut toplu tablo adınız, Firebase uygulama tanımlayıcınızla eşleşmiyor