Android Developers Blog

Seccomp filter in Android O

2017-07-20T14:10:00.000-07:00

Posted by Paul Lawrence, Android Security Engineer
In Android-powered devices, the kernel does the heavy lifting to enforce the Android security model. As the security team has worked to harden Android's userspace and isolate and deprivilege processes, the kernel has become the focus of more security attacks. System calls are a common way for attackers to target the kernel.
All Android software communicates with the Linux kernel using system calls, or syscalls for short. The kernel provides many device- and SOC-specific syscalls that allow userspace processes, including apps, to directly interact with the kernel. All apps rely on this mechanism to access collections of behavior indexed by unique system calls, such as opening a file or sending a Binder message. However, many of these syscalls are not used or officially supported by Android.
Android O takes advantage of a Linux feature called seccomp that makes unused system calls inaccessible to application software. Because these syscalls cannot be accessed by apps, they can't be exploited by potentially harmful apps.

seccomp filter

Android O includes a single seccomp filter installed into zygote, the process from which all the Android applications are derived. Because the filter is installed into zygote—and therefore all apps—the Android security team took extra caution to not break existing apps. The seccomp filter allows:

all the syscalls exposed via bionic (the C runtime for Android). These are defined in bionic/libc/SYSCALLS.TXT.
syscalls to allow Android to boot
syscalls used by popular Android applications, as determined by running Google's full app compatibility suite

Android O's seccomp filter blocks certain syscalls, such as swapon/swapoff, which have been implicated in some security attacks, and the key control syscalls, which are not useful to apps. In total, the filter blocks 17 of 271 syscalls in arm64 and 70 of 364 in arm.

Developers

Test your app for illegal syscalls on a device running Android O.

Detecting an illegal syscall

In Android O, the system crashes an app that uses an illegal syscall. The log printout shows the illegal syscall, for example:

03-09 16:39:32.122 15107 15107 I crash_dump32: performing dump of process 14942 (target tid = 14971)
03-09 16:39:32.127 15107 15107 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-09 16:39:32.127 15107 15107 F DEBUG   : Build fingerprint: 'google/sailfish/sailfish:O/OPP1.170223.013/3795621:userdebug/dev-keys'
03-09 16:39:32.127 15107 15107 F DEBUG   : Revision: '0'
03-09 16:39:32.127 15107 15107 F DEBUG   : ABI: 'arm'
03-09 16:39:32.127 15107 15107 F DEBUG   : pid: 14942, tid: 14971, name: WorkHandler  >>> com.redacted <<<
03-09 16:39:32.127 15107 15107 F DEBUG   : signal 31 (SIGSYS), code 1 (SYS_SECCOMP), fault addr --------
03-09 16:39:32.127 15107 15107 F DEBUG   : Cause: seccomp prevented call to disallowed system call 55
03-09 16:39:32.127 15107 15107 F DEBUG   :     r0 00000091  r1 00000007  r2 ccd8c008  r3 00000001
03-09 16:39:32.127 15107 15107 F DEBUG   :     r4 00000000  r5 00000000  r6 00000000  r7 00000037

Affected developers should rework their apps to not call the illegal syscall.

Toggling seccomp filters during testing

In addition to logging errors, the seccomp installer respects setenforce on devices running userdebug and eng builds, which allows you to test whether seccomp is responsible for an issue. If you type:

adb shell setenforce 0 && adb stop && adb start

then no seccomp policy will be installed into zygote. Because you cannot remove a seccomp policy from a running process, you have to restart the shell for this option to take effect.

Device manufacturers

Because Android O includes the relevant seccomp filters at //bionic/libc/seccomp, device manufacturers don't need to do any additional implementation. However, there is a CTS test that checks for seccomp at //cts/tests/tests/security/jni/android_security_cts_SeccompTest.cpp. The test checks that add_key and keyctl syscalls are blocked and openat is allowed, along with some app-specific syscalls that must be present for compatibility.

Shut the HAL Up

2017-07-18T10:00:00.000-07:00

Posted by Jeff Vander Stoep, Senior Software Engineer, Android Security

Updates are essential for security, but they can be difficult and expensive for device manufacturers. Project Treble is making updates easier by separating the underlying vendor implementation from the core Android framework. This modularization allows platform and vendor-provided components to be updated independently of each other. While easier and faster updates are awesome, Treble's increased modularity is also designed to improve security.

Isolating HALs

A Hardware Abstraction Layer (HAL) provides an interface between device-agnostic code and device-specific hardware implementations. HALs are commonly packaged as shared libraries loaded directly into the process that requires hardware interaction. Security boundaries are enforced at the process level. Therefore, loading the HAL into a process means that the HAL is running in the same security context as the process it's loaded into.

The traditional method of running HALs in-process means that the process needs all the permissions required by each in-process HAL, including direct access to kernel drivers. Likewise, all HALs in a process have access to the same set of permissions as the rest of the process, including permissions required by other in-process HALs. This results in over-privileged processes and HALs that have access to permissions and hardware that they shouldn't.

Figure 1. Traditional method of multiple HALs in one process.

Moving HALs into their own processes better adheres to the principle of least privilege. This provides two distinct advantages:

Each HAL runs in its own sandbox and is permitted access to only the hardware driver it controls and the permissions granted to the process are limited to the permissions required to do its job.
Similarly, the process loses access to hardware drivers and other permissions and capabilities needed by the HALs.

Figure 2. Each HAL runs in its own process.

Moving HALs into their own processes is great for security, but it comes at the cost of increased IPC overhead between the client process and the HAL. Improvements to the binder driver made IPC between HALs and clients practical. Introducing scatter-gather into binder improves the performance of each transaction by removing the need for the serialization/deserialization steps and reducing the number of copy operations performed on data from three down to one. Android O also introduces binder domains to provide separate communication streams for vendor and platform components. Apps and the Android frameworks continue to use /dev/binder, but vendor-provided components now use /dev/vndbinder. Communication between the platform and vendor components must use /dev/hwbinder. Other means of IPC between platform and vendor are disallowed.

Case study: System Server

Many of the services offered to apps by the core Android OS are provided by the system server. As Android has grown, so has system server's responsibilities and permissions, making it an attractive target for an attacker. As part of project Treble, approximately 20 HALs were moved out of system server, including the HALs for sensors, GPS, fingerprint, Wi-Fi, and more. Previously, a compromise in any of those HALs would gain privileged system permissions, but in Android O, permissions are restricted to the subset needed by the specific HAL.

Case study: media frameworks

Efforts to harden the media stack in Android Nougat continued in Android O. In Nougat, mediaserver was split into multiple components to better adhere to the principle of least privilege, with audio hardware access restricted to audioserver, camera hardware access restricted to cameraserver, and so on. In Android O, most direct hardware access has been entirely removed from the media frameworks. For example HALs for audio, camera, and DRM have been moved out of audioserver, cameraserver, and drmserver respectively.

Reducing and isolating the attack surface of the kernel

The Linux kernel is the primary enforcer of the security model on Android. Attempts to escape sandboxing mechanisms often involve attacking the kernel. An analysis of kernel vulnerabilities on Android showed that they overwhelmingly occurred in and were reached through hardware drivers.

De-privileging system server and the media frameworks is important because they interact directly with installed apps. Removing direct access to hardware drivers makes bugs difficult to reach and adds another layer of defense to Android's security model.

Identifying Intrusive Mobile Apps using Peer Group Analysis

2017-07-12T10:02:00.001-07:00

Posted by Martin Pelikan, Giles Hogben, and Ulfar Erlingsson of Google's Security and Privacy team

Mobile apps entertain and assist us, make it easy to communicate with friends and family, and provide tools ranging from maps to electronic wallets. But these apps could also seek more device information than they need to do their job, such as personal data and sensor data from components, like cameras and GPS trackers.

To protect our users and help developers navigate this complex environment, Google analyzes privacy and security signals for each app in Google Play. We then compare that app to other apps with similar features, known as functional peers. Creating peer groups allows us to calibrate our estimates of users' expectations and set adequate boundaries of behaviors that may be considered unsafe or intrusive. This process helps detect apps that collect or send sensitive data without a clear need, and makes it easier for users to find apps that provide the right functionality and respect their privacy. For example, most coloring book apps don't need to know a user's precise location to function and this can be established by analyzing other coloring book apps. By contrast, mapping and navigation apps need to know a user's location, and often require GPS sensor access.

One way to create app peer groups is to create a fixed set of categories and then assign each app into one or more categories, such as tools, productivity, and games. However, fixed categories are too coarse and inflexible to capture and track the many distinctions in the rapidly changing set of mobile apps. Manual curation and maintenance of such categories is also a tedious and error-prone task.

To address this, Google developed a machine-learning algorithm for clustering mobile apps with similar capabilities. Our approach uses deep learning of vector embeddings to identify peer groups of apps with similar functionality, using app metadata, such as text descriptions, and user metrics, such as installs. Then peer groups are used to identify anomalous, potentially harmful signals related to privacy and security, from each app's requested permissions and its observed behaviors. The correlation between different peer groups and their security signals helps different teams at Google decide which apps to promote and determine which apps deserve a more careful look by our security and privacy experts. We also use the result to help app developers improve the privacy and security of their apps.

Apps are split into groups of similar functionality, and in each cluster of similar apps the established baseline is used to find anomalous privacy and security signals.

These techniques build upon earlier ideas, such as using peer groups to analyze privacy-related signals, deep learning for language models to make those peer groups better, and automated data analysis to draw conclusions.

Many teams across Google collaborated to create this algorithm and the surrounding process. Thanks to several, essential team members including Andrew Ahn, Vikas Arora, Hongji Bao, Jun Hong, Nwokedi Idika, Iulia Ion, Suman Jana, Daehwan Kim, Kenny Lim, Jiahui Liu, Sai Teja Peddinti, Sebastian Porst, Gowdy Rajappan, Aaron Rothman, Monir Sharif, Sooel Son, Michael Vrable, and Qiang Yan.

For more information on Google's efforts to detect and fight potentially harmful apps (PHAs) on Android, see Google Android Security Team's Classifications for Potentially Harmful Applications.

References

S. Jana, Ú. Erlingsson, I. Ion (2015). Apples and Oranges: Detecting Least-Privilege Violators with Peer Group Analysis. arXiv:1510.07308 [cs.CR].

T. Mikolov, I. Sutskever, K. Chen, G. S. Corrado, J. Dean (2013). Distributed Representations of Words and Phrases and their Compositionality. Advances in Neural Information Processing Systems 26 (NIPS 2013).

Ú. Erlingsson (2016). Data-driven software security: Models and methods. Proceedings of the 29th IEEE Computer Security Foundations Symposium (CSF'16), Lisboa, Portugal.

Calling all indie developers in the US & Canada: sign up for the Google Play Indie Games Festival in San Francisco

2017-07-11T09:17:00.003-07:00

Posted by Jamil Moledina, Games Strategic Lead, Google Play

Calling all indie developers with fun and creative mobile games: we want to see your latest work! We'll be back with the second Google Play Indie Games Festival taking place in San Francisco on September 23rd.

If you're an indie developer based in the US or Canada and want to submit your game, visit the submission form and enter now through August 6th at 11:59PM PST.

If chosen as one of the 20 Finalists, you could have a chance to demo your game at the event and compete for prizes and bragging rights, to go home as one of the three festival winners!

How useful did you find this blogpost? ★ ★ ★ ★ ★

Android vitals: Increase engagement and installs through improved app performance

2017-07-10T09:59:00.001-07:00

Posted by Fergus Hurley, Product Manager, Google Play

Poor app performance is something that many users have experienced. Think about that last time you experienced an app crashing, failing to respond, or rendering slowly. Consider your reaction when checking the battery usage on your own device, and seeing an app using excessive battery. When an app performs badly, users notice. In fact, in an internal analysis of app reviews on Google Play, we noticed that half of the 1-star reviews mentioned app stability.

Conversely, people consistently reward the best performing apps with better ratings and reviews. This leads to better rankings on Google Play, which helps increase installs. Not only that, but users stay more engaged, and are willing to spend more time and money.

At Google I/O 2017, we announced the new Android vitals dashboard in the Google Play Console. Android vitals is designed to help you understand and analyze bad app behaviors, so you can improve your app's performance and reap the benefits of better performance.

Android vitals in the Google Play Console

Android vitals helps identify opportunities to improve your app's performance. The dashboards are useful for engineers and business owners alike, offering quick reference performance metrics to monitor your app so you can analyze the data and dedicate the right resources to make improvements.

You'll see the following data collected from Android devices whose users have opted in to automatically share usage and diagnostics data:

Stability: ANR rate & crash rate
Render time: slow rendering (16ms) and frozen UI frames (700ms)
Battery usage: stuck wake locks and excessive wakeups

See how Busuu increased their rating from 4.1☆ to 4.5☆ by focusing on app performance

Busuu is one of the world's largest language learning apps. Hear from Antoine Sakho, Head of Product about how Busuu increased user ratings.

Learn more about engineering for high performance with tools from Android and Google Play

Read our best practice article on Android vitals to understand the data shown in the dashboards, and how you can improve your app's performance and stability. Watch the I/O session to learn about more tools from Android and Google Play that you can use to identify and fix bad behaviors:

Learn more about other Play Console features, and stay up to date with news and tips to succeed on Google Play, with the Playbook app. Join the beta and install it today.

How useful did you find this blogpost?

★ ★ ★ ★ ★

Android Things Hackster Community

2017-06-30T10:24:00.000-07:00

Posted by Dave Smith, Developer Advocate for IoT

Android Things makes building connected embedded devices easy by providing the same Android development tools, best-in-class Android framework, and Google APIs that make developers successful on mobile. Since the initial preview launch back in December, the community has turned some amazing ideas into exciting prototypes using the platform.

To empower these makers and developers using Android Things to share and learn from each other, we have partnered with Hackster.io to create a community where aspiring IoT developers can go to showcase their projects and get inspired by the work of others. Hackster.io is a community of 200,000 engineers and developers dedicated to building internet-connected hardware projects. They also seek to educate and challenge members through live workshops and design contests.

We are eager to see the projects that you come up with. More importantly, we're excited to see how your work can inspire other developers to create something great with Android Things. Visit our Hackster.io community to see the amazing projects others have already built and join the community today!

Android Things Webinar

We will be hosting a webinar in cooperation with Hackster.io on July 7th, 2017 at 10AM PST titled Bootstrapping IoT Products with Android Things. During this time, you will learn how we have designed Android Things to address many of the pain points experienced by developers attempting to build IoT products. You will also have the opportunity to send in questions you have regarding the platform and ecosystem. Register today to join us for this exciting event!

Android Things Console developer preview

2017-06-28T09:00:00.000-07:00

Posted by Wayne Piekarski, Developer Advocate for IoT

Today we are launching a preview of the Android Things Console. This console allows developers to manage the software running on their fleet of Android Things IoT devices, including creating factory images, as well as updating the operating system and developer-provided APKs. Devices need to run a system image downloaded via the Android Things Console in order to receive future updates, such as the upcoming Developer Preview 5. Google provides all of the infrastructure for over-the-air (OTA) updates, so developers can focus on their specific application and not have to build their own implementation – getting their IoT devices to enter the market faster and more securely than before.

Let's take a tour of the console, and see the features it offers.

Product Creation and Product Settings

The developer first defines a product, which includes selecting a name and the type of System-on-Module (SoM) that the device is based on. Many developers want to use Google Play Services when building IoT devices, and this is configured here as an optional feature. The size of the OEM partition is also configured, and must be large enough to include the size of any future APK growth.

Factory Images

A device needs an initial base firmware to receive future updates for the correct product from your console. For starters, you can simply use "Create Build Configuration" to build a default factory image with an empty bundle that is configured for your product. This factory image can then be downloaded and flashed to your device, and you can start developing on it by sideloading an APK.

Later on, once you have prepared an application that you would like to deploy to all the devices in your product, you can upload a bundle to the console. This bundle is a ZIP file that contains a main APK file, user space drivers as a service in an APK, and any additional APKs launched by the main APK. A bootanimation.zip file is also supported, which will be displayed during boot up. The uploaded bundle ZIP file is then used to produce a complete system image that can be deployed to devices. More information about the bundle ZIP file contents is available in the documentation.

OTA Updates

This tab allows the developer to select which system image should be pushed to the fleet of product devices. The developer selects one, and then "Push to Devices" starts the process. The update will then be securely pushed to all of the devices, installed to one of the A/B partitions, and made active when the device is rebooted. If any failures are detected, the device automatically rolls back to the previous known working version, so future updates are still possible. Developers will be able to test new releases of Android Things in advance and decide whether devices should be updated automatically.

Feedback

The Android Things Console is currently a preview, and we are working on many more features and customizations. We encourage all Android Things developers to check out the Android Things Console and provide feedback. You can do this by filing bug reports and feature requests, and asking any questions on Stack Overflow. To learn more about the Android Things Console, read the detailed documentation. We also encourage everyone to join Google's IoT Developers Community on Google+, a great resource to get updates and discuss ideas.

What’s new in WebView security

2017-06-22T14:29:00.000-07:00

Posted by Xiaowen Xin and Renu Chaudhary, Android Security Team

The processing of external and untrusted content is often one of the most important functions of an app. A newsreader shows the top news articles and a shopping app displays the catalog of items for sale. This comes with associated risks as the processing of untrusted content is also one of the main ways that an attacker can compromise your app, i.e. by passing you malformed content.

Many apps handle untrusted content using WebView, and we've made many improvements in Android over the years to protect it and your app against compromise. With Android Lollipop, we started delivering WebView as an independent APK, updated every six weeks from the Play store, so that we can get important fixes to users quickly. With the newest WebView, we've added a couple more important security enhancements.

Isolating the renderer process in Android O

Starting with Android O, WebView will have the renderer running in an isolated process separate from the host app, taking advantage of the isolation between processes provided by Android that has been available for other applications.

Similar to Chrome, WebView now provides two levels of isolation:

The rendering engine has been split into a separate process. This insulates the host app from bugs or crashes in the renderer process and makes it harder for a malicious website that can exploit the renderer to then exploit the host app.
To further contain it, the renderer process is run within an isolated process sandbox that restricts it to a limited set of resources. For example, the rendering engine cannot write to disk or talk to the network on its own.

It is also bound to the same seccomp filter (blogpost on seccomp is coming soon) as used by Chrome on Android. The seccomp filter reduces the number of system calls the renderer process can access and also restricts the allowed arguments to the system calls.

Incorporating Safe Browsing

The newest version of WebView incorporates Google's Safe Browsing protections to detect and warn users about potentially dangerous sites.. When correctly configured, WebView checks URLs against Safe Browsing's malware and phishing database and displays a warning message before users visit a dangerous site. On Chrome, this helpful information is displayed more than 250 million times a month, and now it's available in WebView on Android.

Enabling Safe Browsing

To enable Safe Browsing for all WebViews in your app, add in a manifest tag:

<manifest>
     <meta-data android:name="android.webkit.WebView.EnableSafeBrowsing"
                android:value="true" />
      . . .
     <application> . . . </application>
</manifest>

Because WebView is distributed as a separate APK, Safe Browsing for WebView is available today for devices running Android 5.0 and above. With just one added line in your manifest, you can update your app and improve security for most of your users immediately.

Ending support for Android Market on Android 2.1 and lower

2017-06-20T11:00:00.000-07:00

Posted by Maximilian Ruppaner, Software Engineer on Google Play

On June 30, 2017, Google will be ending support for the Android Market app on Android 2.1 Eclair and older devices. When this change happens, users on these devices will no longer be able to access, or install other apps from, the Android Market. The change will happen without a notification on the device, due to technical restrictions in the original Android Market app.

It has been 7 years since Android 2.1 Eclair launched. Most app developers are no longer supporting these Android versions in their apps given these devices now account for only a small number of installs.

We will still be supporting later versions of Android Market for as long as feasible. Google Play, the replacement for Android Market, is available on Android 2.2 and above.

Semantic Time support now available on the Awareness APIs

2017-06-16T10:00:00.000-07:00

Posted by Ritesh Nayak M, Product Manager

Last year at I/O we launched the Awareness API, a simple yet powerful API that let developers use signals such as Location, Weather, Time and User Activity to build contextually relevant app experiences.

Available via Google Play services, the Awareness API offers two ways to take advantage of context signals within your app. The Snapshot API lets your app request information about the user's current context, while the Fence API lets your app react to changes in user's context, and when it matches a certain set of conditions. For example, "tell me whenever the user is walking and their headphone is plugged in".

Until now, you could specify a time fence on the Awareness APIs but were restricted to using absolute/canonical representation of time. Based on developer feedback, we realized that the flexibility of the API in regards to building time fences did not support higher level abstractions people use when they think and talk about time. "This weekend", "on the next holiday", "after sunset", are all very common and colloquial ways of expressing time. That's why we're adding Semantic time support to these APIs starting today

For e.g., if you were building a fitness app and wanted a way to prompt users everyday morning to start their routine, or if you're a reading app that wants to turn on night mode after dusk; you would have to query a 3p API for sunrise/sunset information at the user location and then write up an Awareness fence with those canonical time values. With our latest update, you can use our TIME_INSTANT_SUNRISE and TIME_INSTANT_SUNSET constants and let the platform manage all the complexity for you.

Let's look at an example. Suppose you're building a fitness app which prompts users on Tuesday, and Thursday around sunrise to begin their morning work out. You can set up this triggering using the following lines of code.

// A sun-state-based fence that is TRUE only on Tuesday and Thursday during Sunrise 
AwarenessFence.and(
    TimeFence.aroundTimeInstant(TimeFence.TIME_INSTANT_SUNRISE,
            -10 * ONE_MINUTE_MILLIS, 5 * ONE_MINUTE_MILLIS),
    AwarenessFence.or(
        TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_TUESDAY,
                0, ONE_DAY_MILLIS),
        TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_THURSDAY,
                0, ONE_DAY_MILLIS)));

One of our favorite semantic time features is public holidays. Every country and regions within it have different holidays. Assume you were a local hiking & adventure app that wants to show users activities they can indulge in on a holiday that falls on a Friday or a Monday. You can use a combination of Days and Holiday flags to identify this state for all your users around the world. You can do this with just 3 lines of code and have this work in any part of the world.

// A local-time fence that is TRUE only on public holidays in the
// device locale that fall on Fridays or Mondays.
AwarenessFence.and(
    TimeFence.inTimeInterval(TimeFence.TIME_INTERVAL_HOLIDAY),
    AwarenessFence.or(
        TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_FRIDAY,
                9 * ONE_HOUR_MILLIS, 11 * ONE_HOUR_MILLIS),
        TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_MONDAY,
                9 * ONE_HOUR_MILLIS, 11 * ONE_HOUR_MILLIS)));

In both example cases, Awareness does the heavy lifting of localizing time and holidays based on the device locale settings.

We're excited to see what problems you'll solve using this powerful API. Please join our mailing list to get updates about this and other Context APIs at Google.

Android Things Developer Preview 4.1

2017-06-15T09:59:00.001-07:00

Posted by Wayne Piekarski, Developer Advocate for IoT

Today, we're releasing a new Developer Preview 4.1 (DP4.1) of Android Things, with updates for new supported hardware and bug fixes to the platform. Android Things is Google's platform to enable Android Developers to create Internet of Things (IoT) devices, and seamlessly scale from prototype to production.

New hardware

A new Pico i.MX6UL revision B board has been released, which supports many common external peripherals from partners such as Adafruit and Pimoroni. There were some prototype Pico i.MX6UL boards made available to some early beta testers, and these are not compatible with DP4.1.

Improvements

DP4.1 also includes some performance improvements since DP4, such as boot time optimizations that improve the startup time of i.MX7D based hardware. This Developer Preview also includes a version of Google Play Services, specifically optimized for IoT devices. This new IoT variant is a lot smaller and optimized for use with Android Things, and requires the use of play-services 11.0.0 or later in your build.gradle. For more information about the supported features in the IoT variant of Google Play Services, see the information page.

Google I/O

Android Things had a large presence at Google I/O this year, with 7 talks covering different aspects of Android Things for developers, and these are available as videos in a playlist for those who could not attend:

What’s New In Google’s IoT Platform? Ubiquitous Computing at Google

Bringing Device Production to Everyone With Android Things

From Prototype to Production Devices with Android Things

Developing for Android Things Using Android Studio

Security for IoT on Android Things

Using Google Cloud and TensorFlow on Android Things

Building for Enterprise IoT Using Android Things and Google Cloud Platform

Google I/O also had a codelab area, where attendees could sit down and test out Android Things development with some simple guided training guides. These codelabs are available for anyone to try at https://codelabs.developers.google.com/?cat=IoT

Feedback

Thank you to all the developers who submitted feedback for the previous developer previews. Please continue sending us your feedback by filing bug reports and feature requests, and asking any questions on stackoverflow. To download images for DP4.1, 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 get updates and discuss ideas, with over 5,600 members.

Reduce friction with the new Location APIs

2017-06-14T10:00:00.000-07:00

Posted by Aaron Stacy, Software Engineer, Google Play services

The 11.0.0 release of the Google Play services SDK includes a new way to access LocationServices. The new APIs do not require your app to manually manage a connection to Google Play services through a GoogleApiClient. This reduces boilerplate and common pitfalls in your app.

Read more below, or head straight to the updated location samples on GitHub.

Why not use GoogleApiClient?

The LocationServices APIs allow you to access device location, set up geofences, prompt the user to enable location on the device and more. In order to access these services, the app must connect to Google Play services, which can involve error-prone connection logic. For example, can you spot the crash in the app below?

Note: we'll assume our app has the ACCESS_FINE_LOCATION permission, which is required to get the user's exact location using the LocationServices APIs.

public class MainActivity extends AppCompatActivity implements
        GoogleApiClient.OnConnectionFailedListener {

  @Override
  public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    GoogleApiClient client = new GoogleApiClient.Builder(this)
        .enableAutoManage(this, this)
        .addApi(LocationServices.API)
        .build();
    client.connect();

    PendingResult result = 
         LocationServices.FusedLocationApi.requestLocationUpdates(
                 client, LocationRequest.create(), pendingIntent);

    result.setResultCallback(new ResultCallback() {
      @Override
      public void onResult(@NonNull Status status) {
        Log.d(TAG, "Result: " + status.getStatusMessage());
      }
    });
  }

  // ...
}

If you pointed to the requestLocationUpdates() call, you're right! That call throws an IllegalStateException, since the GoogleApiClient is has not yet connected. The call to connect() is asynchronous.

While the code above looks like it should work, it's missing a ConnectionCallbacks argument to the GoogleApiClient builder. The call to request location updates should only be made after the onConnected callback has fired:

public class MainActivity extends AppCompatActivity implements 
        GoogleApiClient.OnConnectionFailedListener,
        GoogleApiClient.ConnectionCallbacks {

  private GoogleApiClient client;

  @Override
  protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    client = new GoogleApiClient.Builder(this)
        .enableAutoManage(this, this)
        .addApi(LocationServices.API)
        .addConnectionCallbacks(this)
        .build();

    client.connect();
  }

  @Override
  public void onConnected(@Nullable Bundle bundle) {
    PendingResult result = 
            LocationServices.FusedLocationApi.requestLocationUpdates(
                    client, LocationRequest.create(), pendingIntent);
    
    result.setResultCallback(new ResultCallback() {
      @Override
      public void onResult(@NonNull Status status) {
        Log.d(TAG, "Result: " + status.getStatusMessage());
      }
    });
  }

  // ...
}

Now the code works, but it's not ideal for a few reasons:

It would be hard to refactor into shared classes if, for instance, you wanted to access Location Services in multiple activities.
The app connects optimistically in onCreate even if Location Services are not needed until later (for example, after user input).
It does not handle the case where the app fails to connect to Google Play services.
There is a lot of boilerplate connection logic before getting started with location updates.

A better developer experience

The new LocationServices APIs are much simpler and will make your code less error prone. The connection logic is handled automatically, and you only need to attach a single completion listener:

public class MainActivity extends AppCompatActivity {

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    FusedLocationProviderClient client =
            LocationServices.getFusedLocationProviderClient(this);

    client.requestLocationUpdates(LocationRequest.create(), pendingIntent)
        .addOnCompleteListener(new OnCompleteListener() {
          @Override
          public void onComplete(@NonNull Task task) {
            Log.d("MainActivity", "Result: " + task.getResult());
          }
        });
  }
}

The new API immediately improves the code in a few ways:

The API calls automatically wait for the service connection to be established, which removes the need to wait for onConnected before making requests.
It uses the Task API which makes it easier to compose asynchronous operations.
The code is self-contained and could easily be moved into a shared utility class or similar.
You don't need to understand the underlying connection process to start coding.

What happened to all of the callbacks?

The new API will automatically resolve certain connection failures for you, so you don't need to write code that for things like prompting the user to update Google Play services. Rather than exposing connection failures globally in the onConnectionFailed method, connection problems will fail the Task with an ApiException:

    client.requestLocationUpdates(LocationRequest.create(), pendingIntent)
        .addOnFailureListener(new OnFailureListener() {
          @Override
          public void onFailure(@NonNull Exception e) {
            if (e instanceof ApiException) {
              Log.w(TAG, ((ApiException) e).getStatusMessage());
            } else {
              Log.w(TAG, e.getMessage());
            }
          }
        });

Try it for yourself

Try the new LocationServices APIs out for yourself in your own app or head over to the android-play-location samples on GitHub and see more examples of how the new clients reduce boilerplate and simplify logic.

Recognizing Android Excellence on Google Play

2017-06-13T09:00:00.000-07:00

Posted by Kacey Fahey, Developer Marketing, Google Play

Every day developers around the world are hard at work creating high quality apps and games on Android. Striving to deliver amazing experiences for an ever growing diverse user base, we've seen a significant increase in the level of polish and quality of apps and games on Google Play.

As part of our efforts to recognize this content on the Play Store, today we're launching Android Excellence. The new collections will showcase apps and games that deliver incredible user experiences on Android, use many of our best practices, and have great design, technical performance, localization, and device optimization.

Android Excellence collections will refresh quarterly and can be found within the revamped Editors' Choice section of the Play Store – which includes app and game reviews curated by our editorial team.

Congrats to our first group of Android Excellence apps and games!

Android Excellence Apps	Android Excellence Games
AliExpress by Alibaba Mobile B&H Photo Video by B&H Photo Video Citymapper by Citymapper Limited Drivvo by Drivvo drupe by drupe Evernote by Evernote Corporation HotelTonight by HotelTonight Kitchen Stories by Kitchen Stories Komoot by komoot GmbH Lifesum by Lifesum Memrise by Memrise Pocket by Read It Later Runtastic Running & Fitness by Runtastic Skyscanner by Skyscanner Ltd Sleep as Android by Urbandroid Team Vivino by Vivino	After the End Forsaken Destiny by NEXON M Inc. CATS: Crash Arena Turbo Stars by ZeptoLab Golf Clash by Playdemic Hitman GO Square Enix Ltd Horizon Chase by Aquiris Game Studio S.A Kill Shot Bravo by Hothead Games Lineage Red Knights by NCSOFT Corporation Nonstop Knight by flaregames PAC-MAN 256 - Endless Maze by Bandai Namco Entertainment Europe Pictionary™ by Etermax Reigns by DevolverDigital Riptide GP: Renegade by Vector Unit Star Wars™: Galaxy of Heroes by Electronic Arts Titan Brawl by Omnidrone Toca Blocks by Toca Boca Transformers: Forged to Fight by Kabam

Android Excellence Apps

Android Excellence Games

AliExpress by Alibaba Mobile

B&H Photo Video by B&H Photo Video

Citymapper by Citymapper Limited

Drivvo by Drivvo

drupe by drupe

Evernote by Evernote Corporation

HotelTonight by HotelTonight

Kitchen Stories by Kitchen Stories

Komoot by komoot GmbH

Lifesum by Lifesum

Memrise by Memrise

Pocket by Read It Later

Runtastic Running & Fitness by Runtastic

Skyscanner by Skyscanner Ltd

Sleep as Android by Urbandroid Team

Vivino by Vivino

After the End Forsaken Destiny by NEXON M Inc.

CATS: Crash Arena Turbo Stars by ZeptoLab

Golf Clash by Playdemic

Hitman GO Square Enix Ltd

Horizon Chase by Aquiris Game Studio S.A

Kill Shot Bravo by Hothead Games

Lineage Red Knights by NCSOFT Corporation

Nonstop Knight by flaregames

PAC-MAN 256 - Endless Maze by Bandai Namco Entertainment Europe

Pictionary™ by Etermax

Reigns by DevolverDigital

Riptide GP: Renegade by Vector Unit

Star Wars™: Galaxy of Heroes by Electronic Arts

Titan Brawl by Omnidrone

Toca Blocks by Toca Boca

Transformers: Forged to Fight by Kabam

Stay up-to-date on best practices to succeed on Play and get the latest news and videos with the new beta version of our Playbook app for developers.

How useful did you find this blogpost?

★ ★ ★ ★ ★

Money made easily with the new Google Play Billing Library

2017-06-12T09:00:00.000-07:00

Posted by Neto Marin, Developer Advocate

Many developers want to make money through their apps, but it's not always easy to deal with all the different types of payment methods. We launched the Google Play In-app Billing API v3 in 2013, helping developers offer in-app products and subscriptions within their apps. Year after year, we've added features to the API, like subscription renewal, upgrades and downgrades, free trials, introductory pricing, promotion codes, and more.

Based on your feedback, we’re pleased to announce the Play Billing Library - Developer Preview 1. This library aims to simplify the development process when it comes to billing, allowing you to focus your efforts on implementing logic specific to your app, such as application architecture and navigation structure. The library includes several convenient classes and features for you to use when integrating your Android apps with the In-app Billing API. The library also provides an abstraction layer on top of the Android Interface Definition Language (AIDL) service, making it easier for you to define the interface between your app and the In-app Billing API.

Easy to get started and easy to use

Starting with Play Billing Library Developer Preview release, the minimum supported API level is Android 2.2 (API level 8), and the minimum supported In-app Billing API is version 3.

In-app billing relies on the Google Play Store, which handles the communication between your app and Google's Play billing service. To use Google Play billing features, your app must request the com.android.vending.BILLINGpermission in your AndroidManifest.xml file.

To use the library, add the following dependency in your build.gradle file:

dependencies {
    ...
    compile 'com.android.billingclient:billing:dp-1'
}

After this quick setup process, you're ready to start using the Play Billing Library in your app and can connect to the In-app Billing API, query for available products, start the purchase flow, and more.

Sample updated: Trivial Drive V2

With a new library comes a refreshed sample! To help you to understand how to implement in-app billing in your app using the new Play Billing Library, we've rewritten the Trivial Drive sample from the ground up.

Since we released Trivial Drive back in 2013, many new features, devices, and platforms have been added to the Android ecosystem. To reflect this evolution, the Trivial Drive v2 sample now runs on Android TV and Android Wear.

Give it a try!

Before integrating within your app, you can try the Play Billing Library with the codelab published during Google I/O 2017: Buy and Subscribe: Monetize your app on Google Play.

In this codelab, you will start with a simplified version of Trivial Drive V2 that lets users to "drive" and then you will add in-app billing to it. You'll learn how to integrate purchases and subscriptions as well as the best practices for developing reliable apps that handle purchases.

If you are looking for a step-by-step guide about how to sell in-app products from your app using the Play Billing Library, check out our new training class, explaining how to prepare your application, add products for purchase, start purchase flow and much more.

We want your feedback

We look forward to hearing your feedback about this new library. Visit the Play Billing Library site, the library reference, and the new version of the Trivial Drive sample. If you have issues or questions, file a bug report on the Google Issue Tracker, and for issues and suggestions on the sample, contact us on the Trivial Drive issues page.

For technical questions on implementation, library usage, and best practices, you can use the tags google-play and play-billing-library on Stackoverflow or visit the community pages on our Google+ page.

Making the Internet safer and faster: Introducing reCAPTCHA Android API

2017-06-09T09:15:00.000-07:00

Posted by Wei Liu, Product Manager

When we launched reCAPTCHA ten years ago, we had a simple goal: enable users to visit the sites they love without worrying about spam and abuse. Over the years, reCAPTCHA has changed quite a bit. It evolved from the distorted text to street numbers and names, then No CAPTCHA reCAPTCHA in 2014 and Invisible reCAPTCHA in March this year.

By now, more than a billion users have benefited from reCAPTCHA and we continue to work to refine our protections.

reCAPTCHA protects users wherever they may be online. As the use of mobile devices has grown rapidly, it's important to keep the mobile applications and data safe. Today, on reCAPTCHA's tenth birthday, we're glad to announce the first reCAPTCHA Android API as part of Google Play Services.

With this API, reCAPTCHA can better tell human and bots apart to provide a streamlined user experience on mobile. It will use our newest Invisible reCAPTCHA technology, which runs risk analysis behind the scene and has enabled millions of human users to pass through with zero click everyday. Now mobile users can enjoy their apps without being interrupted, while still staying away from spam and abuse.

reCAPTCHA Android API is included with Google SafetyNet, which provides services like device attestation and safe browsing to protect mobile apps. Mobile developers can do both the device and user attestations in the same API to mitigate security risks of their apps more efficiently. This adds to the diversity of security protections on Android: Google Play Protect to monitor for potentially harmful applications, device encryption, and regular security updates. Please visit our site to learn more about how to integrate with the reCAPTCHA Android API, and keep an eye out for our iOS library.

The journey of reCAPTCHA continues: we'll make the Internet safer and easier to use for everyone (except bots).

Android O APIs are final, get your apps ready!

2017-06-08T10:25:00.001-07:00

Posted by Dave Burke, VP of Engineering

Three weeks ago at Google I/O, we announced the second developer preview of Android O along with key themes, Fluid Experiences and Vitals, and highlighted our work towards a modular base with Project Treble. It was also an important milestone for us with the release of the first beta-quality candidate. We talked a lot about what's new in Android during the keynote and breakout sessions—if you missed the livestream, be sure to check out the full archive of talks here.

Today we're rolling out Developer Preview 3 with the final Android O APIs, the latest system images, and an update to Android Studio to help you get ready for the consumer release later in the summer. Watch for one more preview update coming in July that will bring you the near-final system images.

If you've already enrolled your device in the Android Beta Program, you'll receive an update to Developer Preview 3 shortly.

Make your app compatible with Android O

With the consumer launch approaching in the coming months, a critical first step is making your current app compatible with Android O. This will give your users a seamless transition to the new platform as it arrives on their devices.

If you haven't tested your app for compatibility yet, getting started is straightforward -- just enroll a supported device in Android Beta and get the latest update over-the-air, then install your current app from Google Play and test. The app should run and look great, and it should handle the Android O behavior changes properly -- in particular pay attention to background limits and changes in networking, security, and identifiers.

After you've made any necessary updates, we recommend publishing the compatible version of your app to Google Play right away -- without changing the app's platform targeting.

Enhance your app with Android O features and APIs

Extending your apps with Android O features can help you drive more engagement, offer new interactions, give users more control and security, and even improve your app's performance.

Notification channels and dots give you more ways to surface new content to users and bring them back into your app. Picture-in-picture keeps your app onscreen while users are multitasking, and autofill makes it simple for them to enter forms data and helps keep their data secure. Also check out adaptive icons, XML font resources, downloadable fonts and emoji, autosizing TextView, AAudio API, and many others. You'll also want plan your support for background execution limits and other important changes in vital system behavior for O apps.

Visit the O Developer Preview site to learn about all of the new features and APIs and how to build them into your apps.

Picture-in-Picture mode lets you keep users engaged while they are multitasking (left). Notification dots keep users active in your app and let them jump directly the app’s core functions (right).

Get started with Developer Preview 3

Today's preview update includes the latest version of the Android O platform with the final API level 26 and hundreds of bugfixes and optimizations. You can download the final API 26 SDK from the SDK Manager in Android Studio, and Android Support Library 26.0.0 beta 2 from Google's Maven repository.

Together, these give you everything you need to develop and test your apps with the official Android O APIs. Once you've installed the final SDK, you can update your project's compileSdkVersion to API 26 to compile against the official Android O APIs. We also recommend updating your app's targetSdkVersion to API 26 to opt-in and test your app with Android O specific behavior changes. See the migration guide for details on how to set up your environment to build with Android O.

APIs have changed since the second developer preview, so if you have existing code using Android O preview APIs, take a look at the diff report to see where your code might be affected.

If you're developing for Android O, we recommend updating to the latest version of Android Studio 3.0, now available in the canary channel. Aside from great new features like improved app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 includes build support for Instant Apps, an Adaptive Icon Wizard, and support for XML Fonts, and Downloadable Fonts.

Android Studio 3.0 includes tools for developing with Android O features lets you preview XML font resources in your app.

If you don't plan to use those features, you now have the option of developing for Android O using Android Studio 2.3.3 from the stable channel. Note that the tools for working with adaptive icons and downloadable fonts, and XML fonts are not available in Android Studio 2.3.3.

Publish your apps to alpha, beta or production channels in Google Play

Now that the APIs are final, you can publish APK updates compiling with, and optionally targeting, API 26 to your alpha, beta, or even production channels in Google Play. Publishing your O-targeted app during the preview lets you test compatibility on existing devices and push updates to devices running API 26 -- such as users who are enrolled in the Android Beta program.

To make sure that your updated app runs well on Android O as well as older versions, a common strategy is to use Google Play's beta testing feature to get early feedback from a small group of users -- including developer preview users — and then do a staged rollout as you release the updated app to all users.

How to get the preview update

Through the Android Beta program, developers and early adopters worldwide will soon be getting Developer Preview 3 on their devices. If you aren't yet enrolled, just visit android.com/beta and opt-in your eligible Android phone or tablet. As always, you can also download and flash this update manually. The O Developer Preview is available for Pixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P, and Nexus Player.

Thanks so much for all of your feedback so far. Please continue to share feedback or requests as we work towards the consumer release later this summer. We're looking forward to seeing your apps on Android O!

Google Play’s policy on incentivized ratings, reviews, and installs

2017-06-05T10:00:00.000-07:00

Posted by Kazushi Nagayama, Ninja Spamologist and Bryan Woodward, Policy Specialist

Ensuring Google Play remains trusted and secure is one of our top priorities. We've recently announced improvements in fighting spam installs as well as fake ratings & reviews. In order to underscore these announcements and provide more clarity, we have now updated our Developer Program Policies on incentivized ratings, reviews, and installs:

Developers must not attempt to manipulate the placement of any apps in the Store. This includes, but is not limited to, inflating product ratings, reviews, or install counts by illegitimate means, such as fraudulent or incentivized installs, reviews and ratings.

Defining an incentivized action

We deem an action to be incentivized if a user is offered money, goods, or the equivalent in exchange for the action – be it a rating, review or install. Incentivized ratings and reviews have always been against our policies and we will continue to take action against them in order to protect the integrity of our store. Installs done with the intent to manipulate the placement of an app in Google Play will be detected and filtered.

Incentivized installs as user acquisition

We've observed instances where incentivized installs are utilized solely to manipulate the placement of apps in Google Play; these instances are a policy violation. However, we also recognize that incentivized installs can be a legitimate user acquisition channel for some developers. In order to recognize these two distinct use cases, we are taking the following approach:

Whilst we won't automatically remove apps from the store just because they utilize incentivized installs as one of their user acquisition channels, we will monitor for, and take action against behaviour that compromises the integrity of the store.
To address those whose intent we perceive is to manipulate the placements of their apps, we will monitor and filter incentivized installs in our systems, including removal from the top charts. If warranted, identified apps also may be removed from the Store.

Through this approach, we hope to further ensure that the top charts and other discovery mechanisms on Google Play reflect the reality of the popularity of an app.

As a general rule, we advise against utilizing incentivized actions. Incentivized users are a very different user base than users found through other acquisition channels. In an internal analysis, the Google Research team found that incentivized users generally have lower retention rates and make fewer in-app purchases than users found through paid or organic acquisition channels.

For more information on the Google Play policies, please visit the developer policy center. For tips and best practices to find success on Google Play, visit the Android Developers website.

How useful did you find this blogpost?

★ ★ ★ ★ ★

2017 Android Security Rewards

2017-06-01T09:12:00.001-07:00

Posted by Mayank Jain and Scott Roberts of the Android Security team

Two years ago, we launched the Android Security Rewards program. In its second year, we've seen great progress. We received over 450 qualifying vulnerability reports from researchers and the average pay per researcher jumped by 52.3%. On top of that, the total Android Security Rewards payout doubled to $1.1 million dollars. Since it launched, we've rewarded researchers over $1.5 million dollars.

Here are some of the highlights from the Android Security Rewards program's second year:

There were no payouts for the top reward for a complete remote exploit chain leading to TrustZone or Verified Boot compromise, our highest award amount possible.
We paid 115 individuals with an average of $2,150 per reward and $10,209 per researcher.
We paid our top research team, C0RE Team, over $300,000 for 118 vulnerability reports.
We paid 31 researchers $10,000 or more.

Thank you to all the amazing researchers who submitted complete vulnerability reports to us last year.

Improvements to Android Security Rewards program

We're constantly working to improve the Android Security Rewards program and today we're making a few changes to all vulnerability reports filed after June 1, 2017.

Because every Android release includes more security protections and no researcher has claimed the top reward for an exploit chains in 2 years, we're excited to increase our top-line payouts for these exploits.

Rewards for a remote exploit chain or exploit leading to TrustZone or Verified Boot compromise increase from $50,000 to $200,000.
Rewards for a remote kernel exploit increase from $30,000 to $150,000.

In addition to rewarding for vulnerabilities, we continue to work with the broad and diverse Android ecosystem to protect users from issues reported through our program. We collaborate with manufacturers to ensure that these issues are fixed on their devices through monthly security updates. Over 100 device models have a majority of their deployed devices running a security update from the last 90 days. This table shows the models with a majority of deployed devices running a security update from the last two months:

Manufacturer	Device
BlackBerry	PRIV
Fujitsu	F-01J
General Mobile	GM5 Plus d, GM5 Plus, General Mobile 4G Dual, General Mobile 4G
Gionee	A1
Google	Pixel XL, Pixel, Nexus 6P, Nexus 6, Nexus 5X, Nexus 9
LGE	LG G6, V20, Stylo 2 V, GPAD 7.0 LTE
Motorola	Moto Z, Moto Z Droid
Oppo	CPH1613, CPH1605
Samsung	Galaxy S8+, Galaxy S8, Galaxy S7, Galaxy S7 Edge, Galaxy S7 Active, Galaxy S6 Active, Galaxy S5 Dual SIM, Galaxy C9 Pro, Galaxy C7, Galaxy J7, Galaxy On7 Pro, Galaxy J2, Galaxy A8, Galaxy Tab S2 9.7
Sharp	Android One S1, 507SH
Sony	Xperia XA1, Xperia X
Vivo	Vivo 1609, Vivo 1601, Vivo Y55

Source: Google May 29th, 2017.

Thank you to everyone who helped make Android safer and stronger in the past year. Together, we made a huge investment in security research that helps Android users everywhere. If you want to get involved to make next year even better, check out our detailed Program Rules. For tips on how to submit complete reports, see Bug Hunter University.

Meet 5 Android developers working to improve lives around the world

2017-05-26T09:00:00.000-07:00

Posted by Maxim Mai, Apps Partnerships, Google Play

Last Thursday at Google I/O 2017, we announced the winners of this year's Google Play Awards. Grab some popcorn and watch the award ceremony, we think it's just as fun as The Oscars. This year, we included a category to celebrate the achievements of developers who publish outstanding apps that have positive social impact.

In introducing this awards category, we were inspired by the UN's 17 Sustainable Development Goals. With the ability to reach over 1 billion active Android devices around the world, we think that app developers have a tremendous opportunity to impact Zero Hunger (SDG #2), Good Health and Wellbeing (SDG #3) and Quality Education (SDG #4), and many others. Read on to find out more about how this year's winner and finalists and impacting these goals.

Get in touch about your social impact app or game

Our work in supporting developer success in this area on Android and Google Play is just beginning. We would like to encourage Android developers with a focus on social impact to get in touch with us here at Google Play and to tell us about their app or game. It doesn't matter where you are based, what problems you are solving, or which countries you are targeting, we would like to hear your story and maybe we can help you grow faster and improve your app's quality.

Social impact winner & finalists in the 2017 Google Play Awards

🏆 ShareTheMeal by United Nations 🏆

The Google Play Award category winner, ShareTheMeal, generates large scale, global awareness for "Zero Hunger" and its users' donations pay for school meals, which are provided by the World Food Programme, in regions around the world experiencing food insecurity. Over 13 million meals have been donated via the app since launch!

Charity Miles by Charity Miles

This is a running, cycling and walking tracker app with a social impact twist. Charity Miles earns money for charity on your behalf for every mile you move, via its brand fitness exercise sponsors! Users have already donated $2 million to charity by recording over 40 million miles!

Peek Acuity by Peak Vision

Peek Acuity allows anyone with an Android phone to easily measure visual acuity, which is one of the components of vision. It is designed by eye care professionals to be used to help identify people who need further examination by, for example, an optometrist or ophthalmologist. In developing countries, over XM [confirm number with Peek Vision] struggle with vision impairment and many don't have easy access to an eye care professional.

Prodeaf Translator by ProDeaf Tecnologias Assistivas

This app lets anyone translate phrases and words from Portuguese for Brazilian Sign Language (Libras) or from English to American Sign Language (ASL). This significantly reduces barriers to communication between the millions of people who depend on Libras or ASL as their lingua franca and others who have not had the opportunity to learn this form of communication.

Sea Hero Quest by GLITCHERS

This is not just a game, it's a quest to help scientists fight dementia! It sounds too good to be true but this really is a game, where simply by having loads of fun chasing creatures around magical seas and swamps, you can help to fight a disease that currently affects 45 million people worldwide. In fact playing SEA HERO QUEST for just 2 minutes will generate the equivalent of 5 hours of lab-based research data.

If you're working on an app or game with a positive social impact, don't forget to get in touch via this form and tick the "Social Impact app" checkbox.

How useful did you find this blogpost?

★ ★ ★ ★ ★

Welcome to your New Home on Android TV

2017-05-25T10:00:00.000-07:00

Posted by Paul Saxman, Android Devices and Media Developer Relations Lead

Android TV brings rich app experiences and entertainment to the biggest screen in your house, and with Android O, we’re making it even easier for users to access content from their favorite apps. We’ve built a new, content-centric home screen experience for Android TV, and we're bringing the Google Assistant to the platform as well. These features put content that users want to access a few clicks, or spoken words, away.

The New Android TV Home Screen

The new Android TV home screen organizes video content into channels and programs in a way that’s familiar to TV viewers. Each Android TV app can publish multiple channels, which are represented as rows of programs on the home screen. Apps add relevant programs on each channel, and update these programs and channels as users access content or when new content is available. To help engage users, programs can include a video preview, which is automatically played when a user focuses on a program. Users can configure which channels they wish to see on the home screen, and the ordering of channels, so the themes and shows they’re interested in are quick and easy to access.

In addition to channels for you app, the top of the new Android TV home screen includes a quick launch bar for users' favorite apps, and a special Watch Next channel. This channel contains programs based on the viewing habits of the user.

The APIs for creating and maintaining channels and programs are part of the TvProvider APIs, which are distributed as an Android Support Library module with Android O. To get started using these APIs, visit the Android O Developer Preview site for an overview, and try out the Android TV Channels and Programs codelab for a first-hand experience building an Android TV app for Android O.

Later this year, Nexus Players will receive the new Android TV home experience as an OTA update. If you wish build and test apps for the new interface today, however, you can use the Android TV emulator or Nexus Player device images that are part of the latest Android O Developer Preview.

The Google Assistant on Android TV

The Google Assistant on Android TV, coming later this year, will allow users to quickly find and access content using their voice. Because the Assistant is context-aware, it can help users narrow down what content to play. Users will also be able access the Assistant to control playback, even while a video or music is playing. And since the Assistant can control compatible smart home devices, a simple voice request can dim the lights to create an ideal movie viewing environment. When the Google Assistant comes to Android TV, it will launch in the US on Android devices running M, N, and O.

We're looking forward to seeing how developers take advantage of the new Android TV home screen. We welcome feedback, so please visit the Android TV Developer Community on G+ to share you thoughts and ideas!

Request a professional app translation from the Google Play Console and reach new users

2017-05-24T10:45:00.000-07:00

Posted by Rahim Nathwani, Product Manager, Google Play
Localizing your app or game is an important step in allowing you to reach the widest possible audience. It helps you increase downloads and provide better experiences for your audience.
To help do this, Google Play offers an app translation service. The service, by professional linguists, can translate app user interface strings, Play Store text, in-app products and universal app campaign ads. We've made the app translation service available directly from inside the Google Play Console, making it easy and quick to get started.

Choose from a selection of professional translation vendors.
Order, receive and apply translations, without leaving the Play Console.
Pay online with Google Wallet.
Translations from your previous orders (if any) are reused, so you never pay for the same translation twice. Great if you release new versions frequently.

Using the app translation service to translate a typical app and store description into one language may cost around US$50. (cost depends on the amount of text and languages).
Find out more and get started with the app translation service.

How useful did you find this blogpost?

★ ★ ★ ★ ★

Group Messaging in Android Auto

2017-05-23T13:48:00.000-07:00

Posted by David Nelloms, Software Engineer

Communicating with a group of people is a common use case for many messaging apps. However, it may be difficult to know how the Android Auto messaging API applies to group conversations. Here are some tips for getting started with group messaging in Android Auto:

Conversation Name

When constructing the UnreadConversation builder, you are required to pass in a name. This is the name of the conversation that is displayed to the user when messages arrive.

UnreadConversation.Builder unreadConvBuilder =
    new UnreadConversation.Builder(conversationName)
        .setReadPendingIntent(msgHeardPendingIntent)
        .setReplyAction(msgReplyPendingIntent, remoteInput);

For one-on-one conversations, this is simply the name of the other participant. For group conversations, it is best to choose one of two options for the name:

Conversation title: If your app supports adding a title to group conversations, use the title for the name parameter to be consistent with your in-app experience. This field is similar to NotificationCompat.MessagingStyle#setConversationTitle.
A list of participants: Build a comma-separated list of participants for the name parameter to identify the group. Note that this is read aloud by the text-to-speech system, so you may need to abbreviate the list for large groups. You should balance allowing users to uniquely identify the group with the time taken to listen to messages.

Text to Speech Formatting

Getting text to sound natural using a TTS system is a challenging problem. There are teams working hard to improve this, but there are steps you can take to create a better user experience with the current capabilities. The Android Auto messaging API does not yet have an option for pairing participants with individual messages in a group conversation. This is problematic for drivers when there are multiple unread messages from multiple participants in a group conversation, as the drivers cannot see which group member sent which message. One solution is to prepend the sender's name to the message whenever the sender changes so that the names are read aloud to the driver.

CharSequence currentSender = null;
for (Message message : myMessages) {
    StringBuilder messageText = new StringBuilder();
    CharSequence sender = message.getSender();
    // Maybe append sender to indicate who is speaking.
    if (!TextUtils.isEmpty(sender) && !sender.equals(currentSender)) {
        if (currentSender != null) {
            // Punctuation will briefly pause TTS readout between senders.
            messageText.append(". ");
        }
        currentSender = sender;
        messageText.append(sender.toString().toLowerCase(Locale.getDefault()));
        // Punctuation will separate sender from message in TTS readout.
        messageText.append(": ");
    }
    messageText.append(message.getText());
    unreadConvBuilder.addMessage(messageText.toString());
}

Some things to note about the above sample code:

Adding punctuation is not strictly necessary, but it can produce a more natural sounding result.
The sender names are converted to lowercase. This is workaround for a quirk where the TTS implementation vocalizes ". " as "dot" when preceding a capital letter on some devices.

Get participants

In searching for how to handle group messaging, you may have noticed UnreadConversation#getParticipants. This can be confusing as there is no mechanism to add multiple participants in the builder. The builder implementation populates the array with the conversation name passed to its constructor. Internally, Android Auto uses the singular UnreadConversation#getParticipant, which returns the first element of the participants array, to populate the title in the notification view.

Stay tuned

The Android Auto team is working on ways to make messaging with drivers simpler and more intuitive for app developers. Stay tuned for future updates so that you can continue to deliver a great user experience!

Make more money with subscriptions on Google Play

2017-05-19T10:30:00.000-07:00

Posted by George Audi, Tom Grinsted and Larry Yang, Google Play

The subscription business model is one of the best ways to make more regular, reliable, and recurring revenue on Android and Google Play. In fact, both developers and users love subscription apps so much that we’ve seen a 10X growth in consumer spend over the past three years and double the number of active subscribers in the past year. Thousands of developers are offering subscriptions through Google Play and are already seeing success with our billing platform. That’s why we’ve been working hard to help you take advantage of this opportunity and give you greater insights into your business and Android users.

New features to help your subscriptions business thrive

You've got a high-performing product with fantastic features and compelling content, but your business can't succeed without acquiring new users. In addition to free trials, intro pricing, flexible billing periods, and more, we recently launched the ability to pay for subscriptions with Google Play balance. Although people have already been using gift cards to pay for Play content in over 20 countries, the use of gift cards to pay for subscriptions in regions where cash is a popular form of payment, such as Latin America, has resulted in as high as a 15% increase in subscription spend.

But it's not just about acquiring new customers, it's about retaining the ones you have. That's why we are introducing account hold, where we work with you to block access to your content or service if a user's form of payment fails. This directly links a payment failure to the user losing access to your content and/or premium features, which is enough to get them to go and choose a new form of payment. When Keepsafe–the developer of Keepsafe Photo Vault, a photo locker for private pictures and videos with over 50M downloads–integrated account hold, their renewal rate on Android increased by 25%. We have over a dozen developers in early access today, and we will be announcing public availability at the end of June.

We know data is vital to running your business, so we're excited to announce a new subscriptions dashboard in the Play Console, and a new report on Android app subscribers.

The dashboard brings together subscription data like new subscribers, cancellations, and total subscribers. It also displays daily and 30-day rolling revenue data, and highlights your top-performing products. This will give visibility into your subscription products and users and will help guide your business decisions.

Insights to help you grow your subscriptions business

In addition to products and features, understanding people's needs is core to building a successful subscription business. We talked to 2,000 Android app subscribers in the US and UK and asked them how and why they use the apps they do. The results shared in 'Subscription apps on Google Play: User insights to help developers win' report highlight some of the opportunities for you to grow your subscriptions user base, set pricing strategies and learn to keep your users engaged, including:

Use free trials to acquire users. 78% of users start with a free version of an app, and many cite a discount or end of a free trial as a reason to pay.
Keep your content appealing and updated to get and keep users paying. It's the most important driver in converting users from free to paid users, as well as keeping users engaged and retained.

There is a huge opportunity to make money from subscriptions. While pricing elasticity varies by category, few users cite price as a reason to churn from a paid subscription and 64% either budget on a per app basis or not at all (as opposed to budgeting across all app subscriptions).

To find out more about your growing your subscription business with Google Play, watch our I/O session, download the research report (PDF), and get started with subscriptions with Google Play In-app Billing.

How useful did you find this blogpost?

★ ★ ★ ★ ★

Android Wear: New complications tools and watch friendly UI library

2017-05-18T10:00:00.000-07:00

Posted by Hoi Lam, Lead Developer Advocate, Android Wear

Android Wear 2.0 gives users more informative watch faces and provides developers with new ways to build useful apps. These new opportunities have been well received by users and developers alike. To help developers take advantage of these new features, we have released a suite of complication API tools, to make it easier for developers to add complication support to their watch faces, and a new Wear UI library, to help developers build watch friendly user interfaces.

New Complications API tools for Watch Face developers

Complications are bite-sized pieces of information displayed directly on the watch face. They can also be great shortcuts into your favorite apps. We introduced the Complications API last year to enable watch faces to receive data from any app that the user selects, and display the data to the user in a way that is stylistically coherent. Today, we are introducing four new tools to make it easier for watch face developers to integrate with the Complications API:

TextRenderer - Auto-sizes text to fit in bounds defined by watch face makers.
ComplicationDrawable - A full rendering solution for complications, that handles all the styling for you, and adjusts the layout to fit the space you specify
Easy watch face settings sample - Adoptable sample code that makes it easier to build complication settings with a rich and usable experience.
Complication test suite - A sample data provider to help check that your watch face can handle all the combinations of fields that can make up complication data.

It's never been easier to integrate complications into your watch faces.

New Wear UI Library for Wear developers

We have provided Android view components for building watch friendly user interfaces since the launch of Android Wear 1.0. Developers have told us that they would like to see these components open sourced. So, starting at Google I/O, we are open sourcing some components and providing some Android Wear UI components in the Android Support Library. This brings a number of advantages, including more consistent APIs with the rest of the Support Library, more frequent releases, and better responsiveness to developer feedback. We will:

Migrate Wearable Support classes - Migrate and update Android Wear specific view components, such as WearableRecyclerView, from android.support.wearable.view in Wearable Support to android.support.wear.widget in the Android Support Library. This new package is available as open source. In terms of developer impact, we expect the migration process to be simple, with minor API name changes to bring consistency with the existing Android Support Library.
Merge some Android Wear functionality to Android - Some Android Wear components have a lot of overlap with Android, e.g. CircledImageView and DelayedConfirmationView. We will merge the Android Wear specific functionality with the Android counterparts under android.support.v4.widget.
Deprecate outdated user interface patterns - Two user interface patterns are deprecated with Android Wear 2.0: the Card pattern and the Multi-directional layout. As a result, we have deprecated all supporting classes, such as GridViewPager and CardFragment. Please refer to the class reference docs for their replacements.

In the first wave of these changes, we migrated the WearableRecyclerView, BoxInsetLayout and SwipeDismissFrameLayout classes to the new Android Wear UI Library. We expect the migration process to continue during 2017, and developers will have until mid-2018 to migrate to the new UI components. For additional information, see Using the Wear UI Library.

Get started and give us feedback!

To get started with these new tools, simply update the Android Support Library in Android Studio and update your gradle build files to import the new support libraries. In addition to the documentation links above, check out the Google I/O session - Android Wear UI development best practice - where lead engineers for these tools will be on-hand to explain the technical details.

We will continue to update these tools over the next few months, based on your feedback. The sooner we hear from you, the more we can include, so don't be shy! Let us do some of the heavy lifting for your Android Wear apps and watch faces.

What’s next for Google payment and loyalty experiences

2017-05-18T06:00:00.000-07:00

Posted by Pali Bhat, VP of Payment Products

Thousands of apps and millions of stores accept Android Pay, a simpler and more secure mobile payment experience. Android Pay is now available in 10 markets, with more coming soon, including Brazil, Canada, Russia, Spain and Taiwan. And in addition to our already announced Visa and Mastercard partnerships, we'll soon enable a streamlined mobile checkout experience for PayPal users.

The newest ways to pay with Google

Yesterday, we announced the Google Payment API, which lets people pay in app or online with any verified credit or debit card saved to their Google Account, via products like Google Play, Chrome and YouTube.

Paying with Google in the Wish app

For users, the option to pay with Google means breezing through checkout without needing to remember and type multiple lines of payment details. You simply choose your preferred card, enter a security code or authenticate with your Android device, and check out.

Developers who adopt this API can enable an easy-to-use checkout experience for their customers. Sign up for early access to the new Google Payment API.

In the upcoming months, we'll also enable people in the U.S. to send or receive payments via the Google Assistant. On your Google Home or Android device, it's as simple as saying "Ok Google, send $10 to Jane for pizza." All you need is a debit card linked to your Google account.

Pay friends on Google Assistant

Connect with customers before, during and after purchase

We're also announcing new ways for merchants to engage and reward customers before they walk into the store and after they've left.

The Card Linked Offers API drives customer loyalty by providing a new channel to deliver targeted offers, and Panera Bread is one of the first merchants who will roll out this new capability nationally. MyPanera members who save their loyalty card to Android Pay can discover offers and learn about new menu items, surfaced by Android Pay when they are at the store. The offer is redeemed when you use your MyPanera account at checkout.

Card Linked Offers for Panera Bread in the Android Pay app

We're also making it easier for Android Pay users to add loyalty programs. For example, Walgreens Balance Rewards® members who manually apply their loyalty account with a phone number and use Android Pay will receive a notification on their phone that easily enables them to link that loyalty card to Android Pay for future visits. This experience is powered by our smart tap technology, which Walgreens has fully deployed across their 8,000+ U.S. stores.

There's more—we're collaborating with Clover, a First Data company, to expand our smart tap technology beyond national retailers to businesses of all sizes. With the upcoming integration of smart tap in Clover's developer APIs, you'll be able to build Android apps for loyalty, coupon and gift card redemption and new features, such as order ahead and tap for pick up.

Visit developers.google.com/payments for the latest on all of our Google Payment, Loyalty and Offers APIs.