-
Notifications
You must be signed in to change notification settings - Fork 87
Conversation
Add runfiles dependency and data attribute to both AAR and JAR proguard extractor targets, and read the R8 version from r8.version at runtime.
Thread r8_version from main() through _Main and into all proguard_extractor_lib functions. No behavioral change yet.
ExtractEmbeddedProguardFromJar now matches r8-from-X-upto-Y directories against the actual R8 version and only extracts rules whose version range covers the current R8 version. Falls back to legacy META-INF/proguard/ rules when no targeted range matches.
Update ExtractEmbeddedProguardFromAar to prioritize version-targeted R8 rules from classes.jar, falling back to proguard.txt at the AAR root when no targeted range matches. Remove unused ExtractR8Rules and ExtractEmbeddedProguardFromAarLegacy functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't very robust - it assumes the version format is R8 8.9.35 (build ...) (which is the case today, but can change in the future).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe could use the r8-version.properties resource?
e.g.
unzip -p $(location r8_jar) r8-version.properties | sed -En 's/^version.version=(.+)$/1円/p'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The result looks a bit odd to me:
version.sha=afec818d6658b003ba394e10107b7dfc565dd94b
releaser=go/r8bot (luci-r8-custom-ci-archive-0-stqp)
version-file.version.code=1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Came up with this: 5e30c57
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see. In my case there was also a version.version property key with the specific version. I suppose when it's built from an untagged version that doesn't exist.
@damianw
damianw
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing!
Fwiw this doesn't fully solve #491. Beyond respecting the R8 version, the prioritization of rules vs proguard/proguard.txt are also part of that issue. Solving that would require extracting the rules from individual jars instead of a single deploy jar.
Specifically, this is where the rules are currently being extracted. It can't really be done here, because all the resources are in one jar. So applying logic for "if has com.android.tools, ..." etc doesn't really make sense since the classpath is all jumbled together. The rule file selection would need to happen on the original library jars.
snazhmudinov
commented
May 22, 2026
Extract rules from each jar
Ah that makes sense. I tried to run the extractor on jars, which get merged into deploy.jar. Commit.
damianw
commented
May 26, 2026
Great! That all makes sense to me.
Uh oh!
There was an error while loading. Please reload this page.
Addresses #491.
Additional info used: https://developer.android.com/topic/performance/app-optimization/library-optimization#support-different