Android Developers Blog

New Ways to Optimize Your Business in Google Play

2013-05-17T10:37:00.000-07:00

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

Social Gaming, Location, and More in Google Play Services

2013-05-16T12:17:00.000-07:00

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

Android Studio: An IDE built for Android

2013-05-15T14:01:00.000-07:00

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 can do.

Powerful code editing

Android Studio includes a powerful code editor. It is based on the IntelliJ IDEA, 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. Below you can see a multi-configuration preview side by side XML editing.

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

Android at Google I/O 2013: Keynote Wrapup

2013-05-15T12:32:00.001-07:00

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.

All Google Play Developers Can Now Reply to User Reviews

2013-05-13T09:37:00.000-07:00

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

Android at Google I/O 2013

2013-05-09T14:33:00.000-07:00

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.

Tablet Optimization Tips in the Google Play Developer Console

2013-04-25T09:32:00.001-07:00

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

Update on Tablet App Guidelines and Screenshots

2013-04-16T12:38:00.000-07:00

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

New Look, New Purchase Flow in Google Play

2013-04-09T09:09:00.001-07:00

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.

Now is the time to switch to the new Google Play Developer Console

2013-03-12T15:16:00.000-07:00

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

Native RTL support in Android 4.2

2013-03-04T10:06:00.000-08:00

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:

Declare in your app manifest that your app supports RTL mirroring.
Specifically, add android:supportsRtl="true" to the <application> element in your manifest file.
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

Google+ Sign-In Now Part of Google Play Services

2013-02-26T08:01:00.000-08:00

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 website

After 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 customization

When 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 posts

Shares 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 annoying

Users’ 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 metrics

Once 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-In

To 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

Using Cryptography to Store Credentials Safely

2013-02-19T12:46:00.000-08:00

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

Security Enhancements in Jelly Bean

2013-02-14T13:37:00.000-08:00

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

Android Developer Story: Smule

2013-01-15T11:22:00.000-08:00

Check out our latest Android developer story, this one from Smule, creators of AutoRap, Magic Piano, and Songify.

In this short video, the Smule team talks about their experiences launching on Android, the explosive global growth they’ve seen on Google Play, and some of the techniques they use to market and monetize their products effectively across the world.

Visit the Spotlight pages in the Android Developers site to see our growing list of developer stories.

Join the discussion on

+Android Developers

Evolution of Renderscript Performance

2013-01-14T11:35:00.000-08:00

Posted by R. Jason Sams, Android Renderscript Tech Lead

It’s been a year since the last blog post on Renderscript, and with the release of Android 4.2, it’s a good time to talk about the performance work that we’ve done since then. One of the major goals of this past year was to improve the performance of common image-processing operations with Renderscript.

Figure 1. Renderscript image-processing benchmarks run on different Android platform versions (Android 4.0, 4.1, and 4.2) in CPU only on a Galaxy Nexus device.

Figure 2. Renderscript image-processing benchmarks comparing operations run with GPU + CPU to those run in CPU only on the same Nexus 10 device.

When you set out to improve performance, the first task is to measure it. To do this, we built a image-processing benchmark suite. The tests measure how long it takes to apply a given image processing operation to a roughly 1.7 million pixel bitmap. We then ran the benchmark using the same APK on the Galaxy Nexus and normalized the results from Ice Cream Sandwich to 1.0.

We made a few major improvements between ICS and Jelly Bean, which significantly reduced the overhead of short scripts as well as the cost of getting elements out of allocations. Going from Android 4.1 to Android 4.2, we added a number of performance improvements to the math library. Our hardware partners also made major contributions; ARM in particular provided numerous compiler improvements which greatly improved our ability to generate vector code.

Android 4.2 introduced another much more important change: For the first time on any mobile platform. we can use the GPU as a compute device. When run on a device that supports GPU compute, that same benchmark APK will run on the GPU. The chart in Figure 2 is normalized to the same basis as Figure 1.

The Cortex A15 in Nexus 10 is a very good CPU. However, that doesn’t mean we should leave resources idle. The Mali T604 is a very flexible and capable compute device capable of executing a large subset of RenderScript functionality. The green bar in Figure 2 shows what we can do when the Mali is enabled for RS compute. No effort is required on an app developer's part to enable this acceleration; the device will inspect each script and decide which processor to run things automatically. It’s important to note that some scripts can’t be run on the GPU, and such scripts will automatically run on the CPU.

The best part is it doesn’t end here. Performance work is an ongoing effort. RenderScript performance in applications will continue to improve over time as we continue to improve the platform.

To learn more about using Renderscript, see the Renderscript Computation developer's guide.

Join the discussion on

+Android Developers

Verifying Back-End Calls from Android Apps

2013-01-08T09:01:00.000-08:00

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:

Verify that it’s really signed by Google.
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:

The token was issued by Google.
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:

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

Daydream: Interactive Screen Savers

2012-12-27T13:09:00.000-08:00

Posted by Daniel Sandler, a software engineer on the Android System UI team

I’ve always loved screen savers. Supposedly they exist for a practical purpose: protecting that big, expensive monitor from the ghosts of spreadsheets past.

But I’ve always imagined that your computer is secretly hoping you’ll stand up and walk away for a bit. Just long enough for that idle timer to expire…so it can run off and play for a little while. Draw a picture, set off fireworks, explore the aerodynamics of kitchen appliances, whatever—while always ready to get back to work at a keystroke or nudge of the mouse.

Daydream, new in Android 4.2, brings this kind of laid-back, whimsical experience to Android phones and tablets that would otherwise be sleeping. If you haven’t checked it out, you can turn it on in the Settings app, in Display > Daydream; touch When to Daydream to enable the feature when charging.

An attract mode for apps

Apps that support Daydream can take advantage of the full Android UI toolkit in this mode, which means it’s easy to take existing components of your app — including layouts, animations, 3D, and custom views—and remix them for a more ambient presentation. And since you can use touchscreen input in this mode as well, you can provide a richly interactive experience if you choose.

Daydream provides an opportunity for your app to show off a little bit. You can choose to hide some of your app’s complexity in favor of one or more visually compelling experiences that can entertain from across a room, possibly drawing the user into your full app, like a video game’s attract mode.

Figure 1. Google Currents scrolls stories past in a smooth, constantly-moving wall of news.

Google Currents is a great example of this approach: as a Daydream, it shows a sliding wall of visually-interesting stories selected from your editions. Touch a story, however, and Currents will show it to you full-screen; touch again to read it in the full Currents app.

The architecture of a Daydream

Each Daydream implementation is a subclass of android.service.dreams.DreamService. When you extend DreamService, you’ll have access to a simple Activity-like lifecycle API.

Key methods on DreamService to override in your subclass (don’t forget to call the superclass implementation):

onAttachedToWindow() — Use this for initial setup, such as calling setContentView().
onDreamingStarted() — start your animations and timers
onDreamingStopped() — stop animations
onDetachedFromWindow() — tear down anything you built in onAttachedToWindow()

Important methods on DreamService that you may want to call:

setContentView() — set the scene for your Daydream. Can be a layout XML resource ID or an instance of View, even a custom View you implement yourself.
setInteractive(boolean) — by default, your Daydream will exit if the user touches the screen, like a classic screen saver. If you want the user to be able to touch and interact with your Views, call setInteractive(true).
setFullscreen(boolean) — convenience method for hiding the status bar (see below).
setScreenBright(boolean) — by default, Daydreams keep the screen on at full brightness, which may not be appropriate for some situations (for example, dark rooms); setting this to false will reduce the display brightness to a very low level.

Finally, to advertise your Daydream to the system, create a <service> for it in your AndroidManifest.xml:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.app">
    <uses-sdk android:targetSdkVersion="17" android:minSdkVersion="17" />

    <application>
        <service
            android:name=".ExampleDaydream"
            android:exported="true"
            android:label="@string/my_daydream_name">
            <intent-filter>
                <action android:name="android.service.dreams.DreamService" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
            <meta-data
                android:name="android.service.dream"
                android:resource="@xml/dream_info" />
        </service>
    </application>
</manifest>

The <meta-data> tag is optional; it allows you to point to an XML resource that specifies a settings Activity specific to your Daydream. The user can reach it by tapping the settings icon next to your Daydream’s name in the Settings app.

<!-- res/xml/dream_info.xml -->
<?xml version="1.0" encoding="utf-8"?>
<dream xmlns:android="http://schemas.android.com/apk/res/android"
    android:settingsActivity="com.example.app/.ExampleDreamSettingsActivity" />

Here's an example to get you going: a classic screen saver, the bouncing logo, implemented using a TimeAnimator to give you buttery-smooth 60Hz animation.

Figure 2. Will one of them hit the corner?

public class BouncerDaydream extends DreamService {
    @Override
    public void onDreamingStarted() {
        super.onDreamingStarted();

        // Our content view will take care of animating its children.
        final Bouncer bouncer = new Bouncer(this);
        bouncer.setLayoutParams(new 
            ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
        bouncer.setSpeed(200); // pixels/sec

        // Add some views that will be bounced around.
        // Here I'm using ImageViews but they could be any kind of 
        // View or ViewGroup, constructed in Java or inflated from 
        // resources.
        for (int i=0; i<5; i++) {
            final FrameLayout.LayoutParams lp 
                = new FrameLayout.LayoutParams(WRAP_CONTENT, WRAP_CONTENT);
            final ImageView image = new ImageView(this);
            image.setImageResource(R.drawable.android);
            image.setBackgroundColor(0xFF004000);
            bouncer.addView(image, lp);
        }

        setContentView(bouncer);
    }
}

public class Bouncer extends FrameLayout implements TimeAnimator.TimeListener {
    private float mMaxSpeed;
    private final TimeAnimator mAnimator;
    private int mWidth, mHeight;

    public Bouncer(Context context) {
        this(context, null);
    }

    public Bouncer(Context context, AttributeSet attrs) {
        this(context, attrs, 0);
    }

    public Bouncer(Context context, AttributeSet attrs, int flags) {
        super(context, attrs, flags);
        mAnimator = new TimeAnimator();
        mAnimator.setTimeListener(this);
    }

    /**
     * Start the bouncing as soon as we’re on screen.
     */
    @Override
    public void onAttachedToWindow() {
        super.onAttachedToWindow();
        mAnimator.start();
    }

    /**
     * Stop animations when the view hierarchy is torn down.
     */
    @Override
    public void onDetachedFromWindow() {
        mAnimator.cancel();
        super.onDetachedFromWindow();
    }

    /**
     * Whenever a view is added, place it randomly.
     */
    @Override
    public void addView(View v, ViewGroup.LayoutParams lp) {
        super.addView(v, lp);
        setupView(v);
    }

    /**
     * Reposition all children when the container size changes.
     */
    @Override
    protected void onSizeChanged (int w, int h, int oldw, int oldh) {
        super.onSizeChanged(w, h, oldw, oldh);
        mWidth = w;
        mHeight = h;
        for (int i=0; i<getChildCount(); i++) {
            setupView(getChildAt(i));
        }
    }

    /**
     * Bouncing view setup: random placement, random velocity.
     */
    private void setupView(View v) {
        final PointF p = new PointF();
        final float a = (float) (Math.random()*360);
        p.x = mMaxSpeed * (float)(Math.cos(a));
        p.y = mMaxSpeed * (float)(Math.sin(a));
        v.setTag(p);
        v.setX((float) (Math.random() * (mWidth - v.getWidth())));
        v.setY((float) (Math.random() * (mHeight - v.getHeight())));
    }

    /**
     * Every TimeAnimator frame, nudge each bouncing view along.
     */
    public void onTimeUpdate(TimeAnimator animation, long elapsed, long dt_ms) {
        final float dt = dt_ms / 1000f; // seconds 
        for (int i=0; i<getChildCount(); i++) {
            final View view = getChildAt(i);
            final PointF v = (PointF) view.getTag();

            // step view for velocity * time 
            view.setX(view.getX() + v.x * dt);
            view.setY(view.getY() + v.y * dt);

            // handle reflections
            final float l = view.getX();
            final float t = view.getY();
            final float r = l + view.getWidth();
            final float b = t + view.getHeight();
            boolean flipX = false, flipY = false;
            if (r > mWidth) {
                view.setX(view.getX() - 2 * (r - mWidth));
                flipX = true;
            } else if (l < 0) {
                view.setX(-l);
                flipX = true;
            }
            if (b > mHeight) {
                view.setY(view.getY() - 2 * (b - mHeight));
                flipY = true;
            } else if (t < 0) {
                view.setY(-t);
                flipY = true;
            }
            if (flipX) v.x *= -1;
            if (flipY) v.y *= -1;
        }
    }

    public void setSpeed(float s) {
        mMaxSpeed = s;
    }
}

This example code is handy for anything you want to show the user without burning it into the display (like a simple graphic or an error message), and it also makes a great starting point for more complex Daydream projects.

A few more idle thoughts

First, do no harm: Daydream is meant to run when a device is charging. However, if the Daydream consumes too much CPU, charging might happen very slowly or not at all! The system will stop your Daydream if it detects that the device is not charging, so make sure your code leaves enough power to charge the battery in a reasonable amount of time.
Respect the lockscreen: Daydream runs on top of the secure keyguard, which means that if you might be showing sensitive content, you need to give the user tools to control that content. For example, Photo Table and Photo Frame allow the user to select the albums from which photos will be displayed (avoiding embarrassing slideshows).
Screen brightness: Think about where you expect your Daydream to be used and adjust the screen brightness accordingly using setScreenBright() and possibly even using darker or brighter colors as necessary. A bedside clock will need to be dimmer than a desk clock; if you expect your Daydream to serve both purposes you'll need to give the user a choice.
To hide the status bar or not: Many users will need instant access to the battery level and time of day, so you should avoid using setFullscreen(), particularly if your Daydream is more informational than artistic. Daydream will start with the status bar in “lights out” mode (View.SYSTEM_UI_FLAG_LOW_PROFILE), where it’s quite unobtrusive but still shows the clock and charge status.
When to use settings: In general, you have a little latitude for adding extra knobs and dials to Daydream settings. After all, this is a personalization feature, so users should be encouraged to tweak things until they feel at home. Sometimes, though, a more compelling experience can come from taking an artistic stand: giving the user a choice from a small number of polished, beautiful configurations (rather than providing all the controls of a commercial airline cockpit).
There can be more than one: If you discover that your settings allow the user to pick between a few radically different display modes, consider splitting your Daydream into multiple DreamService implementations. For example, the photo gallery in Android 4.2 provides both the Photo Table and Photo Frame Daydreams.
Use an Activity for development: Most Android development tools are optimized for developing and debugging conventional Android apps; since DreamService and Activity are so similar, it can be useful to create a testing Activity that hosts the same content view as your DreamService. This way you can launch and test your code easily from your IDE as if it were any other Android project.

OK, that’s enough for now; you have the tools to go build Daydream support into your apps. Have fun with it — if you do, your users will have fun too. Oh, and when you upload your shiny new APK to Google Play, be sure to add a note to your app’s description so that users searching for Daydreams can discover it.

Localize Your Promotional Graphics on Google Play

2012-12-20T12:18:00.001-08:00

Posted by Ellie Powers, Product Manager on the Google Play team

Google Play is your way to reach millions and millions of Android users around the world. In fact, since the start of 2011, the number of countries where you can sell apps has increased from 30 to over 130 — including most recently, the launch of paid app support in Israel, Mexico, the Czech Republic, Poland, Brazil and Russia, and fully two-thirds of revenue for apps on Google Play comes from outside of the United States.

To help you capitalize on this growing international audience, it’s now even easier to market your apps to users around the world, by adding images and a video URL to your Google Play store listing for each of Google Play’s 49 languages, just as you’ve been able to add localized text.

A localized feature graphic can show translated text or add local flavor to your app — for example, changing its theme to reflect local holidays. Always make sure that your feature graphic works at different sizes.

Once you’ve localized your app, you’ll want to make sure users in all languages can understand what your app does and how it can benefit them. Review the graphics guidelines and get started with localized graphics.

Localized screenshots make it clear to the user that they’ll be able to use your app in their language. As you’re adding localized screenshots, remember that a lot of people will be getting new tablets for the holidays, and loading up with new apps, so you’ll want to include localized tablet screenshots to show off your tablet layouts.

With localized videos, you can now include a language-appropriate voiceover and text, and of course show the app running in the user’s language.

Ready to add localized images and videos to your store listing? To add localized graphics and video to your apps, you need to use the Google Play Developer Console preview — once you add localized graphics, you won’t be able to edit the app using the old version anymore. Those of you who use APK Expansion Files will now want to try the new Developer Console because it now includes this feature. We’ll be adding support for Multiple APK very soon. Once you’ve saved your application in the new Developer Console, automated translations become available to users on the web and devices — with no work from you.

What are you doing to help your app reach a global audience?

Join the discussion on

+Android Developers

The 2012 Android Developer Survey

2012-12-11T09:30:00.000-08:00

The Android Developer Relations team is passionate about making Android app development a great experience, so we're asking all of you involved in building Android apps -- from engineers, to product managers, and distribution and support folks -- to let us know what you think.

We want to better understand the challenges you face when planning, designing, writing, and distributing your Android apps, so we've put together a brief (10-15min) survey that will help us test our assumptions and allow us to create better tools and resources for you.

We've had a great response from thousands of Android developers who have already responded - thank you! If you haven't yet filled in the survey, you can find it here: 2012 Android Developer Survey.

We'll be closing this year's survey this Sunday (December 17th) at 12pm Pacific Time, so be sure to get your responses in before then.

To keep the survey short and simple, there are no sections for general comments. That's because we want to hear your thoughts, questions, suggestions, and complaints all year. If there's anything you'd like to share with us, you can let us know by posting to us (publicly or privately) on Google+ at +Android Developers or using the hash tag #AndroidDev.

We can't always respond, but we're paying close attention to everything you have to say.

As always, we're looking forward to hearing your thoughts!

In-App Billing Version 3

2012-12-10T10:35:00.000-08:00

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

New Google Maps Android API now part of Google Play services

2012-12-03T10:41:00.000-08:00

Posted by Reto Meier, Evan Rapoport, and Andrew Foster

Google Play services is our new platform that offers you better integration with Google products, and which provides greater agility for quickly rolling out new capabilities for you to use within your apps. Today we’re launching Google Play services v2.0, which includes two new APIs, including perhaps our most frequently requested upgrade: Maps.

Google Maps Android API

The new version of the API allows developers to bring many of the recent features of Google Maps for Android to your Android apps. We’re excited to make this API available as part of Google Play services supporting devices from Froyo onwards (API level 8+).

The new API uses vector-based maps that support 2D and 3D views, and allow users to tilt and rotate the map with simple gestures. Along with the layers you’ve come to know from Google Maps such as satellite, hybrid, terrain and traffic, the new API lets you include indoor maps for many major airports and shopping centers in your app.

One of most common feature requests we’ve heard on Android is support for Map Fragments. With this new API, adding a map to your Activity is as simple as:

<fragment
  android:id="@+id/map"
  android:layout_width="match_parent"
  android:layout_height="match_parent"
  class="com.google.android.gms.maps.MapFragment" />

Check out this image from updated Trulia Android app (which goes live tomorrow), that users can use to search for a place to buy or rent in 3D.

The new API is simpler to use, so that creating markers and info windows is easy. Polylines, Polygons, Ground Overlays and Tile Overlays can all now be added to the map with just a few lines of code.

To get started follow the getting started instructions to obtain an API Key. Then download and configure the Google Play services SDK using the SDK Manager. Check the Google Maps for Android API documentation for more details. If you haven't got it already, you'll need to download the Android SDK first.

More than 800,000 sites around the world already use our mapping APIs to create amazing and useful apps. We hope you enjoy using this new addition to the Google Maps API family, and building mapping experiences that were never before possible on a mobile device.

Photo Sphere

In Android 4.2, we introduced Photo Sphere mode in the Camera, which you can use to create amazing, immersive panoramas just like you see in Street View on Google Maps. Today we’re excited to announce new APIs and documentation that empower developers, businesses, and photographers to explore new uses of Photo Sphere for work and for play.

We’ve made Photo Sphere an open format so anyone can create and view them on the web or on mobile devices.

A Photo sphere is simply an image file (like a JPG) that has in it text-based metadata, an open format created by Adobe called XMP. The metadata describes the Photo Sphere’s dimensions and how it should be rendered within the interactive Photo Sphere viewer you see in Android, Google+, and Google Maps.

If you’d like to programmatically or manually add the XMP metadata into panoramic images not created by the Photo Sphere camera in Android, stay tuned today for more details on the metadata and how to apply it to your photos programmatically later.

In the new Google Play services, we’ve added APIs to give you the ability to check whether an image is a Photo Sphere and then open it up in the Photo Sphere viewer.

// This listener will be called with information about the given panorama.
OnPanoramaInfoLoadedListener infoLoadedListener =
  new OnPanoramaInfoLoadedListener() {
    @Override
    public void onPanoramaInfoLoaded(ConnectionResult result,
                                     Intent viewerIntent) {
        if (result.isSuccess()) {
            // If the intent is not null, the image can be shown as a
            // panorama.
            if (viewerIntent != null) {
                // Use the given intent to start the panorama viewer.
                startActivity(viewerIntent);
            }
        }
        
        // If viewerIntent is null, the image is not a viewable panorama.
    }
};

// Create client instance and connect to it.
PanoramaClient client = ...
...

// Once connected to the client, initiate the asynchronous check on whether
// the image is a viewable panorama.
client.loadPanoramaInfo(infoLoadedListener, panoramaUri);

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

Join the discussion on
+Android Developers

Designing for Tablets? We’re Here to Help!

2012-11-26T10:03:00.000-08:00

Posted by Roman Nurik, who often writes about Android design-related topics on Google+

So you’ve got a great Android phone app on Google Play, your users love it, and you’re kicking back and watching the download numbers soar. Congrats! But like any enterprising developer, you may be thinking, “how do I take my app’s success even further?” The answer: an equally awesome experience on tablets. Users love their tablet apps! For example, Mint.com found that the larger screen real estate allowed tablet users to engage with their budget data 7x more than on phones. And TinyCo found that on average, paying users spent 35% more on tablets than on handsets. So now is the right time to think about how your app translates onto these larger screen devices that are designed to meet users’ more generic, everyday computing needs.

In this post, we’ll recap some of the resources available for crafting a great tablet experience for your users. These resources are useful for everyone in the app development pipeline—from product managers, to designers, to developers, and QA engineers.

Android Design Guidelines

No conversation about Android app design or development should go very far without first consulting the Android Design guidelines. While most of the sections are relevant to all Android devices, certain sections stand out as particularly relevant to design on tablets.

The Devices and Displays page introduces the concept of density-independence. For example, although the Nexus 4, Nexus 7, and Motorola XOOM all have a similar pixel resolution (1280x768, 1280x800, and 1280x800 respectively), they have vastly different screens. Instead of thinking in pixels, think in dips (density-independent pixels)—that way, it’s much easier to conceptualize the difference between Nexus 4 (640x384 dp), Nexus 7 (960x600dp), and Nexus 10 or the Motorola XOOM (1280x800 dp).

Following the 48dp rhythm discussed in Metrics and Grids helps take some of the guesswork out of sizing elements, especially for tablets. When in doubt, use multiples of 48dp (or 16dp for a finer grid) for sizing elements horizontally and vertically. For example, when showing sparse content on larger screens, consider using generous side margins of 96dp or 144dp. Or when deciding how wide your master pane should be in a master/detail layout for 10” tablets, see how your master content looks and feels with a width of 240dp or 288dp.

The Multi-pane Layouts guide discusses use cases and examples for combining related views into a single screen to simultaneously improve app navigation and make optimal use of the available screen real estate. It also discusses strategies for laying out content across both portrait and landscape, all while maintaining functional parity across orientations. Since users enjoy using tablets in both portrait and landscape orientations, it’s even more important to react properly to orientation changes than with phones.

Lastly, the Downloadable Stencils offer designers a great starting point for high-fidelity mockups, complete with reference device outlines, correctly sized action bars, and more.

Android Training for Developers

The Training section of the developer site offers task-oriented technical training material, complete with flow diagrams, code snippets, sample projects and more. Several of these ‘classes’ are geared toward helping developers understand how to scale your apps across any screen size.

The Designing Effective Navigation class—aimed more at the initial design phase of the app creation process—offers a methodology for effectively planning and grouping screens on tablets, and even shows example wireframes for a simple news reader application following this methodology.

The classes Building a Dynamic UI with Fragments and Designing for Multiple Screens demonstrate how to use fragments in conjunction with Android’s resources framework. They show how to easily choose between tablet and handset layouts at runtime while maximizing code reuse and minimizing your application size using resource aliases. They also demonstrate techniques for adapting UI flows based on the current layout.

Lastly, while not precisely a training class, the Supporting Tablets and Handsets document offers even more information about some of these key best practices. And if you’re the type of developer that would prefer to skip the text and jump right into the code, you can even add a Master/Detail flow, complete with handset and tablet support, to your app with just a few clicks using the Android Developer Tools for Eclipse.

Android Design in Action Highlights

Each week, a few of us on the developer relations team get together on the Android Design in Action live show to discuss Android design best practices, as well as provide original ‘redesign’ mockups to help demonstrate our vision of how Android apps should look and feel.

A recent episode focused on the topic of responsive design, or designing flexible apps that can adapt to whatever screen size or form factor they’re run on:

In the episode, we celebrated successful examples of responsive design on Android, ranging from creating calendar events in Google Calendar, to browsing wallpapers and stories in Pattrn and Pocket, to playing video in TED, and finally to managing your conference schedule in the open-source Google I/O 2012 app.

We also regularly feature tablet design concepts on the show (some are shown below), so we highly recommend tuning in each week for design ideas.

For even more tablet app inspiration, check out a few of these apps: Expedia Hotels & Flights, Pulse News, SeriesGuide, Tasks and Timer.

The Tablet Quality Checklist

Over in the “Distribute” section of developer.android.com, the recently published Tablet App Quality checklist is a great way to check if your app is tablet-ready along a variety of technical dimensions. You should make sure that everyone involved in your mobile products is aware of the standards defined in this checklist, as it is one of the ways in which the Google Play team selects apps to feature in the Staff Picks for Tablets collection.

So What are You Waiting For?

2013 is almost here, and it’s looking to be another exciting year for Android tablets. Make sure your app is positioned to succeed in the evolving device landscape by following some of the best practices and examples discussed here and on the rest of developer.android.com.

If you have specific questions about your app, let us know on Google+ (+Android Developers) or Twitter (@AndroidDev)!

Join the discussion on +Android Developers

Android SDK Tools, Revision 21

2012-11-14T12:21:00.000-08:00

Posted by Xavier Ducrohet, Android SDK Tech Lead, and Angana Ghosh, Product Manager in Android

Along with the Android 4.2 SDK, we also launched a brand new update of the Android SDK Tools (Revision 21). The update includes new tools and capabilities that can help you work more efficiently as you create applications. Tools such as a new multi-config editor, and new Lint rules will help you develop apps more quickly, while a new UI test framework will give you more ways automate testing and QA for your apps. For new developers, one-click SDK download and new app templates help you get started more quickly.

Multi-config editor

A new multi-configuration editor allows you to develop and prototype your UI across various orientations, screen sizes and locales. For example, while editing your layout in portrait mode, you can see if your edits aren't visible in the shorter landscape orientation. You can see previews for other screen sizes from small phones to large tablets, you can see previews for the layout using all the available language translations in your app, and so on. You can even see how the layout appears when it is included as a fragment in a different larger layout. Finally, Android allows you to create specialized layouts for any of these configurations, and the multi configuration editor shows you these overridden layouts.

Here is a screenshot of the layout editor showing one of the layouts from the Google I/O application, across a variety of screen sizes.

More app templates

Tools R21 brings three new app templates to help you to easily add new screens to your app. There’s a new full-screen activity for use as a photo or video viewer, a settings activity to handle basic user preferences and a login activity to capture username/password.

UI Automator Test Framework

One common approach to UI testing is to run tests manually and verify that the app is behaving as expected. UI Automator is a new software testing framework available in Tools R21 that provides you with tools to easily automate UI testing tasks. It provides a GUI tool to scan and analyze the UI components of an Android application (uiautomatorviewer), a library containing APIs to create customized functional UI tests, and an execution engine to automate and run the tests against multiple physical devices. UI Automator runs on Android 4.1 (API level 16) or higher. To learn more head over to the UI Testing documentation.

One-click SDK installer

New Android SDK developers now have a convenient way to download all the various SDK components like Tools, Platform Tools, Eclipse ADT, and the latest system image with a single click. Existing developers can continue to manage their SDK components and get updates through the SDK Manager.

Revamped AVD creation dialog

The new dialog makes it easier to create Android Virtual Devices (AVDs) matching real device profiles. The AVDs will also appear in the layout editor to show you how the layouts will look.

More Lint rules

And to wrap things up there are 25 new lint rules which catch several common sources of bugs, for example deviations from Android design guide for icons, checks for mismanaged wakelocks, common sources of locale-related bugs and so on. So make sure you upgrade and let Lint loose on your projects before your next app update!

A minor bug-fix to the Android NDK is also available. For a complete list of what’s new, see the release notes for SDK Tools R21, ADT 21.0.0 and Android NDK R8c.

Join the discussion on
+Android Developers

Introducing Android 4.2, A New and Improved Jelly Bean

2012-11-13T10:04:00.000-08:00

Posted by Angana Ghosh, Product Manager in Android, and Dirk Dougherty, Android Developer Relations Team

Today we are making Android 4.2 (Jelly Bean) SDK platform available for download. Below are some of the highlights of Android 4.2, API level 17.

Performance

We've worked with our partners to run Renderscript computation directly in the GPU on the Nexus 10, a first for any mobile computation platform.

New ways to engage users

Users can now place interactive lock screen widgets directly on their device lock screens, for instant access to favorite apps and content. With just a small update, you can adapt any app widget to run on the lock screen. Daydream is an interactive screensaver mode that users can encounter when their devices are charging or docked in a desk dock. You can create interactive daydreams that users display in this mode, and they can include any type of content.

New interaction and entertainment experiences

Android 4.2 introduces platform support for external displays that goes beyond mirroring. Your apps can now target unique content to any number of displays attached to an Android device.

Enhancements for international users

To help you create better apps for users in languages such as Arabic, Hebrew, and Persian, Android 4.2 includes native RTL support, including layout mirroring. With native RTL support, you can deliver the same great app experience to all of your users with minimal extra work. Android 4.2 also includes a variety of font and character optimizations for Korean, Japanese, Indic, Thai, Arabic and Hebrew writing systems.

To get started developing and testing, download the Android 4.2 Platform from the Android SDK Manager. For a complete overview of what's new, take a look at the Android 4.2 platform highlights or read more of the details in the API overview.

Join the discussion on
+Android Developers

Android Developers Blog

New Ways to Optimize Your Business in Google Play

Play Store’s new view: apps designed for tablets

Beta testing and staged rollouts

Localization improvements

New Analytics and monetization features

Google Play for Education coming soon

Social Gaming, Location, and More in Google Play Services

Google Play games services

Location APIs

Google Cloud Messaging

Sign Up for Early Access

Google+ Cross-Platform Single Sign On

More About Google Play Services

Android Studio: An IDE built for Android

Extensible build tools

Powerful code editing

Smoother and richer GUI

Easy access to Google services within Android Tools

Open source development

Try Android Studio and give us feedback

Android at Google I/O 2013: Keynote Wrapup

Google Play Services 3.1

Android Studio: A new IDE for Android development

Google Play Developer Console: a better distribution experience

Follow the Android Sessions

All Google Play Developers Can Now Reply to User Reviews

Android at Google I/O 2013

Tablet Optimization Tips in the Google Play Developer Console

Update on Tablet App Guidelines and Screenshots

New Look, New Purchase Flow in Google Play

Now is the time to switch to the new Google Play Developer Console

Native RTL support in Android 4.2

Google+ Sign-In Now Part of Google Play Services

Google+ Sign-In

Over-the-air installs from your website

App customization

Interactive posts

App activity that’s useful, not annoying

Measure and monitor key metrics

More about Google+ Sign-In

Google Maps Android API v2

More About Google Play Services

Using Cryptography to Store Credentials Safely

An anti-pattern

The right way

Even more security

Check your apps for proper use of SecureRandom

Security Enhancements in Jelly Bean

Content Provider default access has changed

New implementation of SecureRandom

JavascriptInterface methods in WebViews must now be annotated

Secure USB debugging

More information about security best practices

Android Developer Story: Smule

Evolution of Renderscript Performance

Verifying Back-End Calls from Android Apps

Summary

App Registration

Make Client IDs

In Your Android App

Magic Happens

Send the Token

Use the Token

Verify Signature

Verify Token Fields

What’s Next?

Code Fragments

Daydream: Interactive Screen Savers

An attract mode for apps

The architecture of a Daydream

A few more idle thoughts

Further reading and samples

Localize Your Promotional Graphics on Google Play

The 2012 Android Developer Survey

In-App Billing Version 3

Easier to Implement

Local Caching

Product Information

Sample Application

Easy access to Google services
within Android Tools