Как и в предыдущих выпусках, в 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) .
Если ваше приложение использует полностью настраиваемые уведомления, мы рекомендуем как можно скорее протестировать новый шаблон.
Включите изменение пользовательских уведомлений:
- Измените
targetSdkVersionвашего приложения наS, чтобы включить новое поведение. - Перекомпилировать.
- Установите приложение на устройство или эмулятор под управлением Android 12.
- Измените
Протестируйте все уведомления, которые используют пользовательские представления, убедившись, что они выглядят так, как вы ожидаете в тени. Во время тестирования примите во внимание следующие соображения и внесите необходимые корректировки:
Размеры пользовательских представлений изменились. В целом, высота, предоставляемая пользовательским уведомлениям, меньше, чем раньше. В свернутом состоянии максимальная высота пользовательского контента уменьшилась с 106dp до 48dp. Также стало меньше горизонтального пространства.
Все уведомления можно развернуть для приложений, ориентированных на Android 12. Обычно это означает, что если вы используете
setCustomContentView, вам также нужно будет использоватьsetBigCustomContentView, чтобы убедиться, что свернутые и развернутые состояния соответствуют друг другу.Чтобы убедиться, что состояние «Heads Up» выглядит так, как вы ожидаете, не забудьте повысить важность канала уведомлений до «HIGH» (всплывающее уведомление на экране).
Изменения в проверке ссылок приложений Android
В приложениях, ориентированных на Android 12 или выше, система вносит несколько изменений в способ проверки ссылок приложений Android . Эти изменения повышают надежность процесса связывания приложений и предоставляют больше контроля разработчикам приложений и конечным пользователям.
Если вы полагаетесь на проверку ссылок на приложения Android для открытия веб-ссылок в своем приложении, проверьте, что вы используете правильный формат при добавлении фильтров намерений для проверки ссылок на приложения Android. В частности, убедитесь, что эти фильтры намерений включают категорию BROWSABLE и поддерживают схему https .
Вы также можете вручную проверить ссылки вашего приложения, чтобы проверить надежность ваших заявлений.
Улучшения поведения «картинка в картинке»
В Android 12 реализованы улучшения поведения режима «картинка в картинке» (PiP) и рекомендованы косметические улучшения анимации переходов как для навигации с помощью жестов, так и для навигации на основе элементов.
Более подробную информацию см. в разделе Улучшения функции «картинка в картинке» .
Редизайн тоста
В Android 12 вид тоста был переработан. Тосты теперь ограничены двумя строками текста и показывают значок приложения рядом с текстом.
Более подробную информацию см. в обзоре тостов .
Безопасность и конфиденциальность
Приблизительное местоположение
На устройствах под управлением Android 12 или более поздней версии пользователи могут запросить приблизительную точность определения местоположения для вашего приложения.
Современные файлы cookie SameSite в WebView
Компонент WebView в Android основан на Chromium , проекте с открытым исходным кодом, на котором работает браузер Chrome от Google. 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 и SameSite Schemeful .
Протестируйте поведение SameSite в вашем приложении
Если ваше приложение использует WebView или вы управляете веб-сайтом или службой, использующей файлы cookie, мы рекомендуем протестировать ваши потоки на Android 12 WebView. Если вы обнаружите проблемы, вам может потребоваться обновить файлы cookie для поддержки нового поведения SameSite.
Обращайте внимание на проблемы с входами в систему и встроенным контентом, а также с процессами входа в систему, покупками и другими процессами аутентификации, когда пользователь начинает с незащищенной страницы и переходит на защищенную страницу.
Чтобы протестировать приложение с помощью WebView, необходимо включить новые функции SameSite для приложения, которое вы хотите протестировать, выполнив одно из следующих действий:
Вручную включите поведение SameSite на тестовом устройстве , переключив флаг пользовательского интерфейса webview-enable-modern-cookie-same-site в WebView devtools .
Такой подход позволяет проводить тестирование на любом устройстве под управлением Android 5.0 (API уровня 21) или выше, включая Android 12, и WebView версии 89.0.4385.0 или выше.
Скомпилируйте свое приложение для Android 12 (уровень API 31) с помощью
targetSdkVersion.Если вы используете этот подход, вам необходимо использовать устройство под управлением Android 12.
Информацию об удаленной отладке 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 . Для приложений, предназначенных для Android 12 (уровень API 31) или выше, когда пользователь запускает команду adb backup , данные приложения исключаются из любых других системных данных, которые экспортируются с устройства.
Если ваши рабочие процессы тестирования или разработки зависят от данных приложения с использованием 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
Если ваше приложение содержит действие, службу или приемник вещания, который использует фильтры намерений, но не объявляет android:exported , в зависимости от используемой версии Android Studio появятся следующие предупреждающие сообщения:
Android Studio 2020.3.1 Canary 11 или более поздняя версия
Появляются следующие сообщения:
В вашем файле манифеста появляется следующее предупреждение lint:
When using intent filters, please specify android:exported as wellПри попытке скомпилировать приложение появляется следующее сообщение об ошибке сборки:
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 , который создает ваше приложение. Это дополнительное требование повышает безопасность вашего приложения.
Тест ожидаемого изменения изменчивости намерения
Чтобы определить, отсутствуют ли в вашем приложении объявления изменяемости, найдите следующее предупреждение lint в Android Studio:
Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]
Небезопасные намерения запускают
Для повышения безопасности платформы Android 12 и выше предоставляет функцию отладки, которая обнаруживает небезопасные запуски намерений . Когда система обнаруживает такой небезопасный запуск, происходит нарушение StrictMode .
Производительность
Ограничения на запуск приоритетных служб
Приложения, предназначенные для Android 12 или выше, не могут запускать службы переднего плана, работая в фоновом режиме , за исключением нескольких особых случаев . Если приложение пытается запустить службу переднего плана, работая в фоновом режиме, возникает исключение (за исключением нескольких особых случаев).
Рассмотрите возможность использования WorkManager для планирования и запуска ускоренной работы , пока ваше приложение работает в фоновом режиме. Чтобы завершить срочные действия, которые запрашивает пользователь, запустите службы переднего плана в точном сигнале тревоги .
Точное разрешение на сигнализацию
Чтобы приложения экономили системные ресурсы, приложения, предназначенные для Android 12 и выше и устанавливающие точные будильники, должны иметь доступ к функции «Будильники и напоминания», которая отображается на экране «Доступ к специальным приложениям» в настройках системы.
Чтобы получить этот специальный доступ к приложению, запросите разрешение SCHEDULE_EXACT_ALARM в манифесте.
Точные сигналы тревоги должны использоваться только для функций, ориентированных на пользователя. Узнайте больше о приемлемых вариантах использования для установки точного сигнала тревоги .
Отключить изменение поведения
При подготовке приложения к Android 12 вы можете временно отключить изменение поведения в отлаживаемом варианте сборки для целей тестирования. Для этого выполните одну из следующих задач:
- На экране настроек параметров разработчика выберите App Compatibility Changes . На появившемся экране нажмите на имя вашего приложения, затем отключите 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". Этот раздел содержит информацию, необходимую для идентификации компонента, который запускается в результате нажатия уведомления.
Обновите свое приложение
Если ваше приложение запускает действие из службы или приемника вещания, который действует как батут уведомлений, выполните следующие шаги по миграции:
- Создайте объект
PendingIntent, связанный с действием, которое пользователи видят после нажатия на уведомление. - Используйте объект
PendingIntent, созданный на предыдущем шаге, как часть создания уведомления .
Чтобы определить источник активности, например, для выполнения регистрации, используйте extras при публикации уведомления. Для централизованной регистрации используйте ActivityLifecycleCallbacks или Jetpack lifecycle observers .
Переключить поведение
При тестировании отлаживаемой версии вашего приложения вы можете включить и отключить это ограничение с помощью флага совместимости приложения NOTIFICATION_TRAMPOLINE_BLOCK .
Резервное копирование и восстановление
Изменения в работе резервного копирования и восстановления в приложениях, работающих на Android 12 (уровень API 31) и нацеленных на него. Резервное копирование и восстановление Android имеет две формы:
- Резервное копирование в облаке: данные пользователя хранятся на Google Диске пользователя, чтобы их можно было впоследствии восстановить на этом устройстве или на новом устройстве.
- Передача данных с устройства на устройство (D2D): данные пользователя отправляются напрямую на новое устройство пользователя со старого устройства, например, с помощью кабеля.
Дополнительную информацию о резервном копировании и восстановлении данных см. в разделах Резервное копирование пользовательских данных с помощью Auto Backup и Резервное копирование пар «ключ-значение» с помощью Android Backup Service .
Изменения функциональности передачи D2D
Для приложений, работающих на Android 12 и выше и ориентированных на него:
Указание правил включения и исключения с помощью механизма конфигурации XML не влияет на передачи D2D, хотя по-прежнему влияет на резервное копирование и восстановление в облаке (например, резервные копии Google Drive). Чтобы указать правила для передач D2D, необходимо использовать новую конфигурацию, описанную в следующем разделе.
На устройствах некоторых производителей указание
android:allowBackup="false"отключает резервное копирование на Google Диск, но не отключает передачу данных D2D для приложения.
Новый формат включения и исключения
Приложения, работающие на Android 12 и выше и ориентированные на него, используют другой формат для конфигурации XML. Этот формат делает разницу между резервным копированием Google Drive и передачей D2D явной, требуя от вас указывать правила включения и исключения отдельно для резервного копирования в облаке и для передачи D2D.
При желании вы также можете использовать его для указания правил резервного копирования, в этом случае ранее использованная конфигурация будет игнорироваться на устройствах под управлением 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>
Более подробную информацию см. в соответствующем разделе руководства по резервному копированию пользовательских данных с помощью Auto Backup.
Флаг манифеста для приложений
Укажите своим приложениям новую конфигурацию XML с помощью атрибута android:dataExtractionRules в вашем файле манифеста. Когда вы указываете на новую конфигурацию 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 . Эти разрешения упрощают взаимодействие приложений, предназначенных для Android 12, с устройствами Bluetooth , особенно для приложений, которым не требуется доступ к местоположению устройства.
Чтобы подготовить свое устройство к использованию Android 12 или выше, обновите логику своего приложения. Вместо того, чтобы объявлять устаревший набор разрешений Bluetooth , объявляйте более современный набор разрешений Bluetooth .
Одновременный одноранговый доступ + подключение к Интернету
Для приложений, ориентированных на Android 12 (уровень API 31) или выше, устройства, поддерживающие одновременные одноранговые и интернет-подключения, могут поддерживать одновременные Wi-Fi-подключения как к одноранговому устройству, так и к основной сети, предоставляющей интернет, что делает пользовательский опыт более плавным. Приложения, ориентированные на Android 11 (уровень API 30) или ниже, по-прежнему сталкиваются с устаревшим поведением, когда основная сеть Wi-Fi отключается перед подключением к одноранговому устройству.
Совместимость
WifiManager.getConnectionInfo() может вернуть WifiInfo только для одной сети. Из-за этого поведение API было изменено следующим образом в Android 12 и выше:
- Если доступна только одна сеть Wi-Fi, возвращается ее
WifiInfo. - Если доступно более одной сети Wi-Fi и вызывающее приложение инициировало одноранговое соединение, возвращается
WifiInfo, соответствующий одноранговому устройству. - Если доступно более одной сети Wi-Fi и вызывающее приложение не инициировало одноранговое соединение, возвращается
WifiInfoосновного интернет-подключения.
Чтобы обеспечить лучший пользовательский интерфейс на устройствах, поддерживающих две одновременные сети Wi-Fi, мы рекомендуем всем приложениям, особенно тем, которые инициируют одноранговые соединения, отказаться от вызова WifiManager.getConnectionInfo() и вместо этого использовать NetworkCallback.onCapabilitiesChanged() для получения всех объектов WifiInfo , соответствующих NetworkRequest , используемому для регистрации NetworkCallback . getConnectionInfo() устарело, начиная с Android 12.
В следующем примере кода показано, как получить WifiInfo в NetworkCallback :
Котлин
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 ... } }
Ява
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; ... } ... };
Собственный API mDNSResponder
Android 12 изменяет, когда приложения могут взаимодействовать с демоном mDNSResponder с помощью собственного API mDNSResponder . Ранее, когда приложение регистрировало службу в сети и вызывало метод getSystemService() , служба NSD системы запускала демон mDNSResponder, даже если приложение еще не вызывало методы NsdManager . Затем демон подписывался на многоадресные группы all-nodes, заставляя систему чаще просыпаться и потреблять дополнительную энергию. Чтобы минимизировать расход заряда батареи, в Android 12 и выше система теперь запускает демон mDNSResponder только тогда, когда он нужен для событий NSD, и останавливает его после этого.
Поскольку это изменение влияет на то, когда доступен демон mDNSResponder, приложения, которые предполагают, что демон mDNSResponder будет запущен после вызова метода getSystemService() могут получать сообщения от системы о том, что демон mDNSResponder недоступен. Приложения, которые используют NsdManager и не используют собственный API mDNSResponder, не затронуты этим изменением.
Библиотеки поставщиков
Собственные общие библиотеки, предоставляемые поставщиком
Собственные общие библиотеки, не относящиеся к NDK , предоставляемые поставщиками кремниевых чипов или производителями устройств, по умолчанию недоступны, если приложение ориентировано на Android 12 (уровень API 31) или выше. Библиотеки доступны только в том случае, если они явно запрошены с помощью тега <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 .
Чтобы узнать больше об изменениях в этой версии Android, см. Обновления ограничений интерфейсов, не относящихся к SDK, в Android 12. Чтобы узнать больше об интерфейсах, не относящихся к SDK, см. Ограничения интерфейсов, не относящихся к SDK .