Repository navigation
feat(appupdates): show a one-time toast when an optional update is out - #1771
Merged
Merged
Conversation
bmc08gt
force-pushed
the
feat/update-available-toast
branch
from
October 14, 2026 18:30
f59ec08 to
f56fdbd
Compare
github-actions
Bot
added
type: feature
Play's flexible flow, a once-per-version record for the update toast, and the thresholds both toast hosts share. availableUpdate and the forced path are unchanged; the optional state lives in optionalUpdate. Debug builds can fake a priority-5 update with files/debug-optional-update.
When Play reports a flexible update with priority 4+ or 7+ days of staleness, store builds show "New version available" once per version: on the Chats or Wallet home 1s after coming back from a pushed screen or after 3s there (node 11693:162), or in a chat 1s after it opens, above the composer with a 6s timeout, dismissed when the keyboard opens (node 11705:162). Update starts the flexible download; once it is downloaded an indefinite "Update ready" toast offers Restart. The toast host gains a screen-set horizontal inset, which the chat sets to the composer row's side padding along with its bottom clearance. The unsupported-message bubble shows "Update Flipcash" whenever an optional update exists, without the toast's gates.
The forced controller now takes its AppUpdateManager as a constructor parameter, defaulting to the same factory call, so its tests can pass Play's FakeAppUpdateManager. Its behaviour is unchanged. ForcedUpdateTest covers the minimum-version gate, the staff override, opening the immediate flow, the guards in startUpdate(), reset(), and an update already under way being reported on the next check. FlexibleUpdatesTest adds a failed and a cancelled download, starting again after declining Play's dialog, and a download that finished while the app was gone offering Restart on the next check.
checkForUpdate() saw DEVELOPER_TRIGGERED_UPDATE_IN_PROGRESS and called startUpdate(), but startUpdate() first required isUpdateTypeAllowed(IMMEDIATE). Play's FakeAppUpdateManager reports that as false while an immediate update runs, so the resume failed with "Update type is not allowed" and Play's update screen never reopened. startUpdate() now skips that check when resuming, as Play's own resume sample does. The resume test checks that the flow starts a second time.
bmc08gt
force-pushed
the
feat/update-available-toast
branch
from
October 14, 2026 19:33
d0cf1d9 to
adb3fb4
Compare
bmc08gt
added a commit
that referenced
this pull request
Nov 8, 2026
…tional update check (#1981) FlexibleUpdates.check() passed every appUpdateInfo failure to trace(error = ...), which sends it to Bugsnag. Since #1771 that has filed InstallException -6 (download not allowed in the current device state) and RemoteException "AppUpdateService: Binder has died" (the Play Store process died mid-call) from 2026.10.4. Neither is something the app can fix. Those failures, plus the other InstallErrorCodes that describe the device or install (API not available, Play Store not found, app not owned), now leave a breadcrumb only. Other codes, such as -4 for a malformed request, are still reported. The check also rethrows CancellationException instead of logging a cancelled check as a failure.
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
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.
When Play has a flexible update that's priority 4 or higher, or has been out 7+ days, store builds now show a one-time "New version available" toast with an Update button. Stacked on #1770.
Where it shows (once per version):
Update starts Play's flexible download. Once it's downloaded, an indefinite "Update ready" toast offers Restart. If the download finishes while the app is in the background, it installs straight away.
Forced path:
availableUpdateand the minimum-version gate are unchanged; the optional update lives in a separateoptionalUpdate. One fix: resuming a forced update that's already under way never reopened Play's screen.startUpdate()requiredisUpdateTypeAllowed(IMMEDIATE), which Play's fake reports as false while an immediate update runs, so the resume failed with "Update type is not allowed". It now skips that check when resuming, as Play's resume sample does. The controller also takes itsAppUpdateManageras a constructor parameter (defaulting to the same factory call) so the newForcedUpdateTestcan use Play's fake.Other changes:
FloatingToastHostgains a screen-set horizontal inset next to the existing bottom clearance. The chat sets both, so any toast shown in a chat now sits above the composer rather than behind it.Indefiniteplus a 6s timeout, so the host's accessibility scaling for long toasts doesn't apply to it.Trying it on a debug build:
adb shell run-as com.flipcash.app.android touch files/debug-optional-updatefakes a priority-5 update. Deletefiles/datastore/update-toast.preferences_pbto reset the once-per-version record.