HAL 子系統

本頁說明 HAL 子系統，包括要求、攝影機子系統、啟動和作業順序、硬體層級，以及互動。

要求

應用程式架構會向攝影機子系統發出擷取結果的要求。 一項要求對應一組結果。要求會封裝擷取及處理這些結果的所有設定資訊。包括解析度和像素格式、手動感應器、鏡頭和閃光燈控制項、3A 作業模式、RAW 到 YUV 的處理控制項，以及統計資料產生。這可讓您進一步控管結果的輸出和處理方式。您可以同時發出多個要求，而且提交要求時不會遭到封鎖。系統一律會按照收到要求的順序處理。

攝影機要求模型

圖 1. 相機型號。

HAL 和相機子系統

相機子系統包含相機管道中元件的實作方式，例如 3A 演算法和處理控制項。相機 HAL 提供介面，供您實作這些元件的版本。為維持多個裝置製造商和影像訊號處理器 (ISP，或稱相機感應器) 供應商之間的跨平台相容性，相機管道模型是虛擬的，不會直接對應任何實際的 ISP。不過，這與實際的處理管道十分相似，因此您可以有效率地將其對應至硬體。此外，這項技術的抽象程度足以支援多種不同的演算法和作業順序，同時確保品質、效率和跨裝置相容性。

相機管道也支援應用程式架構可啟動的觸發條件，例如開啟自動對焦。此外，它也會將通知傳送回應用程式架構，通知應用程式自動對焦鎖定或發生錯誤等事件。

相機硬體抽象層

圖 2. 攝影機管道。

請注意，上圖顯示的部分圖像處理區塊在初始版本中並未明確定義。相機管道會做出下列假設：

  • RAW Bayer 輸出內容不會在 ISP 內經過任何處理。
  • 系統會根據原始感應器資料生成統計資料。
  • 將原始感應器資料轉換為 YUV 的各種處理區塊順序任意。
  • 雖然會顯示多個縮放和裁剪單元，但所有縮放器單元都會共用輸出區域控制項 (數位變焦)。不過，每個單元可能會有不同的輸出解析度和像素格式。

API 使用摘要

以下簡要說明如何使用 Android Camera API。如要詳細瞭解這些步驟 (包括 API 呼叫)，請參閱「啟動和預期作業順序」一節。

  1. 監聽及列舉攝影機裝置。
  2. 開啟裝置並連線至接聽器。
  3. 針對目標用途設定輸出內容 (例如靜態擷取或錄製)。
  4. 為目標用途建立要求。
  5. 擷取/重複要求和叢發。
  6. 接收結果中繼資料和圖片資料。
  7. 切換用途時，請返回步驟 3。

HAL 作業摘要

  • 架構會發出非同步擷取要求。
  • HAL 裝置必須依序處理要求。並為每個要求產生輸出結果中繼資料，以及一或多個輸出圖片緩衝區。
  • 要求和結果，以及後續要求參照的串流，都會依先進先出原則處理。
  • 特定要求的所有輸出內容必須具有相同時間戳記，架構才能視需要將這些內容配對。
  • 所有擷取設定和狀態 (3A 常式除外) 都會封裝在要求和結果中。
相機 HAL 總覽

圖 3. 相機 HAL 總覽。

啟動和預期作業順序

本節詳細說明使用 Camera API 時的預期步驟。如需 HIDL 介面定義，請參閱 platform/hardware/interfaces/camera/。

列舉及開啟攝影機裝置，並建立有效工作階段

  1. 初始化後，架構會開始監聽實作 ICameraProvider 介面的任何現有攝影機供應器。如果存在這類供應商，架構會嘗試建立連線。
  2. 架構會透過 ICameraProvider::getCameraIdList 列舉攝影機裝置。
  3. 架構會呼叫對應的 ICameraProvider::getCameraDeviceInterface_VX_X，例項化新的 ICameraDevice。
  4. 架構會呼叫 ICameraDevice::open，建立新的有效擷取工作階段 ICameraDeviceSession。

使用攝影機工作階段

  1. 架構會使用輸入/輸出串流清單呼叫 HAL 裝置的 ICameraDeviceSession::configureStreams 。
  2. 架構會針對某些用途，透過呼叫 ICameraDeviceSession::constructDefaultRequestSettings 要求預設設定。ICameraDeviceSession建立後，隨時可能發生這種情況。ICameraDevice::open
  3. 架構會根據其中一組預設設定，建構並將第一個擷取要求傳送至 HAL，且至少有一個輸出串流是架構先前註冊的。這會傳送至 HAL，並附上 ICameraDeviceSession::processCaptureRequest。HAL 必須封鎖這項呼叫的回傳，直到準備好傳送下一個要求為止。
  4. 架構會繼續提交要求並呼叫 ICameraDeviceSession::constructDefaultRequestSettings，視需要取得其他用途的預設設定緩衝區。
  5. 當要求開始擷取 (感應器開始曝光以進行擷取) 時，HAL 會呼叫 ICameraDeviceCallback::notify 並傳送 SHUTTER 訊息，包括影格編號和曝光開始時間戳記。這個通知回呼不一定要在要求的第一個 processCaptureResult 呼叫之前發生，但除非呼叫該擷取的 notify，否則不會將任何結果傳送至應用程式以供擷取。
  6. 管道延遲一段時間後，HAL 會開始將完成的擷取作業傳回架構，並附上 ICameraDeviceCallback::processCaptureResult。系統會按照提交要求的順序傳回這些結果。視攝影機 HAL 裝置的管道深度而定，一次可處理多個要求。

過一段時間後，會發生下列其中一種情況：

  • 架構會停止提交新要求，等待現有擷取作業完成 (填滿所有緩衝區、傳回所有結果)，然後再次呼叫 ICameraDeviceSession::configureStreams。這會重設攝影機硬體和管道，以處理一組新的輸入/輸出串流。部分串流可重複使用先前的設定。如果至少有一個已註冊的輸出串流，架構就會從第一個擷取要求繼續執行至 HAL。(否則請先取得 ICameraDeviceSession::configureStreams 角色)。
  • 架構可以呼叫 ICameraDeviceSession::close 來結束攝影機工作階段。只要沒有其他來自架構的呼叫處於啟用狀態，隨時都可以呼叫這個函式，但呼叫可能會遭到封鎖，直到所有進行中的擷取作業完成為止 (所有結果都已傳回，所有緩衝區都已填滿)。close 呼叫傳回後，HAL 就不得再呼叫 ICameraDeviceCallback。close 呼叫開始後，架構就無法呼叫任何其他 HAL 裝置函式。
  • 如有錯誤或其他非同步事件，HAL 必須使用適當的錯誤/事件訊息呼叫 ICameraDeviceCallback::notify。從裝置範圍的重大錯誤通知返回後，HAL 應如同已對其呼叫 close 一樣運作。不過，HAL 必須先取消或完成所有未完成的擷取作業，才能呼叫 notify，這樣在 notify 發生嚴重錯誤後，架構就不會再收到裝置的回呼。除了 close 以外的方法，都應在 notify 方法從嚴重錯誤訊息傳回後，傳回 -ENODEV 或 NULL。
攝影機操作流程

圖 4. 攝影機運作流程。

硬體層級

攝影機裝置可根據自身功能實作多個硬體層級。詳情請參閱 支援的硬體層級。

應用程式擷取要求、3A 控制項和處理管道之間的互動

視 3A 控制區塊中的設定而定，相機管道會忽略應用程式擷取要求中的部分參數，並改用 3A 控制常式提供的值。舉例來說，如果自動曝光功能處於啟用狀態，感應器的曝光時間、影格時間和感光度參數會由平台 3A 演算法控制，系統會忽略應用程式指定的任何值。3A 常式為影格選擇的值必須在輸出中繼資料中回報。下表說明 3A 控制區塊的不同模式，以及這些模式控制的屬性。如要瞭解這些屬性的定義，請參閱 platform/system/media/camera/docs/docs.html 檔案。

參數 狀態 受控屬性
android.control.aeMode OFF 無。
ON android.sensor.exposureTime、android.sensor.frameDuration、android.sensor.sensitivity、android.lens.aperture (如支援) 和 android.lens.filterDensity (如支援)。
ON_AUTO_FLASH 所有內容，外加 android.flash.firingPower、android.flash.firingTime 和 android.flash.mode。ON
ON_ALWAYS_FLASH 與 ON_AUTO_FLASH 相同。
ON_AUTO_FLASH_RED_EYE 與 ON_AUTO_FLASH 相同。
android.control.awbMode OFF 無。
WHITE_BALANCE_* android.colorCorrection.transform。如果 android.colorCorrection.mode 為 FAST 或 HIGH_QUALITY，則需進行平台專屬調整。
android.control.afMode OFF 無
FOCUS_MODE_* android.lens.focusDistance
android.control.videoStabilization OFF 無。
ON 可調整 android.scaler.cropRegion 實作影片穩定功能。
android.control.mode OFF AE、AWB 和 AF 已停用。
AUTO 使用個別 AE、AWB 和 AF 設定。
SCENE_MODE_* 可以覆寫上述所有參數。個別 3A 控制項已停用。

圖 2 中圖片處理區塊的控制項運作原理類似，每個區塊都有三種模式：

  • OFF：這個處理區塊已停用。無法停用去馬賽克、色彩校正和色調曲線調整區塊。
  • FAST：在此模式下，處理區塊的輸出影格速率可能不會比 OFF 模式慢，但應會盡可能產生最佳品質的輸出內容。這通常用於預覽或錄影模式，或是連拍靜態影像。在某些裝置上，這可能等同於 OFF 模式 (不降低影格率就無法進行處理)，在某些裝置上，這可能等同於 HIGH_QUALITY 模式 (最佳品質仍不會降低影格率)。
  • HIGH_QUALITY：在此模式下，處理區塊應盡可能產生最佳品質的結果，並視需要降低輸出影格率。這通常用於擷取高畫質靜態影像。部分方塊包含手動控制選項，可選擇使用這個選項，而非 FAST 或 HIGH_QUALITY。舉例來說，色彩校正區塊支援色彩轉換矩陣，而色調曲線調整則支援任意全域色調映射曲線。

相機子系統可支援的最大影格率取決於多項因素：

  • 輸出圖像串流的指定解析度
  • 成像器上的分組/跳過模式適用情形
  • 影像感應器介面的頻寬
  • 各 ISP 處理區塊的頻寬

不同 ISP 和感應器之間的這些因素差異很大，因此相機 HAL 介面會盡量將頻寬限制抽象化為簡單模型。這個模型具有下列特徵：

  • 影像感應器一律會根據應用程式要求的輸出串流大小，設定為輸出最小解析度。最小解析度定義為至少與要求的最大輸出串流大小相同。
  • 任何要求都可以使用目前設定的任何或所有輸出串流，因此感應器和 ISP 必須設定為同時支援將單一擷取作業擴展至所有串流。
  • 如果要求未包含 JPEG 串流，JPEG 串流會像經過處理的 YUV 串流；如果要求直接參照 JPEG 串流，則會像 JPEG 串流。
  • JPEG 處理器可與其餘相機管道並行運作，但一次只能處理一個擷取作業。