iOS+
Android
Flutter
Unity
หน้านี้ให้ความช่วยเหลือในการแก้ปัญหาและคำตอบสำหรับคำถามที่พบบ่อยเกี่ยวกับการใช้ Crashlytics หากไม่พบสิ่งที่ต้องการหรือต้องการความช่วยเหลือเพิ่มเติม โปรดติดต่อทีมสนับสนุน Firebase
การแก้ปัญหาทั่วไป/คำถามที่พบบ่อย
ไม่เห็นเมตริกและ/หรือการแจ้งเตือนเกี่ยวกับความเร็วที่ไม่มีข้อขัดข้อง
หากไม่เห็นเมตริกที่ไม่มีการขัดข้อง (เช่น ผู้ใช้และเซสชันที่ไม่มีการขัดข้อง) และ/หรือการแจ้งเตือนเกี่ยวกับความเร็ว ให้ตรวจสอบว่าคุณใช้
Crashlytics SDK v18.6.0 ขึ้นไป (หรือ Firebase BoM v32.6.0 ขึ้นไป)
ไม่เห็นบันทึกเบรดครัมบ์
หากไม่เห็นบันทึกเบรดครัมบ์ เราขอแนะนำให้ตรวจสอบการกําหนดค่าแอปเพื่อหา Google Analytics
โปรดตรวจสอบว่าคุณมีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้
เหตุใดจึงมีการรายงาน ANR สำหรับ Android 11 ขึ้นไปเท่านั้น
Crashlytics รองรับการรายงาน ANR สําหรับแอป Android จากอุปกรณ์ที่ใช้ Android 11 ขึ้นไป API พื้นฐานที่เราใช้รวบรวม ANR (getHistoricalProcessExitReasons ) มีความน่าเชื่อถือมากกว่าแนวทางที่ใช้ SIGQUIT หรือ Watchdog API นี้ใช้ได้ในอุปกรณ์ Android 11 ขึ้นไปเท่านั้น
Why are some ANRs missing
their BuildIds?
หาก ANR บางรายการไม่มี BuildId ให้แก้ปัญหาโดยทำดังนี้
ตรวจสอบว่าคุณใช้ Crashlytics Android SDK และCrashlytics ปลั๊กอิน Gradle เวอร์ชันล่าสุด
หากไม่มี BuildId สำหรับ ANR ของ Android 11 และ Android 12 บางรายการ แสดงว่าคุณอาจใช้ SDK, ปลั๊กอิน Gradle หรือทั้ง 2 อย่างเวอร์ชันล้าสมัย
หากต้องการรวบรวม BuildId สำหรับ ANR เหล่านี้อย่างถูกต้อง คุณต้องใช้เวอร์ชันต่อไปนี้
Crashlytics Android SDK v18.3.5 ขึ้นไป (Firebase BoM v31.2.2 ขึ้นไป)Crashlytics ปลั๊กอิน Gradle v2.9.4 ขึ้นไป ตรวจสอบว่าคุณไม่ได้ใช้ตำแหน่งที่ไม่ใช่มาตรฐานสำหรับไลบรารีที่ใช้ร่วมกัน
หากมีเพียงBuildIdสำหรับไลบรารีที่ใช้ร่วมกันของแอปเท่านั้นที่หายไป แสดงว่าคุณอาจไม่ได้ใช้ตำแหน่งเริ่มต้นมาตรฐานสำหรับไลบรารีที่ใช้ร่วมกัน ในกรณีนี้ Crashlytics อาจไม่พบ BuildId ที่เชื่อมโยง เราขอแนะนำให้คุณพิจารณาใช้ตำแหน่งมาตรฐานสำหรับคลังที่ใช้ร่วมกัน
ตรวจสอบว่าคุณไม่ได้ลบBuildIdออกในระหว่างกระบวนการสร้าง
โปรดทราบว่าเคล็ดลับการแก้ปัญหาต่อไปนี้ใช้ได้กับทั้ง ANR และการขัดข้องของเนทีฟ
ตรวจสอบว่ามี BuildId หรือไม่โดยเรียกใช้ readelf -n ในไบนารี หากไม่มี BuildId ให้เพิ่ม -Wl,--build-id ลงใน Flag สำหรับระบบการสร้าง
ตรวจสอบว่าคุณไม่ได้นำ BuildId ออกโดยไม่ตั้งใจเพื่อพยายามลดขนาด APK
หากคุณเก็บเวอร์ชันที่ลบและไม่ได้ลบข้อมูลออกจากไลบรารีไว้ ให้ตรวจสอบว่าได้ชี้ไปยังเวอร์ชันที่ถูกต้องในโค้ด
ความแตกต่างระหว่างรายงาน ANR ในCrashlytics หน้าแดชบอร์ดกับ Google Play Console
จำนวน ANR ระหว่าง Google Play กับ Crashlytics อาจไม่ตรงกัน ความไม่สอดคล้องนี้อาจเกิดขึ้นจากความแตกต่างของกลไกการเก็บรวบรวมและการรายงานข้อมูล ANR Crashlytics จะรายงาน ANR เมื่อแอปเริ่มทำงานครั้งถัดไป ส่วน Android Vitals จะส่งข้อมูล ANR หลังจากที่ ANR เกิดขึ้น
นอกจากนี้ Crashlytics จะแสดงเฉพาะ ANR ที่เกิดขึ้นในอุปกรณ์ที่ใช้ Android 11 ขึ้นไปเท่านั้น เมื่อเทียบกับ Google Play ที่แสดง ANR จากอุปกรณ์ที่มีบริการ Google Play และยอมรับความยินยอมให้เก็บรวบรวมข้อมูล
ความแตกต่างระหว่างสแต็กเทรซ NDK ในแดชบอร์ด Crashlytics กับ Logcat
เครื่องมือทางเทคนิค LLVM และ GNU มีค่าเริ่มต้นและการจัดการที่แตกต่างกันสำหรับส่วนที่อ่านอย่างเดียวของไบนารีของแอป ซึ่งอาจสร้างสแต็กเทรซที่ไม่สอดคล้องกันในคอนโซล Firebase หากต้องการลดปัญหานี้ ให้เพิ่ม Flag Linker ต่อไปนี้ลงในกระบวนการสร้าง
หากยังคงเห็นความไม่สอดคล้องของสแต็กเทรซ (หรือหากไม่มีแฟล็กใดที่เกี่ยวข้องกับเครื่องมือทํางานของคุณ) ให้ลองเพิ่มสิ่งต่อไปนี้ลงในกระบวนการสร้างแทน
-fno-omit-frame-pointer
ฉันจะใช้ไฟล์สัญลักษณ์ Breakpad Generator แบบไบนารีของฉันเองสําหรับ NDK ได้อย่างไร
ปลั๊กอิน Crashlytics จะรวมเครื่องมือสร้างไฟล์สัญลักษณ์ Breakpad ที่กําหนดเอง
หากต้องการใช้ไบนารีของคุณเองในการสร้างไฟล์สัญลักษณ์ Breakpad (เช่น หากต้องการสร้างไฟล์ปฏิบัติการแบบเนทีฟทั้งหมดในเชนการบิลด์จากซอร์สโค้ด) ให้ใช้แอตทริบิวต์ส่วนขยาย symbolGeneratorBinary (ไม่บังคับ) เพื่อระบุเส้นทางไปยังไฟล์ปฏิบัติการ
หมายเหตุ: ต้องใช้เครื่องมือสร้างไฟล์สัญลักษณ์ Breakpad เวอร์ชัน Linux สำหรับไบนารีของ Android คุณสามารถระบุเส้นทางไปยังไฟล์ไบนารีของเครื่องมือสร้างไฟล์สัญลักษณ์ Breakpad ได้ 2 วิธีดังนี้
ตัวเลือกที่ 1 : ระบุเส้นทางผ่านนามสกุล firebaseCrashlytics ในไฟล์ build.gradle
เพิ่มโค้ดต่อไปนี้ลงในไฟล์ build.gradle.kts ระดับแอป
ปลั๊กอิน Gradle 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 ")
}
}
}
}
เวอร์ชันปลั๊กอินที่ต่ำกว่า
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 : ระบุเส้นทางผ่านบรรทัดพร็อพเพอร์ตี้ในไฟล์ Gradle
properties
คุณสามารถใช้พร็อพเพอร์ตี้ com.google.firebase.crashlytics.breakpadBinary เพื่อระบุเส้นทางไปยังไฟล์ปฏิบัติการได้
คุณสามารถอัปเดตไฟล์พร็อพเพอร์ตี้ Gradle ด้วยตนเองหรืออัปเดตไฟล์ผ่านบรรทัดคำสั่งก็ได้ เช่น หากต้องการระบุเส้นทางผ่านบรรทัดคำสั่ง ให้ใช้คำสั่งต่อไปนี้
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
-Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
ไม่พบข้อขัดข้องเมื่อใช้ Dexguard
หากเห็นข้อยกเว้นต่อไปนี้ แสดงว่าคุณอาจใช้ DexGuard เวอร์ชันที่ใช้ร่วมกับ Firebase Crashlytics SDK ไม่ได้
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
ข้อยกเว้นนี้จะไม่ทำให้แอปขัดข้อง แต่จะป้องกันไม่ให้แอปส่งรายงานข้อขัดข้อง วิธีแก้ปัญหามีดังนี้
ตรวจสอบว่าคุณใช้ DexGuard 8.x เวอร์ชันล่าสุด เวอร์ชันล่าสุดมีกฎที่ SDK ของ Firebase Crashlytics กำหนด
หากไม่ต้องการเปลี่ยนเวอร์ชัน DexGuard ให้ลองเพิ่มบรรทัดต่อไปนี้ลงในกฎการสร้างความสับสน (ในไฟล์การกําหนดค่า DexGuard)
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
เหตุใดฉันจึงเห็นข้อขัดข้องจากไฟล์ .kt ที่ติดป้ายกำกับว่าเป็นปัญหา .java
เมื่อแอปใช้โปรแกรมสร้างความสับสนที่ไม่แสดงนามสกุลไฟล์ Crashlytics จะสร้างปัญหาแต่ละรายการที่มีนามสกุลไฟล์ .java โดยค่าเริ่มต้น
โปรดตรวจสอบว่าแอปของคุณใช้การตั้งค่าต่อไปนี้เพื่อให้ Crashlytics สร้างปัญหาที่มีนามสกุลไฟล์ที่ถูกต้อง
ใช้ Android Gradle 4.2.0 ขึ้นไป
ใช้ R8 โดยเปิดการสร้างความสับสน หากต้องการอัปเดตแอปเป็น R8 ให้ทําตามเอกสารประกอบ นี้
โปรดทราบว่าหลังจากอัปเดตเป็นการตั้งค่าที่อธิบายข้างต้น คุณอาจเริ่มเห็นปัญหา .kt ใหม่ซึ่งซ้ำกับปัญหา .java ที่มีอยู่ ดูข้อมูลเพิ่มเติมเกี่ยวกับสถานการณ์ดังกล่าวได้ในคำถามที่พบบ่อย
เหตุใดฉันจึงเห็นปัญหา .kt ที่ซ้ำกับปัญหา .java ที่มีอยู่
ตั้งแต่ช่วงกลางเดือนธันวาคม 2021 Crashlytics ได้ปรับปรุงการรองรับแอปพลิเคชันที่ใช้ Kotlin
จนกระทั่งเมื่อไม่นานมานี้ โปรแกรมสร้างความสับสนที่ใช้ได้ไม่ได้แสดงนามสกุลไฟล์ ดังนั้น Crashlytics จึงสร้างแต่ละปัญหาที่มีนามสกุลไฟล์ .java โดยค่าเริ่มต้น
อย่างไรก็ตาม ตั้งแต่ Android Gradle 4.2.0 เป็นต้นไป R8 รองรับนามสกุลไฟล์
การอัปเดตนี้จะช่วยให้ Crashlytics ระบุได้ว่าคลาสแต่ละคลาสที่ใช้ภายในแอปเขียนด้วย Kotlin หรือไม่ และใส่ชื่อไฟล์ที่ถูกต้องในลายเซ็นปัญหา ตอนนี้ระบบจะระบุแหล่งที่มาของข้อขัดข้องไปยังไฟล์ .kt (ตามความเหมาะสม) อย่างถูกต้องแล้วหากแอปของคุณมีการตั้งค่าต่อไปนี้
แอปของคุณใช้ Android Gradle 4.2.0 ขึ้นไป
แอปของคุณใช้ R8 โดยเปิดการสร้างความสับสน
เนื่องจากตอนนี้ข้อขัดข้องใหม่จะมีนามสกุลไฟล์ที่ถูกต้องในลายเซ็นปัญหา คุณจึงอาจเห็นปัญหา .kt ใหม่ซึ่งจริงๆ แล้วเป็นปัญหาที่มีป้ายกำกับ .java อยู่แล้วซ้ำกัน ในคอนโซล Firebase เราจะพยายามระบุและแจ้งให้คุณทราบหากปัญหา .kt ใหม่อาจซ้ำกับปัญหาที่มีป้ายกำกับ .java อยู่แล้ว
ใครดู เขียน และลบหมายเหตุเกี่ยวกับปัญหาได้บ้าง
หมายเหตุช่วยให้สมาชิกโปรเจ็กต์แสดงความคิดเห็นเกี่ยวกับปัญหาที่เฉพาะเจาะจงได้ พร้อมคำถาม สถานะ การอัปเดต ฯลฯ
เมื่อสมาชิกในโปรเจ็กต์โพสต์โน้ต ระบบจะติดป้ายกำกับโน้ตด้วยอีเมลของบัญชี Google อีเมลนี้และโน้ตจะแสดงให้สมาชิกโปรเจ็กต์ทุกคนที่มีสิทธิ์ดูโน้ตเห็น
สิทธิ์เข้าถึงที่จําเป็นในการดู เขียน และลบโน้ตมีดังนี้
ใครดู เขียน และลบหมายเหตุเกี่ยวกับปัญหาได้บ้าง
หมายเหตุช่วยให้สมาชิกโปรเจ็กต์แสดงความคิดเห็นเกี่ยวกับปัญหาที่เฉพาะเจาะจงได้ พร้อมคำถาม สถานะ การอัปเดต ฯลฯ
เมื่อสมาชิกในโปรเจ็กต์โพสต์โน้ต ระบบจะติดป้ายกำกับโน้ตด้วยอีเมลของบัญชี Google อีเมลนี้และโน้ตจะแสดงให้สมาชิกโปรเจ็กต์ทุกคนที่มีสิทธิ์ดูโน้ตเห็น
สิทธิ์เข้าถึงที่จําเป็นในการดู เขียน และลบโน้ตมีดังนี้
การผสานรวม
แอปใช้ Google Mobile Ads SDK ด้วย แต่ไม่มีการขัดข้อง
หากโปรเจ็กต์ใช้ Crashlytics ร่วมกับ SDK ของ Google Mobile Ads ก็มีความเป็นไปได้ว่าเครื่องมือรายงานข้อขัดข้องจะรบกวนเมื่อลงทะเบียนตัวแฮนเดิลข้อยกเว้น หากต้องการแก้ไขปัญหา ให้ปิดการรายงานข้อขัดข้องใน Mobile Ads SDK โดยเรียกใช้ disableSDKCrashReporting
ชุดข้อมูล BigQuery ของฉันอยู่ที่ไหน
หลังจากลิงก์ Crashlytics กับ BigQuery แล้ว ชุดข้อมูลใหม่ที่สร้างขึ้นจะอยู่ในสหรัฐอเมริกาโดยอัตโนมัติ ไม่ว่าโปรเจ็กต์ Firebase จะอยู่ที่ไหนก็ตาม
Crashlytics รองรับ armeabi ไหม
Firebase Crashlytics NDK ไม่รองรับ ARMv5 (armeabi)
การรองรับ ABI นี้ถูกนําออกแล้วใน NDK r17
ปัญหาเดิม
ปัญหาที่ลดลงคืออะไร
ปัญหากลับมาเกิดขึ้นอีกเมื่อคุณปิดปัญหาไปแล้วก่อนหน้านี้ แต่Crashlytics ได้รับรายงานใหม่ว่าปัญหาเกิดขึ้นอีกครั้ง
Crashlytics จะเปิดปัญหาที่กลับมาอีกครั้งเหล่านี้ขึ้นใหม่โดยอัตโนมัติเพื่อให้คุณแก้ไขตามความเหมาะสมสำหรับแอปของคุณ
ต่อไปนี้เป็นตัวอย่างสถานการณ์ที่อธิบายวิธีที่ Crashlytics จัดหมวดหมู่ปัญหาเป็นการถดถอย
Crashlytics ได้รับรายงานข้อขัดข้องเกี่ยวกับข้อขัดข้อง "A" เป็นครั้งแรก Crashlytics เปิดปัญหาที่เกี่ยวข้องสำหรับการขัดข้องนั้น (ปัญหา "ก")คุณแก้ไขข้อบกพร่องนี้อย่างรวดเร็ว ปิดปัญหา "ก" แล้วเผยแพร่แอปเวอร์ชันใหม่
Crashlytics ได้รับรายงานอีกฉบับเกี่ยวกับปัญหา "ก" หลังจากที่คุณปิดปัญหาแล้ว
หากรายงานมาจากเวอร์ชันแอปที่ Crashlytics ทราบ เมื่อคุณปิดปัญหา (หมายความว่าเวอร์ชันดังกล่าวได้ส่งรายงานข้อขัดข้องสำหรับข้อขัดข้องใดๆ ก็ตาม) Crashlytics จะไม่ถือว่าปัญหาดังกล่าวแย่ลง ปัญหาจะยังคงปิดอยู่
หากรายงานมาจากเวอร์ชันแอปที่ Crashlytics ไม่ ล่วงรู้ไม่เคย ส่งรายงานข้อขัดข้องใดๆ เกี่ยวกับข้อขัดข้องใดๆ เลย) Crashlytics จะถือว่าปัญหากลับมาอีกครั้งและจะเปิดปัญหาดังกล่าวขึ้นมาใหม่
หมายเหตุ: ก่อนเดือนกุมภาพันธ์ 2022 Crashlytics จะจัดหมวดหมู่ปัญหาเป็นการถดถอยเมื่อปัญหานั้นเกิดขึ้นอีกครั้งในเวอร์ชันใดก็ได้ ของแอป แม้จะเป็นเวอร์ชันที่เราทราบเมื่อคุณปิดปัญหาแล้วก็ตาม ส่งผลให้ Crashlytics ระบุการถดถอยอย่างไม่ถูกต้องในบางครั้ง ตอนนี้เราใช้รูปแบบที่อธิบายไว้ด้านบน เมื่อปัญหากลับมาเกิดขึ้นอีก เราจะส่งการแจ้งเตือนการตรวจหาการเกิดซ้ำและเพิ่มสัญญาณการเกิดซ้ำลงในปัญหาเพื่อแจ้งให้ทราบว่า Crashlytics ได้เปิดปัญหาขึ้นมาอีกครั้ง หากไม่ต้องการให้ระบบเปิดปัญหาขึ้นมาอีกครั้งเนื่องจากอัลกอริทึมการถดถอย ให้ "ปิดเสียง" ปัญหาแทนการปิด
เหตุใดฉันจึงเห็นปัญหาที่เพิ่มขึ้นสำหรับแอปเวอร์ชันเก่า
หากรายงานมาจากแอปเวอร์ชันเก่าที่ไม่เคยส่งรายงานข้อขัดข้องเลยเมื่อคุณปิดปัญหา Crashlytics จะถือว่าปัญหากลับมาอีกครั้งและจะเปิดปัญหานั้นขึ้นมาใหม่
กรณีนี้อาจเกิดขึ้นได้เมื่อคุณแก้ไขข้อบกพร่องและเปิดตัวแอปเวอร์ชันใหม่แล้ว แต่ยังมีผู้ใช้ที่ใช้แอปเวอร์ชันเก่าอยู่ซึ่งไม่มีการแก้ไขข้อบกพร่อง หากเวอร์ชันเก่าเวอร์ชันใดเวอร์ชันหนึ่งไม่เคย ส่งรายงานข้อขัดข้องเมื่อคุณปิดปัญหา และผู้ใช้เหล่านั้นเริ่มพบข้อบกพร่อง รายงานข้อขัดข้องเหล่านั้นจะทริกเกอร์ปัญหาที่กลับมาอีกครั้ง
หากไม่ต้องการให้ระบบเปิดปัญหาขึ้นมาอีกครั้งเนื่องจากอัลกอริทึมการถดถอยของเรา ให้ "ปิดเสียง" ปัญหาแทนการปิด
หมายเหตุ: ก่อนเดือนกุมภาพันธ์ 2022 Crashlytics จะจัดหมวดหมู่ปัญหาเป็นการถดถอยเมื่อปัญหานั้นเกิดขึ้นอีกครั้งในเวอร์ชันแอปใดก็ตาม แม้ว่าจะเป็นเวอร์ชันที่เราทราบเมื่อคุณปิดปัญหาก็ตาม ส่งผลให้ Crashlytics
ระบุการถดถอยอย่างไม่ถูกต้องในบางครั้ง ตอนนี้เราใช้รูปแบบที่อธิบายไว้ด้านบน
