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

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

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

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

API камеры1
Фреймворк камеры на уровне приложения для устройств Android 4.4 и ниже, доступный через класс android.hardware.Camera .
API2 камеры
Фреймворк камеры на уровне приложения для устройств 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 API Camera API1 был признан устаревшим, и его вывод из эксплуатации продолжается по мере того, как разработка новых платформ сосредотачивается на Camera API2. Однако период поэтапного вывода будет длительным, и приложения, использующие Camera API1, в Android ещё некоторое время будут поддерживаться. В частности, продолжается поддержка следующих приложений:

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

API2 камеры

Фреймворк 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, которые оно поддерживает, доступны в виде следующих флагов функций, позволяющих фильтровать приложения камеры Camera API2 в Google Play.

  • 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), поэтому любые тесты Camera API2 CTS, связанные с функциями или возможностями, выходящими за рамки Camera API1, автоматически пропускаются.

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

Требования VTS

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

Укрепление каркаса камеры

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

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

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

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

    Камера и мультимедиа Android 7.0 стек в API1 на HAL3

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

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

    Камера и мультимедиа Android 7.0 стек в API1 на HAL1

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

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

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

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

    Камера Android 7.0 и медиатек в API2 на 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 для сервера камеры. Если политики SELinux, специфичные для устройства, предоставляют медиасерверу разрешения на запуск камеры, необходимо обновить политики SELinux, чтобы предоставить серверу камеры соответствующие разрешения. Мы не рекомендуем дублировать политики SELinux медиасервера для сервера камеры (поскольку медиасервер и сервер камеры обычно требуют разных ресурсов в системе). Сервер камеры должен иметь только те разрешения, которые необходимы для выполнения функций камеры, а любые ненужные разрешения, связанные с камерой, в медиасервере следует удалить.
  • Разделение между Camera HAL и cameraserver. В Android 8.0 и выше дополнительно разделение привязанного Camera HAL осуществляется иным способом, отличным от cameraserver. Межпроцессное взаимодействие происходит через интерфейсы , определенные в HIDL .

Проверка

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

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

История версий Camera HAL

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

Android 10

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

API камеры

Камера HAL

В 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 : Синхронная функция обратного вызова, которую 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 .

Android 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

Android 8.0

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

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

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

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

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

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

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

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

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

Для поддержки этой функции производителям оборудования достаточно добавить новый режим в свой 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

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

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

2.0

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

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

1.0

Начальный HAL камеры 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. Подсказки по арбитражу камер. Добавлена ​​поддержка явного указания количества камер, которые могут быть одновременно открыты и использованы. Для указания допустимых комбинаций устройств поля resource_cost и conflicting_devices всегда должны быть установлены в структуре camera_info возвращаемой вызовом get_camera_info .
  4. Метод инициализации модуля. Вызывается службой камеры после загрузки модуля HAL для однократной инициализации HAL. Вызывается перед вызовом любых других методов модуля.

2.3

В этой версии модуля камеры добавлена ​​поддержка открытия устаревших устройств 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 .