相機版本支援

本頁詳細說明 Camera HAL、API 和相關 Compatibility Test Suite (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 版本。
Camera HAL3.2
搭載 Android 5.0 的相機裝置 HAL 版本。
Camera API1 CTS
在 Camera API1 上執行的相機 CTS 測試集。
Camera API2 CTS
在 Camera API2 上執行額外的相機 CTS 測試。
高音
透過新的供應商介面，將供應商實作項目 (由晶片製造商編寫的裝置專屬低階軟體) 與 Android 作業系統架構分開。
HIDL
HAL 介面定義語言：隨 Treble 推出，用於指定 HAL 與其使用者之間的介面。
影片觀看體驗 (VTS)
供應商測試套件：與 Treble 一併推出。

Camera API

Android 包含下列相機 API。

Camera API1

Android 5.0 已淘汰 Camera API1，並隨著以 Camera API2 為主的新平台開發作業持續逐步停用。不過，逐步淘汰期將相當長，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 介面和功能，且沒有任何新要求。裝置現有的相機 HAL 中已經存在的錯誤 (並導致 Camera API2 CTS 失敗) 的錯誤，都屬於現有 Camera API1 應用程式。我們不預期會出現太多這類錯誤 (不過，任何這類錯誤都必須修正，才能通過 Camera API2 CTS 測試)。

VTS 相關規定

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

相機架構強化

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

API1 的架構變更

API1 錄影功能可能會假設攝影機和影像編碼器位於同一個程序中。使用 API1 時：

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

    Android 7.0 相機和媒體堆疊 (在 HAL3 上的 API 1)

    圖 1. HAL3 上的 Android 7.0 相機和媒體堆疊

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

    Android 7.0 相機和媒體堆疊 (在 HAL1 上的 API 1)

    圖 2. HAL1 上的 Android 7.0 相機和媒體堆疊

API2 的架構變更

針對 HAL1 或 HAL3 上的 API2，BufferQueue 會傳遞緩衝區，讓這些路徑繼續運作。API2 的 Android 7.0 架構：

  • HAL1 不會受到 cameraservice 移轉作業的影響，因此不需要供應商更新。
  • HAL3「會」受到影響，但您無須更新供應商：

    Android 7.0 相機和媒體堆疊 (在 HAL3 上的 API2)

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

補充規定

為了強化媒體和相機架構的安全性，我們做出了架構變更，包括下列額外的裝置需求。

  • 一般。由於 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。
  • 更新攝影機伺服器的 SELinux 政策。如果裝置專屬的 SELinux 政策授予媒體伺服器執行相機的權限，您必須更新 SELinux 政策，才能授予相機伺服器適當的權限。我們不建議為 cameraserver 複製 mediaserver 的 SELinux 政策 (因為 mediaserver 和 cameraserver 通常需要系統中的不同資源)。Cameraserver 應只具備執行相機功能所需的權限，而媒體伺服器中的任何不必要的相機相關權限都應移除。
  • 分離相機 HAL 和相機伺服器。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 測試檢查清單」。

Android 10

Android 10 推出了以下更新。

Camera API

相機 HAL

下列相機 HAL 版本已在 Android 10 中更新。

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 中，供應商的攝影機 HAL 實作必須綁定。Android 8.0 也包含以下相機服務的重要強化功能：

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

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

共用介面

這項功能只會啟用一組緩衝區來驅動兩個輸出內容，例如預覽和影片編碼，進而降低耗電量和記憶體用量。為了支援這項功能，裝置製造商必須確保其相機 HAL 和 gralloc HAL 實作能夠建立可供多個不同使用者 (例如硬體編譯器/GPU 和影片編碼器) 使用的 gralloc 緩衝區，而非僅供單一使用者使用。相機服務會將用戶端用途旗標傳遞至相機 HAL 和 gralloc HAL；這些 HAL 需要分配正確類型的緩衝區，或者相機 HAL 需要傳回錯誤，指出系統不支援此用戶端組合。

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

自訂相機模式的系統 API

公開相機 API 定義了兩種運作模式：一般和受限高速錄影。它們具有相當不同的語義；例如，高速模式一次只能輸出兩個特定輸出。各種原始設備製造商 (OEM) 有意對硬體專屬功能定義其他自訂模式。在幕後，模式只是傳遞至 configure_streams 的整數。請參閱： hardware/camera/device/3.2/ICameraDeviceSession#configurestreams。

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

如要支援這項功能，原始設備製造商只需在 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

新增支援的中繼資料和變更的資料_空間支援：

  • 如果支援 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。