Platforma Android 14 obejmuje zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Poniższe zmiany w działaniu mają zastosowanie do wszystkich aplikacji działających na Androidzie 14, niezależnie od targetSdkVersion. Przetestuj aplikację, a następnie w razie potrzeby zmodyfikuj ją, aby obsługiwała te funkcje.
Przejrzyj też 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 wyłączone
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.
Transmisje zarejestrowanych przez kontekst są w kolejce do momentu, gdy aplikacje są buforowane
Na Androidzie 14 system może umieszczać komunikaty zarejestrowane na podstawie kontekstu w kolejce, gdy aplikacja jest w stanie pamięci podręcznej. Jest to podobne do mechanizmu kolejkowania wprowadzonego na Androidzie 12 (poziom interfejsu API 31) w przypadku transakcji powiązanych z asynchronicznymi powiązaniami. Komunikaty zadeklarowane w pliku manifestu nie są umieszczane w kolejce, a aplikacje są usuwane z pamięci podręcznej w celu dostarczenia transmisji.
Gdy aplikacja opuści stan pamięci podręcznej, np. wraca na pierwszy plan, system dostarczy wszystkie transmisje znajdujące się w kolejce. Kilka wystąpień określonych transmisji można połączyć w jedną transmisję. W zależności od innych czynników, takich jak kondycja systemu, aplikacje mogą zostać usunięte ze stanu z pamięci podręcznej i zostaną dostarczone wszystkie transmisje, które były wcześniej umieszczone w kolejce.
Aplikacje mogą wyłączać 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 żądającego 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 aplikację można umieścić 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 z ograniczeniem 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ą mlock(), do 64 KB na proces. We wcześniejszych wersjach limit ten wynosił 64 MB na proces. Takie ograniczenie ułatwia zarządzanie 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 aplikacji z pamięci podręcznej
Z założenia proces aplikacji znajduje się w pamięci podręcznej, gdy zostaje przeniesiony do tła i nie działają żadne inne jego komponenty. Taki proces aplikacji może zostać zatrzymany z powodu obciążenia pamięci systemu. Wszystkie działania Activity wykonywane po wywołaniu i zwróceniu metody onStop() są zawodne i zdecydowanie odradzamy takie działanie.
Android 14 wymaga spójności i egzekwowania zasad. Wkrótce po tym, jak proces aplikacji przejdzie do pamięci podręcznej, praca w tle będzie niedozwolona, dopóki komponent procesu ponownie nie wejdzie w aktywny stan cyklu życia.
Te zmiany nie powinny mieć wpływu na aplikacje korzystające z typowych interfejsów API cyklu życia obsługiwanych przez platformę, takich jak usługi, JobScheduler i Jetpack WorkManager.
Z perspektywy użytkownika
Zmiany dotyczące sposobu wyświetlania użytkownikom 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ą bardziej 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, który można zainstalować
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ściciela 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.