Welcoming Android 8.1 Oreo and Android Oreo (Go edition)

Posted by Dave Burke, VP of Engineering

At Google
for India
this Monday, we announced the final release of Android 8.1 Oreo.
Android 8.1 Oreo is another exciting step toward bringing to life our vision of
an AI-first mobile platform, for everyone, everywhere.

Android 8.1 introduces support for our new Android Oreo (Go edition) software experience for entry-level
devices. Android Oreo (Go edition) brings the best of Android to the rapidly
growing market for low-memory devices around the world, including your apps and
games.

Android 8.1 also introduces the Neural
Networks API
, a hardware accelerated machine learning runtime to
support ML capabilities in your apps. On supported devices, the Neural Networks
API enables fast and efficient inference for a range of key use cases, starting
with vision-based object classification.

You can get started with Android 8.1 Oreo (API level 27) today. We’re pushing
sources to Android Open Source Project
now, and rolling out the update to supported Pixel and Nexus devices over the
next week. We’re also working with our device maker partners to bring Android
8.1 to more devices, including Android Oreo (Go edition) devices, in the months
ahead.

Android Oreo (Go edition)

As announced at
Google I/O 2017, the “Android Go” project is our initiative to optimize the
Android experience for billions of people coming online around the world.
Starting with Android 8.1, we’re making Android a great platform for entry-level
devices in the Android Oreo (Go edition) configuration:

  • Memory optimizations — Improved memory usage across the
    platform to ensure that apps can run efficiently on devices with 1GB or less
    RAM.
  • Flexible targeting options — New hardware
    feature constants
    to let you target the distribution of your apps to normal
    or low-RAM devices through Google Play.
  • Optimized Google apps: Rebuilt and optimized versions of
    Google apps, using less memory, storage space, and mobile data.
  • Google Play: While all apps will be available on Android
    Oreo (Go edition) devices, Google Play will give visibility to apps specifically
    optimized by developers to provide a great experience for billions of people
    with the building
    for billions guidelines
    .

We’ve updated the building for billions guidelines with
additional guidance on how
to optimize your app for Android Oreo (Go edition) devices
. For most
developers, optimizing your existing APK or using Google Play’s Multiple
APK feature
to target a version of your APK to low-RAM devices is the best
way to prepare for Android Oreo (Go edition) devices. Remember that making
your app lighter
and more efficient benefits your whole audience, regardless
of device.

Neural Networks API

The Neural
Networks API
provides accelerated computation and inference for on-device
machine learning frameworks like TensorFlow Lite — Google’s
cross-platform ML library for mobile — as well as Caffe2 and others. TensorFlow
Lite is now
available to developers
, so visit the TensorFlow
Lite open source repo
for downloads and docs. TensorFlow Lite works with the
Neural Networks API to run models like MobileNets,
Inception v3, and Smart
Reply
efficiently on your mobile device.

Autofill enhancements and more

Android 8.1 includes select new
features and developer APIs
(API level 27), along with the latest
optimizations, bug fixes, and security patches. Extend your app with Autofill
enhancements, a SharedMemory
API, and more. You can also add established Android Oreo features as well, see
the Android
Oreo site
for details.

Test your apps on Android 8.1

If haven’t already, take a few moments today to test your apps and make sure
they offer the experience you want for users upgrading to Android 8.1 Oreo.

Just install your current app from Google Play onto a device or emulator
running Android Oreo and test the user flows. The app should run and look great,
and handle the Android Oreo behavior
changes
properly. In particular, pay attention to background
location limits
, notification
channels
, and changes in networking,
security,
and identifiers.

Speed your development with Android Studio

To build with Android 8.1, we recommend updating to Android
Studio 3.0
, which is now available from the stable
channel
. On top of the new app performance
profiling tools
, support for the Kotlin
programming language
, and Gradle build optimizations, Android Studio 3.0
makes it easier to develop for Android Oreo features like Instant
Apps
, XML
Fonts
, downloadable
fonts
, and adaptive
icons
.

With the final platform we’re updating the SDK and build tools in Android
Studio, as well as the API Level 27 emulator system images. We recommend
updating to the Android
Support Library 27.0.2
, which is available from Google’s
Maven repository
. See the version
notes
for details on what’s new.

As always, we’re providing downloadable factory and OTA images on the Nexus
Images
page to help you do final testing on your Pixel and Nexus devices.

Publish your updates to Google Play

When you’re ready, you can publish your APK updates targeting API level 27 in
your alpha, beta, or production channels. Make sure that your updated app runs
well on Android Oreo as well as older versions. We recommend using beta
testing
to get early feedback from a small group of users and a pre-launch
report
to help you identify any issues, then do a staged
rollout
. Head over to the Android Developers site to find more info on launch
best practices
. We’re looking forward to seeing your app updates!

What’s next for Android Oreo?

We’ll soon be closing the Developer Preview issue tracker, but please keep the
feedback coming! If you still see an issue that you filed in the preview
tracker, just file
a new issue
against Android 8.1 in the AOSP issue tracker. You can also
continue to give us feedback or ask questions in the developer
community
.

Hardening the Kernel in Android Oreo

Posted by Sami Tolvanen, Senior Software Engineer, Android Security

The hardening of Android’s userspace has increasingly made the underlying Linux
kernel a more attractive target to attackers. As a result, more than a third of
Android security bugs were found in the kernel last year. In Android 8.0 (Oreo),
significant effort has gone into hardening the kernel to reduce the number and
impact of security bugs.

Android
Nougat
worked to protect the kernel by isolating it from userspace processes
with the addition of SELinux ioctl filtering and requiring seccomp-bpf support,
which allows apps to filter access to available system calls when processing
untrusted input. Android 8.0 focuses on kernel self-protection with four
security-hardening features backported from upstream Linux to all Android
kernels supported in devices that first ship with this release.

Hardened usercopy

Usercopy functions are used by the kernel to transfer data from user space to
kernel space memory and back again. Since 2014, missing or invalid bounds
checking has caused about 45% of Android’s kernel vulnerabilities. Hardened usercopy adds bounds
checking to usercopy functions, which helps developers spot misuse and fix bugs
in their code. Also, if obscure driver bugs slip through, hardening these
functions prevents the exploitation of such bugs.

This feature was
introduced
in the upstream kernel version 4.8, and we have backported it to
Android kernels 3.18 and above.

int buggy_driver_function(void __user *src, size_t size)
{
    /* potential size_t overflow (don’t do this) */
    u8 *buf = kmalloc(size * N, GPF_KERNEL);
    …
    /* results in buf smaller than size, and a heap overflow */
    if (copy_from_user(buf, src, size))
    return -EFAULT;

    /* never reached with CONFIG_HARDENED_USERCOPY=y */
}

An example of a security issue that hardened usercopy prevents.

Privileged Access Never (PAN) emulation

While hardened usercopy functions help find and mitigate security issues, they
can only help if developers actually use them. Currently, all kernel code,
including drivers, can access user space memory directly, which can lead to
various security issues.

To mitigate this, CPU vendors have introduced features such as Supervisor Mode
Access Prevention (SMAP) in x86 and Privileged Access Never (PAN) in ARM v8.1.
These features prevent the kernel from accessing user space directly and ensure
developers go through usercopy functions. Unfortunately, these hardware features
are not yet widely available in devices that most Android users have today.

Upstream Linux introduced software emulation for PAN in kernel version 4.3
for ARM
and 4.10 in ARM64. We
have backported both features to Android kernels starting from 3.18.

Together with hardened usercopy, PAN emulation has helped find and fix bugs in
four kernel drivers in Pixel devices.

int buggy_driver_copy_data(struct mydata *src, void __user *ptr)
{
    /* failure to keep track of user space pointers */
    struct mydata *dst = (struct mydata *)ptr;
    …
    /* read/write from/to an arbitrary user space memory location */
    dst->field = … ;    /* use copy_(from|to)_user instead! */
    …
    /* never reached with PAN (emulation) or SMAP */
}

An example of a security issue that PAN emulation mitigates.

Kernel Address Space Layout Randomization (KASLR)

Android has included support for Address Space Layout Randomization (ASLR) for
years. Randomizing memory layout makes code reuse attacks probabilistic and
therefore more difficult for an attacker to exploit, especially remotely.
Android 8.0 brings this feature to the kernel. While Linux has supported KASLR on x86 since version 3.14, KASLR for ARM64 has only been
available upstream since Linux 4.6. Android 8.0 makes KASLR available in Android
kernels 4.4 and newer.

KASLR helps mitigate kernel vulnerabilities by randomizing the location where
kernel code is loaded on each boot. On ARM64, for example, it adds 13–25 bits of
entropy depending on the memory configuration of the device, which makes code
reuse attacks more difficult.

Post-init read-only memory

The final hardening feature extends existing memory protections in the kernel by
creating a memory region that’s marked read-only after the kernel has been
initialized. This makes it possible for developers to improve protection on data
that needs to be writable during initialization, but shouldn’t be modified after
that. Having less writable memory reduces the internal attack surface of the
kernel, making exploitation harder.

Post-init read-only memory was
introduced in upstream kernel version 4.6 and we have backported it to Android
kernels 3.18 and newer. While we have applied these protections to some data
structures in the core kernel, this feature is extremely useful for developers
working on kernel drivers.

Conclusion

Android Oreo includes mitigations for the most common source of security bugs in
the kernel. This is especially relevant because 85% of kernel security bugs in
Android have been in vendor drivers that tend to get much less scrutiny. These
updates make it easier for driver developers to discover common bugs during
development, stopping them before they can reach end user devices.

Making it safer to get apps on Android O

Posted by Edward Cunningham. Product Manager, Android Security

Eagle-eyed users of Android O will have noticed the absence of the ‘Allow
unknown sources’ setting, which has existed since the earliest days of Android
to facilitate the installation of apps from outside of Google Play and other
preloaded stores. In this post we’ll talk about the new Install unknown
apps
permission and the security benefits it brings for both Android
users and developers.

Earlier this year we introduced Google Play
Protect
– comprehensive security services that are always at work to protect
your device from harm. Google Play continues to be one of the safest places for
Android users to download their apps, with the majority of Potentially Harmful
Apps (PHAs) originating from third-party sources.

A common strategy employed by PHA authors is to deliver their apps via a hostile
downloader. For example, a gaming app might not contain malicious code but
instead might notify the user to install a PHA that masquerades as an important
security update. (You can read more about hostile downloaders in the Android
Security 2016 Year in Review
). Users who have enabled the installation of
apps from unknown sources leave themselves vulnerable to this deceptive
behavior.

Left (pre-Android O): The install screen for a PHA masquerading as a system
update.
Right (Android O): Before the PHA is installed, the user must first grant
permission to the app that triggered the install.

In Android O, the Install unknown apps permission makes it
safer to install apps from unknown sources. This permission is tied to the app
that prompts the install— just like other runtime permissions—and ensures that
the user grants permission to use the install source before it can prompt the
user to install an app. When used on a device running Android O and higher,
hostile downloaders cannot trick the user into installing an app without having
first been given the go-ahead.

This new permission provides users with transparency, control, and a streamlined
process to enable installs from trusted sources. The Settings app shows the list
of apps that the user has approved for installing unknown apps. Users can
revoke the permission for a particular app at any time.

At any time, users can review the apps that they’ve allowed for installing
unknown apps. To make the permission-granting process easier, app developers can
choose to direct users to their permission screen as part of the setup
flow.

Developer changes

To take advantage of this new behavior, developers of apps that require the
ability to download and install other apps via the Package Installer may need to
make some changes. If an app uses a targetSdkLevel of 26 or above
and prompts the user to install other apps, the manifest file needs to include
the REQUEST_INSTALL_PACKAGES
permission:

<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />

Apps that haven’t declared this permission cannot install other apps, a handy
security protection for apps that have no intention of doing so. You can choose
to pre-emptively direct your users to the Install unknown apps
permission screen using the ACTION_MANAGE_UNKNOWN_APP_SOURCES
Intent action. You can also query the state of this permission using the
PackageManager canRequestPackageInstalls()
API.

Remember that Play policies
still apply to apps distributed on Google Play if those apps can install and
update other apps. In the majority of cases, such behavior is inappropriate; you
should instead provide a deep
link
to the app’s listing on the Play Store.

Be sure to check out the updated publishing
guide
that provides more information about installing unknown apps, and stay
tuned for more posts on security hardening in Android O.