Lesson 5: Mobile Device Troubleshooting Challenge

Mobile troubleshooting is full of symptoms that overlap.

A device that is slow, hot, and draining its battery could have a workload problem, failing battery, poor network conditions, background synchronization, malware, or some combination.

A device that will not charge could have a bad charger, damaged port, unsupported USB-C power source, failed charging circuit, or failing battery.

So the goal is not to memorize a symptom list.

The goal is to learn what each symptom makes worth testing first.

Case 1: poor battery health

Evidence:

battery runtime: much shorter than baseline
battery health report: reduced capacity
charging: normal
case: no swelling

The battery is still charging, so the charging path works well enough to replenish it.

The problem is reduced stored-energy capacity.

A battery-health replacement decision should use model-specific service guidance and safe handling.

Do not confuse poor runtime with proof of a charger failure.

Case 2: swollen battery

Evidence:

case separating near battery
trackpad lifting
battery runtime poor

Stop normal service.

Do not press the case closed. Do not continue charging. Do not puncture the pack.

The safety boundary is already clear.

This is one of the rare troubleshooting cases where the correct answer is deliberately less testing.

Case 3: improper charging

Evidence:

battery: healthy in supplied report
known-good compatible charger: works on another device
this device: no charging through one port
second supported charging port: works

The entire charger and battery path is not dead.

The failure boundary moves toward the damaged or malfunctioning port and its local charging path.

Now change the evidence:

USB-C charger: lower power than device requirement
port: physically healthy
charging: extremely slow or absent under load

The physical port may be fine. The power source may simply not meet the device requirement.

Same symptom. Different boundary.

Case 4: broken screen

A broken screen can mean several things:

• cracked glass;
• damaged image panel;
• black or dead area;
• touch failure;
• both image and digitizer failure.

Do not use "screen broken" as the diagnosis.

Record which functions still work and use the model-specific assembly design to determine the realistic service unit.

Case 5: touch is inaccurate or cursor drifts

Evidence:

image: normal
finger or stylus input: lands away from intended point
screen glass: not visibly cracked

The image path is healthy enough to render normally.

Move toward digitizer calibration, input configuration, driver, or touch hardware evidence before replacing the display panel.

Image and touch are different systems.

If a track point or drawing pad drifts while other pointer devices work, the same logic applies: isolate the failing input path instead of blaming the whole laptop.

Case 6: application will not install

Evidence:

network: working
account/store access: working
free storage: below application requirement
policy: app allowed

This is not proof of malware, failed Wi-Fi, or a bad app store.

The installation requirement is not being met.

Free the required storage through an approved method, then retry and verify.

The clean answer is usually less exciting than the conspiracy theory.

Case 7: device is slow and overheating

Evidence:

storage: nearly full
background applications: numerous
CPU use: persistently high
temperature: elevated
battery: not swollen

The symptoms share a plausible workload and resource explanation.

Measure before replacing hardware.

Useful evidence may include:

• which processes consume CPU;
• memory pressure;
• storage availability;
• temperature behavior;
• background synchronization;
• recent application changes;
• fan or cooling behavior on devices that expose it.

"Hot and slow" is not automatically a battery diagnosis.

Case 8: suspicious mobile behavior

Evidence:

unexpected pop-ups after unapproved application install
network/data use increased
device still connects normally
performance degraded

Malware becomes plausible at recognition depth.

That does not give you permission to collect personal credentials, messages, photos, or unrelated private content.

Preserve the supplied evidence and follow the approved mobile-security remediation path.

Security troubleshooting still has a data boundary.

Case 9: liquid exposure

Evidence:

liquid reached keyboard or ports
device: currently powered off

Keep it powered off.

Repeated power-on attempts can turn recoverable contamination into electrical damage.

Follow the approved service or escalation process.

Again, more testing is not always better testing.

Case 10: stylus does not work

Evidence:

finger touch: works
stylus: model-compatible
stylus battery/charge: depleted

Stay with the stylus power and pairing path.

The digitizer has already demonstrated some touch functionality.

Replacing the whole display assembly would be wildly premature.

Case 11: poor or no connectivity

"No connectivity" is still too vague.

Split it:

• Wi-Fi radio disabled?
• associated with an access point?
• valid IP configuration?
• cellular service provisioned?
• Bluetooth pairing complete?
• hotspot upstream working?
• policy blocking the intended app?

The word connectivity covers several different systems.

Ask what link is actually failing.

Case 12: physically damaged port

A damaged USB-C or other mobile port can create mixed symptoms:

• charging works intermittently;
• data fails but power works;
• connector is loose;
• dock functions appear and disappear;
• external display fails.

Because USB-C can carry multiple capabilities, one damaged port can create several seemingly unrelated tickets.

Map which functions share that physical boundary.

Case 13: degraded performance with synchronization active

Evidence:

Wi-Fi: working
cloud storage: large background sync in progress
CPU and disk use: elevated
battery drain: higher than normal
user reports device is slow

The device may be doing exactly what it was told to do.

Pause or schedule the approved synchronization workload, then compare performance again.

A busy system is not automatically a failing system.

Build six mobile incident records

Choose at least six cases from different symptom families.

For each, write:

symptom
known-good evidence
last proven-good boundary
first failed or uncertain boundary
strongest theory
alternative theory
controlled next check
safety / privacy / policy boundary
expected result
verification
a claim the evidence does not support

That last line keeps your reasoning honest.

The Week 5 model

By now, a mobile device should no longer look like one sealed black box.

You should see layers:

battery / charging
hardware assemblies
panel / touch / camera / input
ports / accessories
Wi-Fi / Bluetooth / NFC / cellular / location
policy / MDM
account
application
synchronization

A symptom moves you toward one boundary.

Evidence moves you closer.

Random resets mostly erase the trail.