Category : android p

Posted by Dave Burke, VP of Engineering

Android P logo

Today we’re rolling out Beta 3 of Android P, our next milestone in this year’s Android P developer preview. With the developer APIs already finalized in the previous update, Beta 3 now takes us very close to what you’ll see in the final version of Android P, due later this summer.

Android P Beta 3 includes the latest bug fixes and optimizations for stability and polish, together with the July 2018 security updates. It’s a great way to test your apps now to make sure they are ready before the final release. Give Beta 3 a try and let us know what you think!

You can get Android P Beta 3 on Pixel devices by enrolling here. If you’re already enrolled and received the Android P Beta 2 on your Pixel device, you’ll automatically get the update to Beta 3. Partners who are participating in the Android P Beta program will also be updating their devices to Beta 3 over the coming weeks.

What’s in this update?

Today’s preview update includes the Beta 3 system images for Pixel devices and the Android Emulator, as well as an update to the Android Studio build tools to include D8 as an independent tool. Beta 3 is an early release candidate build of Android with near-final system behaviors and the official Android P APIs (API level 28).

With the Beta 3 system images and updated build tools, you’ve got everything you need to test your apps or extend them with Android P features like multi-camera support, display cutout, enhanced notifications, ImageDecoder, TextClassifier, and many others. In your testing, make sure to account for App standby buckets, privacy restrictions, and restrictions on non-SDK interfaces.

Get started in a few simple steps

Android P preview

First, make your app compatible and give your users a seamless transition to Android P. Just install your current app from Google Play on an Android P Beta device or emulator and test — the app should run and look great, and handle the Android P behavior changes properly. After you’ve made any necessary updates, we recommend publishing to Google Play right away without changing the app’s platform targeting.

If you don’t have a supported device, remember that you can instead set up an Android Virtual Device on the Android Emulator for your test environment. If you haven’t tried the emulator recently, you’ll find that it’s incredibly fast, boots in under 6 seconds, and even lets you model next-gen screens — such as long screens and screens with a display cutout.

Next, update your app’s targetSdkVersion to 28 as soon as possible, so Android P users of your app can benefit from the platform’s latest security, performance, and stability features. If your app is already targeting API 26+ in line with Google Play’s upcoming policies, then changing to target API 28 should be a small jump. When you change your targeting, make sure your app supports all of the applicable behavior changes.

It’s also important to test your apps for uses of non-SDK interfaces and reduce your reliance on them. As noted recently, Android P restricts access to selected non-SDK interfaces. Watch for logcat warnings that highlight direct uses of restricted non-SDK interfaces and try the new StrictMode method detectNonSdkApiUsage() to catch accesses programmatically. Where possible, you should move to using public equivalents from the Android SDK or NDK. If there’s no public API that meets your use-case, please let us know.

When you’re ready, dive into Android P and learn about the new features and APIs that you can use in your apps. To build with the new APIs, just download the official API 28 SDK and tools into Android Studio 3.1, or use the latest version of Android Studio 3.2. Then update your project’s compileSdkVersion and targetSdkVersion to API 28.

Visit the Developer Preview site for details and documentation. Also check out this video and the Google I/O Android playlist for more on what’s new in Android P for developers.

Publish to Google Play alpha, beta, or production channels

As soon as you’re ready, publish your APK updates that are compiled against, or optionally targeting, API 28. Publishing an update to Google Play during the preview lets you push updates to existing users to test compatibility on their devices.

To make sure that your updated app runs well on Android P as well as older versions, a common strategy is to use Google Play’s beta testing feature. With beta testing you can get early feedback from a small group of users — including Beta 3 users — and then do a staged rollout to production.

What’s next?

Thanks for all of your feedback so far. Please continue to share feedback or requests as we work towards the consumer release later this summer. Feel free to use our hotlists for platform issues, app compatibility issues, and third-party SDK issues.

Also, the Android engineering team will host a Reddit AMA on r/androiddev to answer your technical questions about Android P on July 19 from 11:30-1 PM (Pacific Time). Look out for an announcement on r/androiddev in the coming weeks. We look forward to addressing your questions!

Read more

Posted by Ivan Lozano, Information Security Engineer

Android’s switch to LLVM/Clang as the default platform compiler in Android 7.0 opened up more possibilities for improving our defense-in-depth security posture. In the past couple of releases, we’ve rolled out additional compiler-based mitigations to make bugs harder to exploit and prevent certain types of bugs from becoming vulnerabilities. In Android P, we’re expanding our existing compiler mitigations, which instrument runtime operations to fail safely when undefined behavior occurs. This post describes the new build system support for Control Flow Integrity and Integer Overflow Sanitization.

Control Flow Integrity

A key step in modern exploit chains is for an attacker to gain control of a program’s control flow by corrupting function pointers or return addresses. This opens the door to code-reuse attacks where an attacker executes arbitrary portions of existing program code to achieve their goals, such as counterfeit-object-oriented and return-oriented programming. Control Flow Integrity (CFI) describes a set of mitigation technologies that confine a program’s control flow to a call graph of valid targets determined at compile-time.

While we first supported LLVM’s CFI implementation in select components in Android O, we’re greatly expanding that support in P. This implementation focuses on preventing control flow manipulation via indirect branches, such as function pointers and virtual functions—the ‘forward-edges’ of a call graph. Valid branch targets are defined as function entry points for functions with the expected function signature, which drastically reduces the set of allowable destinations an attacker can call. Indirect branches are instrumented to detect runtime violations of the statically determined set of allowable targets. If a violation is detected because a branch points to an unexpected target, then the process safely aborts.

Assembly-level comparison of a virtual function call with and without CFI enabled.

Figure 1. Assembly-level comparison of a virtual function call with and without CFI enabled.

For example, Figure 1 illustrates how a function that takes an object and calls a virtual function gets translated into assembly with and without CFI. For simplicity, this was compiled with -O0 to prevent compiler optimization. Without CFI enabled, it loads the object’s vtable pointer and calls the function at the expected offset. With CFI enabled, it performs a fast-path first check to determine if the pointer falls within an expected range of addresses of compatible vtables. Failing that, execution falls through to a slow path that does a more extensive check for valid classes that are defined in other shared libraries. The slow path will abort execution if the vtable pointer points to an invalid target.

With control flow tightly restricted to a small set of legitimate targets, code-reuse attacks become harder to utilize and some memory corruption vulnerabilities become more difficult or even impossible to exploit.

In terms of performance impact, LLVM’s CFI requires compiling with Link-Time Optimization (LTO). LTO preserves the LLVM bitcode representation of object files until link-time, which allows the compiler to better reason about what optimizations can be performed. Enabling LTO reduces the size of the final binary and improves performance, but increases compile time. In testing on Android, the combination of LTO and CFI results in negligible overhead to code size and performance; in a few cases both improved.

For more technical details about CFI and how other forward-control checks are handled, see the LLVM design documentation.

For Android P, CFI is enabled by default widely within the media frameworks and other security-critical components, such as NFC and Bluetooth. CFI kernel support has also been introduced into the Android common kernel when building with LLVM, providing the option to further harden the trusted computing base. This can be tested today on the HiKey reference boards.

Integer Overflow Sanitization

The UndefinedBehaviorSanitizer’s (UBSan) signed and unsigned integer overflow sanitization was first utilized when hardening the media stack in Android Nougat. This sanitization is designed to safely abort process execution if a signed or unsigned integer overflows by instrumenting arithmetic instructions which may overflow. The end result is the mitigation of an entire class of memory corruption and information disclosure vulnerabilities where the root cause is an integer overflow, such as the original Stagefright vulnerability.

Because of their success, we’ve expanded usage of these sanitizers in the media framework with each release. Improvements have been made to LLVM’s integer overflow sanitizers to reduce the performance impact by using fewer instructions in ARM 32-bit and removing unnecessary checks. In testing, these improvements reduced the sanitizers’ performance overhead by over 75% in Android’s 32-bit libstagefright library for some codecs. Improved Android build system support, such as better diagnostics support, more sensible crashes, and globally sanitized integer overflow targets for testing have also expedited the rollout of these sanitizers.

We’ve prioritized enabling integer overflow sanitization in libraries where complex untrusted input is processed or where there have been security bulletin-level integer overflow vulnerabilities reported. As a result, in Android P the following libraries now benefit from this mitigation:

  • libui
  • libnl
  • libmediaplayerservice
  • libexif
  • libdrmclearkeyplugin
  • libreverbwrapper

Future Plans

Moving forward, we’re expanding our use of these mitigation technologies and we strongly encourage vendors to do the same with their customizations. More information about how to enable and test these options will be available soon on the Android Open Source Project.

Acknowledgements: This post was developed in joint collaboration with Vishwath Mohan, Jeffrey Vander Stoep, Joel Galenson, and Sami Tolvanen