Платформа Android 14 включает изменения в поведении, которые могут повлиять на ваше приложение. Следующие изменения в поведении применяются ко всем приложениям, работающим на Android 14, независимо от targetSdkVersion . Вам следует протестировать свое приложение, а затем внести необходимые изменения для корректной поддержки этих изменений, где это применимо.
Обязательно ознакомьтесь также со списком изменений в поведении, которые затрагивают только приложения, ориентированные на Android 14 .
Основная функциональность
Точная настройка времени для оповещений по умолчанию запрещена.
Exact alarms are meant for user-intentioned notifications, or for actions that
need to happen at a precise time. Starting in Android 14, the
SCHEDULE_EXACT_ALARM
permission is no longer being pre-granted to most newly installed apps
targeting Android 13 and higher—the permission is denied by default.
Learn more about the changes to the permission for scheduling exact alarms.
Контекстно-зависимая передача данных ставится в очередь, в то время как приложения кэшируются.
В Android 14 система может помещать трансляции с регистрацией контекста в очередь , пока приложение находится в кэшированном состоянии . Это похоже на поведение очередей, которое Android 12 (уровень API 31) представил для транзакций асинхронного связывания. Широковещательные передачи, объявленные в манифесте, не ставятся в очередь, а приложения удаляются из кэшированного состояния для широковещательной доставки.
Когда приложение выходит из кэшированного состояния, например, возвращается на передний план, система доставляет все поставленные в очередь широковещательные сообщения. Несколько экземпляров определенных трансляций могут быть объединены в одну трансляцию. В зависимости от других факторов, таких как состояние системы, приложения могут быть удалены из кэшированного состояния, и все ранее поставленные в очередь широковещательные сообщения будут доставлены.
Приложения могут завершать только свои собственные фоновые процессы.
Starting in Android 14, when your app calls killBackgroundProcesses(),
the API can kill only the background processes of your own app.
If you pass in the package name of another app, this method has no effect on that app's background processes, and the following message appears in Logcat:
Invalid packageName: com.example.anotherapp
Your app shouldn't use the killBackgroundProcesses() API or otherwise attempt
to influence the process lifecycle of other apps, even on older OS versions.
Android is designed to keep cached apps in the background and kill them
automatically when the system needs memory. If your app kills other apps
unnecessarily, it can reduce system performance and increase battery consumption
by requiring full restarts of those apps later, which takes significantly more
resources than resuming an existing cached app.
Для первого клиента GATT, запрашивающего MTU, значение MTU устанавливается равным 517.
Starting from Android 14, the Android Bluetooth stack more strictly adheres to
Version 5.2 of the Bluetooth Core Specification and requests
the BLE ATT MTU to 517 bytes when the first GATT client requests an MTU using
the BluetoothGatt#requestMtu(int) API, and disregards all subsequent MTU
requests on that ACL connection.
To address this change and make your app more robust, consider the following options:
- Your peripheral device should respond to the Android device's MTU request
with a reasonable value that can be accommodated by the peripheral. The
final negotiated value will be a minimum of the Android requested value and
the remote provided value (for example,
min(517, remoteMtu))- Implementing this fix could require a firmware update for peripheral
- Alternatively, limit your GATT characteristic writes based on the minimum
between the known supported value of your peripheral and the received MTU
change
- A reminder that you should reduce 5 bytes from the supported size for the headers
- For example:
arrayMaxLength = min(SUPPORTED_MTU, GATT_MAX_ATTR_LEN(517)) - 5
Новая причина, по которой приложение может быть помещено в категорию ограниченного режима ожидания.
В Android 14 появилась новая причина, по которой приложение можно поместить в ограниченный резервный сегмент . Задания приложения несколько раз вызывают ошибки ANR из-за таймаутов метода onStartJob , onStopJob или onBind . (См. JobScheduler усиливает обратный вызов и сетевое поведение для изменений в onStartJob и onStopJob .)
Чтобы отслеживать, вошло ли приложение в ограниченный резервный сегмент, мы рекомендуем войти в журнал с помощью 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 .
пользовательский опыт
Изменения в том, как пользователи воспринимают уведомления, которые нельзя закрыть.
If your app shows non-dismissable foreground notifications to users, Android 14 has changed the behavior to allow users to dismiss such notifications.
This change applies to apps that prevent users from dismissing foreground
notifications by setting Notification.FLAG_ONGOING_EVENT through
Notification.Builder#setOngoing(true) or
NotificationCompat.Builder#setOngoing(true). The behavior of
FLAG_ONGOING_EVENT has changed to make such notifications actually
dismissable by the user.
These kinds of notifications are still non-dismissable in the following conditions:
- When the phone is locked
- If the user selects a Clear all notification action (which helps with accidental dismissals)
Also, this new behavior doesn't apply to notifications in the following use cases:
CallStylenotifications- Device policy controller (DPC) and supporting packages for enterprise
- Media notifications
- The default Search Selector package
Информация о безопасности данных становится более доступной.
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.
Доступность
Нелинейное масштабирование шрифта до 200%.
Starting in Android 14, the system supports font scaling up to 200%, providing users with additional accessibility options.
If you already use scaled pixels (sp) units to define text sizing, then this change probably won't have a high impact on your app. However, you should perform UI testing with the maximum font size enabled (200%) to ensure that your app can accommodate larger font sizes without impacting usability.
Безопасность
Минимальный уровень 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
Названия пакетов медиа-владельцев могут быть скрыты.
The media store supports queries for the OWNER_PACKAGE_NAME column, which
indicates the app that stored a particular media file. Starting in Android
14, this value is redacted unless at least one of the following conditions is
true:
- The app that stored the media file has a package name that is always visible to other apps.
The app that queries the media store requests the
QUERY_ALL_PACKAGESpermission.
Learn more about how Android filters package visibility for privacy purposes.