Scaffold the :wear application module (issue #276) - #280
Merged
Merged
Conversation
Step 3 of Wear OS phase 1: a new standalone :wear Gradle module with its own Hilt Application/MainActivity, manifest (watch feature requirement, standalone meta-data so it runs without a paired phone, matching the target LTE watch), and launcher icon. Depends on :core, so it picks up the existing Room database and settings DataStore Hilt modules for free -- no wear-specific database module needed, since the watch's own installed copy of AppDatabase never touches the phone's file regardless of matching filenames (separate device, separate app). Adds PlayServicesWearSyncClient, the real DataClient-backed implementation of :core's WearSyncClient interface (added in the previous PR), bound via Hilt in WearSyncModule. Queue snapshots and position updates are wire-encoded into DataMap key/value pairs and round-tripped through the Data Layer API's putDataItem/DataClient listener callbacks. Installed and launched the debug build on a newly created Wear OS 6.0 emulator (mycasts_wear_test) to confirm it actually boots -- confirmed MainActivity reaches state=RESUMED with no crash. Still not wired up to the phone side (step 4: the sync bridge and PhoneSyncListenerService) or backed by real playback (step 5) or a real UI (step 6).
This was referenced Sep 2, 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
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
Step 3 of #276 (see #278, #279 for steps 1-2). Adds a new standalone
:wearGradle module with its own HiltApplication/MainActivity, manifest (watch feature requirement,standalonemeta-data so it runs without a paired phone — matches the target LTE watch), and launcher icon.:weardepends on:core, so it picks up the existing Room database and settings DataStore Hilt modules for free — turns out no wear-specific database module is needed: the watch's own installed copy ofAppDatabasenever touches the phone's file regardless of matching filenames, since they're separate devices/separate app installs. This simplifies the original plan, which assumed a dedicatedWearDatabaseModulewould be needed.Also adds
PlayServicesWearSyncClient, the realDataClient-backed implementation of:core'sWearSyncClientinterface (from #279), bound via Hilt inWearSyncModule. Queue snapshots and position updates are wire-encoded intoDataMapkey/value pairs and round-tripped through the Data Layer API'sputDataItem/listener callbacks.Still not wired up to the phone side (step 4: the sync bridge +
PhoneSyncListenerService), not backed by real playback (step 5), and the UI is a placeholder (step 6).Test plan
./gradlew assembleDebug testDebugUnitTest lintDebugpasses across:app/:core/:wear:weardebug build on it — confirmedMainActivityreachesstate=RESUMEDwith no crash:app's debug build on a phone emulator — confirmed no regression