The Android Q platform includes behavior changes that may affect your app.
The following behavior changes apply exclusively to apps that are targeting
Android Q or higher. If your app sets
targetSdkVersion to "android-Q" or
higher, you should modify your app to support these behaviors properly, where applicable.
Make sure to also review the list of behavior changes that affect all apps running on Android Q.
Updates to non-SDK interface restrictions
To help ensure app stability and compatibility, the platform started restricting which non-SDK interfaces your app can use in Android 9 (API level 28). Android Q includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing.
If you will not be targeting Android Q, some of these changes might not immediately affect you. However, while you can currently use non-SDK interfaces that are part of the greylist (depending on your app's target API level), using any non-SDK method or field always carries a high risk of breaking your app.
If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.
To learn more, see Updates to non-SDK interface restrictions in Android Q and see Restrictions on non-SDK interfaces.
Ashmem has changed the format of dalvik maps in /proc/<pid>/maps, affecting apps that directly parse the maps file. Application developers should test the new /proc/<pid>/maps format on devices and parse accordingly if the app depends on dalvik map formats.
Apps targeting Q can no longer directly use ashmem (/dev/ashmem) and must
instead access shared memory via the NDK’s
In addition, apps cannot make direct IOCTLs to existing ashmem file descriptors
and must instead use either the NDK’s
ASharedMemory class or the Android Java
APIs for creating shared memory regions. This change increases security and
robustness when working with shared memory, improving performance and security
of Android overall.
Android runtime only accepts system-generated OAT files
The Android runtime (ART) no longer invokes
dex2oat from the application
process. This change means that the ART will only accept OAT files that the
system has generated.
Enforcing AOT correctness in ART
In the past, the ahead-of-time (AOT) compilation performed by the Android Runtime (ART) could cause runtime crashes if the classpath environment was not the same at compile time and runtime. Android Q now always requires these environment contexts to be the same, resulting in the following changes in behavior:
- Custom class loaders--that is, class loaders written by apps, unlike class loaders from the dalvik.system package--are not AOT-compiled. This is because ART cannot know about customized class lookup implementation at runtime.
- Secondary dex files--that is, the dex files loaded manually by apps not in the primary APK--are now AOT-compiled in the background, as first-use compilation might be too expensive, leading to unwanted latency before execution. Note that for apps, adopting splits and moving away from secondary dex files is recommended.
- Shared libraries in Android (the entries <library> and <uses-library> in an Android manifest) are now implemented with a new class loader hierarchy.
Permissions changes for fullscreen intents
Apps that target Android Q or higher and use notifications with fullscreen
intents must request the
in their app's manifest file. This is a normal permission, so the system automatically
grants it to the requesting app.
If an app that targets Android Q or higher attempts to create a notification
with a fullscreen intent without requesting the
the system ignores the fullscreen intent and outputs the following log message:
Package [pkg]: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT