Support extracting aar files.

[cpsauer]

Hey awesome Bazel team,

Would you consider allowing extract, download_and_extract, and http_archive to decompress .aar android archives? Figured I'd just toss up a PR to ask because it was such an easy addition; aars are just zip files under the hood, totally parallel to the jar/war cases already in the codebase.

The motivation is that you'll need this basic functionality to be able to depend on the native interface of an aar, which Android Studio & co are working on in prefabs. I ran into the lack of support while trying to hack myself support for #13092.

Thanks for your consideration!
Chris

[ahumesky]

I would say here "probably don't want to do this, probably want to use aar_import", but this might be what we want to do, pending more discussion on #13092

[cpsauer]

Hey again, Alex! Happy to do whatever you want here.

I do think this might be generally useful enough that it's worth decoupling from #13092, even if that was how I originally stumbled onto it. (I'll building my workaround with a shell script regardless to decouple things. Definitely not recommending it as a substitute to aar_import.)

This is handy more generally for rule writers or users looking to depend on subsets of the things in an aar archive. I assume this is why extract() & friends already support decompressing the other java archives, like jars and wars. When I see a function that handles a more general use case but unnecessarily prevents some of some of that usefulness, I get the urge to help it live up to its potential :) Sure it's handy in my workaround, but I PR'd it because I thought it would also serve other use cases.

Some examples of other uses: letting folks depend on just sub-resources of an AAR, supporting the new AAR format changes inside of aar_import, or creating a more robust rule to fix bazelbuild/rules_android#323. (Mini digression: Right now Tensorflow & MediaPipe are depending on the genrule workaround posted in that issue. But it doesn't copy transitive java dependencies into the aar, so they've having to filegroup all the Java files into one android_library rather than have a Java build graph. A rule implementing a fix for them would probably also need the ability to unpack APKs, in addition to AARs as I've done here. Happy to add APK extraction at the same time if you'd like.)

[cpsauer]

(On tests, is the remote build suite just broken/flaky right now? I see doc-change only PRs failing those tests and an unrelated PR failing the same test, but don't want to wrongly ignore them.)

[cpsauer]

@ahumesky, any chance we could get this generalization in, or should I close it out/delete it?
Edit: Shoot, sorry, just refreshed and saw the new tag. Apologies for the unnecessary bump.

[cpsauer]

Ran into a couple more instances where this would have been handy while writing extensions. Any chance we could land it? It's free, useful generality.