Posted by Michael Amygdalidis, Stephan Linzner and Nick Korostelev from the Mobile-Ninjas team at Google

We're pleased to announce the version 1.0 release of the Android Testing Support
Library (ATSL).

ATSL version 1.0 is a major update to our existing testing APIs and comes with
lots of new features, improved performance, stability, and bug fixes. It
provides full API parity with the now deprecated Android platform testing APIs.
This release also adds a number of features that we discussed in our Google I/O 2017 talk,
such as native support for Multiprocess
Espresso and the Android
Test Orchestrator.

We are also happy to announce that, starting with version 1.0, we're
distributing releases on Google's Maven repository, which makes it a lot easier
to use ATSL in your builds. To learn more about using this repository, see the
getting started with the Google Maven repository guide. Note that we're no
longer tying future updates to the testing infrastructure with platform updates.
If you have not yet upgraded your tests to ATSL, this is an excellent time.

Finally, we want to announce a big update to our Android testing documentation.
We've migrated our old testing documentation from our GitHub
website to developers.android.com/testing.
All the testing documentation now appears in a single place, making it even
easier to learn how to write and execute tests on Android.

Let's move on to the fun part of this post, an overview of new APIs and tools
that we're providing in this release.

Espresso
Improvements

Espresso 3.0.0 comes with amazing new features and improved
overall performance. Some of the highlights include: Multiprocess Espresso,
Idling Registry and new Idling Resources. Let's dive in and have a more detailed
look at these new features:

Multiprocess Espresso

Starting with Android
O, the platform includes support for instrumenting tests outside of your
app's default process. (Prior to Android O, you could only test against app
components in your app's default process.) Multiprocess Espresso makes this
support possible. It allows you to seamlessly test your app's UI interactions
that cross process boundaries while still maintaining Espresso's synchronization
guarantees.

The good news is that Espresso does all the work; you don't have to change
anything for setups with UI in multiple processes. You can keep writing your
Espresso tests like you would for single process apps, and Espresso
automatically handles the process IPC and synchronization between processes.

The following diagram shows how multiple instances of Espresso communicate with
each other:

Some apps use build flavors in Gradle or a dependency injection framework, like
Dagger, to generate test build configurations that register idling resources.
Others simply expose the idling resource through their activities. The problem
with all these approaches is that they add complexity to your development
workflow, and some of them even break encapsulation. With the latest release of
Espresso, we've made it easier to register idling resources from within your app
code by introducing the new IdlingRegistry API.
IdlingRegistry is a lightweight registry that doesn't bring in the
entire Espresso library, so you can more easily register resources from your
application code. When combining this API with Multiprocess Espresso, you can
register idling resources from any process within your application code.

Additionally, CountingIdlingResource,
which was previously deprecated in Espresso contrib, has been removed with this
release. Therefore, you need to update your tests to use the new CountingIdlingResource
package that's located in Espresso idling resource. For the full migration
details, refer to our release
notes.

ProviderTestRule

When you test ContentProvider
objects, you can now use ProviderTestRule
instead of ProviderTestCase2.
ProviderTestRule offers an easier way to work with other test rules
currently available for AndroidJUnit4.

ProviderTestRule
includes APIs for initialization, as well as commands to run against a ContentProvider
under test. If your ContentProvider is based off of a SQLite
database, you can use the ProviderTestRule commands for setting the
database file and initialization commands.

Grant Permission
Rule

Android M (API level 23) allows apps to request permissions at runtime. However,
the dialogs that request runtime permissions place tests in a state where they
cannot continue, causing them to fail. By using GrantPermissionRule,
you can skip the dialog popups altogether and simulate a user granting a runtime
permission for your app.

Android Test
Orchestrator

Typically, AndroidJUnitRunner runs all tests in the same instrumentation
process, which can cause a number of problems. For example, tests share their
state in memory, and if one test crashes, it prevents the remainder of the test
suite from running.

Although it's possible to isolate tests by issuing sequential adb
commands, this process adds host-side processing load. By using the new Android
Test Orchestrator instead, you can achieve test isolation entirely on the
device, as shown in this diagram:

Be aware that if your tests require shared state to pass, the
orchestrator causes them to fail. This behavior is by design. As of this post,
Android Test Orchestrator is in beta and is available for use via the command
line. We have integrations planned for Firebase Test Lab and Android Studio,
coming soon.

AndroidJUnitRunner

You can configure class loaders and custom JUnit test filters using the
runner arguments

Sometimes you want to test an activity that you create and configure on the fly
as part of your test workflow. Now, you can configure MonitoringInstrumentation
(and by extension, AndroidJUnitRunner)
using an InterceptingActivityFactory.
You can create your activity under test with a test-specific configuration
without having to rely on compile-time injection.

This overview highlights only some of the most significant changes that we've
made to ATSL. They are many more changes that are worth exploring. For the full
release details, refer to our release
notes.

Last but not least, we want to thank all the developers who contributed features
to this release. We also want to thank the Android testing experts on the mobile
engineering teams at American Express, Slack and GDE Chiu-Ki Chan for
collaborating with us and providing valuable feedback on the pre-release version
of Android Testing Support Library.

As we put the finishing touches on the Android O platform, today we're rolling
out Developer Preview 4 to help you make sure your apps are ready.

This is the final preview before we launch the official Android O platform to
consumers later
this summer. Take this opportunity to wrap up your testing and publish your
updates soon, to give users a smooth transition to Android O.

If you have a device that's enrolled in the Android Beta Program, you'll receive an
update to Developer Preview 4 in the next few days. If you haven't enrolled your
device yet, just visit the Android Beta
site to enroll and get the update.

Watch for more information on the official Android O release soon!

What's in this update?

Developer Preview 4 is a release candidate build of Android O that you can use
to complete your development and testing in time for the upcoming official
release. It includes the final system behaviors, the latest bug fixes and
optimizations, and the final APIs (API level 26) already available since Developer
Preview 3.

We're releasing the Developer Preview 4 device system images today, together
with the stable version of the Android 26.0.0 Support Library. Incremental
updates to the SDK, tools, and Android Emulator system images are on the way
over the next few days.

We're also introducing a new version of Android Testing Support Library
that includes new features like Android Test Orchestrator, Multiprocess
Espresso, and more. Watch for details coming soon.

Test your apps on Android O

Today's Developer Preview 4 system images give you an excellent way to test your
current apps on the near-final version of Android O. By testing now, you can
make sure your app offers the experience you want as users start to upgrade to
the official Android O platform.

Once you've resolved any issues, publish your app updates with the current
targeting level, so that they're available as users start to receive Android O.

Enhance your apps with Android O features and APIs

Users running the latest versions of Android are typically among the most active
in terms of downloading apps, consuming content, and making purchases. They're
also more vocal about support for the latest Android features in their favorite
apps. With Android O, users are anticipating features like notification
channels and dots,
shortcut
pinning, picture-in-picture,
autofill,
and others. These features could also help increase engagement with your app as
more users upgrade to Android O over time.

With Android O your app can directly pin a specific app shortcut in the launcher
to drive engagement.

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 setup your environment to build with Android O.

Publish your updates to Google Play

Google Play is open for apps compiled against or targeting API 26. When you're
ready, you can publish your APK updates in your alpha, beta, or production
channels.

Make sure that your updated app runs well on Android O as well as older
versions. We recommend using Google
Play's beta testing feature to get early feedback from a small
group of users. Then do a staged rollout. We're looking forward to seeing your
app updates!

How to get Developer Preview 4

It's simple to get Developer Preview 4 if you haven't already! Just visit android.com/beta and opt-in your eligible
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, Nexus Player, and the Android Emulator.
Enrolled devices will automatically update when we release the official version
of Android O.

Thanks for all of your input throughout the preview. Continue to share your feedback and
requests, we love it!

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:

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.

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.

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.

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.

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!

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.