本頁面由 Cloud Translation API 翻譯而成。

相機版本支持

本頁面詳細介紹了相機 HAL、API 和相關兼容性測試套件 (CTS)測試中的版本差異。它還涵蓋了為加強和保護 Android 7.0 中的攝像頭框架而進行的幾項架構更改、在 Android 8.0 中切換到 Treble 以及供應商必須進行的更新以支持其攝像頭實現中的這些更改。

術語

本頁使用以下術語：

相機 API1: Android 4.4 及更低設備上的應用級相機框架，通過android.hardware.Camera類公開。
相機 API2: Android 5.0 及更高版本設備上的應用級相機框架，通過android.hardware.camera2包公開。
相機 HAL: SoC 供應商實現的相機模塊層。應用級公共框架構建在相機 HAL 之上。
相機 HAL3.1: 隨 Android 4.4 發布的相機設備 HAL 版本。
相機 HAL3.2: 隨 Android 5.0 發布的相機設備 HAL 版本。
相機 API1 CTS: 在 Camera API1 之上運行的一組相機 CTS 測試。
相機 API2 CTS: 在相機 API2 之上運行的附加相機 CTS 測試集。
高音: 通過新的供應商接口將供應商實現（由矽製造商編寫的特定於設備的低級軟件）與 Android OS 框架分離。
HIDL: Treble 引入的HAL 接口定義語言，用於指定 HAL 與其用戶之間的接口。
VTS: 與 Treble 一起引入的供應商測試套件。

相機 API

Android 包含以下相機 API。

相機 API1

Android 5.0 棄用了 Camera API1，隨著新平台開發的重點放在 Camera API2 上，該 API1 將繼續被淘汰。但是，淘汰期會很長，Android 版本將在一段時間內繼續支持 Camera API1 應用程序。具體來說，繼續支持：

應用程序的相機 API1 接口。基於 Camera API1 構建的相機應用程序應該可以像在運行較低 Android 版本的設備上一樣工作。
相機 HAL 版本。包括對相機 HAL1.0 的支持。

相機 API2

Camera API2 框架向應用程序公開了較低級別的相機控制，包括有效的零拷貝突發/流式傳輸和曝光、增益、白平衡增益、顏色轉換、去噪、銳化等的每幀控制。有關詳細信息，請觀看Google I/O 視頻概述。

Android 5.0 及更高版本包括 Camera API2；但是，運行 Android 5.0 及更高版本的設備可能不支持所有 Camera API2 功能。應用程序可以通過 Camera API2 接口查詢的android.info.supportedHardwareLevel屬性報告以下支持級別之一：

LEGACY ：這些設備通過 Camera API2 接口向應用程序公開功能，這些功能與通過 Camera API1 接口向應用程序公開的功能大致相同。遺留框架代碼在概念上將 Camera API2 調用轉換為 Camera 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 網絡攝像頭。

各個功能通過相機 API2 接口中的android.request.availableCapabilities屬性公開。 FULL設備需要MANUAL_SENSOR和MANUAL_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 測試。但是，該設備在 Camera API2 LEGACY模式下運行（在這種模式下，Camera API2 調用在概念上映射到 Camera API1 調用），因此任何與 Camera API1 以外的特性或功能相關的 Camera API2 CTS 測試都會自動跳過。

在舊設備上，運行的 Camera API2 CTS 測試使用現有的公共 Camera API1 接口和功能，沒有新要求。暴露的錯誤（並導致 Camera API2 CTS 失敗）是設備現有 Camera HAL 中已經存在的錯誤，因此現有的 Camera API1 應用程序會發現這些錯誤。我們預計這種性質的錯誤不會很多（但是，必須修復任何此類錯誤才能通過 Camera API2 CTS 測試）。

VTS 要求

運行帶有綁定 HAL 實現的 Android 8.0 及更高版本的設備必須通過相機VTS 測試。

相機框架加固

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

API1 的架構更改

API1 視頻錄製可能假設攝像頭和視頻編碼器處於同一進程中。使用 API1 時：

HAL3，其中相機服務使用 BufferQueue 在進程之間傳遞緩衝區，無需更新供應商。
圖 1. HAL3 上 API1 中的 Android 7.0 相機和媒體堆棧
HAL1 支持在視頻緩衝區中傳遞元數據，供應商必須更新 HAL 以使用kMetadataBufferTypeNativeHandleSource 。 （Android 7.0 不再支持kMetadataBufferTypeCameraSource 。）
圖 2. HAL1 上 API1 中的 Android 7.0 相機和媒體堆棧

API2 的架構更改

對於 HAL1 或 HAL3 上的 API2，BufferQueue 傳遞緩衝區，因此這些路徑繼續工作。 API2 的 Android 7.0 架構：

HAL1 不受 cameraservice 移動的影響，也不需要更新供應商。
HAL3受到影響，但無需更新供應商：
圖 3. HAL3 上 API2 中的 Android 7.0 相機和媒體堆棧

其他要求

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

一般的。由於 IPC，設備需要額外的帶寬，這可能會影響對時間敏感的相機用例，例如高速視頻錄製。供應商可以通過運行android.hardware.camera2.cts.PerformanceTest和用於 120/240 FPS 高速視頻錄製的 Google 相機應用來衡量實際影響。設備還需要少量額外的 RAM 來創建新進程。
在視頻緩衝區中傳遞元數據（僅限 HAL1 ）。如果 HAL1 在視頻緩衝區中存儲元數據而不是真實的 YUV 幀數據，則 HAL 必須使用kMetadataBufferTypeNativeHandleSource作為元數據緩衝區類型，並在視頻緩衝區中傳遞VideoNativeHandleMetadata 。（Android 7.0 不再支持kMetadataBufferTypeCameraSource 。）使用VideoNativeHandleMetadata ，相機和媒體框架能夠通過正確序列化和反序列化原生句柄在進程之間傳遞視頻緩衝區。
緩衝區句柄地址並不總是存儲相同的緩衝區（僅限 HAL3 ）。對於每個捕獲請求，HAL3 都會獲取緩衝區句柄的地址。 HAL 不能使用地址來標識緩衝區，因為在 HAL 返回緩衝區後，地址可能會存儲另一個緩衝區句柄。您必須更新 HAL 以使用緩衝區句柄來識別緩衝區。例如，HAL 收到一個緩衝區句柄地址 A，其中存儲了緩衝區句柄 A。HAL 返回緩衝區句柄 A 後，緩衝區句柄地址 A 可能會在 HAL 下次收到時存儲緩衝區句柄 B。
更新 cameraserver 的 SELinux 策略。如果特定於設備的 SELinux 策略授予媒體服務器運行攝像機的權限，您必須更新 SELinux 策略以授予攝像機服務器適當的權限。我們不鼓勵為 cameraserver 複製 mediaserver 的 SELinux 策略（因為 mediaserver 和 cameraserver 通常需要係統中的不同資源）。 Cameraserver 應僅具有執行相機功能所需的權限，並且應刪除 mediaserver 中任何不必要的與相機相關的權限。
Camera HAL 和 cameraserver 之間的分離。 Android 8.0 及更高版本還在與 cameraserver 不同的進程中分離了綁定的 Camera 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 引入了以下更新。

相機 API

多攝像頭改進，允許單獨使用物理攝像頭或通過隱藏物理攝像頭 ID 通過相應的邏輯攝像頭使用。請參閱多相機支持。
能夠檢查是否支持特定會話配置，而無需創建新會話的性能開銷。請參閱CameraDevice 。
能夠為給定的用例檢索推薦的流配置，以提高客戶端的電源效率和性能。請參閱getRecommendedStreamConfigurationMap 。
支持深度JPEG圖像格式。有關詳細信息，請參閱動態深度規範。
支持HEIC 圖像格式。請參閱HEIF 成像。
隱私改進。客戶端需要某些密鑰具有CAMERA權限，然後才能從CameraCharacteristics檢索它們。請參閱getKeysNeedingPermission 。

相機 HAL

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_5和signalStreamFlush調用之間的競爭條件。

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

引入多攝像頭 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 。

相機 HAL

3.4

ICameraDeviceSession的更新

configureStreams_3_4 ：添加對sessionParameters和邏輯攝像機的支持。
processCaptureRequest_3_4 ：添加了對在流結構中包含物理相機 ID 的支持。

ICameraDeviceCallback的更新

processCaptureResult_3_4 ：在捕獲結果中添加物理相機元數據。

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，供應商的 Camera 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 。

此功能包括一個系統 API 調用，OEM 相機應用可以使用它來啟用自定義模式。這些模式必須從整數值 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 接口是對使用穩定的 HIDL 定義的 API 的 Camera HAL 接口的徹底改造。在最新的舊版本 3.4 和 2.4（用於攝像頭模塊）中引入的所有特性和攝像頭功能也是 HIDL 定義的一部分。

3.4

對受支持的元數據的少量添加和對 data_space 支持的更改：

如果支持RAW_OPAQUE格式，則強制添加ANDROID_SENSOR_OPAQUE_RAW_SIZE靜態元數據。
如果支持任何 RAW 格式，則強制添加ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE靜態元數據。
使用數據空間編碼的版本 0 定義將camera3_stream_t data_space字段切換為更靈活的定義。
可用於 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_stream_configuration_t流配置操作模式。

3.2

擴展能力 HAL 的小修訂：

棄用get_metadata_vendor_tag_ops 。請改用get_vendor_tag_ops中的camera_common.h 。
棄用register_stream_buffers 。框架在process_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的 Camera 硬件模塊的模塊版本信息。兩個最重要的十六進制數字代表主要版本，兩個最不重要的代表次要版本。

2.4

此相機模塊版本增加了以下 API 更改：

手電筒模式支持。該框架可以為任何具有閃光燈的相機設備打開手電筒模式，而無需打開相機設備。攝像頭設備訪問閃光燈的優先級高於攝像頭模塊；如果已通過模塊接口啟用，打開相機設備會關閉手電筒。當發生資源衝突時，例如調用open()打開相機設備，相機 HAL 模塊必須通過手電筒模式狀態回調通知框架手電筒模式已關閉。
外部攝像頭（例如，USB 熱插拔攝像頭）支持。 API 更新指定相機靜態信息僅在相機連接並準備用於外部熱插拔相機時可用。當相機狀態不是CAMERA_DEVICE_STATUS_PRESENT時，獲取靜態信息的調用是無效調用。該框架僅依靠設備狀態更改回調來管理可用的外部攝像頭列表。
相機仲裁提示。添加了對明確指示可以同時打開和使用的相機設備數量的支持。要指定設備的有效組合，應始終在get_camera_info調用返回的camera_info結構中設置resource_cost和conflicting_devices字段。
模塊初始化方法。在加載 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_info的static_camera_characteristics字段有效。

1.0

報告這些版本號的相機模塊實現初始相機模塊 HAL 接口。通過此模塊可打開的所有相機設備僅支持相機設備 HAL 的版本 1。 camera_info的device_version和static_camera_characteristics字段無效。此模塊及其設備僅支持android.hardware.Camera API。