Mobile fault finding: separating hardware, software and account problems

Why this matters

Mobile devices are the hardest things in this exam to diagnose, for one structural reason: you cannot take them apart to test. There is no minimum configuration boot, no swapping a known-good component, no meter on a rail. All the evidence has to come from observation and from the device's own information.

That constraint is what makes a method necessary. On a desktop you can substitute your way to an answer. On a phone you have to reason your way there, which means classifying the fault correctly before touching anything — and classifying it wrongly costs a customer their data.

This lesson closes domain 1 and is where the domain's material is applied. The general six-step method that governs the whole of domain 5 arrives in lesson 34; what follows here is the mobile-specific shape of the same discipline.

The lesson

The three-question split: is it the device, the network, or the account?

Almost every mobile fault belongs to one of three layers, and naming the layer first prevents most wasted work.

• Device. The hardware or the operating system on this handset. Test: does the fault follow the device to another network, and does it affect more than one account?
• Network. The Wi-Fi or cellular path. Test: does the same task work over the other interface? Turning Wi-Fi off and retrying over cellular takes five seconds and eliminates half the possibilities.
• Account. The credentials, the subscription, the provider, or a policy. Test: does the same account fail on a different device, and do other accounts work on this device?

Those three tests are cheap, non-destructive and available in every situation. Running all three before doing anything else is the single habit that most improves mobile diagnosis, and it maps directly onto the exam's scenario questions, which are usually constructed so that exactly one of the three is consistent with the symptoms given.

Faults that look like hardware and are not: background apps, storage and thermal throttling

"The phone is slow" and "the battery does not last" are reported as hardware failures and usually are not. The four common causes:

• Storage nearly full. Below a few per cent free, a phone slows dramatically, updates fail, the camera refuses to capture and applications crash on launch. This is the first thing to check and the easiest to fix.
• A misbehaving application. The device's own battery and data breakdowns name the culprit. An application consuming battery in the background at a rate out of proportion to its use is the answer, not a worn cell.
• Thermal throttling. A hot device deliberately reduces performance. If the slowness correlates with charging, direct sun, a case, or heavy use, the device is protecting itself and working correctly.
• An operating system update in progress, which consumes processor, storage and battery for a period after installation while indexes rebuild.

The genuine hardware causes — a degraded battery, a failing storage chip — are distinguishable because they persist across reboots, across applications and across a clean-boot state, and because the device's own battery health figure supports them.

Charging faults: cables, ports, lint, and the cheap replacements that damage cells

Charging complaints have a diagnostic order that goes from free to expensive:

1. Try a different cable. Cables fail constantly, at the strain point near the plug, and a cable that charges intermittently while moving is proven.
2. Try a different power source. A computer USB port delivers far less than a mains adapter, and a low-output source produces "charges very slowly" or "charges only when off".
3. Look inside the port with a light. Pocket lint compacts into the connector and is the single most common cause of a phone that has stopped charging. It is removed with a wooden or plastic pick, with the device powered off, never with anything metal.
4. Check for liquid detection. Many devices refuse to charge over a wet connector, and say so.
5. Only then suspect the port or the battery.

The warning worth repeating to users: uncertified chargers and cables are a real risk rather than a snobbery. Power delivery negotiation exists to stop a supply pushing more than the device asked for, and a non-compliant charger can skip it. The failure modes are a damaged charging circuit, a swollen cell, or worse.

Screen and touch faults, and testing without a spare panel

Lesson 3 covered what the layers are; here the question is how to tell which one has failed when you cannot open the device.

• No image, device responsive. If the phone still makes notification sounds, vibrates to touch input at known locations, and can be powered off by the usual gesture, the device is running and the display path has failed.
• Image, no touch. Digitiser or digitiser connector. Confirm by whether the device responds to hardware buttons and voice.
• Partial touch — a dead band across the screen. Characteristic of a digitiser fault rather than software.
• Phantom touches. Often a damaged digitiser or a poor-quality replacement, and sometimes a charger injecting noise. Unplug and retest: phantom touches that stop when the charger is removed are a supply problem.
• Cracked glass, perfect image and touch. Cosmetic and a decision, though glass fragments are a hazard and the seal is compromised.

Both major platforms include accessibility or diagnostic modes that display touch points, which turns "the touch is not working properly" into a measurement. Where a manufacturer provides a built-in hardware test, that is the fastest route to evidence.

When a reset is the answer, what it destroys, and what to capture before it

There are three distinct operations and users conflate them constantly.

• Restart. Powers the device off and on. Destroys nothing. Fixes a surprising proportion of transient faults and should be step one.
• Reset settings. Returns configuration to defaults without removing data. Clears network settings, saved wireless profiles and pairings. This is the right answer for persistent connectivity faults after the cheaper tests fail.
• Factory reset. Erases the device. Everything not synchronised elsewhere is gone.

Before any factory reset, and this is the examinable part:

1. Confirm a current backup exists and that it contains what the user cares about. "It syncs to the cloud" is a claim to verify, not to accept.
2. Record the account credentials. Activation lock and factory reset protection will hold the device hostage after a wipe if nobody can sign in with the account it was enrolled to. A wiped device with a forgotten account is frequently unrecoverable.
3. Remove the device from the account first where the user still has access, which releases that lock cleanly.
4. Note the storage and photo situation, because photo libraries are where the irreplaceable data usually is.

A factory reset also serves as a diagnostic: a fault that survives it is hardware, or a restored backup carrying the problem forward — which is why testing before restoring the backup is worth the extra step.