Showing posts with label Google Play services. Show all posts
Showing posts with label Google Play services. Show all posts

Google Play Services 8.4 SDK is available

Posted by Laurence Moroney, Developer Advocate



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







Custom Email App Invites



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



Predicting User spend and churn in games



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




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



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



Fused Location Provider Updates



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



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



Maps API Improvements



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



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


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


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


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

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


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



Support for Aztec bar codes



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



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



Background Beacon Scanning



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




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



Fitness Platform HistoryApi Improvements



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



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



Place Picker Autocomplete Widget



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


















One tap sign-up and automatic sign-in without password entry using Smart Lock

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!




Android Developer Story: SGN game ‘Cookie Jam’ increases user conversions with Store Listing Experiments

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





Android Developer Story: Gifted Mom reaches more mothers across Africa with Android

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.

Improvements to Sign-In with Google Play services 8.3

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.



What’s new in Google Play services 8.3

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.

Android Development Patterns: A Series on Best Practices for Android Development

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!



Google Play services 8.1: Get ready for Marshmallow!

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.



Google Play services 8.1 and Android 6.0 Permissions

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



Make sure that you are handling connection failures on GoogleApiClient correctly, and that you are using the proper resolution process as outlined here. Note that if Google Play services itself is missing permissions, the user flow to fix them will be handled for you automatically if you follow this methodology.

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



Face Detection in Google Play services

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.












Important Note


This is not a face recognition API. Instead, the new API simply detects areas in the image or video that are human faces. It also infers from changes in the position frame to frame that faces in consecutive frames of video are the same face. If a face leaves the field of view, and re-enters, it isn’t recognized as a previously detected face.




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



Google Play services 7.8 - Let’s see what’s Nearby!

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.




Android Developer Story: Zabob Studio and Buff Studio reach global users with Google Play

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.




Android Developer Story: Buff Studio - Reaching global users with Google Play




Android Developer Story: Zabob Studio - Growing revenue with Google Play



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.



A Closer Look at Google Play services 7.5

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.



Android M Developer Preview & Tools

By Jamal Eason, Product Manager, Android







Today at Google I/O, we announced a developer preview of the next version of Android, the M release. Last year’s developer preview was a first for Android and we received great feedback. We want to continue to give you developers early access to Android so you have time to get your apps ready for the next version of Android. This time with the M Developer Preview, we will provide a clear timeline for testing and feedback plus more updates to the preview build.



Visit the M Developer Preview site for downloads and documentation.



The Android M release: improving the fundamentals



For the M release, we focused on improving the core user experience of Android, from fixing thousands of bugs, to making some big changes to the fundamentals of the platform:



  • Permissions - We are giving users control of app permissions in the M release. Apps can trigger requests for permissions at runtime, in the right context, and users can choose whether to grant the permission. Making permission requests right when they’re needed means users can get up and running in your app faster. Also, users have easy access to manage all their app permissions in settings. On M, as a developer, you should design your app to prompt for permissions in context and account for permissions that don’t get granted. As more devices upgrade to M, app permission behavior will be a critical development flow to test.



  • Runtime App Permissions



  • App links - We are making it even easier to link between apps. Android has always allowed apps to register to natively handle URLs. Now you can add an autoVerify attribute to your app manifest so that users can be linked deep into your native app without any disambiguation prompt. App links, along with App Indexing for Google search, make it easier for users to discover and re-engage with your app.


  • Battery - We’re making Android devices smarter about managing power through a new feature called Doze. With M, Android uses significant motion detection to learn if a device has been left unattended for a while. In this state, Android will exponentially back off background activity, trading off a little bit of app freshness for longer battery life. Consider how this may affect your app; for instance, if you’re building a chat app, you may want to make use of high priority messages to wake your app when the device is dozing.



The Android M release: advancing assistance and payments


We are also delighted to announce a couple of big new features:



  • Now on tap - We are making it even easier for Android users to get assistance with Now on tap -- whenever they need it, wherever they are on their device. For example, if your friend texts you about dinner at a new restaurant, without leaving the app, you can ask Google Now for help. Using just that context, Google can find menus, reviews, help you book a table, navigate there, and deep link you into relevant apps. As a developer, you can implement App Indexing for Google search to let users discover and re-engage with your app through Now on tap.



  • Now on tap




  • Android Pay & Fingerprint - We’ve built on our work with Near Field Communications (NFC) in Gingerbread and Host Card Emulation in Kitkat to develop Android Pay. Android Pay will enable Android users to simply and securely use their Android phone to pay in stores or in thousands of Android Pay partner apps. With M, native fingerprint support enhances Android Pay by allowing users to confirm a purchase with their fingerprint. Moreover, fingerprint on M can be used to unlock devices and make purchases on Google Play. With new APIs in M, it’s easy for you to add fingerprint authorization to your app and have it work consistently across a range of devices and sensors.


These are just a few highlights from the M Developer Preview that we announced today. The M preview will be available for download right after the keynote.




Android Developer Tools


In addition to the developer preview, we are launching new tools to help you in the development of your Android App:



  • Android Studio v1.3 Preview - To help take advantage of the M Developer Preview features, we are releasing a new version of Android Studio. Most notable is a much requested feature from our Android NDK & game developers: code editing and debugging for C/C++ code. Based on JetBrains Clion platform, the Android Studio NDK plugin provides features such as refactoring and code completion for C/C++ code alongside your Java code. Java and C/C++ code support is integrated into one development experience free of charge for Android app developers. Update to Android Studio v1.3 via the Canary channel and let us know what you think.



  • Android Studio 1.3 with Android NDK Support



  • Android Design Support Library - Making Material design apps gets even easier with the new Android Design support library. We have packaged a set a key design components (e.g floating action button, snackbar, navigation view, motion enabled Toolbars) that are backward compatible to API 7 and can be added to your app to create a modern, great looking Android app without building everything from scratch.


  • Google Play Services - Today we also are releasing v7.5 of Google Play services which includes new features ranging from Smart Lock for Passwords, new APIs for Google Cloud Messaging and Google Cast, to Google Maps API on Android Wear devices.


Get Started


The M Developer Preview includes an updated SDK with tools, system images for testing on the official Android emulator, and system images for testing on Nexus 5, Nexus 6, Nexus 9, and Nexus Player devices. We are excited to expand the program and give you more time to ensure your apps support M when it launches this fall. Based on your feedback, we plan to update the M Developer preview system images often during the developer preview program. The sooner we hear from you, the more feedback we can integrate, so let us know!



To get started with the M Developer Preview and prepare your apps for the full release, just follow these steps:



  1. Update to Android Studio v1.3+ Preview

  2. Visit the M Developer Preview site for downloads and documentation.

  3. Explore the new APIs & App Permissions changes

  4. Explore the Android Design Support Library and Google Play Services 7.5 APIs

  5. Get the emulator system images through the SDK Manager or download the Nexus device system images.

  6. Test your app with your supported Nexus device or emulator

  7. Give us feedback