相機版本支援

本頁將詳細說明相機 HAL、API 和相關的版本差異 Compatibility Test Suite (CTS) 測試。 此內容還包含 強化及保護 Android 相機架構的架構變更 7.0,請在 Android 8.0 中改用 Treble,而且供應商必須對其進行以下更新 以輔助他們的相機實作方式變更

術語

本頁面使用的字詞如下:

Camera 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 版本。
Camera API1 CTS
在相機執行的一系列相機 CTS 測試 API1。
Camera API2 CTS
在 Camera API2 上執行額外的相機 CTS 測試。
高音
區隔供應商實作項目 (裝置專用低階軟體) 開發人員專用的 Android 應用程式 供應商介面。
HIDL
HAL 介面定義語言 透過 Treble 導入,並用於指定 HAL 和 對使用者而言。
影片觀看體驗 (VTS)
廠商測試套件一併導入 高音。

Camera API

Android 包含下列相機 API。

Camera API1

Android 5.0 已淘汰 Camera API1,並持續逐步停用,做為新推出的工具 重點在於 Camera API2然而,逐步淘汰期間 但 Android 版本會繼續支援 Camera API1 應用程式 一些時間。具體來說,支援服務的涵蓋項目包括:

  • 應用程式專用的 Camera API1 介面。以相機為建構基礎的相機應用程式 API1 應在搭載較舊 Android 版本的裝置上正常運作。
  • 相機 HAL 版本:支援 Camera HAL1.0。

相機 API2

Camera API2 架構會向應用程式公開低階相機控制項, 包括高效率的零複製/串流資料流,以及每個影格的控制項 曝光, 增加, 白平衡, 色彩轉換, 降噪, 銳利, 等等。詳情請觀看 Google I/O 大會影片簡介

Android 5.0 以上版本包含 Camera API2;不過,搭載 Android 系統的裝置 5.0 以上版本可能不支援所有 Camera API2 功能。 可供應用程式查詢的 android.info.supportedHardwareLevel 屬性 透過 Camera API2 介面,回報下列支援問題之一 層級:

  • LEGACY:這些裝置會透過 Camera API2 介面的功能大致相同 暴露於 Camera API1 介面。舊版架構程式碼 概念上會將 Camera API2 呼叫轉譯為 Camera API1 呼叫。舊版裝置 不支援 Camera API2 功能,例如每個影格控制項
  • LIMITED:這些裝置支援部分 Camera API2 功能 而且必須使用相機 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 屬性 存取 APIFULL 裝置必須搭載MANUAL_SENSORMANUAL_POST_PROCESSING 等功能。 即使 FULL 裝置,RAW 功能也是選用功能。 LIMITED 個裝置可通告以下任一功能、 包括全部不過,BACKWARD_COMPATIBLE 功能 必須一律定義。

裝置支援的硬體等級,以及特定相機 支援的 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、相機 API2 CTS 和 CTS Verifier 相機測試。

未提供相機 HAL3.2 實作的裝置 支援完整 Camera API2 介面的功能仍須將相機傳送至 API2 CTS 測試。不過,該裝置是在 Camera API2 中執行 LEGACY 模式 (在概念上對應 Camera API2 呼叫) 傳送至 Camera API1 呼叫),因此任何與功能或功能相關的 Camera API2 CTS 測試 系統會自動略過 Camera API1 以外的功能。

在舊版裝置上,執行的 Camera API2 CTS 測試會使用 現有公用 Camera API1 介面和功能 Google Cloud 就是最佳選擇錯誤曝光 (且會導致 Camera API2 CTS 失敗) 是裝置現有的相機 HAL 中現有的錯誤,因此 但現有的 Camera API1 應用程式會找到這項功能我們預期不會有許多這類錯誤 不過,這類錯誤必須修正才能通過 Camera API2 CTS 測試。

VTS 相關規定

如果裝置搭載 Android 8.0 以上版本,並實作繫結式 HAL 功能 傳遞相機 VTS 測試

相機架構強化

為了強化媒體和相機架構安全性,Android 7.0 會移動相機鏡頭 由媒體伺服器傳出服務從 Android 8.0 開始,每款繫結化相機 HAL 執行的程序獨立於相機服務之外。供應商可能需要 相機 HAL 的各項變更,取決於使用中的 API 和 HAL 版本。 以下各節將詳細說明 HAL1 和 AP1 和 AP2 的架構變更 HAL3 以及一般需求

API1 的架構變更

API1 錄影功能可能會以 上傳資料集之後,您可以運用 AutoML 自動完成部分資料準備工作在以下裝置上使用 API1 時:

  • HAL3:相機服務使用 BufferQueue 在 程序,無須更新供應商

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

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

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

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

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

API2 的架構變更

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

  • HAL1 不受攝影機服務遷移影響,沒有廠商 update 為必要項目。
  • HAL3 會受到影響,但「沒有供應商更新」 變更:

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

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

補充規定

強化媒體和相機架構的架構變更 安全性包括下列其他裝置需求

  • 一般規定。視處理序間通訊 (IPC) 而定,裝置需要額外頻寬 這可能會影響需要時效的相機用途,例如高速視訊 錄製。廠商可以藉由 android.hardware.camera2.cts.PerformanceTest 和 Google 相機 。此外,裝置必須搭配 額外少量 RAM 就能建立新的程序
  • 在影片緩衝區中傳遞中繼資料 (僅限 HAL1)。HAL1 (如果有) 會在影片緩衝區中儲存中繼資料 (而非實際的 YUV 影格資料),HAL 必須 使用 kMetadataBufferTypeNativeHandleSource 做為中繼資料緩衝區 型別並傳遞 VideoNativeHandleMetadata 在影片緩衝區中。 (Android 已不再支援 kMetadataBufferTypeCameraSource 7.0)。運用 VideoNativeHandleMetadata、相機和媒體架構 成功通過序列化與輸出要求, 能正確還原原生控制代碼
  • 緩衝區帳號代碼不一定會儲存相同的緩衝區 (僅限 HAL3)。針對每個擷取要求,HAL3 會取得緩衝區位址 控制代碼HAL 無法使用位址來識別緩衝區,因為 可能會在 HAL 傳回緩衝區後儲存另一個緩衝區控制代碼。必須更新 HAL 以便使用緩衝區控制代碼來識別緩衝區。例如,HAL 收到 緩衝區控制位址 A,用於儲存緩衝區控制 A。HAL 退貨後 緩衝區控制 A,緩衝區控制位址 A 可能會在下次載入 HAL 接到這些資訊。
  • 更新 cameraserver 的 SELinux 政策。如果 裝置專屬的 SELinux 政策可授予媒體伺服器執行相機的權限。 您必須更新 SELinux 政策,以授予相機伺服器適當的權限。三 我們不建議複製媒體伺服器的 SELinux 政策,以用於相機伺服器 (因為媒體伺服器和相機伺服器,在 系統)。相機伺服器應只具備執行相機所需的權限 功能,以及媒體伺服器中所有不必要的相機相關權限 。
  • 相機 HAL 和相機伺服器區隔。Android 版 8.0 以上版本會額外將繫結器化相機 HAL 置於處理程序中 跟相機伺服器不同IPC 會通過 HIDL 定義介面。

驗證

針對包含相機且搭載 Android 7.0 的所有裝置,驗證 以便完成實作。雖然 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: 告知相機架構是否完整串流的方法 必須重新設定,才能取得新的工作階段參數值。這個 有助於避免不必要的相機重新設定延遲。詳情請見 工作階段重新設定查詢
  • 半場 緩衝區管理 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 方法,讓裝置傳送通知 。 轉送。

2.4

  • 搭載 API 級別 29 以上版本的裝置必須回報 isTorchModeSupportedtrue

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
  • 自訂相機模式的 System API
  • onCaptureQueueEmpty

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

共用介面

此功能僅可讓一組緩衝區可驅動兩個輸出,例如 預覽和影片編碼,降低耗電量和記憶體用量。目的地: 支援這項功能,裝置製造商必須確保相機 HAL 和 gralloc HAL 實作可建立 gralloc 緩衝區,供 多個不同的取用者 (例如硬體 Composer/GPU 和影片) 而非單一消費者相機服務會將 將相機 HAL 和 gralloc HAL 的使用標記傳送至相機他們需要 您必須分配正確類型的緩衝區,或者相機 HAL 必須傳回錯誤 系統不支援這種消費者組合

請參閱《 enableSurfaceSharing》 開發人員說明文件

自訂相機模式的 System API

公用相機 API 定義了兩種作業模式:一般和受限 以及高速錄影功能兩者的語意有很大的差異例如 高速模式一次最多僅能輸出兩個特定輸出內容。集成 原始設備製造商 (OEM) 有意為 硬體專屬功能但實際上,這個模式只是整數 已傳遞至 configure_streams。請參閱以下內容: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams

這項功能包含系統 API 呼叫,原始設備製造商 (OEM) 相機應用程式可用來啟用 自訂模式。這些模式必須以整數值 0x8000 開頭,以免衝突 ,在公用 API 中加入未來模式

如要支援這項功能,原始設備製造商 (OEM) 只需在 HAL 中加入新模式 這個整數會在 set_streams 上傳遞至 HAL 觸發 自訂相機應用程式會使用系統 API

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

擷取佇列空白

這個 API 的用途是縮短控制項變更的延遲時間,例如「縮放 請盡可能將要求佇列保持空白。onCaptureQueueEmpty 無需 HAL 作業而且只是單純加上架構符合以下條件的應用程式 為此,您需要在回呼中新增事件監聽器並回應 才是正確的做法一般而言,就是向相機傳送另一個拍攝要求 裝置。

相機 HIDL 介面

相機 HIDL 介面全面翻新了相機 HAL 介面 ,且該 API 使用穩定的 HIDL 定義的 API。所有功能和相機功能 最新的舊版本 3.4 與 2.4 (相機專用) 也屬於 HIDL 定義的一部分。

3.4

對支援中繼資料進行小幅新增,並調整 data_space 支援的支援功能:

  • 視需要新增 ANDROID_SENSOR_OPAQUE_RAW_SIZE 個靜態中繼資料 表示系統支援 RAW_OPAQUE 格式。
  • 新增 ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE 靜態圖像 中繼資料 (如支援任何 RAW 格式的話)。
  • camera3_stream_t data_space 欄位切換為更有彈性 定義,並採用 Dataspace 編碼版本 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 串流設定作業模式新增至 camera3_stream_configuration_t

3.2

對擴充功能 HAL 的微幅修訂:

  • 淘汰 get_metadata_vendor_tag_ops。使用 改為在「camera_common.hget_vendor_tag_ops
  • 淘汰 register_stream_buffers。所有 gralloc 緩衝區 提供給 process_capture_request 的 HAL 使用,或許是新的 。
  • 新增部分結果支援。process_capture_result 可能是 多次呼叫,並在完整顯示前,呼叫一部分的可用結果 已有結果。
  • 在「camera3_request_template」中新增手動範本。應用程式 可以直接使用此範本控制擷取設定。
  • 重新建構雙向和輸入串流規格。
  • 變更輸入緩衝區傳迴路徑。緩衝區會傳回 process_capture_result 取代 process_capture_request

3.1

對擴充功能 HAL 的微幅修訂:

  • configure_streams 會將消費者使用標記傳遞至 HAL。
  • 清除呼叫,以盡快捨棄所有處理中的要求/緩衝區。

3.0

擴充功能 HAL 的第一個修訂版本:

  • 由於 ABI 完全不同,因此主要版本變更。沒有任何變更 所需的硬體功能或運作模式
  • 經過重新設計的輸入要求與串流佇列介面:傳送至 HAL 的架構呼叫 已將下一個要求和串流緩衝區排入佇列。支援同步處理架構 ,以便有效率的導入做法。
  • 將觸發條件移到要求中,大部分的通知都會併入結果。
  • 將所有回呼整合成單一結構,所有設定 將方法轉換為單一 initialize() 呼叫。
  • 將串流設定加入單一呼叫,簡化串流管理作業。 雙向串流會取代 STREAM_FROM_STREAM 建構容器
  • 舊型/功能有限的硬體裝置適用受限模式語意。

2.0

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

  • 已足夠導入現有的 android.hardware.Camera 也能使用 Google Cloud CLI 或 Compute Engine 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 為基礎)。兩者 最重要的 16 進位數字代表主要版本,至少兩個 來代表子版本

2.4

這個相機模組版本新增了下列 API 變更:

  1. 支援門鎖模式。架構可以啟用任何的手電筒模式 配備閃光燈,無需開啟相機裝置。 相機裝置在存取閃光燈時的優先順序高於相機 module;開啟相機裝置,關閉手電筒 (如果已啟用的話) 透過模組介面發生任何資源衝突時,例如 呼叫 open() 即可開啟相機裝置,也就是相機 HAL 模組 必須透過手電筒模式狀態回呼通知架構, 模式已關閉
  2. 支援外接鏡頭 (例如 USB 熱插頭攝影機)。 API 更新會指定相機靜態資訊只有在相機處於 已連接,可直接連接外接式熱插頭攝影機。呼叫取得靜態值 如果攝影機狀態不明,則資訊為無效通話 CAMERA_DEVICE_STATUS_PRESENT。這套架構只仰賴 裝置狀態變更回呼,以管理可用的外部相機清單。
  3. 相機仲裁提示。新增可明確指出 可以同時開啟及使用的相機裝置數量目的地: 指定有效的裝置組合,即 resource_costconflicting_devices 欄位應一律設定在 get_camera_info 傳回的 camera_info 結構 呼叫。
  4. 模組初始化方法。攝影機服務呼叫 HAL 模組載入後,允許一次性初始化 HAL。 這個方法會在叫用任何其他模組方法之前呼叫。

2.3

這個相機模組版本新增了開放式舊版相機 HAL 裝置支援。 架構可用於開啟相機裝置,做為較低裝置的 HAL 版本 HAL 裝置:如果同一部裝置可以支援多個裝置 API 版本。 標準硬體模組開啟呼叫 (common.methods->open) 繼續 即可使用最新的支援版本開啟相機裝置 以及 camera_info_t.device_version 中列出的版本

2.2

這個相機模組版本新增了模組中的供應商標記支援,且 淘汰先前僅使用的舊 vendor_tag_query_ops 都能在開啟裝置後存取

2.1

這個相機模組版本會為 相機 HAL 模組的架構,可用來通知 相機模組狀態變更。提供有效的模組 set_callbacks() 方法必須回報至少這個版本號碼。

2.0

回報此版本號碼的相機模組會導入第二個版本 已進入相機模組 HAL 介面相機裝置可透過這個方式開啟 模組可能支援相機裝置 1.0 或 2.0 版 HAL 介面。camera_info 的 device_version 欄位一律為 有效;static_camera_characteristics 欄位 camera_info如果 device_version 欄位在 2.0 以上版本。

1.0

回報這些版本號碼的相機模組會導入 相機模組 HAL 介面。所有相機裝置都能透過這個方式開啟 模組僅支援第 1 版的相機裝置 HAL。 「device_version」和「static_camera_characteristicscamera_info 的欄位無效。只有 這個模組及其模組可以支援 android.hardware.Camera API 裝置。