The Update You Did Not Schedule: What Google Play Does to a Running Camera Phone, and Which Switch Actually Helps

Short answer: Installing a new version of an app means the old one stops. Google says so plainly in its update documentation for managed Google Play: "if the app is in use when the update is ready to install, the system will close the app to complete the process." What Android then does is send the app a message — ACTION_MY_PACKAGE_REPLACED — not put its work back. Whether a camera resumes is therefore an app capability, not a platform guarantee. The control worth using is the per-app Enable auto update toggle on that one app's Play Store page, not the global setting, and the update is worth taking deliberately while you are standing in front of the device. Background Camera RemoteStream is what I build; everything below is about the platform and the store, not the app.

I gave the bad version of this advice myself

Turn Your Old Android Phone Into a Free Security Camera, an older setup guide of mine, has a bullet in the preparation list that says to turn off auto-updates so nothing interrupts recording. Plenty of other guides say the same thing. It is not wrong, exactly. It is the wrong granularity, it does not do quite what it sounds like it does, and it swaps a visible problem for an invisible one.

This is the mechanism underneath it, the documentation for each step, and the switch I would use now.

An update is a replacement, and a replacement ends what was running

The word "update" suggests something additive, applied to software that keeps going. On Android it is an install over an install. The package on disk is replaced, and the process that was running the old one does not carry on into the new one.

Google states the consequence in the update documentation for managed Google Play, in a note about its High priority update mode:

"even when using AUTO_UPDATE_HIGH_PRIORITY, updates to apps with larger deployments across the Android ecosystem may still take up to 24h. Also consider that if the app is in use when the update is ready to install, the system will close the app to complete the process."

Two things about that quotation, and the second matters more than the first.

That page is the Android Management API documentation — the enterprise side of Google Play, written for organisations that manage fleets of devices. It is not consumer Play Store documentation, and I am not going to pretend it is. But the sentence is describing an installer behaviour rather than a fleet policy: a package cannot be replaced underneath a process that is still using it. The management API is simply the place Google happens to have written it down in one line.

For a phone in a pocket this is invisible — the app closes, you open it again later, and nothing about your day changed. For a phone doing a job while nobody is looking at it, "the system will close the app" is the whole event.

What the platform does next is send a message, not restart the work

There is a specific broadcast for this. From Android's background execution documentation:

"ACTION_PACKAGE_REPLACED is sent to all registered listeners across all apps, letting them know that some package on the device was replaced. Because the broadcast is implicit, it will not be delivered to manifest-registered receivers in apps that target Android 8.0 or higher. ACTION_MY_PACKAGE_REPLACED is also an implicit broadcast, but since it is sent only to the app whose package was replaced it will be delivered to manifest-registered receivers."

Read that as an operator rather than as a developer. The platform's contribution to an app's recovery is a notification addressed to the app itself. Everything after that — noticing, restarting, re-acquiring the camera, resuming whatever it was doing — is the app's own code, written or not written by whoever built it. Nothing in Android undertakes to put a camera back.

So "does this app come back after it updates?" is a real question with a different answer for every app, and it is not answered by the app's feature list.

The test that settles it, for any app, in about three minutes. Wait until the app has an update available. Start it doing the thing you actually rely on. Update it on purpose from the Play Store, on the device, while you are watching. Then wait a minute and check — without opening the app, without tapping its notification, without touching the screen at all — whether it is doing that thing again. That is exactly the situation an unattended update creates, run at a moment when you are present to see the answer.

The wrinkle that decides the recommendation

It is tempting to reason about when an update can land and conclude you are safe. Google's managed-Play documentation lists the constraints for its default update mode:

"In this mode, the apps are updated automatically by default, when the following constraints are met:

The device is connected to a Wi-Fi network.

The device is charging.

The device is not actively used.

The app to be updated is not running in the foreground."

The same page adds: "Google Play typically checks for app updates once a day, so it can take up to 24 hours before an app update is added to the update queue."

Now look at the last constraint next to Android's platform documentation, which defines when an app counts as being in the foreground:

"An app is considered to be in the foreground if any of the following is true:

It has a visible activity, whether the activity is started or paused.

It has a foreground service."

(The list has a third condition, about another foreground app binding to the app, which is not what is going on here.)

A camera that works with the screen dark is running a foreground service — see FOREGROUND_SERVICE_TYPE_CAMERA: Keeping a Camera Alive With the Screen Off — that is the supported way to hold a camera while nothing is on screen. By the platform's definition, an app with a foreground service is a foreground app. By the store's constraint, an app running in the foreground is not auto-updated.

Does the store's "running in the foreground" mean the platform's definition? The management page does not say. The consumer help page does not discuss the constraints at all. I am not going to invent an answer, and this is the useful conclusion rather than a gap in it: do not build your arrangement on that constraint in either direction. Do not assume a running camera is protected from being replaced, and do not assume it is doomed either. Take the decision out of the inference and into a setting.

Switching auto-update off globally does not remove you from the path

The consumer documentation is direct about this, and it is the part the "just turn off auto-updates" advice skips:

"If Google determines that an app update fixes a critical security vulnerability, we may make certain app updates. These updates can occur regardless of update settings in the app or on your device."

That is a reasonable thing for a store to do. It also means the global switch is not the seal it looks like, and that you have turned off updates for the browser, the messaging app and everything else on the device in exchange for a guarantee you did not get.

There is a second thing an unattended update can do, and it is worse than stopping:

"When some apps get updated, they require new permissions. You may get a notification that asks whether you accept the new permissions."

An update can stop and wait for a person — on the one device in the building that was chosen precisely because nobody is standing at it.

The setting I would actually use

Leave the global control alone. Play's global setting lives under Settings, then Network Preferences, then Auto-update apps, with the options "Update all apps over Wi-Fi or mobile data", "Update with limited amount of mobile data", "Update over Wi-Fi only" and "Don’t auto-update apps." That switch governs every app on the device, which is far more than you meant to decide.

The per-app control is the one that fits. From Google's help page, on the device doing camera duty:

Open the Google Play app.
At the top right, tap your Profile picture.
Tap Manage apps & device, then Manage.
Find the app you want to update automatically.
Tap the app to open its Details page.
Tap More, then turn Enable auto update on — or, here, off.

Google's own description of the toggle: "When updates are available, the app updates automatically. To turn off automatic updates, turn off Enable auto update."

Then adopt a habit rather than a setting. Once a month, or whenever you happen to be at the device for another reason, open the app's Details page, take the update by hand, and stay until you have seen it doing its job again. Same when a version arrives that you actually want. You are not avoiding updates. You are choosing the minute.

Worth writing on a note taped to the mount, because the whole problem with this device is that you will not think about it again: updates are manual here.

What no app can do about it

An app cannot decline its own replacement, and it should not be able to. Software that could refuse to be updated on a device you own would be a considerably worse thing to have bolted to your wall than software that occasionally stops. The asymmetry is deliberate and it is on the right side.

Nor can an app promise that it always comes back. It can implement the recovery path, and you can test whether it did — but the moment of replacement is one where the app is not running, and no code that is not running can guarantee anything.

Which leaves exactly one lever, and it is not a technical one. You cannot make software immune to being replaced. You can decide when it happens, and be standing in front of the device when it does.