One Deadline, Two Different Rules: What Google Play's August 31 Target-API Change Actually Does to an Old Phone Running as a Camera

Five days from now a Google Play deadline lands. If you run an old Android phone as a security camera, you have probably seen a headline about it and wondered whether the thing watching your front door is about to stop working.

It is not. But the reason is more interesting than the reassurance, because August 31 is not one rule. It is two rules with two different API levels sharing one date, and almost every summary collapses them into a single sentence that is wrong in at least one direction.

Here is what the primary documentation says, what it means for a phone whose entire job is to sit on a shelf and record, and — the part that surprised me — why the older your camera phone is, the less this affects you.

Will my old phone's camera app stop working on August 31, 2026?

Short answer: no. Nothing on your phone changes on August 31. The target API level requirement governs what developers may submit to Google Play and which devices can newly discover an app in the store. Google's own help page is explicit about installed apps: "Users who have previously installed the app from Google Play will not be impacted and will still be able to discover, re-install, and use the app on any Android OS version that your app supports." An app already on your camera phone keeps recording exactly as it did on August 30.

What does Google Play's target API level requirement actually do?

Short answer: it does two separate things. From August 31, 2026, "New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play" — that is a submission rule aimed at developers. Separately, "Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app's target API level" — that is an availability rule aimed at store listings. One date, two API levels, two entirely different consequences.

The two rules, and why conflating them produces nonsense

The submission rule sets the bar at API 36; the availability rule sets it at API 35. They are not the same threshold and they do not punish the same thing.

The submission rule is a gate on new binaries. After August 31, if a developer wants to ship any update — a bug fix, a permission change, a one-line typo correction — the upload must target Android 16. An app that stays on API 35 is not removed; it simply cannot receive another update through Play.

The availability rule is a gate on discovery, and it is graded rather than binary. In Google's words, apps that fall below the line "will only be available on devices running Android OS that are the same or lower than your apps' target API level." The developer-facing version puts it more bluntly: "Out-of-date apps are unavailable to new users of devices that run newer versions of Android."

Two things follow that people routinely get wrong:

1. Nobody's installed app is deleted. Neither page describes removal, deactivation, or a kill switch. The words "removed" and "delisted" do not appear. The only mechanism either document describes is restricted availability to new users on newer-OS devices.
2. A stale app does not vanish from the store. It narrows — staying visible to a shrinking set of devices, specifically the old ones.

There is an escape hatch: "If you need more time to update your app, you'll be able to request an extension to November 1, 2026." The form only reaches developers who are already non-compliant, arriving "through the details page of the warning or issue on the Policy status page in Play Console" — which is why compliant developers report being unable to find it.

The inversion: the older your camera phone, the less this touches you

Suppose an app freezes at API 34 and never updates again. The availability rule says it remains available on devices "running Android OS that are the same or lower than your apps' target API level." API 34 is Android 14 — so that abandoned app stays installable on Android 14, 13, 12, 11, all the way down to whatever its minSdkVersion allows.

The devices it disappears from are the new ones.

If your camera is a phone you retired in 2019 running Android 10, the target-API deadline is close to invisible to you. The listings that quietly stop appearing for other people still appear for you. Meanwhile the person buying a brand-new handset this month is the one who gets Google Play's message — which the help page quotes as telling the user "this app is not available to install on their device because it was made for an older version of Android."

The old-phone-as-camera crowd has spent years being the group platform changes hurt first. On this rule, we are the group it reaches last. That is worth stating plainly rather than dressing the deadline up as a crisis.

The number that actually decides whether an app installs on your phone

None of the above is what stops an app from installing on an old device. That is a different manifest attribute entirely, and confusing the two is the most common misreading of this topic.

targetSdkVersion is, per the <uses-sdk> documentation, "an integer designating the API level that the application targets" — a statement of what the developer tested against. Critically: "The application is still able to run on lower versions (down to minSdkVersion)."

minSdkVersion is the floor, and it is the one with teeth: "The Android system prevents the user from installing the application if the system's API level is lower than the value specified in this attribute." The docs explain why the check is strict rather than advisory — "If the application somehow installs on a platform with a lower API level, then it crashes at runtime when it tries to access APIs that don't exist."

So, for anyone provisioning an old phone as a camera:

• minSdkVersion too high → the app will not install, and Play filters it out of your search results before you ever see it. Google Play "uses the <uses-sdk> attributes declared in your app manifest to filter your app from devices that don't meet its platform version requirements."
• targetSdkVersion low → the app installs and runs fine on your old phone; it is newer phones that lose access.

Raising the target does not raise the floor. A developer moving from API 34 to API 36 does not thereby abandon Android 8 users unless they separately raise minSdkVersion. Two independent decisions, routinely discussed as one.

The runtime half nobody mentions: compatibility behaviours

There is a second, quieter effect of the target level, and it operates on your phone rather than in the store.

From the same manifest documentation: "if the API level of the platform is higher than the version declared by your app's targetSdkVersion, the system can enable compatibility behaviors so that your app continues to work the way you expect." Declaring a higher target opts out of those shims: the attribute "informs the system that you have tested against the target version, and the system doesn't enable any compatibility behaviors."

For a camera app this is not academic. Nearly every constraint we have written about here — background execution limits, foreground service types, permission auto-reset, storage access — arrived as a behaviour change gated on the target API level. That is precisely why an app suddenly has to declare a camera foreground service type at all, a change we covered in FOREGROUND_SERVICE_TYPE_CAMERA: keeping a camera alive with the screen off. Raising the target means accepting the current generation of those rules instead of being handed a legacy shim.

The documentation gives exactly one concrete example of a compatibility behaviour (the Holo theme and screen compatibility mode at API 11) and otherwise points at Build.VERSION_CODES. It never enumerates them. So "what changes when this app targets API 36" is not a question the platform docs answer in one place, for anybody.

One user-visible consequence is documented, far below any current deadline: "as of Android 10 (API level 29), users see a warning when they start an app for the first time if the app targets Android 5.1 (API level 22) or lower."

The second Play requirement, on a completely different clock

The other Play requirement that gets mentioned in the same breath is 16 KB memory page sizes — and the two documents never cross-reference each other. Different triggers, different dates. Merging them is an invention, not a reading.

From the page-sizes guide: "Beginning with Android 15, AOSP supports devices that are configured to use a page size of 16 KB (16 KB devices)." The Play requirement is scoped by target level: "all apps targeting Android 15 (API level 35) and higher must support 16 KB memory page sizes on 64-bit devices on Google Play." And the enforcement date is not August 31, 2026: "Starting February 1, 2027, if your app updates don't support 16 KB memory page sizes, you won't be able to release these updates."

Who it affects is narrower than the coverage suggests: "If your app only uses code written in the Java programming language or in Kotlin, including all libraries or SDKs, then your app already supports 16 KB devices." Native code is the trigger — "If your app uses the Android NDK, then your app uses native code" — and the tell is mechanical: "If no shared object files are present or there is no lib folder, then your app doesn't use native code."

Google publishes its own figures, and the camera line is the relevant one: "Faster camera launch: 4.48% faster hot starts on average, and 6.60% faster cold starts on average," alongside "Improved system boot time: improved by 8% (approximately 950 milliseconds) on average." The page immediately qualifies all of it: "These improvements are based on our initial testing, and results on actual devices will likely differ." I am quoting those, not claiming them; I have measured none of them.

One failure mode is worth flagging because the symptom is so confusing: "the app may appear to work, but when built from a bundle in Play, it won't install."

What the documentation does not tell you

Six things I went looking for and could not find stated anywhere in these primary sources. Better to name the gaps than fill them from memory.

1. No statement about existing users on the developer-facing page. The target-sdk guide never uses the phrase "existing users." That reassurance lives only on the Play Console help page — a different document most developers never open.
2. No enumeration of compatibility behaviours. One example (Holo, API 11), then a pointer to Build.VERSION_CODES. No list of what actually changes between API 34 and API 36.
3. No date for existing published apps under the 16 KB rule. February 1, 2027 is scoped explicitly to "app updates." Nothing states what happens to an already-published app that never updates again.
4. No treatment of sideloaded apps. Both requirements are stated as applying "on Google Play." Neither page says anything about an APK installed outside the store — a live question if your camera app is not a Play install.
5. No quantification of the 16 KB memory cost. Devices "use slightly more memory on average" — no MB, no percentage. Binary size is likewise "a slight increase" with no figure.
6. No cross-reference between the two requirements. The target-API page never mentions page sizes; the page-sizes page never mentions August 31 or November 1. Any article presenting them as one deadline is joining them itself.

What to actually do if your camera is an old phone

Nothing, on August 31. But two habits are worth forming, and neither is urgent:

• Check when your camera app last shipped an update, not what API level it targets — the latter is not shown in the store listing. An app updated in the last few months has a developer keeping pace with these gates. An app that has shipped nothing in two years may be one that has quietly stopped being able to.
• Install the app on the camera phone once, deliberately, while it is still available to you. Installed apps are unaffected and remain re-installable "on any Android OS version that your app supports" — an install is durable in a way a store listing is not.

Background Camera RemoteStream is a Play install, records with the screen off, stores video locally on the device, and serves its live view from a small web server on the phone itself — so the parts you depend on run on your hardware, not on someone's server. It is on Google Play, with more at superfunicular.com.

Related reading

• How an Android phone keeps recording video with the screen off — the foreground-service mechanism these API rules keep reshaping.
• A foreground service is not immortal: Android's low memory killer on a 2 GB phone — the other constraint that binds hardest on old, cheap devices.
• The camera app you deliberately never open: hibernation and permission auto-reset — a behaviour change that arrived by exactly this route.
• Why does my Android camera stop recording when the screen turns off? — the background-execution rules underneath all of it.
• What happens to a phone security camera during a power cut or an internet outage? — the other "does my camera survive this" question, with a similarly asymmetric answer.

---

Sources, all read on 2026-08-26: Target API level requirements for Google Play apps · Meet Google Play's target API level requirement · <uses-sdk> manifest element · Support 16 KB page sizes. Every quoted sentence is verbatim from those pages. No claims are made here about any other app's internals or behaviour.