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

ไม่เห็นผู้ใช้ที่ไม่ขัดข้อง บันทึกเส้นทาง และ/หรือการแจ้งเตือนความเร็ว

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

• ตรวจสอบว่าคุณ เปิดใช้ Google Analytics ในโครงการ Firebase แล้ว

• ตรวจสอบว่าเปิดใช้ การแชร์ข้อมูล สำหรับ Google Analytics ในหน้า การผสานรวม > Google Analytics ของคอนโซล Firebase โปรดทราบว่าการตั้งค่า การแชร์ข้อมูล จะแสดงในคอนโซล Firebase แต่จัดการในคอนโซล Google Analytics

• นอกจาก Firebase Crashlytics SDK แล้ว ตรวจสอบให้แน่ใจว่าคุณได้เพิ่ม Firebase SDK สำหรับ Google Analytics ลงในแอปของคุณ ( iOS+ | Android )

• ตรวจสอบว่าคุณใช้เวอร์ชันล่าสุดสำหรับ Firebase SDK ทั้งหมด ( iOS+ | Android )
  ตรวจสอบเป็นพิเศษว่าคุณใช้ Firebase SDK สำหรับ Google Analytics เวอร์ชันต่อไปนี้ เป็นอย่างน้อย : iOS+ — v6.3.1+ (v8.9.0+ สำหรับ macOS และ tvOS) | Android — v17.2.3+ (BoM v24.7.1+)

การดูรูปแบบต่างๆ (และบางครั้ง "รูปแบบต่างๆ") สำหรับปัญหาบางอย่างในตาราง ปัญหา

คุณอาจสังเกตเห็นรูปแบบที่แตกต่างกัน 2 รูปแบบสำหรับปัญหาที่แสดงในตาราง ปัญหา ในคอนโซล Firebase และคุณอาจสังเกตเห็นคุณลักษณะที่เรียกว่า "รูปแบบต่างๆ" ในบางปัญหาของคุณ นี่คือเหตุผล!

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

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

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

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

สิ่งที่คุณจะได้สัมผัสกับการปรับปรุงเหล่านี้มีดังนี้

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

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

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

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

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

ต่อไปนี้เป็นวิธีการเผยแพร่การปรับปรุงเหล่านี้:

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

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

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

เหตุใดจึงรายงาน ANR สำหรับ Android 11+ เท่านั้น

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

เหตุใด ANR บางส่วนจึงไม่มี BuildId

หาก ANR บางส่วนของคุณไม่มี BuildId ให้แก้ไขปัญหาดังต่อไปนี้:

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

  หากคุณไม่มี BuildId สำหรับ Android 11 และ Android 12 ANR บางตัว อาจเป็นไปได้ว่าคุณใช้ SDK, ปลั๊กอิน Gradle ที่ล้าสมัย หรือทั้งสองอย่าง หากต้องการรวบรวม 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 ให้กับแฟล็กสำหรับระบบบิลด์ของคุณ

  • ตรวจสอบว่าคุณไม่ได้ดึง 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 stack trace ในแดชบอร์ด Crashlytics และ logcat

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

• หากคุณใช้ตัวเชื่อมโยง lld จาก toolchain LLVM ให้เพิ่ม:

  -Wl,--no-rosegment
  

• หากคุณใช้ตัวเชื่อมโยง ld.gold จาก toolchain GNU ให้เพิ่ม:

  -Wl,--rosegment
  

หากคุณยังคงเห็นความไม่สอดคล้องกันของสแต็กเทรซ (หรือหากแฟล็กไม่เกี่ยวข้องกับ toolchain ของคุณ) ให้ลองเพิ่มสิ่งต่อไปนี้ในกระบวนการสร้างของคุณแทน:

-fno-omit-frame-pointer

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

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

คุณสามารถระบุพาธไปยังไบนารีตัวสร้างไฟล์สัญลักษณ์ Breakpad ได้ด้วยวิธีใดวิธีหนึ่งจากสองวิธีต่อไปนี้:

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

  เพิ่มสิ่งต่อไปนี้ในไฟล์ build.gradle ระดับแอปของคุณ:

  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 ของคุณ

  คุณสามารถใช้คุณสมบัติ com.google.firebase.crashlytics.symbolGeneratorBinary symbolGeneratorBinary เพื่อระบุเส้นทางไปยังไฟล์ปฏิบัติการ

  คุณสามารถอัปเดตไฟล์คุณสมบัติ Gradle ด้วยตนเองหรืออัปเดตไฟล์ผ่านบรรทัดคำสั่ง ตัวอย่างเช่น หากต้องการระบุเส้นทางผ่านบรรทัดคำสั่ง ให้ใช้คำสั่งดังต่อไปนี้:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/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 รุ่นล่าสุด เวอร์ชันล่าสุดมีกฎที่จำเป็นสำหรับ Firebase Crashlytics SDK

2. หากคุณไม่ต้องการเปลี่ยนเวอร์ชัน 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

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

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

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

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

ผู้ใช้ที่ไม่มีปัญหาจะคำนวณอย่างไร

ค่าที่ไม่มีข้อขัดข้องแสดงถึงเปอร์เซ็นต์ของผู้ใช้ที่มีส่วนร่วมกับแอปของคุณแต่ ไม่มี ข้อขัดข้องในช่วงเวลาที่กำหนด

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

CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100

• เมื่อเกิดข้อขัดข้อง Google Analytics จะส่งเหตุการณ์ประเภท app_exception และ CRASHED_USERS แสดงถึงจำนวนผู้ใช้ที่เกี่ยวข้องกับเหตุการณ์ประเภทนั้น

• ALL_USERS แสดงถึงจำนวนผู้ใช้ทั้งหมดที่มีส่วนร่วมกับแอปของคุณในช่วงเวลาที่คุณเลือกจากเมนูแบบเลื่อนลงที่ด้านขวาบนของแดชบอร์ด Crashlytics

เปอร์เซ็นต์ผู้ใช้ที่ไม่มีข้อขัดข้อง เป็นการรวมในช่วงเวลาหนึ่ง ไม่ใช่ค่าเฉลี่ย

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

• ในวันพุธ เปอร์เซ็นต์ผู้ใช้ที่ไม่มีข้อขัดข้องคือ 50% (ผู้ใช้ 1 ใน 2 คนไม่มีข้อขัดข้อง)
  ผู้ใช้ 2 รายมีส่วนร่วมกับแอปของคุณในวันพุธ แต่มีเพียง 1 รายเท่านั้น (ผู้ใช้ B) ที่ไม่มีข้อขัดข้อง

• ในช่วง 2 วันที่ผ่านมา เปอร์เซ็นต์ผู้ใช้ที่ไม่มีข้อขัดข้องคือ 33.3% (ผู้ใช้ 1 ใน 3 รายไม่มีข้อขัดข้อง)
  ผู้ใช้ 3 รายมีส่วนร่วมกับแอปของคุณในช่วง 2 วันที่ผ่านมา แต่มีเพียง 1 รายเท่านั้น (ผู้ใช้ C) ที่ไม่มีข้อขัดข้อง

• ในช่วง 3 วันที่ผ่านมา เปอร์เซ็นต์ผู้ใช้ที่ไม่มีข้อขัดข้องคือ 0% (ผู้ใช้ 0 ใน 3 รายไม่มีข้อขัดข้อง)
  ผู้ใช้ 3 รายมีส่วนร่วมกับแอปของคุณในช่วง 3 วันที่ผ่านมา แต่ผู้ใช้ 0 รายไม่มีข้อขัดข้อง

ใครสามารถดู เขียน และลบบันทึกเกี่ยวกับปัญหา

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

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

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

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

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

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

  • Project Viewer , Firebase Viewer , Quality Viewer หรือ Crashlytics Viewer

แอปยังใช้ SDK โฆษณาบนอุปกรณ์เคลื่อนที่ของ Google แต่ไม่ขัดข้อง

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

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

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

Crashlytics รองรับ armeabi หรือไม่

Firebase Crashlytics NDK ไม่รองรับ ARMv5 (armeabi) การสนับสนุนสำหรับ ABI นี้ถูกลบออกตั้งแต่ NDK r17

ปัญหาถดถอยคืออะไร?

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

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

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

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

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

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

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

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