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:

• Apps that are running in the background now have limits on how freely they can access background services.
• Apps cannot use their manifests to register for most implicit broadcasts (that is, broadcasts that are not targeted specifically at the app).

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:

• The startService() method now throws an IllegalStateException if an app targeting Android 8.0 tries to use that method in a situation when it isn't permitted to create background services.
• The new Context.startForegroundService() method starts a foreground service. The system allows apps to call Context.startForegroundService() even while the app is in the background. However, the app must call that service's startForeground() method within five seconds after the service is created.

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:

• Fused Location Provider (FLP)
• Geofencing
• GNSS Measurements
• Location Manager
• Wi-Fi Manager

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

• Review your app's logic and ensure that you're using the latest location APIs.
• Test that your app exhibits the behavior that you expect for each use case.
• Consider using the Fused Location Provider (FLP) or geofencing to handle the use cases that depend on the user's current location.

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:

• The com.android.launcher.action.INSTALL_SHORTCUT broadcast no longer has any effect on your app, because it is now a private, implicit broadcast. Instead, you should create an app shortcut by using the requestPinShortcut() method from the ShortcutManager class.
• The ACTION_CREATE_SHORTCUT intent can now create app shortcuts that you manage using the ShortcutManager class. This intent can also create legacy launcher shortcuts that don't interact with ShortcutManager. Previously, this intent could create only legacy launcher shortcuts.
• Shortcuts created using requestPinShortcut() and shortcuts created in an activity that handles the ACTION_CREATE_SHORTCUT intent are now fully-fledged app shortcuts. As a result, apps can now update them using the methods in ShortcutManager.
• Legacy shortcuts retain their functionality from previous versions of Android, but you must convert them to app shortcuts manually in your app.

To learn more about changes to app shortcuts, see the Pinning Shortcuts and Widgetsfeature 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():

• Currency.getDisplayName()
• Currency.getSymbol()
• Locale.getDisplayScript()

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

Additional locale and internationalization-related changes are as follows:

• Calling Currency.getDisplayName(null) throws a NullPointerException, matching the documented behavior.
• Time zone name parsing has changed. Previously, Android devices used the system clock value sampled at boot time to cache the time zone names used for parsing date times. As a result, parsing could be negatively affected if the system clock was wrong at boot time or in other, rarer cases.
  Now, in common cases the parsing logic uses ICU and the current system clock value when parsing time zone names. This change provides more correct results, which may differ from earlier Android versions when your app uses classes likeSimpleDateFormat.
• Android 8.0 (API level 26) updates the version of ICU to version 58.

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:

• TYPE_PHONE
• TYPE_PRIORITY_PHONE
• TYPE_SYSTEM_ALERT
• TYPE_SYSTEM_OVERLAY
• TYPE_SYSTEM_ERROR

...then these windows always appear beneath the windows that use theTYPE_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:

• If you haven't defined any focus state colors for a View object (either its foreground or background drawable), the framework now sets a default focus highlight color for theView. This focus highlight is a ripple drawable that's based on the activity's theme.
  If you don't want a View object to use this default highlight when it receives focus, set the android:defaultFocusHighlightEnabled attribute to false in the layout XML file containing the View, or pass in false to setDefaultFocusHighlightEnabled()in your app's UI logic.
• To test how keyboard input affects UI element focus, you can enable the Drawing > Show layout bounds developer option. In Android 8.0, this option displays an "X" icon over the element that currently has focus.

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):

WebSettings

• The getSaveFormData() method now returns false. Previously, this method returned true instead.
• Calling setSaveFormData() no longer has any effect.

WebViewDatabase

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