Build fails unable to find non-existent 'bugsnag-libs/assets/include'

[faithfracture]

Expected behavior

Build should succeed, expected directory bugsnag-libs should exist.

Observed behavior

Build fails, bugsnag-libs directory is not created

Steps to reproduce

I updated my project to the current version of Bugsnag (4.21.1) from 4.13 and followed the instructions on https://docs.bugsnag.com/platforms/android/#native-api-configuration.

Version

4.21.1

Additional information

My NDK code is in an Android Library Submodule. I suspect this may be the cause, as we've (Bugsnag & myself) have had to come up with workarounds for things because of this in the past.

I've tried removing all the 'bugsnag' related grade stuff from my library's build.gradle file & just putting it in the main applications 'build.gradle' (which is what gives me the aforementioned error). I also tried adding the bugsnag dependency to my android library, which results in a different error:

> Task :nativeModule:processBugsnagDebugManifest FAILED
Failed to find manifest at android-project/nativeModule/build/intermediates/merged_manifests/debug/AndroidManifest.xml

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':nativeModule:processBugsnagDebugManifest'.
> Cannot get property 'asFile' on null object

Moving my NDK library to the main Android project is not an option - I have 6 different apps that build from the same project - moving the NDK library to the main project results in all of the code being compiled for all 3 of my supported architectures for all 6 of my applications, a total of 18 times re-compiling my (very large) C++ library. I've done this in the past and the build time was in excess of 3 hours. Having the NDK in a submodule cuts that down to only about 20 minutes.

[mattdyoung]

Hi @faithfracture

Are you using the Bugsnag gradle plugin?
https://docs.bugsnag.com/build-integrations/gradle/

Can you confirm whether you've set com.bugsnag.android.DETECT_NDK_CRASHES in your manifest as described here?
https://docs.bugsnag.com/platforms/android/#reporting-ndk-errors

[faithfracture]

Yes, I'm using the Bugsnag Gradle plugin:

project build.gradle

buildscript {
    dependencies {
        classpath "com.bugsnag:bugsnag-android-gradle-plugin:4.7.2
}

Yes, I've set DETECT_NDK_CRASHES in the main android application AndroidManifest.xml

app build.gradle

<manifest ... >
  <application ...>
    <meta-data
    android:name="com.bugsnag.android.DETECT_NDK_CRASHES"
    android:value="true" />
  </application>
</manifest>

The bugsnag plugin is also applied in the main application's AndroidManifest.xml.

As I mentioned in the original post, I did try configuring the library module in the same way, but I got the error about not being able to find the manifest.

FWIW, the library manifest does exist, it's just not located at build/intermediates/merged_manifests/debug. It is instead at build/intermediates/library_manifest/debug. In the merged_manifests/debug directory there is an output.json file that includes the path to the library manifest:

[{"outputType":{"type":"MERGED_MANIFESTS"},"apkData":{"type":"MAIN","splits":[],"versionCode":-1,"enabled":true,"outputFile":"nativeModule-debug.aar","fullName":"debug","baseName":"debug"},"path":"../../library_manifest/debug/AndroidManifest.xml","properties":{"packageId":"my.project.library.id","split":""}}]

[mattdyoung]

Hi @faithfracture

We'll need to take a look at whether the Bugsnag gradle plugin can be updated to support this configuration.

[faithfracture]

👍 Thanks!

If for some reason it can't be, is there a workaround? It seems like if the plugin were at least able to look in the build/intermediates/library_manifest/debug for the manifest if one isn't found in build/intermediates/merged_manifests, I could then add my API key & apply the plugin to the library project's manifest directly & go on my merry way. Yeah, I'd have to do some additional legwork for all my different targets, but that's a lot better than not having any NDK reporting at all.

[mattdyoung]

We're not currently aware of any workaround, but the team will be looking at this over the next few days so I'll keep you posted with any updates.

[faithfracture]

@mattdyoung Thanks Matt! I'll guess I'll just stick with the older version for the time being.

[faithfracture]

@mattdyoung Any update on this? I'm going to be migrating to Androidx pretty soon & I'm concerned that v4.13 won't work once I do that. I like the Bugsnag platform, but if I can't have NDK reporting I'll have to switch to something else.

[mattdyoung]

Hi @faithfracture

I'd suggest trying the latest version of the Bugsnag gradle plugin v4.7.3, as that fix should prevent the issue you were seeing.

We still have more work to do to fully support the use case of using Bugsnag in an Android library module e.g. we don't believe it will find the right location for the AndroidManifest.xml in that scenario, but you may be able to work around that.

[faithfracture]

Sorry - your message kinda fell through the cracks. Thanks for the update! I haven't worked on my Android project for a few months, but I'm scheduled back on it in a few weeks so I'll give this a try when I get back to it.

[faithfracture]

Finally got back to this.

I updated the Bugsnag Gradle plugin to com.bugsnag:bugsnag-android-gradle-plugin:4.7.3 (I also tried v4.7.4) and com.bugsnag:bugsnag-android-ndk:4.22.3 in my NDK library.

I'm still getting the same error.

In fact, just updating the gradle plugin to 4.7.3 / 4.7.4 causes the error without updating the library version from 4.14.2.

I'll be working on our Android project for the next couple of months, so I should be able to trying things out in relatively short order.

[johnkiely1]

Hi @faithfracture.

It seems the v4.7.3 release has not fully resolved the underlying issues for your use case. Ultimately we need to address supporting library module usage. This is something we have prioritised and are planning on working on it very soon.

[faithfracture]

Any news on this? I'm happy to help any way I'm able.

[phillipsam]

👍 Thanks!

If for some reason it can't be, is there a workaround? It seems like if the plugin were at least able to look in the build/intermediates/library_manifest/debug for the manifest if one isn't found in build/intermediates/merged_manifests, I could then add my API key & apply the plugin to the library project's manifest directly & go on my merry way. Yeah, I'd have to do some additional legwork for all my different targets, but that's a lot better than not having any NDK reporting at all.

Hi @faithfracture - this comment above suggests it may be possible to work around this for your specific situation. If that is the case, for now we would suggest forking the plugin and altering the path. Designing and implementing the support for library module usage is going to take some time and we do not have a timeframe for this yet.