Posted by Laurence Moroney, Developer Advocate
We’re delighted to announce the availability of Google Play services 8.3. There’s a lot of new information to share with you about what’s available to you in this release.
A big part of this release is focused on user identity. We’ve revamped the Sign In with Google APIs to make implementation simpler and provide users a streamlined experience. First off, the new Google Sign-In no longer requires the device accounts permissions, a big win when you start to develop for Marshmallow. The API also supports the latest Google branding. When using Google Play services 8.3, you’ll find a SignInButton that looks like this with the default scopes:
Previously, users would have to touch a sign in button, and then follow several steps (i.e. selecting account, giving permission to access profile information, and possibly needing to create a Google+ account). With Google Play services 8.3, only one tap is needed for basic profile access.
You can check out the documentation for the new API here.
And to make signing in easier across devices, whether you use Google Sign-In or still have password-based authentication, the Smart Lock APIs received some important updates. We’ve added a new API method to show a dialog that helps your user select a previously-used email address to pre-fill sign in or up forms easily: check out getHintPicker (sample code). This doesn’t require any device permissions and provides an alternative to a picker you may have previously populated from accounts on the device, which would now require a runtime permission with Marshmallow.
You can use this hint information to populate an entire sign-up form with name, email address, and profile picture with one tap, or even direct the user into a sign-in or sign-up flow intelligently based on their email address. Better yet, if the entry the user picked matches an account on the device, Google can provide a verified email address in the hint, which you can use to skip email verification and authenticate the user if your system can support ID tokens, similar to Google Sign-In.
For determining location, Google Play services provides a Fused Location Provider (FLP) which abstracts the underlying location sensors, such as GPS, WiFi, and the cell radio signal, into a single easy-to-use API. We’ve made some improvements to the FLP when it comes to batching. Prior to version 8.3, the batch location APIs would allow the FLP to save power by consolidating network traffic, but when an app removed a batching location request, the batch would be cleared. You may not want this behavior, so we’ve added an API that can return any batched locations immediately. Check the flushLocations and removeLocationUpdates method calls on the FusedLocationProviderApi for more details.
App Invites is a technology that enables your users to share your app with people they know. If you build using App Invites, Google Play services 8.3 has an update that will make coding much simpler. Now, you can use the AppInvite.AppInviteApi.getInvitation() method. This will set up a ResultCallback that you can use to launch your deep link activity, drastically simplifying your code.
The Play game services Player Stats API also gets an update. The latest version now includes a new signal for the probability that a player is about to churn. Developers can use this signal to offer special promotions to improve retention. For example, a developer could provide a discount on a power-up for players that are at risk of churning.
Finally, if you are developing for wearables, you’ll know that battery life and optimization of power usage are critical in having a great user experience. With Google Play services 8.3, we’ve updated the DataApi to allow for urgency in how data items are synced. Now, a priority can be added to the data item to determine when it should be synced. For example, if you are building an app that requires immediate syncing, such as a remote control app, it can still be done immediately by calling setUrgent(), but for something such as updating your contacts, you could tolerate some delay. Non-urgent DataItems may be delayed for up to 30 minutes, but you can expect that in most cases they will be delivered within a few minutes. Low priority is now the default, so setUrgent() is needed to obtain the previous timing.
Filter support has been added to listeners in the Android Wear API, allowing listeners to only receive a subset of changes on both phones and watches. Listeners registered in the Android manifest should be filtered to only receive events that require launching the process, with the remaining events being delivered to live listeners added via methods such as addListener(). This reduces the need for listeners to filter out uninteresting events, making applications and the system more efficient.
That’s it for this release of Google Play services. To learn more, visit the Google Developers site.