All notable changes to the LaunchDarkly Android SDK will be documented in this file. This project adheres to Semantic Versioning.
5.12.0 (2026-04-29)
5.11.2 (2026-04-29)
- releasing version with DataSystem hidden in preparation for FDv2 EAP (2f10f8d)
5.11.1 (2026-03-23)
5.11.0 (2026-02-13)
5.10.0 (2025-12-11)
5.9.2 (2025-10-17)
5.9.1 (2025-07-21)
5.9.0 (2025-07-16)
5.8.0 (2025-05-27)
5.7.0 (2025-05-19)
5.6.1 (2025-01-21)
- 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)
- polling data source now supports one shot configuration (a995a4e)
- polling data source no longer reports initialized=true incorrectly when rate limiting delays first poll (a995a4e)
5.5.0 (2024-11-22)
5.4.0 (2024-10-18)
5.3.1 (2024-07-10)
- registered LDStatusListeners are now sent updates that result from a call to LDClient.identify(...) (#274) (a648213)
5.3.0 (2024-05-13)
5.2.0 (2024-04-25)
- deprecating init without timeout (1e46f0d)
5.1.1 (2024-03-26)
5.1.0 (2024-03-14)
- Always inline contexts for feature events (2a88ef6)
- Redact anonymous attributes within feature events (2a88ef6)
5.0.5 (2024-03-07)
- Improved thread usage in streaming connections.
- Fixes a bug in which a race condition between identify and network state change could result in a crash.
- Fixed a rare bug in key generation in some contexts generated by the Auto Environment Attributes feature.
- Updated how Auto Environment Attributes sanitizes and validates provided values to provide a more user friendly experience.
- 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 LDUser and related functionality. Use LDContext instead. To learn more, read https://docs.launchdarkly.com/home/contexts.
- Deprecated LDUser and related functionality. Use LDContext instead. To learn more, read https://docs.launchdarkly.com/home/contexts.
- Streaming data connection to a relax proxy now calls the callback correctly after fetching the flag data.
- Flag listeners are now called correctly after
identifyresults in flag value changes.
- Fixed NPE when closing a LDClient in certain cases.
- Fixed NPE when creating a multi-context that included one invalid context.
- 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 .
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.
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.
- 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.
- 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.
StreamingDataSourceBuilder.streamEvenInBackground, an option for allowing the SDK to maintain a streaming data connection even when the application is in the background.
StreamingDataSourceBuilder.streamEvenInBackground, an option for allowing the SDK to maintain a streaming data connection even when the application is in the background.
This release is broken and should not be used. It was an accidental duplicate of 4.1.0.
- 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.
- 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.
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.
- In
com.launchDarkly.sdk, the typesLDContextandContextKinddefine the new context model. - For all SDK methods that took an
LDUserparameter, there is now an overload that takes anLDContext. The SDK still supportsLDUserfor now, butLDContextis the preferred model andLDUsermay be removed in a future version. - The
TestDataclass incom.launchdarkly.sdk.android.integrationsis 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.
- 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
secondarymeta-attribute that affects percentage rollouts. If you set an attribute with that name inLDContext, it will simply be a custom attribute like any other. - The
anonymousattribute inLDUseris now a simple boolean, with no distinction between a false state and a null state.
- The SDK no longer uses Android's
AlarmManagerAPI to schedule background polling of flag data. Instead, it uses a simple worker thread.AlarmManagernotifications 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
deviceandosvalues to the user attributes. Applications that wish to use device/OS information in feature flag rules must explicitly add such information.
- Removed all types, fields, and methods that were deprecated as of the most recent 3.x release.
- Removed the
secondarymeta-attribute inLDUserandLDUser.Builder. - The
aliasmethod no longer exists because alias events are not needed in the new context model. - The
autoAliasingOptOutandinlineUsersInEventsoptions no longer exist because they are not relevant in the new context model.
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".
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()toComponents.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().
(all in LDConfig.Builder)
pollingIntervalMillis,stream: seePollingDataSourceBuilder.backgroundPollingIntervalMillis: seePollingDataSourceBuilderandStreamingDataSourceBuilder.allAttributesPrivate,diagnosticRecordingIntervalMillis,eventsCapacity,eventsFlushIntervalMillis,inlineUsersInEvents,privateAttributes: seeEventProcessorBuilder.connectionTimeoutMillis,headerTransform,useReport,wrapperName,wrapperVersion: seeHttpConfigurationBuilder.streamUri,pollUri,eventsUri: SeeServiceEndpointsBuilder.
- 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)
- 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.
- 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)
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.
- In
LDConfig.Builder, the new methodslogAdapter,logLevel, andloggerName, for the new logging capabilities mentioned above. - New class
LDTimberLoggingfor configuring the SDK's Timber integration. - New class
LDAndroidLoggingfor configuring the SDK to use the Android logging API without Timber.
- Changed throttling/jitter logic that used
java.util.Randomto usejava.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 ofjava.util.Randomas 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.
- The map of existing
LDClientinstances was not being cleared after callingclose(). (#108) - Fixed a bug that caused an
ExecutorServiceobject to be unnecessarily created whenflush()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
baseUriorstreamUrito 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": falsein analytics event data for users where theanonymousproperty had not been set at all. In the current user model,"anonymous": falseis subtly different from not setting the property (flag rules referencinganonymouswill 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
variationmethods, 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.
- All Timber logs now use a consistent tag
LaunchDarklySdk. (Thanks, audkar!)
- CI builds now include the SDK test harness, a standardized contract test suite that validates the SDK's behavior against simulated LaunchDarkly endpoints.
- Deadlock between
ThrottlerandConnectivityManager. (Thanks, res0nance!) - Remove object-level locking in
LDClientthat caused synchronousinit()s to unnecessarily block other methods, resulting in ANRs.
- Prevent
NullPointerExceptionwhen event buffer is full anddiagnosticOptOutis true. (Thanks, mattyway!)
- 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:labelattribute from the SDK's manifest. (Thanks, Exaper!)
- Add explicit proguard directives for keeping BroadcastReceivers
- Bump version of git-publish gradle plugin from 3.0.0 to 3.0.1.
- Bump version of gson dependency from 2.8.6 to 2.8.9.
- Removed the
android:allowBackuptag from the SDK'sAndroidManifest.xmlfile 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!)
- 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.
- Catch
SecurityExceptionwhen thrown on call togetNetworkCapabilitiesused to detect current network availability. (#129) - Explicitely flag
PendingIntents asFLAG_IMMUTABLEon Android SDK versions that support doing so. Explicitly specifying mutability is required when targeting Android S+. (#133)
- The Android manifest has been updated to explicitly specify the
android:exportedattribute on declaredreceiverelements. This is to meet new requirements in the upcoming Android 12 release. - Increased the compile-time dependency on
jackson-databindto 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.
- Added check to prevent
NullPointerExceptioninDiagnosticEventProcessor.stopSchedulerwhenLDClient.closeis 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)
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.
LDConfig.Buildercustomization:- The
autoAliasingOptOutconfiguration option that is used to control the new automatic aliasing behavior of theidentifymethod; by settingautoAliasingOptOutto true,identifywill not automatically generate alias events. - The
headerTransformconfiguration option that supersedes the previousadditionalHeadersconfiguration option by allowing fully dynamic updating of headers for requests the SDK makes to the LaunchDarkly service. - The
privateAttributesconfiguration option that replacessetPrivateAttributeNames, specifying the private attributes as varargUserAttributearguments rather than aSet<String>. This allows easily specifying built-in attributes.
- The
LDUser(String)constructor that creates a fully default user.- New accessors for
LDUsergetAttribute(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.Buildermethods overloads forcustomandprivateCustom:custom(String, boolean)andprivateCustom(String, boolean)for setting custom attributes to boolean values.custom(String, int),privateCustom(String, int),custom(String, double), andprivateCustom(String, double)for setting custom attributes to numeric values.custom(String, LDValue)andprivateCustom(String, LDValue)for setting custom attributes to arbitrary data.
- The
UserAttributeclass, 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-LDClientfunctionality:- The
aliasmethod that is used to associate two user objects for analytics purposes with an alias event. jsonValueVariationandjsonValueVariationDetail. These are equivalent to the removedjsonVariationandjsonVariationDetailother than usingLDValueinstead ofJsonElement.trackData(String, LDValue)which replacestrack(String, JsonElement). Other than changing to useLDValuethe behavior is the same.trackMetric(String, LDValue, double)which replacestrack(String, JsonElement, Double). This also usesLDValuerather thanJsonElement, and requires a metric value. Otherwise usetrackData.
- The
- The
LDGsonandLDJacksonclasses, which allow SDK classes likeLDUserto be easily converted to or from JSON using the popular Gson and Jackson frameworks. EvaluationDetail.fromValueandEvaluationDetail.errorfactory methods.LDHeaderUpdaterinterface for the newheaderTransformconfiguration option.
- 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
LDUserinstances created before callingLDClient.initwithout specifying a key would have the keyUNKNOWN_ANDROIDrather 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
NullPointerExceptionis thrown ifLDClient.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.
- Migrated from using the Android Support Libraries to using AndroidX from Jetpack. Using AndroidX requires the
android.useAndroidXAndroid Gradle plugin flag to be set totruein your application'sgradle.propertiesfile. If your application previously set theandroid.enableJetifierAndroid Gradle plugin flag totruein it'sgradle.propertiesfile 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.
- Package names have changed: the main SDK classes are now in
com.launchdarkly.sdkandcom.launchdarkly.sdk.android. - All
LDConfig.Buildersetters have been renamed to remove thesetprefix, e.g.LDConfig.Builder.setMobileKeyhas been renamed toLDConfig.Builder.mobileKey. LDClientAPI changes:boolVariationandintVariationno longer use nullable object types for argument and return values, instead using primitive types, e.g.Boolean boolVariation(String, Boolean)becameboolean boolVariation(String, boolean).boolVariationDetailandintVariationDetailno longer use nullable object types for argument values, instead using primitive types, e.g.boolVariationDetail(String, Boolean)becameboolVariationDetail(String, boolean).allFlags()now returnsMap<String, LDValue>rather thanMap<String, ?>. Rather than the returnedMapcontainingBoolean,Float, andStringtyped objects, with JSON values represented as strings, theMapcontainsLDValuetyped objects which return the source type (including complex types such as JSON arrays and objects).
EvaluationDetail.getVariationIndex()now returnsintinstead ofInteger. No variation index is now represented as the constantEvaluationReason.NO_VARIATION.EvaluationReasonis now a single concrete class rather than an abstract base class. Usages of the sub-classes can be replaced with the base class.
- The default polling domain (configurable with
LDConfig.Builder.pollUri) has changed fromapp.launchdarkly.comtoclientsdk.launchdarkly.com. - The default
eventsUriused to send events to the service has changed fromhttps://mobile.launchdarkly.com/mobiletohttps://mobile.launchdarkly.com. The SDK will now append the expected endpoint path (/mobile) to the configuredUri, which is more consistent with other LaunchDarkly SDKs. - For compatibility with older SDK behavior, the
LDClient.stringVariationmethod could be used to retrieve JSON flags in a serialized representation. This compatibility behavior has been removed, and attempts to request a JSON valued flag usingstringVariationwill behave the same as other mismatched type variation calls. - The
LDClient.identifymethod will now automatically generate an alias event when switching from an anonymous to a known user. This event associates the two users for analytics purposes as they most likely represent a single person. This behavior can be disabled with theautoAliasingOptOutconfiguration option. - All log messages are now tagged
LaunchDarklySdkfor easier filtering. Thanks to @valeriyo for the suggestion (#113). LDUsernow overridesequals,hashCode, andtoStringwith appropriate implementations.LDUser.Builder.country(String)andLDUser.Builder.privateCountry(String)no longer attempt to look up the country from the providedString(attempting to match it as an ISO-3166-1 alpha-2, alpha-3 code; or a country name) and set the country to the resultant IOS-3166-1 alpha-2 only if successful. The SDK no longer gives this attribute special behavior, and sets the user's country attribute directly as the providedString.
LDConfig.Builder:setBaseUri(Uri)has been removed. Please usesetPollUri(Uri)instead.setAdditionalHeaders(Map<String,String>)has been removed. Please useheaderTransform(LDHeaderUpdater)instead.setPrivateAttributeNames(Set<String>)has been removed. Please useprivateAttributes(UserAttribute...)instead.
LDUser.Builder:country(LDCountryCode)andprivateCountry(LDCountryCode)have been removed. Usecountry(String)orprivateCountry(String)to set the country value on a user.custom(String, Number)andprivateCustom(String, Number)have been removed. Use the(String, int)or(String, double)overloads instead.custom(String, Boolean)andprivateCustom(String, Boolean)have been removed. Usecustom(String, boolean)orprivateCustom(String, boolean)instead.custom(String, List<String>),LDUser.customString(String, List<String>),LDUser.privateCustomString(String, List<String>). Usecustom(String, LDValue)andprivateCustom(String, LDValue)instead.customNumber(String, List<Number>)andLDUser.privateCustomNumber(String, List<Number>). Usecustom(String, LDValue)andprivateCustom(String, LDValue)instead.
LDClient:floatVariationandfloatVariationDetailhave been removed. UsedoubleVariationanddoubleVariationDetailinstead.jsonVariationandjsonVariationDetailhave been removed. UsejsonValueVariationandjsonValueVariationDetailinstead.track(String, JsonElement)andtrack(String, JsonElement, Double)overloads have been removed, please use the designated methodstrackData(String, LDValue)andtrackMetric(String, LDValue, double)instead.
- The public constructor for
EvaluationDetailhas been hidden. Use the new factory methodsEvaluationDetail.fromValueandEvaluationDetail.errorinstead. - The concrete sub-classes of
EvaluationReasonhave been removed in favor of makingEvaluationReasona concrete class. The accessors on the sub-classes have been moved to the base class. Instead of usinginstanceOfto determine the type, usegetKind(). LDCountryCodehas been removed as no SDK APIs use this class.- All classes and interfaces in the
com.launchdarkly.sdk.android.flagstore,com.launchdarkly.sdk.android.gson,com.launchdarkly.sdk.android.response, andcom.launchdarkly.sdk.android.tlspackages. These classes and interfaces were not intended for external use. Debounce,FeatureFlagFetcher,SummaryEventSharedPreferences,UserSummaryEventSharedPreferences, andUtilincom.launchdarkly.sdk.android. These deprecated classes and interfaces were not intended for external use.
- Before this release, the SDK could cause an uncaught exception on certain Android implementations, when scheduling a future poll request under certain situations. This fix extends a previous fix implemented in the 2.9.1 release of the SDK, which catches
SecurityExceptions thrown by the alarm manager when registering an alarm for the next poll. ThisSecurityExceptionwas introduced by Samsung on their Lollipop and later Android implementions, and is thrown when the application has at least 500 existing alarms when registering a new alarm. After recent reports of the alarm manager throwing anIllegalStateExceptionrather than aSecurityExceptionunder the same conditions but different Android implementations, this release broadens the exception handling when scheduling a poll request to safeguard against other exception types.
- Added
LDConfig.Builder.setPollUriconfiguration setter that is equivalent to the now deprecatedsetBaseUri. - Added
LDConfig.getPollUriconfiguration getter that is equivalent to the now deprecatedgetPollUri. - Added
LDClient.doubleVariationfor getting floating point flag values as adouble. This is preferred over the now deprecatedfloatVariation.
- Improved event summarization logic to avoid potential runtime exceptions. Thanks to @yzheng988 for reporting (#105).
- Internal throttling logic would sometimes delay new poll or stream connections even when there were no recent connections. This caused switching active user contexts using
identifyto sometimes delay retrieving the most recent flags, and therefore delay the completion of the returnedFuture.
- The maximum delay the internal throttling logic could delay a flag request has been reduced to 60 seconds.
- Deprecated
LDConfig.Builder.setBaseUriandLDConfig.getBaseUri, please usesetPollUriandgetPollUriinstead. - Deprecated
LDClient.floatVariation, please usedoubleVariationfor evaluating flags with floating point values.
- Allow specifying additional headers to be included on HTTP requests to LaunchDarkly services using
LDConfig.Builder.setAdditionalHeaders. This feature is to enable certain proxy configurations, and is not needed for normal use.
- Added a new configuration option,
maxCachedUsersto LDConfig. This option allows configuration of the limit to how many users have their flag values cached locally in the device's SharedPreferences.
- Fixed a NPE that could occur when calling a variation methods with a flag key that does not exist locally or is of the wrong type. This issue could only occur if a null fallback value was provided.
- Previously, the SDK manifest required the SET_ALARM permission. This permission was never used, so it has been removed.
- For polling requests, the SDK uses OkHttp with a cache configured. Previously the cache directory was set to the main application cache directory. This has been changed to a subdirectory of the application cached directory.
- Packages that contained only deprecated classes.
flagstore,flagstore.sharedprefs,gson,response, andtls.
- The SDK now periodically sends diagnostic data to LaunchDarkly, describing the version and configuration of the SDK, the Android API SDK version number, and performance statistics. No credentials, Android device IDs, or other identifiable values are included. This behavior can be disabled with
LDConfig.Builder.setDiagnosticOptOut(boolean)or configured withLDConfig.Builder.setDiagnosticRecordingInterval(int). - New
LDConfig.Builderfield setterssetWrapperName(String)andsetWrapperVersion(String). These allow a library wrapping the SDK (for example, the React Native SDK) to identify itself for usage data.
- Fixed an issue where in some cases the future associated with an
initoridentifycall would never complete if the network status or foreground state changed before the future had completed. Also improved test coverage of this behavior.
UserSummaryEventSharedPreferences,SummaryEventSharedPreferences,FeatureFlagFetcher,Util, andDebounce. These classes were only intended for internal SDK use, and will be removed in the next major release to reduce the number of exposed classes.
- The SDK now specifies a uniquely identifiable request header when sending events to LaunchDarkly to ensure that events are only processed once, even if the SDK sends them two times due to a failed initial attempt.
- All classes in sub-packages, which were only intended for use by the SDK. These classes will be removed in the next major release.
LDCountryCode, as well asLDUsersetters that tookLDCountryCodeas an argument. TheStringoverloads should be used instead, as these will be removed in the next major release. Until that release the additional validation on the country fields will remain, see the Javadoc for more information.
- Removed possibility of fatal
SecurityExceptionon Samsung devices that would be triggered when the SDK attempted to register an alarm to trigger a future poll when the application process already had 500 alarms registered. This limit is only present on Samsung's versions of Android Lollipop and later. The SDK will now catch this error if it occurs to prevent killing the host application. - Rarely, the client would deliver its initial "identify" event to LaunchDarkly immediately rather than waiting for the configured flush interval.
- Fixed some malformed Javadoc comments.
- Added support for new LaunchDarkly experimentation features. See
LDClient.track(String, JsonElement, Double)for recording numeric metrics. - Substantially improved test coverage for SDK behavior in different Application states (network connectivity and backgrounding).
- The
Futurereturned byLDClient.identifycould not complete as intended for certain connectivity states. When in a background state this could not complete until the next background polling cycle, or never if background polling was disabled.
- Added a CircleCI badge to the project readme.
- Fix a bug introduced in 2.8.0 that could cause the SDK to enter a bad state where it would no longer connect to the flag stream if
identify()was called rapidly. - Reverted an unintentional behavior change introduced in 2.8.0 when
LDClient.initis given zero as the timeout argument. Before 2.8.0, this would not wait for initialization and return the client immediately. For 2.8.0-2.8.4 this was changed to wait indefinitely for initialization, 2.8.5 restores the earlier behavior.
- Deadlock when waiting on main thread for
identifycall. - ConcurrentModificationException caused by PollingUpdater or ConnectivityReceiver iterating over LDClient instances during initialization.
- Improved error handling on flag store migration.
- ClassCastException when migrating flag store from certain early Android SDK versions.
- Thread leak (introduced in 2.8.0) when calling
identify()onLDClientinstances.
- Changed the artifact id from
com.launchdarkly:launchdarkly-android-clienttocom.launchdarkly:launchdarkly-android-client-sdk - Changed repository references to use the new URL
There are no other changes in this release. Substituting com.launchdarkly:launchdarkly-android-client version 2.8.0 with com.launchdarkly:launchdarkly-android-client-sdk version 2.8.1 will not affect functionality.
- LDAllFlagsListener interface that can be registered to a LDClient instance. The SDK will call the listener's onChange method whenever it receives an update, passing a list of any flag keys that were updated to the listener.
- Class ConnectionInformation that contains information about the current status of the SDK. This class can be retrieved with the method getConnectionInformation on a LDClient instance and contains information on the current connectivity mode, timestamps of most recent successful and unsuccessful connections to LaunchDarkly, as well as information on the most recent connection failure (if any).
- LDStatusListener interface that can be registered to a LDClient instance. The interface has a method onConnectionModeChanged that will be called when the LDClient instance transitions between connectivity modes (due to foreground status changes, network connectivity changing, or explicitly being set). The listener also has a method onInternalFailure that will be called when the instance experiences a failure updating it's flag store. The SDK is expected to recover from these failures, the listener is supplied to allow more informed monitoring of any underlying reasons the flag store may be not up to date.
- Demo of new ConnectionInformation functionality to example application.
- Internal usages of Guava
- Potential issue that could cause dropping of flag updates if SDK received updates in close succession.
- SDK will no longer assume that the application is started in the foreground, which can be untrue if started by Android's ActivityManager in response to a broadcast.
The LaunchDarkly SDK repositories are being renamed for consistency. This repository is now android-client-sdk rather than android-client.
The artifact id will also change. In the 2.8.0 release, it is still com.launchdarkly:launchdarkly-android-client; in all future releases, it will be com.launchdarkly:launchdarkly-android-client-sdk. No further updates to the com.launchdarkly:launchdarkly-android-client artifact will be published after this release.
- The new configuration option
setEvaluationReasons(true)causes LaunchDarkly to report information about how each feature flag value was determined; you can access this information with the new client methodsboolVariationDetail,stringVariationDetail, etc. The new methods return an object that contains both the flag value and a "reason" object which will tell you, for instance, if the user was individually targeted for the flag or was matched by one of the flag's rules, or if the flag returned the default value due to an error. For more information, see the SDK Reference Guide on evaluation reasons. - The new client method
getVersion()returns the version string of the SDK.
- Bug causing
boolVariation,intVariation, andfloatVariationto always returnnulliffallbackargument wasnull. - Potential issue where environment versions for flag updates could compare incorrectly due to floating point coercion.
- Summary events for unknown flags (flags evaluated without any stored value, variation, or version) now include the returned value as intended.
- Inaccurate events caused by data for flag version and variation being unsynchronized with flag value.
- Bug causing some events to be dropped from summary counts due to data race in sending and updating summary events.
- Potential
ClassCastExceptioncrash on some devices due to old version of OkHttp. - Improved documentation comments throughout.
- Crash on migration when no primary mobile key is specified.
- CircleCI V1 config file
- Support for connecting to multiple environments through LDClient interface.
- Security provider hot patch for devices without support for TLSv1.2 (requires Google Play Services to be successful).
- Use Timber formatting instead of String concatenation in logging.
- Replace Log calls with Timber in example app.
- Client now parses and stores flag version information correctly in polling mode, allowing these fields to be included in feature and summary events.
- Prevent example app from permanently closing LDClient on first backgrounding.
- Support for Android Ice Cream Sandwich, 4.0.3, API 15
- Outbound HTTP requests now have an authentication scheme token in
Authorizationrequest headers
- Polling for flag updates might block the main thread
- Refactored map synchronization to avoid crashes in apps build with Gradle 3.3.0-alpha11
- Restored support for network connectivity detection in Android 7.0+ devices
- Restored support for initializing
LDClienton non-main threads
- Handling of
Futurereturned byLDClient.init() DateHTTP header parsing specifies US locale
ClassCastExceptionwhen callingvariationmethods due to internal storage schema changes between releases 2.3.x and 2.4.0.LDUser.Builder.custom()no longer returnsUnsupportedOperationException.
LDClient#identify(LDUser)now returns aFuture<Void>so that the app can be notified when flag values have been refreshed for the updated user.
- Removed the unused
com.noveogroup.android:android-loggerdependency that prevented some consuming apps from assembling.
- To reduce the network bandwidth used for analytics events, feature request events are now sent as counters rather than individual events, and user details are now sent only at intervals rather than in each event. These behaviors can be modified through the LaunchDarkly UI and with the new configuration option
inlineUsersInEvents. For more details, read Data Export. - New method
setInlineUsersInEventsinLDConfig. Whentrueincludes the full user (excluding private attributes) in analyticsfeatureandcustomevents. Whenfalseincludes only theuserKey. Default:false.
- Updated
Timberdependency to version4.7.0.
- Application class removed from SDK, to avoid conflict with apps
- SDK logging is now using Timber.
- Increased the maximum backoff time for stream reconnection to 1 hour.
- The
setOnline()method may be throttled if called too frequently.
- Support for enhanced feature streams, facilitating reduced SDK initialization times.
- The minimum polling interval is now 5 minutes, and the default event publishing interval is 30 seconds.
- HTTP requests are cached in the app's cache directory.
- The SDK now provides a
consumer-proguard-rules.profile containing recommended ProGuard rules. - Due to a Guava dependency update, we recommend a new ProGuard rule which you may need to add if the rules in
consumer-proguard-rules.proare not applied automatically:
-dontwarn com.google.errorprone.annotations.**
- Restored support for Java 1.7.
- Support for specifying private user attributes in order to prevent user attributes from being sent in analytics events back to LaunchDarkly. See the
allAttributesPrivateandsetPrivateAttributeNamesmethods onLDConfig.Builderas well as theprivateXmethods onLDUser.Builder.
AndroidManifest.xmlno longer enforcessupportsRtl="true"- Client no longer reconnects after detecting an invalidated mobile key
- Client can be initialized outside the main thread. Thanks @jonathanmgrimm!
LDConfig.Builder#setUseReportmethod to allow switching the request verb fromGETtoREPORT. Do not use unless advised by LaunchDarkly.
LDClient.initvalidates that its arguments are non-null.
- Stream connections are closed completely when the app enters background mode.
- Fewer HTTP requests are made to the LaunchDarkly service when feature flags are updated frequently.
- Potential
NullPointerExceptionin thevariationmethods. - Removed spurious error when
LDClientis initialized while the device is offline.
- Potential
ConcurrentModificationExceptionwithLDClient#unregisterFeatureFlagListener
- Modified default and minimum background polling intervals.
- Improved http client lifecycle management.
- Improved offline saving of flags when switching users.
- Even better thread safety in UserManager when removing change listeners.
- Improved thread safety in UserManager when removing change listeners.
- Streamlined SDK initialization.
- The
Future<LDClient>returned fromLDClient.initnow also waits for the feature flag rules to be retrieved.
- More configurable flag update mechanisms including the ability to disable streaming. See README.md for details.
- API BREAKING CHANGE: Guava ListenableFuture is no longer returned from LDClient. Instead we're returning java.util.concurrent.Future.
- Added configurable background polling.
- Improved Json variation handling.
- Improved stream connection lifecycle management.
- Removed SLF4J logger in LDUser.
- Updated suggested Proguard rules for a smaller footprint.
- Suggested Proguard rules now include keep instructions. This should help with some GSON serialization issues.
- Log when GSON serialization problem may be occuring.
- Updated GSON and okhttp-eventsource dependencies
- First release of Android SDK.