4.0.0

[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."

This feature is only available to members of LaunchDarkly's Early Access Program (EAP). If you're in the EAP, you can use contexts by updating your SDK to the latest version and, if applicable, updating your Relay Proxy. Outdated SDK versions do not support contexts, and will cause unpredictable flag evaluation behavior.

If you are not in the EAP, only use single contexts of kind "user", or continue to use the user type if available. If you try to create contexts, the context will be sent to LaunchDarkly, but any data not related to the user object will be ignored.

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

[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

[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

[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

[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

[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

[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

[3.1.7] - 2022-08-17

Fixed:

• All Timber logs now use a consistent tag LaunchDarklySdk. (Thanks, audkar!)

3.1.6

[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

[3.1.5] - 2022-05-05

Fixed

• Prevent NullPointerException when event buffer is full and diagnosticOptOut is true. (Thanks, mattyway!)