Crashlytics ile ilgili sorun giderme ve SSS

Sorunlar tablosundaki bazı sorunlar için farklı biçimler (ve bazen "varyantlar") görme

Firebase Console'daki 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 yeni sorunlar (ör. varyantlar) için güncellenmiş bir tasarım ve bazı ileri seviye özellikleri kullanıma sunduk. Tüm ayrıntılar için son blog yayınımızı inceleyin. Öne çıkan noktaları aşağıda okuyabilirsiniz.

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 sorunlara göre gruplandırmak için artık etkinliğin birçok yönünü inceler. Bunlar arasında yığın izlemedeki çerçeveler, istisna mesajı, hata kodu ve diğer platform veya hata türü özellikleri yer alır.

Ancak bu etkinlik grubunda, hataya yol açan yığın izlemeler farklı olabilir. Farklı bir yığın izleme (stack trace), farklı bir temel neden olduğu anlamına gelebilir. Bir sorundaki bu olası farkı temsil etmek için artık sorunların içinde varyantlar oluşturuyoruz. Her varyant, bir sorundaki aynı hata noktasına ve benzer bir yığın izlemeye sahip etkinliklerin alt grubudur. Varyantlar sayesinde, bir sorundaki en yaygın yığın izlemelerde hata ayıklayabilir ve hataya farklı temel nedenlerin yol açıp açmadığını belirleyebilirsiniz.

Bu iyileştirmelerle birlikte şunları deneyimleyeceksiniz:

• 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 izlemelerde 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 sorun, istisna türü ve paket adı gibi daha fazla aranabilir meta veri içerir.

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 daha akıllı etkinlik gruplandırma algoritmamızı etkinliğe otomatik olarak uygular 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.

Breadcrumb kayıtları görünmüyor

Breadcrumb kayıtlarını 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 özelliğini etkinleştirdiniz.

• Google Analytics için Veri paylaşımı'nı etkinleştirdiniz. 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'ya ek olarak eklenmelidir.

• Uygulamanızda kullandığınız tüm ürünler için en yeni 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 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 sürümleri kullandığınızdan emin olun:

Kilitlenme yaşanmayan oturum metriklerini görememe (veya güvenilir olmayan metrikler görme)

Kilitlenme yaşanmayan kullanıcılar ve oturumlar gibi kilitlenme yaşanmayan metrikleri görmüyorsanız veya güvenilir olmayan metrikler görüyorsanız aşağıdakileri kontrol edin:

• Şu sürümleri kullandığınızdan emin olun:

• Veri toplama ayarlarınızın, kilitlenme yaşanmayan oturum ve kullanıcı metriklerinizin kalitesini etkilemediğinden emin olun:

  • Otomatik kilitlenme raporlamasını devre dışı bırakarak onaylı raporlamayı etkinleştirirseniz kilitlenme bilgileri yalnızca veri toplamayı açıkça onaylamış kullanıcılardan Crashlytics hizmetine gönderilebilir. Bu nedenle, Crashlytics yalnızca bu kullanıcıların kilitlenme bilgilerine sahip olduğundan (tüm kullanıcılarınızın değil) kilitlenme içermeyen metriklerin doğruluğu etkilenecektir. Bu durum, kilitlenme yaşanmayan oturum metriklerinizin daha az güvenilir olmasına ve uygulamanızın genel kararlılığını daha az yansıtmasına neden olabilir.

  • Otomatik veri toplamayı devre dışı bıraktıysanız cihaz üzerinde önbelleğe alınmış raporları Crashlytics hizmetine göndermek için sendUnsentReports yöntemini kullanabilirsiniz. Bu yöntem kullanıldığında Crashlytics hizmetine kilitlenme verileri gönderilir ancak oturum verileri gönderilmez. Bu durum, konsol grafiklerinde kilitlenme içermeyen metrikler için düşük veya sıfır değerlerin gösterilmesine neden olur.

Kilitlenme yaşamayan kullanıcılar nasıl hesaplanır?

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

Bir sorunla ilgili notları kimler görüntüleyebilir, yazabilir ve silebilir?

Notlar, proje üyelerinin sorular, durum güncellemeleri vb. ile belirli sorunlar 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 veya Crashlytics Yöneticisi

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

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

Gerileme gösteren sorun nedir?

Daha önce kapattığınız bir sorunla ilgili olarak Crashlytics, sorunun tekrar ortaya çıktığına dair yeni bir rapor aldığında gerileme yaşanmış olur. Crashlytics, gerileme gösteren bu sorunları otomatik olarak yeniden açar. Böylece, uygulamanız için uygun şekilde ele alabilirsiniz.

Crashlytics'ın bir sorunu regresyon olarak nasıl kategorize ettiğini açıklayan örnek bir senaryoyu aşağıda bulabilirsiniz:

1. Crashlytics, "A" kilitlenmesiyle ilgili ilk kilitlenme raporunu alır. Crashlytics, bu kilitlenme için ilgili bir sorun (Sorun "A") açar.
2. Bu hatayı hızlıca düzeltip "A" sorununu kapatır ve uygulamanızın yeni bir sürümünü yayınlarsınız.
3. Crashlytics, siz sorunu kapattıktan sonra "A" sorunuyla ilgili başka bir rapor alır.
   • Rapor, sorunu kapattığınızda Crashlytics tarafından bilinen bir uygulama sürümünden geliyorsa (yani sürüm, herhangi bir kilitlenme için kilitlenme raporu göndermişse) Crashlytics, sorunu gerileme olarak değerlendirmez. Sorun kapalı kalır.
   • Rapor, sorunu kapattığınızda Crashlytics tarafından bilinmeyen (yani sürümün herhangi bir kilitlenme için hiçbir kilitlenme raporu göndermediği) bir uygulama sürümünden geliyorsa Crashlytics, sorunun gerilediğini düşünür ve sorunu yeniden açar.

Bir sorun gerilediğinde gerileme algılama uyarısı gönderir ve soruna bir gerileme sinyali ekleriz. Böylece Crashlytics tarafından sorunun yeniden açıldığını öğrenirsiniz. Bir sorunun regresyon algoritmamız nedeniyle yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "kapatın".

Neden eski uygulama sürümleri için gerileme gösteren sorunlar görüyorum?

Rapor, sorunu kapattığınızda hiç kilitlenme raporu göndermemiş eski bir uygulama sürümünden geliyorsa Crashlytics, sorunun gerilediğini kabul eder ve sorunu yeniden açar.

Bu durum, bir hatayı düzeltip uygulamanızın yeni bir sürümünü yayınlamanıza rağmen hâlâ hata düzeltmesi yapılmamış eski sürümleri kullanan kullanıcılarınız olduğunda ortaya çıkabilir. Siz sorunu kapattığınızda bu eski sürümlerden biri hiç kilitlenme raporu göndermemişse ve bu kullanıcılar hatayla karşılaşmaya başlarsa bu kilitlenme raporları, gerileme sorunu tetikler.

Bir sorunun regresyon algoritmamız nedeniyle yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "kapatı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 zamanı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'i başlatma bölümünü okuyun). Projenizi güncelledikten sonra bir kilitlenmeyi zorunlu kılı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'leri doğru şekilde ürettiğinden emin olun.

3. Xcode, dSYM'leri düzgün şekilde üretiyorsa ve hâlâ eksik dSYM'ler görüyorsanız çalıştırma komut dosyası aracı, dSYM'leri yüklerken takılıyor olabilir. Bu durumda, aşağıdakilerin her birini deneyin:

   • Crashlytics hizmetinin en yeni 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şivini yüklemek için dSYM'ler sekmesindeki konsol tabanlı "Sürükle ve Bırak" seçeneğini kullanın.
     • 2. seçenek: dSYM'ler 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 oluyorsa Firebase Destek Ekibi ile iletişime geçin ve günlüklerinizi eklediğinizden emin olun.

Kilitlenmeler kötü bir şekilde simgeselleştirilmiş

Yığın izlemeleriniz (stack trace) yeterince simgeselleştirilmemiş görünüyorsa aşağıdakileri kontrol edin:

• Uygulamanızın kitaplığındaki karelerde uygulamanızın koduna referans yoksa -fomit-frame-pointer değerinin derleme işareti olarak ayarlanmadığından emin olun.

• Uygulamanızın kitaplığı için birkaç (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'leri yüklemenin zaten gerçekleşmiş kilitlenmeleri simgeselleştirmeyeceğini, ancak gelecekteki kilitlenmelerin simgeselleştirilmesini sağlayacağını unutmayın.

Crashlytics'i macOS veya tvOS için kullanabilir miyim?

Evet, macOS ve tvOS projelerinde Crashlytics uygulayabilirsiniz. Google Analytics için Firebase SDK'sının 8.9.0 veya sonraki bir sürümünü eklediğinizden emin olun. Böylece kilitlenmeler, Google Analytics tarafından toplanan metriklere (kilitlenme yaşamayan kullanıcılar, en son sürüm, hız uyarıları ve breadcrumb kayıtları) erişebilir.

Crashlytics'i farklı Apple platformlarında birden fazla uygulama içeren bir Firebase projesinde kullanabilir miyim?

Artık farklı Apple platformları (ör. iOS, tvOS ve Mac Catalyst) için geliştirilmiş olsalar bile tek bir Firebase projesindeki birden fazla uygulamayla ilgili kilitlenme raporları oluşturabilirsiniz. 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ümler için raporlanıyor?

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ümlerin yüklü olduğu cihazlarda kullanılabilir.

Bazı ANR'lerde neden BuildId yok?

ANR'lerinizden bazılarında BuildId yoksa aşağıdaki adımları uygulayarak sorunu 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 muhtemelen eski bir SDK, Gradle eklentisi veya her ikisini birden kullanıyorsunuzdur. Bu ANR'ler için BuildId'leri doğru şekilde toplamak istiyorsanız aşağıdaki sürümleri kullanmanız gerekir:

  • Crashlytics Android SDK'sı 18.3.5 ve sonraki sürümler (Firebase BoM 31.2.2 ve sonraki sürümler)
  • Crashlytics Gradle eklentisi 2.9.4 ve sonraki sürümler

• 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ında yalnızca BuildId eksikse paylaşılan kitaplıklar için standart, varsayılan konumu kullanmıyor olabilirsiniz. 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 öğelerini 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 programlarınızda readelf -n komutunu çalıştırarak BuildId olup olmadığını kontrol edin. BuildId yoksa derleme sisteminizin işaretlerine -Wl,--build-id ekleyin.

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

  • Bir kitaplığın hem ayıklanmış hem de ayıklanmamış sürümlerini saklıyorsanız kodunuzda doğru sürümü belirttiğinizden emin olun.

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

Google Play ile Crashlytics arasında ANR sayısında uyuşmazlık olabilir. ANR verilerini toplama ve raporlama mekanizmasındaki farklılık nedeniyle bu beklenen bir durumdur. Crashlytics, uygulama bir sonraki başlatıldığında ANR'leri bildirirken Android vitals, ANR oluştuktan sonra ANR verilerini gönderir.

Ayrıca Crashlytics, yalnızca Android 11 ve sonraki sürümleri çalıştıran cihazlarda gerçekleşen ANR'leri gösterir. Google Play ise Google Play Hizmetleri'nin yüklü olduğu ve veri toplama izni verilen cihazlardaki ANR'leri gösterir.

Neden .java sorunları olarak etiketlenmiş .kt dosyalarından kaynaklanan kilitlenmeler görüyorum?

Bir uygulama, dosya uzantısını göstermeyen bir kod karartıcı kullandığında Crashlytics, her sorunu varsayılan olarak .java dosya uzantısıyla oluşturur.

Crashlytics uygulamasının doğru dosya uzantısıyla sorun 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ü kullanma
• Kod karartma etkinleştirilmiş şekilde R8 kullanır. Uygulamanızı R8'e güncellemek için bu dokümanı inceleyin.

Yukarıda açıklanan kuruluma geçtikten sonra, mevcut .java sorunlarının kopyası olan yeni .kt sorunları görmeye başlayabileceğinizi unutmayın. Bu durum hakkında daha fazla bilgi edinmek için SSS bölümüne bakın.

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

Aralık 2021'in ortasından itibaren Crashlytics, Kotlin kullanan uygulamalar için daha iyi destek sunmaya başladı.

Yakın zamana kadar, mevcut gizleyiciler 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, uygulamada kullanılan her sınıfın Kotlin'de yazılıp yazılmadığını belirleyebilir ve sorun imzasına doğru dosya adını ekleyebilir. Uygulamanızda aşağıdaki kurulum varsa kilitlenmeler artık .kt dosyalarıyla doğru şekilde ilişkilendirilir (uygun şekilde):

• Uygulamanız Android Gradle 4.2.0 veya sonraki bir sürümü kullanıyor.
• Uygulamanız, kod karartma özelliği etkinleştirilmiş R8'i kullanıyor.

Yeni kilitlenmeler artık sorun imzalarında doğru dosya uzantısını içerdiğinden, aslında mevcut .java etiketli sorunların kopyası olan yeni .kt sorunları görebilirsiniz. Firebase konsolunda, yeni bir .kt sorununun mevcut bir .java etiketli sorunun kopyası olup olmadığını belirlemeye ve size bildirmeye çalışırız.

Dexguard ile kilitlenme almıyorum

Aşağıdaki istisnayı görüyorsanız muhtemelen DexGuard'ın Firebase Crashlytics SDK ile uyumlu olmayan bir sürümünü 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. DexGuard 8.x'in en son sürümünü kullandığınızdan emin olun. En yeni sürüm, Firebase Crashlytics SDK'sının gerektirdiği kuralları içerir.

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

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

Crashlytics Gradle eklentisi 3. sürüme nasıl yükseltilir?

Crashlytics Gradle eklentisinin en son sürümü, ana sürümdür (v3.0.0) ve Gradle ile Android Gradle eklentisinin daha eski sürümlerine yönelik desteği sonlandırarak SDK'yı modernize eder. Ayrıca bu sürümdeki değişiklikler, AGP 8.1 ve sonraki sürümlerle ilgili sorunları çözer ve yerel uygulamalar ile özelleştirilmiş derlemeler için desteği iyileştirir.

Minimum koşullar

Crashlytics Gradle eklentisi 3. sürümünün minimum gereksinimleri şunlardır:

• Android Gradle eklentisi 8.1 ve sonraki sürümler
  Android Studio'nun en yeni sürümünde Android Gradle eklentisi Yükseltme Asistanı'nı kullanarak bu eklentiyi yükseltin.

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

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ı aşağıdaki zarar veren değişiklikleri içerir:

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

• 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 fazla dizin içeren bir örnek 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 dizinindeki sembolleri yüklerken uploadCrashlyticsSymbolFilesFeatureXRelease görevi hem MY/NATIVE/LIBS hem de MY/FEATURE_X/LIBS dizinindeki 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 program 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 NDK yığın izlemeleri ile logcat arasındaki farklar

LLVM ve GNU araç zincirleri, uygulamanızın ikili dosyalarının salt okunur segmenti için farklı varsayılanlara ve işlemlere sahiptir. Bu durum, Firebase Console'da tutarsız yığın izlemelerine (stack trace) neden olabilir. 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ısını kullanıyorsanız şunu ekleyin:

  -Wl,--rosegment

Yığın izleme tutarsızlıkları görmeye devam ediyorsanız (veya her iki işaret de araç zincirinizle alakalı değilse) derleme işleminize aşağıdakileri eklemeyi deneyin:

-fno-omit-frame-pointer

NDK için kendi Breakpad sembol dosyası üretme ikili programımı nasıl kullanırım?

Crashlytics eklentisi, özelleştirilmiş bir Breakpad sembol dosyası üretici 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 derlemeyi 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: build.gradle dosyanızdaki firebaseCrashlytics uzantısı aracılığıyla yolu belirtin.

  Uygulama düzeyindeki build.gradle.kts dosyanıza aşağıdakileri ekleyin:

  Gradle eklentisi 3.0.0 ve sonraki sürümler

  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 eski 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 özellikler 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 özellik 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 itibarıyla kaldırılmıştır.

Crashlytics kontrol panelinde Android uygulamaları için sembolize edilmemiş yığın izlemeler (stack trace) görme

Unity IL2CPP kullanıyorsanız ve sembolik olmayan yığın izlemeler görüyorsanız aşağıdakileri deneyin:

1. Crashlytics Unity SDK'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 ve bu komut için gerekli ayarları yaptığınızdan emin olun.

   Firebase konsolunda sembolik yığın izlemelerini görmek istediğiniz her yayınlanan derleme veya başka bir derleme oluşturduğunuzda bu CLI komutunu çalıştırmanız gerekir. Okunabilir kilitlenme raporları alma başlıklı makaleden daha fazla bilgi edinebilirsiniz.

Crashlytics, IL2CPP kullanan uygulamalarla kullanılabilir mi?

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

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ı için Firebase Unity Editor eklentisi, Xcode projenizi sembolleri yükleyecek şekilde otomatik olarak yapılandırır.

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

     Firebase konsolunda sembolik yığın izlemelerini görmek istediğiniz her yayınlanan derleme veya başka bir derleme oluşturduğunuzda bu CLI komutunu çalıştırmanız gerekir. Okunabilir kilitlenme raporları alma bölümünden daha fazla bilgi edinebilirsiniz.

Bir uygulama, yakalanmayan istisnaları neden önemli hata olarak bildirmelidir?

Yakalanmayan istisnaları önemli olarak raporlayarak, uygulama çalışmaya devam etse bile hangi istisnaların oyunun oynanamaz hale gelmesine neden olabileceğine dair daha gerçekçi bir gösterge elde edersiniz.

Ölümcül hataları raporlamaya başlarsanız kilitlenme sorunu yaşamayan kullanıcı (CFU) yüzdeniz muhtemelen düşer ancak CFU metriği, son kullanıcıların uygulamanızla ilgili deneyimlerini daha iyi yansıtır.

Hangi özel durumlar önemli olarak raporlanacak?

Crashlytics uygulamasının yakalanmayan bir istisnayı önemli 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 atılmayan bir istisna, yakalanmamış olarak kabul edilmez.

Yakalanmayan istisnaların önemli hata olarak raporlanmasını etkinleştirdikten sonra birçok yeni önemli hata görüyorum. Bu istisnaları nasıl doğru şekilde ele alabilirim?

Yakalanmayan istisnalarınızın önemli hata olarak raporlanmaya başlamasıyla birlikte, bu yakalanmayan istisnaları ele almak için kullanabileceğiniz bazı seçenekler şunlardır:

• Bu yakalanmayan istisnaları nasıl yakalayıp ele alabileceğinizi düşünün.
• Unity hata ayıklama konsoluna ve Crashlytics'e istisnaları kaydetmek için farklı seçenekleri değerlendirin.

Oluşan istisnaları yakalama ve işleme

İstisnalar, beklenmedik veya istisnai durumları yansıtmak için oluşturulur ve kullanılır. Oluşan bir istisnanın yansıttığı sorunları çözmek, programı bilinen bir duruma döndürmeyi içerir (bu işlem istisna işleme olarak bilinir).

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 bir try-catch bloğuna sarmalayın. Belirli istisnaları uygun şekilde ele almak için catch ifadelerindeki koşulların mümkün olduğunca dar kapsamlı olduğundan emin olun.

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

Unity veya Crashlytics'da istisnaları kaydetmenin birden fazla yolu vardır. Bu yöntemler, sorunu gidermenize yardımcı olur.

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 hizmetine 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 platformuna 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.
  • Bir istisna yakalanıp işlenmesine rağmen Crashlytics platformuna bildirilmesi gerekiyorsa ölümcül olmayan bir etkinlik olarak günlüğe kaydetmek için Crashlytics.LogException(exception) kullanın.

Ancak Unity Cloud Diagnostics'e önemli bir etkinliği manuel olarak bildirmek isterseniz Debug.LogException yöntemini kullanabilirsiniz. Bu seçenek, 1. seçenekte olduğu gibi istisnayı Unity konsoluna yazdırır ancak istisnayı da oluşturur (oluşturulmuş veya yakalanmış olup olmadığına bakılmaksızın). Hatayı yerel olmayan bir şekilde verir. Bu, try-catch blokları içeren bir Debug.LogException(exception) ifadesinin bile yakalanmamış bir istisnaya neden olacağı anlamına gelir.

Bu nedenle, Debug.LogException yöntemini 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 platformuna önemli bir etkinlik olarak yüklemek için.
• İstisnayı oluşturmak için yakalanmamış bir istisna olarak değerlendirilmesini ve Unity Cloud Diagnostics'e bildirilmesini sağlayın.

Yakalanan bir istisnayı Unity konsoluna yazdırmak ve önemli olmayan bir etkinlik olarak Crashlytics hizmetine 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 yaşamıyor

Projeniz Google Mobile Ads SDK'sı ile birlikte Crashlytics kullanıyorsa kilitlenme raporlayıcılar, istisna işleyicileri kaydederken büyük olasılıkla müdahale ediyordur. Sorunu düzeltmek için disableSDKCrashReporting yöntemini çağırarak Mobile Ads SDK'sında kilitlenme raporlamayı devre dışı bırakın.

BigQuery veri kümem nerede?

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 verileri dışa aktarma için etkinleştirilmişse) için geçerlidir.

• Bu konum yalnızca BigQuery hizmetine 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 farklı bir konumda 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 geçtikten sonra sorun mu yaşıyorsunuz?

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

Tüm Firebase projeleri, 2 Mart 2026 itibarıyla otomatik olarak yeni toplu dışa aktarma altyapısına 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 konumunu destekler.

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

  • Dışa aktarma işlemi Ekim 2024'ün ortalarında veya daha sonra etkinleştirildiyse: Kurulum sırasında veri dışa aktarma için bir konum seçmeniz istenmiştir.

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

  • Eski altyapı, dışa aktarma işlemini etkinleştirdiğiniz tarihten 30 gün öncesine kadar olan verilerin doldurulmasını destekliyordu.

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

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

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

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

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

Eski toplu tablo 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 verilerinizde daha fazla kesinti olmaması için aşağıdaki 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 tablolarına nasıl yazdığı aşağıda açıklanmıştır:

• Eski dışa aktarma altyapısı: Verileri, uygulamanızın ikili programındaki paket kimliğine veya paket adına göre adlandırılmış bir tabloya yazıyordu.

• Yeni dışa aktarma altyapısı: Verileri, Firebase projenizdeki kayıtlı Firebase uygulamanız için ayarlanan paket kimliğine veya paket adına dayalı bir ada sahip 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ı girilmediğinde ortaya çıkar.

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

Bu iki konumdaki tanımlayıcılar eşleşmiyorsa aşağıdaki durumlar söz konusudur:

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

• Uygulamanızın ikili programındaki tanımlayıcıya dayalı bir ada sahip mevcut "eski" tablolara artık veri yazılmaz.

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

BigQuery toplu işlem tablosu adlarının, uygulamanın platformunu belirtmek için otomatik olarak _IOS veya _ANDROID ile eklendiğini unutmayın.

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

^{** Uygulamanızın ikili programındaki tanımlayıcılardan biri Firebase uygulaması için ayarlanan tanımlayıcıyla eşleştiyse yeni dışa aktarma altyapısı yeni bir tablo oluşturmamıştır. Bunun yerine, bu tabloyu korur ve tüm uygulamaların verilerini bu 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 kopyalayacaksınız.

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

  2. Toplu işlem tablonuza bağlı olan alt bağımlılıkları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ındaki 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ği'ni (örneğin, 1:1234567890:ios:321abc456def7890) bulup not edin:
     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ükseltmesi tarafından 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 platformunda 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, bağlı her Firebase uygulamasının yazdığı toplu tablonun adı için client_namespace değerini kullanır.

     5. Varsayılan ayarlarını 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 verilerin eksik olduğu günler için geri doldurma planlayın.

  4. Geriye dönük doldurma işlemi tamamlandıktan sonra, yeni dışa aktarma altyapısı tarafından otomatik olarak oluşturulan yeni tabloyu silin.