FCM tokens invalidated within 2-5 hours on budget Android devices (no user action)

[joshuachestang]

Environment

• Devices: Samsung Galaxy A15 5G, Galaxy A16 5G, Moto G Power 2025, Moto G Stylus 2025
• Android version: 16
• firebase-messaging: 24.x
• App type: VoIP (call screening) — uses high-priority data-only FCM messages with Notification.CallStyle (API 31+)

Problem

FCM tokens become messaging/registration-token-not-registered within 2–5 hours of registration on budget Android devices. This happens without any documented rotation trigger (no uninstall, no clear data, no 270-day inactivity).

One token died without ever receiving a single push message, ruling out any send-side cause.

• Budget devices (Galaxy A-series, Moto G) are affected at ~40% rate
• Flagships (S24 Ultra) appear unaffected
• onNewToken does not fire after invalidation when the app process has been killed by OEM battery management

Reproduction timeline (Apr 18, 2026)

Time (UTC)	Event
16:43	User signs up on Galaxy A15 5G, FCM token registered
16:43	Token validated via dry-run messaging.send() — alive
20:34	Periodic dry-run validation — still alive
21:06	Dry-run returns registration-token-not-registered — dead

• Token survived 4.3 hours
• Zero push messages were sent to this token during its lifetime
• User did not open the app again after signup
• App was not uninstalled (device lock still active, call forwarding still verified)

Second example (same day)

Time (UTC)	Event
16:02	User signs up on Moto G Power 2025, token registered
17:05	VoIP push sent successfully
18:20	Dry-run validation — alive
18:27	Token returns registration-token-not-registered — dead

• Token survived 2.4 hours
• One successful push was sent at 17:05

What we've verified

• Single FirebaseMessagingService — no duplicate registrations
• No custom getToken() polling (removed WorkManager-based refresh, foreground health checks)
• onNewToken persists via an unauthenticated HTTP endpoint (no auth token needed) — works correctly when onNewToken actually fires
• Notification.CallStyle.forIncomingCall() per Android telecom notification guidance
• No deleteToken() calls anywhere in the codebase

Related issues

• FCM token is invalid in short time, even a few seconds #5569 (locked) — "FCM token is invalid in short time, even a few seconds"
• onNewToken() returns the wrong token #5863 (closed) — "onNewToken() returns the wrong token"
• firebase get token authentication failed for new users #6058 (closed) — "firebase get token authentication failed for new users"
• Push notification token invalidated after a few minutes #469 — "onNewToken not called reliably"

Questions for the Firebase team

1. What triggers token invalidation besides uninstall/clear-data/270-day-inactivity? The documented triggers do not explain tokens dying in under 5 hours.
2. Is there a known interaction between OEM battery management (Samsung Adaptive Battery, Motorola Moto Protect) and FCM token lifecycle?
3. Is there any server-side mechanism to be notified of token rotation, rather than relying on the onNewToken client callback?

Workaround

We've implemented a persistent WebSocket as the primary delivery channel (same pattern as Signal/WhatsApp/Telegram), with FCM as a parallel fallback. This sidesteps the token lifecycle entirely but shouldn't be necessary for a standard FCM integration.

[joshuachestang]

Additional context — confirmed no competing token managers:

We've verified there are no other libraries or services interfering with FCM token lifecycle:

• expo-notifications is excluded on Android via autolinking (react-native.config.js: platforms: { android: null }) and its ExpoFirebaseMessagingService is removed from the merged manifest via tools:node="remove". We previously discovered that Expo's PushTokenModule.kt was calling deleteToken() internally, which caused 43% token loss — but that was a separate issue we fixed in an earlier release. The current token deaths happen with Expo's native code fully excluded.
• No @react-native-firebase/messaging — we use firebase/messaging (Web SDK) on the JS side and a single native FirebaseMessagingService (GiniFCMHandler.kt) on the Kotlin side.
• No deleteToken() calls anywhere in the codebase.
• No getToken() polling — removed all WorkManager-based periodic refresh and foreground health checks. getToken() is called exactly once on cold start per Firebase's recommendation.
• Single FirebaseMessagingService — verified via manifest merge. No competing service registrations.

The token deaths in our current build (1.2.30) occur with a completely standard FCM setup — one service, one onNewToken handler, one cold-start getToken(), zero deleteToken() calls. The only non-standard aspect is that we send high-priority data-only messages with Notification.CallStyle for incoming VoIP calls.

Also worth noting: This is a VoIP call screening application. Incoming call delivery is time-critical — if the FCM token dies, the user misses real phone calls being forwarded to our service. We're seeing users set up call forwarding, leave the app, and then become unreachable within hours because the token silently invalidates. The onNewToken callback never fires because budget phone OEMs kill the app process.