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 nowszą wersję, w odpowiednich przypadkach zmodyfikuj ją, aby 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
Wymagane są typy usług działających na pierwszym planie
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.
Wymuszanie uprawnienia BLUETOOTH_CONNECT w BluetoothAdapter
Android 14 enforces the BLUETOOTH_CONNECT
permission when calling the
BluetoothAdapter
getProfileConnectionState()
method for apps targeting
Android 14 (API level 34) or higher.
This method already required the BLUETOOTH_CONNECT
permission, but it was not
enforced. Make sure your app declares BLUETOOTH_CONNECT
in your app's
AndroidManifest.xml
file as shown in the following snippet and check that
a user has granted the permission before calling
getProfileConnectionState
.
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
Aktualizacje OpenJDK 17
Android 14 kontynuuje proces odświeżania podstawowych bibliotek Androida, aby dostosować je do funkcji najnowszych wersji OpenJDK LTS, w tym do aktualizacji bibliotek i obsługi języka Java 17 dla deweloperów aplikacji i platform.
Niektóre z tych zmian mogą mieć wpływ na zgodność aplikacji:
- Zmiany w wyrażeniach regularnych: nieprawidłowe odwołania do grup są teraz niedozwolone, aby bardziej odpowiadać semantyce OpenJDK. Możesz zauważyć nowe przypadki, w których klasa
java.util.regex.Matcher
wyrzuca błądIllegalArgumentException
. Dlatego przetestuj aplikację pod kątem obszarów, które używają wyrażeń regularnych. Aby włączyć lub wyłączyć tę zmianę podczas testowania, włącz lub wyłącz flagęDISALLOW_INVALID_GROUP_REFERENCE
za pomocą narzędzi platformy zgodności. - Obsługa UUID: metoda
java.util.UUID.fromString()
przeprowadza teraz bardziej rygorystyczne kontrole podczas sprawdzania argumentu wejściowego, więc podczas deserializacji możesz zobaczyć błądIllegalArgumentException
. Aby włączyć lub wyłączyć tę zmianę podczas testowania, włącz lub wyłą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 problemy, gdy próbujesz zmniejszyć rozmiar, zaciemnić i zoptymalizować aplikację za pomocą ProGuard. Problem pochodzi z biblioteki Kotlina, która zmienia zachowanie w czasie wykonywania w zależności od tego, czy funkcjaClass.forName("java.lang.ClassValue")
zwraca klasę. Jeśli Twoja aplikacja została opracowana na podstawie starszej wersji środowiska uruchomieniowego bez dostępnej klasyjava.lang.ClassValue
, te optymalizacje mogą usunąć metodęcomputeValue
z klas wywodzących się z klasyjava.lang.ClassValue
.
JobScheduler wzmacnia wywołanie zwrotne i zachowanie 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 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 pełnoekranowe o intencjach
W Androidzie 11 (poziom API 30) każda aplikacja mogła używać interfejsu Notification.Builder.setFullScreenIntent
do wysyłania intencji pełnoekranowych, gdy telefon jest zablokowany. Możesz przyznać je automatycznie podczas instalowania aplikacji, deklarując uprawnienie USE_FULL_SCREEN_INTENT
w pliku AndroidManifest.
Powiadomienia z intencją pełnoekranową są przeznaczone do powiadomień o bardzo wysokim priorytecie, które wymagają natychmiastowej uwagi użytkownika, takich jak połączenie telefoniczne czy alarm ustawiony przez użytkownika. W przypadku aplikacji kierowanych na Androida 14 (poziom API 34) i nowszych wersje uprawnienia do korzystania z tego uprawnienia są ograniczone do aplikacji, które umożliwiają tylko dzwonienie i alarmy. Sklep Google Play odwołuje domyślne uprawnienia USE_FULL_SCREEN_INTENT
w przypadku wszystkich aplikacji, które nie pasują do tego profilu. Termin wdrożenia tych zmian zasad to 31 maja 2024 r.
To uprawnienie pozostaje włączone w przypadku aplikacji zainstalowanych na telefonie przed aktualizacją do Androida 14. Użytkownicy mogą włączać i wyłączać to uprawnienie.
Możesz użyć nowego interfejsu API NotificationManager.canUseFullScreenIntent
, aby sprawdzić, czy Twoja aplikacja ma to uprawnienie. Jeśli nie, może ona użyć nowego zamiaru ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT
, aby otworzyć stronę ustawień, na której użytkownicy mogą przyznać uprawnienie.
Bezpieczeństwo
Ograniczenia intencji niewyrażonych i oczekujących
For apps targeting Android 14 (API level 34) or higher, Android restricts apps from sending implicit intents to internal app components in the following ways:
- Implicit intents are only delivered to exported components. Apps must either use an explicit intent to deliver to unexported components, or mark the component as exported.
- If an app creates a mutable pending intent with an intent that doesn't specify a component or package, the system throws an exception.
These changes prevent malicious apps from intercepting implicit intents that are intended for use by an app's internal components.
For example, here is an intent filter that could be declared in your app's manifest file:
<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>
If your app tried to launch this activity using an implicit intent, an
ActivityNotFoundException
exception would be thrown:
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"));
To launch the non-exported activity, your app should use an explicit intent instead:
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
Apps and services that target Android 14 (API level 34) or higher and use
context-registered receivers are required to specify a flag
to indicate whether or not the receiver should be exported to all other apps on
the device: either RECEIVER_EXPORTED
or RECEIVER_NOT_EXPORTED
, respectively.
This requirement helps protect apps from security vulnerabilities by leveraging
the features for these receivers introduced in Android 13.
Exception for receivers that receive only system broadcasts
If your app is registering a receiver only for
system broadcasts through Context#registerReceiver
methods, such as Context#registerReceiver()
, then it
shouldn't specify a flag when registering the receiver.
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 (interfejs API na poziomie 34) lub nowszego system dodatkowo ogranicza, kiedy aplikacje mogą uruchamiać działania w tle:
- Gdy aplikacja wysyła
PendingIntent
za pomocąPendingIntent#send()
lub podobnych metod, musi wyrazić zgodę, jeśli chce przyznać uprawnienia do uruchamiania własnych działań w tle, aby rozpocząć oczekującą intencję. Aby wyrazić zgodę, aplikacja musi przekazać pakietActivityOptions
zsetPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)
. - Gdy widoczna aplikacja wiąże usługę innej aplikacji, która działa w tle, za pomocą metody
bindService()
, musi teraz zdecydować, czy chce przyznać tej usłudze uprawnienia do uruchamiania własnych działań w tle. Aby wyrazić zgodę, aplikacja powinna zawierać flagęBIND_ALLOW_ACTIVITY_STARTS
podczas wywoływania metodybindService()
.
Te zmiany rozszerzają istniejący zestaw ograniczeń, aby chronić użytkowników przed złośliwymi aplikacjami, które nadużywają interfejsów API do uruchamiania zakłócających działań w tle.
Przemierzanie ścieżki ZIP
W przypadku aplikacji kierowanych na Androida 14 (poziom API 34) lub nowszego Android zapobiega podatności na atak polegający na przemierzaniu ścieżki w pliku ZIP w następujący sposób:
ZipFile(String)
i ZipInputStream.getNextEntry()
zgłaszaZipException
błąd, jeśli nazwy elementów pliku ZIP zawierają „..” lub zaczynają się od „/”.
Aplikacje mogą zrezygnować z tej weryfikacji, wywołując funkcję dalvik.system.ZipPathValidator.clearCallback()
.
Wymagana zgoda użytkownika na każdą sesję rejestrowania MediaProjection
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 caches the
Intent
that is returned fromMediaProjectionManager#createScreenCaptureIntent
, and passes it multiple times toMediaProjectionManager#getMediaProjection
. - Your app invokes
MediaProjection#createVirtualDisplay
multiple times on the sameMediaProjection
instance.
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:
- Invoke
VirtualDisplay#resize
with the new width and height. - Provide a new
Surface
with the new width and height toVirtualDisplay#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 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.
If your app does not target Android 14, some of these changes might not immediately affect you. However, while you can currently use some non-SDK interfaces (depending on your app's target API level), using any non-SDK method or field always carries a high risk of breaking your app.
If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.
Więcej informacji o zmianach w tej wersji Androida znajdziesz w artykule Zmiany ograniczeń interfejsu niebędącego interfejsem SDK w Androidzie 14. Więcej informacji o interfejsach innych niż SDK znajdziesz w artykule Ograniczenia dotyczące interfejsów innych niż SDK.