相機版本支援

本頁詳細說明 Camera HAL、API 和相關相容性測試套件 (CTS) 測試的版本差異。此外，本文也涵蓋 Android 7.0 中為強化及保護相機架構所做的幾項架構變更、Android 8.0 中改用 Treble，以及供應商必須進行的更新，以便在相機實作中支援這些變更。

術語

本頁面使用下列詞彙：

Camera API1
Android 4.4 以下版本裝置上的應用程式層級相機架構，透過 android.hardware.Camera 類別公開。
Camera API2
Android 5.0 以上版本裝置的應用程式層級相機架構，透過 android.hardware.camera2 套件公開。
相機 HAL
由 SoC 供應商實作的攝影機模組層。應用程式層級的公開架構是以相機 HAL 為基礎建構而成。
Camera HAL3.1
Android 4.4 隨附的相機裝置 HAL 版本。
相機 HAL 3.2
Android 5.0 隨附的攝影機裝置 HAL 版本。
Camera API1 CTS
這組攝影機 CTS 測試會在 Camera API1 上執行。
Camera API2 CTS
在 Camera API2 上執行的額外相機 CTS 測試集。
高音
透過新的供應商介面，將供應商實作 (裝置專用的低階軟體，由晶片製造商編寫) 與 Android OS 架構分開。
HIDL
HAL 介面定義語言：Treble 導入的語言，用於指定 HAL 與使用者之間的介面。
VTS
供應商測試套件與 Treble 一併推出。

Camera API

Android 包含下列相機 API。

Camera API1

Android 5.0 淘汰了 Camera API1，隨著新平台開發作業著重於 Camera API2，Camera API1 也將持續淘汰。不過，淘汰期會很長，Android 版本在一段時間內仍會支援 Camera API1 應用程式。具體來說，支援服務會繼續提供給：

  • 應用程式適用的 Camera API1 介面。以 Camera API1 為基礎建構的相機應用程式，應能像在較舊的 Android 版本上運作一樣。
  • 相機 HAL 版本。支援 Camera HAL 1.0。

Camera 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 呼叫；舊版裝置不支援 Camera 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_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 需求

搭載 Android 8.0 以上版本且採用繫結 HAL 實作的裝置，必須通過 Camera VTS 測試。

強化攝影機架構

為強化媒體和相機架構安全性，Android 7.0 會將相機服務移出 mediaserver。從 Android 8.0 開始，每個繫結的 Camera HAL 都會在與相機服務不同的程序中執行。視使用的 API 和 HAL 版本而定，供應商可能需要在相機 HAL 中進行變更。以下各節將詳細說明 HAL1 和 HAL3 的 AP1 和 AP2 架構變更，以及一般規定。

API1 的架構變更

API1 錄影功能可能會假設攝影機和影片編碼器位於同一程序中。在下列情況使用 API1：

  • HAL3：相機服務會使用 BufferQueue 在程序之間傳遞緩衝區，不需要更新供應商。

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

    圖 1. Android 7.0 相機和媒體 堆疊 (API1，HAL3)

  • HAL1 支援在視訊緩衝區中傳遞中繼資料，供應商必須更新 HAL，才能使用 kMetadataBufferTypeNativeHandleSource。 (Android 7.0 不再支援 kMetadataBufferTypeCameraSource)。

    Android 7.0 相機和媒體堆疊 (API1，HAL1)

    圖 2. Android 7.0 相機和媒體 堆疊 (API1，HAL1)

API2 的架構變更

如果是 HAL1 或 HAL3 上的 API2，BufferQueue 會傳遞緩衝區，因此這些路徑仍可運作。API2 的 Android 7.0 架構：

  • HAL1 不會受到 cameraservice 遷移作業影響，不需要更新供應商。
  • HAL3 會受到影響，但不需要更新供應商：

    Android 7.0 相機和媒體堆疊 (API2，HAL3)

    圖 3. Android 7.0 相機和媒體堆疊 (API2 中的 HAL3)

補充規定

為強化媒體和相機架構安全性而進行的架構變更，包括下列額外裝置需求。

  • 一般條款。由於 IPC，裝置需要額外頻寬，這可能會影響對時間敏感的攝影機用途，例如高速錄影。供應商可以執行 android.hardware.camera2.cts.PerformanceTest和 Google 相機應用程式，錄製 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 後，緩衝區控制代碼位址 A 可能會在下次 HAL 收到時儲存緩衝區控制代碼 B。
  • 更新 cameraserver 的 SELinux 政策。如果裝置專屬的 SELinux 政策授予 mediaserver 執行相機的權限，您必須更新 SELinux 政策，授予 cameraserver 適當的權限。我們不建議複製 mediaserver 的 SELinux 政策給 cameraserver (因為 mediaserver 和 cameraserver 通常需要系統中的不同資源)。Cameraserver 應只具備執行攝影機功能所需的權限，且應移除 mediaserver 中任何不必要的攝影機相關權限。
  • 攝影機 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 Camera HAL 的可用測試清單，請參閱「Camera HAL 測試檢查清單」。

Android 10

Android 10 導入下列更新。

Camera API

相機 HAL

Android 10 更新了下列 Camera 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。

Android 9

Android 9 版本針對 Camera API2 和 HAL 介面推出下列更新。

Camera 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」的更新

「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

Android 8.0

Android 8.0 版本推出 Treble。使用 Treble 時，供應商 Camera HAL 實作項目必須繫結。Android 8.0 也針對 Camera 服務進行下列重大強化：

  • 共用介面：啟用多個介面共用同一個 OutputConfiguration
  • 自訂相機模式的系統 API
  • onCaptureQueueEmpty

如要進一步瞭解這些功能，請參閱下方各節。

共用表面

這項功能只會啟用一組緩衝區來驅動兩個輸出內容，例如預覽和影片編碼，進而降低耗電量和記憶體用量。如要支援這項功能，裝置製造商必須確保攝影機 HAL 和 gralloc HAL 實作項目可建立 gralloc 緩衝區，供多個不同的消費者 (例如硬體合成器/GPU 和影片編碼器) 使用，而不僅限於一個消費者。相機服務會將消費者使用情形標記傳遞至相機 HAL 和 gralloc HAL；這些標記必須分配正確的緩衝區類型，否則相機 HAL 必須傳回錯誤，指出不支援這類消費者組合。

詳情請參閱 enableSurfaceSharing開發人員說明文件。

自訂相機模式的系統 API

公開相機 API 定義了兩種操作模式：一般和受限高速錄影。兩者語意差異相當大，例如高速模式一次最多只能輸出兩個特定項目。許多原始設備製造商 (OEM) 表示有興趣為硬體專屬功能定義其他自訂模式。在幕後，模式只會傳遞至 configure_streams 的整數。詳情請參閱： hardware/camera/device/3.2/ICameraDeviceSession#configurestreams。

這項功能包含 OEM 相機應用程式可用來啟用自訂模式的系統 API 呼叫。這些模式必須從整數值 0x8000 開始，以免與日後新增至公開 API 的模式發生衝突。

如要支援這項功能，原始設備製造商只需將新模式新增至 HAL，並透過傳遞至 configure_streams 的這個整數觸發，然後讓自訂相機應用程式使用系統 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 靜態中繼資料。
  • 使用資料空間編碼的第 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 更新。
  • 基本支援深度輸出緩衝區。
  • 在 camera3_stream_t 中新增 data_space 欄位。
  • 在 camera3_stream_t 中新增輪替欄位。
  • 將 camera3 串流設定作業模式新增至 camera3_stream_configuration_t。

3.2

擴充功能 HAL 的次要修訂版本：

  • 淘汰 get_metadata_vendor_tag_ops。請改用 camera_common.h 中的 get_vendor_tag_ops。
  • 淘汰 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 為準。最重要的兩個十六進位數字代表主要版本，最不重要的兩個則代表次要版本。

2.4

這個攝影機模組版本新增了下列 API 異動：

  1. 支援手電筒模式。架構可為任何具備閃光燈單元的攝影機裝置開啟手電筒模式，不必開啟攝影機裝置。相機裝置存取閃光燈單元的優先順序高於相機模組；如果透過模組介面啟用手電筒，開啟相機裝置就會關閉手電筒。如有任何資源衝突 (例如呼叫 open() 開啟攝影機裝置)，攝影機 HAL 模組必須透過手電筒模式狀態回呼通知架構，手電筒模式已關閉。
  2. 支援外接式攝影機 (例如 USB 熱插拔攝影機)。API 更新內容指出，只有在攝影機已連線並可供外部熱插拔攝影機使用時，才能取得攝影機靜態資訊。如果相機狀態不是 CAMERA_DEVICE_STATUS_PRESENT，則用來取得靜態資訊的呼叫無效。架構完全依賴裝置狀態變更回呼，管理可用的外部攝影機清單。
  3. 攝影機仲裁提示。新增支援功能，可明確指出可同時開啟及使用的攝影機裝置數量。如要指定有效的裝置組合，請務必在 get_camera_info 呼叫傳回的 camera_info 結構中，設定 resource_cost 和 conflicting_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_info 的 static_camera_characteristics 欄位也有效。

1.0

回報這些版本號碼的攝影機模組會實作初始攝影機模組 HAL 介面。透過這個模組開啟的所有攝影機裝置僅支援攝影機裝置 HAL 第 1 版。camera_info 的 device_version 和 static_camera_characteristics 欄位無效。這個模組及其裝置只能支援 android.hardware.Camera API。