The Android Asset Packaging Tool (aapt2) takes all those lovely resources (images, strings, cat pictures, and whatnot) in your Android app, and compiles them into a binary format that the runtime understands. It's also the thing that generates numerical identifiers and constants for them in R.java, which is the class you use to refer to resources in code.

You should rarely have reasons to interact with aapt2 directly, since for most Android developers, it's something that happens automatically during a build with Gradle, or your build system of choice (e.g. Bazel, or in our case Buck). Suffice to say, you're either doing seriously hardcore interesting things, or you're maybe working on a build / developer infra or something like that (we're hiring!) if you're interacting directly with this tool.

aapt2 operates in two phases; in the compile phase, it converts individual resources into a binary representation (either a .flat file or a .flata, which is just a zip of .flat files). The usually more expensive link phase merges all of these individual resources together into a final .ap_ file, which is just like an APK except with no code. For a while, I super enjoyed dropping "flata" and "ap underscore" into random conversations around the dinner table and relished the confusion on the face of those around me. My family love me really. Anyway.

For some reason, maybe following the, "if it ain't broke" principal, we were using quite an old version of aapt2 for quite some time, then tried to upgrade at some point. There were some new goodies we wanted in the latest version, but when we upgraded we ran into a slew of incompatibilities (caused by our own infamous creativity for the most part) that had to be fixed, and then a significant increase in the aapt2 link phase of our builds. Slow builds make everyone sad.

The next couple of blog entries will talk about two specific optimizations I made to aapt2 a while back to speed it up for a (cough) well known large Android app that may or may not be associated with my employer.

The next blog post in this series talks about a small bug fix that saved 45s of build time.