การแก้ปัญหาและคำถามที่พบบ่อยเกี่ยวกับ Crashlytics

เห็นรูปแบบที่แตกต่างกัน (และบางครั้งก็เห็น "ตัวแปร") สำหรับปัญหาบางอย่างในตารางปัญหา

คุณอาจเห็นรูปแบบปัญหาที่แตกต่างกัน 2 รูปแบบซึ่งแสดงอยู่ในตารางปัญหา ในFirebase Console นอกจากนี้ คุณยังอาจเห็นฟีเจอร์ที่ชื่อ "ตัวแปร" ในปัญหาบางอย่างด้วย โดยมีสาเหตุดังนี้

ในช่วงต้นปี 2023 เราได้เปิดตัวเครื่องมือวิเคราะห์ที่ได้รับการปรับปรุงสำหรับการจัดกลุ่มเหตุการณ์ รวมถึงการออกแบบที่อัปเดตแล้วและฟีเจอร์ขั้นสูงบางอย่างสำหรับปัญหาใหม่ (เช่น ตัวแปร) ดูรายละเอียดทั้งหมดได้ในบล็อกโพสต์ล่าสุด หรืออ่านไฮไลต์ด้านล่าง

Crashlytics จะวิเคราะห์เหตุการณ์ทั้งหมดจากแอป (เช่น ข้อขัดข้อง ข้อผิดพลาดที่ไม่ร้ายแรง และ ANR) และสร้างกลุ่มเหตุการณ์ที่เรียกว่าปัญหา ซึ่งเหตุการณ์ทั้งหมดในปัญหา มีจุดที่ทำให้เกิดข้อผิดพลาดร่วมกัน

ตอนนี้เครื่องมือวิเคราะห์ที่ปรับปรุงแล้วจะพิจารณาหลายแง่มุมของเหตุการณ์ ซึ่งรวมถึงเฟรมใน Stack Trace, ข้อความข้อยกเว้น, รหัสข้อผิดพลาด และลักษณะอื่นๆ ของแพลตฟอร์มหรือประเภทข้อผิดพลาด เพื่อจัดกลุ่มเหตุการณ์เป็นปัญหาเหล่านี้

อย่างไรก็ตาม ภายในกลุ่มเหตุการณ์นี้ สแต็กเทรซที่นำไปสู่ความล้มเหลว อาจแตกต่างกัน สแต็กเทรซที่แตกต่างกันอาจหมายถึงสาเหตุหลักที่แตกต่างกัน เพื่อแสดงความแตกต่างที่อาจเกิดขึ้นภายในปัญหา ตอนนี้เราจึงสร้างตัวแปรภายในปัญหา โดยแต่ละตัวแปรคือกลุ่มย่อยของเหตุการณ์ในปัญหา ที่มีจุดที่ล้มเหลวเดียวกันและสแต็กเทรซที่คล้ายกัน เมื่อใช้ตัวแปร คุณจะแก้ไขข้อบกพร่องของ Stack Trace ที่พบบ่อยที่สุดภายในปัญหาและพิจารณาได้ว่า สาเหตุหลักที่แตกต่างกันทำให้เกิดความล้มเหลวหรือไม่

การปรับปรุงเหล่านี้จะช่วยให้คุณได้รับประสบการณ์การใช้งานดังนี้

• ข้อมูลเมตาที่ปรับปรุงใหม่ซึ่งแสดงในแถวปัญหา
  ตอนนี้คุณจะเข้าใจและคัดแยกปัญหาในแอปได้ง่ายขึ้น

• ปัญหาที่ซ้ำกันน้อยลง
  การเปลี่ยนแปลงหมายเลขบรรทัดจะไม่ทำให้เกิดปัญหาใหม่

• แก้ไขข้อบกพร่องของปัญหาที่ซับซ้อนซึ่งมีสาเหตุต่างๆ ได้ง่ายขึ้น
  ใช้ตัวแปรเพื่อแก้ไขข้อบกพร่องของ Stack Trace ที่พบบ่อยที่สุดภายในปัญหา

• การแจ้งเตือนและสัญญาณที่มีความหมายมากขึ้น
  ปัญหาใหม่แสดงถึงข้อบกพร่องใหม่

• การค้นหาที่ทรงพลังยิ่งขึ้น
  ปัญหาแต่ละรายการจะมีข้อมูลเมตาที่ค้นหาได้มากขึ้น เช่น ประเภทข้อยกเว้นและชื่อแพ็กเกจ

การเปิดตัวการปรับปรุงเหล่านี้มีดังนี้

• เมื่อได้รับเหตุการณ์ใหม่จากแอป เราจะตรวจสอบว่าเหตุการณ์ดังกล่าวตรงกับปัญหาที่มีอยู่หรือไม่

• หากไม่พบรายการที่ตรงกัน เราจะใช้อัลกอริทึมการจัดกลุ่มเหตุการณ์ที่ชาญฉลาดยิ่งขึ้น กับเหตุการณ์โดยอัตโนมัติ และสร้างปัญหาใหม่ด้วยการออกแบบข้อมูลเมตาที่ปรับปรุงใหม่

นี่เป็นการอัปเดตครั้งใหญ่ครั้งแรกที่เราทำการจัดกลุ่มเหตุการณ์ หากคุณมีความคิดเห็นหรือพบปัญหา โปรดแจ้งให้เราทราบโดย ยื่นรายงาน

ไม่เห็นบันทึกเบรดครัมบ์

หากไม่เห็นบันทึกเส้นทาง เราขอแนะนำให้ตรวจสอบการกำหนดค่าของแอปสำหรับ Google Analytics โปรดตรวจสอบว่าคุณมีคุณสมบัติตรงตามข้อกำหนดต่อไปนี้

• คุณได้ เปิดใช้ Google Analytics ในโปรเจ็กต์ Firebase แล้ว

• คุณได้เปิดใช้การแชร์ข้อมูลสำหรับ Google Analytics แล้ว ดูข้อมูลเพิ่มเติมเกี่ยวกับ การตั้งค่านี้ได้ที่ จัดการการตั้งค่าการแชร์ข้อมูล Analytics

• คุณได้ เพิ่ม Firebase SDK สําหรับ Google Analytics ลงในแอปแล้ว คุณต้องเพิ่ม SDK นี้นอกเหนือจาก Crashlytics SDK

• คุณใช้ Firebase SDK เวอร์ชันล่าสุด สําหรับผลิตภัณฑ์ทั้งหมดที่คุณใช้ในแอป

  โปรดตรวจสอบว่าคุณใช้ Firebase SDK สำหรับ Google Analytics เวอร์ชันต่อไปนี้อย่างน้อย
  Android — v17.2.3 ขึ้นไป (BoM v24.7.1 ขึ้นไป)

ไม่เห็นการแจ้งเตือนอัตราความเร็ว

หากไม่เห็นการแจ้งเตือนความเร็ว โปรดตรวจสอบว่าคุณใช้ Crashlytics SDK เวอร์ชัน 18.6.0 ขึ้นไป (หรือ Firebase BoM เวอร์ชัน 32.6.0 ขึ้นไป)

ไม่เห็นเมตริกแบบไม่มีข้อขัดข้อง (หรือเห็นเมตริกที่ไม่น่าเชื่อถือ)

หากไม่เห็นเมตริกที่ไม่มีข้อขัดข้อง (เช่น ผู้ใช้และเซสชันที่ไม่มีข้อขัดข้อง) หรือเห็นเมตริกที่ไม่น่าเชื่อถือ ให้ตรวจสอบสิ่งต่อไปนี้

• ตรวจสอบว่าคุณใช้ Crashlytics SDK เวอร์ชัน 18.6.0 ขึ้นไป (หรือ Firebase BoM เวอร์ชัน 32.6.0 ขึ้นไป)

• ตรวจสอบว่าการตั้งค่าการเก็บรวบรวมข้อมูลไม่ส่งผลต่อคุณภาพของ เมตริกแบบไม่มีข้อขัดข้อง

  • หากคุณเปิดใช้การรายงานแบบเลือกใช้ โดยการปิดใช้การรายงานข้อขัดข้องอัตโนมัติ ระบบจะส่งข้อมูลข้อขัดข้องได้เฉพาะ ไปยัง Crashlytics จากผู้ใช้ที่เลือกใช้การเก็บรวบรวมข้อมูลอย่างชัดเจน เท่านั้น ดังนั้น ความแม่นยำของเมตริกแบบไม่มีข้อขัดข้องจะได้รับผลกระทบเนื่องจาก Crashlytics มีข้อมูลข้อขัดข้องจากผู้ใช้ที่เลือกเข้าร่วมเหล่านี้เท่านั้น (ไม่ใช่ผู้ใช้ทั้งหมด) ซึ่งหมายความว่าเมตริกแบบไม่มีข้อขัดข้องอาจมีความน่าเชื่อถือน้อยลง และสะท้อนถึงความเสถียรโดยรวมของแอปได้น้อยลง

  • หากปิดใช้การเก็บรวบรวมข้อมูลอัตโนมัติ คุณจะใช้ sendUnsentReports เพื่อส่งรายงานที่แคชไว้ในอุปกรณ์ไปยัง Crashlytics ได้ การใช้วิธีนี้จะส่งข้อมูลข้อขัดข้องไปยัง Crashlytics แต่จะไม่ส่งข้อมูลเซสชัน ซึ่งจะทำให้แผนภูมิคอนโซลแสดงค่าต่ำหรือ 0 สำหรับเมตริกที่ไม่มีข้อขัดข้อง

ระบบคำนวณจำนวนผู้ใช้ที่ไม่พบข้อขัดข้องอย่างไร

ดูทำความเข้าใจเมตริกแบบไม่มีข้อขัดข้อง

เหตุใดจึงมีการรายงาน ANR สำหรับ Android 11 ขึ้นไปเท่านั้น

Crashlytics รองรับการรายงาน ANR สำหรับแอป Android จากอุปกรณ์ที่ใช้ Android 11 ขึ้นไป API พื้นฐานที่เราใช้เพื่อรวบรวม ANR (getHistoricalProcessExitReasons) มีความน่าเชื่อถือมากกว่าวิธีการที่ใช้ SIGQUIT หรือ Watchdog API นี้ใช้ได้เฉพาะในอุปกรณ์ Android 11 ขึ้นไป

ทำไม ANR บางรายการจึงไม่มี BuildId

หาก ANR บางรายการไม่มี BuildId ให้แก้ปัญหาดังนี้

• ตรวจสอบว่าคุณใช้ Crashlytics Android SDK และ Crashlyticsปลั๊กอิน Gradle เวอร์ชันล่าสุด

  หากคุณไม่มี BuildId สำหรับ Android 11 และ ANR บางรายการของ 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ที่เชื่อมโยงไม่ได้ เราขอแนะนำให้คุณพิจารณาใช้ตำแหน่งมาตรฐาน สำหรับไลบรารีที่ใช้ร่วมกัน

• ตรวจสอบว่าคุณไม่ได้ลบ BuildIds ในระหว่างกระบวนการสร้าง

  โปรดทราบว่าเคล็ดลับในการแก้ปัญหาต่อไปนี้ใช้ได้กับทั้ง ANR และข้อขัดข้องที่เกิดในโค้ดเนทีฟ

  • ตรวจสอบว่ามี BuildId หรือไม่โดยเรียกใช้ readelf -n ในไบนารี หากไม่มี BuildId ให้เพิ่ม -Wl,--build-id ลงในแฟล็กสำหรับ ระบบบิลด์

  • ตรวจสอบว่าคุณไม่ได้ลบ 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

ความแตกต่าง ระหว่าง Stack Trace ของ NDK ในแดชบอร์ด Crashlytics กับ Logcat

LLVM และ GNU Toolchain มีค่าเริ่มต้นและการจัดการที่แตกต่างกันสำหรับส่วนแบบอ่านอย่างเดียวของไบนารีของแอป ซึ่งอาจสร้าง Stack Trace ที่ไม่สอดคล้องกันในFirebaseคอนโซล หากต้องการลดปัญหานี้ ให้เพิ่มแฟล็ก Linker ต่อไปนี้ ลงในกระบวนการบิลด์

• หากคุณใช้ lld Linker จากชุดเครื่องมือ LLVM ให้เพิ่มสิ่งต่อไปนี้

  -Wl,--no-rosegment

• หากคุณใช้โปรแกรมลิงก์ ld.gold จาก GNU Toolchain ให้เพิ่มสิ่งต่อไปนี้

  -Wl,--rosegment

หากยังคงเห็นความไม่สอดคล้องกันของ Stack Trace (หรือหากไม่มีแฟล็กใดที่เกี่ยวข้องกับ Toolchain) ให้ลองเพิ่มสิ่งต่อไปนี้ลงในกระบวนการบิลด์แทน

-fno-omit-frame-pointer

ฉันจะใช้ไบนารีตัวสร้างไฟล์สัญลักษณ์ Breakpad ของตัวเองสำหรับ NDK ได้อย่างไร

Crashlytics ปลั๊กอินจะรวม เครื่องมือสร้างไฟล์สัญลักษณ์ Breakpad ที่ปรับแต่งแล้ว หากต้องการใช้ไบนารีของคุณเองเพื่อสร้างไฟล์สัญลักษณ์ Breakpad (เช่น หากต้องการสร้างไฟล์ปฏิบัติการแบบเนทีฟทั้งหมดในห่วงโซ่การสร้างจากแหล่งที่มา) ให้ใช้พร็อพเพอร์ตี้ส่วนขยาย symbolGeneratorBinary ที่ไม่บังคับเพื่อระบุเส้นทางไปยังไฟล์ปฏิบัติการ

คุณระบุเส้นทางไปยังไบนารีของเครื่องมือสร้างไฟล์สัญลักษณ์ Breakpad ได้ 1 ใน 2 วิธีต่อไปนี้

• ตัวเลือกที่ 1: ระบุเส้นทางผ่านส่วนขยาย firebaseCrashlytics ในไฟล์ build.gradle

  เพิ่มโค้ดต่อไปนี้ลงในไฟล์ build.gradle.kts ระดับแอป

  ปลั๊กอิน Gradle เวอร์ชัน 3.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 Properties ด้วยตนเองหรืออัปเดตไฟล์ ผ่านบรรทัดคำสั่งได้ เช่น หากต้องการระบุเส้นทางผ่านบรรทัดคำสั่ง ให้ใช้คำสั่งต่อไปนี้

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

ข้อยกเว้นนี้จะไม่ทำให้แอปขัดข้อง แต่จะป้องกันไม่ให้แอปส่งรายงานข้อขัดข้อง วิธีแก้ปัญหามีดังนี้

1. ตรวจสอบว่าคุณใช้ DexGuard 8.x รุ่นล่าสุด เวอร์ชันล่าสุด มีกฎที่ SDK ของ Firebase Crashlytics กำหนด

2. หากไม่ต้องการเปลี่ยนเวอร์ชัน DexGuard ให้ลองเพิ่มบรรทัดต่อไปนี้ ลงในกฎการปกปิดโค้ด (ในไฟล์กำหนดค่า DexGuard)

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

เหตุใดฉันจึงเห็นข้อขัดข้อง จากไฟล์ .kt ที่ติดป้ายกำกับเป็นปัญหา .java

เมื่อแอปใช้เครื่องมือ Obfuscator ที่ไม่แสดงนามสกุลไฟล์ Crashlytics จะสร้างปัญหาแต่ละรายการด้วยนามสกุลไฟล์ .java โดยค่าเริ่มต้น

เพื่อให้ Crashlytics สร้างปัญหาที่มีนามสกุลไฟล์ที่ถูกต้องได้ โปรดตรวจสอบว่าแอปของคุณใช้การตั้งค่าต่อไปนี้

• ใช้ Android Gradle 4.2.0 ขึ้นไป
• ใช้ R8 โดยเปิดการปิดบังไว้ หากต้องการอัปเดตแอปเป็น R8 ให้ดูเอกสารประกอบนี้

โปรดทราบว่าหลังจากอัปเดตเป็นการตั้งค่าที่อธิบายไว้ข้างต้นแล้ว คุณอาจเริ่มเห็น.ktปัญหาใหม่ที่ซ้ำกับปัญหา .java ที่มีอยู่ ดูข้อมูลเพิ่มเติมเกี่ยวกับกรณีดังกล่าวได้ที่ คำถามที่พบบ่อย

เหตุใดฉันจึงเห็นปัญหา .kt ที่ซ้ำกับปัญหา .java ที่มีอยู่

ตั้งแต่ช่วงกลางเดือนธันวาคม 2021 เป็นต้นไป เราจะCrashlyticsปรับปรุงการรองรับแอปพลิเคชัน ที่ใช้ Kotlin

ก่อนหน้านี้ Obfuscator ที่มีอยู่ไม่ได้แสดงนามสกุลไฟล์ ดังนั้น Crashlyticsจึงสร้างปัญหาแต่ละรายการด้วยนามสกุลไฟล์ .java โดยค่าเริ่มต้น อย่างไรก็ตาม ตั้งแต่ Android Gradle 4.2.0 เป็นต้นมา R8 รองรับนามสกุลไฟล์

การอัปเดตนี้ช่วยให้ Crashlytics สามารถระบุได้ว่าคลาสแต่ละคลาสที่ใช้ภายในแอปเขียนด้วย Kotlin หรือไม่ และรวมชื่อไฟล์ที่ถูกต้องไว้ในลายเซ็นของปัญหา ตอนนี้ระบบจะระบุแหล่งที่มาของข้อขัดข้องไปยังไฟล์ .kt อย่างถูกต้อง (ตามความเหมาะสม) หากแอปมีการตั้งค่าต่อไปนี้

• แอปของคุณใช้ Android Gradle 4.2.0 ขึ้นไป
• แอปของคุณใช้ R8 โดยเปิดการปิดบัง

เนื่องจากตอนนี้ข้อขัดข้องใหม่จะมีนามสกุลไฟล์ที่ถูกต้องในลายเซ็นปัญหา คุณจึงอาจเห็นปัญหาใหม่ที่.ktเป็นเพียงปัญหาที่ซ้ำกับปัญหาที่มีอยู่ซึ่งติดป้ายกำกับ.javaไว้ ในFirebaseคอนโซล เราพยายามระบุ และแจ้งให้คุณทราบหาก.ktปัญหาใหม่มีลักษณะคล้ายกับ.javaปัญหาที่มีอยู่

ใครดู เขียน และลบหมายเหตุในปัญหาได้บ้าง

หมายเหตุช่วยให้สมาชิกโปรเจ็กต์แสดงความคิดเห็นเกี่ยวกับปัญหาที่เฉพาะเจาะจงได้ด้วยคำถาม การอัปเดตสถานะ และอื่นๆ

เมื่อสมาชิกในโปรเจ็กต์โพสต์โน้ต ระบบจะติดป้ายกำกับด้วยอีเมลของบัญชี Google อีเมลนี้จะแสดงพร้อมกับหมายเหตุต่อสมาชิกโปรเจ็กต์ทั้งหมดที่มีสิทธิ์ดูหมายเหตุ

ต่อไปนี้จะอธิบายสิทธิ์เข้าถึงที่จำเป็นในการดู เขียน และลบ โน้ต

• สมาชิกโปรเจ็กต์ที่มีบทบาทต่อไปนี้จะดูและลบโน้ตที่มีอยู่ รวมถึงเขียนโน้ตใหม่ในปัญหาได้

  • เจ้าของหรือผู้แก้ไขโปรเจ็กต์ ผู้ดูแลระบบ Firebase ผู้ดูแลระบบคุณภาพ หรือ ผู้ดูแลระบบ Crashlytics

• สมาชิกโปรเจ็กต์ที่มีบทบาทต่อไปนี้จะดูหมายเหตุที่โพสต์ในปัญหาได้ แต่จะลบหรือเขียนหมายเหตุไม่ได้

  • ผู้ดูโปรเจ็กต์ ผู้ดู Firebase ผู้ดูคุณภาพ หรือ ผู้ดู Crashlytics

แอปยังใช้ SDK Google Mobile Ads แต่ไม่พบข้อขัดข้อง

หากโปรเจ็กต์ใช้ Crashlytics ควบคู่กับ SDK ของ Google Mobile Ads มีแนวโน้มที่เครื่องมือรายงานข้อขัดข้องจะรบกวนเมื่อ ลงทะเบียนตัวแฮนเดิลข้อยกเว้น หากต้องการแก้ไขปัญหานี้ ให้ปิดการรายงานข้อขัดข้องใน SDK ของ Mobile Ads โดยเรียกใช้ disableSDKCrashReporting

ชุดข้อมูล BigQuery ของฉันอยู่ที่ไหน

หลังจากลิงก์ Crashlytics กับ BigQuery แล้ว ชุดข้อมูลใหม่ที่คุณสร้างจะอยู่ในสหรัฐอเมริกาโดยอัตโนมัติ ไม่ว่าโปรเจ็กต์ Firebase จะอยู่ที่ใด

Crashlytics รองรับ armeabi ไหม

Firebase Crashlytics NDK ไม่รองรับ ARMv5 (armeabi) เราได้นำการรองรับ ABI นี้ออกแล้วตั้งแต่ NDK r17

ปัญหาที่ถดถอยคืออะไร

ปัญหาเกิดการถดถอยเมื่อคุณปิดปัญหาไปก่อนหน้านี้ แต่ Crashlytics ได้รับรายงานใหม่ว่าปัญหาเกิดขึ้นอีกครั้ง Crashlytics จะเปิดปัญหาที่ถดถอยเหล่านี้อีกครั้งโดยอัตโนมัติเพื่อให้คุณ แก้ไขปัญหาตามความเหมาะสมกับแอปของคุณ

ต่อไปนี้คือสถานการณ์ตัวอย่างที่อธิบายวิธีที่ Crashlytics จัดหมวดหมู่ปัญหาเป็นรีเกรสชัน

1. เป็นครั้งแรกที่ Crashlytics ได้รับรายงานข้อขัดข้องเกี่ยวกับข้อขัดข้อง "ก" Crashlytics จะเปิดปัญหาที่เกี่ยวข้องกับการขัดข้องนั้น (ปัญหา "ก")
2. คุณแก้ไขข้อบกพร่องนี้อย่างรวดเร็ว ปิดปัญหา "ก" แล้วเผยแพร่แอปเวอร์ชันใหม่
3. Crashlytics ได้รับรายงานอีกฉบับเกี่ยวกับปัญหา "ก" หลังจากที่คุณปิดปัญหาแล้ว
   • หากรายงานมาจากแอปเวอร์ชันที่ Crashlytics ทราบ เมื่อคุณปิดปัญหา (หมายความว่าเวอร์ชันได้ส่งรายงานข้อขัดข้อง สำหรับข้อขัดข้องใดๆ) Crashlytics จะไม่ถือว่าปัญหา ดังกล่าวเป็นปัญหาที่เกิดซ้ำ เราจะปิดปัญหาต่อไป
   • หากรายงานมาจากแอปเวอร์ชันที่ Crashlytics ไม่ทราบ เกี่ยวกับเมื่อคุณปิดปัญหา (หมายความว่าเวอร์ชันไม่เคยส่งรายงานข้อขัดข้องใดๆ สำหรับข้อขัดข้องใดๆ เลย) Crashlyticsจะถือว่าปัญหาเกิดซ้ำและจะเปิดปัญหาอีกครั้ง

เมื่อเกิดปัญหาซ้ำ เราจะส่งการแจ้งเตือนการตรวจหาการเกิดซ้ำและเพิ่ม สัญญาณการเกิดซ้ำลงในปัญหาเพื่อแจ้งให้คุณทราบว่า Crashlytics ได้ เปิดปัญหาอีกครั้ง หากไม่ต้องการให้ระบบเปิดปัญหาอีกครั้งเนื่องจาก อัลกอริทึมการถดถอยของเรา ให้ "ปิดเสียง" ปัญหาแทนการปิด

เหตุใดฉันจึงเห็นปัญหาที่ถดถอย สำหรับแอปเวอร์ชันเก่า

หากรายงานมาจากแอปเวอร์ชันเก่าที่ไม่เคยส่งรายงานข้อขัดข้องเลยเมื่อคุณปิดปัญหา Crashlytics จะถือว่าปัญหาดังกล่าวCrashlyticsกลับมาเกิดซ้ำและจะเปิดปัญหาอีกครั้ง

สถานการณ์นี้อาจเกิดขึ้นในกรณีต่อไปนี้ คุณแก้ไขข้อบกพร่องและ เผยแพร่แอปเวอร์ชันใหม่แล้ว แต่ยังมีผู้ใช้ที่ใช้แอปเวอร์ชันเก่า ที่ไม่มีการแก้ไขข้อบกพร่อง หากเวอร์ชันเก่าเหล่านั้นไม่เคยส่งรายงานข้อขัดข้องเลยเมื่อคุณปิดปัญหา และผู้ใช้เริ่มพบข้อบกพร่อง รายงานข้อขัดข้องเหล่านั้นจะทําให้เกิดปัญหาที่ถดถอย

หากไม่ต้องการให้ระบบเปิดปัญหาอีกครั้งเนื่องจากอัลกอริทึมการถดถอยของเรา ให้ "ปิดเสียง" ปัญหาแทนการปิด