Notifications: report fast mode unavailable on the website flavour - #2181
Merged
mpretty-cyro merged 2 commits intoAug 24, 2026
Merged
Conversation
The de-googled build has no FCM at all — `firebase-messaging` is only added to the `play` and `fdroid` variants and `FirebasePushService` only appears in their manifests, so `website` binds `NoOpTokenFetcher` and its token is permanently null. But this function returned an unconditional `true`, so onboarding and Notification settings both offered "Fast Mode (Recommended)" and let it be switched on, after which no push was ever registered and nothing said so. Confirmed on an emulator with Play Services present: flavour is a build-time choice, so a fully Google-serviced device gains nothing. Worse, choosing it set PUSH_ENABLED, which suppresses HomeViewModel's battery-optimisation prompt — removing the one mitigation that helps a user who is actually depending on 15-minute background polling. Note this does not migrate existing installs: a website user who already enabled fast mode keeps PUSH_ENABLED set, so their prompt stays suppressed until that pref is also taken into account.
Bilb
approved these changes
Aug 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
The de-googled build offers "Fast Mode (Recommended)" in onboarding and in Notification settings, lets
the user switch it on, and then never registers for push — with nothing saying so.
isFastModeAvailable()returned an unconditionaltruefor this flavour, but the flavour has no FCM atall:
firebase-messagingis added only to theplayandfdroidvariants (app/build.gradle.kts)FirebasePushServiceis registered only in theplayandfdroidmanifestswebsitebindsNoOpTokenFetcher, whose token is permanentlynull, andPushRegistrationHandlercombines ontoken.filterNotNull()— so registration is never evenattempted
Because the flavour is a build-time choice, the device's capability is irrelevant: a fully
Google-serviced phone that installs this APK still gets no push. Confirmed on an emulator with Play
Services present.
Why it is worse than "notifications are slower"
Choosing fast mode sets
PUSH_ENABLED, andHomeViewModelgates the battery-optimisation prompt on theuser not being in fast mode. So the one mitigation that helps someone who is actually depending on
15-minute
BackgroundPollWorkerpolling is suppressed for exactly the users who cannot receive push.The change
Report fast mode unavailable on this flavour, with a comment recording why so it isn't "fixed" back to
true. The settings toggle then shows as disabled and the battery-optimisation prompt returns.Known gap: existing installs are not migrated
A user who already enabled fast mode keeps
PUSH_ENABLEDset, so their prompt stays suppressed. Theclean follow-up is to treat "effectively in fast mode" as
PUSH_ENABLED && isFastModeAvailable()at thetwo read sites rather than mutating the stored preference — deliberately left out of this change.
Alternative considered
Giving
websitethe same wiringfdroidalready has (Firebase dependency plus the realcom.google.android.gmscheck) would let capable devices receive push. Not taken: this flavour exists tobe Google-free, and it began life as "add no op push manager for de-googled".