Cette page détaille les différences de version entre les HAL de la caméra, les API et les Tests Compatibility Test Suite (CTS). Il aborde également plusieurs Modifications architecturales apportées pour renforcer et sécuriser la structure de la caméra dans Android 7.0, le passage à Treble sous Android 8.0, et les mises à jour que les fournisseurs doivent apporter à prendre en charge ces changements dans leur implémentation de la caméra.
Terminologie
Les termes suivants sont utilisés sur cette page:
- API Camera1
- Le framework de l'appareil photo au niveau de l'application sur les appareils Android 4.4 et versions antérieures, exposé
via la classe
android.hardware.Camera
. - API Camera2
- Le framework de l'appareil photo au niveau de l'application sur les appareils Android 5.0 et versions ultérieures, exposé
via le package
android.hardware.camera2
. - Caméra HAL
- Couche de module de caméra implémentée par les fournisseurs de SoC. Public au niveau de l'application s'appuient sur le HAL de la caméra.
- Caméra HAL3.1
- Version HAL de l'appareil photo publiée avec Android 4.4.
- Caméra HAL3.2
- Version d'Android 5.0 de la version HAL de l'appareil photo.
- Camera API1 CTS
- Ensemble de tests CTS de l'appareil photo exécutés sur l'appareil photo API1.
- Camera API2 CTS
- Ensemble supplémentaire de tests CTS de l'appareil photo exécutés sur l'API Camera2.
- Aigus
- Sépare l'implémentation du fournisseur (logiciel de niveau inférieur spécifique à l'appareil). écrit par des fabricants de silicium) à partir du framework de l'OS Android via une nouvelle via l'interface du fournisseur.
- HIDL
- Langage de définition d'interface HAL introduit avec Treble et utilisé pour spécifier l'interface entre un HAL et de ses utilisateurs.
- VTS
- Ajout de la suite de tests pour les fournisseurs en même temps que Aigus.
API Camera
Android inclut les API d'appareil photo suivantes.
API Camera1
Android 5.0 a abandonné l'API Camera1, qui continue d'être éliminée en tant que nouvelle se concentre sur l'API Camera2. Toutefois, la période d'abandon seront longues et les versions d'Android continueront de prendre en charge les applications de l'API Camera1 pour un certain temps. Plus précisément, ils sont toujours pris en charge:
- Interfaces API1 de l'appareil photo pour les applications. Applications d'appareil photo intégrées à l'appareil photo API1 devrait fonctionner comme sur les appareils équipés de versions antérieures d'Android.
- Versions HAL de l'appareil photo. Compatibilité avec la caméra HAL1.0.
API Camera2
Le framework de l'API Camera2 expose des commandes de niveau inférieur de l'appareil photo à l'application. y compris des flux efficaces d'utilisation intensive ou par flux sans copie, et des contrôles par image exposition, gain, gains de balance des blancs, conversion des couleurs, suppression du bruit, accentuation et plus encore. Pour en savoir plus, regardez la <ph type="x-smartling-placeholder"></ph> Vidéo de présentation de Google I/O
Android 5.0 et versions ultérieures incluent l'API Camera2. Toutefois, les appareils équipés d'Android
Les versions 5.0 et ultérieures peuvent ne pas être compatibles avec toutes les fonctionnalités de l'API Camera 2. La
Propriété android.info.supportedHardwareLevel
que les applications peuvent interroger
via les interfaces de l'API Camera 2, signale l'un des problèmes suivants :
niveaux:
LEGACY
: ces appareils exposent des fonctionnalités aux applications via le Interfaces de l'API Camera 2 ayant à peu près les mêmes capacités que celles-ci aux applications via les interfaces de l'API Camera1. L'ancien code des frameworks transforme les appels de l'API Camera 2 en appels de l'API Camera 1 ; anciens appareils ne sont pas compatibles avec les fonctionnalités de l'API 2 de Camera, telles que les commandes par image.LIMITED
: ces appareils sont compatibles avec certaines fonctionnalités de l'API Camera2. (mais pas toutes) et devez utiliser l'HAL de la caméra 3.2 ou version ultérieure.FULL
: ces appareils sont compatibles avec les principales fonctionnalités Camera API2, et doit utiliser la version 3.2 (ou ultérieure) de l'appareil photo HAL et Android 5.0 (ou version ultérieure).LEVEL_3
: ces appareils prennent en charge le retraitement YUV et l'image RAW. ainsi que d'autres configurations de flux de sortie.EXTERNAL
: ces appareils sont semblables àLIMITED
à quelques exceptions près. par exemple, certaines informations sur les capteurs ou les objectifs ne sont pas signalées ou leur fréquence d'images est moins stable. Ce niveau est utilisé pour les appels caméras telles que les webcams USB.
Les capacités individuelles sont exposées
Propriété android.request.availableCapabilities
dans l'API Camera2
de commande. Les appareils FULL
nécessitent les MANUAL_SENSOR
et
MANUAL_POST_PROCESSING
, entre autres. La
La fonctionnalité RAW
est facultative, même pour les appareils FULL
.
LIMITED
appareils peuvent promouvoir n'importe quel sous-ensemble de ces fonctionnalités,
sans inclure aucun d'entre eux. Cependant, la capacité BACKWARD_COMPATIBLE
doit toujours être définie.
Niveau matériel compatible de l'appareil, ainsi que l'appareil photo spécifique les fonctionnalités API2 prises en charge sont disponibles en tant que flags de fonctionnalité suivants pour Autoriser le filtrage Google Play des applications d'appareil photo de l'API Camera2.
android.hardware.camera.hardware_level.full
android.hardware.camera.capability.raw
android.hardware.camera.capability.manual_sensor
android.hardware.camera.capability.manual_post_processing
Exigences concernant CTS
Les appareils équipés d'Android 5.0 ou version ultérieure doivent réussir les tests CTS de l'API Camera1, Tests de l'appareil photo API2 CTS et CTS Verifier.
Appareils qui ne disposent pas de l'implémentation HAL3.2 de la caméra et qui ne sont pas compatibles
compatible avec l'ensemble des interfaces de l'API 2 de Camera doivent tout de même transmettre l'appareil
Tests CTS d'API2. Cependant, l'appareil s'exécute dans l'API Camera2.
Mode LEGACY
(dans lequel les appels de l'API Camera 2 sont conceptuellement mappés
aux appels de l'API Camera API1), de sorte que tous les tests CTS de l'API Camera2 liés aux fonctionnalités ou
autres que l'API Camera1 sont automatiquement ignorées.
Sur les anciens appareils, les tests CTS de l'API Camera2 utilisent le Interfaces et fonctionnalités de l'API Camera publiques existantes, sans nouvelles exigences. Bugs exposés (et entraînant un échec de CTS de l'API Camera2) sont des bugs déjà présents dans le composant HAL de la caméra de l'appareil ; par les applications Camera API1 existantes. Nous ne nous attendons pas à beaucoup de bugs de cette nature (Toutefois, ces bugs doivent être corrigés pour réussir les tests CTS de l'API Camera2.)
Exigences VTS
Les appareils équipés d'Android 8.0 ou version ultérieure avec des implémentations HAL liées doivent passer la caméra Tests VSS.
Renforcement du framework de l'appareil photo
Pour renforcer la sécurité du système multimédia et de l'appareil photo, Android 7.0 déplace l'appareil photo du serveur de médias. À partir d'Android 8.0, chaque appareil photo lié HAL s'exécute dans un processus distinct du service de caméra. Les fournisseurs devront peut-être modifications dans le HAL de la caméra en fonction des versions de l'API et de HAL utilisées. La Les sections suivantes détaillent les modifications architecturales dans AP1 et AP2 pour HAL1 et HAL3, ainsi que les exigences générales.
Changements d'architecture pour l'API1
L'enregistrement vidéo de l'API1 peut supposer que la caméra et l'encodeur vidéo sont en direct processus. Lors de l'utilisation d'API1 sur:
- HAL3, où le service d'appareil photo utilise BufferQueue pour transmettre des tampons
aucune mise à jour du fournisseur n'est nécessaire.
Figure 1. Appareil photo et contenus multimédias Android 7.0 pile dans API1 sur HAL3
- HAL1, qui prend en charge la transmission de métadonnées dans des tampons vidéo, les fournisseurs doivent
mettez à jour le HAL pour qu'il utilise
kMetadataBufferTypeNativeHandleSource
. (kMetadataBufferTypeCameraSource
n'est plus compatible avec Android 7.0.)Figure 2 Appareil photo et contenus multimédias Android 7.0 pile dans API1 sur HAL1
Changements d'architecture pour l'API2
Pour l'API2 sur HAL1 ou HAL3, BufferQueue transmet des tampons afin que ces chemins continuent au travail. Architecture Android 7.0 pour API2 sur:
- HAL1 n'est pas affecté par le déplacement du service de caméra et aucun fournisseur d'une mise à jour est nécessaire.
- HAL3 est affecté, mais aucune mise à jour de fournisseur l'est
nécessaires:
Figure 3. Appareil photo et contenus multimédias Android 7.0 pile dans API2 sur HAL3
Exigences supplémentaires
Modifications architecturales apportées pour renforcer la structure des contenus multimédias et de la caméra incluent les exigences supplémentaires suivantes concernant l'appareil.
- Généralités. Les appareils nécessitent une bande passante
supplémentaire en raison de l'IPC,
ce qui peut affecter les cas d'utilisation de l'appareil photo urgents, comme la vidéo haute vitesse
l'enregistrement. Les fournisseurs peuvent mesurer l'impact réel en diffusant
android.hardware.camera2.cts.PerformanceTest
et l'appareil photo Google pour enregistrer des vidéos en haute vitesse avec une fréquence de 120 à 240 FPS. Les appareils requièrent également une petite quantité de RAM supplémentaire pour créer le nouveau processus. - Transmettre des métadonnées dans des tampons vidéo (HAL1 uniquement) Si HAL1
stocke les métadonnées au lieu des données de trame YUV réelles dans des tampons vidéo, le HAL doit
utiliser
kMetadataBufferTypeNativeHandleSource
comme tampon de métadonnées saisir et transmettreVideoNativeHandleMetadata
dans les tampons vidéo. (kMetadataBufferTypeCameraSource
n'est plus compatible avec Android 7.0.) AvecVideoNativeHandleMetadata
, les frameworks d'appareil photo et de contenu multimédia peuvent faire passer les tampons vidéo entre les processus en sérialisant et la désérialisation du traitement natif n'est pas optimale. - L'adresse du handle de tampon ne stocke pas toujours le même tampon (HAL3 uniquement). Pour chaque requête de capture, HAL3 obtient les adresses du tampon poignées. HAL ne peut pas utiliser les adresses pour identifier les tampons, car les adresses peut stocker une autre poignée de tampon après le renvoi du tampon par HAL. 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 handle de tampon A, qui stocke le handle de tampon A. Après le retour de HAL la poignée de tampon A, l'adresse A de la poignée de tampon peut stocker la poignée de tampon B la prochaine fois que la HAL le reçoit.
- Mettre à jour les règles SELinux pour cameraserver Si les règles SELinux spécifiques à l'appareil donnent des autorisations de serveur multimédia pour faire fonctionner l'appareil photo, vous devez mettre à jour les règles SELinux pour accorder les autorisations appropriées au serveur d'appareil photo. Mer Déconseiller la réplication des règles SELinux du serveur de médias pour le serveur Camera (Mediaserver et Cameraserver nécessitent généralement des ressources différentes dans le du système d'exploitation). Cameraserver ne doit disposer que des autorisations nécessaires pour accéder à l'appareil photo. et toutes les autorisations liées à l'appareil photo inutiles sur le serveur doit être supprimé.
- Séparation entre le HAL de la caméra et le serveur de caméras. Android Les versions 8.0 et ultérieures séparent également le HAL de la caméra reliée au cours d'un processus est différent de "cameraserver". L'IPC passe par Interfaces définies HIDL.
Validation
Pour tous les appareils équipés d'un appareil photo et équipés d'Android 7.0, vérifiez le mise en œuvre en exécutant Android 7.0 CTS. Même si Android 7.0 n'inclut pas Nouveaux tests CTS qui vérifient les modifications du service de caméra, les tests CTS existants échouent si vous n'avez pas effectué les modifications indiquées ci-dessus.
Pour tous les appareils équipés d'un appareil photo et équipés d'Android 8.0 ou version ultérieure, vérifiez l'implémentation du fournisseur en exécutant VTS.
Historique des versions de l'HAL de la caméra
Pour obtenir la liste des tests disponibles pour évaluer le HAL de l'appareil photo Android, consultez le Test de la couche HAL de la caméra Checklist.
Android 10
Android 10 introduit les mises à jour suivantes.
API Camera
- Améliorations apportées au multi-appareil photo permettant aux caméras physiques de être utilisées individuellement ou via les caméras logiques correspondantes en masquant des identifiants d'appareil photo physiques. Voir Compatibilité avec plusieurs caméras :
- Possibilité de vérifier si une configuration de session particulière
sans l'impact sur les performances
liés à la création d'une session.
Voir
CameraDevice
- Possibilité de récupérer les configurations de flux recommandées pour une utilisation donnée
pour rendre le client plus économe en énergie et performant. Voir
getRecommendedStreamConfigurationMap
- Compatibilité <ph type="x-smartling-placeholder"></ph> de profondeur d'image JPEG. Pour en savoir plus, consultez les <ph type="x-smartling-placeholder"></ph> Spécifications relatives à la profondeur dynamique
- Compatibilité <ph type="x-smartling-placeholder"></ph> Format d'image HEIC : Voir Imagerie HEIF :
- Amélioration de la confidentialité. Certaines clés sont requises pour le client
d'avoir
<ph type="x-smartling-placeholder"></ph>
les autorisations
CAMERA
avant de pouvoir les récupérer depuis <ph type="x-smartling-placeholder"></ph>CameraCharacteristics
Voir <ph type="x-smartling-placeholder"></ph>getKeysNeedingPermission
.
Caméra HAL
Les versions suivantes de l'HAL de l'appareil photo sont mises à jour sous Android 10.
3,5
ICameraDevice
-
getPhysicalCameraCharacteristics
: Les informations statiques de l'appareil photo pour un identifiant d'appareil photo physique étayé par une logique appareil photo. Voir <ph type="x-smartling-placeholder"></ph> Compatibilité multi-caméra. isStreamCombinationSupported
: cette méthode accepte un appel d'API API qui permet aux clients de demander si une configuration de session est compatible. Voir API pour interroger des combinaisons de flux.
ICameraDeviceSession
-
isReconfigurationNeeded
: Méthode qui indique au framework de l'appareil photo si le flux complet une reconfiguration est requise pour d'éventuelles nouvelles valeurs de paramètre de session. Ce permet d'éviter les retards inutiles liés à la reconfiguration de la caméra. Voir <ph type="x-smartling-placeholder"></ph> Requête de reconfiguration de session. - CARL
API de gestion de la mémoire tampon: ces API permettent au HAL de la caméra de demander
ne met en mémoire tampon le framework de l'appareil photo que si nécessaire, au lieu de les associer
la requête de capture et les tampons associés dans le pipeline de l'appareil photo,
ce qui peut potentiellement
réaliser des économies de mémoire importantes.
-
signalStreamFlush
: indique au HAL que la caméra est sur le point d'exécuter la commandeconfigureStreams_3_5
. le HAL doit renvoyer tous les tampons des flux désignés. -
configureStreams_3_5
: semblable àICameraDevice3.4.configureStreams
, mais dans De plus, le compteurstreamConfigCounter
est fourni recherche une condition de concurrence entreconfigureStreams_3_5
etsignalStreamFlush
.
-
Mises à jour de l'outil ICameraDeviceCallback
:
-
requestStreamBuffers
: Rappel synchrone appelé par le HAL de la caméra pour demander au serveur de la caméra tampons. Voir <ph type="x-smartling-placeholder"></ph>requestStreamBuffers
. -
returnStreamBuffers
: Rappel synchrone permettant au HAL de la caméra de renvoyer des tampons de sortie au de la caméra. Voir <ph type="x-smartling-placeholder"></ph>returnStreamBuffers
.
3.4
Les clés suivantes sont ajoutées aux métadonnées de l'appareil photo dans Android 10.
- Formats d'image
<ph type="x-smartling-placeholder">
- </ph>
ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
ANDROID_SCALER_AVAILABLE_FORMATS_Y8
- Balises de métadonnées de l'appareil photo
<ph type="x-smartling-placeholder">
- </ph>
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
- Fonctionnalités
<ph type="x-smartling-placeholder">
- </ph>
-
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
-
- Valeurs pour
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
touche <ph type="x-smartling-placeholder">- </ph>
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
- Configurations de flux de profondeur dynamique disponibles
<ph type="x-smartling-placeholder">
- </ph>
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
- Configurations de flux HEIC disponibles
<ph type="x-smartling-placeholder">
- </ph>
-
ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT
-
Module caméra
Les versions suivantes des modules de caméra sont mises à jour sous Android 10.
2,5
- Ajout de la méthode
notifyDeviceStateChange
pour les appareils à notifier le HAL de la caméra lorsque des changements physiques (pliage, par exemple) affectent la caméra le routage.
2.4
- Les appareils lancés avec le niveau d'API 29 ou supérieur DOIVENT signaler
true
pourisTorchModeSupported
.
Android 9
La version Android 9 introduit les mises à jour suivantes pour l'API de l'appareil photo2 et Interface HAL.
API Camera
- Introduction de l'API multi-caméra pour une meilleure prise en charge des appareils avec plusieurs caméras orientées dans la même direction, offrant ainsi des fonctionnalités telles que l'effet bokeh et zoom fluide. Cela permet aux applis d'afficher plusieurs caméras sur un même appareil comme une seule unité logique (caméra logique). Les demandes de capture peuvent également être envoyées appareils photographiques englobés par une caméra logique. Voir Compatibilité avec plusieurs caméras :
- Introduction des paramètres de session. Les paramètres de session sont un sous-ensemble de capture disponibles pouvant entraîner de graves retards de traitement modifiées. Ces coûts peuvent être atténués si les clients transmettent leurs valeurs initiales pendant l'initialisation de la session de capture. Voir Paramètres de session.
- Ajout de clés de données de stabilisation optique (OIS) pour la stabilisation au niveau de l'application et
les effets. Voir
<ph type="x-smartling-placeholder"></ph>
STATISTICS_OIS_SAMPLES
. - Ajout d'une prise en charge Flash externe. Voir
<ph type="x-smartling-placeholder"></ph>
CONTROL_AE_MODE_ON_EXTERNAL_FLASH
. - Ajoute un intent de suivi du mouvement dans
CAPTURE_INTENT
. Voir <ph type="x-smartling-placeholder"></ph>CONTROL_CAPTURE_INTENT_MOTION_TRACKING
. - Abandon de
LENS_RADIAL_DISTORTION
et ajout <ph type="x-smartling-placeholder"></ph>LENS_DISTORTION
à la place. - Ajout de modes de correction de la distorsion dans
CaptureRequest
. Voir <ph type="x-smartling-placeholder"></ph>DISTORTION_CORRECTION_MODE
. - Ajout de la prise en charge des appareils photo USB/UVC externes sur les appareils compatibles. Voir
<ph type="x-smartling-placeholder"></ph>
INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL
.
Caméra HAL
3.4
Mises à jour de ICameraDeviceSession
- <ph type="x-smartling-placeholder"></ph>
configureStreams_3_4
: Ajout de la prise en charge desessionParameters
et des caméras logiques. - <ph type="x-smartling-placeholder"></ph>
processCaptureRequest_3_4
: Ajout de la possibilité d'inclure des ID de caméras physiques dans la structure du flux.
Mises à jour de ICameraDeviceCallback
-
<ph type="x-smartling-placeholder"></ph>
processCaptureResult_3_4
: Ajoute des métadonnées d'appareil photo physique dans les résultats de capture.
3.3
Les clés suivantes sont ajoutées aux métadonnées de l'appareil photo sous Android 9.
- Fonctionnalités
<ph type="x-smartling-placeholder">
- </ph>
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
<ph type="x-smartling-placeholder">
- </ph>
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, le fournisseur Camera HAL les implémentations doivent être liés. Android 8.0 fonctionne également contient les principales améliorations apportées au service Appareil photo:
- Surfaces partagées: activer plusieurs surfaces partageant la même
OutputConfiguration
- API système pour les modes d'appareil photo personnalisés
onCaptureQueueEmpty
Pour en savoir plus sur ces fonctionnalités, consultez les sections ci-dessous.
Surfaces partagées
Cette fonctionnalité permet à un seul ensemble de tampons de géné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. À prennent en charge cette fonctionnalité, les fabricants d'appareils doivent s'assurer que le HAL et les implémentations HAL de gralloc peuvent créer des tampons Gralloc qui sont utilisés par plusieurs clients différents (tels que le compositeur du matériel/GPU et le fichier vidéo au lieu d'un seul consommateur. Le service de caméra transmet les indicateurs d'utilisation des consommateurs transmis au HAL de la caméra et au HAL de Gralloc ; il doit soit Allouez les bons types de tampons, ou le HAL de la caméra doit renvoyer une erreur que cette combinaison de consommateurs n'est pas acceptée.
Voir le
enableSurfaceSharing
documentation pour les développeurs.
API système pour les modes d'appareil photo personnalisés
L'API de caméra publique définit deux modes de fonctionnement: normal et restreint.
et l'enregistrement haute vitesse. Leur sémantique est assez différente. Exemple :
le mode haut débit est limité à un maximum
de deux sorties spécifiques à la fois. Divers
Les OEM ont exprimé leur intérêt pour la définition d'autres modes personnalisés
des capacités propres au matériel. Dans les coulisses, le mode est un nombre entier
transmis à configure_streams
. Voir:
<ph type="x-smartling-placeholder"></ph>
hardware/camera/device/3.2/ICameraDeviceSession#configurestreams
.
Cette fonctionnalité inclut un appel d'API système que les applications d'appareil photo OEM peuvent utiliser pour activer mode personnalisé. Ces modes doivent commencer à la valeur entière 0x8000 pour éviter les conflits les futurs modes seront ajoutés à l'API publique.
Pour proposer cette fonctionnalité, les OEM doivent simplement ajouter le nouveau mode à leur HAL, déclenché par cet entier transmis au HAL sur configure_streams, puis ont son application d'appareil photo personnalisée utilise l'API système.
Le nom de la méthode est
android.hardware.camera2.CameraDevice#createCustomCaptureSession
.
Voir:
<ph type="x-smartling-placeholder"></ph>
frameworks/base/core/java/android/hardware/camera2/CameraDevice
.
onCaptureQueueEmpty
L'objectif de cette API est de réduire la latence des changements de commande tels que le zoom de
en gardant la file d'attente des requêtes aussi vide que possible. onCaptureQueueEmpty
ne nécessite aucun travail HAL. il s'agissait purement d'un ajout côté framework. Applis qui
pour en profiter, vous devez ajouter un écouteur à ce rappel et répondre
en conséquence. Généralement, cela consiste à envoyer une autre demande de capture à l'appareil photo
appareil.
Interface HIDL de l'appareil photo
L'interface HIDL de la caméra est une refonte complète de l'interface HAL de la caméra. qui utilise des API stables définies par HIDL. Toutes les fonctionnalités et capacités de la caméra dans les dernières versions 3.4 et 2.4 (pour l'appareil photo module) font également partie des définitions HIDL.
3.4
Ajouts mineurs aux métadonnées compatibles et modifications de la prise en charge de data_space:
- Ajouter la métadonnée statique
ANDROID_SENSOR_OPAQUE_RAW_SIZE
comme obligatoire si le formatRAW_OPAQUE
est compatible. - Ajouter un élément
ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
statique les métadonnées comme obligatoires si un format RAW est accepté. - Remplacement du champ
camera3_stream_t data_space
par un champ plus flexible en utilisant la définition version 0 de l'encodage de l'espace de données. - Ajouts de métadonnées générales disponibles pour HALv3.2 ou version ultérieure:
<ph type="x-smartling-placeholder">
- </ph>
-
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 du HAL avec les fonctionnalités étendues:
- Mises à jour des API de retraitement OPAQUE et YUV.
- Compatibilité de base avec les tampons de sortie de profondeur.
- Ajout du champ
data_space
àcamera3_stream_t
- Champ de rotation ajouté à
camera3_stream_t
. - Ajout du mode de fonctionnement de la configuration du flux de caméra3 à
camera3_stream_configuration_t
3.2
Révision mineure du HAL avec les fonctionnalités étendues:
- Abandon de
get_metadata_vendor_tag_ops
. Utilisezget_vendor_tag_ops
à la place danscamera_common.h
. - Abandon de
register_stream_buffers
. Tous les tampons Gralloc fourni par le framework à HAL dansprocess_capture_request
peut être nouveau à tout moment. - Ajouter une prise en charge des résultats partiels.
process_capture_result
est peut-être appelé plusieurs fois avec un sous-ensemble des résultats disponibles avant la requête est disponible. - Ajouter un modèle manuel à
camera3_request_template
. Applications peut utiliser ce modèle pour contrôler directement les paramètres de capture. - Travaillez à nouveau les spécifications du flux bidirectionnel et du 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 du HAL avec les fonctionnalités étendues:
configure_streams
transmet les indicateurs d'utilisation des consommateurs au HAL.- l'appel de vidage pour abandonner aussi rapidement que possible toutes les requêtes/tampons en cours de transfert.
3,0
Première révision du HAL avec fonctionnalités étendues:
- Changement de version majeur, car l'ABI est complètement différente. Aucune modification n'a été apportée au les capacités matérielles requises ou le modèle opérationnel de la version 2.0.
- Refonte des interfaces de requête d'entrée et de file d'attente de flux: structurer les appels dans HAL avec la requête suivante et les tampons de flux déjà retirés de la file d'attente. Compatibilité avec le framework de synchronisation sont incluses, ce qui est nécessaire pour des implémentations efficaces.
- Déplacement des déclencheurs dans les requêtes et déplacement de la plupart des notifications dans les résultats.
- Consolidation de tous les rappels dans le framework en une seule structure et configuration complète
en un seul appel
initialize()
. - Configuration des flux en un seul appel pour simplifier la gestion des flux.
Les flux bidirectionnels remplacent
STREAM_FROM_STREAM
. - Sémantique en mode limité pour les appareils plus anciens ou limités
2.0
Version initiale du HAL aux fonctionnalités étendues (Android 4.2) [camera2.h]:
- Suffisant pour implémenter les
android.hardware.Camera
existants API. - Autorise l'ajout de la file d'attente ZSL dans la couche de service de l'appareil photo.
- Non testé pour de nouvelles fonctionnalités telles que le contrôle de capture manuel et le mode Bayer RAW capture, retraitement des données RAW, etc.
1.0
HAL de l'appareil photo Android initial (Android 4.0) [camera.h]:
- Convertie à partir de la couche d'abstraction CameraHardwareInterface C++.
- Compatible avec l'API
android.hardware.Camera
.
Historique des versions du module de caméra
Cette section contient des informations sur la gestion des versions des modules de la caméra
, basé sur camera_module_t.common.module_api_version
. Les deux
les chiffres hexadécimaux les plus significatifs représentent la version majeure et les deux chiffres les moins importants
représentent la version mineure.
2.4
Cette version du module de caméra ajoute les modifications suivantes à l'API:
- Compatibilité avec le mode Torch Le framework peut activer le mode lampe de poche
équipé d'un flash, sans avoir à ouvrir l'appareil photo. La
a une priorité plus élevée que l'appareil photo pour accéder au flash
. le fait d'ouvrir un appareil photo éteint la lampe de poche si elle était activée
via l'interface du module. En cas de conflit de ressources, par exemple
open()
est appelé pour ouvrir un appareil photo, le module HAL de la caméra. doit informer le framework via le rappel d'état du mode lampe de poche que la lampe de poche a été désactivé. - Compatibilité avec les appareils photo externes (par exemple, les caméras USB à branchement chaud) La
Les mises à jour de l'API spécifient que les informations statiques de la caméra ne sont disponibles que lorsque l'appareil est
connectées et prêtes à être utilisées pour des caméras externes reliées à chaud. Appels pour obtenir des images statiques
Les informations sont des appels incorrects lorsque l'état de la caméra n'est pas
CAMERA_DEVICE_STATUS_PRESENT
Le framework repose uniquement sur des rappels de changement d'état de l'appareil pour gérer la liste des caméras externes disponibles. - Conseils d'arbitrage pour la caméra. Ajout de la possibilité d'indiquer explicitement
le nombre de caméras qu'il est possible d'ouvrir et d'utiliser simultanément. À
spécifier des combinaisons d'appareils valides,
resource_cost
et Les champsconflicting_devices
doivent toujours être définis dans le Structurecamera_info
renvoyée parget_camera_info
. - Méthode d'initialisation du module. Appelé par le service de l'appareil photo après le chargement du module HAL pour permettre l'initialisation unique du HAL. Elle est appelée avant toute autre méthode de module.
2.3
Cette version du module d'appareil photo est désormais compatible avec les anciens appareils HAL.
Le framework peut l'utiliser pour ouvrir l'appareil photo en tant que version HAL inférieure de l'appareil
Appareil HAL si le même appareil est compatible avec plusieurs versions de l'API d'appareil.
L'appel d'ouverture du module matériel standard
(common.methods->open
) continue
pour ouvrir l'appareil photo avec la dernière version compatible, qui est
ou la version indiquée dans camera_info_t.device_version
.
2,2
Cette version du module d'appareil photo prend en charge les tags de fournisseur à partir du module.
abandonne les anciennes vendor_tag_query_ops
, qui n'étaient auparavant
accessible avec un appareil ouvert.
3,4
Cette version du module de caméra prend en charge les rappels asynchrones dans
du module HAL de la caméra, qui permet de signaler au framework
sur les changements d'état du module de la caméra. les modules qui fournissent un
La méthode set_callbacks()
doit 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. Appareils photo que vous pouvez ouvrir via ce
peut prendre en charge les versions 1.0 ou 2.0 de la caméra.
Interface HAL. 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 version ultérieure.
1.0
Les modules de caméra qui signalent ces numéros de version implémentent la configuration
interface HAL du module de caméra. Tous les appareils photo peuvent être ouverts via ce
n'est compatible qu'avec la version 1 du HAL de la caméra. La
device_version
et static_camera_characteristics
les champs camera_info
ne sont pas valides. Seuls les
L'API android.hardware.Camera
est compatible avec ce module et ses
appareils.