v4.4.0 - Add Support for Layers

Release Notes

• Introduces getLayer API to Statsig, adding the ability to get values via a Layer configuration set on the Statsig Console. See docs.statsig.com/layers
• Fixes a crash in DynamicConfig.getInt

Crash Insights - Unsafe Type Casting

We use GSON for parsing of JSON objects. By default, GSON treats all numbers as Double types. We had some unsafe casts in the SDK that convert Double as Int, which throws a ClassCastException.

Impacted Versions: v4.3.1 and below

The SDK has been updated to correctly converts these values to the desired type.

• bd0b0ab

v4.3.1 - Harden the SDK by limited usage of local storage, timeout on shutdown

Also added logic to catch exceptions which should never happen in normal usage, but could if the local storage is overriden in a weird way (or we change types in the future)

v4.3.0 - improve local cache and expose more properties about experiments

• reworked local cache for experiments and feature gates so that they are now keyed on a combination of userID and customIDs, and multiple set of caches can exist at the same time for different users.
• exposed getIsUserInExperiment and getIsExperimentActive on the DynamicConfig class

v4.2.4 - Save DynamicConfig from Proguard

DynamicConfig is our helper class for developers to integrate with DynamicConfigs and Experiments set up in the Statsig console, but it is actually an unused class in the SDK itself. So proguard took the liberty of stripping it out. This ensures that wont happen

Reported in statsig-io/statsig-feedback#19

v4.2.3 - adding logic to avoid logging duplicated exposures

To reduce memory and network bandwidth usage, in this release we added some logic to avoid logging duplicated exposures when the same gate/experiment for a given user is checked multiple times

v4.2.2 - bug fix

Fixed a bug where the SDK was not passing the correct value in the systemName field. Now it always passes "Android" for the field.

v4.2.1 - Fixes a bug where updateUser would poll for updated values

Polling for updated values should only happen in initialize and updateUser with the enableAutoValueUpdate flag in StatsigOptions set to true

v4.2.0 - Synchronous initialize path, logger on background thread

initializeAsync now does synchronous initialization up front, before issuing a network request and then finally calling the callback

logEvents now are queued on a background thread

Device experimentation, sticky user bucketing, and bug fixes

With this release, we are adding support for 2 experimentation features as well as a few important bug fixes:

• Device level experiments.
  • Now the Android SDK keeps track and send a "stable ID" (a.k.a. device ID) that is kept on the device for as long as the application's cache lives. This allows Statsig users to run device level experiments, which use the stable ID as the identifier and keep feature experiences consistent across log-out -> log-in.
• Sticky user bucketing for experiments.
  • Added keepDeviceValue parameter for the getExperiment API. When it's set to true, the group that a user is in for a given experiment is saved and used for the same device, until the experiment is concluded.
• Bug fixes:
  • fixed a bug where cached values were not committed to shared preferences.
  • fixed a bug where names in exposure loggings were hashed.

v4.0.0 - Updated Java API

1. Hide kotlin functions from java API, update IStatsigCallback

interface IStatsigCallback {
    fun onStatsigInitialize()

    fun onStatsigUpdateUser()
}

2. changes to internal SDK coroutine usage.

3. we are passing secondary exposures along with gate/experiment values to the SDK during initialize, so that when exposures are logged, secondary exposures are also recorded/logged at the same time. This improves the efficiency and accuracy of secondary exposures, which were previously evaluated and logged when Statsig server receives the primary exposure loggings.