This document provides release notes for significant updates to Iterable's Android SDK.
TIP
For granular release notes, take a look at the Iterable Android SDK releases page on GitHub.
# In this article
# 3.5.9
January 17, 2025
Version 3.5.9 of Iterable's Android SDK includes a fix for the silent push notification–related bug introduced in versions 3.5.7. and versions 3.5.8.
# 3.5.7 and 3.5.8
January 13 and 15, 2025
These versions of the SDK are deprecated. Do not use them.
Versions 3.5.7
and 3.5.8
of Iterable's Android SDK include changes to help keep a user's Iterable profile
in sync with their physical device's push settings for your app (by keeping the
device's notificationsEnabled
flag up-to-date in Iterable).
However, these versions of the SDK include a bug that can prevent the SDK from receiving silent push notifications, which in turn can prevent end users from receiving expected in-app and embedded messages.
If you've started building on this version of the SDK, please roll back to a previous version while we work on a fix.
# 3.5.3
July 8, 2024
Version 3.5.3 of Iterable's Android SDK provides more insight into JWT refresh failures, so you can take appropriate action in your application code.
Now, when a JWT refresh fails (for any of various reasons), the SDK calls
onAuthFailure(AuthFailure authFailure)
on the IterableAuthHandler
instance
you provided to the SDK at initialization. The AuthFailure
object provides
more information about the failure.
onAuthFailure(AuthFailure authFailure)
replaces onTokenRegistrationFailed(Throwable object)
,
so if you've implemented that method you'll need to update your application code.
For more information, see the documentation for Iterable's Android SDK.
# 3.5.2
May 13, 2024
With Version 3.5.2 of Iterable's Android SDK, you can:
-
Call
setAuthRetryPolicy
onIterableConfig
, providing aRetryPolicy
to to specify:- The maximum number of consecutive JWT-related request failures the SDK should allow before giving up, Defaults to 10.
- The interval between each retry attempt. Defaults to 6 seconds.
- A backoff strategy: linear or exponential. Defaults to linear.
-
Manually pause JWT refresh attempts by calling:
IterableApi.getInstance().pauseAuthRetries(true);
Pass attribution information to the
trackPurchase
method.
# 3.5.0
Feb 1, 2024
Version 3.5.0 of Iterable's Android SDK includes support for Embedded Messaging — eligibility–based, personalized messages created in Iterable and displayed inline, using native interface components, in your mobile and web apps. The SDK provides customizable, out-of-the-box embedded message views (cards, banners, and notifications), or you can design and implement fully custom embedded message interfaces.
To learn more, read Embedded Messages with Iterable's Android SDK.
# 3.4.15
August 31, 2023
Version 3.4.15 of Iterable's Android SDK supports Iterable's European Data Center.
For more info, see Iterable's Android SDK.
# 3.4.10
October 31, 2022
IMPORTANT
Some users have reported crashes in apps built with version 3.4.10 of Iterable's Android SDK. We're investigating the issue. In the meantime, please test thoroughly. If you see crashes, revert to version 3.4.9.
Version 3.4.10 of Iterable's Android SDK, as a privacy enhancement, includes support for encrypting some data at rest, and an option to store in-app messages in memory.
# Encrypted data
In Android apps with minSdkVersion
23 or higher (Android 6.0)
Iterable's Android SDK now encrypts the following fields when storing them at
rest:
-
email
— The user's email address. -
userId
— The user's ID. -
authToken
— The JWT used to authenticate the user with Iterable's API.
(Note that Iterable's Android SDK does not store the last push payload at rest—before or after this update.)
For more information about this encryption in Android, examine the source code
for Iterable's Android SDK: IterableKeychain
.
# Storing in-app messages in memory
This release also allows you to have your Android apps (regardless of minSdkVersion
)
store in-app messages in memory, rather than in an unencrypted local file.
However, an unencrypted local file is still the default option.
To store in-app messages in memory, set the setUseInMemoryStorageForInApps(true)
SDK configuration option (defaults to false
):
Java
IterableConfig.Builder configBuilder = new IterableConfig.Builder() // ... other configuration options ... .setUseInMemoryStorageForInApps(true); IterableApi.initialize(context, "<YOUR_API_KEY>", config);
Kotlin
val configBuilder = IterableConfig.Builder() // ... other configuration options ... .setUseInMemoryStorageForInApps(true); IterableApi.initialize(context, "<YOUR_API_KEY>", configBuilder.build())
When users upgrade to a version of your Android app that uses this version of the SDK (or higher), and enabled this option, the local file used for in-app message storage (if it already exists) is deleted. However, no data is lost.
# Android upgrade instructions
If your app targets API level 23 or higher, this is a standard SDK upgrade, with no special instructions.
If your app targets an API level less than 23, you'll need to make the following changes to your project (which allow your app to build, even though it won't encrypt data):
- In
AndroidManifest.xml
, add<uses-sdk tools:overrideLibrary="androidx.security" />
- In your app's
app/build.gradle
:- Add
multiDexEnabled true
to thedefault
object, underandroid
. - Add
implementation androidx.multidex:multidex:2.0.1
to thedependencies
.
- Add
# 3.4.7
July 12, 2022
This release makes offline events processing available to all Iterable customers who'd like to use it — just ask your customer success manager to enable it for your account. Offline events processing saves a local copy of events triggered in your app while the device is offline (up to 1000 events). When a connection is re-established and your app is in the foreground, the events will be sent to Iterable. For more information, read Offline events processing.
# 3.4.0
December 23, 2021
Version 3.4.0
of
Iterable's Android SDK includes the following changes:
Prevents in-app messages from executing any JavaScript code included in their HTML templates, and prevents web views from accessing local files.
-
Changes two static methods on the
IterableApi
class,handleAppLink
andgetAndTrackDeepLink
, to instance methods. To call these methods, grab an instance of theIterableApi
class by callingIterableApi.getInstance()
. For example,IterableApi.getInstance().handleAppLink(...)
.WARNING
This is a breaking change. You'll need to update your code.
-
Adds an
allowedProtocols
field to theIterableConfig
class.Use this array to declare the specific URL protocols that the SDK can expect to see on incoming links (and that it should therefore handle). Doing this will prevent the SDK from opening links that use unexpected URL protocols.
For example, to allow the SDK to handle
http
,tel
, andcustom
links, pass these values (in an array) to thesetAllowedProtocols
method onIterableConfig.Builder
:Java
IterableConfig.Builder configBuilder = new IterableConfig.Builder() .setAllowedProtocols(new String[]{"http", "tel", "custom"}); IterableApi.initialize(context, "<YOUR_API_KEY>", config);
Kotlin
val configBuilder = IterableConfig.Builder() .setAllowedProtocols(arrayOf("http","tel","custom")) IterableApi.initialize(context, "<YOUR_API_KEY>", configBuilder.build());
IMPORTANT
Iterable's Android SDK handles
https
,action
,itbl
, anditerable
links, regardless of the contents of this array. However, you must explicitly declare any other types of URL protocols you'd like the SDK to handle (otherwise, the SDK won't open them in the web browser or as deep links).
# Deprecations
This release deprecates and sets an end-of-life date for various older versions of Iterable's Android SDK, as described in the Deprecation dates and support windows section of this document. Also see Iterable's SDK Support Policy.
# 3.3.0
May 27, 2021
Version 3.3.0
of Iterable's Android SDK introduces offline events processing. This feature saves a
local copy of events triggered in your app while the device is offline (up to 1000
events). When a connection is re-established and your app is in the foreground, the
events will be sent to Iterable.
Offline events processing off by default, and we're rolling it out on a customer-by-customer basis. After you start using this version of the SDK, we'll send you a message before we enable the feature on your account (unfortunately, we can't give you an exact timeline for when this will happen). If you have any questions, talk to your Iterable customer success manager.
NOTE
As of July 12, 2022, offline events processing is available to all Iterable customers who would like to use it. To get started, you'll need to:
-
Make sure your mobile app is built with one of the following versions of our SDKs:
Have your customer success manager to enable it for your account (unless you've already been using a beta version of this feature, in which case it will continue to work).
For more information, read Offline events processing
# 3.2.12
March 30, 2021
Version 3.2.12
of
Iterable's Android SDK includes:
- Support for syncing in-app message read state across multiple devices. Note
that:
- When the SDK fetches in-app messages from Iterable, it examines each
message's
read
field to determine if it has already been read. - The SDK's default implementation no longer automatically displays in-app messages that have already been seen on another device (even if those messages were not configured to go directly to the inbox).
- When you view a message, the SDK calls
POST /api/events/trackInAppOpen
to create aninAppOpen
event on the user's Iterable profile. Previous versions of the SDK made this same API call, but the call now also causes Iterable to set the message'sread
field totrue
. - Previous versions of the SDK will correctly sync a message's read / unread indicator for the default implementation of a mobile inbox. However, these older SDK versions will not automatically suppress messages that have already been seen on another device (as this version of the SDK will).
- When the SDK fetches in-app messages from Iterable, it examines each
message's
- Support for the display of a custom message (title and body) in an empty mobile inbox. For more details, see Customizing Mobile Inbox on Android
# 3.3.0 - Beta
January 28, 2021
Version 3.3.0-beta1
of Iterable's Android SDK includes:
- The features and updates introduced in the 3.2.x releases (for example, Mobile Inbox, JWT-enabled API keys, and in-app animations).
- Beta support for offline events processing (capturing engagement events when a device is offline and sending them to Iterable when a network connection is reestablished) and in-app message prioritization (specifying a priority for an in-app message campaign, to determine its display order for your users). To try these beta features, have your Iterable customer success manager enable them for your project.
NOTE
As of July 12, 2022, offline events processing is available to all Iterable customers who would like to use it. To get started, you'll need to:
-
Make sure your mobile app is built with one of the following versions of our SDKs:
Have your customer success manager to enable it for your account (unless you've already been using a beta version of this feature, in which case it will continue to work).
For more information, read Offline events processing
# 3.2.0
February 25, 2020
- This release moves version 3.2.0 of Iterable's Android SDK out of beta.
- It also adds customization options to the Mobile Inbox feature. For more details, see Customizing Mobile Inbox on Android.
IMPORTANT
Versions 3.2.0 and higher of Iterable's Android SDK depend on the AndroidX support libraries. Migrate your app to use AndroidX before using version 3.2.0 or higher.
# 3.2.0 - Beta
October 15, 2019
Version 3.2.0 (beta) of Iterable's Android SDK works with Iterable's Mobile Inbox feature. With Mobile Inbox, users of your mobile apps can save in-app messages and revisit them when it's convenient or when the content is more relevant.
The SDK includes a default implementation of an inbox user interface, which can be customized as necessary to match your brand's styles. Also, it automatically captures inbox-related events to Iterable, where they can be used to segment users, filter and trigger journeys, or send system webhooks.
To get started with Mobile Inbox:
- Read In-App Messages and Mobile Inbox.
- Install the version 3.2.0 beta of Iterable's Android SDK.
# 3.1.0
June 10, 2019
Version 3.1.0 of Iterable's Android SDK is now generally available and supported by Iterable.
This version of the SDK automatically downloads new in-app messages, allows apps more control over which in-app messages to display and when to display them, and consolidates the way deep links are handled across push notifications, in-app messages, and emails. For more information, see the beta announcement.
# How to upgrade
Upgrading to version 3.1.0 of the Iterable Android SDK requires some code changes in your mobile apps. For more details, read Upgrading from a version prior to 3.1.0 instructions on GitHub.
# Deprecations
This release deprecates and sets an end-of-life date for various older versions of Iterable's Android SDK, as described in the Deprecation dates and support windows section of this document. Also see Iterable's SDK Support Policy.
# 3.1.0 - Beta
May 13, 2019
The version 3.1.0 beta of Iterable's Android SDK provides various new features:
-
Automatic downloading of new in-app messages
With this version of the SDK, mobile apps automatically download all available in-app messages and store them on device. This makes it possible to inspect the messages to decide when and how to display them. Automatic in-app message downloads happen:
- When Iterable sends silent push notifications (not visible or audible to the user) indicating that new in-app messages are available.
- At key points in the mobile app's lifecycle, such as when it launches or comes to the foreground.
This feature makes it easier than ever to test in-app message campaigns. Simply send a proof and wait for it to appear in the app (no need to manually force the app to download new messages, as could be the case with previous versions of the SDK).
-
More control for mobile apps to decide when and how to display in-app messages
Since this version of the SDK automatically downloads all available in-app messages and stores them on device, the mobile app can examine each message to decide when and how to display it. For example, the app might:
- Skip displaying a particular message
- Display multiple messages in sequence (by default, in-app messages display in sequence, with a 30-second delay between messages—but this is customizable)
- Wait to display a particular message until a network connection is available
- Create a native user interface for a particular message, rather than rendering the HTML supplied by Iterable
- Display a particular in-app message when a user completes a specific action in the app
-
Consolidated handling of deep link URLs
This version of the SDK provides a common way to handle deep link URLs in a mobile app. With this feature, deep link URLs in emails, in-app messages, and push notifications are all handled in the same way, making it easier for marketers to define a set of deep link URLs that work as expected, regardless of message type.
# How to upgrade
Upgrading to the 3.1.0 beta of the Iterable Android SDK requires some code changes in your mobile apps. For more details, take a look at the Migrating from a version prior to 3.1.0 instructions on GitHub.
# More information
To learn more, take a look at the Iterable Android SDK 3.1.0 beta on GitHub.
# Deprecation dates and support windows
This table lists deprecation dates, support windows, and end-of-life dates for various versions of Iterable's Android SDK.
SDK version(s) | Deprecation announcement date | Support window | End-of-life date |
---|---|---|---|
3.5.x (current) | |||
3.4.x | 2/1/2024 | 12 months | 1/31/2025 |
3.3.x | 12/23/2021 | 12 months | 12/22/2022 |
3.2.x | 12/23/2021 | 12 months | 12/22/2022 |
NOTES
- If a version of Iterable's Android SDK is not listed here, it is no longer supported.
- For more information, see our SDK Support Policy.
# Further reading
- Iterable's SDK Support Policy