I don't know about everyone else, but I didn't want to pay for a server, and didn't want to host one on my computer. I have a flagship phone; an S25+ with Snapdragon 8 and 12 GB RAM. It's ridiculous. I wanted to run intense computational coding on my phone, and didn't have a solution to keep my phone from overheating. So. I built one. This is non-rooted using sys-reads and Termux (found on F-Droid for sensor access) and Termux API (found on F-Droid), so you can keep your warranty. 🔥

It was a pretty technically challenging piece for me to make. I studied physics and wanted to apply it to mobile computing, but real life is messy, and the code quickly became equally complicated. I'm showing my final result, as well as the physics I used to make it, as well as providing a link to the code itself in case you want to see my problem solving methodology. The write up follows, and contains an additional section at the end with more in depth details of the physics I used.

What my project does: Monitors core temperatures using sys reads and Termux API. It models thermal activity using Newton's Law of Cooling to predict thermal events before they happen and prevent Samsung's aggressive performance throttling at 42° C.

Target audience: Developers who want to run an intensive server on an S25+ without rooting or melting their phone.

Comparison: I haven't seen other predictive thermal modeling used on a phone before. The hardware is concrete and physics can be very good at modeling phone behavior in relation to workload patterns. Samsung itself uses a reactive and throttling system rather than predicting thermal events. Heat is continuous and temperature isn't an isolated event.

I didn't want to pay for a server, and I was also interested in the idea of mobile computing. As my workload increased, I noticed my phone would have temperature problems and performance would degrade quickly. I studied physics and realized that the cores in my phone and the hardware components were perfect candidates for modeling with physics. By using a "thermal tank" where you know how much heat is going to be generated by various workloads through machine learning, you can predict thermal events before they happen and defer operations so that the 42° C thermal throttle limit is never reached. At this limit, Samsung aggressively throttles performance by about 50%, which can cause performance problems, which can generate more heat, and the spiral can get out of hand quickly.

My solution is simple: never reach 42° C

Physics-Based Thermal Prediction for Mobile Hardware - Validation Results

Core claim: Newton's law of cooling works on phones. 0.58°C MAE over 152k predictions, 0.24°C for battery. Here's the data.

THE PHYSICS

Standard Newton's law: T(t) = T_amb + (T₀ - T_amb)·exp(-t/τ) + (P·R/k)·(1 - exp(-t/τ))

Measured thermal constants per zone on Samsung S25+ (Snapdragon 8 Elite):

• Battery: τ=210s, thermal mass 75 J/K (slow response)
• GPU: τ=95s, thermal mass 40 J/K
• MODEM: τ=80s, thermal mass 35 J/K
• CPU_LITTLE: τ=60s, thermal mass 40 J/K
• CPU_BIG: τ=50s, thermal mass 20 J/K

These are from step response testing on actual hardware. Battery's 210s time constant means it lags—CPUs spike first during load changes.

Sampling at 1Hz uniform, 30s prediction horizon. Single-file architecture because filesystem I/O creates thermal overhead on mobile.

VALIDATION DATA

152,418 predictions over 6.25 hours continuous operation.

Overall accuracy:

• Transient-filtered: 0.58°C MAE (95th percentile 2.25°C)
• Steady-state: 0.47°C MAE
• Raw data (all transients): 1.09°C MAE
• 96.5% within 5°C
• 3.5% transients during workload discontinuities

Physics can't predict regime changes—expected limitation.

Per-zone breakdown (transient-filtered, 21,774 predictions each):

• BATTERY: 0.24°C MAE (max error 2.19°C)
• MODEM: 0.75°C MAE (max error 4.84°C)
• CPU_LITTLE: 0.83°C MAE (max error 4.92°C)
• GPU: 0.84°C MAE (max error 4.78°C)
• CPU_BIG: 0.88°C MAE (max error 4.97°C)

Battery hits 0.24°C which matters because Samsung throttles at 42°C. CPUs sit around 0.85°C, acceptable given fast thermal response.

Velocity-dependent performance:

• Low velocity (<0.001°C/s median): 0.47°C MAE, 76,209 predictions
• High velocity (>0.001°C/s): 1.72°C MAE, 76,209 predictions

Low velocity: system behaves predictably. High velocity: thermal discontinuities break the model. Use CPU velocity >3.0°C/s as regime change detector instead of trusting physics during spikes.

STRESS TEST RESULTS

Max load with CPUs sustained at 95.4°C, 2,418 predictions over ~6 hours.

Accuracy during max load:

• Raw (all predictions): 8.44°C MAE
• Transients (>5°C error): 32.7% of data
• Filtered (<5°C error): 1.23°C MAE, 67.3% of data

Temperature ranges observed:

• CPU_LITTLE: peaked at 95.4°C
• CPU_BIG: peaked at 81.8°C
• GPU: peaked at 62.4°C
• Battery: stayed at 38.5°C

System tracks recovery accurately once transients pass. Can't predict the workload spike itself—that's a physics limitation, not a bug.

DESIGN CONSTRAINTS

Mobile deployment running production workload (particle simulations + GIF encoding, 8 workers) on phone hardware. Variable thermal environments mean 10-70°C ambient range is operational reality.

Single-file architecture (4,160 lines): Multiple module imports equal multiple filesystem reads equal thermal spikes. One file loads once, stays cached. Constraint-driven—the thermal monitoring system can't be thermally expensive.

Dual-condition throttle:

• Battery temp prediction: 0.24°C MAE, catches sustained heating (τ=210s lag)
• CPU velocity >3.0°C/s: catches regime changes before physics fails

Combined approach handles both slow battery heating and fast CPU spikes.

BOTTOM LINE

Physics works:

• 0.58°C MAE filtered
• 0.47°C steady-state
• 0.24°C battery (tight enough for Samsung's 42°C throttle)
• Can't predict discontinuities (3.5% transients)
• Recovers to 1.23°C MAE after spikes clear

Constraint-driven engineering for mobile: single file, measured constants, dual-condition throttle.

In-Depth Discussion:

PHYSICS MODEL ARCHITECTURE

The system combines multiple components to predict thermal behavior:

THERMAL COUPLING HIERARCHY

Components don't heat in isolation. They follow a coupling chain:

CPU/GPU/Battery/Modem → Chassis (vapor chamber) → Ambient Air

Each component uses chassis temperature as T_ref, not ambient. Chassis itself uses fitted ambient temperature. This captures real heat flow: die heat conducts to chassis, chassis radiates to air.

ZONE-SPECIFIC PHYSICS ENGINE

Each thermal zone solves Newton's law independently with measured constants:

T(t) = T_chassis + (T₀ - T_chassis)·exp(-t/τ) + (PR/k)·(1 - exp(-t/τ))

The time constant τ determines response speed. Battery (τ=210s) responds slowly to power changes. CPUs (τ=50-60s) respond quickly. This creates prediction asymmetry: battery is most accurate, CPUs are harder.

Battery gets simplified model since τ >> 30s horizon:

ΔT ≈ (P/C)·Δt

Linear approximation is accurate when exponential hasn't decayed significantly.

POWER ESTIMATION

System power from battery sensor:

P_system = V_battery × |I_battery| / 10⁶ [sensor reports μA as "mA"]

Subtract known loads:

P_thermal = P_system - P_display(brightness) - P_modem(network_type)

Distribute remaining power to CPU/GPU zones by velocity ratios:

P_zone = P_thermal × (v_zone / Σv_active_zones)

Zones heating faster get more power allocation. When all velocities near zero, use typical distribution (CPU_BIG 40%, CPU_LITTLE 50%, GPU 10%).

AMBIENT TEMPERATURE FITTING

Can't directly measure ambient. Fit from system state using battery-to-coolest delta:

T_ambient = T_battery - offset(charging_state, battery_delta)

Offset ranges 2-8°C depending on whether charging (heat generation) or discharging (heat dissipation). Battery's high thermal mass makes it stable reference point.

VELOCITY CALCULATION

Linear regression over last 10 samples per zone:

v = ΔT/Δt [°C/s]

Used for: - Power distribution (which zones are heating) - Regime change detection (velocity >3.0°C/s triggers throttle) - Confidence scaling (high velocity = lower confidence)

DUAL-CONFIDENCE PREDICTION

Each prediction gets two confidence scores:

Physics confidence: Based on time constant relative to horizon - Battery (τ=210s >> 30s): confidence = 0.95 - CPUs (τ=50-60s > 30s): confidence = 0.70-0.75 - Longer τ relative to horizon = more accurate prediction

Sample-size confidence: Based on history depth - confidence = min(1.0, n_samples / 60) - Ramps from 0 to 1 over first minute

Final confidence = physics × sample_size × 0.5 [safety factor]

THROTTLE DECISION LOGIC

Two independent conditions OR together:

Condition 1 - Battery temperature: if T_battery_predicted ≥ 38.5°C: throttle = True

Condition 2 - CPU velocity: if v_cpu_big > 3.0°C/s OR v_cpu_little > 3.0°C/s: throttle = True

Battery catches sustained heating (responds over minutes). Velocity catches regime changes (responds in seconds). Combined system handles both slow and fast thermal events.

OBSERVED PEAK FALLBACK

When zone temperature ≥ throttle_start temperature, physics breaks down because throttling changes power assumption mid-flight. Switch to empirical prediction:

if T_zone ≥ T_throttle_start: T_predicted = T_observed_peak [from validation data]

Example: CPU_BIG at 50°C predicts 81°C peak instead of using Newton's law. Avoids catastrophic under-prediction during throttled operation.

COMPONENT INTERACTION

1. Telemetry reads 7 zones at 1Hz
2. Ambient estimator fits T_ambient from battery/chassis delta
3. Power estimator calculates P_thermal from battery current minus known loads
4. Velocity calculator does linear regression on recent samples
5. Physics engine solves Newton's law per zone using chassis as T_ref
6. If zone is throttled, override with observed peak
7. Confidence calculator weights prediction by τ and sample history
8. Throttle logic checks battery prediction and CPU velocities
9. Return prediction with confidence and throttle decision

The system is hierarchical: ambient → chassis → components. Power flows down from battery measurement. Predictions flow up from per-zone physics. Throttle decision combines slow (battery) and fast (velocity) signals to catch both failure modes.

Phew. Physics. And stuff.