Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Compatibilidad con la versión de la cámara

Esta página detalla las diferencias de versión en HAL cámara, APIs y asociados prueba de compatibilidad Suite (CTS) pruebas. También cubre varios cambios arquitectónicos realizados para fortalecer y asegurar 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 las implementaciones de sus cámaras.

Terminología

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

API de cámara1
El marco cámara de nivel aplicación en dispositivos Android 4.4 y versiones anteriores, expuesta a través de la android.hardware.Camera clase.
Cámara API2
El marco cámara de nivel de aplicaciones en Android 5.0 y dispositivos superiores, expuesta a través de la android.hardware.camera2 paquete.
Cámara HAL
La capa del módulo de la 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
HAL lenguaje de definición de interfaz introducida con agudos y se utiliza para especificar la interfaz entre un HAL y sus usuarios.
VTS
Conjunto de pruebas proveedor introdujo junto agudos.

API de cámara

Android incluye las siguientes API de cámara.

API de cámara1

Android 5.0 dejó de usar Camera API1, que continúa eliminándose a medida que el desarrollo de una nueva plataforma se centra en Camera API2. Sin embargo, el período de eliminación será prolongado y las versiones de Android continuarán admitiendo las 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 la cámara HAL1.0.

Cámara API2

El marco Camera API2 expone el control de cámara de nivel inferior a la aplicación, incluidos los eficientes flujos de transmisión / ráfaga sin copia 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 más detalles, ver el vídeo de introducción de Google I / O .

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

  • LEGACY : Estos dispositivos se exponen las capacidades a aplicaciones a través de las interfaces API2 Cámara que son aproximadamente las mismas capacidades que las personas expuestas a aplicaciones a través de las interfaces API1 cámara. El código de marcos heredados traduce conceptualmente las llamadas de Camera API2 en llamadas Camera API1; Los dispositivos heredados no son compatibles con las funciones de Camera API2, como los controles por fotograma.
  • LIMITED : Estos dispositivos soporta algunas de las capacidades de la cámara API2 (pero no todos) y debe utilizar la cámara HAL 3.2 o superior.
  • FULL : Estos dispositivos admiten todas las principales capacidades de la cámara API2 y debe utilizar la cámara HAL 3.2 o superior y Android 5.0 o superior.
  • LEVEL_3 : Estos dispositivos apoyar YUV reprocesamiento y RAW de captura de imagen, junto con las configuraciones adicionales de flujo de salida.
  • EXTERNAL : Estos dispositivos son similares a LIMITED dispositivos con algunas excepciones; por ejemplo, es posible que la información de algunos sensores o lentes no se informe o tenga velocidades de cuadro menos estables. Este nivel se utiliza para cámaras externas como cámaras web USB.

Capacidades individuales están expuestos a través de la android.request.availableCapabilities propiedad en los interfaces de API2 cámara. FULL dispositivos requieren los MANUAL_SENSOR y MANUAL_POST_PROCESSING capacidades, entre otros. El RAW capacidad es opcional incluso para FULL dispositivos. LIMITED dispositivos pueden anunciar cualquier subconjunto de estas capacidades, con inclusión de ninguno de ellos. Sin embargo, el BACKWARD_COMPATIBLE siempre se debe definir la capacidad.

El nivel de hardware admitido del dispositivo, así como las capacidades específicas de Camera API2 que admite, están disponibles como los siguientes indicadores de funciones para permitir el filtrado de Google Play de las aplicaciones de la 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 con Android 5.0 y superior deben aprobar las pruebas de cámara Camera API1 CTS, Camera API2 CTS y CTS Verifier.

Los dispositivos que no cuentan con una implementación de cámara HAL3.2 y no son capaces de admitir todas las interfaces de la cámara API2 aún deben pasar las pruebas de la cámara API2 CTS. Sin embargo, las carreras de dispositivos en la cámara API2 LEGACY modo (en el que las llamadas API2 cámara se asignan a las llamadas conceptualmente API1 cámara) por lo que cualquier cámara API2 CTS pruebas relacionadas con las características o capacidades más allá de la cámara API1 se omiten automáticamente.

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

Requisitos de VTS

Los dispositivos con Android 8.0 y posteriores con las implementaciones de HAL revestidas con un aglutinante deben pasar la cámara pruebas 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 la cámara del servidor de medios. A partir de Android 8.0, cada HAL de cámara enlazada se ejecuta en un proceso independiente del servicio de la cámara. Es posible que los proveedores deban realizar cambios en la cámara HAL según la API y las versiones de 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 viven en el mismo proceso. Al usar API1 en:

  • HAL3, donde el servicio de cámara utiliza BufferQueue pasar memorias intermedias entre los procesos, no hay actualización de proveedor es necesario.

    Cámara de Android 7.0 y pila de medios en API1 en HAL3

    Figura 1. androide 7.0 de la cámara y los medios de comunicación se apilan en API1 en HAL3

  • HAL1, que apoya pasar metadatos en buffers de vídeo, los proveedores deben actualizar la HAL utilizar kMetadataBufferTypeNativeHandleSource . ( kMetadataBufferTypeCameraSource ya no se admite en Android 7.0.)

    Cámara de Android 7.0 y pila de medios en API1 en HAL1

    Figura 2. androide 7.0 de la cámara y los medios de comunicación se apilan en API1 en HAL1

Cambios arquitectónicos para API2

Para API2 en HAL1 o HAL3, BufferQueue pasa búferes para que esas rutas continúen funcionando. La arquitectura de Android 7.0 para API2 en:

  • HAL1 no se ve afectada por el movimiento cameraservice, y no hay ninguna actualización proveedor es necesario.
  • HAL3 es afectada, pero no hay ninguna actualización proveedor es necesario:

    Cámara de Android 7.0 y pila de medios en API2 en HAL3

    Figura 3. androide 7.0 de la cámara y los medios de comunicación se apilan 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 de dispositivos adicionales.

  • General. Los dispositivos requieren ancho de banda adicional debido a IPC, lo que puede afectar los casos de uso de cámaras sensibles al tiempo, como la grabación de video de alta velocidad. Los vendedores pueden medir el impacto real mediante la ejecución de android.hardware.camera2.cts.PerformanceTest y la aplicación Cámara de Google para 120/240 grabación de vídeo de alta velocidad FPS. Los dispositivos también requieren una pequeña cantidad de RAM adicional para crear el nuevo proceso.
  • Pase metadatos en buffers de vídeo (HAL1 solamente). Si almacena HAL1 metadatos en lugar de datos de la trama real de YUV en buffers de vídeo, el HAL deben utilizar kMetadataBufferTypeNativeHandleSource como el tipo de tampón metadatos y pasar VideoNativeHandleMetadata en buffers de vídeo. ( kMetadataBufferTypeCameraSource ya no es compatible con Android 7.0.) Con VideoNativeHandleMetadata , los marcos de la cámara y los medios de comunicación son capaces de pasar los buffers de vídeo entre los procesos de serializar y deserializar los mangos nativos correctamente.
  • Dirección del mango búfer no siempre almacenar el mismo tampón (HAL3 solamente). Para cada solicitud de captura, HAL3 obtiene direcciones de identificadores de búfer. HAL no puede usar las direcciones para identificar búferes porque las direcciones pueden almacenar otro controlador de búfer después de que HAL devuelva el búfer. Debe actualizar la HAL para utilizar identificadores de búfer para identificar los búferes. Por ejemplo, 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 controlador de búfer A, la dirección de controlador de búfer A puede almacenar el controlador de búfer B la próxima vez que HAL lo 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 de servidor de medias para ejecutar la cámara, debe actualizar las políticas de SELinux para otorgar los permisos adecuados al servidor de cámaras. 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 diferentes recursos en el sistema). Cameraserver debe tener solo los permisos necesarios para realizar las funciones de la cámara y debe eliminarse cualquier permiso innecesario relacionado con la cámara en mediaserver.
  • Separación entre Camera HAL y cameraerver. Android 8.0 y superior separan adicionalmente la cámara HAL enlazada en un proceso diferente al servidor de cámaras. IPC pasa por HIDL definidos interfaces.

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 verifiquen los cambios en el servicio de la cámara, las pruebas CTS existentes fallan si no ha 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 HAL de la cámara

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

Android 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 un ID de la cámara física copias de un dispositivo de cámara lógico. Ver Soporte multi-cámara .
  • isStreamCombinationSupported : Este método es compatible con una API pública que ayuda a los clientes consulta si se admite una configuración de sesión. Ver API para combinaciones de flujo consulta .

ICameraDeviceSession

  • isReconfigurationNeeded : Método que le dice al marco de la cámara si se requiere una completa reconfiguración de tren de posibles nuevos valores de los parámetros de sesión. Esto ayuda a evitar demoras innecesarias en la reconfiguración de la cámara. Ver sesión de consulta reconfiguración .
  • API de gestión de memoria intermedia HAL : Estas API permiten a la cámara HAL a los tampones de peticiones provenientes del marco de la cámara sólo cuando sea necesario en lugar de acoplamiento de cada solicitud de captura con sus memorias intermedias asociadas a lo largo de la tubería de la cámara, lo que resulta en un ahorro de memoria potencialmente significativos.
    • signalStreamFlush : señales a la HAL que el servicio de la cámara está a punto de realizar configureStreams_3_5 y que la HAL debe devolver todas las memorias intermedias de corrientes designados.
    • configureStreams_3_5 : Similar a ICameraDevice3.4.configureStreams , pero además, la streamConfigCounter se proporciona contador para comprobar si hay una condición de carrera entre los configureStreams_3_5 y signalStreamFlush llamadas.

Cambios a ICameraDeviceCallback :

  • requestStreamBuffers : devolución de llamada síncrona que la cámara HAL llama para pedir al servidor de cámara de tampones. Ver requestStreamBuffers .
  • returnStreamBuffers : devolución de llamada síncrona para la HAL cámara para volver buffers de salida al servidor de cámara. Ver 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
  • Los valores para el ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT clave
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • Configuraciones de corriente de profundidad dinámica disponibles
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • Configuraciones de flujo 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 la cámara se actualizan en Android 10.

2.5

  • Añade el notifyDeviceStateChange método para dispositivos para notificar a la HAL cámara cuando los cambios físicos, tales como plegado, afectan a la cámara y de enrutamiento.

2.4

  • Artefactos de lanzamiento con el nivel de la API 29 o superior debe reportar true para isTorchModeSupported .

Android 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 ofrecer un mejor soporte a los dispositivos con varias cámaras orientadas en la misma dirección, lo que permite funciones como el bokeh y el 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 abarcados por una cámara lógica. Ver Soporte multi-cámara .
  • 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 causar 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. Ver Parámetros de sesión .
  • Agrega claves de datos de estabilización óptica (OIS) para efectos y estabilización a nivel de aplicación. Ver STATISTICS_OIS_SAMPLES .
  • Agrega soporte para flash externo. Ver CONTROL_AE_MODE_ON_EXTERNAL_FLASH .
  • Añade un seguimiento del movimiento intención de CAPTURE_INTENT . Ver CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • Deprecates LENS_RADIAL_DISTORTION y añade LENS_DISTORTION en su lugar.
  • Añade modos de corrección de distorsión en CaptureRequest . Ver DISTORTION_CORRECTION_MODE .
  • Agrega soporte para cámaras USB / UVC externas en dispositivos compatibles. Ver INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL .

Cámara HAL

3.4

Cambios a ICameraDeviceSession

Cambios a 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 de Android 8.0 presenta Treble. Con agudo, proveedores implementaciones cámara HAL deben ser revestidas con un aglutinante . Android 8.0 también contiene estas mejoras clave para el servicio de la cámara:

  • Superficies compartidas: Habilitar múltiples superficies que comparten el mismo 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 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 cámara HAL y gralloc HAL puedan crear búferes gralloc que sean utilizados por 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 los indicadores de uso del consumidor a la cámara HAL y al gralloc HAL; necesitan asignar los tipos correctos de búferes o la cámara HAL debe devolver un error de que esta combinación de consumidores no es compatible.

Ver el enableSurfaceSharing documentación para desarrolladores para obtener detalles adicionales.

API del sistema para modos de cámara personalizados

La API de 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 un máximo de dos salidas específicas a la vez. Varios OEM han expresado interés en definir otros modos personalizados para capacidades específicas de hardware. Bajo el capó, el modo es sólo un número entero pasado a configure_streams . Ver: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

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

Para admitir esta función, 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 . Ver: 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 ningún 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 de manera adecuada. Generalmente es enviando otra solicitud de captura al dispositivo de la cámara.

Interfaz de cámara HIDL

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

3.4

Adiciones menores a los metadatos admitidos y cambios en la compatibilidad con data_space:

  • Añadir ANDROID_SENSOR_OPAQUE_RAW_SIZE estática metadatos como obligatorio si RAW_OPAQUE se admite el formato.
  • Añadir ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE estática metadatos como obligatorio si se admite cualquier formato RAW.
  • Interruptor camera3_stream_t data_space campo para una definición más flexible, usando la definición de la versión 0 de espacio de datos de codificación.
  • Adiciones de metadatos generales que están disponibles para usar con HALv3.2 o más reciente:
    • 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 búferes de salida de profundidad.
  • Además de data_space campo para camera3_stream_t .
  • Además del campo de rotación para camera3_stream_t .
  • La adición de modo de operación de configuración corriente camera3 a camera3_stream_configuration_t .

3.2

Revisión menor de HAL de capacidad ampliada:

  • Desaprueba get_metadata_vendor_tag_ops . Uso get_vendor_tag_ops en camera_common.h lugar.
  • Desaprueba register_stream_buffers . Todos los tampones gralloc proporcionadas por marco para HAL en process_capture_request pueden ser nuevos en cualquier momento.
  • Agregue soporte de resultado parcial. process_capture_result se puede llamar varias veces con un subconjunto de los resultados disponibles antes de que el resultado completo está disponible.
  • Añadir plantilla de manual para 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 banderas uso de los consumidores a la HAL.
  • flush call para eliminar todas las solicitudes / búferes en vuelo lo más rápido posible.

3,0

Primera revisión de HAL de capacidad ampliada:

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

2.0

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

  • Suficiente para implementar existente android.hardware.Camera API.
  • Permite la cola ZSL en la capa de servicio de la cámara.
  • No probado para ninguna característica nueva como control de captura manual, captura RAW de Bayer, 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 ++.
  • Soporta android.hardware.Camera API.

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

Esta sección contiene información de versiones de módulo para el 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. Soporte de modo antorcha. El marco puede activar el modo de linterna para cualquier dispositivo de cámara que tenga una unidad de flash, sin 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; la apertura de un dispositivo de cámara apaga la antorcha si se ha habilitado a través de la interfaz del módulo. Cuando hay algún conflicto de recursos, tales como open() es llamado para abrir un dispositivo de cámara, el módulo HAL cámara debe notificar al marco a través de la devolución de llamada de estado del modo de la antorcha que el modo de antorcha ha sido desactivado.
  2. Compatibilidad con cámaras externas (por ejemplo, cámara de conexión en caliente USB). Las actualizaciones de la 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 de conexión en caliente. 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 marco cuenta únicamente con las devoluciones de llamada de cambio de estado del dispositivo para administrar la lista de cámaras externas disponibles.
  3. Sugerencias 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 resource_cost y conflicting_devices campos debe estar siempre en el camera_info estructura devuelta por el get_camera_info llamada.
  4. Método de inicialización del módulo. Lo llama el servicio de cámara después de que se carga el módulo HAL para permitir la inicialización única del HAL. Se llama antes de que se invoque cualquier otro método de módulo.

2.3

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

2.2

Esta versión añade soporte módulo de la cámara etiqueta de vendedor del módulo, y desaprueba los viejos vendor_tag_query_ops que anteriormente sólo se puede acceder con un dispositivo abierto.

2.1

Esta versión del módulo de cámara agrega soporte para devoluciones de llamada 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 una válidos set_callbacks() informe método debe 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 device_version campo de la camera_info es siempre válida; la static_camera_characteristics campo de camera_info es válido si el device_version campo 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 device_version y static_camera_characteristics campos de camera_info no son válidos. Sólo el android.hardware.Camera API puede ser apoyado por este módulo y sus dispositivos.