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…… 


Standout Startup


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


Best Android Wear Experience


New wear 2.0 apps offering great design, user delight and functionality. And the nominees are…


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…


Best VR Experience


Highly engaging and immersive experience with optimal use of Daydream UI. And the nominees are…


Best AR Experience


Apps or games harnessing the creative and imaginative technology of AR. And the nominees are…


Best App for Kids


Apps or games with family friendly design that encourage creativity, exploration and education. And the nominees are…


Best Multiplayer Game


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



Best App


A true representation of beautiful design, intuitive UX and high user appeal. And the nominees are…


Best Game


Games with strong mechanics, stellar graphics and strong engagement and retention tactics. And the nominees are...


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…


Best Social Impact


Apps that creates meaningful social impact for a broad spectrum of people around the world. And the nominees are…


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.

1.http://www.cmswire.com/customer-experience/mobile-app-retention-5-key-strategies-to-keep-your-customers/

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!


Topic
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.

_FORTIFY_FUNCTION
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);
}
and
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) {
        return;
    }
    // [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.

Build.SERIAL


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


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.


Notes


  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.

Feedback


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.

05 April 2017

Android Developer Story: Robinhood uses Android Studio to quickly build and test new features

Posted by Christopher Katsaros, Developer Marketing, Android

Robinhood allows users to buy and sell stocks commission-free* in the US. It is designed to make financial investment easy for all users, even if you’ve never traded before.

With a team of two Android developers, the company has relied on fast tools like Android Studio to build rich new features, which have helped make Robinhood the highest-rated stock brokerage app on Google Play.

Watch Robinhood's Joe Binney, VP of Product Engineering, and Dan Hill, Android Developer, talk about how Android Studio is helping them achieve strong growth on Android.


The top Android developers use Android Studio to build powerful and successful apps on Google Play; learn more about the official IDE for Android app development and get started for yourself.

Get more tips and watch other success stories in the Playbook for Developers app.

*Free trading refers to $0 commissions for Robinhood Financial self-directed individual cash or margin brokerage accounts that trade U.S. listed securities via mobile devices. SEC & FINRA regulatory fees may apply.

 How useful did you find this blogpost?

Focusing our Google Play games services efforts

Posted By James Smith, Product Manager, Google Play

In order to help developers make great games and build their businesses, we offer Google Play Games Services (GPGS). GPGS provides powerful tools to build, analyze and retain your audience and optimize your game. After listening to developer feedback and examining usage, we have decided to remove some of the features so we can focus on making our offering more useful.

In December, we announced the end of support for the creation of new iOS accounts given the low usage of GPGS on iOS. Additionally, our latest Native SDK release (2.3) will no longer support integration with iOS and going forward we will not be supporting or updating the iOS SDK.

We've also examined the features that GPGS offers. While developers use engagement and reporting tools extensively, there is lower usage for Gifts, Requests, and Quests. We therefore plan to stop supporting Gifts, Requests, and Quests. In order to help developers that do use these features plan for their removal, we will leave them open for 12 months, deactivating them by 31st March 2018. We'll be continuing support for other features such as Sign-in, Achievements, Leaderboards and Multiplayer.

Play games services remains an important part of the tools we provide developers, and we're working hard on future GPGS updates. We continue to be strongly committed to providing high quality services for Games, including new tools such as official Firebase support for Unity and C++ developers, and integration with Firebase Analytics. These changes allow us to focus our efforts on the services developers value most to build high quality, engaging games.

How useful did you find this blogpost? 


03 April 2017

An investigation of Chrysaor Malware on Android

Posted by Rich Cannings, Jason Woloz, Neel Mehta, Ken Bodzak, Wentao Chang, Megan Ruthven

Google is constantly working to improve our systems that protect users from Potentially Harmful Applications (PHAs). Usually, PHA authors attempt to install their harmful apps on as many devices as possible. However, a few PHA authors spend substantial effort, time, and money to create and install their harmful app on one or a very small number of devices. This is known as a targeted attack.

In this blog post, we describe Chrysaor, a newly discovered family of spyware that was used in a targeted attack on a small number of Android devices, and how investigations like this help Google protect Android users from a variety of threats.

What is Chrysaor?


Chrysaor is spyware believed to be created by NSO Group Technologies, specializing in the creation and sale of software and infrastructure for targeted attacks. Chrysaor is believed to be related to the Pegasus spyware that was first identified on iOS and analyzed by Citizen Lab and Lookout.

Late last year, after receiving a list of suspicious package names from Lookout, we discovered that a few dozen Android devices may have installed an application related to Pegasus, which we named Chrysaor. Although the applications were never available in Google Play, we immediately identified the scope of the problem by using Verify Apps. We gathered information from affected devices, and concurrently, attempted to acquire Chrysaor apps to better understand its impact on users. We've contacted the potentially affected users, disabled the applications on affected devices, and implemented changes in Verify Apps to protect all users.

What is the scope of Chrysaor?


Chrysaor was never available in Google Play and had a very low volume of installs outside of Google Play. Among the over 1.4 billion devices protected by Verify Apps, we observed fewer than 3 dozen installs of Chrysaor on victim devices. These devices were located in the following countries:




How we protect you


To protect Android devices and users, Google Play provides a complete set of security services that update outside of platform releases. Users don't have to install any additional security services to keep their devices safe. In 2016, these services protected over 1.4 billion devices, making Google one of the largest providers of on-device security services in the world:
Additionally, we are providing detailed technical information to help the security industry in our collective work against PHAs.

What do I need to do?


It is extremely unlikely you or someone you know was affected by Chrysaor malware. Through our investigation, we identified less than 3 dozen devices affected by Chrysaor, we have disabled Chrysaor on those devices, and we have notified users of all known affected devices. Additionally, the improvements we made to our protections have been enabled for all users of our security services.
To ensure you are fully protected against PHAs and other threats, we recommend these 5 basic steps:
  • Install apps only from reputable sources: Install apps from a reputable source, such as Google Play. No Chrysaor apps were on Google Play.
  • Enable a secure lock screen: Pick a PIN, pattern, or password that is easy for you to remember and hard for others to guess.
  • Update your device: Keep your device up-to-date with the latest security patches.
  • Verify Apps: Ensure Verify Apps is enabled.
  • Locate your device: Practice finding your device with Android Device Manager because you are far more likely to lose your device than install a PHA.

How does Chrysaor work?


To install Chrysaor, we believe an attacker coaxed specifically targeted individuals to download the malicious software onto their device. Once Chrysaor is installed, a remote operator is able to surveil the victim's activities on the device and within the vicinity, leveraging microphone, camera, data collection, and logging and tracking application activities on communication apps such as phone and SMS.

One representative sample Chrysaor app that we analyzed was tailored to devices running Jellybean (4.3) or earlier. The following is a review of scope and impact of the Chrysaor app named com.network.android tailored for a Samsung device target, with SHA256 digest:

ade8bef0ac29fa363fc9afd958af0074478aef650adeb0318517b48bd996d5d5
Upon installation, the app uses known framaroot exploits to escalate privileges and break Android's application sandbox. If the targeted device is not vulnerable to these exploits, then the app attempts to use a superuser binary pre-positioned at /system/csk to elevate privileges.

After escalating privileges, the app immediately protects itself and starts to collect data, by:
  • Installing itself on the /system partition to persist across factory resets
  • Removing Samsung's system update app (com.sec.android.fotaclient) and disabling auto-updates to maintain persistence (sets Settings.System.SOFTWARE_UPDATE_AUTO_UPDATE to 0)
  • Deleting WAP push messages and changing WAP message settings, possibly for anti-forensic purpose.
  • Starting content observers and the main task loop to receive remote commands and exfiltrate data

The app uses six techniques to collect user data:

  • Repeated commands: use alarms to periodically repeat actions on the device to expose data, including gathering location data.
  • Data collectors: dump all existing content on the device into a queue. Data collectors are used in conjunction with repeated commands to collect user data including, SMS settings, SMS messages, Call logs, Browser History, Calendar, Contacts, Emails, and messages from selected messaging apps, including WhatsApp, Twitter, Facebook, Kakoa, Viber, and Skype by making /data/data directories of the apps world readable.
  • Content observers: use Android's ContentObserver framework to gather changes in SMS, Calendar, Contacts, Cell info, Email, WhatsApp, Facebook, Twitter, Kakao, Viber, and Skype.
  • Screenshots: captures an image of the current screen via the raw frame buffer.
  • Keylogging: record input events by hooking IPCThreadState::Transact from /system/lib/libbinder.so, and intercepting android::parcel with the interface com.android.internal.view.IInputContext.
  • RoomTap: silently answers a telephone call and stays connected in the background, allowing the caller to hear conversations within the range of the phone's microphone. If the user unlocks their device, they will see a black screen while the app drops the call, resets call settings and prepares for the user to interact with the device normally.

Finally, the app can remove itself through three ways:

  • Via a command from the server
  • Autoremove if the device has not been able to check in to the server after 60 days
  • Via an antidote file. If /sdcard/MemosForNotes was present on the device, the Chrysaor app removes itself from the device.

Samples uploaded to VirusTotal


To encourage further research in the security community, we’ve uploaded these sample Chrysaor apps to Virus Total.

Package Name
SHA256 digest
SHA1 certificate
com.network.android
ade8bef0ac29fa363fc9afd958af0074478aef650adeb0318517b48bd996d5d5
44f6d1caa257799e57f0ecaf4e2e216178f4cb3d
com.network.android
3474625e63d0893fc8f83034e835472d95195254e1e4bdf99153b7c74eb44d86
516f8f516cc0fd8db53785a48c0a86554f75c3ba


Additional digests with links to Chrysaor


As a result of our investigation we have identified these additional Chrysaor-related apps.


Package Name
SHA256 digest
SHA1 certificate
com.network.android
98ca5f94638768e7b58889bb5df4584bf5b6af56b188da48c10a02648791b30c
516f8f516cc0fd8db53785a48c0a86554f75c3ba
com.network.android
5353212b70aa096d918e4eb6b49eb5ad8f59d9bec02d089e88802c01e707c3a1
44f6d1caa257799e57f0ecaf4e2e216178f4cb3d
com.binary.sms.receiver
9fae5d148b89001555132c896879652fe1ca633d35271db34622248e048c78ae
7771af1ad3a3d9c0b4d9b55260bb47c2692722cf
com.android.copy
e384694d3d17cd88ec3a66c740c6398e07b8ee401320ca61e26bdf96c20485b4
7771af1ad3a3d9c0b4d9b55260bb47c2692722cf
com.android.copy
12e085ab85db887438655feebd249127d813e31df766f8c7b009f9519916e389
7771af1ad3a3d9c0b4d9b55260bb47c2692722cf
com.android.copy
6348104f8ef22eba5ac8ee737b192887629de987badbb1642e347d0dd01420f8
31a8633c2cd67ae965524d0b2192e9f14d04d016

Lookout has completed their own independent analysis of the samples we acquired, their report can be viewed here.