Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
faithfracture opened this issue Nov 18, 2019 · 13 comments
Open
Labels
needs discussion Requires internal analysis/discussion scheduled Work is starting on this feature/bug

Comments

@faithfracture
Copy link

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
Copy link

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

@mattdyoung mattdyoung added the awaiting feedback Awaiting a response from a customer. Will be automatically closed after approximately 2 weeks. label Nov 21, 2019
@faithfracture
Copy link
Author

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 mattdyoung removed the awaiting feedback Awaiting a response from a customer. Will be automatically closed after approximately 2 weeks. label Nov 22, 2019
@mattdyoung
Copy link

Hi @faithfracture

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

@mattdyoung mattdyoung added the needs discussion Requires internal analysis/discussion label Nov 25, 2019
@faithfracture
Copy link
Author

👍 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
Copy link

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.

@bugsnagbot bugsnagbot added the scheduled Work is starting on this feature/bug label Dec 6, 2019
@faithfracture
Copy link
Author

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

@faithfracture
Copy link
Author

@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
Copy link

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.

@abigailbramble abigailbramble added released This feature/bug fix has been released scheduled Work is starting on this feature/bug and removed scheduled Work is starting on this feature/bug released This feature/bug fix has been released labels Feb 13, 2020
@faithfracture
Copy link
Author

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
Copy link
Author

faithfracture commented May 13, 2020

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
Copy link
Member

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
Copy link
Author

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

@abigailbramble
Copy link

👍 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs discussion Requires internal analysis/discussion scheduled Work is starting on this feature/bug
Projects
None yet
Development

No branches or pull requests

5 participants