Class FcmTransport

The subscription is the registration token the Cordova client obtained from the FirebaseX plugin. Both Android and iOS devices are reached here: with the plugin in FCM mode the iOS token is an FCM registration token and FCM relays through APNs (ruling on the iOS transport, 2026-09-06). An PushTransport.APNS row, a raw APNs token registered by the legacy client branch, is not this transport's.

Message mapping, PUSH-WIRE-CONTRACT section 6.5: notification.title, body and image from the message; data from options.data, every value a string as FCM requires, plus the actions as JSON text and every member that has no native FCM field (navigate, badge, renotify, requireInteraction, lang, dir), so the device can rebuild the object the Service Worker receives; android.ttl and apns-expiration from the TTL; android.priority and apns-priority from the urgency; android.notification.tag and the apns-collapse-id header from options.tag; android.notification.icon from options.icon, as given; android.notification.event_time from options.timestamp as RFC 3339; android.notification.vibrate_timings from options.vibrate as durations, "0.2s", after a leading "0s" because Android's first element is the delay before the vibrator starts where the Notification API's first element is the first vibration; android.notification.notification_priority PRIORITY_MIN from options.silent when true. A member the message does not carry produces no field, and no sound field is written for either platform.

data.iizi (PUSH-WIRE-CONTRACT section 6.2) is rebuilt here as one JSON string: the members the server put in it - the message ID, the application, the Topic, the send time - and, on this leg only, notification, the whole content object without its data. FirebaseX hands the app's JavaScript nothing but data, so the members mapped to native fields above would otherwise never reach it; the Web Push leg carries no such copy, since its Service Worker decrypts the whole object (ruled 2026-09-23, CC-PUSH-P3 RR-11, landed by CC-PUSH-FCM-DATA-IIZI). FCM refuses a payload over MAX_PAYLOAD; payloadSize(PushMessage) measures it so that push refuses up front, and send(SubscriptionRecord, PushMessage, long, DeliveryUrgency) refuses it again before any request, the backstop.

The target seam (CC-PUSH-CORDOVA-FIX C1e, ruling R-4 A of 2026-09-26): buildMessage(String, PushMessage, long, DeliveryUrgency) addresses a FcmTransport.Target, a registration token or an FCM Topic, and can ask FCM to validate the request without delivering it (validate_only, a member of the request beside message). send(SubscriptionRecord, PushMessage, long, DeliveryUrgency) always addresses the subscription's token and never validates only. The Topic and the validation serve the P4-13 measurement of MAX_PAYLOAD against a Topic with no subscribers, no device needed (P4-13 rulings P13-2 and P13-4); no server path sends to an FCM Topic (PUSH-WIRE-CONTRACT section 2.4).

The subscribe check (CC-PUSHDEV-VALIDATE-ONLY, D-2 (c) of CC-FIX-PUSHDEV-PROJECT, ruled 2026-09-28): checkToken(String, String) posts a validate_only body to a registration token with the application's credentials, so that a device whose token names no Firebase project is told apart at subscribe time - FCM answers 200 for a token of the application's project and SENDER_ID_MISMATCH for another project's, and delivers nothing either way. The verdict, a FcmTransport.TokenCheck, is the value a later caller reuses; the definitive ones are kept per application, project and token, since a token's project never changes. A subscribe path whose token another project issued asks again with *'s credentials, checkToken("*",...), and a match records the row under *'s project (B-10b, RR-21 C).

The credentials are chosen by the row (PUSH-CLUSTER-DESIGN 3.3, B-10b, AppPushConfigs.signer(SubscriptionRecord)): a row made under the server's own * project - a device inside iiziRun Developer subscribed for an application (RR-21 C, ruled PC-9) - is posted to *'s project with *'s service account; a row made under a project this server holds for neither is DeliveryOutcome.KEY_MISMATCH, nothing is posted, and the row is kept.

Status mapping: 200 delivered; 404 with UNREGISTERED, or 400 whose error names the registration token, endpoint stale; 429, 500, 503 transient with Retry-After; 401 and 403 the credentials, permanent and the cached token dropped - except a 403 whose error code is SENDER_ID_MISMATCH, the registration token's fault and not the credentials': the token was issued by another Firebase project than the one the row is signed through - since B-10b only a row that records no project, stored before B-10a or by a device that named none and FCM could not check - so the row is refused with a detail that says so and the OAuth token FCM accepted is kept (ruled 2026-09-26, CC-PUSH-ROADMAP row 4); other 4xx permanent.