---
title: "Improve Android build-times by using resConfigs"
source: "/writing/improve-android-build-times-by-using-resconfigs/"
---

Article

# Improve Android build-times by using resConfigs

Sean Weiser

December 16, 2020

Photo by [macayran](https://pixabay.com/photos/horse-race-hippodrome-horses-1665688/)

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](https://developer.android.com/studio/build/shrink-code#unused-alt-resources) 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](https://www.labkey.org/Documentation/wiki-page.view?name=gradleProps) . 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](https://developer.android.com/guide/topics/resources/providing-resources#AlternativeResources) . 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_](https://livefront.com) _, where everything is configurable._

-   Sean Weiser

    Principal Software Engineer

    [More from Sean](/team/sean-weiser/)

    Sean Weiser

### Tags

[Digital Engineering](/insights/all/?topic=digital-engineering) [Mobile Apps](/insights/all/?topic=mobile-apps)

### Share

-   Copied

## View these next.

[See all](/insights/all/?type=writing)

-   [

    Article

    How To Sabotage Your Project Using Inconsistency

    Collin Flynn

    ](/writing/how-to-sabotage-your-project-using-inconsistency/)
-   [

    Article

    Unit Testing race conditions by creating chaos (Swift)

    Sean Berry

    ](/writing/unit-testing-race-conditions-by-creating-chaos-swift/)
-   [

    Article

    UIApplicationDelegate call sequence reference

    Sean Berry

    ](/writing/uiapplicationdelegate-call-sequence-reference/)