Android Feature Flags & Remote Config: Architecture, Rollouts, A/B Testing, and Kill Switches

Android Feature Flags & Remote Config: Architecture, Rollouts, A/B Testing, and Kill Switches

Not a Medium Member? “Read For Free”

Imagine releasing a new, highly anticipated checkout experience to millions of users. Ten minutes after rollout, your crash reporting dashboard turns red. Without feature flags, your only option is to publish an emergency hotfix and wait hours (or days) for the Play Store review process.

With a robust feature flag system, you can disable that feature instantly with a server-side toggle. This guide explores how to build a production-ready system to enable safe releases, targeted experimentation, and rapid incident response.

1. Architectural Blueprint

To maintain clean architecture, your UI must never interact directly with SDKs like Firebase. By introducing a simple provider abstraction, you decouple your business logic from the underlying vendor.

• UI/ViewModel: Consumes a type-safe FeatureFlagProvider.
• Provider: An abstraction layer that resolves flag values, insulating your app from the specific SDK implementation.

2. Type-Safe Flag Definitions

Avoid “magic strings” and runtime errors by using Kotlin’s type system to define your flags.

interface Flag<T> {
    val key: String
    val defaultValue: T
}

sealed interface AppFlag<T> : Flag<T>

object NewCheckout : AppFlag<Boolean> {
    override val key = "new_checkout"
    override val defaultValue = false
}

3. Implementation & Dependency Injection

By using an interface, you can easily swap implementations (e.g., for testing or migrating to a new provider).

The Abstraction Contract

interface FeatureFlagProvider {
    fun <T> getValue(flag: AppFlag<T>): T
}

Provider Implementation

Note: Always validate remote values and fall back to defaultValue if schema mismatches occur.

class FirebaseFeatureFlagProvider(
    private val remoteConfig: FirebaseRemoteConfig
) : FeatureFlagProvider {
    override fun <T> getValue(flag: AppFlag<T>): T {
        return when (flag.defaultValue) {
            is Boolean -> remoteConfig.getBoolean(flag.key) as T
            is String -> remoteConfig.getString(flag.key) as T
            is Long -> remoteConfig.getLong(flag.key) as T
            else -> flag.defaultValue
        }
    }
}

Hilt Integration

@Module
@InstallIn(SingletonComponent::class)
object FeatureFlagModule {
    @Provides
    fun provideFeatureFlagProvider(config: FirebaseRemoteConfig): FeatureFlagProvider {
        return FirebaseFeatureFlagProvider(config)
    }
}

4. Fetch & Cache Strategy

Configure your SDK to balance freshness and performance.

val settings = remoteConfigSettings {
    minimumFetchIntervalInSeconds = 3600 // Cache for 1 hour
}
remoteConfig.setConfigSettingsAsync(settings)

// Fetching new values
remoteConfig.fetchAndActivate().addOnCompleteListener { task ->
    if (task.isSuccessful) {
        // New values are now activated and available
    }
}

• First launch: The app uses local defaults until a remote config is fetched and activated.
• Persistent state: Once a value is activated, it is cached locally by the SDK across app restarts.

5. Observability & Testing

Don’t ship blind. Correlate feature state with your metrics and ensure your logic is testable.

Observability

val enabled = flagProvider.getValue(NewCheckout)
// Use custom keys for debugging
FirebaseCrashlytics.getInstance().setCustomKey("new_checkout_enabled", enabled)

// Measure feature adoption (API syntax may vary by provider)
analytics.logEvent("checkout_variant_shown", bundleOf("enabled" to enabled))

Testing with Fakes

Use a FakeFeatureFlagProvider to verify logic without hitting the network:

class FakeFeatureFlagProvider(
    private val values: Map<String, Any> = emptyMap()
) : FeatureFlagProvider {
    override fun <T> getValue(flag: AppFlag<T>): T = 
        values[flag.key] as? T ?: flag.defaultValue
}

6. The Feature Flag Lifecycle

Every release flag should be treated as temporary. Following this cycle keeps your codebase clean:

Create Flag ──> Internal Testing ──> Canary Rollout ──> 100% Rollout ──> Remove Flag

• Phased Rollouts: Gradually expose features to mitigate risk.
• A/B Testing: Assign users to variations to compare metrics.
• Kill Switches: Disable critical functionality instantly if metrics dip.

7. Governance & Common Mistakes

Common Mistakes:

• ❌ Blocking Startup: Performing synchronous fetches on the main thread.
• ❌ Direct Access: Using FirebaseRemoteConfig.getInstance() throughout the app.
• ❌ Never Removing Flags: Leaving stale logic in your codebase.

🙋 Frequently Asked Questions (FAQs)

Does the abstraction layer introduce measurable runtime overhead?

No. The performance impact is negligible; network latency and I/O are the actual bottlenecks.

How should I structure my modularized project?

Define a core-feature-flags module to house your interfaces, preventing circular dependencies.

🔚 Conclusion

Feature flags are more than simple toggles — they are a core component of modern software delivery. By combining type-safe abstractions, observability, and rigorous testing, Android teams can ship faster while significantly reducing operational risk.

💬 Continuing the Conversation

• How does your team currently track and “sunset” old feature flags?
• Have you ever successfully used a Kill Switch to prevent a production incident?

What is the single biggest technical challenge you face when testing code that relies on remote configuration?

📘 Master Your Next Technical Interview

Since Java is the foundation of Android development, mastering DSA is essential. I highly recommend “Mastering Data Structures & Algorithms in Java”. It’s a focused roadmap covering 100+ coding challenges to help you ace your technical rounds.

• E-book (Best Value! 🚀): **$1.99 on Google Play**
• Kindle Edition: **$3.49 on Amazon**
• Also available in Paperback & Hardcover.