feat: [SDK-5170] register push before FCM credentials upload

[fadi-george]

Description

One Line Summary

Register Android push subscriptions from the host Firebase configuration before dashboard FCM credentials are uploaded.

Details

Motivation

A newly configured Android app currently receives no push token or Firebase Installation ID until its FCM service account is uploaded to OneSignal and the app launches again. This change derives the sender ID from the host default Firebase app when dashboard parameters do not provide one, allowing the identifier to be uploaded during the first app session.

Scope

• Preserves the dashboard sender ID as the primary source when configured.
• Falls back to the host default Firebase app sender ID when dashboard parameters omit it.
• Supports both legacy FCM token and Firebase Installation ID registration.
• Detects sender-ID mismatches between the host Firebase app and OneSignal configuration.
• Keeps legacy dashboard-provided sender registration available when no default Firebase app exists.
• Makes local demo Firebase configuration optional and ignored by Git.

Review focus

• Whether legacy token registration should reject a host/dashboard sender mismatch even though it uses OneSignal's isolated Firebase app.
• Correct behavior if the effective sender ID changes during the same process after remote parameter hydration.

Testing

Unit testing

Added coverage for sender-ID derivation, registration before a dashboard sender exists, legacy-token and FID paths, missing default Firebase apps, mismatches, reflective registration, and failures.

Ran:

• Focused FCM registration unit tests
• Full testDebugUnitTest
• Spotless
• Detekt
• Release assembly

Manual testing

Built the GMS demo with a local google-services.json and confirmed the generated APK packages google_app_id and gcm_defaultSenderId. Final end-to-end validation of credential upload activating an existing subscription remains pending because the emulator disconnected before the rebuilt APK could be installed.

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

Made with Cursor

[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

• DeviceRegistrationListener.kt: 8/8 touched executable lines (100.0%) (12 touched lines in diff)
• PushTokenManager.kt: 6/7 touched executable lines (85.7%) (8 touched lines in diff)
• PushRegistratorAbstractGoogle.kt: 10/11 touched executable lines (90.9%) (16 touched lines in diff)
• PushRegistratorFCM.kt: 29/29 touched executable lines (100.0%) (53 touched lines in diff)

Overall (aggregate gate)

53/55 touched executable lines covered (96.4% — requires ≥ 80%)

📥 View workflow run

[cursor]

Multi-model review

Models: Claude Opus 5, GPT 5.6 Sol, Cursor Grok 4.6.

Act on

• Legacy .token registration now throws on a host vs dashboard sender mismatch, even though the token is minted on the isolated ONESIGNAL_SDK_FCM_APP_NAME app (3/3). That is a regression for mixed-project apps, and it also blocks the host-fallback → dashboard-sender upgrade after credentials are uploaded. Keep validateSenderId on the FID path only.

Consider

• initFirebaseApp caches by nullness, not sender (3/3). Once the mismatch throw is removed, an in-process sender change (start/host-fallback then HYDRATE, or appId switch) can keep serving the old project's token. Recreate the named app when sender/FCM params change.
• Empty/"null" android_sender_id skips the host fallback (Opus); safeString only yields null when the key is absent.
• Host-fallback still pairs the host sender with OneSignal shared FCM credentials on the named app (Grok). The FID path is consistent; the legacy first-session token may not be the identifier that later receives traffic.
• Residual from the FID work: English substring detect of Firebase's "API disabled…register()" message, and no onRegistered/FID-rotation bridge (Opus/GPT).

Noted / dismissed

• Consumer ProGuard register() keep, defaultSenderId derivation, and the Gradle require range look correct.
• snd= census vs FirebaseOptions sender, and the "FID registration is enabled (…=not set)" error copy, are nits.

  

_{Sent by Cursor Automation: PR Reviews}

[abdulraqeeb33]

Answer to the review focus: do not reject a host vs dashboard sender mismatch on the legacy path. That path still mints from ONESIGNAL_SDK_FCM_APP_NAME. Mixed-project apps are supposed to keep working there. 2734 left that alone.

1. Drop validateSenderId from getLegacyToken. Keep it on the FID path only. Invert the mixed-project legacy test.
2. Same change: rebuild the named app when senderId changes. Host fallback plus HYDRATE can change sender in-process. Cache-by-nullness then uploads the old sender's token.

[abdulraqeeb33]

a few nits but otherwise looking good

[abdulraqeeb33]

Quick question on the path after the first session.

No android_sender_id on setup is expected, host fallback is what we want there. Once the service account is uploaded and params come back with a sender that does not match the host, validateSenderId throws and we surface that as MISC_EXCEPTION. That status is retryable, so the host FID stays SUBSCRIBED.

Should that mismatch be INVALID_FCM_SENDER_ID instead, so we do not keep the host identifier as healthy?

[fadi-george]

Agreed. An FID sender mismatch now maps to INVALID_FCM_SENDER_ID. Permanent configuration errors can also replace a previously successful in-memory token status, so the host FID is not kept healthy. The legacy mixed-project path remains unchanged.

[abdulraqeeb33]

Thank you for addressing the comments @fadi-george . Looks good.