Skip to content

Most visited

Recently visited


Android 8.0 Behavior Changes

Along with new features and capabilities, Android 8.0 (API level 26) 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.

Most of these changes affect all apps, regardless of what version of Android they target. However, several changes only affect apps targeting Android 8.0. To maximize clarity, this page is divided into two sections: Changes for all apps and Changes for apps targeting Android 8.0.

Changes for all apps

These behavior changes apply to all apps when they run on the Android 8.0 (API level 26) platform, regardless of the API level that they target. All developers should review these changes and modify their apps to support them properly, where applicable to the app.

Background execution limits

As one of the changes that Android 8.0 (API level 26) introduces to improve battery life, when your app enters the cached state, with no active components, the system releases any wakelocks that the app holds.

In addition, to improve device performance, the system limits certain behaviors by apps that are not running in the foreground. Specifically:

By default, these restrictions only apply to apps that target O. However, users can enable these restrictions for any app from the Settings screen, even if the app has not targetted O.

Android 8.0 (API level 26) also includes the following changes to specific methods:

For more information, see Background Execution Limits.

Android background location limits

In order to preserve battery, user experience, and system health, background apps receive location updates less frequently when used on a device running Android 8.0. This behavior change affects all apps that receive location updates, including Google Play services.

These changes affect the following APIs:

To ensure that your app runs as expected, complete the following steps:

For more information about these changes, see Background Location Limits.

App shortcuts

Android 8.0 (API level 26) includes the following changes to app shortcuts:

To learn more about changes to app shortcuts, see the Pinning Shortcuts and Widgets feature guide.

Locales and internationalization

Android 7.0 (API level 24) introduced the concept of being able to specify a default Category Locale, but some APIs continued to use the generic Locale.getDefault() method, without arguments, when they should have instead used default DISPLAY category Locale. In Android 8.0 (API level 26), the following methods now use Locale.getDefault(Category.DISPLAY) instead of Locale.getDefault():

Locale.getDisplayScript(Locale) also falls back to Locale.getDefault() when the displayScript value specified for the Locale argument is not available.

Additional locale and internationalization-related changes are as follows:

Alert windows

If an app uses the SYSTEM_ALERT_WINDOW permission and uses one of the following window types to attempt to display alert windows above other apps and system windows:

...then these windows always appear beneath the windows that use the TYPE_APPLICATION_OVERLAY window type. If an app targets Android 8.0 (API level 26), the app uses the TYPE_APPLICATION_OVERLAY window type to display alert windows.

For more information, see the Common window types for alert windows section within the behavior changes for Apps targeting Android 8.0.

Input and navigation

With the advent of Android apps on Chrome OS and other large form factors, such as tablets, we're seeing a resurgence of keyboard navigation use within Android apps. Within Android 8.0 (API level 26), we've re-addressed using the keyboard as a navigation input device, resulting in a more reliable, predictable model for arrow- and tab-based navigation.

In particular, we've made the following changes to element focus behavior:

Also, all toolbar elements in Android 8.0 are automatically keyboard navigation clusters, making it easier for users to navigate into and out of each toolbar as a whole.

To learn more about how to improve support for keyboard navigation within your app, read the Supporting Keyboard Navigation guide.

Web form autofill

Now that the Android Autofill Framework provides built-in support for autofill functionality, the following methods related to WebView objects have changed for apps installed on devices running Android 8.0 (API level 26):

  • Calling clearFormData() no longer has any effect.
  • The hasFormData() method now returns false. Previously, this method returned true when the form contained data.


Android 8.0 (API level 26) includes the following changes to accessibility:

To learn more about how to make your app more accessible, see Accessibility.

Networking and HTTP(S) connectivity

Android 8.0 (API level 26) includes the following behavior changes to networking and HTTP(S) connectivity:


Android 8.0 (API level 26) makes the following changes to the length of the data that the ScanRecord.getBytes() method retrieves:

Seamless Connectivity

Android 8.0 (API level 26) makes a number of improvements to Wi-Fi Settings to make it easier to choose the Wi-Fi network that offers the best user experience. Specific changes include:


Android 8.0 includes the following security-related changes:

In addition, Android 8.0 (API level 26) introduces the following changes related to installing unknown apps from unknown sources:

For additional details about installing unknown apps, see the Unknown App Install Permissions guide.

For additional guidelines on making your app more secure, see Security for Android Developers.


Android 8.0 (API level 26) makes the following privacy-related changes to the platform.

Logging of uncaught exceptions

If an app installs a Thread.UncaughtExceptionHandler that does not call through to the default Thread.UncaughtExceptionHandler, the system does not kill the app when an uncaught exception occurs. Starting from Android 8.0 (API level 26), the system logs the exception stacktrace in this situation; in earlier versions of the platform, the system would not have logged the exception stacktrace.

We recommend that custom Thread.UncaughtExceptionHandler implementations always call through to the default handler; apps that follow this recommendation are unaffected by the change in Android 8.0.

findViewById() signature change

All instances of the findViewById() method now return <T extends View> T instead of View. This change has the following implications:

Contacts provider usage stats change

In previous versions of Android, the Contacts Provider component allows developers to get usage data for each contact. This usage data exposes information for each email address and each phone number associated with a contact, including the number of times the contact has been contacted and the last time the contact was contacted. Apps that request the READ_CONTACTS permission can read this data.

Apps can still read this data if they request READ_CONTACTS permission. In Android 8.0 (API level 26) and higher, queries for usage data return approximations rather than exact values. The Android system maintains the exact values internally, so this change does not affect the auto-complete API.

This behavior change affects the following query parameters:

Collection handling

AbstractCollection.removeAll() and AbstractCollection.retainAll() now always throw a NullPointerException; previously, the NullPointerException was not thrown when the collection was empty. This change makes the behavior consistent with the documentation.

Android enterprise

Android 8.0 (API level 26) changes the behavior of some APIs and features for enterprise apps, including device policy controllers (DPCs). The changes include:

To see the all the enterprise changes in Android 8.0 (API level 26) and learn how they might affect your app, read Android in the Enterprise.

Apps targeting Android 8.0

These behavior changes apply exclusively to apps that are targeting Android 8.0 (API level 26) or higher. Apps that compile against Android 8.0, or set targetSdkVersion to Android 8.0 or higher must modify their apps to support these behaviors properly, where applicable to the app.

Alert windows

Apps that use the SYSTEM_ALERT_WINDOW permission can no longer use the following window types to display alert windows above other apps and system windows:

Instead, apps must use a new window type called TYPE_APPLICATION_OVERLAY.

When using the TYPE_APPLICATION_OVERLAY window type to display alert windows for your app, keep the following characteristics of the new window type in mind:

Content change notifications

Android 8.0 (API level 26) changes how ContentResolver.notifyChange() and registerContentObserver(Uri, boolean, ContentObserver) behave for apps targeting Android 8.0.

These APIs now require that a valid ContentProvider is defined for the authority in all Uris. Defining a valid ContentProvider with relevant permissions will help defend your app against content changes from malicious apps, and prevent you from leaking potentially private data to malicious apps.

View focus

Clickable View objects are now also focusable by default. If you want a View object to be clickable but not focusable, set the android:focusable attribute to false in the layout XML file containing the View, or pass in false to setFocusable() in your app's UI logic.


The following changes affect security in Android 8.0 (API level 26):

For additional guidelines on making your app more secure, see Security for Android Developers.

Account access and discoverability

In Android 8.0 (API level 26), apps can no longer get access to user accounts unless the authenticator owns the accounts or the user grants that access. The GET_ACCOUNTS permission is no longer sufficient. To be granted access to an account, apps should either use AccountManager.newChooseAccountIntent() or an authenticator-specific method. After getting access to accounts, an app can can call AccountManager.getAccounts() to access them.

Android 8.0 deprecates LOGIN_ACCOUNTS_CHANGED_ACTION. Apps should instead use addOnAccountsUpdatedListener() to get updates about accounts during runtime.

For information about new APIs and methods added for account access and discoverability, see Account Access and Discoverability in the New APIs section of this document.


The following changes affect privacy in Android 8.0 (API level 26).


Prior to Android 8.0 (API level 26), if an app requested a permission at runtime and the permission was granted, the system also incorrectly granted the app the rest of the permissions that belonged to the same permission group, and that were registered in the manifest.

For apps targeting Android 8.0, this behavior has been corrected. The app is granted only the permissions it has explicitly requested. However, once the user grants a permission to the app, all subsequent requests for permissions in that permission group are automatically granted.

For example, suppose an app lists both READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE in its manifest. The app requests READ_EXTERNAL_STORAGE and the user grants it. If the app targets API level 25 or lower, the system also grants WRITE_EXTERNAL_STORAGE at the same time, because it belongs to the same STORAGE permission group and is also registered in the manifest. If the app targets Android 8.0 (API level 26), the system grants only READ_EXTERNAL_STORAGE at that time; however, if the app later requests WRITE_EXTERNAL_STORAGE, the system immediately grants that privilege without prompting the user.


Native libraries

In apps targeting Android 8.0 (API level 26), native libraries no longer load if they contain any load segment that is both writable and executable. Some apps might stop working because of this change if they have native libraries with incorrect load segments. This is a security-hardening measure.

For more information, see Writable and Executable Segments.

Linker changes are tied to the API level that an app targets. If there is a linker change at the targeted API level, the app cannot load the library. If you are targeting an API level lower than the API level where the linker change occurs, logcat shows a warning.

Collection handling

In Android 8.0 (API level 26), Collections.sort() is implemented on top of List.sort(). The reverse was true in Android 7.x (API levels 24 and 25): The default implementation of List.sort() called Collections.sort().

This change allows Collections.sort() to take advantage of optimized List.sort() implementations, but has the following constraints:

Class-loading behavior

Android 8.0 (API level 26) checks to make sure that class loaders do not break the assumptions of the runtime when loading new classes. These checks are performed whether the class is referenced from Java (from forName()), Dalvik bytecode, or JNI. The platform does not intercept direct calls from Java to the loadClass() method, nor does it check the results of such calls. This behavior should not affect the functioning of well-behaved class loaders.

The platform checks that the descriptor of the class that the class loader returns matches the expected descriptor. If the returned descriptor does not match, the platform throws a NoClassDefFoundError error, and stores in the exception a detailed message noting the discrepancy.

The platform also checks that the descriptors of the requested classes are valid. This check catches JNI calls that indirectly load classes such as GetFieldID(), passing invalid descriptors to those classes. For example, a field with signature java/lang/String is not found because that signature is invalid; it should be Ljava/lang/String;.

This is different from a JNI call to FindClass() where java/lang/String is a valid fully-qualified name.

Android 8.0 (API level 26) does not support having multiple class loaders try to define classes using the same DexFile object. An attempt to do so causes the Android runtime to throw an InternalError error with the message "Attempt to register dex file <filename> with multiple class loaders".

DexFile API is now deprecated, and you are strongly encouraged to use one of the platform classloaders, including PathClassLoader or BaseDexClassLoader, instead.

Note: You can create multiple class loaders that reference the same APK or JAR file container from the file system. Doing so normally does not result in much memory overhead: If DEX files in the container are stored instead of compressed, the platform can perform an mmap operation on them rather than directly extracting them. However, if the platform must extract the DEX file from the container, referencing a DEX file in this fashion may consume a lot of memory.

In Android, all class loaders are considered parallel-capable. When multiple threads race to load the same class with the same class loader, the first thread to complete the operation wins, and the result is used for the other threads. This behavior occurs regardless of whether the class loader has returned the same class, returned a different class, or thrown an exception. The platform silently ignores such exceptions.

Caution: In versions of the platform lower than Android 8.0 (API level 26), breaking these assumptions can lead to defining the same class multiple times, heap corruption due to class confusion, and other undesirable effects.

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)