Platforma Android 14 wprowadza zmiany w działaniu, które mogą wpłynąć na Twoją aplikację.
Te 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 je obsługuje.
Zapoznaj się też z listą zmian w działaniu, które wpływają tylko na aplikacje kierowane na Androida 14.
Główna funkcja
Harmonogram alarmów precyzyjnych jest domyślnie zabroniony
Dokładne alarmy są przeznaczone do powiadomień wysyłanych przez użytkownika lub do działań, które muszą zostać wykonane w określonym czasie. Od wersji Androida 14 uprawnienie SCHEDULE_EXACT_ALARM nie jest już wstępnie przyznawane większości nowo zainstalowanych aplikacji kierowanych na Androida 13 i nowsze wersje – domyślnie są one odrzucane.
Dowiedz się więcej o zmianach w uprawnieniach do planowania alarmów precyzyjnych.
Komunikaty zarejestrowane w kontekście są umieszczane w kolejce, gdy aplikacje są przechowywane w pamięci podręcznej
On Android 14, the system can place context-registered broadcasts in a queue while the app is in the cached state. This is similar to the queuing behavior that Android 12 (API level 31) introduced for async binder transactions. Manifest-declared broadcasts aren't queued, and apps are removed from the cached state for broadcast delivery.
When the app leaves the cached state, such as returning to the foreground, the system delivers any queued broadcasts. Multiple instances of certain broadcasts might be merged into one broadcast. Depending on other factors, such as system health, apps might be removed from the cached state, and any previously queued broadcasts are delivered.
Aplikacje mogą zatrzymywać tylko własne procesy 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.
MTU jest ustawione na 517 w przypadku pierwszego klienta GATT, który żąda MTU
Począwszy od Androida 14 stos Bluetooth na Androidzie jest ściślej zgodny ze wersją 5.2 specyfikacji Bluetooth Core i gdy pierwszy klient GATT wysyła żądanie MTU przy użyciu interfejsu API BluetoothGatt#requestMtu(int), wysyła żądanie BLE ATT MTU do 517 bajtów. Ignoruje wszystkie kolejne żądania MTU dotyczące tego połączenia ACL.
Aby zastosować się do tej zmiany i zwiększyć bezpieczeństwo aplikacji, rozważ te opcje:
- Urządzenie peryferyjne powinno odpowiadać na żądanie MTU urządzenia z Androidem, podając rozsądną wartość, którą może ono obsłużyć. Ostateczna wynegocjowana wartość będzie minimalną wartością żądanej dla Androida oraz wartością dostarczaną zdalną (np.
min(517, remoteMtu)).- Wdrożenie tej poprawki może wymagać aktualizacji oprogramowania peryferyjnego
- Możesz też ograniczyć zapisy parametrów GATT, opierając się na minimalnej wartości między znaną obsługiwaną wartością urządzenia peryferyjnego a otrzymaną zmianą MTU.
- Należy pamiętać o zmniejszeniu obsługiwanego rozmiaru nagłówków o 5 bajtów
- Przykład:
arrayMaxLength = min(SUPPORTED_MTU, GATT_MAX_ATTR_LEN(517)) - 5
Nowy powód, dla którego można umieścić aplikację w ograniczonym zasobniku gotowości
W Androidzie 14 wprowadziliśmy nowy powód, dla którego można umieścić aplikację w zasobniku trybu czuwania z ograniczonym dostępem.
Zadania aplikacji wielokrotnie powodują błędy ANR z powodu przekroczenia limitu czasu dla metody onStartJob, onStopJob lub onBind.
Informacje o zmianach w onStartJob i onStopJob znajdziesz w sekcji JobScheduler wzmacnia wywołania zwrotne i działanie sieci.
Aby sprawdzić, czy aplikacja dołączyła do ograniczonego zasobnika w trybie gotowości, zalecamy logowanie za pomocą interfejsu API UsageStatsManager.getAppStandbyBucket() podczas wykonywania zadania lub UsageStatsManager.queryEventsForSelf() podczas uruchamiania aplikacji.
mlock o ograniczonym rozmiarze do 64 KB
In Android 14 (API level 34) and higher, the platform reduces the maximum memory
that can be locked using mlock() to 64 KB per process. In
previous versions, the limit was 64 MB per process. This restriction
promotes better memory management across apps and the system. To provide more
consistency across devices, Android 14 adds a new CTS test for the
new mlock() limit on compatible devices.
System wymusza wykorzystanie zasobów aplikacji w pamięci podręcznej
By design, an app's process is in a cached state when it's moved to the
background and no other app process components are running. Such an app process
is subject to being killed due to system memory pressure. Any work that
Activity instances perform after the onStop() method has been called and
returned, while in this state, is unreliable and strongly discouraged.
Android 14 introduces consistency and enforcement to this design. Shortly after an app process enters a cached state, background work is disallowed, until a process component re-enters an active state of the lifecycle.
Apps that use typical framework-supported lifecycle APIs – such as
services, JobScheduler, and Jetpack WorkManager – shouldn't be
impacted by these changes.
Z perspektywy użytkownika
Zmiany w wyświetlaniu powiadomień, których nie można zamknąć
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ą lepiej widoczne
Aby chronić prywatność użytkowników, Android 14 zwiększa liczbę miejsc, w których system wyświetla informacje zadeklarowane w formularzu w Konsoli Play. Obecnie użytkownicy mogą wyświetlać te informacje w sekcji Bezpieczeństwo danych na stronie aplikacji w Google Play.
Zachęcamy do zapoznania się z zasadami udostępniania danych o lokalizacji w aplikacji i dokonania odpowiednich zmian w sekcji Bezpieczeństwo danych w Google Play.
Z przewodnika dowiesz się, jak zwiększyć widoczność informacji o bezpieczeństwie danych na Androidzie 14.
Ułatwienia dostępu
Nieliniowe skalowanie czcionki do 200%
Począwszy od Androida 14 system obsługuje skalowanie czcionek do 200% i zapewnia użytkownikom niedowidzącym dodatkowe opcje ułatwień dostępu zgodne z wytycznymi dotyczącymi dostępności treści internetowych (WCAG).
Jeśli do określania rozmiaru tekstu używasz już skalowanych jednostek pikseli (sp), ta zmiana prawdopodobnie nie będzie miała dużego wpływu na działanie aplikacji. Zalecamy jednak przeprowadzenie testów interfejsu z włączonym maksymalnym rozmiarem czcionki (200%), aby upewnić się, że aplikacja może obsługiwać większe rozmiary czcionek bez negatywnego wpływu na jej obsługę.
Zabezpieczenia
Minimalny docelowy poziom interfejsu API z możliwością zainstalowania
Od Androida 14 nie można instalować aplikacji z wartością targetSdkVersion mniejszą niż 23. Wymóg spełnienia przez aplikacje minimalnych wymagań dotyczących docelowego poziomu interfejsu API zwiększa bezpieczeństwo i prywatność użytkowników.
Złośliwe oprogramowanie często jest kierowane na starsze poziomy interfejsów API, aby ominąć zabezpieczenia i ochronę prywatności, które zostały wprowadzone w nowszych wersjach Androida. Na przykład w niektórych aplikacjach zawierających złośliwe oprogramowanie parametr targetSdkVersion ma wartość 22, co pozwala uniknąć podlegania modelowi uprawnień czasu działania wprowadzonemu w Androidzie 6.0 Marshmallow (poziom interfejsu API 23) w 2015 r. Ta zmiana w Androidzie 14 utrudnia złośliwym oprogramowaniem o ulepszenie zabezpieczeń i prywatności.
Próba zainstalowania aplikacji kierowanej na niższy poziom interfejsu API spowoduje błąd instalacji. W narzędziu Logcat pojawi się ten komunikat:
INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23, but found 7
Na urządzeniach z Androidem 14 wszystkie aplikacje z targetSdkVersion niższą niż 23 pozostaną zainstalowane.
Jeśli musisz przetestować aplikację kierowaną na starszy poziom interfejsu API, użyj tego polecenia ADB:
adb install --bypass-low-target-sdk-block FILENAME.apk
Nazwy pakietów właścicieli multimediów mogą zostać usunięte
Magazyn multimediów obsługuje zapytania do kolumny OWNER_PACKAGE_NAME, która wskazuje aplikację, w której przechowywany jest określony plik multimedialny. Począwszy od Androida 14 ta wartość jest usuwana, chyba że spełniony jest co najmniej jeden z tych warunków:
- Aplikacja, która zapisała plik multimedialny, ma nazwę pakietu, która jest zawsze widoczna dla innych aplikacji.
Aplikacja, która wysyła zapytanie do sklepu multimedialnego, prosi o uprawnienie
QUERY_ALL_PACKAGES.
Dowiedz się więcej o tym, jak Android filtruje widoczność pakietów na potrzeby ochrony prywatności.