Изменения в поведении: приложения, ориентированные на Android 12. Изменения в поведении: приложения, ориентированные на 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. Проверьте все уведомления, использующие пользовательские представления, и убедитесь, что в тени они выглядят так, как вы ожидаете. При тестировании примите во внимание эти соображения и внесите необходимые коррективы:

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

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

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

Изменения в проверке ссылок на приложения Android

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

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

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

Улучшения поведения «картинка в картинке»

В Android 12 представлены улучшения поведения для режима «картинка в картинке» (PiP) и рекомендованы косметические улучшения анимации перехода как для навигации с помощью жестов, так и для навигации на основе элементов.

Дополнительную информацию см . в разделе Улучшения «картинка в картинке» .

Редизайн тостов

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

Дополнительную информацию см. в обзоре тостов .

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

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

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

Примечание. В некоторых выпусках Android 12 это изменение всегда влияет на ваше приложение независимо от целевой версии SDK.

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

Компонент Android WebView основан на 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.

Полные инструкции для веб-разработчиков по этим изменениям см. в разделах «Описание файлов cookie SameSite» и «Схема SameSite» .

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

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

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

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

• Вручную включите поведение SameSite на тестовом устройстве , переключив флаг пользовательского интерфейса webview-enable-modern-cookie-same-site в инструментах разработчика WebView .

  Такой подход позволяет проводить тестирование на любом устройстве под управлением 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 посетите страницу обновлений SameSite для Chromium . Если вы обнаружите ошибку в 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:debuggable значение false перед выпуском приложения.

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

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

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

Если компонент приложения включает категорию 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 или новее

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

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:

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.

Примечание. Хотя приложения с разрешением SYSTEM_ALERT_WINDOW по-прежнему могут запускать действия с помощью трамплина уведомлений, вам следует избегать этого шаблона UX и вместо этого использовать PendingIntent .

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

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

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

Дополнительные сведения о резервном копировании и восстановлении данных см. в разделах Резервное копирование пользовательских данных с помощью автоматического резервного копирования и Резервное копирование пар «ключ-значение» с помощью службы резервного копирования Android .

Изменения в функции передачи D2D

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

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

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

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

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

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

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

Изменения формата 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 только для одной сети. По этой причине в 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 :

Котлин

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 .