Skip to main content
Supported on: Android SDK 1.0.33+
Remote config lets you ship app behavior changes without releasing a new app version. Define key-value pairs in the Console, target them by audience or experiment, and read them from the SDK at runtime.

How It Works

  1. You define remote config keys in the Console.
  2. The SDK fetches the bundle (Firestore + REST fallback) at configure and fetches it again later (see When Config Refreshes). It does not keep a real-time listener on the config.
  3. Your app reads values via AppDNA.remoteConfig.get(key) and the SDK serves the latest cached value.
  4. Each time the SDK applies a fetched config, onChanged callbacks fire — whether or not a value changed, and possibly more than once per fetch — so your UI can re-read what it needs.
Remote config values are cached locally and survive offline use. The cache uses a configurable TTL (default 1 hour) — see Offline Support for cache behavior.

Get a Value

The Android SDK exposes a single typed-as-Any? getter — cast to the concrete type you stored:
Return type is Any?. The SDK preserves the value shape the Console stored (string, number, boolean, list, map). Use as? casts to coerce to the expected type and default with ?: when the key is missing. The top-level convenience method AppDNA.getRemoteConfig(key) is equivalent to AppDNA.remoteConfig.get(key).

Get All Values

Retrieve the entire config map:
Returns Map<String, Any> (empty map if config has not loaded yet).

Force Refresh

Force the SDK to fetch the latest configuration from the server, bypassing the TTL cache:
This is useful during development to test new config values without waiting for the TTL. The convenience method AppDNA.forceRefreshConfig() is equivalent.
Refreshing too frequently in production may impact performance and consume bandwidth. Rely on the default TTL for normal operation.

Listen for Changes

Register a callback that fires each time the SDK applies a fetched config (at configure, on a TTL refresh, on the background ConfigRefreshWorker refresh, on refresh() or AppDNA.forceRefreshConfig()) — whether or not a value changed, and possibly more than once per fetch:
The callback receives the full config snapshot — not just changed keys. Re-read whatever you care about and update your UI accordingly. Callbacks add up: each one you register fires. You can register before configure, and a callback stays registered after shutdown() and fires again once configure runs.

When Config Refreshes

The SDK refreshes remote config automatically:
  • At configure — once the bootstrap succeeds, the SDK fetches the config (if it fails, the SDK serves the cached config). If the bootstrap failed (for example, offline at launch), the fetch runs when a retry of the bootstrap succeeds — the SDK retries it when the network comes back, on foreground and after a backoff (Offline-first).
  • When the TTL elapses — while the process runs, the SDK fetches again once the config is older than the TTL (default 1 hour)
  • In the background — a WorkManager job (ConfigRefreshWorker) fetches every 15 minutes while the device is online; it skips a run when the SDK is not configured in that process
A value published in the Console reaches the app at the next of these fetches, or at AppDNA.remoteConfig.refresh() / AppDNA.forceRefreshConfig() (both fetch at once, bypassing the TTL); the SDK does not listen for it in real time. You rarely need to trigger a refresh manually. If a fetch fails (no connectivity, timeout), the SDK continues using the cached values until the next successful fetch.
The config TTL is configurable via AppDNAOptions(configTTL = 1800L) (in seconds). When you do not set it, the value the server returns with the SDK’s bootstrap request applies once the bootstrap succeeds, if it is positive; otherwise 3600 seconds (1 hour).

Module Access

Module Methods

Targeting and Variants

Remote config values are not targeted per user: every user of the app reads the same published value for a key. To give different users different behavior, run an experiment and branch on AppDNA.experiments.getVariant("id") — whether a user is in it, and which variant they get, is decided on the device (see Who Is in an Experiment).

Full Example

Configuration in Console

Manage remote config in the AppDNA Console:
  1. Open Settings → SDK → Config Bundle and find Remote Config.
  2. Click Add Flag, then set its key, type, value and an optional description.
  3. Click Save & Sync. The flags are published to the SDK’s config, together with the remote config items of the module Setup pages (listed below your flags, read-only; a flag you add with the same key replaces that item), and the config bundle is regenerated.
A save is refused, with the reason, when a value does not match its type (a Boolean flag takes true / false, a Number flag a number, a String flag text; a JSON flag takes any JSON value; an empty value is allowed for every type), when there are more than 500 flags, when one value is larger than 64 KB, or when the published flags — yours plus the Setup items — would exceed the 1 MB size of the document the SDK reads.
Remote config values are cached locally. To test new values immediately, call AppDNA.remoteConfig.refresh() or wait for the TTL to expire.

Next Steps