Tap. Pay. Next.

Since our launch this Fall, we've seen millions of people set up Android Pay, and the vast majority of them are using tap and pay with their Android devices for the first time. There are now over 1 million locations across the United States that already accept tap and pay, with more being added every day. In short, the response from customers and merchants has been tremendous.

Now we’re ready for the next step: We're working to bring Android Pay's simplicity and security to purchases within apps, and to people in more countries around the world.

Android Pay in apps
Starting today, you’ll be able to use Android Pay to speed through mobile checkout within many of your favorite Android apps in the US.



No more pulling out your credit card while on-the-go. No more errors thanks to clumsy thumbs. Just tap the Android Pay button in the app, confirm your information, and you’re done! And just like your purchases in stores, Android Pay never shares your card details with merchants.

Meet our growing collection of apps
In the next few months, you’ll see more and more of your favorite apps adding Android Pay to help you speed through mobile checkout. For a limited time, you’ll also get special savings by using Android Pay in select apps—from $20 off on OpenTable* dining, $10 off your Lyft ride*, $10 off DoorDash* to 30% off Vinted*—there’s something for everyone. Visit our collection to view all the offers.



Developers: want to add Android Pay to your app? You can visit the Android Pay API developer site to learn how to accept Android Pay for the purchase of physical goods and services. We’ve worked with leading payment providers to make accepting Android Pay a breeze.

Android Pay in more countries
We're also taking the first step to bring the convenience of Android Pay to Android users across the globe. In the first half of 2016, Android Pay will arrive in Australia. We’re working closely with many of Australia’s major financial institutions—including ANZ, Westpac and many other banks—with the aim of bringing Android Pay to their MasterCard and Visa card holders. You will be able to use Android Pay wherever NFC payments are accepted in the country, including merchants such as 7-Eleven, McDonald's and Telstra.

And Australia is just the start. We’ll be adding more countries throughout 2016. This was a big year for Android Pay, and we're excited about what's to come.

Posted by Pali Bhat, Director of Product Management, Android Pay 

* Subject to merchant terms and conditions.

Leveraging product flavors in Android Studio for hermetic testing

Posted by Jose Alcérreca, Developer Programs Engineer and Wojtek Kaliciński, Developer Advocate







During our recent talk at Android Dev Summit, we discuss the state of testing on Android on the example of a simple Notes application that we created as part of our testing codelab. In one section of the talk, we discuss the problem of test flakiness and introduce a simple solution for setting up a hermetic testing environment.



Combatting flaky tests



UI tests with frameworks like Espresso or UI Automator can easily get flaky if the application has external dependencies that can sometimes fail or take long to respond. In short, flaky tests are tests that are not reliable (they can pass or fail randomly) which defeats the whole purpose of having tests in the first place.



A common solution to this problem is hermetic testing or, in other words, making sure that your tests are isolated from dependencies. Using fake implementations or fake servers that just return predefined data is a common way of dealing with this problem. Here are some good examples:




  • Network calls can be made via a fake API client or fake server that immediately returns data from files stored on disk instead of hitting the network. This bypasses the network's latency and flakiness as well as any errors originating on the real server.

  • Interactions with low-level framework APIs (especially those for accessing hardware, like camera or storage) can be passed through an intermediate interface. A fake implementation of this interface could return immediately, providing a reference to preloaded data, such as an image, without relying on the hardware.

  • Any sensors can be replaced with fakes too: GPS, microphone, accelerometer etc., giving you a chance to test on data that would be difficult to provide for the test in real life, like a preset location or a set of inputs simulating a gesture.



Dependency Injection (DI) is a software design pattern that facilitates testing, reusing modules and making them interchangeable. DI frameworks can help you deal with the boilerplate associated with this pattern but it can take a considerable amount of time to set them up and understand how they work. Before you are ready to commit to one of those frameworks for your app, you might want to explore an easier way, especially if your project requirements are simple.



Managing dependencies with product flavors



Product flavors is a powerful feature of Android Studio and our Android Gradle plugin that lets you swap Java classes at compile time and doesn't require additional libraries. Some typical examples of flavor dimensions are:





  • free/paid flavors to generate two different APKs that will be released on your distribution channels

  • stable/experimental to keep experiments in a different source set and generate beta versions quickly



We can leverage the same mechanism to create two separate versions of our app to help with hermetic testing:



  • prod - uses real implementation of services and components, using real data and resources

  • mock - for a version that contains fake implementations of dependencies that are hard to test



The procedure is very simple:



  1. Create the flavors in your app/build.gradle file.
     android {  
    productFlavors {
    mock {
    applicationIdSuffix = ".mock"
    }
    prod
    }
    }

  2. Create two directories: app/src/prod and app/src/mock

  3. Create the class that you want to use for production code in the prod/java folder or move it from main/java. Make sure the main/java folder does not contain this class.
  4. Create the same class (with the exact same class and file name) in the mock/java folder, but providing a different (fake) implementation that will be used for tests.
  5. In the Build Variants window in Android Studio, choose the variant that you want to install or run tests against. A variant is the combination of a flavor and a build type.


Note: In gradle, the task names change when you add flavors. Instead of installDebug, you will now have to choose installProdDebug or installMockDebug.



Running your tests



With the prod and mock flavors configured and your mock implementation in place, you can now use the following gradle tasks to choose how your tests should run:




  • connectedMockDebugAndroidTest will merge the androidTest and androidTestMock directories and run every test found in the resulting source set. As these tests are run in a hermetic way, they will be faster and less flaky. This is ideal for a pre-submit check.

  • connectedProdDebugAndroidTest will use the real APIs and sensors so they might fail from time to time. If you have a Continuous Integration system, this task could be executed every night or used manually as a acceptance end-to-end test. Note that this task will run the tests in androidTest even if androidTestProd doesn't exist.



You can refer to our Android Testing Codelab to see how we used this method to provide different Injection class implementations, the one in prod providing real data and the other (mock) serving fake dependencies that use fake data for isolated test execution.



When you’re happy with your hermetic setup, you might want to give more flexibility to your build process and add even more dimensions to be able to interchange different components in your app. While the method discussed above is suitable for simple projects, for more complex situations it would be much better to invest some time to learn about and add a Dependency Injection framework to your project.






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 Studio 2.0 Preview: Android Emulator


Posted by, Jamal Eason, Product Manager, Android





An early preview of the new Android Emulator is now available to try out. As a part of Android Studio 2.0, the latest version of the Android Emulator can help you test your app on a wide range of screens size and configurations beyond the physical Android hardware you use to test.Moreover, using the official Android emulator enables you to test with latest Android versions. Building on this foundation, the top two benefits of new Android emulator are:



  • Speed & Performance: When emulating the latest Android 6.0 release (Marshmallow), we now support Symmetric Multi-Processing and have made significant I/O improvements in both the emulator and ADB. This means you will have faster performance when you are testing your app.




  • Usability & User Interface: The new Android Emulator includes a brand new user interface to make the emulator easy to use. You no longer have to rely on command-line parameters to use the Android emulator. Common tasks and emulator features are now just a mouse click or a keyboard shortcut away.


We previewed the user interface at the Android Dev Summit. You can try it out today along with the new version of ADB for faster APK installation and file transfers to the emulator. Check out the video for a demonstration of the new Android Emulator.







Android Dev Summit 2015: Emulator Demo


We are seeking early feedback to continue to deliver the experience and features that will make you more productive.


New Features in Android Emulator Preview




Performance Improvements




  • CPU Performance




    Android Studio now uses CPU acceleration on x86 emulator system images by default. Combined with new Symmetric Multi-Processor (SMP) support in Android 6.0 Marshmallow system images, the Android emulators can perform even faster than many physical Android devices. Multi-core support not only makes your apps and the emulator run faster but it provides the added advantage of speeding up common developer tasks such as installing APKs. Also, with SMP you can test apps that specifically target multi-processor Android devices.




  • Faster ADB




    In addition to faster CPU speeds in the emulator, there are a number of under-the-hood improvements that will make the experience faster. One of the bottlenecks in the development process that we worked on is the speed of pushing data between Android Studio and your device using ADB (Android Debug Bridge). When you use Android 6.0 Marshmallow and higher system images with the new Android Emulator, you can now push files across ADB up to five times faster than a real device. This will help you if you push large APK or files during your app development cycle.




User Interface






  • Toolbar


    The new interface exposes some of the most common emulator actions in a new toolbar and control panel instead of solely relying on command line options. For the preview, the Android Emulator toolbar enables actions, such as volume control, screen rotation, and screen-shots of the emulator window.








  • Window Zooming & Scaling


    Now you can resize your window simply by dragging a corner. You can also zoom and scroll to get a closer look at a portion of your screen.










Left: Zooming
Right: Window Scaling






  • Drag & Drop


    With the new emulator, you can not only drag and drop APKs for quick installation, but you can also drag and drop any file to your emulator’s internal SD card to help in testing.





Drag and Drop Files




  • Extended UI Controls


    In the extended controls window, additional options help you validate and test features in your app. As shown below, you can initiate a range of emulator actions such as making a virtual call, sending a virtual SMS, or controlling the power level of the emulator. You can additionally send a single GPS location point to the emulator or play back a custom set of KML or GPX points as well.





Phone Controls




Battery Controls

We are continuing to add more functionality and we will keep you up to date as we add more features.



What's Next & Setup


This is just the beginning of developments on the Android Emulator, so expect more features such as support more APIs levels, and adding more sensors with future versions of Android Studio. The new emulator along with Android Studio are available today on the Android Studio canary channel and tools preview channel.



Click here for details on how to setup the preview of the new Android Emulator.


We appreciate your feedback. Connect with us, the Android Studio development team, on Google+.



Google Play Music: Now playing for your family

In a family of music lovers, there’s a soundtrack playing throughout our daily lives. My husband likes to listen to The Smiths radio while he works; I like Entering Beast Mode stations when I hit the gym; and we listen to Michael Bublé as a family while we cook dinner. What can I say, we’re a pretty fun bunch! But it means my family ends up paying for multiple subscription music accounts which can add up over time.

For families like mine, we’re happy to start offering the Google Play Music family plan today. With the family plan, you and up to five family members can subscribe to Google Play Music - together - for just $14.99 per month. You’ll unlock all of the same features you’d get from having individual subscriptions, including ad free, unlimited access to more than 35 million songs and the ability for each family member to stream simultaneously on any device, all for one low price. Now, you can keep your listening experiences separate from your partner and get music recommendations tailored to the music you like. So, my husband’s Depeche Mode singles will never show up in my account - only my true favorites will be front and center. And a family plan on Google play will also get your family access to YouTube Red in the US.
You and your family will be able to sign up for a Google Play Music family plan in the coming days on Android devices in the US, Canada, the UK, Australia, France and Germany, with more countries coming soon. You and your family members can listen on Android, iOS and the web.

Posted by Eunice Kim, product manager for Google Play

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





API Updates for Sign-In with Google

Posted by Laurence Moroney



With the release of Google Play services 8.3, we’ve made a lot of improvements to Sign-In with Google. In the first blog post of this ongoing series, we discussed the user interface improvements. Today, we will look further into the changes to the API to make building apps that Sign-In with Google easier than ever before.



Changes to basic sign in flow


When building apps that sign in with Google, you’ll notice that there are a lot of changes to make your code easier to understand and maintain.



Prior to this release, if you built an app that used Sign-In with Google, you would build one that attempted to connect to a GoogleApiClient. At this point the user was presented with an account picker and/or a permissions dialog, both of which would trigger a connection failure. You would have to handle these connection failures in order to sign in. Once the GoogleApiClient connected, then the user was considered to be signed in and the permissions could be granted. The process is documented in a CodeLab here.



Now, your code can be greatly simplified.



The process of signing in and connecting the GoogleApiClient are handled separately. Signing in is achieved with a GoogleSignInOptions object, on which you specify the parameters of the sign in, such as scopes that you desire. Here’s a code example:



 GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)  
.requestEmail()
.build();


Once you have a GoogleSignInOptions object, you can use it to configure the GoogleApiClient:



Here’s where your code will diverge greatly in the new API. Now, if you want to connect with a Google Account, instead of handling errors on the GoogleApiClient, you’ll instead use an intent that is initialized using the client.



Intent signInIntent = Auth.GoogleSignInApi.getSignInIntent(mGoogleApiClient);
startActivityForResult(signInIntent, RC_SIGN_IN);


Starting the intent will give you the account picker, and the scopes permission dialog if your GoogleSignInOptions requested anything other than basic scope. Once the user has finished interacting with the dialogs, an OnActivityResult callback will fire, and it will contain the requisite sign-in information.




 @Override  
public void onActivityResult(int requestCode, int resultCode, Intent data) {
super.onActivityResult(requestCode, resultCode, data);
// Result returned from launching the Intent from GoogleSignInApi.getSignInIntent(...);
if (requestCode == RC_SIGN_IN) {
GoogleSignInResult result = Auth.GoogleSignInApi.getSignInResultFromIntent(data);
handleSignInResult(result);
}
}



You can learn more about this code in the Integrating Google Sign-In quickstart, or by looking at the sample code.



Silent Sign-In


To further reduce friction for users in a multi-device world, the API supports silent sign in. In this case, if your user has given authorization to the app on a different device, the details will follow their account, and they don’t need to re-give them on future devices that they sign into, unless they deauthorize. An existing sign-in is also cached and available synchronously on the current device is available.



Using it is as simple as calling the silentSignIn method on the API.



OptionalPendingResult opr = 
Auth.GoogleSignInApi.silentSignIn(mGoogleApiClient);


Then, you can check the isDone() method on the pending result -- and if it returns true, the user is signed in, and you can get their status from the PendingResult. If it isn’t then you have to wait for a callback with the SignInResult




 if (pendingResult.isDone()) {  
doStuffWith(pendingResult.get());
} else {
// There's no immediate result ready, displays some progress indicator and waits for the
// async callback.
showProgressIndicator();
pendingResult.setResultCallback(new ResultCallback<GoogleSignInResult>() {
@Override
public void onResult(@NonNull GoogleSignInResult result) {
updateButtonsAndStatusFromSignInResult(result);
hideProgressIndicator();
}
});
}


Customizing the Sign-In Button


When building apps that Sign-In with Google, we provide a SignInButton object that has the Google branding, and which looks like this:






You can customize this button with a number of properties and constants that are documented in the API here.



The branding guidelines are available here, and they include versions of the buttons in PNG, SVG, EPS and other formats in many resolutions, including all the different states of the button. These files may be used for localization of the button, and if you need to match the style of the button to your app, guidelines are provided.



This only deals with the Android side of your app. You’ll likely have a server back end, and you may want to use the credentials on that securely.



In the next blog post, we’ll discuss how to use Sign-In with Google in server-side scenarios, including how to securely pass your credentials to your own server, and how to use Google back-end services, such as Google Drive, with the permission and credentials from users.