Андроид 14
8 апреля 2024 г.
2. Типы устройств
2.2.1. Аппаратное обеспечение :
См. редакцию
Начать новые требования
Если реализации карманных устройств объявляют
FEATURE_BLUETOOTH_LE
, они:- [ 7.4 .3/H-1-3] ДОЛЖЕН измерять и компенсировать смещение Rx, чтобы гарантировать, что медианный RSSI BLE составляет -50 дБм +/- 15 дБ на расстоянии 1 м от эталонного устройства, передающего на
ADVERTISE_TX_POWER_HIGH
. - [ 7.4 .3/H-1-4] ДОЛЖЕН измерять и компенсировать смещение Tx, чтобы гарантировать, что медианный RSSI BLE составляет -50 дБм +/- 15 дБ при сканировании с эталонного устройства, расположенного на расстоянии 1 м и передачи со скоростью
ADVERTISE_TX_POWER_HIGH
.
- [ 7.4 .3/H-1-3] ДОЛЖЕН измерять и компенсировать смещение Rx, чтобы гарантировать, что медианный RSSI BLE составляет -50 дБм +/- 15 дБ на расстоянии 1 м от эталонного устройства, передающего на
См. редакцию
Если реализации портативных устройств поддерживают системный API
HotwordDetectionService
или другой механизм обнаружения горячих слов без указания доступа к микрофону, они:- [9.8/H-1-6] НЕ ДОЛЖНО допускать передачу более 100 байтов данных из службы обнаружения горячих слов при каждом успешном результате использования горячих слов , за исключением аудиоданных, передаваемых через HotwordAudioStream .
См. редакцию
Измените [9.8/H-1-13] на:
- [9.8/H-SR-3] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ перезапускать процесс, на котором размещена служба обнаружения горячих слов, по крайней мере, один раз в час или каждые 30 событий, запускающих оборудование, в зависимости от того, что наступит раньше.
См. редакцию
Удалены требования [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].
См. редакцию
Если реализации карманных устройств возвращают
android.os.Build.VERSION_CODES.U
дляandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, то они:- [ 7.5 /H-1-3] ДОЛЖНО поддерживать свойство
android.info.supportedHardwareLevel
со значениемFULL
или выше для задней основной камеры иLIMITED
или выше для передней основной камеры.
- [ 7.5 /H-1-3] ДОЛЖНО поддерживать свойство
См. редакцию
Если реализации телевизионных устройств не имеют встроенного дисплея, а поддерживают внешний дисплей, подключенный через HDMI, они:
- [ 5.8 /T-0-1] НЕОБХОДИМО установить для режима вывода HDMI самое высокое разрешение для выбранного формата пикселей, которое работает с частотой обновления 50 Гц или 60 Гц для внешнего дисплея, в зависимости от частоты обновления видео для региона, в котором продается устройство. дюйм.
НЕОБХОДИМО установить режим вывода HDMI, чтобы выбрать максимальное разрешение, которое может поддерживаться с частотой обновления 50 Гц или 60 Гц.
- [ 5.8 /T-0-1] НЕОБХОДИМО установить для режима вывода HDMI самое высокое разрешение для выбранного формата пикселей, которое работает с частотой обновления 50 Гц или 60 Гц для внешнего дисплея, в зависимости от частоты обновления видео для региона, в котором продается устройство. дюйм.
3. Программное обеспечение
3.5.1. Ограничение применения :
См. редакцию
- Удалено требование [C-1-9]
5. Мультимедийная совместимость
См. редакцию
Если реализации устройств декларируют поддержку декодера Dolby Vision через
HDR_TYPE_DOLBY_VISION
, они:- [C-1-3] ДОЛЖЕН установить идентификатор дорожки обратно совместимых базовых слоев (если они присутствуют) таким же, как идентификатор дорожки объединенного слоя Dolby Vision.
7. Совместимость оборудования
7.1.1.1. Размер и форма экрана :
См. редакцию
Если реализации устройств поддерживают экраны с конфигурацией размера
UI_MODE_TYPE_NORMAL
и используют физические дисплеи со скругленными углами для визуализации этих экранов, они:- [C-1-1] ДОЛЖЕН обеспечить выполнение хотя бы одного из следующих требований для каждого такого дисплея:
- Когда блок размером
15и 18 пикселей на1518 пикселей закреплен в каждом углу логического дисплея, на экране виден по крайней мере один пиксель каждого блока.
- Когда блок размером
- [C-1-1] ДОЛЖЕН обеспечить выполнение хотя бы одного из следующих требований для каждого такого дисплея:
См. редакцию
Восстановлены следующие требования:
Если реализации устройства объявляют
FEATURE_BLUETOOTH_LE
, они:[C-SR-2] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ измерить и компенсировать смещение Rx, чтобы гарантировать, что медианный RSSI BLE составляет -60 дБм +/- 10 дБ на расстоянии 1 м от эталонного устройства, передающего на
ADVERTISE_TX_POWER_HIGH
, где устройства ориентированы таким образом, что они в «параллельных плоскостях» с экранами, обращенными в одном направлении.[C-SR-3] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ измерять и компенсировать смещение Tx, чтобы медианное значение BLE RSSI составляло -60 дБм +/- 10 дБ при сканировании с эталонного устройства, расположенного на расстоянии 1 м, и передачи со скоростью
ADVERTISE_TX_POWER_HIGH
, где устройства ориентированы. так, что они находятся в «параллельных плоскостях», а экраны обращены в одном направлении.
См. редакцию
Требования [C-10-3] и [C-10-4] перенесены в 2.2.1. Аппаратное обеспечение .
- [C-10-3] ДОЛЖНО измерить и компенсировать смещение Rx, чтобы гарантировать, что медианный RSSI BLE составляет -55 дБм +/- 10 дБ на расстоянии 1 м от эталонного устройства, передающего на
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] ДОЛЖНО измерить и компенсировать смещение Tx, чтобы гарантировать, что медианный RSSI BLE составляет -55 дБм +/- 10 дБ при сканировании с эталонного устройства, расположенного на расстоянии 1 м и передачи со скоростью
ADVERTISE_TX_POWER_HIGH
.
20 ноября 2023 г.
2. Типы устройств
2.2.1. Аппаратное обеспечение :
См. редакцию
Если реализации карманных устройств декларируют поддержку любого 64-битного ABI (с 32-битным ABI или без него):
См. редакцию
- [ 7.5 /H-1-13] ДОЛЖНА поддерживать возможность
LOGICAL_MULTI_CAMERA
для основной задней камеры, если имеется более 1 задней камеры RGB.
- [ 7.5 /H-1-13] ДОЛЖНА поддерживать возможность
См. редакцию
[ 5.8 /T-0-1] НЕОБХОДИМО установить режим вывода HDMI на самое высокое разрешение для выбранного формата SDR или HDR, который работает с частотой обновления 50 Гц или 60 Гц для внешнего дисплея.
НЕОБХОДИМО установить режим вывода HDMI, чтобы выбрать максимальное разрешение, которое может поддерживаться с частотой обновления 50 Гц или 60 Гц.
См. редакцию
- [9/W-0-1] ДОЛЖЕН объявить
android.hardware.security.model.compatible feature
.
- [9/W-0-1] ДОЛЖЕН объявить
6. Совместимость инструментов и опций разработчика
6.1. Инструменты разработчика :
См. редакцию
- [C-0-12] ДОЛЖЕН записать атом
LMK_KILL_OCCURRED_FIELD_NUMBER
в
См. редакцию
- [C-0-13] ДОЛЖНА реализовать команду оболочки
dumpsys gpu --gpuwork
для отображения
- [C-0-12] ДОЛЖЕН записать атом
9. Совместимость моделей безопасности
См. редакцию
Если реализации устройств используют ядро Linux, способное поддерживать SELinux, они:
См. редакцию
Если реализации устройств используют ядро, отличное от Linux, или Linux без SELinux, они:
4 октября 2023 г.
2. Типы устройств
2.2. Требования к портативному устройству :
См. редакцию
Реализации устройств Android классифицируются как портативные устройства, если они соответствуют всем следующим критериям:
- Иметь физический размер диагонали экрана в диапазоне от 4 дюймов
3,3 дюйма (или 2,5 дюйма для реализаций устройств, поставляемых с уровнем API 29 или более ранней версии)до 8 дюймов.
Начать новые требования
- Иметь интерфейс ввода с сенсорным экраном.
- Иметь физический размер диагонали экрана в диапазоне от 4 дюймов
2.2.1. Аппаратное обеспечение :
См. редакцию
Реализации портативных устройств:
- [ 7.1 .1.1/H-0-1] ДОЛЖЕН иметь хотя бы один
Android-совместимый дисплей, отвечающий всем требованиям, описанным в этом документе.дисплей размером не менее 2,2 дюйма по короткому краю и 3,4 дюйма по длинному краю.
Если реализации портативных устройств поддерживают программный поворот экрана, они:
- [ 7.1 .1.1/H-1-1]* ДОЛЖЕН обеспечить размер логического экрана, доступного для сторонних приложений, не менее 2 дюймов по короткой стороне(-ам) и 2,7 дюйма по длинной стороне(-ам). Устройства, поставляемые с Android API уровня 29 или более ранней версии, МОГУТ быть освобождены от этого требования.
Если реализации портативных устройств не поддерживают программный поворот экрана, они:
- [ 7.1 .1.1/H-2-1]* ДОЛЖЕН обеспечить размер логического экрана, доступного для сторонних приложений, не менее 2,7 дюйма по короткому краю(ам). Устройства, поставляемые с Android API уровня 29 или более ранней версии, МОГУТ быть освобождены от этого требования.
Начать новые требования
[ 7.1 .1.1/H-0-3]* ДОЛЖЕН сопоставлять каждый дисплей
UI_MODE_NORMAL
, доступный для сторонних приложений, на беспрепятственную физическую область дисплея размером не менее 2,2 дюйма по короткому краю и 3,4 дюйма по длинному краю.[ 7.1 .1.3/H-0-1]* ДОЛЖНО установить значение
DENSITY_DEVICE_STABLE
на 92 % или выше фактической физической плотности соответствующего дисплея.
Если реализации портативных устройств объявляют
android.hardware.audio.output
иandroid.hardware.microphone
, они:[ 5.6 /H-1-1] ДОЛЖНА иметь среднюю непрерывную двустороннюю задержку 300 миллисекунд или менее в течение 5 измерений со средним абсолютным отклонением менее 30 мс по следующим путям передачи данных: «динамик-микрофон», 3,5 мм. адаптер обратной связи (если поддерживается), USB-петля (если поддерживается).
[ 5.6 /H-1-2] ДОЛЖНА иметь среднюю задержку между тональным сигналом 300 миллисекунд или менее в течение как минимум 5 измерений по каналу передачи данных от громкоговорителя к микрофону.
Если реализации портативных устройств включают хотя бы один тактильный привод, они:
- [ 7.10 /H]* НЕ СЛЕДУЕТ использовать тактильный привод с эксцентриковой вращающейся массой (ERM) (вибратор).
- [ 7.10 /H]* СЛЕДУЕТ реализовать все общедоступные константы для четкого тактильного восприятия в android.view.HapticFeedbackConstants , а именно (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START и GESTURE_END).
- [ 7.10 /H]* СЛЕДУЕТ реализовать все общедоступные константы для четких тактильных ощущений в android.os.VibrationEffect , а именно (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK и EFFECT_DOUBLE_CLICK), а также все возможные общедоступные константы
PRIMITIVE_*
для насыщенных тактильных ощущений в android.os.VibrationEffect.Composition , а именно ( ЩЕЛЧОК, ТИК, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Некоторые из этих примитивов, такие как LOW_TICK и SPIN, могут быть осуществимы только в том случае, если вибратор поддерживает относительно низкие частоты. - [7.10/H]* СЛЕДУЕТ следовать рекомендациям по сопоставлению общедоступных констант в android.view.HapticFeedbackConstants с рекомендуемыми константами android.os.VibrationEffect с соответствующими амплитудными соотношениями.
- [ 7.10 /H]* СЛЕДУЕТ следовать оценке качества API createOneShot() и createWaveform() .
- [ 7.10 /H]* СЛЕДУЕТ проверить, что результат общедоступного API android.os.Vibrator.hasAmplitudeControl() правильно отражает возможности вибратора.
- [ 7.10 /H]* СЛЕДУЕТ расположить привод рядом с местом, где устройство обычно держат или прикасаются к нему руками.
Если реализации портативных устройств включают хотя бы один линейный резонансный привод общего назначения 7.10 , они:
- [ 7.10 /H] СЛЕДУЕТ расположить привод рядом с местом, где устройство обычно держат или прикасаются к нему руками.
- [ 7.10 /H] СЛЕДУЕТ переместить тактильный привод по оси X (влево-вправо) естественной
книжнойориентации устройства .
Если реализации портативных устройств имеют тактильный привод общего назначения , который представляет собой линейный резонансный привод по оси X (LRA), они:
- [ 7.10 /H] ДОЛЖНО иметь резонансную частоту LRA оси X ниже 200 Гц.
- [ 7.1 .1.1/H-0-1] ДОЛЖЕН иметь хотя бы один
См. редакцию
Реализации портативных устройств ДОЛЖНЫ поддерживать следующие форматы кодирования видео и делать их доступными для сторонних приложений:
- [ 5.2 /H-0-3] AV1
Реализации портативных устройств ДОЛЖНЫ поддерживать следующие форматы декодирования видео и делать их доступными для сторонних приложений:
- [ 5.3 /H-0-6] AV1
2.2.3. Программное обеспечение :
См. редакцию
Если реализации устройства, включающие навигационную клавишу функции недавних событий, как подробно описано в разделе 7.2.3, изменяют интерфейс, они:
- [ 3.8 .3/H-1-1] ДОЛЖЕН реализовать поведение закрепления экрана и предоставить пользователю меню настроек для переключения этой функции.
Если реализации портативных устройств включают поддержку
ControlsProviderService
иControl
API и позволяют сторонним приложениям публиковать элементы управления устройствами , то они:- [ 3.8.16 /H-1-6] Реализации устройства ДОЛЖНЫ точно отображать возможности пользователя следующим образом:
- Если устройство установило
config_supportsMultiWindow=true
и приложение объявляет метаданныеMETA_DATA_PANEL_ACTIVITY
в объявленииControlsProviderService
, включая ComponentName допустимого действия (как определено API), то приложение ДОЛЖНО встроить указанное действие в эту возможность пользователя. - Если приложение не объявляет метаданные
META_DATA_PANEL_ACTIVITY
, оно ДОЛЖНО отображать указанные поля, предоставленные APIControlsProviderService
, а также любые указанные поля, предоставленные API управления .
- Если устройство установило
- [ 3.8.16 /H-1-7] Если приложение объявляет метаданные
META_DATA_PANEL_ACTIVITY
, оно ДОЛЖНО передать значение параметра, определенного в [3.8.16/H-1-5], с помощьюEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
при запуске встроенного действия.
Если реализации устройств позволяют пользователям совершать вызовы любого рода, они
- [ 7.4.1.2 /H-0-1] ДОЛЖЕН объявить флаг функции
android.software.telecom
. - [ 7.4.1.2/H-0-2 ] ДОЛЖЕН реализовать телекоммуникационную структуру .
2.2.4. Производительность и мощность :
См. редакцию
Реализации портативных устройств:
- [ 8.5 /H-0-1] ДОЛЖНО предоставить пользователю возможность
в меню «Настройки»видеть все приложения с активными службами переднего плана или заданиями, инициируемыми пользователем, включая продолжительность каждой из этих служб с момента ее запуска, как описано в документе SDK. .и возможность остановить приложение, выполняющее приоритетную службу или задание, инициированное пользователем.с возможностью остановить приложение, в котором запущена служба переднего плана, и отобразить все приложения, в которых есть активные службы переднего плана, а также продолжительность работы каждой из этих служб с момента ее запуска, как описано в документе SDK .- Некоторые приложения МОГУТ быть освобождены от остановки или включения в такие возможности для пользователей, как описано в документе SDK .
- [ 8.5 /H-0-1] ДОЛЖНО предоставить пользователю возможность
- [ 8.5 /H-0-2] ДОЛЖЕН предоставлять пользователю возможность остановить приложение, в котором выполняется приоритетная служба или задание, инициированное пользователем.
См. редакцию
Если реализации устройств декларируют поддержку android.hardware.telephony
, они:
- [ 9.5 /H-1-1] НЕ ДОЛЖНО устанавливать
UserManager.isHeadlessSystemUserMode
значениеtrue
.
Если реализации устройств имеют безопасный экран блокировки и включают один или несколько агентов доверия, реализующих системный API TrustAgentService
, они:
- [ 9.11.1 /H-1-1] ДОЛЖЕН запрашивать у пользователя один из рекомендуемых основных методов аутентификации (например, PIN-код, шаблон, пароль) чаще, чем раз в 72 часа.
Если реализации портативных устройств задают UserManager.isHeadlessSystemUserMode
значение true
, они
Если реализации портативных устройств поддерживают системный API HotwordDetectionService
или другой механизм обнаружения горячих слов без указания доступа к микрофону, они:
- [9.8/H-1-1] НЕОБХОДИМО убедиться, что служба обнаружения горячих слов может передавать данные только в Систему,
ContentCaptureService
или службу распознавания речи на устройстве, созданнуюSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9.8/H-1-6] НЕ ДОЛЖНО допускать передачу более 100 байтов данных (исключая аудиопотоки) из службы обнаружения горячих слов при каждом успешном результате.
- [9.8/H-1-15] ДОЛЖЕН гарантировать, что аудиопотоки, предоставляемые при успешных результатах использования «горячих слов», передаются в одну сторону от службы обнаружения «горячих слов» к службе голосового взаимодействия.
Если реализации устройства включают приложение, которое использует системный API HotwordDetectionService
или аналогичный механизм для обнаружения горячих слов без индикации использования микрофона, приложение:
- [9.8/H-2-3] НЕ ДОЛЖНЫ передавать из службы обнаружения горячих слов аудиоданные, данные, которые можно использовать для восстановления (полностью или частично) аудио, или аудиоконтент, не связанный с самим горячим словом, за исключением
ContentCaptureService
или служба распознавания речи на устройстве.
Если реализации портативных устройств поддерживают системный API VisualQueryDetectionService
или другой механизм обнаружения запросов без указания доступа к микрофону и/или камере, они:
- [9.8/H-3-1] НЕОБХОДИМО убедиться, что служба обнаружения запросов может передавать данные только в Систему,
ContentCaptureService
или службу распознавания речи на устройстве (созданнуюSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] НЕ ДОЛЖНО допускать передачу какой-либо аудио- или видеоинформации из
VisualQueryDetectionService
, за исключениемContentCaptureService
или службы распознавания речи на устройстве. - [9.8/H-3-3] ДОЛЖНО отображать уведомление пользователя в системном пользовательском интерфейсе, когда устройство обнаруживает намерение пользователя взаимодействовать с приложением Digital Assistant (например, путем обнаружения присутствия пользователя с помощью камеры).
- [9.8/H-3-4] ДОЛЖЕН отображать индикатор микрофона и отображать обнаруженный пользовательский запрос в пользовательском интерфейсе сразу после обнаружения пользовательского запроса.
- [9.8/H-3-5] НЕ ДОЛЖНО позволять устанавливаемому пользователем приложению предоставлять услугу визуального обнаружения запросов.
См. редакцию
Если реализации портативных устройств возвращают android.os.Build.VERSION_CODES.T
для android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, то они:
- ДОЛЖЕН соответствовать требованиям к носителям, перечисленным в разделе 2.2.7.1 CDD Android 13 .
Начать новые требования
Если реализации портативных устройств возвращаютandroid.os.Build.VERSION_CODES.U
для android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, то они:- [5.1/H-1-1] ДОЛЖНО объявлять максимальное количество сеансов аппаратного видеодекодера, которые могут выполняться одновременно в любой комбинации кодеков, с помощью методов
CodecCapabilities.getMaxSupportedInstances()
иVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] ДОЛЖНЫ поддерживать 6 экземпляров сеансов аппаратного декодера 8-битного (SDR) видео (AVC, HEVC, VP9, AV1 или новее) в любой комбинации кодеков, работающих одновременно с 3 сеансами с разрешением 1080p при 30 кадрах в секунду. и 3 сеанса с разрешением 4K при 30 кадрах в секунду, кроме AV1. Кодеки AV1 должны поддерживать только разрешение 1080p, но по-прежнему должны поддерживать 6 экземпляров со скоростью 1080p и 30 кадров в секунду.
- [5.1/H-1-3] ДОЛЖНО объявлять максимальное количество сеансов аппаратного кодирования видео, которые могут выполняться одновременно в любой комбинации кодеков, с помощью методов
CodecCapabilities.getMaxSupportedInstances()
иVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] ДОЛЖНЫ поддерживать 6 экземпляров сеансов аппаратного кодирования 8-битного (SDR) видео (AVC, HEVC, VP9, AV1 или новее) в любой комбинации кодеков, работающих одновременно с 4 сеансами с разрешением 1080p при 30 кадрах в секунду. и 2 сеанса с разрешением 4K при 30 кадрах в секунду, кроме AV1. Кодеки AV1 должны поддерживать только разрешение 1080p, но по-прежнему должны поддерживать 6 экземпляров со скоростью 1080p и 30 кадров в секунду.
- [5.1/H-1-5] ДОЛЖНО объявлять максимальное количество сеансов аппаратного кодирования и декодера видео, которые могут выполняться одновременно в любой комбинации кодеков, с помощью методов
CodecCapabilities.getMaxSupportedInstances()
иVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] ДОЛЖНЫ поддерживать 6 экземпляров 8-битного (SDR) аппаратного видеодекодера и сеансов аппаратного видеокодера (AVC, HEVC, VP9, AV1 или новее) в любой комбинации кодеков, работающих одновременно с 3 сеансами в разрешении 4K. Разрешение @30 кадров в секунду (кроме AV1), из которых не более 2 — сеансы кодирования и 3 сеанса с разрешением 1080p. Кодеки AV1 должны поддерживать только разрешение 1080p, но по-прежнему должны поддерживать 6 экземпляров со скоростью 1080p и 30 кадров в секунду.
- [5.1/H-1-19] ДОЛЖНЫ поддерживать 3 экземпляра 10-битного (HDR) аппаратного видеодекодера и сеансы аппаратного видеокодера (AVC, HEVC, VP9, AV1 или новее) в любой комбинации кодеков, работающих одновременно с разрешением 4K при 30 кадрах в секунду. (кроме AV1), из которых не более 1 является сеансом кодировщика, который можно настроить в формате ввода RGBA_1010102 через поверхность GL. Генерация метаданных HDR кодером не требуется при кодировании с поверхности GL. Сеансы кодека AV1 необходимы только для поддержки разрешения 1080p, даже если это требование требует 4K.
- [5.1/H-1-7] ДОЛЖНА иметь задержку инициализации кодека 40 мс или меньше для сеанса кодирования видео 1080p или меньше для всех аппаратных видеокодеров при нагрузке. Здесь нагрузка определяется как одновременный сеанс перекодирования только видео с разрешением 1080p на 720p с использованием аппаратных видеокодеков вместе с инициализацией записи аудио-видео 1080p. Для кодека Dolby Vision задержка инициализации кодека ДОЛЖНА составлять 50 мс или меньше.
- [5.1/H-1-8] ДОЛЖНА иметь задержку инициализации кодека 30 мс или меньше для сеанса кодирования звука со скоростью передачи данных 128 кбит/с или ниже для всех аудиокодеров при нагрузке. Здесь нагрузка определяется как одновременный сеанс перекодирования только видео с разрешением 1080p на 720p с использованием аппаратных видеокодеков вместе с инициализацией записи аудио-видео 1080p.
- [5.1/H-1-9] ДОЛЖНЫ поддерживать 2 экземпляра сеансов безопасного аппаратного видеодекодера (AVC, HEVC, VP9, AV1 или новее) в любой комбинации кодеков, работающих одновременно с разрешением 4k при 30 кадрах в секунду (кроме AV1) для обоих 8- бит (SDR) и 10-битный HDR-контент. Сеансы кодека AV1 необходимы только для поддержки разрешения 1080p, даже если это требование требует 4K.
- [5.1/H-1-10] ДОЛЖНЫ поддерживать 3 экземпляра незащищенных сеансов аппаратного видеодекодера вместе с 1 экземпляром защищенного сеанса аппаратного видеодекодера (всего 4 экземпляра) (AVC, HEVC, VP9, AV1 или новее) в любом кодеке. комбинация работает одновременно с 3 сеансами с разрешением 4K при 30 кадрах в секунду (кроме AV1), которая включает один сеанс безопасного декодера и 1 сеанс nn-secure с разрешением 1080p при 30 кадрах в секунду, где не более 2 сеансов могут быть в 10-битном HDR. Сеансы кодека AV1 необходимы только для поддержки разрешения 1080p, даже если это требование требует 4K.
- [5.1/H-1-11] ДОЛЖЕН поддерживать безопасный декодер для каждого аппаратного декодера AVC, HEVC, VP9 или AV1 на устройстве.
- [5.1/H-1-12] ДОЛЖНА иметь задержку инициализации кодека 40 мс или меньше для сеанса декодирования видео 1080p или меньше для всех аппаратных видеодекодеров при нагрузке. Загрузка здесь определяется как одновременный сеанс перекодирования только видео с разрешением 1080p на 720p с использованием аппаратных видеокодеков вместе с инициализацией воспроизведения аудио-видео 1080p. Для кодека Dolby Vision задержка инициализации кодека ДОЛЖНА составлять 50 мс или меньше.
- [5.1/H-1-13] ДОЛЖНА иметь задержку инициализации кодека 30 мс или меньше для сеанса декодирования звука со скоростью передачи данных 128 кбит/с или ниже для всех аудиодекодеров при нагрузке. Загрузка здесь определяется как одновременный сеанс перекодирования только видео с разрешением 1080p на 720p с использованием аппаратных видеокодеков вместе с инициализацией воспроизведения аудио-видео 1080p.
- [5.1/H-1-14] ДОЛЖЕН поддерживать аппаратный декодер AV1 Main 10, уровень 4.1 и зернистость пленки.
- [5.1/H-1-15] ДОЛЖЕН иметь как минимум один аппаратный видеодекодер с поддержкой 4K60.
- [5.1/H-1-16] ДОЛЖЕН иметь хотя бы один аппаратный видеокодер с поддержкой 4K60.
- [5.3/H-1-1] НЕ ДОЛЖНО пропускать более 1 кадра за 10 секунд (т. е. падение кадров менее 0,167 процента) для видеосеанса 4K со скоростью 60 кадров в секунду под нагрузкой.
- [5.3/H-1-2] НЕ ДОЛЖНО пропадать более чем на 1 кадр за 10 секунд во время изменения разрешения видео в видеосеансе со скоростью 60 кадров в секунду под нагрузкой для сеанса 4K.
- [5.6/H-1-1] ДОЛЖНА иметь задержку ответа на тональный сигнал 80 миллисекунд или меньше при использовании теста ответа на тональный сигнал CTS Verifier.
- [5.6/H-1-2] ДОЛЖНА иметь двустороннюю задержку аудио 80 миллисекунд или меньше по крайней мере по одному поддерживаемому каналу передачи данных.
- [5.6/H-1-3] ДОЛЖЕН поддерживать >=24-битный звук для стереовыхода через аудиоразъемы 3,5 мм, если они имеются, и через USB-аудио, если поддерживается на всем пути передачи данных для малой задержки и потоковой конфигурации. Для конфигурации с низкой задержкой AAudio должно использоваться приложением в режиме обратного вызова с низкой задержкой. Для конфигурации потоковой передачи приложение должно использовать Java AudioTrack. Как в конфигурации с низкой задержкой, так и в конфигурации потоковой передачи выходной приемник HAL должен принимать
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
илиAUDIO_FORMAT_PCM_FLOAT
в качестве целевого выходного формата. - [5.6/H-1-4] ДОЛЖНЫ поддерживать >= 4-канальные аудиоустройства USB (используются DJ-контроллерами для предварительного просмотра песен.)
- [5.6/H-1-5] ДОЛЖНЫ поддерживать MIDI-устройства, соответствующие классу, и объявлять флаг функции MIDI.
- [5.6/H-1-9] ДОЛЖЕН поддерживать как минимум 12-канальное микширование. Это подразумевает возможность открыть AudioTrack с маской канала 7.1.4 и правильно преобразовать или микшировать все каналы в стерео.
- [5.6/H-SR] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ поддерживать 24-канальное микширование, по крайней мере, с поддержкой масок каналов 9.1.6 и 22.2.
- [5.7/H-1-2] ДОЛЖЕН поддерживать
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
с указанными ниже возможностями расшифровки контента.
Минимальный размер выборки | 4 МБ |
Минимальное количество подвыборок — H264 или HEVC | 32 |
Минимальное количество подвыборок – VP9 | 9 |
Минимальное количество подвыборок — AV1 | 288 |
Минимальный размер буфера подвыборки | 1 МиБ |
Минимальный размер общего криптобуфера | 500 КиБ |
Минимальное количество одновременных сеансов | 30 |
Минимальное количество ключей за сеанс | 20 |
Минимальное общее количество ключей (все сеансы) | 80 |
Минимальное общее количество ключей DRM (все сеансы) | 6 |
Размер сообщения | 16 КиБ |
Расшифрованные кадры в секунду | 60 кадров в секунду |
- [5.1/H-1-17] ДОЛЖЕН иметь как минимум один аппаратный декодер изображений, поддерживающий базовый профиль AVIF.
- [5.1/H-1-18] ДОЛЖЕН поддерживать кодер AV1, который может кодировать разрешение до 480p со скоростью 30 кадров в секунду и 1 Мбит/с.
-
[5.12/H-1-1] ДОЛЖЕН[5.12/H-SR] Настоятельно рекомендуется поддерживать функциюFeature_HdrEditing
для всех аппаратных кодеров AV1 и HEVC, присутствующих на устройстве. - [5.12/H-1-2] ДОЛЖЕН поддерживать цветовой формат RGBA_1010102 для всех аппаратных кодеров AV1 и HEVC, присутствующих на устройстве.
- [5.12/H-1-3] ДОЛЖНО объявляться о поддержке расширения EXT_YUV_target для выборки из текстур YUV как в 8, так и в 10-битном формате.
- [7.1.4/H-1-1] ДОЛЖНО иметь как минимум 6 аппаратных оверлеев в аппаратном компоновщике (HWC) блока обработки данных (DPU), причем как минимум 2 из них способны отображать 10-битный видеоконтент.
Если реализации портативных устройств возвращают android.os.Build.VERSION_CODES.U
для android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
и включают поддержку аппаратного кодировщика AVC или HEVC, то они:
- [5.2/H-2-1] ДОЛЖЕН соответствовать минимальному целевому значению качества, определенному кривыми скорости-искажения видеокодера для аппаратных кодеков AVC и HEVC, как определено в будущей документации.
См. редакцию
android.os.Build.VERSION_CODES.U
для android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, то они:- [ 7.5 /H-1-1] ДОЛЖНА иметь основную заднюю камеру с разрешением не менее 12 мегапикселей и поддержкой захвата видео со скоростью 4k при 30 кадрах в секунду. Основная задняя камера — это задняя камера с наименьшим идентификатором камеры.
- [ 7.5 /H-1-2] ДОЛЖНА иметь основную фронтальную камеру с разрешением не менее 6 мегапикселей и поддержкой захвата видео с разрешением 1080p при 30 кадрах в секунду. Основная фронтальная камера — это фронтальная камера с наименьшим идентификатором камеры.
- [ 7.5 /H-1-3] ДОЛЖНО поддерживать свойство
android.info.supportedHardwareLevel
как FULL или выше для обеих основных камер. - [ 7.5 /H-1-4] ДОЛЖЕН поддерживать
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
для обеих основных камер. - [ 7.5 /H-1-5] ДОЛЖНА иметь задержку захвата JPEG камерой 2 < 1000
900мс для разрешения 1080p, измеренную с помощью теста производительности камеры CTS в условиях освещения ITS (3000K) для обеих основных камер. - [ 7.5 /H-1-6] ДОЛЖНА иметь задержку запуска камеры 2 (открытая камера до первого кадра предварительного просмотра) < 500 мс, как измерено с помощью теста производительности камеры CTS в условиях освещения ITS (3000K) для обеих основных камер.
- [ 7.5 /H-1-8] ДОЛЖЕН поддерживать
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
иandroid.graphics.ImageFormat.RAW_SENSOR
для основной задней камеры. - [ 7.5 /H-1-9] ДОЛЖНА иметь основную камеру, обращенную назад, с поддержкой разрешения 720p или 1080p при частоте 240 кадров в секунду.
- [ 7.5 /H-1-10] ДОЛЖНО иметь минимальное значение ZOOM_RATIO < 1,0 для основных камер, если в том же направлении находится сверхширокоугольная камера RGB.
- [ 7.5 /H-1-11] ДОЛЖНО реализовать параллельную потоковую передачу вперед и назад на основных камерах.
- [ 7.5 /H-1-12] ДОЛЖЕН поддерживать
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
как для основной передней, так и для основной задней камеры. - [ 7.5 /H-1-13] ДОЛЖНА поддерживать возможность
LOGICAL_MULTI_CAMERA
для основных камер, если в одном направлении направлено более 1 камеры RGB. - [ 7.5 /H-1-14] ДОЛЖНА поддерживать возможность
STREAM_USE_CASE
как для основной передней, так и для основной задней камеры. - [ 7.5 /H-1-15] ДОЛЖНЫ поддерживать расширения
боке иночного режима через расширения CameraX и Camera2 для основных камер. - [ 7.5 /H-1-16] ДОЛЖЕН поддерживать возможность DYNAMIC_RANGE_TEN_BIT для основных камер.
- [ 7.5 /H-1-17] ДОЛЖЕН поддерживать CONTROL_SCENE_MODE_FACE_PRIORITY и распознавание лиц ( STATISTICS_FACE_DETECT_MODE_SIMPLE или STATISTICS_FACE_DETECT_MODE_FULL ) для основных камер.
2.2.7.3. Аппаратное обеспечение :
См. редакцию
android.os.Build.VERSION_CODES.U
для android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, то они:- [7.1.1.1/H-2-1] ДОЛЖНО иметь разрешение экрана не менее 1080p.
- [7.1.1.3/H-2-1] ДОЛЖНО иметь плотность экрана не менее 400 точек на дюйм.
- [7.1.1.3/H-3-1] ДОЛЖЕН иметь HDR-дисплей, поддерживающий среднюю яркость не менее 1000 нит.
- [7.6.1/H-2-1] ДОЛЖНО иметь не менее 8 ГБ физической памяти.
См. редакцию
android.os.Build.VERSION_CODES.U
для android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, то они:- [8.2/H-1-1] ДОЛЖЕН обеспечивать скорость последовательной записи не менее 150 МБ/с.
- [8.2/H-1-2] ДОЛЖЕН обеспечивать скорость произвольной записи не менее 10 МБ/с.
- [8.2/H-1-3] ДОЛЖЕН обеспечивать скорость последовательного чтения не менее 250 МБ/с.
- [8.2/H-1-4] ДОЛЖЕН обеспечивать производительность произвольного чтения не менее 100 МБ/с.
- [8.2/H-1-5] ДОЛЖЕН обеспечивать производительность параллельного последовательного чтения и записи со скоростью 2x чтения и 1x записи не менее 50 МБ/с.
См. редакцию
Реализации телевизионных устройств ДОЛЖНЫ поддерживать следующие форматы кодирования видео и делать их доступными для сторонних приложений:
- [ 5.2 /Т-0-3] AV1
Реализации телевизионных устройств ДОЛЖНЫ поддерживать следующие форматы декодирования видео и делать их доступными для сторонних приложений:
- [ 5.3.2 /Т-0-7] AV1
См. редакцию
Если реализации устройств имеют безопасный экран блокировки и включают один или несколько агентов доверия, реализующих системный API TrustAgentService
, они:
- [ 9.11.1 /W-1-1] ДОЛЖЕН запрашивать у пользователя один из рекомендуемых основных методов аутентификации (например, PIN-код, шаблон, пароль) чаще, чем раз в 72 часа.
2.5.1. Аппаратное обеспечение :
См. редакцию
Если реализации устройств включают поддержку радиовещания AM/FM и предоставляют эту функциональность любому приложению, они:
- [ 7.4.10 /A-0-1
]ДОЛЖЕН объявить поддержкуFEATURE_BROADCAST_RADIO
.
Камера внешнего вида — это камера, которая снимает сцены за пределами реализации устройства, например камера заднего вида.
Реализации автомобильных устройств:
- СЛЕДУЕТ включать одну или несколько камер внешнего вида.
Если реализации автомобильных устройств включают камеру внешнего вида, для такой камеры они:
- [ 7.5 /A-1-1] НЕ ДОЛЖНО иметь камеры внешнего вида, доступные через API-интерфейсы камер Android , если они не соответствуют основным требованиям к камерам.
- [ 7.5 /A-SR-1] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ не поворачивать и не зеркально отражать изображение камеры при предварительном просмотре.
- [ 7.5 /A-SR-2] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ иметь разрешение не менее 1,3 мегапикселя.
- ДОЛЖНО иметь оборудование с фиксированным фокусом или EDOF (увеличенная глубина резкости).
- В драйвере камеры МОЖЕТ быть реализован аппаратный или программный автофокус.
Если реализации автомобильных устройств включают одну или несколько камер внешнего вида и загружают службу системы внешнего вида (EVS), то для такой камеры они:
- [ 7.5 /A-2-1] НЕ ДОЛЖНО поворачивать или зеркально отражать изображение камеры при предварительном просмотре.
Реализации автомобильных устройств:
- МОЖЕТ включать одну или несколько камер, доступных сторонним приложениям.
Если реализации автомобильных устройств включают хотя бы одну камеру и делают ее доступной для сторонних приложений, то они:
- [ 7.5 /A-3-1] ДОЛЖЕН сообщить флаг функции
android.hardware.camera.any
. - [ 7.5 /A-3-2] НЕ ДОЛЖНО объявлять камеру как системную .
- МОЖЕТ поддерживать внешние камеры, описанные в разделе 7.5.3 .
- МОЖЕТ включать в себя функции (такие как автофокусировка и т. д.), доступные для камер, расположенных сзади, как описано в разделе 7.5.1 .
Камера заднего вида – камера обзора окружающего мира, которая может быть расположена в любом месте транспортного средства и обращена наружу из кабины транспортного средства; то есть он отображает сцены на дальней стороне кузова автомобиля, как камера заднего вида.
Фронтальная камера – камера, обращенная к пользователю, которая может быть расположена в любом месте транспортного средства и обращена внутрь кабины транспортного средства; то есть это изображения пользователя, например, для видеоконференций и подобных приложений.
Реализации автомобильных устройств:
- [7.5/A-SR-1] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ включить одну или несколько камер, обращенных к окружающему миру.
- МОЖЕТ включать одну или несколько камер, обращенных к пользователю.
- [7.5/A-SR-2] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ поддерживать одновременную потоковую передачу с нескольких камер.
Если реализации автомобильных устройств включают хотя бы одну камеру, обращенную к окружающему миру, то для такой камеры они:
- [7.5/A-1-1] ДОЛЖЕН быть ориентирован таким образом, чтобы длинная часть камеры совпадала с плоскостью XY осей автомобильного датчика Android.
- [7.5/A-SR-3] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ иметь оборудование с фиксированным фокусом или EDOF (увеличенная глубина резкости).
- [7.5/A-1-2] ДОЛЖНА иметь основную камеру, обращенную к миру, в качестве камеры, обращенной к миру, с наименьшим идентификатором камеры.
Если реализации автомобильных устройств включают хотя бы одну камеру, обращенную к пользователю, то для такой камеры:
- [7.5/A-2-1] Основная камера, обращенная к пользователю, ДОЛЖНА быть камерой, обращенной к пользователю, с наименьшим идентификатором камеры.
- МОЖЕТ быть ориентировано так, чтобы длинная часть камеры совпадала с плоскостью XY осей автомобильных датчиков Android.
Если реализации автомобильных устройств включают камеру, доступную через API android.hardware.Camera
или android.hardware.camera2
, то они:
- [7.5/A-3-1] ДОЛЖЕН соответствовать требованиям к основной камере, указанным в разделе 7.5.
Если реализации автомобильных устройств включают камеру, которая недоступна ни через API android.hardware.Camera
, ни через API android.hardware.camera2
, то они:
- [7.5/A-4-1] ДОЛЖЕН быть доступен через службу системы расширенного просмотра.
Если реализации автомобильных устройств включают одну или несколько камер, доступных через системную службу расширенного просмотра, для такой камеры они:
- [7.5/A-5-1] НЕ ДОЛЖНО поворачивать или зеркально отражать изображение камеры при предварительном просмотре.
- [7.5/A-SR-4] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ иметь разрешение не менее 1,3 мегапикселя.
Если реализации автомобильных устройств включают одну или несколько камер, которые доступны как через системную службу расширенного просмотра, так и через API android.hardware.Camera
или android.hardware.Camera2
, то для такой камеры они:
- [7.5/A-6-1] ДОЛЖЕН сообщать один и тот же идентификатор камеры.
Если реализации автомобильных устройств предоставляют собственный API камеры, они:
- [7.5/A-7-1] ДОЛЖЕН реализовать такой API камеры с использованием API
android.hardware.camera2
или API системы расширенного просмотра.
2.5.3. Программное обеспечение :
См. редакцию
Реализации автомобильных устройств:
- [ 3.8 /A-0-1] НЕ ДОЛЖНО разрешать полноправным второстепенным пользователям, которые не являются текущими пользователями переднего плана, запускать действия и иметь доступ к пользовательскому интерфейсу на любых дисплеях.
См. редакцию
Если реализации автомобильных устройств объявляют android.hardware.microphone
, они:
- [ 9.8.2 /A-1-1] ДОЛЖЕН отображать индикатор микрофона, когда приложение получает доступ к аудиоданным с микрофона, но не тогда, когда доступ к микрофону осуществляется только
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
или приложениями, выполняющими роли, указанные в разделе 9.1 с идентификатором CDD [C-4-X]. - [ 9.8.2 /A-1-2] НЕ ДОЛЖНО скрывать индикатор микрофона для системных приложений, которые имеют видимые пользовательские интерфейсы или прямое взаимодействие с пользователем.
- [ 9.8.2 /A-1-3] должен предоставить пользовательский доступный доступ для переключения микрофона в приложении «Настройки».
Если реализации автомобильных устройств объявит android.hardware.camera.any
, то они:
- [ 9.8.2 /A-2-1] должен отображать индикатор камеры, когда приложение обращается к данным с живой камерой, но не в том случае, когда камера доступна только при приложениях (-ах), удерживающих роли, как определено,
вызововыев разделе 9.1 разрешения с идентификатором CDD [C-4-X][C-3-X].
- [ 9.8.2 /A-2-3] должен предоставить пользовательский доступный доступ для переключения камеры в приложении «Настройки».
- [ 9.8.2 /A-2-4] должны отображать недавние и активные приложения, используя камеру, возвращаемую из
PermissionManager.getIndicatorAppOpUsageData()
, а также любые сообщения атрибуции, связанные с ними.
Если реализации устройств имеют безопасный экран блокировки и включают один или несколько доверительных агентов, который реализует API системы TrustAgentService
System, они: они:
- [ 9.11.1 /A-1-1] должен бросить вызов пользователю для одного из рекомендуемых методов первичной аутентификации (например: PIN, шаблон, пароль) чаще, чем раз в 336 часов.
3. Программное обеспечение
3.1. Управляемое совместимость с API :
Смотрите ревизию
Реализации устройства:
- [C-0-8] не должен поддерживать установку приложений, нацеленных на уровень API менее 23.
3.2.3.5. Условное применение намерения :
Смотрите ревизию
Если отчет о реализациях устройства
android.hardware.nfc.uicc
илиandroid.hardware.nfc.ese
, они: они:- [C-19-1] должен реализовать NFCADAPTER.Action_transaction_deTected API намерения (как «EVT_TRANSACTION», определяемый Технической спецификацией Ассоциации GSM TS.26-Требования к телефону NFC) .
3.3.1. Приложение двоичные интерфейсы :
Смотрите ревизию
Реализации устройства:
- [C-0-12] Должен экспортировать символы функции для ядра
Vulkan 1.0Vulkan 1.1 Символы функции, а такжеVK_KHR_surface
,VK_KHR_android_surface
libvulkan.so
VK_KHR_swapchain
,VK_KHR_maintenance1
, и VK_KHR_GIGESICAL_DEVOPOPOPOPOPOPOPOPERIES2 и VK_KHHR_GITER_PICESICALIS_DEVOPOPOPORPOPOR_MANTERS1, иVK_KHR_get_physical_device_properties2
Обратите внимание, что, хотя все символы должны присутствовать, раздел 7.1.4.2 более подробно описывает требования к тому, когда ожидается полная реализация каждой соответствующей функции.
- [C-0-12] Должен экспортировать символы функции для ядра
Смотрите ревизию
Если реализации устройства включают экран или видео -вывод, они:
- [C
SPRITZ
1-5] должныEXPRESSIVE
динамические цветовые тональныеRAINBOW
VIBRANT
FRUIT_SALAD
стили цветовTONAL_SPOT
перечисленныеandroid.theme.customization.theme_styles
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
MONOCHROMATIC
.
- [C
3.8.8. Переключение деятельности :
Смотрите ревизию
Если реализации устройства, включающие навигационную клавишу функции недавних событий, как подробно описано в разделе 7.2.3, изменяют интерфейс, они:
- [C-1-2] должен реализовать поведение закрепления экрана и предоставить пользователю меню «Настройки» для переключения функции.
3.9.2 Управляемая поддержка профиля :
Смотрите ревизию
Если реализации устройств объявит
android.software.managed_users
, они:- [C-1-10] должен убедиться, что данные экрана сохраняются в хранении рабочего профиля, когда снимки экрана снимается в окне
topActivity
, которое сосредоточено (тот, на котором взаимодействовал пользователь с последним среди всех действий) и принадлежит рабочему профилю приложение . - [C-1-11] не должен захватывать какое-либо другое содержимое экрана (системная панель, уведомления или какое-либо содержание личного профиля), за исключением окна приложения/Windows при приложении рабочего профиля при сохранении снимка экрана в рабочем профиле (чтобы гарантировать, что данные личного профиля являются не сохранено в рабочем профиле).
- [C-1-10] должен убедиться, что данные экрана сохраняются в хранении рабочего профиля, когда снимки экрана снимается в окне
3.9.5 Структура разрешения политики устройства : новый раздел
Смотрите ревизию
Если отчет о реализациях устройства
android.software.device_admin
илиandroid.software.managed_users
, то они:- [C-1-1] должен разрешить конфликты политики устройств, как задокументировано в документации AOSP.
5. Совместимость с мультимедиа
5.1.4. Кодирование изображения :
Смотрите ревизию
Реализации устройства должны поддерживать кодирование кодирования следующего изображения:
- [C-0-4] Avif
- Устройства должны поддерживать
BITRATE_MODE_CQ
и базовый профиль.
- Устройства должны поддерживать
- [C-0-4] Avif
5.1.5. Декодирование изображения :
Смотрите ревизию
Реализации устройства должны поддерживать декодирование кодирования следующего изображения:
[C-0-7] Avif (базовый профиль)
5.1.6. Детали кодеков изображения :
Смотрите ревизию
Формат/кодек Подробности Поддерживаемые типы файлов/форматы контейнеров JPEG База+прогрессивный Jpeg (.jpg) гифка GIF (.gif) PNG Png (.png) БМП BMP (.bmp) ВебП Webp (.webp) Сырой Arw (.arw), cr2 (.cr2), dng (.dng), nef (.nef), nrw (.nrw), orf (.orf), pef (.pef), raf (.raf), rw2 (. .rw2), srw (.srw) Heif Изображение, сбор изображений, последовательность изображений Heif (.heif), heic (. Avif (базовый профиль) Изображение, коллекция изображений, базовый профиль последовательности изображений Контейнер weif (.avif) Смотрите ревизию
Формат/кодек Подробности Типы файлов/форматы контейнеров поддерживать H.263 - 3gpp (.3gp)
- MPEG-4 (.mp4)
- Матроска (.mkv, только декодировать)
H.264 AVC См. Раздел 5.2 и 5.3 для получения подробной информации - 3gpp (.3gp)
- MPEG-4 (.mp4)
- MPEG-2 TS (.ts, не просыпается)
- Матроска (.mkv, только декодировать)
H.265 HEVC Подробнее см. Раздел 5.3 - MPEG-4 (.mp4)
- Матроска (.mkv, только декодировать)
MPEG-2 Основной профиль - Mpeg2-ts (.ts, не просыпается)
- MPEG-4 (.mp4, только декодирует)
- Матроска (.mkv, только декодировать)
MPEG-4 sp - 3gpp (.3gp)
- MPEG-4 (.mp4)
- Матроска (.mkv, только декодировать)
ВП8 См. Раздел 5.2 и 5.3 для получения подробной информации - Webm (.webm)
- Матроска (.mkv)
ВП9 Подробнее см. Раздел 5.3 - Webm (.webm)
- Матроска (.mkv)
АВ1 См. Раздел 5.2 и раздел 5.3 для получения подробной информации - MPEG-4 (.mp4)
- Матроска (.mkv, только декодировать)
5.1.10. Характеристика кодека СМИ :
Смотрите ревизию
Если реализации устройства поддерживают видеокодеки:
- [C-2-1] Все видеокодеки должны публиковать достижимые данные о частоте кадров для следующих размеров, если подтверждается кодеком:
SD (низкое качество) SD (высокое качество) HD 720p HD 1080p UHD Разрешение видео - 176 x 144 PX (H263, MPEG2, MPEG4)
- 352 x 288 PX (MPEG4 Encoder, H263, MPEG2)
- 320 x 180 px (VP8, VP8)
- 320 x 240 px (другие)
- 704 x 576 px (H263)
- 640 x 360 px (VP8, VP9)
- 640 x 480 px (энкодер MPEG4)
- 720 x 480 px (другой, AV1 )
- 1408 x 1152 px (H263)
- 1280 x 720 пк (другой, AV1 )
1920 x 1080 PX (кроме MPEG4, AV1 ) 3840 x 2160 px (HEVC, VP9, AV1 ) Смотрите ревизию
Если реализации устройств поддерживают любой видеокодер и сделайте его доступным для сторонних приложений, они:- Не должно быть, через два скользящих окна, более 15% над битрейтом между интервалом внутрифрейм (I-Frame).
- Не должно быть более чем на 100% над битрейтом над раздвижным окном в 1 секунду.
Если реализации устройств поддерживают любой видеокодер и сделайте его доступным для сторонних приложений и установите
MediaFormat.KEY_BITRATE_MODE
toBITRATE_MODE_VBR
, чтобы энкодер работал в режиме битрейта переменной, тогда, если он не влияет на минимальный качественный пол , кодированный битрейт:-
[C-5-1] не должнобыть , в течение одного скользящего окна, более 15% над битрейтом между интервалами внутрифреймов (I-Frame). -
[C-5-2] не должнобыть более чем на 100% над битрейтом в скользящем окне 1 секунды.
Если реализации устройства поддерживают какой-либо видеокодер и сделайте его доступным для сторонних приложений и установите
MediaFormat.KEY_BITRATE_MODE
наBITRATE_MODE_CBR
, чтобы энкодер работает в режиме постоянного битрейта, то кодированный битрейт: битрейт:-
[C-6-1] должен[C-SR-2] настоятельно рекомендуется не превышать 15% по сравнению с целевым битрейтом на раздвижное окно в 1 секунду.
Смотрите ревизию
Если реализации устройства поддерживают кодеры H.263 и сделайте их доступными для сторонних приложений, они:
- [C-1-1] должен поддерживать разрешение QCIF (176 x 144), используя базовый уровень профиля 45. Резолюция SQCIF является необязательным.
-
Должен поддерживать динамически настраиваемые битрейты для поддерживаемого энкодера.
Смотрите ревизию
Если реализации устройства поддерживают кодек H.265, они:
- [C-1-1] Должен поддерживать разрешение основного профиля 3 до 512 x 512 .
-
Следует поддерживать профили кодирования HD, как указано в следующей таблице. - [C-SR-1] настоятельно рекомендуется поддерживать профиль SD 720 x 480 и профили кодирования HD, как указано в следующей таблице, если есть аппаратный кодер.
5.2.6. AV1 : новый раздел
Смотрите ревизию
Если реализации устройства поддерживают кодек AV1, они: они:
- [C-1-1] должен поддерживать основной профиль, включая 8-битный и 10-битный контент.
[C-1-2] должны публиковать данные о производительности, т.е. отчеты отчета о производительности через API-
getSupportedFrameRatesFor()
илиgetSupportedPerformancePoints()
для поддерживаемых разрешений в таблице ниже.[C-1-3] должен принять метаданные HDR и вывести его в бит-стрим
Если энкодер AV1 ускоряется аппаратное ускорение, то это:
- [C-2-1] должен поддерживать профиль кодирования HD1080P из таблицы ниже:
СД HD 720p HD 1080p UHD Разрешение видео 720 x 480 px 1280 x 720 пк 1920 x 1080 px 3840 x 2160 px Частота кадров видео 30 кадров в секунду 30 кадров в секунду 30 кадров в секунду 30 кадров в секунду Видео битрейт 5 Мбит/с 8 Мбит/с 16 Мбит / с 50 Мбит/с Смотрите ревизию
Если реализации устройства поддерживают декодеры H.263, они:
- [C-1-1] должны поддерживать базовый уровень профиля 30 (разрешения CIF, QCIF и SQCIF @ 30FPS 384KBPS) и уровня 45 (разрешения QCIF и SQCIF @ 30fps 128 кбит / с) .
Смотрите ревизию
Если реализации устройства поддерживают кодек AV1, они:- [C-1-1] должен поддерживать профиль 0, включая 10-битный контент.
Если реализации устройств поддерживают кодек AV1 и сделайте его доступным для сторонних приложений, они:
- [C-1-1] должен поддерживать основной профиль, включая 8-битный и 10-битный контент.
Если реализации устройств обеспечивают поддержку кодека AV1 с аппаратным ускоренным декодером, то они:
- [C-2-1] должен быть в состоянии декодировать как минимум профили декодирования видео 720p HD 720p из таблицы ниже, когда высота, сообщаемая
Display.getSupportedModes()
Метод равна или превышает 720p. - [C-2-2] Должен быть в состоянии декодировать как минимум HD 1080p Профили декодирования видео из таблицы ниже, когда высота, сообщаемая
Display.getSupportedModes()
Метод равна или превышает 1080p.
СД HD 720p HD 1080p UHD Разрешение видео 720 x 480 px 1280 x 720 пк 1920 x 1080 px 3840 x 2160 px Частота кадров видео 30 кадров в секунду 30 кадров в секунду 30 кадров в секунду 30 кадров в секунду Видео битрейт 5 Мбит/с 8 Мбит/с 16 Мбит / с 50 Мбит/с Если реализации устройства поддерживают профиль HDR через API -интерфейсы медиа, то они:
- [C-3-1] Должен поддерживать извлечение и вывод метаданных HDR из бита и/или контейнера.
- [C-3-2] должен правильно отображать контент HDR на экране устройства или на стандартном порте видео вывода (например, HDMI).
5.4.2. Захват для распознавания голоса :
Смотрите ревизию
Если реализации устройства объявит
android.hardware.microphone
, они:- Должен установить аудио входной чувствительность, так что источник синусоидального тона 1000 Гц, сыгранный на уровне звукового давления 90 дБ (SPL) (измеренный
на расстоянии 30 см отрядом с микрофоном), дает идеальный отклик среднеквадратичного уровня 2500 в диапазоне 1770 и и 3530 для 16 -битных моментов (или -22,35 дБ ± 3DB Полная масштаба для образцов с плавающей запятой/двойной точностью) для каждого микрофона, используемого для записи источника звука распознавания голоса.
- Должен установить аудио входной чувствительность, так что источник синусоидального тона 1000 Гц, сыгранный на уровне звукового давления 90 дБ (SPL) (измеренный
Смотрите ревизию
Если реализации устройства объявляют функцию
android.hardware.audio.output
, они:- [C-1-4] должен поддерживать аудиоэффекты с входом и выводом с плавающей точкой.
- [C-1-5] должен убедиться, что аудиоэффекты поддерживают несколько каналов до количества каналов микшера, также известного как FCC_LIMIT.
Смотрите ревизию
Если реализации устройств объявит
android.hardware.audio.output
, они настоятельно рекомендуются для удовлетворения или превышения следующих требований:- [C-SR-4] Выходная метка времени, возвращаемая AudiotRack.getTimeStamp и
AAudioStream_getTimestamp
является точной до +/-1 мс.
- [C-SR-4] Рассчитанные задержки в обратном направлении, основанные на входных и выходных метках времени, возвращаемых
AAudioStream_getTimestamp
, настоятельно рекомендуется находиться в пределах 30 мсек от измеренной задержки обработки дляAAUDIO_PERFORMANCE_MODE_NONE
иAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
для динамиков, Wired и Wirless Hearsets.
- [C-SR-4] Выходная метка времени, возвращаемая AudiotRack.getTimeStamp и
7. Совместимость оборудования
Смотрите ревизию
Android включает в себя средства, которые автоматически регулируют активы приложений и соответствующие макеты пользовательского интерфейса для устройства, чтобы гарантировать, что сторонние приложения хорошо работают в
различных аппаратных конфигурациях .Разнообразие аппаратных дисплеев и конфигураций. Совместимый с Android-дисплей-это экран дисплея, который реализует все поведения и API, описанные в разработчиках Android-обзор совместимости экрана , этот раздел (7.1) и его подразделах, а также любое дополнительное специфическое поведение типа устройства, документированные в разделе 2 этот CDD.На Android-совместимых дисплеях (ы), где могут работать все сторонние Android-совместимые приложения, реализации устройств должны должным образом реализовать эти API и поведение, как подробно описано в этом разделе.Начните новые требования
Реализации устройства:
- [C-0-1], по умолчанию, приложения должны делать сторонние приложения только на Android-совместимые дисплеи.
Единицы, на которые ссылаются требования в этом разделе, определены следующим образом:
- Физический диагональный размер . Расстояние в дюймах между двумя противоположными углами освещенной части дисплея.
-
точки на дюйм (DPI)плотность . Количество пикселей, охватываемое линейным горизонтальным или вертикальным пролетом 1 ” , выраженным в виде пикселей на дюйм (PPI или DPI) . Там, где указаны значенияDPIи DPI , перечислены, как горизонтальный, так и вертикальный DPI должны попадать в указанный диапазон. - соотношение сторон . Соотношение пикселей более длинного измерения к более короткому размеру экрана. Например, отображение 480x854 пикселей будет 854/480 = 1,779 или примерно «16: 9».
- независимый от плотности пиксель (DP) .
Виртуальныйпиксельный блок , нормализованный с плотностью экранана 160 DPI160. Для некоторой плотности D, и ряд пикселей P, количество DP, независимых от плотности, рассчитывается как:Pixels = DPS * (плотность/160)dp = (160 / d) * p .
7.1.1.1. Размер и форма экрана :
Смотрите ревизию
Если реализации устройства поддерживают экраны, способные для конфигурации
UI_MODE_TYPE_NORMAL
Size ивключают, совместимый с AndroidИспользование физического дисплея с округлыми углами для отображения этих экранов , они: они: они: они: они: они: они: они: они: они: они: они: они: они: они:- [C-1-1] должен убедиться, что по крайней мере одно из следующих требований выполняется для каждого такого дисплея :
- Радиус округлых углов меньше или равен 38 DP.
Когда коробка на 15 DP на 15 DP закреплена на каждом углу логического дисплея, на экране виден по крайней мере один пиксель каждой коробки.
Должен включать в себя доступность пользователя, чтобы переключиться на режим отображения с прямоугольными углами.
Начните новые требования
Если реализации устройства способны только к конфигурации
NO_KEYS
клавиатуры и намереваются сообщить о поддержке конфигурации режимаUI_MODE_TYPE_NORMAL
, они: они: они: они:- [C-4-1] должен иметь размер макета, за исключением любых вырезов дисплея, не менее 596 DP x 384 DP или более.
Если реализации устройств включают, совместимый с андроидом дисплей (ы), который складывается, или включает в себя складной шарнир между несколькими панелями отображения и предоставляет такие дисплеи (ы) для отображения сторонних приложений, они: они:
- [C-2-1] должен реализовать последнюю доступную стабильную версию API Extensions или стабильную версию API SideCar , которая будет использоваться Window Manager JetPack Library.
Если реализации устройства включают, совместимый с андроидом дисплей (ы), который складывается, или включает в себя складной шарнир между несколькими панелями отображения, и если шарнир или склад пересекает полноэкранное окно приложения, они: они:
- [C-3-1] должны сообщить о позиции, границах и состоянии шарнира или складываться через расширения или API-файлы коляска в приложение.
Если реализации устройства включают одну или несколько областей отображения, которые складываются, или включают в себя складной шарнир между несколькими областями панели дисплея, совместимых с Android, и предоставляют такие области дисплея, доступными для приложений, они: они: они: они:
- [C-4-1] должен реализовать правильную версию уровня API API Window Manager, как описано в предстоящей документации.
7.1.1.2. Соотношение сторон экрана : удалено
Смотрите ревизию
Реализации устройства:
- [C-0-1]
По умолчанию реализации устройствдолжны сообщатьтолькоо одной из плотностей Android Framework, которые перечислены на APIDisplayMetrics
с помощью APIDENSITY_DEVICE_STABLE
, и это значение должно быть статическим значением для каждого физического отображенияв любое время; Однако,однако , устройство может сообщать о другойпроизвольной плотностиDisplayMetrics.density
в соответствии с изменениями конфигурации дисплея, сделанных пользователем (например, размером дисплея), установленным после начальной загрузки.
- Реализации устройства должны определять стандартную плотность Android -каркаса, которая является численной близостью к физической плотности экрана, если только эта логическая плотность не нажимает размер экрана ниже минимального поддерживаемого. Если стандартная плотность Android Framework, которая является численной близостью к физической плотности, приводит к размеру экрана, который меньше, чем самый маленький поддерживаемый совместимый размер экрана (ширина 320 DP), реализации устройств должны сообщать о следующей плотности самой низкой стандартной плотности Android Framework.
Начните новые требования
- Следует определить стандартную плотность Android Framework, которая является численной близостью к физической плотности экрана, или значение, которое будет сопоставлено с тем же эквивалентным угловым полем измерения обзора портативного устройства.
Если реализации устройства предоставляют,
естьдоступность для изменения размера дисплея устройства , они :- [C-1-1]
Размер дисплея не должен быть масштабирован, которыйне должен масштабировать дисплей , более 1,5 разаDENSITY_DEVICE_STABLE
, нативная плотностьили производить эффективное минимальное размер экрана, меньшее, чем 320DP (эквивалентно квалификатору ресурса SW320DP), в зависимости от того, что наступает на первое место. - [C-1-2]
Размер отображения не должен быть масштабирован,не должен масштабировать дисплей, меньший, чем в 0,85 раза вышеплотностиDENSITY_DEVICE_STABLE
.
- [C-0-1]
Смотрите ревизию
Если реализации устройства включают в себя поддержку Vulkan
1.0 или выше, они:[C-1-3] должен полностью реализовать API
VkPhysicalDevice
Vulkan 1.0Vulkan 1.1 .[C-1-5] не должен перечислять слои
com.android.graphics.injectLayers.enable
предоставленные библиотеками за пределами пакета приложений, или предоставлять другие способы отслеживания или перехвата API Vulkan, если только приложениеtrue
имеет набора атрибутовandroid:debuggable
com.android.graphics.injectLayers.enable
set totrue
.
- Следует поддерживать
VkPhysicalDeviceProtectedMemoryFeatures
иVK_EXT_global_priority
.
- [C-1-13] должен удовлетворять требованиям, указанным в профиле Android 2021 .
[C-SR-5] настоятельно рекомендуется поддерживать
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
иVK_EXT_global_priority
.[C-SR-6] настоятельно рекомендуется использовать
SkiaVk
с HWUI.
Если реализации устройства включают в себя поддержку Vulkan 1.1 и объявьте любой из флажков функций Vulkan , описанных здесь , они: они:
- [C-SR-7] настоятельно рекомендуется сделать расширение
VK_KHR_external_fence_fd
доступное для сторонних приложений, и включить приложение для экспортной полезной нагрузки и импорта полевой нагрузки FOSIX Descriptors файлов, как описано здесь .
7.3.10. Биометрические датчики :
Смотрите ревизию
Если реализации устройства имеют несколько биометрических датчиков, они:
[C-7-1] Должен, когда биометрика находится в блокировке (т.е. биометрическая система отключена до тех пор, пока пользователь не разблокируется с первичной аутентификацией) или блокировки, связанной с временем (то есть биометрическая. Из -за слишком многих неудачных попыток также заблокируют все другие биометрические данные более низкого биометрического класса. В случае блокировки, связанной с временем, время отказа для биометрической проверки должно быть максимальным временем отказа от всей биометрии в блокировке.
[C-SR-12] настоятельно рекомендуется, когда биометрическая локация находится в блокировке (то есть биометрическая отключена до тех пор, пока пользователь не разблокируется с первичной аутентификацией) или блокировка по времени (то есть биометрическая интервал) Из -за слишком многих неудачных попыток, чтобы также заблокировать все другие биометрические данные одного и того же биометрического класса. В случае блокировки, связанной с по времени, время отказа для биометрической проверки настоятельно рекомендуется быть максимальным временем отказа от всей биометрии в блокировке.
[C-7-2] должен бросить вызов пользователю для рекомендуемой первичной аутентификации (например: PIN, шаблон, пароль), чтобы сбросить счетчик блокировки для заблокированной биометрии. Биометрия класса 3 может быть разрешено сбросить счетчик блокировки для заблокированной биометрики того же или нижнего класса. Биометрия класса 2 или класса 1 нельзя допустить, чтобы завершить операцию сброса блокировки для любой биометрии.
Если реализации устройств хотят рассматривать биометрический датчик как класс 1 (ранее удобство ), они:
[C-1-12] должны иметь скорость приемлемости и самозванца не выше 40% на виды прибора атаки (PAI) представления , измеренные по протоколам тестов на биометрии Android .
[C-SR-13] настоятельно рекомендуется иметь скорость приемлемости и самозванца не выше 30% на виды прибора атаки представления (PAI) , что измеряется с помощью протоколов тестов на биометрии Android .
[C-SR-14] настоятельно рекомендуется раскрывать биометрический класс биометрического датчика и соответствующие риски его включения.
[C-SR-17] настоятельно рекомендуется реализовать новые интерфейсы AIDL (например,
IFace.aidl
иIFingerprint.aidl
).
Если реализации устройств хотят рассматривать биометрический датчик как класс 2 (ранее слабый ), они:
- [C-SR-15] настоятельно рекомендуется иметь скорость приема и самозванца не выше 20% на виды прибора атаки презентации (PAI) , что измеряется с помощью протоколов тестов на биометрии Android .
- [C-2-3] должен выполнить биометрическое соответствие в изолированной среде выполнения за пределами пользователя Android или пространства ядра, таких как доверенная среда выполнения (TEE)
илина чипе с безопасным каналом в изолированную среду выполнения или на защищенной Виртуальная машина, которая соответствует требованиям в разделе 9.17 . - [C-2-4] должен иметь все идентифицируемые данные, зашифрованные и криптографически аутентификацию, так что их нельзя получить, чтение или изменение за пределами изолированной среды выполнения или чипа с безопасным каналом в изолированную среду выполнения, как задокументировано в Руководстве по реализации На сайте проекта с открытым исходным кодом Android или защищенной виртуальной машиной, управляемой гипервизором, который отвечает требованиям в разделе 9.17 .
- [C-2-5] для биометрии на основе камеры, в то время как биометрическая аутентификация или регистрация происходит:
- Должен управлять камерой в режиме, который предотвращает чтение кадров камеры или изменение за пределами изолированной среды выполнения или чипа с безопасным каналом в изолированную среду выполнения или защищенную виртуальную машину, управляемую гипервизором, который соответствует требованиям в разделе 9.17 .
- Для решений RGB с одной камерой кадры могут быть читаемыми за пределами изолированной среды выполнения для поддержки операций, таких как предварительный просмотр для регистрации, но все же не должны быть изменяемыми.
- [C-2-7] не должны разрешать незашифрованный доступ к идентифицируемым биометрическим данным или любым данным, полученным из ИТ (таких как встроенные), к процессору приложения вне контекста футболки или защищенной виртуальной машины, контролируемой гипервизором, который отвечает требованиям в разделе. 9.17 . Обновление устройств, запущенных на Android версии 9 или ранее, не освобождаются от C-2-7.
Если реализации устройств хотят рассматривать биометрический датчик как класс 3 (ранее сильный ), они:
- [C-SR-16] настоятельно рекомендуется иметь скорость приемлемости и самозванца не выше 7% на виды прибора атаки представления (PAI) , измеренные с помощью протоколов тестов на биометрии Android .
7.3.13. IEEE 802.1.15.4 (UWB) :
Смотрите ревизию
Если реализации устройства включают в себя поддержку 802.1.15.4 и предоставят функциональность сторонним приложению, они: они:
- [C-1-2] должен сообщить об аппаратном флаге
android.hardware.uwb
. - [C-1-3] должны поддерживать все следующие наборы конфигурации (предварительно определенные комбинации параметров FIRA UCI ), определенные в реализации AOSP.
-
CONFIG_ID_1
: FIRA DEFED UNICASTSTATIC STS DS-TWR
RANGING, отложенный режим, интервал в диапазоне 240 мс. -
CONFIG_ID_2
: FIRA DEFED ONE-MAMESTATIC STS DS-TWR
RANGING, отложенный режим, интервал в диапазоне 200 мс. Типичный вариант использования: смартфон взаимодействует со многими интеллектуальными устройствами. -
CONFIG_ID_3
: так же, какCONFIG_ID_1
, за исключением того, что данные по углам (AOA) не сообщаются. -
CONFIG_ID_4
: так же, какCONFIG_ID_1
, за исключением того, что режим безопасности P-Sts включен. -
CONFIG_ID_5
: так же, какCONFIG_ID_2
, за исключением того, что режим безопасности P-Sts включен. -
CONFIG_ID_6
: так же, какCONFIG_ID_3
, за исключением того, что режим безопасности P-Sts включен. -
CONFIG_ID_7
: То же, что иCONFIG_ID_2
, за исключением того, что режим ключа P-Sts индивидуального элемента управления включен.
-
- [C-1-4] должен предоставить пользовательский доступный доступ, чтобы пользователь позволил пользователю переключать состояние UWB Radio включен/выключение.
- [C-1-5] должен обеспечить соблюдение этих приложений, использующих радио UWB, удерживать разрешение
UWB_RANGING
(в рамках группы разрешенийNEARBY_DEVICES
).
Пропуск соответствующих тестов на соответствие и сертификации, определенные стандартными организациями, включая FIRA , CCC и CSA, помогает обеспечить правильные функции 802.1.15.4.
- [C-1-2] должен сообщить об аппаратном флаге
Смотрите ревизию
«Телефония», используемая API API Android, и этот документ относится специально для оборудования, связанного с размещением голосовых вызовов и отправкой SMS -сообщений , или созданием мобильных данных с помощью мобильной сети GSM, CDMA, LTE, NR) GSM или CDMA. Устройство, поддерживающее «Телефонию», может предложить некоторые или все услуги по вызову, обмену сообщениями и передачи данных, которые подходят для продукта.
через сеть GSM или CDMA. Несмотря на то, что эти голосовые вызовы могут или не могут быть переключены на пакетах, они предназначены для целей Android, которые считаются независимыми от любого подключения данных, которые могут быть реализованы с использованием той же сети. Другими словами, функция Android «Телефония» и API относятся специально для голосовых вызовов и SMS. Например, реализации устройств, которые не могут размещать вызовы или отправлять/получать SMS -сообщения, не считаются устройством для телефона, независимо от того, используют ли они сотовую сеть для подключения к данным.Смотрите ревизию
Если реализации устройств включают в себя поддержку 802.11 и предоставят функциональность сторонним приложению, они:
- [C-1-4] должен поддерживать многоадресную DNS (MDNS) и не должен фильтровать пакеты MDNS (224.0.0.251 или ff02 :: fb ) в любое время работы, включая , когда экран не находится в активном состоянии, если не сбросить или Фильтрация этих пакетов необходимо для того, чтобы оставаться в пределах диапазонов энергопотребления, требуемых регулирующими требованиями, применимыми к целевому рынку.
Для реализаций устройств Android Television, даже когда в режиме ожидания в режиме ожидания.
- [C-1-4] должен поддерживать многоадресную DNS (MDNS) и не должен фильтровать пакеты MDNS (224.0.0.251 или ff02 :: fb ) в любое время работы, включая , когда экран не находится в активном состоянии, если не сбросить или Фильтрация этих пакетов необходимо для того, чтобы оставаться в пределах диапазонов энергопотребления, требуемых регулирующими требованиями, применимыми к целевому рынку.
Смотрите ревизию
Если реализации устройства объявляют face_bluetooth_le, они:
- [C-SR-2] настоятельно рекомендуется измерить и компенсировать смещение RX, чтобы убедиться, что средний RSSI составляет -60 дБм +/- 10 дБ на расстоянии 1M от опорного устройства, передающегося на
ADVERTISE_TX_POWER_HIGH
, где устройства ориентированы так, чтобы они были На «параллельных плоскостях» с экранами, обращенными к тому же направлению. - [C-SR-3] настоятельно рекомендуется измерить и компенсировать смещение TX, чтобы убедиться, что средний RSSI составляет -60 дБМ +/- 10 дБ при сканировании с контрольного устройства, расположенного на расстоянии 1M и передачи на
ADVERTISE_TX_POWER_HIGH
, где устройства ориентированы так, что они находятся на «параллельных плоскостях» с экранами, стоящими в одном и том же направлении.
- [C-10-3] должен измерить и компенсировать смещение RX, чтобы обеспечить среднее значение RSSI -555DBM +/- 10 дБ на расстоянии 1M от опорного устройства, передающегося по адресу
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] должен измерить и компенсировать смещение TX, чтобы обеспечить среднее количество RSSI -55DBM +/- 10 дБ при сканировании с контрольного устройства, расположенного на расстоянии 1M, и передачи на
ADVERTISE_TX_POWER_HIGH
.
Если реализации устройства поддерживают Bluetooth версию 5.0, то они:
- [C-SR-4] настоятельно рекомендуется оказать поддержку:
- ЛЕ 2М ФИЗ
- Le Codec Phy
- Рекламное расширение LE
- Периодическая реклама
- Не менее 10 наборов рекламы
- По крайней мере 8 LE -параллельных соединений. Каждое соединение может быть в любом подключении топологии.
- Конфиденциальность уровня связи LE
- Размер «разрешения списка» не менее 8 записей
- [C-SR-2] настоятельно рекомендуется измерить и компенсировать смещение RX, чтобы убедиться, что средний RSSI составляет -60 дБм +/- 10 дБ на расстоянии 1M от опорного устройства, передающегося на
Смотрите ревизию
- [C-1-7] должен убедиться, что медиана измерений расстояния в 1 м от опорного устройства находилась в пределах [0,75 м, 1,25 м], где расстояние заземления истины измеряется с верхнего края DUT.
Поддерживался лицом вверх и наклонила 45 градусов.
- [C-1-7] должен убедиться, что медиана измерений расстояния в 1 м от опорного устройства находилась в пределах [0,75 м, 1,25 м], где расстояние заземления истины измеряется с верхнего края DUT.
7.5.1. Камера с задней частью :
Смотрите ревизию
Задняя камера-это камера, расположенная на боковой стороне устройства напротив дисплея; То есть он изображает сцены на дальней стороне устройства, как традиционная камера.
Задняя камера-это мировая камера, которая изображает сцены на дальней стороне устройства, как традиционная камера; На портативных устройствах, то есть камера, расположенная на стороне устройства напротив дисплея.
Смотрите ревизию
Фронтальная камера-это камера, расположенная на той же стороне устройства, что и дисплей; То есть камера обычно используется для изображения пользователя, например, для видеоконференций и аналогичных приложений.
Фронтальная камера-это камера с пользователем, которая обычно используется для изображения пользователя, например, для видеоконференций и аналогичных приложений; На портативных устройствах, то есть камера, расположенная на той же стороне устройства, что и дисплей.
Смотрите ревизию
Внешняя камера - это камера, которая может быть физически прикреплена или отделена от реализации устройства в любое время и может столкнуться с любым направлением; такие как USB -камеры.
Смотрите ревизию
Реализации устройств должны реализовать следующее поведение для API-интерфейсов, связанных с камерой, для всех доступных камер. Реализации устройства:
- [C-SR-1] Для устройств с несколькими камерами RGB в непосредственной близости и обращенной в одном и том же направлении настоятельно рекомендуется поддерживать логическое устройство камеры, которое перечисляет возможности
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, состоящие из всех камер RGB Facing, что направление как физические подразделения.
- [C-SR-1] Для устройств с несколькими камерами RGB в непосредственной близости и обращенной в одном и том же направлении настоятельно рекомендуется поддерживать логическое устройство камеры, которое перечисляет возможности
Смотрите ревизию
Устройства, которые выполняют все следующие критерии, освобождаются от приведенного выше требования:
- Реализации устройств, которые не способны быть вращающимися пользователем, таким как автомобильные устройства.
Смотрите ревизию
Устройства, предназначенные для ручной или изношенной, могут включать в себя тактичный привод общего назначения, доступный для приложений для целей, включая привлечение внимания с помощью рингтонов, сигналов тревоги, уведомлений, а также общей обратной связи.
Если реализации устройств не включают такой гаптический привод общего назначения, они:
- [7.10/c] должен вернуть false для
Vibrator.hasVibrator()
.
Если реализации устройств включают хотя бы один такой тактичный привод общего назначения, они: они:
- [C-1-1] должен вернуть true для
Vibrator.hasVibrator()
. - Не должен использовать эксцентричную вращающуюся массу (ERM) тактичный привод (вибратор).
- Следует реализовать все публичные константы для четкой гаптики в
android.view.HapticFeedbackConstants
, а именно (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
иGESTURE_END
). - Должен реализовать все публичные константы для четкой гаптики в
android.os.VibrationEffect
android.os.VibrationEffect.Composition
аCLICK
(EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
иEFFECT_DOUBLE_CLICK
TICK
и все возможныеLOW_TICK
PRIMITIVE_*
QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Некоторые из этих примитивов, такие какLOW_TICK
иSPIN
могут быть возможными, только если вибратор может поддерживать относительно низкие частоты. - Следует следовать руководству для картирования публичных константов в
android.view.HapticFeedbackConstants
к рекомендуемым константамandroid.os.VibrationEffect
с соответствующими отношениями амплитуды. - Следует использовать эти связанные отображения HAPTIC Constants.
- Следует следовать оценке качества для APIS
createOneShot()
иcreateWaveform()
. - Следует убедиться, что результат публичного API
android.os.Vibrator.hasAmplitudeControl()
правильно отражает возможности их вибратора. - Следует проверить возможности для масштабируемости амплитуды с помощью
android.os.Vibrator.hasAmplitudeControl()
.
Если реализации устройства следуют за картированием такси, они:
- SHOULD verify the implementation status by running
android.os.Vibrator.areAllEffectsSupported()
andandroid.os.Vibrator.arePrimitivesSupported()
APIs. - SHOULD perform a quality assessment for haptic constants.
- SHOULD verify and update if needed the fallback configuration for unsupported primitives as described in the implementation guidance for constants.
- SHOULD provide fallback support to mitigate the risk of failure as described here .
See Section 2.2.1 for device-specific requirements.
- [7.10/c] должен вернуть false для
9. Security Model Compatibility
See revision
Device implementations:
- [C-0-4] MUST have one and only one implementation of both user interfaces.
If device implementations pre-install any packages that hold any of the System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence roles, the packages:
- [C-4-1] MUST fulfill all requirements outlined for device implementations in sections
"9.8.6 Content Capture""9.8.6 OS-level and ambient data and 9.8.15 Sandboxed API implementations".
- [C-4-2] MUST NOT have android.permission.INTERNET permission. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
- [C-4-3] MUST NOT bind to other apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
If device implementations include a default application to support the
VoiceInteractionService
they:- [C-5-1] MUST NOT grant
ACCESS_FINE_LOCATION
as the default for that application.
See revision
If device implementations create the additional user profile discussed above, then they:
- [C-4-5] MUST visually distinguish the dual instance application icons when the icons are presented to users.
- [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
- [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
- SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
- [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
- [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.
[C-4-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
-
Intent.ACTION_VIEW
-
Intent.ACTION_SENDTO
-
Intent.ACTION_SEND
-
Intent.ACTION_EDIT
-
Intent.ACTION_INSERT
-
Intent.ACTION_INSERT_OR_EDIT
-
Intent.ACTION_SEND_MULTIPLE
-
Intent.ACTION_PICK
-
Intent.ACTION_GET_CONTENT
-
MediaStore.ACTION_IMAGE_CAPTURE
-
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile
- [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.
See revision
A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the
android:memtagMode
manifest option:- heap buffer overflow
- use after free
- double free
- wild free (free of a non-malloc pointer)
Device implementations:
- [C-SR-15] Are STRONGLY RECOMMENDED to set
ro.arm64.memtag.bootctl_supported
.
If device implementations set the system property
ro.arm64.memtag.bootctl_supported
to true, they:[C-3-1] MUST allow the system property
arm64.memtag.bootctl
to accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:-
memtag
: a Memory Safety technology as defined above is enabled -
memtag-once
: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot -
memtag-off
: a Memory Safety technology as defined above is disabled
-
[C-3-2] MUST allow the shell user to set
arm64.memtag.bootctl
.[C-3-3] MUST allow any process to read
arm64.memtag.bootctl
.[C-3-4] MUST set
arm64.memtag.bootctl
to the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.[C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol .
- [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable
memtag
.
See revision
Device implementations:
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
, or proprietary APIs.MUST NOT provide users an affordance to disable future display of the user consent.
[C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user's screen is captured.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()
with theandroid.app.role.COMPANION_DEVICE_APP_STREAMING
or theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
device profile.
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
, supports a mechanism for device implementations to capture the followingContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillService
to the system. - Any screen or other data accessible via
Content Capture
API. - Any screen or other data accessible via
FieldClassificationService
API - Any application data passed to the system via the
AppSearchManager
API and accessible viaAppSearchGlobalManager.query
.
- Any other events that an application provides to the system via the
Content Capture
API or orAppSearchManager
API a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()
by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord
,SoundTrigger
or other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such asRAPPOR
).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is общий. Unless such functionality is built as an Android SDK API (AmbientContext
,HotwordDetectionService
).[C-1-6] MUST provide user affordance to erase such data that the
implementation or the proprietary means collectsContentCaptureService
ifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()
provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephony
feature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONY
MUST contain at least the following information:-
SubscriptionManagerService
dump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. Разрешение .
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORD
as an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager
, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANT
role. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionService
and/orVisualQueryDetectionService
Android APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::query
API provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATS
permission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Device implementations:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Device implementations:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
Если реализации устройств имеют безопасный экран блокировки и включают один или несколько доверительных агентов, который реализует API системы
TrustAgentService
System, они: они:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of беспокойство.If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachine
package. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. Проверка ДОЛЖНА выполняться внутри виртуальной машины. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the