Zmiany zachowania: aplikacje kierowane na Androida 14 lub nowszego

Podobnie jak w poprzednich wersjach, Android 14 zawiera zmiany w działaniu, które mogą mieć do aplikacji. Opisane poniżej zmiany w działaniu dotyczą tylko aplikacji, które: są kierowane na Androida 14 (poziom interfejsu API 34) lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 14 lub wyższego, należy zmodyfikować aplikację, aby obsługiwała te zachowania. w odpowiednich przypadkach.

Zapoznaj się też z listą zmian w zachowaniu, które wpływają na wszystkie aplikacje działające na Androidzie 14, niezależnie od ich targetSdkVersion.

Główna funkcja

Wymagane są typy usług działających na pierwszym planie

If your app targets Android 14 (API level 34) or higher, it must specify at least one foreground service type for each foreground service within your app. You should choose a foreground service type that represents your app's use case. The system expects foreground services that have a particular type to satisfy a particular use case.

If a use case in your app isn't associated with any of these types, it's strongly recommended that you migrate your logic to use WorkManager or user-initiated data transfer jobs.

Egzekwowanie uprawnień BLUETOOTH_CONNECT w aplikacji BluetoothAdapter

Android 14 enforces the BLUETOOTH_CONNECT permission when calling the BluetoothAdapter getProfileConnectionState() method for apps targeting Android 14 (API level 34) or higher.

This method already required the BLUETOOTH_CONNECT permission, but it was not enforced. Make sure your app declares BLUETOOTH_CONNECT in your app's AndroidManifest.xml file as shown in the following snippet and check that a user has granted the permission before calling getProfileConnectionState.

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

Aktualizacje OpenJDK 17

Android 14 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases, including both library updates and Java 17 language support for app and platform developers.

A few of these changes can affect app compatibility:

  • Changes to regular expressions: Invalid group references are now disallowed to more closely follow the semantics of OpenJDK. You might see new cases where an IllegalArgumentException is thrown by the java.util.regex.Matcher class, so make sure to test your app for areas that use regular expressions. To enable or disable this change while testing, toggle the DISALLOW_INVALID_GROUP_REFERENCE flag using the compatibility framework tools.
  • UUID handling: The java.util.UUID.fromString() method now does more strict checks when validating the input argument, so you might see an IllegalArgumentException during deserialization. To enable or disable this change while testing, toggle the ENABLE_STRICT_VALIDATION flag using the compatibility framework tools.
  • ProGuard issues: In some cases, the addition of the java.lang.ClassValue class causes an issue if you try to shrink, obfuscate, and optimize your app using ProGuard. The problem originates with a Kotlin library that changes runtime behaviour based on whether Class.forName("java.lang.ClassValue") returns a class or not. If your app was developed against an older version of the runtime without the java.lang.ClassValue class available, then these optimizations might remove the computeValue method from classes derived from java.lang.ClassValue.

JobScheduler wzmacnia wywołanie zwrotne i zachowanie sieci

Od momentu wprowadzenia JobScheduler oczekuje, że aplikacja wróci z onStartJob lub onStopJob w ciągu kilku sekund. Przed Androidem 14 Jeśli zadanie będzie działać zbyt długo, zostanie zatrzymane, a jego wykonanie zakończy się dyskretnie. Jeśli Twoja aplikacja jest kierowana na Androida 14 (poziom interfejsu API 34) lub nowszego przekracza ustalony czas w wątku głównym, aplikacja wywołuje błąd ANR z komunikatem o błędzie „Brak odpowiedzi dla: onStartJob”. lub „Brak odpowiedzi na: onStopJob”.

Przyczyną tego błędu ANR mogą być 2 sytuacje: 1. Istnieje praca blokująca wątek główny, która uniemożliwia wywołania zwrotne onStartJob lub onStopJob od wykonania i ukończenia w oczekiwanym czasie. 2. Deweloper realizuje prace blokujące w harmonogramie zadań oddzwanianie onStartJob lub onStopJob, co uniemożliwia oddzwonienie z w oczekiwanym czasie.

Aby rozwiązać problem 1, musisz dokładniej debugować, co blokuje wątek główny. po wystąpieniu błędu ANR możesz to zrobić, korzystając z funkcji ApplicationExitInfo#getTraceInputStream(), aby zdobyć nagrobek śledzić, gdy wystąpi błąd ANR. Jeśli możesz ręcznie odtworzyć błąd ANR, możesz zarejestrować ślad systemu i sprawdzić go za pomocą Android Studio lub Perfetto, aby lepiej zrozumieć, co działa na w wątku głównym, gdy wystąpi błąd ANR. Pamiętaj, że może się to zdarzyć, gdy używasz interfejsu JobScheduler API bezpośrednio lub biblioteki androidx WorkManager.

Aby rozwiązać problem 2, rozważ migrację do WorkManagera, który obsługuje owinięcie dowolnego przetwarzania w onStartJob lub onStopJob w wątku asynchronicznym.

JobScheduler nakłada również wymóg deklarowania uprawnienia ACCESS_NETWORK_STATE, jeśli używasz setRequiredNetworkType lub Ograniczenie setRequiredNetwork. Jeśli podczas planowania zadania aplikacja nie deklaruje uprawnienia ACCESS_NETWORK_STATE i jest kierowana na Androida 14 lub nowszego, otrzymasz błąd SecurityException.

Interfejs API uruchamiania kafelków

For apps targeting 14 and higher, TileService#startActivityAndCollapse(Intent) is deprecated and now throws an exception when called. If your app launches activities from tiles, use TileService#startActivityAndCollapse(PendingIntent) instead.

Prywatność

Częściowy dostęp do zdjęć i filmów

Android 14 introduces Selected Photos Access, which allows users to grant apps access to specific images and videos in their library, rather than granting access to all media of a given type.

This change is only enabled if your app targets Android 14 (API level 34) or higher. If you don't use the photo picker yet, we recommend implementing it in your app to provide a consistent experience for selecting images and videos that also enhances user privacy without having to request any storage permissions.

If you maintain your own gallery picker using storage permissions and need to maintain full control over your implementation, adapt your implementation to use the new READ_MEDIA_VISUAL_USER_SELECTED permission. If your app doesn't use the new permission, the system runs your app in a compatibility mode.

Interfejs użytkownika

Bezpieczne powiadomienia dotyczące intencji pełnoekranowej

With Android 11 (API level 30), it was possible for any app to use Notification.Builder.setFullScreenIntent to send full-screen intents while the phone is locked. You could auto-grant this on app install by declaring USE_FULL_SCREEN_INTENT permission in the AndroidManifest.

Full-screen intent notifications are designed for extremely high-priority notifications demanding the user's immediate attention, such as an incoming phone call or alarm clock settings configured by the user. For apps targeting Android 14 (API level 34) or higher, apps that are allowed to use this permission are limited to those that provide calling and alarms only. The Google Play Store revokes default USE_FULL_SCREEN_INTENT permissions for any apps that don't fit this profile. The deadline for these policy changes is May 31, 2024.

This permission remains enabled for apps installed on the phone before the user updates to Android 14. Users can turn this permission on and off.

You can use the new API NotificationManager.canUseFullScreenIntent to check if your app has the permission; if not, your app can use the new intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT to launch the settings page where users can grant the permission.

Bezpieczeństwo

Ograniczenia intencji niewyrażonych i oczekujących

For apps targeting Android 14 (API level 34) or higher, Android restricts apps from sending implicit intents to internal app components in the following ways:

  • Implicit intents are only delivered to exported components. Apps must either use an explicit intent to deliver to unexported components, or mark the component as exported.
  • If an app creates a mutable pending intent with an intent that doesn't specify a component or package, the system throws an exception.

These changes prevent malicious apps from intercepting implicit intents that are intended for use by an app's internal components.

For example, here is an intent filter that could be declared in your app's manifest file:

<activity
    android:name=".AppActivity"
    android:exported="false">
    <intent-filter>
        <action android:name="com.example.action.APP_ACTION" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

If your app tried to launch this activity using an implicit intent, an ActivityNotFoundException exception would be thrown:

Kotlin

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(Intent("com.example.action.APP_ACTION"))

Java

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(new Intent("com.example.action.APP_ACTION"));

To launch the non-exported activity, your app should use an explicit intent instead:

Kotlin

// This makes the intent explicit.
val explicitIntent =
        Intent("com.example.action.APP_ACTION")
explicitIntent.apply {
    package = context.packageName
}
context.startActivity(explicitIntent)

Java

// This makes the intent explicit.
Intent explicitIntent =
        new Intent("com.example.action.APP_ACTION")
explicitIntent.setPackage(context.getPackageName());
context.startActivity(explicitIntent);

Odbiorniki transmisji zarejestrowane w czasie wykonywania muszą określać zachowanie eksportu

Apps and services that target Android 14 (API level 34) or higher and use context-registered receivers are required to specify a flag to indicate whether or not the receiver should be exported to all other apps on the device: either RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED, respectively. This requirement helps protect apps from security vulnerabilities by leveraging the features for these receivers introduced in Android 13.

Exception for receivers that receive only system broadcasts

If your app is registering a receiver only for system broadcasts through Context#registerReceiver methods, such as Context#registerReceiver(), then it shouldn't specify a flag when registering the receiver.

Bezpieczniejsze wczytywanie kodu dynamicznego

Jeśli Twoja aplikacja jest kierowana na Androida 14 (API na poziomie 34) lub nowszego i korzysta z dynamicznego ładowania kodu (DCL), wszystkie ładowane dynamicznie pliki muszą być oznaczone jako tylko do odczytu. W przeciwnym razie system zgłasza wyjątek. Zalecamy, aby w miarę możliwości nie wczytywać kodu dynamicznie, ponieważ znacznie zwiększa to ryzyko, że aplikacja zostanie naruszona przez wstrzyknięcie kodu lub manipulowanie kodem.

Jeśli musisz wczytywać kod dynamicznie, wykonaj te czynności, aby ustawić wczytywany dynamicznie plik (np. plik DEX, JAR lub APK) jako tylko do odczytu zaraz po jego otwarciu i przed zapisaniem jakichkolwiek treści:

Kotlin

val jar = File("DYNAMICALLY_LOADED_FILE.jar")
val os = FileOutputStream(jar)
os.use {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly()
    // Then write the actual file content
}
val cl = PathClassLoader(jar, parentClassLoader)

Java

File jar = new File("DYNAMICALLY_LOADED_FILE.jar");
try (FileOutputStream os = new FileOutputStream(jar)) {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly();
    // Then write the actual file content
} catch (IOException e) { ... }
PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);

Obsługa plików wczytywanych dynamicznie, które już istnieją

Aby zapobiec zgłaszaniu wyjątków w przypadku istniejących plików wczytywanych dynamicznie, zalecamy ich usunięcie i ponowne utworzenie przed ponownym wczytaniem w aplikacji. Podczas ponownego tworzenia plików postępuj zgodnie z poprzednimi wskazówkami dotyczącymi oznaczania plików jako tylko do odczytu w momencie zapisu. Możesz też ponownie oznaczyć istniejące pliki jako tylko do odczytu, ale w tym przypadku zdecydowanie zalecamy najpierw zweryfikowanie integralności plików (np. sprawdzenie podpisu pliku pod kątem zaufanej wartości), aby chronić aplikację przed złośliwymi działaniami.

Dodatkowe ograniczenia dotyczące rozpoczynania działań w tle

For apps targeting Android 14 (API level 34) or higher, the system further restricts when apps are allowed to start activities from the background:

These changes expand the existing set of restrictions to protect users by preventing malicious apps from abusing APIs to start disruptive activities from the background.

Przemierzanie ścieżki ZIP

For apps targeting Android 14 (API level 34) or higher, Android prevents the Zip Path Traversal Vulnerability in the following way: ZipFile(String) and ZipInputStream.getNextEntry() throws a ZipException if zip file entry names contain ".." or start with "/".

Apps can opt-out from this validation by calling dalvik.system.ZipPathValidator.clearCallback().

W przypadku aplikacji kierowanych na Androida 14 (API na poziomie 34) lub nowszego SecurityException jest zgłaszany przez MediaProjection#createVirtualDisplay w jednym z tych scenariuszy:

Aplikacja musi prosić użytkownika o zgodę przed każdą sesją rejestrowania. Pojedyncza sesja rejestrowania to pojedyncze wywołanie funkcji MediaProjection#createVirtualDisplay, a każde wystąpienie MediaProjection#createVirtualDisplay może być użyte tylko raz.MediaProjection

Obsługa zmian konfiguracji

Jeśli Twoja aplikacja musi wywołać MediaProjection#createVirtualDisplay, aby obsłużyć zmiany konfiguracji (np. zmianę orientacji lub rozmiaru ekranu), możesz zaktualizować VirtualDisplay dla istniejącego wystąpienia MediaProjection, wykonując te czynności:

  1. Wywołaj VirtualDisplay#resize z nową szerokością i wysokością.
  2. Dodaj nowy Surface o nowej szerokości i wysokości, aby użyć go w miejscu VirtualDisplay#setSurface.

Rejestrowanie wywołania zwrotnego

Aplikacja powinna zarejestrować funkcję wywołania zwrotnego, aby obsłużyć przypadki, gdy użytkownik nie wyrazi zgody na kontynuowanie sesji rejestrowania. Aby to zrobić, wdrożyć Callback#onStop i opublikować w aplikacji odpowiednie zasoby (takie jak VirtualDisplay i Surface).

Jeśli aplikacja nie zarejestruje tego wywołania zwrotnego, funkcja MediaProjection#createVirtualDisplay rzuci wyjątek IllegalStateException, gdy aplikacja ją wywoła.

Zaktualizowane ograniczenia inne niż związane z pakietem SDK

Android 14 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 14, some of these changes might not immediately affect you. However, while you can currently use some non-SDK interfaces (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. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. 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 about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 14. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.