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. Nedenini açıklayalım.

2023'ün başlarında, etkinlikleri gruplandırmak için geliştirilmiş bir analiz motorunun yanı sıra güncellenmiş bir tasarım ve yeni sorunlara (ör. varyantlar) yönelik bazı ileri seviye özellikleri kullanıma sunduk. Tüm ayrıntılar için son blog yayınımızı inceleyin. Önemli noktaları ise aşağıda bulabilirsiniz.

Crashlytics, uygulamanızdaki tüm etkinlikleri (kilitlenmeler, önemli olmayan hatalar ve ANR'ler gibi) analiz eder ve sorun adı verilen etkinlik grupları oluşturur. Bir sorundaki tüm etkinliklerin ortak bir hata noktası vardır.

Geliştirilmiş analiz motoru, etkinlikleri bu sorunlar halinde gruplandırmak için artık yığın izlemedeki ç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 bir yığın izine sahip etkinliklerin alt grubudur. Varyantlarla, bir sorundaki en yaygın yığın izlerini ayıklayabilir ve farklı ana nedenlerin hataya yol açıp açmadığını belirleyebilirsiniz.

Bu iyileştirmelerle birlikte deneyimleyecekleriniz:

• Sorun satırında gösterilen meta veriler yenilendi
  Uygulamanızdaki sorunları anlamak ve önceliklendirmek artık daha kolay.

• Daha az kopya sorun
  Satır numarası değişikliği yeni bir soruna neden olmaz.

• Çeşitli temel nedenleri olan karmaşık sorunların daha kolay hata ayıklanması
  Bir sorundaki en yaygın yığın izlerinin hata ayıklanması 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, hata 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 daha akıllı etkinlik gruplandırma algoritmamızı otomatik olarak 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şılamanız gerekir:

• 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 için 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ğıdaki SDK'ları kullandığınızdan emin olun:

Kilitlenme içermeyen metrikleri görmeme (veya güvenilir olmayan metrikleri görme)

Kullanıcıların kilitlenmeden kullandığı kullanıcı sayısı ve oturum sayısı gibi kilitlenmeden kullanılan 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ı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, yalnızca bu özelliği etkinleştiren kullanıcılardan alınan kilitlenme bilgileri (tüm kullanıcılarınızdan alınan bilgiler yerine) Crashlytics için kullanıldığından kilitlenmesiz metriklerin doğruluğu etkilenir. 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 Crashlytics'e 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 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

Regresyon sorunu nedir?

Daha önce kapattığınız bir sorun, Crashlytics sorunun tekrar oluştuğuna dair yeni bir rapor aldığında regresyon yaşar. 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 senaryoyu aşağıda bulabilirsiniz:

1. Crashlytics, ilk kez Crash "A" hakkında bir kilitlenme raporu alır. Crashlytics, bu kilitlenme için ilgili sorunu açar (Sorun "A").
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. 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, Crashlytics sorunu yeniden açtığını bildirmek için gerileme algılama uyarısı gönderir ve 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 gerilediğini düşünür ve sorunu yeniden açar.

Bu durum aşağıdaki 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 önceki 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 zaman 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 projenizin dSYM'lerini derleme sırasında 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ü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'nın 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'leri 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 bir şekilde simgeleştirilmemiş

Yığın izlemeleriniz iyi simgeselleş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 öğesinin derleme işareti olarak ayarlanmadığından emin olun.

• Uygulamanızın kitaplığı için birden fazla (Missing) çerçevesi 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, Crashlytics'ı macOS ve tvOS projelerinde uygulayabilirsiniz. Kilitlenmelerin Google Analytics tarafından toplanan metrikleri (kilitlenme içermeyen kullanıcılar, en son sürüm, hız uyarıları ve iz kaydı 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.

Farklı Apple platformlarında birden fazla uygulama içeren 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 uygulama için kilitlenmeleri bildirebilirsiniz. Daha önce, aynı paket kimliğini içeren uygulamaları ayrı Firebase projelerine ayırmanız gerekiyordu.

ANR'ler neden yalnızca Android 11 ve sonraki sürümlerde 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 eklentisi sürümü kullandığınızdan emin olun.

  Android 11 ve bazı Android 12 ANR'leri için BuildId eksikse eski bir SDK, Gradle eklentisi veya her ikisini de kullanıyor olabilirsiniz. Bu ANR'ler için BuildId öğelerini 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+

• 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 simgelerinin 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 kullanıyorsanız kodunuzda doğru sürüme işaret ettiğinizden emin olun.

Crashlytics kontrol panelindeki ANR raporları ile Google Play Console arasındaki farklar

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 sonraki sürümlerin yüklü olduğu cihazlarda gerçekleşen 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 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 kuruluma güncelledikten sonra, mevcut .kt sorunlarının kopyası olan yeni .java sorunları görmeye başlayabilirsiniz. Bu durum hakkında daha fazla bilgi edinmek için SSS bölümüne bakın.

Neden .kt mevcut sorunların kopyası olan .java sorunları görüyorum?

Aralık 2021'in ortaları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ı desteklemektedir.

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 çökmeler artık .kt dosyalarına (uygun şekilde) doğru şekilde ilişkilendirilir:

• Uygulamanızda Android Gradle 4.2.0 veya sonraki bir sürüm kullanılıyor.
• Uygulamanızda karartma özelliği 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 sorunun 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şamama

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ümde, Firebase Crashlytics SDK'sı için gerekli olan kurallar yer alıyor.

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ü, ana sürüm (v3.0.0) olup Gradle'ın ve Android Gradle eklentisinin daha eski sürümleri için desteği sonlandırarak SDK'yı modernleştirir. 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 için minimum gereksinimler şunlardır:

• Android Gradle eklentisi 8.1 veya sonraki sürümler
  Bu eklentiyi, Android Studio'nun en son sürümünde Android Gradle eklentisi Yükseltme Yardımcısı'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.5.0" apply false
  ...
}

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.5.0' 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 olarak değiştirildi.

  Birden fazla 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 izlemeleri 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 durumu azaltmak için derleme işleminize aşağıdaki bağlayıcı işaretlerini ekleyin:

• LLVM araç zincirindeki lld bağlayıcıyı 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 kullanabilirim?

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 ikilisinin yolunu iki şekilde belirtebilirsiniz:

• 1. seçenek: firebaseCrashlytics dosyanızdaki build.gradle uzantısı aracılığıyla 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ı.

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 KSA'yı kurduğunuzdan ve crashlytics:symbols:upload komutunu çalıştırdığınızdan emin olun.

   Bu CLI komutunu, yayın derlemesi veya Firebase konsolunda sembolleştirilmiş yığın izlemeleri görmek istediğiniz her 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 uygulamalarda 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: Özel bir işlem yapmanız gerekmez. Apple platformu uygulamaları için Firebase Unity Editor eklentisi, sembolleri yüklemek üzere Xcode projenizi otomatik olarak yapılandırır.

   • Android uygulamaları için: Sembol dosyanızı oluşturup yüklemek üzere 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 izlemeleri görmek istediğiniz her derleme oluşturduğunuzda ç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?

Yakalanmamış 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 raporlamaya 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ızdaki 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 ölümcül hatalar olarak raporlanmasını etkinleştirdikten sonra artık çok sayıda yeni ölümcül hatam var. Bu istisnaları nasıl düzgün şekilde ele alabilirim?

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

• Bu yakalanmamış istisnaları nasıl yakalayıp işleyebileceğinizi düşünün.
• İstisnaları Unity hata ayıklama konsoluna ve Crashlytics'a kaydetmek için farklı seçenekleri değerlendirin.

Atılan istisnaları yakalama ve işleme

Beklenmedik veya istisnai durumları yansıtmak için istisnalar oluşturulur ve atılır. 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ı yakalamak ve 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'da günlük istisnaları

Unity'de istisnaları kaydetmenin veya Crashlytics sorunun hata ayıklamasına yardımcı olmanın 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'ya 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:

  • Olası bir sonraki Crashlytics etkinliğinde hata ayıklamak için bir istisnayı günlüğe kaydetmek gerekiyorsa Crashlytics.Log(exception.ToString()) kullanın.
  • Yakalanıp işlenmesine rağmen bir istisnanın yine de Crashlytics'ya 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 olayı 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 numarasını yalnızca aşağıdaki işlemlerin tümünü yapmak istiyorsanız arayı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 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 içine 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?

Ekim 2024'ün ortalarında Crashlytics, Crashlytics verilerinin BigQuery'e toplu dışa aktarılması için yeni bir altyapı başlattı.

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

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

• Yeni altyapı, ABD dışındaki 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 doldurulmasını desteklemez.

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

  • Yeni altyapı, BigQuery'e dışa aktarmayı etkinleştirdiğiniz en son tarihe veya son 30 güne kadar olan geri doldurmaları (hangisi daha yakınsa) destekler.

• Yeni altyapı, BigQueryFirebase projenizdeki Firebase uygulamalarınız için ayarlanan tanımlayıcıları kullanarak toplu tabloları adlandırır.

  • Eski altyapı, verileri uygulamanızın ikili programındaki paket kimliklerine veya paket adlarına göre adlandırılmış toplu iş tablolarına 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şlem 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şlem verilerinizde daha fazla kesinti olmaması için bu seçeneklerden birini uygulayın.

Dışa aktarma altyapısının, BigQuery tablolarına veri 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şlem tablolarına nasıl yazdığını aşağıda görebilirsiniz:

• Eski dışa aktarma altyapısı: Verileri, uygulamanızın ikili programındaki paket kimliğine veya paket adına dayalı bir ada sahip tabloya yazdı.

• Yeni dışa aktarma altyapısı: Verileri, Firebase projenizde kayıtlı Firebase uygulamanız için ayarlanan paket kimliğine veya paket adına dayalı bir ada sahip bir tabloya yazar.

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ının girilmemesi nedeniyle yaşanır.

Yükseltme işleminden önce bu sorun düzeltilmezse ne olur?

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

• Crashlytics verileriniz artık BigQuery toplu iş tablosuna yazılıyor. Bu, Firebase projenizde kayıtlı Firebase uygulamanız için ayarlanan paket kimliğine veya paket adına dayalı bir ada sahip yeni bir tablo anlamına geliyor.

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

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 ikili programındaki 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 koruyacak ve tüm uygulamalar için tabloya veri yazmaya başlayacaktır.}

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, tüm verileri kopyalayın eski tablonuzdan altyapı yükseltmesi sırasında oluşturulan yeni tabloya.

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

• 2. SEÇENEK:
  Eski tablonuza tekrar yazmak için 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, eşleşmeyen toplu tablo adı ve tanımlayıcısı olan uygulamanın Firebase uygulama kimliğini (örneğin, 1:1234567890:ios:321abc456def7890) bulun ve 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ı" değiştirerek verilerin eski tablonuza yazılmasını sağlayın:

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

     2. Kaynağı içeren 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. Varsayılan olarak, BigQuery içindeki client_namespace değeri 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 bağlı Firebase uygulamasının yazdığı toplu tablo için 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.