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

Add option to extract proguard configurations in jvm_import #920

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

mauriciogg
Copy link
Contributor

Some jars include proguard specs in META-INF/proguard/ META-INF/com.android.tools
We need to extract these files in order to pass them correctly to R8 for android builds.
Normally R8 should detect these files automatically inside the jar, but if proguard specs are specified in META-INF/com.android.tools and META-INF/proguard the files under META-INF/proguard are ignored. See https://r8.googlesource.com/r8/+/refs/heads/main/src/main/java/com/android/tools/r8/R8Command.java#1394 Given that bazel uses a single deploy jar when running R8 it is likely that both directories exist and several needed configs are ignored.

see bazelbuild/bazel#14966 (comment)

Some jars include proguard specs in META-INF/proguard/
META-INF/com.android.tools
We need to extract these files in order to pass them correctly
to R8 for android builds.
Normally R8 should detect these files automatically inside the jar,
but if proguard specs are specified in META-INF/com.android.tools and
META-INF/proguard the files under META-INF/proguard are ignored.
See https://r8.googlesource.com/r8/+/refs/heads/main/src/main/java/com/android/tools/r8/R8Command.java#1394
Given that bazel uses a single deploy jar when running R8 it is likely
that both directories exist and several needed configs are ignored.

see bazelbuild/bazel#14966 (comment)
@jin
Copy link
Collaborator

jin commented Jun 23, 2023

jvm_import seems like the wrong place to add processing like this. Why isn't this part of the Android rules as an action to prepare the 3rd party jars before R8 sees them, instead?

@mauriciogg
Copy link
Contributor Author

jvm_import seems like the wrong place to add processing like this. Why isn't this part of the Android rules as an action to prepare the 3rd party jars before R8 sees them, instead?

where would this live- as a top level action of android_binary? at that point its not possible to know whats a third_party jar vs a local jar. The other approach would be an aspect, but then rules_koltin would need to be aware of it to

@shs96c
Copy link
Collaborator

shs96c commented Jun 23, 2023

Surely rules_android is the right place for this? An aspect when you create the binaries there would make a lot of sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants