Has the Pixel 10 Series Heating Issue Finally Addressed?

Ever since Google decided to ditch Qualcomm in favor of Tensor [Pixel 6 series onwards], it has been plagued with a lot of issues. Among them, it’s the heating issue that has impacted the device the most, right along with the modem. However, with the Pixel 10 series, Google decided to ditch Samsung’s Exynos as the chipset manufacturer and jumped ship over to TSMC. As a result of this, there were high hopes that these issues would now finally be put to rest.

Unfortunately, these assumptions seem to have been just speculations, because in reality, things aren’t looking great. Within a week after users got their hands on the latest Pixel flagships, forums were flooded with the same old reports – network, modem, and performance issues coupled with the device’s overheating. However, it seems the latter issue might finally be a thing of the past, as a developer has managed to find a breakthrough [or is that really the case?]. Let’s find out:

  • What’s the Reason Behind the Pixel 10 Series Overheating?
  • What’s the Fixing Mechanism Put in Place?
  • Does It Really Work? What’s the Risk?
  • So Let’s Try to Implement this Pixel 10 Overheating ‘Fix’

What’s the Reason Behind the Pixel 10 Series Overheating?

In the stock Android 16 firmware for the Pixel 10 Pro, the PollingDelay for critical thermal sensors is incorrectly set to 300,000ms (5 minutes). This creates a massive “blind spot” in the system’s thermal management. During heavy workloads, the CPU can hit 90°C+ before the Thermal HAL even attempts to sample the temperature, leading to heat soak and potential long-term battery degradation. -Developer marx161 on GitHub

According to the developer, the device only tends to check for overheating after a full 5-minute time period has elapsed. This proves to be a long delay, as during that time frame, the CPU temperature can go as high as 90°C before the device can implement the required cooling mechanism. The stock configuration effectively disables real-time thermal management for burst workloads. By the time the 300s timer expires, the device has already reached thermal saturation.

What’s the Fixing Mechanism Put in Place?

Well, most of you might have already guessed the fix- it involves lowering the overheating check from the current 5-minute mark. In this regard, the developer has created a module that will instruct the device to carry out this check every 5 seconds, theeby not lettingthe device reach the high level of thermal saturation. Here are the tweaks his module will perform:

  • Reduces Polling Delay : Sets PollingDelay to 5,000ms for the VIRTUAL-SKIN* sensors across thermal_info_config.json, thermal_info_config_throttling.json, and thermal_info_config_charge.json.
  • Keeps OEM thresholds : Restores the original HotThreshold, CdevCeilingFrequency, and Profile data so only the sampling cadence changes.
  • Retains Hysteresis & Passive Delay : Keeps the default PassiveDelay (7,000ms) and HotHysteresis values to avoid oscillating CPU-frequency decisions even as the sensor updates faster.
  • Moreover, /vendor/etc/ thermal_info_config_throttling.json and thermal_info_config_charge.json will inherit the same 5s polling cadence , so the HAL cannot revert to the 300s delay through the included files.

Does It Really Work? What’s the Risk?

pixel 10 series overheating - 1

Well, first off, I don’t think Google isn’t aware of the fact that they can lower down the time frame from 5 minutes to 5 seconds to cool down the device ‘faster’. However, they haven’t done so because thermal management requires both the heat and speed to be dealt with in a balanced manner. You cannot just push the time to the absolute extreme, assuming that the device will cool down much faster [theoretically it could, but practically it might lead to both performance and battery degradation].

It could also be that the Silicon Valley giant has deliberately kept this time limit to sustain peak performance for longer durations before the role of throttling comes into the frame. Moreover, I am not questioning the credibility of this developer, but to date, he is the only one to come forward with this finding. I couldn’t find any other such report from any other dev from the last 5+ years.

So either this breakthrough deserves a standing ovation, or it is something that others already know of before but decided not to implement or bring it forward due to the risks involved. Still, the developer does deserve credit for his findings, though only time will tell how fruitful it turned out to be. Anyways, if you are willing to test out his fix, then fasten your seatbelts and let’s get started on this quick journey [it’s going to be less than 5 seconds!].

So Let’s Try to Implement this Pixel 10 Overheating ‘Fix’

Before starting, please take a complete device backup. Moreover, the module modifies system thermal parameters, so use it at your own risk. Droidwin and its members wouldn’t be held responsible in case of a thermonuclear war, your alarm doesn’t wake you up, or if anything happens to your device and data by performing the below steps.

Update from Developer : A recent background Google Play System Update (January 2026) has introduced SELinux policy changes that may cause this thermal fix to trigger a bootloop. I am currently investigating the conflict and will update this repository with a fix as soon as possible. Use with extreme caution for now. Update from Droidwin : If you are still planning on using this module, then install the Magisk Bootloop Protector module beforehand. Also, here are a few additional resources that will come in handy: Fix Magisk Module Bootloop without TWRP Recovery | How to Fix Magisk Bootloop using TWRP Recovery.

  1. First off, root your device via Magisk / KernelSU / APatch .
  2. Now download the Pixel-10-Thermal-Fix.zip and flash it.
  3. Finally, restart your device for the changes to take place.

Here’s how you can verify if the time frame has been reduced from 5 minutes to 5 seconds:

  1. Install Termux and give it root access. Then type in the below command: cat /vendor/etc/thermal_info_config.json | grep -A 15 “VIRTUAL-SKIN-CPU-LIGHT-ODPM” # Ensure “PollingDelay” is now 5000.
  2. Likewise, use the commands below to verify the included files as well: cat /vendor/etc/thermal_info_config_throttling.json | rg -n “VIRTUAL-SKIN-CPU-LIGHT-ODPM” -C2 cat /vendor/etc/thermal_info_config_charge.json | rg -n “PollingDelay” -C1
Google preferred - 2

(Cancel Reply)

Δ