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

Изменения поведения: все приложения

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

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

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

Растянуть эффект прокрутки

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

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

Дополнительные сведения см. в руководстве по анимации жестов прокрутки .

Заставки приложений

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

Инструкции см. в разделе «Миграция существующей реализации заставки на Android 12» .

Кроме того, начиная с Android 12, система всегда применяет новый экран-заставку системы Android по умолчанию при холодном и теплом запуске для всех приложений. По умолчанию этот системный экран-заставка по умолчанию создается с использованием элемента значка средства запуска вашего приложения и windowBackground вашей темы (если он одноцветный).

Дополнительные сведения см. в руководстве разработчика заставок .

Разрешение веб-намерений

Начиная с Android 12 (уровень API 31), общее веб-намерение преобразуется в действие в вашем приложении только в том случае, если ваше приложение одобрено для определенного домена, содержащегося в этом веб-намерении. Если ваше приложение не одобрено для домена, вместо этого веб-намерение разрешается в браузерное приложение пользователя по умолчанию.

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

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

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

Улучшения режима погружения для навигации с помощью жестов.

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

Display#getRealSize и getRealMetrics: устаревание и ограничения

Устройства Android доступны во многих различных форм-факторах, таких как большие экраны, планшеты и складные устройства. Чтобы правильно отображать контент для каждого устройства, вашему приложению необходимо определить размер экрана или дисплея. Со временем Android предоставил различные API для получения этой информации. В Android 11 мы представили API WindowMetrics и объявили устаревшими следующие методы:

В Android 12 мы по-прежнему рекомендуем использовать WindowMetrics и объявляем устаревшими следующие методы:

Чтобы смягчить поведение приложений, использующих Display API для получения границ приложения, Android 12 ограничивает значения, возвращаемые API-интерфейсами для приложений, размер которых не может быть полностью изменен. Это может повлиять на приложения, которые используют эту информацию с помощью MediaProjection .

Приложения должны использовать API-интерфейсы WindowMetrics для запроса границ своего окна и Configuration.densityDpi для запроса текущей плотности.

Для более широкой совместимости со старыми версиями Android вы можете использовать библиотеку Jetpack WindowManager , включающую класс WindowMetrics , поддерживающий Android 4.0 (уровень API 14) и выше.

Примеры использования WindowMetrics

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

Действие должно полагаться на WindowMetrics из контекста действия для любой работы, связанной с пользовательским интерфейсом, особенно WindowManager.getCurrentWindowMetrics() или WindowMetricsCalculator.computeCurrentWindowMetrics() Jetpack.

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

Если размер приложения можно полностью изменить, контекст активности возвращает правильные границы, например:

Котлин

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

Ява

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

Если размер приложения не может быть полностью изменен, оно должно выполнить запрос из экземпляра WindowContext и получить WindowMetrics границ активности с помощью WindowManager.getMaximumWindowMetrics() или метода Jetpack WindowMetricsCalculator.computeMaximumWindowMetrics() .

Котлин

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Ява

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

Все приложения в многооконном режиме

В Android 12 многооконный режим становится стандартным.

На больших экранах (sw >= 600dp) платформа поддерживает все приложения в многооконном режиме независимо от конфигурации приложения. Если resizeableActivity="false" приложение переводится в режим совместимости, когда это необходимо для соответствия размерам дисплея.

На маленьких экранах (sw < 600dp) система проверяет minWidth и minHeight действия, чтобы определить, может ли действие выполняться в многооконном режиме. Если resizeableActivity="false" , приложение не сможет работать в многооконном режиме независимо от минимальной ширины и высоты.

Дополнительную информацию см. в разделе Поддержка многооконного режима .

Предварительный просмотр камеры на больших экранах

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

В Android 12 приложения камеры, которые запрашивают определенную ориентацию экрана и не имеют возможности изменения размера ( resizeableActivity="false" ), автоматически переходят в портретный режим вставки, который обеспечивает правильную ориентацию и соотношение сторон предварительного просмотра камеры. На складных устройствах и других устройствах, имеющих уровень аппаратной абстракции камеры ( HAL ), к выходным данным камеры применяется дополнительный поворот, чтобы компенсировать ориентацию датчика камеры, а выходные данные камеры обрезаются, чтобы соответствовать соотношению сторон предварительного просмотра камеры приложения. Обрезка и дополнительный поворот обеспечивают правильное представление предварительного просмотра камеры независимо от ориентации устройства и его сложенного или развернутого состояния.

Задержка UX для уведомлений служб переднего плана

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

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

Ограниченный сегмент ожидания приложений

В Android 11 (уровень API 30) сегмент с ограниченным доступом представлен как сегмент ожидания приложения. Начиная с Android 12, этот сегмент активен по умолчанию. Ограниченный сегмент имеет самый низкий приоритет (и самые высокие ограничения) из всех сегментов. Корзины в порядке приоритета от высокого к низкому:

Активно: приложение используется в данный момент или использовалось совсем недавно.
Рабочий набор: Приложение используется регулярно.
Часто: приложение используется часто, но не каждый день.
Редко: приложение используется нечасто.
Ограничено: приложение потребляет много системных ресурсов или может демонстрировать нежелательное поведение.

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

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

Проверьте, находится ли ваше приложение в ограниченном сегменте

Чтобы проверить, поместила ли система ваше приложение в корзину с ограниченным доступом, вызовите getAppStandbyBucket() . Если возвращаемое значение этого метода STANDBY_BUCKET_RESTRICTED , ваше приложение находится в ограниченном сегменте.

Проверьте поведение ограниченного сегмента

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

adb shell am set-standby-bucket PACKAGE_NAME restricted

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

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

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

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

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

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

Точный : обеспечивает доступ к точной информации о местоположении.
Приблизительно : обеспечивает доступ только к приблизительной информации о местоположении.

Переключатели микрофона и камеры

Поддерживаемые устройства под управлением Android 12 или более поздней версии позволяют пользователям включать и отключать доступ к камере и микрофону для всех приложений на устройстве, нажимая один переключатель. Пользователи могут получить доступ к переключаемым параметрам из быстрых настроек , как показано на рисунке 1, или с экрана «Конфиденциальность» в настройках системы.

Узнайте больше об этих переключателях и о том, как проверить, соответствует ли ваше приложение рекомендациям в отношении разрешений CAMERA и RECORD_AUDIO .

Индикаторы микрофона и камеры

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

Узнайте больше об этих индикаторах и о том, как проверить, соответствует ли ваше приложение рекомендациям в отношении разрешений CAMERA и RECORD_AUDIO .

Плитки быстрых настроек имеют надписи «Доступ к камере» и «Доступ к микрофону». — **Рисунок 2.** Переключение микрофона и камеры в быстрых настройках.

Скругленный прямоугольник в правом верхнем углу со значком камеры и значком микрофона. — **Рисунок 3.** Индикаторы микрофона и камеры, показывающие недавний доступ к данным.

Видимость пакета разрешений

На устройствах под управлением Android 12 или более поздней версии приложения, ориентированные на Android 11 (уровень API 30) или более поздней версии и вызывающие один из следующих методов, получают отфильтрованный набор результатов на основе видимости пакета приложения в других приложениях:

Реализация BouncyCastle удалена.

В Android 12 удалены многие реализации BouncyCastle ранее устаревших криптографических алгоритмов, включая все алгоритмы AES. Вместо этого система использует реализации этих алгоритмов Conscrypt .

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

В вашем приложении используются 512-битные ключи. Conscrypt не поддерживает этот размер ключа. При необходимости обновите логику шифрования вашего приложения, чтобы использовать ключи другого размера.
Ваше приложение использует недопустимые размеры ключей с помощью KeyGenerator . Реализация KeyGenerator в Conscrypt выполняет дополнительную проверку ключевых параметров по сравнению с BouncyCastle. Например, Conscrypt не позволяет вашему приложению генерировать 64-битный ключ AES, поскольку AES поддерживает только 128-, 192- и 256-битные ключи.
BouncyCastle позволяет генерировать ключи недопустимых размеров, но позже происходит сбой, если эти ключи используются с Cipher . Conscrypt терпит неудачу раньше.
Вы инициализируете шифры Галуа/Счетчика (GCM), используя размер, отличный от 12 байт. Реализация GcmParameterSpec в Conscrypt требует инициализации размером 12 байт, что рекомендует NIST.

Уведомления о доступе к буферу обмена

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

Текст внутри всплывающего сообщения имеет следующий формат: APP pasted from your clipboard.

Информация о тексте в описании клипа

В Android 12 и более поздних версиях getPrimaryClipDescription() может обнаружить следующие детали:

Стилизованный текст с использованием isStyledText() .
Различные классификации текста, например URL-адреса, с использованием getConfidenceScore() .

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

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

Если ваше приложение предназначено для Android 12 или более поздней версии, возникает SecurityException .
Если ваше приложение предназначено для Android 11 (уровень API 30) или ниже, намерение не выполняется, и в Logcat появляется следующее сообщение:
```
E ActivityTaskManager Permission Denial: \
android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
dropping broadcast.
```

Исключения

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

Ваше приложение выполняет инструментальный тест .
Ваше приложение предназначено для Android 11 или более ранней версии, и в нем отображается окно, расположенное над панелью уведомлений .
Примечание. Если ваше приложение предназначено для Android 12, вам не нужно использовать ACTION_CLOSE_SYSTEM_DIALOGS в этой ситуации. Это связано с тем, что если ваше приложение вызывает startActivity() , когда окно находится поверх панели уведомлений, система автоматически закрывает панель уведомлений.
Ваше приложение предназначено для Android 11 или более ранней версии. Кроме того, пользователь взаимодействовал с уведомлением, возможно, используя кнопки действий уведомления, а ваше приложение обрабатывает службу или приемник широковещательной рассылки в ответ на это действие пользователя.
Ваше приложение предназначено для Android 11 или более ранней версии и имеет активную службу специальных возможностей . Если ваше приложение предназначено для Android 12 и хочет закрыть панель уведомлений, используйте вместо этого действие специальных возможностей GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE .

Недоверенные события касания блокируются

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

Затронутые приложения

Это изменение влияет на приложения, которые разрешают касаниям проходить через свои окна, например, с помощью флага FLAG_NOT_TOUCHABLE . Несколько примеров включают, помимо прочего, следующее:

Наложения, для которых требуется разрешение SYSTEM_ALERT_WINDOW , например окна, использующие TYPE_APPLICATION_OVERLAY и использующие флаг FLAG_NOT_TOUCHABLE .
Окна активности, использующие флаг FLAG_NOT_TOUCHABLE .

Исключения

В следующих случаях допускаются «сквозные» касания:

Взаимодействия внутри вашего приложения. В вашем приложении отображается наложение, а оно появляется только тогда, когда пользователь взаимодействует с вашим приложением.
Доверенные окна. Эти окна включают (но не ограничиваются) следующее:
Примечание. Windows типа TYPE_APPLICATION_OVERLAY не являются доверенными.
Невидимые окна. Корневой вид окна GONE или INVISIBLE .
Полностью прозрачные окна. Свойство alpha для окна равно 0,0.
Достаточно полупрозрачные окна системных оповещений. Система считает набор окон системных предупреждений достаточно прозрачным, когда совокупная непрозрачность меньше или равна максимальной непрозрачности системы, закрывающей касания. В Android 12 максимальная непрозрачность по умолчанию равна 0,8.

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

Если сенсорное действие заблокировано системой, Logcat регистрирует следующее сообщение:

Untrusted touch due to occlusion by PACKAGE_NAME

Проверьте изменение

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

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

Чтобы вернуть поведение по умолчанию (недоверенные касания блокируются), выполните следующую команду:

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

Жизненный цикл активности

Действия Root Launcher больше не завершаются при нажатии «Назад»

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

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

Мы рекомендуем протестировать ваши приложения с учетом этого изменения. Если ваше приложение в настоящее время переопределяет onBackPressed() для обработки навигации Back и завершения Activity , обновите свою реализацию, чтобы она вызывала super.onBackPressed() вместо завершения. Вызов super.onBackPressed() перемещает действие и его задачу на задний план, когда это необходимо, и обеспечивает более последовательную навигацию для пользователей между приложениями.

Также обратите внимание, что в целом мы рекомендуем использовать API активности AndroidX для обеспечения пользовательской обратной навигации , а не переопределять onBackPressed() . API-интерфейсы действий AndroidX автоматически переходят к соответствующему поведению системы, если нет компонентов, перехватывающих работу системы. Нажмите Назад.

Графика и изображения

Улучшено переключение частоты обновления.

В Android 12 изменение частоты обновления с помощью setFrameRate() может происходить независимо от того, поддерживает ли дисплей плавный переход к новой частоте обновления; плавный переход — это переход без каких-либо визуальных прерываний, например черного экрана на секунду или две. Раньше, если дисплей не поддерживал плавный переход, он обычно продолжал использовать ту же частоту обновления после вызова setFrameRate() . Вы можете заранее определить, будет ли переход к новому обновлению плавным, вызвав getAlternativeRefreshRates() . Обычно обратный вызов onDisplayChanged() вызывается после завершения переключения частоты обновления, но для некоторых дисплеев с внешним подключением он вызывается во время плавного перехода.

Вот пример того, как вы можете это реализовать:

Котлин

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

Ява

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

Возможности подключения

Обновления пароля

В Android 12 добавлены следующие API:

isPasspointTermsAndConditionsSupported() : Условия — это функция Passpoint , которая позволяет сетевым развертываниям заменять небезопасные авторизованные порталы, использующие открытые сети, безопасной сетью Passpoint. Уведомление отображается пользователю, когда необходимо принять положения и условия. Приложения, предлагающие сети Passpoint, закрытые положениями и условиями, должны сначала вызвать этот API, чтобы убедиться, что устройство поддерживает эту возможность. Если устройство не поддерживает эту возможность, оно не сможет подключиться к этой сети, и необходимо предложить альтернативную или устаревшую сеть.
isDecoratedIdentitySupported() : при аутентификации в сетях с украшением префикса декорированный префикс идентификации позволяет сетевым операторам обновлять идентификатор доступа к сети (NAI) для выполнения явной маршрутизации через несколько прокси внутри сети AAA (подробнее об этом см. RFC 7542 ). .
В Android 12 эта функция реализована в соответствии со спецификацией WBA для расширений PPS-MO . Приложения, предлагающие сети Passpoint, требующие декорированного удостоверения, должны сначала вызвать этот API, чтобы убедиться, что устройство поддерживает эту возможность. Если устройство не поддерживает эту возможность, удостоверение не будет оформлено, и аутентификация в сети может завершиться неудачно.

Чтобы создать предложение Passpoint, приложения должны использовать классы PasspointConfiguration , Credential и HomeSp . Эти классы описывают профиль Passpoint, который определен в спецификации Wi-Fi Alliance Passpoint .

Дополнительные сведения см. в разделе API предложений Wi-Fi для подключения к Интернету .

Обновлены ограничения интерфейса, не связанные с 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» .

Дополнительные сведения см. в руководстве разработчика заставок .

Разрешение веб-намерений

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

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

Улучшения режима погружения для навигации с помощью жестов

Display#getRealSize и getRealMetrics: устаревание и ограничения

В Android 12 мы по-прежнему рекомендуем использовать WindowMetrics и объявляем устаревшими следующие методы:

Примеры использования WindowMetrics

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

Котлин

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

Ява

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

Котлин

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Ява

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

Все приложения в многооконном режиме

В Android 12 многооконный режим становится стандартным.

Дополнительную информацию см. в разделе Поддержка многооконного режима .

Предварительный просмотр камеры на больших экранах

Задержка UX для уведомлений служб переднего плана

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

Ограниченный сегмент ожидания приложений

Активно: приложение используется в данный момент или использовалось совсем недавно.
Рабочий набор: Приложение используется регулярно.
Часто: приложение используется часто, но не каждый день.
Редко: приложение используется нечасто.
Ограничено: приложение потребляет много системных ресурсов или может демонстрировать нежелательное поведение.

Проверьте, находится ли ваше приложение в сегменте с ограниченным доступом

Проверьте поведение ограниченного сегмента

adb shell am set-standby-bucket PACKAGE_NAME restricted

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

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

Диалог «Разрешения системы» включает в себя следующие параметры для пользователя, как показано на рисунке 1:

Точный : предоставляет доступ к точной информации о местоположении.
Приблизительно : предоставляет доступ только к приблизительной информации о местоположении.

Микрофон и камера переключаются

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

Узнайте больше об этих переключателях и о том, как проверить, что ваше приложение следует передовым практикам, касающиеся разрешений CAMERA и RECORD_AUDIO .

Индикаторы микрофона и камеры

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

Узнайте больше об этих показателях и о том, как проверить, что ваше приложение следует передовым практикам, касающимися разрешений CAMERA и RECORD_AUDIO .

Quick Settings Плитки помечены как «Доступ к камере» и «Доступ к микрофонам» — **Рисунок 2.** Микрофон и камера переключаются в быстрых настройках.

Округлый прямоугольник в правом верхнем углу, который включает значок камеры и значок микрофона — **Рисунок 3.** Индикаторы микрофона и камеры, которые показывают недавний доступ к данным.

Видимость пакета разрешений

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

Реализация Bouncycastle удалена

Android 12 удаляет многие реализации криптографических алгоритмов Bouncycastle , которые были ранее устарели, включая все алгоритмы AES. Вместо этого система использует реализации созрипта этих алгоритмов.

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

Ваше приложение использует 512-битные размеры ключей. Совместитель не поддерживает этот размер ключа. При необходимости обновите логику криптографии вашего приложения, чтобы использовать разные размеры ключей.
Ваше приложение использует неверные размеры ключей с KeyGenerator . Реализация Concrypt к KeyGenerator выполняет дополнительную проверку по ключевым параметрам, по сравнению с BouncyCastle. Например, созрипт не позволяет вашему приложению генерировать 64-битный ключ AES, потому что AES поддерживает только 128-, 192 и 256-битные ключи.
BouncyCastle позволяет генерировать ключи от недействительных размеров, но позже сбой, если эти клавиши используются с Cipher . Совеска терпит неудачу раньше.
Вы инициализируете свои шифры Galois/Counter Mode (GCM), используя размер, отличный от 12 байтов. Реализация созрипта GcmParameterSpec требует инициализации 12 байтов, что рекомендует NIST.

Уведомления об уведомлениях об буфере обмена

На Android 12 и выше, когда приложение вызовет getPrimaryClip() для доступа к данным клипам из другого приложения в первый раз, тост -сообщение уведомляет пользователя этого доступного буфера.

Текст в сообщении Toast содержит следующий формат: APP pasted from your clipboard.

Информация о тексте в описании клипа

На Android 12 и выше, getPrimaryClipDescription() может обнаружить следующие детали:

Стилизованный текст, используя isStyledText() .
Различные классификации текста, такие как URL -адреса, с использованием getConfidenceScore() .

Приложения не могут закрыть системные диалоги

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

Если ваше приложение предназначено для Android 12 или выше, происходит SecurityException .
Если ваше приложение предназначено для Android 11 (API -уровень 30) или ниже, намерение не выполняется, а в logCat появится следующее сообщение:
```
E ActivityTaskManager Permission Denial: \
android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
dropping broadcast.
```

Исключения

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

Ваше приложение выполняет тест на приборы .
Ваше приложение предназначено для Android 11 или ниже и показывает окно, которое находится на вершине ящика уведомлений .
Примечание. Если ваше приложение нацелен на Android 12, вам не нужно использовать ACTION_CLOSE_SYSTEM_DIALOGS в этой ситуации. Это потому, что, если ваше приложение вызывает startActivity() , в то время как окно находится поверх ящика уведомлений, система автоматически закрывает ящик уведомлений.
Ваше приложение предназначено для Android 11 или ниже. Кроме того, пользователь взаимодействовал с уведомлением, возможно, используя кнопки «Действие уведомления», и ваше приложение обрабатывает службу или вещательный приемник в ответ на это действие пользователя.
Ваше приложение предназначено для Android 11 или ниже и имеет активную службу доступности . Если ваше приложение предназначено для Android 12 и хочет закрыть строку уведомлений, вместо этого используйте действие GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE .

Недоверенные события прикосновения заблокированы

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

Затронутые приложения

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

Наложения, которые требуют разрешения SYSTEM_ALERT_WINDOW , например, Windows, которые используют TYPE_APPLICATION_OVERLAY , и используют флаг FLAG_NOT_TOUCHABLE .
Окна активности, которые используют флаг FLAG_NOT_TOUCHABLE .

Исключения

В следующих случаях допускаются штрихи «Переход»:

Взаимодействия в вашем приложении. Ваше приложение показывает наложение, и наложение появляется только тогда, когда пользователь взаимодействует с вашим приложением.
Доверенные окна. Эти окна включают (но не ограничены) следующие:
Примечание. Windows of TYPE_APPLICATION_OVERLAY не доверяют.
Невидимые окна. Корневый вид окна GONE или INVISIBLE .
Полностью прозрачные окна. Свойство alpha составляет 0,0 для окна.
Достаточно полупрозрачная система предупреждает окна. Система считает, что набор системных оповещений является достаточно прозрачным, когда комбинированная непрозрачность меньше или равна максимальной неясной непрозрачности системы для прикосновений. В Android 12 эта максимальная непрозрачность по умолчанию составляет 0,8.

Обнаружение, когда блокируется ненадлежащее прикосновение

Если система блокируется системой, logcat регистрирует следующее сообщение:

Untrusted touch due to occlusion by PACKAGE_NAME

Проверьте изменение

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

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

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

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

Жизненный цикл активности

Руночные действия запуска больше не закончены на заднем прессе

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

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

Мы рекомендуем проверить ваши приложения с этим изменением. Если ваше приложение в настоящее время переопределяет onBackPressed() для обработки навигации и завершить Activity , обновите свою реализацию, чтобы вызовать super.onBackPressed() вместо завершения. Вызов super.onBackPressed() перемещает деятельность и ее задачу на фону, когда это необходимо, и обеспечивает более последовательный опыт навигации для пользователей в разных приложениях.

Также обратите внимание, что, в целом, мы рекомендуем использовать API Androidx Activity для предоставления пользовательской обратной навигации , а не переопределять onBackPressed() . API APIS Activity Activity автоматически возвращается к соответствующему поведению системы, если нет компонентов, перехватывающих системную обратную связь.

Графика и изображения

Улучшение переключения скорости обновления

В Android 12 изменения скорости обновления с использованием setFrameRate() могут произойти независимо от того, поддерживает ли дисплей бесшовный переход к новой частоте обновления; Беспланный переход - это тот, который не имеет никаких визуальных перерывов, таких как черный экран на секунду или два. Ранее, если дисплей не поддерживал плавный переход, он обычно продолжит использовать ту же скорость обновления после вызова setFrameRate() . Вы можете заранее определить, будет ли переход к новому обновлению, вероятно, будет беспроблемным, позвонив в getAlternativeRefreshRates() . Как правило, обратный вызов onDisplayChanged() вызывается после завершения переключателя скорости обновления, но для некоторых внешних дисплеев он вызывается во время беззамотного перехода.

Вот пример того, как вы можете реализовать это:

Котлин

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

Ява

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

Возможности подключения

Обновления Passpoint

Следующие API добавляются в Android 12:

isPasspointTermsAndConditionsSupported() : Условия и условия - это функция Passpoint , которая позволяет развертываниям сети заменить небезопасные порталы для капитала, которые используют открытые сети, с безопасной сетью Passpoint. Уведомление отображается пользователю, когда должны быть приняты условия и условия. Приложения, которые предлагают сетям Passpoint, которые управляются положениями и условиями, должны сначала назвать этот API, чтобы убедиться, что устройство поддерживает эту возможность. Если устройство не поддерживает возможность, оно не сможет подключиться к этой сети, и должна быть предложена альтернативная или устаревшая сеть.
isDecoratedIdentitySupported() : при аутентификации в сетях с украшением префикса префикс украшенной идентификации позволяет операторам сети обновлять идентификатор доступа к сети (NAI) для проведения явной маршрутизации через несколько прокси внутри сети AAA (см. RFC 7542 для этого) для этого) для большего) для этого) для большей .
Android 12 реализует эту функцию в соответствии со спецификацией WBA для расширений PPS-MO . Приложения, которые предлагают сетям Passpoint, которые требуют украшенной идентификации, должны сначала назвать этот API, чтобы убедиться, что устройство поддерживает эту возможность. Если устройство не поддерживает возможность, идентичность не будет украшена, а аутентификация в сети может потерпеть неудачу.

Чтобы создать предложение Passpoint, приложения должны использовать PasspointConfiguration , Credential и классы HomeSp . Эти классы описывают профиль Passpoint, который определяется в спецификации Passpoint Wi-Fi Alliance .

Для получения дополнительной информации см. API API предложения Wi-Fi для подключения к Интернету .

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

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

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

Эффект перегородки

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

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

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

Приложение Splash Screens

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

Для инструкций см. Мигрируйте существующую реализацию Splash Screen в Android 12 .

Кроме того, начиная с Android 12, система всегда применяет новый экран Splash System Android по умолчанию на холодных и теплых запусках для всех приложений. По умолчанию этот экран Splash System по умолчанию построен с использованием элемента значка вашего приложения и значка запуска и windowBackground вашей темы (если это единственный цвет).

Для получения более подробной информации см. Руководство разработчика Splash Screens .

Резолюция веб -намерений

Начиная с Android 12 (уровень API 31), общее веб -намерение решается для деятельности в вашем приложении, только если ваше приложение одобрено для конкретного домена, содержащегося в этом веб -намерении. Если ваше приложение не одобрено для домена, вместо этого решается в Интернете приложение для браузера пользователя.

Приложения могут получить это одобрение, выполнив одно из следующих:

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

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

Улучшения для иммерсивного режима для навигации по жестам

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

Дисплей#GetRealSize и GetRealMetrics: Университет и ограничения

Устройства Android доступны во многих различных форм -факторах, таких как большие экраны, планшеты и складки. Чтобы правильно отображать контент для каждого устройства, ваше приложение необходимо для определения экрана или размера отображения. Со временем Android предоставил различные API для получения этой информации. В Android 11 мы представили API WindowMetrics и установили эти методы:

В Android 12 мы продолжаем рекомендовать использование WindowMetrics и выпускаем эти методы:

Чтобы смягчить поведение приложений, используя API -интерфейсы Display для извлечения границ приложения, Android 12 ограничивает значения, возвращаемые API для приложений, которые не полностью пересекаются. Это может повлиять на приложения, которые используют эту информацию с помощью MediaProjection .

Приложения должны использовать API WindowMetrics для запроса границ их окна и Configuration.densityDpi для запроса плотности тока.

Для более широкой совместимости с более старыми версиями Android вы можете использовать библиотеку JetPack WindowManager , которая включает в себя класс WindowMetrics , который поддерживает Android 4.0 (API -уровень 14) и выше.

Примеры того, как использовать Windowmetrics

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

Занятие должно полагаться на WindowMetrics из контекста деятельности для любой работы, связанной с пользовательским интерфейсом, в частности WindowManager.getCurrentWindowMetrics() или WindowMetricsCalculator.computeCurrentWindowMetrics() .

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

Если приложение полностью пересекается, контекст активности возвращает правильные границы, как SO:

Котлин

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

Ява

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

Если приложение не полностью пересекается, оно должно запросить из экземпляра WindowContext и получить WindowMetrics границ активности с использованием WindowManager.getMaximumWindowMetrics() или метода jetpack WindowMetricsCalculator.computeMaximumWindowMetrics() .

Котлин

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Ява

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

Все приложения в режиме с несколькими окнами

Android 12 производит стандартное поведение в режиме мульти-окна.

На больших экранах (SW> = 600DP) платформа поддерживает все приложения в режиме мульти-окна независимо от конфигурации приложения. Если resizeableActivity="false" , приложение помещается в режим совместимости при необходимости для размещения размеров отображения.

На небольших экранах (SW <600DP) система проверяет minWidth и minHeight деятельности, чтобы определить, может ли деятельность выполняться в режиме с несколькими окнами. Если resizeableActivity="false" , приложение не может работать в режиме мульти -ветра независимо от минимальной ширины и высоты.

Для получения дополнительной информации см. Вспомогательную поддержку .

Предварительный просмотр камеры на больших экранах

Приложения камеры обычно предполагают фиксированную связь между ориентацией устройства и соотношением сторон предварительного просмотра камеры. Но крупные форм-факторы экрана, такие как складные устройства, и режимы отображения, такие как мульти-Window и Multi-Display, бросают вызов этому предположению.

На Android 12 приложения камеры, которые запрашивают конкретную ориентацию экрана и не имеют использования ( resizeableActivity="false" ) автоматически вводятся вставленным портретным режимом, который обеспечивает правильную ориентацию и соотношение сторон предварительного просмотра камеры. На складках и других устройствах, которые имеют слой абстракции аппаратного обеспечения камеры ( HAL ), к выходу камеры применяется дополнительное вращение, чтобы компенсировать ориентацию датчика камеры, а вывод камеры обрезан в соответствии с соотношением сторон предварительного просмотра камеры приложения. Разрез и дополнительное вращение обеспечивают правильное представление предварительного просмотра камеры независимо от ориентации устройства и сложенного или развернутого состояния устройства.

UX задержка для уведомлений об обслуживании переднего плана

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

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

Ограниченное приложение в режиме ожидания

Android 11 (API -уровень 30) представил ограниченное ведро в качестве ведра приложения. Начиная с Android 12, это ведро активно по умолчанию. Ограниченное ведро имеет самый низкий приоритет (и самые высокие ограничения) всех ведер. Ведра в порядке приоритета от высокого до минимума:

Active: APP в настоящее время используется или совсем недавно использовалось.
Рабочий набор: приложение регулярно используется.
Часто: приложение часто используется, но не каждый день.
Редко: приложение не часто используется.
Ограниченное: приложение потребляет много системных ресурсов или может проявлять нежелательное поведение.

Система рассматривает поведение вашего приложения, в дополнение к моделям использования, решить, размещать ли ваше приложение в ограниченное ведро.

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

Проверьте, находится ли ваше приложение в ограниченном ведре

Чтобы проверить, поместила ли система вашего приложения в ограниченное ведро, вызовите getAppStandbyBucket() . Если возвращаемое значение этого метода является STANDBY_BUCKET_RESTRICTED , то ваше приложение находится в ограниченном ведре.

Проверьте ограниченное поведение ведра

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

adb shell am set-standby-bucket PACKAGE_NAME restricted

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

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

Диалог имеет два набора параметров, один выше другого — **Рисунок 1.** Диалоговое окно системного разрешения, которое позволяет пользователю предоставлять приблизительную информацию о местоположении.

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

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

Диалог «Разрешения системы» включает в себя следующие параметры для пользователя, как показано на рисунке 1:

Точный : предоставляет доступ к точной информации о местоположении.
Приблизительно : предоставляет доступ только к приблизительной информации о местоположении.

Микрофон и камера переключаются

Индикаторы микрофона и камеры

Видимость пакета разрешений

Реализация Bouncycastle удалена

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

Ваше приложение использует 512-битные размеры ключей. Совместитель не поддерживает этот размер ключа. При необходимости обновите логику криптографии вашего приложения, чтобы использовать разные размеры ключей.
Ваше приложение использует неверные размеры ключей с KeyGenerator . Реализация Concrypt к KeyGenerator выполняет дополнительную проверку по ключевым параметрам, по сравнению с BouncyCastle. Например, созрипт не позволяет вашему приложению генерировать 64-битный ключ AES, потому что AES поддерживает только 128-, 192 и 256-битные ключи.
BouncyCastle позволяет генерировать ключи от недействительных размеров, но позже сбой, если эти клавиши используются с Cipher . Совеска терпит неудачу раньше.
Вы инициализируете свои шифры Galois/Counter Mode (GCM), используя размер, отличный от 12 байтов. Реализация созрипта GcmParameterSpec требует инициализации 12 байтов, что рекомендует NIST.

Уведомления об уведомлениях об буфере обмена

Текст в сообщении Toast содержит следующий формат: APP pasted from your clipboard.

Информация о тексте в описании клипа

На Android 12 и выше, getPrimaryClipDescription() может обнаружить следующие детали:

Стилизованный текст, используя isStyledText() .
Различные классификации текста, такие как URL -адреса, с использованием getConfidenceScore() .

Приложения не могут закрыть системные диалоги

Если ваше приложение предназначено для Android 12 или выше, происходит SecurityException .
Если ваше приложение предназначено для Android 11 (API -уровень 30) или ниже, намерение не выполняется, а в logCat появится следующее сообщение:
```
E ActivityTaskManager Permission Denial: \
android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
dropping broadcast.
```

Исключения

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

Ваше приложение выполняет тест на приборы .
Ваше приложение предназначено для Android 11 или ниже и показывает окно, которое находится на вершине ящика уведомлений .
Примечание. Если ваше приложение нацелен на Android 12, вам не нужно использовать ACTION_CLOSE_SYSTEM_DIALOGS в этой ситуации. Это потому, что, если ваше приложение вызывает startActivity() , в то время как окно находится поверх ящика уведомлений, система автоматически закрывает ящик уведомлений.
Ваше приложение предназначено для Android 11 или ниже. Кроме того, пользователь взаимодействовал с уведомлением, возможно, используя кнопки «Действие уведомления», и ваше приложение обрабатывает службу или вещательный приемник в ответ на это действие пользователя.
Ваше приложение предназначено для Android 11 или ниже и имеет активную службу доступности . Если ваше приложение предназначено для Android 12 и хочет закрыть строку уведомлений, вместо этого используйте действие GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE .

Недоверенные события прикосновения заблокированы

Затронутые приложения

Наложения, которые требуют разрешения SYSTEM_ALERT_WINDOW , например, Windows, которые используют TYPE_APPLICATION_OVERLAY , и используют флаг FLAG_NOT_TOUCHABLE .
Окна активности, которые используют флаг FLAG_NOT_TOUCHABLE .

Исключения

В следующих случаях допускаются штрихи «Переход»:

Взаимодействия в вашем приложении. Ваше приложение показывает наложение, и наложение появляется только тогда, когда пользователь взаимодействует с вашим приложением.
Доверенные окна. Эти окна включают (но не ограничены) следующие:
Примечание. Windows of TYPE_APPLICATION_OVERLAY не доверяют.
Невидимые окна. Корневый вид окна GONE или INVISIBLE .
Полностью прозрачные окна. Свойство alpha составляет 0,0 для окна.
Достаточно полупрозрачная система предупреждает окна. Система считает, что набор системных оповещений является достаточно прозрачным, когда комбинированная непрозрачность меньше или равна максимальной неясной непрозрачности системы для прикосновений. В Android 12 эта максимальная непрозрачность по умолчанию составляет 0,8.

Обнаружение, когда блокируется ненадлежащее прикосновение

Если система блокируется системой, logcat регистрирует следующее сообщение:

Untrusted touch due to occlusion by PACKAGE_NAME

Проверьте изменение

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

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

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

Жизненный цикл активности

Руночные действия запуска больше не закончены на заднем прессе

Графика и изображения

Улучшение переключения скорости обновления

В Android 12 изменения скорости обновления с использованием setFrameRate() могут произойти независимо от того, поддерживает ли дисплей бесшовный переход к новой частоте обновления; Беспланный переход - это тот, который не имеет никаких визуальных перерывов, таких как черный экран на секунду или два. Ранее, если дисплей не поддерживал плавный переход, он обычно продолжит использовать ту же скорость обновления после вызова setFrameRate() . Вы можете заранее определить, будет ли переход к новому обновлению, вероятно, будет беспроблемным, позвонив в getAlternativeRefreshRates() . Generally, the callback onDisplayChanged() is called after the refresh rate switch completes, but for some externally-connected displays, it is called during a non-seamless transition.

Here's an example of how you might implement this:

Kotlin

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

Ява

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

Возможности подключения

Passpoint updates

The following APIs are added in Android 12:

isPasspointTermsAndConditionsSupported() : Terms and conditions is a Passpoint feature that allows network deployments to replace insecure captive portals, which use open networks, with a secure Passpoint network. A notification is displayed to the user when terms and conditions are required to be accepted. Apps that suggest Passpoint networks that are gated by terms and conditions must call this API first to make sure that the device supports the capability. If the device does not support the capability, it won't be able to connect to this network, and an alternative or legacy network must be suggested.
isDecoratedIdentitySupported() : When authenticating to networks with a prefix decoration, the decorated identity prefix allows network operators to update the Network Access Identifier (NAI) to perform explicit routing through multiple proxies inside of an AAA network (see RFC 7542 for more on this) .
Android 12 implements this feature to conform with the WBA specification for PPS-MO extensions . Apps that suggest Passpoint networks that require a decorated identity must call this API first to make sure that the device supports the capability. If the device does not support the capability, the identity won't be decorated and the authentication to the network might fail.

To create a Passpoint suggestion, apps must use the PasspointConfiguration , Credential , and HomeSp classes. These classes describe the Passpoint profile, which is defined in the Wi-Fi Alliance Passpoint specification .

For more information, see Wi-Fi suggestion API for internet connectivity .

Updated non-SDK interface restrictions

Android 12 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 12, some of these changes might not immediately affect you. However, while you can currently use some non-SDK interfaces ( depending on your app's target API level ), using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. 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 .

The Android 12 platform includes behavior changes that may affect your app. The following behavior changes apply to all apps when they run on Android 12, regardless of targetSdkVersion . You should test your app and then modify it as needed to support these properly, where applicable.

Make sure to also review the list of behavior changes that only affect apps targeting Android 12 .

User experience

Stretch overscroll effect

On devices running Android 12 and higher, the visual behavior for overscroll events changes.

On Android 11 and lower, an overscroll event causes the visual elements to have a glow; on Android 12 and higher, the visual elements stretch and bounce back on a drag event and they fling and bounce back on a fling event.

For more information, see the guide to animating scroll gestures .

App splash screens

If you have previously implemented a custom splash screen in Android 11 or lower, you'll need to migrate your app to the SplashScreen API to ensure that it displays correctly starting in Android 12. Not migrating your app will result in a degraded or unintended app launch experience.

For instructions, see Migrate your existing splash screen implementation to Android 12 .

Additionally, starting in Android 12, the system always applies the new Android system default splash screen on cold and warm starts for all apps. By default, this system default splash screen is constructed using your app's launcher icon element and the windowBackground of your theme (if it's a single color).

For more details, see the splash screens developer guide .

Web intent resolution

Starting in Android 12 (API level 31), a generic web intent resolves to an activity in your app only if your app is approved for the specific domain contained in that web intent. If your app isn't approved for the domain, the web intent resolves to the user's default browser app instead.

Apps can get this approval by doing one of the following:

Verify the domain using Android App Links .
On apps that target Android 12 or higher, the system changes how it automatically verifies your app's Android App Links. In your app's intent filters , check that you include the BROWSABLE category and support the https scheme.
On Android 12 or higher, you can manually verify your app's Android App Links, to test how this updated logic affects your app.
Request the user to associate your app with the domain in system settings.

If your app invokes web intents, consider adding a prompt or dialog that asks the user to confirm the action.

Immersive mode improvements for gesture navigation

Android 12 consolidates existing behavior to make it easier for users to perform gesture navigation commands while in immersive mode . In addition, Android 12 provides backward compatibility behavior for sticky immersive mode .

Display#getRealSize and getRealMetrics: deprecation and constraints

Android devices are available in many different form factors, such as large screens, tablets, and foldables. To render content appropriately for each device, your app needs to determine the screen or display size. Over time, Android has provided different APIs for retrieving this information. In Android 11, we introduced the WindowMetrics API and deprecated these methods:

In Android 12 we're continuing to recommend using WindowMetrics , and are deprecating these methods:

To mitigate the behavior of applications using Display APIs to retrieve the application's bounds, Android 12 constrains the values returned by the APIs for apps that are not fully resizable. This could have an impact on apps that are using this information with MediaProjection .

Apps should use the WindowMetrics APIs to query the bounds of their window, and Configuration.densityDpi to query the current density.

For broader compatibility with older versions of Android, you can use the Jetpack WindowManager library, which includes a WindowMetrics class that supports Android 4.0 (API level 14) and higher.

Examples of how to use WindowMetrics

First, be sure your app's activities are fully resizable .

An activity should rely upon WindowMetrics from an activity context for any UI-related work, particularly WindowManager.getCurrentWindowMetrics() or Jetpack's WindowMetricsCalculator.computeCurrentWindowMetrics() .

If your app creates a MediaProjection , the bounds must be correctly sized since the projection captures the display partition in which the projector app is running.

If the app is fully resizable, the activity context returns the correct bounds like so:

Kotlin

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

Ява

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

If the app is not fully resizable, it must query from a WindowContext instance and retrieve the WindowMetrics of the activity bounds using WindowManager.getMaximumWindowMetrics() or the Jetpack method WindowMetricsCalculator.computeMaximumWindowMetrics() .

Kotlin

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Ява

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

All apps in multi-window mode

Android 12 makes multi-window mode standard behavior.

On large screens (sw >= 600dp), the platform supports all apps in multi-window mode regardless of app configuration. If resizeableActivity="false" , the app is put into compatibility mode when necessary to accommodate display dimensions.

On small screens (sw < 600dp), the system checks an activity's minWidth and minHeight to determine whether the activity can run in multi-window mode. If resizeableActivity="false" , the app is prevented from running in multi‑window mode regardless of minimum width and height.

For more information, see Multi-window support .

Camera preview on large screens

Camera apps generally assume a fixed relationship between the orientation of the device and the aspect ratio of the camera preview. But large screen form factors, such as foldable devices, and display modes such as multi-window and multi-display, challenge that assumption.

On Android 12, camera apps that request a specific screen orientation and are not resizable ( resizeableActivity="false" ) automatically enter inset portrait mode, which ensures the proper orientation and aspect ratio of the camera preview. On foldables and other devices that have a camera hardware abstraction layer ( HAL ), additional rotation is applied to the camera output to compensate for camera sensor orientation, and the camera output is cropped to match the aspect ratio of the app's camera preview. The cropping and extra rotation ensure proper presentation of the camera preview regardless of device orientation and folded or unfolded state of the device.

UX delay for foreground service notifications

To provide a streamlined experience for short-running foreground services , devices that run Android 12 or higher can delay the display of foreground service notifications by 10 seconds, with a few exceptions . This change gives short-lived tasks a chance to complete before their notifications appear.

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

Restricted App Standby Bucket

Android 11 (API level 30) introduced the restricted bucket as an App Standby Bucket. Starting in Android 12, this bucket is active by default. The restricted bucket has the lowest priority (and the highest restrictions) of all the buckets. The buckets in order of priority from high to low are:

Active: App is currently being used or was very recently used.
Working set: App is in regular use.
Frequent: App is often used, but not every day.
Rare: App is not frequently used.
Restricted: App consumes a great deal of system resources, or may exhibit undesirable behavior.

The system considers your app's behavior, in addition to usage patterns, to decide whether to place your app in the restricted bucket.

Your app is less likely to be placed in the restricted bucket if your app uses system resources more responsibly. Also, the system places your app in a less restrictive bucket if the user interacts directly with your app.

Check whether your app is in the restricted bucket

To check whether the system has placed your app in the restricted bucket, call getAppStandbyBucket() . If the return value of this method is STANDBY_BUCKET_RESTRICTED , then your app is in the restricted bucket.

Test the restricted bucket behavior

To test how your app behaves when the system places your app into the restricted bucket, you can manually move your app to that bucket. To do so, run the following command in a terminal window:

adb shell am set-standby-bucket PACKAGE_NAME restricted

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

Approximate location

The dialog has two sets of options, one above the
other — **Figure 1.** System permissions dialog that allows the user to grant approximate location information.

On devices that run Android 12 or higher, users can request that your app have access to only approximate location information.

If your app requests the ACCESS_FINE_LOCATION runtime permission, you should also request the ACCESS_COARSE_LOCATION permission to handle the case where the user grants approximate location access to your app. You should include both permissions in a single runtime request .

The system permissions dialog includes the following options for the user, as shown in figure 1:

Precise : Provides access to precise location information.
Approximate : Provides access only to approximate location information.

Microphone and camera toggles

Supported devices that run Android 12 or higher allow users to enable and disable camera and microphone access for all apps on the device, by pressing a single toggle option. Users can access the toggleable options from Quick Settings , as shown in figure 1, or from the Privacy screen in system settings.

Learn more about these toggles , and how to check that your app follows best practices regarding the CAMERA and RECORD_AUDIO permissions.

Microphone and camera indicators

On devices that run Android 12 or higher, when an app accesses the microphone or camera, an icon appears in the status bar.

Learn more about these indicators and how to check that your app follows best practices regarding the CAMERA and RECORD_AUDIO permissions.

Quick settings tiles are labeled 'Camera access' and
'Mic access' — **Figure 2.** Microphone and camera toggles in Quick Settings.

A rounded rectangle in the upper-right corner, which
includes a camera icon and a microphone icon — **Figure 3.** Microphone and camera indicators, which show recent data access.

Permission package visibility

On devices that run Android 12 or higher, apps that target Android 11 (API level 30) or higher and that call one of following methods receive a filtered set of results, based on the app's package visibility into other apps:

BouncyCastle implementation removed

Android 12 removes many BouncyCastle implementations of cryptographic algorithms that were previously deprecated, including all AES algorithms. The system instead uses the Conscrypt implementations of these algorithms.

This change affects your app if any of the following are true:

Your app uses 512-bit key sizes. Conscrypt doesn't support this key size. If necessary, update your app's cryptography logic to use different key sizes.
Your app uses invalid key sizes with KeyGenerator . Conscrypt's implementation of KeyGenerator performs additional validation on key parameters, compared to BouncyCastle. For example, Conscrypt doesn't allow your app to generate a 64-bit AES key because AES only supports 128-, 192-, and 256-bit keys.
BouncyCastle allows keys of invalid sizes to be generated, but later fails if these keys are used with a Cipher . Conscrypt fails earlier.
You initialize your Galois/Counter Mode (GCM) ciphers using a size other than 12 bytes. Conscrypt's implementation of GcmParameterSpec requires an initialization of 12 bytes, which NIST recommends.

Clipboard access notifications

On Android 12 and higher, when an app calls getPrimaryClip() to access clip data from a different app for the first time, a toast message notifies the user of this clipboard access.

The text inside the toast message contains the following format: APP pasted from your clipboard.

Information about text in clip description

On Android 12 and higher, getPrimaryClipDescription() can detect the following details:

Stylized text, using isStyledText() .
Different classifications of text, such as URLs, using getConfidenceScore() .

Apps can't close system dialogs

To improve user control when interacting with apps and the system, the ACTION_CLOSE_SYSTEM_DIALOGS intent action is deprecated as of Android 12. Except for a few special cases , when your app tries to invoke an intent that contains this action, the system does one of the following based on your app's target SDK version:

If your app targets Android 12 or higher, a SecurityException occurs.

If your app targets Android 11 (API level 30) or lower, the intent doesn't execute, and the following message appears in Logcat :

E ActivityTaskManager Permission Denial: \
android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
dropping broadcast.

Исключения

In the following cases, an app can still close system dialogs on Android 12 or higher:

Your app is running an instrumentation test .
Your app targets Android 11 or lower and is showing a window that is on top of the notification drawer .
Note: If your app targets Android 12, you don't need to use ACTION_CLOSE_SYSTEM_DIALOGS in this situation. That's because, if your app calls startActivity() while a window is on top of the notification drawer, the system closes the notification drawer automatically.
Your app targets Android 11 or lower. In addition, the user has interacted with a notification, possibly using the notification's action buttons , and your app is processing a service or broadcast receiver in response to that user action.
Your app targets Android 11 or lower and has an active accessibility service . If your app targets Android 12 and wants to close the notification bar, use the GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE accessibility action instead.

Untrusted touch events are blocked

To preserve system security and a good user experience, Android 12 prevents apps from consuming touch events where an overlay obscures the app in an unsafe way. In other words, the system blocks touches that pass through certain windows, with a few exceptions .

Affected apps

This change affects apps that choose to let touches pass through their windows, for example by using the FLAG_NOT_TOUCHABLE flag. Several examples include, but aren't limited to, the following:

Overlays that require the SYSTEM_ALERT_WINDOW permission, such as windows that use TYPE_APPLICATION_OVERLAY , and use the FLAG_NOT_TOUCHABLE flag.
Activity windows that use the FLAG_NOT_TOUCHABLE flag.

Исключения

In the following cases, "pass-through" touches are allowed:

Interactions within your app. Your app shows the overlay, and the overlay appears only when the user is interacting with your app.
Trusted windows. These windows include (but aren't limited to) the following:
Note: Windows of type TYPE_APPLICATION_OVERLAY aren't trusted.
Invisible windows. The window's root view is GONE or INVISIBLE .
Completely transparent windows. The alpha property is 0.0 for the window.
Sufficiently translucent system alert windows. The system considers a set of system alert windows to be sufficiently translucent when the combined opacity is less than or equal to the system's maximum obscuring opacity for touches. In Android 12, this maximum opacity is 0.8 by default.

Detect when an untrusted touch is blocked

If a touch action is blocked by the system, Logcat logs the following message:

Untrusted touch due to occlusion by PACKAGE_NAME

Test the change

Untrusted touches are blocked by default on devices that run Android 12 or higher. To allow untrusted touches, run the following ADB command in a terminal window:

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

To revert the behavior to the default (untrusted touches are blocked), run the following command:

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

Activity lifecycle

Root launcher activities are no longer finished on Back press

Android 12 changes the default handling of the system Back press on launcher activities that are at the root of their tasks. In previous versions, the system would finish these activities on Back press. In Android 12, the system now moves the activity and its task to the background instead of finishing the activity. The new behavior matches the current behavior when navigating out of an app using the Home button or gesture.

For most apps, this change means that users who use Back to navigate out of your app are able to more quickly resume your app from a warm state , instead of having to completely restart the app from a cold state .

We recommend testing your apps with this change. If your app currently overrides onBackPressed() to handle Back navigation and finish the Activity , update your implementation to call through to super.onBackPressed() instead of finishing. Calling super.onBackPressed() moves the activity and its task to the background when appropriate and provides a more consistent navigation experience for users across apps.

Also note that, in general, we recommend using the AndroidX Activity APIs for providing custom back navigation , rather than overriding onBackPressed() . The AndroidX Activity APIs automatically defer to the appropriate system behavior if there are no components intercepting the system Back press.

Graphics and images

Improved refresh rate switching

In Android 12, refresh rate changes using setFrameRate() can happen regardless of whether the display supports a seamless transition to the new refresh rate; a seamless transition is one that doesn't have any visual interruptions, such as a black screen for a second or two. Previously, if the display did not support a seamless transition, it would typically continue using the same refresh rate after setFrameRate() is called. You can determine in advance whether the transition to the new refresh will likely be seamless by calling getAlternativeRefreshRates() . Generally, the callback onDisplayChanged() is called after the refresh rate switch completes, but for some externally-connected displays, it is called during a non-seamless transition.

Here's an example of how you might implement this:

Kotlin

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

Ява

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

Возможности подключения

Passpoint updates

The following APIs are added in Android 12:

isPasspointTermsAndConditionsSupported() : Terms and conditions is a Passpoint feature that allows network deployments to replace insecure captive portals, which use open networks, with a secure Passpoint network. A notification is displayed to the user when terms and conditions are required to be accepted. Apps that suggest Passpoint networks that are gated by terms and conditions must call this API first to make sure that the device supports the capability. If the device does not support the capability, it won't be able to connect to this network, and an alternative or legacy network must be suggested.
isDecoratedIdentitySupported() : When authenticating to networks with a prefix decoration, the decorated identity prefix allows network operators to update the Network Access Identifier (NAI) to perform explicit routing through multiple proxies inside of an AAA network (see RFC 7542 for more on this) .
Android 12 implements this feature to conform with the WBA specification for PPS-MO extensions . Apps that suggest Passpoint networks that require a decorated identity must call this API first to make sure that the device supports the capability. If the device does not support the capability, the identity won't be decorated and the authentication to the network might fail.

For more information, see Wi-Fi suggestion API for internet connectivity .