Compatibilité des versions de l'appareil photo

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.

    Appareil photo et contenus multimédias Android 7.0 pile dans API1 sur HAL3

    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.)

    Appareil photo et contenus multimédias Android 7.0 pile dans API1 sur HAL1

    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:

    Appareil photo Android 7.0 et pile multimédia dans l&#39;API2 sur HAL3

    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 transmettre VideoNativeHandleMetadata dans les tampons vidéo. (kMetadataBufferTypeCameraSource n'est plus compatible avec Android 7.0.) Avec VideoNativeHandleMetadata, 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

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 commande configureStreams_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 compteur streamConfigCounter est fourni recherche une condition de concurrence entre configureStreams_3_5 et signalStreamFlush.

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 pour isTorchModeSupported.

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 de sessionParameters 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 format RAW_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. Utilisez get_vendor_tag_ops à la place dans camera_common.h.
  • Abandon de register_stream_buffers. Tous les tampons Gralloc fourni par le framework à HAL dans process_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 de process_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:

  1. 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é.
  2. 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.
  3. 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 champs conflicting_devices doivent toujours être définis dans le Structure camera_info renvoyée par get_camera_info .
  4. 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.