Apps that crash, drain the battery, or refuse to update
Why this matters
Application faults on a phone are the most common mobile ticket, and the platforms deliberately hide the machinery that would explain them. There is no log the user can read, no task manager, and no installer output. What there is instead is a small set of controls — storage, cache, permissions, account — and a set of symptoms that map onto them more reliably than people expect.
The exam asks about this in symptom form, and the practical value is high: most of these are resolved in two minutes by someone who knows which of the four controls to reach for, and by nobody at all otherwise.
The lesson
Clearing cache against clearing data, and the difference users are never told
This is the distinction users are never told and it causes real data loss.
Clearing the cache removes temporary files the application downloaded or generated. Nothing the user created is lost. It is free, it is safe, and it fixes a surprising range of faults: an application showing stale content, failing to load images, behaving oddly after an update, or occupying far more space than it should.
Clearing the data resets the application to its just-installed state. Sign in again, set it up again, and anything stored only inside the application is gone — offline downloads, drafts, local settings, and on some applications message history.
On Android both are offered in the application's storage settings, side by side, with almost no explanation. On iOS there is no cache control: the equivalent is offloading the app, which removes the application and keeps its data, and deleting it, which removes both.
The order to try:
- Force stop and reopen.
- Restart the device.
- Clear cache.
- Check for an update.
- Clear data — only after confirming what will be lost, which means asking whether anything in this application exists only here.
- Reinstall.
The step worth insisting on is the confirmation before step five. "Clear the data" said casually to a user is how somebody loses a year of a fitness log.
Permissions as a cause of silent failure rather than an error message
Permissions on mobile platforms fail quietly, which is what makes them hard to diagnose.
When an application is denied a permission it needs, it frequently does not say so. It shows an empty list, a spinner, a blank screen, or an error about the network that has nothing to do with the network. The user reports that the application is broken.
The permissions that produce the most confusing symptoms:
- Location, which on some platforms also gates wireless scanning — so an application that cannot find nearby devices may be missing location rather than Bluetooth.
- Photos and files, denied or limited to a selection, producing an application that cannot see the picture the user is looking at.
- Camera and microphone, where the symptom is a call joining with no video and no error.
- Notifications, where the complaint is that the application "does not work" because nothing ever arrives.
- Background activity and battery optimisation, which is the big one: an application restricted in the background stops syncing and stops delivering notifications, and this is frequently done automatically by the system or by a manufacturer's power-saving feature without the user ever being asked.
That last one deserves emphasis because it is the most common cause of "my messages arrive hours late" on Android, and the fix is excluding the application from battery optimisation rather than anything in the application itself.
The check: open the application's settings page in the system settings and read the permission list against what it is trying to do.
Storage, account and payment reasons an update will not install
An update that will not install has a short list of causes, and only one of them is a fault.
- Storage. Updates need working space well beyond the download itself. A device with under a gigabyte free fails updates with unhelpful messages. This is the most common cause by a distance.
- The account. The store account signed in now must be the one that installed the application, or it must be shared appropriately. Devices that changed hands, or that have a personal and a work account, produce applications that cannot be updated by the person holding the phone.
- Payment. A paid application, a subscription that lapsed, or a stored card that expired can block an update. The message is often about the account rather than about money.
- Operating system version. The new version requires a newer system than the device runs or can run. The store usually says so, and for a device at the end of its support this is the end of the road — the honest answer, not a fault to fix.
- Pending system updates blocking store updates on some platforms.
- Managed devices, where the organisation controls which applications and versions are permitted.
The order: free space, then the account, then the system version. Those three cover nearly everything, and the third is the one where the right answer is a conversation about the device's age rather than a repair.
Battery drain attributable to one app, and reading the per-app figures honestly
Both platforms report battery use per application, and reading those figures honestly is the skill — the screen is widely misread.
What it actually shows: proportion of battery consumed, over a period, attributed to each application. Two things follow immediately:
- The application used most is normally at the top. A browser or a video application at 40 per cent on a day of heavy use is not a fault; it is a description of how the day was spent.
- The useful figure is background activity, not total. An application consuming significant battery with almost no screen time is the anomaly worth investigating.
What genuinely drains a battery:
- An application holding the device awake or using location continuously in the background.
- An application repeatedly failing and retrying — a sync that cannot authenticate can consume a battery in hours.
- Poor signal, which makes the cellular radio transmit at maximum power. This attributes itself to whatever was using the network and looks like an application fault.
- Screen brightness and time, which is usually the real answer.
The approach: compare against a normal day, look for background disproportionate to use, and force stop the suspect to see whether the rate changes. If one application is confirmed, updating or reinstalling it is the first move and restricting its background activity is the second.
And the honest caveat: a device whose battery has degraded drains faster at every load, and no application change will fix that. The next lesson deals with telling the two apart.
Reinstalling, sideloaded software, and the app store that is the safer default
Reinstalling is the last software step, and where the application came from decides how much confidence to place in it.
Reinstalling properly: delete the application, restart the device, install it again from the store, sign in. The restart matters more than it sounds — it clears a running copy and any state held by the system on its behalf.
What is kept: anything stored in the cloud under the user's account — messages on platforms that sync, documents, settings that sync. What is lost: anything stored only on the device. Establishing which before deleting is the same rule as clearing data.
Sideloaded software — installed outside the official store — deserves a separate paragraph, because it changes the diagnosis. Sideloaded applications:
- Do not update themselves through the store, so they age and break.
- Have not been through the store's review, such as it is.
- Are a common delivery route for mobile malware, which is the security domain's concern and becomes this domain's when the symptom is a device behaving oddly.
- On a managed device, may be prohibited outright.
So when a misbehaving application was sideloaded, the first question is not how to fix it but where it came from. An application installed from a link in a message, a web page offering a paid application free, or a third-party store is a finding rather than a fault.
The safer default is the official store, and the reason to say so to users is not obedience to the platform: it is that store applications update, sideloaded ones do not, and an application that stopped updating two years ago is an unpatched program with access to the user's photos and messages.
Practise what you just read
1. What does clearing an application’s cache remove?
Select one
Show answer
C. Nothing the user created is lost, which makes it free to try. It fixes stale content, images that will not load and odd behaviour after an update.
2. What must be established before clearing an application’s data?
Select one
Show answer
D. Clearing data resets the application to its just-installed state. Said casually to a user, it is how somebody loses a year of a fitness log or a set of unsent drafts.
3. Which iOS action removes an application and keeps its data?
Select one
Show answer
A. iOS has no separate cache control, so offload and delete are the two equivalents. Offload is the reversible one and delete is the one that takes the application data with it.
7 more questions on this objective are part of the full course.
Hands-on labs
Part of the free CompTIA A+ Core 2 220-1202 course — 50 lessons and 62 hands-on labs.
This is an independent study companion for CompTIA A+ Core 2 220-1202 and is not produced by or endorsed by CompTIA.