Supporto delle versioni della fotocamera

Questa pagina contiene informazioni dettagliate sulle differenze di versione in HAL per le videocamere, API e modelli associati Test della Compatibility Test Suite (CTS). Riguarda anche diversi 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 effettuare per supportare queste modifiche nell'implementazione delle fotocamere.

Terminologia

In questa pagina vengono utilizzati i seguenti termini:

API Fotocamera1
Framework della fotocamera a livello di app su dispositivi Android 4.4 e versioni precedenti, esposto tramite la classe android.hardware.Camera.
API2 della fotocamera
Framework della fotocamera a livello di app su dispositivi 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. Il pubblico a livello di app basati sull'HAL della fotocamera.
Fotocamera HAL3.1
Versione della fotocamera HAL rilasciata con Android 4.4.
Videocamera HAL3.2
Versione della fotocamera HAL rilasciata con Android 5.0.
CTS API1 fotocamera
Set di test CTS della fotocamera eseguiti sulla parte superiore della videocamera API1.
CTS API2 fotocamera
Set aggiuntivo di test CTS della fotocamera eseguito in base all'API Camera2.
Alti
Separa l'implementazione del fornitore (software di livello inferiore, specifico per dispositivo creati da produttori di silicio) dal framework del sistema operativo Android tramite una nuova l'interfaccia del fornitore.
HIDL
Lingua di definizione dell'interfaccia HAL introdotto con Treble e utilizzato per specificare l'interfaccia tra HAL e e i relativi utenti.
VTT
Suite di test del fornitore introdotta insieme Alti.

API Camera

Android include le seguenti API della fotocamera.

API Fotocamera1

Android 5.0 ha deprecato l'API Camera 1, che continua a essere gradualmente eliminata lo sviluppo della piattaforma è incentrato sull'API Camera2. Tuttavia, il periodo di eliminazione graduale potrebbero essere lunghi e le release Android continueranno a supportare le app Fotocamera API1 per per un po' di tempo. Nello specifico, il supporto continua per:

  • Interfacce dell'API Camera1 per le app. App Fotocamera basate sulla fotocamera L'API1 dovrebbe funzionare come sui dispositivi con versioni di release di Android precedenti.
  • Versioni HAL per fotocamera. Include il supporto per la fotocamera HAL1.0.

API2 della fotocamera

Il framework Camera API2 espone all'app il controllo della fotocamera di livello inferiore, che includono flussi burst/streaming zero-copy 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 il Panoramica video di Google I/O.

Android 5.0 e versioni successive include Camera API2; mentre i dispositivi con Android Le versioni 5.0 e successive potrebbero non supportare tutte le funzionalità dell'API Camera 2. La android.info.supportedHardwareLevel proprietà su cui le app possono eseguire query tramite l'interfaccia dell'API Camera segnala uno dei seguenti livelli:

  • LEGACY: questi dispositivi espongono funzionalità alle app tramite Interfacce API2 della fotocamera che hanno all'incirca le stesse funzionalità di quelle esposte alle app tramite le interfacce dell'API Camera1. Il codice dei framework legacy traduce concettualmente le chiamate API2 di Camera in chiamate API1 di Camera; dispositivi legacy non supportano le funzionalità API2 della fotocamera, come i controlli per frame.
  • LIMITED: questi dispositivi supportano alcune funzionalità dell'API Camera2 (ma non tutte) e la videocamera deve utilizzare HAL 3.2 o versioni successive.
  • FULL: questi dispositivi supportano tutte le principali funzionalità dei Fotocamera API2 e deve utilizzare Fotocamera HAL 3.2 o versioni successive e Android 5.0 o versioni successive.
  • LEVEL_3: questi dispositivi supportano la rielaborazione YUV e le immagini RAW acquisizioni, insieme a ulteriori configurazioni degli stream di output.
  • EXTERNAL: questi dispositivi sono simili a LIMITED dispositivi con alcune eccezioni; ad esempio, alcune informazioni dei sensori non essere riportati o hanno frequenze fotogrammi meno stabili. Questo livello viene utilizzato per come le webcam USB.

Le capacità individuali sono esposte attraverso Proprietà android.request.availableCapabilities nell'API Camera2 interfacce. FULL dispositivi richiedono MANUAL_SENSOR e MANUAL_POST_PROCESSING, tra le altre. La La funzionalità RAW è facoltativa anche per i dispositivi FULL. LIMITED dispositivi possono pubblicizzare un sottoinsieme di queste funzionalità, incluso nessuno di questi. Tuttavia, la funzionalità BACKWARD_COMPATIBLE devono essere sempre definiti.

Il livello hardware supportato del dispositivo e la videocamera specifica le funzionalità API2 che supporta, sono disponibili con i seguenti flag di funzionalità consenti il filtro di Google Play delle app fotocamera API2 della fotocamera.

  • 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 l'API Camera 1 CTS, Fotocamera Test delle videocamere API2 CTS e CTS Verifier.

Dispositivi sprovvisti di implementazione della fotocamera HAL3.2 in grado di supportare l'intera interfaccia API2 della fotocamera, deve superare Test CTS su API2. Tuttavia, il dispositivo funziona nell'API Camera2 Modalità LEGACY (in cui le chiamate API2 di Camera vengono concettualmente mappate alle chiamate API1 di Camera), quindi tutti i test CTS di Camera API2 relativi a funzionalità o funzionalità che vanno oltre l'API Camera1 vengono ignorate automaticamente.

Sui dispositivi legacy, i test CTS API2 della fotocamera che vengono eseguiti utilizzano interfacce e funzionalità esistenti dell'API Camera pubblica senza nuove i tuoi requisiti. Bug esposti (e che causano un errore CTS dell'API2 della videocamera) sono presenti bug già presenti nell'HAL della fotocamera esistente del dispositivo, quindi Essere trovato dalle app Camera API1 esistenti. Non ci aspettiamo molti insetti di questa natura (tuttavia, eventuali bug di questo tipo devono essere risolti per superare i test CTS dell'API Camera).

Requisiti VTS

I dispositivi con Android 8.0 e versioni successive con implementazioni HAL binderizzate devono passa la fotocamera Test VTS.

Rafforzamento del framework della fotocamera

Per rafforzare la sicurezza del framework dei contenuti multimediali e della fotocamera, Android 7.0 sposta la fotocamera da mediaserver. A partire da Android 8.0, ogni videocamera vincolata L'HAL viene eseguito in un processo separato dal servizio fotocamera. I fornitori potrebbero dover cambiamenti nell'HAL della fotocamera a seconda della versione API e HAL in uso. La le seguenti sezioni descrivono nel dettaglio le modifiche all'architettura in AP1 e AP2 per HAL1 e HAL3 e requisiti generali.

Modifiche all'architettura per API1

La registrazione video API1 può presupporre che la videocamera e il codificatore video siano in diretta nello stesso e il processo di sviluppo. Quando si utilizza API1 su:

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

    Fotocamera e contenuti multimediali di Android 7.0 stack in API1 su HAL3

    Figura 1. Fotocamera e contenuti multimediali con Android 7.0 stack in API1 su HAL3

  • HAL1, che supporta il passaggio dei metadati nei buffer video, i fornitori devono aggiorna l'HAL per utilizzare kMetadataBufferTypeNativeHandleSource. (kMetadataBufferTypeCameraSource non è più supportato su Android 7,0.

    Fotocamera e contenuti multimediali di Android 7.0 stack in API1 su HAL1

    Figura 2. Fotocamera e contenuti multimediali con Android 7.0 stack in API1 su HAL1

Modifiche all'architettura per API2

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

  • L'HAL1 non è interessato dallo spostamento del servizio camera e nessun fornitore aggiornamento.
  • L'HAL3 è interessato, ma non è previsto alcun aggiornamento del fornitore necessario:

    Fotocamera di Android 7.0 e stack multimediale in API2 su HAL3

    Figura 3. Fotocamera e contenuti multimediali con Android 7.0 stack in API2 su HAL3

Requisiti aggiuntivi

Le modifiche all'architettura apportate per la protezione avanzata dei contenuti multimediali e della fotocamera di sicurezza includono i seguenti requisiti aggiuntivi per i dispositivi.

  • Disposizioni generali. I dispositivi richiedono larghezza di banda aggiuntiva a causa dell'IPC, il che potrebbe interessare i casi d'uso delle videocamere sensibili al tempo, come i video ad alta velocità registrazione in tempo reale. I fornitori possono misurare l'impatto effettivo eseguendo android.hardware.camera2.cts.PerformanceTest e Google Fotocamera per la registrazione di video ad alta velocità a 120/240 f/s. I dispositivi richiedono anche una piccola quantità di RAM aggiuntiva per creare il nuovo processo.
  • Passaggio dei metadati nei buffer video (solo HAL1). Se HAL1 memorizza metadati invece di dati di frame YUV reali nei buffer video, l'HAL deve usa kMetadataBufferTypeNativeHandleSource come buffer dei metadati digita e trasmette VideoNativeHandleMetadata nei buffer video. (kMetadataBufferTypeCameraSource non è più supportato su Android 7,0. Con VideoNativeHandleMetadata, framework multimediali e fotocamera sono in grado di passare i buffer video tra i processi serializzando deserializzare correttamente gli handle nativi.
  • L'indirizzo dell'handle del buffer non sempre memorizza lo stesso buffer (solo HAL3). Per ogni richiesta di acquisizione, HAL3 ottiene gli indirizzi del buffer handle. L'HAL non può utilizzare gli indirizzi per identificare i buffer perché gli indirizzi può memorizzare un altro handle del buffer dopo che HAL ha restituito il buffer. Devi aggiornare l'HAL per utilizzare gli handle del buffer per identificare i buffer. Ad esempio, HAL riceve un handle del buffer indirizzo A, che memorizza l'handle A del buffer. Dopo il ritorno dell'HAL l'handle A del buffer, l'indirizzo A dell'handle del buffer potrebbe memorizzare l'handle B del buffer la prossima volta HAL la riceve.
  • Aggiorna i criteri SELinux per cameraserver. Se i criteri SELinux specifici per dispositivo concedono autorizzazioni a mediaserver per eseguire la fotocamera, devi aggiornare i criteri SELinux per concedere a cameraserver le autorizzazioni appropriate. Me scoraggia la replica dei criteri SELinux di mediaserver per cameraserver (poiché mediaserver e cameraserver richiedono generalmente risorse diverse nello di sistema). Cameraserver deve avere solo le autorizzazioni necessarie per eseguire la videocamera funzionalità ed eventuali autorizzazioni non necessarie correlate alla fotocamera in mediaserver devono essere rimossi.
  • Separazione tra Camera HAL e cameraserver. Android 8.0 e versioni successive separano inoltre la HAL della fotocamera rilegata in un processo diverso da cameraserver. IPC passa attraverso Interfacce definite HIDL.

Convalida

Per tutti i dispositivi che includono una fotocamera e eseguono Android 7.0, verifica con Android 7.0 CTS. Sebbene Android 7.0 non includa nuovi test CTS che verificano le modifiche al servizio delle videocamere, i test CTS esistenti non hanno esito positivo se non hai apportato gli aggiornamenti indicati sopra.

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

Cronologia delle versioni HAL della videocamera

Per un elenco dei test disponibili per valutare la fotocamera Android HAL, consulta la Test dell'HAL della fotocamera elenco di controllo.

Android 10

Android 10 introduce i seguenti aggiornamenti.

API Camera

Videocamera HAL

Le seguenti versioni di Fotocamera HAL sono aggiornate in Android 10:

3,50

ICameraDevice

ICameraDeviceSession

  • isReconfigurationNeeded: Metodo che indica al framework della videocamera se lo streaming completo è necessaria una riconfigurazione per eventuali nuovi valori parametro di sessione. Questo per evitare inutili ritardi nella riconfigurazione della videocamera. Consulta Query di riconfigurazione della sessione.
  • HAL API di gestione del buffer: queste API consentono all'HAL della fotocamera di richiedere buffer dal framework della fotocamera solo quando necessario, invece di accoppiare ciascun di acquisire una richiesta di acquisizione con i buffer associati lungo la pipeline della fotocamera, con un risparmio di memoria potenzialmente significativo.
    • signalStreamFlush: segnala all'HAL che la videocamera che il servizio 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 inoltre, il contatore streamConfigCounter viene fornito verifica la presenza di una condizione di gara tra configureStreams_3_5 e signalStreamFlush chiamate.

Aggiornamenti a ICameraDeviceCallback:

  • requestStreamBuffers: Callback sincrono che l'HAL della videocamera chiama per chiedere al server della videocamera buffer. Consulta requestStreamBuffers.
  • returnStreamBuffers: Callback sincrono per l'HAL della videocamera per restituire i buffer di output alla della videocamera. Consulta returnStreamBuffers.

3,40

Le chiavi che seguono vengono aggiunte ai metadati della fotocamera in Android 10:

  • Formati dell'immagine
    • 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 ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT chiave
    • 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 Fotocamera

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

2,50

  • Aggiunge il metodo notifyDeviceStateChange per consentire ai dispositivi di inviare notifiche l'HAL della fotocamera quando cambiamenti fisici, ad esempio la piegatura, influiscono sulla il routing.

2,40

  • I dispositivi che vengono lanciati con livello API 29 o superiore DEVONO segnalare true per isTorchModeSupported.

Android 9

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

API Camera

  • Introduce l'API multi-camera per supportare meglio i dispositivi con di fotocamere rivolte nella stessa direzione, abilitando funzionalità quali bokeh e senza interruzioni. In questo modo le app possono visualizzare più videocamere su un dispositivo come una sola unità logica (fotocamera logica). Le richieste di acquisizione possono essere inviate anche a singoli con una singola fotocamera logica. Consulta Supporto multi-fotocamera.
  • Introduce i parametri di sessione. I parametri di sessione sono un sottoinsieme dei i parametri di acquisizione disponibili che possono causare gravi ritardi di elaborazione quando modificato. Questi costi possono essere mitigati se i clienti trasmettono i loro valori iniziali durante l'inizializzazione della sessione di acquisizione. Consulta Parametri sessione.
  • Aggiunge chiavi di dati di stabilizzazione ottica (OIS) per la stabilizzazione a livello di app e e gli effetti sonori. Consulta STATISTICS_OIS_SAMPLES.
  • Aggiunge il supporto flash esterno. Consulta CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
  • Aggiunge un intent di rilevamento del movimento in CAPTURE_INTENT. Consulta CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
  • Ritira LENS_RADIAL_DISTORTION e aggiunge LENS_DISTORTION al suo posto.
  • Aggiunge modalità di correzione delle distorsioni in CaptureRequest. Consulta DISTORTION_CORRECTION_MODE.
  • Aggiunge il supporto per le videocamere USB/UVC esterne sui dispositivi supportati. Consulta INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

Videocamera HAL

3,40

Aggiornamenti a ICameraDeviceSession

Aggiornamenti a ICameraDeviceCallback

3,30

Le chiavi che seguono 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 release Android 8.0 introduce Treble. Con Treble, fotocamera HAL del fornitore le implementazioni devono essere binderizzati. Anche Android 8.0 contiene i seguenti miglioramenti principali al servizio Fotocamera:

  • Piattaforme condivise: attiva la condivisione dello stesso su più piattaforme OutputConfiguration
  • API di sistema per modalità fotocamera personalizzate
  • onCaptureQueueEmpty

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

Piattaforme condivise

Questa funzionalità consente a un solo set di buffer di pilotare due output, come anteprima e codifica video, con conseguente riduzione del consumo energetico e della memoria. A supportano questa funzione, i produttori devono assicurarsi che la fotocamera HAL e Le implementazioni dell'HAL Gralloc possono creare buffer Gralloc utilizzati diversi consumatori (ad esempio compositore hardware/GPU e l'encoder), anziché un solo consumer. Il servizio di videocamera supera l'utilizzo da parte dei consumatori segnala alla fotocamera HAL e al gralloc HAL; devono allocare i tipi di buffer corretti oppure l'HAL della fotocamera deve restituire un errore che questa combinazione di consumatori non è supportata.

Consulta enableSurfaceSharing documentazione per gli sviluppatori per ulteriori dettagli.

API di sistema per modalità fotocamera personalizzate

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

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

Per supportare questa funzionalità, gli OEM devono solo aggiungere la nuova modalità all'HAL, attivata da questo numero intero passato all'HAL su configure_streams e quindi la loro app per la videocamera personalizzata usa l'API di sistema.

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

onAcquisisci dalla codaVuota

Lo scopo di questa API è ridurre la latenza delle modifiche di controllo come lo zoom mantenendo la coda di richieste il più vuota possibile. onCaptureQueueEmpty non richiede alcuna operazione HAL; era solo un'aggiunta lato framework. App che Se vuoi approfittarne, devi aggiungere un ascoltatore al callback e rispondere in modo appropriato. di solito l'invio di un'altra richiesta di acquisizione alla fotocamera dispositivo.

Interfaccia HIDL della fotocamera

L'interfaccia di Camera HIDL è una revisione completa dell'interfaccia di Camera HAL che utilizza API stabili definite da HIDL. Tutte le funzionalità e le caratteristiche della fotocamera Presente nelle più recenti versioni legacy 3.4 e 2.4 (per le videocamere (modulo HIDL) sono anch'essi parte delle definizioni HIDL.

3.4

Aggiunte di minore entità 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 ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE statico come obbligatori se è supportato qualsiasi formato RAW.
  • Passa a un campo camera3_stream_t data_space più flessibile utilizzando la definizione della versione 0 della codifica dello spazio dei dati.
  • Aggiunte di metadati generali disponibili per l'utilizzo 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à espansa:

  • Aggiornamenti delle API di rielaborazione OPAQUE e YUV.
  • Supporto di base per buffer di output di profondità.
  • Aggiunta del campo data_space a camera3_stream_t.
  • È stato aggiunto il campo di rotazione a camera3_stream_t.
  • È stata aggiunta la modalità operativa della configurazione dello stream di camera3 a camera3_stream_configuration_t.

3.2

Revisione secondaria dell'HAL con funzionalità espansa:

  • Ritira get_metadata_vendor_tag_ops. Utilizza le funzionalità di get_vendor_tag_ops in camera_common.h.
  • Ritira register_stream_buffers. Tutti i buffer Gralloc forniti dal framework all'HAL in process_capture_request, potrebbero essere nuovi in qualsiasi momento.
  • Aggiungi un supporto per i risultati parziali. process_capture_result potrebbe essere viene richiamata più volte con un sottoinsieme dei risultati disponibili prima della se il risultato è disponibile.
  • Aggiungi modello manuale a camera3_request_template. App puoi 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 process_capture_result anziché process_capture_request.

3.1

Revisione secondaria dell'HAL con funzionalità espansa:

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

3,0

Prima revisione dell'HAL con funzionalità espansa:

  • Grande modifica della versione poiché l'ABI è completamente diversa. Nessuna modifica al le funzionalità hardware o il modello operativo richiesti a partire dalla versione 2.0.
  • Interfacce per coda di flusso e richiesta di input rielaborate: chiamate framework in HAL con la prossima richiesta e i buffer di flusso già eliminati in coda. Supporto del framework di sincronizzazione ed è necessario per un'implementazione efficiente.
  • Spostamento degli attivatori nelle richieste e della maggior parte delle notifiche nei risultati.
  • Consolidamento di tutti i callback in un framework in un'unica struttura e configurazione in una singola chiamata initialize().
  • Trasformazione della configurazione degli stream in una singola chiamata per semplificarne la gestione. Gli stream bidirezionali sostituiscono STREAM_FROM_STREAM costrutto.
  • semantica in modalità limitata per dispositivi hardware meno recenti/limitati.

2,0

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

  • Sufficiente per implementare le android.hardware.Camera esistenti tramite Google Cloud CLI o tramite l'API Compute Engine.
  • Consente la coda ZSL nel livello di servizio fotocamera.
  • Non testato per nessuna nuova funzionalità come il controllo dell'acquisizione manuale e i file RAW di Bayer acquisizione, rielaborazione dei dati RAW ecc.

1,0

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

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

Cronologia delle versioni del modulo Fotocamera

Questa sezione contiene informazioni sul controllo delle versioni del modulo per l'hardware della videocamera basato su camera_module_t.common.module_api_version. I due esadecimali più significativi rappresentano la versione principale e i due minimi significativi rappresentano la versione secondaria.

2.4

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

  1. Supporto per modalità torcia. Il framework può attivare la modalità torcia per qualsiasi fotocamera dotata di flash, senza bisogno di aprire una fotocamera. La fotocamera ha una priorità più alta di accedere all'unità flash rispetto alla fotocamera modulo; l'apertura di un dispositivo con videocamera spegne la torcia, se era stata attivata attraverso l'interfaccia del modulo. In caso di conflitti tra le risorse, ad esempio open() viene chiamato per aprire un dispositivo fotocamera, il modulo HAL della fotocamera devi informare il framework tramite il callback dello stato della modalità torcia che è stata disattivata.
  2. Supporto per fotocamere esterne (ad es. videocamera con attacco a caldo USB). La Gli aggiornamenti dell'API specificano che le informazioni statiche della fotocamera sono disponibili solo quando la videocamera collegato e pronto per l'uso per le videocamere hot-plug esterne. Chiamate per diventare statici le informazioni sono chiamate non valide se lo stato della videocamera è diverso CAMERA_DEVICE_STATUS_PRESENT. Il framework conta esclusivamente i callback di modifica dello stato del dispositivo per gestire l'elenco delle videocamere esterne disponibili.
  3. Suggerimenti di arbitrato per la fotocamera. Aggiunge il supporto per indicare esplicitamente il numero di fotocamere che possono essere aperte e utilizzate contemporaneamente. A specificare combinazioni valide di dispositivi, resource_cost e I campi conflicting_devices devono essere sempre impostati nel Struttura camera_info restituita da get_camera_info chiamata.
  4. Metodo di inizializzazione del modulo. Chiamata dal servizio videocamera dopo il caricamento del modulo HAL per consentire l'inizializzazione una tantum dell'HAL. Viene chiamato prima che vengano richiamati 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 fotocamera come versione HAL del dispositivo precedente Dispositivo HAL se lo stesso dispositivo può supportare più versioni API. Chiamata aperta al modulo hardware standard (common.methods->open) continua per aprire la videocamera con l'ultima versione supportata, ossia anche la versione elencata in camera_info_t.device_version.

2,2

Questa versione del modulo della videocamera aggiunge il supporto per il tag del fornitore dal modulo e ritira la versione precedente di vendor_tag_query_ops che in precedenza erano solo accessibile con un dispositivo aperto.

2.1

Questa versione del modulo della videocamera aggiunge il supporto per i callback asincroni alla dal modulo HAL della fotocamera, che viene utilizzato per notificare il framework sulle modifiche allo stato del modulo della videocamera. Moduli che forniscono un'istanza Il metodo set_callbacks() deve segnalare almeno questo numero di versione.

2,0

I moduli della videocamera che segnalano questo numero di versione implementano la seconda versione dell'interfaccia HAL del modulo videocamera. Dispositivi con fotocamera apribili tramite questa può supportare la versione 1.0 o la versione 2.0 del dispositivo della videocamera dell'HAL. Il campo device_version di camera_info è sempre valida; il campo static_camera_characteristics di camera_info è valido se il campo device_version è 2.0 o versioni successive.

1,0

I moduli videocamera che segnalano questi numeri di versione implementano il modello iniziale modulo videocamera HAL. Tutti i dispositivi con videocamera possono essere aperti tramite questa supporta solo la versione 1 dell'HAL per dispositivo videocamera. La device_version e static_camera_characteristics i campi di camera_info non sono validi. Solo il L'API android.hardware.Camera può essere supportata da questo modulo e dai relativi dispositivi mobili.