Skip to content

Most visited

Recently visited


Android 7.0 Behavior Changes

Along with new features and capabilities, Android 7.0 includes a variety of system and API behavior changes. This document highlights some of the key changes that you should understand and account for in your apps.

If you have previously published an app for Android, be aware that your app might be affected by these changes in the platform.

Battery and Memory

Android 7.0 includes system behavior changes aimed at improving the battery life of devices and reducing RAM usage. These changes can affect your app’s access to system resources, along with the way your app interacts with other apps via certain implicit intents.


Introduced in Android 6.0 (API level 23), Doze improves battery life by deferring CPU and network activities when a user leaves a device unplugged, stationary, and with the screen turned off. Android 7.0 brings further enhancements to Doze by applying a subset of CPU and network restrictions while the device is unplugged with the screen turned off, but not necessarily stationary, for example, when a handset is traveling in a user’s pocket.

Figure 1. Illustration of how Doze applies a first level of system activity restrictions to improve battery life.

When a device is on battery power, and the screen has been off for a certain time, the device enters Doze and applies the first subset of restrictions: It shuts off app network access, and defers jobs and syncs. If the device is stationary for a certain time after entering Doze, the system applies the rest of the Doze restrictions to PowerManager.WakeLock, AlarmManager alarms, GPS, and Wi-Fi scans. Regardless of whether some or all Doze restrictions are being applied, the system wakes the device for brief maintenance windows, during which applications are allowed network access and can execute any deferred jobs/syncs.

Figure 2. Illustration of how Doze applies a second level of system activity restrictions after the device is stationary for a certain time.

Note that activating the screen on or plugging in the device exits Doze and removes these processing restrictions. The additional behavior does not affect recommendations and best practices in adapting your app to the prior version of Doze introduced in Android 6.0 (API level 23), as discussed in Optimizing for Doze and App Standby. You should still follow those recommendations, such as using Firebase Cloud Messaging (FCM) to send and receive messages, and start planning updates to accommodate the additional Doze behavior.

Project Svelte: Background Optimizations

Android 7.0 removes three implicit broadcasts in order to help optimize both memory use and power consumption. This change is necessary because implicit broadcasts frequently start apps that have registered to listen for them in the background. Removing these broadcasts can substantially benefit device performance and user experience.

Mobile devices experience frequent connectivity changes, such as when moving between Wi-Fi and mobile data. Currently, apps can monitor for changes in connectivity by registering a receiver for the implicit CONNECTIVITY_ACTION broadcast in their manifest. Since many apps register to receive this broadcast, a single network switch can cause them all to wake up and process the broadcast at once.

Similarly, in previous versions of Android, apps could register to receive implicit ACTION_NEW_PICTURE and ACTION_NEW_VIDEO broadcasts from other apps, such as Camera. When a user takes a picture with the Camera app, these apps wake up to process the broadcast.

To alleviate these issues, Android 7.0 applies the following optimizations:

If your app uses any of these intents, you should remove dependencies on them as soon as possible so that you can target Android 7.0 devices properly. The Android framework provides several solutions to mitigate the need for these implicit broadcasts. For example, the JobScheduler API provides a robust mechanism to schedule network operations when specified conditions, such as connection to an unmetered network, are met. You can even use JobScheduler to react to changes to content providers.

For more information about background optimizations in Android 7.0 (API level 24) and how to adapt your app, see Background Optimizations.

Permissions Changes

Android 7.0 includes changes to permissions that may affect your app.

File system permission changes

In order to improve the security of private files, the private directory of apps targeting Android 7.0 or higher has restricted access (0700). This setting prevents leakage of metadata of private files, such as their size or existence. This permission change has multiple side effects:

Sharing Files Between Apps

For apps targeting Android 7.0, the Android framework enforces the StrictMode API policy that prohibits exposing file:// URIs outside your app. If an intent containing a file URI leaves your app, the app fails with a FileUriExposedException exception.

To share files between applications, you should send a content:// URI and grant a temporary access permission on the URI. The easiest way to grant this permission is by using the FileProvider class. For more information on permissions and sharing files, see Sharing Files.

Accessibility Improvements

Android 7.0 includes changes intended to improve the usability of the platform for users with low or impaired vision. These changes should generally not require code changes in your app, however you should review these feature and test them with your app to assess potential impacts to user experience.

Screen Zoom

Android 7.0 enables users to set Display size which magnifies or shrinks all elements on the screen, thereby improving device accessibility for users with low vision. Users cannot zoom the screen past a minimum screen width of sw320dp, which is the width of a Nexus 4, a common medium-sized phone.

Figure 3. The screen on the right shows the effect of increasing the Display size of a device running an Android 7.0 system image.

When the device density changes, the system notifies running apps in the following ways:

Most apps do not need to make any changes to support this feature, provided the apps follow Android best practices. Specific things to check for:

Vision Settings in Setup Wizard

Android 7.0 includes Vision Settings on the Welcome screen, where users can set up the following accessibility settings on a new device: Magnification gesture, Font size, Display size and TalkBack. This change increases the visibility of bugs related to different screen settings. To assess the impact of this feature, you should test your apps with these settings enabled. You can find the settings under Settings > Accessibility.

NDK Apps Linking to Platform Libraries

Starting in Android 7.0, the system prevents apps from dynamically linking against non-NDK libraries, which may cause your app to crash. This change in behavior aims to create a consistent app experience across platform updates and different devices. Even though your code might not be linking against private libraries, it's possible that a third-party static library in your app could be doing so. Therefore, all developers should check to make sure that their apps do not crash on devices running Android 7.0. If your app uses native code, you should only be using public NDK APIs.

There are three ways your app might be trying to access private platform APIs:

Apps should not use native libraries that are not included in the NDK because they may change or be removed between different versions of Android. The switch from OpenSSL to BoringSSL is an example of such a change. Also, because there are no compatibility requirements for platform libraries not included in the NDK, different devices may offer different levels of compatibility.

In order to reduce the impact that this restriction may have on currently released apps, a set of libraries that see significant use—such as,,, and—are temporarily accessible on Android 7.0 (API level 24) for apps targeting API level 23 or lower. If your app loads one of these libraries, logcat generates a warning and a toast appears on the target device to notify you. If you see these warnings, you should update your app to either include its own copy of those libraries or only use the public NDK APIs. Future releases of the Android platform may restrict the use of private libraries altogether and cause your app to crash.

All apps generate a runtime error when they call an API that is neither public nor temporarily accessible. The result is that System.loadLibrary and dlopen(3) both return NULL, and may cause your app to crash. You should review your app code to remove use of private platform APIs and thoroughly test your apps using a device or emulator running Android 7.0 (API level 24). If you are unsure whether your app uses private libraries, you can check logcat to identify the runtime error.

The following table describes the behavior you should expect to see from an app depending on its use of private native libraries and its target API level (android:targetSdkVersion).

Libraries Target API level Runtime access via dynamic linker Android 7.0 (API level 24) behavior Future Android platform behavior
NDK Public Any Accessible Works as expected Works as expected
Private (temporarily accessible private libraries) 23 or lower Temporarily accessible Works as expected, but you receive a logcat warning. Runtime error
Private (temporarily accessible private libraries) 24 or higher Restricted Runtime error Runtime error
Private (other) Any Restricted Runtime error Runtime error

Check if your app uses private libraries

To help you identify issues loading private libraries, logcat may generate a warning or runtime error. For example, if your app targets API level 23 or lower, and tries to access a private library on a device running Android 7.0, you may see a warning similar to the following:

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

These logcat warnings tell you which which library is trying to access a private platform API, but will not cause your app to crash. If the app targets API level 24 or higher, however, logcat generates the following runtime error and your app may crash:

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

You may also see these logcat outputs if your app uses third-party libraries that dynamically link to private platform APIs. The readelf tool in the Android 7.0DK allows you to generate a list of all dynamically linked shared libraries of a given .so file by running the following command:

aarch64-linux-android-readelf -dW

Update your app

Here are some steps you can take to fix these types of errors and make sure your app doesn't crash on future platform updates:

Android for Work

Android 7.0 contains changes for apps that target Android for Work, including changes to certificate installation, password resetting, secondary user management, and access to device identifiers. If you are building apps for Android for Work environments, you should review these changes and modify your app accordingly.

For more information about changes to Android for Work in Android 7.0, see Android for Work Updates.

Annotations Retention

Android 7.0 fixes a bug where the visibility of annotations was being ignored. This issue enabled the runtime to access annotations that it should not have been able to. These annotations included:

If your app has relied on this behavior, please add a retention policy to annotations that must be available at runtime. You do so by using @Retention(RetentionPolicy.RUNTIME).

TLS/SSL Default Configuration Changes

Android 7.0 makes the following changes to the default TLS/SSL configuration used by apps for HTTPS and other TLS/SSL traffic:

RC4 being disabled by default may lead to breakages in HTTPS or TLS/SSL connectivity when the server does not negotiate modern cipher suites. The preferred fix is to improve the server’s configuration to enable stronger and more modern cipher suites and protocols. Ideally, TLSv1.2 and AES-GCM should be enabled, and Forward Secrecy cipher suites (ECDHE) should be enabled and preferred.

An alternative is to modify the app to use a custom SSLSocketFactory to communicate with the server. The factory should be designed to create SSLSocket instances that have some of the cipher suites required by the server enabled in addition to default cipher suites.

Note: These changes do not pertain to WebView.

Other Important Points

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields


Follow Google Developers on WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience. (April 2018 — Developer Survey)