A phone that gets hot will slow itself down to protect its hardware. That slowdown is not random and it is not a fault in most cases. It follows a set of thermal tables that map temperature readings to limits for processor speed and charging and screen brightness. When you understand those tables you can explain why a game runs fast for ten minutes and then drops in frame rate.
A custom kernel lets a developer change those tables on a device that they own. That power is useful for testing and for learning how thermal policy works. It is also risky when used without care. A table that allows too much heat for too long can damage a battery or shorten the life of a chip. Safety must come before performance in every change that you make.
This guide explains thermal management tables in plain terms and it shows a careful method for testing changes. Work only on a device that you own and keep a full backup before you flash anything. Do not apply a table from another device model to your phone. Hardware differs between models and a wrong table can cause overheating or an unstable boot.
What a thermal table actually contains
A thermal table is a list of thresholds and actions. A sensor reports a temperature for the processor or the battery or the skin of the phone. The table says what to do when that reading crosses a value. At a low threshold the system may only warn an app. At a higher threshold it may lower the maximum processor frequency. At a still higher threshold it may dim the screen or pause charging or shut the device down.
Tables often use several sensors at once. The processor sensor may rise fast during a game while the battery sensor rises more slowly. The skin sensor matters for comfort because a phone that feels too hot in the hand is a bad experience even if the chip is still safe. A good table balances chip safety and battery safety and user comfort. A bad table focuses on only one of those goals and ignores the others.
How throttling shows up in daily use
Throttling rarely announces itself with a clear message. A game may lose frames after a long session. A video export may take longer on a second run than on a first run. Charging may slow down on a warm day even with the same charger. Those symptoms point to thermal policy when they appear after heat builds up and disappear after the phone cools down.
Test for throttling with a repeatable workload. Run the same benchmark or the same game scene for twenty minutes and record frame rate every minute. Record temperature readings at the same times if your kernel exposes them. A sharp drop that lines up with a temperature threshold is strong evidence of a thermal limit. A gradual drop without a temperature change points to a different cause such as a battery saver setting.
Reading a kernel thermal source safely
Start by finding the thermal configuration for your exact device model and kernel version. Look for files that mention trip points and cooling devices and sensor names. A trip point is a temperature value that triggers an action. A cooling device is the part that the system can slow down such as a processor cluster or a graphics unit. Read the comments in the source because they often explain the intent behind a value.
Do not edit a value that you do not understand. A single number may control several behaviours through a chain of rules. Change one threshold by a small amount and test the result before you change anything else. Keep the original file in a safe place so you can restore it fast. A careful developer keeps a log of every change with the date and the reason and the test result.
Check how the kernel reports temperature. Some sensors report in millidegrees and some report in whole degrees. A value of 45000 may mean 45 degrees rather than a huge temperature. Misreading the unit is a classic error and it can lead to a table that never triggers or triggers far too early. Confirm the unit from the source before you edit a threshold.
A safe testing method for your own device
Test in a cool room with the phone on a hard surface and not inside a thick case. A case traps heat and changes the result. Remove the case for thermal tests so the phone can cool as the maker intended. Keep the phone away from direct sunlight and away from a heater. Those simple controls make your results repeatable across days.
Run a short test first and watch temperature closely. Stop the test if the battery temperature rises fast or if the phone feels uncomfortably hot. A safe test does not push the phone to its shutdown limit. You want to see where throttling starts and not where the phone gives up. Record the start temperature and the peak temperature and the time when throttling began.
Compare the stock table with your changed table under the same workload. Use the same app and the same duration and the same room conditions. A fair comparison needs identical conditions. If your changed table gives higher performance for the same peak temperature then the change may be useful. If it only gives higher performance by allowing much higher heat then the change is not worth the risk.
- Back up the stock kernel and the stock thermal table first.
- Test in a cool room with the phone out of its case.
- Change one threshold at a time by a small amount.
- Stop the test if the battery heats up unusually fast.
Code you can adapt
// Example thermal trip point structure for study only
// Values below are illustrative and must not be copied to a real device
struct thermal_trip {
int temperature_millidegree;
int max_cpu_frequency_khz;
const char *action;
};
struct thermal_trip trips[] = {
{ 45000, 2000000, "limit_cpu" },
{ 55000, 1500000, "limit_cpu_and_gpu" },
{ 65000, 0, "pause_charging" },
};The snippet above is an original example written for this guide. It shows the shape of a thermal trip table in a simplified form for study and it is not a table for any real phone.
The example shows how a table moves from a mild limit to a stronger limit as temperature rises. Real tables are longer and they use several sensors and several cooling devices. The principle stays the same. Each step trades a little performance for a lower temperature. A developer who understands that trade can tune a table with intent rather than by guessing.
Never flash a table that you found online without checking the device model and the kernel version. A table for a different chip can set limits that make no sense for your hardware. It can also leave a sensor without any protection. Build your table from your own device source and test it slowly. That method is slower but it keeps your phone safe.
How this topic connects to nearby work
Thermal slowdowns that reach users show up in the quality signals covered by Android Vitals metrics.
Temperature and throttling evidence is easier to find with the methods in the guide to Logcat advanced filtering.
A different kind of slowdown with a similar diagnosis method appears in the guide to Room database indexing optimization.
Putting it into practice
Battery temperature and processor temperature tell different stories during a long session. Processor temperature rises fast when a game loads the chip. Battery temperature rises slowly because the battery has more thermal mass. A table that watches only processor temperature may allow a battery to heat up unchecked during charging and gaming together. Check both sensors in your test logs. A table that respects both sensors gives a safer result for real use patterns.
Governor behaviour interacts with thermal tables in ways that confuse beginners. A governor chooses processor frequency based on load while a thermal table sets a maximum frequency based on temperature. When both systems act at once the lower limit wins. A test that changes only the governor may show no benefit because the thermal limit still caps speed. Change one system at a time and record which limit was active during the test. That record explains results that otherwise look random.
A final thermal check should include a recovery test after throttling begins. Stop the workload when throttling starts and measure how long the phone takes to return to full speed. A phone that recovers quickly after cooling is behaving normally. A phone that stays slow long after cooling may have a different problem such as a battery saver lock or a background task. Record recovery time alongside peak temperature in your test notes. Recovery behaviour is part of thermal health and it deserves the same attention as peak performance.
Common mistakes
A common mistake is to raise every threshold at once to chase benchmark scores. That approach removes the safety net that protects the battery. A short benchmark may look better while a long gaming session becomes unsafe. Raise one threshold by a small step and test a long session before you judge the result.
Another mistake is to test only in a cold room and then use the phone in a hot place. A table that works in winter may fail in summer. Test in realistic conditions and leave a safety margin for warm weather. A margin of a few degrees costs little performance and adds real protection.
A third mistake is to ignore charging heat. Charging adds heat on top of processor heat. A phone that games while charging heats up from both sources at once. Test gaming and charging together if that is how you use the phone. A table that ignores charging may allow a dangerous combination.
Frequently asked questions
Why does my phone slow down only after long gaming sessions?
Heat builds up slowly during a long session. Early minutes stay below the first trip point so performance stays high. Later minutes cross a threshold and the table lowers processor speed. Cooling the phone down should restore performance if thermal policy is the cause.
Can a custom thermal table damage my phone?
Yes when thresholds are set too high or when a sensor is left without protection. Heat damages batteries over time and it can harm other parts. Keep changes small and keep all safety limits in place. Stop testing if temperatures rise unusually fast.
Should I copy a thermal table from a forum for my model?
Only after you verify the exact model and kernel version and sensor layout. Even then test it slowly with a backup ready. A table that works for one user may fail for another user with a different revision of the same model.
Conclusion
Thermal tables turn heat into a set of clear decisions. Each threshold trades performance for safety at a known temperature. A careful developer reads the source and changes one value at a time and tests under fair conditions. That method gives useful results without putting the phone at risk.
Your concrete next step is to locate the thermal configuration for your own device model and read its trip points without changing anything yet. Note the first threshold and the action that it triggers. That reading alone will explain many slowdowns that you have seen in daily use.
