Вопрос или проблема
Я применяю Firebase Crashlytics к проекту.
Проекты, которые мы разрабатываем, включают приложения и SDK.
SDK содержит файл engine.so. Чтобы избежать стриппинга, мы реализовали его следующим образом.
packagingOptions {
doNotStrip "*/arm64-v8a/*.so"
doNotStrip "*/armeabi-v7a/*.so"
jniLibs {
useLegacyPackaging = true
}
}
После сборки aar для sdk-приложения, когда я проверил файл engine.so внутри,
$ FILE engine.so
engine.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), динамически связанный, с debug_info, не стрипованный
Я подтвердил, что он содержит debug_info.
После применения SDK к приложению, реализация Crashlytics была выполнена следующим образом.
build.gradle (проект)
plugins {
//...
id 'com.google.gms.google-services' version '4.4.2' apply false
id 'com.google.firebase.crashlytics' version '3.0.2' apply false
}
build.gradle (приложение)
plugins {
//...
id 'com.google.gms.google-services'
id 'com.google.firebase.crashlytics'
}
android {
buildTypes {
debug {
firebaseCrashlytics {
mappingFileUploadEnabled true
nativeSymbolUploadEnabled true
}
}
}
tasks.configureEach { task -> if (task.name.startsWith('assemble') && task.name.endsWith("Debug")) task.finalizedBy "uploadCrashlyticsSymbolFile" + task.name.substring('assemble'.length()) }
dependencies {
// ...
implementation platform('com.google.firebase:firebase-bom:33.2.0')
implementation 'com.google.firebase:firebase-crashlytics'
implementation 'com.google.firebase:firebase-crashlytics-ndk'
}
Применение Crashlytics прошло успешно. В случае сбоя это можно было увидеть в Crashlytics консоли Firebase.
Однако столкновение на engine.so остается невыявленным и показывает неправильный стек вызовов. Crashlytics консоли Firebase
null pointer dereference: SIGSEGV 0x0000000000000000
#00 pc 0x6fa91b5b88
#01 pc 0x6fa91b5b6c
#02 pc 0x218964 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#03 pc 0x285ff0 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#04 pc 0x3dce0c libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#05 pc 0x3ea4c8 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#06 pc 0xa16ffc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#07 pc 0x3e5064 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#08 pc 0x760518 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#09 pc 0xa16ffc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#10 pc 0x77ebfc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#11 pc 0x203814 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#12 pc 0xa16ffc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#13 pc 0x2000fc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#14 pc 0xa16ffc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#15 pc 0x3dce0c libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#16 pc 0x3e4584 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#17 pc 0xa16ffc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#18 pc 0x800ba4 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#19 pc 0x3e5040 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#20 pc 0x760518 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#21 pc 0xa16ffc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#22 pc 0x76d498 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#23 pc 0xa16ffc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#24 pc 0x77f2a0 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#25 pc 0x77ebfc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#26 pc 0x203814 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#27 pc 0xa16ffc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#28 pc 0x2000fc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#29 pc 0xa16ffc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#30 pc 0x3dce0c libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#31 pc 0x2000fc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#32 pc 0x3e4584 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#33 pc 0xa16ffc libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
#34 pc 0x3e5040 libart.so (BuildId: 4752fd49b3f5a76fd788c235cf2fb143)
Стек вызовов не найден для engine.so .
Я также пытался загрузить символы с помощью Firebase CLI.
app/build/intermidiates/merged_native_libs/appDebug/out/lib
Сжать папку
А также,
firebase crashlytics:symbols:upload --app="appId" path\lib.zip
Тем не менее, я не смог найти стек вызовов Crash для engine.so в Crashlytics.
Как загрузить ndk-символы для Crashlytics?
nativeSymbolUploadEnabled true
и ./gradlew :app:assembleAppDebug uploadCrashlyticsSymbolFileAppDebug
и Firebase CLI
firebase crashlytics:symbols:upload –app=”appId” path/lib.zip
Ответ или решение
Чтобы успешно загрузить символы для Crashlytics в вашем Android проекте, содержащем родной код, необходимо следовать определённой последовательности шагов, которые обеспечат корректную интеграцию Android NDK с Firebase Crashlytics. В данном ответе мы рассмотрим все важные аспекты и шаги, чтобы гарантировать, что вы сможете видеть полные трассировки стека для вашего engine.so
файла.
Шаг 1: Настройка Gradle
Перед тем как загружать символы, убедитесь, что у вас правильно настроен файл build.gradle
. Судя по вашему описанию, вам уже удалось включить необходимые зависимости и настройки для Crashlytics. Однако, стоит дважды проверить, что в секции buildTypes
действительно включены все необходимые параметры:
android {
buildTypes {
debug {
firebaseCrashlytics {
mappingFileUploadEnabled true
nativeSymbolUploadEnabled true
}
}
}
}
Также убедитесь, что у вас заданы задачи для загрузки символов:
tasks.configureEach { task ->
if (task.name.startsWith('assemble') && task.name.endsWith("Debug"))
task.finalizedBy "uploadCrashlyticsSymbolFile" + task.name.substring('assemble'.length())
}
Шаг 2: Проверка файла engine.so
Проверьте содержимое вашего engine.so
файла, чтобы удостовериться, что он действительно содержит отладочную информацию. Выполните следующую команду в терминале:
file engine.so
Ожидаемый вывод должен содержать информацию о том, что файл не был «стропирован» и содержит отладочную информацию.
Шаг 3: Генерация и загрузка символов
При сборке вашего проекта для debug
конфигурации, Gradle автоматически должен запускать задачу для загрузки символов. Так как вы упомянули, что использовали команду:
./gradlew :app:assembleAppDebug uploadCrashlyticsSymbolFileAppDebug
Убедитесь, что эта команда завершилась успешно, и вам следует обратить внимание на возникшие предупреждения или ошибки в процессе выполнения.
Шаг 4: Использование Firebase CLI
Если загрузка через Gradle не сработала, вы можете воспользоваться Firebase CLI. Убедитесь, что вы используете правильный путь к вашему файлу .zip
, который должен содержать ваши скомпилированные символы:
firebase crashlytics:symbols:upload --app="appId" path/lib.zip
Также стоит убедиться, что структура вашего .zip
файла соответствует необходимым требованиям Firebase. Он должен включать скомпилированные символы из app/build/intermediates/merged_native_libs/appDebug/out/lib
.
Шаг 5: Проверка на консоли Firebase
После успешной загрузки, ожидайте некоторое время, прежде чем проверять консоль Firebase. Убедитесь, что после каждого краша ваше логирование настроено корректно, и Crashlytics может собирать информацию о сбоях. Вы должны также использовать следующий код для инициализации Crashlytics в вашем приложении:
FirebaseCrashlytics.getInstance().setCrashlyticsCollectionEnabled(true);
Дополнительные рекомендации
-
Проверка логов: Внимательно просматривайте журналы (logs) во время загрузки символов. Они могут предоставить подсказки о том, что пошло не так.
-
Обновление библиотек: Убедитесь, что все ваши зависимости, включая
firebase-crashlytics
, актуальны. Возможно, существуют более новые версии, которые исправляют известные проблемы. -
Контроль версий: При изменении конфигурации и сборке, следите за версионностью вашего приложения и синхронизируйте версии с Symbol files.
Следуя этим шагам, вы сможете успешно интегрировать Crashlytics для NDK в вашем проекте и получить корректные трассировки стека, которые помогут вам быстрее идентифицировать и исправлять ошибки, возникающие в родном коде.