Skip to main content

How I learned to love aapt2

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.

Comments

Popular posts from this blog

Java Blooper #2: Must be a Better Way...

The post you're reading is ancient, and yet slightly inexplicably popular :) I've recently started blogging again in 2020 with some fresh content. Check out some of the new topics about blogging again, dynamic method invocation, and aapt2.It's Monday, which means it's time for another blooper... What's wrong with this code? boolean hasThing( List things, Thing thing ) { for ( int i=0; i < things.size(); i++ ) { if ( thing.equals( things.get( i ) ) ) { return true; } } return false; } Update: Minor edit to add missing parenthesis from if statement that got "lost in translation" en-route to the blog :)

Configuring Mac OS X Terminal

The post you're reading is ancient, and yet slightly inexplicably popular :) I've recently started blogging again in 2020 with some fresh content. Check out some of the new topics about blogging again, dynamic method invocation, and aapt2.I recently installed Leopard (Mac OSX 10.5) on a new mac. There are a few factory settings I usually change on a new installation, although by far fewer than I do typically with Windows. One of them is the default keyboard configuration for Ctrl+Left Arrow, Ctrl+Right Arrow, Page Up, Page Down, Home, and End in Terminal. The default settings drive me a bit potty since I'm used to using Linux and emacs every day at work.Changing them is easy, fortunately. Just visit Keyboard under Settings in Terminal->Preferences, and modify the following keys, so that their action matches the value shown. You can edit the keystroke for an item by double clicking on it, selecting "send string to shell", and typing the indicated keys.KeyActio…

Java Blooper #1: Ternary Insanity

The post you're reading is ancient, and yet slightly inexplicably popular :) I've recently started blogging again in 2020 with some fresh content. Check out some of the new topics about blogging again, dynamic method invocation, and aapt2.From time to time, we all write code that could be clearer. Sometimes in the rush of solving a problem, we don't pay attention to the micro details of the code flowing from our fingertips. Other times, we refactor some existing code, and don't necessarily take the opportunity to clean up as much as we could.I find it useful sometimes when reading code to think about whether it could be rewritten in a more straightforward way, and if so whether any lessons can be learned about writing tight and expressive, and most importantly, readable code.Over the next few weeks, I'm going to blog weekly examples of some Java code bloopers that I've seen. All the examples are real and have been observed "in the wild". However some…