[abdulraqeeb33]

Description

One Line Summary

FeatureManager keeps APP_STARTUP flags in a small prefs file and latches them once per process, so code that runs before SDK init can read them cheaply and always agrees with isEnabled.

Details

Motivation

Some APP_STARTUP flags have to be decided before the OneSignal store loads. The first one is sdk_dispatcher_bootstrap (#2805): the SDK picks its thread pools on the first dispatcher call, often on main, before initWithContext reads ConfigModel on IO. Reading ConfigModel that early loads the whole OneSignal prefs file (operations queue included) on main, which 5.10.x never did.

A separate copy alone is not enough. 5.9.9 through 5.10.2 already persist every remote key in ConfigModel. If FeatureManager keeps latching APP_STARTUP flags from the store while pre-init code reads the copy, the first launch after an upgrade can run with the flag off while isEnabled and every telemetry event say it is on. That would corrupt the on/off cohort comparison used to judge a rollout.

Depends on KMP #29, which holds the shared latch (StartupFlagsLatch, StartupFlags, FeatureManager.refreshAtStartup) so iOS gets the same behavior. KMP #29 is merged and the submodule is pinned to its main merge commit (35d538a).

Scope

• New OneSignalStartupFlags prefs file holding the enabled APP_STARTUP keys. Android implements only the store (PrefsStartupFlagsStore) and the process-wide holder (StartupFlagsCache).
• The file lives in device-protected storage on API 24+, so receivers and jobs that run before first unlock read real values instead of "unreadable". It must never hold anything secret.
• FeatureManager:
  • latches APP_STARTUP flags from a once-per-process snapshot of that file; IMMEDIATE flags still come from ConfigModel;
  • writes the file from start() (now an IStartableService, off main) and on later remote flag changes, never before start();
  • exposes FeatureManager.startupFlags { context } for code that runs before init.
• Writes use commit(), so a remote turn-off is on disk before the process can die and the next launch picks it up. A failed commit throws and is logged.
• Writes are serialized by the KMP latch and read ConfigModel inside its lock, so start() racing a flags fetch cannot leave an older flag list on disk. An unreadable file is rewritten rather than skipped, and so is one whose last commit() failed, since SharedPreferences keeps the uncommitted value in memory.
• One value per process, even when unreadable: the first read wins, so code that latched "off" never disagrees with code that runs later.
• Missing file, unreadable file, or no context means every startup flag is off. SDK entry points note the application context in com.onesignal.common.AppContext (the startup initializer, and initEssentials before the logger), so a snapshot taken before ApplicationService starts still reads the file. No reflection: if nothing noted a context, the snapshot is off for the process and warns in logcat. The source is logged at debug when FeatureManager is built.
• IMMEDIATE and unknown keys are never written; StartupFlags.isEnabled returns false for IMMEDIATE flags.
• README.md in the features package documents how to add a startup flag and the rules.

Not changed: IMMEDIATE flag behavior, the flags fetch, ConfigModel persistence.

Known cost: on the first launch of the version that ships this, the file does not exist yet, so APP_STARTUP flags (today sdk_custom_logging) are off for that one launch even if the store has them. The next launch picks them up.

Testing

Unit testing

• StartupFlagsCacheTests: file follows remote flags (any case), only APP_STARTUP catalog keys are written, IMMEDIATE flags read false, reads ignore the config store, unreadable file and no context are off, the snapshot is read once per process, FeatureManager reports the snapshot when it disagrees with the store, and the file is written on start() and later updates but never before start().
• Also: a remote turn-off reaches the next process, a failed commit throws, the file is in device-protected storage, a locked boot still reads the flags, racing writes leave the newest flags on disk, an unreadable file is rewritten, a write after a failed commit retries, and FeatureManager built before the app context is set still reads the file.
• FeatureManagerTests: APP_STARTUP flags latch from the snapshot, not the store; IMMEDIATE flags still follow the store.
• OneSignalTestProjectConfig resets the snapshot around every spec.
• Verified red with the fix reverted: snapshot, before-start(), turn-off, locked boot, racing writes, unreadable rewrite, failed-commit retry, and the noted-context path.

Manual testing

Not yet; covered by unit tests. The first consumer (#2805) will be device tested.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details 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.
• I have reviewed this PR myself, ensuring it meets each checklist item

[github-actions]

📊 Diff Coverage Report

Diff Coverage Report (Changed Lines Only)

Gate: aggregate coverage on changed executable lines must be ≥ 80% (JaCoCo line data for lines touched in the diff).

Changed Files Coverage

• AppContext.kt: 9/10 touched executable lines (90.0%) (30 touched lines in diff)
• ActivityLifecycleInitializer.kt: 1/1 touched executable lines (100.0%) (2 touched lines in diff)
• FeatureManager.kt: 25/27 touched executable lines (92.6%) (62 touched lines in diff)
• StartupFlagsCache.kt: 30/31 touched executable lines (96.8%) (101 touched lines in diff)
• OneSignalImp.kt: 1/1 touched executable lines (100.0%) (3 touched lines in diff)

Overall (aggregate gate)

66/70 touched executable lines covered (94.3% — requires ≥ 80%)

📥 View workflow run

[fadi-george]

Lets resolve kmp issues first

[cursor]

Multi-model review (Opus 5.5, GPT 5.6 Sol, Grok 4.7) of the APP_STARTUP latch.

The design matches the goal: a small device-protected file, one snapshot per process, IMMEDIATE flags still from ConfigModel, writes only after start(). A few issues are worth addressing before this is the source of truth for pre-init readers.

Act on

1. The first snapshot is sticky, including NO_STORE / UNREADABLE. FeatureManager init and any pre-init startupFlags call cache the first result for the process. initEssentials can start cached remote logging and emit logs before ApplicationService.start(), so a background telemetry read of enabledFeatureFlags can construct FeatureManager while appContext still throws (mainly when ActivityLifecycleInitializer did not already set it). That latches every APP_STARTUP flag off. Same outcome if a pre-init caller passes { null } or a context whose applicationContext is null (attachBaseContext / some direct-boot paths): storageContext() does applicationContext then createDeviceProtectedStorageContext(), and a throw is latched as UNREADABLE even when the file is readable.
2. A failed read/write can leave the file unrepaired. If mirror skips write when read() throws, or when commit() fails after already updating the in-memory prefs map, mirrorStartupFlags only logs. Later processes keep seeing off/stale flags.

Consider

• FeatureManager.startupFlags is internal to core. README readers in other modules (FCM, sync jobs) cannot call it without a public/friend entry point.
• SharedPreferences is not multi-process-safe; a secondary process can skip or clobber the file.
• onModelReplaced mirrors on every tag and does commit() I/O under the store replace lock.
• The startup file uses commit() while ConfigModel is async; a crash between the two can oscillate flags across launches.

Noted

• KMP pin to 8f5e5d8 is already called out (re-pin after KMP lands).
• Not scoping the file by app ID is fine for the usual single-appId process.
• First-launch-after-upgrade “changed remotely / NEXT_RUN” logs are noisy, not wrong.

  

_{Sent by Cursor Automation: PR Reviews}

[fadi-george]

Rebase to latest main

[fadi-george]

Some findings:

• Non-blocking: FeatureManager.kt:67, when the androidx startup initializer didn't run (provider removed, or non-default process), the remote WARN from logStartupDiagnostics can resolve FeatureManager before ensureApplicationServiceStarted. NO_STORE gets latched, so startup flags stay off for that process, and start() can write an empty list over a good file. Not latching when the context is missing, or starting ApplicationService before the logger, would fix it.
• Non-blocking: StartupFlags.kt:71 / StartupFlagsCache.kt:73, a failed commit() still updates SharedPreferences in memory, so later mirrors see equal keys and skip the write. A remote turn-off can be lost for one launch. Maybe force a write on the next mirror after a failed commit.
• Nit: StartupFlags.kt:23, require() on an IMMEDIATE flag throws during host app startup. Returning false and logging seems safer.
• Nit: README says the snapshot source is kept for logging, but startup.source is never logged. A debug line would help explain flags being off on the first launch or after an unreadable file.
• Nit: StartupFlagsCache.kt write(context, List) is test-only and skips the read-under-lock. Could be @VisibleForTesting internal or removed.

[abdulraqeeb33]

Thanks, all five addressed.

1. Entry points now note the application context (AppContext), including initEssentials before the logger, so the early FeatureManager reads the file. With nothing noted it's off and warns in logcat, no reflection (52dd35b). start() mirrors ConfigModel, not the snapshot, so it never writes an empty list over a good file.
2. After a failed commit the next mirror rewrites, even with the same flags (13522d3).
3. isEnabled returns false for IMMEDIATE flags, from the KMP merge (pinned in c4e0a57).
4. Snapshot source logged at debug when FeatureManager is built (13522d3).
5. write(context, List) removed; tests use the supplier (13522d3).

[nan-li]

Approving after other open questions are closed