Fix Wear OS sync by matching :wear's applicationId to :app's (issue #276) - #284
Merged
Merged
Conversation
) Real-device testing on a Pixel 10 Pro + Pixel Watch 4 (already paired via the Wear OS companion app) showed the queue never syncing: :app's push succeeded, both devices saw each other as connected Play Services nodes, but the watch's own local Data Layer cache stayed empty no matter how long we waited, even after rebooting both devices. Root cause, confirmed via Android's own Wear OS Data Layer docs: the API only syncs data between a phone app and a watch app that share the same package name. :wear's applicationId (com.bugzapperlabs.mycasts.wear) never matched :app's (com.bugzapperlabs.mycasts), so Play Services treated them as two unrelated apps regardless of node connectivity -- this was silent (no exception, no error) since it's authorization-level filtering, not a connectivity failure. Changed :wear's applicationId to com.bugzapperlabs.mycasts (matching :app exactly; namespace/Kotlin package stays com.bugzapperlabs.mycasts.wear, which doesn't affect Play Services routing). Verified end-to-end on the real device pair: added an episode to Next Up on the phone, confirmed it landed in the watch's own local database and rendered in the watch's queue UI within seconds.
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
1 participant
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.
Summary
Follow-up fix to #276 (phase 1, PRs #278-283), found via real-device testing on a Pixel 10 Pro + Pixel Watch 4.
The queue never actually synced to the watch:
:app's push succeeded with no exception, both devices saw each other as connected Play Services nodes, but the watch's own local Data Layer cache stayed empty no matter how long we waited — even after fully rebooting both devices.Root cause (confirmed via Android's own Wear OS Data Layer documentation): the Data Layer API only syncs data between a phone app and a watch app that share the same package name.
:wear'sapplicationId(com.bugzapperlabs.mycasts.wear) never matched:app's (com.bugzapperlabs.mycasts), so Play Services silently treated them as two unrelated apps regardless of node connectivity — no exception, no error, just nothing delivered. This is also why the user's previously-installed Pocket Casts phone+watch pair worked fine on the same hardware: real Wear OS companion apps always share one package name between the phone and watch halves.Fix
Changed
:wear'sapplicationIdtocom.bugzapperlabs.mycasts, matching:appexactly. The Kotlin package/namespace stayscom.bugzapperlabs.mycasts.wear(namespace doesn't affect Play Services routing, onlyapplicationId/package name does).Test plan
./gradlew assembleDebug testDebugUnitTest lintDebugpasses across:app/:core/:wear