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.
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:
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
targetSdkLevel
REQUEST_INSTALL_PACKAGES
<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.
ACTION_MANAGE_UNKNOWN_APP_SOURCES
canRequestPackageInstalls()
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.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
