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

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.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 14
  • Comments: 18 (1 by maintainers)

Most upvoted comments

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

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.

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.