Using the Play Games player ID for other Google APIs that are not games

Issue: You will not get valid data back from these other endpoints.

Solution: Don’t use player ID for other Google APIs.

Using mobile/client access tokens on the server

Issue: Your access token may not contain the information you’re looking for

...and this is not recommended in the first place.

Solution: Use the new GetServerAuthCode API instead.

Let’s cover each of these issues in detail.

Issue: Asking for unnecessary scopes

Early versions of our samples and documentation created a GoogleApiClient as follows:

// Don’t do it this way!
GoogleApiClient gac = new GoogleApiClient.Builder(this, this, this)
.addApi(Games.API)
.addScope(Plus.SCOPE_PLUS_LOGIN) // The bad part
.build();
// Don’t do it this way!

In this case, the developer is specifically requesting the plus.login scope. If you ask for plus.login, your users will get a consent dialog.

Solution: Ask only for the scopes you need

Remove any unneeded scopes from your GoogleApiClient construction along with any APIs you no longer use.

// This way you won’t get a consent screen
GoogleApiClient gac = new GoogleApiClient.Builder(this, this, this)
.addApi(Games.API)
.build();
// This way you won’t get a consent screen

For Google+ users

If your app uses specific Google+ features, such as requiring access to the player’s real-world Google+ social graph, be aware that new users will still be required to have a G+ profile to use your game. (Existing users who have already signed in won’t be asked to re-consent).

To require Google+ accounts to use your game, change your Games.API declaration to the following:

This is not recommended in the first place, and is even more not-recommended after the shift in scopes.

Reasons not to do this:

It requires your app to know the current account the user is using, which requires holding the GET_ACCOUNTS permission. On Android M, this will result in the user being asked to share their contacts with your app at runtime, which can be intimidating.

The tokeninfo endpoint isn’t really designed for this use case - it’s primarily designed as a debugging tool, not as a production API. This means that you may be rate limited in the future if you call this API.

The user_id returned by token info may no longer be present with the new model. And even if it is present, the value won’t be the same as the new player ID. (See problem 2 above)

The token could expire at any time (access token expiration times are not a guarantee).

Using client tokens on the server require extra validation checks to make sure the token is not granted to a different application.