Supporto delle versioni della fotocamera

Questa pagina descrive le differenze di versione nelle API e negli HAL della fotocamera e nei test associati della Compatibility Test Suite (CTS). Descrive inoltre diverse modifiche all'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 delle fotocamere.

Terminologia

In questa pagina vengono utilizzati i seguenti termini:

API Camera1

Il framework della fotocamera a livello di app su 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.

Videocamera HAL

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

Camera HAL3.1

Versione della fotocamera HAL rilasciata con Android 4.4.

HAL Camera 3.2

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

CTS API1 fotocamera

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

Linguaggio 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 ad Treble.

API di gestione della fotocamera

Android include le seguenti API della fotocamera.

API Fotocamera1

Android 5.0 ha ritirato l'API Camera1, che continua a essere eliminata gradualmente poiché lo sviluppo della nuova piattaforma si concentra 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 continua 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 API2 espone all'app il controllo della fotocamera a livello inferiore, inclusi 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 l'interfaccia dell'API Camera 2 segnala uno dei seguenti livelli di assistenza:

• LEGACY: questi dispositivi mettono a disposizione delle app funzionalità tramite le interfacce dell'API Camera 2 che sono approssimativamente le stesse di quelle messe a disposizione delle app tramite le interfacce dell'API Camera 1. 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 Camera 2 (ma non tutte) e devono utilizzare Fotocamera HAL 3.2 o versioni successive.
• FULL: questi dispositivi supportano tutte le principali funzionalità dell'API Camera 2 e devono utilizzare Fotocamera HAL 3.2 o versioni successive e Android 5.0 o versioni successive.
• LEVEL_3: questi dispositivi supportano la rielaborazione YUV e l'acquisizione 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 un sottoinsieme di queste funzionalità, inclusa nessuna di queste. 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à API2 LEGACY di Fotocamera (in cui le chiamate API2 di Fotocamera sono concettualmente mappate alle chiamate API1 di Fotocamera), pertanto tutti i test CTS dell'API Camera relativi a funzionalità o funzionalità diverse dall'API Camera1 vengono ignorati automaticamente.

Sui dispositivi legacy, i test CTS dell'API Camera in esecuzione utilizzano le interfacce e le funzionalità pubbliche dell'API Camera 1 esistenti senza nuovi requisiti. I bug esposti (e che causano un errore CTS dell'API Camera2) sono bug già presenti nell'HAL della fotocamera esistente del dispositivo e quindi verrebbero rilevati dalle app API Camera1 esistenti. Non ci aspettiamo molti bug di questa natura (tuttavia, tali bug devono essere risolti per superare i test CTS dell'API Camera2).

Requisiti VTS

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

Rafforzamento del framework della videocamera

Per rafforzare la sicurezza del framework dei contenuti multimediali e della fotocamera, Android 7.0 sposta il servizio fotocamera da mediaserver. A partire da Android 8.0, ogni HAL associato per fotocamera 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 seguenti sezioni 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 in diretta nello stesso processo. Quando si utilizza API1 su:

• HAL3, in cui il servizio fotocamera utilizza BufferQueue per passare 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. La fotocamera e gli stack multimediali di Android 7.0 nell'API1 su HAL1

Modifiche all'architettura per l'API 2

Per API2 su HAL1 o HAL3, BufferQueue passa i buffer in modo che questi percorsi continuino a funzionare. L'architettura Android 7.0 per 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 l'android.hardware.camera2.cts.PerformanceTest e l'app Google Fotocamera per la registrazione di video ad alta velocità a 120/240 f/s. 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 dei 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 concedono a mediaserver le autorizzazioni per eseguire la fotocamera, devi aggiornare i criteri SELinux per concedere 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. Sebbene Android 7.0 non includa i nuovi test CTS che verificano le modifiche al servizio videocamera, i test CTS esistenti non vanno a buon fine se non hai apportato 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 HAL della videocamera

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 Assistenza per più fotocamera.
• Possibilità di verificare se una determinata configurazione della sessione è supportata senza l'overhead del rendimento della creazione di una nuova sessione. Vedi CameraDevice.
• Possibilità di recuperare le configurazioni di stream consigliate per un determinato caso d'uso per rendere il client più efficiente e performante. Vedi getRecommendedStreamConfigurationMap.
• Supporto del formato dell'immagine JPEG con profondità. Per ulteriori dettagli, consulta la specifica della profondità dinamica.
• Supporto del 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 di Fotocamera HAL 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 la riconfigurazione completa dello streaming per possibili nuovi valori parametro della sessione. In questo modo, eviterai ritardi non necessari nella riconfigurazione della videocamera. Consulta Query di riconfigurazione 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 di stream di profondità dinamica disponibili
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
• Configurazioni di 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,50

• Aggiunge il metodo notifyDeviceStateChange per consentire ai dispositivi di avvisare l'HAL della videocamera quando cambiamenti fisici, ad esempio la piegatura, 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. Ciò consente alle app di visualizzare più videocamere su un dispositivo come una singola unità logica (fotocamera logica). Le richieste di acquisizione possono essere inviate anche a singole videocamere dotate di una fotocamera 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 in caso di modifiche. 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 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: consente di aggiungere metadati fisici della fotocamera nei risultati dell'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.

Piattaforme condivise

Questa funzionalità consente a un solo set di buffer di gestire due output, come l'anteprima e la codifica video, riducendo il consumo di energia e di memoria. Per supportare questa funzionalità, i produttori di dispositivi devono assicurarsi che le loro implementazioni HAL e Gralloc HAL possano creare buffer Gralloc utilizzati da più consumatori diversi (ad esempio il compositore hardware/GPU e il codificatore video), invece che un solo utente. 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 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. Vari OEM hanno espresso interesse nella definizione di altre modalità personalizzate per funzionalità specifiche per hardware. Alla base, 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 da un 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à all'HAL, attivata da questo numero intero passato all'HAL su configure_streams, quindi fare in modo che l'app della 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.

onCaptureQueueEmpty

Lo scopo di questa API è ridurre la latenza delle modifiche di controllo come lo zoom mantenendo la coda delle richieste il più vuota possibile. onCaptureQueueEmpty non richiede alcuna operazione HAL; si trattava solo di un'aggiunta lato framework. Le app che vogliono sfruttarlo devono aggiungere un listener a questo callback e rispondere di conseguenza. In genere consiste nell'invio di un'altra richiesta di acquisizione alla videocamera.

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 secondaria dell'HAL con funzionalità estesa:

• Aggiornamenti dell'API di elaborazione di nuovo OPAQUE e YUV.
• Supporto di base per buffer di output di 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 camera3 a camera3_stream_configuration_t.

3.2

Revisione secondaria dell'HAL con funzionalità estesa:

• È deprecato get_metadata_vendor_tag_ops. Utilizza invece get_vendor_tag_ops in camera_common.h.
• Ritira 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.
• Rielabora le specifiche del flusso di input e bidirezionale.
• Modifica il percorso di ritorno del buffer di input. Il buffer viene restituito in process_capture_result anziché in process_capture_request.

3.1

Revisione minore dell'HAL con funzionalità espanse:

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

3,0

Prima revisione dell'HAL con funzionalità espansa:

• 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.
• Spostamento degli attivatori nelle richieste e della 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().
• Trasformazione della configurazione degli stream in una singola chiamata per semplificarne la gestione. I flussi bidirezionali sostituiscono il costrutto STREAM_FROM_STREAM.
• semantica in modalità limitata per dispositivi hardware meno recenti/limitati.

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 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 delle risorse, ad esempio open() viene chiamato per aprire un dispositivo della videocamera, il modulo HAL della videocamera deve informare il framework tramite il callback dello stato della modalità torcia che questa è 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 esterne hot-plug. 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 di modifica dello stato del dispositivo per gestire l'elenco delle videocamere esterne disponibili.
3. Suggerimenti di arbitrato per la fotocamera. Aggiunta del supporto per l'indicazione esplicita del numero di dispositivi con videocamera 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 aperto per i dispositivi HAL per le fotocamere precedenti. 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 aperta del modulo hardware standard (common.methods->open) continua ad aprire il dispositivo della videocamera con l'ultima versione supportata, 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 videocamera apribili tramite questo modulo possono supportare la versione 1.0 o la versione 2.0 dell'interfaccia HAL del dispositivo videocamera. 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 segnalano questi numeri di versione implementano l'interfaccia HAL del modulo della videocamera iniziale. Tutte le videocamere apribili tramite questo modulo supportano solo la versione 1 dell'HAL. 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.