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 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, czyClass.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 klasyjava.lang.ClassValue
, optymalizacje mogą spowodować usunięcie metodycomputeValue
z klas wyodrębnionych ze źródłajava.lang.ClassValue
.
JobScheduler wzmacnia wywołania zwrotne i działanie sieci
Since its introduction, JobScheduler expects your app to return from
onStartJob
or onStopJob
within a few seconds. Prior to Android 14,
if a job runs too long, the job is stopped and fails silently.
If your app targets Android 14 (API level 34) or higher and
exceeds the granted time on the main thread, the app triggers an ANR
with the error message "No response to onStartJob
" or
"No response to onStopJob
".
This ANR may be a result of 2 scenarios:
1. There is work blocking the main thread, preventing the callbacks onStartJob
or onStopJob
from executing and completing within the expected time limit.
2. The developer is running blocking work within the JobScheduler
callback onStartJob
or onStopJob
, preventing the callback from
completing within the expected time limit.
To address #1, you will need to further debug what is blocking the main thread
when the ANR occurs, you can do this using
ApplicationExitInfo#getTraceInputStream()
to get the tombstone
trace when the ANR occurs. If you're able to manually reproduce the ANR,
you can record a system trace and inspect the trace using either
Android Studio or Perfetto to better understand what is running on
the main thread when the ANR occurs.
Note that this can happen when using JobScheduler API directly
or using the androidx library WorkManager.
To address #2, consider migrating to WorkManager, which provides
support for wrapping any processing in onStartJob
or onStopJob
in an asynchronous thread.
JobScheduler
also introduces a requirement to declare the
ACCESS_NETWORK_STATE
permission if using setRequiredNetworkType
or
setRequiredNetwork
constraint. If your app does not declare the
ACCESS_NETWORK_STATE
permission when scheduling the job and is targeting
Android 14 or higher, it will result in a 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 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ć pakietActivityOptions
z parametremsetPendingIntentBackgroundActivityStartMode(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 metodybindService()
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
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()
.
Każda sesja przechwytywania MediaProjection wymaga zgody użytkownika
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 zapisuje w pamięci podręcznej element
Intent
zwracany zMediaProjectionManager#createScreenCaptureIntent
i przekazuje go wiele razy doMediaProjectionManager#getMediaProjection
. - Twoja aplikacja wywołuje funkcję
MediaProjection#createVirtualDisplay
wiele razy w tej samej instancjiMediaProjection
.
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
:
- Wywołaj element
VirtualDisplay#resize
z nową szerokością i wysokością. - 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.