Zmiany zachowania: aplikacje kierowane na Androida 14 lub nowszego

Podobnie jak w przypadku poprzednich wersji, Android 14 zawiera zmiany zachowania, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany zachowania mają zastosowanie wyłącznie do aplikacji kierowanych na Androida 14 (API na poziomie 34) lub nowszego. Jeśli Twoja aplikacja jest kierowana na Androida 14 lub nowszego, zmodyfikuj aplikację, aby w stosownych przypadkach prawidłowo obsługiwała te funkcje.

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

Typy usług działających na pierwszym planie są wymagane

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 wymusza uprawnienie BLUETOOTH_CONNECT podczas wywoływania metody BluetoothAdapter getProfileConnectionState() w przypadku aplikacji kierowanych na Androida 14 (poziom API 34) lub nowszego.

Ta metoda wymagała już uprawnienia BLUETOOTH_CONNECT, ale nie była ona egzekwowana. Upewnij się, że aplikacja deklaruje uprawnienie BLUETOOTH_CONNECT w pliku AndroidManifest.xml, jak pokazano w tym fragmencie, i sprawdź, czy użytkownik przyznał odpowiednie uprawnienia przed wywołaniem funkcji 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łania zwrotne i działanie 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

Na Androidzie 11 (poziom interfejsu API 30) każda aplikacja mogła używać Notification.Builder.setFullScreenIntent do wysyłania intencji pełnoekranowych, gdy telefon jest zablokowany. Możesz automatycznie przyznać tę wartość podczas instalacji aplikacji, zadeklarując uprawnienie USE_FULL_SCREEN_INTENT w pliku AndroidManifest.

Powiadomienia intencji pełnoekranowej zaprojektowano z myślą o powiadomieniach o bardzo wysokim priorytecie, które wymagają natychmiastowej uwagi użytkownika, np. o przychodzących połączeniach telefonicznych lub ustawieniach budzika. W przypadku aplikacji kierowanych na Androida 14 (poziom interfejsu API 34) lub nowszego aplikacje, które mogą korzystać z tego uprawnienia, są ograniczone do tych, które oferują tylko wywoływanie i alarmy. Sklep Google Play cofa domyślne uprawnienia USE_FULL_SCREEN_INTENT wszystkim aplikacjom, które nie pasują do tego profilu. Ostateczny termin wprowadzenia tych zmian zasad to 31 maja 2024 r.

To uprawnienie pozostaje włączone w przypadku aplikacji zainstalowanych na telefonie, zanim użytkownik przejdzie na Androida 14. Użytkownicy mogą włączać i wyłączać to uprawnienie.

Możesz użyć nowego interfejsu API NotificationManager.canUseFullScreenIntent, aby sprawdzić, czy aplikacja ma odpowiednie uprawnienia. Jeśli nie, aplikacja może użyć nowej intencji ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT, aby otworzyć stronę ustawień, na której użytkownicy mogą przyznawać te uprawnienia.

Bezpieczeństwo

Ograniczenia dotyczące intencji niejawnych i oczekujących

W przypadku aplikacji kierowanych na Androida 14 (poziom interfejsu API 34) lub nowszego Android ogranicza możliwość wysyłania intencji niejawnych do wewnętrznych komponentów aplikacji w ten sposób:

  • Implicit intents są dostarczane tylko do komponentów eksportowanych. Aplikacje muszą używać jawnej intencji, by dostarczyć komponenty do niewyeksportowanych komponentów, lub oznaczyć komponent jako wyeksportowany.
  • Jeśli aplikacja tworzy zmienną oczekującą intencję z intencją, która nie określa komponentu ani pakietu, system zgłasza wyjątek.

Te zmiany zapobiegają przechwytywaniu niejawnych intencji, które mają być używane przez wewnętrzne komponenty aplikacji.

Oto przykładowy filtr intencji, który można zadeklarować w pliku manifestu aplikacji:

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

Jeśli aplikacja spróbuje uruchomić tę aktywność za pomocą domyślnego zamiaru, zostanie zgłoszony wyjątek ActivityNotFoundException:

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"));

Aby uruchomić aktywność, która nie została wyeksportowana, aplikacja powinna użyć wyraźnego zamiaru:

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

Rejestrowane w czasie wykonywania odbiorniki transmisji muszą określać zachowanie eksportu

Aplikacje i usługi, które są kierowane na Androida 14 (poziom interfejsu API 34) lub nowsze i używają odbiorników zarejestrowanych na podstawie kontekstu, muszą określić flagę wskazującą, czy odbiorca powinien zostać wyeksportowany do wszystkich innych aplikacji na urządzeniu (odpowiednio RECEIVER_EXPORTED lub RECEIVER_NOT_EXPORTED). To wymaganie pomaga chronić aplikacje przed lukami w zabezpieczeniach przez wykorzystanie funkcji dla odbiorców wprowadzonych w Androidzie 13.

Wyjątek dla odbiorców, którzy odbierają tylko komunikaty systemowe

Jeśli Twoja aplikacja rejestruje odbiornik tylko w przypadku komunikatów systemowych za pomocą metod Context#registerReceiver, takich jak Context#registerReceiver(), nie powinna określać flagi podczas rejestrowania odbiorcy.

Bezpieczniejsze wczytywanie kodu dynamicznego

If your app targets Android 14 (API level 34) or higher and uses Dynamic Code Loading (DCL), all dynamically-loaded files must be marked as read-only. Otherwise, the system throws an exception. We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.

If you must dynamically load code, use the following approach to set the dynamically-loaded file (such as a DEX, JAR, or APK file) as read-only as soon as the file is opened and before any content is written:

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

Handle dynamically-loaded files that already exist

To prevent exceptions from being thrown for existing dynamically-loaded files, we recommend deleting and recreating the files before you try to dynamically load them again in your app. As you recreate the files, follow the preceding guidance for marking the files read-only at write time. Alternatively, you can re-label the existing files as read-only, but in this case, we strongly recommend that you verify the integrity of the files first (for example, by checking the file's signature against a trusted value), to help protect your app from malicious actions.

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().

For apps targeting Android 14 (API level 34) or higher, a SecurityException is thrown by MediaProjection#createVirtualDisplay in either of the following scenarios:

Your app must ask the user to give consent before each capture session. A single capture session is a single invocation on MediaProjection#createVirtualDisplay, and each MediaProjection instance must be used only once.

Handle configuration changes

If your app needs to invoke MediaProjection#createVirtualDisplay to handle configuration changes (such as the screen orientation or screen size changing), you can follow these steps to update the VirtualDisplay for the existing MediaProjection instance:

  1. Invoke VirtualDisplay#resize with the new width and height.
  2. Provide a new Surface with the new width and height to VirtualDisplay#setSurface.

Register a callback

Your app should register a callback to handle cases where the user doesn't grant consent to continue a capture session. To do this, implement Callback#onStop and have your app release any related resources (such as the VirtualDisplay and Surface).

If your app doesn't register this callback, MediaProjection#createVirtualDisplay throws an IllegalStateException when your app invokes it.

Zaktualizowane ograniczenia inne niż związane z pakietem SDK

Android 14 zawiera zaktualizowane listy interfejsów innych niż SDK, które są objęte ograniczeniami. Lista została opracowana na podstawie współpracy z deweloperami Androida i najnowszych testów wewnętrznych. Zawsze, gdy to możliwe, sprawdzamy, czy dostępne są publiczne alternatywy, zanim zaczniemy ograniczać interfejsy inne niż SDK.

Jeśli Twoja aplikacja nie jest kierowana na Androida 14, niektóre z tych zmian mogą nie mieć na Ciebie natychmiastowego wpływu. Mimo że obecnie można korzystać z niektórych interfejsów innych niż SDK (w zależności od docelowego poziomu interfejsu API aplikacji), użycie dowolnej metody lub pola spoza pakietu SDK zawsze wiąże się z dużym ryzykiem uszkodzenia aplikacji.

Jeśli nie masz pewności, czy Twoja aplikacja korzysta z interfejsów innych niż SDK, możesz to przetestować. Jeśli Twoja aplikacja wymaga interfejsów innych niż SDK, zacznij planować migrację na alternatywne wersje pakietów SDK. Zdajemy sobie jednak sprawę, że niektóre aplikacje mogą prawidłowo korzystać z interfejsów innych niż SDK. Jeśli nie możesz znaleźć w swojej aplikacji interfejsu innego niż interfejs SDK, musisz poprosić o nowy publiczny interfejs 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.