Change log
All notable changes to the LaunchDarkly Android SDK will be documented in this file. This project adheres to Semantic Versioning.
5.16.0 (2026-08-27)
Features
- add registerPlugin so a plugin can be added after the client starts (8204d6b)
- add registerPlugin so a plugin can be added after the client starts (#393) (49b7c9f)
Bug Fixes
- make the close/reset timer tests deterministic (0160533)
- make the close/reset timer tests deterministic (#394) (984d2e6)
5.15.0 (2026-08-17)
Features
- add HookDecorator so a hook wrapper forwards the stages it does not override (c78c612)
- add HookDecorator so a hook wrapper forwards the stages it does not override (#387) (d118a62)
5.14.0 (2026-08-12)
Features
- add per-hook evaluation exposure deduplication (#380) (7c49324)
- default the exposure deduper to a 10 minute window over 2000 keys (749508e)
- let each hook choose how its exposures are deduplicated (399fcd7)
Bug Fixes
- attribute an evaluation to the context it read the flag for (9e88483)
- keep exposure keys distinct across environments (f46f1c9)
- measure a dedupe window against a clock a time correction cannot move (4c3467a)
- publish the hook list safely across threads (fd34a85)
- publish the hook list safely across threads (#382) (c2687ad)
Performance Improvements
- hash an exposure key only when something asks for its hash (2c29f46)
5.13.3 (2026-07-31)
Bug Fixes
- add defensive cycle guard to prerequisite evaluation (#377) (0372708)
- allow stream to recover from 429, 400, and 408 responses (#379) (2ad5e6f)
5.13.2 (2026-07-10)
Bug Fixes
- coalesce SharedPreferences writes to reduce memory pressure (#374) (bc82217)
5.13.1 (2026-06-09)
Bug Fixes
- remove deprecation marker from LDConfig.Builder.plugins (1c681c2)
- remove deprecation marker from LDConfig.Builder.plugins (#371) (2446924)
5.13.0 (2026-06-08)
Features
- experimental: Android Client SDK FDv2 EAP (#369) (2597ad8)
5.12.2 (2026-06-03)
Bug Fixes
- set 401 guard before notifying error callback to prevent restart race (d875b00)
- set 401 guard before notifying error callback to prevent restart race (#362) (24b2f38)
- set connection401Error before invoking resultCallback in onError (#332) (6fb1b85)
5.12.1 (2026-06-02)
Bug Fixes
- track order processing to forward according contracts (#358) (d4218a7)
5.12.0 (2026-04-29)
Features
5.11.2 (2026-04-29)
Miscellaneous Chores
- releasing version with DataSystem hidden in preparation for FDv2 EAP (2f10f8d)
5.11.1 (2026-03-23)
Bug Fixes
5.11.0 (2026-02-13)
Features
- Add support for per-context summary events. (#320) (c5f078f)
5.10.0 (2025-12-11)
Features
- Add plugins registration result handling (#318) (ea4a41c)
5.9.2 (2025-10-17)
Bug Fixes
- bumping gson to incorporate fixes and improvements (#312) (9ee3537)
5.9.1 (2025-07-21)
Bug Fixes
- prevent flag change listener from being invoked with null flag key (#307) (feada66)
5.9.0 (2025-07-16)
Features
- adds experimental plugin functionality (#305) (2bca41b)
5.8.0 (2025-05-27)
Features
5.7.0 (2025-05-19)
Features
- Add support for inline contexts for custom events (#296) (7ea838f)
5.6.1 (2025-01-21)
Bug Fixes
- correcting protocol parsing logic that may lead to incorrect sanitization of an incoming message from LD servers (#288) (9969148)
5.6.0 (2025-01-08)
Features
- polling data source now supports one shot configuration (a995a4e)
Bug Fixes
- polling data source no longer reports initialized=true incorrectly when rate limiting delays first poll (a995a4e)
5.5.0 (2024-11-22)
Features
- honor polling interval across process restarts (#282) (9b3ca70)
5.4.0 (2024-10-18)
Features
- Adds support for client-side prerequisite events (#279) (8d59b96)
5.3.1 (2024-07-10)
Bug Fixes
- registered LDStatusListeners are now sent updates that result from a call to LDClient.identify(...) (#274) (a648213)
5.3.0 (2024-05-13)
Features
- improved streaming behavior by decreasing maximum retry interval (#268) (81f1912)
5.2.0 (2024-04-25)
Features
- deprecating init without timeout (1e46f0d)
5.1.1 (2024-03-26)
Bug Fixes
- improved LDClient.identify(...) behavior when offline (#261) (24ce942)
5.1.0 (2024-03-14)
Features
- Always inline contexts for feature events (2a88ef6)
- Redact anonymous attributes within feature events (2a88ef6)
Bug Fixes
- Bump launchdarklyJavaSdkInternal to 1.3.0 (#257) (2a88ef6)
5.0.5 (2024-03-07)
Bug Fixes
- propagating NPE fix for ContextBuilder.fromContext bug (#246) (3205005)
[5.0.4] - 2024-02-27
Fixed:
- Improved thread usage in streaming connections.
[5.0.3] - 2024-02-02
Fixed:
- Fixes a bug in which a race condition between identify and network state change could result in a crash.
[5.0.2] - 2023-09-19
Fixed:
- Fixed a rare bug in key generation in some contexts generated by the Auto Environment Attributes feature.
[5.0.1] - 2023-08-25
Fixed:
- Updated how Auto Environment Attributes sanitizes and validates provided values to provide a more user friendly experience.
[5.0.0] - 2023-08-03
Added:
- Added Automatic Mobile Environment Attributes functionality which makes it simpler to target your mobile customers based on application name or version, or on device characteristics including manufacturer, model, operating system, locale, and so on. To learn more, read Automatic environment attributes.
Removed
[4.3.0] - 2023-08-03
Changed:
[4.2.3] - 2023-06-07
Fixed:
- Streaming data connection to a relax proxy now calls the callback correctly after fetching the flag data.
- Flag listeners are now called correctly after
identify results in flag value changes.
[4.2.2] - 2023-05-17
Fixed:
- Fixed NPE when closing a LDClient in certain cases.
- Fixed NPE when creating a multi-context that included one invalid context.
[4.2.1] - 2023-03-15
Fixed:
- Fixed an issue where the allFlagsListener would be not be informed of changed flags. Now the allFlagsListener will be called correctly. This issue was introduced in 4.0.0 .
[4.2.0] - 2023-01-11
Added:
LDConfig.Builder.applicationInfo(), for configuration of application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.
[3.6.0] - 2023-01-11
Added:
LDConfig.Builder.applicationInfo(), for configuration of application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.
[4.1.1] - 2023-01-06
Fixed:
- The fix for unnecessarily long-lived polling connections in the 3.2.2 release was incomplete: rather than turning off the keep-alive behavior, it only reduced it from 10 minutes to 5 minutes. It should now close the connection immediately after each request as intended.
[3.5.1] - 2023-01-06
Fixed:
- The fix for unnecessarily long-lived polling connections in the 3.2.2 release was incomplete: rather than turning off the keep-alive behavior, it only reduced it from 10 minutes to 5 minutes. It should now close the connection immediately after each request as intended.
[4.1.0] - 2022-12-22
Added:
StreamingDataSourceBuilder.streamEvenInBackground, an option for allowing the SDK to maintain a streaming data connection even when the application is in the background.
[3.5.0] - 2022-12-22
Added:
StreamingDataSourceBuilder.streamEvenInBackground, an option for allowing the SDK to maintain a streaming data connection even when the application is in the background.
[3.4.0] - 2022-12-22
This release is broken and should not be used. It was an accidental duplicate of 4.1.0.
[3.3.1] - 2022-12-21
Fixed:
- If the application is in the background when the SDK is started, the SDK will go into polling mode and immediately make a flag data request to LaunchDarkly. Previously, in this scenario the first poll would not happen until the background poll interval elapsed, so the SDK would effectively never have flag data at initialization time for an app or service that started in the background.
[4.0.1] - 2022-12-19
Fixed:
- If the application is in the background when the SDK is started, the SDK will go into polling mode and immediately make a flag data request to LaunchDarkly. Previously, in this scenario the first poll would not happen until the background poll interval elapsed, so the SDK would effectively never have flag data at initialization time for an app or service that started in the background.
[4.0.0] - 2022-12-07
The latest version of this SDK supports LaunchDarkly's new custom contexts feature. Contexts are an evolution of a previously-existing concept, "users." Contexts let you create targeting rules for feature flags based on a variety of different information, including attributes pertaining to users, organizations, devices, and more. You can even combine contexts to create "multi-contexts."
For detailed information about this version, please refer to the list below. For information on how to upgrade from the previous version, please read the migration guide.
Added:
- In
com.launchDarkly.sdk, the types LDContext and ContextKind define the new context model.
- For all SDK methods that took an
LDUser parameter, there is now an overload that takes an LDContext. The SDK still supports LDUser for now, but LDContext is the preferred model and LDUser may be removed in a future version.
- The
TestData class in com.launchdarkly.sdk.android.integrations is a new way to inject feature flag data programmatically into the SDK for testing—either with fixed values for each flag, or with targeting logic that can return different values for different contexts.
Changed (breaking changes from 3.x):
- It was previously allowable to set a user key to an empty string. In the new context model, the key is not allowed to be empty. Trying to use an empty key will cause evaluations to fail and return the default value.
- There is no longer such a thing as a
secondary meta-attribute that affects percentage rollouts. If you set an attribute with that name in LDContext, it will simply be a custom attribute like any other.
- The
anonymous attribute in LDUser is now a simple boolean, with no distinction between a false state and a null state.
Changed (behavioral changes):
- The SDK no longer uses Android's
AlarmManager API to schedule background polling of flag data. Instead, it uses a simple worker thread. AlarmManager notifications could wake up a sleeping device, which is not desirable just for getting flag data.
- Analytics event data now uses a new JSON schema due to differences between the context model and the old user model.
- The SDK no longer adds
device and os values to the user attributes. Applications that wish to use device/OS information in feature flag rules must explicitly add such information.
Removed:
- Removed all types, fields, and methods that were deprecated as of the most recent 3.x release.
- Removed the
secondary meta-attribute in LDUser and LDUser.Builder.
- The
alias method no longer exists because alias events are not needed in the new context model.
- The
autoAliasingOptOut and inlineUsersInEvents options no longer exist because they are not relevant in the new context model.
[3.3.0] - 2022-12-02
The primary purpose of this release is to introduce newer APIs for SDK configuration, corresponding to how configuration will work in the upcoming 4.0 release. The corresponding older APIs are now deprecated; switching from them to the newer ones now will facilitate migrating to 4.0 in the future. This also brings the Android SDK's API closer in line with other current LaunchDarkly SDKs, such as the Java SDK and the .NET SDKs.
Previously, most configuration options were set by setter methods in LDConfig.Builder. These are being superseded by builders that are specific to one area of functionality: for instance, Components.streamingDataSource() and Components.pollingDataSource() provide builders/factories that have options specific to streaming or polling, and the SDK's many options related to analytics events are now in a builder returned by Components.sendEvents(). Using this newer API makes it clearer which options are for what, and makes it impossible to write contradictory configurations like .stream(true).pollingIntervalMillis(30000).
The new configuration builders also include some options for SDK behavior that could not previously be configured; see "Added".
Added:
Components, containing factory methods for the various configuration builders.- Configuration builder classes in
com.launchdarkly.sdk.android.integrations: StreamingDataSourceBuilder, PollingDataSourceBuilder, EventProcessorBuilder, HttpConfigurationBuilder, ServiceEndpointsBuilder.
- It is now possible to entirely disable analytics events, by setting
LDConfig.Builder.events() to Components.noEvents().
- It is now possible to substitute a test fixture for the analytics events subsystem, by creating a custom implementation of
com.launchdarkly.sdk.android.subsystems.EventProcessor.
- It is now possible to change the initial delay for reconnecting after a stream connection failure, with
StreamingDataSourceBuilder.initialReconnectDelayMillis().
Deprecated:
(all in LDConfig.Builder)
pollingIntervalMillis, stream: see PollingDataSourceBuilder.backgroundPollingIntervalMillis: see PollingDataSourceBuilder and StreamingDataSourceBuilder.allAttributesPrivate, diagnosticRecordingIntervalMillis, eventsCapacity, eventsFlushIntervalMillis, inlineUsersInEvents, privateAttributes: see EventProcessorBuilder.connectionTimeoutMillis, headerTransform, useReport, wrapperName, wrapperVersion: see HttpConfigurationBuilder.streamUri, pollUri, eventsUri: See ServiceEndpointsBuilder.
[3.2.3] - 2022-11-16
Fixed:
- The SDK no longer updates SharedPreferences data during every flag evaluation. It was using this to store summary counters for analytics events; however, the small chance that a subset of summary data could be lost, if the application terminated before events were delivered, was outweighed by the performance cost (and other types of analytics data were not being stored like this anyway). It now uses a simpler in-memory data structure. (#194)
[3.2.2] - 2022-10-27
Fixed:
- The SDK was using a connection pool with a keep-alive interval of at least 10 minutes for polling requests. This has been removed and each request now uses a new connection. The keep-alive behavior was not desirable for foreground polling: foreground polling is only done if streaming was explicitly disabled, which would likely be because the application does not want to leave a connection open. And it was of no use for background polling, since the interval for that is at least an hour. One undesirable consequence was that if the 10-minute interval expired after the device had gone to sleep, the small amount of network traffic involved in shutting down the connection could wake the device up again.
[3.2.1] - 2022-09-28
Fixed:
- The SDK now detects and cancels any repeating polling task that might have been left over from a previous run of the application. The potential problem was that if an application crashed or otherwise did not shut down cleanly, an "alarm" notification used by the SDK for polling could continue to exist, causing the application to be started again and to keep polling for LaunchDarkly flag data, even though the user intended to shut down the application. With this fix, such an unintended restart could still happen once, but the SDK will detect this condition and stop the notification from continuing to fire. In the future the SDK may be changed more broadly to stop using the AlarmManager API so that such restarts cannot happen at all, but this fix mitigates the problem in the meantime. (#188)
[3.2.0] - 2022-08-23
The purpose of this release is to introduce a new logging facade, com.launchdarkly.logging, to streamline how logging works in LaunchDarkly Java and Android code.
Previously, the Android SDK always used Timber for logging. This sometimes led to conflicts with an application's separate use of Timber, as described in #88 and #147.
In this release, the default behavior is still to use Timber, but the logging facade can also be configured programmatically to do simple Android logging without Timber, or to forward output to another framework such as java.util.logging, or to multiple destinations, or to capture output in memory. In a future major version release, the default behavior may be changed so that the SDK does not require Timber as a dependency.
Added:
- In
LDConfig.Builder, the new methods logAdapter, logLevel, and loggerName, for the new logging capabilities mentioned above.
- New class
LDTimberLogging for configuring the SDK's Timber integration.
- New class
LDAndroidLogging for configuring the SDK to use the Android logging API without Timber.
[3.1.8] - 2022-08-23
Changed:
- Changed throttling/jitter logic that used
java.util.Random to use java.security.SecureRandom. Even though in this case it is not being used for any cryptographic purpose, but only to produce a pseudo-random delay, static analysis tools may still report every use of java.util.Random as a security risk by default. The purpose of this change is simply to avoid such warnings; it has no practical effect on the behavior of the SDK.
Fixed:
- The map of existing
LDClient instances was not being cleared after calling close(). (#108)
- Fixed a bug that caused an
ExecutorService object to be unnecessarily created when flush() was called.
- The SDK did not correctly persist versioning information when a flag was deleted or archived. In an edge case where flag updates are received out of order, this could cause a deleted flag to appear to be undeleted.
- Setting
baseUri or streamUri to a URI with a trailing slash could cause requests to fail. Now the SDK works correctly regardless of whether these URIs have a trailing slash or not.
- The SDK was including
"anonymous": false in analytics event data for users where the anonymous property had not been set at all. In the current user model, "anonymous": false is subtly different from not setting the property (flag rules referencing anonymous will only work if it is explicitly set), so the event data should accurately represent this by omitting the property if it was omitted.
- Fixed a bug that could cause a NullPointerException when calling
variation methods, in an edge case where the SDK received inconsistent data of a kind that the LaunchDarkly services would not normally send (an evaluation result with a value but no variation). This should not be possible in practice, but could happen in test scenarios.
[3.1.7] - 2022-08-17
Fixed:
- All Timber logs now use a consistent tag
LaunchDarklySdk. (Thanks, audkar!)
[3.1.6] - 2022-08-01
Added:
- CI builds now include the SDK test harness, a standardized contract test suite that validates the SDK's behavior against simulated LaunchDarkly endpoints.
Fixed:
- Deadlock between
Throttler and ConnectivityManager. (Thanks, res0nance!)
- Remove object-level locking in
LDClient that caused synchronous init()s to unnecessarily block other methods, resulting in ANRs.
[3.1.5] - 2022-05-05
Fixed
- Prevent
NullPointerException when event buffer is full and diagnosticOptOut is true. (Thanks, mattyway!)
[3.1.4] - 2022-03-23
Fixed
- Removed Android Appcompat dependency.
- Bump version of okhttp from 4.9.1 to 4.9.2.
- Prevent multiple allocations of the DiagnosticEventProcessor.
- Removed application
android:label attribute from the SDK's manifest. (Thanks, Exaper!)
[3.1.3] - 2022-02-24
Fixed
- Add explicit proguard directives for keeping BroadcastReceivers
- Bump version of git-publish gradle plugin from 3.0.0 to 3.0.1.
[3.1.2] - 2021-12-17
Fixed
- Bump version of gson dependency from 2.8.6 to 2.8.9.
[3.1.1] - 2021-09-03
Fixed
- Removed the
android:allowBackup tag from the SDK's AndroidManifest.xml file to avoid requiring applications to explicitly replace the tag if given a different value. (#138)
- Changed the SDK's network detection check to consider network transport over a VPN as a connected state. This fixes an issue where the SDK would prevent network requests on a VPN due to considering the network to be unavailable. (Thanks, lguipeng!)
[3.1.0] - 2021-08-06
Added
- The SDK now supports the ability to control the proportion of traffic allocation to an experiment. This works in conjunction with a new platform feature now available to early access customers.
[3.0.2] - 2021-07-16
Fixed
- Catch
SecurityException when thrown on call to getNetworkCapabilities used to detect current network availability. (#129)
- Explicitely flag
PendingIntents as FLAG_IMMUTABLE on Android SDK versions that support doing so. Explicitly specifying mutability is required when targeting Android S+. (#133)
[3.0.1] - 2021-06-25
Fixed
- The Android manifest has been updated to explicitly specify the
android:exported attribute on declared receiver elements. This is to meet new requirements in the upcoming Android 12 release.
- Increased the compile-time dependency on
jackson-databind to 2.10.5.1, due to CVE-2020-25649.
- Update the dependency on the shared launchdarkly/java-sdk-common to 1.1.2 to prevent Jackson from showing up as a transitive dependency in tools that inspect module metadata.
[2.14.2] - 2021-06-02
Fixed
- Added check to prevent
NullPointerException in DiagnosticEventProcessor.stopScheduler when LDClient.close is called before the application is foregrounded when the SDK was initialized in the background. (#127)
- Log message warning that JSON flag was requested as a String has been updated to include the key of the flag requested to assist in discovering which flag is being requested with an unexpected type. (#116)
[3.0.0] - 2021-05-07
This major version has an accompanying Migration Guide. Please see the guide for more information on updating to this version of the SDK, as the following is just a summary of the changes.
Usages of Gson provided types have been removed from the public API, replacing JsonElement with LDValue provided by the SDK. LDValue can represent the same values as a JsonElement, but has a diferent API. See the API documentation for a detailed reference.
Added
LDConfig.Builder customization:
- The
autoAliasingOptOut configuration option that is used to control the new automatic aliasing behavior of the identify method; by setting autoAliasingOptOut to true, identify will not automatically generate alias events.
- The
headerTransform configuration option that supersedes the previous additionalHeaders configuration option by allowing fully dynamic updating of headers for requests the SDK makes to the LaunchDarkly service.
- The
privateAttributes configuration option that replaces setPrivateAttributeNames, specifying the private attributes as vararg UserAttribute arguments rather than a Set<String>. This allows easily specifying built-in attributes.
LDUser(String) constructor that creates a fully default user.- New accessors for
LDUser
getAttribute(UserAttribute) for programmatically retrieving attribute values.getCustomAttributes() for retrieving the currently set custom attributes.getPrivateAttributes() for retrieving the attributes set to be private on this user.isAttributePrivate(UserAttribute) for checking if a given attribute is private.- Getters for all built-in attributes, e.g.
getName()
- New
LDUser.Builder methods overloads for custom and privateCustom:
custom(String, boolean) and privateCustom(String, boolean) for setting custom attributes to boolean values.custom(String, int), privateCustom(String, int), custom(String, double), and privateCustom(String, double) for setting custom attributes to numeric values.custom(String, LDValue) and privateCustom(String, LDValue) for setting custom attributes to arbitrary data.
- The
UserAttribute class, which provides a less error-prone way to refer to user attribute names in configuration. This class can also be used to get arbitrary attribute- LDClient functionality:
- The
alias method that is used to associate two user objects for analytics purposes with an alias event.
jsonValueVariation and jsonValueVariationDetail. These are equivalent to the removed jsonVariation and jsonVariationDetail other than using LDValue instead of JsonElement.trackData(String, LDValue) which replaces track(String, JsonElement). Other than changing to use LDValue the behavior is the same.trackMetric(String, LDValue, double) which replaces track(String, JsonElement, Double). This also uses LDValue rather than JsonElement, and requires a metric value. Otherwise use trackData.
- The
LDGson and LDJackson classes, which allow SDK classes like LDUser to be easily converted to or from JSON using the popular Gson and Jackson frameworks.
EvaluationDetail.fromValue and EvaluationDetail.error factory methods.LDHeaderUpdater interface for the new headerTransform configuration option.
Fixed
- Fixed an issue where the SDK could log error level messages when attempting to send diagnostic events without an internet connection. The SDK will no longer attempt to send diagnostic events when an internet connection is known to be unavailable, and will not log an error level message if the connection fails. Thanks to @valeriyo for reporting (#107).
- Fixed an issue where
LDUser instances created before calling LDClient.init without specifying a key would have the key UNKNOWN_ANDROID rather than a device unique key.
- Fixed an issue where flags listeners would be informed of changes to unchanged flags whenever the SDK receives an entire flag set (on a new stream connection, a poll request, or any stream updates behind a relay proxy).
- Fixed an issue where a
NullPointerException is thrown if LDClient.close() is called multiple times.
- Improved the proguard/R8 configuration to allow more optimization. Thanks to @valeriyo for requesting (#106)
- Fixed a potential issue where the SDK could cause additional throttling on requests to the backend service when previously throttled requests had been cancelled before completion.
Changed (requirements/dependencies/build)
- Migrated from using the Android Support Libraries to using AndroidX from Jetpack. Using AndroidX requires the
android.useAndroidX Android Gradle plugin flag to be set to true in your application's gradle.properties file. If your application previously set the android.enableJetifier Android Gradle plugin flag to true in it's gradle.properties file soley for the LaunchDarkly SDK, this flag can now be removed. Thanks to everyone who requested this enhancement (#103).
- The minimum Android API version has been raised from API level 16 (Android 4.1 Jelly Bean) to API level 21 (Android 5.0 Lollipop).
- The SDK no longer has a dependency on Google Play Services. This dependency was only used on pre-21 Android API levels to improve TLS 1.2 compatibility, as the minimum Android version has been raised to 21, the dependency is no longer necessary.
- The SDK is now built with modern Gradle (6.7, Android plugin 4.1.3) and uses Java 8.