Cette page détaille les différences de version dans les HAL de caméra, les API et les tests de la suite de tests de compatibilité (CTS) associés. Il couvre également plusieurs modifications architecturales apportées pour renforcer et sécuriser le cadre de la caméra dans Android 7.0, le passage à Treble dans Android 8.0 et les mises à jour que les fournisseurs doivent apporter pour prendre en charge ces modifications dans leurs implémentations de caméra.
Terminologie
Les termes suivants sont utilisés sur cette page:
- Caméra API1
- Le cadre de caméra au niveau de l'application sur les appareils Android 4.4 et inférieurs, exposé via la classe
android.hardware.Camera
. - Caméra API2
- Le cadre de caméra au niveau de l'application sur les appareils Android 5.0 et supérieurs, exposé via le package
android.hardware.camera2
. - Caméra HAL
- La couche de module de caméra implémentée par les fournisseurs de SoC. Les frameworks publics au niveau de l'application sont construits au-dessus de la caméra HAL.
- Caméra HAL3.1
- Version de l'appareil photo HAL publiée avec Android 4.4.
- Caméra HAL3.2
- Version de l'appareil photo HAL publiée avec Android 5.0.
- Caméra API1 CTS
- Ensemble de tests CTS de caméra qui s'exécutent au-dessus de Camera API1.
- Caméra API2 CTS
- Ensemble supplémentaire de tests CTS de caméra qui s'exécutent au-dessus de Camera API2.
- Tripler
- Sépare la mise en œuvre du fournisseur (logiciel de niveau inférieur spécifique à l'appareil, écrit par les fabricants de silicium) de la structure du système d'exploitation Android via une nouvelle interface de fournisseur.
- HIDL
- Langage de définition d'interface HAL introduit avec Treble et utilisé pour spécifier l'interface entre un HAL et ses utilisateurs.
- VTS
- Suite de tests du fournisseur introduite avec Treble.
API de caméra
Android inclut les API de caméra suivantes.
Caméra API1
La caméra API1 d'Android 5.0 est obsolète, qui continue d'être supprimée à mesure que le développement de la nouvelle plate-forme se concentre sur l'API2 de la caméra. Cependant, la période d'élimination progressive sera longue et les versions d'Android continueront à prendre en charge les applications Camera API1 pendant un certain temps. Plus précisément, le soutien continue pour:
- Interfaces de la caméra API1 pour les applications. Les applications de caméra construites au-dessus de Camera API1 devraient fonctionner comme elles le font sur les appareils exécutant des versions inférieures d'Android.
- Versions de caméra HAL. Inclut la prise en charge de la caméra HAL1.0.
Caméra API2
La structure Camera API2 expose le contrôle de la caméra de niveau inférieur à l'application, y compris des flux de rafale / streaming efficaces sans copie et des contrôles par image de l'exposition, du gain, des gains de balance des blancs, de la conversion des couleurs, du débruitage, de la netteté, etc. Pour plus de détails, regardez la présentation vidéo de Google I / O.
Android 5.0 et supérieur inclut Camera API2; cependant, les appareils exécutant Android 5.0 et supérieur peuvent ne pas prendre en charge toutes les fonctionnalités de l'API2 de la caméra. La propriété android.info.supportedHardwareLevel
que les applications peuvent interroger via les interfaces Camera API2 signale l'un des niveaux de prise en charge suivants:
-
LEGACY
: ces appareils exposent des capacités aux applications via les interfaces Camera API2 qui sont approximativement les mêmes capacités que celles exposées aux applications via les interfaces Camera API1. Le code des frameworks hérités traduit conceptuellement les appels Camera API2 en appels Camera API1; Les anciens appareils ne prennent pas en charge les fonctionnalités de l'API2 de la caméra, telles que les commandes par image. -
LIMITED
: ces appareils prennent en charge certaines fonctionnalités de Camera API2 (mais pas toutes) et doivent utiliser Camera HAL 3.2 ou version ultérieure. -
FULL
: ces appareils prennent en charge toutes les fonctionnalités principales de Camera API2 et doivent utiliser Camera HAL 3.2 ou supérieur et Android 5.0 ou supérieur. -
LEVEL_3
: ces périphériques prennent en charge le retraitement YUV et la capture d'image RAW, ainsi que des configurations de flux de sortie supplémentaires. -
EXTERNAL
: ces appareils sont similaires aux appareilsLIMITED
à quelques exceptions près; par exemple, certaines informations de capteur ou d'objectif peuvent ne pas être rapportées ou avoir des fréquences d'images moins stables. Ce niveau est utilisé pour les caméras externes telles que les webcams USB.
Les fonctionnalités individuelles sont exposées via la propriété android.request.availableCapabilities
dans les interfaces Camera API2. FULL
périphériques FULL
nécessitent les capacités MANUAL_SENSOR
et MANUAL_POST_PROCESSING
, entre autres. La capacité RAW
est facultative même pour les appareils FULL
. LIMITED
appareils LIMITED
peuvent annoncer n'importe quel sous-ensemble de ces capacités, y compris aucune d'elles. Cependant, la capacité BACKWARD_COMPATIBLE
doit toujours être définie.
Le niveau matériel pris en charge de l'appareil, ainsi que les capacités spécifiques de l'API2 de la caméra qu'il prend en charge, sont disponibles sous forme d'indicateurs de fonctionnalité suivants pour permettre le filtrage Google Play des applications de caméra de l'API2 de la caméra.
-
android.hardware.camera.hardware_level.full
-
android.hardware.camera.capability.raw
-
android.hardware.camera.capability.manual_sensor
-
android.hardware.camera.capability.manual_post_processing
Exigences CTS
Les appareils exécutant Android 5.0 et versions ultérieures doivent réussir les tests Camera API1 CTS, Camera API2 CTS et CTS Verifier.
Les appareils qui ne disposent pas d'une implémentation Camera HAL3.2 et ne sont pas capables de prendre en charge toutes les interfaces Camera API2 doivent quand même réussir les tests Camera API2 CTS. Cependant, l'appareil fonctionne en mode Camera API2 LEGACY
(dans lequel les appels Camera API2 sont mappés conceptuellement aux appels Camera API1), de sorte que tous les tests Camera API2 CTS liés à des fonctionnalités ou capacités au-delà de Camera API1 sont automatiquement ignorés.
Sur les appareils hérités, les tests Camera API2 CTS qui sont exécutés utilisent les interfaces et fonctionnalités Camera API1 publiques existantes sans aucune nouvelle exigence. Les bogues qui sont exposés (et qui provoquent un échec de Camera API2 CTS) sont des bogues déjà présents dans la caméra HAL existante de l'appareil et seraient donc détectés par les applications Camera API1 existantes. Nous ne nous attendons pas à beaucoup de bogues de cette nature (cependant, ces bogues doivent être corrigés pour passer les tests Camera API2 CTS).
Exigences VTS
Les appareils exécutant Android 8.0 et versions ultérieures avec des implémentations HAL liées doivent passer les tests Camera VTS .
Durcissement du cadre de la caméra
Pour renforcer la sécurité des médias et du cadre de la caméra, Android 7.0 déplace le service de caméra hors du serveur média. À partir d'Android 8.0, chaque HAL de caméra en liasse s'exécute dans un processus distinct du service de caméra. Les fournisseurs peuvent devoir apporter des modifications à la HAL de la caméra en fonction des versions API et HAL utilisées. Les sections suivantes détaillent les modifications architecturales dans AP1 et AP2 pour HAL1 et HAL3, ainsi que les exigences générales.
Modifications architecturales pour API1
L'enregistrement vidéo API1 peut supposer que la caméra et l'encodeur vidéo vivent dans le même processus. Lors de l'utilisation d'API1 sur:
- HAL3, où le service de caméra utilise BufferQueue pour transmettre des tampons entre les processus, aucune mise à jour du fournisseur n'est nécessaire.
Figure 1. Caméra Android 7.0 et pile multimédia dans API1 sur HAL3
- HAL1, qui prend en charge la transmission de métadonnées dans les tampons vidéo, les fournisseurs doivent mettre à jour le HAL pour utiliser
kMetadataBufferTypeNativeHandleSource
. (kMetadataBufferTypeCameraSource
n'est plus pris en charge dans Android 7.0.)Figure 2. Caméra Android 7.0 et pile multimédia dans API1 sur HAL1
Modifications architecturales pour API2
Pour API2 sur HAL1 ou HAL3, BufferQueue transmet les tampons afin que ces chemins continuent à fonctionner. L'architecture Android 7.0 pour API2 sur:
- HAL1 n'est pas affecté par le déplacement du service de caméra et aucune mise à jour du fournisseur n'est nécessaire.
- HAL3 est affecté, mais aucune mise à jour du fournisseur n'est nécessaire:
Figure 3. Caméra Android 7.0 et pile multimédia dans API2 sur HAL3
Exigences supplémentaires
Les modifications architecturales apportées pour renforcer la sécurité des supports et du cadre de la caméra incluent les exigences supplémentaires suivantes en matière de périphérique.
- Général. Les périphériques nécessitent une bande passante supplémentaire en raison de l'IPC, ce qui peut affecter les cas d'utilisation de caméra sensibles au temps tels que l'enregistrement vidéo à haute vitesse. Les fournisseurs peuvent mesurer l'impact réel en exécutant
android.hardware.camera2.cts.PerformanceTest
et l'application Google Camera pour un enregistrement vidéo haute vitesse à 120/240 FPS. Les appareils nécessitent également une petite quantité de RAM supplémentaire pour créer le nouveau processus. - Transmettez les métadonnées dans les tampons vidéo ( HAL1 uniquement ). Si HAL1 stocke des métadonnées au lieu de vraies données d'image YUV dans des tampons vidéo, la HAL doit utiliser
kMetadataBufferTypeNativeHandleSource
comme type de tampon de métadonnées et transmettreVideoNativeHandleMetadata
dans les tampons vidéo. (kMetadataBufferTypeCameraSource
n'est plus pris en charge sur Android 7.0.) AvecVideoNativeHandleMetadata
, les cadres de caméras et de médias sont capables de transmettre les tampons vidéo entre les processus en sérialisant et en désérialisant correctement les descripteurs natifs. - L'adresse du descripteur de tampon ne stocke pas toujours le même tampon ( HAL3 uniquement ). Pour chaque demande de capture, HAL3 obtient les adresses des descripteurs de tampon. HAL ne peut pas utiliser les adresses pour identifier les tampons car les adresses peuvent stocker un autre handle de tampon après que HAL a renvoyé le tampon. Vous devez mettre à jour le HAL pour utiliser des poignées de tampon pour identifier les tampons. Par exemple, HAL reçoit une adresse de descripteur de tampon A, qui stocke le descripteur de tampon A. Une fois que HAL a renvoyé le descripteur de tampon A, l'adresse de descripteur de tampon A peut stocker le descripteur de tampon B la prochaine fois que HAL le recevra.
- Mettez à jour les politiques SELinux pour le serveur de caméras. Si les politiques SELinux spécifiques au périphérique donnent les autorisations du serveur média pour exécuter la caméra, vous devez mettre à jour les politiques SELinux pour donner les autorisations appropriées au serveur de caméras. Nous déconseillons de reproduire les politiques SELinux du serveur de médias pour le serveur de caméras (car le serveur de médias et le serveur de caméras nécessitent généralement des ressources différentes dans le système). Cameraserver ne doit avoir que les autorisations nécessaires pour exécuter les fonctionnalités de la caméra et toutes les autorisations inutiles liées à la caméra dans mediaserver doivent être supprimées.
- Séparation entre la caméra HAL et le serveur de caméras. Android 8.0 et supérieur séparent en outre la caméra HAL en liant dans un processus différent de celui du serveur de caméras. IPC passe par des interfaces définies par HIDL .
Validation
Pour tous les appareils qui incluent une caméra et exécutent Android 7.0, vérifiez l'implémentation en exécutant Android 7.0 CTS. Bien qu'Android 7.0 n'inclut pas de nouveaux tests CTS qui vérifient les modifications du service de la caméra, les tests CTS existants échouent si vous n'avez pas effectué les mises à jour indiquées ci-dessus.
Pour tous les appareils qui incluent une caméra et exécutent Android 8.0 ou version ultérieure, vérifiez l'implémentation du fournisseur en exécutant VTS.
Historique des versions de la caméra HAL
Pour obtenir la liste des tests disponibles pour évaluer la HAL de la caméra Android, consultez la liste de contrôle des tests de la HAL de la caméra .
Android 10
Android 10 introduit les mises à jour suivantes.
API de la caméra
- Améliorations multi-caméras qui permettent aux caméras physiques d'être utilisées individuellement ou via les caméras logiques correspondantes en masquant les identifiants physiques des caméras Voir Prise en charge multi-caméras .
- Possibilité de vérifier si une configuration de session particulière est prise en charge sans la surcharge de performances liée à la création d'une nouvelle session. Voir
CameraDevice
. - Possibilité de récupérer les configurations de flux recommandées pour un cas d'utilisation donné afin de rendre le client plus économe en énergie et plus performant. Voir
getRecommendedStreamConfigurationMap
. - Prise en charge du format d'image JPEG de profondeur . Pour plus de détails, consultez la spécification Dynamic Depth .
- Prise en charge du format d'image HEIC . Voir Imagerie HEIF .
- Améliorations de la confidentialité. Certaines clés sont nécessaires pour que le client dispose des autorisations
CAMERA
avant de pouvoir être récupérées à partir deCameraCharacteristics
. VoirgetKeysNeedingPermission
.
Caméra HAL
Les versions suivantes de Camera HAL sont mises à jour dans Android 10.
3,5
ICameraDevice
-
getPhysicalCameraCharacteristics
: informations de caméra statique pour un ID de caméra physique sauvegardant un périphérique de caméra logique. Voir Prise en charge multi-caméras . -
isStreamCombinationSupported
: cette méthode prend en charge une API publique qui aide les clients à demander si une configuration de session est prise en charge. Voir API pour interroger les combinaisons de flux .
ICameraDeviceSession
-
isReconfigurationNeeded
: méthode qui indique à la structure de la caméra si une reconfiguration complète du flux est requise pour d'éventuelles nouvelles valeurs de paramètres de session. Cela permet d'éviter des retards inutiles de reconfiguration de la caméra. Voir Requête de reconfiguration de session . - API de gestion de tampon HAL : ces API permettent à la caméra HAL de demander des tampons à la structure de la caméra uniquement lorsque cela est nécessaire au lieu de coupler chaque demande de capture avec ses tampons associés tout au long du pipeline de caméra, ce qui entraîne des économies de mémoire potentiellement importantes.
-
signalStreamFlush
: Signale à la HAL que le service de caméra est sur le point d'exécuterconfigureStreams_3_5
et que la HAL doit renvoyer tous les tampons des flux désignés. -
configureStreams_3_5
: similaire àICameraDevice3.4.configureStreams
, mais en plus, le compteurstreamConfigCounter
est fourni pour vérifier une condition designalStreamFlush
entre les appelsconfigureStreams_3_5
etsignalStreamFlush
.
-
Mises à jour de ICameraDeviceCallback
:
-
requestStreamBuffers
: rappel synchrone que la caméra HAL appelle pour demander au serveur de caméra des tampons. VoirrequestStreamBuffers
. -
returnStreamBuffers
: rappel synchrone pour la caméra HAL pour renvoyer les tampons de sortie au serveur de caméra. VoirreturnStreamBuffers
.
3.4
Les clés suivantes sont ajoutées aux métadonnées de la caméra dans Android 10.
- Formats d'image
-
ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
-
ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
-
ANDROID_SCALER_AVAILABLE_FORMATS_Y8
-
- Balises de métadonnées de l'appareil photo
-
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
-
- Capacités
-
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
-
- Valeurs de la clé
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
-
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
-
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
-
- Configurations de flux de profondeur dynamiques disponibles
-
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
-
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
-
- Configurations de flux HEIC disponibles
-
ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
-
ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT
-
Module caméra
Les versions de module de caméra suivantes sont mises à jour dans Android 10.
2,5
- Ajoute la méthode
notifyDeviceStateChange
pour que les périphériquesnotifyDeviceStateChange
la caméra HAL lorsque des changements physiques, tels que le pliage, affectent la caméra et le routage.
2,4
- Les appareils lancés avec le niveau d'API 29 ou supérieur DOIVENT indiquer
true
pourisTorchModeSupported
.
Android 9
La version Android 9 introduit les mises à jour suivantes de l'interface API2 et HAL de la caméra.
API de la caméra
- Présente l'API multi-caméras pour mieux prendre en charge les appareils avec plusieurs caméras orientées dans la même direction, permettant des fonctionnalités telles que le bokeh et le zoom transparent. Cela permet aux applications d'afficher plusieurs caméras sur un périphérique comme une seule unité logique (caméra logique). Les demandes de capture peuvent également être envoyées à des appareils photo individuels englobés par une caméra logique. Voir Prise en charge multi-caméras .
- Introduit les paramètres de session. Les paramètres de session sont un sous-ensemble des paramètres de capture disponibles qui peuvent entraîner des retards de traitement importants lorsqu'ils sont modifiés. Ces coûts peuvent être atténués si les clients transmettent leurs valeurs initiales lors de l'initialisation de la session de capture. Voir Paramètres de session .
- Ajoute des clés de données de stabilisation optique (OIS) pour la stabilisation et les effets au niveau de l'application. Voir
STATISTICS_OIS_SAMPLES
. - Ajoute la prise en charge du flash externe. Voir
CONTROL_AE_MODE_ON_EXTERNAL_FLASH
. - Ajoute une intention de suivi de mouvement dans
CAPTURE_INTENT
. VoirCONTROL_CAPTURE_INTENT_MOTION_TRACKING
. -
LENS_RADIAL_DISTORTION
et ajouteLENS_DISTORTION
à sa place. - Ajoute des modes de correction de la distorsion dans
CaptureRequest
. VoirDISTORTION_CORRECTION_MODE
. - Ajoute la prise en charge des caméras USB / UVC externes sur les appareils pris en charge. Voir
INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL
.
Caméra HAL
3.4
Mises à jour de ICameraDeviceSession
-
configureStreams_3_4
: ajoute la prise en charge dessessionParameters
et des caméras logiques. -
processCaptureRequest_3_4
: ajoute la prise en charge de l'inclusion des ID de caméra physique dans la structure de flux.
Mises à jour de ICameraDeviceCallback
-
processCaptureResult_3_4
: ajoute des métadonnées de caméra physique dans les résultats de capture.
3,3
Les clés suivantes sont ajoutées aux métadonnées de la caméra dans Android 9.
- Capacités
-
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
-
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
-
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
-
- Balises de métadonnées de l'appareil photo
-
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 version Android 8.0 introduit Treble. Avec Treble, les implémentations de la caméra HAL du fournisseur doivent être regroupées . Android 8.0 contient également ces améliorations clés du service Appareil photo:
- Surfaces partagées: activer plusieurs surfaces partageant la même
OutputConfiguration
- API système pour les modes de caméra personnalisés
-
onCaptureQueueEmpty
Consultez les sections ci-dessous pour plus d'informations sur ces fonctionnalités.
Surfaces partagées
Cette fonction permet à un seul jeu de tampons de gérer deux sorties, telles que l'aperçu et l'encodage vidéo, ce qui réduit la consommation d'énergie et de mémoire. Pour prendre en charge cette fonctionnalité, les fabricants de périphériques doivent s'assurer que leurs implémentations de caméra HAL et gralloc HAL peuvent créer des tampons gralloc qui sont utilisés par plusieurs consommateurs différents (tels que le composeur de matériel / GPU et l'encodeur vidéo), au lieu d'un seul consommateur. Le service de caméra transmet les indicateurs d'utilisation des consommateurs à la caméra HAL et à la HAL gralloc; ils doivent soit allouer les bons types de tampons, soit la caméra HAL doit renvoyer une erreur indiquant que cette combinaison de consommateurs n'est pas prise en charge.
Consultez la documentation du développeur enableSurfaceSharing
pour plus de détails.
API système pour les modes de caméra personnalisés
L'API de caméra publique définit deux modes de fonctionnement: l'enregistrement à grande vitesse normal et contraint. Ils ont une sémantique assez différente; par exemple, le mode haute vitesse est limité à au plus deux sorties spécifiques à la fois. Divers OEM ont exprimé leur intérêt pour la définition d'autres modes personnalisés pour les capacités spécifiques au matériel. Sous le capot, le mode est juste un entier passé à configure_streams
. Voir: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams
.
Cette fonctionnalité comprend un appel d'API système que les applications de caméra OEM peuvent utiliser pour activer un mode personnalisé. Ces modes doivent commencer à la valeur entière 0x8000 pour éviter tout conflit avec les futurs modes ajoutés à l'API publique.
Pour prendre en charge cette fonctionnalité, les OEM doivent simplement ajouter le nouveau mode à leur HAL, déclenché par cet entier transmis au HAL sur configure_streams, puis demander à leur application de caméra personnalisée d'utiliser l'API système.
Le nom de la méthode est android.hardware.camera2.CameraDevice#createCustomCaptureSession
. Voir: frameworks/base/core/java/android/hardware/camera2/CameraDevice
.
onCaptureQueueEmpty
Le but de cette API est de réduire la latence des changements de contrôle comme le zoom en gardant la file d'attente de demandes aussi vide que possible. onCaptureQueueEmpty
ne nécessite aucun travail HAL; c'était purement un ajout côté framework. Les applications qui souhaitent en profiter doivent ajouter un écouteur à ce rappel et répondre de manière appropriée. En général, c'est en envoyant une autre demande de capture à l'appareil photo.
Interface HIDL de la caméra
L'interface Camera HIDL est une refonte complète de l'interface Camera HAL qui utilise des API stables définies par HIDL. Toutes les fonctionnalités et capacités de caméra introduites dans les anciennes versions 3.4 et 2.4 (pour le module caméra) font également partie des définitions HIDL.
3.4
Ajouts mineurs aux métadonnées prises en charge et modifications apportées à la prise en charge de data_space:
- Ajoutez des métadonnées statiques
ANDROID_SENSOR_OPAQUE_RAW_SIZE
obligatoires si le formatRAW_OPAQUE
est pris en charge. - Ajoutez des métadonnées statiques
ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
comme obligatoires si un format RAW est pris en charge. - Basculez le champ
camera3_stream_t data_space
vers une définition plus flexible, à l'aide de la définition de la version 0 du codage de l'espace de données. - Ajouts de métadonnées générales disponibles pour HALv3.2 ou plus récent:
-
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
Révision mineure de la capacité étendue HAL:
- Mises à jour de l'API de retraitement OPAQUE et YUV.
- Prise en charge de base des tampons de sortie de profondeur.
- Ajout de
data_space
champ àcamera3_stream_t
. - Ajout du champ de rotation à
camera3_stream_t
. - Ajout du mode de fonctionnement de configuration de flux
camera3_stream_configuration_t
àcamera3_stream_configuration_t
.
3.2
Révision mineure de la capacité étendue HAL:
-
get_metadata_vendor_tag_ops
. Utilisezget_vendor_tag_ops
danscamera_common.h
. - Observe
register_stream_buffers
. Tous les tampons gralloc fournis par le framework à HAL dansprocess_capture_request
peuvent être nouveaux à tout moment. - Ajoutez une prise en charge partielle des résultats.
process_capture_result
peut être appelé plusieurs fois avec un sous-ensemble des résultats disponibles avant que le résultat complet ne soit disponible. - Ajoutez un modèle manuel à
camera3_request_template
. Les applications peuvent utiliser ce modèle pour contrôler directement les paramètres de capture. - Retravailler les spécifications bidirectionnelles et de flux d'entrée.
- Modifiez le chemin de retour du tampon d'entrée. Le tampon est renvoyé dans
process_capture_result
au lieu deprocess_capture_request
.
3.1
Révision mineure de la capacité étendue HAL:
-
configure_streams
transmet les indicateurs d'utilisation des consommateurs à la HAL. - flush call pour supprimer toutes les requêtes / tampons en cours le plus rapidement possible.
3.0
Première révision de la capacité étendue HAL:
- Changement de version majeur puisque l'ABI est complètement différent. Aucune modification des capacités matérielles ou du modèle opérationnel requis à partir de la version 2.0.
- Interfaces de demande d'entrée et de file d'attente de flux retravaillées: Framework appelle dans HAL avec la demande suivante et les tampons de flux déjà retirés de la file d'attente. Le support du framework de synchronisation est inclus, nécessaire pour des implémentations efficaces.
- Déplacement des déclencheurs dans les demandes, la plupart des notifications dans les résultats.
- Consolidation de tous les rappels dans le cadre en une seule structure et de toutes les méthodes de configuration en un seul appel
initialize()
. - Configuration du flux en un seul appel pour simplifier la gestion du flux. Les flux bidirectionnels remplacent la construction
STREAM_FROM_STREAM
. - Sémantique en mode limité pour les périphériques matériels plus anciens / limités.
2.0
Version initiale de la fonctionnalité étendue HAL (Android 4.2) [camera2.h]:
- Suffisant pour implémenter l'API
android.hardware.Camera
existante. - Permet la file d'attente ZSL dans la couche de service de la caméra.
- Non testé pour de nouvelles fonctionnalités telles que le contrôle de capture manuelle, la capture Bayer RAW, le retraitement des données RAW, etc.
1.0
Caméra Android initiale HAL (Android 4.0) [camera.h]:
- Converti à partir de la couche d'abstraction C ++ CameraHardwareInterface.
- Prend en charge l'API
android.hardware.Camera
.
Historique des versions du module de caméra
Cette section contient des informations de version du module pour le module matériel de la caméra, basées sur camera_module_t.common.module_api_version
. Les deux chiffres hexadécimaux les plus significatifs représentent la version principale, et les deux moins significatifs représentent la version mineure.
2,4
Cette version du module de caméra ajoute les modifications d'API suivantes:
- Prise en charge du mode torche. Le cadre peut activer le mode torche pour tout appareil photo doté d'un flash, sans ouvrir d'appareil photo. L'appareil photo a une priorité d'accès au flash plus élevée que le module appareil photo; l'ouverture d'un appareil photo éteint la torche si elle avait été activée via l'interface du module. Lorsqu'il y a des conflits de ressources, comme
open()
est appelé pour ouvrir un appareil photo, le module HAL de la caméra doit notifier le framework via le rappel d'état du mode torche que le mode torche a été désactivé. - Prise en charge d'une caméra externe (par exemple, une caméra USB hot-plug). Les mises à jour de l'API spécifient que les informations statiques de la caméra sont disponibles uniquement lorsque la caméra est connectée et prête à être utilisée pour les caméras externes hot-plug. Les appels pour obtenir des informations statiques sont des appels non valides lorsque l'état de la caméra n'est pas
CAMERA_DEVICE_STATUS_PRESENT
. Le framework compte uniquement sur les rappels de changement d'état de l'appareil pour gérer la liste des caméras externes disponibles. - Conseils d'arbitrage de la caméra. Ajoute la prise en charge de l'indication explicite du nombre d'appareils photo pouvant être ouverts et utilisés simultanément. Pour spécifier des combinaisons de périphériques valides, les champs
resource_cost
etconflicting_devices
doivent toujours être définis dans la structurecamera_info
renvoyée par l'appelget_camera_info
. - Méthode d'initialisation du module. Appelé par le service de caméra après le chargement du module HAL pour permettre une initialisation unique du HAL. Il est appelé avant que toute autre méthode de module ne soit appelée.
2,3
Cette version de module de caméra ajoute la prise en charge des périphériques HAL de caméra hérités ouverts. La structure peut l'utiliser pour ouvrir le périphérique de caméra en tant que périphérique HAL de version HAL inférieure si le même périphérique peut prendre en charge plusieurs versions d'API de périphérique. L'appel d'ouverture du module matériel standard ( common.methods->open
) continue d'ouvrir l'appareil photo avec la dernière version prise en charge, qui est également la version répertoriée dans camera_info_t.device_version
.
2.2
Cette version du module de caméra ajoute la prise en charge des balises de fournisseur à partir du module et vendor_tag_query_ops
obsolète les anciens vendor_tag_query_ops
qui n'étaient auparavant accessibles qu'avec un périphérique ouvert.
2,1
Cette version du module de caméra ajoute la prise en charge des rappels asynchrones à la structure à partir du module HAL de caméra, qui est utilisé pour informer la structure des modifications apportées à l'état du module de caméra. Les modules qui fournissent une méthode set_callbacks()
valide doivent indiquer au moins ce numéro de version.
2.0
Les modules de caméra qui signalent ce numéro de version implémentent la deuxième version de l'interface HAL du module de caméra. Les appareils photo pouvant être ouverts via ce module peuvent prendre en charge la version 1.0 ou la version 2.0 de l'interface HAL de l'appareil photo. Le champ device_version
de camera_info est toujours valide; le champ static_camera_characteristics
de camera_info
est valide si le champ device_version
est 2.0 ou supérieur.
1.0
Les modules de caméra qui signalent ces numéros de version implémentent l'interface HAL du module de caméra initial. Tous les appareils photo pouvant être ouverts via ce module ne prennent en charge que la version 1 de l'appareil photo HAL. Les champs device_version
et static_camera_characteristics
de camera_info
ne sont pas valides. Seule l'API android.hardware.Camera
peut être prise en charge par ce module et ses appareils.