相機版本支援

本頁詳細說明 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，這個 API 將持續逐步淘汰。不過，淘汰期會很長，Android 版本會持續支援 Camera API1 應用程式一段時間。具體來說，我們會繼續支援以下項目：

  • 適用於應用程式的 Camera API1 介面。在 Camera API 1 上建構的相機應用程式，應可在執行較舊 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 失敗) 是裝置現有相機 HAL 中已存在的錯誤，因此會被現有的 Camera API1 應用程式找到。我們不預期會出現太多這類錯誤 (不過，任何這類錯誤都必須修正，才能通過 Camera API2 CTS 測試)。

VTS 規定

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

強化相機架構

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

API1 的架構變更

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

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

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

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

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

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

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

API2 的架構變更

針對 HAL1 或 HAL3 上的 API2，BufferQueue 會傳遞緩衝區，讓這些路徑繼續運作。適用於以下 API 2 的 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 以上版本則會在與相機伺服器不同的程序中，將繫結的 Camera 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

下列 Camera 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 版本為相機 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。