Uh oh!
There was an error while loading. Please reload this page.
Extract r8 rules based on version - #511
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.
| outs = [ | ||
| "r8.version", | ||
| ], | ||
| cmd = "$(location :r8) --version | awk -F' ' '{ print $$2 }' >$(OUTS)", |
There was a problem hiding this comment.
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.
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.
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.
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
left a comment
There was a problem hiding this comment.
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 |
snazhmudinov
commented
May 22, 2026
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. |
Addresses #491.
Additional info used: https://developer.android.com/topic/performance/app-optimization/library-optimization#support-different