IssueTracker

That seems like a big limitation because it means that to get lint checks on them you need to add them to the base but then they are also packaged with the base instead of the dynamic-features. Can we attempt to fix this for 7.1?

Ok, yes, I can attempt to fix for 7.1.

thanks!

#1

ktzoepubg@gmail.com

+1 on the issue (don't see where to star)

The star is to the left of the bug id on the header line which has the issue id and the issue synopsis.

Re: Comment #9, Can you elaborate on the cases when your customers are getting the incorrect versions in their apps? Is it a case of the app itself using a different version or a case of the app depending on another library with a different version?

The latter. The customer's app has another dependency using the NDK, and there is no way to control which C++ stdlib version gets packaged.

danalbert@, what is the desired behavior in this scenario? To package the latest version or to throw an error unless the versions match?

If you could add an action to packagingOptions to take the latest version, I believe that would address all of our use cases. Something along the lines of pickLatestVersion. However, is the version number a part of the binary file format? It's not in the filename.

There's no way to know which one is newest, and selecting the latest does not guarantee that they are compatible. If you had an app using r10, selecting anything later from your package would break the app. Selecting r10 would also break the app. There's no way to ensure that two libraries with the same name are even related (I wonder how many AARs contain libnative-lib.so because that's what's in the new project template) That's why this error (warning?) is here: these conflicts require someone actually look to see where the conflict is coming from and make a decision on how to resolve it.

The AAR you're talking about is a Java interface that just has a native implementation, right? Not a C++ interface? I'm assuming that's the case, since the mechanisms for the latter shouldn't create this problem. Assuming the former, can you restructure so that your AAR has only a single shared library that uses the static libc++, as described on https://android.googlesource.com/platform/ndk/+/master/docs/user/middleware_vendors.md#for-java-middleware-with-jni-libraries?

Possibly related, did anyone ever get around to making sure this warning doesn't fire if the two artifacts are actually bitwise identical? I know I'd discussed that with someone elsewhere, but apparently not here. There were probably a lot of false positives caused by that, and that's the one case where selecting one arbitrarily will be compatible.

Ok, based on #14, looks like an error is the correct behavior. It's currently a warning, but the plan is to convert to an error in the future.

Possibly related, did anyone ever get around to making sure this warning doesn't fire if the two artifacts are actually bitwise identical?

You mentioned that in comment#4 above, and I agree that it's a good idea. I'll plan to do that before converting to an error.

The AAR you're talking about is a Java interface that just has a native implementation, right? Not a C++ interface? I'm assuming that's the case, since the mechanisms for the latter shouldn't create this problem. Assuming the former, can you restructure so that your AAR has only a single shared library that uses the static libc++, as described on https://android.googlesource.com/platform/ndk/+/master/docs/user/middleware_vendors.md#for-java-middleware-with-jni-libraries?

kr...@, please let me know if that workaround works for you.

Possibly related, did anyone ever get around to making sure this warning doesn't fire if the two artifacts are actually bitwise identical?

You mentioned that in comment#4 above, and I agree that it's a good idea. I'll plan to do that before converting to an error.

Ah, missed that. Never mind :)

In my experience, this already generates an error. If during app packaging, 2 native libraries with the same name exist in 2 different dependencies (AAR files), then an error will be generated about 2 files existing with the same path. It does not do a binary comparison. The only resolution available is packagingOptions.pickFirst.

This is not sufficient for our use cases. We may have, for example, 5 different dependencies (AAR files) consumed through Maven, with a different mix of native libraries included in each. One of those dependencies needs to be designated as containing the correct version of each native library. Instead all we can do is have one picked at random using pickFirst.

One of those dependencies needs to be designated as containing the correct version of each native library. Instead all we can do is have one picked at random using pickFirst.

It wouldn't be picked at random, someone needs to decide which one is going to work for their app, or eliminate incompatible dependencies. I guess I don't understand how that could be done any other way (excluding the previous implementation of "choose one arbitrarily and just hope it works"). What do you have in mind?

Is https://android.googlesource.com/platform/ndk/+/master/docs/user/middleware_vendors.md#for-java-middleware-with-jni-libraries not an option for you? If so, why not?

In my experience, this already generates an error. If during app packaging, 2 native libraries with the same name exist in 2 different dependencies (AAR files), then an error will be generated about 2 files existing with the same path. It does not do a binary comparison. The only resolution available is packagingOptions.pickFirst.

Ah yes, that's right. It's a warning only for the case when there's a conflict between an app's native library and a dependent android library's native library.

We need to be able to specify which Android archive to pick each native library from. I am hopeful that AGP 4.1 with prefab publishing will emerge as a solution that allows us to strip all native libraries out of our Android archives, and consume them using prefab (this would essentially bring the handling of native components on par with Android archives).

The actual scenario is that we have multiple different modules, each with a native component. They can be consumed in various different combinations, but there are dependencies between them at the native level. So if FooModule has a native target libfoo, and BarModule has a native target libbar, that also depends on libfoo, we end up with BarModule.aar containing both libfoo and libbar, while FooModule.aar contains libfoo. Adding both dependencies causes an error.

In that example, does adding packagingOptions.exclude 'libfoo.so' to BarModule solve the issue?

It does. That means FooModule must be included as a dependency at the app level, even if it would not otherwise be necessary (maybe the Android pieces aren't required, just the native libfoo.so). That's not the end of the world, but we do end up with these rare scenarios with libc++_shared.so, where we want the most recent version, or we have a customer that's using another 3rd party dependency that's clashing with the libraries we provide.

It's better to make that selection at the consuming site in case modules are consumed by different apps. Also we need this for external depenencies anyway.

We should do something like

packagingOptions {
   pickFrom('libfoo.so', ':barModule') // for sub-modules
   pickFrom('libfoo.so', 'groupId:artifactId:version') // for external dependencies.
}

That would be awesome!

I filed Issue 214395989 to track the feature request in comment #23