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_VARIANT
reproduces 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)
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:
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 togradlew
, I see that the taskgenerateCrashlyticsSymbolFileRelease
took about 15 seconds anduploadCrashlyticsSymbolFileRelease
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:Compared to our previous release, which does indeed have deobfuscated crashes, here are some dependencies which changed versions:
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 isarm64-v8a
. ~Could this be an issue?~ I tried renaming the folder toarm64
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:
The log
Crashlytics could not find NDK build tasks on which to depend
still appears, but crashes are deobfuscated.