Add pickFrom to JniLibsPackagingOptions and ResourcesPackagingOptions [214395989]

Assigned

Feature Request

Status Update

No update yet.

Description

sp...@google.com

created issue #1

Jan 13, 2022 04:58PM

As described in Comment 23 of Issue 141758241, users should have the ability to specify which .so file or java resource to package when there are multiple ones with the same name.

An example of what this will look like in the DSL:

android {
    packagingOptions {
        jniLibs {
            pickFrom('foo.so', ':fooModule') // for sub-modules
            pickFrom('bar.so', 'groupId:artifactId:version') // for external dependencies.
        }
        resources {
            pickFrom('foo.txt', ':fooModule') // for sub-modules
            pickFrom('bar.txt', 'groupId:artifactId:version') // for external dependencies.
        }
    }
}

This functionality should be added to the Variant API as well.

Comments

xa...@google.com <xa...@google.com> #2Jan 13, 2022 05:00PM

I wonder if when using pickFrom('bar.txt', 'groupId:artifactId:version') we should allow not specifying the version. Otherwise it's yet another place where the version needs to be updated when dependencies change (and it means things like dependency quick fix would result in broken builds).

sp...@google.com <sp...@google.com> #3Jan 13, 2022 05:03PM

Good point. In fact, maybe we shouldn't allow specifying the version at all... I'm not sure what the use case would.

sp...@google.com <sp...@google.com> #4Jul 7, 2022 04:34PM

We should also add this functionality for assets. See Issue 237809605.

xa...@google.com <xa...@google.com> #5Jul 7, 2022 05:24PM

Also, we should design to make this support version catalog.

xa...@google.com <xa...@google.com> #6Jul 7, 2022 05:26PM

Making this P1 since this may be required to work around issue related to the old apk creator going away in 8.0

sp...@google.com <sp...@google.com> #7Jul 7, 2022 05:46PM

Re #5, what do you have in mind? Do we need version catalog support if not supporting specifying the version, as discussed in #2 and #3?

xa...@google.com <xa...@google.com> #8Jul 7, 2022 05:55PM

That's a good question (regarding version) as catalog will always contain the version. Maybe we should just allow the version to be there but we simply ignore it.

As for supporting the catalog, I think it's just a matter of making the API either receive a String or whatever type is when you put libs.myDependency.

ge...@migeran.com <ge...@migeran.com> #9Sep 2, 2022 12:16PM

My recommendation would be to extend the Artifacts API in the AGP to allow the transformation of native library artifacts as well. The transformation of Java classes is already supported (e.g. for instrumentation), so this could be a natural extension to an already existing feature.

The advantage is that the app / library developers could implement any custom selection / transformation logic and not just predefined options like the ones suggested here. What do you think?

Message last modified on Sep 2, 2022 12:17PM

kr...@gmail.com <kr...@gmail.com> #10Feb 18, 2024 10:48PM

Hi,

Any news?

I think this would be pretty useful.

Greetings

sp...@google.com <sp...@google.com> #11Feb 19, 2024 10:42PM

Thanks for the ping. It's still on our radar, but no timeline.

sh...@samsung.com <sh...@samsung.com> #12
Restricted+
Sep 10, 2024 11:39AM

Comment has been deleted.

sp...@google.com <sp...@google.com> Feb 5, 2025 06:05AM

Reassigned to an...@google.com.

je...@google.com <je...@google.com> Feb 7, 2025 01:22AM

Reassigned to bi...@google.com.