Zmiany w działaniu: wszystkie aplikacje

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. Należy przetestować aplikację, a następnie zmodyfikować ją w taki sposób, aby w odpowiednich przypadkach zapewniała prawidłowe działanie tych funkcji.

Sprawdź też listę zmian zachowania, które mają wpływ tylko na aplikacje kierowane na Androida 14.

Główna funkcja

Planowanie alarmów precyzyjnych jest domyślnie zablokowane

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 zarejestrowane w kontekście 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ą zabijać tylko własne procesy 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.

MTU jest ustawione na 517 w przypadku pierwszego klienta GATT żądającego MTU

从 Android 14 开始,Android 蓝牙堆栈会更严格地遵循蓝牙核心规范 5.2 版,当第一个 GATT 客户端使用 BluetoothGatt#requestMtu(int) API 请求 MTU 时,会请求将 BLE ATT MTU 设置为 517 个字节,并忽略针对该 ACL 连接的所有后续 MTU 请求。

如需解决此变更并提高应用的稳健性,请考虑以下选项:

  • 您的外围设备应使用可由外围设备适应的合理值来响应 Android 设备的 MTU 请求。最终商定的值将为 Android 请求的值和远程提供的值(例如 min(517, remoteMtu))中的最小值
    • 实现此修复可能需要更新外围设备的固件
  • 或者,根据外围设备的已知受支持值与接收到的 MTU 变化之间的最小值限制 GATT 特征写入
    • 温馨提示:您应该在支持的标头大小的基础上减少 5 个字节
    • 例如:arrayMaxLength = min(SUPPORTED_MTU, GATT_MAX_ATTR_LEN(517)) - 5

Nowy powód umieszczenia aplikacji w grupie ograniczonego trybu gotowości

Android 14 introduces a new reason an app can be placed into the restricted standby bucket. The app's jobs trigger ANR errors multiple times due to onStartJob, onStopJob, or onBind method timeouts. (See JobScheduler reinforces callback and network behavior for changes to onStartJob and onStopJob.)

To track whether or not the app has entered the restricted standby bucket, we recommend logging with the API UsageStatsManager.getAppStandbyBucket() on job execution or UsageStatsManager.queryEventsForSelf() on app startup.

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ą 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.

Interfejs użytkownika

Zmiany w sposobie wyświetlania użytkownikom powiadomień, których nie można zamknąć

如果您的应用向用户显示不可关闭的前台通知,请注意:Android 14 已更改此行为,允许用户关闭此类通知。

这项变更适用于阻止用户关闭前台的应用 将 Notification.FLAG_ONGOING_EVENT 设置为 Notification.Builder#setOngoing(true)NotificationCompat.Builder#setOngoing(true)FLAG_ONGOING_EVENT 的行为已发生变化,使用户实际上能够关闭此类通知。

在以下情况下,此类通知仍不可关闭:

  • 当手机处于锁定状态时
  • 如果用户选择全部清除通知操作(有助于防止意外关闭)

此外,这一新行为不适用于以下用例中的通知:

  • CallStyle 条通知
  • 企业设备政策控制器 (DPC) 和支持软件包
  • 媒体通知
  • 默认的搜索选择器软件包

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ę.

Bezpieczeństwo

Minimalny docelowy poziom interfejsu API, który można zainstalować

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ą 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.