Андроид 14
26 июня 2024 г.
2. Типы устройств
2.2.1. Аппаратное обеспечение :
См. редакцию
- [7.6.1/H-1-1] ДОЛЖЕН поддерживать только один ABI (только 64-битный или только 32-битный).
См. редакцию
Начать новые требования
Если реализации портативных устройств включают поддержку Vulkan, они:
- [ 7.1.4.2/H-1-1 ] ДОЛЖЕН соответствовать требованиям, указанным в профиле Android Baseline 2021 .
2.4.1. Аппаратное обеспечение :
См. редакцию
Начать новые требования
Если реализации устройств Watch включают поддержку Vulkan, они:
- [ 7.1.4.2/W-1-1 ] ДОЛЖЕН соответствовать требованиям, указанным в профиле Android Baseline 2021 .
2.5.1. Аппаратное обеспечение :
См. редакцию
Начать новые требования
Если реализации автомобильных устройств включают поддержку Vulkan, они:
- [ 7.1.4.2/A-1-1 ] ДОЛЖЕН соответствовать требованиям, указанным в профиле Android Baseline 2021 .
3. Программное обеспечение
Для параметра ODM_SKU:
См. редакцию
Значение этого поля ДОЛЖНО быть закодировано как 7-битный ASCII и соответствовать регулярному выражению
^([0-9A-Za-z.,_-]+)$
.
5. Мультимедийная совместимость
5.1.3. Подробности об аудиокодеках :
Добавлена информация о формате/кодеке Vorbis:
См. редакцию
Декодирование: поддержка моно-, стерео-контента, контента 5.0 и 5.1 с частотой дискретизации 8000, 12000, 16000, 24000 и 48000 Гц.
Кодирование: поддержка моно- и стереоконтента с частотой дискретизации 8000, 12000, 16000, 24000 и 48000 Гц.
7. Совместимость оборудования
См. редакцию
- [C-1-13] ДОЛЖЕН соответствовать требованиям, указанным в профиле Android Baseline 2021 .
7.7.1. Периферийный режим USB :
Удаление:
См. редакцию
- НЕ СЛЕДУЕТ реализовывать звук AOAv2, описанный в документации Android Open Accessory Protocol 2.0. Звук AOAv2 устарел, начиная с версии Android 8.0 (уровень API 26).
9. Совместимость моделей безопасности
Нумерация [C-SR-1] изменена на [C-SR-7] для удаления повторяющегося контента, а также удален [C-SR-8]:
См. редакцию
[C-SR-1] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ сохранять данные ядра, которые записываются только во время инициализации, помеченными как доступные только для чтения после инициализации (например,
__ro_after_init
).[C-SR-2] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ рандомизировать структуру кода ядра и памяти и избегать воздействия, которые могут поставить под угрозу рандомизацию (например,
CONFIG_RANDOMIZE_BASE
с энтропией загрузчика через/chosen/kaslr-seed Device Tree node
илиEFI_RNG_PROTOCOL
) .[C-SR-3] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ включить целостность потока управления (CFI) в ядре, чтобы обеспечить дополнительную защиту от атак повторного использования кода (например,
CONFIG_CFI_CLANG
иCONFIG_SHADOW_CALL_STACK
).[C-SR-4] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ не отключать целостность потока управления (CFI), стек теневых вызовов (SCS) или очистку целочисленного переполнения (IntSan) на компонентах, у которых она включена.
[C-SR-5] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ включить CFI, SCS и IntSan для любых дополнительных компонентов пользовательского пространства, чувствительных к безопасности, как описано в CFI и IntSan .
[C-SR-6] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ включить инициализацию стека в ядре, чтобы предотвратить использование неинициализированных локальных переменных (
CONFIG_INIT_STACK_ALL
илиCONFIG_INIT_STACK_ALL_ZERO
). Кроме того, реализации устройств НЕ ДОЛЖНЫ предполагать значение, используемое компилятором для инициализации локальных переменных.[C-SR-7] НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ включить инициализацию кучи в ядре, чтобы предотвратить использование неинициализированных выделений кучи (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
), и они НЕ ДОЛЖНЫ принимать значение, используемое ядром для инициализации этих выделений.
9.11. Ключи и учетные данные :
См. редакцию
- [C-1-6] ДОЛЖЕН поддерживать одно из следующих действий:
- IKeymasterDevice 3.0,
- IKeymasterDevice 4.0,
- IKeymasterDevice 4.1,
- IKeyMintDevice версии 1 или
- IKeyMintDevice версии 2.
- [C-1-6] ДОЛЖЕН поддерживать одно из следующих действий:
9.11.1. Экран безопасной блокировки, аутентификация и виртуальные устройства :
См. редакцию
- [C-8-3] Они НЕ ДОЛЖНЫ предоставлять API для использования сторонними приложениями для изменения состояния блокировки.
См. редакцию
- [C-12-4] ДОЛЖЕН вызвать
TrustManagerService.revokeTrust()
- Максимум через 24 часа с момента предоставления доверия или
- После 8-часового простоя или
- Если реализации не используют криптографически безопасное и точное определение диапазона, как определено в [C-12-5], базовое соединение с ближайшим физическим устройством потеряно.
- [C-12-5] Реализации, полагающиеся на безопасное и точное определение дальности для удовлетворения требований [C-12-4], ДОЛЖНЫ использовать одно из следующих решений:
- Реализации с использованием UWB:
- ДОЛЖЕН соответствовать требованиям соответствия, сертификации, точности и калибровки для СШП, описанным в 7.4.9 .
- ДОЛЖЕН использовать один из режимов безопасности P-STS, перечисленных в 7.4.9 .
- Реализации с использованием сети Wi-Fi Neighborhood Awareness Network (NAN):
- ДОЛЖЕН соответствовать требованиям точности в 2.2.1 [7.4.2.5/H-SR-1], использовать полосу пропускания 160 МГц (или выше) и следовать шагам настройки измерения, указанным в разделе «Калибровка присутствия» .
- ДОЛЖЕН использовать Secure LTF, как определено в IEEE 802.11az .
- Реализации с использованием UWB:
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, чтобы гарантировать, что медианное значение BLE RSSI составляет -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, , 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] должны поддерживать расширения
Bokeh &Night Mode через расширения как 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 NIT в среднем.
- [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] должен обеспечить параллельную последовательную производительность чтения и записи с 2-кратным чтением и 1x производительность записи не менее 50 МБ/с.
Смотрите ревизию
Реализации телевизионных устройств должны поддерживать следующие форматы кодирования видео и сделать их доступными для сторонних приложений:
- [ 5.2 /T-0-3] AV1
Реализации телевизионных устройств должны поддерживать следующие форматы декодирования видео и сделать их доступными для сторонних приложений:
- [ 5.3.2 /T-0-7] AV1
Смотрите ревизию
Если реализации устройств имеют безопасный экран блокировки и включают один или несколько доверительных агентов, который реализует API системы TrustAgentService
System, они: они:
- [ 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 Automotive Densor Exes.
- [7.5/A-SR-3] настоятельно рекомендуется иметь аппаратное обеспечение либо фиксированного фокуса, либо EDOF (расширенная глубина поле).
- [7.5/A-1-2] должна иметь первичную мировую камеру в качестве мировой камеры с самым низким идентификатором камеры.
Если реализации автомобильных устройств включают в себя хотя бы одну камеру, которая наступает пользователем, для такой камеры:
- [7.5/A-2-1] Основная пользовательская камера должна быть камерой, ориентированной на пользователь с самым низким идентификатором камеры.
- Может быть ориентирован так, чтобы длинное измерение камеры выровнялось с плоскостью XY автомобильных датчиков Android.
Если реализации автомобильных устройств включают камеру, которая доступна через android.hardware.Camera
или android.hardware.camera2
API, то они: они:
- [7.5/A-3-1] должен соответствовать требованиям основной камеры в разделе 7.5.
Если реализации автомобильных устройств включают камеру, которая недоступна через android.hardware.Camera
или android.hardware.camera2
API, то они: они:
- [7.5/A-4-1] должен быть доступен через службу расширенного представления.
Если реализации автомобильных устройств включают одну или несколько камер, доступных через системную службу расширенного представления, для такой камеры они: они:
- [7.5/A-5-1] не должны вращаться или горизонтально отражать предварительный просмотр камеры.
- [7.5/A-SR-4] настоятельно рекомендуется иметь разрешение не менее 1,3 мегапикселя.
Если реализации автомобильных устройств включают одну или несколько камер, которые доступны как через расширенное представление System Service и android.hardware.Camera
или android.hardware.Camera2
API, тогда для такой камеры они: они:
- [7.5/A-6-1] должен сообщать об одном идентификаторе камеры.
Если реализации автомобильных устройств обеспечивают проприетарную камеру API, они: они:
- [7.5/A-7-1] должен реализовать такой API камеры с использованием API API
android.hardware.camera2
или API Extended View System.
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
,VK_KHR_swapchain
,VK_KHR_maintenance1
, и VK_KHR_GIGESICAL_DEVOPOPOPOPOPOPORPOPOPORES2 иVK_KHR_get_physical_device_properties2
иlibvulkan.so
. Обратите внимание, что, хотя все символы должны присутствовать, раздел 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. Переключение деятельности :
Смотрите ревизию
Если реализации устройств, включая навигационную навигационную ключ функции RECENT, как подробно описано в разделе 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 (.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, только декодировать)
VP8 См. Раздел 5.2 и 5.3 для получения подробной информации - Webm (.webm)
- Матроска (.mkv)
VP9 Подробнее см. Раздел 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 х 720 пикселей 1920 х 1080 пикселей 3840 х 2160 пикселей Частота кадров видео 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 х 720 пикселей 1920 х 1080 пикселей 3840 х 2160 пикселей Частота кадров видео 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 включает в себя средства, которые автоматически регулируют активы приложений и соответствующие макеты пользовательского интерфейса для устройства, чтобы гарантировать, что сторонние приложения хорошо работают в
различных аппаратных конфигурациях .Разнообразие аппаратных дисплеев и конфигураций. Андоид-совместимый дисплей-это экран дисплея, который реализует все поведения и 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] MUST provide a user affordance to allow the user to toggle the UWB radio on/off state.
- [C-1-5] MUST enforce that apps using UWB radio hold the
UWB_RANGING
permission (under theNEARBY_DEVICES
permission group).
Passing the relevant conformance and certification tests defined by standard organizations, including FIRA , CCC and CSA helps ensure 802.1.15.4 functions correctly.
- [C-1-2] должен сообщить об аппаратном флаге
See revision
“Telephony” as used by the Android APIs and this document refers specifically to hardware related to placing voice calls and sending SMS messages , or establishing mobile data via a mobile (eg GSM, CDMA, LTE, NR)GSM or CDMA network. A device supporting “Telephony” may choose to offer some or all of the call, messaging and data services as fits the product.
via a GSM or CDMA network. While these voice calls may or may not be packet-switched,they are for the purposes of Android considered independent of any data connectivity that may be implemented using the same network. In other words,the Android “telephony” functionality and APIs refer specifically to voice calls and SMS. For instance, device implementations that cannot place calls or send/receive SMS messages are not considered a telephony device, regardless of whether they use a cellular network for data connectivity.See revision
If device implementations include support for 802.11 and expose the functionality to a third-party application, they:
- [C-1-4] MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets (224.0.0.251 or ff02::fb ) at any time of operation, including when the screen is not in an active state, unless dropping or filtering these packets is necessary to stay within power consumption ranges required by regulatory requirements applicable to the target market.
For Android Television device implementations, even when in standby power states.
- [C-1-4] MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets (224.0.0.251 or ff02::fb ) at any time of operation, including when the screen is not in an active state, unless dropping or filtering these packets is necessary to stay within power consumption ranges required by regulatory requirements applicable to the target market.
See revision
If device implementations declare FEATURE_BLUETOOTH_LE, they:
- [C-SR-2] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at
ADVERTISE_TX_POWER_HIGH
, where devices are oriented such that they are on 'parallel planes' with screens facing the same direction. - [C-SR-3] Are STRONGLY RECOMMENDED to measure and compensate for Tx offset to ensure the median BLE RSSI is -60dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at
ADVERTISE_TX_POWER_HIGH
, where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.
- [C-10-3] MUST measure and compensate for Rx offset to ensure the median BLE RSSI is -55dBm +/-10 dB at 1m distance from a reference device transmitting at
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] MUST measure and compensate for Tx offset to ensure the median BLE RSSI is -55dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at
ADVERTISE_TX_POWER_HIGH
.
If device implementations support Bluetooth version 5.0, then they:
- [C-SR-4] Are STRONGLY RECOMMENDED to provide support for:
- LE 2M PHY
- LE Codec PHY
- LE Advertising Extension
- Periodic advertising
- At least 10 advertisement sets
- At least 8 LE concurrent connections. Each connection can be in either connection topology roles.
- LE Link Layer Privacy
- A "resolving list" size of at least 8 entries
- [C-SR-2] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at
See revision
- [C-1-7] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT.
held face up and tilted 45 degrees.
- [C-1-7] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT.
See revision
A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera.
A rear-facing camera is a world-facing camera that images scenes on the far side of the device, like a traditional camera; on handheld devices, that is a camera located on the side of the device opposite the display.
See revision
A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.
A front-facing camera is a user-facing camera that is typically used to image the user, such as for video conferencing and similar applications; on handheld devices, that is a camera located on the same side of the device as the display.
See revision
An external camera is a camera that can be physically attached or detached from the device implementation at any time and can face any direction; such as USB cameras.
See revision
Device implementations MUST implement the following behaviors for the camera-related APIs, for all available cameras. Device implementations:
- [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, consisting of all of the RGB cameras facing that direction as physical sub-devices.
- [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability
See revision
Devices that fulfill all of the following criteria are exempt from the requirement above:
- Device implementations that are not capable of being rotated by the user such as automotive devices.
See revision
Devices intended to be hand-held or worn may include a general purpose haptic actuator, available to applications for purposes including getting attention through ringtones, alarms, notifications, as well as general touch feedback.
If device implementations DO NOT include such a general purpose haptic actuator, they:
- [7.10/C] MUST return false for
Vibrator.hasVibrator()
.
If device implementations DO include at least one such general purpose haptic actuator, they:
- [C-1-1] MUST return true for
Vibrator.hasVibrator()
. - SHOULD NOT use an eccentric rotating mass (ERM) haptic actuator (vibrator).
- SHOULD implement all public constants for clear haptics in
android.view.HapticFeedbackConstants
namely (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
andGESTURE_END
). - SHOULD implement all public constants for clear haptics in
android.os.VibrationEffect
namely (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
andEFFECT_DOUBLE_CLICK
) and all feasible publicPRIMITIVE_*
constants for rich haptics inandroid.os.VibrationEffect.Composition
namely (CLICK
,TICK
,LOW_TICK
,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Some of these primitives, such asLOW_TICK
andSPIN
may only be feasible if the vibrator can support relatively low frequencies. - SHOULD follow the guidance for mapping public constants in
android.view.HapticFeedbackConstants
to the recommendedandroid.os.VibrationEffect
constants, with the corresponding amplitude relationships. - SHOULD use these linked haptic constants mappings .
- SHOULD follow quality assessment for
createOneShot()
andcreateWaveform()
APIs. - SHOULD verify that the result of the public
android.os.Vibrator.hasAmplitudeControl()
API correctly reflects their vibrator's capabilities. - SHOULD verify the capabilities for amplitude scalability by running
android.os.Vibrator.hasAmplitudeControl()
.
If device implementations follow the haptic constants mapping, they:
- 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] MUST return false for
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.
If device implementations have a secure lock screen and include one or more trust agent, which implements the
TrustAgentService
System API, they:[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. The verification MUST be done inside the VM. - [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