Google pushed out a fourth beta of Android Wear 2.0 this week and gave the smartwatch platform a handful of new features. In order to power the new functionality, Google added a number of new APIs for developers to work with.
Google notes in a blog post that one of the major facets of Android Wear 2.0 is its ability to let watch apps run independently from a nearby smartphone. The company says the new APIs marking their debut in Android Wear 2.0 Developer Preview 4 allow developers to take advantage of that power.
Before smartwatch apps can run by themselves, Android Wear owners need to be able to find them. Remember, Android Wear 2.0 will have its own version of the Google Play Store. Google, however, understands that some apps will work better when they have a smartphone companion. This is the point of the new PlayStoreAvailability and RemoteIntent APIs. The first will help end users get from your app on the watch to the companion app in the Google Play Store. Google says developers can use the RemoteIntent API to open custom URLs on the phone from the watch. More information about the PlayStoreAvailability and RemoteIntent APIs is available here.
Once the app is installed, developers will want to take advantage of the new OAuth API for Android Wear that enables one-click Google sign-in. Google says this API will let developers add a button to their app to open the authentication screen. The watch app will be able to authenticate with the developer's server side APIs directly. End users will be able to select which account to use for authentication. More information about the OAuth API is available here.
Another positive change for developers arrives in the form on in-app billing for watch apps. This gives developers a way to monetize their Android Wear app or watch face through a four-digit PIN linked to the user's Google Account.
The last set of APIs from Google center on user interface functionality. For example, the setShouldPeekOnScrollDown API is an improvement to peeking behavior that lets users take action without scrolling all the way to the bottom of a list. The WearableRecyclerView API is a replacement for the RecyclerView API and makes the curved layout opt-in if developers want to use it. Another tool can help prevent screen burn-in for complications. Google says the burn-in-safe icons are generally the outline of what the icon looks like when users are interacting with it.
Google brought back the swipe-to-dismiss action that it removed from previous betas. In order to do this, it had to update some of the API behaviors. Certain activities now automatically support swipe-to-dismiss, and developers can wrap containing views of fragments to implement certain actions in their app. Importantly, the hardware button maps to "power" instead of "back." This means it can no longer be intercepted by apps.
Last, Google has revised the way Android Wear apps can be packaged in order to support both Android 1.0 and Android 2.0 devices. Google suggests developers take advantage of the new multi-APK delivery mechanism so apps can be searched for in the Play Store on wearables as well as remotely installed from smartphones.
Google has plenty of documentation providing more detail about all these changes here.