📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
@@ -0,0 +1,198 @@
|
||||
---
|
||||
name: diagnose-android-overheating
|
||||
description: "Use when diagnosing Android overheating, idle heat, thermal throttling, charging or radio heat, or abnormal battery drain with read-only ADB evidence and approval gates."
|
||||
category: debugging
|
||||
risk: critical
|
||||
source: self
|
||||
source_type: self
|
||||
date_added: "2026-07-16"
|
||||
author: Antigravity Awesome Skills maintainers
|
||||
tags: [android, adb, overheating, thermal, battery, diagnostics]
|
||||
tools: [claude, cursor, gemini, antigravity, codex]
|
||||
---
|
||||
|
||||
# Diagnose Android Overheating
|
||||
|
||||
## Overview
|
||||
|
||||
Find the most likely source of Android device heat by correlating thermal state, battery conditions, CPU activity, wakeups, radios, sensors, charging, and the user's timeline. Keep diagnosis read-only by default, distinguish evidence from inference, and propose only the smallest reversible intervention after the user approves it.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
- Use when an Android phone is hot, warm while idle, thermally throttled, shutting down from heat, or draining its battery unusually fast.
|
||||
- Use when heat appears during charging, weak cellular signal, 5G use, navigation, camera use, gaming, media playback, tethering, or background activity.
|
||||
- Use when the user wants to identify an offending app, service, wakelock, sensor, modem condition, or charging condition through ADB.
|
||||
- Use when a previous Android optimization or debloat attempt may have left settings that changed power or thermal behavior.
|
||||
- Use for physical phones and tablets. For profiling the energy use of an app under development, use an app-performance skill instead.
|
||||
|
||||
## Safety Stop
|
||||
|
||||
Stop software diagnosis when the device shows battery swelling, smoke, hissing, leaking, a sharp chemical odor, repeated thermal shutdowns, or heat severe enough that it cannot be handled safely. Tell the user to disconnect power if this can be done safely, power the device off, keep it away from flammable material, and seek manufacturer or qualified repair support. Do not suggest cooling the device in a refrigerator or freezer, puncturing it, continuing to charge it, or running stress tests.
|
||||
|
||||
## Diagnostic Contract
|
||||
|
||||
Before collecting data:
|
||||
|
||||
1. Confirm the user owns or is authorized to inspect the device.
|
||||
2. Ask what “hot” means: location on the handset, activity, charging state, network type, onset, duration, and whether the heat also occurs while idle.
|
||||
3. Record the device model, Android version, recent OS/app changes, charger and cable, ambient conditions, and visible thermal warnings.
|
||||
4. Explain that an attached USB cable can charge and warm the device. Use wireless ADB or short capture windows when possible, and compare with the cable disconnected.
|
||||
5. Select a specific device serial when more than one ADB target is present. Never assume the first listed device is the intended phone.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Capture an Untouched Baseline
|
||||
|
||||
Do not reset Batterystats, force-stop apps, clear caches, change network modes, alter AppOps, enable battery saver, or change developer settings before preserving the initial state.
|
||||
|
||||
Start with read-only commands:
|
||||
|
||||
```bash
|
||||
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
|
||||
```
|
||||
|
||||
If a service or option is unavailable, record that limitation. Do not turn missing output into a healthy verdict. Android and OEM builds expose different services, fields, permissions, and `top` syntax.
|
||||
|
||||
### 2. Choose the Evidence Branch
|
||||
|
||||
Read [evidence-and-interpretation.md](references/evidence-and-interpretation.md), then collect only the branches that match the symptom:
|
||||
|
||||
- heat while idle: battery history, power state, alarms, jobs, sensors, location, and radios;
|
||||
- heat while charging: battery/USB state and a controlled unplugged comparison;
|
||||
- heat under one app: process CPU, package memory, jobs, wakelocks, network, camera, and location;
|
||||
- heat in weak signal or mobile data: telephony, connectivity, signal changes, and mobile-radio activity;
|
||||
- heat during camera, navigation, gaming, or playback: CPU/GPU-adjacent state, display, camera/media, sensors, location, and network activity;
|
||||
- heat after a setting change: capture current values and compare them with the known previous state before proposing rollback.
|
||||
|
||||
Do not collect a full bugreport unless narrow evidence is insufficient. Bugreports can contain account identifiers, app activity, network details, notifications, and other sensitive data.
|
||||
|
||||
### 3. Reproduce with a Controlled Comparison
|
||||
|
||||
Define one pass/fail comparison before changing anything. Examples:
|
||||
|
||||
- idle with airplane mode versus idle on weak cellular signal;
|
||||
- same workload on Wi-Fi versus mobile data;
|
||||
- charging versus unplugged after the battery level is stable;
|
||||
- suspect app active versus closed by the user;
|
||||
- screen on at fixed brightness versus screen off;
|
||||
- before versus after the recent OS or app update, when a real reference exists.
|
||||
|
||||
Keep workload, duration, brightness, case, charger, ambient conditions, and starting battery level as constant as practical. Timestamp each observation. Avoid benchmarks or synthetic load unless the user explicitly asks and the device is not already thermally stressed.
|
||||
|
||||
### 4. Correlate, Do Not Guess
|
||||
|
||||
Require at least two independent signals before attributing the heat:
|
||||
|
||||
- thermal severity or rising battery temperature plus sustained process CPU;
|
||||
- thermal change plus mobile-radio activity and poor signal;
|
||||
- heat while idle plus persistent partial wakelock, alarm, job, sensor, or location activity;
|
||||
- heat during charging plus charging state/current evidence and a cooler unplugged comparison;
|
||||
- thermal throttling plus a workload-specific subsystem such as camera, GPU-heavy rendering, navigation, tethering, or media processing.
|
||||
|
||||
A hot battery does not identify the cause. A high CPU snapshot does not prove sustained load. A wakelock name does not prove meaningful energy use without duration and timeline correlation. Batterystats estimates are device-dependent and may be absent or incomplete.
|
||||
|
||||
### 5. Classify the Finding
|
||||
|
||||
Use one primary class and list plausible contributors separately:
|
||||
|
||||
- app or process CPU load;
|
||||
- modem/radio and weak-signal loop;
|
||||
- Wi-Fi, Bluetooth, tethering, or continuous transfer;
|
||||
- screen, camera, video, GPU, or media processing;
|
||||
- GPS, sensors, navigation, or location polling;
|
||||
- charging equipment, charging mode, or simultaneous charge-and-load;
|
||||
- OS/OEM service, post-update optimization, or configuration residue;
|
||||
- battery aging or hardware fault;
|
||||
- normal workload heat within the device's reported thermal state;
|
||||
- insufficient evidence.
|
||||
|
||||
State confidence as `confirmed`, `strongly supported`, `possible`, or `unknown`. Reserve `confirmed` for a controlled comparison or direct timeline evidence that changes with the suspected cause.
|
||||
|
||||
### 6. Gate Every Intervention
|
||||
|
||||
Present the evidence and proposed experiment before changing the device.
|
||||
|
||||
- Read-only inspection may proceed within the user's authorized device scope.
|
||||
- Interruptive actions, such as stopping an app or temporarily changing connectivity, require the user's awareness and must not disrupt calls, authentication, navigation, alarms, or accessibility services.
|
||||
- Persistent settings, network-mode changes, AppOps, package disabling, debloating, or developer-option changes require explicit approval, an exact pre-change value, a rollback command, and post-change verification.
|
||||
- Never disable thermal protection, spoof a thermal status, edit thermal thresholds, clear app data, reset the device, or remove packages as a generic overheating fix.
|
||||
- Do not treat animation scale, background-process limits, forced GPU rendering, cache trimming, or forced Doze as root-cause fixes.
|
||||
|
||||
Change one variable at a time. After the test, restore the old value unless the user explicitly chooses to keep the verified change.
|
||||
|
||||
## Output Format
|
||||
|
||||
```text
|
||||
Symptom and context:
|
||||
Safety status:
|
||||
Evidence collected:
|
||||
Controlled comparison:
|
||||
Most likely cause:
|
||||
Confidence:
|
||||
Contributors or alternatives:
|
||||
Proposed next test or smallest fix:
|
||||
Approval required:
|
||||
Rollback:
|
||||
Remaining uncertainty:
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
### Idle Heat on Mobile Data
|
||||
|
||||
Correlate thermal and battery trends with signal state, mobile-radio activity, process CPU, and wakeups. A weak signal alone is not enough; show that the heat or radio activity falls during a comparable Wi-Fi or airplane-mode window before calling the modem loop the cause.
|
||||
|
||||
### Heat After Installing an App
|
||||
|
||||
Compare the package's sustained CPU, jobs, alarms, network, location, and wakelock time with the symptom window. Do not force-stop or restrict it until the baseline is saved and the user approves an interruption.
|
||||
|
||||
### Heat While Charging
|
||||
|
||||
Record charger/cable context, battery state, temperature trend, plugged source, and simultaneous workload. Compare against a safe unplugged window. Do not infer battery failure from temperature alone.
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Preserve raw output before filtering it; OEM labels and field layouts vary.
|
||||
- Prefer trends and before/after windows over single snapshots.
|
||||
- Separate surface warmth, battery temperature, and framework thermal severity.
|
||||
- Keep a record of every mutation and its original value.
|
||||
- Redact serials, phone numbers, SSIDs, account identifiers, notifications, and personal app activity before sharing logs.
|
||||
- Escalate persistent unexplained idle heat or abnormal charging heat to hardware support when software evidence is weak.
|
||||
|
||||
## Limitations
|
||||
|
||||
- ADB cannot prove battery internal resistance, physical damage, charger quality, or exact internal component temperature on every device.
|
||||
- Thermal sensor values and thresholds are OEM-specific; some devices hide sensors or report status incompletely.
|
||||
- Battery attribution is historical and model-dependent, not a laboratory power measurement.
|
||||
- USB-connected observation can alter charging, radio, and thermal behavior.
|
||||
- Root-only files and vendor services may be unavailable; do not bypass device security to obtain them.
|
||||
|
||||
## Security & Safety Notes
|
||||
|
||||
- Operate only on a device the user owns or is authorized to inspect.
|
||||
- Treat bugreports and raw system dumps as sensitive local artifacts.
|
||||
- Never upload logs, install diagnostic APKs, enable network ADB, or expose the ADB daemon without explicit informed approval.
|
||||
- Keep the workflow read-only until evidence supports a narrow experiment and the user approves it.
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
- **Filtering `thermalservice` down to one word:** Preserve the complete output; status, sensor type, throttling severity, and vendor omissions all matter.
|
||||
- **Calling the top CPU process the cause from one sample:** Sample across the heat window and correlate with thermal change.
|
||||
- **Resetting Batterystats immediately:** Save the pre-existing history first; reset only for an explicitly approved controlled capture.
|
||||
- **Applying several “optimizations” together:** Test one reversible hypothesis at a time and verify the symptom, not just the setting.
|
||||
- **Treating missing OEM data as evidence of no problem:** Report the blind spot and use an independent comparison or escalate.
|
||||
|
||||
## Related Skills
|
||||
|
||||
- `@android-cli` - Use for Android SDK, emulator, deployment, screenshots, and general device interaction.
|
||||
- `@android-dev` - Use when the root cause is in Android application source code and the user wants an implementation fix.
|
||||
- `@mobile-developer` - Use for broader mobile application development rather than handset-level diagnosis.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Diagnose Android Overheating"
|
||||
short_description: "Find Android heat causes with safe ADB evidence"
|
||||
default_prompt: "Diagnose why this Android device is overheating using read-only evidence first, then propose the smallest reversible fix."
|
||||
+168
@@ -0,0 +1,168 @@
|
||||
# Evidence and Interpretation
|
||||
|
||||
Use this reference after the core skill has established device authorization, symptom context, and a safety screen. Commands are read-only unless a section explicitly says otherwise.
|
||||
|
||||
## Contents
|
||||
|
||||
1. Evidence quality
|
||||
2. Thermal and battery baseline
|
||||
3. Symptom branches
|
||||
4. Correlation guide
|
||||
5. Controlled Batterystats capture
|
||||
6. Bugreport privacy
|
||||
7. Official references
|
||||
|
||||
## Evidence Quality
|
||||
|
||||
Prefer evidence in this order:
|
||||
|
||||
1. a controlled comparison that changes only one plausible cause;
|
||||
2. a timestamped trend spanning cool-to-hot or hot-to-cool behavior;
|
||||
3. two independent system signals from the same window;
|
||||
4. a single system snapshot;
|
||||
5. user recollection without device evidence.
|
||||
|
||||
Do not elevate a lower-quality signal merely because it names an app or subsystem.
|
||||
|
||||
## Thermal and Battery Baseline
|
||||
|
||||
Capture the full service outputs before extracting fields:
|
||||
|
||||
```bash
|
||||
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
|
||||
adb -s <serial> shell dumpsys power
|
||||
```
|
||||
|
||||
Interpretation rules:
|
||||
|
||||
- `dumpsys battery` describes battery and charging state. Its temperature field is commonly expressed in tenths of a degree Celsius, but verify the device's representation instead of blindly dividing.
|
||||
- `dumpsys thermalservice` is most useful on Android 10 and later. Some OEMs omit detailed sensors, expose only severity, or restrict output.
|
||||
- Framework thermal status ranges from `0` (none) through `6` (shutdown) on implementations that expose the standard service. `2` means moderate, `3` severe, `4` critical, and `5` emergency thermal stress.
|
||||
- Sensor readings are not interchangeable. Battery, skin, CPU, GPU, modem, and USB sensors describe different locations and policies.
|
||||
- OEM thresholds differ. Never declare a universal safe temperature from one raw value.
|
||||
- Thermal throttling is a response to heat, not automatically its cause.
|
||||
|
||||
If `top -n 1` is rejected, inspect `adb -s <serial> shell top --help` and use only a syntax supported by that device. Do not install BusyBox or request root as a fallback.
|
||||
|
||||
## Symptom Branches
|
||||
|
||||
### Idle or Screen-Off Heat
|
||||
|
||||
```bash
|
||||
adb -s <serial> shell dumpsys batterystats
|
||||
adb -s <serial> shell dumpsys batterystats --history
|
||||
adb -s <serial> shell dumpsys power
|
||||
adb -s <serial> shell dumpsys alarm
|
||||
adb -s <serial> shell dumpsys jobscheduler
|
||||
adb -s <serial> shell dumpsys sensorservice
|
||||
adb -s <serial> shell dumpsys location
|
||||
adb -s <serial> shell dumpsys deviceidle
|
||||
```
|
||||
|
||||
Look for duration and recurrence, not merely presence. A scheduled alarm, registered sensor, or listed job can be normal. Correlate it with screen-off time, wakeups, process activity, network traffic, and the heat window.
|
||||
|
||||
### App-Specific Heat
|
||||
|
||||
First identify the exact package without guessing from the display name. Then inspect it:
|
||||
|
||||
```bash
|
||||
adb -s <serial> shell dumpsys cpuinfo
|
||||
adb -s <serial> shell dumpsys meminfo <package>
|
||||
adb -s <serial> shell dumpsys package <package>
|
||||
adb -s <serial> shell dumpsys jobscheduler <package>
|
||||
adb -s <serial> shell dumpsys gfxinfo <package>
|
||||
```
|
||||
|
||||
Package memory is not a heat measurement. High memory can contribute to pressure or churn, but sustained CPU/GPU, radios, camera, sensors, or charging usually provide a stronger causal path.
|
||||
|
||||
### Cellular, Weak-Signal, or 5G Heat
|
||||
|
||||
```bash
|
||||
adb -s <serial> shell dumpsys telephony.registry
|
||||
adb -s <serial> shell dumpsys connectivity
|
||||
adb -s <serial> shell dumpsys wifi
|
||||
adb -s <serial> shell dumpsys batterystats
|
||||
adb -s <serial> shell getprop | grep -iE 'radio|baseband'
|
||||
```
|
||||
|
||||
Redact phone numbers, subscriber identifiers, network names, and addresses. Look for a repeated association among poor signal, handovers or radio activity, higher battery drain, and the heat timeline. Confirm with a same-workload Wi-Fi or airplane-mode window when safe and acceptable to the user.
|
||||
|
||||
Do not change preferred network type from a copied bitmask. Slot IDs, carrier policy, radio capabilities, and command availability vary by device and Android build.
|
||||
|
||||
### Charging Heat
|
||||
|
||||
```bash
|
||||
adb -s <serial> shell dumpsys battery
|
||||
adb -s <serial> shell dumpsys usb
|
||||
adb -s <serial> shell dumpsys thermalservice
|
||||
```
|
||||
|
||||
Record plugged source, charging status, battery level, workload, charger, cable, case, and ambient conditions. A USB debugging cable can itself change the result. Do not simulate unplugging with `dumpsys battery set`; that changes framework state without reproducing the physical charging condition.
|
||||
|
||||
### Camera, Navigation, Gaming, Video, or Tethering
|
||||
|
||||
Collect the thermal baseline plus only the relevant services:
|
||||
|
||||
```bash
|
||||
adb -s <serial> shell dumpsys media.camera
|
||||
adb -s <serial> shell dumpsys media.metrics
|
||||
adb -s <serial> shell dumpsys location
|
||||
adb -s <serial> shell dumpsys sensorservice
|
||||
adb -s <serial> shell dumpsys connectivity
|
||||
adb -s <serial> shell dumpsys wifi
|
||||
adb -s <serial> shell dumpsys display
|
||||
adb -s <serial> shell dumpsys SurfaceFlinger
|
||||
```
|
||||
|
||||
Service names and permissions vary. Record unsupported services rather than replacing them with root-only commands.
|
||||
|
||||
## Correlation Guide
|
||||
|
||||
| Observation | Stronger interpretation | Required counter-check |
|
||||
| --- | --- | --- |
|
||||
| Rising thermal severity and sustained package CPU | App/process workload may drive heat | Repeat sample; compare with app inactive |
|
||||
| Heat plus poor signal and mobile-radio activity | Modem/radio loop may contribute | Same workload on stable Wi-Fi or airplane mode |
|
||||
| Heat while idle plus long partial wakelock | Background work may prevent sleep | Match wakelock duration to screen-off heat window |
|
||||
| Heat only while physically charging | Charging path or charge-plus-load may contribute | Safe unplugged comparison with workload controlled |
|
||||
| Severe thermal state but low visible app CPU | GPU, modem, camera, charging, kernel, or hardware remains plausible | Inspect matching subsystem and OEM blind spots |
|
||||
| Battery drain without thermal escalation | Energy use may be real but insufficient to cause thermal stress | Compare temperature trend and workload duration |
|
||||
| High temperature with no exposed activity | Hardware fault or inaccessible vendor activity remains possible | Safe mode/OEM diagnostics or qualified service |
|
||||
|
||||
## Controlled Batterystats Capture
|
||||
|
||||
Resetting Batterystats erases the existing collection window. Do it only after preserving the original output and obtaining approval for a fresh experiment.
|
||||
|
||||
Official Android guidance uses this sequence:
|
||||
|
||||
1. save current Batterystats or a bugreport if needed;
|
||||
2. reset Batterystats;
|
||||
3. disconnect the USB cable so the device runs on battery;
|
||||
4. reproduce a defined workload for a defined duration;
|
||||
5. reconnect and export Batterystats or a bugreport;
|
||||
6. compare the captured window with a control window.
|
||||
|
||||
Do not run the reset merely to make output shorter. Record that the reset occurred because it changes the evidence base.
|
||||
|
||||
## Bugreport Privacy
|
||||
|
||||
`adb bugreport <local-path>.zip` creates a broad diagnostic archive. Before running it:
|
||||
|
||||
- explain that it may include identifiers, accounts, app usage, notifications, networks, logs, and recent system activity;
|
||||
- choose a private local path with the user;
|
||||
- do not upload or transmit the archive without separate approval;
|
||||
- extract only the evidence needed for the diagnosis;
|
||||
- redact sensitive fields before sharing excerpts;
|
||||
- follow the user's retention or deletion preference.
|
||||
|
||||
## Official References
|
||||
|
||||
- [Android dumpsys documentation](https://developer.android.com/tools/dumpsys)
|
||||
- [Profile battery usage with Batterystats and Battery Historian](https://developer.android.com/topic/performance/power/setup-battery-historian)
|
||||
- [Analyze power use with Battery Historian](https://developer.android.com/topic/performance/power/battery-historian)
|
||||
- [AOSP thermal mitigation](https://source.android.com/docs/core/power/thermal-mitigation)
|
||||
- [Android Thermal API](https://developer.android.com/games/optimize/adpf/thermal)
|
||||
- [System restrictions on background tasks](https://developer.android.com/develop/background-work/background-tasks/bg-work-restrictions)
|
||||
- [Android developer options](https://developer.android.com/studio/debug/dev-options)
|
||||
Reference in New Issue
Block a user