Posted by Mark Thomas, Product Manager, Google Wallet

A key focus of Google Wallet is to simplify commerce for merchants and shoppers; for over a year now, consumers on Google Play have been using Wallet to make their purchases, to the benefit of the entire ecosystem. Helping merchants benefit from the growing consumer adoption of mobile commerce is where we believe we can make the most impact. And that’s why today we're focusing our efforts on the new Google Wallet Merchant Center and retiring Google Checkout over the next six months.

Most Google Play apps developers will seamlessly transition to the Wallet Merchant Center, which provides new reporting and analytics features and much more. A small number of Google Play developers, however, will see some changes:

• Developers using Google Checkout on their website to sell physical goods or services will no longer be able to use Checkout after November 20, 2013. We have provided some discounted migration options to help with this change. If you are a U.S. merchant selling physical goods and services who does have payment processing, you can apply for Google Wallet Instant Buy, which offers a fast buying experience to Google Wallet shoppers.
• Developers who use the Google Checkout for the Notifications and/or Order Reports API(s) will need to migrate to replacement APIs, made available through Google Play, before November 20, 2013. Watch for announcements on the new APIs soon.

If you sell apps or in-app products in Google Play, you’ll soon have access to the new Wallet Merchant Center. Watch for an email notifying you that that it’s now available to you. We expect to transition all merchants to the Wallet Merchant Center over the next several weeks.

We invite you to join us for our live merchant webinar on May 23, 2013 at 10AM PDT to learn more and ask any outstanding questions. As always, feel free to contact us at any time during this transition. Finally, be sure to check out the exciting updates launched last week at Google I/O (including Instant Buy and Wallet Objects) and stay tuned for more great developer features coming soon!

Posted by Xavier Ducrohet, Tor Norbye, Katherine Chou

Today at Google I/O we announced a new IDE that’s built with the needs of Android developers in mind. It’s called Android Studio, it’s free, and it’s available now for you to try as an early access preview.

To develop Android Studio, we cooperated with JetBrains, creators of one of the most advanced Java IDEs available today. Based on the powerful, extensible IntelliJ IDEA Community Edition, we've added features that are designed specifically for Android development, that simplify and optimize your daily workflow.

Extensible build tools

We know you need a build system that adapts to your project requirements but extends further to your larger development environment. Android Studio uses a new build system based on Gradle that provides flexibility, customized build flavors, dependency resolution, and much more.

This new build system allows you to build your projects in the IDE as well as on your continuous integrations servers. The combination lets you easily manage complex build configurations natively, throughout your workflow, across all of your tools. Check out the preview documentation to get a better idea of what the new build system can do.

Powerful code editing

Android Studio includes a powerful code editor. It's based on the IntelliJ IDEA editor, which supports features such as smart editing, advanced code refactoring, and deep static code analysis.

Smart editing features such as inline resource lookups make it easier to read your code, while giving you instant access to edit code the backing resources. Advanced code refactoring gives you the power to transform your code across the scope of the entire project, quickly and safely.

We added static code analysis for Android development, helping you identify bugs more quickly. On top of the hundreds of code inspections that IntelliJ IDEA provides, we’ve added custom inspections. For example, we’ve added metadata to the Android APIs, that flag which methods can return null and which can’t, which constants are allowed for which methods, and so on. Android Studio uses that data to analyze your code and find potential errors.

Smoother and richer GUI

Over the past year we’ve added some great drag-and-drop UI features to ADT and we’re in the process of adding them all into Android Studio. This release of Android Studio lets you preview your layouts on different device form factors, locales, and platform versions.

Easy access to Google services
within Android Tools

We wanted to make it easy for you to harness the power Google services right from your IDE. To start, we’ve made it trivial to add services such a cloud-based backend with integrated Google Cloud Messaging (GCM) to your app, directly from the IDE.

We’ve also added a new plugin called ADT Translation Manager Plugin to assist with localizing your apps. You can use the plugin to export your strings to the Google Play Developer Console for translation, then download and import your translations back into your project.

Open source development

Starting next week we’ll be doing all of our development in the open, so you can follow along or make your own contributions. You can find the Android Studio project in AOSP at https://android.googlesource.com/platform/tools/adt/idea/

Try Android Studio and give us feedback

Give Android Studio a try and send us your feedback! It's free, and the download bundle includes includes everything you need, including the IDE, the latest SDK tools, the latest Android platform, and more. .

Note: This is an early access preview intended for early adopters and testers who want to influence the direction of the Android tools. If you have a production app with a large installed base, there’s no need to migrate your development to the new tools at this time. We will continue to support Eclipse as a primary platform for development.

If you have feedback on the tools, you can send it to us using the Android Studio issue tracker.

Join the discussion on

+Android Developers

Posted by Ellie Powers, Google Play team

This week at I/O, we were excited to announce some updates to Google Play to help you optimize your business on Google Play: to help you take control of your app publishing, gain insight into your users, and expand your app’s success globally.

Play Store’s new view: apps designed for tablets

Many of you have invested in making great tablet experiences for your users, and we want to ensure that that work pays off and that users are able to discover great apps for their tablets. This week, the Google Play store began providing a view of our top charts highlighting apps which have been designed for tablets according to our tablet app quality checklist.

Be sure you don’t miss out! Check that your app’s optimization tips say that your app is designed for tablets, and upload tablet screenshots for 7” and 10” tablets.

Beta testing and staged rollouts

We have introduced support for beta testing and staged rollouts so that you can get feedback on your new app or app update early in its development and make sure your users are happy with the results. You can test two different versions on two different groups at the same time, such as testing a newer version with your employees first, and a more mature version with a group of external testers.

The beta testing is private on Google Play, and you can specify who gets these versions by adding Google Groups and Google+ Communities. Users give you feedback privately rather than through public reviews. When you’re satisfied that your new version is ready, you can now do a staged rollout to a percentage of your userbase. To give you more flexibility in light of beta testing and help get your whole team involved in the Developer Console, we will soon launch additional access controls.

Localization improvements

We’re collaborating with Google's internationalization team to make translating your app into new languages easier than ever. You can purchase professional translations of your apps from independent providers through the Google Play Developer Console. You can upload the strings you want translated, select the languages you want to translate into, and select your translation vendor based on time and price. If you’re interested in translating your apps with this feature, sign up to be a part of the preview in the Developer Console today on the APK page.

The new optimization tips for localization will help you identify new potential opportunities for global expansion based on popular languages for your app’s users and category. To fully localize your app into a language, you need to translate the strings in an APK, translate your Google Play store listing, and upload localized graphics. The optimization tips will also let you know if you’re missing any of these pieces.

New Analytics and monetization features

Getting better revenue and engagement data has been another key developer request, as developers told us that they check their revenue and stats constantly. New revenue charts in the Developer Console allow you to see your app’s daily revenue and summary figures, and you can filter the data by country. Coming soon, Google Play and Google Analytics are teaming up to bring you better insight into your users. Google Analytics will start showing Google Play views and installs for each campaign, while Google Play will show Google Analytics engagement metrics.

For those of you using in-app billing, we’ve heard your feedback and made some improvements to reduce your development time and costs. Your test accounts will now able to make in-app test purchases without those transactions actually being charged, but everything else works the same as it would for a real user.

In a few weeks, we will launch a new Order Status API, which allows you to verify the status of an in-app order from your servers. We will also be launching a tool for automating downloads of financial reports. Finally, the new Google Wallet Merchant Center is continuing to roll out with enhanced reporting, additional analytics and many other enhancements.

Google Play for Education coming soon

You'll soon be able to offer apps to schools through Google Play for Education, which launches later this year to K-12 schools in the United States. This online destination will allow schools to discover, purchase, and distribute apps to their students. Visit developer.android.com/edu to get started creating or optimizing your apps for schools today.

Join the discussion on

+Android Developers

Posted by Greg Hartrell, Angana Ghosh, Francesco Nerieri, Francis Ma, and the Google Play services team

Some of the most exciting Android announcements at Google I/O this year are part of our latest Google Play services release, version 3.1.

The new version brings you Google Play games services, part of a new cloud-integrated platform for social gaming based on Google+ identity. Also included are location-based services that make it easier to build efficient location-aware apps. For apps using the popular Google Cloud Messaging platform, you can now take advantage of XMPP messaging and easier setup. Finally, Cross-Platform Single Sign On for Google+ Sign-In is now available to your apps.

You can get started using these APIs and services right away—Google Play services 3.1 is already rolling out to Android devices across the world, with support reaching all the way back to Froyo.

Google Play games services

Games are always popular with Android developers, and the announcement of Google Play game services raised the volume even more.

Google Play games services lets you make your games more social, with achievements, leaderboards, and multiplayer, and they help you extend your user’s games across multiple devices by storing game saves and settings in the cloud.

Several great Android games are already using these new game services, including World of Goo, Super Stickman Golf 2, Beach Buggy Blitz, Kingdom Rush, Eternity Warriors 2, and Osmos.

You can take advantage of the new services right away using the games services SDK included in Google Play services. For all the details, check out the Google Play games services documentation.

Location APIs

If you build location-aware Android apps, you’ll want to check out the new location APIs. They make it easy to build accurate, fast, and efficient apps, with new contextual features.

The Fused Location Provider intelligently manages the underlying location technology and gives you the best location according to your needs. We’ve simplified the location APIs and completely rewritten our location algorithm to make location more accurate, flexible and use less battery.

Using the new geofencing API, your app can set up geographic boundaries around specific locations and then receive notifications when the user enters or leaves those areas.

With apps becoming increasingly contextual, understanding what the user is doing is critical to surfacing the right content. A new activity recognition API makes it easy to check the the user’s current activity — still, walking, cycling, and in-vehicle — with very efficient use of the battery. We use low-power sensors and machine-learning classifiers to recognize the activity, giving you both both high accuracy and low battery usage.

To learn more, head over to our training classes at Making Your App Location Aware or dive directly into the reference docs.

Google Cloud Messaging

We’ve added APIs to make it easier to set up GCM in your apps, and in the service itself we’ve added new messaging capabilities for your apps to use.

A new registration API lets your app register with the service using a single method call and begin receiving messages as soon as the call returns.

Sign Up for Early Access

If you’d like to try out CCS messaging or the User Notifications API, please sign up for early access.

In the GCM service itself we’ve added support for messaging over XMPP with the new GCM Cloud Connection Server (CCS). Your servers now have a persistent connection over which to send large numbers of messages, very quickly, and with no overhead. New APIs in Google Play services let apps send messages back upstream to third-party servers using CCS, without needing to manage network connections. This helps keep battery and data usage to a minimum.

Also new in the GCM service is a User Notifications API. This new API lets you synchronize notifications across a user’s multiple devices — when the user dismisses a notification on one device, the notification disappears automatically from all the other devices. To get started with GCM, head over to the developer documentation.

Google+ Cross-Platform Single Sign On

Many people use apps on multiple devices throughout the day, switching between their laptops, tablets, and mobile devices. After signing-in to an app on one device, it’s natural that when they pick up a different device and use the same app, they would expect to be signed in there as well.

To help you provide this kind of seamless transition between platforms and stay connected with users across devices, we’re adding Cross-Platform Single Sign On to our Google+ Sign-In capabilities.

If your app is already using Google+ Sign-In, you’ve already got support for Cross-Platform Single Sign On. This feature will be enabled automatically over the coming days.

Cross-Platform Single Sign On gives you a great way to build longer-running, cross-platform user experiences, and it dovetails perfectly with the new Google Play games services for bridging game state across devices using the cloud.

To learn more about Google+ Sign-In, check out http://developers.google.com/+.

More About Google Play Services

Google Play Services is our platform for offering you better integration with Google products, and providing new capabilities to use within your apps. To learn more about Google Play services and the APIs available to you through it, visit the Google Services area of the Android Developers site.

Join the discussion on

+Android Developers

The last year has been an exciting one for Android developers, with an incredible amount of momentum. In fact, over 48 billion apps have been downloaded from Google Play to date, with over 2.5 billion app downloads in the last month alone.

This week, at Google I/O, our annual developer conference, we’re celebrating this momentum, and putting on stage a number of new features and advancements both for the Android platform and Google Play, to help you design, develop and distribute great apps to your users.

We just wrapped up the keynote, and wanted to share a number of those new features; we’ll be spotlighting some of them throughout the week both here, on Google+, and in 36 Android sessions and sandboxes at the Moscone center in San Francisco (with many of the sessions livestreamed at developer.google.com). Enjoy!

Google Play Services 3.1

Google Play Services is our platform for bringing you easier integration with Google products and new capabilities to use in your apps. Today we announced a new version of Google Play Services that has some great APIs for developers.

• Google Play games services give you great new social features that you can add to your games   achievements, leaderboards, cloud save, and real-time multiplayer
• Location APIs make it easy to add location- and context-awareness to your apps through a fused location provider, geofencing, and activity recognition
• Google Cloud Messaging enhancements let you use bidirectional XMPP messaging between server and devices and dismiss notifications
• Cross-Platform Single Sign On, which lets your users sign in once, for all of their devices using Google+ Sign-In.

Android Studio: A new IDE for Android development

Today we announced a new Integrated Development Environment (IDE) built just for Android, with the needs of Android developers in mind. It’s called Android Studio, it’s free, and it’s available now to try as an early access preview.

To build Android Studio, we worked with with JetBrains, creators of one of the most advanced Java IDEs available today. Based on the powerful, extensible IntelliJ IDEA Community Edition, we've added features and capabilities that are designed specifically for Android development, to simplify and optimize your daily workflow for creating Android apps.

Google Play Developer Console: a better distribution experience

Building awesome Android apps is only part of the story. Today we announced great new features in the Google Play Developer Console that give you more control over how you distribute your app and insight into how your app is doing:

• App translation service: a pilot program that lets you purchase professional translations for your app directly from the Developer Console.
• Revenue graphs: a new tab in the Developer Console gives you a summary of your app global app revenue over time.
• Alpha and beta testing and staged rollouts: you can now distribute your app to controlled alpha and beta test groups, or do staged rollouts to specific percentages of your userbase.
• Optimization tips: design your app for tablets and understand how to expand your app into new language markets.
• Google Analytics: launching later this summer, your Google Analytics usage stats will be viewable right in the Developer Console.
• Referral tracking: also launching later this summer, you’ll get a new report in Google Analytics to show what blogs, campaigns, and ads are driving your installs.

Follow the Android Sessions

Join us for the Android sessions today and through the week by livestream. Visit the I/O Live Stream schedule for details.

Posted by Ellie Powers, Google Play team

There are a lot of great things a developer can do to promote their app, but the best way for your app to take off is when a really happy user tells their friend about your app, who tells their friend, who tells someone else — you get the picture.

That’s why it’s always been a priority for us to strengthen that conversation between developers and their users. Google Play is now connected with Google+, and by associating reviews with an identity, the quality of reviews has increased tremendously (in addition to letting users find reviews they trust).

We’re happy to announce today that all developers on Google Play can now reply to user reviews. You can reply to user reviews in the Google Play Developer Console, and your replies are shown publicly below the corresponding user review on Google Play. Users receive an email notification when you reply and can either reply to you directly by email, or update their review if they choose to do so -- though keep in mind that users are not obligated to update their reviews. You can also update your reply at any time.

Developers who have been using this feature have told us that the following best practices are most effective in improving their apps and building strong relationships with their users:

• Check reviews frequently, and involve people from all parts of your organization
• Identify and prioritize bugs based on user impact
• Let users know when their problems are resolved
• Reply constructively to both negative and positive reviews
• Refer users to documentation or other support channels
• Get ideas about new improvements or features
• Thank the users who are your biggest advocates

Before replying to user reviews, it is important to review the posting guidelines to be sure that you are using this feature in compliance with Google Play’s policies at all times. The reply to each user’s review will be public, so prospective users will see if you provide consistently high quality customer support. Read the posting guidelines, and start connecting with users today.

Conversations are meant to be two-sided, and facilitating discussion between developers and users will ultimately yield better apps, to the benefit of everyone.

Join the discussion on

+Android Developers

Posted by Reto Meier, Android Developer Relations Tech Lead

Google I/O 2013 is less than a week away, and the full session schedule - featuring 34 Android sessions (and 3 codelabs) - is now available. We have great Android content spread across three packed days - covering everything from design, development, and distribution.

Not everyone can come to San Francisco to join us in person, so we’ll be streaming a selection of the best content as part of Google Developers Live. In addition to the keynote and four session streams (including one dedicated to Android), you’ll see one-on-one product deep dives, executive interviews, and Sandbox walkthroughs broadcast from the GDL stage at I/O. All the live feeds will be available on the Google I/O homepage from the comfort of your own home - or join our Google Developer Groups to experience Google I/O as part of Google I/O Extended.

Whether you’re attending in person or virtually, you can follow all the action using the official Google I/O 2013 conference companion app! It supports devices running Android 2.3+, and is optimized for phones and tablets of all shapes and sizes.

Use it to view the conference sessions agenda and create your own personal schedule with reminders, view details on sessions, code labs, office hours, and speakers, track announcements, and even view the keynote and live streamed sessions throughout the conference!

If you’re attending in person, you can use it to guide yourself around the venue using the vector-based conference map, Android Beam session details, scan fellow attendee badges, and provide feedback on the sessions you watch.

And stay tuned after I/O when every Google I/O technical session will also be posted to GDL and YouTube, and the conference app will be open sourced.

Posted by Ellie Powers, Google Play team

Last week we updated our guidelines for making great tablet apps and added the ability to upload tablet screenshots that are shown preferentially in Google Play to users on those devices. Today we’re introducing a new Optimization Tips page in the Google Play Developer Console that lets you quickly see how your app is doing against basic guidelines for tablet app distribution and quality.

When you upload an app, the Developer Console now runs a series of checks to verify basic criteria from the Tablet App Quality Checklist and shows you any issues it finds in the Optimization Tips page.

If you’re developing for tablets, make sure to visit your Optimization Tips page to ensure that your app is delivering a great tablet experience. If there are any issues listed, we recommend addressing them in your app as soon as possible and uploading a new binary for distribution, if needed.

For ideas on how to design and build a great tablet app, including details on how to address issues listed in your Optimization Tips page, check out the Tablet App Quality Checklist. Remember that a great tablet experience goes well beyond these basic checks. Keep working to bring your tablet users the most polished UI and richest content possible.

Join the discussion on

+Android Developers

Posted by Ellie Powers, Google Play team

More and more, developers are investing in a full tablet experience for their apps and seeing those investments pay off big. Starting today, it’s even easier to show off those tablet apps to users and to understand what it takes to make a great tablet app.

Many of you have already made optimizations to your apps to make them more beautiful and useful on tablets, and we’re giving you a way to showcase your application’s specialized tablet layouts. You’re now able to upload screenshots of your app running on 7” and 10” tablets to the Google Play Developer Console, and those screenshots are shown preferentially in Google Play to users on those devices.

In October, we published the tablet app quality checklist, which shares best practices for creating tablet applications that users will love. We've updated this checklist with additional tips and guidelines, as well as more details on specific technical checks you should perform to ensure your app is correctly optimized for tablets. Soon, we’ll start surfacing tips based on our tablet app quality guidelines directly in the Google Play Developer Console, and we’ll use these guidelines to help users better discover tablet apps in Google Play.

So upload your tablet screenshots and confirm your app follows the quality guidelines today.

Join the discussion on

+Android Developers

Posted by Purnima Kochikar, Director of Business Development, Games & Applications

Today we announced that a new version of the Google Play Store app is rolling out worldwide to Android phones and tablets. This new app brings a redesigned UI that’s easier to use and showcases more great content for users. For developers, the new app offers more ways for your app to get noticed, as well as a new, simpler purchase flow.

The new UI is simple and easier to browse. Collections are front and center on the homepage, helping users discover great content through recommendations and curated lists. Items in collections are now presented as cards, with a larger area for your app’s graphics and a larger touch target for users. Overall, the homepage surfaces more apps than before and highlights them more effectively right on the page.

Most important for apps that sell in-app products, the new UI offers a dramatically simplified, dialog-based purchase flow that lets users buy your products without leaving the context of the app. Your app remains active and visible behind the purchase dialogs. When the purchase is complete, users return directly to the place they left, without your app having to reconstruct its state. It’s especially powerful when combined with In-app Billing v3, providing a faster and more reliable purchase flow.

All of these changes build on the core features of Google Play. Our editorial team will continue to look for exemplary apps to showcase in Editors’ Choice and other collections, and our familiar top lists will continue to track the market performance of your app on an ongoing basis.

Watch for the new Play Store app (version 4.0.25) coming to your devices soon. The rollout has already started and we expect all devices running Android 2.2 or higher to have received the update over the next few weeks.

Posted by Bruno Oliveira of the Android Developer Relations Team

In-app Billing has come a long way since it was first announced on Google Play (then Android Market). One year and a half later, the vast majority of top-grossing apps on Google Play use In-app Billing and thousands of developers monetize apps through try-and-buy, virtual goods, as well as subscriptions.

In-app Billing is expanding again, making it even more powerful and flexible so you can continue to build successful applications. Version 3 introduces the following new features:

• An improved design that makes applications simpler to write, debug and maintain. Integrations that previously required several hundred lines of code can now be implemented in as few as 50.
• More robust architecture resulting in fewer lost transactions.
• Local caching for faster API calls.
• Long-anticipated functionality such as the ability to consume managed purchases and query for product information.

In-app Billing version 3 is available now and lets you sell both in-app items and (since February 2013) subscriptions, including subscriptions with free trials. It is supported by Android 2.2+ devices running the latest version of the Google Play Store (over 90% of active devices).

Instead of the four different application components required by the asynchronous structure of the previous release, the new version of the API allows developers to make synchronous requests and handle responses directly from within a single Activity, all of which are accomplished with just a few lines of code. The reduced implementation cost makes this a great opportunity for developers who are implementing new in-app billing solutions.

Easier to Implement
In contrast to the earlier model of asynchronous notification through a background service, the new API is now synchronous and reports the result of a purchase immediately to the application. This eliminates the necessity to integrate the handling of asynchronous purchase results into the application's lifecycle, which significantly simplifies the code that a developer must write in order to sell an in-app item.

To launch a purchase, simply obtain a buy Intent from the API and start it:

Bundle bundle = mService.getBuyIntent(3, "com.example.myapp",
    MY_SKU, ITEM_TYPE_INAPP, developerPayload);

PendingIntent pendingIntent = bundle.getParcelable(RESPONSE_BUY_INTENT);
if (bundle.getInt(RESPONSE_CODE) == BILLING_RESPONSE_RESULT_OK) {
    // Start purchase flow (this brings up the Google Play UI).
    // Result will be delivered through onActivityResult().
    startIntentSenderForResult(pendingIntent, RC_BUY, new Intent(),
        Integer.valueOf(0), Integer.valueOf(0), Integer.valueOf(0));
}

Then, handle the purchase result that's delivered to your Activity's onActivityResult() method:

public void onActivityResult(int requestCode, int resultCode, Intent data) {
    if (requestCode == RC_BUY) {
        int responseCode = data.getIntExtra(RESPONSE_CODE);
        String purchaseData = data.getStringExtra(RESPONSE_INAPP_PURCHASE_DATA);
        String signature = data.getStringExtra(RESPONSE_INAPP_SIGNATURE);

        // handle purchase here (for a permanent item like a premium upgrade,
        // this means dispensing the benefits of the upgrade; for a consumable
        // item like "X gold coins", typically the application would initiate
        // consumption of the purchase here)
    }
}

Also, differently from the previous version, all purchases are now managed by Google Play, which means the ownership of a given item can be queried at any time. To implement the same mechanics as unmanaged items, applications can consume the item immediately upon purchase and provision the benefits of the item upon successful consumption.

Local Caching
The API leverages a new feature of the Google Play store application which caches In-app Billing information locally on the device, making it readily available to applications. With this feature, many API calls will be serviced through cache lookups instead of a network connection to Google Play, which significantly speeds up the API's response time. For example, an application could query the owned items using this call:

Bundle bundle = mService.getPurchases(3, mContext.getPackageName(), ITEM_TYPE_INAPP);
if (bundle.getInt(RESPONSE_CODE) == BILLING_RESPONSE_RESULT_OK) {
    ArrayList mySkus, myPurchases, mySignatures;
    mySkus = bundle.getStringArrayList(RESPONSE_INAPP_ITEM_LIST);
    myPurchases = bundle.getStringArrayList(RESPONSE_INAPP_PURCHASE_DATA_LIST);
    mySignatures = bundle.getStringArrayList(RESPONSE_INAPP_PURCHASE_SIGNATURE_LIST);

    // handle items here
}

Querying for owned items was an expensive server call in previous versions of the API, so developers were discouraged from doing so frequently. However, since the new version implements local caching, applications can now make this query every time they start running, and as often as necessary thereafter.

Product Information
The API also introduces a long-anticipated feature: the ability to query in-app product information directly from Google Play. Developers can now programmatically obtain an item's title, description and price. No currency conversion or formatting is necessary: prices are reported in the user's currency and formatted according to their locale:

Bundle bundle = mService.getSkuDetails(3, "com.example.myapp", 
        ITEM_TYPE_INAPP, skus); // skus is a Bundle with the list of SKUs to query
if (bundle.getInt(RESPONSE_CODE) == BILLING_RESPONSE_RESULT_OK) {
    List detailsList = bundle.getStringArrayList(RESPONSE_SKU_DETAILS_LIST);
    for (String details : detailsList) {
        // details is a JSON string with 
        // SKU details (title, description, price, ...)
    }
}

This means that, for example, developers can update prices in Developer Console and then use this API call to show the updated prices in the application (such as for a special promotion or sale) with no need to update the application's code to change the prices displayed to the user.

Sample Application
In addition to the API, we are releasing a new sample application that illustrates how to implement In-app Billing. It also contains helper classes that implement commonly-written boilerplate code such as marshalling and unmarshalling data structures from JSON strings and Bundles, signature verification, as well as utilities that automatically manage background work in order to allow developers to call the API directly from the UI thread of their application. We highly recommend that developers who are new to In-app Billing leverage the code in this sample, as it further simplifies the process of implemention. The sample application is available for download through the Android SDK Manager.

App-Specific Keys
Along with the other changes introduced with In-app Billing Version 3, we have also improved the way Licensing and In-app Billing keys are managed. Keys are now set on a per-app basis, instead of a per-developer basis and are available on the “Services & APIs” page for each application on Google Play Developer Console preview. Your existing applications will continue to work with their current keys.

Get Started!
To implement In-app Billing in your application using the new API, start with the updated In-App Billing documentation and take the Selling In-App Products training class.
Join the discussion on

+Android Developers

Posted by Ellie Powers, Google Play team

The new Google Play Developer Console is out of preview and is the default experience. In addition to offering all of the functionality of the old version, the new version features a streamlined publishing flow, store listings in more languages with language-specific graphics, and new user ratings statistics, so you’ll have better tools for delivering great Android apps that delight users. If you haven't already made the switch, now is the time, as we'll be retiring the former version on April 15 to focus our efforts on this new experience.

The new Developer Console brings you new functionality built on top of a quick-to-navigate user experience. You can add language-specific graphics to your store listing to help your users around the world understand what your app is about. New graphs let you track your ratings over time with breakdowns by device, country, app version, and more. The statistics page now shows you when you released each version of your app, so you see how each new version changes your installations and ratings, and you can view crashes specific to an application version. These new features are only the beginning of what’s to come for developers on Google Play in the future.

If you're still using the old Developer Console, now is the time to switch over fully to the new version by clicking “Try the new version” in the header. Let us know what you think by clicking the “Feedback” link in the header in the new Developer Console, and if you experience any serious issues, please contact support. We’re planning some more improvements in the next month and in the future. Your input will continue to be key to what we do.

Join the discussion on

+Android Developers

Posted by Fabrice Di Meglio, Android Frameworks Team

Android 4.1 (Jelly Bean) introduced limited support for bidirectional text in TextView and EditText elements, allowing apps to display and edit text in both left-to-right (LTR) and right-to-left (RTL) scripts. Android 4.2 added full native support for RTL layouts, including layout mirroring, allowing you to deliver the same great app experience to all of your users, whether their language uses a script that reads right-to-left or one that reads left-to-right.

If you do nothing, your app will not change — it will continue to appear as it currently does. However, with a few simple changes, your app will be automatically mirrored when the user switches the system language to a right-to-left script (such as Arabic, Hebrew, or Persian). For example, see the following screenshots of the Settings app:

To take advantage of RTL layout mirroring, simply make the following changes to your app:

1. Declare in your app manifest that your app supports RTL mirroring.

   Specifically, add android:supportsRtl="true" to the <application> element in your manifest file.

2. Change all of your app's "left/right" layout properties to new "start/end" equivalents.
   • If you are targeting your app to Android 4.2 (the app's targetSdkVersion or minSdkVersion is 17 or higher), then you should use “start” and “end” instead of “left” and “right”. For example, android:paddingLeft should become android:paddingStart.
   • If you want your app to work with versions earlier than Android 4.2 (the app's targetSdkVersion or minSdkVersion is 16 or less), then you should add “start” and end” in addition to “left” and “right”. For example, you’d use both android:paddingLeft and android:paddingStart.

For more precise control over your app UI in both LTR and RTL mode, Android 4.2 includes the following new APIs to help manage View components:

• android:layoutDirection — attribute for setting the direction of a component's layout.
• android:textDirection — attribute for setting the direction of a component's text.
• android:textAlignment — attribute for setting the alignment of a component's text.
• getLayoutDirectionFromLocale() — method for getting the Locale-specified direction

You can even create custom versions of layout, drawables, and other resources for display when a right-to-left script is in use. Simply use the resource qualifier "ldrtl" to tag your resources, meaning “layout direction right-to-left”. To debug and optimize custom right-to-left layouts, HierarchyViewer now lets you see start/end properties, layout direction, text direction, and text alignment for all the Views in the hierarchy.

It's now easy to create beautiful Android apps for all your users, whether they use a right-to-left or left-to-right language. We look forward to seeing some great apps!

Join the discussion on

+Android Developers

Posted by Reto Meier, Android Developer Relations and Matt Waddell, Google+

Google Play Services is our platform for offering you better integration with Google products, and providing new capabilities to use within your apps. Today we’re rolling out Google Play services v3.0, which includes Google+ Sign-In and Google Maps Android API improvements.

Google+ Sign-In
Google+ Sign-In lets users sign in to your Android app with their existing Google credentials, and bring along their Google+ info for an upgraded experience. In addition to basic authentication, today’s release includes features that can accelerate both app downloads and engagement.


Over-the-air installs from your websiteAfter signing in with Google on your web site, users will now have the option to install your Android app on their devices instantly. They’ll enjoy a seamless desktop-to-mobile experience, and you’ll be able to drive more downloads. Linking your web site and Android apps is as simple as registering your project and clients with the Google APIs console.


App customizationWhen users sign in with Google, they can now bring their Google+ info with them (like their public profile, and the people in their circles). This lets your app welcome them by name, display their picture, connect them with friends, and lots more.


Interactive postsShares from your app can now include calls to action (like “listen,” “RSVP,” and “check-in”), custom thumbnails, and brand attribution — all of which help them stand out in users’ Google+ streams. Clicking on an interactive post can also deep link to a specific piece of content inside your app, further improving engagement.


App activity that’s useful, not annoyingUsers’ app activities will only be visible to the Google+ circles they specify (if any), and they’ll only appear when they’re relevant. Putting users in control, and not spraying their stream builds trust in your app, and encourages meaningful sharing.

Measure and monitor key metricsOnce your Google+ Sign-In integration is live, you’ll be able to measure and monitor downloads, total users, interactive post performance, and other key metrics. To set up Google+ Platform Insights for your Android app, simply connect it with your Google+ page.

More about Google+ Sign-InTo learn more about integrating with Google+ Sign-In, visit our developer docs. You can also read our announcement on the Google+ Developers Blog, or download some of the first apps to include this functionality.

Google Maps Android API v2
This release includes fixes for more than 20 bugs, including half of the top 10 issues filed in the Google Maps API issue tracker. These include improvements to map rendering and the behavior of markers and infowindows.

Also included are features like native support for new map shapes such as circles, anti-clockwise polygons, and the OnMyLocationChangeListener event, which is called when a change in location is detected.

Check out the product documentation for a complete set of release notes.

More About Google Play Services
To learn more about Google Play services and the APIs available to you through it, visit the Google Services area of the Android Developers site.
Join the discussion on

+Android Developers

Posted by Trevor Johns, Android Developer Relations team

Following our talk "Security and Privacy in Android Apps" at Google I/O last year, many people had specific questions about how to use cryptography in Android. Many of those revolved around which APIs to use for a specific purpose. Let's look at how to use cryptography to safely store user credentials, such as passwords and auth tokens, on local storage.

An anti-pattern

A common (but incorrect) pattern that we've recently become aware of is to use SecureRandom as a means of generating deterministic key material, which would then be used to encrypt local credential caches. Examples are not hard to find, such as here, here, here, and elsewhere.

In this pattern, rather than storing an encryption key directly as a string inside an APK, the code uses a proxy string to generate the key instead — similar to a passphrase. This essentially obfuscates the key so that it's not readily visible to attackers. However, a skilled attacker would be able to easily see around this strategy. We don't recommend it.

The fact is, Android's existing security model already provides plenty of protection for this kind of data. User credentials should be stored with the MODE_PRIVATE flag set and stored in internal storage, rather than on an SD card, since permissions aren't enforced on external storage. Combined with device encryption, this provides protection from most types of attacks targeting credentials.

However, there's another problem with using SecureRandom in the way described above. Starting with Android 4.2, the default SecureRandom provider is OpenSSL, and a developer can no longer override SecureRandom’s internal state. Consider the following code:

  SecureRandom secureRandom = new SecureRandom();
  byte[] b = new byte[] { (byte) 1 };
  secureRandom.setSeed(b);
  // Prior to Android 4.2, the next line would always return the same number!
  System.out.println(secureRandom.nextInt());

The old Bouncy Castle-based implementation allowed overriding the internally generated, /dev/urandom based key for each SecureRandom instance. Developers which attempted to explicitly seed the random number generator would find that their seed replaces, not supplements, the existing seed (contrary to the reference implementation’s documentation). Under OpenSSL, this error-prone behavior is no longer possible.

Unfortunately, applications who relied on the old behavior will find that the output from SecureRandom changes randomly every time their application starts up. (This is actually a very desirable trait for a random number generator!) Attempting to obfuscate encryption keys in this manner will no longer work.

The right way

A more reasonable approach is simply to generate a truly random AES key when an application is first launched:

public static SecretKey generateKey() throws NoSuchAlgorithmException {
    // Generate a 256-bit key
    final int outputKeyLength = 256;

    SecureRandom secureRandom = new SecureRandom();
    // Do *not* seed secureRandom! Automatically seeded from system entropy.
    KeyGenerator keyGenerator = KeyGenerator.getInstance("AES");
    keyGenerator.init(outputKeyLength, secureRandom);
    SecretKey key = keyGenerator.generateKey();
    return key;
}

Note that the security of this approach relies on safeguarding the generated key, which is is predicated on the security of the internal storage. Leaving the target file unencrypted (but set to MODE_PRIVATE) would provide similar security.

Even more security

If your app needs additional encryption, a recommended approach is to require a passphase or PIN to access your application. This passphrase could be fed into PBKDF2 to generate the encryption key. (PBKDF2 is a commonly used algorithm for deriving key material from a passphrase, using a technique known as "key stretching".) Android provides an implementation of this algorithm inside SecretKeyFactory as PBKDF2WithHmacSHA1:

public static SecretKey generateKey(char[] passphraseOrPin, byte[] salt) throws NoSuchAlgorithmException, InvalidKeySpecException {
    // Number of PBKDF2 hardening rounds to use. Larger values increase
    // computation time. You should select a value that causes computation
    // to take >100ms.
    final int iterations = 1000; 

    // Generate a 256-bit key
    final int outputKeyLength = 256;

    SecretKeyFactory secretKeyFactory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
    KeySpec keySpec = new PBEKeySpec(passphraseOrPin, salt, iterations, outputKeyLength);
    SecretKey secretKey = secretKeyFactory.generateSecret(keySpec);
    return secretKey;
}

The salt should be a random string, again generated using SecureRandom and persisted on internal storage alongside any encrypted data. This is important to mitigate the risk of attackers using a rainbow table to precompute password hashes.

Check your apps for proper use of SecureRandom

As mentioned above and in the New Security Features in Jelly Bean, the default implementation of SecureRandom is changed in Android 4.2. Using it to deterministically generate keys is no longer possible.

If you're one of the developers who's been generating keys the wrong way, we recommend upgrading your app today to prevent subtle problems as more users upgrade to devices running Android 4.2 or later.

Join the discussion on

+Android Developers

Posted by Tim Bray

Most Android apps have some sort of server-side back end, to persist and share data. Even the most basic game needs to remember its players’ high scores. When you’re building your back end, one problem you have to solve is how the back-end code knows what app it’s talking to and who the person using it is.

You probably have HTTP endpoints for communicating with your client apps, but how can the server-side code be sure who’s sending messages to it? After all, anyone can send HTTP POST requests from anywhere; could they impersonate your users if they could guess their identities?

It’s really user-unfriendly to ask people to type in usernames and passwords on mobile devices. In particular, if someone has installed your app and given it permission to use the Internet and know your identity, they shouldn’t be pestered any more.

It turns out that Google Play services, now available on every compatible device running Android release 2.2 or higher, offers a good solution to this problem, based on the use of Google Accounts.

Summary

Doing this is a multi-step process, which I’ll outline in full, but here’s the short version: You use the GoogleAuthUtil class, available through Google Play services, to retrieve a string called an “ID Token”. You send the token to your back end and your back end can use it to quickly and cheaply verify which app sent it and who was using the app.

This capability is built into Google facilities such as App Engine’s new Cloud Endpoints feature, which bakes app/back-end identity into a simple programming model.

Now let’s get to the details.

App Registration

You’re going to have to use the Google API Console quite a bit in this process. You’ll need to make a new project for this purpose; while you can give it a nice human-readable name and graphical branding, it turns out that those resources aren’t used in this particular scenario.

You can also authorize this project to access a large number of different Google APIs; but once again, you don’t need to in this scenario.

You should give serious thought to the people you authorize as members of the project, since these are important administrative roles.

Make Client IDs

You’ll need to make two different OAuth 2.0 “Client IDs” for your project. The first one is a “Client ID for Web applications”. Once again, you can ignore all the labeling and branding stuff, you’ll just need the Client-ID string, which will look something like 9414861317621.apps.googleusercontent.com.

Now you’ll need to make another Client ID for your Android app. To do this, you’ll need to provide two pieces of information: your app’s package name and cert signature. The package name is just the Java-style reverse-DNS, as given in the top-level “package” attribute in your AndroidManifest.xml, for example com.example.identity.

To get your app’s cert signature, use the following shell command:

$ keytool -exportcert -alias <your-key-name> -keystore <your-key-store-file> -v -list

Copy the octets labeled “SHA1”, paste them into the Developer Console field, and create your app’s Client ID. Once again, all you’ll really need from the readout is the Client-ID string.

In Your Android App

You’ll need to call the Google Play services GoogleAuthUtil class to get an ID token; the procedure is as described in Obtaining an Access Token. There’s one extra bit of magic: the value of the scope argument to the getToken(email, scope) method. It has to be the string audience:server:client_id:X, where X is the Client ID of for the Web app, as described above. If our Client ID were the example value given above, the value of the scope argument would be audience:server:client_id:9414861317621.apps.googleusercontent.com.

Magic Happens

Normally, when you ask for an OAuth token, the person using the device sees a challenge, asking them if it’s OK to use their identity to get at some resource or other. But in this case, the system looks at the server-side Client ID in your scope argument, notices that it’s in the same project as your Android app, and gives you the token without pestering the user; they’ve already agreed to a relationship with you, the developer who controls that project.

Send the Token

When you’re ready to start talking to your server back end, you need to send the token string to it. The best way to do this is in the body of an POST message; you could put it in a URL parameter, but they’re often logged. You absolutely must use an HTTPS connection, to keep any men-in-the-middle from peeking at your token.

There’s no particular reason for extra round-trips; if you’re sending a game high score to your back end, just stick the ID Token string in as an extra argument.

Use the Token

When your server receives the token from your Android app, it’s really important that you verify it. This requires two steps:

1. Verify that it’s really signed by Google.
2. Verify that it’s really meant for you.

Verify Signature

It turns out that this is signed using a Google public/private key pair, and Google publishes the public keys (which we change regularly) at www.googleapis.com/oauth2/v1/certs; go ahead and have a look.

You have to verify that the ID Token, which is actually a JSON Web Token, was signed with one of those certs. Fortunately, there are decent libraries around to do this; in this post, I’ll give pointers for Java, Ruby, and PHP.

The libraries can cache the Google certs and only refresh them when required, so the verification is (almost always) a fast static call.

Verify Token Fields

It turns out that the ID Token has a JSON payload, and most libraries that validate the signatures also give it to you as a hash or dictionary or whatever. Thus, you can retrieve named fields, such as aud and azp and email.

First, you have to look at the field named aud and verify that it’s identical to your Client ID, the string you included in the Android app’s scope argument. Seriously, do not omit this step; if you don't verify the ID Token, then any other developer can spoof requests to your service.

Optionally, you can look at the field named azp (stands for “authorized party”) and verify that it is identical to the Client ID of your Android app. By the way, you can have multiple different Android client apps, each with its own Client ID, in that top-level project.

Let’s assume you’ve done all three of these things. Then, you know that:

1. The token was issued by Google.
2. The token was sent to a device that was being operated by the person identified in the payload's email field.

You also have high confidence that:

3. The token was obtained by the Android app identified by the Client ID in the payload’s azp field.

The Client ID only has “high confidence” because non-compatible or rooted Android devices may be able to tamper with that information. But they won't be able to fake the Google signature or the authentication of the device user to Google.

What’s Next?

That’s up to you. You know which person and app you’re talking to, it’s up to you what to do with that information.

Code Fragments

Here’s a Java class that implements an ID-Token checker using the Google Java libraries:

import java.io.IOException;
import java.security.GeneralSecurityException;

import com.google.api.client.googleapis.auth.oauth2.GoogleIdToken;
import com.google.api.client.googleapis.auth.oauth2.GoogleIdTokenVerifier;
import com.google.api.client.http.javanet.NetHttpTransport;
import com.google.api.client.json.JsonFactory;
import com.google.api.client.json.gson.GsonFactory;

public class Checker {

    private final List mClientIDs;
    private final String mAudience;
    private final GoogleIdTokenVerifier mVerifier;
    private final JsonFactory mJFactory;
    private String mProblem = "Verification failed. (Time-out?)";

    public Checker(String[] clientIDs, String audience) {
        mClientIDs = Arrays.asList(clientIDs);
        mAudience = audience;
        NetHttpTransport transport = new NetHttpTransport();
        mJFactory = new GsonFactory();
        mVerifier = new GoogleIdTokenVerifier(transport, mJFactory);
    }

    public GoogleIdToken.Payload check(String tokenString) {
        GoogleIdToken.Payload payload = null;
        try {
            GoogleIdToken token = GoogleIdToken.parse(mJFactory, tokenString);
            if (mVerifier.verify(token)) {
                GoogleIdToken.Payload tempPayload = token.getPayload();
                if (!tempPayload.getAudience().equals(mAudience))
                    mProblem = "Audience mismatch";
                else if (!mClientIDs.contains(tempPayload.getIssuee()))
                    mProblem = "Client ID mismatch";
                else
                    payload = tempPayload;
            }
        } catch (GeneralSecurityException e) {
            mProblem = "Security issue: " + e.getLocalizedMessage();
        } catch (IOException e) {
            mProblem = "Network problem: " + e.getLocalizedMessage();
        }
        return payload;
    }

    public String problem() {
        return mProblem;
    }
}

If you wanted to do this in Ruby, you’d want to install the google-id-token Ruby gem, and do something like this:

require 'google-id-token'
validator = GoogleIDToken::Validator.new
jwt = validator.check(token, required_audience, required_client_id)
if jwt
  email = jwt['email']
else
  report "Cannot validate: #{validator.problem}"
end

For PHP programmers, check out the Google APIs Client Library for PHP, in particular the function verifyIdToken in apiOAuth2.php.

Join the discussion on

+Android Developers

Posted by Fred Chung, Android Developer Relations team

Android 4.2, Jelly Bean, introduced quite a few new features, and under the covers it also added a number of security enhancements to ensure a more secure environment for users and developers.

This post highlights a few of the security enhancements in Android 4.2 that are especially important for developers to be aware of and understand. Regardless whether you are targeting your app to devices running Jelly Bean or to earlier versions of Android, it's a good idea to validate these areas in order to make your app more secure and robust.

Content Provider default access has changed

Content providers are a facility to enable data sharing amongst app and system components. Access to content providers should always be based on the principle of least privilege — that is, only grant the minimal possible access for another component to carry out the necessary tasks. You can control access to your content providers through a combination of the exported attribute in the provider declaration and app-specific permissions for reading/writing data in the provider.

In the example below, the provider ReadOnlyDataContentProvider sets the exported attribute to "true", explicitly declaring that it is readable by any external app that has acquired the READ_DATA permission, and that no other components can write to it.

<provider android:name=”com.example.ReadOnlyDataContentProvider”
    android:authorities=”com.example”
    android:exported=”true”
    android:readPermission=”com.example.permission.READ_DATA” />

Since the exported attribute is an optional field, potential ambiguity arises when the field is not explicitly declared in the manifest, and that is where the behavior has changed in Android 4.2.

Prior to Jelly Bean, the default behavior of the exported field was that, if omitted, the content provider was assumed to be "exported" and accessible from other apps (subject to permissions). For example, the content provider below would be readable and writable by other apps (subject to permissions) when running on Android 4.1 or earlier. This default behavior is undesirable for sensitive data sources.

<provider android:name=”com.example.ReadOnlyDataContentProvider”
    android:authorities=”com.example” />

Starting in Android 4.2, the default behavior for the same provider is now “not exported”, which prevents the possibility of inadvertent data sharing when the attribute is not declared. If either the minSdkVersion or targetSdkVersion of your app is set to 17 or higher, the content provider will no longer be accessible by other apps by default.

While this change helps to avoid inadvertent data sharing, it remains the best practice to always explicitly declare the exported attribute, as well as declaring proper permissions, to avoid confusion. In addition, we strongly encourage you to make use of Android Lint, which among other things will flag any exported content providers (implicit or explicit) that aren't protected by any permissions.

New implementation of SecureRandom

Android 4.2 includes a new default implementation of SecureRandom based on OpenSSL. In the older Bouncy Castle-based implementation, given a known seed, SecureRandom could technically (albeit incorrectly) be treated as a source of deterministic data. With the new OpenSSL-based implementation, this is no longer possible.

In general, the switch to the new SecureRandom implementation should be transparent to apps. However, if your app is relying on SecureRandom to generate deterministic data, such as keys for encrypting data, you may need to modify this area of your app. For example, if you have been using SecureRandom to retrieve keys for encrypting/decrypting content, you will need to find another means of doing that.

A recommended approach is to generate a truly random AES key upon first launch and store that key in internal storage. For more information, see the post "Using Cryptography to Store Credentials Safely".

JavascriptInterface methods in WebViews must now be annotated

Javascript hosted in a WebView can directly invoke methods in an app through a JavaScript interface. In Android 4.1 and earlier, you could enable this by passing an object to the addJavascriptInterface() method and ensuring that the object methods intended to be accessible from JavaScript were public.

On the one hand, this was a flexible mechanism; on the other hand, any untrusted content hosted in a WebView could potentially use reflection to figure out the public methods within the JavascriptInterface object and could then make use of them.

Beginning in Android 4.2, you will now have to explicitly annotate public methods with @JavascriptInterface in order to make them accessible from hosted JavaScript. Note that this also only takes effect only if you have set your app's minSdkVersion or targetSdkVersion to 17 or higher.

// Annotation is needed for SDK version 17 or above.
@JavascriptInterface
public void doSomething(String input) {
   . . .
}

Secure USB debugging

Android 4.2.2 introduces a new way of protecting your apps and data on compatible devices — secure USB debugging. When enabled on a device, secure debugging ensures that only host computers authorized by the user can access the internals of a USB-connected device using the ADB tool included in the Android SDK.

Secure debugging is an extension of the ADB protocol that requires hosts to authenticate before accessing any ADB services or commands. At first launch, ADB generates an RSA key pair to uniquely identifies the host. Then, when you connect a device that requires secure debugging, the system displays an authorization dialog such as the one shown below.

The user can allow USB debugging for the host for a single session or can give automatic access for all future sessions. Once a host is authorized, you can execute ADB commands for the device in the normal way. Until the device is authorized, it remains in "offline" state, as listed in the adb devices command.

For developers, the change to USB debugging should be largely transparent. If you've updated your SDK environment to include ADB version 1.0.31 (available with SDK Platform-tools r16.0.1 and higher), all you need to do is connect and authorize your device(s). If your development device appears in "offline" state, you may need to update ADB. To so so, download the latest Platform Tools release through the SDK Manager.

Secure USB debugging is enabled in the Android 4.2.2 update that is now rolling out to Nexus devices across the world. We expect many more devices to enable secure debugging in the months ahead.

More information about security best practices

For a full list of security best practices for Android apps, make sure to take a look at the Security Tips document.

Join the discussion on

+Android Developers