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

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

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.