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 常式除外) 都會封裝在要求和結果中。

圖 3. 相機 HAL 總覽

啟動和預期作業順序

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

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

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	關閉	無
	開啟	android.sensor.exposureTime android.sensor.frameDuration android.sensor.sensitivity android.lens.aperture (如果支援) android.lens.filterDensity (如果支援)
	ON_AUTO_FLASH	所有項目皆為 ON，外加 android.flash.firingPower、android.flash.firingTime 和 android.flash.mode
	ON_ALWAYS_FLASH	與 ON_AUTO_FLASH 相同
	ON_AUTO_FLASH_RED_EYE	與 ON_AUTO_FLASH 相同
android.control.awbMode	關閉	無
	WHITE_BALANCE_*	android.colorCorrection.transform。如果 android.colorCorrection.mode 為 FAST 或 HIGH_QUALITY，則會進行平台專屬調整。
android.control.afMode	關閉	無
	FOCUS_MODE_*	android.lens.focusDistance
android.control.videoStabilization	關閉	無
	開啟	可調整 android.scaler.cropRegion，實作影像防震功能
android.control.mode	關閉	AE、AWB 和 AF 已停用
	自動	使用個別 AE、AWB 和 AF 設定
	SCENE_MODE_*	可以覆寫上述所有參數。個別 3A 控制選項已停用。

圖 2 中「影像處理」區塊的控制項運作原理類似，且每個區塊通常有三種模式：

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

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

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

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

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