8

Android 12 has forbidden the so called notification trampolines: https://developer.android.com/about/versions/12/behavior-changes-12#notification-trampolines

Currently I'm tracking notification click events trough analytics tools but making use of a "trampoline", a broadcast receiver which send the event before the actual notification Intent to open a specific Activity.

Reading here and there I see that an alternative to that approach, which would avoid trampolines as well, consists in populating the Intent extras with the information required to send the analytics event. But here I see 2 issues:

  1. This logic shall be replicated on all the involved Activities, so it's quite hard to make it solid to avoid mistakes/bugs
  2. It's not possible, AFAIK, to cleanup the Intent extras on Activity re-creation, meaning that, even if you remove the intent extras required to send the event, if the same activity is re-created (i.e. using the "don't keep activities" dev option), the original Intent extras are used, resulting in multiple events for a single real notification click.

Here is the function I use to consume the intent extra:

fun consumeClickEventIfAny(intent: Intent) {
    intent.extras?.let { extras ->
        if (extras.containsKey(EXTRA_ANALYTICS_FOR_CLICK)) {
            ... trigger analytics event here
            extras.remove(EXTRA_ANALYTICS_FOR_CLICK)
            intent.replaceExtras(extras)
        }
    }
}

Did you faced the same or similar issue? How did you solved it? Any help would be very appreciated. Thank you!

Carlo Codega
  • 93
  • 4
  • I'm dealing with a similar issue where I cannot use notification trampolins anymore to deal with notification clicks, but haven't found a solution yet. – fobisthename Aug 20 '21 at 09:21
  • 4
    Currently I'm handling the click analytics logic inside the target Activity. Btw I'm still a little bit confused with this new limit, because we could actually do the same trampoline logic using a phantom Activity, that would behave like the BroadcastReceiver. But I'm trying to avoid this. – Carlo Codega Aug 20 '21 at 13:18
  • @CarloCodega Any update on this? I am running into a similar issue and I imagine others will be very soon as well. Cheers! – Bink Oct 25 '21 at 21:11
  • @Bink nope! Still handling analytics inside each target Activity.... nothing good! – Carlo Codega Oct 27 '21 at 07:28
  • Don't know if it is the case, the restriction mentioned : 1. create a pendingIntent to launch a service or broadcastReceiver 2. put the pendingIntent to the notificaiton by setContentIntent() 3. Inside service- onsStartCommand or Insdie receiver-onReceive, startActivity 4. Finally, I tap the notificaiotn and fire the pendingIntent, everything works fine on android12....... This confuse me a lot... – BobTheCat Dec 16 '21 at 07:23
  • @BobTheCat is your app targeting sdk 31? The change supposed to happen only for the apps targeting android 12 – art-o-nawa Feb 15 '22 at 07:24
  • @art-o-nawa thanks for the reply. Yes, the change happens only for the apps targeting > android 12. And my scenario for the last comment works based on targetSdk = api 31(android 12) and my device is android 10. If I switch the device to an android 12 phone, the change happens. So, does targeting android 12 means both app'stargetSdk and the phone IO is android 12? – BobTheCat Feb 16 '22 at 02:27
  • @BobTheCat so the scenario works as expected. Targeting an sdk version means setting it as your targetSdk for the app, it doesn’t require the app to run on that OS version. But based on your target sdk each OS version will put certain amount of restrictions on your app. Trampoline restriction has appeared in android 12 and is only affecting apps that target android 12. – art-o-nawa Feb 16 '22 at 06:10
  • @art-o-nawa So simply put, for trampoline restriction, it only effects when both phone OS and app target sdk >=31 – BobTheCat Feb 16 '22 at 06:30
  • 1
    @BobTheCat yes, that’s right – art-o-nawa Feb 16 '22 at 07:13

0 Answers0