---
title: Build for Wear OS, Android TV and Automotive
description: Capawesome Cloud builds every Android application module in one build and returns an APK and AAB per form factor — phone, Wear OS, Android TV, and Automotive.
---

# Build for Wear OS, Android TV and Automotive

An Android project can hold more than one application module: the phone app plus a Wear OS app, an Android TV app, or an Android Automotive app. Every Capawesome Cloud Android build compiles the whole Gradle project and collects the APK and the AAB of every application module it finds. Projects with a single application module are unchanged — they still produce one APK and one AAB.

Each artifact carries the form factor detected from its module's manifest. There is nothing to configure and nothing to enable.

To add a Wear OS module to a Capacitor project, see [How to Build a Wear OS App for Your Capacitor App](../../blog/posts/how-to-build-a-wear-os-app-for-your-capacitor-app.md). To exchange messages and state between the phone app and the watch app, use the [Capacitor Watch plugin](../../sdks/capacitor/watch.md).

## Prerequisites

Every application module in the project must:

- Use the same `applicationId` as the phone app. A [native configuration](native-configurations.md) rewrites the `applicationId` in every module whose `build.gradle` (or `build.gradle.kts`) declares one, so declare it explicitly in each application module to keep them in sync.
- Use the same signing certificate. The build signs all modules with the keystore of the selected [Android signing certificate](certificates/android.md).
- Use a `versionCode` that is unique across form factors. Google Play rejects two artifacts of the same app with the same version code.
- Support the [build type](build-types.md) and product flavor of the build. `ANDROID_BUILD_TYPE` and `ANDROID_FLAVOR` apply to every application module, not just the phone app. A module without the selected build type or flavor is not built and not collected.
- Target a form factor of its own. The build fails when two application modules target the same form factor, such as a phone app and a demo app. Set the `ANDROID_MODULES` [environment variable](environment-variables.md#reserved-variables) to the Gradle project paths of the modules to collect, e.g. `:app,:wear`. The other modules are still compiled but not uploaded. A listed module without an artifact for the build type and flavor fails the build.
- Produce a single APK. With [APK splits](https://developer.android.com/build/configure-apk-splits){:target="_blank"} (e.g. ABI splits), set `universalApk true` so the build can pick the universal APK, which installs on every device. Without it, the build fails. App bundles are not affected.

### Unique version codes

Google Play applies two rules to version codes. A version code that has been uploaded once can never be used again for the same package, whatever the form factor. And each new release on a track must have a higher version code than the previous release on that track. The phone app and the watch app share the package name, so they need separate version codes, but neither has to be higher than the other: the mobile track only compares against earlier phone releases, the wear track against earlier watch releases.

The simplest scheme keeps the phone module on the build number from [Auto-increment build numbers](auto-incrementing-build-numbers.md) and gives every other application module the build number plus a fixed offset in its own Gradle file:

```groovy
android {
    defaultConfig {
        versionCode = (System.getenv("CI_BUILD_NUMBER") ?: "1").toInteger() + 1000000
    }
}
```

Choose the offset so the phone range can never reach it. With 1,000,000 per form factor, each range holds a million builds and stays far below Google Play's limit of 2,100,000,000.

## Form factors

The form factor comes from the features the module's manifest declares as required (`android:required="true"`, the default):

| Form factor | Required feature | Typical module |
| --- | --- | --- |
| `mobile` | none of the features below | Phone and tablet app (default) |
| `watch` | `android.hardware.type.watch` | Wear OS app |
| `tv` | `android.software.leanback` | Android TV app |
| `automotive` | `android.hardware.type.automotive` | Android Automotive OS app |

A feature declared with `android:required="false"` does not count, so a phone app that optionally supports Android TV stays `mobile`.

When no form factor is requested, artifacts are selected in the order `mobile`, `watch`, `tv`, `automotive`. The same order decides which artifact supplies the package name and version shown for the build in the Console.

## Download the artifacts

=== "CLI"

    [`apps:builds:download`](../cli/commands.md#appsbuildsdownload) and [`apps:builds:create`](../cli/commands.md#appsbuildscreate) accept `--form-factor` with the values `mobile`, `watch`, `tv`, and `automotive`. It picks which Android artifact the `--apk` and `--aab` flags download — it never changes what is built.

    ```bash
    # Mobile AAB, saved as <buildId>.aab
    npx @capawesome/cli apps:builds:download --aab

    # Watch AAB of the same build, saved as <buildId>-watch.aab
    npx @capawesome/cli apps:builds:download --aab --form-factor watch
    ```

    Without `--form-factor`, the CLI downloads the first artifact in the order `mobile`, `watch`, `tv`, `automotive`, so a project with a phone module gets the phone artifact. A mobile artifact is saved as `<buildId>.<type>`, other form factors as `<buildId>-<formFactor>.<type>`, unless you pass a file path. Each flag downloads one artifact per invocation, so two form factors take two commands.

=== "Console"

    Open the build's detail page from the [Builds](https://console.cloud.capawesome.io/apps/_/builds){:target="_blank"} page. It lists every artifact of the build with its form factor, and each artifact has its own download.

[`apps:builds:run`](run-on-emulator-or-simulator.md) selects its artifact the same way. The **Install** button and its QR code always serve the mobile artifact, as does the public [share page](share-a-build.md); a build without a mobile artifact shows no Install or Download button.

## Publish to Google Play

A submission to a [Google Play Store destination](../app-store-publishing/destinations/google-play-store.md) uploads every artifact of the destination's publishing format (AAB or APK), mobile first. The destination's track applies to the mobile artifact. The other artifacts go to Google Play's prefixed track of the same name:

| Form factor | Track on Google Play |
| --- | --- |
| `mobile` | the destination's track, e.g. `production` |
| `watch` | `wear:<track>`, e.g. `wear:production` |
| `tv` | `tv:<track>`, e.g. `tv:production` |
| `automotive` | `automotive:<track>`, e.g. `automotive:production` |

Before the first submission, enable the form factor in Google Play Console under **Advanced settings → Form factors**. Google Play only offers the prefixed tracks after this opt-in, and Wear OS apps go through their own review.

When a build has more than one artifact, Capawesome Cloud validates all of them against Google Play before it publishes anything. A missing `wear:production` track therefore fails the submission before the phone app is released. See [Submit a build](../app-store-publishing/submit-a-build.md).

## Limitations

- **iOS**: standalone watchOS, tvOS, and visionOS apps are not built as separate artifacts. iOS targets and app extensions ship inside the single `.ipa` and are configured through [custom iOS provisioning profiles](custom-ios-provisioning-profiles.md).
- **Android XR**: an Android XR module is not detected and is treated as `mobile`.
- **No override**: the form factor comes from the manifest. There is no per-module setting to change it.
- **APK splits**: only the universal APK is collected, not the per-ABI or per-density APKs.
- **Install on a device**: a watch APK cannot be installed through the Install button or the QR code. Download it with `--form-factor watch` and install it with `adb install`.

## Next steps

- [Publish Android App Bundles](android-app-bundles.md) — the format Google Play requires for new apps.
- [Set up signing certificates](certificates/android.md) — the keystore that signs every module.
- [Share a build](share-a-build.md) — give external testers a public link to the mobile artifact.