27 April 2017

SafetyNet attestation, a building block for anti-abuse

Posted by Arindam Basu, Borbala Benko, Alan Butler, Edward Cunningham, William Luh

Building innovative security features for Android app developers and their users continues to be a priority. As part of this effort, we provide SafetyNet attestation, an API for developers to remotely evaluate whether they are talking to a genuine Android device.

SafetyNet examines software and hardware information on the device to assess its integrity. The result is a cryptographically signed statement, attesting basic properties of the device — such as overall integrity and compatibility with Android (CTS) — as well as metadata about your app, such as its package name and signature. The following JSON snippet shows an example of how the API reports this information:

  "nonce": "R2Rra24fVm5xa2Mg",
  "timestampMs": 9860437986543,
  "apkPackageName": "com.package.name.of.requesting.app",
  "apkCertificateDigestSha256": ["base64 encoded, SHA-256 hash of the
                                  certificate used to sign requesting app"],
  "apkDigestSha256": "base64 encoded, SHA-256 hash of the app's APK",
  "ctsProfileMatch": true,
  "basicIntegrity": true,
The contents of an example attestation response, providing information about the calling app and the integrity and compatibility of the device.

The SafetyNet attestation API can help your server distinguish traffic coming from genuine, compatible Android devices from traffic coming from less-trusted sources, including non-Android devices. This classification helps you better understand the risks associated with each device so that you can fine-tune preventive or mitigative actions in case of abuse or misbehavior.

We encourage developers to use SafetyNet attestations to augment their anti-abuse strategy. Combine SafetyNet attestation with other signals, such as your existing device-side signals and behavioral signals about what the user is trying to do, in order to build robust, multi-tier protection systems.

For further information, check the recently updated documentation and see the SafetyNet API Samples on GitHub.

24 April 2017

The Google Play Awards are returning to Google I/O

Posted by Purnima Kochikar, Director, Apps and Games Business Development, Google Play

Drum roll please! The Google Play Awards are back again this year and will take place Thursday, May 18th at 6:30pm (Pacific Time) during Google I/O, our annual developer festival.

The annual ceremony is a great opportunity for the industry to recognize outstanding developers that continue to set the bar for quality apps and games showing a passion for driving innovation and adoption of new platforms and user experiences.

This year we'll be honoring partners across 12 award categories, some familiar and some new. Nominees were selected much like last year by cross-functional teams throughout Google who work hand-in-hand with the relevant categories and product areas. While category specific criteria can be found below, the common requirements across all categories focused on high star rating, technical performance and freshness, requiring a launch or major update since April 2016. The winners of each category will be announced at Google I/O in May.

The full list of categories and nominees are below and can also be found at g.co/play/GPA2017:

Standout Indie

Games from indie developers that focus on artistic design, gameplay mechanics and overall polish. And the nominees are…… 

Awards category: Standout Indie

Standout Startup

Apps from new developers that offer a unique experience while achieving strong organic install growth. And the nominees are……
Awards category: Standout Startup

Best Android Wear Experience

New wear 2.0 apps offering great design, user delight and functionality. And the nominees are…
Awards category: Best Android Wear Experience

Best TV Experience

Apps or games leveraging innovative features for the large-screen format while providing an immersive and intuitive experience. And the nominees are…
Awards category: Best TV Experience

Best VR Experience

Highly engaging and immersive experience with optimal use of Daydream UI. And the nominees are…
Awards category: Best VR Experience

Best AR Experience

Apps or games harnessing the creative and imaginative technology of AR. And the nominees are…
Awards category: Best AR Experience

Best App for Kids

Apps or games with family friendly design that encourage creativity, exploration and education. And the nominees are…
Awards category: Best App for Kids

Best Multiplayer Game

Games built to connect gamers in competitive and engaging multiplayer experiences. And the nominees are…

Awards category: Best Multiplayer Game

Best App

A true representation of beautiful design, intuitive UX and high user appeal. And the nominees are…
Awards category: Best App

Best Game

Games with strong mechanics, stellar graphics and strong engagement and retention tactics. And the nominees are...
Awards category: Best Game

Best Accessibility Experience

Apps or games enabling device interaction in an innovative way that serves people with disabilities or special needs. And the nominees are…
Awards category: Best Accessibility Experience

Best Social Impact

Apps that creates meaningful social impact for a broad spectrum of people around the world. And the nominees are…
Awards category: Best Social Impact

Join us live at the ceremony May 18th at 6:30 pm PDT at Google I/O or via the live stream to see who wins.

How useful did you find this blogpost?

20 April 2017

App onboarding for kids: how Budge Studios creates a more engaging experience for families

Posted by Josh Solt (Partner Developer Manager, Kids Apps at Google Play) and Noemie Dupuy (Founder & Co-CEO at Budge Studios)

Developers spend a considerable amount of resources driving users to download their apps, but what happens next is often the most critical part of the user journey. User onboarding is especially nuanced in the kids space since developers must consider two audiences: parents and children. When done correctly, a compelling onboarding experience will meet the needs of both parents and kids while also accounting for unique considerations, such as a child's attention span.

Budge Studios has successfully grown their catalog of children's titles by making onboarding a focal point of their business. Their target demographic is three to eight-year olds, and their portfolio of games include top titles featuring Strawberry Shortcake, Hello Kitty, Crayola, Caillou and The Smurfs.

"First impressions matter, as do users' first experience with your app. In fact, 70%1 of users who delete an app will do so within a day of having downloaded it, leaving little time for second chances. As an expert in kids' content, Budge tapped into our knowledge of kids to improve and optimize the onboarding experience, leading to increased initial game-loop completion and retention." - Noemie, Founder & Co-CEO at Budge Studios

Three key ways Budge Studios designs better onboarding experiences:

1. Make sure your game is tailor-made for kids

When Budge released their app Crayola Colorful Creatures, they looked at data to identify opportunities to create a smoother onboarding flow for kids. At launch, only 25% of first-time users were completing the initial game loop. Budge analyzed data against gameplay and realized the last activity was causing a drastic drop-off. It required kids to use the device's microphone, and that proved too challenging for very young kids. Budge was able to adjust the initial game loop so that all the activities were accessible to the youngest players. These adjustments almost tripled the initial loop completion, resulting in 74% of first-time users progressing to see additional activities.

2. Earn parents trust by providing real value upfront

Budge has a large of portfolio of apps. Earning parents' trust by providing valuable and engaging experiences for kids is important for retaining users in their ecosystem and achieving long term success.

With every new app, Budge identifies what content is playable for free, and what content must be purchased. Early on, Budge greatly limited the amount of free content they offered, but over time has realized providing high quality free content enhances the first-time user experience. Parents are more willing to spend on an app if their child has shown a real interest in a title.

Working with top kids' brands means that Budge can tap into brand loyalty of popular kids characters to provide value. To launch Strawberry Shortcake Dreams, Budge decided to offer Strawberry Shortcake, the most popular character in the series, as a free character. Dress Up Dreams is among the highest converting apps in the Budge portfolio, indicating that giving away the most popular character for free helped conversions rather than hurting it.

3. Test with real users

Budge knows there is no substitute for direct feedback from its end-users, so Budge involves kids every step of the way. Budge Playgroup is a playtesting program that invites families to try out apps at the alpha, beta and first-playable development stages.

The benefits from early testing can be as basic as understanding how the size and coordination of kids' hands affect their ability to complete certain actions or even hold the device, and as specific as pinpointing a less-than-effective button.

In the testing stages of Strawberry Shortcake Holiday Hair, Budge caught an issue with the main menu of the app, which would not have been evident without observing kids using the app.

Prior to Playtesting:

After Playtesting:

In the original design, users were prompted to start gameplay by audio cues. During testing, it was clear that the voiceover was not sufficient in guiding kids to initiate play, and that additional visual clues would significantly improve the experience. A simple design change resulted in a greatly enhanced user experience.

The onboarding experience is just one component of an app, but just like first impressions, it has a disproportionate impact on your users' perception of your app. As Budge has experienced, involving users in testing your app, using data to flag issues and providing real value to your users upfront, creates a smoother, more accessible onboarding experience and leads to better results.

For more best practices on developing family apps and games, please check out The Family Playbook for developers. And visit the Android Developers website to stay up-to-date with features and best practices that will help you grow a successful business on Google Play.


How useful did you find this blogpost?

14 April 2017

Java 8 Language Features Support Update

Posted by James Lau, Product Manager

Yesterday, we released Android Studio 2.4 Preview 6. Java 8 language features are now supported by the Android build system in the javac/dx compilation path. Android Studio's Gradle plugin now desugars Java 8 class files to Java 7-compatible class files, so you can use lambdas, method references and other features of Java 8.

For those of you who tried the Jack compiler, we now support the same set of Java 8 language features but with faster build speed. You can use Java 8 language features together with tools that rely on bytecode, including Instant Run. Using libraries written with Java 8 is also supported.

We first added Java 8 desugaring in Android Studio 2.4 Preview 4. Preview 6 includes important bug fixes related to Java 8 language features support. Many of these fixes were made in response to bug reports you filed. We really appreciate your help in improving Android development tools for the community!

It's easy to try using Java 8 language features in your Android project. Just download Android Studio 2.4 Preview 6, and update your project's target and source compatibility to Java version 1.8. You can find more information in our preview documentation.

Happy lambda'ing!

A New Issue Tracker for our AOSP Developers

Posted by Sandie Gong, Developer Relations Program Manager & Chris Iremonger, Android Technical Program Manager

Like many other issue trackers at Google, we're upgrading our Android Open Source Project (AOSP) issue tracking system to Issue Tracker. We are hoping to facilitate a better collaboration between our developers and our Android product teams by using a tool we use internally at Google to track bugs and feature requests during product development.

Starting today, all issues formerly at code.google.com/p/android/issues will migrate to Issue Tracker under the Android Public Tracker component. You may have noticed that we are already using the new tool to collect feedback on the O Developer Preview!

What has been migrated

Getting started with Issue Tracker

You can learn more about navigating our Issue Tracker from our developer documentation. By default, Issue Tracker displays only the issues assigned to you. You can easily change that to show a hotlist of your choice, a bookmark group, or a saved search. You can also adjust notification settings by clicking the gear icon in the top right corner and selecting Settings.

The mappings in Issue Tracker are also slightly different than code.google.com so make sure to check out Life of a Bug to learn more about what the various statuses mean.

Searching for component specific issues

Opening a code.google.com issue link will automatically redirect you to the new system. We've cleaned up some of the spam, but you'll be able to find all of the other issues from code.google.com in Issue Tracker, including any issue you've reported, commented on, or starred.

You can view all reported Android issues in the Android Public Tracker component and drill down to see reported issues for specific categories of issues, such as Tools and Support Libraries, by searching for specific components.

Filing a bug or feature request

Before filing a new issue, please check if it is already reported in the issues list. Let us know what issues are important to you by starring an existing issue.

Submitting a new issue is easy. Once you click "Create Issue", search for the appropriate component for your issue. Alternatively, you can just follow the correct issue creation link for each component listed in Report Bugs.

Here's some helpful links to get you started!

Relevant Links
Navigating and creating issues in the Android component
Navigating Google Issue Tracker
Google Issue Tracker announcements for other products

13 April 2017

FORTIFY in Android

Posted by George Burgess, Software Engineer

FORTIFY is an important security feature that's been available in Android since mid-2012. After migrating from GCC to clang as the default C/C++ compiler early last year, we invested a lot of time and effort to ensure that FORTIFY on clang is of comparable quality. To accomplish this, we redesigned how some key FORTIFY features worked, which we'll discuss below.

Before we get into some of the details of our new FORTIFY, let's go through a brief overview of what FORTIFY does, and how it's used.

What is FORTIFY?

FORTIFY is a set of extensions to the C standard library that tries to catch the incorrect use of standard functions, such as memset, sprintf, open, and others. It has three primary features:

  • If FORTIFY detects a bad call to a standard library function at compile-time, it won't allow your code to compile until the bug is fixed.
  • If FORTIFY doesn't have enough information, or if the code is definitely safe, FORTIFY compiles away into nothing. This means that FORTIFY has 0 runtime overhead when used in a context where it can't find a bug.
  • Otherwise, FORTIFY adds checks to dynamically determine if the questionable code is buggy. If it detects bugs, FORTIFY will print out some debugging information and abort the program.

Consider the following example, which is a bug that FORTIFY caught in real-world code:

struct Foo {
    int val;
    struct Foo *next;
void initFoo(struct Foo *f) {
    memset(&f, 0, sizeof(struct Foo));
FORTIFY caught that we erroneously passed &f as the first argument to memset, instead of f. Ordinarily, this kind of bug can be difficult to track down: it manifests as potentially writing 8 bytes extra of 0s into a random part of your stack, and not actually doing anything to *f. So, depending on your compiler optimization settings, how initFoo is used, and your project's testing standards, this could slip by unnoticed for quite a while. With FORTIFY, you get a compile-time error that looks like:

/path/to/file.c: call to unavailable function 'memset': memset called with size bigger than buffer
    memset(&f, 0, sizeof(struct Foo));
For an example of how run-time checks work, consider the following function:

// 2147483648 == pow(2, 31). Use sizeof so we get the nul terminator,
// as well.
#define MAX_INT_STR_SIZE sizeof("2147483648")
struct IntAsStr {
    char asStr[MAX_INT_STR_SIZE];
    int num;
void initAsStr(struct IntAsStr *ias) {
    sprintf(ias->asStr, "%d", ias->num);
This code works fine for all positive numbers. However, when you pass in an IntAsStr with num <= -1000000, the sprintf will write MAX_INT_STR_SIZE+1 bytes to ias->asStr. Without FORTIFY, this off-by-one error (that ends up clearing one of the bytes in num) may go silently unnoticed. With it, the program prints out a stack trace, a memory map, and will abort with a core dump.

FORTIFY also performs a handful of other checks, such as ensuring calls to open have the proper arguments, but it's primarily used for catching memory-related errors like the ones mentioned above.
However, FORTIFY can't catch every memory-related bug that exists. For example, consider the following code:

__attribute__((noinline)) // Tell the compiler to never inline this function.
inline void intToStr(int i, char *asStr) { sprintf(asStr, “%d”, num); }

char *intToDupedStr(int i) {
    const int MAX_INT_STR_SIZE = sizeof(“2147483648”);
    char buf[MAX_INT_STR_SIZE];
    intToStr(i, buf);
    return strdup(buf);
Because FORTIFY determines the size of a buffer based on the buffer's type and—if visible—its allocation site, it can't catch this bug. In this case, FORTIFY gives up because:

  • the pointer is not a type with a pointee size we can determine with confidence because char * can point to a variable amount of bytes
  • FORTIFY can't see where the pointer was allocated, because asStr could point to anything.

If you're wondering why we have a noinline attribute there, it's because FORTIFY may be able to catch this bug if intToStr gets inlined into intToDupedStr. This is because it would let the compiler see that asStr points to the same memory as buf, which is a region of sizeof(buf) bytes of memory.

How FORTIFY works

FORTIFY works by intercepting all direct calls to standard library functions at compile-time, and redirecting those calls to special FORTIFY'ed versions of said library functions. Each library function is composed of parts that emit run-time diagnostics, and—if applicable—parts that emit compile-time diagnostics. Here is a simplified example of the run-time parts of a FORTIFY'ed memset (taken from string.h). An actual FORTIFY implementation may include a few extra optimizations or checks.

inline void *memset(void *dest, int ch, size_t count) {
    size_t dest_size = __builtin_object_size(dest);
    if (dest_size == (size_t)-1)
        return __memset_real(dest, ch, count);
    return __memset_chk(dest, ch, count, dest_size);
In this example:

  • _FORTIFY_FUNCTION expands to a handful of compiler-specific attributes to make all direct calls to memset call this special wrapper.
  • __memset_real is used to bypass FORTIFY to call the "regular" memset function.
  • __memset_chk is the special FORTIFY'ed memset. If count > dest_size, __memset_chk aborts the program. Otherwise, it simply calls through to __memset_real.
  • __builtin_object_size is where the magic happens: it's a lot like size sizeof, but instead of telling you the size of a type, it tries to figure out how many bytes exist at the given pointer during compilation. If it fails, it hands back (size_t)-1.

The __builtin_object_size might seem sketchy. After all, how can the compiler figure out how many bytes exist at an unknown pointer? Well... It can't. :) This is why _FORTIFY_FUNCTION requires inlining for all of these functions: inlining the memset call might make an allocation that the pointer points to (e.g. a local variable, result of calling malloc, …) visible. If it does, we can often determine an accurate result for __builtin_object_size.

The compile-time diagnostic bits are heavily centered around __builtin_object_size, as well. Essentially, if your compiler has a way to emit diagnostics if an expression can be proven to be true, then you can add that to the wrapper. This is possible on both GCC and clang with compiler-specific attributes, so adding diagnostics is as simple as tacking on the correct attributes.

Why not Sanitize?

If you're familiar with C/C++ memory checking tools, you may be wondering why FORTIFY is useful when things like clang's AddressSanitizer exist. The sanitizers are excellent for catching and tracking down memory-related errors, and can catch many issues that FORTIFY can't, but we recommend FORTIFY for two reasons:

  • In addition to checking your code for bugs while it's running, FORTIFY can emit compile-time errors for code that's obviously incorrect, whereas the sanitizers only abort your program when a problem occurs. Since it's generally accepted that catching issues as early as possible is good, we'd like to give compile-time errors when we can.
  • FORTIFY is lightweight enough to enable in production. Enabling it on parts of our own code showed a maximum CPU performance degradation of ~1.5% (average 0.1%), virtually no memory overhead, and a very small increase in binary size. On the other hand, sanitizers can slow code down by well over 2x, and often eat up a lot of memory and storage space.

Because of this, we enable FORTIFY in production builds of Android to mitigate the amount of damage that some bugs can cause. In particular, FORTIFY can turn potential remote code execution bugs into bugs that simply abort the broken application. Again, sanitizers are capable of detecting more bugs than FORTIFY, so we absolutely encourage their use in development/debugging builds. But the cost of running them for binaries shipped to users is simply way too high to leave them enabled for production builds.

FORTIFY redesign

FORTIFY's initial implementation used a handful of tricks from the world of C89, with a few GCC-specific attributes and language extensions sprinkled in. Because Clang cannot emulate how GCC works to fully support the original FORTIFY implementation, we redesigned large parts of it to make it as effective as possible on clang. In particular, our clang-style FORTIFY implementation makes use of clang-specific attributes and language extensions, as well as some function overloading (clang will happily apply C++ overloading rules to your C functions if you use its overloadable attribute).

We tested hundreds of millions of lines of code with this new FORTIFY, including all of Android, all of Chrome OS (which needed its own reimplementation of FORTIFY), our internal codebase, and many popular open source projects.

This testing revealed that our approach broke existing code in a variety of exciting ways, like:
template <typename OpenFunc>
bool writeOutputFile(OpenFunc &&openFile, const char *data, size_t len) {}

bool writeOutputFile(const char *data, int len) {
    // Error: Can’t deduce type for the newly-overloaded `open` function.
    return writeOutputFile(&::open, data, len);
struct Foo { void *(*fn)(void *, const void *, size_t); }
void runFoo(struct Foo f) {
    // Error: Which overload of memcpy do we want to take the address of?
    if (f.fn == memcpy) {
    // [snip]

There was also an open-source project that tried to parse system headers like stdio.h in order to determine what functions it has. Adding the clang FORTIFY bits greatly confused the parser, which caused its build to fail.

Despite these large changes, we saw a fairly low amount of breakage. For example, when compiling Chrome OS, fewer than 2% of our packages saw compile-time errors, all of which were trivial fixes in a couple of files. And while that may be "good enough," it is not ideal, so we refined our approach to further reduce incompatibilities. Some of these iterations even required changing how clang worked, but the clang+LLVM community was very helpful and receptive to our proposed adjustments and additions, such as:

We recently pushed it to AOSP, and starting in Android O, the Android platform will be protected by clang FORTIFY. We're still putting some finishing touches on the NDK, so developers should expect to see our upgraded FORTIFY implementation there in the near future. In addition, as we alluded to above, Chrome OS also has a similar FORTIFY implementation now, and we hope to work with the open-source community in the coming months to get a similar implementation* into glibc, the GNU C library.

* For those who are interested, this will look very different than the Chrome OS patch. Clang recently gained an attribute called diagnose_if, which ends up allowing for a much cleaner FORTIFY implementation than our original approach for glibc, and produces far prettier errors/warnings than we currently can. We expect to have a similar diagnose_if-powered implementation in a later version of Android.

11 April 2017

Android O to drop insecure TLS version fallback in HttpsURLConnection

Posted by Tobias Thierer, Software Engineer

To improve security, insecure TLS version fallback has been removed from HttpsURLConnection in Android O.

What is changing and why?

TLS version fallback is a compatibility workaround in the HTTPS stack to connect to servers that do not implement TLS protocol version negotiation correctly. In previous versions of Android, if the initial TLS handshake fails in a particular way, HttpsURLConnection retries the handshake with newer TLS protocol versions disabled. In Android O, it will no longer attempt those retries. Connections to servers that correctly implement TLS protocol version negotiation are not affected.

We are removing this workaround because it weakens TLS by disabling TLS protocol version downgrade protections. The workaround is no longer needed, because fewer than 0.01% of web servers relied on it as of late 2015.

Will my app be affected?

Most apps will not be affected by this change. The easiest way to be sure is to build and test your app with the Android O Developer Preview. Your app's HTTPS connections in Android O will not be affected if they:

  • Target web servers that work with recent versions of Chrome or Firefox, because those servers have correctly implemented TLS protocol version negotiation. Support for TLS version fallback was removed in Firefox 37 (Mar 2015) and Chrome 50 (Apr 2016).
  • Use a third-party HTTP library not built on top of HttpsURLConnection. We suggest you disable protocol fallback if you're using a third-party library. For example, in OkHttp versions up to 3.6, you may want to configure your OkHttpClient to only use ConnectionSpec.MODERN_TLS.

My app is affected. What now?

If your app relies on TLS version fallback, its HTTPS connections are vulnerable to downgrade attacks. To fix this, you should contact whoever operates the server. If this is not possible right away, then as a workaround you could use a third-party HTTP library that offers TLS version fallback. Be aware that using this method weakens your app's TLS security. To discover any compatibility issues, please test your app against the Android O Developer Preview.