可折叠设备和相机
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
注意:本页介绍的是 Camera2 软件包。除非您的应用需要 Camera2 中的特定低级功能,否则我们建议您使用 CameraX。CameraX 和 Camera2 都支持 Android 5.0(API 级别 21)及更高版本。
在开发可在可折叠设备上运行的相机应用时,相机开发者可能会遇到独特的挑战。与智能手机不同,智能手机通常可以假定与显示屏方向、摄像头方向和朝向相关的几项假设,但可折叠设备可能具有多种外形规格、显示屏布局和摄像头组合。
智能手机的相机通常与显示屏保持一致的纵向方向。不过,对于某些可折叠状态,情况可能并非如此。展开的屏幕可能有一个传感器的屏幕方向为纵向,另一个传感器的屏幕方向为横向。
如果您的相机应用使用 SurfaceTexture
或自定义渲染流水线,请注意摄像头传感器方向。
这样可确保渲染的内容始终垂直显示,像素保持方形,避免水平或垂直方向的拉伸。
本指南介绍了 Camera2 开发者需要考虑的事项,以及针对不同可折叠设备状态调整相机预览渲染的步骤。
设备状态切换对摄像头的影响
可折叠设备可能包括:
这些设备可能会变为活跃状态,具体取决于设备状态。为了简化设备状态处理,某些设备会实现由两个或更多物理传感器组成的逻辑摄像头。
如果开发者在这种逻辑摄像头设备上打开并启用预览流式传输,相机会根据特定折叠状态在物理设备之间自动切换。
例如,假设有一款具有两个显示屏的可折叠设备:
- 折叠状态下的常规纵向屏幕,其中物理“外置”前置摄像头处于纵向模式。
- 在展开状态下启用的可折叠屏幕,其中包含相对于展开显示屏处于横向模式的“内部”前置实体摄像头。
当用户在应用从前置逻辑摄像头流式传输数据时折叠或展开设备时,设备实现可能会在内部和外部实体传感器之间切换,以响应每次设备状态切换。
显示屏切换可能需要应用调整其界面。
除了任何界面调整之外,开发者可能还需要考虑调整相机预览针对有效物理摄像头的呈现方式。
实体相机设备开关
逻辑摄像头设备接口提供了处理实体摄像头开关所需的 API。开发者必须监控有效的物理 ID 的值。
在可折叠设备上,有效的物理身份证件拍摄结果可能会因不同的可折叠状态切换(例如折叠和展开)而发生变化。
在这种情况下,开发者必须使用当前有效的物理 ID 并检查相应的摄像头特性。
可能发生变化并影响预览呈现的两个最重要的相机特性是传感器方向和镜头朝向。
如果应用的预览渲染流水线依赖于静态相机参数来计算其最终转换矩阵,请确保传递当前值并更新图形转换。
如需深入了解相机预览流水线以及如何计算转换,请参阅相机预览指南。
其他无效假设
不建议缓存摄像头特性值。
您不能假定相机特性会保持不变,因为这些特性可能会在设备折叠或展开时发生变化。因此,您不应存储和重复使用相机特性。而是每次都检查相机特性。
假设相机应用在外屏上启动,并缓存当前的前置和后置摄像头特性。如果应用在内部显示屏上重启,处于活动状态的前置物理传感器可能具有不同的屏幕方向,可能会触发不必要的预览渲染副作用。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):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"]],["最后更新时间 (UTC):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."]]