Tag Archives: Google Play services

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

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.

An updated app guide and new video tips to help you find success on Google Play

Posted by Dom Elliott, The Google Play Apps & Games team

Last year, we introduced our first playbook for developers, “The Secrets to App Success on Google Play”, to help you grow your app or game business, which has been downloaded more than 200,000 times.. Many new features have since been announced on the platform – from Store Listing Experiments and beta testing improvements to App Invites and Smart Lock for Passwords.

Get the second edition of “The Secrets to App Success on Google Play”

Hot off the press, you can now download the second edition to learn about all the new tools and best practices for improving the quality of your app, growing a valuable audience, increasing engagement and retention, and earning more revenue.

Get the book on Google Play in English now or you can sign-up to be notified when the booklet is released in the following languages: Bahasa Indonesia, Deutsch, español (Latinoamérica), le français, português do Brasil, tiếng Việt, русский язы́к, ไทย, 한국어, 中文 (简体), 中文 (繁體), 日本語. Based on your feedback, the guide was updated to work seamlessly in the Google Play Books app. If you prefer, you can also download a PDF version from the Android Developers website.

New videos with tips to find success on Google Play

To accompany the guide, watch the first two episodes in a new ten-part video series of actionable tips you can start using today to achieve your business objectives. Subscribe to the Android Developers channel on YouTube and follow +Android Developers to watch the new videos as they’re released weekly.

Two new videos will be released each week in the ten-part series
on the Android Developer YouTube channel.

Let us know your feedback

Once you’ve checked out the guide and the videos, we’d again love to hear your feedback so we can continue to improve our developer support, please let us know what you think.

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.

Developer tips for success with Player Analytics and Google Play games services

Posted by, Lily Sheringham, Developer Marketing at Google Play

Editor’s note: As part of our series featuring tips from developers, we spoke to some popular game developers to find out how they use Player Analytics and Google Play game services to find success on Google Play. - Ed.

Google Play games services, available in the Developer Console, allows you to add features such as achievements and leaderboards to your games. Google Play games services provides Player Analytics, a free games-specific analytics tool, in the Developer Console Game services tab. You can use the reports to understand how players are progressing, spending, and churning backed by a data-driven approach.

Bombsquad grows revenue by 140% per user with Player Analytics

Independent developer Eric Froemling, initially created the game Bombsquad as a hobby, but now relies on it as his livelihood. Last year, he switched the business model of the game from paid to free-to-play. By using Player Analytics, he was able to improve player retention and monetization in the game, achieving a 140% increase in the average revenue per daily active user (ARPDAU).

Watch the video below to learn how Eric uses Player Analytics and the Developer Console to improve gamers’ experience, while increasing retention and monetization.



Tips from Auxbrain for success with Google Play games services

Kevin Pazirandeh, founder and CEO of games developer Auxbrain, creator of Zombie Highway, provides insight into how they use Google Play games services, and comments:

“While there are a few exceptions, I have not run into a better measure of engagement, and perhaps more importantly, a measure for change in engagement, than the retention table. For the uninitiated, a daily retention table gives you the % of players who return on the nth day after their first play. Comparing retention rates of two similar games can give you an immediate signal if you are doing something right or wrong.”

Kevin shares his top tips on how to best use the analytics tools in Google Play games services:

  1. You get Player Analytics for free - If you’ve implemented Google Play game services in your games, check out Player Analytics under Game services in the Developer Console, you’ll find you are getting analytics data already.
  2. Never assume change is for the better - Players may not view changes in your game as the improvement you had hoped they were. So when you make a change, have a strategy for measuring the result. Where you cannot find a way to measure the change’s impact with Player Analytics, consider not making it and prioritize those changes you can measure.
  3. Use achievements and events to track player progress - If you add achievements or events you can use the Player progression report or Event viewer to track player progress. You’ll quickly find out where players are struggling or churning, and can look for ways to help move players on.
  4. Use sign-in to get more data - The more data about player behavior you collect, the more meaningful the reports in Player Analytics become. The best way to increase the data collected is to get more players signed-in. Auto sign-in players, and provide a Play game services start point on the first screen (after any tutorial flow) for those that don’t sign-in first time.
  5. Track your player engagement with Retention tables - The Retention table report lets you see where players are turning away, over time. Compare retention before and after changes to understand their impact, or between similar games to see if different designs decisions are turning players away earlier or later.

Get started with Google Play Games Services or learn more about products and best practices that will help you grow your business on Google Play globally.

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, Magnus Hyytsten, 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

Barcode Detection in Google Play services

Posted by Laurence Moroney, Developer Advocate

With the release of Google Play services 7.8 we’re excited to announce that we’ve added new Mobile Vision APIs which provides the Barcode Scanner API to read and decode a myriad of different barcode types quickly, easily and locally.

Barcode detection

Classes for detecting and parsing bar codes are available in the com.google.android.gms.vision.barcode namespace. The BarcodeDetector class is the main workhorse -- processing Frame objects to return a SparseArray<Barcode> types.

The Barcode type represents a single recognized barcode and its value. In the case of 1D barcode such as UPC codes, this will simply be the number that is encoded in the barcode. This is available in the rawValue property, with the detected encoding type set in the format field.

For 2D barcodes that contain structured data, such as QR codes, the valueFormat field is set to the detected value type, and the corresponding data field is set. So, for example, if the URL type is detected, the constant URL will be loaded into the valueFormat, and the URL property will contain the desired value. Beyond URLs, there are lots of different data types that the QR code can support -- check them out in the documentation here.

When using the API, you can read barcodes in any orientation. They don’t always need to be straight on, and oriented upwards!

Importantly, all barcode parsing is done locally, making it really fast, and in some cases, such as PDF-417, all the information you need might be contained within the barcode itself, so you don’t need any further lookups.

You can learn more about using the API by checking out the sample on GitHub. This uses the Mobile Vision APIs along with a Camera preview to detect both faces and barcodes in the same image.

Supported Bar Code Types

The API supports both 1D and 2D bar codes, in a number of sub formats.

For 1D Bar Codes, these are:

AN-13
EAN-8
UPC-A
UPC-E
Code-39
Code-93
Code-128
ITF
Codabar

For 2D Bar Codes, these are:

QR Code
Data Matrix
PDF 417

Learn More

It’s easy to build applications that use bar code detection using the Barcode Scanner 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 Mobile Vision Documentation

Explore the sample