Изменения поведения: все приложения

Платформа Android 14 включает изменения в поведении, которые могут повлиять на ваше приложение. Следующие изменения поведения применяются ко всем приложениям , работающим на Android 14, независимо от targetSdkVersion . Вам следует протестировать свое приложение, а затем изменить его по мере необходимости, чтобы обеспечить его правильную поддержку, где это применимо.

Обязательно ознакомьтесь также со списком изменений поведения, которые влияют только на приложения, предназначенные для Android 14 .

Основная функциональность

Точные сигналы тревоги по расписанию запрещены по умолчанию

Точные сигналы тревоги предназначены для уведомлений, предназначенных пользователю, или для действий, которые должны произойти в определенное время. Начиная с Android 14, разрешение SCHEDULE_EXACT_ALARM больше не предоставляется заранее большинству недавно установленных приложений, предназначенных для Android 13 и более поздних версий — по умолчанию разрешение запрещено.

Узнайте больше об изменениях в разрешении на планирование точных сигналов тревоги .

Широковещательные рассылки, зарегистрированные в контексте, ставятся в очередь, а приложения кэшируются.

В Android 14 система может помещать трансляции с регистрацией контекста в очередь , пока приложение находится в кэшированном состоянии . Это похоже на поведение очередей, которое Android 12 (уровень API 31) представил для транзакций асинхронного связывания. Широковещательные передачи, объявленные в манифесте, не ставятся в очередь, а приложения удаляются из кэшированного состояния для широковещательной доставки.

Когда приложение выходит из кэшированного состояния, например, возвращается на передний план, система доставляет все поставленные в очередь широковещательные сообщения. Несколько экземпляров определенных трансляций могут быть объединены в одну трансляцию. В зависимости от других факторов, таких как состояние системы, приложения могут быть удалены из кэшированного состояния, и все ранее поставленные в очередь широковещательные сообщения будут доставлены.

Приложения могут убивать только свои фоновые процессы

Начиная с Android 14, когда ваше приложение вызывает killBackgroundProcesses() , API может уничтожать только фоновые процессы вашего собственного приложения.

Если вы передадите имя пакета другого приложения, этот метод не окажет влияния на фоновые процессы этого приложения, и в Logcat появится следующее сообщение:

Invalid packageName: com.example.anotherapp

Ваше приложение не должно использовать API killBackgroundProcesses() или иным образом пытаться влиять на жизненный цикл процессов других приложений, даже в более старых версиях ОС. Android предназначен для хранения кэшированных приложений в фоновом режиме и автоматического их закрытия, когда системе требуется память. Если ваше приложение без необходимости завершает работу других приложений, оно может снизить производительность системы и увеличить расход заряда батареи, поскольку позже потребуется полный перезапуск этих приложений, что требует значительно больше ресурсов, чем возобновление существующего кэшированного приложения.

MTU установлен на 517 для первого клиента GATT, запрашивающего MTU.

Начиная с Android 14, стек Android Bluetooth более строго соответствует версии 5.2 базовой спецификации Bluetooth и запрашивает MTU BLE ATT размером 517 байт, когда первый клиент GATT запрашивает MTU с помощью API BluetoothGatt#requestMtu(int) и игнорирует все последующие запросы MTU для этого соединения ACL.

Чтобы учесть это изменение и сделать ваше приложение более надежным, рассмотрите следующие варианты:

  • Ваше периферийное устройство должно ответить на запрос MTU устройства Android с разумным значением, которое может быть обработано периферийным устройством. Окончательное согласованное значение будет минимумом запрошенного значения Android и значения, предоставленного удаленным устройством (например, min(517, remoteMtu) )
    • Для реализации этого исправления может потребоваться обновление прошивки для периферийных устройств.
  • Альтернативно, ограничьте запись характеристик GATT на основе минимума между известным поддерживаемым значением вашего периферийного устройства и полученным изменением MTU.
    • Напоминаем, что вам следует уменьшить поддерживаемый размер заголовков на 5 байт.
    • Например: arrayMaxLength = min(SUPPORTED_MTU, GATT_MAX_ATTR_LEN(517)) - 5

Новая причина, по которой приложение можно поместить в резервную корзину с ограниченным доступом

Android 14 引入了将应用放入“受限待机”分桶的新原因。由于 onStartJobonStopJobonBind 方法超时,应用的作业会多次触发 ANR 错误。(如需了解对 onStartJobonStopJob 的更改,请参阅 JobScheduler 增强回调和网络行为。)

如需跟踪应用是否已进入“受限待机”分桶,我们建议您在作业执行时使用 API UsageStatsManager.getAppStandbyBucket() 进行日志记录,或者在应用启动时使用 UsageStatsManager.queryEventsForSelf() 进行日志记录。

mlock ограничен 64 КБ

В Android 14 (уровень API 34) и выше платформа уменьшает максимальный объем памяти, который можно заблокировать с помощью mlock() до 64 КБ на процесс. В предыдущих версиях ограничение составляло 64 МБ на процесс. Это ограничение способствует лучшему управлению памятью в приложениях и системе. Чтобы обеспечить большую согласованность между устройствами, в Android 14 добавлен новый тест CTS для нового ограничения mlock() на совместимых устройствах.

Система обеспечивает использование ресурсов кэшированного приложения.

По замыслу процесс приложения находится в кэшированном состоянии, когда он перемещается в фоновый режим и никакие другие компоненты процесса приложения не работают. Такой процесс приложения может быть уничтожен из-за нехватки системной памяти. Любая работа, выполняемая экземплярами Activity после вызова и возврата метода onStop() в этом состоянии, является ненадежной и настоятельно не рекомендуется.

Android 14 обеспечивает последовательность и строгость в этом дизайне. Вскоре после того, как процесс приложения переходит в кэшированное состояние, фоновая работа запрещается до тех пор, пока компонент процесса повторно не войдет в активное состояние жизненного цикла.

Эти изменения не должны затронуть приложения, которые используют типичные API жизненного цикла, поддерживаемые платформой, такие как сервисы , JobScheduler и Jetpack WorkManager .

Пользовательский опыт

Изменения в том, как пользователи видят уведомления, которые невозможно закрыть.

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

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

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

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

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

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

Информация о безопасности данных становится более наглядной

Чтобы повысить конфиденциальность пользователей, в Android 14 увеличено количество мест, где система отображает информацию, которую вы указали в форме Play Console. В настоящее время пользователи могут просмотреть эту информацию в разделе «Безопасность данных» на странице вашего приложения в Google Play.

Мы рекомендуем вам ознакомиться с политикой обмена данными о местоположении вашего приложения и внести необходимые обновления в раздел безопасности данных Google Play вашего приложения.

Узнайте больше в руководстве о том, как информация о безопасности данных становится более наглядной на Android 14.

Доступность

Нелинейное масштабирование шрифта до 200 %.

Начиная с Android 14, система поддерживает масштабирование шрифта до 200 %, предоставляя пользователям с плохим зрением дополнительные возможности доступа, соответствующие рекомендациям по доступности веб-контента (WCAG) .

Если вы уже используете масштабированные пиксели (sp) для определения размера текста, то это изменение, вероятно, не окажет большого влияния на ваше приложение. Однако вам следует выполнить тестирование пользовательского интерфейса с включенным максимальным размером шрифта (200%), чтобы убедиться, что ваше приложение может использовать шрифты большего размера без ущерба для удобства использования.

Безопасность

Минимальный устанавливаемый целевой уровень API

Начиная с Android 14, приложения с версией targetSdkVersion ниже 23 не могут быть установлены. Требование к приложениям соответствовать этим минимальным требованиям к целевому уровню API повышает безопасность и конфиденциальность пользователей.

Вредоносное ПО часто нацелено на старые уровни API, чтобы обойти средства безопасности и конфиденциальности, представленные в новых версиях Android. Например, некоторые вредоносные приложения используют targetSdkVersion , равный 22, чтобы избежать применения модели разрешений во время выполнения, представленной в 2015 году в Android 6.0 Marshmallow (уровень API 23). Это изменение в Android 14 усложняет вредоносным программам обход улучшений безопасности и конфиденциальности. Попытка установить приложение, ориентированное на более низкий уровень API, приведет к сбою установки, и в Logcat появится следующее сообщение:

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23, but found 7

На устройствах, обновляющихся до Android 14, все приложения с targetSdkVersion ниже 23 останутся установленными.

Если вам нужно протестировать приложение, ориентированное на более старый уровень API, используйте следующую команду ADB:

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

Названия пакетов владельцев носителей могут быть отредактированы.

Медиа-хранилище поддерживает запросы к столбцу OWNER_PACKAGE_NAME , который указывает приложение, в котором сохранился конкретный медиа-файл . Начиная с Android 14, это значение удаляется, если не выполняется хотя бы одно из следующих условий:

  • Приложение, в котором хранится медиафайл, имеет имя пакета, которое всегда видно другим приложениям.
  • Приложение, которое запрашивает хранилище мультимедиа, запрашивает разрешение QUERY_ALL_PACKAGES .

Узнайте больше о том, как Android фильтрует видимость пакетов в целях конфиденциальности.