设备开始过热时,需要进行热缓解。随着算法复杂性、系统核心频率和集成水平不断提高,而设备的形制和尺寸不断缩小,热缓解的重要性日益凸显。
Android 10 在 Android 框架中引入了热系统,以及一个新的 HAL 版本,用于将热子系统硬件设备的接口抽象化。硬件接口包括设备表面、电池、GPU、CPU 和 USB 端口的温度传感器和热敏电阻。为了确保设备表面温度不超过指定的热限制值,最重要的是跟踪设备表面温度。
借助该 Android 框架,设备制造商和应用开发者可以使用热数据来确保在设备开始过热时保持一致的用户体验。例如,当系统温度较高时,jobscheduler
作业会受到限制,如有必要,可启动框架热关机。通过注册的回调函数(位于 PowerManager
类中)接收高温通知的应用可妥善调整其用户体验。
Thermal HAL
Android 9 及更低版本利用 Thermal
HAL 1.0
中定义的轮询接口获取温度读数。旧版 Thermal HAL 允许 Android 框架和其他可信客户端(例如设备制造商的 HAL)通过同一 API 读取每个传感器的当前温度和产品政策特定的限制和关闭阈值。
Android 10 中引入了 Thermal HAL 2.0
,可为多个客户端提供热传感器读数及相关严重级别,以指示受热情况。图 1 显示了 2 条来自 Android 系统界面的警告消息,分别根据 USB_PORT 和 SKIN 传感器的 IThermalEventListener
创建(当两者达到 EMERGENCY
严重级别时)。
系统会通过 IThermal HAL 为不同
types
的热传感器检索当前温度。每个函数调用都会返回一个状态值:SUCCESS
或 FAILURE
。如果返回 SUCCESS
,进程将继续。如果返回 FAILURE
,status.debugMessage
中将记录一条错误消息,该消息必须简单易懂。
除了作为可返回当前温度的轮询接口之外,HIDL 回调
IThermalChangedCallback
可与 Thermal HAL 客户端中的回调接口一起使用,例如框架的热服务。例如,RegisterIThermalChangedCallback
和 UnregisterIThermalChangedCallback
可用于注册/取消注册严重级别发生改变的事件。如果指定传感器的热严重级别发生了变化,notifyThrottling
会向热事件监听器发送温控降频事件回调。
除了热传感器信息外,getCurrentCoolingDevices
还提供一个进行了缓解操作、正在冷却的设备的列表。即使某个冷却设备已离线,该列表顺序仍保持不变。设备制造商可以利用该列表收集 statsd
指标。
如需了解详情,请参阅参考实现。虽然您可以添加自己的扩展,但绝不能停用热缓解功能。
热服务
在 Android 10 中,框架中的热服务利用来自 Thermal HAL 2.0
的各种缓解信号不断进行监控,并向其客户端提供有关限制严重级别的反馈,其中包括内部组件和 Android 应用。该服务利用 2 个 Binder 回调接口,即作为回调提供的 IThermalEventListener
和 IThermalStatusListener
。前者适用于内部平台和设备制造商,而后者适用于 Android 应用。
通过回调接口,设备的当前热状态能够以整数值的形式检索到,该值的范围为 0x00000000
(未限制)到 0x00000006
(设备关机)。只有可信系统服务(例如 Android API 或设备制造商 API)才能访问详细的热传感器和热事件信息。图 2 介绍了 Android 10 中热缓解处理流程的模型。
设备制造商使用准则
设备制造商必须实现 Thermal HAL 2.0 的 HIDL 方面(如 IThermal.hal
中所提供),以便报告设备温度传感器和限制状态。如果您是开发者,可利用此实现增强应用在高温状态下的用户体验。
限制设备性能的任何因素(包括电池电量限制)都必须通过 Thermal HAL 进行报告。为确保做到这一点,请将可能会指示需要进行缓解操作(根据状态变化)的所有传感器放入 Thermal HAL,并报告所采取的任何缓解操作所对应的严重级别。从传感器读数返回的温度值不一定是实际温度,只要它准确反映相应的严重级别阈值即可。例如,您可以传递不同的数值而非实际温度阈值,也可以在阈值规范中建立保护带以提供迟滞功能。不过,与该值对应的严重级别必须与在相应阈值所需达到的级别一致。(例如,当现实中实际温度为 65°C,且该温度的严重级别对应于您指定的“严重”时,您可以考虑返回 72°C 作为临界温度阈值。)严重级别必须始终准确无误,以便充分发挥热框架的功能。
如需详细了解框架中的阈值级别及其如何与各缓解操作一一对应,请参阅每个热状态代码的用法建议。
Thermal API
应用可以通过
PowerManager
类来添加和移除监听器以及获取热状态信息。IThermal
接口提供了所需的所有功能,包括返回热状态值。
IThermal binder interface
封装为 OnThermalStatusChangedListener
接口,供应用在注册或移除热状态监听器时使用。
Android Thermal API 提供了回调和轮询这两种方法,以便通过在 PowerManager
类中定义的状态代码将热严重级别告知应用。这些方法包括:
getCurrentThermalStatus()
,以整数形式返回设备的当前热状态(除非该设备正处于受限状态)。addThermalStatusListener()
,添加监听器。removeThermalStatusListener()
,移除之前添加的监听器。
状态代码可转化为具体的限制级别,用于收集数据和设计最佳用户体验。例如,应用可能会收到 0x0 (NONE) 状态,该状态稍后可能会更改为 0x1 (LIGHT)。将 0x0 状态标记为 t0,然后衡量从状态 NONE 更改为状态 LIGHT (t1) 所经过的时间,这样一来,设备制造商就能针对特定用例设计和测试缓解策略。您可能需要按照以下建议的方法使用热状态代码。
热状态代码 | 说明和建议用法 |
---|---|
NONE (0x0) | 未限制。 此状态代码可用于实施保护操作,例如,检测从 NONE (0x0) 到 LIGHT (0x1) 的时间段(从 t0 到 t1)的起始时间。 |
LIGHT (0x1) | 轻微限制。用户体验不受影响。 在此阶段,请对设备采取温和的缓解操作。例如,不要提频或采用低效频率(仅适用于大核心)。 |
MODERATE (0x2) | 中等限制。用户体验没有受到很大影响。 执行的热缓解操作会影响前台 activity,因此应用应立即减少耗电量。 |
SEVERE (0x3) | 严重限制。用户体验在很大程度上受到影响。 在此阶段,设备热缓解措施应该会限制系统容量。这可能会导致显示卡顿和音频抖动等负面影响。 |
CRITICAL (0x4) | 平台已采取一切措施减少耗电量。 设备热缓解软件已经以最低容量运行所有组件。 |
EMERGENCY (0x5) | 平台中的关键组件因热状况而即将关闭。 设备功能受限。这是系统在设备关机前发出的最后一次警告。在此阶段,调制解调器和移动数据网络等一些功能会完全关闭。 |
SHUTDOWN (0x6) | 立即关机。 鉴于此阶段的严重级别,应用可能无法收到此通知。 |
API 测试
设备制造商必须通过 Thermal HAL 的 VTS 测试,并且可以使用 kernel sysfs
接口中的 emul_temp
模拟温度变化。