摺疊式裝置和相機
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
注意:本頁面所述是指 Camera2 套件。除非應用程式需要 Camera2 的特定低階功能,否則建議使用 CameraX。CameraX 和 Camera2 均支援 Android 5.0 (API 級別 21) 以上版本。
相機開發人員在開發在折疊式裝置上執行的相機應用程式時,可能會遇到特殊的挑戰。與智慧型手機不同,摺疊式裝置可能具有不同的板型規格、顯示版面配置和相機組合,因此與螢幕方向、相機方向和相機方向相關的假設通常不太準確。
智慧型手機的相機通常會以與螢幕相符的直向方向拍攝。不過,某些可折疊狀態可能不符合這個情況。展開的螢幕可能會有一個直向感應器和一個橫向感應器。
如果相機應用程式使用 SurfaceTexture
或自訂轉譯管道,請注意相機感應器方向。
這可確保算繪內容一律以直立方式顯示,且像素保持方形,避免在水平或垂直方向上拉長。
本指南將說明 Camera2 開發人員需要考量的事項,以及調整相機預覽算繪畫面以因應不同折疊式裝置狀態的步驟。
裝置狀態切換對攝影機的影響
折疊式裝置可能包括:
這些裝置的啟用狀態取決於裝置狀態。為簡化裝置狀態處理作業,某些裝置會實作邏輯相機,由兩個或更多實體感應器組成。
如果開發人員在這種邏輯相機裝置上開啟並啟用預覽串流功能,相機會自動切換實體裝置,以回應特定折疊狀態。
舉例來說,假設有兩個螢幕的折疊式裝置:
- 摺疊狀態下的一般直向螢幕,實體「外部」前置鏡頭以直向方向顯示。
- 在展開狀態下啟用的摺疊式螢幕,其中包含「內部」前置實體相機,相機與展開螢幕的方向為橫向。
當使用者在應用程式從前置邏輯相機串流時折疊或展開裝置時,裝置實作可能會在內部和外部實體感應器之間切換,以回應每個裝置狀態切換。
顯示切換鈕可能需要應用程式調整其 UI。
除了調整 UI 之外,開發人員可能還需要考慮調整相機預覽畫面,以便針對實際運作的相機進行轉譯。
實體相機裝置切換裝置
邏輯相機裝置介面會提供必要的 API,用於處理實體相機切換。開發人員必須監控有效實體 ID 的值。
在折疊式裝置上,有效的實體 ID 擷取結果會隨折疊和展開等不同折疊式狀態切換而變更。
在這種情況下,開發人員必須使用目前有效的實體 ID,並檢查相應的相機特性。
感應器方向和鏡頭朝向是兩項可能會變更且會影響預覽算繪的最重要的相機特性。
如果應用程式的預覽算繪管道需要使用靜態相機參數來計算最終轉換矩陣,請務必傳遞目前的值並更新圖形轉換。
如要進一步瞭解相機預覽管道和轉換計算方式,請參閱相機預覽指南。
其他無效的假設
我們不建議快取相機特徵值。
您不能假設攝影機特性會保持不變,因為裝置在折疊或展開時,特性可能會有所不同。因此,請勿儲存及重複使用相機特性。請改為每次檢查攝影機特性。
請考慮以下情況:相機應用程式在外側前置螢幕上啟動,並快取目前的前後置鏡頭特性。如果應用程式在內螢幕上重新啟動,則有效的前端實體感應器可能會採用不同的方向,可能會觸發不必要的預覽算繪副作用。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","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-27 (世界標準時間)。"],[],[],null,["# Foldable devices and cameras\n\n**Note:** This page refers to the [Camera2](/reference/android/hardware/camera2/package-summary) package. Unless your app requires specific, low-level features from Camera2, we recommend using [CameraX](/camerax). Both CameraX and Camera2 support Android 5.0 (API level 21) and higher.\n\n\u003cbr /\u003e\n\nCamera developers might encounter unique challenges when working on camera\napplications that run on foldable devices. Unlike smartphones, where several\nassumptions related to display orientation, camera orientation, and facing are\noften valid, foldable devices can have diverse form factors, display layouts,\nand camera combinations.\n\nSmartphones commonly have cameras with portrait orientation\nmatching the display. However, this may not be true for certain foldable states.\nAn unfolded screen might have one sensor with portrait orientation and another\nsensor with landscape orientation.\n\nIf your camera application uses a [`SurfaceTexture`](/reference/android/graphics/SurfaceTexture) or a\ncustom rendering pipeline, be aware of the camera sensor orientation.\n\nThis ensures that rendered content is always physically upright and pixels\nremain square, avoiding stretching in horizontal or vertical directions.\n\nThis guide provides information on what Camera2 developers need to consider\nand the steps to adjust camera preview rendering for different foldable device\nstates.\n\nHow device state switches affect cameras\n----------------------------------------\n\nFoldable devices may include:\n\n- Two or more physical displays\n- Several physical camera devices\n\nThese devices can become active depending on the device state. To simplify\ndevice state handling, certain devices implement a logical camera that consists\nof two or more physical sensors.\n\nIf developers open and enable preview streaming on such a logical camera\ndevice, the camera automatically switches between physical devices in response\nto specific fold states.\n\nFor example, consider a foldable device with two displays:\n\n- A regular portrait screen in folded state with a physical 'outer' front camera in portrait orientation.\n- A foldable screen enabled in unfolded state with an 'inner' front physical camera with landscape orientation relative to the unfolded display.\n\nWhen the user folds or unfolds the device while an application streams from\nthe front logical camera, the device implementation may switch between the\ninner and outer physical sensors in response to each device state switch.\n\nThe display switch may require the application to adjust its UI.\n\nAlong with any UI adjustments, developers may need to consider adjusting how\nthe camera preview renders with regard to the active physical camera.\n\nPhysical camera device switches\n-------------------------------\n\nThe logical camera device interface provides the necessary APIs to handle\nphysical camera switches. Developers must monitor the value of the\n[active physical id](/reference/kotlin/android/hardware/camera2/CaptureResult#logical_multi_camera_active_physical_id).\n\nOn foldable devices the active physical ID capture result can change in response\nto different foldable state switches like folding and unfolding.\n\nIn such events, developers must use the current active physical ID and check the\ncorresponding [camera characteristics](/reference/kotlin/android/hardware/camera2/CameraCharacteristics).\n\nThe two most important camera characteristics that can potentially change\nand affect preview rendering are the [sensor orientation](/reference/kotlin/android/hardware/camera2/CameraCharacteristics#sensor_orientation)\nand the [lens facing](/reference/kotlin/android/hardware/camera2/CameraCharacteristics#lens_facing).\n\nIf your application's preview rendering pipeline depends on static camera\nparameters to calculate its final transformation matrix, ensure that you pass\nthe current values and update the graphics transformations.\n\nFor a deeper understanding of camera preview pipelines and how transformations\nare calculated, consult the [camera preview guide](/media/camera/camera2/camera-preview).\n\nAdditional invalid assumptions\n------------------------------\n\nCaching of camera characteristic values is not recommended.\n\nYou can't assume that camera characteristics will remain constant, since the\ncharacteristics can change when the device is folded or unfolded. For that\nreason, you shouldn't store and reuse camera characteristics. Instead, check\nthe camera characteristics each time.\n\nConsider the case where a camera application starts on the outer front\ndisplay and caches the current front and back camera characteristics. If the\napplication restarts on the inner display, the active front physical\nsensor may have a different orientation, potentially triggering unwanted preview\nrender side effects."]]