Firebase-android-sdk: Message: "Crashlytics could not find NDK build tasks on which to depend."

[kenmorse]

Describe your environment

• Android Studio version: 4.0
• Firebase Component: Crashlytics, firebase-crashlytics-gradle plugin
• Component version: 2.2.0

Describe the problem

The problem with specifying NDK library paths was helpfully fixed as part of issue #1199; however, the new version 2.2.0 of the firebase-crashlytics-gradle plugin now produces this message:

Crashlytics could not find NDK build tasks on which to depend. You many need to manually enforce task dependencies for generateCrashlyticsSymbolFileFlavorAmazonRelease

The message does not stop the build, but there is also no indication of whether there is a significant problem or not. I suspect the message is due to the NDK being part of a Gradle/Android subproject, and not the ":app" project itself.

Steps to reproduce:

./gradlew app:uploadCrashlyticsSymbolFileBUILD_VARIANTreproduces the "could not find NDK build tasks" message.

[kevinkokomani]

Thanks for letting us know about this. If you do notice that this causes any issues with your symbol file upload, your build, or the symbolication of your NDK crashes, please update this issue with your findings!

[kenmorse]

@kevinkokomani — thanks Kevin. I've got a simple reproducible case with a test app that includes a native Android library. When crashing in the native code the C++ code is not referenced in the stack trace information. What's the best way to proceed?

[kevinkokomani]

Thanks for working on that Ken - I think the best way forward is to submit a case to Firebase support, linking this GitHub issue that you opened, and attaching the repro you've created. Submitting a case will ensure that if support can't help with the issue, it will get routed directly to the Crashlytics NDK team for review.

[kenmorse]

Case submitted with repo — thanks @kevinkokomani.

[kevinkokomani]

Thanks @kenmorse!

[MassimoMessore]

Case submitted with repo — thanks @kevinkokomani.

Same problem here using the same Android Studio and Component version when I try to generate and upload symbols of native libraries (externally generated using autotools).

I successfully configured _unstrippedNativeLibsDir_ and _strippedNativeLibsDir_ paths and I can see in gradle logs the same warning about Crashlytics could not find NDK build tasks on which to depend even if the symbols are apparently generated and successfully uploaded via HTTP PUTs on server side.

Unfortunately I can't see the stack trace information on Crashlytics console when a native crash occurs (missing symbols).

Is there an issue tracker to track down this case?

Regards

[kevinkokomani]

This would be the issue tracker. Would you be comfortable with posting your relevant setup details here, in terms of how you're configuring NDK and how exactly you're including your native libraries into your app? It would help us to reproduce this issue as well as confirm that you're running into the same issue as kenmorse.

Thanks!

[MassimoMessore]

Hi @kevinkokomani, thanks for your quick reply.

My project tree is structured as follows:

appProject
 |
 | -- androidLibraryModule
 |    | 
 |    | -- src
 |    | -- libs
 |    | -- obj
 |    | ...
 |    | -- build.gradle
 | 
 | -- app
 |    |
 |    | -- src
 |    | ...
 |    | -- build.gradle
 |
 | -- build.gradle 

The app module depends on the androidLibraryModule which contains the native shared libraries (built using an external autotools-based script with NDK r17c standalone GCC toolchains) in the two folders:

• libs: stripped libraries
• obj: unstripped libraries

These two folders are structured as expected with the proper ABI folders (arm64-v8a, x86, etc.).

Following the Fabric to Firebase Crashlytics migration guidelines for Android I upgraded my build.gradle files as follows:

androidLibraryModule/build.gradle

apply plugin: 'com.android.library'
[...]

repositories {
    google()
}

dependencies {
    implementation fileTree(dir: 'libs', include: '*.jar')
    implementation 'androidx.legacy:legacy-support-v4:1.0.0'
    implementation "com.google.firebase:firebase-crashlytics:17.1.1"
    implementation "com.google.firebase:firebase-analytics:17.4.4"
}
[...]

}

app/build.gradle

apply plugin: 'com.android.application'
apply plugin: 'com.google.gms.google-services'
apply plugin: 'com.google.firebase.crashlytics'

buildscript {
    repositories {
        google()
        jcenter()
    }

    dependencies {
        classpath "com.android.tools.build:gradle:4.0.1"
    }
}

android {
    [...]

    buildTypes {
        debug {

        }
        release {
            minifyEnabled true
            [...]

            firebaseCrashlytics {
                nativeSymbolUploadEnabled true
                unstrippedNativeLibsDir "../androidLibraryModule/obj"
                strippedNativeLibsDir "../androidLibraryModule/libs"
            }
        }
    }
   [...]

    splits {
        abi {
            enable false
            reset()
            include 'x86', 'armeabi-v7a', 'arm64-v8a', 'x86_64'
            universalApk true
        }
    }
    packagingOptions {
        exclude 'lib/armeabi/libcrashlytics.so'
    }
}

dependencies {
    implementation project(':androidLibraryModule')
    implementation "com.google.firebase:firebase-crashlytics:17.1.1"
    implementation "com.google.firebase:firebase-analytics:17.4.4"
    implementation "com.google.firebase:firebase-crashlytics-ndk:17.1.1"
    [...]
}

appProject/build.gradle

buildscript {
    [...]

    dependencies {
        classpath "com.android.tools.build:gradle:4.0.1"
        classpath "com.google.gms:google-services:4.3.3"
        // Firebase Crashlytics Gradle plugin.
        classpath 'com.google.firebase:firebase-crashlytics-gradle:2.2.0'
    }
    repositories {
        google()
        jcenter()
    }
}

[...]

Hope that the given details will be useful to clarify this issue I didn't face before when using Fabric SDK.

Regards.
Massimo

[ivanuschak]

Hi @kevinkokomani, @MassimoMessore,

Just wanted to confirm I'm facing the same issue as Massimo.
I have similar Android Studio project and native libraries built separately from this project (also using NDK r17c), libraries are placed in two folders (stripped(release libs) and unstripped(debug libs)), which are pointed in the application build.gradle file (_unstrippedNativeLibsDir_ and _strippedNativeLibsDir_ properties).
I'm building the project in Debug mode, so the _uploadCrashlyticsSymbolFileDebug_ task is performed successfully (there is no warnings/errors) and also I checked that all the *.cSYM files are successfully uploaded to the firebase during this task execution.
I tried to use different 'firebase-crashlytics-ndk' versions (17.0.0-beta, 17.0.1 and 17.1.1), but eventually I always have _'missing symbols'_ in crash report stack trace in the firebase console.
I double checked the settings related to firebase and assured that everything set up in accordance with the crachlytics-ndk documentation.
Of course there may be a mistake in my configuration, but I double checked everything and currently for me it looks like a bug in firebase.

Best Regards,
Nikolay

[calvarez-ov]

I found this log in our latest release build, and it also happens that our native crashes are no longer deobfuscated.

For info, thanks to the --profile argument passed to gradlew, I see that the task generateCrashlyticsSymbolFileRelease took about 15 seconds and uploadCrashlyticsSymbolFileRelease took about 40 seconds, so it looks like the tasks actually did something. I would guess the upload task actually uploaded the files, based on that duration.

Also, I reran with --debug and saw logs from crashlytics indicating success, like:

2020-07-31T16:41:34.535+0200 [DEBUG] [com.google.firebase.crashlytics] Crashlytics symbol file uploaded successfully; deleting local csym: /path/to/project/app/build/crashlytics/Release/nativeSymbols/mediastreamer-x86-yyyyyyyy.cSYM
2020-07-31T16:41:34.558+0200 [DEBUG/ [com.google.firebase.crashlytics] PUT file: /path/to/project/app/build/crashlytics/Release/nativeSymbols/ortp-x86-xxxxxxxx.gz to URL: https://firebasecrashlyticssymbols.googleapis.com/v1/project/-/app/1:123412341234:android:zzzzz/upload/native/xxxxxxxx
2020-07-31T16:41:34.559+0200 [DEBUG] [com.google.firebase.crashlytics] PUT headers:
2020-07-31T16:41:34.559+0200 [DEBUG] [com.google.firebase.crashlytics]  User-Agent = crashlytics-gradle/2.2.0
2020-07-31T16:41:34.559+0200 [DEBUG] [com.google.firebase.crashlytics]  X-CRASHLYTICS-API-CLIENT-TYPE = crashlytics-gradle
2020-07-31T16:41:34.559+0200 [DEBUG] [com.google.firebase.crashlytics]  X-CRASHLYTICS-API-CLIENT-VERSION = 2.2.0
2020-07-31T16:41:36.246+0200 [DEBUG] [com.google.firebase.crashlytics] PUT response: [reqId=null] 200

Compared to our previous release, which does indeed have deobfuscated crashes, here are some dependencies which changed versions:

• firebase-crashlytics-gradle: 2.1.0 -> 2.2.0
• firebase-crashlytics and firebase-crashlytics-ndk: 17.0.0-> 17.1.1
• android gradle plugin: 3.6.3 -> 4.0.0

Note: we don't build any native code in our project. We do include native libraries though, and we upload the symbols for those libraries.

I noticed the documentation mentions an arm64 folder. Ours is arm64-v8a. ~Could this be an issue?~ I tried renaming the folder to arm64 but that didn't resolve the problem.

---

Note: I tested downgrading the android gradle plugin to 3.6.3, and that resulted in crashes being deobfuscated again!

Specifically, this scenario works:

• firebase-crashlytics-gradle: 2.2.0
• firebase-crashlytics and firebase-crashlytics-ndk: 17.1.1
• android gradle plugin: 3.6.3

The log Crashlytics could not find NDK build tasks on which to depend still appears, but crashes are deobfuscated.

[antonkovalyov351]

I had same issue with missing stacktrace and this what I received from support:

...try to add the following information to your AndroidManifest.xml file and see if this will resolve the issue:

<application
    android:extractNativeLibs="true"'
    ...
</application>

Note that this may increase the size of the final binary at the end of the build by a little. ...

I have tried it and it worked. At least for stack entries which belong to my own native code.
Hope this will help.

[calvarez-ov]

@antonkovalyov351 Thanks for this tip. But it doesn't resolve our issue of obfsucated stacktraces :( What version of Android Gradle Plugin did you use in the build that worked for you?

[antonkovalyov351]

@antonkovalyov351 Thanks for this tip. But it doesn't resolve our issue of obfsucated stacktraces :( What version of Android Gradle Plugin did you use in the build that worked for you?

4.0.0

[calvarez-ov]

🤔
I've tried:

• agp 4.0.1 + extractNativeLibs not specified
• agp 4.0.1 + extractNativeLibs true
• agp 4.0.0 + extractNativeLibs true
• agp 4.0.0 + extractNativeLibs false

None of them result in deobfuscated stacktraces

The first three all seem to have identical apk sizes.
The last one nearly doubles the size of the apk. from 21 Mb to 40 Mb.

Our project doesn't build the native code, but we do have access to the debug symbols for the native code. That's how deobfuscation worked up until our recent upgrade to agp 4.0.x: we copy the symbols to the configured folders as documented and run ./gradlew assembleRelease uploadCrashlyticsSymbolFileRelease

[calvarez-ov]

Here's a sample project which reproduces the missing stack traces:

https://github.com/libon/CrashObfuscationTest

[calvarez-ov]

Opened #1978 for the missing ndk stacktrace info, as it appears unrelated to the original issue reported here.

[rodly]

Any word on this?