Short answer: If an app targets Android 11 or higher and nobody interacts with it for a few months, the system resets its runtime permissions. On Android 12 and higher it also force-stops the app, blocks it from running background jobs, stops it receiving push notifications, and clears its cache. Google's documentation is explicit that running a scheduled job does not count as usage. A phone working as a camera is the one arrangement whose correct operating state is "nobody ever opens it", which puts it on precisely the wrong side of that rule. One toggle per device turns the behaviour off, it lives in App info, and it takes about thirty seconds. Everything below is checkable on your own handset — Background Camera RemoteStream is what I build, and the toggle matters exactly as much whichever camera app you picked.
Most writing about keeping a camera alive on Android — including mine — is about surviving the next hour: the service that must not be killed, the screen that must be allowed to go dark, the process that must not be swapped out. That is a real fight and it is well documented.
This is a different clock. This one runs for months, and it does not care whether your setup is working. It cares whether a human has touched it.
The failure this produces
There is no crash. There is no error. The camera app is still installed, still on the launcher, still sitting where you left it. What has changed is one line in Settings: the camera permission that you granted in August now reads Denied, and nothing on the device asked you about it.
That is a bad shape of failure for a camera, because a camera's job is to be unremarkable. Everything about the arrangement looks exactly as it did the day you set it up.
What the platform actually does
From Google's app hibernation documentation:
| Target SDK | Device | Effect of hibernation |
|---|---|---|
| Android 12+ | Runs Android 12+ | Runtime permissions reset. No background jobs or alarms. No push notifications, including high-priority FCM. App cache deleted. |
| Android 11 | Runs Android 11 | Runtime permissions reset. |
| Android 11 | Runs Android 6.0–10 with Google Play services | Runtime permissions reset. In effect since December 2021. |
Note the third row. This is not a problem confined to handsets new enough to be interesting. The auto-reset half of it was back-ported through Play services to devices going back to Android 6.0, which is to say: to precisely the population of retired handsets that people put on camera duty.
What counts as "usage", and the sentence that catches this setup
The documentation defines app usage generously at first. A resumed Activity counts. Interacting with a widget counts. Interacting with a notification counts — though dismissing one does not. More broadly, "as long as a component of the package is invoked, it is still considered app usage".
Then it adds the qualifier that decides this whole question:
This excludes usage that would not occur if the app is force stopped. For example, running a job does not count as usage even though the job service component is invoked.
And it gives a list of behaviours that, on their own, land an app in hibernation after a few months:
- running a scheduled job with
JobScheduler - receiving an implicit broadcast
- scheduling alarms
A machine quietly doing the work you asked it to do is not, by this definition, a machine anybody is using.
Where the documentation stops, and where I stop with it
A long-running foreground service started deliberately by the user is in neither list. It is not named as usage and it is not named as a non-example.
You can argue it either way. It is a component of the package being invoked, which sounds like usage. It is also a thing that would stop if the app were force-stopped, which is the exact carve-out the qualifier describes. The persistent notification a foreground service must post is a genuine escape hatch, because interacting with a notification does count — but existing is not interacting, and a notification you never tap is a notification the system has no reason to credit you for.
I am not going to resolve that for you with a confident paragraph, because I cannot, and because the whole point of a camera is that you find out about problems before they matter rather than after. The correct engineering response to an unspecified behaviour whose failure mode is losing camera permission is not to model the behaviour. It is to opt out of it. That is one toggle, it is free, and it removes the question entirely.
The exemptions tell you who this feature was designed around
Android does grant blanket exemptions from hibernation. The categories are worth reading as a group: work-profile apps, device policy controllers, carrier-privileged apps, third-party app stores, and any app with no launcher icon.
Every one of those is institutional. An employer, a carrier, a device administrator, a store. There is no category for a thing a household set up on purpose and depends on. That is not an oversight, and it is not malice either — it is a straightforward consequence of who writes the exemption list and what they can verify. But if your mental model is "surely the OS knows this app is doing a job", the exemption list is the evidence that it does not, and has no mechanism to find out.
Turning it off, by version
The option lives on the App info screen for the camera phone's camera app. The label changed across releases:
| Device runs | Where | Toggle to turn off |
|---|---|---|
| Android 13 or higher | App info | Pause app activity if unused |
| Android 12 | App info | Remove permissions and free up space |
| Android 11 | App info → Permissions | Remove permissions if app isn't used |
| Android 6.0–10 with Play services | Play Store → Menu → Play Protect → Permissions for Unused Apps | Remove permissions if app isn't used |
To see whether it has already happened to something, Google's own Play help page points at Settings → Apps → Unused apps, which lists what the system has already optimised. Worth a look on any handset that has been sitting unused for a while before you press it into service — it may already be in this state on arrival.
The part that costs you twice
The documentation is clear that leaving hibernation is not a repair:
When the user next interacts with your app, your app exits hibernation, and it can create jobs, alerts, and notifications again. However, the system doesn't [...] re-grant your app's runtime permissions. The user must re-grant these permissions for your app.
Scheduled jobs, alarms and notifications from before hibernation are not rescheduled either.
So opening the app when you finally notice does not put things back. It wakes the app up into a state where it has no camera permission and no schedule, and you have to grant and restart by hand. If the reason you opened it was that you wanted to look at something that happened last night, you are already too late by a long way.
Verifying rather than trusting
If you have adb and a spare five minutes, the platform exposes the state directly:
adb shell cmd app_hibernation get-state <package-name>
The docs also describe how to bring the threshold down to a second so you can watch the whole thing happen on a test device rather than waiting a quarter for it — set auto_revoke_unused_threshold_millis2, run the PermissionController job, then put the threshold back.
If you do not have adb, the Settings path above is the same information with fewer steps. Either way, do not take a blog post's word for the state of your own device, including this one.
The honest limitation
A purpose-built camera does not have this failure mode, and it is worth being straight about why. It is not because the vendor is more careful. It is because that device is not a general-purpose computer that also has to protect its owner from a hundred applications they installed once and forgot. Hibernation is a good feature. On a normal phone it is doing something genuinely useful, and the people it protects vastly outnumber the people running a camera.
Running your camera on a device that has other jobs means inheriting that device's opinions about what "unused" means. That is a real cost of this approach, not a footnote to it, and the fact that it is fixable with one toggle does not make it zero — you have to know the toggle exists.
What to do this week
- On the camera handset, open Settings → Apps → your camera app → App info and turn off the unused-apps toggle, using the wording table above.
- Check Settings → Apps → Unused apps to see whether the system has already acted on anything.
- While you are in App info, confirm the camera permission still reads Allow rather than Denied. If it reads Denied, that is your answer.
- Put a recurring reminder somewhere you will actually see it — once a quarter — to open the app on the camera phone and tap around for ten seconds. A resumed Activity is unambiguous usage under the documentation, and it is the cheapest insurance available.
Background Camera RemoteStream records with the screen off and keeps the footage on the phone: Play Store · superfunicular.com
Related: how the screen-off recording path actually works, and heat and battery on a handset left running.
Sources: Android Developers, App hibernation (last updated 2026-08-14); Google Play Help, Manage unused apps on your Android device.
Top comments (0)