Support omitting standalone APKs when minSdk < 21

[lberrymage]

Is your feature request related to a problem? Please describe.

When generating split APKs for an app with minSdk < 21, standalone APKs are always generated as well (because SDK < 21 devices don't support split APKs). This greatly increases the size of the generated APK set due to duplication mainly of native code. This approach makes sense for the Play Store since it supports very old versions of Android, but for alternative stores which don't support Android 4.4 and below, this causes unnecessary disk usage since they'll never serve standalone APKs.

I'm also running an app store that accepts APK sets directly instead of app bundles for various reasons. I realize that's not how bundletool is typically used, but this means APK sets themselves are handled over the network, exacerbating the issue since the solution isn't as simple as deleting the standalone APKs from disk after they're generated.

Describe the solution you'd like

Adding a --splits-only flag for the default mode of bundletool or a new mode entirely that only generates split APKs should be sufficient. I don't really have a preference to one solution or the other, but from some brief code reading I think the latter would be simpler to implement.

Describe alternatives you've considered

Another option is to add a --override-min-sdk flag or similar to make bundletool behave as if the app's minSdk was as specified on the command line. This would solve the aforementioned issue as well as another: that both splits with uncompressed and compressed native code are generated for apps with minSdk < 23. It would also make sense generally since app stores may wish to override the minSdk for split generation if they have a minSdk > 23 themselves and don't want to make unnecessary accommodations for API levels they'll never serve apps to.

Personally I think this solution makes more sense than the former one since it more completely solves the issue of generating unnecessary data for apps stores with a recent (> 23) minSdk, but I thought it would be better to narrow the scope of this issue to the problem that causes the majority of excess disk usage and expand it later if this kind of change is desired.

[ymakhno]

I do not think this feature fits bundletool as nothing prevents developer from generating multiple AABs: one with minSdk below 21 for Google Play and another with minSdk=23 for this custom store.

[lberrymage]

The reason I suggest it in bundletool is that setting the minSdk in the app seems more like a workaround for bundletool's default behavior than a "proper" solution since the theoretical minSdk hasn't actually changed (plus doing so is more work for app developers besides). The minSdk semantically declares the minimum version of Android the app itself supports, but what I'm suggesting is that the store (through bundletool) should also be able to decide the minimum version of Android it supports and not require app developers to modify their app around bundletool's / the store's behavior.

TLDR: bundletool assumes an app store supports all versions of Android, but this is not always the case.