How would you manage API keys in Gradle without version control?

WHAT THIS TESTS: This question tests your practical knowledge of secure development practices within the Android ecosystem. The interviewer is looking for more than just a basic "put it in local.properties". They want to see if you understand the standard tooling, its configuration, its limitations, and how it integrates with both local development and CI/CD pipelines. It's a test of your ability to manage project configuration responsibly at scale.

A GOOD ANSWER COVERS: A strong answer outlines a four-step strategy. First, identify the recommended tool, which is the official Google Secrets Gradle Plugin (com.google.android.libraries.mapsplatform.secrets-gradle-plugin). Second, describe the setup: add the plugin classpath to the root build.gradle.kts and apply it in the app-level build.gradle.kts. Third, explain the storage mechanism: secrets are placed in a key-value format in a properties file (e.g., local.properties or a custom one) which MUST be included in .gitignore. Fourth, explain the access mechanism: the plugin makes these properties available as fields in the generated BuildConfig class, which can be accessed from your Kotlin or Java code. A bonus point is mentioning you can also inject them into the AndroidManifest.xml.

COMMON WRONG ANSWERS: A significant red flag is suggesting any method that involves checking secrets into version control, even if obfuscated or in a "private" repository. Another common but incomplete answer is just saying "use local.properties" without mentioning the plugin; this approach is brittle and doesn't easily expose values to BuildConfig without custom Gradle scripting. The biggest mistake is failing to acknowledge the limitation: this plugin only protects secrets from being in your Git history. It does NOT protect them from being extracted from a compiled APK by a determined attacker. A senior candidate must mention this trade-off.

LIKELY FOLLOW-UPS: Be prepared for "How would you provide these secrets to your CI/CD pipeline?" The answer involves using the CI provider's secret management system (e.g., GitHub Actions Secrets, GitLab CI/CD variables) to dynamically create the secrets.properties file on the build runner before the Gradle build starts. Another follow-up could be, "What if you need different keys for debug and release builds?" This can be handled by defining different properties files or using Gradle's build variant-aware configuration.

ONE CONCRETE EXAMPLE: For a new project, I would add the Secrets Gradle Plugin v2.0.1 or newer to my root build.gradle.kts. I would then create a secrets.properties file, add API_KEY="your_secret_key" to it, and immediately add secrets.properties to my .gitignore file. In the app's build.gradle.kts, I'd configure the plugin to use this file. The API key would then be accessible in my code as BuildConfig.API_KEY. For the CI pipeline, I would have a step that runs echo API_KEY=$PROD_API_KEY_SECRET > secrets.properties, where the secret value is injected by the CI system.