Sign-in

Play Games Services sign-in provides you with a player's gaming identity, which is a platform-level, gaming-specific identity for Android players. This identity helps build a relationship between your game and the player. Players are more willing to use this identity to sign in than with alternate centralized systems.

In addition, sign-in gives you a strong, consistent identifier that you can use as a key to a cloud save system. Cloud save is highly-valued; it enables players to do the following:

Pick up where they left off if they change or reset their device
Play the game on multiple devices (for example, on another phone or a Chromebook)
Uninstall and later re-install the game

You can use Play Games Services identity as a key for your own cloud save solution, or you can use the free Saved Games service.

Play Games Services (PGS) supports automatic sign-in, a zero-friction way to sign in players, as well as manual sign-in, which is a one-click process. This document describes these different methods of sign-in.

In order to successfully sign players into your game, use the following sign-in flow:

During the startup sequence of your game, try Automatic sign-in to automatically sign the player in.
If automatic sign-in does not work and the user's device is online, try Manual sign-in.
If manual sign-in is declined, remember the user's choice and do not show manual sign-in again, but continue to try Automatic sign-in on startup.

Additionally, you should ensure that users are able to sign into your game with their Play Games services account with a dedicated, easy-to-find button.

Automatic sign-in allows users to sign into your game with zero friction - it's automatic! If your game requests that the user sign in and the automatic sign-in setting is enabled (in the Google Play Games app), then you will receive the user's PGS identity credentials and the user will see the PGS sign-in experience.

Automatic sign-in is a setting users can control. Users can choose to automatically sign into all games or be asked each time.

Automatic sign-in

If a user doesn't automatically sign into the game, you can ask them to sign in manually. Users can sign in with one click from a dialogue box displayed on top of your game.

Manual sign-in

Allow PGS popups for the correct sign-in experience

When using PGS, users need to know they are signed in. This is done by showing the PGS sign-in experience.

To show the sign-in experience, call the setViewForPopups() method of the GamesClient class during game startup. This is critical to enable the correct user experience.

OAuth Scopes and PGS

PGS relies on the OAuth system to allow users to give your game access to their account. OAuth Scopes are permissions that you as a developer can request. If granted, these permissions let your game call certain APIs on behalf of the user and also give you access to certain parts of their Google account.

PGS has a unique scope for games (games-lite) and relies on another scope (drive.appdata) if your game uses the saved games feature. The saved games feature gives access to the user's Google Drive account, which is where the game data is stored.

Your game can request any scope that you need to create a great game experience for your users. Your game can request all of the scopes it needs in one bundle, limiting the number of requests for Google account access. However, this approach has a major drawback. If you request more than the PGS-specific scopes, automatic sign-in cannot succeed. Automatic sign-in is the best way to get players signed into your game.

Best practice is to use incremental scope requests. Your game should ask for PGS-only scopes first in the initial request, and request other scopes separately at a more relevant moment.

OAuth access is granted using a different screen for each scope. This allows users to decide, in a granular way, which scopes to give access to. By using automatic sign-in with only PGS scopes, users will not have to interact with any OAuth prompts, reducing sign-in friction.

PGS provides a gaming identity for Android players, but it doesn't need to be the only identity connected to your users. You can sign in players using PGS, a social network ID, and your own in-game ID system all at the same time. Each system provides unique value for both you and your players, and all can work together to make a great experience for Android players.

Securely retrieve and verify the player identity for backend integration

You can request a Server Auth code to enable your server to talk directly to the Play Games Services servers via the REST API with the authority of the signed-in player. This enables direct access to the player's ID, profile, and other information (such as friends list, if authorized). If you store any Player IDs, friend IDs, or other related data in your backend, this method must be used to remove the potential for device-side manipulation of these fields.

Additionally, for some older games and players, the player ID returned by the Android SDK for a player may not be the same ID that other players see when viewing that player in the same game - this is particularly relevant when using the friends list. However, the player_id returned within the REST API is always consistent and is always the ID that is seen by other players.

For more information, see Offline access and the REST API documentation.

Client implementation

To learn how to implement sign-in support on Android, see Sign-in in Android Games.