Soporte de versión de cámara

Esta página detalla las diferencias de versión en Camera HAL, API y pruebas de Compatibility Test Suite (CTS) asociadas. También cubre varios cambios arquitectónicos realizados para reforzar y proteger el marco de la cámara en Android 7.0, el cambio a Treble en Android 8.0 y las actualizaciones que los proveedores deben realizar para admitir estos cambios en sus implementaciones de cámaras.

Terminología

En esta página se utilizan los siguientes términos:

Cámara API1
El marco de la cámara a nivel de aplicación en dispositivos Android 4.4 y versiones inferiores, expuesto a través de la clase android.hardware.Camera .
Cámara API2
El marco de la cámara a nivel de aplicación en dispositivos Android 5.0 y superiores, expuesto a través del paquete android.hardware.camera2 .
cámara hal
La capa del módulo de cámara implementada por los proveedores de SoC. Los marcos públicos a nivel de aplicación se construyen sobre la cámara HAL.
Cámara HAL3.1
Versión del dispositivo de cámara HAL lanzada con Android 4.4.
Cámara HAL3.2
Versión del dispositivo de cámara HAL lanzada con Android 5.0.
Cámara API1 CTS
Conjunto de pruebas CTS de cámara que se ejecutan sobre Camera API1.
Cámara API2 CTS
Conjunto adicional de pruebas CTS de cámara que se ejecutan sobre Camera API2.
Triplicar
Separa la implementación del proveedor (software de nivel inferior, específico del dispositivo, escrito por fabricantes de silicio) del marco del sistema operativo Android a través de una nueva interfaz de proveedor.
HIDL
Lenguaje de definición de interfaz HAL introducido con Treble y utilizado para especificar la interfaz entre un HAL y sus usuarios.
VTS
Se presentó el conjunto de pruebas del proveedor junto con Treble.

API de cámara

Android incluye las siguientes API de cámara.

Cámara API1

Android 5.0 dejó de usar Camera API1, que continúa siendo eliminada a medida que el desarrollo de una nueva plataforma se centra en Camera API2. Sin embargo, el período de eliminación será largo y las versiones de Android seguirán admitiendo aplicaciones Camera API1 durante algún tiempo. Específicamente, el soporte continúa para:

  • Interfaces de cámara API1 para aplicaciones. Las aplicaciones de cámara creadas sobre Camera API1 deberían funcionar como lo hacen en dispositivos que ejecutan versiones anteriores de Android.
  • Versiones de cámara HAL. Incluye soporte para cámara HAL1.0.

Cámara API2

El marco Camera API2 expone el control de la cámara de nivel inferior a la aplicación, incluidos flujos eficientes de ráfaga/transmisión de copia cero y controles por cuadro de exposición, ganancia, ganancias de balance de blancos, conversión de color, eliminación de ruido, nitidez y más. Para obtener más información, mira la descripción general en vídeo de Google I/O .

Android 5.0 y superior incluye Camera API2; sin embargo, es posible que los dispositivos con Android 5.0 y versiones posteriores no admitan todas las funciones de Camera API2. La propiedad android.info.supportedHardwareLevel que las aplicaciones pueden consultar a través de las interfaces Camera API2 informa uno de los siguientes niveles de soporte:

  • LEGACY : Estos dispositivos exponen capacidades a las aplicaciones a través de las interfaces Camera API2 que son aproximadamente las mismas capacidades que las expuestas a las aplicaciones a través de las interfaces Camera API1. El código de los marcos heredados traduce conceptualmente las llamadas de Camera API2 en llamadas de Camera API1; Los dispositivos heredados no admiten funciones de Camera API2, como los controles por cuadro.
  • LIMITED : Estos dispositivos admiten algunas capacidades de Camera API2 (pero no todas) y deben usar Camera HAL 3.2 o superior.
  • FULL : Estos dispositivos admiten todas las capacidades principales de Camera API2 y deben usar Camera HAL 3.2 o superior y Android 5.0 o superior.
  • LEVEL_3 : estos dispositivos admiten el reprocesamiento YUV y la captura de imágenes RAW, junto con configuraciones de flujo de salida adicionales.
  • EXTERNAL : Estos dispositivos son similares a los dispositivos LIMITED con algunas excepciones; por ejemplo, es posible que parte de la información del sensor o de la lente no se informe o tenga velocidades de fotogramas menos estables. Este nivel se utiliza para cámaras externas como cámaras web USB.

Las capacidades individuales se exponen a través de la propiedad android.request.availableCapabilities en las interfaces Camera API2. Los dispositivos FULL requieren las capacidades MANUAL_SENSOR y MANUAL_POST_PROCESSING , entre otras. La capacidad RAW es opcional incluso para dispositivos FULL . Los dispositivos LIMITED pueden anunciar cualquier subconjunto de estas capacidades, incluida ninguna de ellas. Sin embargo, siempre se debe definir la capacidad BACKWARD_COMPATIBLE .

El nivel de hardware admitido del dispositivo, así como las capacidades específicas de Camera API2 que admite, están disponibles como las siguientes marcas de características para permitir que Google Play filtre las aplicaciones de cámara 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

Requisitos CTS

Los dispositivos que ejecutan Android 5.0 y versiones posteriores deben pasar las pruebas de cámara Camera API1 CTS, Camera API2 CTS y CTS Verifier.

Los dispositivos que no cuentan con una implementación de Camera HAL3.2 y no son capaces de admitir las interfaces completas de Camera API2 aún deben pasar las pruebas Camera API2 CTS. Sin embargo, el dispositivo se ejecuta en el modo LEGACY de Camera API2 (en el que las llamadas de Camera API2 se asignan conceptualmente a las llamadas de Camera API1), por lo que cualquier prueba CTS de Camera API2 relacionada con funciones o capacidades más allá de Camera API1 se omite automáticamente.

En dispositivos heredados, las pruebas CTS de Camera API2 que se ejecutan utilizan las interfaces y capacidades públicas existentes de Camera API1 sin nuevos requisitos. Los errores que están expuestos (y que causan una falla de Camera API2 CTS) son errores que ya están presentes en la cámara HAL existente del dispositivo y, por lo tanto, las aplicaciones de Camera API1 existentes los encontrarían. No esperamos muchos errores de esta naturaleza (sin embargo, dichos errores deben corregirse para pasar las pruebas CTS de Camera API2).

Requisitos VTS

Los dispositivos que ejecutan Android 8.0 y superior con implementaciones HAL enlazadas deben pasar las pruebas de Camera VTS .

Endurecimiento del marco de la cámara

Para reforzar la seguridad del marco de la cámara y los medios, Android 7.0 saca el servicio de cámara del servidor de medios. A partir de Android 8.0, cada cámara HAL enlazada se ejecuta en un proceso independiente del servicio de cámara. Es posible que los proveedores necesiten realizar cambios en la cámara HAL según la API y las versiones HAL en uso. Las siguientes secciones detallan los cambios arquitectónicos en AP1 y AP2 para HAL1 y HAL3, así como los requisitos generales.

Cambios arquitectónicos para API1

La grabación de video API1 puede asumir que la cámara y el codificador de video están en vivo en el mismo proceso. Cuando se utiliza API1 en:

  • HAL3, donde el servicio de cámara utiliza BufferQueue para pasar buffers entre procesos, no es necesaria ninguna actualización del proveedor .

    Cámara Android 7.0 y pila multimedia en API1 en HAL3

    Figura 1. Cámara de Android 7.0 y pila multimedia en API1 en HAL3

  • HAL1, que admite el paso de metadatos en buffers de video, los proveedores deben actualizar HAL para usar kMetadataBufferTypeNativeHandleSource . ( kMetadataBufferTypeCameraSource ya no es compatible con Android 7.0).

    Cámara Android 7.0 y pila multimedia en API1 en HAL1

    Figura 2. Cámara de Android 7.0 y pila multimedia en API1 en HAL1

Cambios arquitectónicos para API2

Para API2 en HAL1 o HAL3, BufferQueue pasa buffers para que esas rutas sigan funcionando. La arquitectura de Android 7.0 para API2 en:

  • HAL1 no se ve afectado por el cambio del servicio de cámara y no es necesaria ninguna actualización del proveedor .
  • HAL3 se ve afectado, pero no es necesaria ninguna actualización del proveedor :

    Cámara Android 7.0 y pila multimedia en API2 en HAL3

    Figura 3. Cámara y pila multimedia de Android 7.0 en API2 en HAL3

Requerimientos adicionales

Los cambios arquitectónicos realizados para reforzar la seguridad del marco de la cámara y los medios incluyen los siguientes requisitos adicionales del dispositivo.

  • General. Los dispositivos requieren ancho de banda adicional debido a IPC, lo que puede afectar casos de uso de cámaras urgentes, como la grabación de video de alta velocidad. Los proveedores pueden medir el impacto real ejecutando android.hardware.camera2.cts.PerformanceTest y la aplicación Google Camera para grabación de video de alta velocidad de 120/240 FPS. Los dispositivos también requieren una pequeña cantidad de RAM adicional para crear el nuevo proceso.
  • Pasar metadatos en buffers de video ( solo HAL1 ). Si HAL1 almacena metadatos en lugar de datos de cuadros YUV reales en búferes de video, HAL debe usar kMetadataBufferTypeNativeHandleSource como tipo de búfer de metadatos y pasar VideoNativeHandleMetadata en búferes de video. ( kMetadataBufferTypeCameraSource ya no es compatible con Android 7.0). Con VideoNativeHandleMetadata , los marcos de cámaras y medios pueden pasar los buffers de video entre procesos serializando y deserializando los identificadores nativos correctamente.
  • La dirección del identificador del búfer no siempre almacena el mismo búfer ( solo HAL3 ). Para cada solicitud de captura, HAL3 obtiene direcciones de identificadores de búfer. HAL no puede usar las direcciones para identificar buffers porque las direcciones pueden almacenar otro identificador de buffer después de que HAL devuelve el buffer. Debe actualizar HAL para utilizar identificadores de búfer para identificar los búferes. Por ejemplo, HAL recibe una dirección de identificador de búfer A, que almacena el identificador de búfer A. Después de que HAL devuelve el identificador de búfer A, la dirección de identificador de búfer A puede almacenar el identificador de búfer B la próxima vez que HAL la reciba.
  • Actualice las políticas de SELinux para el servidor de cámaras. Si las políticas de SELinux específicas del dispositivo otorgan permisos al servidor de medios para ejecutar la cámara, debe actualizar las políticas de SELinux para otorgar los permisos adecuados al servidor de la cámara. No recomendamos replicar las políticas SELinux del servidor de medios para el servidor de cámaras (ya que el servidor de medios y el servidor de cámaras generalmente requieren recursos diferentes en el sistema). Cameraserver debe tener solo los permisos necesarios para realizar las funciones de la cámara y se deben eliminar todos los permisos innecesarios relacionados con la cámara en el servidor de medios.
  • Separación entre cámara HAL y servidor de cámara. Android 8.0 y versiones posteriores también separan la cámara HAL enlazada en un proceso diferente al del servidor de cámara. IPC pasa por interfaces definidas por HIDL .

Validación

Para todos los dispositivos que incluyen una cámara y ejecutan Android 7.0, verifique la implementación ejecutando Android 7.0 CTS. Aunque Android 7.0 no incluye nuevas pruebas CTS que verifican los cambios en el servicio de la cámara, las pruebas CTS existentes fallan si no has realizado las actualizaciones indicadas anteriormente.

Para todos los dispositivos que incluyen una cámara y ejecutan Android 8.0 y superior, verifique la implementación del proveedor ejecutando VTS.

Historial de versiones de cámara HAL

Para obtener una lista de pruebas disponibles para evaluar la cámara HAL de Android, consulte la Lista de verificación de pruebas de cámara HAL .

androide 10

Android 10 presenta las siguientes actualizaciones.

API de cámara

cámara hal

Las siguientes versiones de Camera HAL se actualizan en Android 10.

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics : la información de la cámara estática para una ID de cámara física que respalda un dispositivo de cámara lógica. Consulte Compatibilidad con múltiples cámaras .
  • isStreamCombinationSupported : este método admite una API pública que ayuda a los clientes a consultar si se admite una configuración de sesión. Consulte API para consultar combinaciones de flujos .

ICameraDeviceSession

  • isReconfigurationNeeded : método que le indica al marco de la cámara si se requiere una reconfiguración completa de la transmisión para posibles nuevos valores de parámetros de sesión. Esto ayuda a evitar retrasos innecesarios en la reconfiguración de la cámara. Ver Consulta de reconfiguración de sesión .
  • API de administración de búfer HAL : estas API permiten que la cámara HAL solicite búferes del marco de la cámara solo cuando sea necesario, en lugar de acoplar cada solicitud de captura con sus búferes asociados a lo largo de la canalización de la cámara, lo que genera ahorros de memoria potencialmente significativos.
    • signalStreamFlush : indica al HAL que el servicio de cámara está a punto de realizar configureStreams_3_5 y que el HAL debe devolver todos los buffers de las transmisiones designadas.
    • configureStreams_3_5 : similar a ICameraDevice3.4.configureStreams , pero además, se proporciona el contador streamConfigCounter para verificar una condición de carrera entre las llamadas configureStreams_3_5 y signalStreamFlush .

Actualizaciones de ICameraDeviceCallback :

  • requestStreamBuffers : devolución de llamada síncrona que la cámara HAL llama para solicitar buffers al servidor de la cámara. Consulte requestStreamBuffers .
  • returnStreamBuffers : devolución de llamada síncrona para que la cámara HAL devuelva los buffers de salida al servidor de la cámara. Consulte returnStreamBuffers .

3.4

Las siguientes claves se agregan a los metadatos de la cámara en Android 10.

  • Formatos de imagen
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • Etiquetas de metadatos de la cámara
    • 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
  • Capacidades
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
  • Valores para la clave ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • Configuraciones dinámicas de flujo de profundidad disponibles
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • Configuraciones de transmisión HEIC disponibles
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Módulo de cámara

Las siguientes versiones del módulo de cámara se actualizan en Android 10.

2.5

  • Agrega el método notifyDeviceStateChange para que los dispositivos notifiquen a la cámara HAL cuando los cambios físicos, como el plegado, afectan la cámara y el enrutamiento.

2.4

  • Los dispositivos que se inician con el nivel API 29 o superior DEBEN informar true para isTorchModeSupported .

androide 9

La versión de Android 9 presenta las siguientes actualizaciones para la interfaz API2 y HAL de la cámara.

API de cámara

  • Presenta la API multicámara para admitir mejor dispositivos con múltiples cámaras orientadas en la misma dirección, habilitando funciones como bokeh y zoom continuo. Esto permite que las aplicaciones vean varias cámaras en un dispositivo como una unidad lógica (cámara lógica). Las solicitudes de captura también se pueden enviar a dispositivos de cámara individuales incluidos en una cámara lógica. Consulte Compatibilidad con múltiples cámaras .
  • Introduce los parámetros de la sesión. Los parámetros de sesión son un subconjunto de los parámetros de captura disponibles que pueden provocar graves retrasos en el procesamiento cuando se modifican. Estos costos se pueden mitigar si los clientes pasan sus valores iniciales durante la inicialización de la sesión de captura. Consulte Parámetros de sesión .
  • Agrega claves de datos de estabilización óptica (OIS) para estabilización y efectos a nivel de aplicación. Consulte STATISTICS_OIS_SAMPLES .
  • Agrega soporte para flash externo. Consulte CONTROL_AE_MODE_ON_EXTERNAL_FLASH .
  • Agrega una intención de seguimiento de movimiento en CAPTURE_INTENT . Consulte CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • Desaproba LENS_RADIAL_DISTORTION y agrega LENS_DISTORTION en su lugar.
  • Agrega modos de corrección de distorsión en CaptureRequest . Consulte DISTORTION_CORRECTION_MODE .
  • Agrega soporte para cámaras USB/UVC externas en dispositivos compatibles. Consulte INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL .

cámara hal

3.4

Actualizaciones de ICameraDeviceSession

Actualizaciones de ICameraDeviceCallback

3.3

Las siguientes claves se agregan a los metadatos de la cámara en Android 9.

  • Capacidades
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • Etiquetas de metadatos de la cámara
    • 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

La versión Android 8.0 presenta Treble. Con Treble, las implementaciones de Camera HAL del proveedor deben estar enlazadas . Android 8.0 también contiene estas mejoras clave para el servicio de cámara:

  • Superficies compartidas: habilite varias superficies que compartan la misma OutputConfiguration
  • API del sistema para modos de cámara personalizados
  • onCaptureQueueEmpty

Consulte las secciones siguientes para obtener más información sobre estas funciones.

Superficies compartidas

Esta característica permite que solo un conjunto de buffers impulse dos salidas, como vista previa y codificación de video, lo que reduce el consumo de energía y memoria. Para admitir esta característica, los fabricantes de dispositivos deben asegurarse de que las implementaciones de HAL de su cámara y HAL de gralloc puedan crear búferes de gralloc que sean utilizados por varios consumidores diferentes (como el compositor/GPU de hardware y el codificador de video), en lugar de solo un consumidor. El servicio de cámara pasa las banderas de uso del consumidor a la cámara HAL y al gralloc HAL; deben asignar los tipos correctos de buffers o la cámara HAL debe devolver un error indicando que esta combinación de consumidores no es compatible.

Consulte la documentación para desarrolladores enableSurfaceSharing para obtener detalles adicionales.

API del sistema para modos de cámara personalizados

La API de la cámara pública define dos modos de funcionamiento: grabación de alta velocidad normal y restringida. Tienen una semántica bastante diferente; por ejemplo, el modo de alta velocidad está limitado a como máximo dos salidas específicas a la vez. Varios fabricantes de equipos originales han expresado interés en definir otros modos personalizados para capacidades específicas del hardware. En esencia, el modo es solo un número entero pasado a configure_streams . Consulte: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

Esta característica incluye una llamada API del sistema que las aplicaciones de cámara OEM pueden usar para habilitar un modo personalizado. Estos modos deben comenzar con un valor entero 0x8000 para evitar conflictos con modos futuros agregados a la API pública.

Para admitir esta característica, los OEM simplemente necesitan agregar el nuevo modo a su HAL, activado por este número entero pasado al HAL en configure_streams, y luego hacer que su aplicación de cámara personalizada use la API del sistema.

El nombre del método es android.hardware.camera2.CameraDevice#createCustomCaptureSession . Consulte: frameworks/base/core/java/android/hardware/camera2/CameraDevice .

onCaptureQueueVacío

El propósito de esta API es reducir la latencia de los cambios de control como el zoom manteniendo la cola de solicitudes lo más vacía posible. onCaptureQueueEmpty no requiere trabajo HAL; fue puramente una adición del lado del marco. Las aplicaciones que quieran aprovecharlo deben agregar un oyente a esa devolución de llamada y responder adecuadamente. Generalmente, eso se realiza enviando otra solicitud de captura al dispositivo de la cámara.

Interfaz HIDL de cámara

La interfaz Camera HIDL es una revisión completa de la interfaz Camera HAL que utiliza API estables definidas por HIDL. Todas las funciones y capacidades de la cámara introducidas en las versiones heredadas más recientes 3.4 y 2.4 (para el módulo de la cámara) también forman parte de las definiciones HIDL.

3.4

Adiciones menores a los metadatos admitidos y cambios en la compatibilidad con el espacio de datos:

  • Agregue metadatos estáticos ANDROID_SENSOR_OPAQUE_RAW_SIZE como obligatorios si se admite el formato RAW_OPAQUE .
  • Agregue metadatos estáticos ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE como obligatorio si se admite algún formato RAW.
  • Cambie el campo camera3_stream_t data_space a una definición más flexible, utilizando la definición de la versión 0 de codificación del espacio de datos.
  • Adiciones de metadatos generales que están disponibles para su uso en HALv3.2 o posterior:
    • 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

Revisión menor de HAL de capacidad ampliada:

  • Actualizaciones de API de reprocesamiento OPAQUE y YUV.
  • Soporte básico para buffers de salida de profundidad.
  • Adición del campo data_space a camera3_stream_t .
  • Adición de campo de rotación a camera3_stream_t .
  • Adición del modo de operación de configuración de transmisión de camera3 a camera3_stream_configuration_t .

3.2

Revisión menor de HAL de capacidad ampliada:

  • get_metadata_vendor_tag_ops está en desuso. Utilice get_vendor_tag_ops en camera_common.h en su lugar.
  • register_stream_buffers está en desuso. Todos los buffers gralloc proporcionados por framework a HAL en process_capture_request pueden ser nuevos en cualquier momento.
  • Agregue soporte de resultados parciales. Se puede llamar process_capture_result varias veces con un subconjunto de los resultados disponibles antes de que esté disponible el resultado completo.
  • Agregue una plantilla manual a camera3_request_template . Las aplicaciones pueden usar esta plantilla para controlar la configuración de captura directamente.
  • Vuelva a trabajar las especificaciones de flujo de entrada y bidireccional.
  • Cambie la ruta de retorno del búfer de entrada. El búfer se devuelve en process_capture_result en lugar de process_capture_request .

3.1

Revisión menor de HAL de capacidad ampliada:

  • configure_streams pasa indicadores de uso del consumidor al HAL.
  • llamada de descarga para descartar todas las solicitudes/búferes en curso lo más rápido posible.

3.0

Primera revisión de HAL de capacidad ampliada:

  • Cambio de versión importante ya que la ABI es completamente diferente. No hay cambios en las capacidades de hardware requeridas ni en el modelo operativo desde 2.0.
  • Solicitud de entrada reelaborada y interfaces de cola de transmisión: llamadas de marco a HAL con la siguiente solicitud y buffers de transmisión ya retirados de la cola. Se incluye soporte de marco de sincronización, necesario para implementaciones eficientes.
  • Se movieron los activadores a las solicitudes y la mayoría de las notificaciones a los resultados.
  • Consolidé todas las devoluciones de llamadas en el marco en una estructura y todos los métodos de configuración en una única llamada initialize() .
  • Hizo la configuración de la transmisión en una sola llamada para simplificar la administración de la transmisión. Las transmisiones bidireccionales reemplazan la construcción STREAM_FROM_STREAM .
  • Semántica de modo limitado para dispositivos de hardware antiguos/limitados.

2.0

Lanzamiento inicial de HAL con capacidad ampliada (Android 4.2) [camera2.h]:

  • Suficiente para implementar la API android.hardware.Camera existente.
  • Permite la cola ZSL en la capa de servicio de cámara.
  • No se ha probado ninguna característica nueva, como control de captura manual, captura Bayer RAW, reprocesamiento de datos RAW, etc.

1.0

Cámara inicial de Android HAL (Android 4.0) [camera.h]:

  • Convertido de la capa de abstracción CameraHardwareInterface de C++.
  • Admite la API android.hardware.Camera .

Historial de versiones del módulo de cámara

Esta sección contiene información sobre la versión del módulo para el módulo de hardware de la cámara, basada en camera_module_t.common.module_api_version . Los dos dígitos hexadecimales más significativos representan la versión mayor y los dos menos significativos representan la versión menor.

2.4

Esta versión del módulo de cámara agrega los siguientes cambios de API:

  1. Soporte de modo antorcha. El marco puede activar el modo antorcha para cualquier dispositivo de cámara que tenga una unidad de flash, sin abrir el dispositivo de cámara. El dispositivo de la cámara tiene mayor prioridad para acceder a la unidad de flash que el módulo de la cámara; Al abrir un dispositivo de cámara se apaga la antorcha si se hubiera habilitado a través de la interfaz del módulo. Cuando hay conflictos de recursos, como cuando se llama open() para abrir un dispositivo de cámara, el módulo HAL de la cámara debe notificar al marco a través de la devolución de llamada de estado del modo antorcha que el modo antorcha se ha desactivado.
  2. Compatibilidad con cámara externa (por ejemplo, cámara USB de conexión en caliente). Las actualizaciones de API especifican que la información estática de la cámara está disponible solo cuando la cámara está conectada y lista para usar con cámaras externas conectables en caliente. Las llamadas para obtener información estática no son válidas cuando el estado de la cámara no es CAMERA_DEVICE_STATUS_PRESENT . El marco cuenta únicamente con devoluciones de llamadas de cambio de estado del dispositivo para administrar la lista de cámaras externas disponibles.
  3. Consejos de arbitraje de cámara. Agrega soporte para indicar explícitamente la cantidad de dispositivos de cámara que se pueden abrir y usar simultáneamente. Para especificar combinaciones válidas de dispositivos, los campos resource_cost y conflicting_devices siempre deben configurarse en la estructura camera_info devuelta por la llamada get_camera_info .
  4. Método de inicialización del módulo. Lo llama el servicio de cámara después de cargar el módulo HAL para permitir una inicialización única de HAL. Se llama antes de invocar cualquier otro método de módulo.

2.3

Esta versión del módulo de cámara agrega compatibilidad con dispositivos HAL de cámara heredados abiertos. El marco puede usarlo para abrir el dispositivo de la cámara como dispositivo HAL de versión inferior si el mismo dispositivo puede admitir múltiples versiones de API de dispositivo. La llamada abierta del módulo de hardware estándar ( common.methods->open ) continúa abriendo el dispositivo de cámara con la última versión compatible, que también es la versión que figura en camera_info_t.device_version .

2.2

Esta versión del módulo de cámara agrega compatibilidad con etiquetas de proveedor desde el módulo y desaproba las antiguas vendor_tag_query_ops a las que anteriormente solo se podía acceder con un dispositivo abierto.

2.1

Esta versión del módulo de cámara agrega soporte para devoluciones de llamadas asincrónicas al marco desde el módulo HAL de la cámara, que se utiliza para notificar al marco sobre cambios en el estado del módulo de la cámara. Los módulos que proporcionan un método set_callbacks() válido deben informar al menos este número de versión.

2.0

Los módulos de cámara que informan este número de versión implementan la segunda versión de la interfaz HAL del módulo de cámara. Los dispositivos de cámara que se pueden abrir a través de este módulo pueden admitir la versión 1.0 o la versión 2.0 de la interfaz HAL del dispositivo de cámara. El campo device_version de camera_info siempre es válido; el campo static_camera_characteristics de camera_info es válido si el campo device_version es 2.0 o superior.

1.0

Los módulos de cámara que informan estos números de versión implementan la interfaz HAL del módulo de cámara inicial. Todos los dispositivos de cámara que se pueden abrir a través de este módulo solo admiten la versión 1 del dispositivo de cámara HAL. Los campos device_version y static_camera_characteristics de camera_info no son válidos. Este módulo y sus dispositivos solo pueden admitir la API android.hardware.Camera .