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

A key part of Android Wear 2.0 is letting
watch apps work as a 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 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 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 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.

// Check Play Store is available

int playStoreAvailabilityOnPhone =

    PlayStoreAvailability.getPlayStoreAvailabilityOnPhone(getApplicationContext());



if (playStoreAvailabilityOnPhone == PlayStoreAvailability.PLAY_STORE_ON_PHONE_AVAILABLE) {

    // To launch a web URL, setData to Uri.parse("https://g.co/wearpreview")

    Intent intent =

        new Intent(Intent.ACTION_VIEW)

            .addCategory(Intent.CATEGORY_BROWSABLE)

            .setData(Uri.parse("market://details?id=com.google.android.wearable.app"));

    // 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-close in this release, we've made the following platform and API
changes:

• 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 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 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

• 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
  drawer.
  
• WearableRecyclerView:
  The curved layout is now opt-in, and with this, the WearableRecyclerView is now
  a drop-in replacement for RecyclerView.
  
• 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 g.co/wearpreview for the latest builds and
documentation, keep the feedback coming by filing bugs or posting in our Android Wear
Developers community, and stay tuned for Android Wear Developer Preview 5!