fix(live-notifications): recover the opt-in set in a cold process

[mahmoud-elmorabea]

Live notifications delivered after ordinary process death were dropped, because the enabled-types gate could not distinguish an app that never opted in from a process that had not loaded the opt-in yet.

Why

Android starts a process solely to deliver an FCM push. No app code runs there — CustomerIOFirebaseMessagingService only calls SDKComponent.setupAndroidComponent(context) — so ModuleMessagingPushFCM is never registered and SDKComponent.pushModuleConfig falls back to MessagingPushModuleConfig.default(), whose type set is empty. The gate in LiveNotificationHandler read that as "not enabled" and returned.

A dropped end was worse than a missed render: the matching start was posted by an earlier live process as an ongoing, non-dismissible notification, so it stayed on screen with no way for the user to clear it.

What

• LiveNotificationStore persists the app-wide opt-in set, replacing on each write and clearing when empty, so disabling a type does not leave a stale opt-in behind. The key is deliberately unprefixed to stay clear of the per-activity reclamation sweeps.
• ModuleMessagingPushFCM.initialize() records the set on every initialization, empty included.
• The gate prefers the live config and falls back to the persisted set.

A populated config always wins, so the opt-in guarantee still holds for apps that never enabled the feature, and a newly disabled type takes effect immediately rather than waiting for the persisted copy to be rewritten.

Custom types additionally need a render callback, which cannot be persisted; that half is tracked separately. Their end is already improved here, since the handler cancels a stranded notification when there is nothing to render.

Verification

• messagingpush unit suite: 279 tests, 0 failures, including 9 new ones covering the cold-process gate both ways, end cancelling a stranded notification, config-wins-over-stale-persisted, replace/clear semantics, and survival of the reclamation sweeps.
• ktlint clean; apiCheck passes with no .api changes (all touched code is internal).

Not device-tested.

---

Note

Medium Risk
Changes push delivery gating and SharedPreferences opt-in state; behavior is well-covered by new tests but affects notification lifecycle after process death.

Overview
Fixes live notifications being dropped when FCM wakes a cold process after the app was killed. In that case pushModuleConfig.liveNotificationTypes is empty, so the handler treated opted-in apps the same as apps that never enabled the feature—including end events, which could leave a non-dismissible ongoing notification stuck on screen.

Persistence: LiveNotificationStore now saves the app-wide enabled activity-type set (replace on write, clear when empty). ModuleMessagingPushFCM.initialize() writes that set on every init, including when empty, so disabling types does not leave a stale opt-in.

Gating: LiveNotificationHandler uses enabledActivityTypes()—live config when non-empty, otherwise the persisted set—so cold FCM delivery can still honor the opt-in while apps that never enabled live notifications stay ignored.

^{Reviewed by Cursor Bugbot for commit c73d8cc. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Sample app builds 📱

Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request.

---

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 68.59%. Comparing base (fd69467) to head (c73d8cc).

Additional details and impacted files

@@                       Coverage Diff                        @@
##             feature/live-notifications     #803      +/-   ##
================================================================
+ Coverage                         68.40%   68.59%   +0.19%     
- Complexity                         1373     1388      +15     
================================================================
  Files                               229      229              
  Lines                              7542     7550       +8     
  Branches                           1127     1132       +5     
================================================================
+ Hits                               5159     5179      +20     
+ Misses                             1985     1976       -9     
+ Partials                            398      395       -3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

• java_layout: live-notifications-cold-start-types (1785319459)

[github-actions]

Build available to test
Version: live-notifications-cold-start-types-SNAPSHOT
Repository: https://central.sonatype.com/repository/maven-snapshots/

[github-actions]

• kotlin_compose: live-notifications-cold-start-types (1785319469)

[github-actions]

📏 SDK Binary Size Comparison Report

Module	Last Recorded Size	Current Size	Change in Size
core	45.65 KB	45.65 KB	✅ No Change
datapipelines	42.68 KB	42.68 KB	✅ No Change
messagingpush	71.44 KB	71.57 KB	⬆️ +0.13KB
messaginginapp	123.88 KB	123.88 KB	✅ No Change
tracking-migration	22.89 KB	22.89 KB	✅ No Change
location	18.93 KB	18.93 KB	✅ No Change
geofence	78.55 KB	78.55 KB	✅ No Change

[Shahroz16]

Looks good to me. I traced this through the killed-process FCM path, and the saved type set is replaced/cleared correctly, with the live config taking over once it exists. That fixes the practical drop for the bundled templates, including cold end delivery.

One known follow-up, not something I think should hold this PR: a wrapper cold process still does not have the runtime callback or branding config, so custom start/update cannot render and bundled templates use fallback styling. A custom end is improved here because it can now clear the stranded notification. This was already outside this minimal fix, so I think we can handle it separately after release.