Supporto delle versioni della videocamera

Questa pagina descrive le differenze di versione nelle API e negli HAL della fotocamera e nei test associati della Compatibility Test Suite (CTS). Copre inoltre diverse modifiche dell'architettura apportate per rafforzare e proteggere il framework della fotocamera in Android 7.0, il passaggio a Treble in Android 8.0 e gli aggiornamenti che i fornitori devono apportare per supportare queste modifiche nelle implementazioni della fotocamera.

Terminologia

In questa pagina vengono utilizzati i seguenti termini:

API Camera1

Il framework della fotocamera a livello di app sui dispositivi Android 4.4 e versioni precedenti, esposto tramite la classe android.hardware.Camera.

API Camera2

Il framework della fotocamera a livello di app sui dispositivi con Android 5.0 e versioni successive, esposto tramite il pacchetto android.hardware.camera2.

HAL della fotocamera

Il livello del modulo della videocamera implementato dai fornitori di SoC. I framework pubblici a livello di app sono basati sull'HAL della fotocamera.

HAL3.1 della fotocamera

Versione dell'HAL del dispositivo della videocamera rilasciata con Android 4.4.

HAL Camera 3.2

Versione dell'HAL del dispositivo della fotocamera rilasciata con Android 5.0.

CTS dell'API Camera1

Serie di test CTS della videocamera eseguiti sull'API Camera 1.

CTS dell'API Camera 2

Serie aggiuntiva di test CTS della fotocamera eseguiti sull'API Camera2.

Alti

Separa l'implementazione del fornitore (software di livello inferiore specifico per il dispositivo scritto dai produttori di silicio) dal framework del sistema operativo Android tramite una nuova interfaccia del fornitore.

HIDL

Language di definizione dell'interfaccia HAL introdotto con Treble e utilizzato per specificare l'interfaccia tra un HAL e i suoi utenti.

VTS

Suite di test del fornitore introdotta insieme a Treble.

API di gestione della fotocamera

Android include le seguenti API per le videocamere.

API Camera1

Android 5.0 ha ritirato l'API Camera1, che continuerà a essere ritirata man mano che lo sviluppo della nuova piattaforma si concentrerà sull'API Camera2. Tuttavia, il periodo di ritiro sarà lungo e le release di Android continueranno a supportare le app con API Camera 1 per un po' di tempo. Nello specifico, il supporto continuerà per:

• Interfacce dell'API Camera1 per le app. Le app di fotocamera basate sull'API Camera 1 dovrebbero funzionare come su dispositivi con versioni precedenti di Android.
• Versioni HAL della fotocamera. Include il supporto per Camera HAL 1.0.

API Camera2

Il framework Camera API 2 espone all'app il controllo della fotocamera a livello inferiore, tra cui flussi di streaming/burst a copia zero efficienti e controlli per frame di esposizione, guadagno, guadagni del bilanciamento del bianco, conversione del colore, riduzione del rumore, nitidezza e altro ancora. Per maggiori dettagli, guarda la panoramica video di Google I/O.

Android 5.0 e versioni successive includono l'API Camera2. Tuttavia, i dispositivi con Android 5.0 e versioni successive potrebbero non supportare tutte le funzionalità dell'API Camera2. La proprietà android.info.supportedHardwareLevel su cui le app possono eseguire query tramite le interfacce dell'API Camera2 riporta uno dei seguenti livelli di assistenza:

• LEGACY: questi dispositivi mettono a disposizione delle app funzionalità tramite le interfacce dell'API Camera2 che sono approssimativamente le stesse di quelle messe a disposizione delle app tramite le interfacce dell'API Camera1. Il codice dei framework precedenti traduce concettualmente le chiamate all'API Camera2 in chiamate all'API Camera1; i dispositivi legacy non supportano le funzionalità dell'API Camera2, come i controlli per frame.
• LIMITED: questi dispositivi supportano alcune funzionalità dell'API Camera2 (ma non tutte) e devono utilizzare Camera HAL 3.2 o versioni successive.
• FULL: questi dispositivi supportano tutte le funzionalità principali dell'API Camera2 e devono utilizzare Camera HAL 3.2 o versioni successive e Android 5.0 o versioni successive.
• LEVEL_3: questi dispositivi supportano la rielaborazione YUV e la cattura di immagini RAW, oltre a configurazioni aggiuntive dello stream di output.
• EXTERNAL: questi dispositivi sono simili ai dispositivi LIMITED con alcune eccezioni; ad esempio, alcune informazioni su sensori o obiettivi potrebbero non essere registrate o avere frame rate meno stabili. Questo livello viene utilizzato per le videocamere esterne, ad esempio le webcam USB.

Le singole funzionalità sono esposte tramite la proprietà android.request.availableCapabilities nelle interfacce dell'API Camera2. I dispositivi FULL richiedono, tra le altre, le funzionalità MANUAL_SENSOR e MANUAL_POST_PROCESSING. La funzionalità RAW è facoltativa anche per i dispositivi FULL. I dispositivi LIMITED possono pubblicizzare qualsiasi sottoinsieme di queste funzionalità, incluso nessuno. Tuttavia, la funzionalità BACKWARD_COMPATIBLE deve essere sempre definita.

Il livello hardware supportato del dispositivo, nonché le funzionalità specifiche dell'API Camera2 supportate, sono disponibili come i seguenti flag di funzionalità per consentire a Google Play di filtrare le app di fotocamere con 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

Requisiti CTS

I dispositivi con Android 5.0 e versioni successive devono superare i test CTS dell'API Camera1, i test CTS dell'API Camera2 e i test della fotocamera di CTS Verifier.

I dispositivi che non dispongono di un'implementazione di Camera HAL3.2 e non sono in grado di supportare le interfacce complete dell'API Camera2 devono comunque superare i test CTS dell'API Camera2. Tuttavia, il dispositivo funziona in modalità Camera API2LEGACY (in cui le chiamate Camera API2 sono mappate concettualmente alle chiamate Camera API1), pertanto tutti i test CTS Camera API2 relativi a funzionalità o funzionalità oltre a Camera API1 vengono ignorati automaticamente.

Sui dispositivi precedenti, i test CTS dell'API Camera2 eseguiti utilizzano le interfacce e le funzionalità pubbliche esistenti dell'API Camera1 senza nuovi requisiti. I bug esposti (e che causano un errore CTS dell'API Camera2) sono bug già presenti nell'HAL Camera esistente del dispositivo e quindi verrebbero rilevati dalle app API Camera1 esistenti. Non prevediamo molti bug di questo tipo (tuttavia, tutti questi bug devono essere corretti per superare i test CTS dell'API Camera2).

Requisiti VTS

I dispositivi con Android 8.0 e versioni successive con implementazioni HAL con binder devono superare i test VTS della fotocamera.

Rafforzamento del framework della videocamera

Per rafforzare la sicurezza del framework multimediale e della fotocamera, Android 7.0 sposta il servizio fotocamera da mediaserver. A partire da Android 8.0, ogni HAL Camera con binder viene eseguito in un processo separato dal servizio della fotocamera. I fornitori potrebbero dover apportare modifiche all'HAL della fotocamera in base alle versioni dell'API e dell'HAL in uso. Le sezioni seguenti descrivono le modifiche all'architettura in AP1 e AP2 per HAL1 e HAL3, nonché i requisiti generali.

Modifiche all'architettura per l'API1

La registrazione video dell'API1 potrebbe presupporre che la videocamera e il codificatore video siano attivi nello stesso procedura. Quando utilizzi l'API1 su:

• HAL3, in cui il servizio della fotocamera utilizza BufferQueue per trasmettere i buffer tra i processi, non è necessario alcun aggiornamento del fornitore.

  

  Figura 1. Piattaforma Media e della fotocamera di Android 7.0 nell'API1 su HAL3

• HAL1, che supporta il passaggio dei metadati nei buffer video, i fornitori devono aggiornare l'HAL per utilizzare kMetadataBufferTypeNativeHandleSource. (kMetadataBufferTypeCameraSource non è più supportato in Android 7.0.)

  

  Figura 2. Piattaforma Media e della fotocamera di Android 7.0 in API1 su HAL1

Modifiche all'architettura per l'API 2

Per l'API 2 su HAL 1 o HAL 3, BufferQueue passa i buffer in modo che questi percorsi continuino a funzionare. L'architettura Android 7.0 per l'API2 su:

• HAL1 non è interessato dal trasferimento di cameraservice e non è necessario alcun update del fornitore.
• HAL3 è interessato, ma non è necessario alcun aggiornamento del fornitore:

  

  Figura 3. Piattaforma Media e Fotocamera di Android 7.0 in API2 su HAL3

Requisiti aggiuntivi

Le modifiche all'architettura apportate per rafforzare la sicurezza del framework per i contenuti multimediali e le videocamere includono i seguenti requisiti aggiuntivi per i dispositivi.

• Generale. I dispositivi richiedono una larghezza di banda aggiuntiva a causa dell'IPC, che potrebbe influire sui casi d'uso della videocamera sensibili al tempo, come la registrazione di video ad alta velocità. I fornitori possono misurare l'impatto effettivo eseguendo android.hardware.camera2.cts.PerformanceTest e l'app Google Foto per la registrazione video ad alta velocità a 120/240 FPS. I dispositivi richiedono inoltre una piccola quantità di RAM aggiuntiva per creare il nuovo processo.
• Passare i metadati nei buffer video (solo HAL1). Se HAL1 memorizza i metadati anziché i dati reali dei frame YUV nei buffer video, l'HAL deve utilizzare kMetadataBufferTypeNativeHandleSource come tipo di buffer di metadati e passare VideoNativeHandleMetadata nei buffer video. (kMetadataBufferTypeCameraSource non è più supportato su Android 7.0.) Con VideoNativeHandleMetadata, i framework della fotocamera e dei contenuti multimediali sono in grado di passare i buffer video tra i processi serializzando e deserializzando correttamente i handle nativi.
• L'indirizzo dell'handle del buffer non memorizza sempre lo stesso buffer (solo HAL3). Per ogni richiesta di acquisizione, HAL3 riceve gli indirizzi degli handle del buffer. HAL non può utilizzare gli indirizzi per identificare i buffer perché gli indirizzi potrebbero memorizzare un altro handle del buffer dopo che HAL ha restituito il buffer. Devi aggiornare l'HAL per utilizzare handle dei buffer per identificare i buffer. Ad esempio, HAL riceve un indirizzo handle del buffer A, che memorizza l'handle del buffer A. Dopo che l'HAL ha restituito il handle del buffer A, l'indirizzo dell'handle del buffer A potrebbe memorizzare l'handle del buffer B la volta successiva che l'HAL lo riceve.
• Aggiorna i criteri SELinux per cameraserver. Se i criteri SELinux specifici del dispositivo assegnano a mediaserver le autorizzazioni per eseguire la fotocamera, devi aggiornare i criteri SELinux per assegnare a cameraserver le autorizzazioni appropriate. sconsigliamo di replicare i criteri SELinux di mediaserver per cameraserver (poiché mediaserver e cameraserver richiedono in genere risorse diverse nel sistema). Cameraserver deve disporre solo delle autorizzazioni necessarie per eseguire le funzionalità della fotocamera e le autorizzazioni relative alla fotocamera non necessarie in mediaserver devono essere rimosse.
• Separazione tra HAL della fotocamera e cameraserver. Android 8.0 e versioni successive separano inoltre l'HAL della fotocamera in un processo diverso da cameraserver. L'IPC passa attraverso le interfacce definite da HIDL.

Convalida

Per tutti i dispositivi che includono una fotocamera e funzionano con Android 7.0, verifica l'implementazione eseguendo il CTS di Android 7.0. Anche se Android 7.0 non include nuovi test CTS che verificano le modifiche al servizio della fotocamera, i test CTS esistenti non passano se non hai eseguito gli aggiornamenti indicati sopra.

Per tutti i dispositivi che includono una videocamera e che eseguono Android 8.0 e versioni successive, verifica l'implementazione del fornitore eseguendo il VTS.

Cronologia delle versioni di Camera HAL

Per un elenco dei test disponibili per la valutazione dell'HAL della fotocamera Android, consulta la lista di controllo per i test dell'HAL della fotocamera.

Android 10

Android 10 introduce i seguenti aggiornamenti.

API Camera

• Miglioramenti alle configurazioni con più videocamere che consentono di utilizzare le videocamere fisiche singolarmente o tramite le videocamere logiche corrispondenti nascondendo gli ID delle videocamere fisiche. Consulta Supporto della modalità multicamera.
• Possibilità di verificare se una determinata configurazione della sessione è supportata senza l'overhead delle prestazioni della creazione di una nuova sessione. Consulta CameraDevice.
• Possibilità di recuperare le configurazioni di stream consigliate per un determinato caso d'uso per rendere il client più efficiente e performante. Consulta getRecommendedStreamConfigurationMap.
• Supporto del formato immagine JPEG con profondità. Per ulteriori dettagli, consulta la specifica della profondità dinamica.
• Supporto per il formato immagine HEIC. Consulta Immagini HEIF.
• Miglioramenti alla privacy. Alcune chiavi sono obbligatorie per il cliente per avere le autorizzazioni CAMERA prima che possano essere recuperate da CameraCharacteristics. Consulta getKeysNeedingPermission.

HAL della fotocamera

Le seguenti versioni HAL della fotocamera sono aggiornate in Android 10.

3.5

ICameraDevice

• getPhysicalCameraCharacteristics: Le informazioni statiche della videocamera per un ID videocamera fisico che supporta un dispositivo videocamera logico. Consulta Supporto della modalità multicamera.
• isStreamCombinationSupported: questo metodo supporta un'API pubblica che consente ai client di eseguire query per verificare se è supportata una configurazione della sessione. Consulta l'API per eseguire query sulle combinazioni di stream.

ICameraDeviceSession

• isReconfigurationNeeded: Metodo che indica al framework della videocamera se è necessaria una ricofigurazione completa dello stream per possibili nuovi valori parametro della sessione. In questo modo, eviterai ritardi non necessari nella riconfigurazione della videocamera. Consulta Query di ricofigurazione della sessione.
• API di gestione dei buffer HAL: queste API consentono all'HAL della fotocamera di richiedere i buffer dal framework della fotocamera solo quando necessario, anziché accoppiare ogni richiesta di acquisizione con i relativi buffer associati nell'intera pipeline della fotocamera, con un risparmio di memoria potenzialmente significativo.
  • signalStreamFlush: indica all'HAL che il servizio della videocamera sta per eseguire configureStreams_3_5 e che l'HAL deve restituire tutti i buffer degli stream designati.
  • configureStreams_3_5: simile a ICameraDevice3.4.configureStreams, ma in più viene fornito il contatore streamConfigCounter per verificare la presenza di una condizione di gara tra le chiamate configureStreams_3_5 e signalStreamFlush.

Aggiornamenti a ICameraDeviceCallback:

• requestStreamBuffers: callback sincrono chiamato dall'HAL della videocamera per richiedere i buffer al server della videocamera. Consulta requestStreamBuffers.
• returnStreamBuffers: callback sincrono per l'HAL della videocamera per restituire i buffer di output al server della videocamera. Consulta returnStreamBuffers.

3.4

Le seguenti chiavi vengono aggiunte ai metadati della fotocamera in Android 10.

• Formati delle immagini
  • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
  • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
  • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
• Tag dei metadati della videocamera
  • 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
• Funzionalità
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
• Valori per la chiave ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
  • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
  • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
• Configurazioni dello stream di profondità dinamica disponibili
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
• Configurazioni dello stream HEIC disponibili
  • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
  • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Modulo della videocamera

Le seguenti versioni del modulo della fotocamera sono aggiornate in Android 10.

2,5

• Aggiunge il metodo notifyDeviceStateChange per consentire ai dispositivi di notificare l'HAL della fotocamera quando le modifiche fisiche, come la chiusura, influiscono sulla fotocamera e sul routing.

2.4

• I dispositivi lanciati con il livello API 29 o versioni successive DEVONO segnalare true per isTorchModeSupported.

Android 9

La release di Android 9 introduce i seguenti aggiornamenti all'API Camera2 e all'interfaccia HAL.

API Camera

• Viene introdotta l'API multicamera per supportare meglio i dispositivi con più fotocamere rivolte nella stessa direzione, attivando funzionalità come il bokeh e lo zoom continuo. In questo modo le app possono visualizzare più videocamere su un dispositivo come un'unica unità logica (videocamera logica). Le richieste di acquisizione possono essere inviate anche a singoli dispositivi di videocamere inclusi in una videocamera logica. Consulta Supporto della modalità multicamera.
• Introduce i parametri di sessione. I parametri di sessione sono un sottoinsieme dei parametri di acquisizione disponibili che possono causare gravi ritardi di elaborazione se modificati. Questi costi possono essere ridotti se i client trasmettono i valori iniziali durante l'inizializzazione della sessione di acquisizione. Consulta Parametri di sessione.
• Aggiunge chiavi di dati per la stabilizzazione ottica (OIS) per la stabilizzazione e gli effetti a livello di app. Consulta STATISTICS_OIS_SAMPLES.
• Aggiunge il supporto del flash esterno. Consulta CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
• Aggiunge un'intenzione di rilevamento del movimento in CAPTURE_INTENT. Consulta CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
• Ritirata LENS_RADIAL_DISTORTION e aggiunta LENS_DISTORTION al suo posto.
• Aggiunge le modalità di correzione delle distorsioni in CaptureRequest. Consulta DISTORTION_CORRECTION_MODE.
• Aggiunta del supporto per le videocamere esterne USB/UVC sui dispositivi supportati. Consulta INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

HAL della fotocamera

3.4

Aggiornamenti a ICameraDeviceSession

• configureStreams_3_4: aggiunge il supporto per le videocamere sessionParameters e logiche.
• processCaptureRequest_3_4: aggiunge il supporto per l'inclusione degli ID delle videocamere fisiche nella struttura dello stream.

Aggiornamenti a ICameraDeviceCallback

• processCaptureResult_3_4: aggiunge i metadati della fotocamera fisica nei risultati di acquisizione.

3,30

Le seguenti chiavi vengono aggiunte ai metadati della fotocamera in Android 9.

• Funzionalità
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
• Tag dei metadati della videocamera
  • 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 versione Android 8.0 introduce Treble. Con Treble, le implementazioni HAL Camera del fornitore devono essere incapsulate. Android 8.0 contiene inoltre questi miglioramenti chiave al servizio Fotocamera:

• Piattaforme condivise: attiva più piattaforme che condividono lo stesso OutputConfiguration
• API di sistema per le modalità della fotocamera personalizzate
• onCaptureQueueEmpty

Per ulteriori informazioni su queste funzionalità, consulta le sezioni seguenti.

Superfici condivise

Questa funzionalità consente a un solo set di buffer di gestire due output, ad esempio la visualizzazione di anteprima e la codifica video, il che riduce il consumo di energia e memoria. Per supportare questa funzionalità, i produttori di dispositivi devono assicurarsi che le implementazioni HAL della fotocamera e HAL di gralloc possano creare buffer gralloc utilizzati da più consumatori diversi (come il compositore hardware/la GPU e l'encoder video), anziché da un solo consumatore. Il servizio della fotocamera passa i flag di utilizzo dei consumatori all'HAL della fotocamera e all'HAL gralloc. Questi devono allocare i tipi di buffer corretti oppure l'HAL della fotocamera deve restituire un errore che indica che questa combinazione di consumatori non è supportata.

Per ulteriori dettagli, consulta la enableSurfaceSharing documentazione per gli sviluppatori.

API di sistema per le modalità della fotocamera personalizzate

L'API videocamera pubblica definisce due modalità di funzionamento: registrazione normale e ad alta velocità limitata. Hanno una semantica abbastanza diversa; ad esempio, la modalità ad alta velocità è limitata a un massimo di due output specifici contemporaneamente. Diversi OEM hanno espresso il proprio interesse a definire altre modalità personalizzate per funzionalità specifiche dell'hardware. Dietro le quinte, la modalità è solo un numero intero passato a configure_streams. Consulta: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams.

Questa funzionalità include una chiamata API di sistema che le app per fotocamere OEM possono utilizzare per attivare una modalità personalizzata. Queste modalità devono iniziare con il valore intero 0x8000 per evitare conflitti con le modalità future aggiunte all'API pubblica.

Per supportare questa funzionalità, gli OEM devono semplicemente aggiungere la nuova modalità al proprio HAL, attivata da questo numero intero passato all'HAL su configure_streams, e poi fare in modo che la loro app videocamera personalizzata utilizzi l'API di sistema.

Il nome del metodo è android.hardware.camera2.CameraDevice#createCustomCaptureSession. Consulta: frameworks/base/core/java/android/hardware/camera2/CameraDevice.

Nota: nella release Android 8.1, per accedere a questa API le app devono essere preinstallate nell'immagine di sistema.

onCaptureQueueEmpty

Lo scopo di questa API è ridurre la latenza delle modifiche dei controlli come lo zoom mantenendo la coda delle richieste il più vuota possibile. onCaptureQueueEmpty non richiede alcuna operazione HAL; si tratta di un'aggiunta puramente a livello di framework. Le app che vogliono sfruttarlo devono aggiungere un listener a questo callback e rispondere di conseguenza. In genere, inviando un'altra richiesta di acquisizione al dispositivo fotocamera.

Interfaccia HIDL della fotocamera

L'interfaccia HIDL della fotocamera è una revisione completa dell'interfaccia HAL della fotocamera che utilizza API stabili definite da HIDL. Tutte le funzionalità e le capacità della fotocamera introdotte nelle versioni precedenti 3.4 e 2.4 (per il modulo della fotocamera) più recenti fanno parte anche delle definizioni HIDL.

3.4

Piccole aggiunte ai metadati supportati e modifiche al supporto di data_space:

• Aggiungi i metadati statici ANDROID_SENSOR_OPAQUE_RAW_SIZE come obbligatori se il formato RAW_OPAQUE è supportato.
• Aggiungi i metadati statici ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE come obbligatori se è supportato un formato RAW.
• Passa il campo camera3_stream_t data_space a una definizione più flessibile, utilizzando la definizione della versione 0 della codifica dello spazio dati.
• Aggiunta di metadati generali che possono essere utilizzati per HALv3.2 o versioni successive:
  • 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

Revisione minore dell'HAL con funzionalità espanse:

• Aggiornamenti dell'API di elaborazione di nuovo OPAQUE e YUV.
• Supporto di base per i buffer di output della profondità.
• Aggiunta del campo data_space a camera3_stream_t.
• Aggiunta del campo di rotazione a camera3_stream_t.
• Aggiunta della modalità di funzionamento della configurazione dello stream della fotocamera 3 a camera3_stream_configuration_t.

3.2

Revisione minore dell'HAL con funzionalità espanse:

• È deprecato get_metadata_vendor_tag_ops. Utilizza invece get_vendor_tag_ops in camera_common.h.
• È deprecato register_stream_buffers. Tutti i buffer gralloc forniti dal framework ad HAL in process_capture_request possono essere nuovi in qualsiasi momento.
• Aggiungere il supporto dei risultati parziali. process_capture_result può essere chiamato più volte con un sottoinsieme dei risultati disponibili prima che il risultato completo sia disponibile.
• Aggiungi il modello manuale a camera3_request_template. Le app possono utilizzare questo modello per controllare direttamente le impostazioni di acquisizione.
• Rivedere le specifiche degli stream bidirezionali e di input.
• Modifica il percorso di ritorno del buffer di input. Il buffer viene restituito in process_capture_result anziché process_capture_request.

3.1

Revisione minore dell'HAL con funzionalità espanse:

• configure_streams passa i flag di utilizzo dei consumatori all'HAL.
• Esegui la chiamata flush per eliminare tutte le richieste/i buffer in corso il più rapidamente possibile.

3,0

Prima revisione dell'HAL con funzionalità espanse:

• Modifica importante della versione poiché l'ABI è completamente diverso. Nessuna modifica alle funzionalità hardware o al modello operativo richieste rispetto alla versione 2.0.
• Interfacce di coda di richieste di input e stream ristrutturate: il framework chiama HAL con la richiesta successiva e i buffer dello stream già rimossi dalla coda. È incluso il supporto del framework di sincronizzazione, necessario per implementazioni efficienti.
• Gli attivatori sono stati spostati nelle richieste, la maggior parte delle notifiche nei risultati.
• Sono stati raggruppati tutti i callback nel framework in un'unica struttura e tutti i metodi di configurazione in una singola chiamata initialize().
• La configurazione dello stream è stata semplificata in una singola chiamata. Gli stream bidirezionali sostituiscono il costrutto STREAM_FROM_STREAM.
• Semantika della modalità limitata per dispositivi hardware meno recenti/con limitazioni.

2,0

Versione iniziale dell'HAL con funzionalità espanse (Android 4.2) [camera2.h]:

• Sufficiente per implementare l'API android.hardware.Camera esistente.
• Consente la coda ZSL nel livello di servizio della fotocamera.
• Non è stato testato per nuove funzionalità come il controllo manuale dell'acquisizione, l'acquisizione in formato RAW Bayer, la rielaborazione dei dati RAW e così via.

1.0

HAL iniziale della fotocamera Android (Android 4.0) [camera.h]:

• Convertito dal livello di astrazione CameraHardwareInterface C++.
• Supporta l'API android.hardware.Camera.

Cronologia delle versioni del modulo della videocamera

Questa sezione contiene informazioni sulla versione del modulo Hardware della videocamera, in base a camera_module_t.common.module_api_version. Le due cifre esadecimali più significative rappresentano la versione principale, mentre le due meno significative rappresentano la versione secondaria.

2.4

Questa versione del modulo della fotocamera aggiunge le seguenti modifiche all'API:

1. Supporto della modalità torcia. Il framework può attivare la modalità torcia per qualsiasi dispositivo con fotocamera dotato di un'unità flash, senza aprire il dispositivo. Il dispositivo con fotocamera ha una priorità di accesso all'unità flash superiore rispetto al modulo della fotocamera. Se apri un dispositivo con fotocamera, la torcia si spegne se era stata attivata tramite l'interfaccia del modulo. In caso di conflitti di risorse, ad esempio se viene chiamato open() per aprire un dispositivo con videocamera, il modulo HAL della videocamera deve informare il framework tramite il callback dello stato della modalità torcia che la modalità torcia è stata disattivata.
2. Supporto di fotocamere esterne (ad esempio fotocamere USB hot-plug). Gli aggiornamenti dell'API specificano che le informazioni statiche della videocamera sono disponibili solo quando la videocamera è collegata e pronta per l'uso per le videocamere hot-plug esterne. Le chiamate per recuperare informazioni statiche non sono valide quando lo stato della videocamera non è CAMERA_DEVICE_STATUS_PRESENT. Il framework si basa esclusivamente su callback per la modifica dello stato del dispositivo per gestire l'elenco delle videocamere esterne disponibili.
3. Suggerimenti per l'arbitrato della videocamera. Aggiunta del supporto per l'indicazione esplicita del numero di dispositivi con fotocamera che possono essere aperti e utilizzati contemporaneamente. Per specificare combinazioni valide di dispositivi, i campi resource_cost e conflicting_devices devono essere sempre impostati nella struttura camera_info restituita dalla chiamata get_camera_info.
4. Metodo di inizializzazione del modulo. Chiamato dal servizio della fotocamera dopo il caricamento del modulo HAL per consentire l'inizializzazione una tantum dell'HAL. Viene chiamato prima dell'invocazione di altri metodi del modulo.

2.3

Questa versione del modulo della fotocamera aggiunge il supporto per i dispositivi HAL della fotocamera legacy aperti. Il framework può utilizzarlo per aprire il dispositivo della videocamera come dispositivo HAL con versione inferiore se lo stesso dispositivo può supportare più versioni dell'API del dispositivo. La chiamata di apertura del modulo hardware standard (common.methods->open) continua ad aprire il dispositivo della videocamera con la versione supportata più recente, che è anche la versione elencata in camera_info_t.device_version.

2,2

Questa versione del modulo della videocamera aggiunge il supporto dei tag del fornitore dal modulo e ritira i vecchi vendor_tag_query_ops che in precedenza erano accessibili solo con un dispositivo aperto.

2.1

Questa versione del modulo della videocamera aggiunge il supporto per i callback asincroni al framework dal modulo HAL della videocamera, che viene utilizzato per notificare al framework le modifiche allo stato del modulo della videocamera. I moduli che forniscono un metodo set_callbacks() valido devono segnalare almeno questo numero di versione.

2,0

I moduli della videocamera che riportano questo numero di versione implementano la seconda versione dell'interfaccia HAL del modulo della videocamera. I dispositivi di fotocamere aperti tramite questo modulo possono supportare la versione 1.0 o 2.0 dell'interfaccia HAL del dispositivo di fotocamera. Il campo device_version di camera_info è sempre valido; il campo static_camera_characteristics di camera_info è valido se il campo device_version è 2.0 o superiore.

1.0

I moduli della videocamera che riportano questi numeri di versione implementano l'interfaccia HAL del modulo della videocamera iniziale. Tutti i dispositivi con fotocamera aperti tramite questo modulo supportano solo la versione 1 dell'HAL del dispositivo con fotocamera. I campi device_version e static_camera_characteristics di camera_info non sono validi. Solo l'API android.hardware.Camera può essere supportata da questo modulo e dai suoi dispositivi.