Fix outside package target activities (Launch URL) not opening when notification is tapped on

[jkasten2]

Description

One Line Summary

Fix notification open with Launch URL not showing any Activities, this was a regression bug introduced in PR #1377.

Details

Motivation

Notification Launch URL is an active supported feature used by OneSignal customers so ensuring it works correctly is high priority.

Scope

The main goal is to fix Launch URL not working but the code change in this PR effects all notification opens. The "opens" noted here is scoped to how Activities are shown to the user. This includes the Activity flags used to start Activities and the backstace it generates.
No changes to how OneSignal consumes or generates Intent data.

Why the bug was happening?

The issue was due to an Activity backstack not being built correctly. Both NotificationOpenedReceiver and the target Activity were launched with FLAG_ACTIVITY_NEW_TASK however this means when NotificationOpenedReceiver is finished it does not bring up the target since it is on a different task. The Android flag allowTaskReparenting allows this to happen, however this can effect the backstack of the main task which we don't want to do.

How the bug was fixed?

Setting android:taskAffinity sets FLAG_ACTIVITY_NEW_TASK and allowTaskReparenting for us. By setting the value to "" (empty string) it prevents any side effects on existing tasks as it means it has no affinity to associate it with. This allowed us to clean up some runtime logic to add FLAG_ACTIVITY_NEW_TASK and others we no longer need now.

A caveat is that on Android 5.1 and older android:taskAffinity="" doesn't give us the allowTaskReparenting behavior, nor does setting it explicitly work. To account for this an Activity named NotificationOpenedReceiverAndroid22AndOlder was created without the android:taskAffinity parameter.

Related additional information

Tasks and the back stack

Basic understand of this topic is recommend

• https://developer.android.com/guide/components/activities/tasks-and-back-stack

What android:taskAffinity="" does

By default, all activities in an application have the same affinity. You can set this attribute to group them differently, and even place activities defined in different applications within the same task. To specify that the activity does not have an affinity for any task, set it to an empty string.

Source: https://developer.android.com/guide/topics/manifest/activity-element#aff

Notification Trampolines

Background on what "Notification Trampolines" are and how a "Reverse Activity Trampoline" works.

• https://onesignal.com/blog/android-12-notification-open-changes/
• Reverse Activity Trampolining Implementation PR #1377

Testing

Unit testing

Added test to ensure correct Activity is used for newer vs older versions of Android.
No existing exist unit tests to ensure correct Activity is infocus or the backstack is built correctly. Robolectric doesn't have fakes / mocking to simulate to this level.

Manual testing

Each scenario was tested with the following devices:

• ⚠️Can't test older Android versions, due to know TLS1.2 issue
• ✅Android 5.0 Emulator
• ✅Android 5.1 Emulator
• ✅Android 6.0 Emulator
• ✅Android 7.1 Emulator
• ✅Android 8.1 Emulator
• ✅Android 9 LG G7
• ✅Android 9 Amazon Fire 7 (KFMUWI)
• ✅Android 10 Emulator
• ✅Android 11 Emulator
• ✅Android 12 Emulator

Default notification

• App Foreground
• App Background - by pressing back button
• App Background - by pressing home button
• App not running - Task still in recent list, resumes app's task correctly
• App not running - Recent list cleared, app cold starts new task

HTTPS URL notification

• App Foreground
• App Background - by pressing home button
• App not running - Recent list cleared, app cold starts new task

com.onesignal.NotificationOpened.DEFAULT set to DISABLE

• App Foreground
• App Background - by pressing home button
• App not running - swiped away app

Data URL scheme - appname://test

Tested by adding the following <intent-filter> entries for the following Activities in the example app's AndroidManifest.xml.

<activity
    android:name=".activity.SplashActivity"
    android:exported="true">
  <intent-filter>
      <action android:name="android.intent.action.MAIN" />
      <category android:name="android.intent.category.LAUNCHER" />
  </intent-filter>
  <intent-filter>
      <action android:name="android.intent.action.VIEW"/>
      <category android:name="android.intent.category.DEFAULT"/>
      <category android:name="android.intent.category.BROWSABLE"/>
      <data android:scheme="osexamplesplash"/>
  </intent-filter>
</activity>

<activity
    android:name=".activity.MainActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.VIEW"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <category android:name="android.intent.category.BROWSABLE"/>
        <data android:scheme="osexample"/>
    </intent-filter>
</activity>

Each scenario below includes testing twice, once with osexamplesplash:// another with osexample://.

• App Foreground
• App Background - by pressing home button
• App Background - App swiped away
• App not running - Recent list cleared, app cold starts new task

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REPLACE sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Public API changes are intended and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is 

[emawby]

Reviewed 5 of 5 files at r1.
Reviewable status: all files reviewed (commit messages unreviewed), 1 unresolved discussion (waiting on @Jeasmine, @jkasten2, and @nan-li)

---

OneSignalSDK/onesignal/src/main/java/com/onesignal/GenerateNotificationOpenIntent.kt, line 11 at r1 (raw file):

    private val context: Context,
    private val intent: Intent?,
    private val startApp: Boolean

Are we using this boolean anymore?

[Jeasmine]

will it make sense to have a single Base NotificationOpenedReceiver and both NotificationOpenedReceiver and NotificationOpenedReceiverAndroid22AndOlder implement it?

[jkasten2]

Reviewable status: all files reviewed (commit messages unreviewed), 2 unresolved discussions (waiting on @emawby, @Jeasmine, and @nan-li)

---

OneSignalSDK/onesignal/src/main/java/com/onesignal/GenerateNotificationOpenIntent.kt, line 11 at r1 (raw file):

Previously, emawby (Elliot Mawby) wrote…

Are we using this boolean anymore?

Yes, the only place it gets used now is at the top of getIntentAppOpen.

---

OneSignalSDK/onesignal/src/main/java/com/onesignal/NotificationOpenedReceiverAndroid22AndOlder.kt, line 43 at r1 (raw file):

Previously, Jeasmine (JNahui) wrote…

will it make sense to have a single Base NotificationOpenedReceiver and both NotificationOpenedReceiver and NotificationOpenedReceiverAndroid22AndOlder implement it?

ah yes, I'll do that. It will de-dup a few lines of code and prevent missing the other class when updating any of the logic in it.

[jkasten2]

Reviewable status: 3 of 6 files reviewed, 2 unresolved discussions (waiting on @emawby, @Jeasmine, and @nan-li)

---

OneSignalSDK/onesignal/src/main/java/com/onesignal/NotificationOpenedReceiverAndroid22AndOlder.kt, line 43 at r1 (raw file):

Previously, jkasten2 (Josh Kasten) wrote…

ah yes, I'll do that. It will de-dup a few lines of code and prevent missing the other class when updating any of the logic in it.

I addressed this in commit 17f6340