Since Google Fit was released in 2015, apps with an abundance of features for health and fitness tracking have integrated with the Google Fit APIs. Over the years, the number of users using Google Fit as a central repository for their fitness and wellness data has grown significantly.
With Android 10, we're making further updates to give users even more control over this personal data. One key change concerns how Android apps can monitor a user’s physical activity and retrieve data from Android sensor APIs and the Google Fit platform.
In Android 10: Activity recognition permission
Android 10 introduces a new runtime permission for activity recognition for apps that make use of the user's step and calorie count or classify the user's physical activity, such as walking, biking, or moving in a vehicle through one of the following APIs:
If your app relies only on raw data from other built-in sensors on the device, such as the accelerometer and gyroscope, you don't need to declare this new permission in your app.
Activity Recognition Permission Enforcement
Google Fit physical activity APIs
This new permission affects a subset of data types available in the Google Fit APIs on Android. If your app accesses these types from Google Fit today, then you need to update your app inline with the new permissions.
The activity recognition runtime permission is required for accessing the following APIs / data types:
With Android 10 now launched and SDK 29 becoming your primary development target, now is the time to make sure your apps are compatible with the new runtime permission.
ComplicationDrawable
WatchFaceStyle.setAccentColor
WatchFaceStyle.setHideNotificationIndicator
WatchFaceStyle.setShowUnreadCountIndicator,
WatchFaceStyle.getUnreadCount
TYPE_NO_PERMISSION
onTap
Drawable.Callback
Today, we are launching the beta of the next Android Wear update. As we mentioned at Google I/O, this will mainly be a technical upgrade to API 26 with enhancements to background limits and notification channels. LG Watch Sport users can go to this webpage to sign up and the factory image will automatically be downloaded to the watch you enroll. As this is a beta, please be sure to review the known issues before enrolling. If you don't have a watch to test on, you can use the Android emulator. For developers working with Android Wear for China, an updated emulator image is also available.
In this update, users can choose the types of notifications they receive via an app through notification channels. This gives users finer-grained control than muting all notifications from the app. For notifications generated locally by Android Wear apps, users will be able to customise the notifications channel they want to see, right on their watch. Please refer to the Wear notification sample for more details. For notifications bridged from the phone, the phone notifications channel settings will dictate what is shown on the watch.
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { mNotificationManager.createNotificationChannel( NotificationChannel("1001", "New Follower", NotificationManager.IMPORTANCE_DEFAULT)) mNotificationManager.createNotificationChannel( NotificationChannel("1002", "Likes", NotificationManager.IMPORTANCE_LOW)) }
There are increased restrictions on background services. Developers should assume services can no longer run in the background without a visible notification. In addition, the background location update frequency will be reduced. Battery-saving best practices such as using JobScheduler should be adopted to ensure your app is battery-efficient and able to perform background tasks when possible.
We expect this to be the only beta release before the final production release. Thank you for your feedback so far. Please submit any bugs you find via the Android Wear issue tracker. The earlier you submit them, the higher the likelihood that we can include the fixes in the final release.
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.
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 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.
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.
PlayStoreAvailability
RemoteIntent
// 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); }
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:
SwipeDismissFrameLayout
Additional details are available under the behavior changes section of the Android Wear Preview site.
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.
setShouldPeekOnScrollDown
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!
Posted by Hoi Lam, Android Wear Developer Advocate
At Google I/O 2016, we launched the Android Wear 2.0 Developer Preview, which gives developers early access to the next major release of Android Wear. Since I/O, feedback from the developer community has helped us identify bugs and shape our product direction. Thank you!
Today, we are releasing the second developer preview with new functionalities and bug fixes. Prior to the consumer release, we plan to release additional updates, so please send us your feedback early and often. Please keep in mind that this preview is a work in progress, and is not yet intended for daily use.
compileSdkVersion
targetSdkVersion
WearableActionDrawer
peek_view
drawer_content
WearableDrawerView
notifyDataSetChanged
public class MainActivity extends Activity { ... @Override /* KeyEvent.Callback */ public boolean onKeyDown(int keyCode, KeyEvent event) { switch (keyCode) { case KeyEvent.KEYCODE_NAVIGATE_NEXT: Log.d(TAG, "Next"); break; case KeyEvent.KEYCODE_NAVIGATE_PREVIOUS: Log.d(TAG, "Previous"); break; } // If you did not handle, then let it be handled by the next possible element as deemed by // Activity. return super.onKeyDown(keyCode, event); } }
The Android Wear 2.0 Developer Preview includes an updated SDK with tools and system images for testing on the official Android emulator, the LG Watch Urbane 2nd Edition LTE, and the Huawei Watch.
To get started, follow these steps:
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!
Posted by Wayne Piekarski, Developer Advocate
A new update to Android Wear is rolling out with lots of new features like always-on apps, Wi-Fi connectivity, media browsing, emoji input, and more. Let’s discuss some of the great new capabilities that are available in this release.
Above all, a watch should make it easy to tell the time. That's why most Android Wear watches have always-on displays, so you can see the time without having to shake your wrist or lift your arm to wake up the display. In this release, we're making it possible for apps to be always-on as well.
With always-on functionality, your app can display dynamic data on the device, even when the app is in ambient mode. This is useful if your app displays information that is continuously updated. For example, running apps like Endomondo, MapMyRun, and Runtastic use the always-on screen to let you keep track of how long and far you’ve been running. Zillow keeps you posted about the median price of homes nearby when you’re house-hunting.
Always-on functionality is also useful for apps that may not update data very frequently, but present information that’s useful for reference over a longer period of time. For example, Bring! lets you keep your shopping list right on your wrist, and Golfshot gives you accurate distances from tee to pin. If you’re at the airport and making your way to your gate, American Airlines, Delta, and KLM let you keep all of your flight info a glance away on your watch.
Note: the above apps will not display always-on functionality on your watch until you receive the update for the latest version of Android Wear.
Always-on functionality works similar to watch faces, in that the power usage of the display and processor is kept to a minimum by reducing the colors and refresh rate of the display. To implement an always-on Activity, you need to make a few small changes to your app's AndroidManifest.xml, your app’s build.gradle, and the Activity to declare that it supports ambient mode. A code sample and documentation are available to show you how it works. Be sure to tune in to the livestream at Google I/O next week for Android Wear: Your app and the always-on screen.
Many existing Android Wear devices already contain hardware support for Wi-Fi, and this release enables software support for Wi-Fi. The saved Wi-Fi networks on your phone are copied to your watch during setup, and your watch automatically connects to those Wi-Fi networks when it loses Bluetooth connection to your phone. Your watch can then connect to your phone over the Internet, even if they’re not on the same Wi-Fi network.
You should continue to use the Data Layer API for all communications between the watch and phone. By using this standard API, your app will always work, no matter what kind of connectivity the user’s wearable supports. Cloud sync also introduces a new virtual node in the Data Layer called the cloud node, which may be returned in calls to getConnectedNodes(). Learn more in the Multi-wearable support section below.
The release of Google Play services 7.3 now allows support for multiple wearable devices to be paired simultaneously to a single phone or tablet, so you can have a wearable for fitness, and another for dressing up. While DataItems will continue to work in the same way, since they are synchronized to all devices, working with the MessageApi is a little different. When you update your build.gradle to use version 7.3 or higher, getConnectedNodes() from the NodeApi will usually return multiple nodes. There is an extra virtual node added to represent the cloud node used to communicate over Wi-Fi, so all developers need to deal with this situation in their code.
To help simplify finding the right node among many devices, we have added a CapabilityApi, allowing your nodes to announce features they provide, for example downloading images or music. You can also now use the ChannelApi to open up a connection to a specific device to transfer large resources such as images or audio streams, without having to send them to all devices like you would when embedding assets into data items. We have updated our Android Wear samples and documentation to show the best practices in implementing this.
The Android 5.0 release added the ability for apps to browse the media content of another app, via the android.media.browse API. With the latest Android Wear update, if your media playback app supports this API, then you will be able to browse to find the next song directly from your watch. This is the same browse capability used in Android Auto. You implement the API once, and it will work across a variety of platforms. To do so, you just need to allow Android Wear to browse your app in the onGetRoot() method validator. You can also add custom actions to the MediaSession that will appear as controls on the watch. We have a Universal Media Player sample that shows you how to implement this functionality.
The latest version of Android Wear will roll out via an over-the-air (OTA) update to all Android Wear watches over the coming weeks. To take advantage of these new features, you will need to use targetSdkVersion 22 and add the necessary dependencies for always-on support. We have also expanded the collection of emulators available via the SDK Manager, to simulate the experience on all the currently available devices, resolutions, and shapes, including insets like the Moto 360.
In this update, we have also disabled support for apps that use the unofficial, activity-based approach for displaying watch faces, as announced in December. These watch faces will no longer work and should be updated to use the new watch face API.
Since the launch of Android Wear last summer, Android Wear has grown into a platform that gives users many possibilities to personalize their watches, with a variety of shapes and styles, a range of watch bands, and thousands of apps and watch faces. Features such as always-on apps and Wi-Fi allow developers even more flexibility to give users amazing experiences with Android Wear.
Posted by Timothy Jordan, Developer Advocate
With so many recent updates and improvements to Android Wear, it's high time to share an updated overview of the platform. We're certainly not done—there's a lot more to come—but this is the picture today as you start or continue developing your groundbreaking Android Wear user experiences.
Guns'n'Glory Heros and Strava
The Android Wear platform emphasizes depth and flexibility. Built on Android, it allows developers to use familiar APIs to create useful, performant, and imaginative apps that run directly on the watch. In the spirit of Android, you have the freedom to make substantial changes to the user experience, including the creation of custom watch faces. There are three main categories of experiences you can build: apps, custom watch faces, and notifications.
Apps that are built for Android Wear run directly on the watch and can do nearly anything a phone can, from tracking your run to giving you a little entertainment while waiting for the bus. Some even work without a connection to the phone, such as fitness and music apps. There are libraries to help you move data between the phone and the wearable, as well as create stunning and adaptable UIs. Here's a list of some of the great features you have access to:
Selected watch faces
The ability to create custom watch faces gives you direct access to the most prominent UI element on a user's most personal device. The API is simple enough to build watch faces quickly and flexible enough to allow personalization. Again, given the depth and flexibility of the Android platform, you can create something for the user that's both beautiful and packed with unique features.
The development journey starts with the simplicity of bringing your design to the wrist. At the core of the watch face API is the onDraw method that allows you to draw whatever design you can think of to the canvas at a high enough frame rate to deliver fluid animation. This will come through at full fidelity while the watch is in interactive mode.
At other times, when the watch is in ambient mode, you're able to draw a more discreet version of the watch face. Additional preferences can be set to arrange the system UI elements appropriately for your design. Once those basics are covered, the limits are your imagination! You can go further with additions like the moon phase, current weather, or fitness stats. Watchmakers call these items "complications" -- but with Android they're hardly complicated. Once you have the data, just draw it on the canvas as you did the time.
Glympse and WhatsApp
Of course, Android Wear Notifications are the easiest way to get started in the world of wearables. If you've got an Android app with notifications -- they already work on a Wear watch. If you've already enhanced your notification with actions, this is even better and also automatically already works. You can take things further with Wear-specific functionality like Stacks, Pages, and Voice Replies that make your notifications richer experiences on the wrist.
The user experiences you build for Wear get to take advantage of the power and flexibility of the Android platform. It's easy to get started and possible to create truly groundbreaking UI for your users. Together, we can create an ecosystem of user experiences as diverse as the watches they run on and the people who wear them.
Check out the developer videos and documentation for more, and share your thoughts on the Android Wear Developers community. We can’t wait to see the innovative user experiences you will build on Android Wear.
By Wayne Piekarski, Developer Advocate
With the latest release of Android Wear, wearables with built-in GPS like the Sony Smartwatch 3 can now give you a GPS location update directly from the wearable, without a paired phone nearby. You can now build an app like MyTracks that lets a user track their run even when they leave their phone at home. For wearable devices that do not have built-in GPS, a software solution has always existed in Google Play Services that automatically uses the GPS from your connected phone.
The Golfshot wearable app uses built-in GPS to calculate your distance to the next hole, even when you don’t have your phone with you.
Implementing GPS location updates for Android Wear is simple. On the wearable, use the FusedLocationProviderApi from Google Play services to request location updates. This is the same API that has been available on mobile, so you can easily reuse your existing code and samples.
FusedLocationProviderApi
FusedLocationProviderApi automatically makes the most power-efficient decision about where to get location updates. If the phone is connected to the wearable, it uses the GPS on the phone and sends the updates to the wearable. If the phone is not connected to the wearable and the wearable has a built-in GPS, then it uses the wearable’s GPS.
One case you’ll need to handle is if the phone is not connected to the wearable and the wearable does not have built-in GPS. You will need to detect this and provide a graceful recovery mechanism, such as a message telling the user to bring their phone with them. However, for the most part, deciding which GPS to use, and sending the position from the phone to the wearable, is handled automatically. You do not need to deal with the low-level implementation details yourself.
When writing an app that runs on the wearable, you will eventually want to synchronize the data it collects with the paired phone. When the wearable is being taken out for a run, especially with the built-in GPS, there may not be a phone present. So you will want to store your location data using the Data Layer API, and when the phone reconnects with the wearable later, the data will be automatically synchronized.
For more details about how to use the location API, check out the extensive documentation and sample here.
Also, as a heads up, starting on November 3 with the public release of Android 5.0, you will be able to submit your apps for clearer designation as Android Wear apps on Google Play. If your apps follow the criteria in the Wear App Quality checklist and are accepted as Wear apps on Play, it will be easier for Android Wear users to discover your apps. Stay tuned for more information about how to submit your apps for Android Wear review through the Google Play Developer Console.
By Hoi Lam, Developer Advocate, Android Wear
The best cooking companion since the apron?
Android Wear is designed for serving up useful information at just the right time and in the right place. A neat example of this is Allthecooks Recipes. It gives you the right recipe, right when you need it.
This app is a great illustration of the four creative visions for Android Wear:
Allthecooks also shows what developers can do by combining both the power of the mobile device and the convenience of Android Wear.
One particularly well-designed aspect of Allthecooks is their approach to the multi-device experience. Allthecooks lets the user search and browse the different recipes on their Android phone or tablet. When the user is ready, there is a clearly labelled blue action link to send the recipe to the watch.
The integration is natural. Using the on-screen keyboard and the larger screen real estate, Allthecooks is using the best screen to browse through the recipes. On the wearables side, the recipe is synchronised by using the DataApi and is launched automatically, fulfilling one of the key creative visions for Android Wear.
The end result? The mobile / Wear integration is seamless.
Once the recipe has been sent to the Android Wear device, Allthecooks splits the steps into easily glanceable pages. At the end of that list of steps, it allows the user to jump back to the beginning with a clearly marked button.
This means if you would like to browse through the steps before starting to cook, you can effortlessly get to the beginning again without swiping through all the pages. This is a great example of two other points in the vision: glanceable and zero or low interaction.
One of the key ingredients of great cooking is timing, and Allthecooks is always on hand to do all the inputs for you when you are ready to start the clock. A simple tap on the blue “1” and Allthecooks will automatically set the timer to one hour. It is a gentle suggestion that Allthecooks can set the timer for you if you want.
Alternatively, if you want to use your egg timer, why not? It is a small detail but it really demonstrates the last and final element of Android Wear’s vision of suggest and demand. It is an ever ready assistant when the user wants it. At the same time, it is respectful and does not force the user to go down a route that the user does not want.
Great design is about being user-centric and paying attention to details. Allthecooks could have just shrunk their mobile app for wear. Instead the Allthecooks team put a lot of thoughts into the design and leveraged all four points of the Android Wear creative vision. The end result is that the user can get the best experience out of both their Android mobile device and their Android Wear device. So developers, what will you be cooking next on Android Wear?
For more inspiring Android Wear user experiences, check out the Android Wear collection on Google Play!
Notification notification1 = new WearableNotifications.Builder(builder1) .addPages(extras) .build();
// Nuke all previous notifications and generate unique ids NotificationManagerCompat.from(this).cancelAll(); int notificationId = 0; // Titles, authors, and overdue status of some books to display String[] titles = { "How to survive with no food", "Sailing around the world", "Navigation on the high seas", "Avoiding sea monsters", "Salt water distillation", "Sail boat maintenance" }; String[] authors = { "I. M. Hungry", "F. Magellan", "E. Shackleton", "K. Kracken", "U. R. Thirsty", "J. Macgyver" }; Boolean[] overdue = { true, true, true, true, true, false }; List extras = new ArrayList(); // Extra pages of information for the notification that will // only appear on the wearable int numOverdue = 0; for (int i = 0; i < titles.length; i++) { if (!overdue[i]) continue; BigTextStyle extraPageStyle = new NotificationCompat.BigTextStyle(); extraPageStyle.setBigContentTitle("Overdue Book " + (i+1)) .bigText("Title: " + titles[i] + ", Author: " + authors[i]); Notification extraPageNotification = new NotificationCompat.Builder(this) .setStyle(extraPageStyle) .build(); extras.add(extraPageNotification); numOverdue++; } // Main notification that will appear on the phone handset and the wearable Intent viewIntent1 = new Intent(this, MainActivity.class); PendingIntent viewPendingIntent1 = PendingIntent.getActivity(this, notificationId+1, viewIntent1, 0); NotificationCompat.Builder builder1 = new NotificationCompat.Builder(this) .addAction(R.drawable.ic_action_done, "Returned", viewPendingIntent1) .setContentTitle("Books Overdue") .setContentText("You have " + numOverdue + " books due at the library") .setSmallIcon(R.drawable.ic_launcher); Notification notification1 = new WearableNotifications.Builder(builder1) .addPages(extras) .build(); // Issue the notification NotificationManagerCompat notificationManager = NotificationManagerCompat.from(this); notificationManager.notify(notificationId+1, notification1);
import android.support.v4.app.NotificationCompat; import android.app.Notification; import android.app.PendingIntent; import android.content.Intent; import android.graphics.Bitmap; import android.graphics.BitmapFactory; import android.preview.support.v4.app.NotificationManagerCompat; import android.preview.support.wearable.notifications.WearableNotifications;
res/drawable-xxhdpi/ic_action_done.png
Today’s post on #AndroidWear is from +Wayne Piekarski.
Stacking notifications with the Android Wear Developer Preview is really simple—it requires only a few lines of extra notification code:
Notification wearableNotification = new WearableNotifications.Builder( notificationCompatBuilder) .setGroup(“messages”) .build();
A few weeks ago, I published a new DevBytes video which covered how to implement stacking notifications with Android Wear:
In the video, I included a demonstration of what these notifications look like in the emulator, and thought it would be useful to share the code for the demo. If you’re just getting started with stacked notifications, this should be all you need to get up and running right away. So here it is, with some additional instructions below. The wearable-specific code is highlighted and in bold.
Bitmap bitmapMila = BitmapFactory.decodeResource(getResources(), R.drawable.mila128); // Nuke all previous notifications and generate unique ids NotificationManagerCompat.from(this).cancelAll(); int notificationId = 0; // String to represent the group all the notifications will be a part of final String GROUP_KEY_MESSAGES = "group_key_messages"; // Group notification that will be visible on the phone NotificationCompat.Builder builderG = new NotificationCompat.Builder(this) .setContentTitle("2 Pet Notifications") .setContentText("Mila and Dylan both sent messages") .setSmallIcon(R.drawable.ic_launcher) .setLargeIcon(bitmapMila); Notification summaryNotification = new WearableNotifications.Builder(builderG) .setGroup(GROUP_KEY_MESSAGES, WearableNotifications.GROUP_ORDER_SUMMARY) .build(); // Separate notifications that will be visible on the watch Intent viewIntent1 = new Intent(this, MainActivity.class); PendingIntent viewPendingIntent1 = PendingIntent.getActivity(this, notificationId+1, viewIntent1, 0); NotificationCompat.Builder builder1 = new NotificationCompat.Builder(this) .addAction(R.drawable.ic_action_done, "Treat Fed", viewPendingIntent1) .setContentTitle("Message from Mila") .setContentText("What's for dinner? " + "Can we have steak?") .setSmallIcon(R.drawable.ic_launcher); Notification notification1 = new WearableNotifications.Builder(builder1) .setGroup(GROUP_KEY_MESSAGES) .build(); Intent viewIntent2 = new Intent(this, MainActivity.class); PendingIntent viewPendingIntent2 = PendingIntent.getActivity(this, notificationId+2, viewIntent2, 0); NotificationCompat.Builder builder2 = new NotificationCompat.Builder(this) .addAction(R.drawable.ic_action_done, "Water Filled", viewPendingIntent2) .setContentTitle("Message from Dylan") .setContentText("Can you refill our water bowl?") .setSmallIcon(R.drawable.ic_launcher); Notification notification2 = new WearableNotifications.Builder(builder2) .setGroup(GROUP_KEY_MESSAGES) .build(); // Issue the group notification NotificationManagerCompat notificationManager = NotificationManagerCompat.from(this); notificationManager.notify(notificationId+0, summaryNotification); // Issue the separate wear notifications notificationManager.notify(notificationId+2, notification2); notificationManager.notify(notificationId+1, notification1);
Using the code is really simple:
showTheNotifications()
onCreate
res/drawable-nodpi/mila128.jpg
And that’s basically it, it’s really simple! Once you have a good feel for how the code works, make sure to check out the stacking notifications documentation to learn more. Make sure to also familiarize yourself with the Android Wear Design Principles, which explain more about the types of icons that should be used for actions. For the picture of the dog, it’s important you use an image that is quite small, and not straight from a digital camera, since there are limits to the size of the images that can be handled by the API.
I hope this post is useful in helping you to get started with Android Wear notifications!
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
