Изменения поведения: приложения для Android 14 или более поздней версии. Изменения поведения: приложения для Android 14 или более поздней версии. Изменения поведения: приложения для Android 14 или более поздней версии. Изменения поведения: приложения для Android 14 или более поздней версии.

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

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

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

Требуются типы служб переднего плана

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

Если вариант использования в вашем приложении не связан ни с одним из этих типов, настоятельно рекомендуется перенести вашу логику на использование WorkManager или заданий передачи данных, инициируемых пользователем .

Обеспечение разрешения BLUETOOTH_CONNECT в BluetoothAdapter

Android 14 применяет разрешение BLUETOOTH_CONNECT при вызове метода BluetoothAdapter getProfileConnectionState() для приложений, предназначенных для Android 14 (уровень API 34) или выше.

Для этого метода уже требовалось разрешение BLUETOOTH_CONNECT , но оно не было применено. Убедитесь, что ваше приложение объявляет BLUETOOTH_CONNECT в файле AndroidManifest.xml вашего приложения, как показано в следующем фрагменте, и убедитесь, что пользователь предоставил разрешение перед вызовом getProfileConnectionState .

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

Обновления OpenJDK 17

В Android 14 продолжается работа по обновлению основных библиотек Android, чтобы они соответствовали функциям последних выпусков OpenJDK LTS, включая обновления библиотек и поддержку языка Java 17 для разработчиков приложений и платформ.

Некоторые из этих изменений могут повлиять на совместимость приложений:

  • Изменения в регулярных выражениях : недопустимые ссылки на группы теперь запрещены, чтобы более точно соответствовать семантике OpenJDK. Вы можете столкнуться с новыми случаями, когда класс java.util.regex.Matcher генерирует исключение IllegalArgumentException , поэтому обязательно проверяйте свое приложение на наличие областей, в которых используются регулярные выражения. Чтобы включить или отключить это изменение во время тестирования, переключите флаг DISALLOW_INVALID_GROUP_REFERENCE с помощью инструментов платформы совместимости .
  • Обработка UUID : метод java.util.UUID.fromString() теперь выполняет более строгие проверки при проверке входного аргумента, поэтому во время десериализации вы можете увидеть IllegalArgumentException . Чтобы включить или отключить это изменение во время тестирования, переключите флаг ENABLE_STRICT_VALIDATION с помощью инструментов платформы совместимости .
  • Проблемы ProGuard . В некоторых случаях добавление класса java.lang.ClassValue вызывает проблемы, если вы пытаетесь сжать, запутать и оптимизировать свое приложение с помощью ProGuard. Проблема возникает из-за библиотеки Kotlin, которая меняет поведение во время выполнения в зависимости от того, возвращает ли Class.forName("java.lang.ClassValue") класс или нет. Если ваше приложение было разработано для более старой версии среды выполнения без доступного класса java.lang.ClassValue , то эти оптимизации могут удалить метод computeValue из классов, производных от java.lang.ClassValue .

JobScheduler усиливает обратный вызов и сетевое поведение

自从引入后，JobScheduler 期望您的应用从 onStartJob 或 onStopJob。在 Android 14 之前，如果作业运行时间过长，系统会停止作业并静默失败。如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台， 超过在主线程上授予的时间，应用会触发 ANR 显示“没有响应 onStartJob”错误消息或 “onStopJob没有回复”。

此 ANR 可能是由以下 2 种情况造成的： 1.有工作阻塞主线程，阻止回调 onStartJob 或者onStopJob在预期时间内执行并完成。 2. 开发者在 JobScheduler 中运行阻塞工作 回调 onStartJob 或 onStopJob，阻止从 在预期的时限内完成

要解决第 1 个问题，您需要进一步调试阻塞主线程的因素 您可以使用以下代码 ApplicationExitInfo#getTraceInputStream()，用于获取 Tombstone ANR 发生时的跟踪信息如果您能够手动重现 ANR 问题 您可以录制系统轨迹，并使用 Android Studio 或 Perfetto，以便更好地了解应用上运行的 在发生 ANR 时调用主线程 请注意，直接使用 JobScheduler API 或使用 androidx 库 WorkManager 时可能会发生这种情况。

如需解决问题 2，请考虑迁移到 WorkManager，它支持将 onStartJob 或 onStopJob 中的任何处理封装在异步线程中。

JobScheduler 还引入了一项要求，即如果使用 setRequiredNetworkType 或 setRequiredNetwork 约束条件，则必须声明 ACCESS_NETWORK_STATE 权限。如果您的应用未声明 ACCESS_NETWORK_STATE 权限 Android 14 或更高版本，则会导致 SecurityException。

API запуска плиток

Для приложений, предназначенных для версии 14 и выше, TileService#startActivityAndCollapse(Intent) устарел и теперь выдает исключение при вызове. Если ваше приложение запускает действия из плиток, используйте вместо этого TileService#startActivityAndCollapse(PendingIntent) .

Конфиденциальность

Частичный доступ к фотографиям и видео

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

Это изменение доступно только в том случае, если ваше приложение предназначено для Android 14 (уровень API 34) или более поздней версии. Если вы еще не используете средство выбора фотографий, мы рекомендуем внедрить его в свое приложение , чтобы обеспечить единообразный выбор изображений и видео, а также повысить конфиденциальность пользователей без необходимости запрашивать какие-либо разрешения на хранение.

Если вы поддерживаете свой собственный инструмент выбора галереи, используя разрешения на хранение, и вам необходимо сохранять полный контроль над своей реализацией, адаптируйте свою реализацию для использования нового разрешения READ_MEDIA_VISUAL_USER_SELECTED . Если ваше приложение не использует новое разрешение, система запускает его в режиме совместимости .

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

Безопасные полноэкранные уведомления о намерениях

В Android 11 (уровень API 30) любое приложение могло использовать Notification.Builder.setFullScreenIntent для отправки полноэкранных намерений, когда телефон заблокирован. Вы можете автоматически предоставить это разрешение при установке приложения, объявив разрешение USE_FULL_SCREEN_INTENT в AndroidManifest.

Полноэкранные уведомления о намерениях предназначены для уведомлений с чрезвычайно высоким приоритетом, требующих немедленного внимания пользователя, таких как входящий телефонный звонок или настройки будильника, настроенные пользователем. Для приложений, предназначенных для Android 14 (уровень API 34) или выше, приложения, которым разрешено использовать это разрешение, ограничены теми, которые обеспечивают только вызовы и сигналы тревоги. Магазин Google Play отзывает разрешения USE_FULL_SCREEN_INTENT по умолчанию для всех приложений, которые не соответствуют этому профилю. Крайний срок внесения этих изменений в политику — 31 мая 2024 года .

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

Вы можете использовать новый API NotificationManager.canUseFullScreenIntent чтобы проверить, имеет ли ваше приложение разрешение; в противном случае ваше приложение может использовать новое намерение ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT для запуска страницы настроек, на которой пользователи могут предоставить разрешение.

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

Ограничения на неявные и ожидаемые намерения

Для приложений, предназначенных для Android 14 (уровень API 34) или выше, Android запрещает приложениям отправлять неявные намерения внутренним компонентам приложения следующими способами:

  • Неявные намерения доставляются только экспортированным компонентам. Приложения должны либо использовать явное намерение доставить неэкспортированные компоненты, либо пометить компонент как экспортированный.
  • Если приложение создает изменяемое ожидающее намерение с намерением, в котором не указан компонент или пакет, система выдает исключение.

Эти изменения не позволяют вредоносным приложениям перехватывать неявные намерения, предназначенные для использования внутренними компонентами приложения.

Например, вот фильтр намерений , который можно объявить в файле манифеста вашего приложения:

<activity
    android:name=".AppActivity"
    android:exported="false">
    <intent-filter>
        <action android:name="com.example.action.APP_ACTION" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

Если ваше приложение попытается запустить это действие, используя неявное намерение, будет выдано исключение ActivityNotFoundException :

Котлин 

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(Intent("com.example.action.APP_ACTION"))

Ява 

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(new Intent("com.example.action.APP_ACTION"));

Чтобы запустить неэкспортируемое действие, ваше приложение должно вместо этого использовать явное намерение:

Котлин 

// This makes the intent explicit.
val explicitIntent =
        Intent("com.example.action.APP_ACTION")
explicitIntent.apply {
    package = context.packageName
}
context.startActivity(explicitIntent)

Ява 

// This makes the intent explicit.
Intent explicitIntent =
        new Intent("com.example.action.APP_ACTION")
explicitIntent.setPackage(context.getPackageName());
context.startActivity(explicitIntent);

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

Приложения и службы, ориентированные на Android 14 (уровень API 34) или выше и использующие приемники, зарегистрированные в контексте, должны указать флаг, указывающий, следует ли экспортировать приемник во все другие приложения на устройстве: либо RECEIVER_EXPORTED , либо RECEIVER_NOT_EXPORTED соответственно. . Это требование помогает защитить приложения от уязвимостей безопасности за счет использования функций этих приемников, представленных в Android 13 .

Исключение для приемников, которые принимают только системные трансляции.

Если ваше приложение регистрирует получателя только для системных широковещательных рассылок с помощью методов Context#registerReceiver , таких как Context#registerReceiver() , то ему не следует указывать флаг при регистрации получателя.

Более безопасная динамическая загрузка кода

如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台并使用动态代码 正在加载 (DCL)，所有动态加载的文件都必须标记为只读。 否则，系统会抛出异常。我们建议应用尽可能避免动态加载代码，因为这样做会大大增加应用因代码注入或代码篡改而遭到入侵的风险。

如果必须动态加载代码，请使用以下方法，在动态文件（例如 DEX、JAR 或 APK 文件）打开并写入任何内容之前立即将其设为只读：

Kotlin

val jar = File("DYNAMICALLY_LOADED_FILE.jar")
val os = FileOutputStream(jar)
os.use {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly()
    // Then write the actual file content
}
val cl = PathClassLoader(jar, parentClassLoader)

Java

File jar = new File("DYNAMICALLY_LOADED_FILE.jar");
try (FileOutputStream os = new FileOutputStream(jar)) {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly();
    // Then write the actual file content
} catch (IOException e) { ... }
PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);

处理已存在的动态加载文件

为防止系统对现有动态加载的文件抛出异常，我们建议您先删除并重新创建文件，然后再尝试在应用中重新动态加载这些文件。重新创建文件时，请按照上述指南在写入时将文件标记为只读。或者，您可以将现有文件重新标记为只读，但在这种情况下，我们强烈建议您先验证文件的完整性（例如，对照可信值检查文件的签名）以保护应用免遭恶意操作的影响。

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

Для приложений, ориентированных на Android 14 (уровень API 34) или выше, система дополнительно ограничивает, когда приложениям разрешено запускать действия в фоновом режиме:

  • Когда приложение отправляет PendingIntent с помощью PendingIntent#send() или аналогичных методов, приложение должно согласиться, если оно хочет предоставить свои собственные привилегии запуска фоновой активности для запуска ожидающего намерения. Чтобы принять участие, приложение должно передать пакет ActivityOptions с помощью setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED) .
  • Когда видимое приложение привязывает службу другого приложения, находящегося в фоновом режиме, с помощью bindService() , видимое приложение теперь должно согласиться, если оно хочет предоставить свои собственные привилегии запуска фоновой активности связанному сервису. Чтобы принять участие, приложение должно включить флаг BIND_ALLOW_ACTIVITY_STARTS при вызове метода bindService() .

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

Обход почтового индекса

Для приложений, предназначенных для Android 14 (уровень API 34) или выше, Android предотвращает уязвимость обхода пути Zip следующим образом: ZipFile(String) и ZipInputStream.getNextEntry() выдают исключение ZipException , если имена записей zip-файла содержат «..» или start. с "/".

Приложения могут отказаться от этой проверки, вызвав dalvik.system.ZipPathValidator.clearCallback() .

Для приложений, предназначенных для Android 14 (уровень API 34) или выше, MediaProjection#createVirtualDisplay создает исключение SecurityException в любом из следующих сценариев:

Ваше приложение должно запрашивать у пользователя согласие перед каждым сеансом захвата. Один сеанс захвата — это один вызов MediaProjection#createVirtualDisplay , и каждый экземпляр MediaProjection должен использоваться только один раз.

Обработка изменений конфигурации

Если вашему приложению необходимо вызвать MediaProjection#createVirtualDisplay для обработки изменений конфигурации (например, изменения ориентации или размера экрана), вы можете выполнить следующие действия, чтобы обновить VirtualDisplay для существующего экземпляра MediaProjection :

  1. Вызовите VirtualDisplay#resize с новой шириной и высотой.
  2. Предоставьте новую Surface с новой шириной и высотой для VirtualDisplay#setSurface .

Зарегистрируйте обратный звонок

Ваше приложение должно зарегистрировать обратный вызов для обработки случаев, когда пользователь не дает согласия на продолжение сеанса захвата. Для этого реализуйте Callback#onStop и освободите приложение все связанные ресурсы (например, VirtualDisplay и Surface ).

Если ваше приложение не регистрирует этот обратный вызов, MediaProjection#createVirtualDisplay выдает исключение IllegalStateException , когда ваше приложение его вызывает.

Обновлены ограничения, не связанные с SDK

Android 14 包含更新后的受限非 SDK 接口列表（基于与 Android 开发者之间的协作以及最新的内部测试）。在限制使用非 SDK 接口之前，我们会尽可能确保有可用的公开替代方案。

如果您的应用并非以 Android 14 为目标平台，其中一些变更可能不会立即对您产生影响。然而，虽然您目前仍可以使用一些非 SDK 接口（具体取决于应用的目标 API 级别），但只要您使用任何非 SDK 方法或字段，终归存在导致应用出问题的显著风险。

如果您不确定自己的应用是否使用了非 SDK 接口，则可以测试您的应用来进行确认。如果您的应用依赖于非 SDK 接口，您应该开始计划迁移到 SDK 替代方案。然而，我们知道某些应用具有使用非 SDK 接口的有效用例。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案，应请求新的公共 API。

Дополнительные сведения об изменениях в этой версии Android см . в разделе Обновления ограничений интерфейса, не связанных с SDK, в Android 14 . Дополнительные сведения об интерфейсах, отличных от SDK, см. в разделе Ограничения на интерфейсы, не относящиеся к SDK .