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
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ą zatrzymywać tylko własne procesy w tle
Począwszy od Androida 14, gdy aplikacja wywołuje metodę killBackgroundProcesses(), interfejs API może kończyć tylko procesy Twojej aplikacji w tle.
Jeśli przekażesz nazwę pakietu innej aplikacji, ta metoda nie będzie miała wpływu na jej procesy w tle, a w Logcat pojawi się następujący komunikat:
Invalid packageName: com.example.anotherapp
Aplikacja nie powinna używać interfejsu killBackgroundProcesses() API ani w żaden inny sposób wpływać na cykl życia innych aplikacji, nawet w starszych wersjach systemu operacyjnego.
Android zapisuje aplikacje z pamięci podręcznej w tle i automatycznie je zamyka, gdy system potrzebuje pamięci. Jeśli aplikacja niepotrzebnie zatrzymuje inne aplikacje, może ograniczyć wydajność systemu i zwiększyć zużycie baterii, ponieważ później będzie wymagać pełnego ponownego uruchomienia tych aplikacji, co wymaga znacznie większej ilości zasobów niż wznawianie działania aplikacji zapisanej w pamięci podręcznej.
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
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 w 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 w wyświetlaniu powiadomień, których nie można zamknąć
Jeśli Twoja aplikacja wyświetla użytkownikom powiadomienia na pierwszym planie, których nie można zamknąć, Android 14 zmienił to działanie, aby użytkownicy mogli je odrzucić.
Ta zmiana ma zastosowanie do aplikacji, które uniemożliwiają użytkownikom zamykanie powiadomień na pierwszym planie przez ustawienie wartości od Notification.FLAG_ONGOING_EVENT do Notification.Builder#setOngoing(true) lub NotificationCompat.Builder#setOngoing(true). Działanie FLAG_ONGOING_EVENT zostało zmienione, aby użytkownik mógł odrzucić takie powiadomienia.
Tego rodzaju powiadomień nie można zamknąć pod tymi warunkami:
- Gdy telefon jest zablokowany
- Jeśli użytkownik wybierze działanie związane z powiadomieniem Wyczyść wszystko (co pomaga w przypadkowych odrzuceniach).
Ten nowy sposób nie dotyczy też powiadomień w tych przypadkach użycia:
- Powiadomienia z
CallStyle - Kontroler zasad dotyczących urządzeń (DPC) i pakiety pomocnicze dla firm
- Powiadomienia o multimediach
- Domyślny pakiet selektora wyszukiwania
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.