Изменения в поведении: приложения для 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 . Если ваше приложение не использует новое разрешение, система запускает его в режиме совместимости .

Удобство использования

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

В 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) или более поздней версии, запрещено отправлять неявные намерения внутренним компонентам приложения. Это ограничение работает следующим образом:

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

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

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

<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:

Kotlin

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

Java

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

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

Kotlin

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

Java

// 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) или более поздней версии и использует динамическую загрузку кода, все динамически загружаемые файлы должны быть помечены как доступные только для чтения. В противном случае система выдаст исключение. Мы рекомендуем по возможности избегать динамической загрузки кода, поскольку она значительно повышает риск компрометации приложения в результате внедрения или изменения кода.

Если вам необходимо динамически загружать код, используйте следующий подход, чтобы установить для динамически загружаемого файла (например, 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 и запускать разрушительные действия в фоновом режиме.

Обход каталога в ZIP-архиве

Для приложений, предназначенных для 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 .