Home Android: Google Play services

Home / Google Play services

Showing posts with label Google Play services. Show all posts

Friday, November 6, 2015

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.

Friday, September 25, 2015

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

Android Android Developer Google Play services Support Library

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!

Google Play services Marshmallow permissions SDK updates

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

Android Developer Google Play services 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

Home Android