Diagnose Android arcade emulator thermal throttling before changing cores
Suspect thermal throttling when the same authorized game starts at full emulation speed and then degrades after sustained load while the device warms. Reproduce from a cool baseline, record elapsed time, speed, frame pacing, audio, charging state, case, ambient conditions, and Android thermal evidence when the device exposes it. If a cool repeat restores performance, reduce one workload layer—renderer cost, shader, output resolution, run-ahead, or fast-forward—then retest for a stable session; changing ROMs cannot fix heat.
Do this in order
- 01
Record device model, Android version, emulator and core revision, authorized test game, room conditions, case, charger, battery level, display refresh, renderer, shader, run-ahead, fast-forward, and baseline speed.
- 02
Let the device return to a normal cool idle state, close background workloads, disconnect charging unless needed for a controlled comparison, and cold-launch the unchanged test scene.
- 03
Log speed, frame pacing, audio continuity, device-reported thermal status or headroom when available, and elapsed time at fixed checkpoints without repeatedly touching settings.
- 04
Stop safely when Android warns of heat or the device becomes uncomfortable; do not chill the device artificially or bypass system protection.
- 05
After a cool repeat, reduce exactly one sustained workload such as shader passes, internal resolution, run-ahead frames, unlimited fast-forward, or an unnecessarily high display target, then run the same duration.
- 06
Accept the change only if emulation speed and audio remain stable for the target session; otherwise compare renderer, core workload, battery/Game Mode, and device limits without replacing game data.
Decision and diagnostic table
| Pattern | Best current inference | Next controlled check |
|---|---|---|
| Slow from the first frame | Configuration, core, renderer, or device ceiling | Restore a simple cold baseline |
| Fast cold, slower after warming | Sustained thermal or power limit | Repeat after cooling with time checkpoints |
| Only audio breaks while speed is full | Audio route or buffer boundary | Keep thermal evidence but test audio separately |
| Frame cap is stable but lower | Refresh or Game Mode intervention may be active | Record display target and Android mode |
Thermal faults have a time signature
Android documents that devices can sustain peak performance only for a limited time and may throttle CPU or GPU as thermal stress rises. A cold-versus-warm timeline is stronger evidence than surface temperature or one slow frame.
Thermal headroom and status are device-dependent. Some devices expose incomplete values, so combine any reading with elapsed-time and repeatable performance evidence rather than treating one number as universal.
Reduce sustained work, not diagnostic visibility
Lower one costly layer at a time and keep the speed display, log, and test scene constant. Turning off every feature at once may cool the device but cannot identify the workload that crossed its sustainable limit.
Frame caps and throttling are not identical
Android 13 and later can apply FPS throttling as a Game Mode intervention on supported games. A stable lower frame target differs from progressive emulation-speed loss, and an emulator may not be classified or integrated as a game. Record the actual device behavior instead of assuming the feature applies.
Performance testing does not authorize ROMs, BIOS files, CHDs, artwork, or logs containing private identifiers. Use lawful content, respect device heat warnings, do not defeat thermal safeguards, and redact serials, accounts, and private paths from reports.