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


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

การแก้ปัญหาทั่วไป/คําถามที่พบบ่อย

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

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

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

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

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

ต่อไปนี้คือสิ่งที่คุณจะพบจากการปรับปรุงเหล่านี้

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

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

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

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

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

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

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

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

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

หากไม่เห็นเมตริกที่ไม่มีการขัดข้อง (เช่น ผู้ใช้และเซสชันที่ไม่มีการขัดข้อง) และ/หรือการแจ้งเตือนเกี่ยวกับความเร็ว ให้ตรวจสอบว่าคุณใช้ Crashlytics SDK v18.6.0 ขึ้นไป (หรือ Firebase BoM v32.6.0 ขึ้นไป)

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

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

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

  • ตรวจสอบว่าคุณใช้ CrashlyticsAndroid 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 ระหว่าง Google Play กับ Crashlytics อาจไม่ตรงกัน ความไม่สอดคล้องนี้อาจเกิดขึ้นจากความแตกต่างของกลไกการเก็บรวบรวมและการรายงานข้อมูล ANR Crashlytics จะรายงาน ANR เมื่อแอปเริ่มทำงานครั้งถัดไป ส่วน Android Vitals จะส่งข้อมูล ANR หลังจากที่ ANR เกิดขึ้น

นอกจากนี้ Crashlytics จะแสดงเฉพาะ ANR ที่เกิดขึ้นในอุปกรณ์ที่ใช้ Android 11 ขึ้นไปเท่านั้น เมื่อเทียบกับ Google Play ที่แสดง ANR จากอุปกรณ์ที่มีบริการ Google Play และยอมรับความยินยอมให้เก็บรวบรวมข้อมูล

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

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

    -Wl,--no-rosegment

  • หากคุณใช้ linker ld.gold จากชุดเครื่องมือ GNU ให้เพิ่ม

    -Wl,--rosegment

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

-fno-omit-frame-pointer

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

คุณระบุเส้นทางไปยังไฟล์ไบนารีของเครื่องมือสร้างไฟล์สัญลักษณ์ 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 เวอร์ชันที่ใช้ร่วมกับ 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

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

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

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

โปรดทราบว่าหลังจากอัปเดตเป็นการตั้งค่าที่อธิบายข้างต้น คุณอาจเริ่มเห็นปัญหา .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 อีเมลนี้และโน้ตจะแสดงให้สมาชิกโปรเจ็กต์ทุกคนที่มีสิทธิ์ดูโน้ตเห็น

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

การผสานรวม

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

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

การรองรับแพลตฟอร์ม

NDK ของ Firebase Crashlytics ไม่รองรับ ARMv5 (armeabi) การรองรับ ABI นี้ถูกนําออกแล้วใน NDK r17

ปัญหาเดิม

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

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

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

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

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

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

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