Skip to content

Push Notifications Android

Jump to bottom
rodvar edited this page Apr 29, 2026 · 1 revision

Push Notifications on Bisq Connect for Android

Bisq Connect for Android offers two delivery paths for trade and chat notifications. They are mutually exclusive — exactly one runs at a time, controlled by a single toggle in Settings → Notifications → Relayed push notifications.

This page explains how each path works, what each one trades off, and why we ship the decentralised mode as the default.

TL;DR

Default (decentralised) Relayed (FCM)
Toggle state OFF ON
Delivers when app is closed / killed No (only while the app's foreground service is alive) Yes
Third party in delivery path None Google's Firebase Cloud Messaging
Battery cost Higher (foreground service stays alive) Lower (process can be killed)
Privacy posture Strongest — Google is never contacted Encrypted payload via Google; metadata visible to Google
Network calls to Google Zero Token registration + each push delivery
Works on de-Googled devices Yes No (needs Google Play Services)
Trusted node round-trip required to deliver No Yes (relay → FCM → device)

When does each mode make sense?

If you only want the short answer, the rules of thumb below should be enough. The rest of the document covers the mechanics in detail for readers who want to know more before deciding.

Stay on the default (decentralised) if any of these apply:

  • You actively use the app multiple times a day, so an open foreground service is acceptable.
  • You run a de-Googled or privacy-focused ROM.
  • You're philosophically opposed to introducing Google as a delivery party, even with encrypted payloads.
  • You're testing or developing against a local trusted node and don't want to register FCM tokens.

Opt in to relayed if any of these apply:

  • You only check Bisq occasionally and want notifications to arrive reliably even after force-stop or reboot.
  • The persistent foreground notification or battery cost is unacceptable.
  • You're on a Pixel / mainstream Android device where Google Play Services is already running for other apps anyway.
  • You've experienced the OS killing the foreground service in the background and want a delivery channel that doesn't depend on Bisq's process being alive.

You can switch between modes at any time. Switching off relayed mode revokes the FCM token, disables Firebase auto-init, restarts the local foreground service, and tells the trusted node to forget your device registration.

Default mode — local foreground service

This is what every Bisq Connect install does the moment you finish onboarding, until you explicitly opt in to the relayed path.

How it works

  1. The app holds a foreground service alive in the background. Its sole purpose is to keep the WebSocket to your trusted node alive and to keep the app's process from being killed by Android's resource manager.
  2. While that service is running, the app subscribes to trade-state and chat-message events from your trusted node over the existing WebSocket.
  3. When an event of interest fires (offer taken, fiat sent, chat message, etc.), the app posts a system notification.

The trusted node and your device are the only parties involved. No Google, no Apple, no Bisq-controlled relay server.

Trade-offs

Pro Con
No third party can observe that you receive notifications. The foreground service requires battery-optimisation exemption to survive long sessions on aggressive OEMs (Samsung, Xiaomi, OPPO).
Works on any Android device, including de-Googled ROMs (/e/OS, LineageOS without GApps). If Android kills the app process (low memory, force-stop, reboot before unlock), notifications stop until you open the app again.
Latency is roughly the round-trip to your trusted node. After a device reboot, you do not receive notifications until you launch the app at least once.
No FCM token to register. Nothing on Google's servers identifies you as a Bisq user. The persistent foreground notification ("Bisq is running") is visible whenever the service is up. Some users find this distracting.

Why this is the default

The Bisq philosophy prefers tools that don't introduce new trust relationships. The default keeps the trust model identical to the rest of the app: you trust your trusted node, and that's the only entity in the loop.

Users for whom the trade-offs are unacceptable (battery, post-reboot delivery, persistent notification) can opt in to the relayed path on a per-install basis.

Relayed mode — FCM (Firebase Cloud Messaging)

Opt-in only. Off until the user explicitly enables it in Settings.

How it works

  1. First-time opt-in. When the user toggles the setting on, the app shows an explainer dialog summarising the trade-off, then triggers the system POST_NOTIFICATIONS permission prompt (Android 13+).
  2. Token fetch. The app turns Firebase Cloud Messaging auto-init ON (it is OFF by default — see manifest opt-out flags below) and asks Google for a per-install FCM token.
  3. Symmetric key generation. The app generates a fresh AES-256 symmetric key, stores it in EncryptedSharedPreferences (master key in AndroidKeyStore), and registers (deviceId, deviceToken, symmetricKey, platform=ANDROID) with the trusted node.
  4. Local foreground service stops. An internal orchestrator stops the local foreground service so that exactly one delivery path runs at a time.
  5. Delivery.
    • The trusted node serialises a notification to JSON.
    • The trusted node encrypts the JSON with the device's symmetric key (AES-256-GCM, wire format nonce(12) || ciphertext || tag(16), Base64-encoded).
    • The trusted node posts the encrypted payload to a Bisq-operated relay server.
    • The relay forwards the payload to Google's FCM endpoint as a data-only message. This is required so the device's messaging service is invoked even when the app is killed.
    • The device receives the FCM data, decrypts with the locally stored symmetric key, and posts a privacy-friendly category-based notification ("Trade update" / "New message" / "Offer update").
    • Tapping the notification opens the app and routes to the relevant screen.

What Google sees

  • That an FCM token belonging to your device is registered with the Bisq Firebase project.
  • That an encrypted payload of size N was delivered to your token at time T.
  • Your device IP address at delivery time.

What Google cannot see

  • The notification content (encrypted with a key only the trusted node and your device hold).
  • Trade details, counterparty identity, payment info, amounts.
  • Anything about your reputation, profile, or in-app activity.

What the Bisq-operated relay sees

  • The encrypted payload it forwards (cannot decrypt — never holds a symmetric key).
  • Your FCM token (necessary to address the message).
  • Delivery timestamps and counts.

The relay is operated by Bisq maintainers. Source code: https://github.com/bisq-network/bisq-relay.

Trade-offs

Pro Con
Notifications arrive even when the app is force-stopped, the device just rebooted, or the foreground service was killed. Google is in the delivery path. Even though payload contents are encrypted, Google sees per-token delivery metadata.
No persistent foreground notification — battery cost is materially lower. Requires Google Play Services. Will not work on de-Googled ROMs unless sandboxed Play Services is installed (e.g., GrapheneOS with GMS sandbox).
Latency mostly bounded by Google's push-delivery SLO (typically seconds, often sub-second for high priority). Adds a Bisq-operated relay server to the trust path. The relay cannot read message content but it does forward your encrypted payloads and metadata.
Survives device sleep / Doze without the user having to whitelist the app from battery optimisation. The user must trust both Google (for delivery) and Bisq (for relay operation), in addition to their trusted node.

Privacy hardening (regardless of mode)

These apply on every install, including users who never opt in:

  • Firebase auto-init is OFF by default. The FCM library is bundled in the APK but inert until the user opts in. The app flips auto-init on at registration and back off on unregister.
  • Firebase Analytics, Ad ID collection, Analytics Storage, Ad Storage, Crashlytics, and Performance monitoring are all disabled at the manifest level.
  • No notification token or token prefix is ever logged. Even a 10-character prefix is a stable per-install identifier; we treat the whole token as sensitive.
  • Lock-screen notifications never reveal trade details. They display only a category banner ("Trade update", "New message", "Offer update", or generic "New notification"). The user must open the app to see specifics. Mirrors the iOS NSE privacy posture.
  • Symmetric keys rotate on every registration. Each registration cycle generates a fresh AES-256 key, bounding the exposure window of any single key.

Frequently asked

Do I need a Google account on the device to use the default mode? No. The default mode does not contact Google at all. The bundled FCM library is inert until you opt in.

If I opt in and later opt out, does Google still have my token? The token is revoked on opt-out. Auto-init is also disabled, so the FCM library stops talking to Google's servers. Google's records of past delivery metadata are subject to their retention policy, not Bisq's.

Will the relay see who I trade with? No. The relay only ever sees the encrypted payload and your FCM token. Trade details, counterparty identity, and amounts are encrypted end-to-end between your trusted node and your device.

Can I run my own relay? The relay is open source. The trusted node currently points at the Bisq-operated relay; running your own would require a code change in the trusted node to point at a different relay endpoint. There is no per-user relay selection at the moment.

Why doesn't this apply to the Bisq Easy Node app? The Node app embeds a full Bisq2 process and communicates over the P2P network directly. It does not use a trusted node and does not use the relay. Notifications are posted entirely on-device.

Clone this wiki locally