Platforma Android 14 zawiera zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu dotyczą wszystkich aplikacji działających na Androidzie 14 niezależnie od targetSdkVersion. Przetestuj aplikację, a potem w razie potrzeby zmodyfikuj ją, aby prawidłowo obsługiwała te funkcje.
Zapoznaj się też z listą zmian w działaniu, które wpływają tylko na aplikacje kierowane na Androida 14.
Główna funkcja
Planowanie alarmów precyzyjnych jest domyślnie odrzucane
Alarmy precyzyjne są przeznaczone do powiadomień, które użytkownik chce otrzymać, lub do działań, które muszą być wykonane w określonym czasie. Od Androida 14 uprawnienia SCHEDULE_EXACT_ALARM nie są wstępnie przyznawane większości nowo instalowanych aplikacji kierowanych na Androida 13 i nowsze wersje – domyślnie są one odrzucane.
Dowiedz się więcej o zmianach w uprawnieniach dotyczących planowania dokładnych alarmów.
Zarejestrowane w kontekście transmisje są umieszczane w kolejce, gdy aplikacje są przechowywane w pamięci podręcznej
Na Androidzie 14 system może umieszczanie komunikatów zarejestrowanych kontekstowo w kolejce podczas korzystania przez aplikację z aplikacji jest w pamięci podręcznej. Jest to podobne do kolejkowania transakcji asynchronicznych w binderze, które zostało wprowadzone w Androidzie 12 (poziom API 31). Transmisje zadeklarowane w pliku manifestu nie są umieszczane w kolejce, a aplikacje są usuwane ze stanu pamięci podręcznej na potrzeby przesyłania komunikatów.
Gdy aplikacja opuści stan pamięci podręcznej, np. powrót na pierwszy plan, system dostarcza wszystkie transmisje w kolejce. Wiele wystąpień niektórych transmisji mogą zostać połączone w jedną transmisję. W zależności od innych czynników, takich jak system stanu, aplikacje mogą zostać usunięte ze stanu pamięci podręcznej, a wszystkie aplikacje znajdujące się w kolejce i wysyłanie wiadomości.
Aplikacje mogą kończyć tylko własne procesy działające w tle
Starting in Android 14, when your app calls killBackgroundProcesses(),
the API can kill only the background processes of your own app.
If you pass in the package name of another app, this method has no effect on that app's background processes, and the following message appears in Logcat:
Invalid packageName: com.example.anotherapp
Your app shouldn't use the killBackgroundProcesses() API or otherwise attempt
to influence the process lifecycle of other apps, even on older OS versions.
Android is designed to keep cached apps in the background and kill them
automatically when the system needs memory. If your app kills other apps
unnecessarily, it can reduce system performance and increase battery consumption
by requiring full restarts of those apps later, which takes significantly more
resources than resuming an existing cached app.
Wartość MTU jest ustawiona na 517 w przypadku pierwszego klienta GATT, który wysyła żądanie MTU.
Starting from Android 14, the Android Bluetooth stack more strictly adheres to
Version 5.2 of the Bluetooth Core Specification and requests
the BLE ATT MTU to 517 bytes when the first GATT client requests an MTU using
the BluetoothGatt#requestMtu(int) API, and disregards all subsequent MTU
requests on that ACL connection.
To address this change and make your app more robust, consider the following options:
- Your peripheral device should respond to the Android device's MTU request
with a reasonable value that can be accommodated by the peripheral. The
final negotiated value will be a minimum of the Android requested value and
the remote provided value (for example,
min(517, remoteMtu))- Implementing this fix could require a firmware update for peripheral
- Alternatively, limit your GATT characteristic writes based on the minimum
between the known supported value of your peripheral and the received MTU
change
- A reminder that you should reduce 5 bytes from the supported size for the headers
- For example:
arrayMaxLength = min(SUPPORTED_MTU, GATT_MAX_ATTR_LEN(517)) - 5
Nowy powód, dla którego aplikacja może zostać umieszczona w ograniczonym zasobniku stanu gotowości
Android 14 wprowadza nowy powód, dla którego aplikacja może zostać umieszczona w zasobie o ograniczonym dostępie.
Zadania aplikacji wielokrotnie wywołują błędy ANR z powodu przekroczenia limitu czasu oczekiwania metod onStartJob, onStopJob lub onBind.
(aby dowiedzieć się więcej o zmianach w funkcjach onStartJob i onStopJob, zapoznaj się z artykułem JobScheduler wzmacnia działanie funkcji wywołania zwrotnego i zachowania sieci).
Aby śledzić, czy aplikacja weszła do puli ograniczonego trybu gotowości, zalecamy rejestrowanie za pomocą interfejsu API UsageStatsManager.getAppStandbyBucket() podczas wykonywania zadania lub UsageStatsManager.queryEventsForSelf() podczas uruchamiania aplikacji.
mlock ograniczony do 64 KB
W Androidzie 14 (poziom interfejsu API 34) i nowszych platforma zmniejsza maksymalną ilość pamięci, którą można zablokować za pomocą funkcji mlock(), do 64 KB na proces. W poprzednich wersjach limit wynosił 64 MB na proces. To ograniczenie sprzyja lepszemu zarządzaniu pamięcią w aplikacjach i systemie. Aby zapewnić większą spójność na różnych urządzeniach, Android 14 dodaje nowy test CTS dla nowego limitu mlock() na zgodnych urządzeniach.
System wymusza wykorzystanie zasobów przez aplikacje z pamięci podręcznej
Zgodnie z zamierzeniami, gdy aplikacja jest przeniesiona do tle i nie działają żadne inne komponenty procesu aplikacji, jej proces jest w stanie buforowania. Taki proces aplikacji może zostać przerwany z powodu obciążenia pamięci systemowej. Wszelkie działania wykonywane przez instancje Activity po wywołaniu i zwrocie metody onStop() są w tym stanie niewiarygodne i nie zalecamy ich wykonywania.
Android 14 wprowadza spójność i wymuszanie tego projektu. Krótko po tym, jak proces aplikacji wejdzie w stan pamięci podręcznej, praca w tle jest niedozwolona, dopóki komponent procesu nie wejdzie ponownie w stan aktywny cyklu życia.
Zmiany te nie powinny mieć wpływu na aplikacje, które korzystają z typowych interfejsów API obsługiwanych przez platformę, takich jak services, JobScheduler i Jetpack WorkManager.
Wrażenia użytkownika
Zmiany w sposobie, w jaki użytkownicy korzystają z powiadomień, których nie można odrzucić
If your app shows non-dismissable foreground notifications to users, Android 14 has changed the behavior to allow users to dismiss such notifications.
This change applies to apps that prevent users from dismissing foreground
notifications by setting Notification.FLAG_ONGOING_EVENT through
Notification.Builder#setOngoing(true) or
NotificationCompat.Builder#setOngoing(true). The behavior of
FLAG_ONGOING_EVENT has changed to make such notifications actually
dismissable by the user.
These kinds of notifications are still non-dismissable in the following conditions:
- When the phone is locked
- If the user selects a Clear all notification action (which helps with accidental dismissals)
Also, this new behavior doesn't apply to notifications in the following use cases:
CallStylenotifications- Device policy controller (DPC) and supporting packages for enterprise
- Media notifications
- The default Search Selector package
Informacje o bezpieczeństwie danych są bardziej widoczne
To enhance user privacy, Android 14 increases the number of places where the system shows the information you have declared in the Play Console form. Currently, users can view this information in the Data safety section on your app's listing in Google Play.
We encourage you to review your app's location data sharing policies and take a moment to make any applicable updates to your app's Google Play Data safety section.
Learn more in the guide about how data safety information is more visible on Android 14.
Ułatwienia dostępu
Nieliniowe skalowanie czcionki do 200%
Od Androida 14 system obsługuje skalowanie czcionek do 200%, co zapewnia użytkownikom dodatkowe opcje ułatwień dostępu.
Jeśli do określania rozmiaru tekstu używasz już skalowalnych pikseli (sp), ta zmiana prawdopodobnie nie będzie miała dużego wpływu na Twoją aplikację. Warto jednak przeprowadzić testy interfejsu z włączonym maksymalnym rozmiarem czcionki (200%), aby upewnić się, że aplikacja obsługuje większe rozmiary czcionki bez wpływu na użyteczność.
Bezpieczeństwo
Minimalny poziom interfejsu API, na którym można zainstalować aplikację
Starting with Android 14, apps with a
targetSdkVersion lower than 23
can't be installed. Requiring apps to meet these minimum target API level
requirements improves security and privacy for users.
Malware often targets older API levels in order to bypass security and privacy
protections that have been introduced in newer Android versions. For example,
some malware apps use a targetSdkVersion of 22 to avoid being subjected to the
runtime permission model introduced in 2015 by Android 6.0 Marshmallow (API
level 23). This Android 14 change makes it harder for malware to avoid security
and privacy improvements.
Attempting to install an app targeting a lower API level will result in an
installation failure, with the following message appearing in Logcat:
INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23, but found 7
On devices upgrading to Android 14, any apps with a targetSdkVersion lower
than 23 will remain installed.
If you need to test an app targeting an older API level, use the following ADB command:
adb install --bypass-low-target-sdk-block FILENAME.apk
Nazwy pakietów właścicieli mediów mogą być zamazane
Magazyn multimediów obsługuje zapytania dotyczące kolumny OWNER_PACKAGE_NAME, która wskazuje aplikację, w której został zapisany konkretny plik multimedialny. Począwszy od Androida 14 ta wartość jest zaciemniona, chyba że jest spełniony co najmniej 1 z tych warunków:
- Aplikacja, która przechowuje plik multimedialny, ma nazwę pakietu, która jest zawsze widoczna dla innych aplikacji.
Aplikacja, która wysyła zapytanie do magazynu multimediów, prosi o uprawnienia
QUERY_ALL_PACKAGES.
Dowiedz się więcej o tym, jak Android filtruje widoczność pakietów ze względu na prywatność.