We’re taking steps to reduce sign-in friction and unnecessary permission requests for players by moving the Games APIs to a new model. The new interaction is:

• Players are prompted to sign-in once per account, rather than once per game
• Players no longer need their account upgraded to Google+ to use Play Games services
• Once players have signed-in for the first time, they will no longer need to sign in to any future games; they will be automatically signed in
• Note: Players can turn off auto-sign-in through the Play Games App’s settings

• Once a user signs in for first time, new games will generally be able to sign in without any user interaction
• There is no consent screen required for signing in on any particular game. Sign-in will be automatic to each new game.

In order to respect user’s privacy and avoid revealing their real name, we also have to change the way player IDs work.

• For existing players: Games will continue to get their Google+ ID (also called “player ID” in previous documentation) when they sign in.
• For new players: Games will get a new player ID which is not the same as the previous IDs we’ve used.

Potential issues

Most games should see no interruption or change in service. There are a handful of cases, however, where some change is required.

Below are some issues, along with potential solutions.

These are:

1. Asking for the Google+ scope unnecessarily
   • Issue: Your users will get unnecessary, potentially disturbing pop-up consent windows
   • Solution: Don’t request any additional scopes unless you absolutely need them
2. 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.
3. 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:

 .addApi(Games.API, new GamesOptions.Builder()  
                       .setRequireGooglePlus(true).build())  

This will ensure that your game continues to ask for the necessary permissions/scopes to continue using the player’s real-world social graph and real name profile.

Issue: Using the Player ID as another ID

If you call the Games.getCurrentPlayerId() API, the value returned here is the identifier that Games uses for this player.

Traditionally, this value could be passed into other APIs such as Plus.PeopleApi.load. In the new model, this is no longer the case. Player IDs are ONLY valid for use with Games APIs.

Solution - Don’t mix IDs

The Games APIs (those accessed from com.google.android.gms.games) all use the Player ID, and as long as you use only those, they are guaranteed to work with the new IDs.

Issue: Using mobile/client access tokens on the server

A common pattern we’ve seen is:

• Use GoogleAuthUtil to obtain an access token
• Send this token to a server
• On the server, call Google to verify the authenticity. This is most commonly done by calling https://www.googleapis.com/oauth2/v1/tokeninfo and looking at the response

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.

Solution: Use the new GetServerAuthCode flow

Fortunately, the solution is known, and is basically the same as our server-side auth recommendations for web.

 // Good way  
 {  
 GetServerAuthCodeResult result =   
 Games.getGamesServerAuthCode(gac, clientId).await();  
 if (result.isSuccess()) {  
             String authCode = result.getCode();  
             // Send code to server.  
 }  
 }  
 // Good way  

In summary

Let’s be very clear: If you do nothing, unless you are depending explicitly on Google+ features, you will see no change in functionality, and a smoother sign-in experience.

If you are:

• Requesting Google+ scopes without using them, it’s a good idea to stop using them from here out.
• Sending client access tokens to your server, we strongly suggest you use getGamesServerAuthCode() instead.

Thanks, and keep making awesome games!

Over the past six months, a number of new tools in the Google Play Developer Console have been added to help you grow your app or game business on Google Play. Our improved beta testing features help you gather more feedback and fix issues. Store Listing Experiments let you run A/B tests on your app’s Play Store listing. Universal App Campaigns and the User Acquisition performance report help you grow your audience and better understand your marketing.

Starting today, you can now generate and distribute promo codes to current and new users on Google Play to drive engagement. Under the Promotions tab in the Developer Console, you can set up promo codes for your apps, games, and in-app products to distribute in your own marketing campaigns (up to 500 codes per app, per quarter). Consider using promo codes to reward loyal users, encourage app reviews, and attract new customers.

How to use promo codes

1. Choose your app in the Developer Console.
2. Under the Promotions tab choose Add new promotion.
   
3. Review and accept the additional terms of service if you haven’t run a promotion before.
4. Choose from the options available, then generate and download your promo codes.
5. Distribute your promo codes via your marketing channels such as social networks, in email, on the web, to your app’s beta testers, or in your app or game itself.
6. Users can redeem your promo codes in a number of ways, including:

1. From Google Play, using the Redeem menu option.
2. From your app. They’ll be directed to the Play checkout flow before being redirected back to your app.
3. By following a link that embeds the promo code (see tips below).

For more details about running a promotion for your app or game, read this article on the Google Play Developer Help Center.

Tips for making the most of promo codes

Some things to keep in mind when running a successful promotion:

• There’s a limit of 500 promo codes per app every quarter.
• You can embed your code in a URL so that users don’t have to enter it themselves (for example, if you’re sending your codes in an email). You can use the URL: https://play.google.com/store?code={CODE} (where {CODE} is a generated promo code).
• To use promo codes for in-app products, you should implement In-app Promotions in your app. Note that promo codes can’t be used for subscriptions.
• Review and adhere to the Promotional Code Terms Of Service.

We hope you find interesting ways to use promo codes to find new users and engage existing fans. To learn more about the many tools and best practices you can use to grow your business on Google Play, download our new developer playbook, “The Secrets to App Success on Google Play”.

Posted by Laurence Moroney, Developer Advocate

We’re delighted to announce the availability of Google Play services 8.4. There’s a lot of new information to share with you about what’s available to you in this release.

Custom Email App Invites

App Invites is a technology that enables your users to share apps with people they know. In Google Play services 8.4 we’ve updated this to make it easier for them to share via email. Before this you could create a custom email that contained user defined text and an image, but now we’re allowing you to add content from the app directly into the message. It allows you to fully define the email body using HTML, and set the email subject line. So, for example, if you have a favorite cooking app that you want to share with your friends, your invite to use the app can include a favorite recipe from the app. They get the immediate benefit of being able to access the desired content, giving them a more informed choice about whether or not they decide to install the app to get richer and more content. Check out the App Invites sample on GitHub here.

Predicting User spend and churn in games

The Play Games Analytics developer experience is designed to enable game developers to better understand, manage, and optimize game experiences throughout the player lifecycle. With this in mind, we’ve extended the Player Stats API to help you better understand your players behavior, and based on this, entice them to stay in your game.

The churn prediction method will return data on the probability that the player will churn, i.e., stop playing the game. You can create content in response to this to entice them to stay in your game.

Additionally, the spend prediction method will return the probability that the player will spend something in the game. It’s up to you how to handle this data, but -- for example -- if there’s a low probability that the player will spend something, you could provide discounted in-app purchases or show ads.

Fused Location Provider Updates

The Fused Location Provider (FLP) in Google Play services provides location to your apps using a number of sensors, including GPS, WiFi and Cell Towers.

When desiring to save battery power, and using coarse updates, the FLP doesn’t use Global Positioning Services (GPS), and instead uses WiFi and Cell tower signals. In Google Play services 8.4, we have greatly improved how the FLP detects location from cell towers. Prior to this, we would get the location information relative to only the primary cell tower. Now, the FLP takes the primary tower and other towers nearby to provide a more accurate location. We’ve also improved location detection from WiFi access points, particularly in areas where GPS is not available -- such as indoors.

Maps API Improvements

Have you ever wished you could easily handle a tap on a suburb without having to add another layer on the map to intercept the taps? We’ve added an onClickListener for polygons, so you can easily add transparent polygons and intercept the taps directly. We’ve also added on click listeners to polylines and ground overlays.

Here’s how you can use a listener to detect a click on a polygon:

 map.setOnPolygonClickListener(new GoogleMap.OnPolygonClickListener() {  
       @Override  
       public void onPolygonClick(Polygon polygon) {  
        ...  
       }  
     });  

Info windows now also offer an OnInfoWindowCloseListener and an OnInfoWindowLongClickListener. The on close listener is particularly useful if you wish to zoom back out on the map after the user has looked at the detail associated with a particular marker.

 mMap.setOnInfoWindowCloseListener(new GoogleMap.OnInfoWindowCloseListener() {...});  

 mMap.setOnInfoWindowLongClickListener(new GoogleMap.OnInfoWindowLongClickListener() {...});  

For more details, and an example that uses these, see the ApiDemos sample on GitHub and check out the historical changes to this sample, so you can see how the new APIs work. Also see the Release Notes.

Support for Aztec bar codes

In Google Play services 7.8, we launched Vision APIs that supported face and barcode detection. One bar code format we didn’t support was Aztec bar codes, so with Google Play services 8.4 we’ve now added support for these.

Applications using BarcodeDetector in its default configuration (no barcode format restrictions) will automatically start decoding AZTEC codes.

Background Beacon Scanning

With Google Play services 8.4, the Nearby Messages API now supports background scanning for Eddystone, the open beacon format from Google. With this update, your app can be woken up when a BLE beacon is sighted. Back in July, Google Play Services 7.8 introduced the Nearby Messages API with a simple publish-subscribe interface. In the case of beacons, developers publish content by adding attachments to beacon records using Proximity Beacon API. These attachments are served back to your app when Nearby sights a beacon of interest.

New methods that we’ve added include a subscribe method for background beacon subscriptions where BLE scans are triggered at screen-on events; an associated unsubscribe event; and the ability to handle intents that you get when the Nearby API calls back during a background subscription.

Fitness Platform HistoryApi Improvements

We now support consistent step counts across the Google Fit app, other fitness apps and Android Wear watch faces with the HistoryApi.readDailyTotal() method. Please see the following documentation for more detail: https://developers.google.com/fit/android/history#read_daily_total_data?utm_campaign=play services_series_launch_121815&utm_source=anddev&utm_medium=blog

We also have a new HistoryApi.updateData() method. This method allows you to update data in one API call without having to delete and insert with two calls.

Place Picker Autocomplete Widget

Today we are announcing the mobile autocomplete widget, the latest addition to our existing set of programmatic autocomplete features on Android and iOS, as well as the addition of Autocomplete to our place picker widget. Autocomplete functionality assists users by automatically completing the name and address of a place as they type. Widgets make it even easier for developers to add autocomplete functionality to their application with just a small amount of code. Learn more about this at this blog post.