Android Developers Apps

More than 1 billion Android users come to Google Play every month to discover their favorite apps and games, enabling developers to reach a vast global audience and build successful businesses on the platform. To maintain a positive experience for both users and developers, the Google Play Developer Program Policies play a central role in helping make Google Play an open, safe and enjoyable ecosystem by educating the community and defining appropriate content and activities in the store.

We constantly listen to our developers and users to maintain fair and defined policies and look for ways to improve how we communicate those policies to help developers avoid accidental pitfalls. As part of that effort, we’ve redesigned our Developer Program Policy Center to communicate our policies with greater transparency and clarity. This redesign includes:

• Thematic organization of policies, so it is easier for developers to find relevant policies and understand the broad principles behind them


• Visual examples and detailed guidelines for the most common violations based on developer feedback
  


• 
  Expanded information on our policy enforcement to help resolve violations
  


• A visual refresh embracing Material Design to help developers more intuitively find the information they are looking for on mobile or desktop
  

From making it easier to self-correct minor violations in minutes using the app publishing status feature to improving our policy communication, the new policy center is part of our ongoing effort to improve the developer experience. We invite you to explore the new policy center and and share your feedback.

Millions of users rate and review your apps every day on Google Play. From feature requests to technical issues, ratings and reviews offer a wealth of information about what people like and dislike. Since 2013, you’ve been able to reply to reviews on Google Play, giving you a direct communication channel with your most engaged users. You've told us you value having this channel because it helps you iterate on user feedback faster on Android than other platforms. In the last few months, we’ve made a number of improvements in the Google Play Developer Console to help you better analyze and manage ratings and reviews so that you can improve your app experience and boost its rating.

We recently revamped ratings and reviews with features you can now find on dedicated pages in the Developer Console:

• See ratings over time: See how your rating changes daily, weekly, and monthly and easily spot any changes when you release a new version of your app.


• Ratings breakdown: Break down your rating by country, language, device, app version, or Android version.

• Review highlights: See common themes from what users say in reviews of your app – these are the same highlights that users see on the Play Store. Review highlights are shown when you have a high enough volume of reviews and are updated regularly to reflect the latest user experiences with your app.


• Device metadata: See certain device data such as RAM, CPU, and screen size so you can more easily identify problems users are mentioning in user reviews and debug such issues.


• Search review text: Search inside reviews to see what people are saying about a particular topic or keyword.


• Replies & updates to reviews: When you reply to reviews, the user receives an email. Now, you can also opt-in to be emailed if the user updates their review or rating.

Photo Editor by Aviary is a photo editing app with a strong focus on simplicity and intuitive use. Ratings and reviews and other Android features allow Aviary to iterate on builds two to three times faster compared to other platforms while being in a regular dialogue with their users.

Glu Mobile is a mobile gaming company known for Racing Rivals, Cooking Dash 2016 and its upcoming Taylor Swift game. Ratings and reviews features help Glu engage their audience, gather feedback, and manage user satisfaction. “Google’s review highlights allow us to see a snapshot of game features users like or dislike at a glance. We monitor review trends, watch out for notifications, and respond to reviews for our games,” says Niccolo de Masi, Glu Mobile CEO. Here are some tips Glu is using to master ratings and reviews in the Developer Console:

1. Reply to reviews: Reply to user reviews of your game in the Google Play Developer Console. Help them with their issues or let them know that you're considering their feature suggestions. A positive experience could result in the user increasing their rating.
   
2. Use search: You can now search within all reviews and apply search filters for rating, language, app version, device and more. Use this feature to find specific user feedback, for example, on new content you’ve added.
   
3. Take action: Now, you can be notified when a user answers you or updates their review. You can immediately start working on improvements if you learned about an issue. If the feedback is positive, engage with your community and turn satisfied users into fans.
   
4. Analyze over time: Analyze ratings over time to learn more about how user satisfaction improves as you update your game. This allows you to understand if your latest feature update or bug fix results in higher user satisfaction.
   
5. Identify key themes: Google Play automatically surfaces review highlights that users are mentioning about your game. This makes it quick for you to analyze reviews and understand user feedback.
   

We hope these tools help you better engage with your audience and improve your app. Visit the Developer Console Help Center to find out more about seeing and managing ratings and reviews. For more tools and best practices to help you grow a successful business, download The Secrets to App Success on Google Play.

Posted Steven Soneff, Product Manager, Google Identity

More than 30 percent of users signing in to the Netflix app on Android no longer have to enter a password thanks to Google’s Smart Lock for Passwords. Learn more

It’s been six months since the launch of Smart Lock for Passwords and we are thrilled with the impact it has made in getting users signed back in to many of their favorite apps. Million of users have been seamlessly signed in using saved accounts for over 40 major apps when going from one Android device to another or from Chrome to Android and vice versa. This first wave of developers have realized that removing the friction of sign-in increases user re-engagement, monetization opportunities, and cross-device analytics, improving the value and experience of their users.

The New York Times has seen 80 percent of their new sign-in events assisted by Smart Lock. Meanwhile, the Netflix customer support team found over a 20 percent reduction in support cases related to account recovery for their Android user base. Users strongly choose to stay signed in across their devices with over 60 percent opt-in to save sign-in info for major Smart Lock-enabled apps. And many of these developers were able to realize these gains with less than a day’s work by making only client-side changes to their app. To learn more about Smart Lock for Passwords, visit our developer site.

What’s New

With the latest release of Google Play services, we’ve made some enhancements to the Smart Lock for Passwords API to help you sign up new users or sign existing users in more quickly. Using the new method to retreive sign-in "hints", your users will see a dialog with a list of email addresses that they can select in a single tap:

This new experience is particularly important with Android Marshmallow’s runtime permissions model. To simplify and improve the user experience, this dialog doesn’t require device permissions and includes any email addresses that the user has saved with Smart Lock, not just the accounts on the device. This means that you can improve your sign-in and sign-up flows so that most of your users never need to type their email address. Apps using this dialog have seen nearly three-quarters of users select an entry shown, improving sign-up rates.

Next, after the user has tapped and shared their email address, with some server-side support, a sophisticated app can fully tailor the sign-in flow. By using the email address, you can check your database to see if a user has already registered for an account. You can then intelligently render either the sign-in or sign-up screens with the user’s email address, name and profile photo pre-filled.

Skipping the Password Altogether

It’s possible to do even better: if the user chooses a Google account from the dialog, an OpenID Connect ID Token is provided. This can save your app from having to verify email addresses for new accounts or skip the password altogether for returning users. ID tokens are also used by Google Sign-In to authenticate in place of a password, and are a strong assertion from Google that the owner of the given email address is present. If users on your site recover their passwords by email, then an ID token from Google is giving you the same assertion that the user owns the email address and is signed in to this device with that email address. You can also consider presence of ID token in addition to the password a signal to prevent password cracking and abuse.

We’ve found that the majority of users on Android use the email address that’s signed in on their device as their account for third-party apps, so this means seamlessly signing in most of your returning users, or creating a new account with one tap!

Code Samples and User Flow

Here’s a recap of how to streamline your app’s sign-in flow:

When your app starts, request stored Smart Lock credentials, and go straight to the user’s content when possible. Create a request for password or Google credentials, then listen for a callback with the results. Sign in immediately if stored user credentials (username / password, ID token, etc.) is available.

 CredentialRequest request = new CredentialRequest.Builder()  
     .setSupportsPasswordLogin(true)  
     .setAccountTypes(IdentityProviders.GOOGLE) // you can add other identity providers, too  
     .build();  
 Auth.CredentialsApi.request(mCredentialsApiClient, request).setResultCallback(  
     new ResultCallback<CredentialRequestResult>() {  
       public void onResult(CredentialRequestResult result) {  
         if (result.getStatus().isSuccess()) {  
          handleCredential(result.getCredential()) // sign in automatically!  

When the user wants or needs to sign in with their email address, show the picker to help them input it. Create a request for hints, pass control to the system to display UI, and handle the result when the user selects an entry.

 HintRequest hintRequest = new HintRequest.Builder()  
     .setEmailAddressIdentifierSupported(true)  
     .setAccountTypes(IdentityProviders.GOOGLE)  
     .build();  
 PendingIntent intent = Auth.CredentialsApi.getHintPickerIntent(mCredentialsApiClient,   
                                 hintRequest);  
 startIntentSenderForResult(intent.getIntentSender(), RC_HINT, null, 0, 0, 0);  
 ...  
 onActivityResult(int requestCode, int resultCode, Intent data) {  
   switch (requestCode) {  
     case RC_HINT:  
       if (resultCode == RESULT_OK) {  
         Credential hint = data.getParcelableExtra(Credential.EXTRA_KEY);  
         handleCredential(hint);  

The result from the hint request will contain the user’s selected identifier and an ID token if it is a Google account on the device. If you use the ID token, you must send and verify it on your server for security. Note that this token will also include a claim if the email address is verified, so you can skip any email verification step. If no token is present, or you can’t do server-side validation, just pre-fill the email field for the user.

 handleCredential(Credential credential) {  
   if (!credential.getIdTokens().isEmpty()) {  
     credential.getIdTokens().get(0).getIdToken(); // send the ID token string to your server  
   } else {  
     // otherwise, try fill the sign-in form fields and submit if password is available  
     mEmailField.setText(credential.getId());  
     mPasswordField.setText(credential.getPassword());  

On your server, after validating the ID token, use it to create an account or sign the user in without need for their password. Google provides libraries to do token validation, or you can use an open-source implementation. The ID token contains the user’s email address, and you can look it up in your database to determine whether an account needs to be created.

 GoogleIdTokenVerifier verifier = new GoogleIdTokenVerifier.Builder(transport, jsonFactory)  
         .setIssuer("https://accounts.google.com")  
         .setAudience(Arrays.asList(String.format("android://%s@%s",   
                             SHA512_HASH, PACKAGE_NAME)))  
         .build();  
 ...  
     GoogleIdToken idToken = verifier.verify(idTokenString);  
     if (idToken == null) {  
       Log.w(TAG, "ID Token Verification Failed, check the README for instructions.");  
       return;  
     }  
     GoogleIdToken.Payload payload = idToken.getPayload();  
     Log.d(TAG, "IdToken:Email:" + payload.getEmail());  
     Log.d(TAG, "IdToken:EmailVerified:" + payload.getEmailVerified());  
     // based on the email address, determine whether you need to create account   
     // or just sign user in  

Then save the user’s email address credential “hint” in Smart Lock for automatic sign-in next time. Simply call the Credentials API save method with the hint and either set the user-entered password, or set the account type if you logged the user in with an ID token.

 Credential credential = new Credential.Builder(hint)  
     // if you signed in with ID token,   
     // set account type to the URL for your app (instead of a password field)  
     //.setAccountType("https://yourdomain.com")   
     .setPassword(password)  
     .build();  
 Auth.CredentialsApi.save(mCredentialsApiClient, credential).setResultCallback(  
     new ResolvingResultCallbacks<Status>(this, RC_SAVE) {  

Learn More

To learn more about the basics of a Smart Lock API integration, check out our code lab for a step-by-step guide. We’re excited to make authentication without passwords possible via Smart Lock and are looking forward to a world where not only credentials can be managed more effectively, but apps can get their users signed in and up quickly and securely without the friction of typing usernames and passwords. We’d love to hear your feedback or questions!

Posted by Lily Sheringham, Google Play team

Founded in 2010, SGN is a Los Angeles based mobile game developer with hit titles including Cookie Jam, Panda Pop, Juice Jam and Book of Life: Sugar Smash. They now have more than 200 employees and are one of the fastest growing cross-platform gaming developers.

SGN used Store Listing experiments to test multiple variants across their portfolio of games. For Cookie Jam, they saw an 8 percent increase in conversions simply by changing the background color of their app icon. They also saw increased installs following tests with the Panda Pop app icon and by changing the character in their Book of Life: Sugar Smash app icon.

Watch Josh Yguado, Co-founder and President of SGN, and Matthew Casertano, SVP of Game Operations, talk about how using Store Listing Experiments helped SGN improve their ROI, conversion rates and gamer retention.

Find out more about how to run tests on your Store Listing to increase installs and achieve success with the new guide to ‘Secrets to App Success on Google Play’.

Posted by Lily Sheringham, Google Play team

Gifted Mom is an app developed in Cameroon which provides users with basic, yet critical information about pregnancy, breastfeeding and child vaccinations. The widespread use of Android smartphones in Africa has meant that Gifted Mom has been able to reach more people at scale and improve lives.

Watch the creators of Gifted Mom, developer Alain Nteff and doctor Conrad Tankou, explain how they built their business and launched Gifted Mom on Google Play. They also talk about their plans to grow and help people in other developing countries across the continent in the next three years, in order to ultimately tackle maternal and infant mortality.

Find out more about building apps for Android and how to find success on Google Play.

Posted by Laurence Moroney, Developer Advocate

With Google Play services 8.3, we’ve been hard at work to provide a greatly improved sign-in experience for developers that want to build apps that sign their users in with Google. To help you better understand some of these changes, this is the first in a series of blog posts about what’s available to you as a developer. In this post, we’ll discuss the changes to the user experience, and how you can use them in your app, as well as updates to the API to make coding Sign-In with Google more straightforward. On Android Marshmallow, this new Sign-In API has removed any requirement for device permissions, so there is no need to request runtime access to the accounts on the device, as was the case with the old API.

User Experience Improvements

We’ve gotten lots of feedback from developers about the user experience of using Google’s social sign-in button. Many of you noted that it took too many steps and was confusing for users. Typically, the experience is that the user touches a sign in button, and they are asked to choose an account. If that account doesn’t have a Google+ profile, they need to create one, and after that they have to give permissions based on the type of information that the app is asking for. Finally, they get to sign in to the app.

With the new API, the default set of permissions that the app requests has been reduced to basic profile information and optionally email address as demonstrated here. This introduces opportunities for much streamlined user experience: the first improvement here is in the presentation of the button itself. We had received feedback that the Google+ branding on the Sign-In button made it feel like the user would need to share Google+ data, which most apps don’t use. As such, the SignInButton has been rebranded with the reduced scopes -- it now reads ‘Sign In with Google’, and follows the standard Google branding for use with basic profile information.

After this, the user flow is also more straightforward. Instead of subsequent screens where a Google account is picked based on the email addresses registered on the device, followed by a potential ‘Create Google+ Profile’ dialog, followed by a permissions consent dialog, like this:

The user experience has changed to a single step, where the user chooses their account and gives consent. If they don’t have a Google+ profile, they don’t need to create one, eliminating that step. Additional consent dialogs come later, and are best requested in context so that the user understand why you might ask for access to their calendar or contact, and they are only prompted at the time that this data is needed.

We hope that a streamlined, one-tap, non-social sign-in option with additional OAuth permissions requested in context will help improve your sign-in rates and make it a breeze to sign-in with Google.

Check out some live apps that use the new API, including Instacart, NPR One, and Bring!

In the next post we’ll build on this by looking at some of the changes in the API to make coding apps that use Sign-In with Google even easier.

Posted by Laurence Moroney, Developer Advocate

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

A big part of this release is focused on user identity. We’ve revamped the Sign In with Google APIs to make implementation simpler and provide users a streamlined experience. First off, the new Google Sign-In no longer requires the device accounts permissions, a big win when you start to develop for Marshmallow. The API also supports the latest Google branding. When using Google Play services 8.3, you’ll find a SignInButton that looks like this with the default scopes:

Previously, users would have to touch a sign in button, and then follow several steps (i.e. selecting account, giving permission to access profile information, and possibly needing to create a Google+ account). With Google Play services 8.3, only one tap is needed for basic profile access.

You can check out the documentation for the new API here.

And to make signing in easier across devices, whether you use Google Sign-In or still have password-based authentication, the Smart Lock APIs received some important updates. We’ve added a new API method to show a dialog that helps your user select a previously-used email address to pre-fill sign in or up forms easily: check out getHintPicker (sample code). This doesn’t require any device permissions and provides an alternative to a picker you may have previously populated from accounts on the device, which would now require a runtime permission with Marshmallow.

You can use this hint information to populate an entire sign-up form with name, email address, and profile picture with one tap, or even direct the user into a sign-in or sign-up flow intelligently based on their email address. Better yet, if the entry the user picked matches an account on the device, Google can provide a verified email address in the hint, which you can use to skip email verification and authenticate the user if your system can support ID tokens, similar to Google Sign-In.

For determining location, Google Play services provides a Fused Location Provider (FLP) which abstracts the underlying location sensors, such as GPS, WiFi, and the cell radio signal, into a single easy-to-use API. We’ve made some improvements to the FLP when it comes to batching. Prior to version 8.3, the batch location APIs would allow the FLP to save power by consolidating network traffic, but when an app removed a batching location request, the batch would be cleared. You may not want this behavior, so we’ve added an API that can return any batched locations immediately. Check the flushLocations and removeLocationUpdates method calls on the FusedLocationProviderApi for more details.

App Invites is a technology that enables your users to share your app with people they know. If you build using App Invites, Google Play services 8.3 has an update that will make coding much simpler. Now, you can use the AppInvite.AppInviteApi.getInvitation() method. This will set up a ResultCallback that you can use to launch your deep link activity, drastically simplifying your code.

The Play game services Player Stats API also gets an update. The latest version now includes a new signal for the probability that a player is about to churn. Developers can use this signal to offer special promotions to improve retention. For example, a developer could provide a discount on a power-up for players that are at risk of churning.

Finally, if you are developing for wearables, you’ll know that battery life and optimization of power usage are critical in having a great user experience. With Google Play services 8.3, we’ve updated the DataApi to allow for urgency in how data items are synced. Now, a priority can be added to the data item to determine when it should be synced. For example, if you are building an app that requires immediate syncing, such as a remote control app, it can still be done immediately by calling setUrgent(), but for something such as updating your contacts, you could tolerate some delay. Non-urgent DataItems may be delayed for up to 30 minutes, but you can expect that in most cases they will be delivered within a few minutes. Low priority is now the default, so setUrgent() is needed to obtain the previous timing.

Filter support has been added to listeners in the Android Wear API, allowing listeners to only receive a subset of changes on both phones and watches. Listeners registered in the Android manifest should be filtered to only receive events that require launching the process, with the remaining events being delivered to live listeners added via methods such as addListener(). This reduces the need for listeners to filter out uninteresting events, making applications and the system more efficient.

That’s it for this release of Google Play services. To learn more, visit the Google Developers site.

Posted by, Ian Lake, Developer Advocate

One of the benefits of Android development is the flexibility provided by the large number of APIs in the Android framework and Support Library, not even including the Google Play services APIs. However, that can be a lot to understand, particularly when confronted with multiple options or design decisions. Thankfully, things are about to get a lot clearer with a new series: Android Development Patterns.

The goal of Android Development Patterns is to focus on the fundamental components and best practices that can make the biggest difference in your app. We spend time talking about the why behind each API, so that you know exactly what is best for your situation.

Centered on Android framework APIs, the Android Support Library, and high level app structure and design, we’ll augment the many videos on the Android Developers YouTube channel to bring the focus back towards Android development at its core.

Android Development Patterns are more than just videos. You’ll find written pro-tips from in-house experts at Google, such as Joanna Smith and Ian Lake, every week through the Android Development Patterns Google+ Collection.

Watch all of Android Development Patterns!

Posted by, Laurence Moroney, Developer Advocate

With the rollout of Google Play services 8.1 finally finished, there’s a lot of new information to share with developers about the release!

Marshmallow Permissions

Android 6.0 (Marshmallow) has introduced a new permissions model allowing users to control app permissions at runtime. As an app developer, it’s important for you to adopt this and give your users good control over the permissions your app needs. You can find more details here.

If your app is using Google Play services SDK versions prior to 8.1, you must update to use this new version to ensure your app is fully compatible with Android 6.0. This will enable you to manage the permission flows appropriately for your app and avoid any potential connection issues. For more details, and a step-by-step guide to what your app should do for the best user experience, take a look at this blog post on the Android Developers site.

App Invites

App Invites allows you to grow your apps audience by letting existing Android and iOS users invite their Google contacts via email or SMS to try your app out. Google Play services 8.1 adds the ability for developers to customize the email invitation, including adding a custom image, and specifying a call-to-action button text. These improvements should help developers increase user engagement and conversions with app invites.

Ambient Mode Maps

Android Wear provides a feature called ambient mode, enabling apps to stay visible, even when they aren’t actively being used. Now, with Google Play services 8.1, the Google Maps Android API supports ambient mode. In this mode, a simplified low-color rendering of the map will be seen. This reduces power consumption by lighting fewer pixels, but the camera and zoom level are retained, so user context will be kept. To learn more about ambient mode, check out this blog post.

Nearby Status Listener

Google Nearby allows you to build simple interactions between nearby devices. A new addition in Google Play services allows your app to receive callbacks when an active Nearby publish or subscribe expires. This frees you from tracking the TTL and allows your app's UI to accurately reflect whether Nearby is active or not.

Play Games Player Stats API

The new Play Games Player Stats API allows you to build better, smarter, games. It will let you tailor user experiences to specific segments of players and different stages of the player lifecycle. For example, you can give your most valuable players that are returning from a break in play a special welcome back message and reward.

Breaking Changes

In this release, there are some changes to GoogleApiClient and PendingResult, making them abstract classes, which may lead to breaking changes in your code. Learn more about these changes and how to handle them in the release notes.

SDK Now available!

You can get started developing today by downloading the Google Play services SDK from the Android SDK Manager. To learn more about Google Play services and the APIs available to you through it, visit our documentation on Google Developers.

Posted by, Laurence Moroney, Developer Advocate

Along with new platform features, Android 6.0 Marshmallow has a new permissions model that streamlines the app install and auto-update process. Google Play services 8.1 is the first release to support runtime permissions on devices running Android 6.0. and will obtain all the permissions it needs to support its APIs. As a result, your apps won’t normally need to request permissions to use them. However, if you update your apps to target API level 23, they will still need to check and request runtime permissions, as necessary.

To update your Google Play services apps to handle the latest permissions model, it’s good practice to manage the user’s expectations in setting permissions that the runtime may require. Below are some best practices to help you get started.

Before you begin...

For the purposes of this post, ensure that your API level and Target SDK are set to at least 23. Additionally, ensure that, for backwards compatibility, you are using the V4 support library to verify and request permissions. If you don’t have it already, add it to your gradle file:

 
com.android.support:support-v4:23.0.1

You’ll also need to declare Permissions in your AndroidManifest.xml file. There’s no change here. Whatever permissions your app has always needed should be declared in your AndroidManifest.xml file with the uses-permission tag. Here’s an example:

 
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

Documentation on maps and location, including a walkthrough on connecting may be found here.

Step 1. Manage Connections to the GoogleApiClient

Here’s an example:

 
@Override
public void onConnectionFailed(ConnectionResult result) {
      if (mResolvingError) {
             // Already attempting to resolve an error.
             return;
      } else if (result.hasResolution()) {
             try {
                   mResolvingError = true;
                   result.startResolutionForResult(this, REQUEST_RESOLVE_ERROR);
             } catch (SendIntentException e) {
                   // There was an error with the resolution intent. Try again.
                   mGoogleApiClient.connect();
             }
      } else {
             // Show dialog using GooglePlayServicesUtil.getErrorDialog()
             showErrorDialog(result.getErrorCode());
             mResolvingError = true;
      }
}

Step 2. Verify Permissions before calling APIs

It’s easy to assume that once you can connect, and you’ve declared the required permissions for APIs that you want to use in your AndroidManifest.xml file, that future calls will be fine. However, it is vital to ensure that you have the required permission before calling an API or connecting to the GoogleApiClient. This can be done using the checkSelfPermission method of ActivityCompat, Fragment or ContextCompat.

If the call returns false, i.e. the permissions aren’t granted, you’ll use requestPermissions to request them. The response to this will be returned in a callback which you will see in the next step.

Here’s an example:

 
private static final int REQUEST_CODE_LOCATION = 2;

if (ActivityCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION)
                != PackageManager.PERMISSION_GRANTED) {
 // Request missing location permission.
 ActivityCompat.requestPermissions(this, 
    new String[]{Manifest.permission.ACCESS_FINE_LOCATION}, 
    REQUEST_CODE_LOCATION);
} else {
 // Location permission has been granted, continue as usual.
 Location myLocation = 
             LocationServices.FusedLocationApi.getLastLocation(mGoogleApiClient);
}

Step 3. Implement the request permission callback.

In step 2, if the permission wasn’t granted by the user, the requestPermissions method was called to ask the user to grant them. The response from the user is captured in the onRequestPermissionsResult callback. You need to implement this, and always check the return values because the request could be denied or cancelled. Note that you might need to request multiple permissions here -- this sample just checks for a single permission -- you may need to check for more.

 
public void onRequestPermissionsResult(int requestCode, 
                                      String[] permissions,
                                      int[] grantResults) {
     if (requestCode == REQUEST_CODE_LOCATION) {
          if(grantResults.length == 1 
       && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
          // success!
          Location myLocation =
               LocationServices.FusedLocationApi.getLastLocation(mGoogleApiClient);
     } else {
     // Permission was denied or request was cancelled
     }
}

Step 4. Show permission rationale

If the user has previously denied the permission request, your app should display an additional explanation before requesting the permission again. Indeed, if the permissions are non trivial for the core features of the app, and the user is confused as to why they are needed, it would be recommended to guide them.

In this case, before the call to requestPermissions (step 2, above), you should call shouldShowRequestPermissionRationale, and if it returns true, you should create some UI to display additional context for the permission.

As such your code from Step 2 might look like this:

private static final int REQUEST_CODE_LOCATION = 2;

if (ActivityCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION)
                != PackageManager.PERMISSION_GRANTED) {
 // Check Permissions Now

  if (ActivityCompat.shouldShowRequestPermissionRationale(this,
                Manifest.permission.ACCESS_FINE_LOCATION)) {
        // Display UI and wait for user interaction
  } else {
 ActivityCompat.requestPermissions(
             this, new String[]{Manifest.permission.ACCESS_FINE_LOCATION}, 
                                     REQUEST_CODE_LOCATION);
  }
} else {
     // permission has been granted, continue as usual
     Location myLocation = 
        LocationServices.FusedLocationApi.getLastLocation(mGoogleApiClient);
}

Note that in this case your user may still deny the permissions, in which case you will need to craft your app so as not to be in a situation where a denied permission affects parts of the app where it shouldn’t. Refer to the best practices section on the Android developer’s site for more details and guidance.

If you’ve built any applications that use Google Play services, I’d recommend that you download the Google Play services 8.1 SDK, and rebuild your applications using it, testing against the most recent versions of Android 6.0, which you can download from the Android Developers site.

Useful resources:

Get started with building for Android 6.0

Android Permissions design guidelines

Google IO 2015 Session on Android M Permissions

Samples for Google Play services 8.1 with coding best practices

Posted by Laurence Moroney, Developer Advocate

With the release of Google Play services 7.8, we announced the addition of new Mobile Vision APIs, which includes a new Face API that finds human faces in images and video better and faster than before. This API is also smarter at distinguishing faces at different orientations and with different facial features facial expressions.

Face Detection

Face Detection is a leap forward from the previous Android FaceDetector.Face API. It’s designed to better detect human faces in images and video for easier editing. It’s smart enough to detect faces even at different orientations -- so if your subject’s head is turned sideways, it can detect it. Specific landmarks can also be detected on faces, such as the eyes, the nose, and the edges of the lips.

Detecting a face

When the API detects a human face, it is returned as a Face object. The Face object provides the spatial data for the face so you can, for example, draw bounding rectangles around a face, or, if you use landmarks on the face, you can add features to the face in the correct place, such as giving a person a new hat.

• getPosition() - Returns the top left coordinates of the area where a face was detected


• getWidth() - Returns the width of the area where a face was detected


• getHeight() - Returns the height of the area where a face was detected


• getId() - Returns an ID that the system associated with a detected face

Orientation

The Face API is smart enough to detect faces in multiple orientations. As the head is a solid object that is capable of moving and rotating around multiple axes, the view of a face in an image can vary wildly.

Here’s an example of a human face, instantly recognizable to a human, despite being oriented in greatly different ways:

The API is capable of detecting this as a face, even in the circumstances where as much as half of the facial data is missing, and the face is oriented at an angle, such as in the corners of the above image.

Here are the method calls available to a face object:

• getEulerY() - Returns the rotation of the face around the vertical axis -- i.e. has the neck turned so that the face is looking left or right [The y degree in the above image]


• getEulerZ() - Returns the rotation of the face around the Z azis -- i.e. has the user tilted their neck to cock the head sideways [The r degree in the above image]

Landmarks

A landmark is a point of interest within a face. The API provides a getLandmarks() method which returns a List , where a Landmark object returns the coordinates of the landmark, where a landmark is one of the following: Bottom of mouth, left cheek, left ear, left ear tip, left eye, left mouth, base of nose, right cheek, right ear, right ear tip, right eye or right mouth.

Activity

In addition to detecting the landmark, the API offers the following function calls to allow you to smartly detect various facial states:

• getIsLeftEyeOpenProbability() - Returns a value between 0 and 1, giving probability that the left eye is open


• getIsRighteyeOpenProbability() - Same but for right eye


• getIsSmilingProbability() - Returns a value between 0 and 1 giving a probability that the face is smiling

Thus, for example, you could write an app that only takes a photo when all of the subjects in the image are smiling.

Learn More

It’s easy to build applications that use facial detection using the Face API, and we’ve provided lots of great resources that will allow you to do so. Check them out here:

Follow the Code Lab

Read the Documentation

Explore the sample

Join the discussion on



+Android Developers

Posted by Magnus Hyttsten, Developer Advocate, Play services team

Today we’ve finished the roll-out of Google Play services 7.8. In this release, we’ve added two new APIs. The Nearby Messages API allows you to build simple interactions between nearby devices and people, while the Mobile Vision API helps you create apps that make sense of the visual world, using real-time on-device vision technology. We’ve also added optimization and new features to existing APIs. Check out the highlights in the video or read about them below.

Nearby Messages

Nearby Messages introduces a cross-platform API to find and communicate with mobile devices and beacons, based on proximity. Nearby uses a combination of Bluetooth, Wi-Fi, and an ultrasonic audio modem to connect devices. And it works across Android and iOS. For more info on Nearby Messages, check out the documentation and the launch blog post.

Mobile Vision API

We’re happy to announce a new Mobile Vision API. Mobile Vision has two components.

The Face API allows developers to find human faces in images and video. It’s faster, more accurate and provides more information than the Android FaceDetector.Face API. It finds faces in any orientation, allows developers to find landmarks such as the eyes, nose, and mouth, and identifies faces that are smiling and/or have their eyes open. Applications include photography, games, and hands-free user interfaces.

The Barcode API allows apps to recognize barcodes in real-time, on device, in any orientation. It supports a range of barcodes and can detect multiple barcodes at once. For more information, check out the Mobile Vision documentation.

Google Cloud Messaging

And finally, Google Cloud Messaging - Google’s simple and reliable messaging service - has expanded notification to support localization for Android. When composing the notification from the server, set the appropriate body_loc_key, body_loc_args, title_loc_key, and title_loc_args. GCM will handle displaying the notification based on current device locale, which saves you having to figure out which messages to display on which devices! Check out the docs for more info.

And getting ready for the Android M release, we've added high and normal priority to GCM messaging, giving you additional control over message delivery through GCM. Set messages that need immediate users attention to high priority, e.g., chat message alert, incoming voice call alert. And keep the remaining messages at normal priority so that it can be handled in the most battery efficient way without impeding your app performance.

SDK Now Available!

You can get started developing today by downloading the Google Play services SDK from the Android SDK Manager.

To learn more about Google Play services and the APIs available to you through it, visit our documentation on Google Developers.

Join the discussion on



+Android Developers

Posted by Lily Sheringham, Google Play team

South Korean Games developers Zabob Studio and Buff Studio are start-ups seeking to become major players in the global mobile games industry.

Zabob Studio was set up by Kwon Dae-hyeon and his wife in 2013. This couple-run business has already published ten games, including hits ‘Zombie Judgement Day’ and ‘Infinity Dungeon.’ So far, the company has generated more than KRW ₩140M (approximately $125,000 USD) in sales revenue, with about 60 percent of the studio’s downloads coming from international markets, such as Taiwan and Brazil.

Elsewhere, Buff Studio was founded in 2014 and right from the start, its first game Buff Knight was an instant hit. It was even featured as the ‘Game of the Week’ on Google Play and was included in “30 Best Games of 2014” lists. A sequel is already in the works showing the potential of the franchise.

In this video, Kwon Dae-hyeon, CEO of Zabob Studio, and Kim Do-Hyeong, CEO of Buff Studio, talk about how Google Play services and the Google Play Developer Console have helped them maintain a competitive edge, market their games efficiently to global users and grow revenue on the platform.

Check Zabob Studio apps and Buff Knight on Google Play!

We’re pleased to share that Android Developer Stories will now come with translated subtitles on YouTube in popular languages around the world. Find out how to turn on YouTube captions. To read locally translated blog posts, visit the Google developer blog in Korean.

Join the discussion on



+Android Developers

Posted by Ian Lake, Developer Advocate

At Google I/O, we announced the rollout of Google Play services 7.5 that deliver new capabilities and optimizations to devices across the Android ecosystem. Google Play services ensures that you can build on the latest features from Google for your users, with the confidence that those services will work properly on Android 2.3 and higher devices.

You’ll find the addition of Smart Lock for Passwords, Instance ID, new APIs for Google Cloud Messaging and Google Cast, as well as access to the Google Maps API on Android Wear devices.

Smart Lock for Passwords

Typing in a password, particularly on a mobile device, is never a pleasant experience. In many cases, your users have already logged in on the web or another device - shouldn’t your login process know that? Smart Lock for Passwords builds on the Chrome Password Manager, adding a new CredentialsApi API and UI on Android to retrieve saved credentials as part of your login process and saving new credentials for later use on other Android devices and any Chrome browser. Both password-based and Identity Provider (IDP, like Google Sign-In) credentials are supported. Keep your users logged in as they move between and to new devices; don’t let them drop off, get frustrated, or end up with multiple accounts.

Learn more about Smart Lock for Passwords on the developer site.

Instance ID, Identity, and Authorization

Instance ID (IID) allows you to retrieve a unique identifier for every app instance, providing a mechanism to authenticate and authorize actions, even if your app does not have user registration and accounts. For example, this allows you to uniquely determine which app instance is sending a request from by including the Instance ID token. We’ve also made it easy to handle edge cases to ensure that you’ll have valid Instance ID tokens.

Google Cloud Messaging

Google Cloud Messaging (GCM) gives developers a battery efficient mechanism for sending information to your users as well as send upstream messages from a device to your server.

Google Cloud Messaging and InstanceID

Previously, GCM used a unique registration ID to refer to each device - while these IDs will continue to work, you can now utilize Instance ID tokens for GCM, gaining all of the advantages of InstanceID around handling error cases. Instance ID tokens are fully compatible with user notifications, allowing you to send notifications to all of a user's devices.

Topic based subscriptions

You’ll also get another new feature for switching to InstanceID with GCM - topic based subscriptions! This makes it easy to publish a message to exactly the right audience and have GCM handle all the heavy lifting of sending to all subscribed instances. Your app can subscribe to multiple topics, allowing you to create any set of topics needed to best handle your app’s messaging needs.

Receiving messages with GCM

Of course, just subscribing to receive messages is only half the battle: receiving GCM messages can now be done using a GcmReceiver and a subclass of GcmListenerService. These two classes make it easy to help your app reliably process messages, even when the device is awakened from deep sleep.

GCM Network Manager

Applications often need to sync data with their servers when new information is available. In GCM we refer to this model as “send to sync”. We made this task much simpler with the introduction of the GCM Network Manager APIs, which handles many of the common implementation patterns such as waiting for network connectivity, device charging, network retries, and backoff. GcmNetworkManager will schedule your background tasks when it is most appropriate and it can batch multiple tasks together for efficiency and battery savings, even utilizing the JobScheduler APIs for best performance on Android 5.0+ devices. With support for both one-off tasks and periodic tasks, this API serves as a flexible framework for many different types of operations.

App Invites Beta

Now in beta, App Invites is new functionality for both Android and iOS that provides a standard UI for users to invite their contacts to install your app and optionally deep link specifically to selected content, using your users’ device and Google-wide contacts as a source to drive referrals to increase the reach of your app.

With the ability to send invites via SMS or email, this provides a great mechanism to organically grow your user base, give your users a consistent way to share your app with exactly who would like it, and track how effective your invites are.

With App Invites, our goal is to take the hard work out of building user referral and onboarding flows, so that you can focus on your core app experience. Learn more about App Invites on the developer site!

Google Cast

Google Cast is a technology that lets you easily cast content from your mobile device or laptop right to your TV or speakers. With the new ability to use remote display on any Android, iOS, or Chrome app, better media support, better game support, we hope your Google Cast experience is better than ever!

Remote Display API

We are making it easy for mobile developers to bring graphically intensive apps or games to Google Cast receivers with Google Cast Remote Display APIs for Android and iOS. The new Remote Display API allows you to build a tailored, integrated second screen experience, without requiring an identical mirroring of content between mobile devices and the Google Cast device.

Learn more about Remote Display on the Google Cast Developers Site!

Autoplay and Queuing APIs

Playing single media items on Chromecast has been something RemoteMediaPlayer (or CastCompanionLibrary’s VideoCastController) has been doing well for some time. With this release, RemoteMediaPlayer is gaining a full media queue and support for autoplay for a seamless media playback experience. This ensures that all connected devices can easily maintain a synchronized queue of upcoming media items, opening up new possibilities of creating collaborative Google Cast media experiences.

Game Manager APIs for Google Cast

Bringing your game to Google Cast can make for a great multiplayer experience, using a mobile device as a game controller and the TV to display the action. To make it easier to send messages and state changes to all connected clients and the cast receiver, Google Play services 7.5 introduces the GameManagerClient and the Game Manager APIs for Google Cast, available for Android, iOS, Chrome, and for receivers.

Android Wear

Watches are great devices for telling time. But what if in addition showing you when you are, watches could easily show you where you are? With the new release, you can now use the familiar Maps APIs on Android Wear devices:

This makes it possible to display fully interactive maps, as well as lite mode maps, directly on Android Wear devices. You’ll be able to scroll and zoom interactive maps, show the user’s current location, and more. Check out the full list of supported features in the developer documentation and check out all the details on the Geo Developers blog.

Google Fit

Google Fit is an open platform designed to make building fitness apps, whether that means retrieving sensor data like current location and speed, collecting and storing activity data, or automatically aggregating that data into a single view of the user’s fitness data.

You’ll now be able to use the RecordingApi for gathering estimated distance traveled and calories burned data, making it available to your app and other Google Fit enabled apps via the HistoryApi.

Being active can take many forms. While some activities are easily measured in terms of steps or distance, strength training is measured in terms of type, resistance and repetitions. This type of data can now be stored in Google Fit via new support for a large number of workout exercises, helping users build a complete view of their activity.

SDK is now available!

Google Play services 7.5 is now available: get started with updated SDK now!

To learn more about Google Play services and the APIs available to you through it, visit the Google APIs for Android site.

Join the discussion on



+Android Developers

Posted by Ian Lake, Developer Advocate

Today, we’re excited to give you new tools to build better apps with the rollout of Google Play services 7.3. With new Android Wear APIs, the addition of nutrition data to Google Fit, improvements to retrieving the user’s activity and location, and better support for optional APIs, there’s a lot to explore in this release.

Android Wear

Google Play services 7.3 extends the Android Wear network by enabling you to connect multiple Wear devices to a single mobile device.

While the DataApi will automatically sync DataItems across all nodes in the Wear network, the directed nature of the MessageApi is faced with new challenges. What node do you send a message to when the NodeApi starts showing multiple nodes from getConnectedNodes()? This is exactly the use case for the new CapabilityApi, which allows different nodes to advertise that they provide a specific functionality (say, the phone node being able to download images from the internet). This allows you to replace a generic NodeListener with a more specific CapabilityListener, getting only connection results and a list of nodes that have the specific functionality you need. We’ve updated the Sending and Receiving Messages training to explore this new functionality.

Another new addition for Android Wear is the ChannelApi, which provides a bidirectional data connection between two nodes. While assets are the best way to efficiently add binary data to the data layer for synchronization to all devices, this API focuses on sending larger binary data directly between specific nodes. This comes in two forms: sending full files via the sendFile() method (perfect for later offline access) or opening an OutputStream to stream real time binary data. We hope this offers a flexible, low level API to complement the DataApi and MessageApi.

We’ve updated our samples with these changes in mind so go check them out here!

Google Fit

Google Fit makes building fitness apps easier with fitness specific APIs on retrieving sensor data like current location and speed, collecting and storing activity data in Google Fit’s open platform, and automatically aggregating that data into a single view of the user’s fitness data.

To make it even easier to retrieve up-to-date information, Google Play Services 7.3 adds a new method to the HistoryApi: readDailyTotal(). This automatically aggregates data for a given DataType from midnight on the current day through now, giving you a single DataPoint. For TYPE_STEP_COUNT_DELTA, this method does not require any authentication, making it possible to retrieve the current number of steps for today from any application whether on mobile devices or on Android Wear - great for watch faces!

Google Fit is also augmenting its existing data types with granular nutrition information, including protein, fat, cholesterol, and more. By leveraging these details about the user’s diet, developers can help users stay more informed about their health and fitness.

Location

LocationRequest is the heart of the FusedLocationProviderApi, encapsulating the type and frequency of location information you’d like to receive. An important, but small change to LocationRequest is the addition of a maximum wait time for location updates via setMaxWaitTime(). By using a value at least two times larger than the requested interval, the system can batch location updates together, reducing battery usage and, on some devices, actually improving location accuracy.

For any ongoing location requests, it is important to know that you will continue to get good location data back. The SettingsApi is still incredibly useful for confirming that user settings are optimal before you put in a LocationRequest, however, it isn’t the best approach for continual monitoring. For that, you can use the new LocationCallback class in place of your existing LocationListener to receive LocationAvailability updates in addition to location updates, giving you a simple callback whenever settings might have changed which will affect the current set of LocationRequests. You can also use FusedLocationProviderApi’s getLocationAvailability() to retrieve the current state on demand.

Connecting to Google Play services

One of the biggest benefits of GoogleApiClient is that it provides a single connection state, whether you are connecting to a single API or multiple APIs. However, this made it hard to work with APIs that might not be available on all devices, such as the Wearable API. This release makes it much easier to work with APIs that may not always be available with the addition of an addApiIfAvailable() method ensuring that unavailable APIs do not hold up the connection process. The current state for each API can then be retrieved via getConnectionResult(), giving you a way to check at runtime whether an API is available and connected.

While GoogleApiClient’s connection process already takes care of checking for Google Play services availability, if you are not using GoogleApiClient, you’ll find many of the static utility methods in GooglePlayServicesUtil such as isGooglePlayServicesAvailable() have now been moved to the singleton GoogleApiAvailability class. We hope the move away from static methods helps you when writing tests, ensuring your application can properly handle any error cases.

SDK is now available!

Google Play services 7.3 is now available: get started with updated SDK now!

To learn more about Google Play services and the APIs available to you through it, visit the Google Play services section on the Android Developer site.

Join the discussion on



+Android Developers