Google releases Android Wear 2.0 developer preview 4, restores some Wear 1.0 behavior and adds many new APIs

Android Police

By Cody Toombs

Published Dec 13, 2016

Google revealed disappointing news alongside the release of the third developer preview of Android Wear 2.0, informing developers and early users that a final release would be pushed back to early 2017. The fourth developer preview became available today and it comes with some big changes that suggest the Wear team is putting the extra time to good use. There are several new APIs for developers and a few things for users to check out.

Swipe-to-dismiss

The most significant change in this release is the return of "swipe-to-dismiss" – the navigation model where users swipe right across the screen to return to a previous screen or exit an app. This was the navigation model of Android Wear 1.0, but it was swapped out with the first 2.0 developer preview in favor of using the physical power button as a Back button. User feedback prompted the Wear team to revert to the original swipe method, likely because it's faster, more intuitive, and keeps user attention on the screen.

The physical power button once again acts more like the Home button did in Android Wear 1.0: it will leave any current app or notification and return to the watch face. If the watch face is already showing, a button press opens the app launcher. It also still serves the additional role of dismissing a keyboard if one is showing. Developers should check out the list of other implications and behavior changes as they relate to building apps.

This change may actually re-open the door for watches that don't have hardware buttons. Whether people want that or not may be up for debate, but a mandatory hardware button for navigation had been a topic of some discussion after the first developer preview was released.

Compatibility with Android Wear 1.0 apps

Also making a return from Android Wear 1.0 is support for apps packaged inside of apps. The third developer preview added a miniature version of the Play Store to handle apps for the watch, but in doing so, Google disabled support for the older method of packaging apks for Wear inside of apks for phones. This particular piece of information wasn't widely communicated, so there was a great deal of confusion about apps that didn't appear to be installing properly. Both types of installations should now work with DP4, but Google is still strongly encouraging developers to use the standalone model since it gives more choices to users and improves usability through the Play Store.

Play Store APIs

Features related to the Play Store have also expanded. Developers can now add in-app purchases to Wear apps without relying on paired apps or workarounds. Authorization for purchases is still protected by a 4-digit PIN.

There's also a new feature for standalone apps that's intended to help users install the matching app on their phones. Developers may now send an intent across to a paired device without any special accommodations.

Seamless authentication

Google's final major addition follows along with the theme of simplifying actions on a watch using a paired phone. Developers can now call an API on a watch that opens up a sign-in prompt on a paired phones. This will allow users to choose accounts and read details about permissions on a more appropriately sized screen.