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

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

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

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

Специальные уведомления

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

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

Таким образом, в Android 12 все уведомления визуально согласованы и легко сканируются, а также имеют понятное и знакомое пользователям расширение.

На иллюстрации ниже показано специальное уведомление в стандартном шаблоне.

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

Изменение в Android 12 влияет на приложения, в которых определены пользовательские подклассы Notification.Style или используются методы Notification.Builder: setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) и setCustomHeadsUpContentView(RemoteViews).

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

  1. Включите специальные уведомления:

    1. Чтобы включить новые функции, измените targetSdkVersion приложения на S.
    2. Перекомпилируйте.
    3. Установите приложение на устройство или эмулятор с Android 12.

  2. Проверьте все уведомления, в которых используются специальные представления, и убедитесь, что они выглядят правильно. При тестировании учитывайте следующие факторы и вносите необходимые корректировки:

    • Размеры специальных представлений изменились. В целом высота, выделяемая для специальных уведомлений, стала меньше, чем раньше. В свернутом состоянии максимальная высота пользовательского контента уменьшилась со 106 до 48 dp. Кроме того, у них меньше места по горизонтали.

    • В приложениях, предназначенных для Android 12, все уведомления можно развернуть. Как правило, это означает, что если вы используете setCustomContentView, то вам также нужно использовать setBigCustomContentView, чтобы обеспечить согласованность свернутого и развернутого состояний.

    • Чтобы всплывающие уведомления выглядели так, как вы ожидаете, не забудьте повысить важность канала уведомлений до уровня "Высокая" (всплывающие уведомления).

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

Если вы используете проверку ссылок на приложения для Android, чтобы открывать веб-ссылки в приложении, убедитесь, что при добавлении фильтров намерений для проверки ссылок на приложения для Android вы используете правильный формат. В частности, убедитесь, что эти фильтры намерений включают категорию BROWSABLE и поддерживают схему https.

Вы также можете вручную проверить ссылки в приложении, чтобы убедиться в надежности деклараций.

Улучшения в режиме "Картинка в картинке"

В Android 12 улучшена работа режима "картинка в картинке" и анимация переходов при навигации жестами и по элементам.

Подробнее об улучшениях режима "Картинка в картинке"…

Новый дизайн всплывающих уведомлений

В Android 12 изменен дизайн тостов. Теперь всплывающие уведомления ограничены двумя строками текста и содержат значок приложения.

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

Подробную информацию можно найти в обзоре всплывающих уведомлений.

Безопасность и конфиденциальность

Приблизительное местоположение

На устройствах с Android 12 и более поздних версий пользователи могут разрешить приложению определять только приблизительное местоположение.

Современные файлы cookie SameSite в WebView

Компонент WebView для Android основан на Chromium – проекте с открытым исходным кодом, на базе которого работает браузер Google Chrome. В Chromium были внесены изменения, касающиеся обработки сторонних файлов cookie. Это позволило повысить безопасность и конфиденциальность, а также обеспечить пользователям большую прозрачность и контроль. Начиная с Android 12, эти изменения также включены в WebView, если приложения поддерживают Android 12 (уровень API 31) или более поздние версии.

Атрибут SameSite файла cookie определяет, можно ли отправлять его со всеми запросами или только с запросами к одному сайту. Следующие изменения, направленные на защиту конфиденциальности, улучшают обработку сторонних файлов cookie по умолчанию и помогают предотвратить непреднамеренную передачу данных между сайтами:

  • Файлы cookie без атрибута SameSite обрабатываются как SameSite=Lax.
  • Файлы cookie с атрибутом SameSite=None также должны содержать атрибут Secure. Это означает, что они требуют безопасного контекста и должны передаваться по протоколу HTTPS.
  • Ссылки между версиями сайта с протоколами HTTP и HTTPS теперь обрабатываются как межсайтовые запросы, поэтому файлы cookie не отправляются, если они не помечены как SameSite=None; Secure.

Разработчикам рекомендуется определить, какие из критически важных путей пользователей зависят от межсайтовых файлов cookie, и убедиться, что атрибут SameSite явно задан с нужными значениями там, где это необходимо. Вам необходимо явно указать файлы cookie, которые могут использоваться на разных сайтах или при переходе с HTTP на HTTPS в пределах одного сайта.

Полные инструкции для веб-разработчиков по этим изменениям можно найти в статьях SameSite Cookies Explained (Объяснение файлов cookie SameSite) и Schemeful SameSite (Атрибут SameSite с учетом схемы).

Протестируйте поведение SameSite в своем приложении

Если в вашем приложении используется WebView или вы управляете сайтом или сервисом, использующим файлы cookie, рекомендуем протестировать ваши процессы в WebView на Android 12. Если вы обнаружите проблемы, вам может потребоваться обновить файлы cookie, чтобы обеспечить поддержку новых моделей поведения SameSite.

Обратите внимание на проблемы со входом и встроенным контентом, а также на процессы входа, покупки и другие процессы аутентификации, в которых пользователь начинает с небезопасной страницы и переходит на безопасную.

Чтобы протестировать приложение с WebView, необходимо включить новые правила SameSite для приложения, которое вы хотите протестировать, выполнив одно из следующих действий:

Подробную информацию об удаленной отладке WebView на устройствах Android можно найти в статье Начало работы с удаленной отладкой устройств Android.

Другие ресурсы

Дополнительную информацию о современных принципах работы атрибута SameSite и его внедрении в Chrome и WebView можно найти на странице обновлений Chromium SameSite. Если вы обнаружите ошибку в WebView или Chromium, сообщите о ней в общедоступной системе отслеживания ошибок Chromium.

Частота запросов к датчикам движения ограничена

Чтобы защитить потенциально конфиденциальную информацию о пользователях, в Android 12 и более поздних версиях ОС система ограничивает частоту обновления данных от некоторых датчиков движения и положения.

Подробнее об ограничении частоты запросов к датчикам…

Гибернация приложений

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

Подробнее о гибернации приложений…

Декларация атрибуции в проверке доступа к данным

API для проверки доступа к данным, представленный в Android 11 (уровень API 30), позволяет создавать теги атрибуции на основе способов использования приложения. Эти теги позволяют легко определить, какая часть приложения выполняет определенный тип доступа к данным.

Если ваше приложение предназначено для Android 12 или более поздней версии, вы должны объявить эти теги атрибуции в файле манифеста приложения.

Ограничение на резервное копирование ADB

Чтобы защитить личные данные приложений, в Android 12 изменен режим работы по умолчанию для команды adb backup. Если пользователь выполняет команду adb backup в приложении, предназначенном для Android 12 (уровень API 31) или более поздней версии, данные приложения исключаются из всех остальных системных данных, экспортируемых с устройства.

Если ваши рабочие процессы тестирования или разработки зависят от данных приложения, использующих adb backup, вы можете включить экспорт данных приложения, установив для android:debuggable значение true в файле манифеста приложения.

Более безопасный экспорт компонентов

Если ваше приложение предназначено для Android 12 или более поздней версии и содержит действия, сервисы или широковещательные приемники, которые используют фильтры намерений, вы должны явно объявить атрибут android:exported для этих компонентов приложения.

Если компонент приложения включает категорию LAUNCHER, задайте для android:exported значение true. В большинстве других случаев задайте для параметра android:exported значение false.

В следующем фрагменте кода показан пример сервиса, который содержит фильтр интентов с атрибутом android:exported, для которого задано значение false:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

Сообщения в Android Studio

Если в вашем приложении есть Activity, сервис или широковещательный приемник, который использует фильтры интентов, но не объявляет android:exported, то в зависимости от версии Android Studio вы увидите одно из следующих предупреждений:

Android Studio 2020.3.1 Canary 11 или более поздней версии;

Появятся следующие сообщения:

  1. В файле манифеста появляется следующее предупреждение:

    When using intent filters, please specify android:exported as well

  2. При попытке скомпилировать приложение появляется следующее сообщение об ошибке:

    Manifest merger failed : Apps targeting Android 12 and higher are required \
to specify an explicit value for android:exported when the corresponding \
component has an intent filter defined.
Более ранние версии Android Studio

Если вы попытаетесь установить приложение, Logcat покажет следующее сообщение об ошибке:

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

Изменяемость отложенных интентов

Если ваше приложение предназначено для Android 12, вы должны указать изменяемость каждого объекта PendingIntent, создаваемого приложением. Это дополнительное требование повышает безопасность приложения.

Протестируйте изменение изменяемости отложенного интента

Чтобы определить, отсутствуют ли в вашем приложении объявления изменяемости, найдите в Android Studio следующее предупреждение lint:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Запуск небезопасных намерений

Чтобы повысить безопасность платформы, в Android 12 и более поздних версиях предусмотрена функция отладки, которая обнаруживает небезопасные запуски намерений. Если система обнаруживает такой небезопасный запуск, происходит нарушение StrictMode.

Эффективность

Ограничения на запуск активных служб

Приложения, предназначенные для Android 12 и более поздних версий, не могут запускать активные службы в фоновом режиме, за исключением нескольких особых случаев. Если приложение пытается запустить активную службу, работая в фоновом режиме, возникает исключение (за исключением нескольких особых случаев).

Рекомендуем использовать WorkManager, чтобы планировать и запускать приоритетные задачи, пока приложение работает в фоновом режиме. Чтобы выполнять срочные действия, запрашиваемые пользователем, запускайте активные службы в точное время.

Разрешение на выполнение операций в точное время

Чтобы приложения экономили системные ресурсы, у приложений, предназначенных для Android 12 и более поздних версий и использующих операции в точное время, должен быть доступ к функции "Будильники и напоминания", которая находится в разделе Специальный доступ в настройках системы.

Чтобы получить этот специальный доступ, запросите разрешение SCHEDULE_EXACT_ALARM в манифесте.

Операции в точное время должны использоваться только для пользовательских функций. Подробнее о допустимых случаях использования точных будильников…

Как отключить изменение поведения

При подготовке приложения к Android 12 вы можете временно отключить изменение поведения в варианте сборки для отладки, чтобы провести тестирование. Для этого нужно сделать что-либо из следующего:

  • В разделе Для разработчиков выберите Изменения совместимости приложений. На открывшемся экране нажмите на название приложения и отключите параметр REQUIRE_EXACT_ALARM_PERMISSION.

  • В окне терминала на компьютере для разработки выполните следующую команду:

    adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME

Ограничения на запуск действий из уведомлений

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

Чтобы повысить производительность приложений и удобство работы с ними, в приложениях для Android 12 и более поздних версий нельзя запускать действия из сервисов или широковещательных приемников, которые используются в качестве трамплинов для уведомлений. Другими словами, после того как пользователь нажмет на уведомление или командную кнопку в нем, ваше приложение не сможет вызвать startActivity() внутри сервиса или широковещательного приемника.

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

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

Определите, какие компоненты приложения действуют как трамплины для уведомлений.

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

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

В одном из разделов выходных данных есть текст "NotifInteractionLog". В этом разделе содержится информация, необходимая для идентификации компонента, который запускается в результате нажатия на уведомление.

Обновите приложение

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

  1. Создайте объект PendingIntent, связанный с действием, которое пользователи увидят после нажатия на уведомление.
  2. Используйте объект PendingIntent, созданный на предыдущем шаге, в качестве части создаваемого уведомления.

Чтобы определить источник действия, например для ведения журнала, используйте дополнительные параметры при публикации уведомления. Для централизованного ведения журналов используйте ActivityLifecycleCallbacks или наблюдатели жизненного цикла Jetpack.

Переключить поведение

При тестировании отладочной версии приложения вы можете включать и отключать это ограничение с помощью флага совместимости NOTIFICATION_TRAMPOLINE_BLOCK.

резервное копирование и восстановление;

В приложениях, которые работают на Android 12 (уровень API 31) и поддерживают эту версию ОС, изменились принципы резервного копирования и восстановления данных. Резервное копирование и восстановление данных на устройствах Android может выполняться двумя способами:

  • Резервные копии в облаке. Пользовательские данные хранятся на Google Диске, чтобы их можно было восстановить на том же или новом устройстве.
  • Передача с устройства на устройство. Пользовательские данные отправляются напрямую со старого устройства на новое, например по кабелю.

Дополнительную информацию о резервном копировании и восстановлении данных можно найти в статьях Автоматическое резервное копирование пользовательских данных и Резервное копирование пар "ключ-значение" с помощью Android Backup Service.

Изменения в функциях прямой передачи данных

Для приложений, работающих на Android 12 и более поздних версиях и предназначенных для них:

  • Правила включения и исключения, заданные с помощью механизма конфигурации XML, не влияют на передачу данных между устройствами, но по-прежнему влияют на облачное резервное копирование и восстановление (например, на резервные копии Google Диска). Чтобы задать правила для переноса данных с устройства на устройство, используйте новую конфигурацию, описанную в следующем разделе.

  • На устройствах некоторых производителей указание android:allowBackup="false" отключает резервное копирование на Google Диск, но не отключает передачу данных между устройствами для приложения.

Новый формат включения и исключения

В приложениях, предназначенных для Android 12 и более поздних версий, используется другой формат XML-конфигурации. Этот формат позволяет явно указать разницу между резервным копированием на Google Диск и переносом данных с устройства на устройство, поскольку правила включения и исключения для этих двух процессов задаются отдельно.

При желании вы также можете использовать его, чтобы задать правила резервного копирования. В этом случае ранее использованная конфигурация будет игнорироваться на устройствах с Android 12 или более поздней версии. Старая конфигурация по-прежнему требуется для устройств с Android 11 или более ранней версией.

Изменения в формате XML

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

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

Изменения в формате выделены полужирным шрифтом.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

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

Параметр в манифесте для приложений

Укажите в файле манифеста атрибут android:dataExtractionRules, чтобы приложения использовали новую XML-конфигурацию. Если вы укажете новый XML-файл конфигурации, атрибут android:fullBackupContent, указывающий на старый файл, будет игнорироваться на устройствах с Android 12 и более поздними версиями. В приведенном ниже фрагменте кода показаны новые записи в файле манифеста:

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

Функции связи

Разрешения Bluetooth

В Android 12 появились разрешения BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE и BLUETOOTH_CONNECT. Эти разрешения упрощают взаимодействие с устройствами Bluetooth для приложений, предназначенных для Android 12, особенно для тех, которым не требуется доступ к данным о местоположении устройства.

Чтобы подготовить устройство к работе с Android 12 или более поздней версией, обновите логику приложения. Вместо устаревшего набора разрешений Bluetooth используйте более современный.

Одновременное одноранговое подключение и подключение к интернету

Если приложение предназначено для Android 12 (уровень API 31) или более поздней версии, устройства, поддерживающие одновременное одноранговое подключение и подключение к интернету, могут поддерживать одновременные подключения по Wi-Fi как к одноранговому устройству, так и к основной сети, обеспечивающей доступ к интернету, что делает работу пользователя более удобной. В приложениях, предназначенных для Android 11 (уровень API 30) или более ранних версий, по-прежнему будет использоваться прежний алгоритм, при котором основная сеть Wi-Fi отключается перед подключением к одноранговому устройству.

Совместимость

WifiManager.getConnectionInfo() может возвращать WifiInfo только для одной сети. Поэтому в Android 12 и более поздних версиях поведение API изменилось следующим образом:

  • Если доступна только одна сеть Wi-Fi, возвращается ее WifiInfo.
  • Если доступно несколько сетей Wi-Fi и приложение для звонков инициировало одноранговое подключение, возвращается WifiInfo, соответствующий одноранговому устройству.
  • Если доступно несколько сетей Wi-Fi и приложение для звонков не инициировало одноранговое подключение, возвращается WifiInfo основного подключения к интернету.

Чтобы повысить удобство работы на устройствах, поддерживающих одновременное подключение к двум сетям Wi-Fi, мы рекомендуем всем приложениям, особенно тем, которые инициируют одноранговые подключения, отказаться от вызова WifiManager.getConnectionInfo() и вместо этого использовать NetworkCallback.onCapabilitiesChanged(), чтобы получить все объекты WifiInfo, соответствующие NetworkRequest, используемому для регистрации NetworkCallback. getConnectionInfo() не поддерживается в Android 12 и более поздних версиях.

В примере кода ниже показано, как получить WifiInfo в NetworkCallback:

Kotlin

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

Java

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

mDNSResponder native API

В Android 12 изменились условия, при которых приложения могут взаимодействовать с демоном mDNSResponder через mDNSResponder native API. Ранее, когда приложение регистрировало сервис в сети и вызывало метод getSystemService(), системный сервис NSD запускал фоновый процесс mDNSResponder, даже если приложение ещё не вызывало методы NsdManager. Затем демон подписывал устройство на многоадресные группы всех узлов, из-за чего система чаще выходила из спящего режима и потребляла больше энергии. Чтобы снизить расход заряда батареи, в Android 12 и более поздних версиях демон mDNSResponder запускается только при необходимости для событий NSD, а затем останавливается.

Поскольку это изменение влияет на доступность демона mDNSResponder, приложения, которые предполагают, что демон mDNSResponder будет запущен после вызова метода getSystemService(), могут получать от системы сообщения о том, что демон mDNSResponder недоступен. Изменение не затронет приложения, которые используют NsdManager и не используют нативный API mDNSResponder.

Библиотеки поставщиков

Общие библиотеки, предоставленные поставщиком

Общие нативные библиотеки, не относящиеся к NDK и предоставляемые производителями микросхем или устройств, по умолчанию недоступны, если целевой уровень API приложения – 31 (Android 12) или выше. Библиотеки доступны, только если они явно запрашиваются с помощью тега <uses-native-library>.

Если приложение предназначено для Android 11 (уровня API 30) или более ранней версии, тег <uses-native-library> не требуется. В этом случае любая нативная общая библиотека будет доступна независимо от того, является ли она библиотекой NDK.

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

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

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

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

Подробнее об изменениях в ограничениях на использование интерфейсов, не входящих в SDK, в Android 12… Подробнее об ограничениях на интерфейсы, не входящие в SDK…