Following the deprecation of the
[Google Sign-In](https://android-developers.googleblog.com/2024/09/streamlining-android-authentication-credential-manager-replaces-legacy-apis.html)
API, we are removing the games v1 SDK in 2026. After February 2025, you will be unable to publish
titles that are newly integrated with games v1 SDK, on Google Play. We recommend that you use the
games v2 SDK instead.  

While existing titles with the previous games v1 integrations continue to function for a
couple of years, you are encouraged to
[migrate to v2](https://developer.android.com/games/pgs/android/migrate-to-v2)
starting June 2025.  

This guide is for using the Play Games Services v1 SDK. For information
on the latest SDK version, see the
[v2 documentation](https://developer.android.com/games/pgs/signin).

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](https://developer.android.com/games/pgs/savedgames).

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.
| **Note:** You can implement sign-in without implementing any other Play Games Services features (for example, leaderboards or saved games). Sign-in is a low-friction way to get a strong identity for your players.

## Recommended sign-in flow

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

1. During the startup sequence of your game, try [Automatic sign-in](https://developer.android.com/games/pgs/v1/signin#automatic-sign-in) to automatically sign the player in.
2. If automatic sign-in does not work and the user's device is online, try [Manual sign-in](https://developer.android.com/games/pgs/v1/signin#manual-sign-in).
3. 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

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.
| **Note:** Automatic sign-in only works if the game does not request additional OAuth Scopes. For more information, see [OAuth Scopes and PGS](https://developer.android.com/games/pgs/v1/signin#oauth-scopes).

![Automatic sign-in](https://developer.android.com/static/images/games/pgs/automatic-sign-in.gif)

## Manual 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.
| **Note:** Manual sign-in works better if the game does not request additional OAuth Scopes. For more information, see [OAuth Scopes and PGS](https://developer.android.com/games/pgs/v1/signin#oauth-scopes).

![Manual sign-in](https://developer.android.com/static/images/games/pgs/manual-sign-in.gif)

## 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()`](https://developers.google.com/android/reference/com/google/android/gms/games/GamesClient.html#setViewForPopups(android.view.View))
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](https://developers.google.com/identity/protocols/OAuth2) to allow users
to give your game access to their account.
[OAuth Scopes](https://developers.google.com/identity/protocols/googlescopes)
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.

## Support for multiple sign-in methods

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](https://developer.android.com/games/pgs/v1/android/server-access) and the
[REST API](https://developer.android.com/games/services/web/api/rest) documentation.

## Client implementation

To learn how to implement sign-in support on Android, see
[Sign-in in Android Games](https://developer.android.com/games/pgs/v1/android/signin).