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

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

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

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

API камеры1
Платформа камеры уровня приложения на устройствах Android 4.4 и более ранних версий, предоставляемая через класс android.hardware.Camera .
API камеры2
Платформа камеры уровня приложения на устройствах Android 5.0 и более поздних версий, предоставляемая через пакет android.hardware.camera2 .
Камера ХАЛ
Уровень модуля камеры, реализованный поставщиками 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 посредством нового интерфейса поставщика.
ХИДЛ
Язык определения интерфейса HAL , представленный в Treble и используемый для определения интерфейса между HAL и его пользователями.
СУДС
Набор тестов поставщиков представлен вместе с Treble.

API-интерфейсы камеры

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

API камеры1

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

  • Интерфейсы 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 , которое приложения могут запрашивать через интерфейсы API2 камеры, сообщает об одном из следующих уровней поддержки:

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

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

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

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

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

    Камера 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 медиасервера для сервера камеры (поскольку медиасерверу и серверу камеры обычно требуются разные ресурсы в системе). Сервер камеры должен иметь только те разрешения, которые необходимы для выполнения функций камеры, а все ненужные разрешения, связанные с камерой, на медиасервере следует удалить.
  • Разделение 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 Imaging .
  • Улучшения конфиденциальности. Определенные ключи необходимы для того, чтобы клиент имел разрешения CAMERA , прежде чем их можно будет получить из CameraCharacteristics . См. getKeysNeedingPermission .

Камера ХАЛ

Следующие версии 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 .

Камера ХАЛ

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. При использовании Treble реализации Camera HAL поставщика должны быть связаны . Android 8.0 также содержит следующие ключевые улучшения службы камеры:

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

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

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

Эта функция позволяет использовать только один набор буферов для управления двумя выходами, такими как предварительный просмотр и кодирование видео, что снижает потребление энергии и памяти. Чтобы поддерживать эту функцию, производители устройств должны гарантировать, что реализации HAL для камер и gralloc могут создавать буферы gralloc, которые используются несколькими различными потребителями (такими как аппаратный композитор/графический процессор и видеокодер), а не только одним потребителем. Служба камеры передает флаги использования потребителя в HAL камеры и HAL graloc; им необходимо либо выделить правильные типы буферов, либо 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.
  • вызов сброса, чтобы как можно быстрее удалить все текущие запросы/буферы.

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.
  • Поддерживает 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 .