Эта страница переведена с помощью Cloud Translation API.

Изменения в поведении: приложения, ориентированные на 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. Измените targetSdkVersion вашего приложения на S чтобы включить новое поведение.
2. Перекомпилируйте.
3. Установите приложение на устройство или эмулятор под управлением 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 со всплывающим всплывающим сообщением «Отправка сообщения» рядом со значком приложения.

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

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

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

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

Современные файлы 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 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 или новее

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

В файле манифеста появится следующее предупреждение:
```
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 , создаваемого вашим приложением. Это дополнительное требование повышает безопасность вашего приложения.

Проверьте ожидающее изменение изменчивости намерения

Чтобы определить, отсутствуют ли в вашем приложении объявления об изменчивости, найдите следующее предупреждение в 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): пользовательские данные передаются непосредственно на новое устройство пользователя со старого устройства, например, с помощью кабеля.

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

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

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

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

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

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

Включите изменение пользовательских уведомлений:
1. Измените targetSdkVersion вашего приложения на S чтобы включить новое поведение.
2. Перекомпилируйте.
3. Установите приложение на устройство или эмулятор под управлением Android 12.
Проверьте все уведомления, использующие пользовательские представления, и убедитесь, что в тени они выглядят так, как вы ожидаете. При тестировании примите во внимание эти соображения и внесите необходимые коррективы:
- Изменились размеры пользовательских представлений. В целом высота, предоставляемая пользовательским уведомлениям, меньше, чем раньше. В свернутом состоянии максимальная высота пользовательского контента уменьшилась со 106dp до 48dp. Кроме того, здесь меньше горизонтального пространства.
- Все уведомления можно расширять для приложений, ориентированных на Android 12. Обычно это означает, что если вы используете setCustomContentView , вам также понадобится использовать setBigCustomContentView чтобы убедиться, что свернутое и развернутое состояния согласованы.
- Чтобы состояние «Heads Up» выглядело так, как вы ожидаете, не забудьте повысить важность канала уведомлений до «HIGH» (Всплывающие окна на экране).

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

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

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

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

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

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

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

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

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

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

Проверьте поведение 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 .

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

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

Узнайте больше об ограничении скорости сенсора .

Спящий режим приложения

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

Узнайте больше в руководстве по спящему режиму приложения .

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

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

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

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

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

В вашем файле Manifest появляется предупреждение о 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 и выше предоставляют функцию отладки, которая обнаруживает небезопасные запуска намерений . Когда система обнаруживает такой небезопасенный запуск, происходит нарушение строгих мод .

Производительность

Ограничения запуска обслуживания переднего плана

Приложения, которые нацелены на 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
```

Уведомление об ограничениях батута

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

Чтобы повысить производительность приложений и UX, приложения, которые нацелены на 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 Lifecycle Observers .

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

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

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

Существуют изменения в том, как работает резервное копирование и восстановление в приложениях, которые работают, и нацелены на Android 12 (API -уровень 31). Android Backup and Restore имеет две формы:

Облачное резервное копирование: пользовательские данные хранятся в Google Drive пользователя, чтобы позже его можно было восстановить на этом устройстве или на новом устройстве.
Трансферы устройства к устройствам (D2D): Пользовательские данные отправляются непосредственно на новое устройство пользователя с их более старого устройства, например, с помощью кабеля.

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

Изменения функциональности передачи D2D

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

Указание включает и исключайте правила с механизмом конфигурации XML, не влияет на передачу D2D, хотя он все еще влияет на облачное резервное копирование и восстановление (например, резервное копирование Google Drive). Чтобы указать правила для передачи D2D, вы должны использовать новую конфигурацию, описанную в следующем разделе.
На устройствах от некоторых производителей устройств, указание android:allowBackup="false" отключает резервное копирование на Google Drive, но не отключает 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>

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

Manifest Flag для приложений

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

<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, и приложение Calling не вызвало одноранговое соединение, то возвращается основное 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;
    ...
  }
  ...
};

Mdnsresponder Native API

Android 12 изменяется, когда приложения могут взаимодействовать с демоном mdnsresponder, используя нативный API Mdnsresponder . Ранее, когда приложение зарегистрировало службу в сети и называлось методом getSystemService() , служба NSD системы запустила Daemon 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 интерфейсы.

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

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

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

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

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

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

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

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

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

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

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

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

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

Включить пользовательские уведомления измениться:
1. Измените targetSdkVersion вашего приложения на S чтобы обеспечить новое поведение.
2. Перекомпилировать.
3. Установите свое приложение на устройство или эмулятор под управлением Android 12.
Проверьте все уведомления, которые используют пользовательские представления, гарантируя, что они выглядят так, как вы ожидаете в тени. Во время тестирования примите во внимание эти соображения и внесите необходимые корректировки:
- Размеры пользовательских видов изменились. В целом, высота, предоставленная пользовательским уведомлениям, меньше, чем раньше. В разрушенном состоянии максимальная высота пользовательского содержания уменьшилась с 106dp до 48dp. Кроме того, горизонтального пространства меньше.
- Все уведомления расширяются для приложений, нацеленных на Android 12. Как правило, это означает, что если вы используете setCustomContentView , вы также захотите использовать setBigCustomContentView чтобы убедиться, что свернутые и расширенные состояния являются согласованными.
- Чтобы убедиться, что состояние «головы» выглядит так, как вы ожидаете, не забудьте повысить важность канала уведомлений до «высокого» (всплывающий на экране).

Ссылки на приложение Android

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

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

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

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

Android 12 вводит улучшение поведения для режима изображения в картинке (PIP) и рекомендуется косметические улучшения в переходной анимации как для навигации по жестам, так и для навигации на основе элементов.

См. Улучшения с картинкой в картинке для получения дополнительной информации.

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

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

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

См. Обзор Toasts для получения более подробной информации.

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

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

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

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

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

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

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

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

Для получения полного руководства для веб -разработчиков в этих изменениях см. SameSite Cookie, объясненные и схему Sameful SameSite .

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

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

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

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

Вручную включите поведение SameSite на тестовом устройстве , включив флаг UI Flag Webview-ENABLE-SODERN-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 атрибут для этих компонентов приложения.

<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 Studio 2020.3.1 Canary 11 или позже

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

В вашем файле Manifest появляется предупреждение о 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'

В ожидании изменений

Проверьте ожидающее изменение изменений в намерениях

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Небезопасное намерение запускает

Производительность

Ограничения запуска обслуживания переднего плана

Точное разрешение тревоги

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

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

На экране параметров разработчиков выберите «Изменения совместимости приложения» . На появлении экрана нажмите имя вашего приложения, затем выключите require_exact_alarm_permission .
В окне терминала на вашем машине разработки запустите следующую команду:
```
adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
```

Уведомление об ограничениях батута

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

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

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

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

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

Облачное резервное копирование: пользовательские данные хранятся в Google Drive пользователя, чтобы позже его можно было восстановить на этом устройстве или на новом устройстве.
Трансферы устройства к устройствам (D2D): Пользовательские данные отправляются непосредственно на новое устройство пользователя с их более старого устройства, например, с помощью кабеля.

Изменения функциональности передачи D2D

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

Указание включает и исключайте правила с механизмом конфигурации XML, не влияет на передачу D2D, хотя он все еще влияет на облачное резервное копирование и восстановление (например, резервное копирование Google Drive). Чтобы указать правила для передачи D2D, вы должны использовать новую конфигурацию, описанную в следующем разделе.
На устройствах от некоторых производителей устройств, указание android:allowBackup="false" отключает резервное копирование на Google Drive, но не отключает D2D -трансфер для приложения.

Новое включает и исключает формат

Формат 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>

Manifest Flag для приложений

<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

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

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

Если доступен только одна сеть Wi-Fi, ее WifiInfo возвращается.
Если доступно более одной сети Wi-Fi, и вызывающее приложение запустило одноранговое соединение, возвращается WifiInfo соответствующее устройству с одноранговым одноразовым.
If more than one Wi-Fi network is available and the calling app did not trigger a peer-to-peer connection, the primary internet-providing connection's WifiInfo is returned.

To provide a better user experience on devices that support dual concurrent Wi-Fi networks, we recommend all apps—especially ones that trigger peer-to-peer connections—migrate away from calling WifiManager.getConnectionInfo() and instead use NetworkCallback.onCapabilitiesChanged() to get all WifiInfo objects that match the NetworkRequest used to register the NetworkCallback . getConnectionInfo() is deprecated as of Android 12.

The following code sample shows how to get the WifiInfo in a 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;
    ...
  }
  ...
};

mDNSResponder native API

Android 12 changes when apps can interact with the mDNSResponder daemon using the mDNSResponder native API . Previously, when an app registered a service on the network and called the getSystemService() method, the system's NSD service started the mDNSResponder daemon, even if the app had not called any NsdManager methods yet. The daemon then subscribed the device to the all-nodes multicast groups, causing the system to wake more frequently and use additional power. To minimize battery usage, in Android 12 and higher the system now starts the mDNSResponder daemon only when it is needed for NSD events and stops it afterwards.

Because this change affects when the mDNSResponder daemon is available, apps that assume that the mDNSResponder daemon will be started after calling the getSystemService() method might receive messages from the system that say that the mDNSResponder daemon is not available. Apps that use NsdManager and do not use the mDNSResponder native API are unaffected by this change.

Vendor libraries

Vendor-supplied native shared libraries

Non-NDK native shared libraries that are provided by silicon vendors or device manufacturers are not accessible by default if the app is targeting Android 12 (API level 31) or higher. The libraries are accessible only when they are explicitly requested using the <uses-native-library> tag.

If the app is targeting Android 11 (API level 30) or lower, the <uses-native-library> tag is not required. In that case, any native shared library is accessible regardless of whether it is an NDK library.

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

Android 12 включает обновленные списки ограниченных интерфейсов, не входящих в SDK, на основе сотрудничества с разработчиками Android и последних результатов внутреннего тестирования. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

Если вы не уверены, использует ли ваше приложение интерфейсы, отличные от SDK, вы можете проверить свое приложение , чтобы выяснить это. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API .

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 12 . To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces .