Feature: Split components of bundletool artifacts
- Dominant language
- Java
- Stars
- 4k
- Forks
- 428
- PR merge metrics
- No merged PRs in 30d
Description
**Describe the solution you'd like**
Currently the bundletool is published to Maven as [`com.android.tools.build:bundletool`](https://mvnrepository.com/artifact/com.android.tools.build/bundletool). That artifact includes everything necessary to support the entire feature set of the AAB bundletool, including parsing an AAB file, and generating APKs from an AAB.
My proposal would be to split the functionality into smaller pieces, so that if a tool wants to only parse and extract bits of information in an AAB file, it can use one artifact, and if it wants to build APKs it can use another artifact. As it is today, pulling in the bundletool artifact adds approximately 37MB to the runtime classpath.
**Describe alternatives you've considered**
Current alternatives are:
1. include `com.android.tools.build:bundletool` and try to use existing classes and functionality from that.
2. Duplicate the protobuf definitions and write our own way of extracting the relevant information from the manifest pb.
**Additional context**
In my case, I'm looking for a way to only parse out bits of information from the base manifest in the AAB file, so my current approach leverages aspects of the `DumpManager` class in order to extract things like the `packageName` and `versionCode`. If the bundletool had separate published artifacts for discrete bits of functionality, it would be trivial to parse and extract what's needed from the AAB, without having to include the monolith.
For purposes of command-line use, a `bundletool-all.jar` could still be produced that shadows everything it needs into a monolithic jar; while smaller dependencies could be published separately where needed.
Contributor guide
Assessment
This issue has not been assessed yet.