Compatibilidad con la versión de la cámara

En esta página, se detallan las diferencias de versión en las HAL de la cámara, las APIs y las pruebas asociadas del conjunto de pruebas de compatibilidad (CTS). También se abordan varios cambios de arquitectura realizados para endurecer 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 cámaras.

Terminología

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

Cámara API1

El framework de la cámara a nivel de la app en dispositivos con Android 4.4 y versiones anteriores, expuesto a través de la clase android.hardware.Camera.

API2 de Camera

El framework de la cámara a nivel de la app en dispositivos Android 5.0 y versiones posteriores, expuesto a través del paquete android.hardware.camera2.

HAL de la cámara

La capa del módulo de la cámara que implementan los proveedores de SoC. Los frameworks públicos a nivel de la app se compilan sobre el HAL de la cámara.

HAL3.1 de la cámara

Versión de la HAL del dispositivo de la cámara lanzada con Android 4.4.

HAL3.2 de la cámara

Versión de la HAL del dispositivo de la cámara lanzada con Android 5.0.

CTS de la API1 de Camera

Conjunto de pruebas de CTS de la cámara que se ejecutan en la API de Camera1.

CTS de API2 de Camera

Conjunto adicional de pruebas de CTS de la cámara que se ejecutan en la API de Camera2.

Treble

Separa la implementación del proveedor (software específico del dispositivo y de nivel inferior que escriben los fabricantes de silicio) del framework del SO Android a través de una nueva interfaz de proveedor.

HIDL

Lenguaje de definición de interfaz de HAL que se introdujo con Treble y se usa para especificar la interfaz entre un HAL y sus usuarios.

VTS

Se presentó el paquete de pruebas de proveedores junto con Treble.

APIs de Camera

Android incluye las siguientes APIs de la cámara.

API de Camera1

En Android 5.0, se dio de baja la API de Camera 1, que continúa desapareciendo gradualmente a medida que el desarrollo de una nueva plataforma se centra en la API 2 de Camera. Sin embargo, el período de eliminación gradual será prolongado, y las versiones de Android seguirán admitiendo apps de Camera API1 durante un tiempo. Específicamente, se seguirá brindando asistencia para lo siguiente:

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

API2 de Camera

El framework de la API2 de la cámara expone a la app un control de cámara de nivel inferior, incluidos flujos de transmisión o ráfaga eficientes sin copia y controles por fotograma de exposición, ganancia, ganancias de balance de blancos, conversión de colores, reducción de ruido, nitidez y mucho más. Para obtener más información, mira la descripción general del video de Google I/O.

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

• LEGACY: Estos dispositivos exponen funciones a las apps a través de las interfaces de la API2 de Camera, que son aproximadamente las mismas que las expuestas a las apps a través de las interfaces de la API1 de Camera. El código de los frameworks heredados traduce conceptualmente 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 funciones de la API2 de Camera (pero no todas) y deben usar la HAL de la cámara 3.2 o una versión posterior.
• FULL: Estos dispositivos admiten todas las funciones principales de la API de Camera2 y deben usar Camera HAL 3.2 o versiones posteriores, y Android 5.0 o versiones posteriores.
• LEVEL_3: Estos dispositivos admiten el reprocesamiento de YUV y la captura de imágenes RAW, junto con 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 la lente, o que tengan velocidades de fotogramas 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 API2 de la cámara. Los dispositivos FULL requieren las capacidades de MANUAL_SENSOR y MANUAL_POST_PROCESSING, entre otras. La función RAW es opcional incluso para dispositivos FULL. Los dispositivos LIMITED pueden anunciar cualquier subconjunto de estas funciones, incluso ninguno. Sin embargo, la capability BACKWARD_COMPATIBLE siempre se debe definir.

El nivel de hardware compatible del dispositivo, así como las capacidades específicas de la API de Camera2 que admite, están disponibles como las siguientes marcas de función para permitir que Google Play filtre 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 cámara del CTS de API1, el CTS de Camera API2 y el verificador del CTS.

Los dispositivos que no cuentan con una implementación de Camera HAL3.2 y que no son compatibles con las interfaces completas de la API2 de Camera deben aprobar las pruebas de CTS de la API2 de Camera. 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 de manera conceptual a las llamadas a la API de Camera1), por lo que se omiten automáticamente las pruebas de 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 la API de Camera2 que se ejecutan usan las interfaces y funciones públicas existentes de la API de Camera1 sin requisitos nuevos. Los errores que se exponen (y que causan una falla de CTS de la API de Camera2) ya están presentes en el 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 muchos errores de esta naturaleza (sin embargo, deben corregirse para pasar las pruebas del CTS de API2 de Camera).

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 marco de trabajo de la cámara

Para endurecer la seguridad del framework de la cámara y el contenido multimedia, Android 7.0 quita el servicio de la cámara de mediaserver. A partir de Android 8.0, cada HAL de cámara enlazada 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 API y HAL que estén en uso. 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 la API1 puede suponer que la cámara y el codificador de video se encuentran en el mismo proceso. Cuando se usa la API1 en los siguientes dispositivos:

• En HAL3, en el que el servicio de la cámara usa BufferQueue para pasar búferes entre procesos, no se necesita ninguna actualización del proveedor.

  

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

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

  

  Figura 2: Pila de medios y cámara de Android 7.0 en el nivel de API 1 en HAL 1

Cambios en la 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 los siguientes dispositivos:

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

  

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

Requisitos adicionales

Los cambios de arquitectura realizados para endurecer la seguridad del framework de la cámara y el contenido multimedia incluyen los siguientes requisitos adicionales del dispositivo.

• General. Los dispositivos requieren ancho de banda adicional debido al IPC, lo que puede afectar los casos de uso de la cámara 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 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 proceso nuevo.
• Envía 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 controladores nativos de forma correcta.
• La dirección del identificador de búfer no siempre almacena el mismo búfer (solo HAL3). Para cada solicitud de captura, HAL3 obtiene las direcciones de los controladores de búfer. La HAL no puede usar las direcciones para identificar búferes porque las direcciones pueden almacenar otro controlador de búfer después de que la HAL lo muestre. Debes actualizar el sistema HAL para usar controladores de búfer para identificar los búferes. Por ejemplo, la HAL recibe una dirección de controlador de búfer A, que almacena el controlador de búfer A. Después de que 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 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 otorgarle los permisos adecuados a mediaserver. No recomendamos replicar las políticas de SELinux de mediaserver para cameraserver (ya que mediaserver y cameraserver suelen requerir recursos diferentes 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. Además, Android 8.0 y las versiones posteriores separan la HAL de la cámara vinculada en un proceso diferente al de cameraserver. El IPC pasa por interfaces definidas por HIDL.

Validación

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

Para todos los dispositivos que incluyen una cámara y ejecutan Android 8.0 y versiones posteriores, ejecuta VTS para verificar la implementación del proveedor.

Historial de versiones de la HAL de la cámara

Si quieres obtener una lista de pruebas disponibles para evaluar la HAL de la cámara de Android, consulta la Lista de tareas de pruebas de la HAL de la cámara.

Android 10

Android 10 incluye las siguientes actualizaciones.

API de cámara

• Mejoras en la función de varias cámaras que permiten que las cámaras físicas se usen de forma individual o a través de las cámaras lógicas correspondientes ocultando los IDs de las cámaras físicas. Consulta Compatibilidad con varias cámaras.
• Posibilidad de verificar si se admite una configuración de sesión en particular sin la sobrecarga de rendimiento de crear una sesión nueva. Consulta CameraDevice.
• Capacidad para recuperar configuraciones de transmisión recomendadas para un caso de uso determinado para que el cliente sea más eficiente en el uso de energía y tenga un mejor rendimiento. Consulta getRecommendedStreamConfigurationMap.
• Compatibilidad con el formato de imagen JPEG de profundidad Para obtener más detalles, consulta las especificaciones de profundidad dinámica.
• Compatibilidad con el formato de imagen HEIF Consulta el artículo sobre imágenes de HEIF.
• Mejoras de privacidad. Se requieren ciertas claves para que el cliente tenga permisos de CAMERA antes de que se puedan recuperar de CameraCharacteristics. Consulta getKeysNeedingPermission.

HAL de la cámara

Las siguientes versiones de la HAL de la cámara se actualizaron en Android 10.

3.5

ICameraDevice

• getPhysicalCameraCharacteristics: Es la información de la cámara estática para un ID de cámara física que respalda un dispositivo de cámara lógica. Consulta Compatibilidad con varias 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. Consulta la API para consultar combinaciones de transmisiones.

ICameraDeviceSession

• isReconfigurationNeeded: Es un método que le indica al framework de la cámara si se requiere la reconfiguración completa de la transmisión para posibles valores de parámetros de sesión nuevos. De esta manera, se evitan 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 la 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 acoplar cada solicitud de captura con los búferes asociados a lo largo de la canalización de la cámara, lo que genera un ahorro de memoria potencialmente significativo.
  • signalStreamFlush: Indica a la HAL que el servicio de la cámara está a punto de realizar configureStreams_3_5 y que la HAL debe mostrar todos los búferes de las transmisiones designadas.
  • configureStreams_3_5: Es 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: Llamada de devolución de llamada síncrona que llama el HAL de la cámara para solicitar 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
• Parámetros de configuración disponibles para la transmisión de profundidad dinámica
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
• Configuraciones de transmisión de 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 de módulos de cámara se actualizan 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, afecten a la cámara y al enrutamiento.

2.4

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

Android 9

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

API de cámara

• Se presenta la API de varias cámaras para admitir mejor los dispositivos con varias cámaras orientadas en la misma dirección, lo que habilita funciones como el bokeh y el zoom uniforme. 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.
• Presenta 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.
• Agrega 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 la memoria flash externa. Consulta CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
• Agrega un intent de seguimiento de movimiento en CAPTURE_INTENT. Consulta CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
• LENS_RADIAL_DISTORTION deja de estar disponible y se agrega 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 a ICameraDeviceSession

• configureStreams_3_4: Agrega compatibilidad con sessionParameters y cámaras lógicas.
• processCaptureRequest_3_4: Agrega compatibilidad para incluir IDs de cámaras físicas en la estructura de transmisión.

Actualizaciones a ICameraDeviceCallback

• processCaptureResult_3_4: Agrega metadatos de la cámara física en los resultados de la captura.

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 presenta Treble. Con Treble, las implementaciones de HAL de la 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: Habilita varias superficies que comparten 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 la cámara y de gralloc puedan crear búferes de gralloc que usen varios consumidores diferentes (como el compositor de hardware/GPU y el codificador de video), en lugar de solo uno. El servicio de la cámara pasa las marcas de uso del consumidor al HAL de la cámara y al HAL de gralloc. Deben asignar los tipos de búferes correctos, o bien el HAL de la cámara debe mostrar un error que indique que no se admite esta combinación de consumidores.

Consulta la documentación para desarrolladores de enableSurfaceSharing 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 operación: grabación normal y restringida de alta velocidad. Tienen una semántica bastante diferente. Por ejemplo, el modo de alta velocidad se limita a dos salidas específicas como máximo a la vez. Varios OEMs expresaron interés en definir otros modos personalizados para capacidades específicas de hardware. En el fondo, 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 del OEM pueden usar para habilitar un modo personalizado. Estos modos deben comenzar en 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.

Nota: En la versión de Android 8.1, las apps deben estar preinstaladas en la imagen del sistema para acceder a esta API.

onCaptureQueueEmpty

El propósito de esta API es reducir la latencia de los cambios de control, como el zoom, manteniendo la lista de solicitudes lo más vacía posible. onCaptureQueueEmpty no requiere trabajo de HAL; fue solo una adición del 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, se hace mediante el envío de otra solicitud de captura al dispositivo de cámara.

Interfaz 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 cámara presentadas 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 del HIDL.

3.4

Se agregaron elementos menores a los metadatos admitidos y se realizaron cambios en la compatibilidad con data_space:

• Agrega metadatos estáticos ANDROID_SENSOR_OPAQUE_RAW_SIZE como obligatorios si se admite el formato RAW_OPAQUE.
• Agrega metadatos estáticos ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE como obligatorios si se admite algún formato RAW.
• Cambia el campo camera3_stream_t data_space a una definición más flexible, con la definición de versión 0 de la codificación de espacios de datos.
• Adiciones generales de metadatos que están disponibles para usar en 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 menor del HAL de capacidades expandidas:

• Actualizaciones de la API de reprocesamiento de OPAQUE y YUV.
• Compatibilidad básica con búferes de salida de profundidad
• Adición del campo data_space a camera3_stream_t.
• Adición del 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 menor de la HAL de capacidad expandida:

• Deja de estar disponible get_metadata_vendor_tag_ops. En su lugar, usa get_vendor_tag_ops en camera_common.h.
• Deja de estar disponible register_stream_buffers. Todos los búferes de gralloc que el framework proporciona a HAL en process_capture_request pueden ser nuevos en cualquier momento.
• Se agregó compatibilidad con resultados parciales. Es posible que se llame a process_capture_result varias veces con un subconjunto de los resultados disponibles antes de que el resultado completo esté disponible.
• Se agregó una plantilla manual a camera3_request_template. Las apps pueden usar esta plantilla para controlar la configuración de captura directamente.
• Vuelve a trabajar en las especificaciones de flujo de entrada y bidireccional.
• Cambia la ruta de acceso de retorno del búfer de entrada. El búfer se muestra en process_capture_result en lugar de process_capture_request.

3.1

Revisión menor del HAL de capacidades expandidas:

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

3.0

Primera revisión del HAL de capacidades expandidas:

• Cambio de versión importante, ya que la ABI es completamente diferente. No hay cambios en las capacidades de hardware ni en el modelo operativo requeridos a partir de la versión 2.0.
• Se modificaron las interfaces de solicitud de entrada y cola de transmisión: el framework llama a HAL con la siguiente solicitud y los búferes de transmisión ya quitados de la cola. Se incluye la compatibilidad con el framework de sincronización, que es necesaria para implementaciones eficientes.
• Se movieron 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 a 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 capacidades expandidas (Android 4.2) [camera2.h]:

• Suficiente para implementar la API de android.hardware.Camera existente.
• Permite la cola de ZSL en la capa de servicio de la cámara.
• No se probó en ninguna función nueva, como el control de captura manual, la captura en formato RAW Bayer, 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 de CameraHardwareInterface de C++.
• Admite 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, basado en 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

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

1. Compatibilidad con el modo linterna. El framework puede activar el modo linterna para cualquier dispositivo de cámara que tenga una unidad de flash, sin necesidad de abrir un dispositivo de cámara. El dispositivo de la cámara tiene una prioridad más alta para acceder a la unidad de flash que el módulo de la cámara. Si se abre un dispositivo de cámara, se apaga la linterna si se habilitó 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 linterna que se desactivó el modo linterna.
2. Compatibilidad con cámaras externas (por ejemplo, cámaras con conexión en caliente USB). 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 usar en cámaras externas con conexión en caliente. Las llamadas para obtener información estática son llamadas no válidas cuando el estado de la cámara no es CAMERA_DEVICE_STATUS_PRESENT. El framework solo cuenta con 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 manera explícita la cantidad de dispositivos de cámara que se pueden abrir y usar al mismo tiempo. Para especificar combinaciones válidas de dispositivos, los campos resource_cost y conflicting_devices siempre deben establecerse en la estructura camera_info que muestra la llamada get_camera_info.
4. Método de inicialización del módulo. El servicio de la cámara lo llama después de que se carga el módulo HAL para permitir la inicialización única del HAL. Se lo llama antes de que se invoquen otros métodos del módulo.

2.3

Esta versión del módulo de cámara agrega compatibilidad con dispositivos HAL de cámara heredados abiertos. El framework puede usarlo para abrir el dispositivo de la cámara como un dispositivo HAL de versión inferior si el mismo dispositivo puede admitir varias versiones de API del 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 que se indica en camera_info_t.device_version.

2.2

Esta versión del módulo de la cámara agrega compatibilidad con la etiqueta del proveedor desde el módulo y da de baja el vendor_tag_query_ops anterior al que solo se podía acceder con un dispositivo abierto.

2.1

Esta versión del módulo de 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 2.0 de la interfaz de 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 de 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 de la HAL del dispositivo de cámara. 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 de android.hardware.Camera.