Esta página detalla las diferencias de versión en las HAL de la cámara, las API y las pruebas asociadas del conjunto de pruebas de compatibilidad (CTS) . También cubre varios cambios arquitectónicos realizados para fortalecer y proteger el marco de la cámara en Android 7.0, el cambio a Treble en Android 8.0 y las actualizaciones que los proveedores deben realizar para admitir estos cambios en sus implementaciones de cámara.
Terminología
En esta página se utilizan los siguientes términos:
- Cámara API1
- El marco de trabajo de la cámara a nivel de aplicación en Android 4.4 y dispositivos anteriores, expuesto a través de la clase
android.hardware.Camera
. - Cámara API2
- El marco de la cámara a nivel de aplicación en dispositivos Android 5.0 y superiores, expuesto a través del paquete
android.hardware.camera2
. - Cámara HAL
- La capa del módulo de cámara implementada por los proveedores de SoC. Los marcos públicos a nivel de aplicación se construyen sobre la HAL de la cámara.
- Cámara HAL3.1
- Versión del dispositivo de cámara HAL lanzada con Android 4.4.
- Cámara HAL3.2
- Versión del dispositivo de cámara HAL lanzada con Android 5.0.
- Cámara API1 CTS
- Conjunto de pruebas CTS de cámara que se ejecutan sobre Camera API1.
- Cámara API2 CTS
- Conjunto adicional de pruebas CTS de cámara que se ejecutan sobre Camera API2.
- Triplicar
- Separa la implementación del proveedor (software de nivel inferior específico del dispositivo escrito por fabricantes de silicio) del marco del sistema operativo Android a través de una nueva interfaz de proveedor.
- HIDL
- Lenguaje de definición de interfaz HAL introducido con Treble y utilizado para especificar la interfaz entre una HAL y sus usuarios.
- VTS
- Suite de pruebas de proveedores presentada junto con Treble.
API de cámara
Android incluye las siguientes API de cámara.
Cámara API1
Android 5.0 dejó de usar Camera API1, que sigue desapareciendo a medida que el desarrollo de nuevas plataformas se centra en Camera API2. Sin embargo, el período de eliminación será largo y las versiones de Android seguirán siendo compatibles con 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 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 flujos de transmisión/ráfaga de copia cero eficientes y controles por cuadro de exposición, ganancia, ganancias de balance de blancos, conversión de color, eliminación de ruido, nitidez y más. Para obtener más información, vea la descripción general en video 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. La propiedad android.info.supportedHardwareLevel
que las aplicaciones pueden consultar a través de las interfaces Camera API2 informa uno de los siguientes niveles de soporte:
-
LEGACY
: estos dispositivos exponen capacidades a las aplicaciones a través de las interfaces Camera API2 que son aproximadamente las mismas capacidades que las expuestas a las aplicaciones a través de las interfaces Camera API1. El código de marcos heredados traduce conceptualmente las llamadas Camera API2 en llamadas Camera API1; Los dispositivos heredados no son compatibles con las funciones de Camera API2, como los controles por cuadro. -
LIMITED
: estos dispositivos admiten algunas funciones de Camera API2 (pero no todas) y deben usar Camera HAL 3.2 o superior. -
FULL
: estos dispositivos son compatibles con todas las capacidades principales de Camera API2 y deben usar Camera HAL 3.2 o superior y Android 5.0 o superior. -
LEVEL_3
: estos dispositivos admiten el reprocesamiento YUV y la captura de imágenes RAW, junto con configuraciones de flujo de salida adicionales. -
EXTERNAL
: estos dispositivos son similares a los dispositivosLIMITED
con algunas excepciones; por ejemplo, es posible que la información de algunos sensores o lentes no se informe o tenga velocidades de fotogramas menos estables. Este nivel se utiliza para cámaras externas como cámaras web USB.
Las capacidades individuales se exponen a través de la propiedad android.request.availableCapabilities
. AvailableCapabilities en las interfaces de Camera API2. Los dispositivos FULL
requieren las capacidades MANUAL_SENSOR
y MANUAL_POST_PROCESSING
, entre otras. La capacidad RAW
es opcional incluso para dispositivos FULL
. Los dispositivos LIMITED
pueden anunciar cualquier subconjunto de estas capacidades, incluso ninguna de ellas. Sin embargo, siempre se debe definir la capacidad BACKWARD_COMPATIBLE
.
El nivel de hardware compatible del dispositivo, así como las capacidades específicas de Camera API2 que admite, están disponibles como los siguientes indicadores de función para permitir el filtrado de Google Play de las aplicaciones de cámara Camera API2.
-
android.hardware.camera.hardware_level.full
-
android.hardware.camera.capability.raw
-
android.hardware.camera.capability.manual_sensor
-
android.hardware.camera.capability.manual_post_processing
requisitos CTS
Los dispositivos que ejecutan Android 5.0 y superior deben pasar las pruebas de cámara Camera API1 CTS, Camera API2 CTS y CTS Verifier.
Los dispositivos que no cuenten con una implementación de Camera HAL3.2 y no sean compatibles con las interfaces completas de Camera API2 aún deben pasar las pruebas CTS de Camera API2. Sin embargo, el dispositivo se ejecuta en el modo Camera API2 LEGACY
(en el que las llamadas de Camera API2 se asignan conceptualmente a las llamadas de Camera API1), por lo que cualquier prueba CTS de Camera API2 relacionada con características o capacidades más allá de Camera API1 se omite automáticamente.
En dispositivos heredados, las pruebas CTS de Camera API2 que se ejecutan usan las interfaces y capacidades públicas de Camera API1 existentes sin nuevos requisitos. Los errores que están expuestos (y que causan una falla de 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, las aplicaciones de la API1 de la cámara existentes los encontrarían. No esperamos muchos errores de esta naturaleza (sin embargo, dichos errores deben corregirse para pasar las pruebas CTS de Camera API2).
Requisitos VTS
Los dispositivos que ejecutan Android 8.0 y versiones posteriores con implementaciones HAL enlazadas deben pasar las pruebas Camera VTS .
Endurecimiento del marco de la cámara
Para fortalecer 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 Cámara HAL 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 las versiones de API y HAL en uso. Las siguientes secciones detallan los cambios de arquitectura 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 suponer 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 usa BufferQueue para pasar búferes entre procesos, no es necesaria una actualización del proveedor .
- HAL1, que admite el paso de metadatos en búferes de video, los proveedores deben actualizar HAL para usar
kMetadataBufferTypeNativeHandleSource
. (kMetadataBufferTypeCameraSource
ya no es compatible con Android 7.0).
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 afectado por el movimiento del servicio de cámara y no es necesaria ninguna actualización del proveedor .
- HAL3 se ve afectado, pero no es necesaria una actualización del proveedor :
Requerimientos adicionales
Los cambios en la arquitectura realizados para fortalecer la seguridad del marco de la cámara y los medios incluyen los siguientes requisitos adicionales del dispositivo.
- General. Los dispositivos requieren ancho de banda adicional debido a IPC, lo que puede afectar los casos de uso de cámaras sensibles al tiempo, como la grabación de video de alta velocidad. Los proveedores pueden medir el impacto real ejecutando
android.hardware.camera2.cts.PerformanceTest
y la aplicación Google Camera para grabación de video de alta velocidad de 120/240 FPS. Los dispositivos también requieren una pequeña cantidad de RAM adicional para crear el nuevo proceso. - Pase metadatos en búferes de video ( solo HAL1 ). Si HAL1 almacena metadatos en lugar de datos de cuadros YUV reales en búferes de video, HAL debe usar
kMetadataBufferTypeNativeHandleSource
como tipo de búfer de metadatos y pasarVideoNativeHandleMetadata
en búferes de video. (kMetadataBufferTypeCameraSource
ya no es compatible con Android 7.0). ConVideoNativeHandleMetadata
, los marcos de trabajo de la cámara y los medios pueden pasar los búferes de video entre procesos al serializar y deserializar los identificadores nativos correctamente. - La dirección del controlador del búfer no siempre almacena el mismo búfer ( solo HAL3 ). Para cada solicitud de captura, HAL3 obtiene direcciones de identificadores de búfer. HAL no puede usar las direcciones para identificar búferes porque las direcciones pueden almacenar otro identificador de búfer después de que HAL devuelva el búfer. Debe actualizar la HAL para usar identificadores de búfer para identificar los búfer. Por ejemplo, HAL recibe una dirección de identificador de búfer A, que almacena el identificador de búfer A. Después de que HAL devuelva el identificador de búfer A, la dirección de identificador de búfer A puede almacenar el identificador de búfer B la próxima vez que HAL lo reciba.
- Actualice las políticas de SELinux para cameraserver. Si las políticas de SELinux específicas del dispositivo otorgan permisos al servidor de medios para ejecutar la cámara, debe actualizar las políticas de SELinux para otorgar los permisos adecuados al servidor de la cámara. No recomendamos replicar las políticas de 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 funcionalidades de la cámara y cualquier permiso innecesario relacionado con la cámara en mediaserver debe eliminarse.
- Separación entre Camera HAL y cameraserver. Android 8.0 y versiones posteriores también separan la cámara HAL encuadernada en un proceso diferente al de cameraserver. IPC pasa por interfaces definidas por HIDL .
Validación
Para todos los dispositivos que incluyen una cámara y ejecutan Android 7.0, verifique la implementación ejecutando Android 7.0 CTS. Si bien 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 realizó 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 las pruebas disponibles para evaluar Android Camera HAL, consulte la Lista de verificación de pruebas de Camera HAL .
androide 10
Android 10 presenta las siguientes actualizaciones.
API de cámara
- Mejoras multicámara que permiten el uso de cámaras físicas de forma individual o a través de las correspondientes cámaras lógicas ocultando los ID de las cámaras físicas. Consulte Compatibilidad con varias cámaras .
- Capacidad para verificar si una configuración de sesión en particular es compatible sin la sobrecarga de rendimiento de crear una nueva sesión. Consulte
CameraDevice
. - Capacidad para recuperar configuraciones de transmisión recomendadas para un caso de uso dado para hacer que el cliente sea más eficiente y eficiente en cuanto a energía. Consulte
getRecommendedStreamConfigurationMap
. - Compatibilidad con el formato de imagen JPEG de profundidad . Para obtener más detalles, consulte la especificación de profundidad dinámica .
- Soporte para el formato de imagen HEIC . Consulte Imágenes HEIF .
- Mejoras en la privacidad. Se requieren ciertas claves para que el cliente tenga permisos de
CAMERA
antes de poder recuperarlas deCameraCharacteristics
. ConsultegetKeysNeedingPermission
.
Cámara HAL
Las siguientes versiones de Camera HAL se actualizan en Android 10.
3.5
ICameraDevice
-
getPhysicalCameraCharacteristics
: la información de cámara estática para una ID de cámara física que respalda un dispositivo de cámara lógica. Consulte 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. Consulte API para consultar combinaciones de secuencias .
ICameraDeviceSession
-
isReconfigurationNeeded
: método que le dice al marco de la cámara si se requiere una reconfiguración completa de la transmisión para posibles nuevos valores de parámetros de sesión. Esto ayuda a evitar retrasos innecesarios en la reconfiguración de la cámara. Consulte Consulta de reconfiguración de sesión . - API de administración de búfer HAL : estas API permiten que la HAL de la cámara solicite búferes del marco de la cámara solo cuando sea necesario en lugar de acoplar cada solicitud de captura con sus búferes asociados a lo largo de la canalización de la cámara, lo que resulta en ahorros de memoria potencialmente significativos.
-
signalStreamFlush
: indica a la HAL que el servicio de la cámara está a punto de realizarconfigureStreams_3_5
y que la HAL debe devolver todos los búfer de las secuencias designadas. -
configureStreams_3_5
: similar aICameraDevice3.4.configureStreams
, pero además, el contadorstreamConfigCounter
se proporciona para verificar una condición de carrera entre las llamadasconfigureStreams_3_5
ysignalStreamFlush
.
-
Actualizaciones de ICameraDeviceCallback
:
-
requestStreamBuffers
: devolución de llamada síncrona que la cámara HAL llama para solicitar búferes al servidor de la cámara. ConsulterequestStreamBuffers
. -
returnStreamBuffers
: devolución de llamada síncrona para que la HAL de la cámara devuelva los búferes de salida al servidor de la cámara. ConsultereturnStreamBuffers
.
3.4
Las siguientes claves se agregan a los metadatos de la cámara en Android 10.
- Formatos de imagen
-
ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
-
ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
-
ANDROID_SCALER_AVAILABLE_FORMATS_Y8
-
- Etiquetas de metadatos de la cámara
-
ANDROID_REQUEST_CHARACTERISTIC_KEYS_NEEDING_PERMISSION
-
ANDROID_SCALER_AVAILABLE_RECOMMENDED_STREAM_CONFIGURATIONS
-
ANDROID_SCALER_AVAILABLE_RECOMMENDED_INPUT_OUTPUT_FORMATS_MAP
-
ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION
-
ANDROID_DEPTH_AVAILABLE_RECOMMENDED_DEPTH_STREAM_CONFIGURATIONS
-
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS
-
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_MIN_FRAME_DURATIONS
-
ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
-
ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS
-
ANDROID_HEIC_AVAILABLE_HEIC_MIN_FRAME_DURATIONS
-
ANDROID_HEIC_AVAILABLE_HEIC_STALL_DURATIONS
-
ANDROID_HEIC_INFO_SUPPORTED
-
ANDROID_HEIC_INFO_MAX_JPEG_APP_SEGMENTS_COUNT
-
- Capacidades
-
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
-
- Valores para la clave
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
-
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
-
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
-
- Configuraciones de flujo 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 cámara se actualizan en Android 10.
2.5
-
notifyDeviceStateChange
el método de notificaciónDeviceStateChange para que los dispositivos notifiquen a la HAL de la cámara cuando los cambios físicos, como el plegado, afectan la cámara y el enrutamiento.
2.4
- Los dispositivos que se inician con el nivel de API 29 o superior DEBEN informar
true
paraisTorchModeSupported
.
androide 9
La versión de Android 9 presenta las siguientes actualizaciones para la cámara API2 y la interfaz HAL.
API de cámara
- Presenta la API multicámara para admitir mejor 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 incluidos en una cámara lógica. Consulte Compatibilidad con varias cámaras .
- Introduce los parámetros de la sesión. Los parámetros de sesión son un subconjunto de los parámetros de captura disponibles que pueden 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. Consulte Parámetros de sesión .
- Agrega claves de datos de estabilización óptica (OIS) para estabilización y efectos a nivel de aplicación. Consulte
STATISTICS_OIS_SAMPLES
. - Agrega soporte para flash externo. Consulte
CONTROL_AE_MODE_ON_EXTERNAL_FLASH
. - Agrega una intención de seguimiento de movimiento en
CAPTURE_INTENT
. ConsulteCONTROL_CAPTURE_INTENT_MOTION_TRACKING
. -
LENS_RADIAL_DISTORTION
y agregaLENS_DISTORTION
en su lugar. - Agrega modos de corrección de distorsión en
CaptureRequest
. VerDISTORTION_CORRECTION_MODE
. - Agrega soporte para cámaras USB/UVC externas en dispositivos compatibles. Consulte
INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL
.
Cámara HAL
3.4
Actualizaciones de ICameraDeviceSession
-
configureStreams_3_4
: agrega soporte parasessionParameters
y cámaras lógicas. -
processCaptureRequest_3_4
: agrega soporte para incluir ID de cámara física 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, las implementaciones HAL de la cámara del proveedor deben estar enlazadas . Android 8.0 también contiene estas mejoras clave para el servicio de cámara:
- Superficies compartidas: habilite varias superficies que compartan la misma configuración de
OutputConfiguration
- API del sistema para modos de cámara personalizados
-
onCaptureQueueEmpty
Consulte las secciones a continuación para obtener más información sobre estas características.
superficies compartidas
Esta función permite que solo un conjunto de búfer 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 característica, los fabricantes de dispositivos deben asegurarse de que las implementaciones HAL de su cámara y gralloc HAL puedan crear búferes gralloc que utilizan múltiples consumidores diferentes (como el compositor de hardware/GPU y el codificador de video), en lugar de un solo consumidor. El servicio de cámara pasa las banderas de uso del consumidor a la cámara HAL y gralloc HAL; deben asignar los tipos correctos de búfer o la HAL de la cámara debe devolver un error de que esta combinación de consumidores no es compatible.
Consulte la documentación para desarrolladores de enableSurfaceSharing
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: normal y grabación de alta velocidad 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. Debajo del capó, el modo es solo un número entero que se pasa a configure_streams
. Consulte: 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 con el valor entero 0x8000 para evitar conflictos con futuros modos agregados a la API pública.
Para admitir esta característica, los OEM solo necesitan agregar el nuevo modo a su HAL, activado por este entero pasado a HAL en configure_streams, y luego hacer que su aplicación de cámara personalizada use la API del sistema.
El nombre del método es android.hardware.camera2.CameraDevice#createCustomCaptureSession
. Consulte: frameworks/base/core/java/android/hardware/camera2/CameraDevice
.
onCaptureQueueEmpty
El objetivo de esta API es reducir la latencia de los cambios de control, como el zoom, manteniendo la cola de solicitudes lo más vacía posible. onCaptureQueueEmpty
no requiere trabajo HAL; fue puramente una adición del lado del marco. Las aplicaciones que quieran aprovecharlo deben agregar un oyente a esa devolución de llamada y responder adecuadamente. Generalmente eso 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 estables definidas por HIDL. Todas las funciones y capacidades de la cámara introducidas en las versiones heredadas más recientes 3.4 y 2.4 (para el módulo de la cámara) también forman parte de las definiciones de HIDL.
3.4
Adiciones menores a los metadatos admitidos y cambios en la compatibilidad con data_space:
- Agregue metadatos estáticos
ANDROID_SENSOR_OPAQUE_RAW_SIZE
como obligatorios si se admite el formatoRAW_OPAQUE
. - Agregue metadatos estáticos
ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
como obligatorios si se admite cualquier formato RAW. - Cambie el campo
camera3_stream_t data_space
a una definición más flexible, utilizando la definición de versión 0 de codificación de espacio de datos. - Adiciones de metadatos generales que están disponibles para usar con HALv3.2 o posterior:
-
ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
-
ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
-
ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
-
ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
-
ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
-
ANDROID_SENSOR_OPAQUE_RAW_SIZE
-
ANDROID_SENSOR_OPTICAL_BLACK_REGIONS
-
3.3
Revisión menor de HAL de capacidad ampliada:
- Actualizaciones de la API de reprocesamiento OPAQUE y YUV.
- Soporte básico para buffers de salida de profundidad.
- Adición del campo
data_space
acamera3_stream_t
. - Adición del campo de rotación a
camera3_stream_t
. - Adición del modo de operación de configuración de flujo camera3 a
camera3_stream_configuration_t
.
3.2
Revisión menor de HAL de capacidad ampliada:
-
get_metadata_vendor_tag_ops
. Utiliceget_vendor_tag_ops
encamera_common.h
en su lugar. - Obsoleta
register_stream_buffers
. Todos los búferes gralloc proporcionados por el marco a HAL enprocess_capture_request
pueden ser nuevos en cualquier momento. - Agregar compatibilidad con resultados parciales.
process_capture_result
se puede llamar varias veces con un subconjunto de los resultados disponibles antes de que esté disponible el resultado completo. - Agregue una plantilla manual a
camera3_request_template
. Las aplicaciones pueden usar esta plantilla para controlar la configuración de captura directamente. - Vuelva a trabajar en las especificaciones bidireccionales y de flujo de entrada.
- Cambie la ruta de retorno del búfer de entrada. El búfer se devuelve en
process_capture_result
en lugar deprocess_capture_request
.
3.1
Revisión menor de HAL de capacidad ampliada:
-
configure_streams
pasa indicadores de uso del consumidor a la HAL. - vaciar la llamada para descartar todas las solicitudes/búferes en tránsito lo más rápido posible.
3.0
Primera revisión de HAL de capacidad ampliada:
- Cambio importante de versión ya que la ABI es completamente diferente. Sin cambios en las capacidades de hardware requeridas o el modelo operativo de 2.0.
- Interfaces de cola de transmisión y solicitud de entrada reelaboradas: Framework llama a HAL con la siguiente solicitud y los búferes de transmisión ya eliminados. Se incluye soporte de marco de sincronización, necesario para implementaciones eficientes.
- Desencadenadores movidos a solicitudes, la mayoría de notificaciones a resultados.
- Consolidó todas las devoluciones de llamada en el marco en una estructura y todos los métodos de configuración en una única llamada de
initialize()
. - Hizo la configuración de la transmisión en una sola llamada para simplificar la gestión de la transmisión. Los flujos bidireccionales reemplazan la construcción
STREAM_FROM_STREAM
. - Semántica de modo limitado para dispositivos de hardware más antiguos o limitados.
2.0
Lanzamiento inicial de HAL de capacidad ampliada (Android 4.2) [camera2.h]:
- Suficiente para implementar la API
android.hardware.Camera
existente. - Permite la cola ZSL en la capa de servicio de cámara.
- No probado para ninguna función nueva, como control de captura manual, captura Bayer RAW, reprocesamiento de datos RAW, etc.
1.0
Cámara inicial de Android HAL (Android 4.0) [camera.h]:
- Convertido de la capa de abstracción CameraHardwareInterface de C++.
- Admite la API
android.hardware.Camera
.
Historial de versiones del módulo de cámara
Esta sección contiene información sobre la versión del módulo para el módulo de hardware de la cámara, según camera_module_t.common.module_api_version
. Los dos dígitos hexadecimales más significativos representan la versión principal y los dos menos significativos representan la versión secundaria.
2.4
Esta versión del módulo de la cámara agrega los siguientes cambios en la API:
- 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 mayor prioridad para acceder a la unidad de flash que el módulo de la cámara; al abrir un dispositivo de cámara se apaga la 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 marco a través de la devolución de llamada de estado del modo antorcha que el modo antorcha se ha apagado. - Compatibilidad con cámara externa (por ejemplo, cámara USB conectable en caliente). Las actualizaciones de API especifican que la información estática de la cámara está disponible solo cuando la cámara está conectada y lista para usar para cámaras externas conectables 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 marco cuenta únicamente con las devoluciones de llamada de cambio de estado del dispositivo para administrar la lista de cámaras externas disponibles. - Consejos de arbitraje de cámara. Agrega soporte para indicar explícitamente la cantidad de dispositivos de cámara que se pueden abrir y usar simultáneamente. Para especificar combinaciones válidas de dispositivos, los campos
resource_cost
yconflicting_devices
siempre deben establecerse en la estructuracamera_info
devuelta por la llamadaget_camera_info
. - Método de inicialización del módulo. Llamado por el servicio de cámara después de cargar el módulo HAL para permitir la inicialización única de HAL. Se llama antes de que se invoque cualquier otro método de módulo.
2.3
Esta versión del módulo de cámara agrega compatibilidad con dispositivos HAL de cámara heredados abiertos. El marco puede usarlo para abrir el dispositivo de la cámara como un dispositivo HAL de la versión inferior del dispositivo HAL si el mismo dispositivo puede admitir varias versiones de la API del dispositivo. La llamada abierta del módulo de hardware estándar ( common.methods->open
) continúa abriendo el dispositivo de la cámara con la última versión compatible, que también es la versión que se muestra en camera_info_t.device_version
.
2.2
Esta versión del módulo de la cámara agrega compatibilidad con etiquetas de proveedores desde el módulo y deja en desuso el antiguo vendor_tag_query_ops
que anteriormente solo se podía acceder con un dispositivo abierto.
2.1
Esta versión del módulo de la cámara agrega soporte para devoluciones de llamadas asincrónicas al marco desde el módulo HAL de la cámara, que se usa para notificar al marco 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 HAL del módulo de cámara. Los dispositivos de cámara que se pueden abrir a través de este módulo pueden admitir la versión 1.0 o la versión 2.0 de la interfaz HAL del dispositivo de cámara. El campo device_version
de camera_info siempre es válido; el campo static_camera_characteristics
de camera_info
es válido si el campo device_version
es 2.0 o superior.
1.0
Los módulos de cámara que informan estos números de versión implementan la interfaz HAL del módulo de cámara inicial. Todos los dispositivos de cámara que se pueden abrir a través de este módulo solo admiten la versión 1 del dispositivo de cámara HAL. Los campos device_version
y static_camera_characteristics
de camera_info
no son válidos. Solo la API android.hardware.Camera
puede ser compatible con este módulo y sus dispositivos.