Android Thermal HAL如何实现温控降频？

Android的温控机制并不是由某个单一进程完成的，而是跨越了内核驱动、HAL层、Native服务以及Java Framework的多级协作。其中Thermal HAL处于承上启下的位置，它向上接收来自ThermalService的监控与配置请求，向下通过sysfs节点或内核接口读取温度、下发限频指令。理解Thermal HAL的工作方式，是排查设备在游戏、视频录制等高负载场景下突然卡顿或掉帧的关键一步。

Thermal HAL在系统中的角色与启动流程

在Android的HAL分层设计中，Thermal HAL属于硬件抽象层中与传感器和电源管理密切相关的模块。它的主要职责是屏蔽不同SoC厂商在温控实现上的差异，向Framework提供统一的接口。Google在AOSP中定义了thermal HAL的接口规范，通常位于hardware/interfaces/thermal目录下，版本从1.0逐步演进到2.0及更高版本。HAL模块以动态库的形式存在，文件名多为thermal.default.so或由厂商自定义，由hwservicemanager在系统启动时根据manifest声明进行加载。

Thermal HAL启动后，会先扫描系统中可用的温度传感器。扫描的逻辑通常通过读取/sys/class/thermal/目录下的thermal_zone节点来实现。每个thermal_zone对应一个温度传感器或温度聚合点，节点中包含type、temp、trip_point等属性文件。例如，/sys/class/thermal/thermal_zone0/temp中存放的是整数值，通常需要除以1000得到摄氏度。HAL会为每个zone维护一个结构体，记录其类型（如cpu、gpu、battery、skin等）、当前温度、上一次温度以及关联的降温设备。

除了温度传感器，Thermal HAL还需要管理降温设备（cooling device）。降温设备通常位于/sys/class/thermal/cooling_device目录下，每个cooling_device可以对应一个CPU簇、GPU、充电芯片或风扇。通过向cur_state节点写入不同档位，可以限制对应硬件的工作能力。例如，写入cooling_device0/cur_state = 2可能表示将某个CPU大核的最大频率限制在其最高频率的60%。HAL需要建立传感器与降温设备之间的映射关系，这种映射有时通过静态配置表，有时通过解析设备树节点获得。

温控降频的判断逻辑与限频策略

温控降频的核心在于温度阈值判断与降温设备状态调整。Thermal HAL内部通常会运行一个监控线程，周期性读取各温度传感器的数值，并与预设的阈值表进行比较。阈值表可以是从配置文件加载的，也可以是编译期硬编码的。例如，对于CPU传感器，可能设置几个档位：温度低于60摄氏度时不限制；60到75摄氏度之间将大核频率限制在2.0GHz；75到85摄氏度时限制到1.5GHz并启动小核限频；超过85摄氏度则进入紧急状态，可能直接触发关核或系统弹窗提示。

一个典型的温度监控循环可以用以下伪代码表示，它展示了HAL如何根据当前温度计算目标档位并下发给内核：

while (running) {
    for (int i = 0; i < zone_count; i++) {
        int temp = read_temp(zone[i].temp_path);
        int target_state = 0;
        for (int j = 0; j < zone[i].trip_count; j++) {
            if (temp >= zone[i].trips[j].threshold) {
                target_state = zone[i].trips[j].cooling_state;
            } else {
                break;
            }
        }
        if (target_state != zone[i].current_state) {
            write_cooling_state(zone[i].cooling_device, target_state);
            zone[i].current_state = target_state;
            notify_framework(zone[i].type, temp, target_state);
        }
    }
    usleep(POLL_INTERVAL_US);
}

上述代码中，target_state的确定采用“最高满足条件”的方式，也就是从低到高遍历阈值，只要温度超过某个档位就将目标状态更新为该档位，这样当温度跨越多档时，最终状态对应于最高的限制档位。这种方案适合单调上升的温度趋势，但在温度快速回落时需要加入迟滞机制，避免限频状态在阈值附近来回抖动。迟滞通常在阈值判断时引入一个小的回退区间，比如上升到75度时触发限频，但需要降温到72度以下才解除该档位。

限频的粒度直接影响用户体验。如果只是限制CPU最高频率，游戏帧率可能平滑下降；但如果还涉及关核或限制GPU频率，画面卡顿会非常明显。有些厂商的Thermal HAL会实现更细粒度的策略，比如根据当前前台应用类型动态调整温控目标。例如视频播放时优先保证屏幕亮度与音频不中断，可以接受轻度降频；而在游戏场景中则尝试通过阶梯式降频维持帧率稳定，而不是一次性将频率压到最低。

与Framework层的交互及回调处理

Thermal HAL并不是独立工作的，它需要向Java层的ThermalService报告温度变化和限频事件。在HIDL或AIDL接口中，通常定义了registerThermalCallback和getCurrentTemperatures等方法。HAL通过回调将每个温度传感器的当前温度和降温状态上报给Framework，ThermalService再根据这些信息决定是否需要通知应用层，比如广播ACTION_THERMAL_EVENT或触发系统UI显示过热提示。

在Android 10及更高版本中，Framework还引入了ThermalManagerService，应用可以通过PowerManager的addThermalStatusListener接口监听热状态变化。HAL上报的温度与档位会被映射为轻度、中度、严重等不同等级，这些等级进一步影响系统调度策略。例如当HAL报告皮肤温度过高并已将CPU限频到较低档位时，SurfaceFlinger可能会降低合成帧率，ActivityManager也可能延迟后台任务执行。回调的数据结构必须严格符合接口定义，否则会出现上层收不到事件但内核已经限频的情况。

以下是一个在HAL实现中通过回调上报温度变化的示例片段，其中使用了HIDL的回调对象：

void ThermalImpl::notifyTemperatureChange(int type, float temp, int state) {
    std::lock_guard<std::mutex> lock(callback_mutex_);
    if (callback_ != nullptr) {
        Temperature temp_msg;
        temp_msg.type = static_cast<TemperatureType>(type);
        temp_msg.value = temp;
        temp_msg.status = static_cast<CoolingStatus>(state);
        std::vector<Temperature> temps {temp_msg};
        auto ret = callback_->onTemperatureChanged(temps);
        if (!ret.isOk()) {
            ALOGE("Failed to notify temperature change");
        }
    }
}

HAL实现中还可能包含对虚拟温度传感器的支持。例如有些设备没有独立的GPU温度传感器，而是通过CPU温度和GPU负载模型估算一个虚拟GPU温度。这种实现需要在HAL中维护一个简单的热模型，根据负载和当前环境温度计算估计值，并同样通过回调上报。最终目标是让上层决策逻辑不感知底层传感器缺失，保持策略代码的统一。

在配置温控策略时，厂商通常会在设备树或单独的thermal配置文件（如thermal-engine.conf、thermal_info_config.json）中定义阈值表。HAL在初始化时解析这些文件，将阈值和降温设备映射加载到内存中。修改这些配置不需要重新编译HAL，只需要重启相关服务或推送新配置即可生效，这为产线调试和售后优化提供了便利。需要注意的是，配置中的阈值单位、温度换算系数以及状态值含义必须与HAL解析逻辑完全一致，否则可能出现限频过强或完全不起作用的问题。

Android Thermal HAL温控降频热管理修改时间：2026-08-24 19:22:49