Tag Archives: AndroidO

Double Stuffed Security in Android Oreo

Posted by Gian G Spicuzza, Android Security team

Android Oreo is stuffed full of security enhancements. Over the past few months, we've covered how we've improved the security of the Android platform and its applications: from making it safer to get apps, dropping insecure network protocols, providing more user control over identifiers, hardening the kernel, making Android easier to update, all the way to doubling the Android Security Rewards payouts. Now that Oreo is out the door, let's take a look at all the goodness inside.

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.

Lastly, we've made significant changes to device identifiers to give users more control, including:

  • Moving the static Android ID and Widevine values to an app-specific value, which helps limit the use of device-scoped non-resettable IDs.
  • In accordance with IETF RFC 7844 anonymity profile, net.hostname is now empty and the DHCP client no longer sends a hostname.
  • For apps that require a device ID, we've built a Build.getSerial() API and protected it behind a permission.
  • Alongside security researchers1, we designed a robust MAC address randomization for Wi-Fi scan traffic in various chipsets firmware.

Android Oreo brings in all of these improvements, and many more. As always, we appreciate feedback and welcome suggestions for how we can improve Android. Contact us at [email protected].

_____________________________________________________________________

1: Glenn Wilkinson and team at Sensepost, UK, Célestin Matte, Mathieu Cunche: University of Lyon, INSA-Lyon, CITI Lab, Inria Privatics, Mathy Vanhoef, KU Leuven

Android 8.1 Developer Preview

Posted by Dave Burke, VP of Engineering

Today we're giving you an early look at Android 8.1. This update to Android Oreo includes a set of targeted enhancements including optimizations for Android Go (for devices with 1GB or less of memory) and a new Neural Networks API to accelerate on-device machine intelligence. We've also included a few smaller enhancements to Oreo in response to user and developer feedback.

We're bringing you this Developer Preview so you can get your apps ready; we've already been helping device makers prepare for this new version. We recommend starting soon -- we're expecting the final public version in December.

It's easy to get Android 8.1 Developer Preview on your Pixel or Nexus device. Just enroll in the Android Beta Program -- you'll soon receive an over-the-air update to Android 8.1 beta. If you enrolled previously, you're all set, there's no need to re-enroll. The Developer Preview will be available for Pixel 2 and Pixel 2 XL devices, as well as for Pixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P, and the Android emulator.

What's in Android 8.1?

Android 8.1 includes select new features and developer APIs (API level 27), along with the latest optimizations, bug fixes, and security patches. Some of the new APIs include:

  • Android Go memory optimizations and targeting -- Android 8.1 includes a set of memory optimizations for Android Go configurations (1GB or less of memory). We've added new hardware feature constants so you can now target the distribution of your apps and APK splits to normal or low-RAM devices running Android 8.1 and later.
  • Neural Networks API -- as part of our efforts to bring machine intelligence to Android, we've added a Neural Networks API via the NDK. It enables hardware-accelerated inference operations on supported devices. We designed the Neural Networks API as a foundational layer for ML frameworks like TensorFlow Lite -- Google's upcoming cross-platform ML framework for mobile -- as well as Caffe2 and others. Stay tuned for TensorFlow Lite announcements.
  • Autofill enhancements -- we've made it easier for password managers and other Autofill services to use the Autofill framework. For example, we've added support for more UI customization of the Save dialog, as well as setAutofillOptions() for users to set credit card expiration using a spinner.
  • Shared memory API -- this new API lets apps allocate shared memory for faster access to common data. Apps can map anonymous shared memory and manage protection controls using the SharedMemory API. The API is parcelable, AIDL friendly, and exposes useful features like removing write permissions.

Take a look at Android 8.1 site for more information, including the diff report and updated API reference docs.

Test your apps on Android 8.1

With the consumer launch coming in December, it's important to test your current app now. This gives users a seamless transition to Android 8.1 when it arrives on their devices.

Just enroll your eligible device in Android Beta to get the latest update, then install your app from Google Play and test. If you don't have a Pixel or Nexus device, you can set up an Android 8.1 emulator for testing instead. If you notice any issues, fix them and update your app in Google Play right away -- without changing the app's platform targeting.

Build with new features and APIs

When you're ready, take advantage of the new features and APIs in Android 8.1, which we've already finalized as API Level 27. For an overview of what's new, take a look at Android 8.1 for Developers. You can also extend your apps with established Android Oreo features as well, see the Android Oreo site for details.

If your app uses forms, make sure to test them with autofill so that users can take advantage of this convenient feature. Enable "Autofill with Google" or a similar service in Settings and test the form fills to make sure they work as expected. We strongly recommend providing explicit hints about your fields, and also associating your website and mobile app, so that logins can be shared between them.

If your app uses the Camera2 API and you have a Pixel 2 device, you can try an early version of Pixel Visual Core, Google's first custom-designed co-processor for image processing and machine learning on consumer products. To begin testing HDR+ through Pixel Visual Core, just enable the new developer option "Camera HAL HDR+" (and make sure that CONTROL_ENABLE_ZSL is "true").

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 with Android Oreo features like Instant Apps, XML Fonts, downloadable fonts, and adaptive icons.

We also recommend updating to the Android Support Library 27.0.0, which is available from Google's Maven repository. New in this version are: a ContentPager library for efficiently loading "paged" data on a background thread; ViewCompat wrappers for Autofill methods; an AmbientMode headless fragment that improves Wear ambient mode support, fullscreen Trusted Web Activities, and more. See the version notes for more information.

You can update your project's compileSdkVersion to API 27 to compile against the official Android 8.1 APIs. We also recommend updating your app's targetSdkVersion to API 27 to test with compatibility behaviors disabled. See the this guide for details on how to set up your environment to build with Android 8.1.

Publish your updates to Google Play

The Android 8.1 APIs are already final, so we've opened Google Play for apps compiled against or targeting API level 27. 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 8.1 as well as older versions. We recommend using Google Play's beta testing feature to run an alpha test on small group of users, then run a much larger open beta test. When you're ready to launch your update, you can use a staged rollout. We're looking forward to seeing your app updates!

Give us your feedback!

As always, your feedback is crucial, so please let us know what you think. We've set up different hotlists where you report Android platform and tools issues, app compatibility issues, and third-party SDKs and tools issues. We also have a new hotlist for Neural Networks API issues.

You can also give us feedback through the Android Developer community or Android Beta community as we work towards the consumer release in December.

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.

Introducing Android 8.0 Oreo

Posted By: Dave Burke, VP of Engineering

After more than a year of development and months of testing by developers and early adopters (thank you!), we're now ready to officially launch Android 8.0 Oreo to the world. Android 8.0 brings a ton of great features such as picture-in-picture, autofill, integrated Instant Apps, Google Play Protect, faster boot time, and much more.

We're pushing the sources to Android Open Source Project (AOSP) for everyone to access today. Pixel and Nexus 5X/6P builds have entered carrier testing and we expect to start rolling out in phases over the next several weeks, alongside Pixel C and Nexus Player. Android Beta users will receive the update to the final version today and images are available to download and flash manually. We've been working closely with our partners over the last many months, and by the end of this year, hardware makers like Essential, Huawei, HTC, Kyocera, Motorola, HMD Global Home of Nokia Phones, Samsung, Sharp and Sony are scheduled to be launching or upgrading new devices to Android 8.0 Oreo.

What's in Android Oreo?

In Android 8.0 Oreo we focused on creating fluid experiences that make Android even more powerful and easy to use, such as:

  • Picture-in-picture lets users manage two tasks simultaneously on any size screen, and it's easy for apps to support it. (Shown at right)
  • Notification dots extend the reach of notifications and offer a new way to surface activity in your apps. Dots work with zero effort for most apps -- we even extract the color of the dot from your icon.
  • Autofill framework simplifies how users set up a new device and synchronize their passwords. Apps using form data can optimize their apps for Autofill, and password manager apps can use the new APIs to make their services available to users in their favorite apps. Autofill will roll out fully over the next few weeks as part of an update to Google Play Services.

We also invested in Android Vitals, a project focused on optimizing battery life, startup time, graphics rendering, and stability, while giving developers better visibility over the health of their apps:

  • System optimizations: We worked across the system to help apps run faster and smoother -- for example, in the runtime we added a new concurrent compacting garbage collection, code locality, and more.
  • Background limits: We added new limits on background location and wi-fi scans and changes in the way apps run in the background. These boundaries prevent unintentional overuse of battery and memory and apply to all apps -- make sure you understand and account for these in your apps.
  • Complementary Android Vitals dashboards and IDE profilers: In the Play Console you can now see aggregate data about your app to help you pinpoint common issues - excessive crash rate, ANR rate, frozen frames, slow rendering, excessive wakeups, and more. You'll also find new performance profilers in Android Studio 3.0, and new instrumentation in the platform.

In Android 8.0 your app can directly pin a specific app shortcut in the launcher to drive engagement (left). Notification dots keep users active in your app and let them jump directly to the app's core functions (right).

For developers, Android Oreo includes many new capabilities to help you build better, more efficient apps. Here are just a few:

  • Autosizing textview: Use autosizing TextView to automatically fill a TextView with text, regardless of the amount. You can create an array of preset text sizes, or set min and max sizes with a step granularity, and the text will grow and shrink to fill the available TextView space.
  • Fonts in XML: Fonts are now a fully supported resource type. You can now use fonts in XML layouts and define font families in XML.
  • Downloadable fonts and emoji: With downloadable fonts you can load fonts from a shared provider instead of including them in your APK. The provider and support library manage the download of fonts and shares them across apps. The same implementation also supports downloadable emoji, so you can get updated emoji without being limited to the emoji built into the device.
  • Adaptive icons: You can now create adaptive icons that the system displays in different shapes, based on a mask selected by a device manufacturer. The system also animates interactions with the icons, and uses them in the launcher, shortcuts, settings, sharing dialogs, and in the overview screen.

Adaptive icons display in a variety of shapes across different device models.
  • Shortcut pinning: App shortcuts and homescreen widgets are great for engaging users and now you can let users add and pin shortcuts and widgets to the launcher from within your app. There's also a new option to add a specialized activity to help users create shortcuts. The activity is complete with custom options and confirmation.
  • Wide-gamut color for apps: Imaging apps can now take full advantage of new devices that have a wide-gamut color capable display. To display wide gamut images, apps enable a flag in their manifest files (per activity) and load bitmaps with an embedded wide color profile (AdobeRGB, Pro Photo RGB, DCI-P3, etc.).
  • WebView enhancements: In Android Oreo, we've enabled WebView multiprocess mode by default and added an API to let your app handle errors and crashes. You can also opt in your app's WebView objects to verify URLs through Google Safe Browsing.
  • Java 8 Language APIs and runtime optimizations: Android now supports several new Java Language APIs, including the new java.time API. In addition, the Android Runtime is faster than ever before, with improvements of up to 2x on some application benchmarks.

Learn more about these and other new features by visiting the Android 8.0 Oreo site on developer.android.com. Also check out the What's New in Android Oreo? video for an overview of new features for developers.

Make sure your apps are ready

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 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.

Once you've resolved any issues, publish your app updates to Google Play in your alpha, beta, or production channels so that they're available as users start to receive Android 8.0 Oreo.

Speed your development with Android Studio

When you're ready to build with new APIs in Android Oreo, we recommend updating to the latest version of Android Studio 3.0, available for download from the beta channel. Aside from improved app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 makes it easier to develop with Instant Apps, XML Fonts, downloadable fonts, and adaptive icons.

Android Studio 3.0 includes tools for developing with Android Oreo features, such as previewing XML font resources in your app.

We also recommend updating to the Android Support Library 26.0.2, available now from Google's Maven repository, and to the latest SDK, tools, and emulator system images, available in the SDK Manager.

If you're just getting started building for Android Oreo, read the migration guide first. It gives you an overview of the process and the configuration changes you'll need to make.

To compile against the official Android 8.0 APIs, update your project's compileSdkVersion to API 26. We also recommend updating your app's targetSdkVersion to API 26 to opt-in and test your app with Android Oreo specific behavior changes. See the migration guide for details on how to set up your environment to build with Android Oreo.

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 Oreo 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!

What's next for Android Oreo?

We'll soon be closing the Developer Preview issue tracker, but please keep the feedback coming! You can file a new issue against Android 8.0 in the AOSP issue tracker.

Thanks again to the many developers and early adopters who participated in the Android O Developer Preview and public beta. You gave us great feedback, and filed hundreds of issues that helped us to make the Android Oreo platform great for consumers and developers.

Android Things Developer Preview 5

Posted by Wayne Piekarski, Developer Advocate for IoT

Today, we're releasing Developer Preview 5 (DP5) of Android Things, which includes the major change of being based on the upcoming Android O release. Android Things is Google's platform to enable Android Developers to create Internet of Things (IoT) devices, and seamlessly scale from prototype to production.

Android O

Android O is currently under Developer Preview for phones and tablets, and DP5 is now based on this upcoming release (previous releases were based on Android N). This means that your future Android Things applications should target API 26 to work correctly on the platform with our support libraries.

Hardware Changes

DP5 now adds support for the new NXP SprIoT i.MX6UL design, as listed in our developer kits documentation. With Intel discontinuing the Edison and Joule hardware designs, these platforms are moving to legacy support. They will not continue to receive the latest platform updates, but developers may continue to access the DP4.1 system images from the Android Things Console.

An important goal of Android Things is to help developers seamlessly scale from prototype to production. When we exit Developer Preview, we will differentiate between hardware platforms targeted for prototyping-only and hardware reference designs that can scale to production. Production-ready hardware will satisfy Google's security requirements and include long term support from the silicon manufacturers. We will have more to share later on.

Improvements

With the move to the Android O codebase, there are new API features from Android as well as specific features for Android Things. For those developers using UserDriver APIs, you will need to add new permissions to your AndroidManifest.xml. The documentation contains details about the permissions needed for each driver type. DP5 also now supports OpenGL ES 2.0 and WebView on the Raspberry Pi 3, which was a highly requested feature from developers. We have also implemented dynamic pin muxing for the Raspberry Pi 3, with pins being configured at runtime depending on what features are being used.

Android Studio

The samples for Android Things are now available directly in Android Studio for browsing and importing. You can now go to File, New, Import Samples, and search for Things to see everything that is available. We have a wide range of samples, demonstrating how to interact with buttons, sensors, LEDs, and displays, as well as implementing Google Assistant and TensorFlow.

Android Things Console

We recently launched the Android Things Console, which provides the ability to support over-the-air updates (OTA) to Android Things devices. We have recently made a number of UX improvements to the console to improve usability and functionality. DP5 is now available within the Android Things Console, but the DP5 update will not be pushed automatically to devices without your intervention. You will need to update your application for DP5, then create a new update and push it via the console yourself.

Feedback

With Android Things being updated to Android O, significant changes have been made to the platform. Please send us your feedback by filing bug reports and feature requests, and asking any questions on Stack Overflow. To start using DP5, use the Android Things Console to download system images and update existing devices. More information about the changes are available in the release notes. You can also join Google's IoT Developers Community on Google+, a great resource to get updates and discuss ideas. Also, we have our new hackster.io community, where everyone can share the amazing projects they have built!

Developer Preview 4 now available, official Android O coming soon!

Posted by Dave Burke, VP of Engineering

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.

Just enroll a supported device in the Android Beta Program to get today's update over-the-air, install your current app from Google Play, and test the user flows. The app should run and look great, and should handle the Android O behavior changes properly -- in particular, pay attention to background location limits, notification channels, and changes in networking, security, and identifiers.

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.
Notification dots keep users active in your app and let them jump directly the app's core functions.

Enhancing your apps with Android O features can help you drive engagement with users, offer new interactions, give them more control and security, and improve performance. Features like adaptive icons, downloadable fonts, and autosizing TextView can simplify your development and minimize your APK size. Battery is also a top concern for users, so they'll appreciate your app being optimized 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.

Speed your development with Android Studio

When you're ready to build for Android O, we recommend updating to the latest version of Android Studio 3.0, available for download from the canary channel. Aside from improved app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 makes it easier to develop with Instant Apps, XML Fonts, Downloadable Fonts, and Adaptive Icons.

We also recommend updating to the stable version of the Android Support Library 26.0.0, available now from Google's Maven repository, and to the latest SDK, tools, and emulator system images, available over the next few days.

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!

Seccomp filter in Android O

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.

What’s new in WebView security

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:

  1. 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.
  2. 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.

Android O APIs are final, get your apps ready!

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!