Oct 18

Building a Titan: Better security through a tiny chip


Posted by Nagendra Modadugu and Bill Richardson, Google Device Security Group

At the Made by Google event last week, we talked about the combination of AI + Software + Hardware to help organize your information. To better protect that information at a hardware level, our new Pixel 3 and Pixel 3 XL devices include a Titan M chip.We briefly introduced Titan M and some of its benefits on our Keyword Blog, and with this post we dive into some of its technical details.

Titan M is a second-generation, low-power security module designed and manufactured by Google, and is a part of the Titan family. As described in the Keyword Blog post, Titan M performs several security sensitive functions, including:

  • Storing and enforcing the locks and rollback counters used by Android Verified Boot.
  • Securely storing secrets and rate-limiting invalid attempts at retrieving them using the Weaver API.
  • Providing backing for the Android Strongbox Keymaster module, including Trusted User Presence and Protected Confirmation. Titan M has direct electrical connections to the Pixel’s side buttons, so a remote attacker can’t fake button presses. These features are available to third-party apps, such as FIDO U2F Authentication.
  • Enforcing factory-reset policies, so that lost or stolen phones can only be restored to operation by the authorized owner.
  • Ensuring that even Google can’t unlock a phone or install firmware updates without the owner’s cooperation with Insider Attack Resistance.

Including Titan M in Pixel 3 devices substantially reduces the attack surface. Because Titan M is a separate chip, the physical isolation mitigates against entire classes of hardware-level exploits such as Rowhammer, Spectre, and Meltdown. Titan M’s processor, caches, memory, and persistent storage are not shared with the rest of the phone’s system, so side channel attacks like these—which rely on subtle, unplanned interactions between internal circuits of a single component—are nearly impossible. In addition to its physical isolation, the Titan M chip contains many defenses to protect against external attacks.

But Titan M is not just a hardened security microcontroller, but rather a full-lifecycle approach to security with Pixel devices in mind. Titan M’s security takes into consideration all the features visible to Android down to the lowest level physical and electrical circuit design and extends beyond each physical device to our supply chain and manufacturing processes. At the physical level, we incorporated essential features optimized for the mobile experience: low power usage, low-latency, hardware crypto acceleration, tamper detection, and secure, timely firmware updates. We improved and invested in the supply chain for Titan M by creating a custom provisioning process, which provides us with transparency and control starting from the earliest silicon stages.

Finally, in the interest of transparency, the Titan M firmware source code will be publicly available soon. While Google holds the root keys necessary to sign Titan M firmware, it will be possible to reproduce binary builds based on the public source for the purpose of binary transparency.

A closer look at Titan M

Titan (left) and Titan M (right)

Titan M’s CPU is an ARM Cortex-M3 microprocessor specially hardened against side-channel attacks and augmented with defensive features to detect and respond to abnormal conditions. The Titan M CPU core also exposes several control registers, which can be used to taper access to chip configuration settings and peripherals. Once powered on, Titan M verifies the signature of its flash-based firmware using a public key built into the chip’s silicon. If the signature is valid, the flash is locked so it can’t be modified, and then the firmware begins executing.

Titan M also features several hardware accelerators: AES, SHA, and a programmable big number coprocessor for public key algorithms. These accelerators are flexible and can either be initialized with keys provided by firmware or with chip-specific and hardware-bound keys generated by the Key Manager module. Chip-specific keys are generated internally based on entropy derived from the True Random Number Generator (TRNG), and thus such keys are never externally available outside the chip over its entire lifetime.

While implementing Titan M firmware, we had to take many system constraints into consideration. For example, packing as many security features into Titan M’s 64 Kbytes of RAM required all firmware to execute exclusively off the stack. And to reduce flash-wear, RAM contents can be preserved even during low-power mode when most hardware modules are turned off.

The diagram below provides a high-level view of the chip components described here.

Better security through transparency and innovation

At the heart of our implementation of Titan M are two broader trends: transparency and building a platform for future innovation.

Transparency around every step of the design process — from logic gates to boot code to the applications — gives us confidence in the defenses we’re providing for our users. We know what’s inside, how it got there, how it works, and who can make changes.

Custom hardware allows us to provide new features, capabilities, and performance not readily available in off-the-shelf components. These changes allow higher assurance use cases like two-factor authentication, medical device control, P2P payments, and others that we will help develop down the road.

As more of our lives are bound up in our phones, keeping those phones secure and trustworthy is increasingly important. Google takes that responsibility seriously. Titan M is just the latest step in our continuing efforts to improve the privacy and security of all our users.


Android Developers Blog

Sep 27

Building better apps with Runtime Permissions

Posted by Ian Lake, Developer Advocate

Android devices do a lot, whether it is taking pictures, getting directions or making phone calls. With all of this functionality comes a large amount of very sensitive user data including contacts, calendar appointments, current location, and more. This sensitive information is protected by permissions, which each app must have before being able to access the data. Android 6.0 Marshmallow introduces one of the largest changes to the permissions model with the addition of runtime permissions, a new permission model that replaces the existing install time permissions model when you target API 23 and the app is running on an Android 6.0+ device.

Runtime permissions give your app the ability to control when and with what context you’ll ask for permissions. This means that users installing your app from Google Play will not be required to accept a list of permissions before installing your app, making it easy for users to get directly into your app. It also means that if your app adds new permissions, app updates will not be blocked until the user accepts the new permissions. Instead, your app can ask for the newly added runtime permissions as needed.

Finding the right time to ask for runtime permissions has an important impact on your app’s user experience. We’ve gathered a number of design patterns in our new Permission design guidelines including best practices around when to request permissions, how to explain why permissions are needed, and how to handle permissions being denied.

Ask up front for permissions that are obvious

In many cases, you can avoid permissions altogether by using the existing intents system to utilize other existing specialized apps rather than building a full experience within your app. An example of this is using ACTION_IMAGE_CAPTURE to start an existing camera app the user is familiar with rather than building your own camera experience. Learn more about permissions versus intents.

However, if you do need a runtime permission, there’s a number of tools to help you. Checking for whether your app has a permission is possible with ContextCompat.checkSelfPermission() (available as part of revision 23 of the support-v4 library for backward compatibility) and requesting permissions can be done with requestPermissions(), bringing up the system controlled permissions dialog to allow the user to grant you the requested permission(s) if you don’t already have them. Keep in mind that users can revoke permissions at any time through the system settings so you should always check permissions every time.

A special note should be made around shouldShowRequestPermissionRationale(). This method returns true if the user has denied your permission request at least once yet have not selected the ‘Don’t ask again’ option (which appears the second or later time the permission dialog appears). This gives you an opportunity to provide additional education around the feature and why you need the given permission. Learn more about explaining why the app needs permissions.

Read through the design guidelines and our developer guide for all of the details in getting your app ready for Android 6.0 and runtime permissions. Making it easy to install your app and providing context around accessing user’s sensitive data are key changes you can make to build better apps.

Join the discussion on

+Android Developers


Android Developers Blog

Sep 02

Pixel Security: Better, Faster, Stronger

Posted by Paul Crowley, Senior Software Engineer and Paul Lawrence, Senior Software Engineer

Encryption protects your data if your phone falls into someone else’s hands. The
new Google Pixel and Pixel XL are encrypted by default to offer strong data
protection, while maintaining a great user experience with high I/O performance
and long battery life. In addition to encryption, the Pixel phones debuted
running the Android Nougat release, which has even more security
improvements.

This blog post covers the encryption implementation on Google Pixel devices and
how it improves the user experience, performance, and security of the device.

File-Based Encryption Direct Boot experience

One of the security features introduced in Android Nougat was file-based
encryption. File-based encryption (FBE) means different files are encrypted
with different keys that can be unlocked independently. FBE also separates data
into device encrypted (DE) data and credential encrypted (CE) data.

Direct
boot uses file-based encryption to allow a seamless user experience when a
device reboots by combining the unlock and decrypt screen. For users, this means
that applications like alarm clocks, accessibility settings, and phone calls are
available immediately after boot.

Enhanced with TrustZone® security

Modern processors provide a means to execute code in a mode that remains secure
even if the kernel is compromised. On ARM®-based processors this mode is known
as TrustZone. Starting in Android Nougat, all disk encryption keys are stored
encrypted with keys held by TrustZone software. This secures encrypted data in
two ways:

  • TrustZone enforces the Verified Boot
    process. If TrustZone detects that the operating system has been modified, it
    won’t decrypt disk encryption keys; this helps to secure device encrypted (DE)
    data.

  • TrustZone enforces a waiting period between guesses at the user credential,
    which gets longer after a sequence of wrong guesses. With 1624 valid four-point
    patterns and TrustZone’s ever-growing waiting period, trying all patterns would
    take more than four years. This improves security for all users, especially
    those who have a shorter and more easily guessed pattern, PIN, or
    password.

Encryption on Pixel phones

Protecting different folders with different keys required a distinct approach
from full-disk
encryption (FDE). The natural choice for Linux-based systems is the
industry-standard eCryptFS. However, eCryptFS didn’t meet our performance
requirements. Fortunately one of the eCryptFS creators, Michael Halcrow, worked
with the ext4 maintainer, Ted Ts’o, to add encryption natively to ext4, and
Android became the first consumer of this technology. ext4 encryption
performance is similar to full-disk encryption, which is as performant as a
software-only solution can be.

Additionally, Pixel phones have an inline hardware encryption engine, which
gives them the ability to write encrypted data at line speed to the flash
memory. To take advantage of this, we modified ext4 encryption to use this
hardware by adding a key reference to the bio structure, within the ext4 driver
before passing it to the block layer. (The bio structure is the basic container
for block I/O in the Linux kernel.) We then modified the inline encryption block
driver to pass this to the hardware. As with ext4 encryption, keys are managed
by the Linux keyring. To see our implementation, take a look at the source
code for the Pixel kernel.

While this specific implementation of file-based encryption using ext4 with
inline encryption benefits Pixel users, FBE is available in AOSP and ready to
use, along with the other features mentioned in this post.


Android Developers Blog

Aug 24

Tips to be better found and discovered on Google Play

Posted by Andrew Ahn, Product Manager, Google Play

We’re constantly working on ways to make Google Play a great place for users to
discover apps and games they’ll love. We know this is crucial to most developers
ongoing success. There are steps you can take to ensure your app is primed for
success – that’s why we’re sharing a reminder of some of our top tips for
getting your app discovered on Google Play.

Build for quality

First, build for quality. Android users expect high-quality apps. App quality
directly influences the long-term success of your app – in terms of installs,
user rating and reviews, engagement, and user retention. These are some of the
factors that go into our search and discovery systems that help discern what
apps to recommend and surface across our Google Play experiences. When building
your app, check against the quality
criteria, and use what you need from the material design guidelines to make
sure you are delivering a highly usable experience. Also, be sure to test your
app for functional quality. Opt-in to the pre-launch
report for your alpha and beta apps in the Google Play Developer Console and
you’ll receive a report for each APK showing how it performs on real devices. This will help you identify crashes and other issues before you release your app.

Example: Designing for high usability through Google Material Design.

Request only the permissions you need

Second, be considerate on which permission settings to enable for your app. We
see that there are some apps that ask for very sensitive permissions, even when
the app doesn’t use them. (For example, a camera app asking for read and write
permissions to call logs.) Excessive app permissions may dissuade users from
installing your app. In fact, one study, in which users
were shown two unbranded apps with similar ratings that had the same
functionality but different sets of permission requests, showed that users were,
on average, 3 times more likely to install the app with fewer permissions
requests. And a similar
study showed that users are 1.7 times more likely, on average, to select the
application with fewer permission requests. The rule of thumb is to enable
permissions that are only essential to your app. Read the best
practices for app permissions.

Chart:
Distribution of permission groups use across Arcade Games category.

If you’re building an arcade game, you many only need a very few permission
settings, if any.

Listen and respond to your users

Lastly, be attentive to user feedback. It’s ultimately the users who drive our
search and discovery systems. When you hear user feedback about bugs or other
issues, we recommend engaging with the feedback and, if needed, updating your
app in a timely manner. Having an up-to-date app that reflects your user’s
feedback can help you gain more installs, engagement, and higher ratings. Beta
testing is a good way to get feedback from real users before launch. You can
also check the ratings
and reviews section of the Developer Console to see an analysis of what
users are saying about your app and how that is affecting your rating compared
to similar apps.

Review benchmarks in the Developer Console uses machine learning to give you
insights about what users are saying about your app and how it affects your
rating.

Google Play strives to help users find and discover the most safe, high quality,
useful, and relevant apps. Building apps that put user’s interest first will
help you be successful in Google Play. For more tips and best practices for
building a successful app business on Google Play, get the Playbook for Developers app.

How useful did you find this blogpost?



Android Developers Blog

Jul 27

AndroidX Development is Now Even Better


Posted by Aurimas Liutikas, software engineer on AndroidX team

AndroidX (previously known as Android Support Library) started out as a small set of libraries intended to provide backwards compatibility for new Android platform APIs and, as such, its development was strictly tied to the platform. As a result, all work was done in internal Google branches and then pushed to the public Android Open Source Project (AOSP) together with the platform push. With this flow, external contributions were limited to a narrow window of time where the internal and AOSP branches were close in content. On top of that, it was difficult to contribute — in order to do a full AndroidX build and testing, external developers had to check out >40GB of the full Android platform code.

Today, the scope of AndroidX has expanded dramatically and includes libraries such as AppCompat for easier UI development, Room for database management, and WorkManager for background work. Many of these libraries implement higher-level abstractions and are less tied to new revisions of the Android platform, and all libraries are designed with backwards compatibility in mind from the start. Several libraries, such as RecyclerView and Fragment, are purely AndroidX-side implementations with few ties to the platform.

Starting a little over two years ago, we began a process of unbundling — moving AndroidX out of Android platform builds into its own separate build. We had to do a great deal of work, including migrating our builds from make to Gradle as well as migrating all of our API tracking tools and documentation generation out of the platform build. With that process completed, we reached a point where a developer can now check out a minimal AndroidX project, open it in Android Studio, and build using the public SDK and public Android Gradle Plugin.

The Android developer community has long expressed a desire to contribute more easily to AndroidX; however, this was always a challenge due to the reasons described above. This changes today: AndroidX development is moving to public AOSP. That means that our primary feature development (except for top-secret integrations with the platform ????) and bug fixes will be done in the open using the r.android.com Gerrit review tool and changes will be visible in the aosp/androidx-master-dev branch.

We are making this change to give better transparency to developers; it gives developers a chance to see features and bug fixes implemented in real-time. We are also excited about receiving bug fix contributions from the community. We have written up a short guide on how to go about contributing a patch.

In addition to regular development, AOSP will be a place for experimentation and prototyping. You will see new libraries show up in this repository; some of them may be removed before they ship, change dramatically during pre-alpha development, or merge into existing libraries. The general rule is that only the libraries on maven.google.com are officially ready for external developer usage.

Finally, we are just getting started. We apologize for any rough edges that you might have when contributing to AndroidX, and we request your feedback via the public AndroidX tracker if you hit any issues.


Android Developers Blog

Jul 14

Pixel Security: Better, Faster, Stronger

Posted by Paul Crowley, Senior Software Engineer and Paul Lawrence, Senior Software Engineer

Encryption protects your data if your phone falls into someone else’s hands. The
new Google Pixel and Pixel XL are encrypted by default to offer strong data
protection, while maintaining a great user experience with high I/O performance
and long battery life. In addition to encryption, the Pixel phones debuted
running the Android Nougat release, which has even more security
improvements.

This blog post covers the encryption implementation on Google Pixel devices and
how it improves the user experience, performance, and security of the device.

File-Based Encryption Direct Boot experience

One of the security features introduced in Android Nougat was file-based
encryption. File-based encryption (FBE) means different files are encrypted
with different keys that can be unlocked independently. FBE also separates data
into device encrypted (DE) data and credential encrypted (CE) data.

Direct
boot uses file-based encryption to allow a seamless user experience when a
device reboots by combining the unlock and decrypt screen. For users, this means
that applications like alarm clocks, accessibility settings, and phone calls are
available immediately after boot.

Enhanced with TrustZone® security

Modern processors provide a means to execute code in a mode that remains secure
even if the kernel is compromised. On ARM®-based processors this mode is known
as TrustZone. Starting in Android Nougat, all disk encryption keys are stored
encrypted with keys held by TrustZone software. This secures encrypted data in
two ways:

  • TrustZone enforces the Verified Boot
    process. If TrustZone detects that the operating system has been modified, it
    won’t decrypt disk encryption keys; this helps to secure device encrypted (DE)
    data.

  • TrustZone enforces a waiting period between guesses at the user credential,
    which gets longer after a sequence of wrong guesses. With 1624 valid four-point
    patterns and TrustZone’s ever-growing waiting period, trying all patterns would
    take more than four years. This improves security for all users, especially
    those who have a shorter and more easily guessed pattern, PIN, or
    password.

Encryption on Pixel phones

Protecting different folders with different keys required a distinct approach
from full-disk
encryption (FDE). The natural choice for Linux-based systems is the
industry-standard eCryptFS. However, eCryptFS didn’t meet our performance
requirements. Fortunately one of the eCryptFS creators, Michael Halcrow, worked
with the ext4 maintainer, Ted Ts’o, to add encryption natively to ext4, and
Android became the first consumer of this technology. ext4 encryption
performance is similar to full-disk encryption, which is as performant as a
software-only solution can be.

Additionally, Pixel phones have an inline hardware encryption engine, which
gives them the ability to write encrypted data at line speed to the flash
memory. To take advantage of this, we modified ext4 encryption to use this
hardware by adding a key reference to the bio structure, within the ext4 driver
before passing it to the block layer. (The bio structure is the basic container
for block I/O in the Linux kernel.) We then modified the inline encryption block
driver to pass this to the hardware. As with ext4 encryption, keys are managed
by the Linux keyring. To see our implementation, take a look at the source
code for the Pixel kernel.

While this specific implementation of file-based encryption using ext4 with
inline encryption benefits Pixel users, FBE is available in AOSP and ready to
use, along with the other features mentioned in this post.


Android Developers Blog

Jun 22

Better Biometrics in Android P


Posted by Vishwath Mohan, Security Engineer

To keep users safe, most apps and devices have an authentication mechanism, or a way to prove that you’re you. These mechanisms fall into three categories: knowledge factors, possession factors, and biometric factors. Knowledge factors ask for something you know (like a PIN or a password), possession factors ask for something you have (like a token generator or security key), and biometric factors ask for something you are (like your fingerprint, iris, or face).

Biometric authentication mechanisms are becoming increasingly popular, and it’s easy to see why. They’re faster than typing a password, easier than carrying around a separate security key, and they prevent one of the most common pitfalls of knowledge-factor based authentication—the risk of shoulder surfing.

As more devices incorporate biometric authentication to safeguard people’s private information, we’re improving biometrics-based authentication in Android P by:

  • Defining a better model to measure biometric security, and using that to functionally constrain weaker authentication methods.
  • Providing a common platform-provided entry point for developers to integrate biometric authentication into their apps.

A better security model for biometrics

Currently, biometric unlocks quantify their performance today with two metrics borrowed from machine learning (ML): False Accept Rate (FAR), and False Reject Rate (FRR).

In the case of biometrics, FAR measures how often a biometric model accidentally classifies an incorrect input as belonging to the target user—that is, how often another user is falsely recognized as the legitimate device owner. Similarly, FRR measures how often a biometric model accidentally classifies the user’s biometric as incorrect—that is, how often a legitimate device owner has to retry their authentication. The first is a security concern, while the second is problematic for usability.

Both metrics do a great job of measuring the accuracy and precision of a given ML (or biometric) model when applied to random input samples. However, because neither metric accounts for an active attacker as part of the threat model, they do not provide very useful information about its resilience against attacks.

In Android 8.1, we introduced two new metrics that more explicitly account for an attacker in the threat model: Spoof Accept Rate (SAR) and Imposter Accept Rate (IAR). As their names suggest, these metrics measure how easily an attacker can bypass a biometric authentication scheme. Spoofing refers to the use of a known-good recording (e.g. replaying a voice recording or using a face or fingerprint picture), while impostor acceptance means a successful mimicking of another user’s biometric (e.g. trying to sound or look like a target user).

Strong vs. Weak Biometrics

We use the SAR/IAR metrics to categorize biometric authentication mechanisms as either strong or weak. Biometric authentication mechanisms with an SAR/IAR of 7% or lower are strong, and anything above 7% is weak. Why 7% specifically? Most fingerprint implementations have a SAR/IAR metric of about 7%, making this an appropriate standard to start with for other modalities as well. As biometric sensors and classification methods improve, this threshold can potentially be decreased in the future.

This binary classification is a slight oversimplification of the range of security that different implementations provide. However, it gives us a scalable mechanism (via the tiered authentication model) to appropriately scope the capabilities and the constraints of different biometric implementations across the ecosystem, based on the overall risk they pose.

While both strong and weak biometrics will be allowed to unlock a device, weak biometrics:

  • require the user to re-enter their primary PIN, pattern, password or a strong biometric to unlock a device after a 4-hour window of inactivity, such as when left at a desk or charger. This is in addition to the 72-hour timeout that is enforced for both strong and weak biometrics.
  • are not supported by the forthcoming BiometricPrompt API, a common API for app developers to securely authenticate users on a device in a modality-agnostic way.
  • can’t authenticate payments or participate in other transactions that involve a KeyStore auth-bound key.
  • must show users a warning that articulates the risks of using the biometric before it can be enabled.

These measures are intended to allow weaker biometrics, while reducing the risk of unauthorized access.

BiometricPrompt API

Starting in Android P, developers can use the BiometricPrompt API to integrate biometric authentication into their apps in a device and biometric agnostic way. BiometricPrompt only exposes strong modalities, so developers can be assured of a consistent level of security across all devices their application runs on. A support library is also provided for devices running Android O and earlier, allowing applications to utilize the advantages of this API across more devices .

Here’s a high-level architecture of BiometricPrompt.

The API is intended to be easy to use, allowing the platform to select an appropriate biometric to authenticate with instead of forcing app developers to implement this logic themselves. Here’s an example of how a developer might use it in their app:

Conclusion

Biometrics have the potential to both simplify and strengthen how we authenticate our digital identity, but only if they are designed securely, measured accurately, and implemented in a privacy-preserving manner.

We want Android to get it right across all three. So we’re combining secure design principles, a more attacker-aware measurement methodology, and a common, easy to use biometrics API that allows developers to integrate authentication in a simple, consistent, and safe manner.

Acknowledgements: This post was developed in joint collaboration with Jim Miller


Android Developers Blog

Mar 03

Introducing new app categories — From Art to Autos to Dating — to help users better find your apps

Posted by By Sarah Karam, Google Play Apps Business Development

With more than 1 billion active users in 190 countries around the world, Google
Play continues to be an important distribution platform for you to build a
global audience. To help you get your apps in front of more users, it’s
important to make them more quickly and easily discoverable in Google Play.
That’s why we rolled out major features, such as Search
Ads, Indie
Corner, store
listing experiments, and more, over the past year.

To improve the overall search experience, we’re introducing new app categories
and renaming a few existing ones, making them more comprehensive and relevant to
what users are looking for today.

The new categories include:

  • Art & Design
  • Auto & Vehicles
  • Beauty
  • Dating
  • Events
  • Food & Drink
  • House & Home
  • Parenting

In addition, the “Transportation” category will be renamed “Maps & Navigation,”
and the “Media & Video” category will be renamed “Video Players & Editors.”

To select a new category for your app or game

  1. Sign in to your Google Play
    Developer Console.

  2. Select an app.
  3. On the left menu, click Store Listing.
  4. Under “Categorization,” select an application type and category.
  5. Near the top of the page, click Save draft (new apps) or Submit update
    (existing apps).

Newly added categories will be available on Google Play within 60 days. If you
choose a newly added category for an app before the category is available for
users, your current app category may change. See additional details and view our
full list of categories in the Help
Center.


Android Developers Blog

Feb 15

A better way to track your promotions on Google Play Billing

Posted by Neto Marin, Developer Advocate

Promotions can be a valuable tool to increase user engagement or attract new users by offering content or features to a limited number of users free of charge.

We are happy to share an improvement in the Google Play Developer API that makes it easier to track your promotions from your own backend. Starting today, the API for Purchases.products will return “Promo" as a new value for the field purchaseType when the user redeems a promo code. Now, the possible values are:

  • 0. Test (test purchases)
  • 1. Promo (Promo code redemption purchase)

For purchases made using the standard in-app billing flow, the field will continue to not be set in the API response.

Please note: This state is only returned by the Purchases.products API. For subscriptions you may use Free Trials to offer free of charge subscription periods.

For more details about how to create and redeem promo codes, check the In-app Promotions documentation. For more details about the server-side API, check the Google Play Developer API documentation.


Android Developers Blog

Dec 07

What’s new in Google Play at I/O 2016: better betas, the pre-launch report, benchmarks, a new Play Console app, and more

Posted by Purnima Kochikar, Director, Google Play Apps & Games

Google Play reaches over 1 billion monthly active users giving developers the world’s largest app distribution platform. Last year, Play users installed apps 65 billion times. To keep that great momentum going, we’re continuing to listen to your feedback and invest in more ways to help you grow your app or game business. Today, we’re sharing new features that benefit developers of all sizes.

 




Improvements to beta tests and app discovery on Google Play

Beta testing is a crucial tool that many developers use in the Google Play Developer Console to test their apps with real users, gather feedback, and make improvements before launching widely. Open beta tests are helpful to get feedback from a large group of users and allow any user to join a beta test. We’re making open beta tests easier to find and participate in: apps that are available only as open betas and aren’t in production yet will soon appear in Play search results, users will be able to opt-in from Play store listings directly, and users will be able to send you private feedback through your Play store listing too.

We’ll also be adding a new featured section to the store, called Google Play Early Access, showcasing a hand-picked group of promising open betas that haven’t gone to production yet.

There are more than a million apps available on Google Play and we continue to work on making it easy for people to discover the apps they’ll love. To that end, you’ll start seeing new collections on the store for tasks that might require a combination of apps. For example, when you’re buying a house, you’ll see the best apps for finding real estate, keeping notes, getting a mortgage, and travelling in the area in one handy collection. Developers don’t need to take any action to take advantage of this benefit, apps will automatically be chosen. These contextual collections make it easier for users to discover complimentary apps as well as new types of apps.

Users can now opt-in to beta
tests from the Play Store
An example of a new collection
for apps relating to buying a house

Improve your app with the Play pre-launch report

Your app business relies on having high quality apps. To achieve quality, your apps need to be tested on a range of real devices before you ship them to your users. Play’s new pre-launch report summarizes issues found when testing your app on Firebase Test Lab for Android on a wide range of devices.




The pre-launch report in the Developer Console

Along with diagnostics to help you fix any crashes we detected in your app, your reports will also include screenshots from devices that use different Android versions, languages, and screen resolutions. These can help you find layout issues. We’ve also included early warnings of known security vulnerabilities that may have sneaked into your app — even via third party libraries you rely on. You can enable the pre-launch report in the Developer Console.


Gain deeper insights from user reviews at a glance and reply to user reviews more easily

Your app reviews offer a wealth of information on what your users like and dislike about your app. We’re expanding on the improvements we made to ratings and reviews earlier this year, to offer you more ways to take advantage of reviews and better engage your audience.

Review benchmarks let you see your app’s rating distribution compared to similar apps in your category for a list of common topics which are relevant for all apps – like design, stability, and speed. You are also able to see how each area impacts your app’s rating. Review topics will let you see your app’s rating distribution for a list of topics which are specific to your app. With this analysis functionality, you can more easily identify what users think of your app and where to focus your improvement efforts.




Review benchmarks in the Developer Console

Developers frequently tell us they find replying to reviews valuable as a channel to directly engage their audience and gather feedback. In fact, we have found that users who update their star rating after a developer has responded to their review increase it by an average of 0.7 stars. For developers who have their own customer support solutions, we’re making replying easier with a new Reply to Reviews API. In the last few months, we’ve tested the API with Zendesk and Conversocial, so you can now start replying to reviews directly from those popular platforms or build your own custom integration.




Developers can now reply to reviews on Google Play from platorms
such as Zendesk and Conversocial

Understand more about user acquisition and conversion, and see how you’re doing compared to others

The User Acquisition performance report in the Developer Console gives you a snapshot of how many users visit your store listing, how many install your app, and how many go on to make purchases. We’ve now added the ability to see user acquisition data by country and you’ll soon be able to see user acquisition benchmarks and compare your app’s conversion rates to similar apps on the Play store. With this data, you can find opportunities to focus your marketing efforts and increase your installs with tools like Store Listing Experiments.



User acquisition country data in the Developer Console



Building apps and games for billions of users

Hundreds of millions of users, many of them in emerging markets, are coming online and, for many of them, their first experience is on an Android device.
 

To help you get your app ready for this opportunity, we’ve created Building for Billions guidelines with a development checklist to help you optimize your app. You can also get more in-depth tips and best practices for expanding to new markets in the accompanying Building for Billions Playbook

To help you meet local expectations when you set your prices and make purchases more attractive to your users, the Developer Console will now automatically round prices to local conventions in each market. For example, for a US app priced at $ 1.99, a user in Japan would see ¥200 rather than a non-rounded price from a straight FX conversion. You can also set up pricing templates to change pricing for products in bulk. You can make this change in the Developer Console.

While you’re working on getting your app ready for billions of users, we’ve been enhancing the Google Play experience for them too. With improved compression, we’ve made app updates more data efficient, and we’re focusing on making the Play Store itself faster than ever on all connection types.

We’ve also revamped how we select visible apps in key markets like India and Brazil to better showcase apps that are more relevant locally and apps made by local developers. And we continue to add more payment methods in new countries, including carrier billing and gift cards in India and Indonesia.

Two new apps: Get your app data and important notifications on the go, and stay up to date with best practices

To give you access to your data when you need it, and to keep you informed of crucial business updates with notifications, we’re launching the Play Console app. You can access your app’s data including installs, uninstalls, crashes, ratings, and reviews. You can also receive push notifications for important news like when your app update is live on Google Play. And you can even reply to reviews directly in the app, making it easier and quicker to engage your audience when you want to. Get the Play Console app on Google Play today.

Staying on top of all the features and best practices and strategies you should consider when growing your business can be a challenge. We’ve built another app, the Playbook by Google Play. The Playbook is a tailored list, based on your objectives, of the latest articles and videos from Google experts and across the web to help you grow a successful business on Google Play. Join the Playbook beta today and let us know your feedback.

The Play Console app
Playbook by Google Play

Finally, we will be soon making some updates to the Developer Distribution Agreement (DDA), which includes the ability for family members to share purchased apps on Google Play. Here you can see the updated DDA.



To learn more about all of these features, tune-in live to ‘What’s new in Google Play for developers’ at 11am PDT / 2pm EDT / 7:00pm GMT+1 on May 19 on the Google Developers YouTube channel.

If you’re attending I/O, come and visit the Google Play sandbox to get your app reviewed by experts.

Whether you’re attending I/O in person, at one of the many I/O Extended events around the world, or just watching from home, you can find more Google Play sessions in the I/O 2016 schedule.


Android Developers Blog