Изменения в поведении: приложения, ориентированные на Android 12.

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

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

пользовательский опыт

Пользовательские уведомления

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

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

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

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

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

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

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

1. Включите изменение пользовательских уведомлений:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Более подробную информацию см. в разделе «Обзор всплывающих уведомлений» .

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

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

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

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

Современные файлы 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» и «Schemeful 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 посетите страницу обновлений 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: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:export>ed=&q<uot;false&quo>t;
    in<tent-filter
        action android:name="com.exampl>e.app<.START_BACKGRO>U<ND"> /
    /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 по-прежнему могут запускать действия с помощью всплывающих уведомлений, следует избегать этого шаблона пользовательского интерфейса и вместо него использовать 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 Drive). Для указания правил для передачи данных между устройствами необходимо использовать новую конфигурацию, описанную в следующем разделе.

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

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

Приложения, работающие на Android 12 и выше и ориентированные на эту операционную систему, используют другой формат XML-конфигурации. Этот формат явно указывает на разницу между резервным копированием в Google Drive и передачей данных напрямую в облако (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"
    requireFl<ags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    exclude domain=["file<" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
/full-backup-content>

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

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|fa>lse"]
  <  ...
    include domain=["file" | "database" | "sharedpref" | "external" |
          <              "root"] path="string"/>
    ...
    exclude domain=["file" | "database&q<uot; | ">sha<redpref" |> "extern<al" |
                        "root"] path="string"/>
    ...
  /cloud-backup
  device-transfer
  <  ...
    include domain=["file" | "database" | "sharedpref" | "external" |
        <                >&<quot;root"] path=>"string"/>
    ...
    exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  /device-transfer
/data-extraction-rules

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

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

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

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.x<ml"
    !-- 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 .

Одновременное подключение к сети P2P + интернет-соединение

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

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;
    ...
  }
  ...
};

собственный 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» .