Issue when App opens through Push Notification(Cold Start) #873

Activity

1. sherwinski

   assigned

   fadi-george

   on Jun 4, 2026
2. akashchetu23-arch commented on Jun 10, 2026

   

   akashchetu23-arch

   on Jun 10, 2026

   Author

   More actions

   Hi

   Any update on this?
3. fadi-george

   assigned

   nan-li

   on Jun 10, 2026
4. fadi-george commented on Jun 11, 2026

   

   fadi-george

   on Jun 11, 2026

   Collaborator

   More actions

   Hey, I'll see if someone can take a look tomorrow.
5. sherwinski

   assigned

   sherwinski

   and unassigned

   nan-li

   and

   fadi-george

   on Jun 12, 2026
6. sherwinski commented on Jun 12, 2026

   

   sherwinski

   on Jun 12, 2026

   Contributor

   More actions

   Hey there, I'll be looking into this over the next week.
7. sherwinski commented on Jul 7, 2026

   

   sherwinski

   on Jul 7, 2026

   Last edited by sherwinski

   Contributor

   More actions

   Hi @akashchetu23-arch, just wanted to follow up here.

   It looks like there's a bug on the Android side where a click that cold-started the app could be silently dropped if your Clicked handler was subscribed after OneSignal.Initialize(). The Unity bridge attached its native listener before a C# handler existed, so the replayed event did nothing.

   We've opened #881 so that the native click listener is now registered when you subscribe to Clicked. I'll follow up with more details once that's merged and released.
8. sherwinski commented on Jul 7, 2026

   

   sherwinski

   on Jul 7, 2026

   Contributor

   More actions

   I also wanted to address a few things from your original bug report:

   Is there a recommended approach for deep linking without relying on Launch URL?

   Yes — the recommended approach is exactly what you're doing: send Additional Data (no Launch URL needed) and perform navigation inside the Clicked handler. That avoids the iOS browser-opening behavior entirely, and once the fix lands it works reliably for cold starts on Android too.

   ---

   Reading Intent extras is not the supported path in SDK v5. getStringExtra("playback_data") / getStringExtra("custom") was the legacy v3/v4 pattern but in v5 the SDK no longer places the payload on the launch Intent, so those extras will always be null (expected behavior). The supported way to access Additional Data on a notification click is the SDK's click event would be as follows:

   OneSignal.Notifications.Clicked += (sender, e) =>
   {
       var data = e.Notification.AdditionalData; // IDictionary<string, object>
       if (data != null && data.TryGetValue("playback_data", out var playbackData))
       {
           // navigate / deep link using playbackData
       }
   };

   Note: JsonUtility.ToJson(e.Notification) will always show AdditionalData as empty because Unity's JsonUtility can't serialize dictionaries. So we recommend inspecting e.Notification.AdditionalData directly (or serialize it with Json.NET / MiniJSON) when debugging.

   Hope this helps, please let me know if you have any other questions.
9. sherwinski

   closed this as completedin #881on Jul 8, 2026
10. sherwinski commented on Jul 10, 2026

    

    sherwinski

    on Jul 10, 2026

    Contributor

    More actions

    We've released a fix for this in v5.3.0 🚀 Please give it a try and let us know if it helps with the issue you're running into.