Responding to Android 12 Push Notification Changes

We shared our thoughts and perspectives on Mobile Push in Android 12 earlier this year when the Beta was released and initial features were announced. With the release of Android 12 this week, we wanted to revisit these notification changes and share how we've adapted our Android SDK to optimize performance and compliance.

Notification Trampolines

One significant notification change associated with Android 12 is that notification trampolines have been disallowed.

What is a notification trampoline?

Some apps use a "notification trampoline" technique to call a background Service or Broadcast when a notification is tapped before launching an app Activity. This intermediary thread often takes additional time to compute before the intended app Activity is displayed to the user.

How does a notification trampoline affect UX?

A notification trampoline introduces a delay that can range from well under a second to many seconds or more if the background work is intensive or requires a network call to finish. For your users, this additional computing time translates to an unresponsive notification, which can negatively impact their app experience and hurt brand perception. To complicate this experience further, notifications disappear immediately after they're opened, so the user will not be given another opportunity to launch the app. Providing prompt user feedback is therefore important to capture audience engagement in addition to creating a positive UX.

How to Migrate Away From a Notification Trampoline

The OneSignal-Android-SDK 4.5.0 has been optimized to show the user visual feedback even faster. For apps using the default OneSignal notification setup, no additional changes are required after updating the SDK. If you have disabled OneSignal’s default notification open behavior, please see the section below to ensure your custom handling meets the requirements.

Android 12 Requirements for Notifications

According to the Android 12 notification trampoline restrictions, two types of notification responses are available to apps:

1. Directly start an Activity.

2. Perform background work via Broadcast or Server, but do NOT show an Activity.

Option one is the most straightforward and popular solution. The Activity you choose could be a specific one that you select when the notification is generated, or the Action might simply be starting your main launcher Activity, or resuming the app where it can handle the content of the notification.

If you choose option two, some notifications (such as ones that have buttons like "delete" or "archive") could perform the work in the background without bringing the app to the foreground. Even if you don’t launch your app, it’s recommended to show a toast (a small message box) to the user to indicate that their interaction has been recognized.

See Android’s Notification trampoline restrictions documentation for even more information.

How OneSignal Implemented These Changes

This is a technical deep-dive into how OneSignal handled Android 12’s Notification trampoline requirement describing the research, considerations, and implementation process.

Identifying the Change

The Action that is triggered when a notification is tapped is set by calling Notification.Builder.setContentIntent. This takes a PendingIntent which can be an Intent to start an Activity, Broadcast, or Service. We previously used a Broadcast so that the OneSignal SDK could track if notifications were opened and conditionally start an Activity.

Goals and Requirements

At OneSignal, one of our primary goals is to ensure that our SDK is easy to set up with as few manual steps as possible. With that goal in mind, it was important for us to find a solution to support Android 12 that didn’t require additional setup.

Because OneSignal must open an app when a notification is tapped and showing an Activity from a Broadcast or Service was disallowed, these options were off the table. That meant we needed to use an Activity. However, the activity needed to be able to handle two things: (1) tracking whether or not the notification was opened and (2.) displaying the Activity intended by the app developer.

Implementation Options

We investigated multiple approaches to implementing this change. Possible options included:

• Use an Android API to attach multiple Intents to the notification to start both a background job (to track the open event) and show the intended Activity to the user at the same time.

This would be ideal, but unfortunately, Android’s native Notification API does not provide this.

• Use a PendingIntent with a OneSignal SDK Activity that isn’t visible, and use that Activity to load app settings and conditionally start a follow-up Activity when the notification is opened.

This is technically allowed by Android 12, but trampolines in the same way with an invisible Activity rather than a Broadcast.

• Use Application.ActivityLifecycleCallbacks and set the intended Activity on the notification, but with an Intent data required by the OneSignal SDK to track opens.

This solution doesn’t work for Intents set to open another app or web browser.

• Any data on the Intent could be filtered out by the app.

This approach requires extra processing each time an app’s Activity is started to check its Intent for notification open events.

• Use PendingIntent.getActivities.

This allows the intended Activity to be shown directly to the user, while also starting an invisible Activity in the OneSignal SDK to automatically track the open event.

This last option is the "Reverse Activity Trampoline" approach we chose for the OneSignal-Android-SDK 4.5.0 and developed in tandem with Google.

Reverse Activity Trampoline

This approach involves starting two Activities, but relies on the Android back stack to get the user to the intended Activity rather than relying on code in the app to handle Activity redirection.

This transitions the user from opening the notification to the intended Activity faster by frontloading payload parsing and reading user settings, and by offloading Activity transition logic to the Android OS.

Staying on the Cutting Edge

We're always looking for ways to make our SDKs more efficient and capable.  As new versions of mobile operating systems and browsers develop, we routinely consider how these evolving platforms will impact messaging and notifications.

If you have other questions about OneSignal and the release of Android 12, reach out to us at support@onesignal.com.

If you’re interested in joining our team, click the button below to check out our current job openings.