Android Build Optimisations

[vaslabs]

This discussion is to exchange ideas and discuss on starting to optimise the Android build.

Basically, some things in the build process are over "provisioned" (for lack of a better word) , there might be excessive things packaged in the APK or things that are using CLI tools can be optimised as jvm workers (e.g. like the KSP2)

A few things that come to mind at the moment:

• Android Test apk is separate from the main APK, but it does package the main module as well. Perhaps setting the main module as a compile only module would still work and make the test APK lighter
• Android manifest merger is used as a CLI tool, and can probably be used via a classloader
• Resources are transitively resolved (see more here)
• Native dependencies are always packaged, in gradle this setting is controlled by a flag. We can also have a setting to filter out architectures in case someone targets specific devices and want to optimise their apk (although this is possible by overriding androidPackageableNativeDeps, it needs some knowledge of mill + android)

[vaslabs]

First iteration for reducing the androidTest apk

#5963

I suspect further reduction can be done with R8 (I found evidence in Gradle's resulting apk that R8 is involved) but will leave that work for a subsequent PR

[souvlakias]

While migrating the Jetcaster Compose sample, a few points came up about how we handle multi-module projects.
The main difference is that Gradle treats each non-app module as a library and produces an AAR for it.
We don’t have to go all the way to producing an AAR, but we should still treat these modules as libraries.

For example:

• The merged manifest shouldn’t include information about Maven dependencies.
• The generated R.txt or R.java file that's passed along should only include user-defined resources.

[vaslabs]

Code housekeeping

Android bundle

Android bundle is a non executable, non installable package . At the moment we have a separate trait which duplicates some of the logic and by now it's probably not supporting all the configurations we support with app module builds.

We can consider having a bundle task in the android module instead and get rid of the extra trait.

Maven layout

I think by now we are familiar with the android structure. We can align the android modules with the rest of mill, by mixing the maven module and cleaning up some duplicated code but also have android module traits that extend java modules, similar to Kotlin module approach

[vaslabs]

Security enhancements

So far we have support and examples for signing apks with user managed keys.

We can add support for Google signing services . Not sure about the example but maybe we can come up with a mock server