Supporto per la versione della fotocamera

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

Terminologia

In questa pagina vengono utilizzati i seguenti termini:

API della fotocamera1
Il framework della fotocamera a livello di app su dispositivi Android 4.4 e versioni precedenti, esposto tramite la classe android.hardware.Camera .
API della fotocamera2
Il framework della fotocamera a livello di app su dispositivi Android 5.0 e versioni successive, esposto tramite il pacchetto android.hardware.camera2 .
Fotocamera HAL
Il livello del modulo fotocamera implementato dai fornitori di SoC. I framework pubblici a livello di app sono basati sull'HAL della fotocamera.
Fotocamera HAL3.1
Versione del dispositivo fotocamera HAL rilasciata con Android 4.4.
Fotocamera HAL3.2
Versione del dispositivo fotocamera HAL rilasciata con Android 5.0.
Fotocamera API1 CTS
Insieme di test CTS della fotocamera eseguiti su Camera API1.
Fotocamera API2 CTS
Set aggiuntivo di test CTS della fotocamera eseguiti su Camera API2.
Alti
Separa l'implementazione del fornitore (software di livello inferiore specifico del dispositivo scritto dai produttori di silicio) dal framework del sistema operativo Android attraverso 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 a Treble.

API della fotocamera

Android include le seguenti API della fotocamera.

API della fotocamera1

Android 5.0 ha deprecato Camera API1, che continua a essere gradualmente eliminata poiché lo sviluppo della nuova piattaforma si concentra su Camera API2. Tuttavia, il periodo di eliminazione sarà lungo e le versioni Android continueranno a supportare le app Camera API1 per un po' di tempo. Nello specifico continua il supporto per:

  • Interfacce API1 della fotocamera per le app. Le app della fotocamera basate su Camera API1 dovrebbero funzionare come sui dispositivi che eseguono versioni di Android inferiori.
  • Versioni HAL della fotocamera. Include il supporto per la fotocamera HAL1.0.

API della fotocamera2

Il framework Camera API2 espone il controllo della fotocamera di livello inferiore all'app, inclusi efficienti flussi burst/streaming zero-copy e controlli per fotogramma di esposizione, guadagno, guadagni di bilanciamento del bianco, conversione del colore, denoising, nitidezza e altro ancora. Per maggiori dettagli, guarda la panoramica video di Google I/O .

Android 5.0 e versioni successive includono Camera API2; tuttavia, i dispositivi con Android 5.0 e versioni successive potrebbero non supportare tutte le funzionalità Camera API2. La proprietà android.info.supportedHardwareLevel su cui le app possono eseguire query tramite le interfacce Camera API2 segnala uno dei seguenti livelli di supporto:

  • LEGACY : questi dispositivi espongono funzionalità alle app tramite le interfacce Camera API2 che sono all'incirca le stesse funzionalità esposte alle app tramite le interfacce Camera API1. Il codice dei framework legacy traduce concettualmente le chiamate Camera API2 in chiamate Camera API1; i dispositivi legacy non supportano le funzionalità Camera API2 come i controlli per fotogramma.
  • LIMITED : questi dispositivi supportano alcune funzionalità Camera API2 (ma non tutte) e devono utilizzare Camera HAL 3.2 o versione successiva.
  • FULL : questi dispositivi supportano tutte le principali funzionalità di Camera API2 e devono utilizzare Camera HAL 3.2 o versione successiva e Android 5.0 o versione successiva.
  • LEVEL_3 : questi dispositivi supportano la rielaborazione YUV e l'acquisizione di immagini RAW, insieme a configurazioni aggiuntive del flusso di output.
  • EXTERNAL : questi dispositivi sono simili ai dispositivi LIMITED con alcune eccezioni; ad esempio, alcune informazioni sul sensore o sull'obiettivo potrebbero non essere riportate o avere frame rate meno stabili. Questo livello viene utilizzato per fotocamere esterne come webcam USB.

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

Il livello hardware supportato del dispositivo, nonché le funzionalità specifiche Camera API2 supportate, sono disponibili come flag di funzionalità seguenti per consentire a Google Play di filtrare le app della fotocamera Camera API2.

  • android.hardware.camera.hardware_level.full
  • android.hardware.camera.capability.raw
  • android.hardware.camera.capability.manual_sensor
  • android.hardware.camera.capability.manual_post_processing

Requisiti del CTS

I dispositivi con Android 5.0 e versioni successive devono superare i test della fotocamera Camera API1 CTS, Camera API2 CTS e CTS Verifier.

I dispositivi che non dispongono di un'implementazione Camera HAL3.2 e non sono in grado di supportare le interfacce Camera API2 complete devono comunque superare i test Camera API2 CTS. Tuttavia, il dispositivo viene eseguito in modalità Camera API2 LEGACY (in cui le chiamate Camera API2 sono concettualmente mappate alle chiamate Camera API1) quindi qualsiasi test CTS Camera API2 relativo a caratteristiche o funzionalità oltre Camera API1 viene automaticamente saltato.

Sui dispositivi legacy, i test CTS Camera API2 eseguiti utilizzano le interfacce e le funzionalità pubbliche esistenti di Camera API1 senza nuovi requisiti. I bug esposti (e che causano un errore CTS Camera API2) sono bug già presenti nell'HAL Camera esistente del dispositivo e quindi verrebbero rilevati dalle app Camera API1 esistenti. Non ci aspettiamo molti bug di questa natura (tuttavia, eventuali bug di questo tipo devono essere corretti per superare i test CTS Camera API2).

Requisiti VTS

I dispositivi che eseguono Android 8.0 e versioni successive con implementazioni HAL binderizzate devono superare i test Camera VTS .

Rafforzamento della struttura della fotocamera

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

Modifiche all'architettura per API1

La registrazione video API1 può presupporre che la fotocamera e il codificatore video siano attivi nello stesso processo. Quando si utilizza API1 su:

  • HAL3, dove il servizio fotocamera utilizza BufferQueue per passare i buffer tra i processi, non è necessario alcun aggiornamento del fornitore .

    Fotocamera Android 7.0 e stack multimediale nell'API1 su HAL3

    Figura 1. Fotocamera Android 7.0 e stack multimediale nell'API1 su HAL3

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

    Fotocamera Android 7.0 e stack multimediale nell'API1 su HAL1

    Figura 2. Fotocamera Android 7.0 e stack multimediale nell'API1 su HAL1

Modifiche all'architettura per API2

Per API2 su HAL1 o HAL3, BufferQueue passa i buffer in modo che tali percorsi continuino a funzionare. L'architettura Android 7.0 per API2 su:

  • HAL1 non è interessato dallo spostamento del servizio fotocamera e non è necessario alcun aggiornamento del fornitore .
  • HAL3 è interessato, ma non è necessario alcun aggiornamento del fornitore :

    Fotocamera Android 7.0 e stack multimediale in API2 su HAL3

    Figura 3. Fotocamera Android 7.0 e stack multimediale nell'API2 su HAL3

Requisiti addizionali

Le modifiche all'architettura apportate per rafforzare la sicurezza dei supporti e della struttura della fotocamera includono i seguenti requisiti aggiuntivi del dispositivo.

  • Generale. I dispositivi richiedono una larghezza di banda aggiuntiva a causa dell'IPC, che può influire sui casi d'uso della fotocamera sensibili al fattore tempo, come la registrazione video ad alta velocità. I fornitori possono misurare l'impatto effettivo eseguendo android.hardware.camera2.cts.PerformanceTest e l'app Google Camera 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.
  • Passa i metadati nei buffer video ( solo HAL1 ). Se HAL1 memorizza i metadati anziché i dati dei frame YUV reali 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 gli handle nativi.
  • L'indirizzo dell'handle del buffer non memorizza sempre lo stesso buffer ( solo HAL3 ). Per ogni richiesta di acquisizione, HAL3 ottiene gli indirizzi degli handle del buffer. HAL non può utilizzare gli indirizzi per identificare i buffer perché gli indirizzi potrebbero memorizzare un altro handle di buffer dopo che HAL ha restituito il buffer. È necessario aggiornare l'HAL per utilizzare gli handle di buffer per identificare i buffer. Ad esempio, HAL riceve un indirizzo di handle di buffer A, che memorizza l'handle di buffer A. Dopo che HAL restituisce l'handle di buffer A, l'indirizzo di handle di buffer A può memorizzare l'handle di buffer B la prossima volta che l'HAL lo riceve.
  • Aggiorna le policy SELinux per il cameraserver. Se le policy SELinux specifiche del dispositivo forniscono le autorizzazioni del mediaserver per eseguire la fotocamera, è necessario aggiornare le policy SELinux per fornire le autorizzazioni appropriate al cameraserver. Sconsigliamo di replicare le politiche SELinux del mediaserver per il cameraserver (poiché mediaserver e cameraserver generalmente richiedono risorse diverse nel sistema). Cameraserver dovrebbe avere solo le autorizzazioni necessarie per eseguire le funzionalità della fotocamera e qualsiasi autorizzazione non necessaria relativa alla fotocamera nel mediaserver dovrebbe essere rimossa.
  • Separazione tra Camera HAL e cameraserver. Android 8.0 e versioni successive separano inoltre l'HAL della fotocamera binderizzato in un processo diverso da cameraserver. IPC passa attraverso le interfacce definite da HIDL .

Validazione

Per tutti i dispositivi che includono una fotocamera ed eseguono Android 7.0, verifica l'implementazione eseguendo Android 7.0 CTS. Sebbene Android 7.0 non includa nuovi test CTS che verifichino le modifiche al servizio della fotocamera, i test CTS esistenti falliscono se non hai effettuato gli aggiornamenti sopra indicati.

Per tutti i dispositivi che includono una fotocamera ed eseguono Android 8.0 e versioni successive, verificare l'implementazione del fornitore eseguendo VTS.

Cronologia delle versioni HAL della fotocamera

Per un elenco dei test disponibili per la valutazione dell'HAL della fotocamera Android, vedere l' elenco di controllo dei test dell'HAL della fotocamera .

Androide 10

Android 10 introduce i seguenti aggiornamenti.

API della fotocamera

Fotocamera HAL

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

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics : informazioni statiche sulla fotocamera per un ID fotocamera fisica che supporta un dispositivo fotocamera logico. Vedere Supporto multi-camera .
  • isStreamCombinationSupported : questo metodo supporta un'API pubblica che aiuta i client a eseguire query se è supportata una configurazione di sessione. Vedi API per eseguire query sulle combinazioni di flussi .

ICameraDeviceSession

  • isReconfigurationNeeded : metodo che indica al framework della telecamera se è necessaria una riconfigurazione completa del flusso per possibili nuovi valori dei parametri di sessione. Ciò aiuta a evitare inutili ritardi nella riconfigurazione della fotocamera. Vedere Query di riconfigurazione della sessione .
  • API di gestione del buffer HAL : queste API consentono all'HAL della fotocamera di richiedere buffer dal framework della fotocamera solo quando richiesto invece di accoppiare ciascuna richiesta di acquisizione con i buffer associati in tutta la pipeline della fotocamera, con conseguente risparmio di memoria potenzialmente significativo.
    • signalStreamFlush : segnala all'HAL che il servizio telecamera sta per eseguire configureStreams_3_5 e che l'HAL deve restituire tutti i buffer dei flussi designati.
    • configureStreams_3_5 : simile a ICameraDevice3.4.configureStreams , ma in più, viene fornito il contatore streamConfigCounter per verificare una condizione di competizione tra le chiamate configureStreams_3_5 e signalStreamFlush .

Aggiornamenti a ICameraDeviceCallback :

  • requestStreamBuffers : callback sincrono che l'HAL della telecamera chiama per richiedere i buffer al server della telecamera. Vedi requestStreamBuffers .
  • returnStreamBuffers : callback sincrono per l'HAL della telecamera per restituire i buffer di output al server della telecamera. Vedi returnStreamBuffers .

3.4

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

  • Formati di immagine
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • Tag dei metadati della fotocamera
    • ANDROID_REQUEST_CHARACTERISTIC_KEYS_NEEDING_PERMISSION
    • ANDROID_SCALER_AVAILABLE_RECOMMENDED_STREAM_CONFIGURATIONS
    • ANDROID_SCALER_AVAILABLE_RECOMMENDED_INPUT_OUTPUT_FORMATS_MAP
    • ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION
    • ANDROID_DEPTH_AVAILABLE_RECOMMENDED_DEPTH_STREAM_CONFIGURATIONS
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_MIN_FRAME_DURATIONS
    • ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS
    • ANDROID_HEIC_AVAILABLE_HEIC_MIN_FRAME_DURATIONS
    • ANDROID_HEIC_AVAILABLE_HEIC_STALL_DURATIONS
    • ANDROID_HEIC_INFO_SUPPORTED
    • ANDROID_HEIC_INFO_MAX_JPEG_APP_SEGMENTS_COUNT
  • Capacità
    • 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 flusso di profondità dinamico disponibili
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • Configurazioni di flusso HEIC disponibili
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Modulo fotocamera

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

2.5

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

2.4

  • I dispositivi avviati con livello API 29 o superiore DEVONO riportare true per isTorchModeSupported .

Androide 9

La versione Android 9 introduce i seguenti aggiornamenti all'interfaccia API2 e HAL della fotocamera.

API della fotocamera

  • Introduce l'API multi-camera per supportare meglio i dispositivi con più fotocamere rivolte nella stessa direzione, abilitando funzionalità come bokeh e zoom continuo. Ciò consente alle app di visualizzare più fotocamere su un dispositivo come un'unità logica (fotocamera logica). Le richieste di acquisizione possono anche essere inviate a singoli dispositivi fotocamera racchiusi in una fotocamera logica. Vedere Supporto multi-camera .
  • 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 mitigati se i client trasmettono i propri valori iniziali durante l'inizializzazione della sessione di acquisizione. Vedere Parametri di sessione .
  • Aggiunge chiavi dati di stabilizzazione ottica (OIS) per la stabilizzazione e gli effetti a livello di app. Vedi STATISTICS_OIS_SAMPLES .
  • Aggiunge il supporto flash esterno. Vedi CONTROL_AE_MODE_ON_EXTERNAL_FLASH .
  • Aggiunge un intento di tracciamento del movimento in CAPTURE_INTENT . Vedi CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • Depreca LENS_RADIAL_DISTORTION e aggiunge LENS_DISTORTION al suo posto.
  • Aggiunge modalità di correzione della distorsione in CaptureRequest . Vedi DISTORTION_CORRECTION_MODE .
  • Aggiunge il supporto per fotocamere USB/UVC esterne sui dispositivi supportati. Vedi INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL .

Fotocamera HAL

3.4

Aggiornamenti a ICameraDeviceSession

Aggiornamenti a ICameraDeviceCallback

3.3

I seguenti tasti vengono aggiunti ai metadati della fotocamera in Android 9.

  • Capacità
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • Tag dei metadati della fotocamera
    • 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 della fotocamera del fornitore devono essere binderizzate . Android 8.0 contiene anche questi miglioramenti chiave al servizio Fotocamera:

  • Superfici condivise: abilita più superfici che condividono la stessa OutputConfiguration
  • API di sistema per modalità fotocamera personalizzate
  • onCaptureQueueEmpty

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

Superfici condivise

Questa funzionalità consente a un solo set di buffer di pilotare due output, come l'anteprima e la codifica video, riducendo il consumo energetico e di memoria. Per supportare questa funzionalità, i produttori di dispositivi devono garantire che le loro implementazioni HAL della fotocamera e HAL gralloc possano creare buffer gralloc utilizzati da più consumatori diversi (come il compositore hardware/GPU e il codificatore video), anziché da un solo consumatore. Il servizio fotocamera passa i flag di utilizzo del consumatore all'HAL della fotocamera e all'HAL gralloc; devono allocare i tipi corretti di buffer oppure l'HAL della fotocamera deve restituire un errore indicante che questa combinazione di consumatori non è supportata.

Consulta la documentazione per gli sviluppatori enableSurfaceSharing per ulteriori dettagli.

API di sistema per modalità fotocamera personalizzate

L'API della telecamera pubblica definisce due modalità operative: registrazione normale e vincolata ad alta velocità. Hanno una semantica abbastanza diversa; ad esempio, la modalità ad alta velocità è limitata a un massimo di due uscite specifiche contemporaneamente. Vari OEM hanno espresso interesse nella definizione di altre modalità personalizzate per funzionalità specifiche dell'hardware. Dietro le quinte, la modalità è solo un numero intero passato a configure_streams . Vedi: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

Questa funzionalità include una chiamata API di sistema che le app della fotocamera OEM possono utilizzare per abilitare una modalità personalizzata. Queste modalità devono iniziare dal 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 quindi fare in modo che la propria app fotocamera personalizzata utilizzi l'API di sistema.

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

onCaptureQueueEmpty

Lo scopo di questa API è ridurre la latenza delle modifiche ai controlli come lo zoom mantenendo la coda delle richieste quanto più vuota possibile. onCaptureQueueEmpty non richiede lavoro HAL; era puramente un'aggiunta dal lato della struttura. Le applicazioni che vogliono trarne vantaggio devono aggiungere un ascoltatore a quella richiamata e rispondere in modo appropriato. Generalmente ciò avviene inviando un'altra richiesta di acquisizione al dispositivo fotocamera.

Interfaccia HIDL della fotocamera

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

3.4

Aggiunte minori ai metadati supportati e modifiche al supporto data_space:

  • Aggiungi metadati statici ANDROID_SENSOR_OPAQUE_RAW_SIZE come obbligatori se il formato RAW_OPAQUE è supportato.
  • Aggiungi metadati statici ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE come obbligatori se è supportato un formato RAW.
  • Passa al campo camera3_stream_t data_space con una definizione più flessibile, utilizzando la definizione della versione 0 della codifica dataspace.
  • Aggiunte di metadati generali disponibili per l'uso 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 capacità estesa:

  • Aggiornamenti API di ritrattamento 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à operativa di configurazione del flusso camera3 a camera3_stream_configuration_t .

3.2

Revisione minore dell'HAL con capacità estesa:

  • Depreca get_metadata_vendor_tag_ops . Utilizza invece get_vendor_tag_ops in camera_common.h .
  • Depreca register_stream_buffers . Tutti i buffer gralloc forniti dal framework all'HAL in process_capture_request potrebbero essere nuovi in ​​qualsiasi momento.
  • Aggiungi il supporto dei risultati parziali. process_capture_result può essere chiamato più volte con un sottoinsieme dei risultati disponibili prima che sia disponibile il risultato completo.
  • Aggiungi modello manuale a camera3_request_template . Le applicazioni possono utilizzare questo modello per controllare direttamente le impostazioni di acquisizione.
  • Rielaborare le specifiche del flusso bidirezionale e di input.
  • Modificare 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 capacità estesa:

  • configure_streams passa i flag di utilizzo del consumatore all'HAL.
  • flush call per eliminare tutte le richieste/buffer in volo il più velocemente possibile.

3.0

Prima revisione dell'HAL con capacità estesa:

  • Importante cambiamento di versione poiché l'ABI è completamente diverso. Nessuna modifica alle capacità hardware richieste o al modello operativo dalla versione 2.0.
  • Richiesta di input e interfacce della coda di flusso rielaborate: il framework chiama nell'HAL con la richiesta successiva e i buffer di flusso già rimossi dalla coda. È incluso il supporto del framework di sincronizzazione, necessario per implementazioni efficienti.
  • Spostati i trigger nelle richieste, la maggior parte delle notifiche nei risultati.
  • Consolidati tutti i callback nel framework in un'unica struttura e tutti i metodi di installazione in un'unica chiamata initialize() .
  • Ho reso la configurazione dello streaming in un'unica chiamata per semplificare la gestione dello streaming. I flussi bidirezionali sostituiscono il costrutto STREAM_FROM_STREAM .
  • Semantica in modalità limitata per dispositivi hardware meno recenti/limitati.

2.0

Versione iniziale di HAL con funzionalità estese (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 testato per nuove funzionalità come il controllo manuale dell'acquisizione, l'acquisizione RAW Bayer, la rielaborazione dei dati RAW, ecc.

1.0

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

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

Cronologia delle versioni del modulo fotocamera

Questa sezione contiene informazioni sulla versione del modulo per il modulo hardware della fotocamera, 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 minore.

2.4

Questa versione del modulo fotocamera aggiunge le seguenti modifiche API:

  1. Supporto modalità torcia. Il framework può attivare la modalità torcia per qualsiasi dispositivo con fotocamera dotato di unità flash, senza aprire il dispositivo con fotocamera. Il dispositivo fotocamera ha una priorità più alta nell'accesso al flash rispetto al modulo fotocamera; l'apertura di un dispositivo fotocamera spegne la torcia se era stata abilitata tramite l'interfaccia del modulo. Quando si verificano conflitti di risorse, ad esempio quando open() viene chiamato per aprire un dispositivo fotocamera, il modulo HAL della fotocamera deve notificare al framework tramite la richiamata dello stato della modalità torcia che la modalità torcia è stata disattivata.
  2. Supporto per fotocamera esterna (ad esempio, fotocamera USB hot-plug). Gli aggiornamenti API specificano che le informazioni statiche della fotocamera sono disponibili solo quando la fotocamera è collegata e pronta per l'uso per fotocamere hot-plug esterne. Le chiamate per ottenere informazioni statiche non sono valide quando lo stato della fotocamera non è CAMERA_DEVICE_STATUS_PRESENT . Il framework conta esclusivamente sui callback di modifica dello stato del dispositivo per gestire l'elenco delle telecamere esterne disponibili.
  3. Suggerimenti per l'arbitraggio della fotocamera. Aggiunge il supporto per indicare esplicitamente il numero di dispositivi 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 che venga invocato qualsiasi altro metodo del modulo.

2.3

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

2.2

Questa versione del modulo fotocamera aggiunge il supporto dei tag del fornitore dal modulo e depreca il vecchio vendor_tag_query_ops che in precedenza era accessibile solo con un dispositivo aperto.

2.1

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

2.0

I moduli telecamera che riportano questo numero di versione implementano la seconda versione dell'interfaccia HAL del modulo telecamera. I dispositivi fotocamera apribili tramite questo modulo possono supportare la versione 1.0 o la versione 2.0 dell'interfaccia HAL del dispositivo 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 successivo.

1.0

I moduli telecamera che riportano questi numeri di versione implementano l'interfaccia HAL del modulo telecamera iniziale. Tutti i dispositivi fotocamera apribili tramite questo modulo supportano solo la versione 1 dell'HAL del dispositivo 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.