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

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

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

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

API камеры1

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

API камеры2

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

Камера HAL

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

Камера HAL3.1

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

Камера HAL3.2

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

Камера API1 CTS

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

Камера API2 CTS

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

ВЧ

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

HIDL

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

СУДС

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

API камеры

Android включает следующие API камеры.

API камеры1

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

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

API камеры2

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

Android 5.0 и выше включает Camera API2; однако устройства под управлением Android 5.0 и более поздних версий могут не поддерживать все функции 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 и выше должны пройти тесты камеры Camera API1 CTS, Camera API2 CTS и CTS Verifier.

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

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

Требования СУДС

Устройства под управлением Android 8.0 и выше с биндеризованными реализациями HAL должны пройти тесты Camera VTS .

Упрочнение каркаса камеры

Чтобы усилить безопасность инфраструктуры мультимедиа и камеры, Android 7.0 переносит службу камеры с медиасервера. Начиная с Android 8.0, каждый связанный HAL камеры выполняется в процессе, отдельном от службы камеры. Поставщикам может потребоваться внести изменения в HAL камеры в зависимости от используемых версий API и 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 на:

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

  

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

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

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

• Общий. Устройствам требуется дополнительная пропускная способность из-за IPC, что может повлиять на случаи использования чувствительных ко времени камер, таких как высокоскоростная видеозапись. Поставщики могут измерить фактическое воздействие, запустив android.hardware.camera2.cts.PerformanceTest и приложение Google Camera для высокоскоростной записи видео со скоростью 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 медиасервера для cameraserver (поскольку для mediaserver и cameraserver обычно требуются разные ресурсы в системе). Сервер камеры должен иметь только те разрешения, которые необходимы для выполнения функций камеры, а любые ненужные разрешения, связанные с камерой, в медиасервере должны быть удалены.
• Разделение HAL камеры и сервера камеры. В Android 8.0 и более поздних версиях HAL камеры с привязкой дополнительно отделяется в процессе, отличном от процесса cameraserver. IPC проходит через интерфейсы , определенные HIDL .

Проверка

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

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

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

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

Андроид 10

В Android 10 представлены следующие обновления.

API камеры

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

Камера HAL

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

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 : синхронный обратный вызов, который вызывает HAL камеры, чтобы запросить у сервера камеры буферы. См. 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 .

Андроид 9

В выпуске Android 9 представлены следующие обновления API2 камеры и интерфейса HAL.

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 .

Камера HAL

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

Андроид 8.0

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

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

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

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

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

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

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

API общедоступной камеры определяет два режима работы: обычный и высокоскоростной записи с ограничениями. У них довольно разная семантика; например, высокоскоростной режим ограничен не более чем двумя конкретными выходами одновременно. Различные OEM-производители выразили заинтересованность в определении других пользовательских режимов для аппаратных возможностей. Под капотом режим — это просто целое число, переданное в 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 в качестве обязательных, если поддерживается любой формат 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.
• Базовая поддержка буферов вывода глубины.
• Добавление поля data_space в camera3_stream_t .
• Добавление поля вращения в 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.
• Переработаны интерфейсы входных запросов и очередей потоков: Framework вызывает HAL со следующим запросом и буферами потоков, уже исключенными из очереди. Включена поддержка платформы синхронизации, необходимая для эффективной реализации.
• Триггеры перемещены в запросы, большинство уведомлений — в результаты.
• Все обратные вызовы в фреймворке объединены в одну структуру, а все методы настройки — в один вызов initialize() .
• Конфигурация потока объединена в один вызов, чтобы упростить управление потоком. Двунаправленные потоки заменяют конструкцию STREAM_FROM_STREAM .
• Семантика ограниченного режима для старых/ограниченных аппаратных устройств.

2.0

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

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

1,0

Исходная камера Android HAL (Android 4.0) [camera.h]:

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

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

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

2,4

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

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

2.3

В этой версии модуля камеры добавлена ​​открытая устаревшая поддержка устройств HAL камеры. Платформа может использовать его, чтобы открыть устройство камеры как более низкое устройство HAL версии устройства HAL, если одно и то же устройство может поддерживать несколько версий API устройства. Вызов открытия стандартного аппаратного модуля ( 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 .