android/wear-os-samples for Wear OS apps and watch faces

A feature-oriented Wear OS sample collection

android/wear-os-samples addresses developers who are starting a Wear OS app or watch face and need an example tied to a particular platform capability. It is not a framework, starter application, or backend service. Instead, the repository contains individual Android Studio projects, each focused on a separate subject. The collection spans Compose-based app development, communication between a watch and phone, OAuth authentication, audio recording and playback, AndroidX tiles, Remote Compose widgets, Watch Face Push, Watch Face Format, and complication data sources.

This structure suits developers who already know the feature they want to investigate. For example, a developer working on phone-to-watch messaging can inspect the DataLayer project without adapting an unrelated audio or widget sample. A watch face developer can focus on WatchFaceFormat, Complications, or WatchFacePush. The tradeoff is that the repository does not present these capabilities as one integrated reference application, so it offers little evidence of how they should be combined in a single product.

The primary language is Kotlin, and several app or widget samples use Compose. WatchFaceFormat is presented separately as an XML-based watch face format. This mix makes the repository a practical index of implementation styles represented in the samples, but it does not imply that every sample uses the same UI architecture.

How DataLayer and ComposeStarter solve separate problems

The repository uses separate top-level directories for each sample. ComposeStarter is described as a simple Compose for Wear OS starting point, while DataLayer concentrates on communication through the Wear OS Data Layer. That separation is significant because the two examples answer different development questions. ComposeStarter addresses application construction with Compose and Kotlin. DataLayer addresses the transfer of information between a watch and its paired phone.

Based on the repository layout, a developer can enter the directory for the capability under investigation and open that project in Android Studio. The README does not describe a common application shell, shared navigation structure, or common data model spanning the samples. It also does not claim that ComposeStarter depends on DataLayer. Each linked directory should therefore be assessed as an independent Android Studio project unless its own files establish otherwise.

This arrangement reduces the amount of unrelated code that must be read for a specific feature. It also means there is no single entry point through which all samples demonstrate end-to-end device communication, authentication, and UI behavior. The README functions mainly as a directory of choices, with links to Android developer guides for the underlying APIs.

DataLayer, WearOAuth, and device communication boundaries

DataLayer and WearOAuth address two distinct forms of communication. DataLayer demonstrates communication between a watch and a phone through the Data Layer. WearOAuth demonstrates authentication on a Wear OS app using the user's mobile device, without requiring the developer to provide a separate mobile companion app because the Wear OS companion app handles the request on the mobile side. The README states that the OAuth sample uses OAuth.

These samples should not be treated as interchangeable. The Data Layer example is intended to show watch-to-phone messaging, while WearOAuth focuses on an authentication request handled through the phone environment. Their linked Android guides cover different wearable platform subjects, and the repository summary does not claim that either project supplies production-grade identity management, token storage, message schemas, or conflict resolution.

For an engineer, that boundary is useful. A messaging requirement can be investigated in DataLayer, while delegated user authentication can be investigated in WearOAuth. However, the README remains silent about production deployment, message compatibility between different watch and phone versions, retry behavior, authentication failure handling, and secret management. Those points cannot be inferred from the one-line sample descriptions.

WatchFaceFormat, Complications, and WatchFacePush paths

The watch face material is divided into three directories rather than presented as one complete watch face project. WatchFaceFormat demonstrates Watch Face Format, which the README describes as allowing quick development of performant watch faces in XML. Complications supplies a suite of data sources for testing complication implementations across a range of states. WatchFacePush demonstrates the Watch Face Push AndroidX Library.

These projects address different layers of watch face work. WatchFaceFormat concerns the XML representation of a watch face. Complications concerns the data presented by complication slots. WatchFacePush concerns AndroidX support for pushing changes or updates to watch faces, although the README itself only identifies the library and does not document the sample's update protocol. It would therefore be inaccurate to infer transport behavior, update frequency, or failure recovery from the summary.

The Complications sample is especially framed as a test companion for watch face developers. It can provide varied data against which an implementation can be checked visually. The README does not claim that it models every production complication source or guarantees layout behavior on every watch shape and size. Developers still need to consult the linked Android guides and inspect the project files before selecting an approach.

Opening a sample for a first Wear OS study

The README does not provide command-line installation steps, dependency versions, emulator names, device configuration instructions, or a repository-wide build command. Its stated entry point is the collection of individual Android Studio projects, with each sample linked to the relevant Android developer guide. Because no exact setup commands or configuration files are included in the README, this article does not invent an installation procedure.

For a first use, select the top-level directory that matches the intended capability. Android Studio is the project type identified by the README. Review the files in that directory, then follow the guide linked beside the sample description. DataLayer is the relevant starting point for watch-to-phone communication, ComposeStarter for a simple Compose app, WearTilesKotlin for AndroidX tiles, and WearWidget for Remote Compose widgets.

A first study should end with a visible project-specific result, such as identifying the watch-side UI entry point, locating the phone-facing Data Layer code, or reviewing how a tile or widget is declared. The README does not document a universal command that builds all projects, so readers should not treat an unstated Gradle task as confirmed. It also does not define a required emulator or physical-device setup for each sample.

Audio, permissions, tiles, and Remote Compose coverage

WearSpeakerSample addresses audio recording and playback on wearable devices that have a speaker. The README also says that the sample demonstrates permission handling, but it does not enumerate the Android permissions, runtime prompt sequence, denial behavior, or storage policy. The speaker requirement is itself a concrete deployment constraint: the example concerns devices with suitable audio hardware rather than every Wear OS target.

WearTilesKotlin uses the AndroidX library for tiles. The README links to the Wear Tiles guide, but does not describe synchronization, button actions, tile layouts, or lifecycle behavior. Its scope should consequently be described as a sample of AndroidX tile development, not as a general tile implementation specification.

WearWidget uses Remote Compose and is described as a Wear Widget sample. Again, the README does not document update scheduling, data sources, rendering constraints, or packaging. What can be confirmed is the chosen mechanism: AndroidX for WearTilesKotlin and Remote Compose for WearWidget. Developers working across these areas can compare separate examples, but the repository does not show them sharing an application-level dependency or architecture.

Maintenance, licensing, and release status

The repository is not archived, and its last push was on 2026-10-14. The top-level layout includes a renovate.json file, indicating that Renovate configuration is part of the repository, but the README does not describe its dependency schedule or update policy. No further maintenance cadence can be confirmed from that filename alone. The repository also has no GitHub releases, so there is no published release sequence to use when assessing version-to-version upgrade work.

The repository is licensed under Apache-2.0. That identifier indicates the license selected by the project. The README and repository summary do not provide legal guidance about notices, modifications, redistribution, or compatibility. Code copied into an application should be reviewed under the actual Apache-2.0 license text and any dependency licenses introduced by that application. This is a compliance check tied to the files being copied, not evidence that the samples themselves are ready for production use.

Upgrades may require examining each Android Studio project independently because the repository contains multiple samples and no documented coordinated release process. The linked Android guides are also separate references. The last push date supports recent repository activity, but it does not prove that every sample has the same feature scope or dependency state.

Editorial conclusion

Wear OS developers should adopt this repository when they need a focused reference for a documented AndroidX or Compose capability, especially Data Layer communication, OAuth, tiles, widgets, audio, watch faces, or complications. Developers seeking a complete production application, a shared application architecture, or documented release procedures should treat the collection as reference code only. Before adopting an example, verify the sample that matches the intended feature in Android Studio, compare its dependency choices with the current Wear OS guide linked by that sample, and confirm that the watch and phone capabilities cover the intended deployment. The repository is licensed under Apache-2.0 and its last push was on 2026-10-14, but it has no GitHub releases, so upgrade planning must be handled outside the repository's published release history.

Frequently asked questions

Official sources

1. android/wear-os-samples on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README