Zmiany w działaniu: aplikacje kierowane na Androida 14 lub nowszego

Podobnie jak w poprzednich wersjach Android 14 obejmuje zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu dotyczą tylko aplikacji kierowanych na Androida 14 (poziom interfejsu API 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 działaniu, które wpływają na wszystkie aplikacje działające na Androidzie 14, niezależnie od targetSdkVersion aplikacji.

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 BluetoothAdapter Metoda getProfileConnectionState() w kierowaniu na aplikacje Android 14 (poziom interfejsu API 34) lub nowszy.

Ta metoda wymagała już uprawnienia BLUETOOTH_CONNECT, ale nie wymagało tego jest egzekwowane. Upewnij się, że aplikacja deklaruje parametr BLUETOOTH_CONNECT w kodzie aplikacji AndroidManifest.xml jak pokazano w tym fragmencie, i sprawdź, czy użytkownik przyznał uprawnienie przed nawiązaniem połączenia getProfileConnectionState.

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

Aktualizacje OpenJDK 17

Android 14 kontynuuje prace nad odświeżaniem podstawowych bibliotek Androida w celu dostosowania do funkcji z najnowszych wersji OpenJDK LTS, w tym aktualizacji bibliotek oraz obsługi języka Java 17 dla deweloperów aplikacji i platform.

Kilka z tych zmian może mieć wpływ na zgodność aplikacji:

  • Zmiany w wyrażeniach regularnych: nie można teraz stosować nieprawidłowych odwołań do grup, aby lepiej zachować zgodność z semantyką OpenJDK. Mogą się pojawić nowe przypadki, w których obiekt IllegalArgumentException jest wywoływany przez klasę java.util.regex.Matcher, dlatego pamiętaj, aby przetestować aplikację pod kątem obszarów, które używają wyrażeń regularnych. Aby włączyć lub wyłączyć tę zmianę podczas testowania, przełącz flagę DISALLOW_INVALID_GROUP_REFERENCE za pomocą narzędzi platformy zgodności.
  • Obsługa identyfikatorów UUID: metoda java.util.UUID.fromString() przeprowadza teraz bardziej rygorystyczne testy podczas weryfikacji argumentu wejściowego, więc podczas deserializacji możesz zobaczyć IllegalArgumentException. Aby włączyć lub wyłączyć tę zmianę podczas testowania, przełącz flagę ENABLE_STRICT_VALIDATION za pomocą narzędzi platformy zgodności.
  • Problemy z ProGuard: w niektórych przypadkach dodanie klasy java.lang.ClassValue powoduje problem, gdy próbujesz zmniejszyć, zaciemnić lub zoptymalizować aplikację za pomocą ProGuard. Problem wynika z biblioteki Kotlin, która zmienia działanie w czasie działania w zależności od tego, czy Class.forName("java.lang.ClassValue") zwraca klasę. Jeśli Twoja aplikacja została opracowana przy użyciu starszej wersji środowiska wykonawczego, w którym nie ma dostępnej klasy java.lang.ClassValue, optymalizacje mogą spowodować usunięcie metody computeValue z klas wyodrębnionych ze źródła 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 Tiles

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 引入了所选照片访问权限，可让用户授权应用访问其媒体库中的特定图片和视频，而不是授予对指定类型的所有媒体的访问权限。

仅当您的应用以 Android 14（API 级别 34）或更高版本为目标平台时，才会启用此变更。如果您还没有使用照片选择器，建议您在应用中实现该选择器，以便在选择图片和视频时提供一致的体验，同时还可以加强用户隐私保护，而无需请求任何存储权限。

如果您使用存储权限维护自己的图库选择器，并且需要完全控制您的实现，请调整您的实现，以使用新的 READ_MEDIA_VISUAL_USER_SELECTED 权限。如果您的应用不使用新权限，系统会在兼容模式下运行应用。

Z perspektywy 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.

Zabezpieczenia

Ograniczenia dotyczące intencji niejawnych i oczekujących

W przypadku aplikacji kierowanych na Androida 14 (poziom interfejsu API 34) lub nowszego Android ogranicza dostęp do aplikacji od wysyłania niejawnych intencji do wewnętrznych komponentów aplikacji w taki sposób:

  • Intencje ogólne są dostarczane tylko do eksportowanych komponentów. Aplikacje muszą: użyć jawnej intencji, aby dostarczyć do niewyeksportowanych komponentów, lub zaznaczyć element jako wyeksportowany komponent.
  • Jeśli aplikacja tworzy zmienną intencję oczekującą z intencją, która nie jest: określić komponent lub pakiet, system zgłosi wyjątek.

Te zmiany zapobiegają przechwytywaniu niejawnych intencji, które złośliwe aplikacje przeznaczone dla wewnętrznych komponentów aplikacji.

Oto przykład intentu filtr, który można zadeklarować w plik 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 próbowała uruchomić tę aktywność, używając intencji niejawnej, wyjątek zostałaby wrzucona:

Kotlin

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

Java

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

Aby uruchomić niewyeksportowaną aktywność, aplikacja powinna używać intencji zamiast:

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 środowisku wykonawczym muszą określić sposób 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 dynamiczne wczytywanie kodu

Jeśli Twoja aplikacja jest kierowana na Androida 14 (poziom interfejsu API 34) lub nowszego i korzysta z kodu dynamicznego Ładowanie (DCL) powoduje, że wszystkie dynamicznie ładowane pliki muszą być oznaczone jako tylko do odczytu. W przeciwnym razie system zgłosi wyjątek. Zalecamy, aby aplikacje unikały dynamiczne wczytywanie kodu bo to znacznie zwiększa ryzyko, że aplikacja został przejęty przez wstrzyknięcie kodu lub zmodyfikowanie kodu.

Jeśli musisz dynamicznie ładować kod, użyj następującej metody, aby ustawić atrybut dynamicznie ładowany (np. DEX, JAR czy APK) jako tylko do odczytu podczas otwierania pliku i do zapisywania 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 ładowanych dynamicznie, które już istnieją

Aby zapobiec zgłaszaniu wyjątków dla istniejących plików wczytywanych dynamicznie: zalecamy usunięcie i ponowne utworzenie plików, zanim spróbujesz dynamicznie wczytać je ponownie w aplikacji. Podczas ponownego tworzenia plików postępuj zgodnie z instrukcjami – wskazówki dotyczące oznaczania plików jako tylko do odczytu podczas zapisu. Ewentualnie możesz zmienić etykiety istniejących plików na „tylko do odczytu”, ale w tym przypadku zdecydowanie zalecamy wcześniejsze sprawdzenie integralności plików (na przykład porównując podpis pliku z zaufaną wartością), pomaga to chronić aplikację przed złośliwymi działaniami.

Dodatkowe ograniczenia 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.

Zaktualizowano ograniczenia spoza pakietu SDK

Android 14 zawiera zaktualizowane listy podlegających ograniczeniom interfejsów spoza pakietu SDK opracowane na podstawie współpracy z deweloperami aplikacji na Androida i najnowszych testów wewnętrznych. Zanim ograniczymy dostęp do interfejsów spoza SDK, dbamy o to, aby w miarę możliwości dostępne były publiczne alternatywy.

Jeśli Twoja aplikacja nie jest kierowana na Androida 14, niektóre z tych zmian mogą Cię nie odczuć od razu. Mimo że obecnie możesz używać niektórych interfejsów spoza pakietu SDK (w zależności od docelowego poziomu interfejsu API aplikacji), używanie dowolnej metody lub pola spoza pakietu SDK niesie ze sobą wysokie ryzyko uszkodzenia aplikacji.

Jeśli nie masz pewności, czy Twoja aplikacja korzysta z interfejsów innych niż SDK, możesz przetestować ją, aby to sprawdzić. Jeśli Twoja aplikacja korzysta z interfejsów innych niż SDK, zacznij planować migrację do alternatywnych pakietów SDK. Zdajemy sobie jednak sprawę, że niektóre aplikacje mają odpowiednie przypadki użycia w zakresie interfejsów spoza SDK. Jeśli nie możesz znaleźć alternatywy dla interfejsu innego niż SDK dla funkcji w aplikacji, poproś 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.