Bugsnag Gradle plugin fails to generate NDK mapping files since NDK r23

[vmilea]

Describe the bug

NDK r23 has removed GNU binutils:

find . -iname "*objdump"

./22.1.7171670/toolchains/x86-4.9/prebuilt/darwin-x86_64/bin/i686-linux-android-objdump
./22.1.7171670/toolchains/x86-4.9/prebuilt/darwin-x86_64/i686-linux-android/bin/objdump
./22.1.7171670/toolchains/llvm/prebuilt/darwin-x86_64/aarch64-linux-android/bin/objdump
./22.1.7171670/toolchains/llvm/prebuilt/darwin-x86_64/bin/x86_64-linux-android-objdump
./22.1.7171670/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdump
./22.1.7171670/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump
./22.1.7171670/toolchains/llvm/prebuilt/darwin-x86_64/bin/i686-linux-android-objdump
./22.1.7171670/toolchains/llvm/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump
./22.1.7171670/toolchains/llvm/prebuilt/darwin-x86_64/arm-linux-androideabi/bin/objdump
./22.1.7171670/toolchains/llvm/prebuilt/darwin-x86_64/x86_64-linux-android/bin/objdump
./22.1.7171670/toolchains/llvm/prebuilt/darwin-x86_64/i686-linux-android/bin/objdump
./22.1.7171670/toolchains/x86_64-4.9/prebuilt/darwin-x86_64/bin/x86_64-linux-android-objdump
./22.1.7171670/toolchains/x86_64-4.9/prebuilt/darwin-x86_64/x86_64-linux-android/bin/objdump
./22.1.7171670/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump
./22.1.7171670/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/arm-linux-androideabi/bin/objdump
./22.1.7171670/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/aarch64-linux-android/bin/objdump
./22.1.7171670/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdump

./23.1.7779620/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump

The Bugsnag Android plugin can't cope, and fails when preparing symbols:

> Task :app:generateBugsnagNdkPlay-releaseMapping
Generating NDK mapping files
Bugsnag: Error attempting to calculate objdump location: Failed to find executable objdump at /Users/vmilea/Library/Android/sdk/ndk/23.1.7779620/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdump
Bugsnag: Unable to upload NDK symbols: Could not find objdump location for arm64-v8a
Bugsnag: Error attempting to calculate objdump location: Failed to find executable objdump at /Users/vmilea/Library/Android/sdk/ndk/23.1.7779620/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin/aarch64-linux-android-objdump
Bugsnag: Unable to upload NDK symbols: Could not find objdump location for arm64-v8a
...

Steps to reproduce

1. Set ndkVersion 23.1.7779620
2. Do a release build.

Environment

• Android Studio version: Android Studio Bumblebee | 2021.1.1
• Gradle version: 7.0.2
• Android Gradle Plugin (AGP) version: 7.0.4
• Bugsnag Android Gradle Plugin version: 7.2.0
• Bugsnag manifest section (if modified): -

[xljones]

Hey @vmilea, thanks for raising this issue. Yes, looks like the objdump binaries were indeed removed in NDK r23. We'll take a look into what's possible to support this version here. In the meantime, if you're able to NDK r21 still contains these binaries and is tested with.

[vmilea]

In the meantime, if you're able to NDK r21 still contains these binaries and is tested with.

We've worked around it for now by pointing bugsnag.objdumpPaths to files from an older NDK. This way we can keep using NDK r23b, which has universal binaries to drastically improve build times for our developers on Apple M1 Silicon.

We'll take a look into what's possible to support this version here.

Have you considered allowing the merged_native_libs to be uploaded, and generating the mapping files on the server instead? This would avoid problems with the newer NDKs, and also save a lot of bandwidth (the original .so is 4-5x smaller than the mapping file when compressed).

[johnkiely1]

Hi @vmilea, Thanks for the suggestion, we are looking into the approach of processing on server and we will let you know of updates. In the meantime your workaround seems like the best option here.

[jgreen210]

We didn't notice this problem for a long time since it just logs some errors, it doesn't make the gradle tasks fail.

[jaltin]

We also seem to have just hit this. Is there any update on a fix for this @xljones?

[luke-belton]

Hi @jaltin - this is still on our backlog to review when priorities allow. In the meantime, you could consider adopting the workaround suggested above.

[jaltin]

Hi @jaltin - this is still on our backlog to review when priorities allow. In the meantime, you could consider adopting the workaround suggested above.

@luke-belton we have avoided the fix as it caused other complications for us.

Do you have any idea of if/when this will be looked at?

[abigailbramble]

@jaltin this is one of the things that we are looking into at the moment. It requires a fair amount of work and we are hoping to release something for this in the next quarter.

[jaltin]

@jaltin this is one of the things that we are looking into at the moment. It requires a fair amount of work and we are hoping to release something for this in the next quarter.

@phillipsam Thanks for the more time specific update, it really helps in setting our expectations.

Hope you manage to get it done in the next quarter, would really be helpful.

[afturner]

Hi @phillipsam, just wanted to check in and see whether there were any updates on the plan for working on a fix? Just curious :) thanks.

[johnkiely1]

Hey @afturner, This is still on our backlog, and has turned into an even larger piece of work that initially expected. We are working on some of the prerequisites at the moment and expect get to this soon, but we don't have any updated ETA to share at the moment.

[gareththackeray]

As of version 7.4.0 this plugin you can opt in to our new mechanism for uploading symbols files by setting the useLegacyNdkSymbolUpload config to false.

For more information see the docs. Any issues please let us know.

[andrei-tofan]

We still have not seen the NDK symbols files being uploaded using the 7.4.0 version configured using the guide. I see this message in the log output:

Cannot detect Bugsnag SDK version for variant prodRelease, assuming a modern version is being used. This can cause problems with NDK symbols if older versions are being used. Please either specify the Bugsnag SDK version for prodRelease directly.See https://docs.bugsnag.com/api/ndk-symbol-mapping-upload/ for details.

Is this the source of the issue and if so how we can fix it?

[johnkiely1]

Hi @andrei-tofan, would you mind writing in to us at [email protected]. If you would be willing to share your entire build.gradle files that would be ideal. If thats not possible at a minimum could you include how you are configuring the BugSnag gradle plugin in your build.gradle files.

[andrei-tofan]

Hi @johnkiely1, I've sent the files to support (request #43575).