Zmiany w działaniu: wszystkie aplikacje

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. W razie potrzeby przetestuj aplikację i zmodyfikuj ją, aby prawidłowo obsługiwała te funkcje.

Zapoznaj się też z listą zmian w zachowaniu, które mają wpływ tylko na aplikacje kierowane na Androida 14.

Główna funkcja

Domyślnie odrzucane są prośby o zaplanowanie alarmów precyzyjnych

精确的闹钟适用于用户指定的通知,或是在确切时间需要执行的操作。从 Android 14 开始,系统不再向以 Android 13 及更高版本为目标平台的大多数新安装应用预先授予 SCHEDULE_EXACT_ALARM 权限,该权限默认处于拒绝状态。

详细了解安排精确闹钟的权限变化

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

Począwszy od Androida 14, gdy Twoja aplikacja wywołuje killBackgroundProcesses(), interfejs API może zakończyć tylko procesy w tle Twojej aplikacji.

Jeśli podasz nazwę pakietu innej aplikacji, ta metoda nie będzie miała wpływu na procesy w tle tej aplikacji. W Logcat pojawi się wtedy taki komunikat:

Invalid packageName: com.example.anotherapp

Aplikacja nie powinna używać interfejsu API killBackgroundProcesses() ani w inny sposób próbować wpływa na cykl życia innych aplikacji, nawet w starszych wersjach systemów operacyjnych. Android został zaprojektowany tak, aby utrzymywał w tle aplikacje z pamięci podręcznej i zabijał je automatycznie, gdy system potrzebuje pamięci. Jeśli aplikacja wyłącza inne aplikacje może zmniejszyć wydajność systemu i zwiększyć zużycie baterii, wymagając późniejszego pełnego ponownego uruchomienia, co zajmuje znacznie niż wznowienie istniejącej aplikacji w pamięci podręcznej.

Wartość MTU jest ustawiona na 517 w przypadku pierwszego klienta GATT, który wysyła żądanie MTU.

Począwszy od Androida 14 stos Bluetooth w tym systemie operacyjnym ściślej przestrzega specyfikacji Bluetooth Core w wersji 5.2 i ustawia MTU BLE ATT na 517 bajtów, gdy pierwszy klient GATT żąda MTU za pomocą interfejsu API BluetoothGatt#requestMtu(int), oraz ignoruje wszystkie kolejne żądania MTU dotyczące tego połączenia ACL.

Aby uwzględnić tę zmianę i ulepszyć aplikację, rozważ te opcje:

  • Urządzenie peryferyjne powinno odpowiadać na żądanie MTU urządzenia z Androidem odpowiednią wartością, która może być obsługiwana przez urządzenie peryferyjne. Ostateczna wynegocjowana wartość będzie stanowić minimum wartości żądanej przez Androida i wartości podawanej przez urządzenie zdalne (np. min(517, remoteMtu)).
    • Wdrożenie tej poprawki może wymagać aktualizacji oprogramowania urządzenia peryferyjnego.
  • Możesz też ograniczyć zapisywanie właściwości GATT na podstawie minimalnej wartości obsługiwanej przez Twoje urządzenie peryferyjne i otrzymanej zmiany MTU.
    • Przypomnienie, że należy zmniejszyć o 5 bajtów obsługiwany rozmiar nagłówków
    • Na przykład: arrayMaxLength = min(SUPPORTED_MTU, GATT_MAX_ATTR_LEN(517)) - 5

Nowy powód, dla którego aplikacja może zostać umieszczona w ograniczonym zasobniku 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 onStartJobonStopJob, 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

在 Android 14(API 级别 34)及更高版本中,平台将可使用 mlock() 锁定的最大内存量减少到每个进程 64 KB。在之前的版本中,每个进程的上限为 64 MB。此限制有助于更好地管理应用和系统的内存。为了在各种设备上提供更一致的体验,Android 14 针对兼容设备上的新 mlock() 限制添加了一项新的 CTS 测试

System wymusza wykorzystanie zasobów aplikacji 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, JobSchedulerJetpack WorkManager.

Interfejs użytkownika

Zmiany w sposobie wyświetlania 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 Zmieniliśmy sposób działania, aby umożliwić użytkownikom odrzucanie takich powiadomień.

Ta zmiana dotyczy aplikacji, które uniemożliwiają użytkownikom odrzucanie powiadomień na pierwszym planie przez ustawienie Notification.FLAG_ONGOING_EVENTNotification.Builder#setOngoing(true) lub NotificationCompat.Builder#setOngoing(true). Działanie funkcji Aplikacja FLAG_ONGOING_EVENT zmieniła ustawienie, aby takie powiadomienia były które użytkownik może odrzucić.

Tego rodzaju powiadomień nadal nie można odrzucić w przypadku: warunki:

  • Gdy telefon jest zablokowany
  • Jeśli użytkownik wybierze działanie powiadomienia Wyczyść wszystko (co ułatwia przypadkowe odrzucenia)

Nowe zachowanie nie dotyczy też powiadomień w tych przypadkach użycia:

  • CallStyle powiadomień
  • Kontroler zasad dotyczących urządzeń (DPC) i obsługujące pakiety dla firm
  • Powiadomienia o multimediach
  • Domyślny pakiet selektora wyszukiwania

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%, zapewniając użytkownikom ze słabym wzrokiem dodatkowe opcje ułatwień dostępu zgodne z wytycznymi Web Content Accessibility Guidelines (WCAG).

Jeśli do definiowania rozmiaru tekstu używasz już skalowanych pikseli (sp), ta zmiana prawdopodobnie nie będzie miała dużego wpływu na Twoją aplikację. Powinieneś jednak przeprowadzić testy interfejsu z włączonym maksymalnym rozmiarem czcionki (200%), aby mieć pewność, ż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ę

Od Androida 14 nie można instalować aplikacji z wersją targetSdkVersion niższą niż 23. aplikacje muszą spełniać wymagania dotyczące minimalnego docelowego poziomu interfejsu API; zwiększają bezpieczeństwo i prywatność użytkowników.

Złośliwe oprogramowanie często atakuje starsze poziomy interfejsu API, aby ominąć zabezpieczenia i prywatność zabezpieczeń wprowadzonych w nowszych wersjach Androida. Przykład: niektóre złośliwe aplikacje używają tych zabezpieczeń: targetSdkVersion z 22, model uprawnień czasu działania wprowadzony w 2015 r. przez Androida 6.0 Marshmallow (API) poziom 23). Ta zmiana w Androidzie 14 utrudnia złośliwemu unikaniu zabezpieczeń i lepszą ochronę prywatności. Próba zainstalowania aplikacji kierowanej na niższy poziom interfejsu API spowoduje niepowodzenie instalacji i wyświetlenie tego komunikatu w Logcat:

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 wersją targetSdkVersion niższą niż 23.

Jeśli chcesz przetestować aplikację kierowaną na starszy poziom interfejsu API, użyj tego ADB polecenie:

adb install --bypass-low-target-sdk-block FILENAME.apk

Nazwy pakietów właścicieli multimedió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ść.