自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
工作階段參數
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
工作階段參數功能可讓相機用戶端在擷取工作階段初始化階段中主動設定耗用大量資源的要求參數子集 (即工作階段參數),藉此縮短延遲時間。有了這項功能,HAL 實作項目會在串流設定階段 (而非第一次擷取要求) 接收用戶端參數,並可根據參數值更有效率地準備及建構內部管道。
在 Android 10 中,您可以使用選用的工作階段重新設定查詢功能,進一步控制內部工作階段參數重新設定邏輯,藉此提升效能。詳情請參閱「工作階段重新設定查詢」。
範例和來源
參考工作階段參數實作項目已是 CameraHal 的一部分。這個 HAL 會使用舊版 Hal API。實作相機 HIDL API 的綁定 CameraHal 必須使用相應的 HIDL sessionParams 項目,才能在串流設定期間存取任何新的傳入工作階段參數。
相機用戶端可以呼叫 getAvailableSessionKeys()
,查詢所有支援的工作階段參數的鍵,並最終透過 setSessionParameters()
設定初始值。
實作
您的 CameraHal 實作必須在相應的靜態相機中繼資料中填入 ANDROID_REQUEST_AVAILABLE_SESSION_KEYS
,並提供 ANDROID_REQUEST_AVAILABLE_REQUEST_KEYS
的子集,其中包含一長串難以套用於每個影格,且在擷取工作階段生命週期內修改時可能導致意外延遲的鍵。
常見的例子包括需要耗費大量時間重新設定硬體或變更內部相機管道的參數。擷取要求仍可控制工作階段參數,但用戶端應注意並預期應用程式會發生延遲。
此架構會監控所有傳入的要求,如果偵測到工作階段參數的值有所變更,就會在內部重新設定攝影機。傳遞至 CameraHal 的新串流設定會包含更新後的工作階段參數值,用於更有效率地設定相機管道。
自訂
您可以在 CameraHal 端填入的可用工作階段參數清單中定義標記。如果 CameraHal 將可用的工作階段參數清單留空,這項功能就不會啟用。
驗證
CTS 包含下列新案例,用於測試工作階段參數:
一般來說,某個參數成為工作階段鍵清單的一部分後,其目前的值就會納入工作階段參數,並在 HAL 層級的串流設定期間傳遞。
請謹慎選取工作階段參數。在串流設定之間,這些值不應經常變更。經常變更的參數 (例如擷取意圖) 並不適合,如果將這些參數新增至工作階段參數清單,可能會因過度內部重新設定而導致 CTS 失敗。
工作階段重新設定查詢
Android 10 推出了選用的會話重新設定查詢功能,可改善效能,因為會話參數值修改所導致的內部串流重新設定,可能會降低效能。為解決這個問題,HIDL ICameraDeviceSession
3.5 以上版本支援 isReconfigurationRequired
方法,可針對內部工作階段參數重新設定邏輯提供精細控制。使用此方法,即可在需要時精確執行串流重新設定。
isReconfigurationRequired
的引數會提供每個待處理的工作階段參數修改作業所需的資訊,允許各種裝置專屬的客製化設定。
這項功能僅在相機服務和相機 HAL 中實作。沒有公開 API。如果實作這項功能,攝影機用戶端在使用工作階段參數時,應可看到效能提升。
實作
如要支援工作階段重新設定查詢,您必須實作 isReconfigurationRequired
方法,以便檢查是否需要完整重新設定串流,以便取得新的會話參數值。
如果用戶端變更任何宣傳的工作階段參數值,相機架構會呼叫 isReconfigurationRequired
方法。視具體值而定,HAL 會決定是否需要重新設定完整的串流。如果 HAL 傳回 false
,攝影機架構會略過內部重新設定。如果 HAL 傳回 true
,架構會重新設定串流,並相應傳遞新的工作階段參數值。
在將含有新參數的要求提交至 HAL 之前,架構可以呼叫 isReconfigurationRequired
方法,且可以在提交前取消要求。因此,HAL 不得以任何方式使用這個方法呼叫來變更其行為。
HAL 實作必須符合下列規定:
- 在啟用工作階段設定後,架構必須能夠隨時呼叫
isReconfigurationRequired
方法。
- 不得影響待處理的攝影機要求效能。特別是,在正常攝影機串流期間,不得出現任何錯誤或延遲。
裝置和 HAL 實作必須符合下列效能規定:
- 不得變更攝影機的硬體和軟體設定。
- 不得對攝影機效能造成使用者可見的影響。
isReconfigurationRequired
方法使用下列引數:
oldSessionParams
:上一個工作階段的工作階段參數。通常是現有的工作階段參數。
newSessionParams
:由用戶端設定的新工作階段參數。
預期的傳回狀態碼如下:
OK
:成功重新設定所需的查詢。
METHOD_NOT_SUPPORTED
:攝影機裝置不支援重新設定查詢。
INTERNAL_ERROR
:由於發生內部錯誤,因此無法完成重新設定查詢。
傳回值如下:
true
:需要重新設定串流。
false
:不需要重新設定串流。
如要忽略工作階段重新設定查詢,HAL 會傳回 METHOD_NOT_SUPPORTED
或 false
。這會導致預設相機服務行為,在每次工作階段參數變更時觸發串流重新設定。
驗證
您可以使用 CameraHidlTest#configureStreamsWithSessionParameters
中的 VTS 測試案例,驗證工作階段重新設定查詢功能。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-26 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-07-26 (世界標準時間)。"],[],[],null,["# Session parameters\n\nThe session parameters feature reduces delays by enabling camera clients to\nactively configure the subset of costly request parameters, that is, session\nparameters, as part of the capture session initialization phase. With this\nfeature, your HAL implementations receive the client parameters during the\nstream configuration phase instead of the first capture request and can,\ndepending on their values, prepare and build the internal pipeline more\nefficiently.\n\nIn Android 10, you can improve performance by using\nthe optional session reconfiguration query feature for more control over the\ninternal session parameter reconfiguration logic. For more information, see\n[Session reconfiguration query](#session_reconfiguration_query).\n\nExamples and source\n-------------------\n\nA reference session parameter implementation is already part of the\n[CameraHal](https://android.googlesource.com/platform/hardware/qcom/camera/+/main/msm8998/QCamera2/HAL3/QCamera3HWI.cpp).\nThis HAL uses the legacy Hal API.\nThe [binderized](/docs/core/architecture/hal-types)\nCameraHal that implements the camera HIDL API must use the respective HIDL\n[sessionParams](https://android.googlesource.com/platform/hardware/interfaces/+/android16-release/camera/device/3.4/types.hal#111)\nentry to access any new incoming session parameters during stream configuration.\n\nCamera clients can query the keys of all supported session parameters by calling\n[`getAvailableSessionKeys()`](https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics#getAvailableSessionKeys())\nand eventually set their initial values through\n[`setSessionParameters()`](https://developer.android.com/reference/android/hardware/camera2/params/SessionConfiguration#setSessionParameters(android.hardware.camera2.CaptureRequest)).\n\nImplementation\n--------------\n\nYour CameraHal implementation must populate the\n[`ANDROID_REQUEST_AVAILABLE_SESSION_KEYS`](https://android.googlesource.com/platform/hardware/interfaces/+/android16-release/camera/metadata/3.3/types.hal#98)\nwithin the respective static camera metadata and provide a subset of\n[`ANDROID_REQUEST_AVAILABLE_REQUEST_KEYS`](https://android.googlesource.com/platform/hardware/interfaces/+/android16-release/camera/metadata/3.2/types.hal#1016),\nwhich contains a list of keys that are difficult to apply per-frame and can\nresult in unexpected delays when modified during the capture session lifetime.\n\nTypical examples include parameters that require a time-consuming hardware\nreconfiguration or an internal camera pipeline change. Control over session\nparameters can still be exerted in capture requests but clients should be aware\nof and expect delays in their app.\n\nThe framework monitors all incoming requests and if it detects a change in the\nvalue of a session parameter, it internally reconfigures the camera. The new\nstream configuration passed to CameraHal then includes the updated session\nparameter values, which are used to configure the camera pipeline more\nefficiently.\n\nCustomization\n-------------\n\nYou can define tags in the available session parameter list that is populated on\nthe CameraHal side. This feature is not active if CameraHal leaves the\navailable session parameter list empty.\n\nValidation\n----------\n\nCTS includes the following new cases for testing session parameters:\n\n- [`CameraDeviceTest#testSessionConfiguration`](https://android.googlesource.com/platform/cts/+/a3676a2dfa0630204be80a3c1f1cbbe6db2c3925/tests/camera/src/android/hardware/camera2/cts/CameraDeviceTest.java#793)\n- [`CameraDeviceTest#testCreateSessionWithParameters`](https://android.googlesource.com/platform/cts/+/a3676a2dfa0630204be80a3c1f1cbbe6db2c3925/tests/camera/src/android/hardware/camera2/cts/CameraDeviceTest.java#868)\n- [`CameraDeviceTest#testSessionParametersStateLeak`](https://android.googlesource.com/platform/cts/+/42f4eb187e216363208b96b726ec4287ce512231/tests/camera/src/android/hardware/camera2/cts/CameraDeviceTest.java#870)\n- [`NativeCameraDeviceTest#testCameraDevicePreviewWithSessionParameters`](https://android.googlesource.com/platform/cts/+/a3676a2dfa0630204be80a3c1f1cbbe6db2c3925/tests/camera/libctscamera2jni/native-camera-jni.cpp#2140)\n\nIn general, after a certain parameter is part of the session key list, its\ncurrent value is included as part of the session parameters passed during stream\nconfiguration at the HAL layer.\n\nSession parameters must be carefully selected. The values shouldn't change\nfrequently, if at all, between stream configurations. Parameters that change\nfrequently, such as capture intent, are ill-suited and adding them to the\nsession parameter list could cause CTS failures due to excessive internal\nre-configuration.\n\nSession reconfiguration query\n-----------------------------\n\nAndroid 10 introduces an optional session\nreconfiguration query feature to\nimprove performance as internal stream reconfigurations resulting from session\nparameter value modifications can reduce performance. To address this concern,\nHIDL\n[`ICameraDeviceSession`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/camera/device/3.5/ICameraDeviceSession.hal)\nversion 3.5 and higher supports the\n[`isReconfigurationRequired`](https://android.googlesource.com/platform/hardware/interfaces/+/22eac5f667dfca8de336ddc45ad60a08250f6b30/camera/device/3.5/ICameraDeviceSession.hal#146)\nmethod, which provides fine-grained control over the internal session parameter\nreconfiguration logic. Using this method, stream reconfiguration can occur\nprecisely when required.\n\nThe arguments for `isReconfigurationRequired`\nprovide the required information about every pending session parameter\nmodification, allowing for various kinds of device-specific customizations.\n\nThis feature is implemented only in the camera service and the camera HAL. There\nare no public-facing APIs. If this feature is implemented, camera clients should\nsee performance improvements when working with session parameters.\n\n### Implementation\n\nTo support session reconfiguration queries, you must implement the\n[`isReconfigurationRequired`](https://android.googlesource.com/platform/hardware/interfaces/+/22eac5f667dfca8de336ddc45ad60a08250f6b30/camera/device/3.5/ICameraDeviceSession.hal#146)\nmethod to check whether complete stream reconfiguration is required for new\nsession parameter values.\n\nIf the client changes the value of any advertised session parameter, the camera\nframework calls the `isReconfigurationRequired`\nmethod. Depending on the specific values, the HAL decides whether a complete\nstream reconfiguration is required. If the HAL returns `false`, the camera\nframework skips the internal reconfiguration. If the HAL returns `true`, the\nframework reconfigures the streams and passes the new session parameter values\naccordingly.\n\nThe `isReconfigurationRequired` method can be called by the framework some time\nbefore a request with new parameters is submitted to the HAL, and the request\ncan be cancelled before it is submitted. Therefore, the HAL must not use this\nmethod call to change its behavior in any way.\n\nThe HAL implementation must meet the following requirements:\n\n- The framework must be able to call the `isReconfigurationRequired` method at any time after active session configuration.\n- There must be no impact on the performance of pending camera requests. In particular, there must not be any glitches or delays during normal camera streaming.\n\nThe device and HAL implementation must meet the following performance\nrequirements:\n\n- Hardware and software camera settings must not be changed.\n- There must be no user-visible impact on camera performance.\n\nThe `isReconfigurationRequired`\nmethod takes the following arguments:\n\n- `oldSessionParams`: Session parameters from the previous session. Usually the existing session parameters.\n- `newSessionParams`: New session parameters that are set by the client.\n\nThe expected return status codes are:\n\n- `OK`: Successful reconfiguration required query.\n- `METHOD_NOT_SUPPORTED`: The camera device doesn't support the reconfiguration query.\n- `INTERNAL_ERROR`: The reconfiguration query can't complete due to an internal error.\n\nThe return values are:\n\n- `true`: Stream reconfiguration is required.\n- `false`: Stream reconfiguration isn't required.\n\nTo ignore a session reconfiguration query, the HAL returns\n`METHOD_NOT_SUPPORTED` or `false`. This results in the default camera service\nbehavior where stream reconfiguration is triggered on each session parameter\nchange.\n\n### Validation\n\nThe session reconfiguration query feature can be validated using the VTS test\ncase in\n[`CameraHidlTest#configureStreamsWithSessionParameters`](https://android.googlesource.com/platform/hardware/interfaces/+/e18057b42f1698f33f34d14e86a53934bd337bb8/camera/provider/2.4/vts/functional/VtsHalCameraProviderV2_4TargetTest.cpp#2653)."]]