Improve Android build-times by using resConfigs

If you work on a large Android project, you know how painful long builds can be. Any tweak that can reduce those build times saves many developer hours, especially for your local builds. If your application supports more than one language, you can eliminate some of that time by skipping resource processing for languages you don’t care about during development. Android supports removing unused alternative resources at build-time by using the resConfigs property. While working on an app, you probably need one language to verify functionality is working; the others are just taking up time and space in your build.

Adding resConfigs to your project

Actually adding resConfigs to your project is easy. Specify the languages you don’t want to filter out from your build in the default Android configuration block in your application module’s build.gradle file. For example, to filter out all non-English alternative resources, add the following:

However, once you check that change in, everyone else is affected: other developers, your CI system, and even your production releases. This change, as-is, can’t be made for any application that needs to support multiple languages. So, how can you get around this limitation?

Making resConfigs configurable

You need to allow each build to specify which languages, if any, it wants to filter out. The resConfigs property should be configurable based on developer-specific settings (i.e. settings that are not checked-in to source control).

First, add a new Gradle property to a location that is not checked-in, but is picked up by the build system. Your user-level gradle.properties file works well for this. See where that file exists on your system. I’ve called the new property supportedResConfigs:

Specify the languages you want to support by adding a comma-delimited list of language codes. This can be as short or as long as you want. You can also comment this line out if you don’t want to filter out any resources.

Next, add a new property to your build script to actually read that value in. It can go directly into your application module’s build.gradle file, but I typically add it to a separate file called buildConfig.gradle.

This creates a new property called supportedResConfigs, which is either null if the Gradle property isn’t defined or is a list containing all languages you want to support.

Finally, reference that property when specifying resConfigs:

Remember to apply buildTasks.gradle (or whatever you called it) if you included that code in a separate file.

Once added, this code allows each individual developer to specify the languages they want to support in their local builds. It also allows your CI system and other non-developer builds to completely ignore the resConfigs property and include all languages.

More resConfigs options

resConfigs controls more than just the language resources included in your build. You’re allowed to reference values for any resource qualifier. We discussed filtering out unneeded languages, but what if you also want to filter out dark mode drawables? Or not include any landscape layouts? Or maybe even all of those at the same time for some reason?

That snippet filters out all alternative resources from a resource folder with any non-en language qualifier, any non-notnight night mode qualifier, and any non-port orientation qualifer. Do you have resources you want to include in an en-night folder? Too bad! Even though they are English language resources, they get excluded due to the night qualifer. As mentioned earlier, the list of values can be as extensive and non-sensical as you want. As long as it’s configurable, though, it won’t impact anyone else.

Sean works for Livefront, where everything is configurable.