Как и в предыдущих версиях, в 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.
- Измените
Протестируйте все уведомления, использующие пользовательские представления, чтобы убедиться, что в тени они выглядят так, как вы ожидаете. При тестировании учитывайте следующие моменты и внесите необходимые изменения:
Размеры настраиваемых представлений изменились. В целом, высота настраиваемых уведомлений стала меньше, чем раньше. В свёрнутом состоянии максимальная высота настраиваемого контента уменьшилась со 106 до 48 dp. Кроме того, стало меньше горизонтального пространства.
Все уведомления можно развернуть для приложений, ориентированных на 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 и Schemeful SameSite .
Протестируйте поведение SameSite в вашем приложении
Если ваше приложение использует WebView или вы управляете веб-сайтом или сервисом, использующим файлы cookie, мы рекомендуем протестировать ваши потоки в WebView для Android 12. При обнаружении проблем может потребоваться обновить файлы 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, вы можете временно отключить изменение поведения в отлаживаемой версии сборки для целей тестирования. Для этого выполните одно из следующих действий:
- На экране настроек «Параметры разработчика» выберите «Изменения совместимости приложений» . На открывшемся экране нажмите на название приложения и отключите параметр 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, созданный на предыдущем шаге, как часть построения вашего уведомления .
Чтобы определить источник активности, например, для ведения журнала, используйте дополнительные элементы при публикации уведомления. Для централизованного ведения журнала используйте обратные ActivityLifecycleCallbacks или наблюдатели жизненного цикла Jetpack .
Переключить поведение
При тестировании отладочной версии вашего приложения вы можете включить и отключить это ограничение с помощью флага совместимости приложения NOTIFICATION_TRAMPOLINE_BLOCK .
Резервное копирование и восстановление
В приложениях, работающих на Android 12 (уровень API 31) и ориентированных на эту платформу, произошли изменения в работе резервного копирования и восстановления. Резервное копирование и восстановление в Android существует в двух вариантах:
- Резервное копирование в облаке: данные пользователя хранятся на Google Диске пользователя, чтобы их можно было впоследствии восстановить на этом или новом устройстве.
- Передача данных с устройства на устройство (D2D): данные пользователя отправляются напрямую на новое устройство пользователя со старого устройства, например, с помощью кабеля.
Дополнительную информацию о резервном копировании и восстановлении данных см. в разделах Резервное копирование пользовательских данных с помощью Auto Backup и Резервное копирование пар «ключ-значение» с помощью Android Backup Service .
Изменения функциональности передачи D2D
Для приложений, работающих на базе Android 12 и выше:
Настройка правил включения и исключения с помощью механизма конфигурации XML не влияет на передачу данных D2D, но по-прежнему влияет на резервное копирование и восстановление в облаке (например, резервное копирование Google Диска). Чтобы задать правила для передачи данных D2D, необходимо использовать новую конфигурацию, описанную в следующем разделе.
На устройствах некоторых производителей указание
android:allowBackup="false"отключает резервное копирование на Google Диск, но не отключает передачу данных D2D для приложения.
Новый формат включения и исключения
Приложения, работающие на Android 12 и более поздних версиях и предназначенные для них, используют другой формат XML-конфигурации. Этот формат делает различие между резервным копированием на Google Диск и переносом данных 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 . Затем демон подписывал устройство на многоадресные группы для всех узлов, что приводило к более частому пробуждению системы и повышенному энергопотреблению. Чтобы минимизировать расход заряда батареи, в 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 .