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

Jeśli Twoja aplikacja jest kierowana na Androida 14 (poziom interfejsu API 34) lub nowszego, musi określić co najmniej 1 typ takiej usługi dla każdej usługi na pierwszym planie w aplikacji. Wybierz typ tej usługi, który odzwierciedla jej zastosowanie. System oczekuje, że usługi na pierwszym planie, które mają określony typ, spełnią określony przypadek użycia.

Jeśli przypadek użycia w Twojej aplikacji nie jest powiązany z żadnym z tych typów, zdecydowanie zalecamy przeniesienie logiki za pomocą WorkManagera lub zadań przenoszenia danych inicjowanych przez użytkownika.

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 w pliku AndroidManifest.xml aplikacji deklarujesz BLUETOOTH_CONNECT, jak pokazano w tym fragmencie kodu, i sprawdź, czy użytkownik przyznał uprawnienia, zanim wywołasz funkcję 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

W przypadku aplikacji kierowanych do użytkowników, którzy ukończyli 14 lat, Narzędzie TileService#startActivityAndCollapse(Intent) zostało wycofane i obecnie zgłasza tylko w przypadku wywołania. Jeśli aplikacja uruchamia czynności z kart, użyj zamiast tego TileService#startActivityAndCollapse(PendingIntent).

Prywatność

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

Android 14 wprowadza dostęp do wybranych zdjęć, który pozwala przyznawać aplikacjom dostęp do określonych obrazów i filmów w bibliotece, zamiast przyznawać dostęp do wszystkich multimediów danego typu.

Ta zmiana jest włączona tylko wtedy, gdy Twoja aplikacja jest kierowana na Androida 14 (poziom API 34) lub nowszego. Jeśli nie używasz jeszcze selektora zdjęć, zalecamy zaimplementowanie go w swojej aplikacji. Pozwoli to w spójny sposób wybierać obrazy i filmy, a jednocześnie zwiększy prywatność użytkowników bez konieczności wysyłania próśb o uprawnienia do przechowywania danych.

Jeśli samodzielnie zarządzasz selektorem galerii z użyciem uprawnień do przechowywania danych i chcesz zachować pełną kontrolę nad implementacją, dostosuj implementację, aby wykorzystywała nowe uprawnienie READ_MEDIA_VISUAL_USER_SELECTED. Jeśli aplikacja nie korzysta z nowych uprawnień, system uruchomi ją w trybie zgodności.

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

W przypadku aplikacji kierowanych na Androida 14 (poziom interfejsu API 34) lub nowszego system jeszcze bardziej ogranicza możliwość uruchamiania działań w tle:

  • Gdy aplikacja wysyła obiekt PendingIntent za pomocą PendingIntent#send() lub podobnej metody, musi wyrazić zgodę na przyznanie przez nią uprawnień do uruchamiania intencji w tle, aby uruchomić oczekującą intencję. Aby można było włączyć tę opcję, aplikacja musi przekazywać pakiet ActivityOptions z parametrem setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED).
  • Gdy widoczna aplikacja wiąże za pomocą metody bindService() usługę innej aplikacji działającej w tle, ta aplikacja musi teraz wyrazić na nią zgodę, jeśli chce przyznać tej usłudze uprawnienia do uruchamiania własnej aktywności w tle. Aby ją włączyć, podczas wywoływania metody bindService() aplikacja powinna zawierać flagę BIND_ALLOW_ACTIVITY_STARTS.

Te zmiany rozszerzają obecny zestaw ograniczeń, aby chronić użytkowników przez uniemożliwienie szkodliwym aplikacjom nadużywania interfejsów API w celu rozpoczynania uciążliwych działań w tle.

Przemierzanie ścieżki ZIP

W przypadku aplikacji kierowanych na Androida 14 (poziom interfejsu API 34) lub nowszego Android zapobiega lukom w porcie ścieżki ZIP w taki sposób: ZipFile(String) i ZipInputStream.getNextEntry() zwracają wynik ZipException, jeśli nazwy wpisów w pliku ZIP zawierają „..” lub zaczynają się od „/”.

Aplikacje mogą zrezygnować z tej weryfikacji, wywołując metodę dalvik.system.ZipPathValidator.clearCallback().

W przypadku aplikacji kierowanych na Androida 14 (poziom interfejsu API 34) lub nowszego element SecurityException jest zwracany przez MediaProjection#createVirtualDisplay w jednym z tych scenariuszy:

Aplikacja musi prosić użytkownika o zgodę przed każdą sesją przechwytywania. Pojedyncza sesja przechwytywania jest pojedynczym wywołaniem w metodzie MediaProjection#createVirtualDisplay, a każdej instancji MediaProjection można użyć tylko raz.

Obsługa zmian konfiguracji

Jeśli Twoja aplikacja musi wywoływać MediaProjection#createVirtualDisplay w celu obsługi zmian konfiguracji (takich jak zmiana orientacji ekranu lub rozmiaru ekranu), możesz wykonać te czynności, aby zaktualizować VirtualDisplay w istniejącej instancji MediaProjection:

  1. Wywołaj element VirtualDisplay#resize z nową szerokością i wysokością.
  2. Podaj nowy element Surface z nową szerokością i wysokością VirtualDisplay#setSurface.

Rejestrowanie wywołania zwrotnego

Aplikacja powinna zarejestrować wywołanie zwrotne na potrzeby obsługi przypadków, w których użytkownik nie wyrazi zgody na kontynuowanie sesji przechwytywania. Aby to zrobić, zaimplementuj Callback#onStop i poproś o udostępnienie w aplikacji wszystkich powiązanych zasobów (np. VirtualDisplay i Surface).

Jeśli aplikacja nie rejestruje tego wywołania zwrotnego, MediaProjection#createVirtualDisplay zgłasza IllegalStateException, gdy aplikacja go wywołuje.

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.

Więcej informacji o zmianach w tej wersji Androida znajdziesz w artykule Aktualizacje ograniczeń interfejsu spoza pakietu SDK w Androidzie 14. Więcej informacji o interfejsach spoza SDK znajdziesz w artykule Ograniczenia dotyczące interfejsów spoza SDK.