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.

10 April 2017

Changes to Device Identifiers in Android O

Posted by Giles Hogben, Privacy Engineer

Android O introduces some improvements to help provide user control over the use of identifiers. These improvements include:

  • limiting the use of device-scoped identifiers that are not resettable
  • updating the Android O Wi-Fi stack in conjunction with changes to the Wi-Fi chipset firmware used by Pixel, Pixel XL and Nexus 5x phones to randomize MAC addresses in probe requests
  • updating the way that applications request account information and providing more user-facing control

Device identifier changes

Here are some of the device identifier changes for Android O:

Android ID

In O, Android ID (Settings.Secure.ANDROID_ID or SSAID) has a different value for each app and each user on the device. Developers requiring a device-scoped identifier, should instead use a resettable identifier, such as Advertising ID, giving users more control. Advertising ID also provides a user-facing setting to limit ad tracking.

Additionally in Android O:

  • The ANDROID_ID value won't change on package uninstall/reinstall, as long as the package name and signing key are the same. Apps can rely on this value to maintain state across reinstalls.
  • If an app was installed on a device running an earlier version of Android, the Android ID remains the same when the device is updated to Android O, unless the app is uninstalled and reinstalled.
  • The Android ID value only changes if the device is factory reset or if the signing key rotates between uninstall and reinstall events.
  • This change is only required for device manufacturers shipping with Google Play services and Advertising ID. Other device manufacturers may provide an alternative resettable ID or continue to provide ANDROID ID.


To be consistent with runtime permissions required for access to IMEI, use of android.os.Build.SERIAL is deprecated for apps that target Android O or newer. Instead, they can use a new Android O API, Build.getSerial(), which returns the actual serial number, as long as the caller holds the PHONE permission. In a future version of Android, apps targeting Android O will see Build.SERIAL as "UNKNOWN". To avoid breaking legacy app functionality, apps targeting prior versions of Android will continue see the device's serial number, as before.


Net.Hostname provides the network hostname of the device. In previous versions of Android, the default value of the network hostname and the value of the DHCP hostname option contained Settings.Secure.ANDROID_ID. In Android O, net.hostname is empty and the DHCP client no longer sends a hostname, following IETF RFC 7844 (anonymity profile).

Widevine ID

For new devices shipping with O, the Widevine Client ID returns a different value for each app package name and web origin (for web browser apps).

Unique system and settings properties

In addition to Build.SERIAL, there are other settings and system properties that aren't available in Android O. These include:

  • ro.runtime.firstboot: Millisecond-precise timestamp of first boot after last wipe or most recent boot
  • htc.camera.sensor.front_SN: Camera serial number (available on some HTC devices)
  • persist.service.bdroid.bdaddr: Bluetooth MAC address property
  • Settings.Secure.bluetooth_address: Device Bluetooth MAC address. In O, this is only available to apps holding the LOCAL_MAC_ADDRESS permission.

MAC address randomization in Wi-Fi probe requests

We collaborated with security researchers1 to design robust MAC address randomization for Wi-Fi scan traffic produced by the chipset firmware in Google Pixel and Nexus 5X devices. The Android Connectivity team then worked with manufacturers to update the Wi-Fi chipset firmware used by these devices.

Android O integrates these firmware changes into the Android Wi-Fi stack, so that devices using these chipsets with updated firmware and running Android O or above can take advantage of them.

Here are some of the changes that we've made to Pixel, Pixel XL and Nexus 5x firmware when running O+:

  • For each Wi-Fi scan while it is disconnected from an access point, the phone uses a new random MAC address (whether or not the device is in standby).
  • The initial packet sequence number for each scan is also randomized.
  • Unnecessary Probe Request Information Elements have been removed: Information Elements are limited to the SSID and DS parameter sets.

Changes in the getAccounts API

In Android O and above, the GET_ACCOUNTS permission is no longer sufficient to gain access to the list of accounts registered on the device. Applications must use an API provided by the app managing the specific account type or the user must grant permission to access the account via an account chooser activity. For example, Gmail can access Google accounts registered on the device because Google owns the Gmail application, but the user would need to grant Gmail access to information about other accounts registered on the device.

Apps targeting Android O or later should either use AccountManager#newChooseAccountIntent() or an authenticator-specific method to gain access to an account. Applications with a lower target SDK can still use the current flow.

In Android O, apps can also use the AccountManager.setAccountVisibility()/ getVisibility() methods to manage visibility policies of accounts owned by those apps.

In addition, the LOGIN_ACCOUNTS_CHANGED_ACTION broadcast is deprecated, but still works in Android O. Applications should use addOnAccountsUpdatedListener() to get updates about accounts at runtime for a list of account types that they specify.

Check out Best Practices for Unique Identifiers for more information.


  1. Glenn Wilkinson and team at Sensepost, UK, Célestin Matte, Mathieu Cunche: University of Lyon, INSA-Lyon, CITI Lab, Inria Privatics, Mathy Vanhoef, KU Leuven 

06 April 2017

Android Things Developer Preview 3

Posted by Wayne Piekarski, Developer Advocate for IoT

Today, we are releasing the Developer Preview 3 (DP3) of Android Things, bringing new features and bug fixes to the platform. This preview is part of our commitment to provide regular updates to developers who are building Internet of Things (IoT) products with our platform. Android developers can quickly build smart devices using Android APIs and Google services, while staying secure with updates directly from Google. The System-on-Module (SoM) architecture supports prototyping with development boards, and then scaling them to large production runs while using the same Board Support Package (BSP) from Google.

Android Bluetooth APIs

DP3 now includes support for all Android Bluetooth APIs in android.bluetooth and android.bluetooth.le, across all Android Things supported hardware. You can now write code that interacts with both Bluetooth classic and low energy (LE) devices just like a regular Android phone. Existing samples such as Bluetooth LE advertisements and scanning and Bluetooth LE GATT can be used unmodified on Android Things. We have also provided two new samples, Bluetooth LE GATT server and Bluetooth audio sink.

USB Host support

Android version 3.1 and later supports USB Host, which allows a regular user space application to communicate with USB devices without root privileges or support needed from the Linux kernel. This functionality is now supported in Android Things, to enable interfacing with custom USB devices. Any existing code supporting USB Host will work on Android Things, and an extra sample USB Enumerator is available that demonstrates how to iterate over and print the interfaces and endpoints for each USB device.


Once again, thank you to all the developers who submitted feedback for the previous developer previews. Please continue to send us your feedback by filing bug reports and feature requests, and ask any questions on stackoverflow. To download images for Developer Preview 3, visit the Android Things download page, and find the changes in the release notes. You can also join Google's IoT Developers Community on Google+, a great resource to keep up to date and discuss ideas, with over 4100 new members.