Making Your Watch Face Wear 2.0 ready

Android Wear 2.0 is right around the corner. The preview can be downloaded for a variety of devices and the final version is set to be released in February. Time to get your wearable app or watch face ready for 2.0!

One fantastic new feature of Wear 2.0 is the integration of a Play Store on the watch. If you have a watch face in the store right now, it will increase its discoverability and make it available to all Android Wear owners who use an iPhone! Great stuff!

Wearable Play Store preview Download a watch face directly from Android Wear

If you have a watch face targeting Wear 1.0 in the store right now then you’ve probably already received a message from Google with a few pointers on how to make it 2.0-ready. However, there is a lot of documentation to go through, especially if you want to keep 1.0 compatibility. That’s why we did a little write-up on how to get to Wear 2.0 quickly and as automatically as possible.

Whether it’s an update to Wear 2.0 you’re making, or a fresh Wear 2.0 app that you’d also want to publish in the regular phone store, you’ll have to go down the road of multiple-APKs. This involves advanced uploads, careful version numbering and some manual labor that we’re going to delegate to Gradle.

Before you continue, double-check that your watch face can really be made stand-alone — only if the watch face is a completely functional module that does not rely on sending/receiving data to/from the phone, or if the related phone app only provides optional functionality, then can your wear app be made stand-alone. If it requires a phone to do anything, then it’s no use making it stand-alone.

Throughout this example we’re going to assume you’re familiar with Gradle and that you have both an app and a wear module in your project.

Prepare for Wear 2.0

1. Target Nougat

Android Wear 2.0 is Nougat, so set your targetSdk to 25 in the build.gradle of the wear module.

2. Runtime permissions

Updating to SDK 25 means that, if you weren’t already, you should now use runtime permissions.

Make your wear app stand alone

3. Adjust the wear manifest

The following line of meta-data is the first and most important step to let the Play Store know your wearable app can run on its own. Add it to your wear module’s AndroidManifest.xml:

<application>
   ...
    <meta-data
        android:name="com.google.android.wearable.standalone"
        android:value="true" />

</application>

4. Create a shared module

Wear apps that purely function as a watch face could previously do without a launcher icon and an app name. If you try to make such an app stand-alone though, you’ll get an error when uploading it to the Play Store. Since we usually prefer to have the same name and icon as the related phone app, we suggest creating a shared module (if you don’t already have one) and putting the icons in its resource folders (in its respective resource bins when necessery, e.g. for different languages). This ensures that changing the icon or translating the app name is automatically propagated in both apps.

For convenience, we’ll also share the version name and number across modules. There are multiple ways of doing this; we prefer using the gradle.properties file. Add the following to it; we’ll reference it from the Gradle scripts later:

VERSION_NAME=1.2.0
VERSION_CODE=120

Multiple-APK

Using multiple-APK uploads is usually a last-resort method when dealing with backwards-compatibility. Google usually advises against it, however in this case there’s no way to avoid it: you need an APK for installing on phones, and an APK for installing on wearables. Besides, you’ll also be dealing with different minimum SDKs that force the use of multiple APKs.

5. Version numbers

You’ll need to have two version codes: a low one for the backwards-compatible APKs, and a higher one for the standalone APK. We prefer following Google’s suggested method:

  • the first two digits indicate the minimum SDK level;
  • the second few digits indicate a differentiation of your choice;
  • the last three digits indicate the version name.

Version numbering

The first two digits are most crucial, they make sure that devices with a newer OS will receive the updates that are most compatible with the new SDKs. In this example we’re differentiating on SDK level alone, so we leave the middle digits out. In our example we have a Wear 1.0-compatible embedded wear module (SDK level 21) and a Wear 2.0-compatible standalone wear app (SDK level 24). Our version code is 120, so our version numbers will be:

  • 21120
  • 24120

Intuitively you might think that the next update, say, 21121, can never be published because the version number is lower than 24120 and the Play Store won’t allow downgrades. This is only the case in single-APK mode though where the Play Store prevents you from publishing such ‘impossible’ updates.

6. Flavors

We’re making different types of APKs and the easiest way of doing this is by using Gradle product flavors. Let’s call one ‘regular‘ and one ‘standalone‘. You could also go for `phone‘ and ‘wear‘, or whatever.

In your wear module’s build.gradle:

android {
    publishNonDefault true        // because we're doing flavor trickery
    ...
    defaultConfig {
        // This is the value from the properties file we set earlier
        versionName VERSION_NAME  
        ...
    }
    ...
    productFlavors {
        regular {
            // The embedded wear app is still compatible with Wear 1.0
            minSdkVersion 21
            // We reflect compatibility in the version number: 21120
            versionCode Integer.parseInt("21" + VERSION_CODE)
        }
        standalone {
            // The standalone wear app must have minSdk 24 for it to work
            minSdkVersion 24
            // Different, higher version number here: 24120
            versionCode Integer.parseInt("24" + VERSION_CODE)
        }
    }
}

What happened here is that we automatically set different version numbers for each flavor (even though we still only have to update it once for every update: in the gradle.properties file) and we automatically set the appropriate minSdkVersion for each flavor. The publishNonDefault is needed because we’re making two wear flavors and we want to ensure the correct one is embedded in the phone APK. That happens in the mobile module’s build.gradle file:

android {
    ...
    defaultConfig {
        versionName VERSION_NAME  
        versionCode Integer.parseInt("21" + VERSION_CODE)
        ...
    }
}

dependencies {
    ...
    // REPLACE THIS:
    //wearApp project(':wear')
    // WITH:
    wearApp project(path: ':wear', configuration: 'regularRelease')
    ...
}

In the above snippet we don’t bother with the product flavors or the version numbers, since we’ll be releasing only a single phone APK. We do need to make sure the ‘regular’ flavor of the wear APK is embedded, which we set in the dependencies block.

Updates

7. Build

Build your updates as usual: update the version code in the gradle.properties and run ./gradlew assembleRelease. This will build all necessary APKs.

8. Uploading to the Play Store

Finally, we did it! We have a way of building the original and the stand-along APK with a single command, and now we’re ready to publish them to the Play Store.

First things first: multiple-APK uploads require you to switch the Play developer console to ‘advanced mode’. The button is on the top-right of the APK upload page:

Enabling 'advanced mode' in the Play Store developer console

Now it is time to upload the APKs:

  • Upload app-release.apk, like you did before making your app 2.0-ready.
  • Upload wear-standalone-release.apk.
  • Deactivate previous builds if needed.
  • Publish.

That’s it. Done! Both APKs will be published to Play Store, and within a couple of hours they can be found on both your phone and your watch. Enjoy!

Wearable Play Store example

Share