Oct 16

Final Android Wear 2.0 Developer Preview: iOS support. Time to upload your apps to the Play Store!

Posted by Hoi Lam, Developer
Advocate 

Cross platform support by Telegram Messenger

Today, we are releasing the fifth and final developer preview for Android Wear
2.0. In this release, we have added iOS support and included a number of bug
fixes and enhancements. Apps compiled with this preview are now ready for final
submission to the Google Play Store, so it’s time to publish
your apps. As Android Wear 2.0 approaches its final release in early
February, we would like to thank you for your continued feedback during the
developer preview program. Your input has helped us uncover bugs as well as
drive critical product decisions. Thank you!

iOS Support

Since 2015,
you’ve been able to pair Android Wear watches with iPhones, and now you can
distribute your apps to iPhone-paired watches as well. To do so, just set the standalone=true
flag in your watch app manifest. This lets the Play Store know that your watch
app doesn’t require an Android phone app, and therefore can appear in the Play
Store on watches paired to iPhones. To pair your watch to an iPhone and
test, just follow these
steps.

The available network bandwidth for standalone apps can be lower than expected,
as the platform balances battery savings vs network bandwidth. Make sure to
check out these guidelines
for accessing the network, including accessing Wi-Fi and cellular networks on
watches paired with iPhones.

Also with this developer preview release, Android Wear apps running on watches
paired with iOS devices will be able to perform phone hand-off flows such as OAuth
and RemoteIntent
for launching a web page on a paired iOS device.

Uploading Your App to the Google Play Store

The final developer preview includes an update to the Wearable Support Library.
Apps compiled with API level 25 and this support library are considered ready
for deployment in the Google Play Store. Please note that there are no updates
to the preview watch image or emulator in this developer preview release.


Other Enhancement and Bug Fixes

  • Navigation Drawer: Flip
    a flag to toggle to the single-page, icon-only action drawer, which provides
    faster, more streamlined navigation to different views in your app.
  • NFC HCE support: NFC
    Host Card Emulation FEATURE_NFC_HOST_CARD_EMULATION is now
    supported.
  • ProGuard and Complication API: New ProGuard configuration
    means complication data container classes will no longer be obfuscated. This
    fixes a ClassNotFoundException when watch faces are trying to access data supplied
    by a complication data provider.

Countdown to Launch

Thank you for the fantastic level of feedback we have gotten from you as
developers. Check out g.co/wearpreview for
the latest builds and documentation, and be sure to publish
your apps before the Android Wear 2.0 consumer launch in early February. As
we work towards the consumer launch and beyond, please continue filing bugs or posting comments in our Android Wear
Developers community. We can’t wait to see your Android Wear 2.0 apps!


Android Developers Blog

Sep 09

Interactive watch faces with the latest Android Wear update

Posted by Wayne Piekarski, Developer Advocate

The Android Wear team is rolling out a new update that includes support for interactive watch faces. Now, you can detect taps on the watch face to provide information quickly, without having to open an app. This gives you new opportunities to make your watch face more engaging and interesting. For example, in this animation for the Pujie Black watch face, you can see that just touching the calendar indicator quickly changes the watch face to show the agenda for the day, making the watch face more helpful and engaging.

Interactive watch face API

The first step in building an interactive watch face is to update your build.gradle to use version 1.3.0 of the Wearable Support library. Then, you enable interactive watch faces in your watch face style using setAcceptsTapEvents(true):

setWatchFaceStyle(new WatchFaceStyle.Builder(mService)
    .setAcceptsTapEvents(true)
    // other style customizations
    .build());

To receive taps, you can override the following method:

@Override
public void onTapCommand(int tapType, int x, int y, long eventTime) { }

You will receive events TAP_TYPE_TOUCH when the user initially taps on the screen, TAP_TYPE_TAP when the user releases their finger, and TAP_TYPE_TOUCH_CANCEL if the user moves their finger while touching the screen. The events will contain (x,y) coordinates of where the touch event occurred. You should note that other interactions such as swipes and long presses are reserved for use by the Android Wear system user interface.

And that’s it! Adding interaction to your existing watch faces is really easy with just a few extra lines of code. We have updated the WatchFace sample to show a complete implementation, and design and development documentation describing the API in detail.

Wi-Fi added to LG G Watch R

This release also brings Wi-Fi support to the LG G Watch R. Wi-Fi support is already available in many Android Wear watches and allows the watch to communicate with the companion phone without requiring a direct Bluetooth connection. So, you can leave your phone at home, and as long as you have Wi-Fi, you can use your watch to receive notifications, send messages, make notes, or ask Google a question. As a developer, you should ensure that you use the Data API to abstract away your communications, so that your application will work on any kind of Android Wear watch, even those without Wi-Fi.

Updates to existing watches

This update to Android Wear will roll out via an over-the-air (OTA) update to all Android Wear watches over the coming weeks. The wearable support library version 1.3 provides the implementation for touch interactions, and is designed to continue working on devices which have not been updated. However, the touch support will only work on updated devices, so you should wait to update your apps on Google Play until the OTA rollout is complete, which we’ll announce on the Android Wear Developers Google+ community. If you want to release immediately but check if touch interactions are available, you can use this code snippet:

PackageInfo packageInfo = PackageManager.getPackageInfo("com.google.android.wearable.app", 0);
if (packageInfo.versionCode > 720000000) {
  // Supports taps - cache this result to avoid calling PackageManager again
} else {
  // Device does not support taps yet
}


Android Wear developers have created thousands of amazing apps for the platform and we can’t wait to see the interactive watch faces you build. If you’re looking for a little inspiration, or just a cool new watch face, check out the Interactive Watch Faces collection on Google Play.

Join the discussion on

+Android Developers


Android Developers Blog

Aug 30

Make the most of Notifications with the redesigned Wear OS by Google


Posted by Hoi Lam, Lead Developer Advocate, Wear OS by Google

Today we announced that we are evolving the design of Wear OS by Google to help you get the most out of your time – providing quicker access to your information and notifications. Notifications can come from the automatic bridging of the phone’s notification or be generated by a local Wear app running on the watch. Whether you are a phone developer, a Wear app developer, or both, there are a few things you will need to know about the new notification stream.

The new notification stream

Until now, each notification took up the entire screen in Wear OS. Although this provided more space to include things like inline action, it also meant it took a long time for the user to go through all their notifications. The new notification stream is more compact, and can display multiple notifications on the same screen. This means users can process their notification streams more quickly.

What this means for developers

  • Concise notification content is even more important. The new unexpanded notification on Wear will show up to three lines of text. Because this is already more information than a single line unexpanded notification on the user’s phone, if your notification works on the phone unexpanded, it should be fine on Wear.
  • Brand notification with color. The default title and icon color for notification is white. Developers can now convey their brand identities by customizing the color of the title and icon tint using setColor.
  • Custom notification layout will no longer be supported. Previously developers used setDisplayIntent to inflate a custom activity inside the notification stream. We have found that the custom layout often does not take into account of the device form factor, and is difficult to keep up to date as Wear OS’s notification experience evolves. As a result, we will no longer support this in notifications.
  • Inline action is being reviewed. To save space, the new layout no longer display inline action in the stream and setHintDisplayActionInline will be ignored. Users can continue to access notification actions including inline action when they tap to expand the notification. Our design team is reviewing whether we should include inline action in a future release. As a result, before a decision is made, we are not deprecating the related APIs. We will keep the developer community updated in due course.

As always, the current best practices for notification still apply. In particular, for messaging apps developers, we strongly encourage the use of MessagingStyle notification and enabling on-device Smart Reply through setAllowGeneratedReplies.

We will start rolling these changes out in the next month, so watch for updates on your Wear OS by Google smartwatch!


Android Developers Blog

Aug 23

Get a glimpse of Wear 2.0’s upcoming standalone apps

Kacey Fahey, Marketing Programs Manager, Google Play

The upcoming Android Wear 2.0 experience will introduce standalone apps, expanding your potential reach to both Android and iOS audiences with Wear devices. Users will be able to search, install, and use apps without ever leaving their device. See how other developers are enhancing their user experience with standalone apps for messaging, travel & local, and health & fitness.

Glide

Having a watch app further simplifies video messaging with Glide. Using the Wear Complications API, Glide is now able to live broadcast directly from the watch face. By tapping contact shortcuts from the watch face, you can now launch directly into a conversation. This experience brings speed and intimacy to the world of messaging, making wrist-based communication more accessible and effortless.

Foursquare

Travelers around the world use Foursquare’s Android Wear app to discover hidden gems and be in the know about the best places to eat, drink and explore. With their upcoming 2.0 app, the team has a clean new canvas for rich notifications giving users an immersive experience with Foursquare content.

“The standalone nature of the Android Wear 2.0 app will offer a big boost in search performance and app responsiveness so you spend less time staring at the screen and more time exploring the world around you,” said Kyle Fowler, Software Engineer at Foursquare.

Lifesum

Lifesum helps users make better food choices, improve their exercise, and reach health goals. The upcoming 2.0 experience complements the existing Lifesum mobile app and as a standalone app, it will allow users to more easily track water and meals throughout the day.

“It’s all about increasing access and being there for the user in a quick and simple way. We believe a simplified way of tracking meals and water will make it easier for our users on their journey of becoming healthier and happier,” said Joakim Hammer, Android Developer at Lifesum

Check out g.co/wearpreview for the latest builds and documentation about the recently released Android Wear Developer Preview 4.

How useful did you find this blogpost?


Android Developers Blog

Aug 18

Android Wear 2.0 for China – Developer Preview

Posted by Hoi Lam, Developer Advocate

Today at Google
Developer Day China, we are happy to announce a developer preview
of Android Wear 2.0 for developers creating apps for China. Android Wear 2.0 is
the biggest update since our partners launched their first devices in China last
year.

We’re making a Developer Preview available today and plan to release additional
updates in the coming months. Please send us your feedback by filing bugs or posting in our Android Wear
Developers community.

Developing for the Chinese Market

With Android Wear 2.0, apps can access the internet directly on Android Wear
devices. As a result, for the majority of apps, having a companion phone
application is no longer necessary. This means that most developers creating
apps for Android Wear 2.0 may no longer need to import the Google Play services
library.

There are two situations where developers will need to import Google Play
services for China:

  • Apps that require direct interaction with the paired mobile
    device
    – some experiences require Android Wear to connect directly to a
    paired phone. In this case, the Data
    Layer API introduced in Android Wear 1.0 will continue to function.

  • New FusedLocationProvider
    for China
    – we have added location detection to the SDK for Chinese
    developers. With the user’s permission, your app can receive location updates
    via the FusedLocationProvider.

You can find more details about how to import the China compatible version of
Google Play services library here.

Product testing for Android Wear 2.0 for China

The Android Wear 2.0 Developer Preview includes an updated SDK with tools, and
system images for testing using the Huawei Watch.

To get started, follow these steps:

  • Update to Android Studio v2.1.1 or later
  • Visit the Android Wear 2.0
    Developer Preview site for downloads and documentation

  • Download
    the device system images

  • Test your app with your supported device

Give us feedback

We will update this developer preview over the next few months based on your
feedback. The sooner we hear from you, the more we can include in the final
release, so don’t be shy!

Android Wear 2.0 中国版 – 开发者预览版

编辑: 林海泉, Android Wear 开发平台负责人

今天在上海举办的Google
开发者大会上,我们正式宣布了一款专门针对中国市场的Android Wear 2.0 开发者预览版。Android Wear
2.0系统,将是自我们的合作伙伴首次发布手表产品以来最重大的更新。

开发者预览版已于今日正式上线。与此同时,我们也计划在未来的几个月内持续进行更新。请您将您遇到的问题在此提交反馈,或者在我们的Android
Wear开发者论坛发表意见。

为中国市场开发应用

在Android Wear 2.0系统中,应用可以由Android
Wear手表直接连接至互联网。因此,对于大多数应用来说,手机端的伴侣应用也就变得不再必要。这也意味着,多数为Android Wear
2.0开发应用的开发者将不再需要引用Google Play services客户端库。

目前,在两个情况下开发者仍然需要引入Google Play Services客户端库来为中国市场开发应用:

  • 需要与手机直接进行通信的应用 – 有一些用例需要Android
    Wear手表与已配对手机直接连接。在这种情况下,Android Wear 1.0中引入的Data
    Layer API仍然可以继续使用。

  • 使用 FusedLocationProvider
    - 我们在最新的中国版SDK中加入了定位的支持。在用户的许可下,您的应用可以通过FusedLocationProvider来接收定位更新。

您可以在这里找到关于如何引入与中国版兼容的Google
Play service的更多信息。

Android Wear 2.0 中国版产品测试

Android Wear 2.0 开发者预览版包括最新的SDK套件,手表测试系统镜像(基于华为手表)。

情按照以下步骤进行测试:

  • 更新到Android Studio至v2.1.1以上版本
  • 访问 Android Wear
    2.0 开发者预览版,那里的文件下载与文档下载部分

  • 下载手表系统镜像
  • 在手表上测试您的应用

开发反馈

我们会根据您的反馈在未来的几个月中更新开发者预览版。您给我们的反馈越早,我们将会在最终的发布版本中包含更多针对您的反馈的解决方案。敬请期待!


Android Developers Blog

Aug 17

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

Posted by Hoi Lam, Developer
Advocate

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 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-dismiss 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!


Android Developers Blog

Aug 16

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

Posted by Hoi Lam, Developer
Advocate

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 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-dismiss 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!


Android Developers Blog

Aug 16

Updating Wear OS Google Play Store policy to increase app quality


Posted by Hoi Lam, Lead Developer Advocate, Wear OS by Google

Today we are announcing a new initiative to improve Wear app quality and their presentation in the Google Play Store. The Wear app review process, which has been in place since the launch of Android Wear 2.0, is currently optional. It will become mandatory for apps to be listed on the Wear OS by Google version of the Google Play Store from the following dates:

  • New Wear apps: 1 October 2018
  • Existing Wear apps: 4 March 2019.

The review process for mobile apps remains unchanged, and is independent of the Wear app review. Mobile app updates will not be blocked if they fail the Wear app review.

We hope this lightweight app review process will improve the quality of Wear app experiences across the wide range of devices available to your users. In addition, since screenshots are required for the Wear app review, this will improve the discovery and presentation of your Wear apps in the Google Play Store.

See a comprehensive list of review criteria here. The following are common issues we see during Wear app reviews:

  • Support for different screen types – Wear OS by Google is available in both round and square screens, and some round devices also have a chin. Developers are advised to test on all screen types. If a physical device is unavailable, please use the Wear OS by Google emulator.
  • Wear OS by Google app screenshot – To pass the review, the app needs to have at least one Wear OS app screenshot. To keep pre-release Wear apps private, the Google Play Store will not show the Wear screenshots unless the Wear App is in production or open testing. Currently, the Google Play Store only supports uploading one set of screenshots across all production and test versions. For existing Wear apps, we recommend developers keeping their production Wear app screenshots unchanged when uploading new open test or closed test Wear apps.

Opting out of app review for early prototypes

We understand that some developers need to experiment with their Wear apps in the early stages of app development, and a Wear app review at this stage might not be appropriate. In this case, developers have two options:

  • Manually deploy Wear APKs to their users, or
  • Leverage internal testing features via the Google Play console, which enables developers to test with up to 100 internal testing accounts.

Please note that the open test and closed test channels will be subject to Wear app review to help front-load the quality assurance process and to avoid leaving reviews to the last minute.

Thank you for your continuing support of Wear OS by Google.


Android Developers Blog

Jun 12

Wear OS developer preview reenabling alarms and jobs for background apps


Posted by Hoi Lam, Lead Developer Advocate, Wear OS by Google

From the outset of the Wear OS by Google developer preview, battery life has been a major focus area. When we talked to the developer community, the update that attracted the most feedback was the disabling of alarms and jobs for background apps. After listening to developer feedback and reviewing the battery statistics, we are reversing this change. This should be reflected in all connected Wear OS preview devices, so there is no need to reflash your device.

App Standby Buckets

The decision came as we reviewed the feedback and saw that a strict on/off setting prevents reasonable usage and promotes anti-patterns. Going forward, we plan to leverage the App Standby Buckets feature in Android P to fine-tune a suitable setting for Wear OS devices. The exact setting for alarms and jobs for background apps is still being iterated on. Developers are advised to follow the best practices to make sure their apps behave well, whichever bucket the apps are in.

Input and data privacy in background apps

Another area that developers should pay attention to is the strengthening of input and data privacy for background apps in Android P. Depending on an app’s requirements, developers may need to use a foreground service to enable access to the device sensor throughout the day.

Please give us your feedback

We expect to provide more updates to this preview before the final production release. Please submit any bugs you find via the Wear OS by Google issue tracker. The earlier you submit them, the higher the likelihood that we can include the fixes in the final release.


Android Developers Blog

Jun 09

Porting Your Android Wear Developer Preview Code to the Latest Support Library

Today’s post on #AndroidWear is from +Wayne Piekarski.

Now that the full Android Wear SDK is available, it’s time to port your existing wearable-enabled notification code from the Developer Preview. In the process, you’ll switch to using the latest Android support library, and there are some small API changes that will require you to update your code. This article will show you how to update my previous code samples that were released earlier for stacks and pages, which you can use to guide the conversion of your own code as well.

To get started with an existing project in Android Studio, you should update to the 0.8 or later release. You also need to make sure you’ve downloaded the Google Support Library version 20 or later from the SDK Manager. Since this is only a notification-based example, there’s no need to download the full Android Wear SDK, which is only needed if you want to create an APK to run on the wearable device.

Unix diff output is used to show the necessary changes in an easy to understand way. Do not copy the + or – symbols at the start of each line, and ignore the lines starting with @@ which are used to indicate the line number that changed. For the curious, I used the following command to generate the diff output from the last commit in my GIT repository (the -U1 shows one line of context to keep the output simple):

git show HEAD -U1

Gradle changes

To add the new support-v4 library, you need to edit your build.gradle file like so:

@@ -24,2 +24,3 @@ dependencies {
     compile 'com.android.support:appcompat-v7:19.+'
+    compile 'com.android.support:support-v4:20.0+'
 }

Make sure you remove the wearable-preview-support.jar that was provided with the Developer Preview from your libs directory and build.gradle file, since these features are now in the standard support library.

Package imports

Since the APIs and package names have changed, the import statements at the top of MainActivity.java need to be adjusted like this:

@@ -7,3 +7,2 @@ import android.view.MenuItem;
-import android.support.v4.app.NotificationCompat;
 import android.app.Notification;
@@ -13,4 +12,9 @@ import android.graphics.Bitmap;
 import android.graphics.BitmapFactory;
-import android.preview.support.v4.app.NotificationManagerCompat;
-import android.preview.support.wearable.notifications.WearableNotifications;
+import android.support.v4.app.NotificationCompat;
+import android.support.v4.app.NotificationManagerCompat;
+
+// Extra dependencies needed for the pages example
+import java.util.ArrayList;
+import java.util.List;
+import android.support.v4.app.NotificationCompat.BigTextStyle;

Stacking notifications

Since the preview SDK, we have simplified how notifications are implemented. The existing NotificationCompat.Builder() was extended to support groups directly, instead of a separate WearableNotifications class. The steps are a lot simpler, as can be seen with the following changes to showStackNotifications():

@@ -63,3 +67,3 @@ public class MainActivity extends ActionBarActivity {
         // Group notification that will be visible on the phone
-    NotificationCompat.Builder builderG = new NotificationCompat.Builder(this)
+    Notification summaryNotification = new NotificationCompat.Builder(this)
             .setContentTitle("2 Pet Notifications")
@@ -67,5 +71,5 @@ public class MainActivity extends ActionBarActivity {
             .setSmallIcon(R.drawable.ic_launcher)
-                .setLargeIcon(bitmapMila);
-    Notification summaryNotification = new WearableNotifications.Builder(builderG)
-            .setGroup(GROUP_KEY_MESSAGES, WearableNotifications.GROUP_ORDER_SUMMARY)
+                .setLargeIcon(bitmapMila)
+            .setGroup(GROUP_KEY_MESSAGES)
+            .setGroupSummary(true)
             .build();
@@ -76,3 +80,3 @@ public class MainActivity extends ActionBarActivity {
             PendingIntent.getActivity(this, notificationId+1, viewIntent1, 0);
-    NotificationCompat.Builder builder1 = new NotificationCompat.Builder(this)
+    Notification notification1 = new NotificationCompat.Builder(this)
             .addAction(R.drawable.ic_action_done, "Treat Fed", viewPendingIntent1)
@@ -81,4 +85,3 @@ public class MainActivity extends ActionBarActivity {
                     + "Can we have steak?")
-                .setSmallIcon(R.drawable.ic_launcher);
-    Notification notification1 = new WearableNotifications.Builder(builder1)
+            .setSmallIcon(R.drawable.ic_launcher)
             .setGroup(GROUP_KEY_MESSAGES)
@@ -89,3 +92,3 @@ public class MainActivity extends ActionBarActivity {
             PendingIntent.getActivity(this, notificationId+2, viewIntent2, 0);
-    NotificationCompat.Builder builder2 = new NotificationCompat.Builder(this)
+    Notification notification2 = new NotificationCompat.Builder(this)
             .addAction(R.drawable.ic_action_done, "Water Filled", viewPendingIntent2)
@@ -93,4 +96,3 @@ public class MainActivity extends ActionBarActivity {
             .setContentText("Can you refill our water bowl?")
-            .setSmallIcon(R.drawable.ic_launcher);
-        Notification notification2 = new WearableNotifications.Builder(builder2)
+            .setSmallIcon(R.drawable.ic_launcher)
             .setGroup(GROUP_KEY_MESSAGES)

Page notifications

Page notifications have also changed to use a WearableExtender() class instead of the WearableNotifications class, as can be seen here in showPageNotifications():

@@ -151,3 +153,3 @@ public class MainActivity extends ActionBarActivity {
             PendingIntent.getActivity(this, notificationId+1, viewIntent1, 0);
-    NotificationCompat.Builder builder1 = new NotificationCompat.Builder(this)
+    Notification notification1 = new NotificationCompat.Builder(this)
             .addAction(R.drawable.ic_action_done, "Returned", viewPendingIntent1)
@@ -155,5 +157,4 @@ public class MainActivity extends ActionBarActivity {
             .setContentText("You have " + numOverdue + " books due at the library")
-            .setSmallIcon(R.drawable.ic_launcher);
-    Notification notification1 = new WearableNotifications.Builder(builder1)
-            .addPages(extras)
+                .setSmallIcon(R.drawable.ic_launcher)
+            .extend(new NotificationCompat.WearableExtender().addPages(extras))
             .build();

Conclusion

If you want to download the final source code of showStackNotifications() and showPageNotifications(), you can download the MainActivity.java file. You can build this file easily by creating a new project in Android Studio, adding the support library, and then copying in this MainActivity.java.

As you can see, porting this previous code over to the latest Android Wear SDK is really easy! It should take you hardly any time at all to get your experimental applications ported over and ready for publishing on the Google Play!

Join the discussion on
+Android Developers


Android Developers Blog