Compatibilidad con la versión de la cámara

En esta página, se detallan las diferencias de versiones entre las HAL de la cámara, las APIs y las APIs Pruebas del Conjunto de pruebas de compatibilidad (CTS) También abarca varias cambios arquitectónicos 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 las implementaciones de su cámara.

Terminología

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

Cámara API1

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

Cámara API2

Se expuso el framework de la cámara a nivel de la app en dispositivos con Android 5.0 y versiones posteriores. a través del paquete android.hardware.camera2.

HAL de cámara

La capa del módulo de la cámara que implementan los proveedores de SoC. El público a nivel de la app se construyen 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.

Cámara HAL3.2

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

CTS de API1 de cámara

Conjunto de pruebas del CTS de la cámara que se ejecutan en la parte superior de la Cámara API1

CTS de API2 de cámara

Conjunto adicional de pruebas del CTS de cámara que se ejecutan sobre la API2 de Camera.

Treble

Separa la implementación del proveedor (software específico para el dispositivo, software de menor nivel). escrito por fabricantes de Silicon) desde el framework del SO Android hasta un nuevo y del proveedor de servicios en la nube.

HIDL

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

VTS

Se presenta el paquete de pruebas de proveedores junto con Agudo.

APIs de cámara

Android incluye las siguientes API de cámara.

Cámara API1

En Android 5.0, la API de Camera 1 dejó de estar disponible, y continúa eliminando gradualmente a medida que se incorporan de la plataforma se centra en la API2 de Camera. Sin embargo, el período de eliminación gradual y los lanzamientos de Android continuarán admitiendo apps de Camera API1 para algún tiempo. Específicamente, la compatibilidad continúa con lo siguiente:

• Interfaces de API 1 de Cámara para apps. Apps de cámara integradas en Cámara API1 debería funcionar como en dispositivos con versiones anteriores de Android.
• Versiones de la HAL de la cámara Incluye compatibilidad con la HAL 1.0 de la cámara.

Cámara API2

El framework de Camera API2 expone el control de cámara de nivel inferior a la app, como flujos eficientes de picos de actividad/transmisión y controles por fotograma de exposición, ganancia, ganancias del balance de blancos, conversión de color, reducción de ruido, nitidez, y más. Para obtener más información, mira la Descripción general de los videos de Google I/O

Android 5.0 y las versiones posteriores incluyen la API de Camera; Sin embargo, los dispositivos con Android Es posible que 5.0 y las versiones posteriores no admitan todas las funciones de Camera API2. El Propiedad android.info.supportedHardwareLevel que las apps pueden consultar Mediante las interfaces API2 de Camera, informa una de las siguientes opciones de compatibilidad: niveles:

• LEGACY: Estos dispositivos exponen capacidades a las apps a través de la Interfaces de API2 de Camera que tienen aproximadamente las mismas capacidades que aquellas a las apps a través de las interfaces de Camera API1. El código de los frameworks heredados traduce conceptualmente las llamadas a la API2 de Camera en llamadas a la API1 de Camera; dispositivos heredados No son compatibles con las funciones de la API 2 de Camera, por ejemplo, los controles por fotograma.
• LIMITED: Estos dispositivos admiten algunas capacidades de Camera API2 (pero no todas), y debe usar la HAL de la cámara 3.2 o una versión posterior.
• FULL: Estos dispositivos admiten todas las funciones principales de Cámara API2 y debe usar la HAL de la cámara 3.2 o superior y Android 5.0 o superior.
• LEVEL_3: Estos dispositivos admiten el reprocesamiento de YUV y la imagen RAW. junto con parámetros de configuración adicionales de transmisión de salida.
• EXTERNAL: Estos dispositivos son similares a LIMITED dispositivos, con algunas excepciones; por ejemplo, parte de la información del sensor o la lente no se informan o tienen velocidades de fotogramas menos estables. Este nivel se usa para métricas como cámaras web USB.

Las capacidades individuales se exponen a través del Propiedad android.request.availableCapabilities en la API 2 de Camera interfaces. Los dispositivos FULL requieren MANUAL_SENSOR y MANUAL_POST_PROCESSING, entre otras. El La función RAW es opcional incluso para dispositivos FULL. Los dispositivos LIMITED pueden promocionar cualquier subconjunto de estas funciones, incluidos ninguno de ellos. Sin embargo, la función BACKWARD_COMPATIBLE siempre debe definirse.

El nivel de hardware compatible con el dispositivo y la cámara específica API2 compatibles, están disponibles como las siguientes marcas de función para Permite que Google Play filtre las apps de cámara con API2 de Camera.

• 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 el CTS de Camera API1, Camera Pruebas de cámara del CTS de API2 y el verificador del CTS.

Dispositivos que no cuentan con una implementación de cámara HAL3.2 y no lo están compatibles con todas las interfaces API2 de Camera deben pasar la API de Pruebas del CTS de API2 Sin embargo, el dispositivo se ejecuta en la API2 de Camera Modo LEGACY (en el que las llamadas a la API2 de Camera se asignan conceptualmente a las llamadas a la API2 de Camera) a las llamadas de API1 de Camera) por lo que cualquier prueba del CTS de API2 de Camera relacionada con las funciones o otras funciones además de la API 1 de Camera se omiten automáticamente.

En dispositivos heredados, las pruebas del CTS de API2 de Camera que se ejecutan usan el interfaces y capacidades públicas existentes de Camera API1 sin y los requisitos de cumplimiento. Errores expuestos (y que causan una falla del CTS API2 de Camera) son errores que ya están presentes en la HAL de la cámara existente del dispositivo y, por lo tanto, pueden encontrar las apps con la API 1 de Camera. No esperamos muchos errores de esta naturaleza. (Sin embargo, se deben corregir esos errores 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 enlazadas deben pasar la cámara Pruebas de VTS:

Endurecimiento del marco de trabajo de la cámara

Para reforzar la seguridad del marco de trabajo de contenido multimedia y cámara, Android 7.0 mueve la cámara fuera de mediaserver. A partir de Android 8.0, cada Cámara Binderizada La HAL se ejecuta en un proceso independiente del servicio de cámara. Es posible que los proveedores deban tomar cambios en la HAL de la cámara según las versiones de API y HAL que estén en uso El En las siguientes secciones, se detallan los cambios arquitectónicos en AP1 y AP2 para HAL1 y HAL3, así como los requisitos generales.

Cambios de arquitectura para API1

La grabación de video API1 puede suponer que la cámara y el codificador de video están conectados a la misma el proceso de administración de recursos. Cuando se usa API1 en:

• HAL3, donde el servicio de cámara usa BufferQueue para pasar búferes No es necesario actualizar el proveedor.

  

  Figura 1: Cámara y contenido multimedia de Android 7.0 Pila en API1 en HAL3

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

  

  Figura 2: Cámara y contenido multimedia de Android 7.0 Pila en API1 en HAL1

Cambios de arquitectura para API2

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

• La HAL1 no se ve afectada por el movimiento del servicio de cámara y ningún proveedor actualización es necesaria.
• La HAL3 se ve afectada, pero no hay actualizaciones del proveedor. necesario:

  

  Figura 3: Cámara y contenido multimedia de Android 7.0 Pila en API2 en HAL3

Requisitos adicionales

Los cambios arquitectónicos que se realizaron para endurecer el framework de medios y cámaras 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 en los que el tiempo es importante, como las transmisiones de video de alta velocidad grabación. Los proveedores pueden medir el impacto real ejecutando android.hardware.camera2.cts.PerformanceTest y la Cámara de Google para grabar videos de alta velocidad a 120/240 FPS. Los dispositivos también requieren pequeña cantidad de RAM adicional para crear el nuevo proceso.
• Pasar metadatos en búferes de video (solo para HAL1) Si es HAL1 en lugar de datos de fotogramas YUV reales en búferes de video, la HAL debe Usa kMetadataBufferTypeNativeHandleSource como el búfer de metadatos. escribe y pasa VideoNativeHandleMetadata en búferes de video. (kMetadataBufferTypeCameraSource ya no es compatible con Android 7.0.) Con VideoNativeHandleMetadata, marcos de trabajo de cámara y contenido multimedia pasan los búferes de video entre procesos mediante la serialización deserializar los controladores nativos correctamente.
• La dirección del controlador de búfer no siempre almacena el mismo (solo para HAL3). Para cada solicitud de captura, la HAL3 obtiene las direcciones del búfer controladores. La HAL no puede usar las direcciones para identificar los búferes porque estas puede almacenar otro controlador de búfer después de que la HAL lo muestre. Debes actualizar la HAL para usar controladores de búferes para identificarlos. Por ejemplo, la HAL recibe una dirección del controlador de búfer A, que almacena el controlador de búfer A. Después de que regresa la HAL controlador de búfer A, la dirección del controlador de búfer A puede almacenar el controlador de búfer B la próxima vez que La HAL lo recibe.
• 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, debe actualizar las políticas de SELinux para otorgar los permisos adecuados de cameraserver. Mié no se recomienda la replicación de las políticas de SELinux de mediaserver para cameraserver (ya que mediaserver y cameraserver generalmente requieren recursos diferentes en el de configuración del sistema). Cameraserver solo debe tener los permisos necesarios para ejecutar la cámara y cualquier permiso innecesario relacionado con la cámara en mediaserver deben quitarse.
• Separación entre la HAL de la cámara y el cameraserver. En Android Además, las versiones 8.0 y posteriores separan la HAL de la cámara vinculada en un proceso. es diferente de cameraserver. que la IPC Interfaces definidas por HIDL.

Validación

Para todos los dispositivos que incluyan una cámara y ejecuten Android 7.0, verifica el con la ejecución del CTS de Android 7.0. Aunque Android 7.0 no incluye nuevas pruebas del CTS que verifican los cambios en el servicio de la cámara; las pruebas del CTS existentes fallan si no realizaste las actualizaciones que se indican arriba.

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

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 el Prueba de la HAL de la cámara Lista de tareas

Android 10

Android 10 incluye las siguientes actualizaciones.

API de cámara

• Mejoras en varias cámaras que permiten que las cámaras físicas usarse individualmente o con las cámaras lógicas correspondientes ocultando IDs de cámaras físicas. Consulta Compatibilidad con varias cámaras.
• Puede verificar si una configuración de sesión específica está sin la sobrecarga de rendimiento que conlleva crear una sesión nueva. Consulta CameraDevice
• Capacidad de recuperar la configuración de transmisión recomendada para un uso determinado para que el cliente tenga un mayor rendimiento y eficiencia energética. Consulta getRecommendedStreamConfigurationMap
• Compatibilidad con formato de imagen JPEG de profundidad. Para obtener más detalles, consulta la Especificación de profundidad dinámica.
• Compatibilidad con Formato de imagen HEIC. Consulta Procesamiento de imágenes HEIF.
• Mejoras en la privacidad Ciertas claves son necesarias para el cliente para tener los permisos CAMERA antes de que se puedan recuperar CameraCharacteristics Consulta getKeysNeedingPermission

HAL de cámara

Se actualizaron las siguientes versiones de la HAL de la cámara en Android.

3.5

ICameraDevice

• getPhysicalCameraCharacteristics: La información de la cámara estática para un ID de cámara físico que respalda un valor lógico dispositivo de cámara. Consulta Compatibilidad con varias cámaras.
• isStreamCombinationSupported: Este método admite un bucket API que ayuda a los clientes a consultar si se admite una configuración de sesión. Consulta API para consultar combinaciones de flujos.

ICameraDeviceSession

• isReconfigurationNeeded: Método que le indica al framework de la cámara si completa la transmisión se requiere reconfiguración para los posibles valores de parámetros de sesión nuevos. Esta ayuda a evitar demoras innecesarias en la reconfiguración de la cámara. Consulta Consulta de reconfiguración de sesión.
• HAL APIs de administración de búfer: 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 uno una solicitud de captura con sus búferes asociados a lo largo de la canalización de la cámara. lo que genera un ahorro de memoria potencialmente significativo.
  • signalStreamFlush: Le indica a la HAL que la cámara. servicio 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 en además, el contador streamConfigCounter se proporciona a verificar una condición de carrera entre configureStreams_3_5 y signalStreamFlush.

Actualizaciones a ICameraDeviceCallback:

• requestStreamBuffers: Devolución de llamada síncrona que la HAL de la cámara llama para solicitar al servidor de la cámara tiempos de reserva. Consulta requestStreamBuffers
• returnStreamBuffers: Es la devolución de llamada síncrona para que la HAL de la cámara devuelva los búferes de salida al del servidor de la cámara. Consulta returnStreamBuffers

3.4

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

• Formatos de imagen
  • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
  • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
  • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
• Etiquetas de metadatos de la cámara
  • ANDROID_REQUEST_CHARACTERISTIC_KEYS_NEEDING_PERMISSION
  • ANDROID_SCALER_AVAILABLE_RECOMMENDED_STREAM_CONFIGURATIONS
  • ANDROID_SCALER_AVAILABLE_RECOMMENDED_INPUT_OUTPUT_FORMATS_MAP
  • ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION
  • ANDROID_DEPTH_AVAILABLE_RECOMMENDED_DEPTH_STREAM_CONFIGURATIONS
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_MIN_FRAME_DURATIONS
  • ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
  • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS
  • ANDROID_HEIC_AVAILABLE_HEIC_MIN_FRAME_DURATIONS
  • ANDROID_HEIC_AVAILABLE_HEIC_STALL_DURATIONS
  • ANDROID_HEIC_INFO_SUPPORTED
  • ANDROID_HEIC_INFO_MAX_JPEG_APP_SEGMENTS_COUNT
• Capacidades
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
• Valores para ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT tecla
  • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
  • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
• Opciones de configuración 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

Se actualizaron las siguientes versiones del módulo de cámara en Android

2.5

• Agrega el método notifyDeviceStateChange para que los dispositivos envíen notificaciones. la HAL de la cámara cuando los cambios físicos, como el plegado, afectan la de alto rendimiento.

2.4

• Los dispositivos que se lanzan con nivel de API 29 o versiones posteriores DEBEN informar true por isTorchModeSupported.

Android 9

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

API de cámara

• Presenta la API de varias cámaras para admitir mejor dispositivos con varias apuntando en la misma dirección, lo que permite funciones como bokeh y zoom fluido. Esto permite que las apps vean varias cámaras en un dispositivo como una sola. unidad lógica (cámara lógica). Las solicitudes de captura también pueden enviarse o dispositivos de cámara en función de 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 provocar retrasos graves en el procesamiento cuando modificados. Estos costos pueden mitigarse 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 a nivel de la app y efectos. Consulta STATISTICS_OIS_SAMPLES
• Se agrega 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
• LENS_RADIAL_DISTORTION deja de estar disponible y 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 USB/UVC externas en dispositivos compatibles. Consulta INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL

HAL de cámara

3.4

Actualizaciones de ICameraDeviceSession

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

Actualizaciones de 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.

• 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 Treble, HAL de la cámara del proveedor implementaciones deben ser vinculados. Android 8.0 también incluye estas mejoras clave al servicio de Cámara:

• Plataformas compartidas: Habilita varias plataformas que compartan la misma OutputConfiguration
• API del sistema para modos de cámara personalizados
• onCaptureQueueEmpty

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

Plataformas compartidas

Esta función permite que un solo conjunto de búferes controle dos salidas, como vista previa y codificación de video, lo que reduce el consumo de energía y memoria. Para compatibilidad con esta función, los fabricantes de dispositivos deben asegurarse de que la HAL de la cámara y Las implementaciones de HAL de gralloc pueden crear búferes gralloc que usan varios consumidores diferentes (como el compositor de hardware/GPU y el codificador), en lugar de un solo consumidor. El servicio de cámara pasa la marcas de uso del consumidor en la HAL de la cámara y la HAL de gralloc tienen que asignar los tipos correctos de búferes, o la HAL de la cámara deberá mostrar un error que esta combinación de consumidores no es compatible.

Consulta la enableSurfaceSharing documentación para desarrolladores y obtén 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 restringido y grabar a alta velocidad. 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 Los OEMs expresaron interés en definir otros modos personalizados para específicas del hardware. De forma interna, el modo es solo un número pasado a configure_streams. Consulta lo siguiente: 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 con un número entero 0x8000 para evitar conflictos con los modos Future agregados a la API pública.

Para admitir esta función, los OEM solo deben agregar el modo nuevo a su HAL, activado por este valor entero que se pasa a la HAL en configure_streams y, luego, su aplicación de cámara personalizada usen la API del sistema.

El nombre del método es android.hardware.camera2.CameraDevice#createCustomCaptureSession. Consulta lo siguiente: 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 y mantener la lista de solicitudes lo más vacía posible. onCaptureQueueEmpty no requiere trabajo de HAL. solo se trató de un agregado del framework. Aplicaciones que Si quieres aprovecharla, debes agregar un objeto de escucha a esa devolución de llamada y responder apropiadamente. Por lo general, se hace mediante el envío de otra solicitud de captura a la cámara. dispositivo.

Interfaz HIDL de la cámara

La interfaz del HIDL de la cámara es una revisión completa de la interfaz de la HAL de la cámara que usa APIs estables definidas por HIDL. Todas las funciones y capacidades de la cámara introducidos en las versiones heredadas más recientes, 3.4 y 2.4 (para el conjunto de también forman parte de las definiciones de HIDL.

3.4

Adiciones menores a metadatos compatibles y 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 una imagen estática de ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE metadatos como obligatorios si se admite cualquier formato RAW.
• Cambiar el campo camera3_stream_t data_space a un campo más flexible con la definición de la versión 0 de la codificación de espacios de datos.
• Adiciones de metadatos generales 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 de la HAL de capacidad expandida:

• Actualizaciones de las APIs 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.
• Adición del modo de operación de configuración de transmisión de camera3 a camera3_stream_configuration_t

3.2

Revisión menor de la HAL de capacidad expandida:

• get_metadata_vendor_tag_ops deja de estar disponible. Usa get_vendor_tag_ops en camera_common.h en su lugar.
• register_stream_buffers deja de estar disponible. Todos los búferes de gralloc que proporciona el framework a la HAL en process_capture_request podrían ser nuevos. en cualquier momento.
• Se agregó compatibilidad con resultados parciales. Es posible que process_capture_result sea llamado varias veces con un subconjunto de los resultados disponibles antes de la que el resultado está disponible.
• Agregar plantilla manual a camera3_request_template. Aplicaciones puede usar esta plantilla para controlar directamente la configuración de captura.
• Revisar las especificaciones bidireccionales y de flujo de entrada
• Cambia la ruta de acceso 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 la HAL de capacidad expandida:

• configure_streams pasa marcas de uso del consumidor a la HAL.
• llamada de limpieza para descartar todas las solicitudes en tránsito o los búferes lo más rápido posible.

3.0

Primera revisión de la HAL de capacidad expandida:

• Cambio de versión importante, ya que la ABI es completamente diferente. No se realizaron cambios en la las capacidades de hardware o 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: Llamadas al framework en la HAL. con la siguiente solicitud y los búferes de transmisión ya retirados de la cola. Compatibilidad con el marco de trabajo de sincronización necesaria para implementaciones eficientes.
• Se movieron los activadores a las solicitudes; la mayoría de las notificaciones, a los resultados.
• Se consolidaron todas las devoluciones de llamada en un marco de trabajo en una sola estructura en una sola llamada initialize().
• Ahora puedes configurar las transmisiones en una sola llamada para simplificar su administración. Las transmisiones bidireccionales reemplazan a STREAM_FROM_STREAM construir.
• Semántica de modo limitado para dispositivos de hardware antiguos o limitados

2.0

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

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

1.0

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

• Se convirtió desde la capa de abstracción CameraHardwareInterface de C++.
• 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 de los módulos para el hardware de la cámara basado en camera_module_t.common.module_api_version. Los dos los dígitos hexadecimales más significativos representan la versión principal, y los dos dígitos menos significativos representan la versión secundaria.

2.4

Esta versión del módulo de 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 tiene una unidad de flash, sin abrir un dispositivo de cámara. El El dispositivo de la cámara tiene mayor prioridad para acceder a la unidad de flash que la cámara. module; Al abrir un dispositivo de cámara, se apaga la linterna si estaba habilitada a través de la interfaz del módulo. Cuando hay conflictos de recursos, como 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 la linterna se ha desactivado.
2. Compatibilidad con cámara externa (por ejemplo, cámara USB con conexión en caliente). El Las actualizaciones de la API especifican que la información estática de la cámara está disponible solo cuando la cámara que está conectada y lista para usarse para cámaras externas con conexión en caliente. Llamadas a la estática información son llamadas no válidas cuando el estado de la cámara no es CAMERA_DEVICE_STATUS_PRESENT El framework se basa únicamente en 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 explícitamente la cantidad de dispositivos de cámara que se pueden abrir y usar simultáneamente. Para especificar combinaciones válidas de dispositivos, resource_cost y Los campos conflicting_devices siempre deben establecerse en Estructura de camera_info que muestra get_camera_info llamada.
4. Método de inicialización del módulo. Llamada por el servicio de cámara después de que se cargue el módulo de la HAL, para permitir la inicialización única de la HAL. Se llama a este método antes de invocar a cualquier otro método de módulo.

2.3

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

2.2

Esta versión del módulo de cámara agrega compatibilidad con etiquetas del proveedor desde el módulo. da de baja el vendor_tag_query_ops anterior que antes solo estaba accesibles con un dispositivo abierto.

2.1

Esta versión del módulo de cámara agrega compatibilidad con devoluciones de llamada asíncronas al del módulo de la 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 una El método set_callbacks() debe 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 la HAL del módulo de la cámara. Dispositivos de cámara que se pueden abrir con esta puede admitir la versión 1.0 o 2.0 del dispositivo de cámara Interfaz de la HAL. 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 el método Interfaz de la HAL del módulo de la cámara. Todos los dispositivos de cámara se pueden abrir con esta solo admite la versión 1 de la HAL del dispositivo de cámara. El device_version y static_camera_characteristics Los campos de camera_info no son válidos. Solo los La API de android.hardware.Camera puede ser compatible con este módulo y su dispositivos.