Device Health
Device health is the page that tells you whether the rest of MobileTracking is actually working. It lists every paired phone with its battery, its last check-in, its app version and the state of the permissions the app depends on, so a quiet map never gets mistaken for a quiet afternoon. When something has been switched off, you find out from this page rather than from a gap you notice a week later.
What the device health page shows you
One row per phone, and enough detail to tell the difference between fine, flat, and switched off.
Each device row names the phone, the child it is paired with, the Android version and the version of the family app it is running. Next to that sit the two numbers you will look at most: battery level, and the time of the last check-in written as “4 minutes ago” rather than a raw timestamp you have to decode. Below them is a short list of the permissions the app needs, each either healthy or clearly flagged.
A row is only ever in one of a few honest states. Reporting normally. Reporting late. Silent for longer than expected. Missing a permission. Protection switched off. Unpaired. Every state comes with one sentence explaining what it means and, where it applies, a button that walks you through the fix rather than leaving you to guess.
There is also a tamper log. It records the moments that change what the app can do: a permission granted or revoked, battery optimisation turned back on, the app force stopped, protection disabled, the device unpaired. Each entry has a time, so a gap in your location history can usually be matched to the exact event that caused it.
- Battery level and last check-in time per phone.
- Android version, app version, and pairing state.
- Location, notification access and battery settings, each flagged if unhealthy.
- A dated log of permission and protection changes.
What “offline” really means
Nothing here runs on a fixed clock, so the word offline needs a more careful definition than most apps give it.
The child app checks in on a schedule that flexes with what the phone is doing. It reports more often while moving, less often while sitting still on a desk, and it defers work when Android decides the phone should be dozing. There is no promised heartbeat every sixty seconds, because forcing one would cost battery all day to buy you almost nothing.
So “offline” does not mean “the second check-in was missed”. It means the phone has been quiet for meaningfully longer than its own recent pattern, taking into account how it has been behaving for the last few hours. A phone that normally checks in every four minutes and has said nothing for forty is treated very differently from one that has been idle and slow all evening.
The most common innocent causes are simple: the phone is off, the battery died, there is no data signal, or Android’s battery saver has stretched the intervals out. The less innocent causes are equally visible: a revoked location permission, battery optimisation switched back on, the app force stopped from the system settings, or the app removed altogether. Device health separates these rather than lumping them into one vague warning icon.
Everything the page reports comes from the phone itself, over an encrypted connection to your account, and it is recorded with the phone’s own timestamp. When a device has been offline and comes back, its queued events upload with their original times, so the log reads correctly afterwards instead of collapsing a lost evening into a single moment.
How to fix a missing permission
Most problems on this page are one settings screen away from solved, and the app knows which screen.
When a permission is flagged, the row tells you which one and what it stops working. Location set to “while using the app” means background reporting and place alerts will not fire reliably. Notification access switched off means keyword alerts go quiet. Battery optimisation switched back on means check-ins arrive in clumps or not at all. The consequence is written next to the problem, so you can judge whether it needs sorting now or at the weekend.
You can send a fix request from your panel. It appears on the child’s phone as a plain notification saying which permission needs restoring and why, with a button that opens the right Android settings screen directly. On most phones that is three taps. It is deliberately a request rather than a silent remote change: no app can grant itself Android permissions, and any product claiming otherwise is describing something you should not install.
If you have the phone in your hand, the same checklist is available on the device itself. Manufacturer skins hide these settings in different places, so the guidance names the actual menu path for Samsung, Xiaomi, Oppo and stock Android rather than offering one generic instruction that fits nobody. Autostart and protected apps lists are the usual culprits when everything looks correct and check-ins still stop overnight.
Silence is information
The failure mode of every monitoring product is a parent who believes an empty screen means an uneventful day.
An app that only shows you activity teaches you to relax when nothing appears. But nothing appears for two very different reasons: the day was ordinary, or the app stopped working on Tuesday and nobody noticed. Device health exists to keep those two apart, which is why it is a page in its own right rather than a small icon somewhere.
That is also why the alerts from this page are pushed by default. A location alert you miss is an inconvenience. A permission that has been off for four days quietly invalidates everything else you thought you were seeing, so it deserves to interrupt you once.
Used properly, this page is boring, and it should be. Glance at it after setup, glance at it when something feels off, and let it interrupt you the rest of the time. If every phone says reporting normally with a recent check-in, then the quiet map really is a quiet afternoon.
What device health deliberately does not do
There are things a monitoring page could plausibly offer that we have chosen to leave out.
It cannot force a setting. Android does not allow an app to grant its own permissions or to prevent a user from revoking them, and we do not use accessibility loopholes to fake it. Everything here works by making changes visible, never by making them impossible.
It does not lock or wipe the phone. There is no remote kill switch, no forced factory reset, and no way to brick a device from your panel. Those powers belong to corporate device management, not to a family app.
It does not hide from the person carrying the phone. The child app is visible, and the tamper log is not a secret file: if you can see that a permission was switched off at 21:14, so can they. The point of the log is to make an honest conversation possible, not to build a case.
It also does not read anything private in order to know a phone is healthy. Battery, check-in times, app version and permission states are the whole of it. Device health has no interest in the contents of the phone.
Read the device list first
Before you trust any other screen, check that every phone says it is reporting and that the last check-in is recent. Thirty seconds here saves you from misreading everything else.
- Battery and last check-in on every row.
- Plain state labels instead of coloured dots alone.
- A tamper log with times attached.
Match phones to children
Each child can have more than one device, and each device shows its own health. An old tablet that stopped reporting months ago is worth unpairing rather than leaving in the list.
- See every device a child has paired.
- Unpair anything no longer in use.
- Keep alerts pushed for health problems.
Restore the permission together
A fix request opens the exact Android screen that needs changing. Doing it with your child present keeps the whole thing ordinary rather than accusatory.
- Location set to “allow all the time”.
- Notification access on, if you use keyword alerts.
- Battery optimisation off for the family app.
Battery, last check-in, app version, permission state, and a dated tamper log.
Flexible check-ins, compared against the phone’s own recent pattern instead of a fixed clock.
No remote wipe, no forced settings, no hidden log, no reading of private content.
What your child sees
The same health information is available on their phone: what is switched on, what is being shared, and when the app last checked in. If a fix request arrives, it says who sent it and what it is for. Nothing on this page is a trap, because the person carrying the phone can read every line of it.
- Same facts, both sidesStatus, sharing and check-in times are visible on the phone too.
- Requests, not forceA permission fix is a notification they act on, never a silent change.
- Uninstalling is possibleThey can remove the app, and you will see that clearly rather than never.
| State | What it means | Likely cause | What to do |
|---|---|---|---|
| Reporting | Recent check-in, all permissions healthy | Everything is working | Nothing at all |
| Reporting late | Check-ins are arriving, but slower than usual | Battery saver, weak signal, low battery | Wait, or ask them to charge the phone |
| Silent | No check-in for much longer than this phone’s pattern | Phone off, flat battery, no data | Call or message before assuming the worst |
| Permission off | Location or notification access has been revoked | Changed in Android settings | Send a fix request and ask why |
| Protection off | Removal protection has been disabled | Switched off on the phone | Talk first, then re-enable together |
| Unpaired | The app has been removed or signed out | Uninstalled, or the account was signed out | Re-pair in person, with a conversation |
Usually within tens of minutes, judged against that phone’s own recent rhythm rather than a fixed timer. Permission changes and uninstalls are flagged much faster, because the app reports them as they happen.
No. They can revoke permissions or uninstall the app, as Android allows. What they cannot do is make that invisible to you.
You can send a request that opens the correct settings screen on their phone. No app can grant Android permissions on its own, and any that claims to is doing something you should not want on a child’s phone.
Manufacturers manage background apps differently, and battery saver modes make it worse. Excluding the family app from battery optimisation and enabling autostart usually evens the two phones out.
No. Battery, check-in times, app and Android versions, and permission states. It has no interest in messages, photos or the contents of the phone.
Know that it is actually working
Pair an Android phone and watch the device health page fill in: battery, check-in times, permission state and a plain tamper log, so silence never has to be guesswork.
Related features: Setup and Pairing, Multiple Children, and The Child App.