이 페이지에서는 Crashlytics 사용과 관련된 자주 묻는 질문(FAQ)에 대한 답변과 문제 해결 도움말을 제공합니다. 원하는 내용을 찾을 수 없거나 추가 지원이 필요하면 Firebase 지원팀에 문의하세요.
이 페이지에서는 다음 유형의 주제에 관한 정보를 확인할 수 있습니다.
Firebase Console에서 데이터 표시 또는 데이터 작업에 관한 질문, 회귀된 문제에 관한 질문 등 일반적인 문제 해결
BigQuery에 관한 질문을 비롯한 통합 지원
일반적인 문제 해결 및 FAQ
문제 표에 일부 문제에 대해 다른 형식(가끔 '변형')이 표시됨
Firebase Console의 문제 표에 두 가지 다른 문제 형식이 표시될 수 있습니다. 또한 일부 문제에는 '변형'이라는 특징이 있을 수 있습니다. 이유는 다음과 같습니다.
2023년 초, Google에서는 이벤트 그룹화를 위한 향상된 분석 엔진, 업데이트된 디자인, 새로운 문제(예: 변형)에 대한 일부 고급 기능을 출시했습니다. 자세한 내용은 최근 블로그 게시물을 참조하세요. 아래에서 주요 내용을 확인할 수 있습니다.
Crashlytics는 앱의 모든 이벤트(예: 비정상 종료, 심각하지 않은 문제, ANR)를 분석하고 문제라는 이벤트 그룹을 만듭니다. 한 문제의 모든 이벤트에는 공통적인 장애점이 있습니다.
이벤트를 이러한 문제로 그룹화하기 위해 이제 향상된 분석 엔진이 스택 트레이스의 프레임, 예외 메시지, 오류 코드, 기타 플랫폼 또는 오류 유형 특성 등 이벤트의 여러 측면을 살펴봅니다.
그러나 이 이벤트 그룹 내에서 장애로 이어지는 스택 트레이스가 다를 수 있습니다. 스택 트레이스가 다르면 근본 원인이 달라질 수 있습니다. 문제 내에서 발생할 수 있는 이러한 차이를 나타내기 위해 이제 문제 내에 변형을 만듭니다. 각 변형은 문제에서 동일한 장애점 및 유사한 스택 트레이스가 있는 이벤트의 하위 그룹입니다. 변형을 사용하면 문제 내에서 가장 일반적인 스택 트레이스를 디버깅하고 서로 다른 근본 원인으로 인해 장애가 발생했는지 파악할 수 있습니다.
개선된 기능은 다음과 같습니다.
문제 행에 개선된 메타데이터 표시
이제 앱의 문제를 더 쉽게 파악하고 분류할 수 있습니다.중복 문제 감소
줄 번호를 변경해도 새 문제가 발생하지 않습니다.다양한 근본 원인이 있는 복잡한 문제를 더 손쉽게 디버깅
변형을 사용하여 문제 내에서 가장 일반적인 스택 트레이스를 디버깅합니다.더 의미 있는 알림과 신호
새로운 문제가 실제로는 새로운 버그를 나타냅니다.더욱 강력한 검색
각 문제에 예외 유형 및 패키지 이름과 같이 검색 가능성이 더 높은 메타데이터가 포함됩니다.
개선된 기능이 적용되는 방식은 다음과 같습니다.
앱에서 새로운 이벤트가 수신되면 기존 문제와 일치하는지 확인합니다.
일치하는 항목이 없으면 이벤트에 더 스마트한 이벤트 그룹화 알고리즘을 자동으로 적용하고 개선된 메타데이터 설계로 새로운 문제를 만듭니다.
Google에서 진행 중인 이벤트 그룹화에 대한 첫 번째 대규모 업데이트입니다. 의견이 있거나 문제가 발생하면 신고를 제출하여 알려주시기 바랍니다.
탐색경로 로그가 표시되지 않음
탐색경로 로그(iOS+ | Android | Flutter | Unity)가 표시되지 않는 경우 Google Analytics의 앱 구성을 확인하는 것이 좋습니다. 다음 요건을 충족해야 합니다.
Firebase 프로젝트에서 Google Analytics를 사용 설정했습니다.
Google Analytics에 대해 데이터 공유를 사용 설정했습니다. 애널리틱스 데이터 공유 설정 관리하기에서 이 설정에 대해 자세히 알아보세요.
Google Analytics용 Firebase SDK(iOS+ | Android | Flutter | Unity)를 앱에 추가했습니다.
Crashlytics SDK 외에 이 SDK를 추가해야 합니다.앱에서 사용하는 모든 제품에 최신 Firebase SDK 버전을 사용 중입니다(iOS+ | Android | Flutter | Unity).
Apple 플랫폼 및 Android 앱의 경우 특히 적어도 Google Analytics용 Firebase SDK의 다음 버전을 사용하는지 확인하세요.
iOS+ — v6.3.1 이상 (macOS 및 tvOS의 경우 v8.9.0 이상) |Android — v17.2.3 이상 (BoM v24.7.1 이상)
신속 알림이 표시되지 않음
신속 알림이 표시되지 않으면 다음을 사용 중인지 확인하세요.
비정상 종료가 발생하지 않은 측정항목이 표시되지 않거나 신뢰할 수 없는 측정항목이 표시됨
비정상 종료가 발생하지 않은 측정항목(예: 비정상 종료가 발생하지 않은 사용자 및 세션)이 표시되지 않거나 신뢰할 수 없는 측정항목이 표시되면 다음을 확인하세요.
데이터 수집 설정이 비정상 종료가 발생하지 않은 측정항목의 품질에 영향을 미치지 않는지 확인합니다.
자동 비정상 종료 보고를 사용 중지하여 보고 선택 옵션을 사용 설정하는 경우 데이터 수집에 명시적으로 동의한 사용자만 Crashlytics에 비정상 종료 정보를 전송할 수 있습니다. 따라서 Crashlytics에는 모든 사용자가 아닌 동의한 사용자의 비정상 종료 정보만 있으므로 비정상 종료가 발생하지 않은 측정항목의 정확성이 영향을 받습니다. 즉, 비정상 종료가 발생하지 않은 측정항목의 신뢰도가 낮아지고 앱의 전반적인 안정성을 반영하지 못할 수 있습니다.
자동 데이터 수집을 사용 중지한 경우
sendUnsentReports를 사용하여 기기 내 캐시된 보고서를 Crashlytics로 전송할 수 있습니다. 이 메서드를 사용하면 비정상 종료 데이터가 Crashlytics로 전송되지만 세션 데이터는 전송되지 않으므로 콘솔 차트에 비정상 종료가 발생하지 않은 측정항목의 값이 낮거나 0으로 표시됩니다.
비정상 종료가 발생하지 않은 사용자는 어떻게 계산되나요?
비정상 종료가 발생하지 않은 측정항목 이해하기를 참조하세요.
문제에 관한 메모를 보고, 작성하고, 삭제할 수 있는 권한은 누구에게 있나요?
프로젝트 구성원은 메모를 통해 질문, 상태 업데이트 등의 특정 문제에 대한 의견을 남길 수 있습니다.
프로젝트 구성원이 메모를 게시하면 Google 계정의 이메일로 라벨이 지정됩니다. 이 이메일 주소는 메모를 확인할 권한이 있는 모든 프로젝트 구성원에게 메모와 함께 표시됩니다.
다음은 메모를 보고 작성하고 삭제하는 데 필요한 액세스 권한입니다.
다음 역할의 프로젝트 구성원은 기존 메모를 보고 삭제할 수 있으며, 문제에 관한 새로운 메모를 작성할 수 있습니다.
- 프로젝트 소유자 또는 편집자, Firebase 관리자, 품질 관리자, Crashlytics 관리자
다음 역할의 프로젝트 구성원은 문제에 게시된 메모를 볼 수 있지만 메모를 삭제하거나 작성할 수는 없습니다.
- 프로젝트 뷰어, Firebase 뷰어, 품질 뷰어, Crashlytics 뷰어
회귀된 문제란 무엇인가요?
이전에 문제를 종료했지만 Crashlytics에서 해당 문제가 다시 발생했다는 새로운 보고를 받으면 문제가 회귀된 것입니다. 앱에 맞게 문제를 해결할 수 있도록 Crashlytics에서 이러한 회귀된 문제를 자동으로 다시 엽니다.
다음은 Crashlytics에서 문제를 회귀로 분류하는 방식을 설명하는 예시 시나리오입니다.
- Crashlytics에서 처음으로 비정상 종료 'A'에 관한 비정상 종료 보고서를 받습니다. Crashlytics에서 이 비정상 종료에 해당하는 문제(문제 'A')를 엽니다.
- 개발자가 이 버그를 신속하게 수정하고 문제 'A'를 종료한 후 앱의 새 버전을 출시합니다.
- 개발자가 문제를 종료한 후 Crashlytics에서 문제 'A'에 관한 다른 보고서를 받습니다.
- 문제가 종료되었을 때 Crashlytics에서 알고 있는 앱 버전에서 보고서를 보낸 경우(즉, 해당 버전에서 모든 비정상 종료에 대해 비정상 종료 보고서를 보낸 경우) Crashlytics에서는 문제가 회귀된 것으로 간주하지 않습니다. 문제가 종료된 상태로 유지됩니다.
- 문제가 종료되었을 때 Crashlytics에서 모르는 앱 버전에서 보고서를 보낸 경우(즉, 해당 버전에서 비정상 종료에 대해 어떠한 비정상 종료 보고서도 보내지 않은 경우) Crashlytics에서 문제가 회귀된 것으로 간주하고 문제를 다시 엽니다.
문제가 회귀되면 Crashlytics에서 문제를 다시 열었음을 알 수 있도록 회귀 감지 알림이 전송되고 문제에 회귀 신호가 추가됩니다. 회귀 알고리즘으로 인해 문제가 다시 열리지 않도록 하려면 문제를 종료하는 대신 '숨기세요'.
이전 앱 버전의 회귀된 문제가 표시되는 이유는 무엇인가요?
문제가 종료되었을 때 비정상 종료 보고서를 보낸 적이 없는 이전 앱 버전에서 보고서를 보내면 Crashlytics에서 문제가 회귀된 것으로 간주하고 문제를 다시 엽니다.
이러한 상황은 다음과 같은 경우에 발생할 수 있습니다. 개발자가 버그를 수정하고 앱의 새 버전을 출시했지만 버그가 수정되지 않은 이전 버전에 아직 사용자가 있습니다. 만약 문제가 종료되었을 때 이전 버전 중 하나에서 비정상 종료 보고서를 보낸 적이 없는 경우 해당 사용자에게 버그가 발생하기 시작하면 비정상 종료 보고서가 회귀된 문제를 트리거합니다.
회귀 알고리즘으로 인해 문제가 다시 열리지 않도록 하려면 문제를 종료하는 대신 '숨기세요'.
플랫폼별 지원
다음 섹션에서는 플랫폼별 문제 해결 및 FAQ를 제공합니다(iOS+ | Android | Unity).
Apple 플랫폼 지원
dSYM이 누락되거나 업로드되지 않습니다.
프로젝트의 dSYM을 업로드하고 상세 출력을 얻으려면 다음을 확인하세요.
프로젝트의 빌드 단계에 Xcode가 빌드 시 프로젝트의 dSYM을 업로드하도록 허용하는 Crashlytics 실행 스크립트가 포함되어 있는지 확인합니다. 스크립트 추가 방법은 Crashlytics 초기화를 참조하세요. 프로젝트를 업데이트한 후 강제 비정상 종료를 통해 비정상 종료가 Crashlytics 대시보드에 표시되는지 확인합니다.
Firebase Console에 'dSYM 누락' 알림이 표시되면 Xcode를 확인하여 빌드에 대해 dSYM이 제대로 생성되는지 확인합니다.
Xcode가 dSYM을 제대로 생성하는데 여전히 dSYM이 누락된 것으로 나타난다면 dSYM을 업로드하는 동안 실행 스크립트 도구가 중단될 수 있습니다. 이 경우 다음을 각각 시도해 보세요.
사용 중인 Crashlytics가 최신 버전인지 확인합니다.
누락된 dSYM 파일을 수동으로 업로드합니다.
- 옵션 1: dSYMs 탭에서 콘솔 기반 '드래그 앤 드롭' 옵션을 사용하여 누락된 dSYM 파일이 담긴 ZIP 파일을 업로드합니다.
- 옵션 2:
upload-symbols스크립트를 사용하여 dSYMs 탭에서 제공된 UUID에 대해 누락된 dSYM 파일을 업로드합니다.
dSYM이 계속 누락된 것으로 나타나거나 업로드에 실패하면 Firebase 지원팀에 문의하세요. 이때 로그를 함께 제공합니다.
비정상 종료가 잘못 기호화되었습니다.
스택 트레이스가 잘못 기호화된 것 같다면 다음을 확인하세요.
앱 라이브러리의 프레임에 앱 코드에 대한 참조가 없는 경우
-fomit-frame-pointer앱 라이브러리에
(Missing)프레임이 여러 개 표시된다면 Firebase Console의 Crashlytics dSYMs 탭에 선택사항인 dSYM이 (영향을 받는 앱 버전에) 누락된 것으로 나열되어 있는지 확인합니다. 누락되었다면 이 FAQ 페이지의 dSYM이 누락되거나 업로드되지 않습니다.에서 'dSYM 누락 알림' 문제 해결 단계를 따르세요. 이러한 dSYM을 업로드해도 이미 발생한 비정상 종료는 기호화되지 않지만 이렇게 하면 이후의 비정상 종료를 기호화하는 데 도움이 됩니다.
macOS 또는 tvOS에 Crashlytics를 사용할 수 있나요?
예. macOS 및 tvOS 프로젝트에 Crashlytics를 구현할 수 있습니다. 비정상 종료가 Google Analytics에서 수집한 측정항목(비정상 종료가 발생하지 않은 사용자, 최신 출시 버전, 신속 알림, 탐색경로 로그)에 액세스할 수 있도록 v8.9.0 이상의 Google Analytics용 Firebase SDK를 포함하도록 하세요.
서로 다른 Apple 플랫폼에 기반한 여러 앱이 포함된 단일 Firebase 프로젝트에서 Crashlytics를 사용할 수 있나요?
이제 서로 다른 Apple 플랫폼(예: iOS, tvOS, Mac Catalyst)을 위해 앱을 개발했더라도 단일 Firebase 프로젝트에서 여러 앱의 비정상 종료를 보고할 수 있습니다. 이전에는 동일한 번들 ID가 포함된 앱을 개별 Firebase 프로젝트로 분리해야 했습니다.
Android 지원
Android 11 이상에서만 ANR이 보고되는 이유는 무엇인가요?
Crashlytics는 Android 11 이상을 실행하는 기기에서 Android 앱의 ANR 보고를 지원합니다. ANR을 수집하는 데 사용되는 기본 API(getHistoricalProcessExitReasons)는 SIGQUIT 또는 watchdog 기반 접근 방식보다 더 안정적입니다. 이 API는 Android 11 이상 기기에서만 사용할 수 있습니다.
일부 ANR에서 BuildId가 누락된 이유는 무엇인가요?
일부 ANR에서 BuildId가 누락된 경우 다음과 같이 문제를 해결합니다.
최신 Crashlytics Android SDK 및 Crashlytics Gradle 플러그인 버전을 사용 중인지 확인합니다.
Android 11 및 일부 Android 12 ANR에서
BuildId가 누락되면 오래된 SDK, Gradle 플러그인 또는 둘 다를 사용하고 있을 수 있습니다. 이러한 ANR의BuildId를 올바르게 수집하려면 다음 버전을 사용해야 합니다.- Crashlytics Android SDK v18.3.5 이상(Firebase BoM v31.2.2 이상)
- Crashlytics Gradle 플러그인 v2.9.4 이상
공유 라이브러리에 비표준 위치를 사용하고 있는지 확인하세요.
앱의 공유 라이브러리에
BuildId만 누락되었다면 공유 라이브러리의 표준 기본 위치를 사용하지 않았을 가능성이 높습니다. 이 경우 Crashlytics가 연결된BuildId를 찾지 못할 수 있습니다. 공유 라이브러리에는 표준 위치를 사용하는 것이 좋습니다.빌드 프로세스 중에
BuildId를 제거하지 않도록 합니다.다음 문제 해결 팁은 ANR 및 네이티브 충돌 모두에 적용됩니다.
바이너리에서
readelf -n을 실행하여BuildId가 있는지 확인합니다.BuildId가 없으면 빌드 시스템의 플래그에-Wl,--build-id를 추가합니다.APK 크기를 줄이기 위해 의도치 않게
BuildId를 제거하지 않았는지 확인합니다.라이브러리의 제거된 버전과 제거되지 않은 버전을 유지하는 경우 코드에서 올바른 버전을 가리켜야 합니다.
Crashlytics 대시보드의 ANR 보고서와 Google Play Console의 ANR 보고서의 차이점
Google Play와 Crashlytics 간에는 ANR 수가 일치하지 않을 수 있습니다. 이것은 ANR 데이터를 수집하고 보고하는 메커니즘에 차이가 있기 때문입니다. Crashlytics는 다음번 앱이 시작될 때 ANR을 보고하는 반면 Android vitals는 ANR이 발생한 후에 ANR 데이터를 보냅니다.
또한 Crashlytics는 Google Play 서비스 및 데이터 수집 동의가 허용된 기기의 ANR을 표시하는 Google Play와 달리 Android 11 이상을 실행하는 기기에서 발생하는 ANR만 표시합니다.
.java 문제로 라벨이 지정된 .kt 파일에서 비정상 종료가 표시되는 이유는 무엇인가요?
앱에서 파일 확장자를 노출하지 않는 난독 처리기를 사용하는 경우 Crashlytics는 기본적으로 .java 파일 확장자로 각 문제를 생성합니다.
Crashlytics에서 올바른 파일 확장자로 문제를 생성할 수 있도록 앱에서 다음 설정을 사용하는지 확인하세요.
- Android Gradle 4.2.0 이상 사용
- 난독화가 사용 설정된 상태로 R8 사용. 앱을 R8로 업데이트하려면 이 문서의 안내를 따르세요.
위에 설명된 설정으로 업데이트하면 기존 .java 문제와 중복되는 새로운 .kt 문제가 표시되기 시작할 수 있습니다. 이러한 상황에 대한 자세한 내용은 FAQ를 참고하세요.
기존 .java 문제와 중복된 .kt 문제가 표시되는 이유는 무엇인가요?
2021년 12월 중순부터, Crashlytics에서 Kotlin을 사용하는 애플리케이션 관련 지원을 개선했습니다.
최근까지는 사용 가능한 난독화 도구가 파일 확장자를 노출하지 않았으므로 Crashlytics는 기본적으로 .java 파일 확장자로 각 문제를 생성했습니다.
하지만 Android Gradle 4.2.0부터 R8에서 파일 확장자를 지원합니다.
이 업데이트를 통해 이제 Crashlytics는 앱 내에서 사용되는 각 클래스가 Kotlin으로 작성되었는지 확인하고 문제 서명에 올바른 파일 이름을 포함할 수 있습니다. 이제 앱에서 다음 설정을 사용하는 경우 비정상 종료가 .kt 파일에 올바르게 인식됩니다.
- 앱에서 Android Gradle 4.2.0 이상 사용
- 앱에서 난독화가 사용 설정된 상태로 R8 사용
이제 새로운 비정상 종료의 문제 서명에 올바른 파일 확장자가 포함되므로 기존의 .java 라벨로 된 문제와 실제로 중복되는 새로운 .kt 문제가 표시될 수 있습니다. Firebase Console에서는 새로운 .kt 문제가 기존의 .java 라벨로 된 문제와 중복되었을 가능성이 있는지 확인하고 안내합니다.
DexGuard에서 비정상 종료가 발생하지 않습니다.
다음 예외가 표시된다면 Firebase Crashlytics SDK와 호환되지 않는 DexGuard 버전을 사용 중일 수 있습니다.
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
이 예외는 앱에 장애를 일으키지는 않지만 비정상 종료 보고서를 보내는 것을 막습니다. 이 문제를 해결하려면 다음 안내를 따르세요.
최신 DexGuard 8.x 출시 버전을 사용 중인지 확인합니다. 최신 버전에는 Firebase Crashlytics SDK에서 요구하는 규칙이 포함됩니다.
DexGuard 버전을 변경하고 싶지 않으면 난독화 규칙(DexGuard 구성 파일에 있음)에 다음 줄을 추가해 보세요.
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
Crashlytics Gradle 플러그인 v3로 업그레이드하려면 어떻게 해야 하나요?
Crashlytics Gradle 플러그인의 최신 버전은 주 버전(v3.0.0)이며, 더 낮은 버전의 Gradle 및 Android Gradle 플러그인에 대한 지원을 중단하여 SDK를 현대화합니다. 또한 이 출시 버전의 변경사항은 AGP v8.1 이상의 문제를 해결하고 네이티브 앱 및 커스텀 빌드의 지원을 개선합니다.
최소 요구사항
Crashlytics Gradle 플러그인 v3의 최소 요구사항은 다음과 같습니다.
Android Gradle 플러그인 8.1 이상
Android 스튜디오의 최신 버전에서 Android Gradle 플러그인 업그레이드 어시스턴트를 사용하여 이 플러그인을 업그레이드하세요.Firebase의
google-servicesGradle 플러그인 4.4.1 이상
다음과 같이 프로젝트의 Gradle 빌드 파일에서 최신 버전을 지정하여 이 플러그인을 업그레이드하세요.
Kotlin
plugins { id("com.android.application") version "8.1.4" apply false id("com.google.gms.google-services") version "4.4.4" apply false ... }
Groovy
plugins { id 'com.android.application' version '8.1.4' apply false id 'com.google.gms.google-services' version '4.4.4' apply false ... }
Crashlytics 확장 프로그램 변경사항
Crashlytics Gradle 플러그인 v3를 사용하면 Crashlytics 확장 프로그램에 다음과 같은 브레이킹 체인지가 포함됩니다.
defaultConfigAndroid 블록에서 확장 프로그램이 삭제되었습니다. 대신 각 변형을 구성해야 합니다.지원 중단된
mappingFile필드가 삭제되었습니다. 대신 병합된 매핑 파일은 이제 자동으로 제공됩니다.지원 중단된
strippedNativeLibsDir필드가 삭제되었습니다. 대신 모든 네이티브 라이브러리에unstrippedNativeLibsDir를 사용해야 합니다.unstrippedNativeLibsDir필드를 누적하도록 변경했습니다.여러 디렉터리가 있는 예시 보기
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") } } } }
uploadCrashlyticsSymbolFilesBasicReleaseMY/NATIVE/LIBS의 기호만 업로드하지만,uploadCrashlyticsSymbolFilesFeatureXReleaseMY/NATIVE/LIBS및MY/FEATURE_X/LIBS의 기호를 모두 업로드합니다.폐쇄 필드
symbolGenerator를 두 개의 새로운 최상위 필드로 대체했습니다.symbolGeneratorType:"breakpad"(기본값) 또는"csym"의 문자열breakpadBinary: 로컬dump_syms바이너리 재정의 파일
확장 프로그램 업그레이드 방법 예시
Kotlin
| 전 |
buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGenerator( closureOf<SymbolGenerator> { symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } ) } } } |
| v3 |
buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } |
Groovy
| 전 |
buildTypes { release { firebaseCrashlytics { // ... symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } } |
| v3 |
buildTypes { release { firebaseCrashlytics { // ... symbolGeneratorType "breakpad" breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } |
Android-NDK 관련 지원
Crashlytics 대시보드와 logcat 간의 NDK 스택 트레이스 차이점
LLVM 및 GNU 도구 모음에는 앱 바이너리의 읽기 전용 세그먼트에 대한 고유 기본값과 처리 방식이 있으므로 Firebase Console에서 일관되지 않은 스택 트레이스를 생성할 수 있습니다. 이 문제를 완화하려면 빌드 프로세스에 다음 링커 플래그를 추가하세요.
LLVM 도구 모음의
lld링커를 사용하는 경우 다음을 추가합니다.-Wl,--no-rosegmentGNU 도구 모음의
ld.gold링커를 사용하는 경우 다음을 추가합니다.-Wl,--rosegment
스택 트레이스 불일치가 계속 발생하거나 도구 모음과 관련된 플래그가 없는 경우 대신 빌드 프로세스에 다음을 추가해 보세요.
-fno-omit-frame-pointerNDK에 자체 Breakpad 기호 파일 생성기 바이너리를 사용하려면 어떻게 해야 하나요?
Crashlytics 플러그인은 맞춤설정된 Breakpad 기호 파일 생성기를 번들로 제공합니다.
Breakpad 기호 파일을 생성하는 데 자체 바이너리를 사용하려면(예: 소스에서 빌드 체인에 모든 네이티브 실행 파일을 빌드하려는 경우) 선택사항인 symbolGeneratorBinary 확장 프로그램 속성을 사용하여 해당 실행 파일의 경로를 지정하세요.
다음 두 가지 방법 중 하나를 사용하여 Breakpad 기호 파일 생성기 바이너리에 대한 경로를 지정할 수 있습니다.
옵션 1:
build.gradle파일의firebaseCrashlytics확장 프로그램을 통해 경로 지정앱 수준
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 속성 파일의 속성 줄을 통해 경로 지정
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
Crashlytics는 armeabi를 지원하나요?
Firebase Crashlytics NDK는 ARMv5(armeabi)를 지원하지 않습니다. 이 ABI에 대한 지원은 NDK r17부터 삭제되었습니다.
Unity 지원
Crashlytics 대시보드에서 Android 앱의 기호화되지 않은 스택 트레이스가 표시됩니다.
Unity IL2CPP를 사용 중인데 기호화되지 않은 스택 트레이스가 표시되면 다음을 시도해 보세요.
Crashlytics Unity SDK v8.6.1 이상을 사용 중인지 확인합니다.
기호 파일을 생성하여 업로드하려면 Firebase CLI
crashlytics:symbols:upload명령어를 설정하고 실행해야 합니다.Firebase Console에서 출시 빌드 또는 기호화된 스택 트레이스를 보려는 빌드를 만들 때마다 이 CLI 명령어를 실행해야 합니다. 읽을 수 있는 비정상 종료 보고서 받기에서 자세히 알아보세요.
Crashlytics를 IL2CPP를 사용하는 앱과 함께 사용할 수 있나요?
예, Crashlytics는 IL2CPP를 사용하는 앱에 대한 기호화된 스택 트레이스를 표시할 수 있습니다. 이 기능은 Android 또는 Apple 플랫폼에서 출시된 앱에서 사용할 수 있습니다. 필요한 작업은 다음과 같습니다.
Crashlytics Unity SDK v8.6.0 이상을 사용 중인지 확인합니다.
플랫폼에 필요한 작업을 완료합니다.
Apple 플랫폼 앱: 특별한 작업이 필요하지 않습니다. Apple 플랫폼 앱의 경우 Firebase Unity 편집기 플러그인이 기호를 업로드하도록 Xcode 프로젝트를 자동으로 구성해 줍니다.
Android 앱: 기호 파일을 생성하여 업로드하려면 Firebase CLI
crashlytics:symbols:upload명령어를 설정하고 실행해야 합니다.Firebase Console에서 출시 빌드 또는 기호화된 스택 트레이스를 보려는 빌드를 만들 때마다 이 CLI 명령어를 실행해야 합니다. 읽을 수 있는 비정상 종료 보고서 받기에서 자세히 알아보세요.
포착되지 않은 예외를 심각한 예외로 보고
Crashlytics는 포착되지 않은 예외를 심각한 예외로 보고할 수 있습니다(Unity SDK v10.4.0부터). 다음 FAQ는 이 기능을 사용하는 근거와 권장사항을 설명하는 데 도움이 됩니다.
앱에서 포착되지 않은 예외를 심각한 예외로 보고해야 하는 이유는 무엇인가요?
포착되지 않은 예외를 심각한 예외로 보고하면 앱이 계속 실행되어도 어떤 예외로 인해 게임을 플레이할 수 없게 되는지 보다 현실적으로 파악할 수 있습니다.
심각한 오류 보고를 시작하면 비정상 종료가 발생하지 않은 사용자(CFU) 비율이 감소할 수 있지만, CFU 측정항목이 최종 사용자의 앱 경험을 더 잘 나타냅니다.
어떤 예외가 심각한 오류로 보고되나요?
Crashlytics가 포착되지 않은 예외를 심각한 오류로 보고하려면 다음 두 조건을 모두 충족해야 합니다.
앱에서 초기화하는 동안
ReportUncaughtExceptionsAsFatal속성을true로 설정해야 합니다.앱(또는 앱에 포함된 라이브러리)에서 포착되지 않는 예외가 발생합니다. 생성되었지만 발생하지 않은 예외는 포착되지 않은 예외로 간주되지 않습니다.
포착되지 않은 예외를 심각한 예외로 보고할 수 있도록 사용 설정한 후 새로운 심각한 오류가 많이 발생했습니다. 이러한 예외를 적절하게 처리하려면 어떻게 해야 하나요?
포착되지 않은 예외가 심각한 예외로 보고되기 시작하면 다음과 같은 방법으로 이러한 포착되지 않은 예외를 처리할 수 있습니다.
발생한 예외 포착 및 처리
예상치 못한 상태나 예외 상태를 반영하기 위해 예외가 생성되고 발생합니다. 발생한 예외가 반영된 문제를 해결하려면 프로그램을 알려진 상태(예외 처리라고 하는 프로세스)로 되돌려야 합니다.
프로그램을 알려진 상태로 되돌릴 수 없는 경우가 아니라면 예상되는 모든 예외를 포착하여 처리하는 것이 좋습니다.
어떤 종류의 예외를 포착하고 어떤 코드로 처리할지를 제어하려면 try-catch 블록에서 예외를 생성할 수 있는 코드를 래핑합니다.
특정 예외를 적절하게 처리하려면 catch문의 조건 범위가 최대한 좁아야 합니다.
Unity 또는 Crashlytics에서 예외 로깅
문제를 디버그하는 데 도움이 되도록 Unity 또는 Crashlytics에서 예외를 기록하는 방법은 여러 가지가 있습니다.
Crashlytics 사용 시 권장되는 가장 일반적인 두 가지 옵션은 다음과 같습니다.
옵션 1: Unity 콘솔에서 출력하되 개발 또는 문제 해결 중에 Crashlytics에 보고하지 않습니다.
- Unity 콘솔에 예외 콘텐츠를 출력하고 예외를 다시 발생시키지 않는
Debug.Log(exception),Debug.LogWarning(exception),Debug.LogError(exception)를 사용하여 Unity 콘솔에 출력합니다.
- Unity 콘솔에 예외 콘텐츠를 출력하고 예외를 다시 발생시키지 않는
옵션 2: 다음 상황에 대해 Crashlytics 대시보드에서 통합 보고를 하려면 Crashlytics에 업로드합니다.
- 발생 가능한 후속 Crashlytics 이벤트를 디버깅하기 위해 예외를 로깅할 필요가 있는 경우에는
Crashlytics.Log(exception.ToString())를 사용합니다. - 포착 및 처리되더라도 예외를 Crashlytics에 계속 보고해야 하는 경우
Crashlytics.LogException(exception)을 사용하여 심각하지 않은 이벤트로 로깅합니다.
- 발생 가능한 후속 Crashlytics 이벤트를 디버깅하기 위해 예외를 로깅할 필요가 있는 경우에는
그러나 심각한 이벤트를 Unity 클라우드 진단에 수동으로 보고하려면 Debug.LogException을 사용하면 됩니다. 이 옵션은 옵션 1과 같이 Unity 콘솔에 예외를 출력하지만 발생 및 포착 여부와 관계없이 예외가 발생합니다. 비로컬에서 오류가 발생합니다. 즉, try-catch 블록이 있는 주변 Debug.LogException(exception)도 여전히 포착되지 않은 예외를 발생시킵니다.
따라서 다음 모든 작업을 실행하려는 경우에만 Debug.LogException을 호출합니다.
- Unity 콘솔에 예외를 출력하려면 다음 안내를 따르세요.
- Crashlytics에 예외를 심각한 이벤트로 업로드합니다.
- 예외를 발생시키려면 포착되지 않은 예외로 처리하고 Unity 클라우드 진단에 보고해야 합니다.
포착된 예외를 Unity 콘솔에 출력하고 또한 심각하지 않은 이벤트로 Crashlytics에 업로드하려면 다음 단계를 따르세요.
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
//
}
통합 지원
또한 앱이 Google Mobile Ads SDK를 사용하지만 비정상 종료가 발생하지 않습니다.
프로젝트에서 Google Mobile Ads SDK와 함께 Crashlytics를 사용하는 경우 예외 핸들러를 등록할 때 비정상 종료 보고 도구가 간섭할 가능성이 있습니다. 이 문제를 해결하려면 disableSDKCrashReporting을 호출하여 Mobile Ads SDK에서 비정상 종료 보고를 사용 중지하세요.
내 BigQuery 데이터 세트는 어디에 있나요?
Firebase는 BigQuery로의 데이터 내보내기를 설정할 때 선택한 데이터 세트 위치로 데이터를 내보냅니다.
이 위치는 Crashlytics 데이터 세트와 Firebase 세션 데이터 세트 모두에 적용됩니다(세션 데이터 내보내기가 사용 설정된 경우).
이 위치는 BigQuery로 내보낸 데이터에만 적용되며 Firebase Console의 Crashlytics 대시보드 또는 Android 스튜디오에서 사용하기 위해 저장된 데이터의 위치에는 영향을 미치지 않습니다.
데이터 세트를 만든 후에는 위치를 변경할 수 없지만 데이터 세트를 다른 위치에 복사하거나 다른 위치에서 데이터 세트를 수동으로 이동(다시 만들기)할 수 있습니다. 자세한 내용은 기존 내보내기 위치 변경을 참조하세요.
BigQuery의 새 내보내기 인프라로 업그레이드하는 방법
2024년 10월 중순, Crashlytics는 Crashlytics 데이터를 BigQuery로 일괄 내보내기 위한 새 인프라를 출시했습니다.
2024년 10월 이후에 일괄 내보내기를 사용 설정한 경우 Firebase 프로젝트에서 자동으로 새 내보내기 인프라를 사용합니다. 이와 관련해 별도의 조치를 취할 필요는 없습니다.
2024년 10월 이전 또는 도중에 일괄 내보내기를 사용 설정한 경우 이 FAQ의 정보를 검토하여 조치를 취해야 하는지 확인하세요.
모든 Firebase 프로젝트는 2026년 1월 9일부터 새 일괄 내보내기 인프라로 자동 업그레이드됩니다. 이 날짜 전에 업그레이드할 수 있지만 BigQuery 배치 테이블이 업그레이드의 기본 요건을 충족하는지 확인해야 합니다.
새 인프라로 업그레이드할 수 있지만 BigQuery 배치 테이블이 업그레이드의 기본 요건을 충족하는지 확인해야 합니다.
새 인프라를 사용 중인지 확인
2024년 10월 중순 이후에 일괄 내보내기를 사용 설정한 경우 Firebase 프로젝트에서 자동으로 새 내보내기 인프라를 사용합니다.
프로젝트에서 사용 중인 인프라를 확인할 수 있습니다. Google Cloud 콘솔로 이동하여 '데이터 전송 구성'에 Firebase Crashlytics with Multi-Region Support 라벨이 지정되어 있으면 프로젝트에서 새 내보내기 인프라를 사용 중인 것입니다.
이전 내보내기 인프라와 새 내보내기 인프라의 중요한 차이점
새 인프라는 미국 이외의 Crashlytics 데이터 세트 위치를 지원합니다.
2024년 10월 중순 이전에 내보내기를 사용 설정하고 그리고 새 내보내기 인프라로 업그레이드하면 원하는 경우 데이터 내보내기 위치를 변경할 수 있습니다.
2024년 10월 중순 이후에 내보내기를 사용 설정하면 설정 중에 데이터 내보내기 위치를 선택하라는 메시지가 표시되었습니다.
새 인프라는 내보내기를 사용 설정하기 전의 데이터 백필을 지원하지 않습니다.
이전 인프라는 내보내기를 사용 설정한 날짜로부터 최대 30일 전까지 백필을 지원했습니다.
새 인프라는 최대 지난 30일 동안 또는 BigQuery로 내보내기를 사용 설정한 가장 최근 날짜(둘 중 최근)에 대해 백필을 지원합니다.
새 인프라는 Firebase 프로젝트의 Firebase 앱에 설정된 식별자를 사용하여 BigQuery 배치 테이블의 이름을 지정합니다.
이전 인프라는 앱의 바이너리에 있는 번들 ID 또는 패키지 이름을 기반으로 이름을 지정하여 배치 테이블에 데이터를 작성했습니다.
새 인프라는 Firebase 프로젝트에 등록된 Firebase 앱에 설정된 번들 ID 또는 패키지 이름을 기반으로 이름을 지정하여 배치 테이블에 데이터를 작성합니다.
1단계: 업그레이드의 기본 요건
기존 BigQuery 배치 테이블이 Firebase 프로젝트에 등록된 Firebase 앱에 설정된 번들 ID 또는 패키지 이름과 일치하는 식별자를 사용하는지 확인합니다. 일치하지 않으면 내보낸 일괄 데이터가 중단될 수 있습니다. 대부분의 프로젝트는 적절하고 호환되는 상태이지만 업그레이드하기 전에 확인하는 것이 중요합니다.
Firebase Console에서 Firebase 프로젝트에 등록된 모든 Firebase 앱을 확인할 수 있습니다. settings 프로젝트 설정으로 이동한 다음 내 앱 카드로 스크롤하여 모든 Firebase 앱과 해당 정보를 확인합니다.
Google Cloud 콘솔의 BigQuery 페이지에서 모든 BigQuery 배치 테이블을 확인할 수 있습니다.
예를 들어 업그레이드에 문제가 없는 이상적인 상태는 다음과 같습니다.
com_yourcompany_yourproject_IOS라는 배치 테이블과 Firebase 프로젝트에 번들 IDcom.yourcompany.yourproject로 등록된 Firebase iOS+ 앱이 있습니다.com_yourcompany_yourproject_ANDROID라는 배치 테이블과 Firebase 프로젝트에 패키지 이름com.yourcompany.yourproject로 등록된 Firebase Android 앱이 있습니다.
배치 테이블 이름이 등록된 Firebase 앱에 설정된 식별자와 일치하지 않는 경우 일괄 내보내기가 중단되지 않도록 수동으로 업그레이드하기 전 또는 2026년 1월 9일 전에 이 페이지 하단의 안내를 따르세요.
2단계: 새 인프라로 수동 업그레이드
2024년 10월 중순 이전에 일괄 내보내기를 사용 설정한 경우 Firebase Console에서 Crashlytics 데이터 내보내기를 사용 중지했다가 다시 사용 설정하기만 하면 새 인프라로 수동 업그레이드할 수 있습니다.
자세한 단계는 다음과 같습니다.
Firebase 콘솔에서 통합 페이지로 이동합니다.
BigQuery 카드에서 관리를 클릭합니다.
Crashlytics 슬라이더를 사용 중지하여 내보내기를 사용 중지합니다. 메시지가 표시되면 데이터 내보내기를 중지할 것인지 확인합니다.
즉시 Crashlytics 슬라이더를 다시 사용 설정하여 내보내기를 다시 사용 설정합니다. 메시지가 표시되면 데이터를 내보낼 것인지 확인합니다.
BigQuery로의 Crashlytics 데이터 내보내기에 이제 새 내보내기 인프라가 사용됩니다.
기존 배치 테이블 이름이 Firebase 앱 식별자와 일치하지 않음
기존 배치 테이블 이름이 등록된 Firebase 앱에 설정된 번들 ID 또는 패키지 이름과 일치하지 않는 경우 이 섹션을 펼치고 내보낸 일괄 데이터가 중단되지 않도록 옵션 중 하나를 구현합니다.
이 상태의 기존 BigQuery 배치 테이블이 있는 경우 Firebase의 새로운 BigQuery로의 일괄 내보내기 인프라와 호환되지 않는 것입니다. 모든 Firebase 프로젝트는 2026년 1월 9일부터 새로운 내보내기 인프라로 자동 마이그레이션됩니다.
Crashlytics 데이터를 BigQuery로 일괄 내보내는 데 서비스 중단이 발생하지 않도록 하려면 수동으로 업그레이드하기 전 또는 2026년 1월 9일 전에 이 섹션의 안내를 따르세요.
내보내기 인프라에서 식별자를 사용하여 BigQuery 테이블에 데이터를 작성하는 방법 이해하기
다음은 두 내보내기 인프라가 Crashlytics 데이터를 BigQuery 배치 테이블에 작성하는 방법입니다.
기존 내보내기 인프라: 앱의 바이너리에 있는 번들 ID 또는 패키지 이름을 기반으로 하는 이름으로 테이블에 데이터를 작성합니다.
새 내보내기 인프라: Firebase 프로젝트에 등록된 Firebase 앱에 설정된 번들 ID 또는 패키지 이름을 기반으로 하는 이름으로 테이블에 데이터를 작성합니다.
안타깝게도 앱의 바이너리에 있는 번들 ID 또는 패키지 이름이 Firebase 프로젝트에 등록된 Firebase 앱에 설정된 번들 ID 또는 패키지 이름과 일치하지 않는 경우가 있습니다. 이는 일반적으로 누군가 앱 등록 중에 실제 식별자를 입력하지 않은 경우에 발생합니다.
업그레이드하기 전에 이 문제가 해결되지 않으면 어떻게 되나요?
이 두 위치의 식별자가 일치하지 않으면 새 내보내기 인프라로 업그레이드한 후 다음과 같은 문제가 발생합니다.
Crashlytics 데이터가 새 BigQuery 배치 테이블에 작성되기 시작합니다. 즉, Firebase 프로젝트에 등록된 Firebase 앱에 설정된 번들 ID 또는 패키지 이름을 기반으로 이름이 지정된 새 테이블입니다.
앱의 바이너리에 있는 식별자를 기반으로 이름이 지정된 기존의 '레거시' 테이블에는 더 이상 데이터가 작성되지 않습니다.
일치하지 않는 식별자의 시나리오 예시
BigQuery 배치 테이블 이름에는 앱의 플랫폼을 나타내기 위해 _IOS 또는 _ANDROID가 자동으로 추가됩니다.
| 앱의 바이너리에 있는 식별자 | Firebase 앱에 설정된 식별자 | 이전 동작 | 새 내보내기 인프라로 업그레이드 후 동작 |
솔루션 |
|---|---|---|---|---|
foo |
bar |
앱의 바이너리에 있는 식별자(foo)에 따라 이름이 지정된 단일 테이블에 작성합니다.
|
Firebase 앱에 설정된 식별자(bar)에 따라 이름이 지정된 단일 테이블을 만든 다음 테이블에 작성합니다.
|
아래에 설명된 옵션 1 또는 2를 구현합니다. |
foo |
bar, qux 등 |
앱의 바이너리에 있는 식별자(foo)에 따라 이름이 지정된 단일 테이블에 작성합니다.
|
Firebase 앱에 설정된 식별자(bar, qux 등)에 따라 이름이 지정된 여러 테이블을 만든* 다음 테이블에 작성합니다.
|
아래에 설명된 옵션 2를 구현합니다. |
foo, baz 등 |
bar |
앱의 바이너리에 있는 여러 식별자(foo, baz 등)에 따라 이름이 지정된 여러 테이블에 작성합니다.
|
Firebase 앱에 설정된 식별자(bar)에 따라 이름이 지정된 단일 테이블을 만든** 다음 모든 앱의 데이터를 테이블에 작성합니다.
|
구현할 수 있는 옵션이 없습니다.
데이터와 함께 내보낸 앱의 |
* 앱 바이너리의 식별자가 Firebase 앱에 설정된 식별자 중 하나와 일치하는 경우 새 내보내기 인프라에서는 해당 식별자에 대한 새 테이블을 만들지 않습니다. 대신 해당 앱의 데이터를 계속 작성합니다. 다른 모든 앱은 새 테이블에 작성됩니다.
** 앱 바이너리의 식별자 중 하나가 Firebase 앱에 설정된 식별자와 일치하는 경우 새 내보내기 인프라에서는 새 테이블을 만들지 않습니다. 대신 이 테이블을 유지하고 모든 앱의 데이터를 이 테이블에 작성하기 시작합니다.
서비스 중단을 방지하는 옵션
서비스 중단을 방지하려면 수동으로 업그레이드하기 전에 또는 2026년 1월 9일 전에 아래에 설명된 옵션 중 하나에 대한 안내를 따르세요.
옵션 1:
새 내보내기 인프라에서 만든 새 테이블을 사용합니다. 기존 테이블의 데이터를 새 테이블로 복사합니다.Firebase Console에서 연결된 앱의 내보내기를 사용 중지했다가 다시 사용 설정하여 새 내보내기 인프라로 업그레이드합니다.
이 작업은 Firebase 프로젝트에 등록된 Firebase 앱에 설정된 번들 ID 또는 패키지 이름을 기반으로 하는 이름으로 새 배치 테이블을 만듭니다.
Google Cloud 콘솔에서 방금 만든 새 테이블로 기존 테이블의 모든 데이터를 복사합니다.
배치 테이블에 종속된 다운스트림 종속 항목이 있는 경우 새 테이블을 사용하도록 변경합니다.
옵션 2:
기존 테이블에 계속 작성합니다. 이를 위해 BigQuery 구성에서 일부 기본값을 재정의합니다.Firebase Console에서 배치 테이블 이름과 식별자가 일치하지 않는 앱의 Firebase 앱 ID(예:
1:1234567890:ios:321abc456def7890)를 찾아 메모합니다.
settings 프로젝트 설정으로 이동한 다음 내 앱 카드로 이동하여 모든 Firebase 앱과 해당 정보를 확인합니다.Firebase Console에서 연결된 앱의 내보내기를 사용 중지했다가 다시 사용 설정하여 새 내보내기 인프라로 업그레이드합니다.
이 작업은 다음 두 가지 작업을 실행합니다.
Firebase 프로젝트에 등록된 Firebase 앱에 설정된 번들 ID 또는 패키지 이름을 기반으로 이름이 지정된 새 배치 테이블을 만듭니다. (이 테이블은 나중에 삭제하지만 아직은 삭제하지 마세요.)
소스
Firebase Crashlytics with Multi-Region Support로 BigQuery '데이터 전송 구성'을 만듭니다.
Google Cloud 콘솔에서 데이터가 기존 테이블에 계속 작성되도록 새 '데이터 전송 구성'을 변경합니다.
BigQuery > 데이터 전송으로 이동하여 '데이터 전송 구성'을 확인합니다.
소스
Firebase Crashlytics with Multi-Region Support가 있는 구성을 선택합니다.오른쪽 상단에 있는 수정을 클릭합니다.
데이터 소스 세부정보 섹션에서 gmp_app_id 목록과 client_namespace 목록을 찾습니다.
BigQuery에서 Firebase 앱 ID는
gmp_app_id라고 합니다. 기본적으로 BigQuery의client_namespace값은 앱의 상응하는 고유한 번들 ID/패키지 이름이지만 이 기본 구성을 재정의합니다.BigQuery는 연결된 각 Firebase 앱이 작성하는 배치 테이블의 이름에
client_namespace값을 사용합니다.기본 설정을 재정의하려는 Firebase 앱의 gmp_app_id를 찾습니다. client_namespace 값을 Firebase 앱이 대신 쓸 테이블의 이름으로 변경합니다(일반적으로 앱이 기존 내보내기 인프라로 쓰기 작업을 수행했던 기존 테이블의 이름).
구성 변경사항을 저장합니다.
기존 테이블에 데이터가 누락된 날짜에 대해 백필을 예약합니다.
백필이 완료되면 새 내보내기 인프라에서 자동으로 생성된 새 테이블을 삭제합니다.