Expanding support for hardware security

Android already supports Verified Boot,
which is designed to prevent devices from booting up with software that has been
tampered with. In Android Oreo, we added a reference implementation for Verified
Boot running with Project
Treble, called Android Verified Boot 2.0 (AVB). AVB has a couple of cool
features to make updates easier and more secure, such as a common footer format
and rollback protection. Rollback protection is designed to prevent a device to
boot if downgraded to an older OS version, which could be vulnerable to an
exploit. To do this, the devices save the OS version using either special
hardware or by having the Trusted Execution Environment (TEE) sign the data.
Pixel 2 and Pixel 2 XL come with this protection and we recommend all device
manufacturers add this feature to their new devices.

Oreo also includes the new OEM
Lock Hardware Abstraction Layer (HAL) that gives device manufacturers more
flexibility for how they protect whether a device is locked, unlocked, or
unlockable. For example, the new Pixel phones use this HAL to pass commands to
the bootloader. The bootloader analyzes these commands the next time the device
boots and determines if changes to the locks, which are securely stored in
Replay Protected Memory Block (RPMB), should happen. If your device is stolen,
these safeguards are designed to prevent your device from being reset and to
keep your data secure. This new HAL even supports moving the lock state to
dedicated hardware.

Speaking of hardware, we've invested support in tamper-resistant hardware, such
as the security
module found in every Pixel 2 and Pixel 2 XL. This physical chip prevents
many software and hardware attacks and is also resistant to physical penetration
attacks. The security module prevents deriving the encryption key without the
device's passcode and limits the rate of unlock attempts, which makes many
attacks infeasible due to time restrictions.

While the new Pixel devices have the special security module, all new GMS devices shipping with Android Oreo
are required to implement key
attestation. This provides a mechanism for strongly attesting
IDs such as hardware identifiers.

We added new features for enterprise-managed devices as well. In work profiles,
encryption keys are now ejected from RAM when the profile is off or when your
company's admin remotely locks the profile. This helps secure enterprise data at
rest.

Platform hardening and process isolation

As part of Project
Treble, the Android framework was re-architected to make updates easier and
less costly for device manufacturers. This separation of platform and
vendor-code was also designed to improve security. Following the principle of
least privilege, these HALs run in their own
sandbox and only have access to the drivers and permissions that are
absolutely necessary.

Continuing with the media
stack hardening in Android Nougat, most direct hardware access has been
removed from the media frameworks in Oreo resulting in better isolation.
Furthermore, we've enabled Control Flow Integrity (CFI) across all media
components. Most vulnerabilities today are exploited by subverting the normal
control flow of an application, instead changing them to perform arbitrary
malicious activities with all the privileges of the exploited application. CFI
is a robust security mechanism that disallows arbitrary changes to the original
control flow graph of a compiled binary, making it significantly harder to
perform such attacks.

In addition to these architecture changes and CFI, Android Oreo comes with a
feast of other tasty platform security enhancements:

Seccomp
filtering: makes some unused syscalls unavailable to apps so that
they can't be exploited by potentially harmful apps.

Hardened
usercopy: A recent survey
of security bugs on Android
revealed that invalid or missing bounds checking was seen in approximately 45%
of kernel vulnerabilities. We've backported a bounds checking feature to Android
kernels 3.18 and above, which makes exploitation harder while also helping
developers spot issues and fix bugs in their code.

Privileged Access Never (PAN) emulation: Also backported to
3.18 kernels and above, this feature prohibits the kernel from accessing user
space directly and ensures developers utilize the hardened functions to access
user space.

Kernel Address Space Layout Randomization (KASLR):
Although Android has supported userspace Address Space Layout Randomization
(ASLR) for years, we've backported KASLR to help mitigate vulnerabilities on
Android kernels 4.4 and newer. KASLR works by randomizing the location where
kernel code is loaded on each boot, making code reuse attacks probabilistic and
therefore more difficult to carry out, especially remotely.

App security and device identifier changes

Android
Instant Apps run in a restricted sandbox which limits permissions and
capabilities such as reading the on-device app list or transmitting cleartext
traffic. Although introduced during the Android Oreo release, Instant Apps
supports devices running Android Lollipop and
later.

In order to handle untrusted content more safely, we've isolated
WebView by splitting the rendering engine into a separate process and
running it within an isolated sandbox that restricts its resources. WebView also
supports Safe Browsing to protect
against potentially dangerous sites.

[Edit: Updated post on Dec 21 to clarify that when the
64-bit requirement is introduced in August 2019, 32-bit support is not going
away. Apps that include a 32-bit library just need to have a 64-bit version
too.]

Google Play powers billions of app installs and updates annually. We
relentlessly focus on security and performance to ensure everyone has a positive
experience discovering and installing apps and games they love. Today we're
giving Android developers a heads-up about three changes designed to support
these goals, as well as explaining the reasons for each change, and how they
will help make Android devices even more secure and performant for the long
term.

In the second half of 2018, Play will require that new apps and app updates
target a recent Android API level. This will be required for new apps in
August 2018, and for updates to existing apps in
November 2018. This is to ensure apps are built on the latest
APIs optimized for security and performance.

In August 2019, Play will require that new apps and app
updates with native libraries provide 64-bit versions in addition to their
32-bit versions.

Additionally, in early 2018, Play will start adding a small amount of
security metadata on top of each APK to further verify app authenticity. You do
not need to take any action for this change.

We deeply appreciate our developer ecosystem, and so hope this long advance
notice is helpful in planning your app releases. We will continue to provide
reminders and share developer resources as key dates approach to help you
prepare.

Target API level requirement from late 2018

API behavior changes advance the security and privacy protections of Android –
helping developers secure their apps and protecting people from malware. Here
are a few such changes from recent platform versions:

Many of these changes only apply to apps that explicitly declare their support
for new API behaviors, through the targetSdkVersion
manifest attribute. For example, only apps with a targetSdkVersion of 23
(the API level of Android 6.0) or higher give the user full control over what
private data – such as contacts or location – the app can access via runtime
permissions. Similarly, recent releases include user experience improvements
that prevent apps from accidentally overusing resources like battery and memory;
background
execution limits is a good example of this type of improvement.

In order to provide users with the best Android experience possible, the Google
Play Console will require that apps target a recent API level:

2019 onwards: Each year the targetSdkVersion requirement
will advance. Within one year following each Android dessert release, new apps
and app updates will need to target the corresponding API level or
higher.

Existing apps that are not receiving updates are unaffected. Developers remain
free to use a minSdkVersion
of their choice, so there is no change to your ability to build apps for older
Android versions. We encourage developers to provide backwards compatibility as
far as reasonably possible. Future Android versions will also restrict apps that
don't target a recent API level and adversely impact performance or security. We
want to proactively reduce fragmentation in the app ecosystem and ensure apps
are secure and performant while providing developers with a long window and
plenty of notice in order to plan ahead.

This year we released Android Oreo, the most secure and best performing version
of Android yet, and we introduced Project
Treble to help the latest releases reach devices faster. Get started
building apps that target Android 8.1 Oreo
today.

64-bit support requirement in 2019

Platform support for 64-bit architectures was introduced in Android 5.0. Today,
over 40% of Android devices coming online have 64-bit support, while still
maintaining 32-bit compatibility. For apps that use native libraries, 64-bit
code typically offers significantly better performance, with additional
registers and new instructions.

In anticipation of future Android devices that support 64-bit code only, the
Play Console will require that new apps and app updates with native libraries
provide 64-bit versions in addition to their 32-bit versions. This can be within
a single APK or as one of the multiple APKs published.

We are not removing 32-bit support. Google Play will continue to support 32-bit
apps and devices. Apps that do not include native code are unaffected.

This change will come into effect in August 2019. We're providing advance notice
today to allow plenty of time for developers who don't yet support 64-bit to
plan the transition. Stay tuned for a future post in which we'll take an
in-depth look at the performance benefits of 64-bit native libraries on Android,
and check out the CPUs and
Architectures guide of the NDK for more info.

Security metadata in early 2018

Next year we'll begin adding a small amount of security metadata on top of each
APK to verify that it was officially distributed by Google Play. Often when you
buy a physical product, you'll find an official label or a badge which signifies
the product's authenticity. The metadata we're adding to APKs is like a Play
badge of authenticity for your Android app.

No action is needed by developers or users. We'll adjust Play's maximum APK size
to take into account the small metadata addition, which is inserted into the APK Signing Block
and does not alter the functionality of your app. In addition to enhancing the
integrity of Play's mobile app ecosystem, this metadata will enable new
distribution opportunities for developers in the future and help more people
keep their apps up to date.

Looking ahead

2017 has been a fantastic year for developers who have seen growth and success
on Google Play. We've been hard at work on features (including those announced
at I/O
2017 and at Playtime)
to help you improve your app quality and business performance. With these
features and the upcoming updates, we hope to see the Android and Play ecosystem
continue to thrive in 2018 and beyond.

Today, we are excited to announce Quick Boot for the Android Emulator. With
Quick Boot, you can launch the Android Emulator in under 6 seconds. Quick Boot
works by snapshotting an emulator session so you can reload in seconds. Quick
Boot was first released with Android Studio 3.0 in the canary update channel and
we are excited to release the feature as a stable update today.

In addition to this new feature, we also wanted to highlight some of the top
features from recent releases. Since the complete revamp of the Android Emulator
two
years ago, we continue to focus on improving speed, stability and adding a
rich set of features that accelerate your app development and testing. With all
the recent changes, it is definitely worth updating to the latest version of the
Android Emulator to use it today.

Top 5 Features

Quick Boot - Released as a stable feature today, Quick Boot
allows you to resume your Android Emulator session in under 6 seconds. The first
time you start an Android Virtual Device (AVD) with the Android Emulator, it
must perform a cold boot (just like powering on a device), but subsequent starts
are fast and the system is restored to the state at which you closed the
emulator last (similar to waking a device). We accomplished this by completely
re-engineering the legacy emulator snapshot architecture to work with virtual
sensors and GPU acceleration. No additional setup is required because Quick Boot
is enabled by default starting with Android Emulator v27.0.2.

Quick Boot in the Android Emulator

Android CTS Compatibility -With each
release of the Android SDK, we ensure that the Android Emulator is ready for
your app development needs, from testing backwards compatibility with Android
KitKat to integrating the latest APIs of the developer preview. To increase
product quality and reliability of emulator system images, we now qualify final
Android System Image builds from Android Nougat (API 24) and higher against the
Android Compatibility Test
Suite (CTS)—the same testing suite that official Android physical devices
must pass.

Google Play Support -We know that many
app developers use Google Play Services, and it can be difficult to keep the
service up to date in the Android Emulator system images. To solve this problem,
we now offer versions of Android System Images that include the Play Store app.
The Google Play images are available starting with Android Nougat (API 24). With
these new emulator images, you can update Google Play Services via the Play
Store app in your emulator just as you would on a physical Android device. Plus,
you can now test end-to-end install, update, and purchase flows with the Google
Play Store.

Performance Improvements -Making the
emulator fast and performant is an on-going goal for our team. We continuously
look at the performance impact of running the emulator on your development
machine, especially RAM usage. With the latest versions of the Android Emulator,
we now allocate RAM on demand, instead of allocating and pinning the memory to
the max RAM size defined in your AVD. We do this by tapping into the native
hypervisors for Linux (KVM) and macOS® (Hypervisor.Framework), and an
enhanced Intel® HAXM (v6.2.1 and higher) for Microsoft®
Windows®, which uses the new on-demand memory allocation.

Additionally, over the last several releases, we have improved CPU and I/O
performance while enhancing GPU performance, including OpenGL ES 3.0 support.
Looking at a common task such as ADB push highlights the improvements in the
Android CPU and I/O pipelines:

ADB Push Speed Comparison with Android Emulator

For GPU performance, we created a sample GPU emulation stress
test app to gauge improvements over time. We found that the latest emulator
can render higher frame rates than before, and it is one of the few emulators
that can render OpenGL ES 3.0 accurately per the Android specification.

GPU Emulation Stress Test - Android App

GPU Emulation Stress Test with Android Emulator

More Features

In addition to these major features, there are a whole host of additional
features that we have added to the Android Emulator over the last year that you
may not be aware of:

Wi-Fi support - Starting with API 24 system images, you can
create an AVD that both connects to a virtual cellular network and a virtual
Wi-Fi Access Point.

Google Cast support - When using a Google Play system
image, you can cast screen and audio content to Chromecast devices on the same
Wi-Fi network.

Drag and drop APKs & files - Simply drag an APK onto the
Android Emulator window to trigger an app install. Also you can drag any other
data file and find it in the /Downloads folder in your Android Virtual Device.

Host copy & paste - You can copy & paste text between the
Android Emulator and your development machine.

All of these features and improvements are available to download and use now
with Android Emulator v27.0.2+, which you can get via the SDK Manager in Android
Studio. For a fast experience, we recommend creating and running the x86 version
of emulator system images, with the latest Android Emulator, Intel® HAXM (if
applicable) and graphics drivers installed.

We appreciate any feedback on things you like, issues or features you would like
to see. If you find a bug, issue, or have a feature request feel free to file
an issue. We are definitely not done, but we hope you are excited about the
improvements so far.

Creating robust connections between IoT devices can be difficult. WiFi and
Bluetooth are ubiquitous and work well in many scenarios, but suffer limitations
when power is constrained or large numbers of devices are required on a single
network. In response to this, new communications technologies have arisen to
address the power and scalability requirements for IoT.

Low-power Wireless Personal Area Network (LoWPAN) technologies are specifically
designed for peer-to-peer usage on constrained battery-powered devices. Devices
on the same LoWPAN can communicate with each other using familiar IP networking,
allowing developers to use standard application protocols like HTTP and CoAP.
The specific LoWPAN technology that we are most excited about is Thread: a secure,
fault-tolerant, low-power mesh-networking technology that is quickly becoming an
industry standard.

Today we are announcing API support for configuring and managing LoWPAN as a
part of Android Things Developer Preview 6.1, including first-class networking
support for Thread. By adding an 802.15.4 radio module to one of our developer
kits, Android Things devices can communicate directly with other peer
devices on a Thread network. These types of low-power connectivity solutions
enable Android Things devices to perform edge computing tasks,
aggregating data locally from nearby devices to make critical decisions without
a constant connection to cloud services. See the LoWPAN API guide
for more details on building apps to create and join local mesh networks.

To get started with DP6.1, use the Android Things Console to
download system images and flash existing devices. Then download the LoWPAN sample app to try it
out for yourself! LoWPAN isn't the only exciting thing happening in the latest
release. See the release
notes for the full set of fixes and updates included in DP6.1.

Developing for 3D is complicated. Whether you're using a native graphics API or
enlisting the help of your favorite game engine, there are thousands of graphics
commands that have to come together perfectly to produce beautiful 3D images on
your phone, desktop or VR headsets.

GAPID (Graphics API
Debugger) is a new tool that helps developers diagnose rendering and
performance issues with their applications. With GAPID, you can capture a trace
of your application and step through each graphics command one-by-one. This lets
you visualize how your final image is built and isolate problematic calls, so
you spend less time debugging through trial-and-error.

GAPID supports OpenGL ES on Android, and Vulkan on Android, Windows and Linux.

Debugging in action, one draw call at a time

GAPID not only enables you to diagnose issues with your rendering commands, but
also acts as a tool to run quick experiments and see immediately how these
changes would affect the presented frame.

Here are a few examples where GAPID can help you isolate and fix issues with
your application:

What's the GPU doing?

Why isn't my text appearing?!

Working with a graphics API can be frustrating when you get an unexpected
result, whether it's a blank screen, an upside-down triangle, or a missing mesh.
As an offline debugger, GAPID lets you take a trace of these applications, and
then inspect the calls afterwards. You can track down exactly which command
produced the incorrect result by looking at the framebuffer, and inspect the
state at that point to help you diagnose the issue.

What happens if I do X?

Using GAPID to edit shader code

Even when a program is working as expected, sometimes you want to experiment.
GAPID allows you to modify API calls and shaders at will, so you can test things
like:

What if I used a different texture on this object?

What if I changed the calculation of bloom in this shader?

With GAPID, you can now iterate on the look and feel of your app without having
to recompile your application or rebuild your assets.

Whether you're building a stunning new desktop game with Vulkan or a beautifully
immersive VR experience on Android, we hope that GAPID will save you both time
and frustration and help you get the most out of your GPU. To get started with
GAPID and see just how powerful it is, download it, take your
favorite application, and capture a
trace!

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.

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.

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.

In recent months, there's a growing trend for handset makers to ship new devices
with long screen aspect ratio (stretching beyond 16:9), many of which also sport
rounded corners. This attests to the Android ecosystem's breadth and choice.
Pixel 2 XL and Huawei Mate 10 Pro are just two of many examples. These screen
characteristics could bring a very immersive experience to users and they take
notice of apps and games that don't take advantage of the long aspect ratio
screen on these new devices. Therefore it is important for developers to
optimize for these screen designs. Let's have a look at related support
provided by the Android OS.

Optimize for long aspect ratio screens

Most apps using standard UI widgets will likely work out-of-the-box on these devices. Android
documentation details techniques for flexibly working on multiple screen
sizes. However, some games and apps with custom UIs may run into issues due to
incorrect assumptions on certain aspect ratios. We're sharing a few typical
issues faced by developers, so you can pay attention to those relevant to you:

Certain sides of the screen are cropped. This makes any
graphic or UI elements in the affected regions look incomplete.

Touch targets are offset from UI elements (e.g. buttons).
Users may be confused on UI elements that are seemingly interactive.

For full screen mode on rounded corners devices, any UI elements
very close to the corners may be outside of the curved corner viewable
area. Imagine if a commerce app's "Purchase" button was partially
obstructed? We recommend referencing Material
Design guidelines by leaving 16dp side margins in layouts.

If responsive UI is really not suitable for your situation, as a last
resort declare an explicit maximum supported aspect ratio as follows. On
devices with a wider aspect ratio, the app will be shown in a compatibility mode
padded with letterbox. Keep in mind that certain device models provide an
override for users to force the app into full-screen compatibility mode, so be
sure to test under these scenarios too!

Targets API level 25 or lower: Use android.max_aspect meta-data.
Note that maximum aspect ratio values will be respected only if your
activities don't support resizableActivity. See documentation
for detail.

System letterboxes an app when the declared maximum aspect ratio is smaller
than the device's screen.

Consider using side-by-side activities

Long aspect ratio devices enable even more multi-window use cases that could
increase user productivity. Beginning in Android 7.0, the platform offers a
standard way for developers to implement multi-window on supported devices as
well as perform data drag and drop between activities. Refer to documentation
for details.

Testing is crucial. If you don't have access to one of these long screen
devices, be sure to test on the emulator with adequate screen size and
resolution hardware properties, which are explained in the emulator
documentation.

We know you want to delight your users with long screen devices. With a few
steps, you can ensure your apps and games taking full advantage of these
devices!