Compatibilidad con las versiones de la cámara

En esta página, se detallan las diferencias de versión en las HALs de cámara, las APIs y las pruebas asociadas del Conjunto de pruebas de compatibilidad (CTS). También abarca varios cambios de arquitectura realizados para reforzar y proteger el framework 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 la cámara.

Terminología

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

API de Camera1
Es el framework de la cámara a nivel de la app en dispositivos con Android 4.4 y versiones anteriores, que se expone a través de la clase android.hardware.Camera.
API de Camera2
Es el framework de la cámara a nivel de la app en dispositivos con Android 5.0 y versiones posteriores, expuesto a través del paquete android.hardware.camera2.
HAL de la cámara
Es la capa del módulo de la cámara implementada por los proveedores de SoC. Los frameworks públicos a nivel de la app se compilan sobre la HAL de la cámara.
Cámara HAL3.1
Versión de la HAL del dispositivo de cámara lanzada con Android 4.4.
HAL3.2 de la cámara
Versión de la HAL del dispositivo de cámara lanzada con Android 5.0.
CTS de Camera API1
Conjunto de pruebas de CTS de la cámara que se ejecutan sobre la API de Camera1.
CTS de Camera API2
Conjunto adicional de pruebas de CTS de la cámara que se ejecutan sobre la API de Camera2.
Treble
Separa la implementación del proveedor (software de nivel inferior específico del dispositivo escrito por los fabricantes de semiconductores) del framework del SO Android a través de una nueva interfaz del proveedor.
HIDL
Lenguaje de definición de la interfaz de HAL: Se introdujo con Treble y se usa para especificar la interfaz entre una HAL y sus usuarios.
VTS
Se introdujo el paquete de pruebas de proveedores junto con Treble.

APIs de Camera

Android incluye las siguientes APIs de cámara.

API de Camera1

Android 5.0 dejó de utilizar la API de Camera1, que se sigue descontinuando a medida que el desarrollo de la nueva plataforma se centra en la API de Camera2. Sin embargo, el período de descontinuación será largo, y las versiones de Android seguirán admitiendo las apps de Camera API1 durante un tiempo. Específicamente, se sigue brindando asistencia para lo siguiente:

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

API de Camera2

El framework de la API de Camera2 expone el control de la cámara de nivel inferior a la app, incluidos los flujos eficientes de ráfaga o transmisión sin copia y los controles por fotograma de exposición, ganancia, ganancias de balance de blancos, conversión de color, reducción de ruido, nitidez y mucho más. Para obtener más detalles, mira el video de resumen de Google I/O.

Android 5.0 y versiones posteriores incluyen la API de Camera2. Sin embargo, es posible que los dispositivos que ejecutan Android 5.0 y versiones posteriores no admitan todas las funciones de la API de Camera2. La propiedad android.info.supportedHardwareLevel que las apps pueden consultar a través de las interfaces de la API de Camera2 informa uno de los siguientes niveles de compatibilidad:

  • LEGACY: Estos dispositivos exponen capacidades a las apps a través de las interfaces de Camera API2, que son aproximadamente las mismas capacidades que las que se exponen a las apps a través de las interfaces de Camera API1. Conceptualmente, el código de los frameworks heredados traduce las llamadas a la API de Camera2 en llamadas a la API de Camera1. Los dispositivos heredados no admiten funciones de la API de Camera2, como los controles por fotograma.
  • LIMITED: Estos dispositivos admiten algunas capacidades de la API de Camera2 (pero no todas) y deben usar Camera HAL 3.2 o una versión posterior.
  • FULL: Estos dispositivos admiten todas las capacidades principales de la API de Camera2 y deben usar Camera HAL 3.2 o una versión posterior, y Android 5.0 o una versión posterior.
  • LEVEL_3: Estos dispositivos admiten el reprocesamiento de YUV y la captura de imágenes RAW, además de configuraciones adicionales de transmisión de salida.
  • EXTERNAL: Estos dispositivos son similares a los dispositivos LIMITED, con algunas excepciones. Por ejemplo, es posible que no se informe cierta información del sensor o del lente, o que las frecuencias de fotogramas sean menos estables. Este nivel se usa 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 de la API de Camera2. Los dispositivos FULL requieren las capacidades de MANUAL_SENSOR y MANUAL_POST_PROCESSING, entre otras. La capacidad RAW es opcional incluso para los dispositivos FULL. Los dispositivos LIMITED pueden anunciar cualquier subconjunto de estas capacidades, incluso ninguna. Sin embargo, siempre se debe definir la capacidad BACKWARD_COMPATIBLE.

El nivel de hardware admitido del dispositivo, así como las capacidades específicas de la API de Camera2 que admite, están disponibles como los siguientes parámetros de configuración para permitir el filtrado de Google Play de las apps de cámara de la API de Camera2.

  • 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 de CTS

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

Los dispositivos que no incluyen una implementación de HAL3.2 de la cámara y no son capaces de admitir las interfaces completas de la API de Camera2 deben aprobar las pruebas del CTS de la API de Camera2. Sin embargo, el dispositivo se ejecuta en el modo LEGACY de la API de Camera2 (en el que las llamadas a la API de Camera2 se asignan conceptualmente a las llamadas a la API de Camera1), por lo que se omiten automáticamente todas las pruebas del CTS de la API de Camera2 relacionadas con funciones o capacidades más allá de la API de Camera1.

En los dispositivos heredados, las pruebas de CTS de Camera API2 que se ejecutan usan las interfaces y capacidades públicas existentes de Camera API1 sin requisitos nuevos. Los errores que se exponen (y que provocan una falla en el CTS de la API de Camera2) ya están presentes en la HAL de la cámara existente del dispositivo y, por lo tanto, las apps existentes de la API de Camera1 los encontrarían. No esperamos que haya muchos errores de este tipo (sin embargo, se deben corregir todos los errores de este tipo para aprobar las pruebas del CTS de la API de Camera2).

Requisitos de VTS

Los dispositivos que ejecutan Android 8.0 y versiones posteriores con implementaciones de HAL vinculadas deben aprobar las pruebas de VTS de la cámara.

Endurecimiento del framework de la cámara

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

Cambios arquitectónicos para la API1

La grabación de video de API1 puede suponer que la cámara y el codificador de video se ejecutan en el mismo proceso. Cuando se usa la API1 en los siguientes casos:

  • En HAL3, donde el servicio de cámara usa BufferQueue para pasar búferes entre procesos, no es necesaria ninguna actualización del proveedor.

    Pila de cámara y medios de Android 7.0 en API1 en HAL3

    Figura 1: Pila de cámara y medios de Android 7.0 en API1 en HAL3

  • HAL1, que admite el paso de metadatos en búferes de video, los proveedores deben actualizar la HAL para usar kMetadataBufferTypeNativeHandleSource. (kMetadataBufferTypeCameraSource ya no se admite en Android 7.0).

    Pila de cámara y medios de Android 7.0 en API1 en HAL1

    Figura 2: Pila de cámara y medios de Android 7.0 en API1 en HAL1

Cambios de arquitectura para la API2

En el caso de API2 en HAL1 o HAL3, BufferQueue pasa búferes para que esas rutas sigan funcionando. La arquitectura de Android 7.0 para API2 en:

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

    Pila de cámara y medios de Android 7.0 en API2 en HAL3

    Figura 3: Pila de cámara y medios de Android 7.0 en API2 en HAL3

Requisitos adicionales

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

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

Validación

En todos los dispositivos que incluyen una cámara y ejecutan Android 7.0, verifica la implementación ejecutando el CTS de Android 7.0. Si bien Android 7.0 no incluye pruebas nuevas del CTS que verifiquen los cambios en el servicio de la cámara, las pruebas existentes del CTS fallarán si no realizaste las actualizaciones indicadas anteriormente.

En todos los dispositivos que incluyen una cámara y ejecutan Android 8.0 y versiones posteriores, verifica la implementación del proveedor ejecutando VTS.

Historial de versiones de la HAL de la cámara

Para obtener una lista de las pruebas disponibles para evaluar la HAL de la cámara de Android, consulta la lista de tareas para la prueba de la HAL de la cámara.

Android 10

Android 10 incluye las siguientes actualizaciones.

API de cámara

HAL de la cámara

En Android 10, se actualizaron las siguientes versiones de la HAL de la cámara.

3.5

ICameraDevice

ICameraDeviceSession

  • isReconfigurationNeeded: Método que le indica al framework de la cámara si se requiere una reconfiguración completa de la transmisión para los posibles valores nuevos de los parámetros de sesión. Esto ayuda a evitar demoras innecesarias en la reconfiguración de la cámara. Consulta Consulta de reconfiguración de sesión.
  • APIs de administración de búfer de HAL: Estas APIs permiten que la HAL de la cámara solicite búferes del framework de la cámara solo cuando sea necesario, en lugar de vincular cada solicitud de captura con sus búferes asociados en todo el canal de la cámara, lo que genera ahorros de memoria potencialmente significativos.
    • signalStreamFlush: Señala a la HAL que el servicio de cámara está a punto de realizar configureStreams_3_5 y que la HAL debe devolver todos los búferes de las transmisiones designadas.
    • configureStreams_3_5: Similar a ICameraDevice3.4.configureStreams, pero, además, se proporciona el contador streamConfigCounter para verificar si hay una condición de carrera entre las llamadas configureStreams_3_5 y signalStreamFlush.

Actualizaciones a ICameraDeviceCallback:

  • requestStreamBuffers: Es una devolución de llamada síncrona que llama el HAL de la cámara para solicitarle búferes al servidor de la cámara. Consulta requestStreamBuffers.
  • returnStreamBuffers: Devolución de llamada síncrona para que el HAL de la cámara devuelva búferes de salida al servidor de la cámara. Consulta 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
  • Funciones
    • 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 de transmisión de profundidad dinámica 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 la cámara

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

2.5

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

2.4

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

Android 9

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

API de cámara

  • Se introduce la API de varias cámaras para mejorar la compatibilidad con dispositivos que tienen varias cámaras orientadas en la misma dirección, lo que permite funciones como el bokeh y el zoom sin interrupciones. Esto permite que las apps 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. Consulta Compatibilidad con varias cámaras.
  • Se introducen los parámetros de sesión. Los parámetros de sesión son un subconjunto de los parámetros de captura disponibles que pueden causar demoras graves 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. Consulta Parámetros de sesión.
  • Se agregan claves de datos de estabilización óptica (OIS) para la estabilización y los efectos a nivel de la app. Consulta STATISTICS_OIS_SAMPLES.
  • Se agregó compatibilidad con flash externo. Consulta CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
  • Agrega un intent de seguimiento de movimiento en CAPTURE_INTENT. Consulta CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
  • Se dejó de usar LENS_RADIAL_DISTORTION y se agregó LENS_DISTORTION en su lugar.
  • Se agregaron modos de corrección de distorsión en CaptureRequest. Consulta DISTORTION_CORRECTION_MODE.
  • Se agregó compatibilidad con cámaras externas USB/UVC en dispositivos compatibles. Consulta INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

HAL de la cámara

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.

  • Funciones
    • 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 de Android 8.0 incluye Treble. Con Treble, las implementaciones de HAL de cámara del proveedor deben estar vinculadas. Android 8.0 también contiene estas mejoras clave para el servicio de la cámara:

  • Superficies compartidas: Permiten que varias superficies compartan el mismo OutputConfiguration
  • API del sistema para modos de cámara personalizados
  • onCaptureQueueEmpty

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

Superficies compartidas

Esta función permite que solo un conjunto de búferes controle dos salidas, como la vista previa y la codificación de video, lo que reduce el consumo de energía y memoria. Para admitir esta función, los fabricantes de dispositivos deben asegurarse de que sus implementaciones de HAL de cámara y HAL de gralloc puedan crear búferes de gralloc que utilicen varios consumidores diferentes (como el compositor de hardware/GPU y el codificador de video), en lugar de solo un consumidor. El servicio de cámara pasa las marcas de uso del consumidor a la HAL de la cámara y a la HAL de gralloc. Estas deben asignar los tipos correctos de búferes, o bien la HAL de la cámara debe devolver un error que indique que no se admite esta combinación de consumidores.

Consulta la enableSurfaceSharingdocumentación para desarrolladores para obtener más detalles.

API del sistema para modos de cámara personalizados

La API de cámara pública define dos modos de funcionamiento: normal y grabación de alta velocidad restringida. Tienen una semántica bastante diferente; por ejemplo, el modo de alta velocidad se limita a un máximo de dos salidas específicas a la vez. Varios OEM expresaron interés en definir otros modos personalizados para las capacidades específicas del hardware. En segundo plano, el modo es solo un número entero que se pasa a configure_streams. Consulta: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams.

Esta función incluye una llamada a la API del sistema que las apps de cámara de OEM pueden usar para habilitar un modo personalizado. Estos modos deben comenzar con el valor entero 0x8000 para evitar conflictos con los modos futuros que se agreguen a la API pública.

Para admitir esta función, los OEM solo deben agregar el nuevo modo a su HAL, que se activa con este número entero que se pasa al HAL en configure_streams, y, luego, hacer que su app de cámara personalizada use la API del sistema.

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

onCaptureQueueEmpty

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 de HAL, ya que se agregó solo en el framework. Las apps que quieran aprovecharla deben agregar un objeto de escucha a esa devolución de llamada y responder de manera adecuada. Por lo general, esto se hace enviando otra solicitud de captura al dispositivo de cámara.

Interfaz de HIDL de la cámara

La interfaz de HIDL de la cámara es una revisión completa de la interfaz de HAL de la cámara que usa APIs estables definidas por HIDL. Todas las funciones y capacidades de la cámara que se introdujeron 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 de HIDL.

3.4

Se realizaron pequeñas incorporaciones a los metadatos admitidos y cambios en la compatibilidad con data_space:

  • Agrega metadatos estáticos de ANDROID_SENSOR_OPAQUE_RAW_SIZE como obligatorios si se admite el formato RAW_OPAQUE.
  • Agrega metadatos estáticos de ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE como obligatorios si se admite algún formato RAW.
  • Se cambió el campo camera3_stream_t data_space a una definición más flexible, con la definición de la versión 0 de la codificación del espacio de datos.
  • Se agregaron metadatos generales que están disponibles para HALv3.2 o versiones posteriores:
    • 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 secundaria del HAL de capacidad expandida:

  • Se actualizaron las APIs de reprocesamiento OPAQUE y YUV.
  • Compatibilidad básica con búferes de salida de profundidad
  • Se agregó el campo data_space a camera3_stream_t.
  • Se agregó el campo de rotación a camera3_stream_t.
  • Se agregó el modo de operación de configuración de transmisión de camera3 a camera3_stream_configuration_t.

3.2

Revisión secundaria del HAL de capacidad expandida:

  • get_metadata_vendor_tag_ops quedó obsoleto. En su lugar, usa get_vendor_tag_ops en camera_common.h.
  • register_stream_buffers quedó obsoleto. Todos los búferes de gralloc que el framework proporciona al HAL en process_capture_request pueden ser nuevos en cualquier momento.
  • Se agregó compatibilidad con resultados parciales. process_capture_result se puede llamar varias veces con un subconjunto de los resultados disponibles antes de que esté disponible el resultado completo.
  • Se agregó una plantilla manual a camera3_request_template. Las apps pueden usar esta plantilla para controlar la configuración de captura directamente.
  • Se reelaboraron las especificaciones de entrada y bidireccionales.
  • Cambia la ruta de devolución del búfer de entrada. El búfer se devuelve en process_capture_result en lugar de process_capture_request.

3.1

Revisión secundaria del HAL de capacidad expandida:

  • configure_streams pasa marcas de uso del consumidor al HAL.
  • Llamada de vaciado para descartar todas las solicitudes o búferes en curso lo más rápido posible.

3.0

Primera revisión del HAL con capacidades expandidas:

  • Cambio de versión principal, ya que la ABI es completamente diferente. No se modificaron las capacidades de hardware ni el modelo operativo requeridos desde la versión 2.0.
  • Se rediseñaron las interfaces de solicitud de entrada y de cola de transmisión: El framework llama al HAL con los siguientes búferes de solicitud y transmisión ya retirados de la cola. Se incluye la compatibilidad con el marco de trabajo de sincronización, que es necesaria para implementaciones eficientes.
  • Se trasladaron los activadores a las solicitudes y la mayoría de las notificaciones a los resultados.
  • Se consolidaron todas las devoluciones de llamada en el framework en una sola estructura y todos los métodos de configuración en una sola llamada a initialize().
  • Se convirtió la configuración de la transmisión en una sola llamada para simplificar la administración de la transmisión. Los flujos bidireccionales reemplazan la construcción STREAM_FROM_STREAM.
  • Semántica del modo limitado para dispositivos de hardware más antiguos o limitados.

2.0

Versión inicial de la HAL de capacidad expandida (Android 4.2) [camera2.h]:

  • Es suficiente para implementar la API de android.hardware.Camera existente.
  • Permite la fila de ZSL en la capa de servicio de la cámara.
  • No se probó con ninguna función nueva, como el control de captura manual, la captura de Bayer RAW, el reprocesamiento de datos RAW, etcétera.

1.0

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

  • Se convirtió de la capa de abstracción CameraHardwareInterface de C++.
  • Es compatible con la API de android.hardware.Camera.

Historial de versiones del módulo de la cámara

En esta sección, se incluye información sobre el control de versiones del módulo de hardware de la cámara, según camera_module_t.common.module_api_version. Los dos dígitos hexadecimales más significativos representan la versión principal, y los dos menos significativos representan la versión secundaria.

2.4

En esta versión del módulo de la cámara, se agregan los siguientes cambios en la API:

  1. Se agregó compatibilidad con el modo de linterna. El framework puede activar el modo de linterna para cualquier dispositivo de cámara que tenga una unidad de flash, sin abrir el dispositivo de cámara. El dispositivo de cámara tiene una mayor prioridad para acceder a la unidad de flash que el módulo de cámara. Abrir un dispositivo de cámara apaga la linterna si se había habilitado a través de la interfaz del módulo. Cuando hay conflictos de recursos, como cuando se llama a open() para abrir un dispositivo de cámara, el módulo HAL de la cámara debe notificar al framework a través de la devolución de llamada de estado del modo de linterna que se desactivó el modo de linterna.
  2. Compatibilidad con cámaras externas (por ejemplo, cámaras USB de conexión en caliente) Las actualizaciones de la API especifican que la información estática de la cámara solo está disponible cuando la cámara está conectada y lista para usarse en el caso de las cámaras externas con conexión 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 framework solo se basa en las devoluciones de llamada de cambio de estado del dispositivo para administrar la lista de cámaras externas disponibles.
  3. Sugerencias de arbitraje de la cámara. Se agregó compatibilidad para indicar de forma explícita la cantidad de dispositivos de cámara que se pueden abrir y usar de forma simultánea. Para especificar combinaciones válidas de dispositivos, los campos resource_cost y conflicting_devices siempre deben establecerse en la estructura camera_info que devuelve la llamada a get_camera_info.
  4. Método de inicialización del módulo. El servicio de cámara llama a esta función después de que se carga el módulo de HAL para permitir la inicialización única de la HAL. Se llama antes de que se invoque cualquier otro método del módulo.

2.3

Esta versión del módulo de la cámara agrega compatibilidad con dispositivos HAL de cámara heredados abiertos. El framework puede usarlo para abrir el dispositivo de cámara como un dispositivo HAL de versión inferior si el mismo dispositivo admite varias versiones de la API del dispositivo. La llamada abierta estándar del módulo de hardware (common.methods->open) sigue abriendo el dispositivo de cámara con la versión admitida más reciente, que también es la versión que se indica en camera_info_t.device_version.

2.2

Esta versión del módulo de la cámara agrega compatibilidad con etiquetas de proveedores desde el módulo y dejó de estar disponible la antigua vendor_tag_query_ops, a la que antes solo se podía acceder con el dispositivo abierto.

2.1

Esta versión del módulo de la cámara agrega compatibilidad con devoluciones de llamada asíncronas al framework desde el módulo de HAL de la cámara, que se usa para notificar al framework sobre los 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 de 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 de la 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 inicial de la HAL del módulo de cámara. Todos los dispositivos de cámara que se pueden abrir a través de este módulo solo admiten la versión 1 de la HAL del dispositivo de cámara. Los campos device_version y static_camera_characteristics de camera_info no son válidos. Solo la API de android.hardware.Camera puede ser compatible con este módulo y sus dispositivos.