Compatibilité des versions de l'appareil photo

Cette page détaille les différences de version entre les HAL de l'appareil photo, les API et les tests CTS (Compatibility Test Suite) associés. Il couvre également plusieurs modifications d'architecture apportées pour renforcer et sécuriser le framework de l'appareil photo 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 d'appareil photo.

Terminologie

Les termes suivants sont utilisés sur cette page:

API Camera1
Framework de l'appareil photo au niveau de l'application sur les appareils Android 4.4 ou version antérieure, 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.
HAL de l'appareil photo
Couche du module de caméra implémentée par les fournisseurs de SoC. Les frameworks publics au niveau de l'application sont basés sur le HAL de la caméra.
Camera HAL3.1
Version du HAL de l'appareil photo publiée avec Android 4.4.
Camera HAL3.2
Version du HAL de l'appareil photo publiée avec Android 5.0.
CTS de l'API Camera1
Ensemble de tests CTS de l'appareil photo exécutés sur l'API 1 de l'appareil photo.
CTS de l'API Camera2
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 les fabricants de silicium) du framework de l'OS Android via une nouvelle interface de fournisseur.
HIDL
Langage de définition d'interface HAL introduit avec Treble et utilisé pour spécifier l'interface entre un HAL et ses utilisateurs.
VTS
Suite de tests du fournisseur lancée avec Treble.

API de la caméra

Android inclut les API de caméra suivantes.

API Camera1

Android 5.0 a abandonné l'API Camera1, qui continue d'être abandonnée à mesure que le développement de la nouvelle plate-forme se concentre sur l'API Camera2. Toutefois, la période d'abandon sera longue, et les versions d'Android continueront de prendre en charge les applications de l'API Camera1 pendant un certain temps. Plus précisément, l'assistance continue pour:

  • Interfaces de l'API 1 de l'appareil photo pour les applications Les applications d'appareil photo basées sur l'API 1 de l'appareil photo doivent fonctionner comme sur les appareils exécutant des versions d'Android antérieures.
  • Versions de l'HAL de la caméra. Inclut la prise en charge de la couche HAL de l'appareil photo 1.0.

API Camera2

Le framework Camera API2 expose un contrôle de l'appareil photo de niveau inférieur à l'application, y compris des flux de streaming/rafales efficaces sans copie et des commandes par frame de l'exposition, du gain, des gains de balance des blancs, de la conversion des couleurs, du dénoyage, de l'accentuation, etc. Pour en savoir plus, regardez la présentation vidéo de Google I/O.

Android 5.0 et versions ultérieures incluent l'API Camera2. Toutefois, les appareils équipés d'Android 5.0 ou version ultérieure ne sont pas nécessairement compatibles avec toutes les fonctionnalités de l'API Camera2. La propriété android.info.supportedHardwareLevel que les applications peuvent interroger via les interfaces de l'API Camera2 indique l'un des niveaux de compatibilité suivants:

  • LEGACY: ces appareils exposent des fonctionnalités aux applications via les interfaces Camera API2 qui sont à peu près les mêmes que celles exposées aux applications via les interfaces Camera API1. Le code des anciens frameworks traduit conceptuellement les appels d'API Camera2 en appels d'API Camera1. Les anciens appareils ne sont pas compatibles avec les fonctionnalités de l'API Camera2, telles que les commandes par frame.
  • LIMITED: ces appareils sont compatibles avec certaines fonctionnalités de l'API Camera2 (mais pas toutes) et doivent utiliser Camera HAL 3.2 ou une version ultérieure.
  • FULL: ces appareils prennent en charge toutes les principales fonctionnalités de l'API Camera2 et doivent utiliser Camera HAL 3.2 ou version ultérieure, ainsi qu'Android 5.0 ou version ultérieure.
  • LEVEL_3: ces appareils sont compatibles avec le retraitement YUV et la capture d'images RAW, ainsi qu'avec des configurations de flux de sortie supplémentaires.
  • EXTERNAL: ces appareils sont semblables aux appareils LIMITED, à quelques exceptions près. Par exemple, certaines informations sur les capteurs ou les objectifs 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.

Les fonctionnalités individuelles sont exposées via la propriété android.request.availableCapabilities dans les interfaces de l'API Camera2. Les appareils FULL nécessitent les fonctionnalités MANUAL_SENSOR et MANUAL_POST_PROCESSING, entre autres. La fonctionnalité RAW est facultative, même pour les appareils FULL. Les appareils LIMITED peuvent annoncer n'importe quel sous-ensemble de ces fonctionnalités, y compris aucun. Toutefois, la capacité BACKWARD_COMPATIBLE doit toujours être définie.

Le niveau matériel compatible de l'appareil, ainsi que les fonctionnalités spécifiques de l'API Camera2 qu'il prend en charge, sont disponibles sous forme de flags de fonctionnalités permettant à Google Play de filtrer les 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 du CTS

Les appareils équipés d'Android 5.0 ou version ultérieure doivent réussir les tests CTS de l'API 1 de la caméra, de l'API 2 de la caméra et du vérificateur CTS de la caméra.

Les appareils qui ne disposent pas d'une implémentation HAL3.2 d'appareil photo et qui ne sont pas compatibles avec l'ensemble des interfaces de l'API Camera2 doivent tout de même réussir les tests CTS de l'API Camera2. Toutefois, l'appareil s'exécute en mode LEGACY de l'API Camera2 (dans lequel les appels de l'API Camera2 sont mappés conceptuellement aux appels de l'API Camera1). Par conséquent, tous les tests CTS de l'API Camera2 liés aux fonctionnalités ou aux fonctionnalités au-delà de l'API Camera1 sont automatiquement ignorés.

Sur les anciens appareils, les tests CTS de l'API Camera2 exécutés utilisent les interfaces et fonctionnalités publiques existantes de l'API Camera1, sans nouvelles exigences. Les bugs exposés (qui provoquent un échec CTS de l'API Camera2) sont des bugs déjà présents dans le HAL de l'appareil photo existant de l'appareil et seraient donc détectés par les applications existantes de l'API Camera1. Nous ne nous attendons pas à de nombreux bugs de cette nature (cependant, tous ces bugs doivent être corrigés pour réussir les tests CTS de l'API Camera2).

Exigences concernant les VTS

Les appareils équipés d'Android 8.0 ou version ultérieure avec des implémentations HAL liées doivent réussir les tests VTS de la caméra.

Renforcement du framework de la caméra

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

Modifications architecturales pour l'API1

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

  • HAL3, où le service d'appareil photo utilise BufferQueue pour transmettre des tampons entre les processus, aucune mise à jour du fournisseur n'est nécessaire.

    Pile appareil photo et multimédia Android 7.0 dans l'API 1 sur HAL3

    Figure 1. Pile appareil photo et multimédia Android 7.0 dans l'API 1 sur HAL3

  • HAL1, qui permet de transmettre des métadonnées dans des tampons vidéo, les fournisseurs doivent mettre à jour le HAL pour utiliser kMetadataBufferTypeNativeHandleSource. (kMetadataBufferTypeCameraSource n'est plus compatible avec Android 7.0.)

    Pile appareil photo et multimédia Android 7.0 dans l'API 1 sur HAL 1

    Figure 2 Pile appareil photo et multimédia Android 7.0 dans l'API 1 sur HAL1

Modifications architecturales pour l'API2

Pour l'API 2 sur HAL1 ou HAL3, BufferQueue transmet des tampons pour que ces chemins continuent de fonctionner. Architecture Android 7.0 pour l'API 2 sur:

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

    Pile caméra et multimédia Android 7.0 dans l'API 2 sur HAL3

    Figure 3. Stache de caméra et de médias Android 7.0 dans l'API 2 sur HAL3

Exigences supplémentaires

Les modifications architecturales apportées pour renforcer la sécurité du framework multimédia et de la caméra incluent les exigences d'appareil supplémentaires suivantes.

  • 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 des caméras sensibles au temps, tels que l'enregistrement vidéo à grande vitesse. Les fournisseurs peuvent mesurer l'impact réel en exécutant android.hardware.camera2.cts.PerformanceTest et l'application Google Caméra pour l'enregistrement vidéo haute vitesse à 120/240 FPS. Les appareils nécessitent également une petite quantité de RAM supplémentaire pour créer le nouveau processus.
  • Transmettre des métadonnées dans les tampons vidéo (HAL1 uniquement) Si HAL1 stocke des métadonnées au lieu de données de frame YUV réelles dans les tampons vidéo, le HAL doit utiliser kMetadataBufferTypeNativeHandleSource comme type de tampon de métadonnées 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 multimédias peuvent transmettre les tampons vidéo entre les processus en sérialisant et désérilant correctement les poignées natives.
  • L'adresse de l'identifiant de tampon ne stocke pas toujours le même tampon (HAL3 uniquement). Pour chaque requête de capture, HAL3 obtient les adresses des poignées de tampon. HAL ne peut pas utiliser les adresses pour identifier les tampons, car les adresses peuvent stocker un autre gestionnaire de tampon après que HAL a renvoyé le tampon. Vous devez mettre à jour le HAL pour utiliser des poignées de tampon pour identifier les tampons. Par exemple, le HAL reçoit une adresse de poignée de tampon A, qui stocke la poignée de tampon A. Une fois que le HAL a renvoyé le conteneur de tampon A, l'adresse du conteneur de tampon A peut stocker le conteneur de tampon B la prochaine fois que le HAL le recevra.
  • Mise à jour des règles SELinux pour cameraserver. Si les règles SELinux spécifiques à l'appareil accordent à mediaserver les autorisations d'exécuter la caméra, vous devez mettre à jour les règles SELinux pour accorder à cameraserver les autorisations appropriées. Nous déconseillons de répliquer les règles SELinux du mediaserver pour le cameraserver (car le mediaserver et le cameraserver nécessitent généralement des ressources différentes dans le système). Cameraserver ne doit disposer que des autorisations nécessaires pour exécuter les fonctionnalités de l'appareil photo. Toutes les autorisations liées à l'appareil photo inutiles dans mediaserver doivent être supprimées.
  • Séparation entre le HAL de la caméra et le serveur de caméra. Android 8.0 et versions ultérieures séparent également le HAL de l'appareil photo lié dans un processus différent de cameraserver. L'IPC passe par des interfaces définies par HIDL.

Validation

Pour tous les appareils qui incluent une caméra et exécutent Android 7.0, vérifiez l'implémentation en exécutant Android 7.0 CTS. Bien qu'Android 7.0 n'inclue pas de nouveaux tests CTS qui vérifient les modifications apportées au service de l'appareil photo, les tests CTS existants échouent si vous n'avez pas effectué les mises à jour indiquées ci-dessus.

Pour tous les appareils équipés d'une caméra et exécutant 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 la checklist de test du HAL de l'appareil photo.

Android 10

Android 10 introduit les mises à jour suivantes.

API Camera

HAL de l'appareil photo

Les versions HAL de l'appareil photo suivantes sont mises à jour dans Android 10.

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics : informations statiques sur la caméra pour un ID de caméra physique qui prend en charge un appareil photo logique. Consultez la section Compatibilité avec plusieurs caméras.
  • isStreamCombinationSupported: cette méthode est compatible avec une API publique qui aide les clients à déterminer si une configuration de session est prise en charge. Consultez la section API permettant d'interroger les combinaisons de flux.

ICameraDeviceSession

  • isReconfigurationNeeded : méthode qui indique au framework de la caméra si une reconfiguration complète du flux est requise pour les nouvelles valeurs de paramètre de session possibles. Cela permet d'éviter les délais de reconfiguration inutiles de la caméra. Consultez la section Requête de reconfiguration de session.
  • API de gestion des tampons HAL: ces API permettent au HAL de l'appareil photo de ne demander des tampons au framework de l'appareil photo que lorsque cela est nécessaire, au lieu de coupler chaque requête de capture avec ses tampons associés tout au long du pipeline de l'appareil photo, ce qui permet de réaliser des économies de mémoire potentiellement importantes.
    • signalStreamFlush: signale au HAL que le service de caméra est sur le point d'effectuer configureStreams_3_5 et que le HAL doit renvoyer tous les tampons des flux désignés.
    • configureStreams_3_5: semblable à ICameraDevice3.4.configureStreams, mais en plus, le compteur streamConfigCounter est fourni pour vérifier une condition de course entre les appels configureStreams_3_5 et signalStreamFlush.

Mises à jour de l'outil ICameraDeviceCallback :

  • requestStreamBuffers : rappel synchrone appelé par le HAL de la caméra pour demander des tampons au serveur de la caméra. Consultez requestStreamBuffers.
  • returnStreamBuffers : rappel synchrone pour que le HAL de la caméra renvoie des tampons de sortie au serveur de la caméra. Consultez returnStreamBuffers.

3.4

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

  • Formats d'image
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • Tags de métadonnées de la caméra
    • 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
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
  • Valeurs de la clé ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • Configurations de flux de profondeur 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 de caméras

Les versions de module photo suivantes sont mises à jour dans Android 10.

2.5

  • Ajoute la méthode notifyDeviceStateChange pour que les appareils puissent avertir le HAL de la caméra lorsque des modifications physiques, telles que le pliage, affectent la caméra et le routage.

2.4

  • Les appareils qui se lancent 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 de l'API2 de l'appareil photo et de l'interface HAL.

API Camera

  • Introduction de l'API multicaméra pour mieux prendre en charge les appareils équipés de plusieurs caméras orientées dans la même direction, ce qui permet d'utiliser des fonctionnalités telles que le bokeh et le zoom fluide. Cela permet aux applications d'afficher plusieurs caméras sur un appareil en tant qu'unité logique (caméra logique). Les requêtes de capture peuvent également être envoyées à des appareils photo individuels inclus dans une caméra logique. Consultez la section Compatibilité avec plusieurs caméras.
  • Présentation des 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. Consultez la section Paramètres de session.
  • Ajoute des clés de données de stabilisation optique (OIS) pour la stabilisation et les effets au niveau de l'application. Consultez STATISTICS_OIS_SAMPLES pour en savoir plus.
  • Ajout de la compatibilité avec le flash externe. Voir CONTROL_AE_MODE_ON_EXTERNAL_FLASH pour plus d'informations.
  • Ajoute un intent de suivi du mouvement dans CAPTURE_INTENT. Consultez CONTROL_CAPTURE_INTENT_MOTION_TRACKING pour en savoir plus.
  • Abandon de LENS_RADIAL_DISTORTION et ajout de LENS_DISTORTION à la place.
  • Ajoute des modes de correction de la distorsion dans CaptureRequest. Consultez DISTORTION_CORRECTION_MODE pour en savoir plus.
  • Ajout de la compatibilité avec les caméras USB/UVC externes sur les appareils compatibles. Consultez INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL pour en savoir plus.

HAL de l'appareil photo

3.4

Mises à jour de ICameraDeviceSession

Mises à jour de ICameraDeviceCallback

3.3

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

  • Fonctionnalités
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • Tags de métadonnées de la caméra
    • ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
    • ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE
    • ANDROID_DISTORTION_CORRECTION_AVAILABLE_MODES
    • ANDROID_LENS_POSE_REFERENCE
    • ANDROID_LENS_DISTORTION
    • ANDROID_REQUEST_AVAILABLE_SESSION_KEYS
    • ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS
    • ANDROID_STATISTICS_OIS_DATA_MODE
    • ANDROID_STATISTICS_OIS_TIMESTAMPS
    • ANDROID_STATISTICS_OIS_X_SHIFTS
    • ANDROID_STATISTICS_OIS_Y_SHIFTS

Android 8.0

La version Android 8.0 introduit Treble. Avec Treble, les implémentations du HAL de l'appareil photo du fournisseur doivent être liées. Android 8.0 contient également les principales améliorations apportées au service Appareil photo:

  • Surfaces partagées: permet à plusieurs surfaces de partager le 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é n'autorise qu'un seul ensemble de tampons à 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 d'appareils doivent s'assurer que leurs implémentations du HAL de l'appareil photo et du HAL gralloc peuvent créer des tampons gralloc utilisés par plusieurs consommateurs différents (tels que le compositeur matériel/GPU et l'encodeur vidéo), au lieu d'un seul consommateur. Le service de l'appareil photo transmet les indicateurs d'utilisation des consommateurs au HAL de l'appareil photo et au HAL gralloc. Ils doivent allouer les types de tampons appropriés, ou le HAL de l'appareil photo doit renvoyer une erreur indiquant que cette combinaison de consommateurs n'est pas prise en charge.

Pour en savoir plus, consultez la documentation destinée aux développeurs enableSurfaceSharing.

API système pour les modes d'appareil photo personnalisés

L'API publique de l'appareil photo définit deux modes de fonctionnement: l'enregistrement normal et l'enregistrement haute vitesse contraint. Ils ont une sémantique assez différente. Par exemple, le mode haute vitesse est limité à deux sorties spécifiques au maximum à la fois. Plusieurs OEM ont exprimé leur intérêt à définir d'autres modes personnalisés pour les fonctionnalités spécifiques au matériel. En interne, le mode n'est qu'un entier transmis à configure_streams. Consultez 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 un mode personnalisé. Ces modes doivent commencer à la valeur entière 0x8000 pour éviter les conflits avec les futurs modes ajoutés à l'API publique.

Pour prendre en charge cette fonctionnalité, les OEM n'ont qu'à ajouter le nouveau mode à leur HAL, déclenché par cet entier transmis au HAL sur configure_streams, puis à demander à leur application d'appareil photo personnalisée d'utiliser l'API système.

Le nom de la méthode est android.hardware.camera2.CameraDevice#createCustomCaptureSession. Consultez frameworks/base/core/java/android/hardware/camera2/CameraDevice.

onCaptureQueueEmpty

L'objectif de cette API est de réduire la latence des modifications de contrôle telles que le zoom en maintenant la file d'attente de requêtes aussi vide que possible. onCaptureQueueEmpty ne nécessite aucune opération HAL. Il s'agit d'un ajout purement côté framework. Les applications qui souhaitent en profiter doivent ajouter un écouteur à ce rappel et y répondre de manière appropriée. En général, cela se fait en envoyant une autre requête de capture à l'appareil photo.

Interface HIDL de la caméra

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 fonctionnalités de l'appareil photo introduites dans les versions précédentes les plus récentes, 3.4 et 2.4 (pour le module de l'appareil photo), font également partie des définitions HIDL.

3.4

Ajouts mineurs aux métadonnées compatibles et modifications apportées à la prise en charge de data_space:

  • Ajoutez les métadonnées statiques ANDROID_SENSOR_OPAQUE_RAW_SIZE comme obligatoires si le format RAW_OPAQUE est compatible.
  • Ajoutez les métadonnées statiques ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE comme obligatoires si un format RAW est accepté.
  • Passez le champ camera3_stream_t data_space à une définition plus flexible, en utilisant la définition de la version 0 de l'encodage de l'espace de données.
  • Ajouts de métadonnées généraux disponibles pour HALv3.2 ou version ultérieure :
    • ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
    • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
    • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
    • ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
    • ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
    • ANDROID_SENSOR_OPAQUE_RAW_SIZE
    • ANDROID_SENSOR_OPTICAL_BLACK_REGIONS

3.3

Révision mineure de la HAL à capacités étendues:

  • Mises à jour de l'API OPAQUE et de la re-métadate de YUV.
  • Prise en charge de base des tampons de sortie de profondeur.
  • Ajout du champ data_space à camera3_stream_t.
  • Ajout du champ de rotation à camera3_stream_t.
  • Ajout du mode de fonctionnement de la configuration du flux camera3 à camera3_stream_configuration_t.

3.2

Révision mineure de la HAL à capacités étendues:

  • Abandon de get_metadata_vendor_tag_ops. Utilisez plutôt get_vendor_tag_ops dans camera_common.h.
  • Abandon de register_stream_buffers. Tous les tampons gralloc fournis par le framework à HAL dans process_capture_request peuvent être nouveaux à 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 ne soit disponible.
  • Ajout d'un modèle manuel à camera3_request_template. Les applications peuvent utiliser ce modèle pour contrôler directement les paramètres de capture.
  • Retravaillez les spécifications des flux bidirectionnels et 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 la HAL à capacités étendues:

  • configure_streams transmet les indicateurs d'utilisation des consommateurs au HAL.
  • Appel de vidage pour supprimer toutes les requêtes/tampons en cours aussi rapidement que possible.

3,0

Première révision de la HAL à capacités étendues:

  • Changement de version majeure, car l'ABI est complètement différent. Aucune modification des fonctionnalités matérielles requises ou du modèle opérationnel par rapport à la version 2.0.
  • Interfaces de requête d'entrée et de file d'attente de flux retravaillées: le framework appelle HAL avec la prochaine requête et les tampons de flux déjà déchargés de la file d'attente. La prise en charge du framework de synchronisation est incluse, ce qui est nécessaire pour des implémentations efficaces.
  • Les déclencheurs ont été déplacés vers les requêtes et la plupart des notifications vers les résultats.
  • Consolidation de tous les rappels dans le framework en une seule structure, et de toutes les méthodes de configuration en un seul appel initialize().
  • La configuration des flux est désormais effectuée en un seul appel pour simplifier la gestion des flux. Les flux bidirectionnels remplacent la construction STREAM_FROM_STREAM.
  • Sémantique du mode limité pour les appareils matériels plus anciens/limités.

2.0

Version initiale de HAL à fonctionnalités étendues (Android 4.2) [camera2.h]:

  • Suffisante pour implémenter l'API android.hardware.Camera existante.
  • Permet la file d'attente ZSL dans la couche de service de l'appareil photo.
  • Aucune nouvelle fonctionnalité n'a été testée, comme le contrôle manuel de la capture, la capture RAW Bayer, le retraitement des données RAW, etc.

1.0

HAL de la caméra Android initiale (Android 4.0) [camera.h]:

  • Converti à partir de la couche d'abstraction CameraHardwareInterface C++.
  • Compatible avec l'API android.hardware.Camera.

Historique des versions du module de caméras

Cette section contient des informations de gestion des versions pour le module matériel de la caméra, basé sur 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 d'appareil photo ajoute les modifications d'API suivantes:

  1. Compatibilité avec le mode lampe de poche. Le framework peut activer le mode lampe de poche pour tout appareil photo doté d'un flash, sans ouvrir l'appareil photo. L'appareil photo a une priorité d'accès au flash plus élevée que le module de l'appareil photo. L'ouverture d'un appareil photo éteint la lampe de poche si elle a été activée via l'interface du module. En cas de conflit de ressources, par exemple si open() est appelé pour ouvrir un appareil photo, le module HAL de la caméra doit avertir le framework via le rappel d'état du mode lampe de poche que le mode lampe de poche a été désactivé.
  2. Compatibilité avec les appareils photo externes (par exemple, les appareils photo USB en mode "plug and play"). Les mises à jour de l'API spécifient que les informations statiques de la caméra ne sont disponibles que lorsque la caméra est connectée et prête à l'emploi pour les caméras externes en prise chaude. Les appels permettant d'obtenir des informations statiques sont des appels non valides lorsque l'état de la caméra n'est pas CAMERA_DEVICE_STATUS_PRESENT. Le framework ne compte que sur les rappels de modification de l'état de l'appareil pour gérer la liste des caméras externes disponibles.
  3. Conseils d'arbitrage de la caméra. Ajoute la possibilité d'indiquer explicitement le nombre d'appareils photo pouvant être ouverts et utilisés simultanément. Pour spécifier des combinaisons d'appareils valides, les champs resource_cost et conflicting_devices doivent toujours être définis dans la structure camera_info renvoyée par l'appel get_camera_info.
  4. Méthode d'initialisation du module. Appelé par le service de la caméra après le chargement du module HAL pour permettre une initialisation unique du HAL. Il est appelé avant l'appel de toute autre méthode du module.

2.3

Cette version du module photo ajoute la prise en charge des anciens appareils HAL de caméra. Le framework peut l'utiliser pour ouvrir l'appareil photo en tant qu'appareil HAL de version inférieure si le même appareil peut prendre en charge plusieurs versions d'API d'appareil. L'appel d'ouverture du module matériel standard (common.methods->open) continue d'ouvrir l'appareil photo avec la dernière version compatible, qui est également la version listée dans camera_info_t.device_version.

2,2

Cette version du module de caméra ajoute la prise en charge de la balise du fournisseur à partir du module et abandonne l'ancienne vendor_tag_query_ops qui n'était auparavant accessible que lorsque l'appareil était ouvert.

3,4

Cette version du module de caméra prend en charge les rappels asynchrones dans le framework à partir du module HAL de la caméra, qui permet d'informer le framework des modifications apportées à l'état du module de la caméra. Les modules qui fournissent une méthode set_callbacks() valide doivent indiquer au moins ce numéro de version.

2.0

Les modules d'appareil photo qui signalent ce numéro de version implémentent la deuxième version de l'interface HAL du module d'appareil photo. Les appareils photo pouvant être ouverts via ce module peuvent être compatibles avec la version 1.0 ou la version 2.0 de l'interface HAL de l'appareil photo. Le champ device_version de camera_info est toujours valide. Le champ static_camera_characteristics de camera_info est valide si le champ device_version est défini sur 2.0 ou version ultérieure.

1.0

Les modules d'appareil photo qui signalent ces numéros de version implémentent l'interface HAL du module d'appareil photo initial. Tous les appareils photo pouvant être ouverts via ce module ne sont compatibles qu'avec la version 1 de la HAL de l'appareil photo. Les champs device_version et static_camera_characteristics de camera_info ne sont pas valides. Seule l'API android.hardware.Camera peut être prise en charge par ce module et ses appareils.