7

Our native Crashlytics crash reports are missing all symbol information as of late. I had hoped that the latest Crashlytics NDK would resolve the issue, but it does not.

I see that there is a similar query out there, but in this case I am not using Firebase, just Crashlytics, and had been doing so successfully for quite some time.

Our build.gradle (using CMake and the Gradle 3.0.0 or 3.1.0 Android plugin -- same issue either way) contains:

buildscript {
    ...
    dependencies {
        ...
        classpath 'io.fabric.tools:gradle:1.+'
    }
}
...
dependencies {
    ...
    implementation('com.crashlytics.sdk.android:crashlytics:2.9.1@aar') {
        transitive = true
    }
    implementation 'com.crashlytics.sdk.android:crashlytics-ndk:2.0.2'
}

Which would seem to be correct and using all the latest Fabric components unless I am missing something.

I then added:

crashlytics {
    enableNdk true
    manifestPath 'AndroidManifest.xml'
}

tasks.whenTaskAdded { task ->
    if (task.name.startsWith('assemble')) {
        task.finalizedBy "crashlyticsUploadSymbols" + task.name.substring('assemble'.length())
    }
}

none of which I had needed some time ago when this was working. (And, no, just adding the crashlytics block was insufficient.)

This gives me symbols for the .cpp files I actually build in this project. It still has no symbols for the .a file I link in, nor even for libc++_shared.so!

user6519354
  • 169
  • 1
  • 7
  • 1
    you can add Fabric plugin to Android studio. https://examples.javacodegeeks.com/android/android-fabric-crashlytics-integration/ – Nik Mar 27 '18 at 11:36
  • How do you upload the symbols to Crashlytics? – Alex Cohn Mar 27 '18 at 12:09
  • I had been letting the Gradle build just do it via "apply plugin: 'io.fabric'". Searching the latest Gradle debug output, however, the fabric plugin runs and fabricGenerateResourcesGenuineDebug (for the GenuineDebug build variant) runs, but I see no evidence of any other fabric* or crash* task running at all. – user6519354 Mar 31 '18 at 15:54
  • Also, it would be immensely helpful if the Fabric Gradle plugin had a verbose mode where it actually explained itself, i.e. which directories it is scanning, which .so's it is processing, which ones it is not, etc. As it stands it's a mysterious black box that I've now cajoled into addressing part of one of my .so files, whereas it used to address this entire .so and the C++ standard library. – user6519354 Apr 09 '18 at 11:36
  • 1
    I have the same issue... Not a lot of help from the fabric team either... If you get the answer, let me know! – gxela Jun 19 '18 at 13:52
  • Nice way to trigger the upload task automatically. Thanks for sharing! Did you have any luck getting it to pull symbols from your own .so files? Are you sure the copies in jniLibs are unstripped? – tmm1 Jul 26 '18 at 18:38
  • I was able to get my own .so symbolized (check `app/build/fabric/*/csyms` to verify cSYM is generated) by adding them to my Android.mk using the `include $(PREBUILT_SHARED_LIBRARY)` helper. – tmm1 Jul 26 '18 at 23:42

2 Answers2

0

For Java

https://docs.fabric.io/android/crashlytics/dex-and-proguard.html

Configure ProGuard and DexGuard

We’ve made it simple to set up ProGuard or DexGuard in your app and receive deobfuscated crash reports. First of all, Fabric uses annotations internally, so add the following line to your configuration file:

-keepattributes *Annotation*

Next, in order to provide the most meaningful crash reports, add the following line to your configuration file:

-keepattributes SourceFile,LineNumberTable

Crashlytics will still function without this rule, but your crash reports will not include proper file names or line numbers.

For C++

https://docs.fabric.io/android/crashlytics/ndk.html

Specifying the path to debug and release binaries

To properly symbolicate and process native crashes, we need the symbols from your native binaries. Typically, Android’s native binary build processes produce two sets of binaries: one set with debugging symbols, and one set to be packaged in your final APK. The Fabric plugin uses both sets of binaries to generate a symbol file on your machine. The symbol generation and upload process assumes your project will have two directories - one for the debug binaries (called obj below), and one for the release binaries (called libs below) - that are broken down by architecture-specific folders.

When building your project with the Android plugin for Gradle version 2.2.0+ with the externalNativeBuild DSL, the Fabric plugin is able to automatically detect the necessary directories for each native build variant in order to generate the appropriate symbol files.

obj/  
    — armeabi  
        + lib1.so  
        + lib2.so  
    — x86  
        + lib1.so  
        + lib2.so  

libs/  
    — armeabi  
        + lib1.so  
        + lib2.so  
    — x86  
        + lib1.so  
        + lib2.so

The paths to the debug and release binaries can be manually controlled via the androidNdkOut (default: src/main/obj) and androidNdkLibsOut (default: src/main/libs) properties. Ant users can modify these in the fabric.properties file. Gradle users can control these via the crashlytics {} block in their build.gradle.

Ant: ant crashlytics-upload-symbols

Gradle: ./gradlew crashlyticsUploadSymbols{Variant}

For example: ./gradlew crashlyticsUploadSymbolsRelease

You should also read "Uploading symbols for external dependencies" it it applies to your code.

tmm1
  • 2,025
  • 1
  • 20
  • 35
Jerome
  • 1,153
  • 1
  • 17
  • 28
  • I had understood that we had disabled proguard, but I will check. Also, isn't this just for Java or does proguard also process native binaries -- I'm talking about C++ symbols here. – user6519354 Mar 28 '18 at 11:29
  • To be clear, I am getting *Java* crash reports just fine and *was* getting C++ crash reports just fine -- until at some point I lost symbols in the C++ crash reports. – user6519354 Mar 28 '18 at 11:36
  • Thanks. As noted, I'm using the latest Gradle, Android Gradle Plugin, and CMake -- and this *was* all working. I just checked and Google Play Console has symbol information for our C++ crashes (it just doesn't demangle C++ symbol names), so it's unclear why Crashlytics is doing so much worse here. – user6519354 Mar 28 '18 at 13:50
  • and nothing happen when you do a ./gradlew crashlyticsUploadSymbols{Variant} ? – Jerome Mar 28 '18 at 14:53
  • I got an error when I attempted this, so I added crashlytics { enableNdk true manifestPath 'AndroidManifest.xml' } tasks.whenTaskAdded { task -> if (task.name.startsWith('assemble')) { task.finalizedBy "crashlyticsUploadSymbols" + task.name.substring('assemble'.length()) } } which I didn't need before. This gave me symbols from the code I actually compile in this project, but not from .a and .so files I incorporate that also have symbols. – user6519354 Apr 07 '18 at 14:00
0

add the following to your gradle.properties file:

android.bundle.enableUncompressedNativeLibs = false

onam kwon
  • 9
  • 2