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

На этой странице подробно описываются различия версий в Camera 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 с помощью нового интерфейса поставщика.
ХИДЛ
Язык определения интерфейса HAL , представленный в Treble и используемый для указания интерфейса между HAL и его пользователями.
СДС
Вместе с Treble представлен тестовый набор для поставщиков .

API камеры

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

API камеры1

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

  • Интерфейсы Camera API1 для приложений. Приложения Camera, созданные на основе Camera API1, должны работать так же, как и на устройствах с более ранними версиями Android.
  • Версии Camera HAL. Включает поддержку Camera 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, которые оно поддерживает, доступны в виде следующих флагов функций, позволяющих фильтровать приложения камеры 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).

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

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

Проверка

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

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

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

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

андроид 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 .

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

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

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

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

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

1.0

Первоначальный HAL камеры Android (Android 4.0) [camera.h]:

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

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

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

2.4

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

  1. Поддержка режима Torch. Фреймворк может включить режим Torch для любого устройства камеры, имеющего вспышку, без открытия устройства камеры. Устройство камеры имеет более высокий приоритет доступа к вспышке, чем модуль камеры; открытие устройства камеры выключает Torch, если он был включен через интерфейс модуля. При возникновении конфликтов ресурсов, например, при вызове open() для открытия устройства камеры, модуль HAL камеры должен уведомить фреймворк через обратный вызов состояния режима Torch, что режим Torch был выключен.
  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 может поддерживаться этим модулем и его устройствами.