Safe your API Keys via Secrets Gradle plugin

Source: https://www.wallarm.com/what/api-key-meaning-what-is-it-and-what-is-it-for

Where should I start about hiding the API keys? It has been coming for a long time that we Android developers try to hide the key by putting in

1. BuildConfig in build.gradle
2. In strings.xml (You may remember Google provide the map key that we mostly put in strings.xml)
3. Sometimes we create a field and keep it in class.
4. In most wired places we think it’s internal code and we put it at the exact place where is being used.

In the end, guess what we end up pushing our API’s Secrets in the git history.

We all try to put app Secrets in BuildConfig in the build.gradle that is a great way to exclude the secrets from git history.

Let’s explore the spoon-feeding gradle plugin that gives us values in BuildConfig.

1. Install the Secrets Gradle Plugin in root of project build.gralde.kts
2. Add Secrets Gradle Plugin in module
3. Add Secrets Gradle Plugin configuration.
4. Add production secrets.properties
5. Add local local.defaults.properties

1. Install the Secrets Gradle Plugin in root of project build.gralde.kts

buildscript {
    dependencies {
        classpath("com.google.android.libraries.mapsplatform.secrets-gradle-plugin:secrets-gradle-plugin:2.0.1")
    }
}

Try to use an updated plugin version from https://github.com/google/secrets-gradle-plugin

2. Add Secrets Gradle Plugin in the module

plugins {
    id("com.google.android.libraries.mapsplatform.secrets-gradle-plugin")
}

Add above plugin in the module in which you want to include Secrets, If you have only app module then add there and you are done.

I know you will be thinking what about multi-module. It simple add modules where you need to use. we basically do in network or data module. Just go ahead and add module’s build.gradle.kts.

3. Add Secrets Gradle Plugin configuration.

Let’s add the plugin configurations. I know it feels like a lot when we hear configuration but this way to simple that’s why I mentioned spoon feeding.

android {
  ..........
}

secrets {
    // This production secrets file and going to contains real secrets
    propertiesFileName = "secrets.properties"

    // A properties file containing default secret values. This file can be
    // checked in version control. It can also contains demo secrets that 
    // you want outer wolrd to know.
    defaultPropertiesFileName = "local.defaults.properties"
}

Let’s sync the project and see the magic.

Oops I know, I know you can’t see anything added in the module’s BuildConfig

We forgot to add the field in local.defaults.properties or secrets.properties.

NOTE: Let me tell you difference between propertiesFileName and defaultPropertiesFileName. If propertiesFileName file is not present in the project it gonna build with defaultPropertiesFileName by default and once you will add propertiesFileName. It is going to use values mentioned in propertiesFileName.

Let’s see how’s the secrets.properties or local.defaults.properties would look like.

local.defaults.properties

# SERVER URL
SERVER_URL="http://example.com/"

# Provide GEO API Key
GEO_API_KEY="API_KEY"

secrets.properties

# SERVER URL
SERVER_URL="http://medium.com/"

# Provide GEO API Key
GEO_API_KEY="jwwqdwpymitxdfpzssryoqealgjvoupt"

So you put real values in secrets.properties and fake or demo in local.defaults.properties.

BuildConfig would look like

public final class BuildConfig {
  public static final boolean DEBUG = Boolean.parseBoolean("true");
  public static final String LIBRARY_PACKAGE_NAME = "com.android";
  public static final String BUILD_TYPE = "debug";
  public static final String FLAVOR = "demo";
  public static final String SERVER_URL = "http://medium.com/";
  public static final String GEO_API_KEY = "jwwqdwpymitxdfpzssryoqealgjvoupt";
}

Yes, finally we did it. Now you can go ahead and use these values in the code anywhere.