請求
應用框架會針對捕獲的結果向相機子系統發出請求。一個請求對應一組結果。請求包含有關捕獲和處理這些結果的所有配置信息。其中包括分辨率和像素格式；手動傳感器、鏡頭和閃光燈控件；3A 操作模式；RAW 到 YUV 處理控件；以及統計信息的生成等。這樣一來，便可更好地控制結果的輸出和處理。一次可發起多個請求，而且提交請求時不會出現阻塞。請求始終按照接收的順序進行處理。
圖 1. 相機模型
HAL 和相機子系統
相機子系統包括相機管道中組件的實現，例如 3A 算法和處理控件。相機 HAL 爲您提供了用於實現您的這些組件版本的接口。爲了保持多個設備製造商和圖像信號處理器（ISP，也稱爲相機傳感器）供應商之間的跨平臺兼容性，相機管道模型是虛擬的，且不直接對應於任何真正的 ISP。不過，它與真正的處理管道足夠相似，因此您可以有效地將其映射到硬件。此外，它足夠抽象，可支持多種不同的算法和運算順序，而不會影響質量、效率或跨設備兼容性。
相機管道還支持應用框架可以啓動來開啓自動對焦等功能的觸發器。它還會將通知發送迴應用框架，以通知應用自動對焦鎖定或錯誤等事件。
圖 2. 相機管道
請注意，上圖所示的一些圖像處理塊在初始版本中沒有明確定義。相機管道做出以下假設：
- RAW Bayer 輸出在 ISP 內部不經過任何處理。
- 統計信息根據原始傳感器數據生成。
- 將原始傳感器數據轉換爲 YUV 的各種處理塊按任意順序排列。
- 當顯示多個刻度和剪裁單元時，所有縮放器單元共享輸出區域控件（數字縮放）。不過，每個單元都可能具有不同的輸出分辨率和像素格式。
API 用途摘要
下面簡要介紹了使用 Android Camera API 的步驟。有關這些步驟（包括 API 調用）的詳細說明，請參閱“啓動和預期操作順序”部分。
- 監聽和枚舉相機設備。
- 打開設備並連接監聽器。
- 配置目標使用情形的輸出（如靜態捕獲、錄製等）。
- 爲目標使用情形創建請求。
- 捕獲/重複請求和連拍。
- 接收結果元數據和圖片數據。
- 切換使用情形時，返回到第 3 步。
HAL 操作摘要
- 捕獲的異步請求來自於框架。
- HAL 設備必須按順序處理請求。對於每個請求，均生成輸出結果元數據以及一個或多個輸出圖像緩衝區。
- 請求和結果以及後續請求引用的信息流遵守先進先出規則。
- 指定請求的所有輸出的時間戳必須完全相同，以便框架可以根據需要將它們匹配在一起。
- 所有捕獲配置和狀態（不包括 3A 例程）都包含在請求和結果中。
圖 3. 相機 HAL 概覽
啓動和預期操作順序
本部分詳細說明了使用 Camera API 時應遵循的步驟。有關 HIDL 接口的定義，請參閱 platform/hardware/interfaces/camera/。
枚舉、打開相機設備並創建有效會話
- 初始化後，框架開始監聽實現
ICameraProvider接口的任何現有相機提供程序。如果存在一個或多個此類提供程序，框架將嘗試建立連接。 - 框架通過
ICameraProvider::getCameraIdList()枚舉相機設備。 - 框架通過調用相應的
ICameraProvider::getCameraDeviceInterface_VX_X()來實例化一個新的ICameraDevice。 - 框架調用
ICameraDevice::open()來創建一個新的有效捕獲會話 ICameraDeviceSession。
使用有效相機會話
- 框架調用
ICameraDeviceSession::configureStreams()並傳入到 HAL 設備的輸入/輸出流列表。 - 框架通過調用
ICameraDeviceSession::constructDefaultRequestSettings()來爲某些使用情形請求默認設置。這可能會在ICameraDevice::open創建ICameraDeviceSession之後的任何時間發生。 - 框架通過基於某一組默認設置的設置以及框架之前註冊的至少一個輸出流來構建第一個捕獲請求並將其發送到 HAL。此請求通過
ICameraDeviceSession::processCaptureRequest()發送到 HAL。HAL 必須阻止此調用返回，直到準備好發送下一個請求爲止。 - 框架繼續提交請求並根據需要調用
ICameraDeviceSession::constructDefaultRequestSettings()以獲取其他使用情形的默認設置緩衝區。 - 當請求捕獲開始（傳感器開始曝光以進行捕獲）時，HAL 會調用
ICameraDeviceCallback::notify()並顯示 SHUTTER 消息，包括幀號和開始曝光的時間戳。此通知回調不必在對請求第一次調用processCaptureResult()之前發生，但直到針對相應的捕獲調用notify()之後，纔會嚮應用提供有關該捕獲的結果。 - 經過一定的管道延遲後，HAL 開始使用
ICameraDeviceCallback::processCaptureResult()將完成的捕獲返回到框架。這些捕獲按照與提交請求相同的順序返回。一次可發起多個請求，具體取決於相機 HAL 設備的管道深度。
一段時間後，會出現以下某種情況：
- 框架可能會停止提交新的請求，等待現有捕獲完成（所有緩衝區都已填充，所有結果都已返回），然後再次調用
ICameraDeviceSession::configureStreams()。這會重置相機硬件和管道，以獲得一組新的輸入/輸出流。可重複使用先前配置中的部分信息流。如果至少還有一個已註冊的輸出流，則框架將從發送到 HAL 的第一個捕獲請求繼續。（否則，需要先調用ICameraDeviceSession::configureStreams()。） - 框架可能會調用
ICameraDeviceSession::close()以結束相機會話。當框架中沒有其他處於有效狀態的調用時，可能隨時會調用此函數；不過，在所有發起的捕獲完成（所有結果都已返回，所有緩衝區都已填充）之前，調用可能會阻塞。close()調用返回後，不允許再從 HAL 對ICameraDeviceCallback進行調用。一旦進行close()調用，框架便不能再調用其他任何 HAL 設備函數。 - 在發生錯誤或其他異步事件時，HAL 必須調用
ICameraDeviceCallback::notify()並返回相應的錯誤/事件消息。從嚴重的設備範圍錯誤通知返回後，HAL 的行爲方式應像對其調用了close()一樣。但是，HAL 必須在調用notify()之前取消或完成所有待處理的捕獲，以便在調用notify()並返回嚴重錯誤時，框架不會收到來自設備的更多回調。在notify()方法從嚴重錯誤消息返回後，close()之外的方法應返回 -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_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 中，圖像處理塊中的控件都以類似的原理操作，並且每個塊一般都具有 3 種模式：
- OFF：該處理塊處於停用狀態。無法停用去馬賽克、色彩校正和色調曲線調整塊。
- FAST：與 OFF 模式相比，在這種模式下，處理塊可能不會降低輸出幀速率，但是考慮到限制條件，它應該會產生能夠產生的最優質輸出。通常，該模式會用於預覽或視頻錄製模式，或用於連拍靜態圖像。在一些設備上，該模式可能等同於 OFF 模式（進行任何處理都會降低幀速率）；而在另外一些設備上，該模式可能等同於 HIGH_QUALITY 模式（最佳質量仍不會降低幀速率）。
- HIGH_QUALITY：在這種模式下，處理塊應儘可能產生最優質結果，根據需要降低輸出幀速率。通常，該模式會用於拍攝優質靜態圖像。一些塊包括可以被選中的手動控件（而非 FAST 或 HIGH_QUALITY）。例如，色彩校正塊支持顏色變換矩陣，而色調曲線調整支持任意的全局色調映射曲線。
相機子系統可以支持的最大幀速率受到多種因素的影響：
- 所請求的輸出圖像流的分辨率
- 成像器上像素組合/跳過模式的可用性
- 成像器接口的帶寬
- 各種 ISP 處理塊的帶寬
由於這些因素在不同的 ISP 和傳感器之間可能有很大差異，因此相機 HAL 接口會設法將帶寬限制抽象爲儘可能簡單的模型。顯示的模型具有以下特性：
- 考慮到應用的請求輸出流大小，圖像傳感器始終配置爲輸出儘可能最小的分辨率。最小分辨率定義爲至少與請求的最大輸出流一樣大。
- 因爲任何請求都可能使用當前配置的任意或所有輸出流，所以傳感器和 ISP 必須配置爲支持將單個捕獲同時擴展到所有信息流。
- 對於不包含 JPEG 流的請求，JPEG 流表現得像經過處理的 YUV 流一樣；在直接引用它們的請求中，它們用作 JPEG 流。
- JPEG 處理器可以並行運行到相機管道的剩餘部分，但不能一次處理多個捕獲。