Prise en charge de la version de la caméra

Cette page détaille les différences de version Hals de l' appareil photo, des API, et associés de test de compatibilité Suite (CTS) des tests. 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 effectuer 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 la caméra au niveau de l' application sur Android 4.4 et les périphériques inférieurs, exposés par la android.hardware.Camera classe.
Caméra API2
Le cadre de la caméra au niveau de l' application sur Android 5.0 et supérieur appareils, exposés par le android.hardware.camera2 package.
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 sur 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) du cadre du système d'exploitation Android via une nouvelle interface de fournisseur.
HIDL
Interface HAL langage de définition introduite avec Treble et utilisé pour spécifier l'interface entre HAL et ses utilisateurs.
VTS
Suite de tests du fournisseur a présenté aux côtés aigus.

API de caméra

Android inclut les API de caméra suivantes.

Caméra API1

Android 5.0 a déprécié Camera API1, qui continue d'être abandonné alors que le développement de la nouvelle plate-forme se concentre sur Camera API2. Cependant, la période d'élimination sera longue et les versions Android continueront à prendre en charge les applications Camera API1 pendant un certain temps. Plus précisément, l'assistance continue pour :

  • Interfaces API1 de caméra pour les applications. Les applications d'appareil photo construites au-dessus de Camera API1 devraient fonctionner comme elles le font sur les appareils exécutant des versions inférieures d'Android.
  • Versions HAL de la caméra. Inclut la prise en charge de la caméra HAL1.0.

Caméra API2

Le framework Camera API2 expose un contrôle de caméra de niveau inférieur à l'application, y compris des flux efficaces de rafale/diffusion 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, voir la présentation vidéo Google I / O .

Android 5.0 et versions ultérieures inclut Camera API2 ; cependant, les appareils exécutant Android 5.0 et versions ultérieures peuvent ne pas prendre en charge toutes les fonctionnalités de l'API2 de l'appareil photo. La android.info.supportedHardwareLevel propriété que les applications peuvent interroger via les interfaces API2 de l' appareil signale l' un des niveaux de support suivants:

  • LEGACY : Ces dispositifs exposent capacités à des applications via les interfaces API2 de l' appareil photo qui sont à peu près les mêmes capacités que celles qui sont exposées à des applications via les interfaces API1 de la caméra. Le code des frameworks hérités traduit conceptuellement les appels Camera API2 en appels Camera API1 ; Les appareils hérités ne prennent pas en charge les fonctionnalités Camera API2 telles que les commandes par image.
  • LIMITED : Ces dispositifs soutiennent certaines capacités de API2 de la caméra (mais pas tous) et doit utiliser l' appareil photo HAL 3.2 ou supérieur.
  • FULL : Ces appareils prennent en charge toutes les fonctionnalités principales de API2 de l' appareil et doit utiliser la caméra HAL 3.2 ou supérieur et Android 5.0 ou supérieur.
  • LEVEL_3 : Ces dispositifs soutiennent le retraitement et YUV RAW capture d'image, ainsi que des configurations de flux de sortie supplémentaires.
  • EXTERNAL : Ces appareils sont similaires à LIMITED dispositifs à quelques exceptions près; par exemple, certaines informations de capteur ou d'objectif peuvent ne pas être signalées ou avoir des fréquences d'images moins stables. Ce niveau est utilisé pour les caméras externes telles que les webcams USB.

Capacités individuelles sont exposées par la android.request.availableCapabilities propriété dans les interfaces API2 de la caméra. FULL dispositifs nécessitent les MANUAL_SENSOR et MANUAL_POST_PROCESSING capacités, entre autres. Le RAW capacité est en option même pour FULL appareils. LIMITED appareils peuvent annoncer un sous - ensemble de ces capacités, y compris aucun d'entre eux. Cependant, la BACKWARD_COMPATIBLE capacité doit toujours être définie.

Le niveau matériel pris en charge de l'appareil, ainsi que les capacités spécifiques de Camera API2 qu'il prend en charge, sont disponibles sous la forme des indicateurs de fonctionnalité suivants pour permettre le filtrage Google Play des applications de caméra 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

Exigences CTS

Les appareils exécutant Android 5.0 et versions ultérieures doivent réussir les tests de caméra 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 les interfaces Camera API2 complètes doivent tout de même réussir les tests Camera API2 CTS. Cependant, l'appareil fonctionne en API2 Caméra LEGACY Mode (dans lequel les appels API2 de la caméra sont mis en correspondance sur le plan conceptuel aux appels API1 de la caméra) de sorte que toute caméra API2 CTS tests liés à des fonctions ou capacités au - delà API1 de l' appareil photo sont automatiquement ignorées.

Sur les appareils existants, les tests Camera API2 CTS qui sont exécutés utilisent les interfaces et les capacités publiques existantes de Camera API1 sans aucune nouvelle exigence. Les bogues qui sont exposés (et qui provoquent une défaillance de Camera API2 CTS) sont des bogues déjà présents dans la Camera HAL existante de l'appareil, et seraient donc trouvés par les applications Camera API1 existantes. Nous ne nous attendons pas à beaucoup de bogues de cette nature (cependant, de tels bogues doivent être corrigés pour réussir les tests Camera API2 CTS).

Exigences VTS

Appareils fonctionnant sous Android 8.0 et avec les implémentations binderized HAL doivent passer les caméras tests VTS .

Durcissement du cadre de la caméra

Pour renforcer la sécurité du cadre des médias et des caméras, Android 7.0 déplace le service de caméra hors du serveur multimédia. À partir d'Android 8.0, chaque HAL de caméra lié s'exécute dans un processus distinct du service de caméra. Les fournisseurs peuvent avoir besoin d'apporter des modifications à la caméra HAL en fonction de l'API et des versions HAL utilisées. Les sections suivantes détaillent les modifications architecturales apportées à AP1 et AP2 pour HAL1 et HAL3, ainsi que les exigences générales.

Changements architecturaux pour API1

L'enregistrement vidéo API1 peut supposer que la caméra et l'encodeur vidéo vivent dans le même processus. Lorsque vous utilisez API1 sur :

  • HAL3, où le service de la caméra utilise BufferQueue pour passer des tampons entre les processus, aucune mise à jour du fournisseur est nécessaire.

    Caméra Android 7.0 et pile multimédia dans API1 sur HAL3

    Figure 1. caméra et applications 7.0 médias pile dans API1 sur HAL3

  • HAL1, qui supporte le passage de métadonnées dans un tampon vidéo, les fournisseurs doit mettre à jour la couche HAL à utiliser kMetadataBufferTypeNativeHandleSource . ( kMetadataBufferTypeCameraSource est pas prise en charge dans Android 7.0.)

    Caméra Android 7.0 et pile multimédia dans API1 sur HAL1

    Figure 2. appareil photo Android 7.0 et les médias pile dans API1 sur HAL1

Changements architecturaux pour API2

Pour API2 sur HAL1 ou HAL3, BufferQueue passe des tampons afin que ces chemins continuent de fonctionner. L'architecture Android 7.0 pour API2 sur :

  • HAL1 est pas affectée par le mouvement de cameraservice, et aucune mise à jour du fournisseur est nécessaire.
  • HAL3 est affectée, mais aucune mise à jour du fournisseur est nécessaire:

    Caméra Android 7.0 et pile multimédia dans API2 sur HAL3

    Figure 3. caméra et applications 7.0 médias pile dans API2 sur HAL3

Exigences supplémentaires

Les modifications architecturales apportées pour renforcer la sécurité de la structure des supports et des caméras incluent les exigences supplémentaires suivantes concernant les périphériques.

  • Général. Les appareils 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 vendeurs peuvent mesurer l' impact réel en exécutant android.hardware.camera2.cts.PerformanceTest et l'application Appareil photo Google pour 120/240 FPS enregistrement vidéo à haute vitesse. Les appareils nécessitent également une petite quantité de RAM supplémentaire pour créer le nouveau processus.
  • Métadonnées passer dans des tampons vidéo (HAL1 seulement). Si les magasins HAL1 métadonnées au lieu de données de trame YUV réel dans les tampons vidéo, la HAL doit utiliser kMetadataBufferTypeNativeHandleSource comme type de mémoire tampon de métadonnées et passer VideoNativeHandleMetadata dans des tampons vidéo. ( kMetadataBufferTypeCameraSource n'est plus pris en charge sur Android 7.0.) Avec VideoNativeHandleMetadata , les cadres de la caméra et les médias sont en mesure de transmettre les tampons vidéo entre les processus par sérialisation et désérialisation les poignées d' origine correctement.
  • Tampon adresse de la poignée ne stocke pas toujours le même tampon (HAL3 uniquement). Pour chaque demande de capture, HAL3 obtient les adresses des handles de tampon. HAL ne peut pas utiliser les adresses pour identifier les tampons car les adresses peuvent stocker un autre descripteur de tampon une fois que HAL a renvoyé le tampon. Vous devez mettre à jour la couche HAL pour utiliser des descripteurs 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. Une fois que HAL a renvoyé le handle de tampon A, l'adresse de handle de tampon A peut stocker le handle de tampon B la prochaine fois que HAL le reçoit.
  • Mettez à jour les politiques SELinux pour cameraserver. Si les politiques SELinux spécifiques à l'appareil donnent des autorisations au serveur multimédia pour exécuter la caméra, vous devez mettre à jour les politiques SELinux pour donner les autorisations appropriées au serveur de la caméra. Nous déconseillons de répliquer les politiques SELinux du serveur multimédia pour le serveur de caméra (car le serveur multimédia et le serveur de caméra 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 Camera HAL et cameraserver. Android 8.0 et versions ultérieures séparent en outre la HAL de la caméra binderized dans un processus différent de cameraserver. IPC traverse défini HIDL- interfaces.

Validation

Pour tous les appareils qui incluent une caméra et exécutent Android 7.0, vérifiez la mise en œuvre en exécutant Android 7.0 CTS. Bien qu'Android 7.0 n'inclue pas de nouveaux tests CTS qui vérifient les changements de service de 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 et versions ultérieures, vérifiez la mise en œuvre du fournisseur en exécutant VTS.

Historique des versions de la caméra HAL

Pour une liste des tests disponibles pour évaluer la caméra Android HAL, consultez la caméra HAL Liste d' essai .

Android 10

Android 10 introduit les mises à jour suivantes.

API de caméra

Caméra HAL

Les versions suivantes de Camera HAL sont mises à jour dans Android 10.

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics : Les informations de la caméra statique pour un identifiant de la caméra physique de support d' un dispositif de caméra logique. Voir Prise en charge multi-caméra .
  • isStreamCombinationSupported : Cette méthode prend en charge une API publique qui aide les clients requête si une configuration de session est pris en charge. Voir API pour les combinaisons de flux de requête .

ICameraDeviceSession

  • isReconfigurationNeeded : Méthode qui indique le cadre de la caméra si la reconfiguration du flux complet est nécessaire pour d' éventuelles nouvelles valeurs des paramètres de session. Cela permet d'éviter les retards inutiles de reconfiguration de la caméra. Voir requête de reconfiguration session .
  • API de gestion de la mémoire tampon HAL : Ces API permettent à la caméra HAL de tampons de demande du cadre de la caméra uniquement si nécessaire au lieu de coupler chaque demande de capture avec ses tampons associés tout au long de la canalisation de la caméra, ce qui entraîne des économies de mémoire potentiellement importantes.
    • signalStreamFlush : Les signaux à la couche d' abstraction que le service de la caméra est sur le point d'effectuer configureStreams_3_5 et que le HAL doit retourner tous les tampons de flux désignés.
    • configureStreams_3_5 : Similaire à ICameraDevice3.4.configureStreams , mais en plus, le streamConfigCounter compteur est fourni pour vérifier une condition de course entre les configureStreams_3_5 et signalStreamFlush appels.

Les mises à jour ICameraDeviceCallback :

  • requestStreamBuffers : rappel synchrone que la caméra HAL appelle à demander au serveur de la caméra pour les tampons. Voir requestStreamBuffers .
  • returnStreamBuffers : rappel synchrone pour la caméra HAL pour retourner des tampons de sortie vers le serveur de la caméra. Voir returnStreamBuffers .

3.4

Les clés suivantes sont ajoutées aux métadonnées de l'appareil photo dans Android 10.

  • Formats d'images
    • 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
  • Les valeurs de la ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT clé
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • Configurations de flux de profondeur dynamique 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 notifyDeviceStateChange procédé de dispositifs de notifier la caméra HAL lorsque des changements physiques, telles que le pliage, affectent la caméra et de routage.

2.4

  • Dispositifs de lancement avec le niveau de l' API 29 ou supérieur doivent signaler true pour isTorchModeSupported .

Android 9

La version Android 9 introduit les mises à jour suivantes de l'interface API2 et HAL de la caméra.

API de 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 appareil en tant qu'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éra .
  • 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 la 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 un mouvement suivi dans l' intention CAPTURE_INTENT . Voir CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • Deprecates LENS_RADIAL_DISTORTION et ajoute LENS_DISTORTION à sa place.
  • Ajoute les modes de correction de la distorsion dans CaptureRequest . Voir DISTORTION_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

Les mises à jour ICameraDeviceSession

Les mises à jour ICameraDeviceCallback

3.3

Les clés suivantes sont ajoutées aux métadonnées de l'appareil photo 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, fournisseur implémentations caméra HAL doivent être binderized . Android 8.0 contient également ces améliorations clés du service Appareil photo :

  • Surfaces partagées: plusieurs surfaces Activer le partage de la même OutputConfiguration
  • API système pour les modes de caméra personnalisés
  • onCaptureQueueEmpty

Voir les sections ci-dessous pour plus d'informations sur ces fonctionnalités.

Surfaces partagées

Cette fonctionnalité permet à un seul jeu de tampons de piloter 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 HAL de caméra et de HAL gralloc peuvent créer des tampons gralloc qui sont utilisés par plusieurs consommateurs différents (tels que le compositeur/GPU matériel et l'encodeur vidéo), au lieu d'un seul consommateur. Le service de caméra transmet les indicateurs d'utilisation du consommateur à la caméra HAL et à la gralloc HAL ; 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.

Voir la enableSurfaceSharing documentation développeur pour obtenir de plus amples renseignements.

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 nombre entier passé à configure_streams . Voir: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

Cette fonctionnalité inclut 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 à HAL sur configure_streams, puis faire en sorte que leur application de caméra personnalisée utilise 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 .

onCaptureQueueVide

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 des demandes aussi vide que possible. onCaptureQueueEmpty ne nécessite aucun travail de HAL; c'était purement un ajout côté cadre. Les applications qui souhaitent en profiter doivent ajouter un écouteur à ce rappel et répondre de manière appropriée. Généralement, c'est en envoyant une autre demande de capture à l'appareil photo.

Interface caméra HIDL

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 versions héritées les plus récentes 3.4 et 2.4 (pour le module de 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 :

  • Ajouter ANDROID_SENSOR_OPAQUE_RAW_SIZE métadonnées statiques comme obligatoire si RAW_OPAQUE format est pris en charge.
  • Ajouter ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE métadonnées statiques comme obligatoire si un format RAW est pris en charge.
  • Commutateur camera3_stream_t data_space champ à une définition plus souple, en utilisant la version 0 définition du codage DataSpace.
  • 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 HAL à capacité étendue :

  • Mises à jour des 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 .
  • L' addition de champ de rotation à camera3_stream_t .
  • Ajout du mode de fonctionnement de configuration du flux de camera3 à camera3_stream_configuration_t .

3.2

Révision mineure de HAL à capacité étendue :

  • Réprouve get_metadata_vendor_tag_ops . Utilisez get_vendor_tag_ops dans camera_common.h à la place.
  • Réprouve register_stream_buffers . Tous les tampons fournis par gralloc cadre de HAL en process_capture_request peut être nouveau à tout moment.
  • Ajout de la prise en charge des résultats partiels. process_capture_result peut être appelé plusieurs fois avec un sous - ensemble des résultats disponibles avant que le résultat complet est disponible.
  • Ajouter 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 de process_capture_request .

3.1

Révision mineure de HAL à capacité étendue :

  • configure_streams passe drapeaux d'utilisation des consommateurs sur HAL.
  • flush call pour supprimer toutes les demandes/tampons en vol aussi vite que possible.

3.0

Première révision de HAL à capacité étendue :

  • Changement de version majeur puisque l'ABI est complètement différent. Aucune modification des capacités matérielles requises ou du modèle opérationnel depuis la version 2.0.
  • Interfaces de requête d'entrée et de file d'attente de flux retravaillées : le framework appelle dans HAL avec la prochaine requête et les tampons de flux déjà retirés de la file d'attente. La prise en charge du cadre de synchronisation est incluse, nécessaire pour des implémentations efficaces.
  • Déclencheurs déplacés dans les demandes, la plupart des notifications dans les résultats.
  • Consolidé dans tous les callbacks cadre dans une seule structure, et toutes les méthodes de configuration en un seul initialize() appel.
  • Configuration du flux en un seul appel pour simplifier la gestion du flux. Flux bidirectionnels remplacer le STREAM_FROM_STREAM construction.
  • Sémantique en mode limité pour les périphériques matériels plus anciens/limités.

2.0

Version initiale de HAL à capacité étendue (Android 4.2) [camera2.h] :

  • Suffisante pour la mise en œuvre existante android.hardware.Camera API.
  • Permet la file d'attente ZSL dans la couche de service de caméra.
  • Non testé pour les nouvelles fonctionnalités telles que le contrôle de capture manuel, la capture Bayer RAW, le retraitement des données RAW, etc.

1,0

Appareil photo Android initial HAL (Android 4.0) [camera.h] :

  • Converti à partir de la couche d'abstraction C++ CameraHardwareInterface.
  • Prise en charge android.hardware.Camera API.

Historique des versions du module de caméra

Cette section contient des informations module versioning pour le module matériel de l' appareil photo, sur la base camera_module_t.common.module_api_version . Les deux chiffres hexadécimaux les plus significatifs représentent la version majeure 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 :

  1. Prise en charge du mode torche. Le cadre peut activer le mode torche pour tout appareil photo doté d'un flash, sans ouvrir un appareil photo. L'appareil photo a une priorité plus élevée pour accéder au flash que le module de l'appareil photo ; l'ouverture d'un appareil photo éteint la torche si elle a été activée via l'interface du module. Quand il y a des conflits de ressources, comme open() est appelée à ouvrir un dispositif de caméra, le module de caméra HAL doit informer le cadre par l'état du mode de la torche rappel que le mode de la torche a été désactivé.
  2. 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 hot-plug externes. Les appels pour obtenir des informations statiques sont des appels non valides lorsque l' état de l' appareil photo est pas CAMERA_DEVICE_STATUS_PRESENT . Le cadre compte uniquement sur les rappels de changement d'état de l'appareil pour gérer la liste des caméras externes disponibles.
  3. Conseils d'arbitrage de la caméra. Ajoute la prise en charge de l'indication explicite du nombre de caméras pouvant être simultanément ouvertes et utilisées. Pour spécifier des combinaisons valides de périphériques, les resource_cost et conflicting_devices champs doivent toujours être dans la camera_info structure retournée par le get_camera_info appel.
  4. Méthode d'initialisation du module. Appelé par le service caméra après le chargement du module HAL pour permettre une initialisation unique de HAL. Il est appelé avant toute autre méthode de module.

2.3

Cette version du module de caméra ajoute la prise en charge des périphériques HAL de caméra hérités ouverts. Le framework 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. Le module matériel standard appel ouvert ( common.methods->open ) continue d'ouvrir l'appareil de la caméra avec la dernière version prise en charge, qui est également la version indiquée dans camera_info_t.device_version .

2.2

Cette version du module de caméra ajoute le support d'étiquette de fournisseur du module, et deprecates les anciens vendor_tag_query_ops qui étaient auparavant accessibles uniquement avec un dispositif ouvert.

2.1

Cette version du module de caméra ajoute la prise en charge des rappels asynchrones au framework depuis le module HAL de la caméra, qui est utilisé pour informer le framework des modifications apportées à l'état du module de caméra. Les modules qui fournissent un valide set_callbacks() doit la méthode rapport 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 device_version domaine de camera_info est toujours valide; le static_camera_characteristics domaine de camera_info est valide si le device_version champ est de 2,0 ou plus.

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 périphériques de caméra pouvant être ouverts via ce module ne prennent en charge que la version 1 du périphérique de caméra HAL. Les device_version et static_camera_characteristics champs de camera_info ne sont pas valides. Seule la android.hardware.Camera API peut être pris en charge par ce module et ses périphériques.