Android Wear 2.0 Developer Preview 4: Authentication, In-App Billing, and more

Posted by Hoi Lam, Developer

A key part of Android Wear 2.0 is letting
watch apps work as standalone apps, so users can respond to messages, track
their fitness, and use their favorite apps, even when their phone isn't around.
Developer Preview 4 includes a number of new APIs that will help you build more
powerful standalone apps.

Seamless authentication

To make authentication a seamless experience for both Android phone and iPhone
users, we have created new APIs for href=" wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog">OAuth
and added support for one-click Google Sign-in. With the OAuth API for
Android Wear, users can tap a button on the watch that opens an authentication
screen on the phone. Your watch app can then authenticate with your server side
APIs directly. With Google Sign-In, it's even easier. All the user needs to do
is select which account they want to authenticate with and they are done.

In-app billing

In addition to paid apps, we have added href=" wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog">in-app
billing support, to give you another way to monetize your Android Wear app
or watch face. Users can authorize purchases quickly and easily on the watch
through a 4-digit Google Account PIN. Whether it's new levels in a game or new
styles on a watch face, if you can build it, users can buy it.

Cross-device promotion

What if your watch app doesn't work standalone? Or what if it offers a better
user experience when both the watch and phone apps are installed? We've been
listening carefully to your feedback, and we've added href=" wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog#detecting-your-app">two
new APIs (PlayStoreAvailability and RemoteIntent)
to help you navigate users to the Play Store on a paired device so they can
more easily install your app. Developers can also open custom URLs on the phone
from the watch via the new RemoteIntent API; no phone app or data
layer is required.

class="prettyprint">// Check Play Store is available
int playStoreAvailabilityOnPhone =

if (playStoreAvailabilityOnPhone == PlayStoreAvailability.PLAY_STORE_ON_PHONE_AVAILABLE) {
// To launch a web URL, setData to Uri.parse("")
Intent intent =
new Intent(Intent.ACTION_VIEW)
// mResultReceiver is optional; it can be null.
RemoteIntent.startRemoteActivity(this, intent, mResultReceiver);

Swipe-to-dismiss is back

Many of you have given us the feedback that the swipe-to-dismiss gesture from
Android Wear 1.0 is an intuitive time-saver. We agree, and have reverted back to
the previous behavior with this developer preview release. To support
swipe-to-dismiss in this release, we've made the following platform and API

  • Activities now automatically support swipe-to-dismiss.
    Swiping an activity from left to right will result in it being dismissed and the
    app will navigate down the back stack.
  • New Fragment and View support. Developers can wrap the
    containing views of a Fragment or Views in general in the new
    SwipeDismissFrameLayout to implement custom actions such as going
    down the back stack when the user swipes rather than exiting the activity.
  • Hardware button now maps to "power" instead of "back" which
    means it can no longer be intercepted by apps.

Additional details are available under the href=" wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog">behavior
changes section of the Android Wear Preview site.

Compatibility with Android Wear 1.0 apps

Android Wear apps packaged using the legacy embedded app mechanism can now be
delivered to Android Wear 2.0 watches. When a user installs a phone app that
also contains an embedded Android Wear app, the user will be prompted to install
the embedded app via a notification. If they choose not to install the embedded
app at that moment, they can find it in the Play Store on Android Wear under a
special section called "Apps you've used".

Despite support for the existing mechanism, there are significant benefits for
apps that transition to the href="">multi-APK
delivery mechanism. Multi-APK allows the app to be searchable in the Play
Store on Android Wear, to be eligible for merchandising on the homepage, and to
be remotely installed from the web to the watch. As a result, we strongly
recommend that developers move to multi-APK.

More additions in Developer Preview 4

  • href=" wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog">Action
    and Navigation Drawers: An enhancement to peeking behavior
    allows the user to take action without scrolling all the way to the top or
    bottom of a list. Developers can further fine-tune drawer peeking behavior
    through new APIs, such as setShouldPeekOnScrollDown for the action
  • href=" wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog">WearableRecyclerView:
    The curved layout is now opt-in, and with this, the WearableRecyclerView is now
    a drop-in replacement for RecyclerView.
  • href=" wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog#using_fields_for_complication_data">Burn-in
    protection icon for complications: Complication data providers can now
    provide icons for use on screens susceptible to burn-in. These burn-in-safe
    icons are normally the outline of the icon in interactive mode. Previously,
    watch faces may have chosen not to display the icon at all in ambient mode to
    prevent screen burn-in.

Feedback welcome!

Thanks for all your terrific feedback on Android Wear 2.0. Check out href=""> for the latest builds and
documentation, keep the feedback coming by href="">filing bugs or posting in our href="">Android Wear
Developers community, and stay tuned for Android Wear Developer Preview 5!

Related Posts

Subscribe Our Newsletter