Repository navigation
The watch tells the phone what it did with the pushed face - #9
Merged
Philoul merged 2 commits intoSep 15, 2026
Conversation
The face choice on the phone applies only to a watch with Watch Face Push (Wear OS 6+), but the phone showed it to every watch, and hid the Custom watchface controls for the complications face - a dead end on a watch that runs the code-based face, or for loading a zip before switching. The watch now reports WatchFacePushStatus(supported, installedFace) after the startup sync, after every install and in reply to the preferences. The phone shows the choice only when the watch said it is supported, in a card of its own with the complications face's picture when that face is selected. The Custom watchface card is always there. While the watch still holds the other face, the chosen row says "Installing…" until the watch reports the swap. A custom watchface sent while the complications face is selected is stored on the watch but not shown, and a dialog says so at that moment. A reinstalled wear app started with the default face and kept it until something asked the phone for the preferences, which on a watch with only the pushed face nothing did. The data layer service asks once at start, as soon as a node is known, so the phone's choice wins within seconds of connecting. The confirmation before a switch names both faces and drops the notes about Wear OS 6 and editor settings.
The lock that serialises installs lives in the helper instance, and the helper had no scope, so every injection site got its own instance and its own lock: the app, the data handler, the menu and the data layer service. After a reinstall the startup sync and the preferences from the phone still installed side by side, both found the slot empty, and the second failed with "limit reached" while the phone said "Installing…" for good. The helper is now a singleton. Two smaller things on the same path. A fresh install waits a few seconds for the phone's choice before installing the default, since the phone answers the resend request well within that time - measured 0.6 s - and the default would only be swapped out again. And an install whose token is already the synced one returns at once, so two callers wanting the same face no longer install it twice; a menu tap still installs, because that is the wearer asking for a face they removed.
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.
Follow-up to your review of the phone screen, on top of wear/cwf_wff.
One commit, tested on a Galaxy Watch 5 (Wear OS 6).
What changed
Testing
Screenshots:
