Bu sayfada, Crashlytics kullanımıyla ilgili sorun giderme yardımı ve sık sorulan soruların yanıtları yer almaktadır. Aradığınızı bulamıyorsanız veya daha fazla yardıma ihtiyacınız varsa Firebase Destek Ekibi ile iletişime geçin.
Bu sayfada, aşağıdaki konu türleri hakkında bilgi bulabilirsiniz:
Firebase konsolunda verilerin gösterilmesi veya verilerle çalışma ile ilgili sorular ve gerileyen sorunlarla ilgili sorular dahil olmak üzere genel sorun giderme.
Apple platformları, Android, Web ve Unity'ye özel sorular da dahil olmak üzere platforma özel destek.
Entegrasyon desteği (BigQuery ile ilgili sorular dahil)
Genel sorun giderme/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. 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ıza göz atın. Öne çıkan noktaları aşağıda okuyabilirsiniz.
Crashlytics, uygulamanızdaki tüm etkinlikleri (kilitlenmeler, önemli olmayan hatalar ve ANR'ler gibi) analiz eder ve sorunlar 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:
Crashlytics uyarıları alınmıyor (izinler)
Crashlytics uyarılarını almak veya yapılandırmak için proje üyelerinin gerekli IAM izinlerine sahip olması gerekir. Uyarı ayarlarını yönetebilir ve hesabınızın uyarı tercihlerini Firebase konsolunda
Aşağıdaki tabloda, gerekli izinler ve varsayılan olarak bu izinleri içeren önceden tanımlanmış roller listelenmiştir:
| Özellik | Uyarı almak için gerekli izin | Varsayılan olarak gerekli izni içeren roller |
|---|---|---|
| Crashlytics - Mobil uygulama uyarıları | firebase.projects.update |
|
| Crashlytics - Web uygulaması uyarıları |
|
Uyarıları yapılandırma hakkında daha fazla bilgi için Crashlytics uyarılarını yapılandırma ve alma başlıklı makaleyi inceleyin. IAM rolleri ve izinleri hakkında daha fazla bilgi için Firebase'de izinler ve erişim başlıklı makaleyi inceleyin.
Kilitlenme yaşanmayan oturum metriklerini görememe (veya güvenilir olmayan metrikler görme)
Kilitlenme yaşanmayan metrikleri (ör. kilitlenme yaşanmayan kullanıcılar ve oturumlar) 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 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. Crashlytics yalnızca bu kullanıcıların kilitlenme bilgilerine sahip olduğundan (tüm kullanıcılarınızın değil) kilitlenme yaşanmayan oturum metriklerinin 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ınan raporları Crashlytics hizmetine göndermek için
sendUnsentReportskullanabilirsiniz. Bu yöntem kullanıldığında Crashlytics hizmetine kilitlenme verileri gönderilir ancak oturum verileri gönderilmez. Bu nedenle, konsol grafiklerinde kilitlenme içermeyen metrikler için düşük değerler veya sıfır değerleri gösterilir.
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 Hesabı e-posta adresleriyle 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.
Aşağıdaki rollerden herhangi birine sahip proje üyeleri, bir sorunla ilgili yayınlanan notları görüntüleyebilir ancak not silemez veya yazamaz.
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şanır. Crashlytics, bu gerileme sorunlarını otomatik olarak yeniden açar. Böylece, uygulamanız için uygun şekilde bu sorunları ele alabilirsiniz.
Crashlytics'ın bir sorunu regresyon olarak nasıl kategorize ettiğini açıklayan örnek bir senaryoyu aşağıda bulabilirsiniz:
- Crashlytics, "A" kilitlenmesiyle ilgili ilk kilitlenme raporunu alır. Crashlytics, bu kilitlenme için ilgili bir sorun (Sorun "A") açar.
- 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.
- 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 gerilemiş olarak kabul etmez. Sorun kapalı kalır.
- Rapor, sorunu kapattığınızda Crashlytics tarafından bilinmeyen (yani sürümün herhangi bir kilitlenme için hiç kilitlenme raporu göndermediği) bir uygulama sürümünden geliyorsa Crashlytics, sorunun tekrarladığını kabul eder ve sorunu yeniden açar.
Bir sorun gerilediğinde gerileme algılama uyarısı gönderir ve soruna bir gerileme sinyali ekleyerek Crashlytics tarafından sorunun yeniden açıldığını bildiririz. Bir sorunun gerileme 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?
Bir rapor, siz 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 şu koşullarda ortaya çıkabilir: Bir hatayı düzeltip uygulamanızın yeni bir sürümünü yayınladınız ancak hâlâ hata düzeltmesi yapılmamış önceki sürümleri kullanan kullanıcılarınız var. Şans eseri, siz sorunu kapattığınızda bu önceki 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 gösteren bir sorunu tetikler.
Bir sorunun regresyon algoritmamız nedeniyle yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "kapatın".
Platforma özgü destek
Aşağıdaki bölümlerde platforma özel sorun giderme ve SSS için destek sağlanmaktadır: iOS+ | Android | Web | Unity.
Apple platformları desteği
dSYM'ler eksik/yüklenmiyor
Projenizin dSYM'lerini yüklemek ve ayrıntılı çıkış almak için aşağıdakileri kontrol edin:
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'i başlatma başlıklı makaleyi okuyun). Projenizi güncelledikten sonra bir kilitlenme tetikleyin ve kilitlenmenin Crashlytics kontrol panelinde göründüğünü doğrulayın.
Firebase konsolunda "Eksik dSYM" uyarısı görürseniz derleme için dSYM'leri doğru şekilde ürettiğinden emin olmak üzere Xcode'u kontrol edin.
Xcode, dSYM'leri doğru ş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-symbolskomut dosyasını kullanın.
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 yeterince simgeselleştirilmemiş
Yığın izlemelerinizde sembolleştirme işlemi düzgün yapılmamış gibi görünüyorsa aşağıdakileri kontrol edin:
Uygulamanızın kitaplığındaki karelerde uygulamanızın koduna referans yoksa
değerinin derleme işareti olarak ayarlanmadığından emin olun.-fomit-frame-pointerUygulamanızın kitaplığı için birkaç
(Missing)karesi görüyorsanız Firebase konsolunun Crashlytics dSYM'ler sekmesinde eksik olarak listelenen isteğe bağlı dSYM'ler (etkilenen uygulama sürümü için) 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 daha önce 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 v8.9.0 ve sonraki sürümlerini 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 uygulamanın kilitlenme sorunlarını bildirebilirsiniz. Daha önce, aynı paket kimliğini içeren uygulamaları ayrı Firebase projelerine ayırmanız gerekiyordu.
Android desteği
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
BuildIdeksikse muhtemelen eski bir SDK, Gradle eklentisi veya her ikisini birden kullanıyorsunuzdur. Bu ANR'ler içinBuildIdöğelerini 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
BuildIdeksikse paylaşılan kitaplıklar için standart, varsayılan konumu kullanmıyor olabilirsiniz. Bu durumda Crashlytics, ilişkiliBuildIdöğelerini bulamayabilir. Paylaşılan kitaplıklar için standart konumu kullanmanızı öneririz.Derleme işlemi sırasında
BuildIds'yi 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 -nkomutunu çalıştırarakBuildIdolup olmadığını kontrol edin.BuildIdyoksa derleme sisteminizin işaretlerine-Wl,--build-idekleyin.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üme işaret ettiğ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 verilerini ANR gerçekleştikten sonra 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 izninin kabul edildiği 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ına sahip sayılar 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ü kullanmalıdır.
- Kod karartma etkinleştirilmiş şekilde R8 kullanır. Uygulamanızı R8'e güncellemek için bu belgeyi inceleyin.
Yukarıda açıklanan kuruluma geçtikten 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 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 sürümünden itibaren R8, dosya uzantılarını destekler.
Bu güncellemeyle birlikte Crashlytics, artık 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:
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.
DexGuard sürümünüzü değiştirmek istemiyorsanız kod 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 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+
Android Studio'nun en yeni sürümündeki Android Gradle eklentisi Yükseltme Asistanı'nı kullanarak bu eklentiyi yükseltin.Firebase'in
google-servicesGradle eklentisi 4.4.1+
Projenizin Gradle derleme dosyasında en yeni sürümü belirterek bu eklentiyi yükseltin. Örneğin:
Kotlin
plugins { id("com.android.application") version "8.1.4" apply false id("com.google.gms.google-services") version "4.5.0" apply false ... }
Groovy
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ı,
defaultConfigAndroid engelleme listesinden kaldırıldı. Bunun yerine her varyantı yapılandırmanız gerekir.Desteği sonlandırılan
mappingFilealanı kaldırıldı. Bunun yerine, birleştirilmiş eşleme dosyası artık otomatik olarak sağlanır.Desteği sonlandırılan
strippedNativeLibsDiralanı kaldırıldı. Bunun yerine tüm yerel kitaplıklar içinunstrippedNativeLibsDirkullanmanız gerekir.unstrippedNativeLibsDiralanı kümülatif olacak şekilde değiştirildi.Birden fazla dizin içeren bir örnek görüntüleyin
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") } } } }
görevi yalnızcauploadCrashlyticsSymbolFilesBasicReleaseMY/NATIVE/LIBSdizinindeki sembolleri yüklerken görevi hemuploadCrashlyticsSymbolFilesFeatureXReleaseMY/NATIVE/LIBShem deMY/FEATURE_X/LIBSdizinindeki sembolleri yükler.Kapanış alanı
symbolGenerator, iki yeni üst düzey alanla değiştirildi:symbolGeneratorType,"breakpad"(varsayılan) veya"csym"dizesi.breakpadBinary, yerel birdump_symsikili program geçersiz kılma dosyası.
Uzantıyı yükseltme örneği
Kotlin
| Önce |
buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGenerator( closureOf<SymbolGenerator> { symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } ) } } } |
| Şimdi v3'te |
buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } |
Groovy
| Önce |
buildTypes { release { firebaseCrashlytics { // ... symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } } |
| Şimdi v3'te |
buildTypes { release { firebaseCrashlytics { // ... symbolGeneratorType "breakpad" breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } |
Android-NDK'ya özel destek
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
lldbağlayıcısını kullanıyorsanız şunları ekleyin:-Wl,--no-rosegmentGNU araç zincirindeki
ld.goldbağ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-pointerNDK 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.gradledosyanızdakifirebaseCrashlyticsuzantısı aracılığıyla yolu belirtin.Uygulama düzeyindeki
build.gradle.ktsdosyanı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 ö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ılmıştır.
Web desteği
Component crashlytics has not been registered yet hatası görünüyor
@firebase/crashlytics paketini kullanırken içe aktarma işlemlerinizde modüler ad alanlarını karıştırmayın. @firebase/crashlytics kaynağından getCrashlytics içe aktarılırken firebase/app kaynağından initializeApp içe aktarılması, paketleyicilerin iki ayrı dahili kayıt defteri yüklemesine neden olur. Bu da Component crashlytics has not been registered yet gibi hatalara yol açar.
Çift paket kayıt defteri çakışmalarını şu şekilde önleyebilirsiniz:
Projenizdeki tüm Firebase içe aktarma işlemlerini, kapsamlı
@firebase/ad alanını (ör.@firebase/appve@firebase/crashlytics) kullanacak şekilde standartlaştırın.Uygulamanız Vite kullanıyorsa
vite.config.tsdosyanızda@firebase/appöğesini açıkça tekilleştirin:// vite.config.ts import { defineConfig } from 'vite'; export default defineConfig({ resolve: { dedupe: ['@firebase/app'] } });
verbatimModuleSyntax etkinleştirildiğinde TypeScript derleme hatası
Modern TypeScript yapılandırmaları (ör. Vite ve Angular şablonları) genellikle tsconfig.json içinde "verbatimModuleSyntax": true seçeneğini etkinleştirir. Bu işaret etkinleştirildiğinde, standart bir değer içe aktarma işlemi kullanılarak TypeScript arayüzü içe aktarılırsa derleme hatası oluşur.
FirebaseApp veya Crashlytics gibi TypeScript arayüzlerini içe aktarırken açık type içe aktarma işlemlerini kullanın:
import { initializeApp, type FirebaseApp } from '@firebase/app';
import { getCrashlytics, type Crashlytics } from '@firebase/crashlytics';
Unity desteği
Crashlytics kontrol panelinde Android uygulamaları için sembolize edilmemiş yığın izlemeler (stack trace) görme
Unity IL2CPP kullanıyorsanız ve simgeleştirilmemiş yığın izlemeler görüyorsanız aşağıdakileri deneyin:
Crashlytics Unity SDK'sının 8.6.1 veya sonraki bir sürümünü kullandığınızdan emin olun.
Sembol dosyanızı oluşturup yüklemek için Firebase CLI
crashlytics:symbols:uploadkomutunu ç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 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:
Crashlytics Unity SDK'sının 8.6.0 veya daha yeni bir sürümünü kullandığınızdan emin olun.
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:uploadkomutunu çalıştıracak şekilde ayarlandığınızdan ve çalıştırdığı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.
Yakalanmayan istisnaları önemli hata olarak bildirme
Crashlytics, yakalanmayan istisnaları önemli hata olarak bildirebilir (Unity SDK'nın v10.4.0 sürümünden itibaren). Aşağıdaki SSS bölümünde, bu özelliğin kullanımına ilişkin gerekçeler ve en iyi uygulamalar açıklanmaktadır.
Bir uygulama, yakalanmayan istisnaları neden önemli hata olarak bildirmelidir?
Yakalanmayan istisnaları önemli hata olarak bildirerek, 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ı bildirmeye 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ğitrueolarak ayarlanmalıdır.Uygulamanız (veya dahil edilen bir kitaplık) yakalanmayan bir istisna oluşturuyor. Oluşturulan ancak oluşturulmayan bir istisna, yakalanmamış olarak kabul edilmez.
Yakalanmayan istisnaların önemli 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 (istisna işleme olarak bilinen bir işlem).
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
Sorunlarda hata ayıklamaya 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: Unity konsolunda yazdırın ancak geliştirme veya sorun giderme sırasında Crashlytics hizmetine bildirmeyin.
Debug.Log(exception),Debug.LogWarning(exception)veDebug.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. - Yakalanıp işlenmesine rağmen bir istisnanın Crashlytics hizmetine bildirilmesi gerekiyorsa ölümcül olmayan bir etkinlik olarak günlüğe kaydetmek için
Crashlytics.LogException(exception)kullanın.
- Bir istisna, olası bir sonraki Crashlytics etkinliğinde hata ayıklamak için günlüğe kaydedilmeye değerse
Ancak önemli bir etkinliği Unity Cloud Diagnostics'e 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). Hata yerel olmayan bir şekilde
oluşur. Bu, try-catch blokları içeren bir Debug.LogException(exception) bloğunun bile yakalanmamış bir istisnayla sonuçlanacağı 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 kullanılır.
- İ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 ölümcül 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
//
}
Entegrasyon desteği
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 konumuna 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 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 istendi.
Yeni altyapı, dışa aktarma işlemini 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 dolgu veya BigQuery için dışa aktarmayı etkinleştirdiğiniz en son tarih (hangisi daha yeniyse) için dolgu destekler.
Yeni altyapı, Firebase projenizdeki Firebase uygulamalarınız için ayarlanan tanımlayıcıları kullanarak BigQuery toplu tablolarını 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ı, Firebase projenizdeki kayıtlı Firebase uygulamalarınız için ayarlanan paket kimliklerine veya paket adlarına göre adlandırılan toplu tablolara veri 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 projenizde 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 tabloya yazılır. Bu, Firebase projenizde 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ılar | Firebase uygulamalarınız için ayarlanan tanımlayıcılar | Eski davranış | Yeni dışa aktarma altyapısına geçişten sonraki davranış |
Çözüm |
|---|---|---|---|---|
foo |
bar |
Uygulamanın ikili programındaki (foo) tanımlayıcıya göre adlandırılan tek bir tabloya yazar.
|
Firebase uygulaması (bar) için ayarlanan tanımlayıcıya göre adlandırılan tek bir tablo oluşturur ve bu tabloya yazar.
|
Aşağıda açıklanan 1. veya 2. seçeneği uygulayın. |
foo |
bar, qux vb. |
Uygulamanın ikili programındaki (foo) tanımlayıcıya göre adlandırılan tek bir tabloya yazar.
|
Firebase Uygulamaları için ayarlanan tanımlayıcıların (bar, qux vb.) adını taşıyan birden fazla tablo oluşturur* ve bu tablolara yazar.
|
Aşağıda açıklanan 2. seçeneği uygulayın. |
foo, baz vb. |
bar |
Uygulamanın ikili programındaki birden fazla tanımlayıcıya (foo, baz vb.) göre adlandırılan birden fazla tabloya yazar.
|
Her uygulamanın verilerini oluşturur** ve Firebase uygulaması için ayarlanan tanımlayıcıya (bar) göre adlandırılan tek bir tabloya yazar.
|
Seçeneklerin hiçbiri uygulanamaz.
Verilerle birlikte dışa aktarılan uygulamanı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.Google Cloud konsolunda, eski tablonuzdaki tüm verileri altyapı yükseltmesi sırasında oluşturulan yeni tabloya kopyalayın.
Toplu iş 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. Bunun için BigQuery yapılandırmasındaki bazı varsayılanları geçersiz kılmanız gerekir.Firebase konsolunda, eşleşmeyen toplu işlem tablosu adı ve tanımlayıcısı olan uygulamanın Firebase Uygulama Kimliği'ni (ör.
1:1234567890:ios:321abc456def7890) bulun ve 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.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:
"Veri aktarımı yapılandırmanızı" görüntülemek için BigQuery > Veri aktarımları'na gidin.
Kaynağı içeren yapılandırmayı seçin
Firebase Crashlytics with Multi-Region Support.Sağ üst köşedeki Düzenle'yi tıklayın.
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_idolarak adlandırılır. Varsayılan olarak, BigQuery içindekiclient_namespacedeğ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_namespacedeğerini kullanır.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).
Yapılandırma değişikliğini kaydedin.
Eski tablonuzda verilerin eksik olduğu günler için geri doldurma planlayın.
Dolgu işlemi tamamlandıktan sonra, yeni dışa aktarma altyapısı tarafından otomatik olarak oluşturulan yeni tabloyu silin.