Skip to content

How to Contribute

We'd love to accept your patches and contributions to this project. There are just a few small guidelines you need to follow.

If you find a common problem that you think would help other Wear developers please consider submitting a PR. Please avoid significant work before raising an issue with the label "Feature Request"


The project should work immediately from a fresh checkout in Android Studio (Stable or newer) or Gradle (./gradlew).

When submitting a PR, please check API compatibility and lint rules first.

A good first step is

./gradlew spotlessApply spotlessCheck compileDebugSources compileReleaseSources metalavaGenerateSignature metalavaGenerateSignatureRelease lintDebug

Also make sure you have (Git LFS) installed.

If you change any code affecting screenshot tests, then run the following to update changed images on a Linux host. Alternatively uncomment the same property in

./gradlew testDebug -P screenshot.record=repair

This can be automated For a PR against the same branch, the Github action should commit against PR if possible. For maintainers, this means creating the branch in the google/horologist repo. For contributors, once your PR fails, create a second PR in your fork, that will fix the issue.

Contributor License Agreement

Contributions to this project must be accompanied by a Contributor License Agreement. You (or your employer) retain the copyright to your contribution, this simply gives us permission to use and redistribute your contributions as part of the project. Head over to to see your current agreements on file or to sign a new one.

You generally only need to submit a CLA once, so if you've already submitted one (even if it was for a different project), you probably don't need to do it again.

Code reviews

All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.

Translation and localization

This project uses a semi-automatic pipeline to translate strings. When new or updated localized strings are ready, a PR is generated (example: google/horologist#692). Only the files configured via localization.bzl are sent for translation.

If you see a problem with translated text, don't edit localized resource files (e.g. res/values-en/strings.xml) manually, as they'll be overwritten. Instead, file an issue and use the l10n label. This will then be forwarded to the relevant teams.

Project Direction and Ownership

There are a couple of reasons we may not accept an otherwise valuable contribution.

  • Where the internal framework feature team, thinks the contribution is against the long term direction of the library.
  • Where long term ownership is unclear, such as a large contribution that likely involves ongoing maintenance.