Diagnose Android Device Overheating via ADB

This skill finds the most likely source of Android device heat by correlating thermal state, battery conditions, CPU activity, wakeups, radios, sensors, charging, and the user's own timeline of when the heat occurs - keeping diagnosis read-only by default and proposing only the smallest reversible intervention after explicit approval. It applies to a phone or tablet that's hot, warm while idle, thermally throttled, shutting down from heat, or draining unusually fast, whether during charging, weak signal, 5G, navigation, camera use, gaming, or background activity, and whether the goal is finding an offending app or checking whether a prior debloat/optimization attempt left settings that changed power or thermal behavior.

A hard safety stop comes before any software diagnosis: battery swelling, smoke, hissing, leaking, a sharp chemical odor, repeated thermal shutdowns, or heat too severe to handle safely all mean stopping immediately, disconnecting power if safe, powering the device off, keeping it away from flammable material, and getting manufacturer or qualified repair support - never suggesting a refrigerator or freezer, puncturing the device, continuing to charge it, or running a stress test.

Before collecting any data, the diagnostic contract confirms device ownership/authorization, defines what "hot" actually means (location, activity, charging state, network type, onset, whether it happens at idle too), records device model/OS version/recent changes/charger/ambient conditions, and notes that an attached USB cable itself charges and warms the device - preferring wireless ADB or short capture windows, and always selecting the correct device serial when more than one is attached rather than assuming the first listed. The workflow runs six steps: capture an untouched baseline first, before resetting Batterystats, force-stopping apps, or changing any settings, using read-only commands like:

adb devices -l
adb -s <serial> shell getprop ro.product.manufacturer
adb -s <serial> shell getprop ro.product.model
adb -s <serial> shell getprop ro.build.version.release
adb -s <serial> shell getprop ro.build.version.sdk
adb -s <serial> shell uptime
adb -s <serial> shell dumpsys battery
adb -s <serial> shell dumpsys thermalservice
adb -s <serial> shell dumpsys cpuinfo
adb -s <serial> shell top -n 1

Then choosing an evidence branch matched to the specific symptom (idle heat pulls battery history/alarms/jobs/sensors/radios; charging heat pulls battery/USB state plus an unplugged comparison; single-app heat pulls that process's CPU/jobs/wakelocks/network) rather than collecting a full bugreport, which can carry sensitive account and network data. A controlled comparison defines one pass/fail test before changing anything - airplane mode versus weak signal, Wi-Fi versus mobile data, charging versus unplugged - holding workload, brightness, and starting battery level as constant as practical. Attribution requires at least two independent signals (thermal severity plus sustained CPU, or heat-while-idle plus a persistent wakelock/alarm/job), since a hot battery alone, a single high-CPU snapshot, or a wakelock's mere existence without duration and timeline correlation doesn't prove a cause. The finding gets classified into one primary class (app/process load, modem/radio loop, connectivity, screen/camera/media, GPS/location, charging equipment, OS/OEM residue, hardware fault, normal workload heat, or insufficient evidence) with an explicit confidence level - confirmed, strongly supported, possible, or unknown - reserving "confirmed" for a real controlled comparison or direct timeline evidence.

Every intervention is gated by its own risk tier: read-only inspection can proceed within authorized scope; interruptive actions (stopping an app, changing connectivity) need the user's awareness and must never disrupt calls, authentication, navigation, alarms, or accessibility services; and persistent changes (settings, network mode, AppOps, debloating) need explicit approval, the exact pre-change value, a rollback command, and post-change verification. Disabling thermal protection, spoofing thermal status, editing thermal thresholds, or resetting the device are explicitly never acceptable as a generic fix, and one variable gets changed at a time with the old value restored afterward unless the user chooses to keep a verified change. Findings are reported in a fixed structure covering symptom, safety status, evidence, comparison, most likely cause, confidence, contributors, proposed next step, approval needed, rollback, and remaining uncertainty.

Use it for physical Android phones and tablets showing heat, throttling, or abnormal drain - not for profiling an app's energy use during development, which needs a dedicated app-performance skill instead. Escalate to hardware support when persistent unexplained idle heat or abnormal charging heat shows weak software evidence, rather than continuing to test.

Input is ADB access to the authorized device and the user's description of when and where the heat occurs. Output is a structured diagnostic report naming the most likely cause, its confidence level, contributing factors, and a proposed minimal reversible next test, with every mutation logged against its original value for rollback.

It operates entirely through ADB shell commands (dumpsys battery, dumpsys thermalservice, dumpsys cpuinfo) and hands off to @android-cli for general device interaction, @android-dev when the root cause is in app source code, or @mobile-developer for broader app development questions.

Anyone diagnosing unexplained Android device heat or battery drain on their own authorized device who needs a read-only-first, evidence-correlated process rather than guessing from a single CPU snapshot or a generic "optimization" fix.