Sep 23

Using the Hardware Scaler for Performance and Efficiency

Posted by Hak Matsuda and Dirk Dougherty, Android Developer Relations team

If you develop a performance-intensive 3D game, you’re always looking for ways to give users richer graphics, higher frame rates, and better responsiveness. You also want to conserve the user’s battery and keep the device from getting too warm during play. To help you optimize in all of these areas, consider taking advantage of the hardware scaler that’s available on almost all Android devices in the market today.

How it works and why you should use it

Virtually all modern Android devices use a CPU/GPU chipset that includes a hardware video scaler. Android provides the higher-level integration and makes the scaler available to apps through standard Android APIs, from Java or native (C++) code. To take advantage of the hardware scaler, all you have to do is render to a fixed-size graphics buffer, rather than using the system-provided default buffers, which are sized to the device’s full screen resolution.

When you render to a fixed-size buffer, the device hardware does the work of scaling your scene up (or down) to match the device’s screen resolution, including making any adjustments to aspect ratio. Typically, you would create a fixed-size buffer that’s smaller than the device’s full screen resolution, which lets you render more efficiently — especially on today’s high-resolution screens.

Using the hardware scaler is more efficient for several reasons. First, hardware scalers are extremely fast and can produce great visual results through multi-tap and other algorithms that reduce artifacts. Second, because your app is rendering to a smaller buffer, the computation load on the GPU is reduced and performance improves. Third, with less computation work to do, the GPU runs cooler and uses less battery. And finally, you can choose what size rendering buffer you want to use, and that buffer can be the same on all devices, regardless of the actual screen resolution.

Optimizing the fill rate

In a mobile GPU, the pixel fill rate is one of the major sources of performance bottlenecks for performance game applications. With newer phones and tablets offering higher and higher screen resolutions, rendering your 2D or 3D graphics on those those devices can significantly reduce your frame rate. The GPU hits its maximum fill rate, and with so many pixels to fill, your frame rate drops.

style="border-radius: 6px;padding:0;margin:0;" />

Power consumed in the GPU at different rendering resolutions, across several popular chipsets in use on Android devices. (Data provided by Qualcomm).

To avoid these bottlenecks, you need to reduce the number of pixels that your game is drawing in each frame. There are several techniques for achieving that, such as using depth-prepass optimizations and others, but a really simple and effective way is making use of the hardware scaler.

Instead of rendering to a full-size buffer that could be as large as 2560×1600, your game can instead render to a smaller buffer — for example 1280×720 or 1920×1080 — and let the hardware scaler expand your scene without any additional cost and minimal loss in visual quality.

Reducing power consumption and thermal effects

A performance-intensive game can tend to consume too much battery and generate too much heat. The game’s power consumption and thermal conditions are important to users, and they are important considerations to developers as well.

As shown in the diagram, the power consumed in the device GPU increases significantly as rendering resolution rises. In most cases, any heavy use of power in GPU will end up reducing battery life in the device.

In addition, as CPU/GPU rendering load increases, heat is generated that can make the device uncomfortable to hold. The heat can even trigger CPU/GPU speed adjustments designed to cool the CPU/GPU, and these in turn can throttle the processing power that’s available to your game.

For both minimizing power consumption and thermal effects, using the hardware scaler can be very useful. Because you are rendering to a smaller buffer, the GPU spends less energy rendering and generates less heat.

Accessing the hardware scaler from Android APIs

Android gives you easy access to the hardware scaler through standard APIs, available from your Java code or from your native (C++) code through the Android NDK.

All you need to do is use the APIs to create a fixed-size buffer and render into it. You don’t need to consider the actual size of the device screen, however in cases where you want to preserve the original aspect ratio, you can either match the aspect ratio of the buffer to that of the screen, or you can adjust your rendering into the buffer.

From your Java code, you access the scaler through SurfaceView, introduced in API level 1. Here’s how you would create a fixed-size buffer at 1280×720 resolution:

surfaceView = new GLSurfaceView(this);
surfaceView.getHolder().setFixedSize(1280, 720);

If you want to use the scaler from native code, you can do so through the NativeActivity class, introduced in Android 2.3 (API level 9). Here’s how you would create a fixed-size buffer at 1280×720 resolution using NativeActivity:

int32_t ret = ANativeWindow_setBuffersGeometry(window, 1280, 720, 0);

By specifying a size for the buffer, the hardware scaler is enabled and you benefit in your rendering to the specified window.

Choosing a size for your graphics buffer

If you will use a fixed-size graphics buffer, it’s important to choose a size that balances visual quality across targeted devices with performance and efficiency gains.

For most performance 3D games that use the hardware scaler, the recommended size for rendering is 1080p. As illustrated in the diagram, 1080p is a sweet spot that balances a visual quality, frame rate, and power consumption. If you are satisfied with 720p, of course you can use that size for even more efficient operations.

More information

If you’d like to take advantage of the hardware scaler in your app, take a look at the class documentation for SurfaceView or NativeActivity, depending on whether you are rendering through the Android framework or native APIs.

Watch for sample code on using the hardware scaler coming soon!

Join the discussion on

+Android Developers


Android Developers Blog

Sep 20

Announcing the 2016 Android Experiments I/O Challenge!

Posted by Roman Nurik, Senior Interactive Designer, and Richard The, Google Creative Lab

Last summer we launched Android Experiments: a showcase of creative Android projects, and an open invitation for all developers to submit their own experiments to the gallery. So far we’ve seen some amazing work from the developer community – from live wallpaper, to watch faces, to interesting hacks of the IOIO board – and we want to see more.

Today we announce the Android Experiments I/O Challenge: a chance for your experiment (and you) to go to I/O 2016!

From now through April 13, you can enter by submitting your experiments to the gallery. The top three winners of the contest will receive a trip to this year’s Google I/O, and the five runner-ups will get the new Nexus 6P.

So what makes a good Android Experiment? It’s a project that utilizes the unique capabilities of the Android platform in an innovative way. Here are a few suggestions:

  • Creative uses of Android’s new or distinctive features
  • Projects that explore how we interact with our devices, in small and big ways
  • Unique visual aesthetics
  • Open source projects that inspire other developers
  • Surprise us – we want to see the amazing things you’re cooking up

All projects on Android Experiments are open source. If you’re not sure where to start take a look on the site gallery, dig in and get inspired.

We can’t wait to see how you’re combining code and creativity! Enter on androidexperiments.com/challenge today.


Android Developers Blog

Sep 20

Beta Channel for the Android WebView

Posted by Richard Cole, Software Engineer, Google London

Many Android apps use a WebView for displaying HTML content. In Android 5.0 Lollipop, Google has the ability to update WebView independently of the Android platform. Beginning today, developers can use a new beta channel to test the latest version of WebView and provide feedback.

WebView updates bring numerous bug fixes, new web platform APIs and updates from Chromium. If you’re making use of the WebView in your app, becoming a beta channel tester will give you an early start with new APIs as well as the chance to test your app before the WebView rolls out to your users.

The first version offered in the beta channel will be based on Chrome 40 and you can find a full list of changes on the chromium blog entry.

To become a beta tester, join the community which will enable you to sign up for the Beta program; you’ll then be able to install the beta version of the WebView via the Play Store. If you find any bugs, please file them on the Chromium issue tracker.

Join the discussion on

+Android Developers


Android Developers Blog

Sep 20

Google Play Billing Library 1.0 released

Posted by Neto Marin, Developer Advocate

In June we announced the developer
preview for a new Google Play Billing Library. Today, we are pleased to
announce the official release of the Play Billing Library 1.0. This library
simplifies the development process for Google Play Billing, allowing you to
focus your efforts on your app.

Thank you for your valuable feedback and suggestions that helped us reach the
1.0 release. Watch the video below for a quick overview of the library’s
features.



Before you start

With Play Billing, you can receive payments from users around the world via a
payment system they trust and you can take advantage of features and reports in
the Play Console to manage and earn more revenue.

If you have never implemented in-app billing in your apps, or you want to know
what you can offer using Play Billing Library, read the In-app
Billing Overview to familiarize yourself with concepts and terminology that
make it easier for you to implement In-app Billing using the Play Billing
Library.

Getting started

Play Billing Library is available through Maven repository, and adding Play
Billing Library to your project is simple as adding the following dependency
into your app’s build.gradle file:

dependencies {
    ...
    compile 'com.android.billingclient:billing:1.0'
}

The Play Billing Library 1.0 automatically adds the
com.android.vending.BILLING permission to your APK. This means you
no longer need to manually include it in your application module’s manifest.

BillingClient and PurchasesUpdatedListener

These classes are the most important pieces when integrating the library into
your Android app. The BillingClient
is the bridge between your app and Google Play. You will use it for listing
available products, starting the billing flow for in-app products or
subscriptions (i.e. opening the payment interface), getting user purchases, and
creating or modifying subscriptions.

When creating your BillingClient
instance, you’ll need to set a PurchasesUpdatedListener.
This allows your app to receive updates from the In-app Billing API, including
transaction results after the billing flow, as well as purchases completed
outside of your app, e.g. user redeemed a Promo Code or bought a product on
another device.

The following code demonstrates how you could override the )">onPurchasesUpdated()
method of your PurchasesUpdatedListener:

@Override
void onPurchasesUpdated(@BillingResponse int responseCode,
        List<Purchase> purchases) {
    if (responseCode == BillingResponse.OK
            && purchases != null) {
        for (Purchase purchase : purchases) {
            handlePurchase(purchase);
        }
    } else if (responseCode == BillingResponse.USER_CANCELED) {
        // Handle an error caused by a user canceling the purchase flow.
    } else {
        // Handle any other error codes.
    }
}

You can implement the PurchasesUpdatedListener
in your Activity or in any other class you want, according to your app’s
architecture. And here’s the code for creating the BillingClient
instance, and setting the PurchasesUpdatedListener:

mBillingClient = BillingClient.newBuilder(mContext)
                              .setListener(mPurchasesUpdatedListener)
                              .build();

Listing and selling products

To sell products in your app, first, you need to add them using the Play
Console. For more details about how to add in-app products see the page Administering
In-app Billing.

Attention: If this is a brand new app, before adding
the products you must publish it to the alpha or beta distribution channel. For
more information, see Draft
Apps are No Longer Supported.

To get a list of product details with prices for current user, call ,
com.android.billingclient.api.SkuDetailsResponseListener)">querySkuDetailsAsync()
.
You must also specify a listener which implements the SkuDetailsResponseListener
interface. You can then override the onSkuDetailsResponse()
method which notifies the listener when the query finishes, as illustrated by
the following sample code:

List<String> skuList = new ArrayList<> ();
skuList.add("premiumUpgrade");
skuList.add("gas");
SkuDetailsParams.Builder params = SkuDetailsParams.newBuilder();
params.setSkusList(skuList).setType(SkuType.INAPP);
mBillingClient.querySkuDetailsAsync(params.build(),
    new SkuDetailsResponseListener() {
        @Override
        public void onSkuDetailsResponse(SkuDetailsResult result) {
            // Process the result.
        }
    })

After the user chooses a product to buy, you’ll need to start the billing flow
and handle the transaction result. To start a purchase request from your app,
call the launchBillingFlow()
method on the Play Billing Library client. You must call the launchBillingFlow()
method (and all the other methods from BillingClient)
from the UI thread.

The launchBillingFlow()
method needs BillingFlowParams
object that contains relevant data for completing the purchase, such as the
product ID of the item to purchase and the product type (in this case, SkuType.INAPP).
To get an instance of BillingFlowParams,
construct it with newBuilder()
method:

BillingFlowParams.Builder builder = BillingFlowParams
                                       .newBuilder()
                                       .setSku(skuId).setType(SkuType.INAPP);
int responseCode = mBillingClient.launchBillingFlow(builder.build());

As we mentioned earlier, the transaction result will be sent to the )">onPurchasesUpdated()
method. For details how to process the data received on )">onPurchasesUpdated()
and how to handle a purchase, check the section Purchase
an item in our training guide.

Consuming products

By default, all in-app products are managed. It means that Google Play tracks
the product ownership and doesn’t allow to buy multiple times. To be able to buy
a product again, you must consume the product before it becomes available again.

It’s common to implement consumption for in-app products which users may want to
purchase multiple times, such as in-game currency or equipment. You typically
don’t want to implement consumption for in-app products that user purchases once
and provide a permanent effect, such as a premium upgrade.

To consume a product, call the consumeAsync()
method on the Play Billing Library client and pass in the
purchaseToken String value returned when you made the purchase. The
consumption result is returned via onConsumeResponse() method of the ConsumeResponseListener
interface, that you must override to handle the consumption result.

The following example illustrates consuming a product using the associated
purchaseToken:

ConsumeResponseListener listener = new ConsumeResponseListener() {
    @Override
    public void onConsumeResponse(@BillingResponse int responseCode,
                                  String outToken) {
        if (responseCode == BillingResponse.OK) {
            // Handle the success of the consume operation.
            // For example, increase the number of player's coins,
            // that provide temporary benefits
        }
    }
};
mBillingClient.consumeAsync(purchaseToken, listener);

Sample updated: Trivial Drive V2

With a new library comes a refreshed sample! To help you to understand how to
implement in-app billing in your app using the new Play Billing Library, we’ve
rewritten the Trivial
Drive sample from the ground up.

Since we released Trivial Drive back in 2013, many new features, devices, and
platforms have been added to the Android ecosystem. To reflect this evolution,
the Trivial
Drive v2 sample now runs on Android TV and Android Wear.

What’s next?

Before integrating within your app, you can try the Play Billing Library with
the codelab published during Google I/O 2017: Buy
and Subscribe: Monetize your app on Google Play.

In this codelab, you will start with a simplified version of Trivial Drive V2
that lets users to “drive” and then you will add in-app billing to it. You’ll
learn how to integrate purchases and subscriptions as well as the best practices
for developing reliable apps that handle purchases.

Get more info on the Play
Billing Library and the official
reference for classes and methods documentation on the Android Developers
website. For a step-by-step guide to implementing the Play Billing Library in
your project, visit the library’s
training class.

We still want your feedback

If you have issues or questions, file a bug
report on the Google Issue Tracker, and for issues and suggestions on the
sample (like a bug or a new feature), contact us on the Trivial
Drive issues page.

For technical questions on implementation, library usage, and best practices,
you can use the tags google-play
and play-billing-library
on StackOverflow or visit the communities on our
Google+ page.


Android Developers Blog

Sep 17

The Guardian — Understanding and engaging mobile users

Posted by Leticia Lago, Google Play team

The Guardian is a global news organization with one of the world’s largest quality English-speaking news websites, theguardian.com. It has more than 100 million monthly unique browsers and app users, two thirds of which come from outside the UK. With a longstanding reputation for agenda-setting journalism, the publication is most recently renowned for its Pulitzer Prize and Emmy-winning coverage of the disclosures made by whistleblower Edward Snowden. The Guardian’s early adoption of a digital-first policy and continued digital innovation means it has also become a respected name among developers and tech audiences. In the last year, it has launched a redesigned app and new website and been among a handful of publishers to develop its own Glassware.

The Guardian app is taking advantage of unique Google Play and Android features to drive user engagement. Their mobile app readers are now 10 to 20 times more engaged than their average web users. Improving engagement has also helped them lift the rating for their app from 4.0 to 4.4 on Google Play.

Anthony Sullivan, Director of Product, and Tom Grinsted, Product Manager, share some best practices for increasing app engagement in this video.

To learn more, be sure to check out these resources to better engage your users:

  • Convert installs to active users [video] — hear from Matteo Vallone, Partner Development Manager for Google Play, about the best practices for engaging and retaining users through intents, identity, context, and rich notifications as well as delivering a cross-platform user experience.
  • Adding Wearable Features to Notifications [tutorial] — learn how to add notifications to Android Wear devices, including how to make use of the Wear notification features: voice commands, stacks, and pages.
  • Beta testing [help] — discover how to make use of the alpha and beta testing features offered by Google Play, and get feedback from real users.
  • Build your community (of testers) [guide] — get advice on how to build communities on G+ or other social networks, then tap into their skills and enthusiasm to help with testing your app.
Join the discussion on

+Android Developers


Android Developers Blog

Sep 16

Android Things Hackster Contest

Posted by Dave Smith,
Developer Advocate for IoT

Android Things
lets you build professional, mass-market products on a trusted platform, without
previous knowledge of embedded system design. With Android Things you get a
turnkey hardware solution and an easy-to-use software development platform based
on Android Studio and the Android SDK — making it easy to build designs that
scale to production. Android Things is currently in developer preview and we’d
love to see what you can build with our
latest release.

Today we are announcing a contest with Hackster and NXP for developers to
showcase their use of Android Things with other Google developer platforms.
Project ideas should be added to Google’s Hackster.io Community by
including Android Things
as a software component, then registered through the contest page.

Idea Submissions

Submit your project ideas starting today. Ideas submitted by September 29, 2017
are eligible to receive one of 120 Pico Pi i.MX6UL Kits to use in the final design. During this phase, projects do
not need to be complete; we just want to see your amazing ideas! We are looking
for concepts in the following categories:

  • Smart Home
  • Robotics
  • Smart City
  • Industrial IoT / Manufacturing
  • Retail
  • Entertainment

Project Submissions

Final projects must be submitted by Oct 31, 2017. Your project does not need to
be one of the chosen recipients of a Pico kit to be eligible for the grand
prize. Winners will receive support from Avnet, Dragon Innovation and
Kickstarter to take their ideas from prototype to production. See the contest page for more
details.

We are eager to see the projects that you come up with. More importantly, we’re
excited to see how your work can inspire other developers to create something
great with Android Things. To learn more about the benefits of Android Things,
watch the recording from the Bootstrapping IoT Products with Android
Things webinar. You can also join Google’s IoT
Developers Community on Google+, a great resource to get updates, ask
questions, and discuss ideas.


Android Developers Blog

Sep 15

Play Games Permissions are changing in 2016

Posted by Wolff Dobson, Developer Advocate

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

Advantages:

  • 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.

  1. Upgrade to the latest version of Google Play Services SDK – at least 8.4.87.

  2. Create a server client ID if you don’t already have one

    1. Go to the Google Developer Console, and select your project

    2. From the left nav, select API Manager, then select Credentials

    3. Select “New Credentials” and choose “OAuth Client ID”

    4. Select “Web Application” and name it something useful for your application

    5. The client id for this web application is now your server client id.

  3. In your game, connect your GoogleApiClient as normal.

  4. Once connected, call the following API:

    1. Games.getGamesServerAuthCode(googleApiClient, “your_server_client_id”)

    2. If you were using GoogleAuthUtil before, you were probably calling this on a background thread – in which case the code looks like this:


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

  1. Upgrade to the latest version of Google Play Services SDK – at least 8.4.87.

  2. Create a server client ID if you don’t already have one

    1. Go to the Google Developer Console, and select your project

    2. From the left nav, select API Manager, then select Credentials

    3. Select “New Credentials” and choose “OAuth Client ID”

    4. Select “Web Application” and name it something useful for your application

    5. The client id for this web application is now your server client id.

  3. In your game, connect your GoogleApiClient as normal.

  4. Once connected, call the following API:

    1. Games.getGamesServerAuthCode(googleApiClient, “your_server_client_id”)

    2. If you were using GoogleAuthUtil before, you were probably calling this on a background thread – in which case the code looks like this:

// Good way

{

GetServerAuthCodeResult result =

Games.getGamesServerAuthCode(gac, clientId).await();

if (result.isSuccess()) {

    String authCode = result.getCode();

    // Send code to server.

}

}

// Good way

  1. Send the auth code to your server, exactly the same as before.

  2. On your server, make an RPC to https://www.googleapis.com/oauth2/v4/token to exchange the auth code for an access token, probably using a Google Apis Client Library.

    1. You’ll have to provide the server client ID, server client secret (listed in the Developer Console when you created the server client ID), and the auth code.

    2. See more details here: https://developers.google.com/identity/protocols/OAuth2WebServer#handlingresponse

    3. No, really:  You should use a Google Apis Client Library to make this process easier.

  3. Once you have the access token, you can now call www.googleapis.com/games/v1/applications/<app_id>/verify/ using that access token.

    1. Pass the auth token in a header as follows:

      1. “Authorization: OAuth <access_token>”

    2. The response value will contain the player ID for the user. This is the correct player ID to use for this user.

    3. This access token can be used to make additional server-to-server calls as needed.

Note: This API will only return a 200 if the access token was actually issued to your web app.

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!


Android Developers Blog

Sep 15

SafetyNet Verify Apps API, Google Play Protect at your fingertips

Posted by William Luh, Software Engineer

Google Play Protect, which
includes the Verify Apps security feature, helps keep users safe from harmful
apps. Google Play Protect is available on all Android devices with Google Play
installed and provides users with peace of mind and insights into the state of
their device security.

App developers can get similar security insights into the installed apps
landscape on user devices from the SafetyNet Verify
Apps API. This new suite of APIs lets developers determine whether a user’s
device is protected by Google Play Protect, encourage users not already using
Google Play Protect to enable it, and identify any known potentially
harmful apps (PHAs) that are installed on the device.

These APIs are especially useful for developers of apps that may be impacted by
installed PHAs on the same device as their app. Determining that Google Play
Protect is enabled with isVerifyAppsEnabled() gives developers
additional assurance that a device is more likely to be clean. If a device
doesn’t have Google Play Protect enabled, developers can request that the user
enable Google Play Protect with enableVerifyApps(). With Google
Play Protect enabled, developers can use the listHarmfulApps()
method to determine whether there are any potentially harmful apps installed on
a user’s device. This easy-to-use suite of features does not require
API keys and requesting quota.

Enterprise-focused apps in particular may benefit from using the Verify Apps
API. Enterprise apps are designed to safeguard a company’s data from the outside
world. These apps often implement strict enforcements, such as ensuring the
mobile device is approved by the enterprise and requiring a strong password for
lockscreens. If any of the criteria are not satisfied, the enterprise may revoke
credentials and remove sensitive data from the device. Having a mechanism to
enforce Google Play Protect and scan for PHAs is another tool to help enterprise
app developers keep enterprise data and devices safe.

For better protection, developers should use the attestation
API along with the new Verify Apps API. Use the attestation API first to
establish that the device has not been modified from a known state. Once the
Android system can be trusted, the results from the Verify Apps API can be
trusted. Existing attestation API users may find additional benefits in using
the Verify Apps API as it may be able to detect on-device PHAs. In general,
using multiple signals for anti-abuse detection is encouraged.

To learn how to use this API in your app, check out the developer
docs.


Android Developers Blog

Sep 14

Google and Ideas United Launch Program to Support Inclusivity in Game Design


Posted by Daraiha Greene, CS Education in Media Program Manager, Multicultural
Strategy, and Kate Brennan and Mathilde Cohen Solal, Google Play

Today, we are thrilled to announce Infinite Deviation: Games. Infinite Deviation is an
initiative created by Google Computer Science (CS) in Media and Ideas United in order to
tackle issues of representation by bringing creativity and computer science
together in unexpected ways — ensuring that representations of computer
scientists are inclusive of women, people of color, the LGBTQIA+ community,
people with disabilities, and other underrepresented groups. Last year, Infinite
Deviation produced a series of narrative
short films to dispel stereotypes in computer science and is excited to
collaborate with Google Play to bring the Infinite Deviation program to gaming.

Currently only 23%
of people in the gaming industry identify as women and only 3%
of game developers are African-American. From ensuring women are represented
in video
games to giving young girls the chance to create
their own games, Google Play is committed to bringing new, diverse voices to
gaming. The program gives game designers from all backgrounds the chance to
pitch an original mobile game concept and have it developed, published, and
promoted in partnership with Google Play. Applicants can submit their mobile
game concepts until October 9.

The top three ideas will be chosen by a panel of industry experts and designers
will receive the resources and support they need to bring their games to life on
Google Play. Games will be judged on creativity and innovation, as well as their
ability to tell original stories that resonate with underrepresented audiences.

Participants must have less than two years of professional game design
experience in order to be eligible. For more information on the program,
including how to apply, you can visit InfiniteDeviation.com.

By promoting original games that resonate with underrepresented audiences, we
hope the program creates more favorable perceptions of computer science, bust
biases, and nurture acceptance through an activity many enjoy.


Android Developers Blog