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. Przetestuj aplikację, a następnie w razie potrzeby zmodyfikuj ją, aby prawidłowo obsługiwała te zmiany.
Zapoznaj się też z listą zmian w działaniu, które wpływają tylko na aplikacje kierowane na Androida 14.
Główna funkcjonalność
Domyślnie odrzucane są alarmy ustawione na dokładną godzinę
Alarmy precyzyjne są przeznaczone do powiadomień, które użytkownik chce otrzymać, lub do działań, które muszą być wykonane w określonym czasie. Od Androida 14 uprawnienia SCHEDULE_EXACT_ALARM nie są wstępnie przyznawane większości nowo instalowanych aplikacji kierowanych na Androida 13 i nowsze wersje – domyślnie są one odrzucane.
Dowiedz się więcej o zmianach w uprawnieniach dotyczących planowania dokładnych alarmów.
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ą zamykać 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 ustawiana na 517 w przypadku pierwszego klienta GATT, który zażąda 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 ograniczonej grupie gotowości
Android 14 引入了一种可将应用放入受限待机模式存储分区的新原因。由于 onStartJob、onStopJob 或 onBind 方法超时,应用的作业多次触发 ANR 错误。(如需了解对 onStartJob 和 onStopJob 的更改,请参阅 JobScheduler 强化了回调和网络行为。)
如需跟踪应用是否已进入受限待机分桶,我们建议您在作业执行时使用 API UsageStatsManager.getAppStandbyBucket() 进行日志记录,或在应用启动时使用 UsageStatsManager.queryEventsForSelf() 进行日志记录。
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ą funkcji mlock(), do 64 KB na proces. W poprzednich wersjach limit wynosił 64 MB na proces. To ograniczenie sprzyja lepszemu zarządzaniu 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 przez aplikacje przechowywane w 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, JobScheduler i Jetpack WorkManager.
Wrażenia użytkownika
Zmiany w sposobie, w jaki użytkownicy korzystają z powiadomień, których nie można odrzucić
如果您的应用向用户显示不可关闭的前台通知,请注意: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
为了加强用户隐私保护,Android 14 增加了系统显示您在 Play 管理中心表单中声明的信息的位置数量。目前,用户可以在 Google Play 中的应用详情的数据安全部分查看此信息。
我们建议您查看应用的位置数据分享政策,并花一点时间对应用的 Google Play“数据安全”部分进行任何适用的更新。
如需了解详情,请参阅有关如何在 Android 14 上以更显眼的方式显示数据安全信息的指南。
Ułatwienia dostępu
Nieliniowe skalowanie czcionek do 200%
从 Android 14 开始,系统支持将字体放大至最高 200%,为用户提供更多无障碍选项。
如果您已使用可缩放像素 (sp) 单位来定义文本大小,这项更改可能不会对您的应用产生太大影响。不过,您应在启用最大字号 (200%) 的情况下执行界面测试,确保应用能够在不影响易用性的情况下适应较大的字号。
Bezpieczeństwo
Minimalny poziom docelowego interfejsu API z możliwością zainstalowania
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ć ocenzurowane
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ść.