March 5, 2016

    Managing and securing your app’s configuration


     In this article, we will cover a simple way to take advantage of the Gradle build system’s build variants. This helps you to easily define different server URLs and API keys for these different environments. Moving your environment configuration into Gradle’s build variants means you are not reliant on manual code changes (which can be error-prone) before releasing your live app version.

    We will also cover the use of DexGuard’s asset encryption to ensure the protection of your configuration values from static code analysis.

    There is accompanying sample code located here, which illustrates the techniques discussed in this article. We recommend you to read the Android development documents, as it contains useful information on getting started with build variants.

    Built-in Gradle configuration options

    Environment build variants

    When we talk about environment, we mean server environment, data or external application. When developing applications, it’s common practice to define different environments for each stage of the project, for example development, testing and release.

    We can apply different configurations to our application to match those environments. For example:

    • debug – the development release, typically with verbose logging and pointing to non-live APIs and/or data sets.

    • qa – the testing release for your testers to sign off. It is nearly as productive as possible except pointing at testing API/data environment.

    • release – the version ready for upload/distribution (also called live or production).

    buildTypes { 
      debug { 
        debuggable true 
        applicationIdSuffix ".debug" 
        proguardFiles getDefaultProguardFile ('proguard-android.txt'), 'proguard-project.txt' } release { 
        proguardFiles getDefaultProguardFile ('proguard-android.txt'), 'proguard-project.txt' } } 

    This code shows standard debug and release build type configurations.

    Common build variant attributes

    Seasoned Android developers are likely familiar with the following attributes that can be defined within the buildTypes or buildFlavors sections of the application’s file.

    • versionNameSuffix '-debug' – this adds ‘debug’ to the end of the versionName, which is useful in the case of occuring crashes, so that you can identify them as originating from a debug build of the app.

    • applicationIdSuffix '.debug' – defining an applicationIdSuffix for the debug/qa build variants alters the applicationId. This is very useful as it allows multiple versions of the same app to be installed on your device.

    • signingConfig signingConfigs.release – signingConfig allows you to define a different signing certificate for each build variant. This can be useful when interacting with certain third party APIs (such as the Facebook Android SDK) that require the signing certificate key hash to be added to the server side configuration.

    Using Android resources to differentiate between build variants

    As noted in the previous section, you can install multiple versions of the same application on a device using the applicationIdSuffix. This can help during development and testing, in particular with regression testing. However, by default each installation will have the same name and icon, so it can be difficult to identify which app is which on the app launcher draw.

    In the next section, we will cover a way to define a different app name per build variant.

    Creating a different app name for the debug build variant

    To identify debug builds of our example we shall create a new xml resources file called app_name.xml with the below content in debug/res/values/

    <?xml version="1.0" encoding="utf-8"?> 
      <!-- differ between each version --> 
      <string name="app_name">Config debug</string> 

    Note: The debug folder directly corresponds to the name of the debug build variant.

    Creating the release build variant’s app name

    For the release build variant we create the same file app_name.xml as above, except this time located under the release variants folder, i.e. release/res/values/

    We must define an attribute with the key of app_name, but this time we use the name of the app we want to have when the app is released. For example:

    <?xml version="1.0" encoding="utf-8"?>
      <!-- differ between each version -->
      <string name="app_name">Config example</string>

    Reference @string/app_name in the application element

    To ensure that our app uses the app_name we just defined, we have to reference the @string/app_name in our application element in the app’s Android Manifest.xml file.

      android:theme="@style/AppTheme" > 

    Changing the app icon

    For further customization, we can also change the app icon to include some kind of visual indicator to indicate it’s not a release build. Using the same method as described above we’ve added a bug icon to the corner of the ic_launcher.png.  

    Using properties file based configuration

    Now we’ll have a look at adding deeper configuration for your app’s build types. This will allow you to configure your app to point at different API servers depending on the build variant.

    For each of your buildtypes you have to create a file called in the <buildtype>/assets folder within app/src. For our example we create two files with these full paths:

    <project root>/app/src/debug/assets/ 
    <project root>/app/src/release/assets/ 

    Utility class to read file

    The code below defines an AssetPropertyManager class. This is a simple utility class to handle the reading of the properties file from the apps/assets directory and to provide property values to the rest of the app via getters.

    private static final String PROP_FILE = ""; 
    private final Properties properties = new Properties(); 
    public AssetPropertyManager(Context context) { 
      AssetManager assetManager = context.getAssets(); 
      try { 
      } catch (IOException ignored) { 
      // TODO: Handle error 

    You have to create getter methods for each of your config properties.

    public String getFlurryKey() { 
      return properties.getProperty(CONFIG_FLURRY); 

    Optimization tip

    It’s a good idea to initialize the AssetPropertyManager when the application starts up, to avoid blocking any UI code that might need the config data.

    public class MyApp extends Application { 
      public void onCreate() { 
      assetPropertyManager = new AssetPropertyManager(this); 
      public AssetPropertyManager getAssetPropertyManager() { 
      return assetPropertyManager; 

    Now you have to use the getApplication().getAssetPropertyManager().getFlurryKey() in your code when you need to pass the api key.

    DexGuard protection

    Separating your config into a properties file eases maintenance, but it also makes it easier for an attacker to find out if the file decompiles your application’s .apk file. Therefore it’s recommended to use a binary protection tool such as DexGuard.

    This is the DexGuard configuration needed to ensure these environment config values are secured.

    Define the following in your project’s dexguard-project.txt file:

    -encryptassetfiles assets/

    Or you could add the following line to encrypt all asset files in the assets directory:

    -encryptassetfiles assets/**

    After encryption of our example, the file looks like this:

    When we view the file from the protected .apk, the source has been encrypted and cannot be easily decrypted.

    Additional protection

    For additional protection, you may want to encrypt the string constants in the AssetPropertyManager and encrypt the entire class.

    -encryptstrings class com.scottyab.configexample.AssetPropertyManager -encryptclasses com.scottyab.configexample.AssetPropertyManager 


    First, we have covered several useful ways to vary an Android app’s configuration depending on the build type or build flavor. We have utilised built-in Android Gradle plugin variables such as 'applicationIdSuffix' and 'signingConfig'. Next, we have further customised the configuration by extracting our app’s environment configuration into a separate file. This is illustrated in the code sample that accompanies this article. This change has made it easier to find and maintain the configuration between build types or build flavors, which is ideal for new developers to a project. Finally, we have reviewed how to enable and configure DexGuard to secure those configuration options.

    Scott Alexander-Bown

    About the author
    Scott Alexander-Bown (@scottyab) is an independent Android developer and co-author of the Android Security Cookbook. He is also the founder of SWmobile, a mobile developer-focused Meetup group which runs tech talks, networking and hacking events.

    Tag(s): Android , Technical , Dexguard


    Discover how Guardsquare provides industry-leading protection for mobile apps.

    Request Pricing

    Other posts you might be interested in