自 2026 年起,为了与我们的主干稳定开发模型保持一致,并确保生态系统的平台稳定性,我们将在第 2 季度和第 4 季度向 AOSP 发布源代码。如需构建 AOSP 并为其贡献代码,请使用 android-latest-release。android-latest-release 清单分支将始终引用推送到 AOSP 的最新版本。如需了解详情,请参阅 AOSP 变更。
Google uses AI technology to translate content into your preferred language. AI translations can contain errors.
在暂停期间管理音频资源
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
为了确保系统稳定性以及进入低功耗状态(例如挂起到 RAM (S2R) 或挂起到磁盘 (S2D))的能力,在电源转换期间正确管理音频资源至关重要。
当系统启动挂起时,应用可能并不总是释放音频输入或输出流。活跃的音频流可能会阻止音频子系统和底层硬件进入空闲状态,这可能会阻止片上系统 (SoC) 进入深度睡眠状态。这会导致挂起尝试失败并增加功耗。
原始设备制造商 (OEM) 必须在其音频硬件抽象层 (HAL) 实现中实现强大的回退机制,以在挂起转换期间处理活跃的音频流。无论应用行为如何,这对于平台稳定性都至关重要。
应用应正确管理音频资源,但系统不能依赖此功能进行基本的电源状态转换。音频 HAL 是强制停用资源以确保系统能够进入挂起状态的适当层。我们建议采用这种方法来实现强大的电源管理。
实现电源管理
如需在音频 HAL 中实现强大的电源管理,请按以下步骤操作:
检测系统电源状态变化,尤其是向挂起状态的转换。
当系统准备挂起时,如果任何音频流(包括输入和输出)仍处于活跃状态,请进行干预:
- 释放硬件输出流并舍弃来自音频框架的传入数据。
- 释放硬件输入流并将静音音频发送到框架。
此 HAL 级操作可确保音频硬件能够进入空闲状态,让系统能够成功挂起,即使应用尚未释放其音频资源也是如此。
当系统从挂起状态恢复时,将音频子系统恢复到活跃状态。这包括取消之前静音的任何输出流的静音状态,以及重新激活输入流,让应用继续播放和捕获音频。
对应用的影响
在挂起期间,HAL 级音频资源管理会以以下方式影响应用:
- 透明挂起: 对于使用麦克风的应用,系统挂起(进入 S2D 或 S2R)是透明的。
- 转换期间的音频静音: 启动挂起转换后,活跃的流会在 HAL 中静音。应用会继续运行,但在挂起期间只会收到静音音频。
- 自动恢复: 系统恢复后,应用会自动再次开始接收或发送真实音频数据,而无需执行任何资源重新获取或恢复操作。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2026-06-18。
[[["易于理解","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):2026-06-18。"],[],[]]