Поддержка версий камеры

На этой странице описаны различия между версиями Camera HAL, API и связанных с ними тестов Compatibility Test Suite (CTS). Также в нем рассматриваются архитектурные изменения, внесенные для повышения надежности и безопасности фреймворка камеры в Android 7.0, переход на Treble в Android 8.0 и обновления, которые поставщики должны внести для поддержки этих изменений в своих реализациях камеры.

Терминология

На этой странице используются следующие термины:

Camera API1

Фреймворк камеры на уровне приложения на устройствах с Android 4.4 и более ранними версиями, доступный через класс android.hardware.Camera.

Camera API2

Фреймворк камеры на уровне приложения на устройствах с Android 5.0 и более поздних версий, доступный через пакет android.hardware.camera2.

Аппаратно-зависимый уровень камеры

Уровень модуля камеры, реализованный поставщиками однокристальных систем. Общедоступные фреймворки на уровне приложений созданы на основе HAL камеры.

Camera HAL3.1

Версия HAL устройства камеры, выпущенная с Android 4.4.

Camera HAL3.2

Версия HAL камеры, выпущенная вместе с Android 5.0.

Camera API1 CTS

Набор тестов CTS для камеры, которые выполняются поверх Camera API1.

Camera API2 CTS

Дополнительный набор тестов CTS для камеры, которые выполняются поверх Camera API2.

Высокие частоты

Отделяет реализацию поставщика (низкоуровневое ПО, написанное производителями микросхем для конкретных устройств) от фреймворка ОС Android с помощью нового интерфейса поставщика.

HIDL

Язык определения интерфейса HAL, представленный в Treble и используемый для определения интерфейса между HAL и его пользователями.

VTS

Набор тестов поставщика, представленный вместе с Treble.

API камеры

В Android есть следующие API камеры:

Camera API1

В Android 5.0 устарел Camera API1, который продолжает выводиться из эксплуатации, поскольку разработка новых платформ сосредоточена на Camera API2. Однако период поэтапного отказа будет длительным, и выпуски Android будут поддерживать приложения Camera API1 в течение некоторого времени. В частности, поддержка продолжается для:

• Интерфейсы Camera API1 для приложений. Приложения камеры, созданные на основе Camera API1, должны работать так же, как и на устройствах с более ранними версиями Android.
• Версии HAL камеры. Поддерживается Camera HAL1.0.

Camera API2

API камеры 2 предоставляет приложению доступ к низкоуровневым функциям управления камерой, в том числе к эффективным потокам серийной съемки и потоковой передачи без копирования, а также к управлению экспозицией, усилением, балансом белого, преобразованием цвета, шумоподавлением, повышением резкости и другими параметрами для каждого кадра. Подробную информацию можно найти в видеообзоре Google I/O.

В Android 5.0 и более поздних версиях есть Camera API2, однако устройства с этими версиями ОС могут поддерживать не все функции Camera API2. Свойство android.info.supportedHardwareLevel, которое приложения могут запрашивать через интерфейсы Camera API2, сообщает об одном из следующих уровней поддержки:

• LEGACY: эти устройства предоставляют приложениям доступ к функциям через интерфейсы Camera API2, которые примерно соответствуют функциям, доступным через интерфейсы Camera API1. Устаревшие фреймворки концептуально преобразуют вызовы Camera API2 в вызовы Camera API1. Устаревшие устройства не поддерживают функции Camera API2, такие как управление каждым кадром.
• LIMITED – устройства, которые поддерживают некоторые возможности Camera API2 (но не все) и должны использовать Camera HAL 3.2 или более поздней версии.
• FULL – устройства, поддерживающие все основные возможности Camera API2 и использующие Camera HAL 3.2 или более поздней версии и Android 5.0 или более поздней версии.
• LEVEL_3: эти устройства поддерживают повторную обработку YUV и съемку изображений в формате RAW, а также дополнительные конфигурации выходного потока.
• EXTERNAL – устройства, похожие на устройства LIMITED, но с некоторыми исключениями. Например, они могут не передавать информацию о датчиках или объективах или иметь менее стабильную частоту кадров. Этот уровень используется для внешних камер, например USB-камер.

Отдельные возможности доступны через свойство android.request.availableCapabilities в интерфейсах Camera API2. Устройства FULL должны поддерживать, в частности, функции MANUAL_SENSOR и MANUAL_POST_PROCESSING. Функция RAW не является обязательной даже для устройств FULL. LIMITED может рекламировать любые из этих функций, в том числе ни одной. Однако возможность BACKWARD_COMPATIBLE должна быть определена всегда.

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

• android.hardware.camera.hardware_level.full
• android.hardware.camera.capability.raw
• android.hardware.camera.capability.manual_sensor
• android.hardware.camera.capability.manual_post_processing

Требования CTS

Устройства с Android 5.0 и более поздних версий должны пройти тесты CTS для Camera API1, Camera API2 и CTS Verifier.

Устройства, в которых не реализован аппаратно-зависимый уровень камеры 3.2 и которые не поддерживают все интерфейсы Camera API2, должны пройти тесты CTS для Camera API2. Однако устройство работает в режиме Camera API2 LEGACY (в котором вызовы Camera API2 концептуально сопоставляются с вызовами Camera API1), поэтому все CTS-тесты Camera API2, связанные с функциями или возможностями, выходящими за рамки Camera API1, автоматически пропускаются.

На устаревших устройствах тесты CTS для Camera API2 выполняются с использованием существующих общедоступных интерфейсов и возможностей Camera API1 без новых требований. Ошибки, которые выявляются (и приводят к сбою CTS Camera API2), уже присутствуют в существующем HAL камеры устройства и, следовательно, будут обнаружены существующими приложениями Camera API1. Мы не ожидаем большого количества ошибок такого рода (однако любые подобные ошибки должны быть исправлены, чтобы пройти тесты CTS для Camera API2).

Требования к VTS

Устройства с Android 8.0 и более поздних версий, на которых реализован HAL с привязкой, должны пройти VTS-тесты камеры.

Усиление защиты фреймворка камеры

Чтобы повысить безопасность медиа и камеры, в Android 7.0 сервис камеры был вынесен из mediaserver. Начиная с Android 8.0 каждый HAL камеры с интерфейсом Binder работает в процессе, отдельном от сервиса камеры. В зависимости от используемых версий API и HAL поставщикам может потребоваться внести изменения в камеру HAL. В следующих разделах описаны архитектурные изменения в AP1 и AP2 для HAL1 и HAL3, а также общие требования.

Архитектурные изменения для API1

При записи видео с помощью API1 предполагается, что камера и видеокодер работают в одном процессе. При использовании API1 на:

• В HAL3, где сервис камеры использует BufferQueue для передачи буферов между процессами, обновление поставщика не требуется.

  

  Рисунок 1. Камера и медиастек Android 7.0 в API1 на HAL3

• HAL1, который поддерживает передачу метаданных в видеобуферах, поставщики должны обновить HAL, чтобы использовать kMetadataBufferTypeNativeHandleSource. (kMetadataBufferTypeCameraSource больше не поддерживается в Android 7.0.)

  

  Рисунок 2. Стек камеры и мультимедиа Android 7.0 в API1 на HAL1

Изменения в архитектуре API2

Для API2 на HAL1 или HAL3 BufferQueue передает буферы, поэтому эти пути продолжают работать. Архитектура Android 7.0 для API2 на следующих устройствах:

• Перенос cameraservice не влияет на HAL1, поэтому обновление поставщика не требуется.
• HAL3 затронут, но обновление поставщика не требуется:

  

  Рисунок 3. Камера и медиастек Android 7.0 в API2 на HAL3

Дополнительные требования

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

• Общие положения. Устройствам требуется дополнительная пропускная способность из-за IPC, что может повлиять на варианты использования камеры, требующие быстрого реагирования, например при высокоскоростной видеозаписи. Поставщики могут измерить фактическое влияние, запустив android.hardware.camera2.cts.PerformanceTest и приложение "Google Камера" для высокоскоростной видеозаписи с частотой 120/240 кадров в секунду. Устройствам также требуется небольшой объем дополнительной оперативной памяти для создания нового процесса.
• Передача метаданных в буферах видео (только HAL1). Если HAL1 хранит в видеобуферах метаданные, а не реальные данные кадра YUV, HAL должен использовать kMetadataBufferTypeNativeHandleSource в качестве типа буфера метаданных и передавать VideoNativeHandleMetadata в видеобуферах. (kMetadataBufferTypeCameraSource больше не поддерживается на Android 7.0). С помощью VideoNativeHandleMetadata фреймворки камеры и мультимедиа могут передавать видео буферы между процессами, правильно сериализуя и десериализуя собственные дескрипторы.
• Адрес дескриптора буфера не всегда хранит один и тот же буфер (только HAL3). Для каждого запроса на захват HAL3 получает адреса дескрипторов буфера. HAL не может использовать адреса для идентификации буферов, поскольку после того, как HAL возвращает буфер, в адресах может храниться другой дескриптор буфера. Вы должны обновить HAL, чтобы использовать дескрипторы буферов для идентификации буферов. Например, HAL получает адрес дескриптора буфера A, в котором хранится дескриптор буфера A. После того как HAL возвращает дескриптор буфера A, адрес дескриптора буфера A может хранить дескриптор буфера B при следующем получении HAL.
• Обновите правила SELinux для cameraserver. Если в SELinux-политиках для устройства медиасерверу предоставлены разрешения на запуск камеры, вам необходимо обновить SELinux-политики, чтобы предоставить камере необходимые разрешения. Мы не рекомендуем копировать правила SELinux mediaserver для cameraserver, поскольку mediaserver и cameraserver обычно требуют разных системных ресурсов. У cameraserver должны быть только разрешения, необходимые для работы камеры. Все ненужные разрешения, связанные с камерой, в mediaserver следует удалить.
• Разделение Camera HAL и cameraserver. В Android 8.0 и более поздних версий HAL камеры с привязкой также отделяется в процессе, отличном от cameraserver. Межпроцессное взаимодействие осуществляется через интерфейсы, определенные в HIDL.

Проверка

Для всех устройств с камерой и ОС Android 7.0 проверьте реализацию, запустив CTS для Android 7.0. В Android 7.0 нет новых тестов CTS, которые проверяют изменения в сервисе камеры, но существующие тесты CTS не будут пройдены, если вы не выполните указанные выше обновления.

Для всех устройств с камерой и Android 8.0 или более поздней версии проверьте реализацию поставщика, запустив VTS.

История версий HAL камеры

Список тестов, доступных для оценки HAL камеры Android, приведен в контрольном списке тестирования HAL камеры.

Android 10

В Android 10 появились следующие изменения:

Camera API

• Улучшения для нескольких камер, позволяющие использовать физические камеры по отдельности или через соответствующие логические камеры, скрывая идентификаторы физических камер. Подробнее о поддержке нескольких камер…
• Возможность проверить, поддерживается ли определенная конфигурация сеанса, без снижения производительности, связанного с созданием нового сеанса. Подробнее: CameraDevice.
• Возможность получать рекомендованные конфигурации потока для определенного варианта использования, чтобы повысить энергоэффективность и производительность клиента. Подробнее: getRecommendedStreamConfigurationMap.
• Поддержка графического формата JPEG для изображений с глубиной. Подробнее о спецификации динамической глубины…
• Поддержка графического формата HEIC. Подробнее о формате HEIF…
• Улучшения в области конфиденциальности. Для получения определенных ключей из CameraCharacteristics клиенту необходимо иметь разрешения CAMERA. Подробнее: getKeysNeedingPermission.

Аппаратно-зависимый уровень камеры

В Android 10 обновлены следующие версии Camera HAL:

3.5

ICameraDevice

• getPhysicalCameraCharacteristics – статическая информация о физической камере, которая поддерживает логическую камеру. Подробнее о поддержке нескольких камер…
• isStreamCombinationSupported: этот метод поддерживает общедоступный API, который помогает клиентам узнать, поддерживается ли конфигурация сеанса. Подробнее о запросах сочетаний потоков с помощью API…

ICameraDeviceSession

• isReconfigurationNeeded: Метод, который сообщает фреймворку камеры, требуется ли полная перенастройка потока для возможных новых значений параметров сеанса. Это позволяет избежать ненужных задержек при перенастройке камеры. Подробнее о запросе на изменение конфигурации сеанса…
• API управления буфером HAL. Эти API позволяют HAL камеры запрашивать буферы у фреймворка камеры только при необходимости, а не связывать каждый запрос на съемку с его буферами на протяжении всего конвейера камеры. Это позволяет значительно сэкономить память.
  • signalStreamFlush – сообщает HAL, что сервис камеры собирается выполнить configureStreams_3_5 и что HAL должен вернуть все буферы назначенных потоков.
  • configureStreams_3_5: аналогично ICameraDevice3.4.configureStreams, но дополнительно предоставляется счетчик streamConfigCounter, чтобы проверить наличие состояния гонки между вызовами configureStreams_3_5 и signalStreamFlush.

Изменения в ICameraDeviceCallback:

• requestStreamBuffers: Синхронный обратный вызов, который аппаратно-зависимый уровень камеры вызывает, чтобы запросить у сервера камеры буферы. Подробнее: requestStreamBuffers.
• returnStreamBuffers: Синхронный обратный вызов для HAL камеры, чтобы вернуть выходные буферы на сервер камеры. Подробнее: returnStreamBuffers.

3.4

В Android 10 в метаданные камеры добавлены следующие ключи:

• Графические форматы
  • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
  • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
  • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
• Теги метаданных камеры
  • ANDROID_REQUEST_CHARACTERISTIC_KEYS_NEEDING_PERMISSION
  • ANDROID_SCALER_AVAILABLE_RECOMMENDED_STREAM_CONFIGURATIONS
  • ANDROID_SCALER_AVAILABLE_RECOMMENDED_INPUT_OUTPUT_FORMATS_MAP
  • ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION
  • ANDROID_DEPTH_AVAILABLE_RECOMMENDED_DEPTH_STREAM_CONFIGURATIONS
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_MIN_FRAME_DURATIONS
  • ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
  • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS
  • ANDROID_HEIC_AVAILABLE_HEIC_MIN_FRAME_DURATIONS
  • ANDROID_HEIC_AVAILABLE_HEIC_STALL_DURATIONS
  • ANDROID_HEIC_INFO_SUPPORTED
  • ANDROID_HEIC_INFO_MAX_JPEG_APP_SEGMENTS_COUNT
• Возможности
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
• Значения для ключа ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
  • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
  • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
• Доступные конфигурации динамического потока глубины
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
• Доступные конфигурации потока HEIC
  • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
  • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Модуль камеры

В Android 10 обновлены следующие версии модуля камеры:

2.5

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

2.4

• Устройства, выпущенные с уровнем API 29 или выше, ДОЛЖНЫ сообщать true для isTorchModeSupported.

Android 9

В Android 9 внесены следующие изменения в Camera API2 и интерфейс HAL:

Camera API

• Представлен API для нескольких камер, который позволяет лучше поддерживать устройства с несколькими камерами, направленными в одну сторону, и использовать такие функции, как эффект боке и плавное масштабирование. Это позволяет приложениям просматривать несколько камер на устройстве как один логический блок (логическую камеру). Запросы на съемку также можно отправлять на отдельные камеры, входящие в состав одной логической камеры. Подробнее о поддержке нескольких камер…
• Параметры сеанса. Параметры сеанса – это подмножество доступных параметров сбора данных, изменение которых может привести к значительным задержкам обработки. Эти расходы можно снизить, если клиенты передают исходные значения при инициализации сеанса захвата. Параметры сеанса
• Добавляет ключи данных оптической стабилизации изображения (OIS) для стабилизации и эффектов на уровне приложения. Подробнее: STATISTICS_OIS_SAMPLES.
• Добавлена поддержка внешней вспышки. Подробнее: CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
• Добавляет намерение отслеживания движения в CAPTURE_INTENT. Подробнее: CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
• Прекращает поддержку LENS_RADIAL_DISTORTION и добавляет вместо него LENS_DISTORTION.
• Добавлены режимы коррекции искажений в CaptureRequest. Подробнее: DISTORTION_CORRECTION_MODE.
• Добавлена поддержка внешних USB-камер и камер UVC на поддерживаемых устройствах. Подробнее: INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

Аппаратно-зависимый уровень камеры

3.4

Изменения в ICameraDeviceSession

• configureStreams_3_4: Добавлена поддержка sessionParameters и логических камер.
• processCaptureRequest_3_4: Добавлена поддержка идентификаторов физических камер в структуре потока.

Изменения в ICameraDeviceCallback

• processCaptureResult_3_4: Добавляет метаданные физической камеры в результаты съемки.

3.3

В Android 9 в метаданные камеры добавлены следующие ключи:

• Возможности
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
• Теги метаданных камеры
  • ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
  • ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE
  • ANDROID_DISTORTION_CORRECTION_AVAILABLE_MODES
  • ANDROID_LENS_POSE_REFERENCE
  • ANDROID_LENS_DISTORTION
  • ANDROID_REQUEST_AVAILABLE_SESSION_KEYS
  • ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS
  • ANDROID_STATISTICS_OIS_DATA_MODE
  • ANDROID_STATISTICS_OIS_TIMESTAMPS
  • ANDROID_STATISTICS_OIS_X_SHIFTS
  • ANDROID_STATISTICS_OIS_Y_SHIFTS

Android 8.0

Проект Treble был представлен в Android 8.0. В Treble реализации HAL камеры от поставщиков должны быть связаны. В Android 8.0 также добавлены следующие улучшения сервиса камеры:

• Общие поверхности: включите несколько поверхностей, использующих один и тот же элемент OutputConfiguration.
• Системный API для пользовательских режимов камеры
• onCaptureQueueEmpty

Подробную информацию об этих функциях можно найти в разделах ниже.

Общие поверхности

Эта функция позволяет использовать один набор буферов для двух выходных потоков, например для предварительного просмотра и кодирования видео, что снижает энергопотребление и расход памяти. Чтобы эта функция работала, производители устройств должны убедиться, что их реализации HAL камеры и HAL gralloc могут создавать буферы gralloc, которые используются несколькими разными потребителями (например, аппаратным композитором/GPU и видеокодировщиком), а не только одним потребителем. Сервис камеры передает флаги использования потребителей в HAL камеры и HAL gralloc. Они должны либо выделить правильные типы буферов, либо HAL камеры должен вернуть ошибку, указывающую на то, что эта комбинация потребителей не поддерживается.

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

Системный API для пользовательских режимов камеры

В общедоступном API камеры определены два режима работы: обычный и высокоскоростная запись с ограничениями. У них довольно разная семантика. Например, в режиме высокой скорости можно использовать не более двух выходов одновременно. Разные производители оригинального оборудования выразили заинтересованность в определении других пользовательских режимов для функций, связанных с оборудованием. Внутри режима используется целое число, которое передается в configure_streams. Подробнее: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams.

Эта функция включает системный вызов API, который OEM-приложения для камеры могут использовать, чтобы включить специальный режим. Эти режимы должны начинаться с целого числа 0x8000, чтобы избежать конфликтов с будущими режимами, добавленными в общедоступный API.

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

Название метода: android.hardware.camera2.CameraDevice#createCustomCaptureSession. Подробнее: frameworks/base/core/java/android/hardware/camera2/CameraDevice.

onCaptureQueueEmpty

Этот API позволяет уменьшить задержку при изменении настроек, например масштаба, за счет того, что очередь запросов будет как можно меньше. onCaptureQueueEmpty не требует работы с HAL, так как это дополнение на стороне фреймворка. Приложения, которые хотят использовать эту функцию, должны добавить прослушиватель для этого обратного вызова и соответствующим образом реагировать на него. Обычно это делается путем отправки камере ещё одного запроса на съемку.

Интерфейс HIDL камеры

Интерфейс Camera HIDL – это полностью переработанный интерфейс Camera HAL, в котором используются стабильные API, определенные HIDL. Все функции и возможности камеры, представленные в последних устаревших версиях 3.4 и 2.4 (для модуля камеры), также включены в определения HIDL.

3.4

Незначительные дополнения к поддерживаемым метаданным и изменения в поддержке data_space:

• Добавьте статические метаданные ANDROID_SENSOR_OPAQUE_RAW_SIZE как обязательные, если поддерживается формат RAW_OPAQUE.
• Добавьте ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE static metadata в качестве обязательного, если поддерживается какой-либо формат RAW.
• Поле camera3_stream_t data_space было изменено на более гибкое определение с использованием определения кодировки пространства данных версии 0.
• Дополнения к общим метаданным, которые можно использовать для HALv3.2 и более поздних версий:
  • ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
  • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
  • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
  • ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
  • ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
  • ANDROID_SENSOR_OPAQUE_RAW_SIZE
  • ANDROID_SENSOR_OPTICAL_BLACK_REGIONS

3.3

Незначительные изменения в HAL с расширенными возможностями:

• Изменения в API для обработки OPAQUE и YUV.
• Базовая поддержка буферов вывода глубины.
• В camera3_stream_t добавлено поле data_space.
• В camera3_stream_t добавлено поле ротации.
• Добавление режима работы конфигурации потока camera3 в camera3_stream_configuration_t.

3.2

Незначительные изменения в HAL с расширенными возможностями:

• Прекращена поддержка функции get_metadata_vendor_tag_ops. Вместо него используйте get_vendor_tag_ops в camera_common.h.
• Прекращена поддержка функции register_stream_buffers. Все буферы gralloc, предоставленные фреймворком HAL в process_capture_request, могут быть новыми в любой момент.
• Добавлена поддержка частичных результатов. process_capture_result может вызываться несколько раз с подмножеством доступных результатов, прежде чем будет доступен полный результат.
• Добавьте шаблон, созданный вручную, в camera3_request_template. Приложения могут использовать этот шаблон для прямого управления настройками захвата.
• Переработать спецификации двунаправленного и входного потоков.
• Измените путь возврата буфера ввода. Буфер возвращается в виде process_capture_result, а не process_capture_request.

3.1

Незначительное изменение HAL с расширенными возможностями:

• configure_streams передает флаги использования потребителем в HAL.
• вызов flush, чтобы как можно быстрее отменить все выполняемые запросы и очистить буферы.

3,0

Первая версия HAL с расширенными возможностями:

• Изменение основной версии, так как ABI полностью отличается. Требования к оборудованию и операционной модели не изменились по сравнению с версией 2.0.
• Переработанные интерфейсы запроса ввода и очереди потоков: фреймворк вызывает HAL с уже извлеченными из очереди следующим запросом и буферами потоков. Поддержка фреймворка синхронизации, необходимого для эффективной реализации.
• Триггеры перенесены в запросы, а большинство уведомлений – в результаты.
• Все обратные вызовы были объединены в одну структуру, а все методы настройки – в один вызов initialize().
• Настройка потока теперь выполняется за один вызов, что упрощает управление потоками. Двунаправленные потоки заменяют конструкцию STREAM_FROM_STREAM.
• Семантика ограниченного режима для устаревших или ограниченных аппаратных устройств.

2.0

Первый выпуск HAL с расширенными возможностями (Android 4.2) [camera2.h]:

• Достаточно для реализации существующего API android.hardware.Camera.
• Позволяет использовать очередь ZSL на уровне сервиса камеры.
• Не тестировалось для новых функций, таких как ручное управление съемкой, съемка в формате Bayer RAW, повторная обработка первичных данных и т. д.

1.0

Первоначальный аппаратно-зависимый уровень камеры Android (Android 4.0) [camera.h]:

• Преобразовано из уровня абстракции CameraHardwareInterface на языке C++.
• Поддерживает API android.hardware.Camera.

История версий модуля камеры

В этом разделе приведена информация об управлении версиями модуля для аппаратного обеспечения камеры на основе camera_module_t.common.module_api_version. Два старших шестнадцатеричных разряда представляют основную версию, а два младших – промежуточную версию.

2,4

В этой версии модуля камер добавлены следующие изменения API:

1. Поддержка режима фонарика. Фреймворк может включить режим фонарика для любого устройства камеры, у которого есть вспышка, не открывая устройство камеры. У устройства камеры более высокий приоритет доступа к вспышке, чем у модуля камеры. Если фонарик был включен через интерфейс модуля, при открытии устройства камеры он выключится. При возникновении конфликтов ресурсов, например при вызове open() для открытия камеры, модуль HAL камеры должен уведомить фреймворк через обратный вызов статуса режима фонарика о том, что режим фонарика отключен.
2. Поддержка внешних камер (например, USB-камер с возможностью горячего подключения). В обновлениях API указано, что статическая информация о камере доступна только тогда, когда камера подключена и готова к использованию для внешних камер с возможностью горячего подключения. Вызовы для получения статической информации недопустимы, если статус камеры не CAMERA_DEVICE_STATUS_PRESENT. Фреймворк полагается исключительно на обратные вызовы изменения статуса устройства для управления списком доступных внешних камер.
3. Подсказки по арбитражу камеры. Добавлена поддержка явного указания количества камер, которые можно одновременно открыть и использовать. Чтобы указать допустимые комбинации устройств, в структуре camera_info, возвращаемой вызовом get_camera_info, всегда должны быть заданы поля resource_cost и conflicting_devices.
4. Метод инициализации модуля. Вызывается сервисом камеры после загрузки модуля HAL, чтобы выполнить однократную инициализацию HAL. Он вызывается до любых других методов модуля.

2.3

В этой версии модуля камеры добавлена поддержка устаревшего устройства HAL камеры. Фреймворк может использовать его, чтобы открыть камеру как устройство HAL более низкой версии, если устройство поддерживает несколько версий API. Стандартный вызов модуля оборудования open(common.methods->open) по-прежнему открывает камеру с последней поддерживаемой версией, которая также указана в camera_info_t.device_version.

2.2

В этой версии модуля камеры добавлена поддержка тегов поставщика и прекращена поддержка старых тегов vendor_tag_query_ops, которые ранее были доступны только при открытом устройстве.

2.1

В этой версии модуля камеры добавлена поддержка асинхронных обратных вызовов фреймворка из модуля HAL камеры, который используется для уведомления фреймворка об изменениях состояния модуля камеры. Модули, в которых есть действительный метод set_callbacks(), должны сообщать хотя бы этот номер версии.

2.0

Модули камер, которые сообщают этот номер версии, реализуют вторую версию интерфейса HAL модуля камеры. Устройства камеры, открываемые через этот модуль, могут поддерживать версию 1.0 или 2.0 интерфейса HAL устройства камеры. Поле device_version в camera_info всегда действительно. Поле static_camera_characteristics в camera_info действительно, если поле device_version имеет значение 2.0 или выше.

1.0

Модули камер, которые сообщают эти номера версий, реализуют исходный интерфейс HAL модуля камер. Все камеры, которые можно открыть с помощью этого модуля, поддерживают только версию 1 HAL камеры. Поля device_version и static_camera_characteristics объекта camera_info недействительны. Этот модуль и его устройства поддерживают только API android.hardware.Camera.