Android App and Device Notifications
How Android app mode, the feed push prompt, and device-level notification subscriptions work for signed-in users.
Android App and Device Notifications
Where you see this in the app
Device notifications appear in the signed-in app experience on supported browsers and Android app-mode sessions.
The main surfaces are:
| Surface | What it does |
|---|---|
/android | Sets Android app mode and continues into the normal hosted app |
/feed | Shows the shared signed-in push prompt when the device is eligible |
Settings -> Notifications | Lets you retry, inspect, enable, or disable the current device subscription |
The Android app is intentionally a thin hosted-app shell. It uses the same main web experience instead of a separate mobile-only product.
Android entry and app mode
Opening /android sets the app-mode cookie and redirects into the normal app. After that, GetPaidX can label the current device as an Android app session in notification UI.
From a user standpoint, this means:
- the same account, feed, profile, posts, and workspaces remain available,
- the route is not a separate landing page,
- notification prompts and device state can distinguish Android app mode from a normal browser tab.
Feed push prompt
Signed-in users may see a tap-first notification prompt on /feed.
The prompt asks before calling the browser or Android permission dialog. This matters because device notification permission is controlled by the browser or operating system, not only by GetPaidX account settings.
If the prompt is dismissed, the app waits before showing it again. Users can still use Settings -> Notifications as the manual retry surface.
Settings notification controls
Settings -> Notifications combines account email preferences with current-device push controls.
The push card is the right place to check:
| Item | Meaning |
|---|---|
| Device support | Whether the current browser/app session can use Web Push |
| Permission state | Whether the browser or OS allows notifications |
| Current subscription | Whether this device is linked to the signed-in account |
| Disable action | Removes this device subscription from the account |
If notifications are blocked at the browser or operating-system level, changing GetPaidX settings alone may not be enough. The user may need to allow notifications in the device settings first.
Device ownership and retries
Push subscriptions belong to a signed-in user and a specific browser/device subscription. A different browser profile, phone, installed app, or cleared browser state can appear as a different subscription.
If notifications stop working, check:
- the user is signed in,
- the browser or app still has notification permission,
- the current device shows as subscribed in settings,
- the device has not been disabled or replaced by a new browser profile.
The app can backfill or reconcile recent subscription ownership, but the user-facing expectation should stay simple: enable notifications on each device where you want them.
What notifications can deliver
Device notifications extend the existing in-app notification stream to the phone or browser lockscreen when the environment supports it.
They are separate from email preferences. Pausing non-payment email does not automatically disable a device push subscription, and disabling a device push subscription does not delete account notification preferences.
Related docs
Related docs
See it in action
Previous
Notifications, Usage, and AI Credits
How notification preferences, device push subscriptions, AI credit balance, usage metrics, and active workspace session controls work from the account settings side.
Next
Programmatic API Catalog and Token Scopes
How to use personal access tokens, scope groups, and the live API catalog when automating GetPaidX from scripts or workspace agents.