相機版本支持

本頁詳細介紹了相機 HAL、API 和相關相容性測試套件 (CTS)測試中的版本差異。它還涵蓋了為強化和保護 Android 7.0 中相機框架而進行的多項架構變更、Android 8.0 中向 Treble 的切換,以及供應商在相機實作中支援這些變更必須進行的更新。

術語

本頁使用以下術語:

相機API1
Android 4.4 及更低版本裝置上的應用程式級相機框架,透過android.hardware.Camera類別公開。
相機API2
Android 5.0 及更高版本裝置上的應用程式級相機框架,透過android.hardware.camera2套件公開。
相機哈爾
由SoC供應商實現的相機模組層。應用程式級公共框架建構在相機 HAL 之上。
相機HAL3.1
隨 Android 4.4 一起發布的相機設備 HAL 版本。
相機HAL3.2
隨Android 5.0一起發布的相機設備HAL版本。
相機 API1 CTS
在相機 API1 之上運行的相機 CTS 測試集。
相機 API2 CTS
在相機 API2 之上運行的附加相機 CTS 測試集。
高音
透過新的供應商介面將供應商實現(由晶片製造商編寫的特定於設備的較低級別軟體)與 Android 作業系統框架分開。
HIDL
HAL 介面定義語言隨 Treble 一起引入,用於指定 HAL 與其使用者之間的介面。
虛擬交通系統
與 Treble 一起推出的供應商測試套件

相機API

Android 包含以下相機 API。

相機API1

Android 5.0 棄用了 Camera API1,隨著新平台開發的重點是 Camera API2,該 API 繼續被淘汰。不過,淘汰期將會很長,Android 版本將在一段時間內繼續支援 Camera API1 應用程式。具體來說,我們將繼續支持:

  • 應用程式的相機 API1 介面。基於相機 API1 建置的相機應用程式應該像在運行較低 Android 版本的裝置上一樣運作。
  • 相機 HAL 版本。包括對相機 HAL1.0 的支援。

相機API2

相機 API2 框架向應用程式公開了較低的相機控制,包括高效的零複製突發/串流媒體串流以及曝光、增益、白平衡增益、顏色轉換、去噪、銳化等的每幀控制。有關詳細信息,請觀看Google I/O 影片概述

Android 5.0以上版本包含Camera API2;但是,運行 Android 5.0 及更高版本的裝置可能不支援所有相機 API2 功能。應用程式可以透過相機 API2 介面查詢的android.info.supportedHardwareLevel屬性報告以下支援等級之一:

  • LEGACY :這些裝置透過相機 API2 介面向應用程式公開的功能與透過相機 API1 介面向應用程式公開的功能大致相同。遺留框架程式碼從概念上將相機 API2 呼叫轉換為相機 API1 呼叫;舊設備不支援相機 API2 功能,例如每幀控制。
  • LIMITED :這些裝置支援部分 Camera API2 功能(但不是全部),必須使用 Camera HAL 3.2 或更高版本。
  • FULL :這些裝置支援 Camera API2 的所有主要功能,必須使用 Camera HAL 3.2 或更高版本以及 Android 5.0 或更高版本。
  • LEVEL_3 :這些裝置支援 YUV 重新處理和 RAW 影像捕獲,以及其他輸出流配置。
  • EXTERNAL :這些設備與LIMITED設備類似,但有一些例外;例如,某些感測器或鏡頭資訊可能不會報告或幀速率不太穩定。此等級用於外部攝影機,例如 USB 網路攝影機。

各個功能透過 Camera API2 介面中的android.request.availableCapabilities屬性公開。 FULL設備需要MANUAL_SENSORMANUAL_POST_PROCESSING功能等。即使對於FULL設備, RAW功能也是可選的。 LIMITED設備可以宣傳這些功能的任何子集,包括其中任何一個。但是,必須始終定義BACKWARD_COMPATIBLE功能。

裝置支援的硬體等級及其支援的特定 Camera API2 功能可作為以下功能標誌提供,以允許 Google Play 過濾 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

CTS要求

運行 Android 5.0 及更高版本的裝置必須通過 Camera API1 CTS、Camera API2 CTS 和 CTS Verifier 相機測試。

不具備 Camera HAL3.2 實作且無法支援完整 Camera API2 介面的裝置仍必須通過 Camera API2 CTS 測試。但是,設備在相機 API2 LEGACY模式下運作(其中相機 API2 呼叫在概念上對應到相機 API1 呼叫),因此與相機 API1 以外的特性或功能相關的任何相機 API2 CTS 測試都會自動跳過。

在舊設備上,運行的相機 API2 CTS 測試使用現有的公共相機 API1 介面和功能,沒有新的要求。暴露的錯誤(導致相機 API2 CTS 失敗)是裝置現有相機 HAL 中已經存在的錯誤,因此可以被現有相機 API1 應用程式發現。我們預計不會出現許多此類性質的錯誤(但是,必須修復任何此類錯誤才能通過 Camera API2 CTS 測試)。

VTS 要求

運行 Android 8.0 及更高版本且具有綁定化 HAL 實現的裝置必須通過相機VTS 測試

相機框架加固

為了強化媒體和相機框架的安全性,Android 7.0 將相機服務移出媒體伺服器。從 Android 8.0 開始,每個綁定化的相機 HAL 在與相機服務分開的進程中運作。供應商可能需要根據所使用的 API 和 HAL 版本對相機 HAL 進行更改。以下部分詳細介紹了 HAL1 和 HAL3 的 AP1 和 AP2 架構變更以及一般要求。

API1 的架構更改

API1 視訊錄製可能假設相機和視訊編碼器位於同一進程中。當使用 API1 時:

  • HAL3,其中相機服務使用 BufferQueue 在進程之間傳遞緩衝區,無需供應商更新

    HAL3 上 API1 中的 Android 7.0 相機和媒體堆疊

    圖 1. HAL3 上 API1 中的 Android 7.0 相機與媒體堆疊

  • HAL1,支援在視訊緩衝區中傳遞元數據,供應商必須更新 HAL 以使用kMetadataBufferTypeNativeHandleSource (Android 7.0 不再支援kMetadataBufferTypeCameraSource 。)

    HAL1 上 API1 中的 Android 7.0 相機和媒體堆疊

    圖 2. HAL1 上 API1 中的 Android 7.0 相機與媒體堆疊

API2 的架構更改

對於 HAL1 或 HAL3 上的 API2,BufferQueue 傳遞緩衝區,以便這些路徑繼續運作。 API2 的 Android 7.0 架構:

  • HAL1 不受相機服務移動的影響,且不需要供應商更新
  • HAL3受到影響,但不需要供應商更新

    HAL3 上 API2 中的 Android 7.0 相機和媒體堆疊

    圖 3. HAL3 上 API2 中的 Android 7.0 相機與媒體堆疊

其他要求

為強化媒體和相機框架安全性而進行的架構更改包括以下附加設備要求。

  • 一般的。由於 IPC,設備需要額外的頻寬,這可能會影響對時間敏感的相機用例,例如高速視訊錄製。供應商可以透過運行android.hardware.camera2.cts.PerformanceTest和 Google Camera 應用程式進行 120/240 FPS 高速錄影來測量實際影響。設備還需要少量額外的 RAM 來建立新進程。
  • 在視訊緩衝區中傳遞元資料僅限 HAL1 )。如果 HAL1 在視訊緩衝區中儲存元資料而不是真實的 YUV 幀數據,則 HAL 必須使用kMetadataBufferTypeNativeHandleSource作為元資料緩衝區類型,並在視訊緩衝區中傳遞VideoNativeHandleMetadata 。 ( Android 7.0 不再支援kMetadataBufferTypeCameraSource 。)使用VideoNativeHandleMetadata ,相機和媒體框架能夠透過正確序列化和反序列化本機句柄在進程之間傳遞視訊緩衝區。
  • 緩衝區句柄位址並不總是儲存相同的緩衝區僅限 HAL3 )。對於每個捕獲請求,HAL3 都會取得緩衝區句柄的位址。 HAL 無法使用位址來識別緩衝區,因為在 HAL 傳回緩衝區後,位址可能會儲存另一個緩衝區句柄。您必須更新 HAL 以使用緩衝區句柄來識別緩衝區。例如,HAL接收到緩衝區句柄位址A,該位址儲存緩衝區句柄A。HAL回傳緩衝區句柄A後,下次HAL接收到緩衝區句柄位址A時,緩衝區句柄位址A可能儲存緩衝區句柄B 。
  • 更新相機伺服器的 SELinux 策略。如果裝置特定的 SELinux 策略授予 mediaserver 運行攝影機的權限,您必須更新 SELinux 策略以授予攝影機伺服器適當的權限。我們不鼓勵為相機伺服器複製媒體伺服器的 SELinux 策略(因為媒體伺服器和相機伺服器通常需要係統中的不同資源)。 Cameraserver 應僅具有執行相機功能所需的權限,並且應刪除 mediaserver 中任何不必要的與相機相關的權限。
  • Camera HAL 和cameraserver 分開。 Android 8.0 及更高版本還在與相機伺服器不同的進程中分離了綁定化相機 HAL。 IPC 透過HIDL 定義的介面。

驗證

對於包含相機並運行 Android 7.0 的所有設備,請透過運行 Android 7.0 CTS 來驗證實作。儘管 Android 7.0 不包含用於驗證相機服務變更的新 CTS 測試,但如果您尚未進行上述更新,現有 CTS 測試將會失敗。

對於包含攝影機並運行 Android 8.0 及更高版本的所有設備,請透過運行 VTS 來驗證供應商實施。

相機 HAL 版本歷史

有關可用於評估 Android 相機 HAL 的測試列表,請參閱相機 HAL 測試清單

安卓10

Android 10 引入了以下更新。

相機介面

相機哈爾

Android 10 中更新了以下相機 HAL 版本。

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics :支援邏輯相機設備的實體相機 ID 的靜態相機資訊。請參閱多攝影機支援
  • isStreamCombinationSupported :此方法支援公共 API,可協助用戶端查詢是否支援會話配置。請參閱查詢流程組合的 API

ICameraDeviceSession

  • isReconfigurationNeeded :告訴相機框架是否需要對可能的新會話參數值進行完整的流重新配置的方法。這有助於避免不必要的相機重新配置延遲。請參閱會話重新配置查詢
  • HAL 緩衝區管理 API :這些 API 允許相機 HAL 僅在需要時才從相機框架請求緩衝區,而不​​是在整個相機管道中將每個捕獲請求與其關聯的緩衝區耦合起來,從而可能節省大量記憶體。
    • signalStreamFlush :向 HAL 發出訊號,指示相機服務即將執行configureStreams_3_5 ,且 HAL 必須傳回指定流的所有緩衝區。
    • configureStreams_3_5 :與ICameraDevice3.4.configureStreams類似,但此外,也提供了streamConfigCounter計數器來檢查configureStreams_3_5signalStreamFlush呼叫之間的競爭條件。

ICameraDeviceCallback的更新:

  • requestStreamBuffers :相機 HAL 呼叫的同步回調,向相機伺服器請求緩衝區。請參閱requestStreamBuffers
  • returnStreamBuffers :相機 HAL 的同步回調,用於將輸出緩衝區返回到相機伺服器。請參閱returnStreamBuffers

3.4

以下按鍵已新增至 Android 10 中的相機元資料。

  • 圖片格式
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • 相機元資料標籤
    • 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
  • 能力
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
  • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT鍵的值
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • 可用的動態深度流配置
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • 可用的 HEIC 流配置
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

網路攝影機模組

Android 10 中更新了以下相機模組版本。

2.5

  • 設備新增notifyDeviceStateChange方法,當折疊等物理變化影響攝影機和路由時,通知攝影機HAL。

2.4

  • 使用 API 等級 29 或更高等級啟動的裝置必須針對isTorchModeSupported報告true

安卓9

Android 9 版本引入了相機 API2 和 HAL 介面的以下更新。

相機介面

  • 引入多攝影機 API,更好地支援多個攝影機朝同一方向的設備,實現散景和無縫變焦等功能。這允許應用程式將設備上的多個攝影機視為一個邏輯單元(邏輯攝影機)。捕獲請求也可以發送到一台邏輯攝影機所包含的各個攝影機設備。請參閱多攝影機支援
  • 引入會話參數。會話參數是可用擷取參數的子集,修改後可能會導致嚴重的處理延遲。如果用戶端在捕獲會話初始化期間傳遞其初始值,則可以減輕這些成本。請參閱會話參數
  • 增加光學穩定 (OIS) 資料鍵,以實現應用程式級穩定和效果。請參閱STATISTICS_OIS_SAMPLES
  • 新增外部快閃記憶體支援。請參閱CONTROL_AE_MODE_ON_EXTERNAL_FLASH
  • CAPTURE_INTENT中加入運動追蹤意圖。請參閱CONTROL_CAPTURE_INTENT_MOTION_TRACKING
  • 棄用LENS_RADIAL_DISTORTION並在其位置加入LENS_DISTORTION
  • CaptureRequest中加入失真校正模式。請參閱DISTORTION_CORRECTION_MODE
  • 在受支援的裝置上新增了對外部 USB/UVC 攝影機的支援。請參閱INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL

相機哈爾

3.4

ICameraDeviceSession更新

ICameraDeviceCallback更新

3.3

以下按鍵已新增至 Android 9 中的相機元資料。

  • 能力
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • 相機元資料標籤
    • 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

安卓8.0

Android 8.0 版本引進了 Treble。對於 Treble,供應商相機 HAL 實作必須進行綁定。 Android 8.0 還包含對相機服務的以下關鍵增強功能:

  • 共享表面:啟用多個表面共享相同的OutputConfiguration
  • 用於自訂相機模式的系統 API
  • onCaptureQueueEmpty

有關這些功能的更多信息,請參閱以下部分。

共享表面

此功能僅允許一組緩衝區驅動兩個輸出,例如預覽和視訊編碼,從而降低功耗和記憶體消耗。為了支援這項功能,設備製造商需要確保其相機HAL 和gralloc HAL 實作可以創建供多個不同用戶(例如硬體組合器/GPU 和視訊編碼器)使用的gralloc 緩衝區,而不​​僅僅是一個使用者。相機服務將消費者使用標誌傳遞給相機HAL和gralloc HAL;他們需要分配正確類型的緩衝區,或者相機 HAL 需要傳回不支援這種消費者組合的錯誤。

有關更多詳細信息,請參閱enableSurfaceSharing開發人員文件。

用於自訂相機模式的系統 API

公共相機API定義了兩種操作模式:正常和限制高速記錄。它們有相當不同的語義;例如,高速模式僅限於同時最多兩個特定輸出。各個 OEM 廠商都表示有興趣為特定於硬體的功能定義其他自訂模式。在底層,模式只是傳遞給configure_streams一個整數。請參閱: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams

此功能包括 OEM 相機應用程式可用於啟用自訂模式的系統 API 呼叫。這些模式必須從整數值 0x8000 開始,以避免與將來新增至公共 API 的模式發生衝突。

為了支援此功能,OEM 只需要在其 HAL 中新增模式(由傳遞到configure_streams 上的 HAL 的這個整數觸發),然後讓其自訂相機應用程式使用系統 API。

方法名稱為android.hardware.camera2.CameraDevice#createCustomCaptureSession 。請參閱: frameworks/base/core/java/android/hardware/camera2/CameraDevice

onCaptureQueueEmpty

此 API 的目的是透過使請求佇列盡可能為空來減少縮放等控制變更的延遲。 onCaptureQueueEmpty不需要 HAL 工作;它純粹是框架端的添加。想要利用它的應用程式需要向該回調添加一個監聽器並做出適當的回應。通常,這是透過向相機設備發送另一個捕獲請求來實現的。

攝影機 HIDL 介面

Camera HIDL 介面是對 Camera HAL 介面的徹底改造,它使用穩定的 HIDL 定義的 API。最新舊版 3.4 和 2.4(針對相機模組)中引入的所有功能和相機功能也是 HIDL 定義的一部分。

3.4

對支援的元資料進行了少量添加,並對 data_space 支援進行了更改:

  • 如果支援RAW_OPAQUE格式,則必須新增ANDROID_SENSOR_OPAQUE_RAW_SIZE靜態元資料。
  • 如果支援任何 RAW 格式,則必須新增ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE靜態元資料。
  • camera3_stream_t data_space欄位切換為更靈活的定義,使用資料空間編碼的版本0定義。
  • 可用於 HALv3.2 或更高版本的常規元資料新增:
    • 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

擴充功能 HAL 的小修改:

  • OPAQUE 和 YUV 重新處理 API 更新。
  • 對深度輸出緩衝區的基本支援。
  • data_space欄位新增至camera3_stream_t
  • camera3_stream_t中新增旋轉欄位。
  • camera3_stream_configuration_t中新增了camera3流配置操作模式。

3.2

擴充功能 HAL 的小修改:

  • 棄用get_metadata_vendor_tag_ops 。請改用camera_common.h中的get_vendor_tag_ops
  • 棄用register_stream_buffersprocess_capture_request中框架向 HAL 提供的所有 gralloc 緩衝區在任何時候都可能是新的。
  • 新增部分結果支援。在完整結果可用之前,可以使用可用結果的子集多次呼叫process_capture_result
  • 將手動模板新增至camera3_request_template 。應用程式可以使用此模板直接控制捕獲設定。
  • 重新設計雙向和輸入流規格。
  • 變更輸入緩衝區返迴路徑。緩衝區在process_capture_result而不是process_capture_request中傳回。

3.1

擴充功能 HAL 的小修改:

  • configure_streams將消費者使用標誌傳遞給 HAL。
  • 刷新呼叫以盡快刪除所有正在進行的請求/緩衝區。

3.0

擴充功能 HAL 的第一次修訂:

  • 主要版本更改,因為 ABI 完全不同。與 2.0 相比,所需的硬體功能或操作模型沒有變化。
  • 重新設計的輸入請求和流佇列介面:框架呼叫 HAL,下一個請求和流緩衝區已出隊。包括同步框架支持,這是高效實施所必需的。
  • 將觸發器移至請求中,將大多數通知移至結果中。
  • 將框架中的所有回呼合併到一個結構中,並將所有設定方法合併到一個initialize()呼叫中。
  • 將流配置放入單一呼叫中以簡化流管理。雙向流取代了STREAM_FROM_STREAM構造。
  • 較舊/有限硬體設備的有限模式語義。

2.0

擴充功能 HAL 的初始版本 (Android 4.2) [camera2.h]:

  • 足以實現現有的android.hardware.Camera API。
  • 允許相機服務層中的 ZSL 佇列。
  • 未測試任何新功能,例如手動擷取控制、Bayer RAW 擷取、RAW 資料的重新處理等。

1.0

初始Android相機HAL(Android 4.0)[camera.h]:

  • 由C++ CameraHardwareInterface抽象層轉換而來。
  • 支援android.hardware.Camera API。

相機模組版本歷史

本部分包含基於camera_module_t.common.module_api_version的相機硬體模組的模組版本資訊。兩個最高有效的十六進位數字代表主要版本,兩個最低有效的十六進位數字代表次要版本。

2.4

此相機模組版本新增了以下 API 變更:

  1. 火炬模式支援。該框架可以為任何具有閃光燈單元的相機設備開啟手電筒模式,而無需開啟相機設備。攝影機設備對閃光燈單元的存取優先順序高於攝影機模組;如果已透過模組介面啟用手電筒,則開啟攝影機設備會關閉手電筒。當出現任何資源衝突時,例如呼叫open()開啟相機設備時,相機 HAL 模組必須透過手電筒模式狀態回調通知框架手電筒模式已關閉。
  2. 支援外部攝影機(例如 USB 熱插拔攝影機)。 API 更新指定相機靜態資訊僅在相機已連接並準備用於外部熱插拔相機時才可用。當相機狀態不是CAMERA_DEVICE_STATUS_PRESENT時,取得靜態資訊的呼叫無效。此框架僅依靠裝置狀態變更回呼來管理可用的外部攝影機清單。
  3. 相機仲裁提示。增加了對明確指示可以同時開啟和使用的相機設備數量的支援。若要指定有效的裝置組合,應始終在get_camera_info呼叫傳回的camera_info結構中設定resource_costconflicting_devices欄位。
  4. 模組初始化方法。加載 HAL 模組後由相機服務調用,以允許一次性初始化 HAL。它在調用任何其他模組方法之前調用。

2.3

此相機模組版本新增了開放傳統相機 HAL 裝置支援。如果相同裝置可以支援多個裝置 API 版本,框架可以使用它來將相機裝置開啟為較低裝置 HAL 版本的 HAL 裝置。標準硬體模組開啟呼叫( common.methods->open )繼續開啟具有最新支援版本的相機設備,這也是在camera_info_t.device_version中列出的版本。

2.2

此相機模組版本添加了模組的供應商標籤支持,並棄用了以前只能在設備打開時才能訪問的舊vendor_tag_query_ops

2.1

此相機模組版本添加了對從相機 HAL 模組到框架的非同步回調的支持,該回調用於通知框架有關相機模組狀態的變更。提供有效set_callbacks()方法的模組必須至少報告此版本號。

2.0

報告此版本號的相機模組實作相機模組 HAL 介面的第二版本。透過此模組可開啟的相機設備可能支援相機設備 HAL 介面的版本 1.0 或版本 2.0。 camera_info的device_version欄位始終有效;如果device_version欄位為 2.0 或更高版本,則camera_infostatic_camera_characteristics欄位有效。

1.0

報告這些版本號的相機模組實現了初始相機模組 HAL 介面。透過此模組可開啟的所有相機設備僅支援相機設備 HAL 的版本 1。 camera_infodevice_versionstatic_camera_characteristics欄位無效。此模組及其裝置僅支援android.hardware.Camera API。