Push: Firebase project + google-services.json wiring #45

Activity

1. Adron

   added

   blockedBlocked on something outside this repoBlocked on something outside this repo

   P1Big hole in a shipped featureBig hole in a shipped feature

   area:notificationsNotifications & pushNotifications & push

   on Sep 15, 2026
2. Adron

   added a parent issue on Sep 15, 2026

   • Push notifications: real device push (FCM) to replace the WorkManager poll #44
3. Adron commented on Sep 16, 2026

   

   Adron

   on Sep 16, 2026

   MemberAuthor

   More actions

   Blocked — cannot implement yet. Here is exactly what is needed to unblock.

   Everything downstream of this (#46 token lifecycle, #47 FCM message handling, #48 retiring the poll) is designed and ready; none of it can be built or tested without a Firebase project. Concretely:

   1. Firebase project + google-services.json

   • Create (or point me at) the Firebase project for com.interlinedlist.android.
   • I need the google-services.json for the debug variant placed at app/google-services.json locally. It should stay gitignored; CI will read it from a repository secret.
   • Confirm the applicationId that should be registered — the debug build currently uses a .debug suffix, which needs its own Firebase app entry (or the suffix has to be dropped for FCM to resolve).
   • The release SHA-256 signing fingerprint is also needed if you want FCM to work on Play builds.

   2. CI secret

   Please add a repository secret (suggested name GOOGLE_SERVICES_JSON, base64-encoded contents). The workflow will decode it into app/google-services.json before the build, and fall back to a stub when the secret is absent so forks and PRs from outside the org still build.

   3. Server-side contract — this is the important one

   /help/notifications documents push as iOS-only today. Before writing the registration code I need confirmation of:

   • Does POST /api/push/register accept FCM tokens for Android? The OpenAPI schema does not say which platforms the platform field allows — what is the exact accepted value (android? fcm?) and what is the full request body?
   • Does the server actually send to FCM, or only APNs? If the sender side is not implemented, registering a token is a no-op and this epic is server work first.
   • Is there a Firebase server key / service account configured on the backend for this project? (If the backend uses a different Firebase project than the one you hand me, tokens will register but never receive anything.)
   • What is the payload shape of a push? To route a tap to the right screen the app needs stable data keys — ideally the notification id, its type (matching the existing NotificationCategory mapping), and the target entity id. A notification-only payload with no data block cannot be deep-linked reliably.
   • DELETE /api/push/unregister — does it take the token in the body or as a query parameter?

   4. Decision needed: what happens to the poll

   Should the WorkManager poll be removed once FCM is live, or kept as a low-frequency backstop for devices without Play Services (#48)? My recommendation is to keep it, demoted to a long interval and skipped whenever a valid FCM token is registered — that keeps the app working on de-Googled devices. Confirm and I will build it that way.

   What I can do without this

   Nothing in this epic — #46, #47 and #48 all depend on a device token existing. They stay open until this lands.
4. Adron commented on Sep 16, 2026

   

   Adron

   on Sep 16, 2026

   MemberAuthor

   More actions

   Update — most of section 3 above is now answered, and the blocker is smaller than it looked

   I found the human-written API reference the original parity review missed:
   https://interlinedlist.com/help/api/push-notifications. It answers the server-contract
   questions directly, and I confirmed the endpoint is live and bearer-authenticated by POSTing an
   empty body (it returns {"error":"token is required","code":"bad_request"} — so it is reachable
   from the app today, not cookie-gated).

   What the reference says:

   These endpoints support session cookies for the web app and Bearer tokens for native clients.

   POST /api/push/register
   Authorization: Bearer <token>
   { "token": "<base64-or-hex device token>", "platform": "ios", "environment": "production" }
   

   Field	Required	Notes
   token	yes	provider-issued device token
   platform	yes	ios or android
   environment	no	sandbox or production; inferred from server config when omitted

   Response 200 { "registered": true }. Re-registering an existing token updates rather than
   duplicating. DELETE /api/push/unregister takes { "token": … } in the body and is
   idempotent (unknown token still returns 200). The docs also say to re-register on every app launch
   in case the token rotated, and that a user signed in on several devices gets the push on all of
   them.

   So: platform: "android" is an accepted value, the request body is settled, and the
   unregister shape is settled. Strike questions 3b (body shape) and most of 3a.

   What is still genuinely blocked — now just two things:

   1. The Firebase project + google-services.json + CI secret. Unchanged; everything in
      section 1 and 2 above still stands.
   2. Does the server's sender actually dispatch to FCM? The page describes delivery as "via
      APNs (iOS) or other push providers", which is not a commitment. If the backend only wires
      APNs, an Android token will register happily and never receive anything. Please confirm the
      backend has an FCM credential (and that it belongs to the same Firebase project you hand me —
      a mismatch fails silently in exactly this way).

   Still open from the original comment: the payload shape. To deep-link a tap the app needs
   stable data keys — ideally the notification id, its type (matching the existing
   NotificationCategory mapping), and the target entity id. A notification-only payload with no
   data block cannot be routed reliably. The reference documents registration but not delivery
   payloads.

   Consequence for the epic: #46 (device-token lifecycle) is no longer blocked and I am
   implementing it now — the register/unregister repository, the re-register-on-launch behaviour and
   the platform/environment contract can all be built and tested against the documented shapes,
   with the FCM token itself behind a provider interface that #47 fills in once the Firebase project
   exists. #47 and #48 still wait on this issue.