Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Supporto versione fotocamera

Questa pagina descrive le differenze di versione negli HAL della fotocamera, nelle API e nei test della Compatibility Test Suite (CTS) associati. Comprende anche diverse modifiche architettoniche 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

I seguenti termini sono usati in questa pagina:

API fotocamera 1
Il framework della fotocamera a livello di app su Android 4.4 e dispositivi inferiori, esposto attraverso la classe android.hardware.Camera .
Camera API2
Il framework della videocamera a livello di app su Android 5.0 e versioni successive, esposto attraverso il pacchetto android.hardware.camera2 .
Camera HAL
Il livello del modulo telecamera implementato dai fornitori di SoC. I framework pubblici a livello di app sono costruiti sulla parte superiore della videocamera HAL.
Camera HAL3.1
Versione del dispositivo fotocamera HAL rilasciata con Android 4.4.
Camera HAL3.2
Versione del dispositivo fotocamera HAL rilasciata con Android 5.0.
Camera API1 CTS
Set di test CTS della fotocamera eseguiti su Camera API1.
Camera API2 CTS
Set aggiuntivo di test CTS della fotocamera eseguiti su Camera API2.
triplo
Separa l'implementazione del fornitore (software di livello inferiore specifico per dispositivo scritto dai produttori di silicio) dal framework del sistema operativo Android attraverso una nuova interfaccia del fornitore.
HIDL
Il linguaggio di definizione dell'interfaccia HAL è stato 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 fotocamera 1

L'API Camera1 deprecata di Android 5.0, che continua a essere gradualmente eliminata dal momento che lo sviluppo della nuova piattaforma si concentra su Camera API2. Tuttavia, il periodo di eliminazione sarà lungo e le versioni di Android continueranno a supportare le app Camera API1 per qualche tempo. In particolare, il supporto continua per:

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

Camera API2

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

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à di Camera API2. La proprietà android.info.supportedHardwareLevel cui le app possono eseguire query tramite le interfacce Camera API2 riporta uno dei seguenti livelli di supporto:

  • LEGACY : questi dispositivi espongono funzionalità alle app tramite le interfacce Camera API2 che hanno approssimativamente le stesse funzionalità di quelle 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 funzioni Camera API2 come i controlli per frame.
  • LIMITED : questi dispositivi supportano alcune funzionalità Camera API2 (ma non tutte) e devono utilizzare Camera HAL 3.2 o 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 il ritrattamento YUV e l'acquisizione di immagini RAW, insieme a ulteriori configurazioni 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 telecamere esterne come webcam USB.

Le capacità individuali sono esposte attraverso la proprietà android.request.availableCapabilities nelle interfacce Camera API2. FULL dispositivi FULL richiedono, tra le altre, le funzionalità MANUAL_SENSOR e MANUAL_POST_PROCESSING . La funzionalità RAW è opzionale anche per i dispositivi FULL . LIMITED dispositivi LIMITED possono pubblicizzare qualsiasi sottoinsieme di queste funzionalità, inclusa nessuna di esse. Tuttavia, la capacità BACKWARD_COMPATIBLE deve essere sempre definita.

Il livello hardware supportato del dispositivo, nonché le funzionalità specifiche Camera API2 che supporta, sono disponibili come flag di funzionalità seguenti per consentire il filtro Google Play delle app 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 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 presentano un'implementazione di Camera HAL3.2 e che non sono in grado di supportare le interfacce API2 Camera complete devono comunque superare i test CTS Camera API2. Tuttavia, il dispositivo funziona in modalità LEGACY Camera API2 (in cui le chiamate Camera API2 sono mappate concettualmente alle chiamate Camera API1), quindi tutti i test CTS Camera API2 relativi a funzionalità o funzionalità oltre Camera API1 vengono automaticamente ignorati.

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

Requisiti VTS

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

Indurimento della struttura della fotocamera

Per rafforzare la sicurezza dei media e della videocamera, Android 7.0 sposta il servizio videocamera fuori dal mediaserver. A partire da Android 8.0, ogni videocamera HAL vincolata viene eseguita in un processo separato dal servizio videocamera. I fornitori potrebbero dover apportare modifiche all'HAL della videocamera in base alle versioni API e HAL in uso. Le seguenti sezioni 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ò presumere che la telecamera e il codificatore video siano attivi 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 .

    Fotocamera Android 7.0 e stack multimediale in API1 su HAL3

    Figura 1. Camera Android 7.0 e stack multimediale in 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.)

    Fotocamera Android 7.0 e stack multimediale in API1 su HAL1

    Figura 2. Fotocamera Android 7.0 e stack multimediale in 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 di telecamere 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 in API2 su HAL3

Requisiti addizionali

Le modifiche apportate all'architettura per la protezione dei supporti e la protezione della struttura della videocamera includono i seguenti requisiti aggiuntivi per i dispositivi.

  • Generale. I dispositivi richiedono una larghezza di banda aggiuntiva a causa dell'IPC, che può influire sui casi di utilizzo della fotocamera sensibili al 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à 120/240 FPS. I dispositivi richiedono anche 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 di 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 di telecamere e media 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ò usare gli indirizzi per identificare i buffer perché gli indirizzi possono 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 volta successiva che l'HAL lo riceve.
  • Aggiorna i criteri SELinux per cameraserver. Se le politiche SELinux specifiche del dispositivo concedono le autorizzazioni mediaserver per eseguire la telecamera, è necessario aggiornare le politiche SELinux per fornire le autorizzazioni appropriate a cameraserver. Scoraggiamo la replica delle politiche SELinux del mediaserver per cameraserver (poiché mediaserver e cameraserver richiedono generalmente risorse diverse nel sistema). Cameraserver dovrebbe avere solo le autorizzazioni necessarie per eseguire le funzionalità della fotocamera e tutte le autorizzazioni non necessarie relative alla fotocamera nel mediaserver devono essere rimosse.
  • Separazione tra Camera HAL e cameraserver. Android 8.0 e versioni successive separano ulteriormente l'HAL della fotocamera con raccoglitori in un processo diverso da cameraserver. IPC passa attraverso 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 verificano 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, verifica l'implementazione del fornitore eseguendo VTS.

Cronologia delle versioni di Camera HAL

Per un elenco di test disponibili per la valutazione dell'HAL della videocamera Android, consultare l'elenco di controllo del test della videocamera HAL .

Android 10

Android 10 introduce i seguenti aggiornamenti.

API della fotocamera

Camera HAL

Le seguenti versioni di Camera HAL sono aggiornate in Android 10.

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics : le informazioni sulla telecamera statica per un ID telecamera fisico che supporta un dispositivo telecamera logico. Vedi Supporto multi-camera .
  • isStreamCombinationSupported : questo metodo supporta un'API pubblica che consente ai client di isStreamCombinationSupported query se è supportata una configurazione di sessione. Consulta l' API per eseguire query sulle combinazioni di stream .

ICameraDeviceSession

  • isReconfigurationNeeded : metodo che indica al framework della telecamera se è necessaria la riconfigurazione completa del flusso per possibili nuovi valori dei parametri di sessione. Ciò consente di evitare inutili ritardi di riconfigurazione della fotocamera. Vedi query di riconfigurazione della sessione .
  • API di gestione del buffer HAL : queste API consentono all'HAL della telecamera di richiedere buffer dal framework della telecamera solo quando richiesto invece di accoppiare ciascuna richiesta di acquisizione con i buffer associati attraverso la pipeline della telecamera, con conseguenti risparmi di memoria potenzialmente significativi.
    • signalStreamFlush : signalStreamFlush 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 aggiunta viene fornito il contatore streamConfigCounter per verificare la presenza di una race condition tra le chiamate configureStreams_3_5 e signalStreamFlush .

Aggiornamenti a ICameraDeviceCallback :

  • requestStreamBuffers : callback sincrono che l'HAL della telecamera chiama per chiedere 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

I seguenti tasti vengono aggiunti 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
  • 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 del flusso di profondità dinamica disponibili
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • Configurazioni del flusso HEIC disponibili
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Modulo telecamera

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

2.5

  • Aggiunge il metodo notifyDeviceStateChange per i dispositivi per avvisare l'HAL della fotocamera quando le modifiche fisiche, come la piegatura, influiscono sulla fotocamera e sul routing.

2.4

  • I dispositivi che si avviano con livello API 29 o superiore DEVONO indicare true per isTorchModeSupported .

Android 9

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

API della fotocamera

  • Presenta l'API multi-camera per supportare al meglio i dispositivi con più telecamere rivolte nella stessa direzione, abilitando funzionalità come il bokeh e lo zoom continuo. Ciò consente alle app di visualizzare più telecamere su un dispositivo come un'unica unità logica (telecamera logica). Le richieste di acquisizione possono anche essere inviate a singoli dispositivi telecamera racchiusi in una telecamera logica. Vedi Supporto multi-camera .
  • Presenta i parametri della sessione. I parametri di sessione sono un sottoinsieme dei parametri di acquisizione disponibili che possono causare gravi ritardi di elaborazione quando modificati. Questi costi possono essere mitigati se i client passano i loro valori iniziali durante l'inizializzazione della sessione di acquisizione. Vedi 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 rilevamento del movimento in CAPTURE_INTENT . Vedi CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • LENS_RADIAL_DISTORTION e aggiunge LENS_DISTORTION al suo posto.
  • Aggiunge le modalità di correzione della distorsione in CaptureRequest . Vedi DISTORTION_CORRECTION_MODE .
  • Aggiunge il supporto per le fotocamere USB / UVC esterne sui dispositivi supportati. Vedi INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL .

Camera HAL

3.4

Aggiornamenti a ICameraDeviceSession

Aggiornamenti a ICameraDeviceCallback

3.3

I seguenti tasti vengono aggiunti 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 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 di Android 8.0 introduce Treble. Con Treble, le implementazioni HAL della videocamera del fornitore devono essere vincolate . 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

Vedere le sezioni seguenti per ulteriori informazioni su queste funzionalità.

Superfici condivise

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

Consulta la documentazione per sviluppatori di 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 al massimo a due uscite specifiche contemporaneamente. Vari OEM hanno espresso interesse nel definire altre modalità personalizzate per funzionalità specifiche dell'hardware. Sotto il cofano, la modalità è solo un numero intero passato a configure_streams . Vedi: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

Questa funzione include una chiamata API di sistema che le app della fotocamera OEM possono utilizzare per abilitare una modalità personalizzata. Queste modalità devono iniziare con un valore intero 0x8000 per evitare conflitti con le modalità future aggiunte all'API pubblica.

Per supportare questa funzione, gli OEM devono semplicemente aggiungere la nuova modalità al loro HAL, innescato da questo numero intero passato all'HAL su configure_streams, e quindi far sì che la loro 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 al controllo come lo zoom mantenendo la coda delle richieste il più vuota possibile. onCaptureQueueEmpty non richiede alcun lavoro HAL; era puramente un'aggiunta dal lato della struttura. Le applicazioni che vogliono trarne vantaggio devono aggiungere un listener a quel callback e rispondere in modo appropriato. In genere ciò avviene inviando un'altra richiesta di acquisizione al dispositivo della fotocamera.

Interfaccia HIDL della fotocamera

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

3.4

Aggiunte minori ai metadati supportati e modifiche al supporto data_space:

  • Aggiungi ANDROID_SENSOR_OPAQUE_RAW_SIZE metadati statici come obbligatori se il formato RAW_OPAQUE è supportato.
  • Aggiungi ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE metadati statici come obbligatori se è supportato qualsiasi formato RAW.
  • Passa il campo camera3_stream_t data_space a una definizione più flessibile, usando la definizione versione 0 della codifica dataspace.
  • Aggiunte di metadati generali che sono 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 a capacità estesa:

  • Aggiornamenti API di rielaborazione OPAQUE e YUV.
  • Supporto di base per buffer di output di profondità.
  • L'aggiunta di data_space campo per camera3_stream_t .
  • Aggiunta del campo di rotazione a camera3_stream_t .
  • Aggiunta della modalità operativa di configurazione del flusso camera3_stream_configuration_t a camera3_stream_configuration_t .

3.2

Revisione minore dell'HAL a capacità estesa:

  • get_metadata_vendor_tag_ops . Utilizzare invece get_vendor_tag_ops in camera_common.h .
  • Deprecate register_stream_buffers . Tutti i buffer di gralloc forniti da Framework a HAL in process_capture_request possono essere nuovi in ​​qualsiasi momento.
  • Aggiungi supporto risultati parziale. 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.
  • 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 a 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 a capacità estesa:

  • Importante modifica della versione poiché l'ABI è completamente diverso. Nessuna modifica alle capacità hardware richieste o al modello operativo dalla 2.0.
  • Interfacce di coda di flusso e richieste di input rielaborate: il framework chiama HAL con la richiesta successiva e i buffer di flusso già annullati. È incluso il supporto del framework di sincronizzazione, necessario per implementazioni efficienti.
  • Sposta i trigger in richieste, la maggior parte delle notifiche in risultati.
  • Consolidato tutti i callback in framework in una struttura e tutti i metodi di installazione in una singola chiamata initialize() .
  • Trasforma la configurazione del flusso in un'unica chiamata per semplificare la gestione del flusso. I flussi bidirezionali sostituiscono il costrutto STREAM_FROM_STREAM .
  • Semantica in modalità limitata per dispositivi hardware vecchi / limitati.

2.0

Versione iniziale di HAL con funzionalità estese (Android 4.2) [camera2.h]:

  • Sufficiente per l'implementazione dell'API android.hardware.Camera esistente.
  • Consente la coda ZSL nel livello di servizio della fotocamera.
  • Non testato per nuove funzionalità come controllo di acquisizione manuale, acquisizione Bayer RAW, rielaborazione di dati RAW, ecc.

1.0

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

  • Convertito da C ++ CameraHardware Livello di astrazione dell'interfaccia.
  • Supporta l'API android.hardware.Camera .

Cronologia delle versioni del modulo videocamera

Questa sezione contiene informazioni sulla versione del modulo per il modulo hardware Camera, basato su camera_module_t.common.module_api_version . Le due cifre esadecimali più significative rappresentano la versione principale e le due meno significative rappresentano la versione minore.

2.4

Questa versione del modulo videocamera aggiunge le seguenti modifiche API:

  1. Supporto modalità torcia. Il framework può attivare la modalità torcia per qualsiasi dispositivo fotocamera dotato di unità flash, senza aprire un dispositivo fotocamera. Il dispositivo fotocamera ha una priorità maggiore nell'accesso all'unità flash rispetto al modulo fotocamera; l'apertura di un dispositivo videocamera spegne la torcia se era stata abilitata tramite l'interfaccia del modulo. Quando si verificano conflitti di risorse, come ad esempio open() viene chiamato per aprire un dispositivo videocamera, il modulo HAL della videocamera deve notificare al framework tramite la richiamata dello stato della modalità torcia che la modalità torcia è stata disattivata.
  2. Supporto per videocamera esterna (ad esempio, videocamera hot plug USB). 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 ottenere informazioni statiche sono chiamate non 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 di telecamere esterne disponibili.
  3. Suggerimenti per l'arbitrato 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 resource_cost e conflicting_devices campi dovrebbero sempre essere impostate nel camera_info struttura restituita dalla get_camera_info chiamata.
  4. Metodo di inizializzazione del modulo. Chiamato dal servizio fotocamera dopo il caricamento del modulo HAL per consentire l'inizializzazione una tantum dell'HAL. Viene chiamato prima che vengano invocati altri metodi del modulo.

2.3

Questa versione del modulo videocamera aggiunge il supporto del dispositivo HAL della videocamera legacy aperto. Il framework può utilizzarlo per aprire il dispositivo della fotocamera come versione HAL del dispositivo inferiore Dispositivo HAL 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 fotocamera con l'ultima versione supportata, che è anche la versione elencata in camera_info_t.device_version .

2.2

Questa versione del modulo telecamera aggiunge il supporto tag fornitore dal modulo e deprezza i vecchi vendor_tag_query_ops che erano precedentemente accessibili solo con un dispositivo aperto.

2.1

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

2.0

I moduli videocamera che riportano questo numero di versione implementano la seconda versione dell'interfaccia HAL del modulo videocamera. 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 superiore.

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 del dispositivo fotocamera 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.