Google began rolling out v8.3 of the Play services framework a few weeks ago, and it looks like it's in a wide release. While this version didn't present with any direct user-facing features and only a few cryptic hints for a teardown, it did bring some definite improvements to the Play services SDK. There are some changes to streamline the sign-in experience for app developers and users alike, along with some additional enhancements that should make it easier for developers to set up new user accounts. New APIs have also been added to make data delivery more efficient between a phone and an Android Wear watch. There are some worthwhile improvements to the Fused Location Provider, App Invites API, and Player Stats API. For a quick overview, check out Magnus Hyttsten's latest video.
Using Google's sign-in features hasn't been exceptionally difficult for either users or developers, at least, not lately. That doesn't mean they can't get better. Play services v8.3 adds a new sign-in process that allows apps to display a single dialog box with a list of Google accounts on the device. When a user picks an account, it automatically grants basic profile access.
One of the best parts about this is that the new API doesn't require a standard Android permission for account access, especially since that now requires a separate runtime permission in Marshmallow (API 23).
The API has also been restructured so sign-in steps are decoupled from the rest of the Play services scopes, which should simplify things a bit for developers.
It's also worth mentioning that all of the images have been updated to the new Google logo, including the newly updated sign-in buttons.
Auto-Fill and Sign Up
The sign-in improvements bring another interesting set of capabilities to simplify account creation in an app or service. When users pick an account to sign up with, developers can immediately pull up details to begin creating an account, including: name, email address, and profile photo. This way users don't have to take the time to enter details that could be pre-populated for them.
Additionally, if a user enters an email address that matches an account on the device, Google automatically confirms the authenticity of it so the app developer won't have to perform an email verification step – you know, when you sign up and get an email a minute later asking you to click a link to prove the account is really yours.
Urgency For Wearable Data
In the interests of performance and battery efficiency, the Data API for syncing with a wearable device now supports a new setting for priority. When data absolutely has to reach the wearable immediately, it can be marked with a call to setUrgent. This will ensure that immediately relevant information cuts in line ahead of less important content.
One thing to note, both for users and developers, is that much of the synced data will now travel as low priority. Google's blog post notes that data should be delivered within just a few minutes, but it could take as much as 30 minutes. It's possible that this could occasionally result in some slow response times, at least until developers update their apps to prioritize their traffic accordingly. Clarification: As Ian Lake points out, this will only occur with apps that target Play Services SDK 8.3. Any app targeting an older version will maintain the current behavior.
There are also a few other improvements worth mentioning:
- Fused Location Provider has been updated with a pair of new API calls that make it possible to get batched locations even after a request has been removed.
- App Invites now have a getInvitation method that will set up a callback that streamlines launching a deep link activity.
- Player Stats API offers a new signal with a probability that a player might soon abandon a game, never to return. This will give developers an opportunity to offer discounted or free incentives to keep players around a bit longer or to help them through tough points in a game.
- Also for wearables, Data API Listeners can now support filters. This enables developers to limit the types of changes that have to be processed by phones and watches, and should ultimately cut down on how much apps have to handle.
- Android Developers Blog