Questa pagina descrive in dettaglio le differenze di versione negli HAL della fotocamera, nelle API e nei test CTS (Compatibility Test Suite) associati. Copre anche diverse modifiche architetturali apportate per rafforzare e proteggere il framework della fotocamera in Android 7.0, il passaggio a Treble in Android 8.0 e gli aggiornamenti che i fornitori devono apportare per supportare queste modifiche nelle implementazioni della fotocamera.
Terminologia
In questa pagina vengono utilizzati i seguenti termini:
- API fotocamera1
- Il framework della fotocamera a livello di app su dispositivi Android 4.4 e precedenti, esposto tramite la classe
android.hardware.Camera
. - Camera API2
- 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 della fotocamera implementato dai fornitori di SoC. I framework pubblici a livello di app sono costruiti sulla parte superiore della fotocamera HAL.
- 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.
- 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.
- Alti
- Separa l'implementazione del fornitore (software di livello inferiore specifico del 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
- Vendor test suite introdotta insieme a Treble.
API della fotocamera
Android include le seguenti API della fotocamera.
API fotocamera1
Android 5.0 ha deprecato Camera API1, che continua a essere gradualmente eliminato poiché lo sviluppo della nuova piattaforma si concentra su Camera API2. Tuttavia, il periodo di eliminazione graduale sarà lungo e le versioni di Android continueranno a supportare le app Camera API1 per un po' di tempo. Nello specifico, prosegue il supporto per:
- Interfacce API1 della fotocamera per le app. Le app della fotocamera basate su Camera API1 dovrebbero funzionare come sui dispositivi con versioni inferiori di Android.
- Versioni della fotocamera HAL. 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 di flusso/streaming a raffica zero copie e controlli per fotogramma di esposizione, guadagno, guadagni di bilanciamento del bianco, conversione del colore, riduzione del rumore, nitidezza e altro ancora. Per i dettagli, guarda la panoramica del 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à di Camera API2. La proprietà android.info.supportedHardwareLevel
che le app possono interrogare 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 sono approssimativamente le stesse capacità 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 funzionalità Camera API2 come i controlli per fotogramma. -
LIMITED
: questi dispositivi supportano alcune funzionalità di Camera API2 (ma non tutte) e devono utilizzare Camera HAL 3.2 o versioni successive. -
FULL
: questi dispositivi supportano tutte le principali funzionalità di Camera API2 e devono utilizzare Camera HAL 3.2 o versioni successive e Android 5.0 o versioni successive. -
LEVEL_3
: questi dispositivi supportano la rielaborazione YUV e l'acquisizione di immagini RAW, insieme a configurazioni del flusso di output aggiuntive. -
EXTERNAL
: questi dispositivi sono simili ai dispositiviLIMITED
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 le webcam USB.
Le singole capacità sono esposte tramite la proprietà android.request.availableCapabilities
nelle interfacce Camera API2. I dispositivi FULL
richiedono le funzionalità MANUAL_SENSOR
e MANUAL_POST_PROCESSING
, tra le altre. La funzionalità RAW
è opzionale anche per i dispositivi FULL
. I 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 della Camera API2 che supporta, sono disponibili come flag di funzionalità seguenti per consentire il filtraggio di Google Play delle 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 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 API2 Camera completa devono comunque superare i test CTS Camera API2. Tuttavia, il dispositivo viene eseguito in modalità Camera API2 LEGACY
(in cui le chiamate Camera API2 sono mappate concettualmente alle chiamate Camera API1), quindi tutti i test CTS Camera API2 relativi a funzionalità o capacità oltre Camera API1 vengono automaticamente ignorati.
Sui dispositivi legacy, i test CTS di Camera API2 eseguiti utilizzano le interfacce e le capacità pubbliche esistenti della Camera API1 senza nuovi requisiti. I bug che vengono esposti (e che causano un errore CTS Camera API2) sono bug già presenti nell'HAL Camera esistente del dispositivo e quindi verrebbero 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 che eseguono 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 del framework della fotocamera, Android 7.0 sposta il servizio della fotocamera fuori dal mediaserver. A partire da Android 8.0, ogni HAL della fotocamera legato viene eseguito in un processo separato dal servizio della 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 videocamera e codificatore video siano attivi nello stesso processo. Quando si utilizza API1 su:
- HAL3, in cui il servizio telecamera utilizza BufferQueue per passare i buffer tra i processi, non è necessario alcun aggiornamento del fornitore .
Figura 1. Fotocamera Android 7.0 e stack multimediale in 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.)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 quei percorsi continuino a funzionare. L'architettura Android 7.0 per API2 su:
- HAL1 non è interessato dallo spostamento del servizio telecamera e non è necessario alcun aggiornamento del fornitore .
- HAL3 è interessato, ma non è necessario alcun aggiornamento del fornitore :
Figura 3. Fotocamera Android 7.0 e stack multimediale in API2 su HAL3
Requisiti addizionali
Le modifiche all'architettura apportate per la protezione avanzata dei supporti e della struttura della fotocamera includono i seguenti requisiti aggiuntivi per i dispositivi.
- Generale. I dispositivi richiedono larghezza di banda aggiuntiva a causa dell'IPC, che può influire sui casi d'uso della fotocamera sensibili al fattore tempo, come la registrazione di video ad alta velocità. I fornitori possono misurare l'impatto effettivo eseguendo
android.hardware.camera2.cts.PerformanceTest
e l'app Google Camera per la registrazione video ad alta velocità a 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 invece dei dati frame YUV reali nei buffer video, l'HAL deve utilizzare
kMetadataBufferTypeNativeHandleSource
come tipo di buffer dei metadati e passareVideoNativeHandleMetadata
nei buffer video. (kMetadataBufferTypeCameraSource
non è più supportato su Android 7.0.) ConVideoNativeHandleMetadata
, i framework della fotocamera e dei 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ò utilizzare gli indirizzi per identificare i buffer perché gli indirizzi possono memorizzare un altro handle del buffer dopo che HAL ha restituito il buffer. È necessario aggiornare l'HAL per utilizzare gli handle del 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 ha restituito 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 politiche di SELinux per cameraserver. Se le politiche di SELinux specifiche del dispositivo concedono i permessi del server multimediale per eseguire la telecamera, è necessario aggiornare le politiche di SELinux per concedere le autorizzazioni appropriate al server della telecamera. Sconsigliamo di replicare le politiche SELinux del mediaserver per 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 tutte le autorizzazioni non necessarie relative alla fotocamera nel mediaserver dovrebbero essere rimosse.
- Separazione tra Camera HAL e cameraserver. Android 8.0 e versioni successive separano inoltre l'HAL della fotocamera legato in un processo diverso dal server della fotocamera. IPC passa attraverso interfacce definite HIDL .
Convalida
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 HAL della fotocamera
Per un elenco dei test disponibili per la valutazione dell'HAL della fotocamera Android, vedere Elenco di controllo dei test HAL della fotocamera .
Android 10
Android 10 introduce i seguenti aggiornamenti.
API della fotocamera
- Miglioramenti multicamera che consentono di utilizzare le telecamere fisiche individualmente o tramite corrispondenti telecamere logiche nascondendo gli ID delle telecamere fisiche. Vedere Supporto multicamera .
- Possibilità di verificare se una particolare configurazione di sessione è supportata senza il sovraccarico di prestazioni della creazione di una nuova sessione. Vedere
CameraDevice
. - Possibilità di recuperare le configurazioni di flusso consigliate per un determinato caso d'uso per rendere il client più efficiente dal punto di vista energetico e performante. Vedere
getRecommendedStreamConfigurationMap
. - Supporto per il formato immagine JPEG di profondità . Per ulteriori dettagli, vedere la specifica Dynamic Depth .
- Supporto per il formato immagine HEIC . Vedere Imaging HEIF .
- Miglioramenti alla privacy. Alcune chiavi sono necessarie affinché il client disponga delle autorizzazioni
CAMERA
prima che possano essere recuperate daCameraCharacteristics
. VederegetKeysNeedingPermission
.
Fotocamera HAL
Le seguenti versioni di Camera HAL sono aggiornate in Android 10.
3.5
ICameraDevice
-
getPhysicalCameraCharacteristics
: le informazioni sulla fotocamera statica per un ID fotocamera fisico che supporta un dispositivo fotocamera logico. Vedere Supporto multicamera . -
isStreamCombinationSupported
: questo metodo supporta un'API pubblica che aiuta i client a interrogare se è supportata una configurazione di sessione. Vedi API per interrogare le 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. Questo aiuta a evitare inutili ritardi nella riconfigurazione della telecamera. Vedere 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 in tutta la pipeline della telecamera, con conseguenti risparmi di memoria potenzialmente significativi.
-
signalStreamFlush
: segnala all'HAL che il servizio telecamera sta per eseguireconfigureStreams_3_5
e che l'HAL deve restituire tutti i buffer dei flussi designati. -
configureStreams_3_5
: simile aICameraDevice3.4.configureStreams
, ma in aggiunta, viene fornito il contatorestreamConfigCounter
per verificare una condizione di competizione tra le chiamateconfigureStreams_3_5
esignalStreamFlush
.
-
Aggiornamenti a ICameraDeviceCallback
:
-
requestStreamBuffers
: richiamata sincrona che l'HAL della telecamera chiama per chiedere i buffer al server della telecamera. VedirequestStreamBuffers
. -
returnStreamBuffers
: richiamata sincrona per l'HAL della telecamera per restituire i buffer di output al server della telecamera. VederereturnStreamBuffers
.
3.4
Le seguenti chiavi vengono aggiunte ai metadati della fotocamera in Android 10.
- Formati 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à dinamiche 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 vengono aggiornate in Android 10.
2.5
- Aggiunge il metodo notificationDeviceStateChange per consentire ai dispositivi di notificare
notifyDeviceStateChange
della videocamera quando le modifiche fisiche, come la piegatura, influiscono sulla videocamera e sul routing.
2.4
- I dispositivi avviati con livello API 29 o superiore DEVONO riportare
true
perisTorchModeSupported
.
Android 9
La versione di Android 9 introduce i seguenti aggiornamenti all'API2 della fotocamera e all'interfaccia HAL.
API della fotocamera
- Introduce l'API multicamera 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ù telecamere su un dispositivo come un'unità logica (telecamera logica). Le richieste di acquisizione possono anche essere inviate a dispositivi con fotocamera individuale racchiusi in una fotocamera logica. Vedere Supporto 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 quando vengono modificati. Questi costi possono essere ridotti se i client trasmettono i loro valori iniziali durante l'inizializzazione della sessione di acquisizione. Vedere Parametri di sessione .
- Aggiunge chiavi dati di stabilizzazione ottica (OIS) per stabilizzazione ed effetti a livello di app. Vedere
STATISTICS_OIS_SAMPLES
. - Aggiunge il supporto flash esterno. Vedere
CONTROL_AE_MODE_ON_EXTERNAL_FLASH
. - Aggiunge un intento di rilevamento del movimento in
CAPTURE_INTENT
. VedereCONTROL_CAPTURE_INTENT_MOTION_TRACKING
. -
LENS_RADIAL_DISTORTION
e aggiungeLENS_DISTORTION
al suo posto. - Aggiunge modalità di correzione della distorsione in
CaptureRequest
. VedereDISTORTION_CORRECTION_MODE
. - Aggiunge il supporto per fotocamere USB/UVC esterne sui dispositivi supportati. Vedere
INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL
.
Fotocamera HAL
3.4
Aggiornamenti a ICameraDeviceSession
-
configureStreams_3_4
: Aggiunge il supporto persessionParameters
e telecamere logiche. -
processCaptureRequest_3_4
: Aggiunge il supporto per l'inclusione degli ID delle telecamere fisiche nella struttura del flusso.
Aggiornamenti a ICameraDeviceCallback
-
processCaptureResult_3_4
: Aggiunge i metadati della fotocamera fisica nei risultati di acquisizione.
3.3
Le seguenti chiavi vengono aggiunte 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 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 uscite, come l'anteprima e la codifica video, riducendo il consumo di energia e memoria. Per supportare questa funzione, i produttori di dispositivi devono garantire che le implementazioni HAL e gralloc HAL della fotocamera 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 telecamera trasmette i flag di utilizzo del consumatore alla telecamera HAL e gralloc HAL; devono allocare i giusti tipi di buffer oppure la fotocamera HAL deve restituire un errore che indica che questa combinazione di consumer non è supportata.
Per ulteriori dettagli, vedere la documentazione per sviluppatori di enableSurfaceSharing
.
API di sistema per modalità fotocamera personalizzate
L'API della telecamera pubblica definisce due modalità operative: registrazione ad alta velocità normale e vincolata. 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. Sotto il cofano, la modalità è solo un numero intero passato a configure_streams
. Vedere: 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 proprio HAL, attivato da questo numero intero passato all'HAL su configure_streams, quindi fare in modo che l'app della 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 lato framework. Le applicazioni che vogliono trarne vantaggio devono aggiungere un listener a quella richiamata 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 stabili definite HIDL. 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 i metadati statici
ANDROID_SENSOR_OPAQUE_RAW_SIZE
come obbligatori se il formatoRAW_OPAQUE
è supportato. - Aggiungi i metadati statici
ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
come obbligatori se è supportato qualsiasi formato RAW. - Cambia il campo
camera3_stream_t data_space
a una definizione più flessibile, utilizzando la definizione della versione 0 della codifica dello spazio dati. - Aggiunte ai 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 con capacità estese:
- Aggiornamenti API di rielaborazione OPAQUE e YUV.
- Supporto di base per i buffer di output di profondità.
- Aggiunta del campo
data_space
acamera3_stream_t
. - Aggiunta del campo di rotazione a
camera3_stream_t
. - Aggiunta della modalità operativa di configurazione del flusso della telecamera3 a
camera3_stream_configuration_t
.
3.2
Revisione minore dell'HAL con capacità estese:
- Deprecato
get_metadata_vendor_tag_ops
. Usa inveceget_vendor_tag_ops
incamera_common.h
. - Depreca
register_stream_buffers
. Tutti i buffer gralloc forniti da framework a HAL inprocess_capture_request
possono essere nuovi in qualsiasi momento. - Aggiungi il supporto per i risultati parziali.
process_capture_result
può essere chiamato più volte con un sottoinsieme dei risultati disponibili prima che il risultato completo sia disponibile. - Aggiungi modello manuale a
camera3_request_template
. Le applicazioni possono utilizzare questo modello per controllare direttamente le impostazioni di acquisizione. - Rielabora le specifiche del flusso di input e bidirezionale.
- Modificare il percorso di ritorno del buffer di input. Il buffer viene restituito in
process_capture_result
invece diprocess_capture_request
.
3.1
Revisione minore dell'HAL con capacità estese:
-
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à estese:
- Importante modifica della versione poiché l'ABI è completamente diverso. Nessuna modifica alle capacità hardware o al modello operativo richiesti dalla 2.0.
- Interfacce di richiesta di input e coda di flusso rielaborate: chiamate Framework in HAL con la richiesta successiva e buffer di flusso già rimossi dalla coda. È incluso il supporto del framework di sincronizzazione, necessario per implementazioni efficienti.
- Attivatori spostati nelle richieste, la maggior parte delle notifiche nei risultati.
- Consolidato tutti i callback nel framework in un'unica struttura e tutti i metodi di installazione in un'unica chiamata
initialize()
. - Trasformata 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 più vecchi/limitati.
2.0
Versione iniziale di HAL con capacità 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 nessuna nuova funzionalità come il controllo dell'acquisizione manuale, l'acquisizione RAW Bayer, la rielaborazione dei dati RAW, ecc.
1.0
Fotocamera Android iniziale HAL (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, 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 fotocamera aggiunge le seguenti modifiche API:
- Supporto modalità torcia. Il framework può attivare la modalità torcia per qualsiasi dispositivo fotocamera dotato di un'unità flash, senza aprire un dispositivo fotocamera. Il dispositivo fotocamera ha una priorità di accesso all'unità flash maggiore rispetto al modulo fotocamera; aprendo un dispositivo fotocamera si spegne la torcia se fosse stata abilitata tramite l'interfaccia del modulo. Quando si verificano conflitti di risorse, ad esempio
open()
viene chiamato per aprire un dispositivo fotocamera, il modulo HAL della fotocamera deve notificare al framework tramite il callback dello stato della modalità torcia che la modalità torcia è stata disattivata. - Supporto per fotocamera esterna (ad esempio, fotocamera hot plug USB). Gli aggiornamenti API specificano che le informazioni statiche della telecamera sono disponibili solo quando la telecamera è collegata e pronta per l'uso per telecamere 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 sulle chiamate di modifica dello stato del dispositivo per gestire l'elenco delle telecamere esterne disponibile. - Suggerimenti per l'arbitrato della telecamera. Aggiunge il supporto per indicare esplicitamente il numero di dispositivi della fotocamera che possono essere aperti e utilizzati contemporaneamente. Per specificare combinazioni valide di dispositivi, i campi
resource_cost
e dispositivi_inconflicting_devices
devono sempre essere impostati nella strutturacamera_info
restituita dalla chiamataget_camera_info
. - Metodo di inizializzazione del modulo. Chiamato dal servizio telecamera 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 del dispositivo HAL della fotocamera legacy aperta. Il framework può usarlo per aprire il dispositivo della fotocamera come dispositivo HAL versione inferiore del dispositivo 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 fotocamera aggiunge il supporto del tag del fornitore dal modulo e depreca i vecchi vendor_tag_query_ops
che in precedenza erano accessibili solo con un dispositivo aperto.
2.1
Questa versione del modulo telecamera aggiunge il supporto per i callback asincroni al framework dal modulo HAL della telecamera, che viene utilizzato per notificare al framework le modifiche allo stato del modulo telecamera. 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 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.