Get a sneak peek at Android Nougat 7.1.2

Posted by Dave Burke, VP of Engineering

The next maintenance release for Android Nougat -- 7.1.2 -- is just around the
corner! To get the recipe just right, starting today, we're rolling out a public
beta to eligible devices that are enrolled in the Android Beta Program, including Pixel and
Pixel XL, Nexus 5X, Nexus Player, and Pixel C devices. We're also preparing an update for Nexus 6P that we expect to release soon.




Android 7.1.2 is an incremental maintenance release focused on refinements, so
it includes a number of bugfixes and optimizations, along with a small number of
enhancements for carriers and users.




If you'd like to try the public beta for Android 7.1.2, the easiest way is
through the Android Beta Program. If
you have an eligible device that's already enrolled, you're all set -- your
device will get the public beta update in the next few days and no action is
needed on your part. If your device isn't enrolled, it only takes a moment to
visit android.com/beta and opt-in your
eligible Android phone or tablet -- you'll soon receive the public beta update
over-the-air. As always, you can also download and flash this update manually.




We're expecting to launch the final release of the Android 7.1.2 in just a
couple of months, Like the beta, it will be available for Pixel, Pixel XL,
Nexus 5X, Nexus 6P, Nexus Player, and Pixel C devices. Meanwhile we welcome your
feedback or requests in the Android Beta
community as we work towards the final over-the-air update. Thanks for being
part of the public beta!

Engaging users during major events: How The Guardian used innovative notifications

Posted By Tamzin Taylor, Partner Development at Google Play

Major sporting, cultural, political events present an opportunity to re-engage
users if you can find a relevant and unique way to serve them information. For
example, The
Guardian was able to substantially increase user engagement with its mobile
app during the recent US election by using new notifications functionality in
Android 7.0 Nougat. While notifications themselves are nothing new, The Guardian
used innovative techniques and design elements to give their users a rich, real
time update on the election results as they happened.

How The Guardian innovated with notifications

Users who opted-in received a single, continuously updating notification which
was persistent on their lock screen as results came in on election night. The
notification used avatars of the candidates and a progress bar to bring the
information to life.

The notification showed the most up-to-date numbers of electoral votes won and
states called, an indication of which swing states have been called, and the
breakdown of the popular vote between the two leading candidates.

"Having the ability to have a constantly updating notification on screen,
allowed us to keep our users engaged throughout election night".

� Rob Phillips from The Guardian

Another important feature was the ability to notify users of major updates with
a link to detailed information and analysis. In order to do this, the Guardian
allowed the newsroom teams to push notifications of major events, such as when
the 270 vote mark was passed.

"Our newsroom could let our readers know in real time when there was a
serious milestone, and we were able to deliver 101 unique notifications during
the course of the evening. The clear menu options acted as key drivers
to our journalism as the news unfolded, and meant we could get our readers
connected with our content when they were most receptive".

� Rob Phillips from The Guardian

Results and next steps

The engagement results were impressive:

• 170K people signed up to see the alert, with 122K users interacting with the
  alert
  


• The average number of interactions was around 620K, or 5.1 per user
  


• 74% of users who saw the notification tapped through to the main live blog
  


• 25% of users who saw the notification tapped through to our full results
  content

Finally, perhaps the most impressive statistic is that promoting live updates
(via the notification) resulted in 103% increase in daily
installs during election week.

"By providing our users with the ability to quickly and easily check
information, to highlight major moments and to direct people to where to find
more information, we can deliver value to our readers, helping them make sense
of the events wherever they are, quickly and succinctly. After all, that's what
we're here to do as a news company, and we're delighted that the new
functionality on Nougat lets us do that"

� Rob Phillips from The Guardian

On the back of the success of using Android
N capabilities for live notifications, the Guardian plans to test the same
approach with sports content, and explore how it could be applied more
extensively to other major events like The Oscars and the Super Bowl.

How useful did you find this blogpost?

? ? ? ? ?

                                                                              

Final update to Android 7.1 Developer Preview

Posted by Dave Burke, VP of Engineering

Today we're rolling out an update to the Android 7.1 Developer Preview -- the
last before we release the final Android 7.1.1 platform to the ecosystem.
Android 7.1.1 includes the developer features already available on Pixel and
Pixel XL devices and adds optimizations and bug fixes on top of the base Android
7.1 platform. With Developer Preview 2, you can make sure your apps are ready
for Android 7.1.1 and the consumers that will soon be running it on their
devices.

As href="https://android-developers.blogspot.com/2016/10/android71-dev-preview-available.html">highlighted
in October, we're also expanding the range of devices that can receive this
Developer Preview update to Nexus 5X, Nexus 6P, Nexus 9, and Pixel C.

If you have a supported device that's enrolled in the href="http://www.android.com/beta">Android Beta Program, you'll receive an
update to Developer Preview 2 over the coming week. If you haven't enrolled your
device yet, just visit the site to
enroll your device and get the update.

In early December, we'll roll out Android 7.1.1 to the full lineup of supported
devices as well as Pixel and Pixel XL devices.

What's in this update?

Developer Preview 2 is a release candidate for Android 7.1.1 that you can use to
complete your app development and testing in preparation for the upcoming final
release. In includes near-final system behaviors and UI, along with the latest
bug fixes and optimizations across the system and Google apps.

It also includes the developer features and APIs (API level 25) already
introduced in Developer Preview 1. If you haven't explored the developer
features, you'll want to take a look at href="https://developer.android.com/preview/shortcuts.html?utm_campaign=android_launch_developerpreview_112216&utm_source=anddev&utm_medium=blog">app shortcuts,
href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview_112216&utm_source=anddev&utm_medium=blog#circular-icons">round
icon resources, and href="https://developer.android.com/preview/image-keyboard.html?utm_campaign=android_launch_developerpreview_112216&utm_source=anddev&utm_medium=blog">image keyboard
support, among others -- you can see the href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview_112216&utm_source=anddev&utm_medium=blog">full list of
developer features here.

With Developer Preview 2, we're also updating the SDK build and platform tools
in Android Studio, the Android 7.1.1 platform, and the API Level 25 emulator
system images. The latest version of the support library (href="https://developer.android.com/topic/libraries/support-library/revisions.html?utm_campaign=android_launch_developerpreview_112216&utm_source=anddev&utm_medium=blog">25.0.1)
is also available for you to href="https://developer.android.com/reference/android/support/v13/view/inputmethod/InputConnectionCompat.OnCommitContentListener.html?utm_campaign=android_launch_developerpreview_112216&utm_source=anddev&utm_medium=blog">add
image keyboard support, href="https://developer.android.com/reference/android/support/design/widget/BottomNavigationView.html?utm_campaign=android_launch_developerpreview_112216&utm_source=anddev&utm_medium=blog">bottom
navigation, and other features for devices running API Level 25 or earlier.

For details on API Level 25 check out the href="https://developer.android.com/sdk/api_diff/25/changes.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">API
diffs and the updated href="https://developer.android.com/reference/packages.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">API
reference on the href="https://developer.android.com/preview/index.html">developer preview
site.

Get your apps ready for Android 7.1

Now is the time to optimize your apps to look their best on Android 7.1.1. To
get started, update to href="https://developer.android.com/studio/index.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">Android
Studio 2.2.2 and then download the API Level 25 platform, emulator system
images, and tools through the SDK Manager in Android Studio.

After installing the API Level 25 SDK, you can update your project's
compileSdkVersion to 25 to build and test against the new APIs. If you're doing
compatibility testing, we recommend updating your app's targetSdkVersion to 25
to test your app with compatibility behaviors disabled. For details on how to
set up your app with the API Level 25 SDK, see href="https://developer.android.com/preview/setup-sdk.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">Set
up the Preview.

If you're adding app shortcuts or circular launcher icons to your app, you can
use Android Studio's built-in Image Asset Studio to quickly help you create
icons of different sizes that meet the href="https://material.google.com/style/icons.html#icons-product-icons">material
design guidelines. You can test your round icons on the Google APIs emulator
for API Level 25, which includes support for round icons and the new Google
Pixel Launcher.

Android Studio and the Google APIs emulator let you quickly create and test
your round icon assets.

If you're adding image keyboard support, you can use the Messenger and Google
Keyboard apps included in the preview system images for testing as they include
support for this new API.

Scale your tests using Firebase Test Lab for Android

To help scale your testing, make sure to take advantage of href="http://android-developers.blogspot.com/2016/11/android-dev-preview-in-firebase-test-lab.html">Firebase
Test Lab for Android and run your tests in the cloud at no charge during the
preview period on all virtual devices including the Developer Preview 2 (API
25). You can use the automated crawler (href="https://firebase.google.com/docs/test-lab/robo-ux-test">Robo Test) to
test your app without having to write any test scripts, or you can upload your
own instrumentation (e.g. Espresso) tests. You can upload your tests href="https://console.firebase.google.com/project/_/testlab/run">here.

Publish your apps to alpha, beta or production channels in Google
Play

After you've finished final testing, you can publish your updates compiled
against, and optionally targeting, API 25 to Google Play. You can publish to
your alpha, href="https://developer.android.com/distribute/engage/beta.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">beta,
or even production channels in the Google Play Developer Console. In this way,
push your app updates to users whose devices are running Android 7.1, such as
Pixel and Android Beta devices.

Get Developer Preview 2 on Your Eligible Device

If you have an eligible device that's already enrolled in the href="https://android.com/beta">Android Beta Program, the device will get
the Developer Preview 2 update over the coming week. No action is needed on your
part. If you aren't yet enrolled in program, the easiest way to get started is
by visiting android.com/beta and opt-in
your eligible Android phone or tablet -- you'll soon receive this preview update
over-the-air. As always, you can also download and href="https://developer.android.com/preview/download.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog#flash">flash
this update manually.

As mentioned above, this Developer Preview update is available for Nexus 5X,
Nexus 6P, Nexus 9, and Pixel C devices.

We're expecting to launch the final release of the Android 7.1.1 in just a few
weeks Starting in December, we'll roll out Android 7.1.1 to the full lineup of
supported preview devices, as well as the recently launched Pixel and Pixel XL
devices. At that time, we'll also push the sources to AOSP, so our device
manufacturer partners can bring this new platform update to consumers on their
devices.

Meanwhile, we continue to welcome your feedback in the href="https://code.google.com/p/android/issues/list?can=1&q=label%3ADevPreview-N-7.1">Developer
Preview issue tracker, href="https://plus.google.com/communities/105153134372062985968/stream/755bb91d-c101-4e32-9277-1e560c4e26d2">N
Preview Developer community, or href="https://plus.google.com/communities/106765800802768335079">Android Beta
community as we work towards the final consumer release in December!

Now available: Android 7.1 Developer Preview

Posted by Dave Burke, VP of Engineering

A couple of weeks ago we announced that a developer preview of Android 7.1 Nougat was on the way. You can get started with this new release today by downloading the SDK and tools. To get the 7.1 release on your eligible device, enroll your device in the Android Beta program. If your device is already enrolled, you'll receive the update automatically.

What�s in the Developer Preview?

The Android 7.1 Developer Preview gives you everything you need to test your app on the new platform or extend it with new features like app shortcuts and image keyboard support. It includes an updated SDK and tools, documentation and samples, as well as emulators and device system images for running your apps on supported devices.

We�re continuing the model we used in N and earlier releases, and with Android 7.1 being an incremental release there are a few differences to highlight:

• Since 7.1 has already launched on Pixel, we�re delivering the initial Developer Preview at beta quality for the Nexus lineup of devices. The goal is to tease out any device-specific issues.


• We�ve finalized the new APIs as API Level 25


• We�ve opened up publishing on Google Play for apps targeting the new API level, so you can update your apps soon as you are ready.

After the initial preview release, we plan to deliver an update in November followed by the final public release to the Android Open Source Project (AOSP) in December. Initially available on Nexus 5X, Nexus 6P, and Pixel C devices, we�ll extend the Developer Preview to other devices in November.

Get your apps ready for Android 7.1

To get started, update to Android Studio 2.2.2 and download API Level 25 platform, emulator system images and tools. The final API Level 25 SDK is available for download through the SDK Manager in Android Studio.

Once you�ve installed the API Level 25 SDK, you can update your project�s compileSdkVersion to 25 to build and test against the new APIs. If you�re doing compatibility testing, we recommend updating your app�s targetSdkVersion to 25 to test your app with compatibility behaviors disabled. For details on how to set up your app with the API Level 25 SDK, see Set up the Preview.

If you�re adding app shortcuts or circular launcher icons to your app, you can use Android Studio�s built-in Image Asset Studio to quickly help you create icons of different sizes that meet the material design guidelines.

The Google APIs Emulator System images shipped with the Android API Level 25 SDK include support for round icons and the new Google Pixel Launcher. The Google API system image allows you to test how your app�s circular app icons look in devices that support circular icons. Also, if you are developing live wallpapers, you can also use the the new system images with the Android Emulator to test the enhanced preview metadata in Android 7.1.

To help you add image keyboard support, you can use the Messenger and Google Keyboard apps included in the preview system images for testing as they include support for this new API.

Along with the API Level 25 SDK, we have also updated the Android Support Library to 25.0.0. The new version lets you add image keyboard support with compatibility back to API level 13. It also introduces BottomNavigationView widget, which implements the bottom navigation pattern from the material design guidelines.

For details on API Level 25 check out the API diffs and the updated API reference on the developer preview site.

You can use the Android Emulator in Android Studio to test your circular app icons & shortcuts in a launcher

You can use the Image Asset tool to quickly create circular icon assets.

Publish your apps to alpha, beta or production channels in Google Play

Since the Android 7.1 APIs are final, you can publish updates compiling with, and optionally targeting, API 25 to Google Play. You can now publish app updates that use API 25 to your alpha, beta, or even production channels in the Google Play Developer Console. In this way, push your app updates to users whose devices are running Android 7.1, such as Pixel and Android Beta devices.

How to Get Android 7.1 Developer Preview on Your Eligible Device

If you are already enrolled in the Android Beta program, then your eligible enrolled devices will get the Android 7.1 Developer Preview update right away, no action is needed on your part. If you aren�t yet enrolled in Android Beta, the easiest way to get started is to visit android.com/beta and opt-in your eligible Android phone or tablet -- you�ll soon receive this (and later) preview updates over-the-air. If you have an enrolled device and do not want to receive the update, just visit Android Beta and unenroll the device. You can also download and flash this update manually.

We welcome your feedback in the Developer Preview issue tracker, N Preview Developer community, or Android Beta community as we work towards the consumer release in December!

Coming soon: Android 7.1 Developer Preview

Posted by Dave Burke, VP of Engineering

Today, we�re taking the wraps off of Android 7.1 Nougat, the latest version of the platform. You probably saw a sneak peek of it at last week�s event. It�s an incremental update based on Android 7.0 but includes new features for consumers and developers — from platform Daydream VR support and A/B system updates to app shortcuts and image keyboard support.

We�ve already been working closely with device makers to get them ready for Android 7.1, and next we�ll give you access to this update so you can start getting your apps ready.

Later this month we�ll be bringing you the Android 7.1 platform as an open Developer Preview, similar to what we did for Android 7.0. You�ll be able to test and build on the new platform and try the latest features.

As always, we�ll deliver the Developer Preview through the Android Beta program, which makes it incredibly easy to participate.

What�s in Android 7.1?

Android 7.1 delivers the productivity, security, and performance of Android 7.0, along with a variety of optimizations and bug fixes, features, and new APIs (API level 25).

For developers, Android 7.1 adds new capabilities to help you drive engagement in your app and deliver an improved user experience, such as:

• App shortcuts API — lets you surface key actions directly in the launcher and take your users deep into your app instantly. You can create up to 5 shortcuts, either statically or dynamically.


• Circular app icons support — lets you provide great-looking rounded icon resources that match the look of Pixel and other launchers.


• Enhanced live wallpaper metadata — lets you provide metadata about your live wallpapers to any picker displaying the wallpapers as a preview. You can show existing metadata such as label, description, and author, as well as a new context URL and title to link to more information.

Android 7.1 also adds these much-requested developer features to the platform:

• Image keyboard support — expands the types of content that users can enter from their keyboards, letting them express themselves through custom stickers, animated gifs, and more. Apps can tell the keyboard what types of content they accept, and keyboards can deliver all of the images and other content that they offer to the user. For broad compatibility, this API will also be available in the support library.


• Storage manager Intent — lets an app take the user directly to a new Settings screen to clear unused files and free up storage space on the device.

For carriers and calling apps, the platform includes new APIs to support multi-endpoint calling and new telephony configuration options.

Image keyboard support: Let users input images and other content directly from a keyboard.

App shortcuts: Use app shortcuts to surface key actions and take users deep into your app instantly.

Get your apps ready

Android 7.1 is an incremental release, but it�s always important to make sure your apps look and run great — especially as devices start to reach consumers.

The Android 7.1 Developer Preview will give you everything you need to test your apps or extend them with new features like shortcuts or keyboard images. Included are the SDK with new APIs, build tools, documentation and samples, as well as emulators and device system images for running your apps on supported Nexus devices. We�ll also include a launcher and apps that support app shortcuts, and a keyboard and apps that support keyboard images.

If you want to receive the Developer Preview automatically, visit Android Beta and enroll your device. If you previously enrolled a device and haven�t unenrolled, your device will receive the update. If you already enrolled but don�t want to receive the update, visit Android Beta to unenroll the device as soon as possible.

Initially, we�ll offer the Developer Preview for Nexus 5X, Nexus 6P, and Pixel C devices, extending to other supported devices by the end of the preview. At the final release of the Android 7.1.x platform, due in early December, we�ll roll out updates to the full lineup of supported devices — Nexus 6, 5X, 6P, 9, Player, Pixel C, and supported Android One devices — as well as Pixel and Pixel XL devices.

Coming to consumer devices soon

We�re working with our partners to bring Android 7.1 to devices in the ecosystem over the months ahead, so we recommend downloading the Android 7.1 Developer Preview as soon as it�s available. Test your apps for compatibility and optimize them to look their best, such as by providing circular app icons and adding app shortcuts.

Meanwhile, stay tuned, we�ll be sharing more details about the Developer Preview soon!

Taking the final wrapper off of Android 7.0 Nougat

Posted by Dave Burke, VP of Engineering

Android 7.0 Nougat

Today, Android 7.0 Nougat will begin rolling out to users, starting with Nexus
devices. At the same time, we�re pushing the Android 7.0 source code to the
Android Open Source Project (AOSP), extending public availability of this new
version of Android to the broader ecosystem.

We�ve been working together with
you over the past several months to get your feedback on this release, and also
to make sure your apps are ready for the users who will run them on Nougat
devices.

What�s inside Nougat

Android Nougat reflects input from thousands of fans and developers like you,
all around the world. There are over 250 major features in Android Nougat,
including VR Mode in
Android. We�ve worked at all levels of the Android stack in
Nougat — from how the operating system reads sensor data to how it sends pixels to
the display — to make it especially built to provide high quality mobile VR
experiences.

Plus, Nougat brings a number of new features to help make Android
more powerful, more productive and more secure. It introduces a brand new
href="https://developer.android.com/about/versions/nougat/android-7.0.html?utm_campaign=android_launch_android7.0nougat_082216&utm_source=anddev&utm_medium=blog#jit_aot?utm_source=anddev&utm_medium=blog">JIT/AOT
compiler to improve software performance, make app installs faster,
and take up less storage. It also adds platform support for href="https://developer.android.com/ndk/guides/graphics/index.html?utm_campaign=android_launch_android7.0nougat_082216&utm_source=anddev&utm_medium=blog">Vulkan,
a low-overhead, cross-platform API for high-performance, 3D graphics. href="http://developer.android.com/guide/topics/ui/multi-window.html?utm_source=anddev&utm_medium=blog">Multi-Window
support lets users run two apps at the same time, and href="http://developer.android.com/guide/topics/ui/notifiers/notifications.html?utm_campaign=android_launch_android7.0nougat_082216&utm_source=anddev&utm_medium=blog#direct?utm_source=anddev&utm_medium=blog">Direct
Reply so users can reply directly to notifications without having
to open the app. As always, Android is built with powerful layers of security
and encryption to keep your private data private, so Nougat brings new features
like File-based encryption, seamless updates, and href="https://developer.android.com/training/articles/direct-boot.html?utm_source=anddev&utm_medium=blog">Direct
Boot.

You can find all of the href="https://developer.android.com/about/versions/nougat/index.html?utm_source=anddev&utm_medium=blog">Nougat
developer resources here, including details on behavior changes and new
features you can use in your apps. An overview of what's new for developers is
available href="https://developer.android.com/about/versions/nougat/android-7.0.html?utm_source=anddev&utm_medium=blog">here, and
you can explore all of the new user features in Nougat href="https://www.android.com/versions/nougat-7-0/">here.

Multi-window mode in Android Nougat

The next wave of users

Starting today and rolling out over the next several weeks, the Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, Nexus Player,
Pixel C, and General Mobile 4G (Android One) will get an over-the-air software
update to Android 7.0 Nougat. Devices enrolled in the href="https://www.google.com/android/beta">Android Beta Program will also
receive this final version.

And there are many tasty devices coming from our partners running Android Nougat, including the upcoming href="http://www.lgnewsroom.com/2016/08/new-lg-v20-to-be-worlds-first-phone-to-launch-with-android-7-0-nougat/">LG
V20, which will be the first new smartphone that ships with Android Nougat, right out of the box.

With all of these new devices beginning to run Nougat, now is the time to
publish your app updates to Google Play. We recommend compiling against, and
ideally targeting, API 24. If you�re still testing some last minute changes, a
great strategy to do this is using href="https://developer.android.com/distribute/engage/beta.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">Google
Play�s beta testing feature to get early feedback from a small group of
users — including those using Android 7.0 Nougat — and then doing a staged
rollout as you release the updated app to all users.

What�s next for Nougat?

We�re moving Nougat into a new regular maintenance schedule over the coming
quarters. In fact, we�ve already started work on the first Nougat maintenance
release, that will bring continued refinements and polish, and we�re planning to
bring that to you this fall as a developer preview. Stay tuned!

We�ll be closing open bugs logged against Developer Preview builds soon, but
please keep the feedback coming! If you still see an issue that you filed in the
preview tracker, just href="https://source.android.com/source/report-bugs.html">file a new issue
against Android 7.0 in the AOSP issue tracker.

Thanks for being part of the preview, which we shared earlier this year with href="https://medium.com/google-developers/n-as-in-so-early-it-s-not-named-yet-f06bbde8c390#.uqdm4w8hi">an
eye towards giving everyone the opportunity to make the next release of
Android stronger. Your continued feedback has been extremely beneficial in
shaping this final release, not just for users, but for the entire Android
ecosystem.

Protecting Android with more Linux kernel defenses

Posted by Jeff Vander Stoep, Android Security team

Android relies heavily on the Linux kernel for enforcement of its security
model. To better protect the kernel, we�ve enabled a number of mechanisms within
Android. At a high level these protections are grouped into two
categories�memory protections and attack surface reduction.

Memory protections

One of the major security features provided by the kernel is memory protection
for userspace processes in the form of address space separation. Unlike
userspace processes, the kernel�s various tasks live within one address space
and a vulnerability anywhere in the kernel can potentially impact unrelated
portions of the system�s memory. Kernel memory protections are designed to
maintain the integrity of the kernel in spite of vulnerabilities.

Mark memory as read-only/no-execute

This feature segments kernel memory into logical sections and sets restrictive
page access permissions on each section. Code is marked as read only + execute.
Data sections are marked as no-execute and further segmented into read-only and
read-write sections. This feature is enabled with config option
CONFIG_DEBUG_RODATA. It was put together by Kees Cook and is based on a subset
of Grsecurity�s KERNEXEC feature by Brad
Spengler and Qualcomm�s CONFIG_STRICT_MEMORY_RWX feature by Larry Bassel and
Laura Abbott. CONFIG_DEBUG_RODATA landed in the upstream kernel for arm/arm64
and has been backported to Android�s 3.18+ arm/href="https://android-review.googlesource.com/#/c/174947/">arm64 common
kernel.

Restrict kernel access to userspace

This feature improves protection of the kernel by preventing it from directly
accessing userspace memory. This can make a number of attacks more difficult
because attackers have significantly less control over kernel memory
that is executable, particularly with CONFIG_DEBUG_RODATA enabled. Similar
features were already in existence, the earliest being Grsecurity�s UDEREF. This
feature is enabled with config option CONFIG_CPU_SW_DOMAIN_PAN and was
implemented by Russell King for ARMv7 and backported to href="https://android-review.googlesource.com/#/q/topic:sw_PAN">Android�s
4.1 kernel by Kees Cook.

Improve protection against stack buffer overflows

Much like its predecessor, stack-protector, stack-protector-strong protects
against stack
buffer overflows, but additionally provides coverage for href="https://outflux.net/blog/archives/2014/01/27/fstack-protector-strong/">more
array types, as the original only protected character arrays.
Stack-protector-strong was implemented by Han Shen and href="https://gcc.gnu.org/ml/gcc-patches/2012-06/msg00974.html">added to the gcc
4.9 compiler.

Attack surface reduction

Attack surface reduction attempts to expose fewer entry points to the kernel
without breaking legitimate functionality. Reducing attack surface can include
removing code, removing access to entry points, or selectively exposing
features.

Remove default access to debug features

The kernel�s perf system provides infrastructure for performance measurement and
can be used for analyzing both the kernel and userspace applications. Perf is a
valuable tool for developers, but adds unnecessary attack surface for the vast
majority of Android users. In Android Nougat, access to perf will be blocked by
default. Developers may still access perf by enabling developer settings and
using adb to set a property: �adb shell setprop security.perf_harden 0�.

The patchset for blocking access to perf may be broken down into kernel and
userspace sections. The href="https://android-review.googlesource.com/#/c/234573/">kernel patch is
by Ben Hutchings and is
derived from Grsecurity�s CONFIG_GRKERNSEC_PERF_HARDEN by Brad Spengler. The
userspace changes were href="https://android-review.googlesource.com/#/q/topic:perf_harden">contributed
by Daniel Micay. Thanks to href="https://conference.hitb.org/hitbsecconf2016ams/sessions/perf-from-profiling-to-kernel-exploiting/">Wish
Wu and others for responsibly disclosing security vulnerabilities in perf.

Restrict app access to ioctl commands

Much of Android security model is described and enforced by SELinux. The ioctl()
syscall represented a major gap in the granularity of enforcement via SELinux.
Ioctl command
whitelisting with SELinux was added as a means to provide per-command
control over the ioctl syscall by SELinux.

Most of the kernel vulnerabilities reported on Android occur in drivers and are
reached using the ioctl syscall, for example href="https://source.android.com/security/bulletin/2016-03-01.html#elevation_of_privilege_vulnerability_in_mediatek_wi-fi_kernel_driver">CVE-2016-0820.
Some ioctl commands are needed by third-party applications, however most are not
and access can be restricted without breaking legitimate functionality. In
Android Nougat, only a small whitelist of socket ioctl commands are available to
applications. For select devices, applications� access to GPU ioctls has been
similarly restricted.

Require seccomp-bpf

Seccomp provides an additional sandboxing mechanism allowing a process to
restrict the syscalls and syscall arguments available using a configurable
filter. Restricting the availability of syscalls can dramatically cut down on
the exposed attack surface of the kernel. Since seccomp was first introduced on
Nexus devices in Lollipop, its availability across the Android ecosystem has
steadily improved. With Android Nougat, seccomp support is a requirement for all
devices. On Android Nougat we are using seccomp on the mediaextractor and
mediacodec processes as part of the href="http://android-developers.blogspot.com/2016/05/hardening-media-stack.html">media
hardening effort.

Ongoing efforts

There are other projects underway aimed at protecting the kernel:

• The href="http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project">Kernel
  Self Protection Project is developing runtime and compiler defenses for the
  upstream kernel.
  
• Further sandbox tightening and attack surface reduction with SELinux is
  ongoing in AOSP.
  
• href="https://www.chromium.org/chromium-os/developer-guide/chromium-os-sandboxing#h.l7ou90opzirq">Minijail
  provides a convenient mechanism for applying many containment and sandboxing
  features offered by the kernel, including seccomp filters and namespaces.
  
• Projects like href="https://www.kernel.org/doc/Documentation/kasan.txt">kasan and href="https://www.kernel.org/doc/Documentation/kcov.txt">kcov help fuzzers
  discover the root cause of crashes and to intelligently construct test cases
  that increase code coverage�ultimately resulting in a more efficient bug hunting
  process.

Due to these efforts and others, we expect the security of the kernel to
continue improving. As always, we appreciate feedback on our work and welcome
suggestions for how we can improve Android. Contact us at href="mailto:security@android.com">security@android.com.

Strictly Enforced Verified Boot with Error Correction

Posted by Sami Tolvanen, Software Engineer

Overview

Android uses multiple layers of protection to keep users safe. One of these
layers is verified
boot, which improves security by using cryptographic integrity checking to
detect changes to the operating system. Android has href="https://g.co/ABH">alerted about system integrity since Marshmallow,
but starting with devices first shipping with Android 7.0, we require verified
boot to be strictly enforcing. This means that a device with a corrupt boot
image or verified partition will not boot or will boot in a limited capacity
with user consent. Such strict checking, though, means that non-malicious data
corruption, which previously would be less visible, could now start affecting
process functionality more.

By default, Android verifies large partitions using the dm-verity kernel driver,
which divides the partition into 4 KiB blocks and verifies each block when read,
against a signed hash tree. A detected single byte corruption will therefore
result in an entire block becoming inaccessible when dm-verity is in enforcing
mode, leading to the kernel returning EIO errors to userspace on verified
partition data access.

This post describes our work in improving dm-verity robustness by introducing
forward error correction (FEC), and explains how this allowed us to make the
operating system more resistant to data corruption. These improvements are
available to any device running Android 7.0 and this post reflects the default
implementation in AOSP that we ship on our Nexus devices.

Error-correcting codes

Using forward error correction, we can detect and correct errors in source data
by shipping redundant encoding data generated using an error-correcting code.
The exact number of errors that can be corrected depends on the code used and
the amount of space allocated for the encoding data.

href="https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction">Reed-Solomon
is one of the most commonly used error-correcting code families, and is readily
available in the Linux kernel, which makes it an obvious candidate for
dm-verity. These codes can correct up to ?t/2? unknown errors and up to
t known errors, also called href="https://en.wikipedia.org/wiki/Erasure_code">erasures, when t
encoding symbols are added.

A typical RS(255, 223) code that generates 32 bytes of encoding data for every
223 bytes of source data can correct up to 16 unknown errors in each 255 byte
block. However, using this code results in ~15% space overhead, which is
unacceptable for mobile devices with limited storage. We can decrease the space
overhead by sacrificing error correction capabilities. An RS(255, 253) code can
correct only one unknown error, but also has an overhead of only 0.8%.

An additional complication is that block-based storage corruption often occurs
for an entire block and sometimes spans multiple consecutive blocks. Because
Reed-Solomon is only able to recover from a limited number of corrupted bytes
within relatively short encoded blocks, a naive implementation is not going to
be very effective without a huge space overhead.

Recovering from consecutive corrupted blocks

In the changes we made to href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a739ff3f543afbb4a041c16cd0182c8e8d366e70">dm-verity
for Android 7.0, we used a technique called interleaving to allow us to recover
not only from a loss of an entire 4 KiB source block, but several consecutive
blocks, while significantly reducing the space overhead required to achieve
usable error correction capabilities compared to the naive implementation.

Efficient interleaving means mapping each byte in a block to a separate
Reed-Solomon code, with each code covering N bytes across the corresponding N
source blocks. A trivial interleaving where each code covers a consecutive
sequence of N blocks already makes it possible for us to recover from the
corruption of up to (255 - N) / 2 blocks, which for RS(255, 223) would
mean 64 KiB, for example.

An even better solution is to maximize the distance between the bytes covered by
the same code by spreading each code over the entire partition, thereby
increasing the maximum number of consecutive corrupted blocks an RS(255, N) code
can handle on a partition consisting of T blocks to ?T/N? � (255 -
N) / 2.

Interleaving with distance D and block size B.

An additional benefit of interleaving, when combined with the integrity
verification already performed by dm-verity, is that we can tell exactly where
the errors are in each code. Because each byte of the code covers a different
source block�and we can verify the integrity of each block using the existing
dm-verity metadata�we know which of the bytes contain errors. Being able to
pinpoint erasure locations allows us to effectively double our error correction
performance to at most ?T/N? � (255 - N) consecutive blocks.

For a ~2 GiB partition with 524256 4 KiB blocks and RS(255, 253), the maximum
distance between the bytes of a single code is 2073 blocks. Because each code
can recover from two erasures, using this method of interleaving allows us to
recover from up to 4146 consecutive corrupted blocks (~16 MiB). Of course, if
the encoding data itself gets corrupted or we lose more than two of the blocks
covered by any single code, we cannot recover anymore.

While making error correction feasible for block-based storage, interleaving
does have the side effect of making decoding slower, because instead of reading
a single block, we need to read multiple blocks spread across the partition to
recover from an error. Fortunately, this is not a huge issue when combined with
dm-verity and solid-state storage as we only need to resort to decoding if a
block is actually corrupted, which still is rather rare, and random access reads
are relatively fast even if we have to correct errors.

Conclusion

Strictly enforced verified boot improves security, but can also reduce
reliability by increasing the impact of disk corruption that may occur on
devices due to software bugs or hardware issues.

The new error correction feature we developed for dm-verity makes it possible
for devices to recover from the loss of up to 16-24 MiB of consecutive blocks
anywhere on a typical 2-3 GiB system partition with only 0.8% space overhead and
no performance impact unless corruption is detected. This improves the security
and reliability of devices running Android 7.0.

Final Developer Preview before Android 7.0 Nougat begins rolling out

Posted by Dave Burke, VP of Engineering

As we close in on the public rollout of href="https://developer.android.com/preview/index.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog">Android 7.0 Nougat
to devices later this summer, today we�re releasing Developer Preview
5, the last milestone of this preview series. href="http://android-developers.blogspot.com/2016/06/android-n-apis-are-now-final.html">Last
month�s Developer Preview included the final APIs for Nougat; this preview
gives developers the near-final system updates for all of the supported preview
devices, helping you get your app ready for consumers.

Here�s a quick rundown of what�s included in the final Developer Preview of
Nougat:

• System images for Nexus and other preview devices
  
• An emulator that you can use for doing the final testing of your apps to
  make sure they�re ready
  
• The final N APIs (API level 24) and latest system behaviors and UI
  
• The latest bug fixes and optimizations across the system and in preinstalled
  apps

Working with this latest Developer Preview, you should make sure your app
handles all of the href="https://developer.android.com/preview/behavior-changes.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog">system
behavior changes in Android N, like Doze on the Go, background
optimizations, screen zoom, permissions changes, and more. Plus, you can take
advantage of href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog">new developer
features in Android N such as href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog#multi-window_support">Multi-window
support, Direct Reply and other href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog#notification_enhancements">notifications
enhancements, href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog#direct_boot">Direct
boot, href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog#emoji">new
emojis and more.

Publish your apps to alpha, beta or production channels in Google
Play

After testing your apps with Developer Preview 5 you should publish the updates
to Google Play soon. We recommend compiling against, and optionally targeting,
API 24 and then publishing to your alpha, beta, or production channels in the
Google Play Developer Console. A great strategy to do this is using href="https://developer.android.com/distribute/engage/beta.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">Google
Play�s beta testing feature to get early feedback from a small group of
users -- including Developer Preview users � and then doing a staged rollout as
you release the updated app to all users.

How to get Developer Preview 5

If you are already enrolled in the Android
Beta program, your devices will get the Developer Preview 5 update right
away, no action is needed on your part. If you aren�t yet enrolled in Android
Beta, the easiest way to get started is by visiting href="https://android.com/beta">android.com/beta and opt-in your eligible
Android phone or tablet -- you�ll soon receive this preview update over-the-air.
As always, you can also download and href="https://developer.android.com/preview/download.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog#flash">flash
this update manually. The Nougat Developer Preview is available for Nexus 6,
Nexus 5X, Nexus 6P, Nexus 9, and Pixel C devices, as well as General Mobile 4G
[Android One] devices.

Thanks so much for all of your feedback so far. Please continue to share
feedback or requests either in the href="https://code.google.com/p/android/issues/list?can=2&q=label%3ADevPreview-N">N
Developer Preview issue tracker, href="https://plus.google.com/communities/105153134372062985968/stream/755bb91d-c101-4e32-9277-1e560c4e26d2">N Preview
Developer community, or href="https://plus.google.com/communities/106765800802768335079">Android Beta
community as we work towards the consumer release later this summer. Android
Nougat is almost here!

Also, the Android engineering team will host a Reddit AMA on r/androiddev to
answer all your technical questions about the platform tomorrow, July 19
from 12-2 PM (Pacific Time). We look forward to addressing your
questions!

Changes to Trusted Certificate Authorities in Android Nougat

Posted by Chad Brubaker, Android Security team

In Android Nougat, we�ve changed how Android handles trusted certificate
authorities (CAs) to provide safer defaults for secure app traffic. Most apps
and users should not be affected by these changes or need to take any action.
The changes include:

• Safe and easy APIs to trust custom CAs.
  
• Apps that target API Level 24 and above no longer trust user or admin-added
  CAs for secure connections, by default.
  
• All devices running Android Nougat offer the same standardized set of system
  CAs�no device-specific customizations.

For more details on these changes and what to do if you�re affected by them,
read on.

Safe and easy APIs

Apps have always been able customize which certificate authorities they trust.
However, we saw apps making mistakes due to the complexities of the Java TLS
APIs. To address this we href="https://developer.android.com/preview/features/security-config.html">improved
the APIs for customizing trust.

User-added CAs

Protection of all application data is a key goal of the Android application
sandbox. Android Nougat changes how applications interact with user- and
admin-supplied CAs. By default, apps that target API level 24 will�by design�not
honor such CAs unless the app explicitly opts in. This safe-by-default setting
reduces application attack surface and encourages consistent handling of network
and file-based application data.

Customizing trusted CAs

Customizing the CAs your app trusts on Android Nougat is easy using the Network
Security Config. Trust can be specified across the whole app or only for
connections to certain domains, as needed. Below are some examples for trusting
a custom or user-added CA, in addition to the system CAs. For more examples and
details, see href="https://developer.android.com/preview/features/security-config.html">the
full documentation.

Trusting custom CAs for debugging

To allow your app to trust custom CAs only for local debugging, include
something like this in your Network Security Config. The CAs will only be
trusted while your app is marked as debuggable.

<network-security-config>  
      <debug-overrides>  
           <trust-anchors>  
                <!-- Trust user added CAs while debuggable only -->
                <certificates src="user" />  
           </trust-anchors>  
      </domain-config>  
 </network-security-config>

Trusting custom CAs for a domain

To allow your app to trust custom CAs for a specific domain, include something
like this in your Network Security Config.

<network-security-config>  
      <domain-config>  
           <domain includeSubdomains="true">internal.example.com</domain>  
           <trust-anchors>  
                <!-- Only trust the CAs included with the app  
                     for connections to internal.example.com -->  
                <certificates src="@raw/cas" />  
           </trust-anchors>  
      </domain-config>  
 </network-security-config>

Trusting user-added CAs for some domains

To allow your app to trust user-added CAs for multiple domains, include
something like this in your Network Security Config.

<network-security-config>  
      <domain-config>  
           <domain includeSubdomains="true">userCaDomain.com</domain>  
           <domain includeSubdomains="true">otherUserCaDomain.com</domain>  
           <trust-anchors>  
                  <!-- Trust preinstalled CAs -->  
                  <certificates src="system" />  
                  <!-- Additionally trust user added CAs -->  
                  <certificates src="user" />  
           </trust-anchors>  
      </domain-config>  
 </network-security-config>

Trusting user-added CAs for all domains except some

To allow your app to trust user-added CAs for all domains, except for those
specified, include something like this in your Network Security Config.

<network-security-config>  
      <base-config>  
           <trust-anchors>  
                <!-- Trust preinstalled CAs -->  
                <certificates src="system" />  
                <!-- Additionally trust user added CAs -->  
                <certificates src="user" />  
           </trust-anchors>  
      </base-config>  
      <domain-config>  
           <domain includeSubdomains="true">sensitive.example.com</domain>  
           <trust-anchors>  
                <!-- Only allow sensitive content to be exchanged  
             with the real server and not any user or  
    admin configured MiTMs -->  
                <certificates src="system" />  
           <trust-anchors>  
      </domain-config>  
 </network-security-config>

Trusting user-added CAs for all secure connections

To allow your app to trust user-added CAs for all secure connections, add this
in your Network Security Config.

<network-security-config>  
      <base-config>  
            <trust-anchors>  
                <!-- Trust preinstalled CAs -->  
                <certificates src="system" />  
                <!-- Additionally trust user added CAs -->  
                <certificates src="user" />  
           </trust-anchors>  
      </base-config>  
 </network-security-config>

Standardized set of system-trusted CAs

To provide a more consistent and more secure experience across the Android
ecosystem, beginning with Android Nougat, compatible devices trust only the
standardized system CAs maintained in href="https://android.googlesource.com/platform/system/ca-certificates/">AOSP.

Previously, the set of preinstalled CAs bundled with the system could vary from
device to device. This could lead to compatibility issues when some devices did
not include CAs that apps needed for connections as well as potential security
issues if CAs that did not meet our security requirements were included on some
devices.

What if I have a CA I believe should be included on Android?

First, be sure that your CA needs to be included in the system. The preinstalled
CAs are only for CAs that meet our security requirements
because they affect the secure connections of most apps on the device. If you
need to add a CA for connecting to hosts that use that CA, you should instead
customize your apps and services that connect to those hosts. For more
information, see the Customizing trusted CAs section above.

If you operate a CA that you believe should be included in Android, first
complete the Mozilla CA
Inclusion Process and then file a href="https://code.google.com/p/android/issues/entry">feature request
against Android to have the CA added to the standardized set of system CAs.

Improving Stability with Private C/C++ Symbol Restrictions in Android N

Posted by Dimitry Ivanov & Elliott Hughes, Software Engineers

As documented in the href="https://developer.android.com/preview/behavior-changes.html#ndk">Android N
behavioral changes, to protect Android users and apps from unforeseen
crashes, Android N will restrict which libraries your C/C++ code can link
against at runtime. As a result, if your app uses any private symbols from
platform libraries, you will need to update it to either use the public NDK APIs
or to include its own copy of those libraries. Some libraries are public: the
NDK exposes libandroid, libc, libcamera2ndk, libdl,
libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES,
libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are
private, and Android N only allows access to them for platform HALs, system
daemons, and the like. If you aren�t sure whether your app uses private
libraries, you can immediately check it for warnings on the N Developer Preview.

We�re making this change because it�s painful for users when their apps stop
working after a platform update. Whether they blame the app developer or the
platform, everybody loses. Users should have a consistent app experience across
updates, and developers shouldn�t have to make emergency app updates to handle
platform changes. For that reason, we recommend against using private C/C++
symbols. Private symbols aren�t tested as part of the Compatibility Test Suite
(CTS) that all Android devices must pass. They may not exist, or they may behave
differently. This makes apps that use them more likely to fail on specific
devices, or on future releases — as many developers found when Android 6.0
Marshmallow switched from OpenSSL to BoringSSL.

You may be surprised that there�s no STL in the list of NDK libraries. The three
STL implementations included in the NDK — the LLVM libc++, the GNU STL, and
libstlport — are intended to be bundled with your app, either by statically
linking into your library, or by inclusion as a separate shared library. In the
past, some developers have assumed that they didn�t need to package the library
because the OS itself had a copy. This assumption is incorrect: a particular STL
implementation may disappear (as was the case with stlport, which was removed in
Marshmallow), may never have been available (as is the case with the GNU STL),
or it may change in ABI incompatible ways (as is the case with the LLVM libc++).

In order to reduce the user impact of this transition, we�ve identified a set of
libraries that see significant use from Google Play�s most-installed apps, and
that are feasible for us to support in the short term (including
libandroid_runtime.so, libcutils.so, libcrypto.so, and libssl.so). For legacy
code in N, we will temporarily support these libraries in order to give you more
time to transition. Note that we don't intend to continue this support in any
future Android platform release, so if you see a warning that means your code
will not work in a future release — please fix it now!

Table 1. What to expect if your app is linking against private native libraries.

Libraries	App's targetSdkVersion	Runtime access via dynamic linker	Impact, N Developer Preview	Impact, Final N Release	Impact, future platform version
NDK Public	Any	Accessible
Private (graylist)	<=23	Temporarily accessible	Warning / Toast	Warning	Error
	>=24	Restricted	Error	Error	Error
Private (all other)>	Any	Restricted	Error	Error	Error

What behavior will I see?

Please test your app during the N Previews.

N Preview behavior

• All public NDK libraries (libandroid, libc, libcamera2ndk, libdl, libGLES,
  libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++,
  libvulkan, and libz), plus libraries that are part of your app are accessible.
  
• For all other libraries you�ll see a warning in logcat and a toast on the
  display. This will happen only if your app�s targetSdkVersion is less than N. If
  you change your manifest to target N, loading will fail: Java�s
  System.loadLibrary will throw, and C/C++�s dlopen(3) will return NULL.

Test your apps on the Developer Preview — if you see a toast like this one, your app is accessing private native APIs. Please fix your code soon!

N Final Release behavior

• All NDK libraries (libandroid, libc, libcamera2ndk, libdl, libGLES,
  libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++,
  libvulkan, and libz), plus libraries that are part of your app are accessible.
  
• For the temporarily accessible libraries (such as libandroid_runtime.so,
  libcutils.so, libcrypto.so, and libssl.so), you�ll see a warning in logcat for
  all API levels before N, but loading will fail if you update your app so that
  its targetSdkVersion is N or later.
  
• Attempts to load any other libraries will fail in the final release of
  Android N, even if your app is targeting a pre-N platform version.

Future platform behavior

• In O, all access to the temporarily accessible libraries will be removed.
  As a result, you should plan to update your app regardless of your
  targetSdkVersion prior to O. If you believe there is missing functionality from
  the NDK API that will make it impossible for you to transition off a temporarily
  accessible library, please file a bug here.

What do the errors look like?

Here�s some example logcat output from an app that hasn�t bumped its target SDK
version (and so the restriction isn�t fully enforced because this is only the
developer preview):

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

This is telling you that your library �libapplib.so� refers to the library
�libandroid_runtime.so�, which is a private library.

When Android N ships, or if you set your target SDK version to N now, you�ll see
something like this if you try to use System.loadLibrary from Java:

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by "/system/lib/libnativeloader.so"
is not accessible for the namespace "classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

If you�re using href="http://man7.org/linux/man-pages/man3/dlopen.3.html">dlopen(3) from
C/C++ you�ll get a NULL return and href="http://man7.org/linux/man-pages/man3/dlerror.3.html">dlerror(3) will
return the same �dlopen failed...� string as shown above.

For more information about how to check if your app is using private symbols,
see the FAQ on developer.android.com.

Security "Crypto" provider deprecated in Android N

Posted by Sergio Giro, software engineer

If your Android app derives keys using the SHA1PRNG algorithm from the Crypto
provider, you must start using a real key derivation function and possibly re-encrypt your data.

The Java Cryptography Architecture allows developers to create an instance of a class like a cipher, or a pseudo-random number generator, using calls like:


SomeClass.getInstance("SomeAlgorithm", "SomeProvider");


Or simply:


SomeClass.getInstance("SomeAlgorithm");


For instance,


Cipher.getInstance(�AES/CBC/PKCS5PADDING�);


SecureRandom.getInstance(�SHA1PRNG�);


On Android, we don�t recommend specifying the provider. In general, any call to
the Java Cryptography Extension (JCE) APIs specifying a provider should only be
done if the provider is included in the application or if the application is
able to deal with a possible ProviderNotFoundException.

Unfortunately, many apps depend on the now removed �Crypto� provider for an
anti-pattern of key derivation.

This provider only provided an implementation of the algorithm �SHA1PRNG� for
instances of SecureRandom. The problem is that the SHA1PRNG algorithm is not
cryptographically strong. For readers interested in the details, On
statistical distance based testing of pseudo random sequences and experiments
with PHP and Debian OpenSSL,Section 8.1, by Yongge Want and Tony Nicol,
states that the �random� sequence, considered in binary form, is biased towards
returning 0s, and that the bias worsens depending on the seed.

As a result, in Android N we are deprecating the
implementation of the SHA1PRNG algorithm and the Crypto provider altogether.
We�d previously covered the issues with using SecureRandom for key derivation a
few years ago in href=http://android-developers.blogspot.com/2013/02/using-cryptography-to-store-credentials.html>Using
Cryptography to Store Credentials Safely. However, given its continued use,
we will revisit it here.

A common but incorrect usage of this provider was to derive keys for encryption
by using a password as a seed. The implementation of SHA1PRNG had a bug that
made it deterministic if setSeed() was called before obtaining output. This bug
was used to derive a key by supplying a password as a seed, and then using the
"random" output bytes for the key (where �random� in this sentence means
�predictable and cryptographically weak�). Such a key could then be used to
encrypt and decrypt data.

In the following, we explain how to derive keys correctly, and how to decrypt
data that has been encrypted using an insecure key. There�s also a
full example, including a helper class to use the deprecated SHA1PRNG
functionality, with the sole purpose of decrypting data that would be otherwise
unavailable.

Keys can be derived in the following way:

• If you're reading an AES key from disk, just store the actual key and don't go through this weird dance. You can get a SecretKey for AES usage from the bytes by doing:
  

  
  SecretKey key = new SecretKeySpec(keyBytes, "AES");
  



• If you're using a password to derive a key, follow href="http://nelenkov.blogspot.com/2012/04/using-password-based-encryption-on.html">Nikolay Elenkov's excellent tutorial with the caveat that a good rule of thumb is the salt size should be the same size as the key output. It looks like this:

   /* User types in their password: */  
   String password = "password";  

   /* Store these things on disk used to derive key later: */  
   int iterationCount = 1000;  
   int saltLength = 32; // bytes; should be the same size
              as the output (256 / 8 = 32)  
   int keyLength = 256; // 256-bits for AES-256, 128-bits for AES-128, etc  
   byte[] salt; // Should be of saltLength  

   /* When first creating the key, obtain a salt with this: */  
   SecureRandom random = new SecureRandom();  
   byte[] salt = new byte[saltLength];  
   random.nextBytes(salt);  

   /* Use this to derive the key from the password: */  
   KeySpec keySpec = new PBEKeySpec(password.toCharArray(), salt,  
              iterationCount, keyLength);  
   SecretKeyFactory keyFactory = SecretKeyFactory  
              .getInstance("PBKDF2WithHmacSHA1");  
   byte[] keyBytes = keyFactory.generateSecret(keySpec).getEncoded();  
   SecretKey key = new SecretKeySpec(keyBytes, "AES");  

That's it. You should not need anything else.

To make transitioning data easier, we covered the case of developers that have
data encrypted with an insecure key, which is derived from a password every
time. You can use the helper class InsecureSHA1PRNGKeyDerivator in
the example app to derive the key.

 private static SecretKey deriveKeyInsecurely(String password, int
 keySizeInBytes) {  
    byte[] passwordBytes = password.getBytes(StandardCharsets.US_ASCII);  
    return new SecretKeySpec(  
            InsecureSHA1PRNGKeyDerivator.deriveInsecureKey(  
                     passwordBytes, keySizeInBytes),  
            "AES");  
 }  

You can then re-encrypt your data with a securely derived key as explained
above, and live a happy life ever after.

Note 1: as a temporary measure to keep apps working, we decided to still create
the instance for apps targeting SDK version 23, the SDK version for Marshmallow,
or less. Please don't rely on the presence of the Crypto provider in the Android
SDK, our plan is to delete it completely in the future.

Note 2: Because many parts of the system assume the existence of a SHA1PRNG
algorithm, when an instance of SHA1PRNG is requested and the provider is not
specified we return an instance of OpenSSLRandom, which is a strong source of
random numbers derived from OpenSSL.