It looked like a one-number change
Google Play raises its target API requirement every year. A warning appears in the console, someone bumps the number in the build settings, and that part takes five minutes.
The rest does not. Build it, put it on a real device, and the top and bottom of the screen are under system UI, the Back button does nothing, or the orientation you locked comes undone on a tablet.
That is because raising target API is a declaration that this app will follow the new behaviour rules. The moment the number changes, everything you had been exempt from applies at once.
And this is not a chore you can defer. Miss the deadline and you cannot ship updates at all.
Below are the ones that actually show up in a Unity game.
The required level and the deadline change from year to year. Always check the current bar in Google Play's target API requirements, and the full list of behaviour changes in the Android behaviour changes docs. What follows is what to check when you make the move.
What happens if you put it off
The deadline is fixed, and two things happen together once you pass it.
1. You cannot ship updates. New apps and app updates have to meet the bar to be submitted. Until you raise target API, nothing goes out — not a content patch, not a crash fix, not an urgent security fix.
2. New players stop arriving. An app below the bar can no longer be installed fresh on devices running an Android version newer than its own target API. That share of devices grows over time, so new installs dry up gradually.
To be precise: the app is not removed from the store. Players who already installed it keep playing. But no one new gets in, and you are left unable to change anything. On a live service the second part is the worse one — because when something goes wrong, you cannot do anything about it.
If you have already missed the date, check whether an extension request is open in the console. An extension buys time; it is not an exemption.
The rules arrive in two kinds
Android's behaviour changes mix two different things. Telling them apart narrows the work considerably.
| Kind | When it applies | What to do |
|---|---|---|
| Applies to every app | As soon as the OS updates, regardless of target API | Cannot be deferred |
| Applies once you raise target API | From the moment you bump the number | Check it as part of the bump |
What follows is the second kind. These are the ones you switch on yourself, so knowing what you turned on is most of the job.
What actually shows up in a Unity game
1. The screen goes under system UI — edge-to-edge
The app draws across the whole display, with the status bar and navigation bar sitting over it. There used to be an attribute to opt out; that escape hatch is now closed.
In a game it shows at the edges of the UI first. Currency counters in the top corners, a row of buttons along the bottom — anything pinned to the edge ends up under the status bar or the gesture bar.
In Unity the thing to look at is Screen.safeArea. It returns the area actually usable once system UI is subtracted, so if your canvas is laid out against the full display (Screen.width, Screen.height), everything is off by that difference. Projects that already handled notched devices are usually fine; projects that skipped that work get caught here.
2. Back does not arrive the way it used to — predictive back
onBackPressed() is no longer called, and the back key event is not delivered the old way either.
Unity games commonly take Android's Back as KeyCode.Escape. If opening the pause menu or stepping back a screen hangs off that, test it on a real device. There is a manifest flag that restores the old behaviour, but that buys time rather than solving anything.
3. Orientation lock comes undone on tablets and foldables — but games are exempt
On large screens, the manifest's orientation, resizability, and aspect-ratio restrictions are ignored. A portrait-only game can end up stretched to landscape on a tablet.
There is a games exemption here. Declaring the app category as a game in the manifest opts you out of that override.
<application android:appCategory="game">
<activity android:screenOrientation="portrait" />
</application>
Unity projects often ship without this attribute. If your layout falls apart on a large screen, start here. It may be a one-line problem.
4. Missed periodic work no longer runs in a burst — mostly a plugin concern
When work scheduled at a fixed interval gets skipped several times over, because the device was idle for a stretch, the old behaviour ran it once per missed slot. Now it runs once and moves on.
First, narrowing the scope: this is an Android-native story more than a Unity C# one. The offline-reward maths common in games compares timestamps on resume, so it does not apply.
What can be caught is a native plugin or third-party SDK running repeating work of its own — analytics uploads, push-token refresh, periodic sync. Vendors generally handle it, so the job on your side is confirming you moved that SDK to a version that supports the target API.
On a live game there is one more layer
If you have not launched yet, fix the items above, build, done. If you are already in service, it is different.
A target API bump is not finished until you rebuild, pass review, and players take the update. The deadline is fixed, so you plan backwards from the review window — and until the update lands, the existing build keeps running as it is.
The shape of this is identical to receiving an engine security advisory. As there, before you plan anything, confirm you can still rebuild that build at all. If the build machine has moved on, or nobody can reach the signing key, there is no schedule to make.
Worth checking on the security side
Some things are worth confirming while you are in here, because you are rebuilding and re-submitting anyway.
- Is the signing setup unchanged — as you rebuild, check that the key and the procedure are the same as before.
- Do your plugins and SDKs support the target API — especially the ones carrying native binaries. In the vendor's docs, read which version added support alongside when that version shipped. A plugin nobody has touched in a long time is a frequent blocker.
- Has anything crept in that should not ship — temporary logging or debug flags added while working through this should not go out with the build.
- Have you rebuilt your tamper baseline — when the build changes, the definition of a clean build changes with it. Repackaging detection is covered in the Unity MOD APK prevention guide.
Checklist
Before the bump
- Confirmed the current required level and deadline in the official docs.
- Know which target API the build currently on the store was made with.
- Confirmed the plugins and SDKs in use support the target version.
After the bump, on a real device
- UI at the edges of the screen is not hidden under system UI.
- Back correctly opens the pause menu and steps back a screen.
- Orientation and layout hold up as intended on tablets and foldables.
- Plugins and SDKs that run repeating work behave correctly on the target API version.
Release process
- Planned backwards from the review window.
- Checked the signing setup and build reproducibility together.
- Removed the temporary logs and flags.
If you are using OZero Security
Not our part
- We do not handle store policy for you. The target API bump, the review schedule, and the manifest settings are your team's work.
- UI and input problems caused by the behaviour changes above are game-code work as well.
Our part
- Since our SDK ships native libraries, keeping them compatible with the API level Google Play requires is our job. For the range we currently support, check the manual or ask us.
- On the rebuilt artifact, we identify executable binary tampering, debugger attachment and hooking, and untrusted runtimes such as emulators and rooted devices, which raises the cost of bypassing it.
If a policy deadline already has you rebuilding and re-submitting, folding protection into the same cycle costs less. Doing it separately later means one more review.
In closing: what goes up is not a number but a set of behaviour rules
Treat a target API bump as a build-settings change and a real device will surprise you. What it actually is: a declaration that you accept, all at once, the behaviour rules you had been exempt from.
So the order goes: raise the number, look at the screen, the input, and large screens on a real device yourself, then plan the review. Emulators tend not to reveal the first three.
And this deadline comes around every year. Write down what you checked this time and next year's pass is much shorter.
Next steps
- Check the protection scope — supported platform specs and what each plan (Standard / Pro) defends against.
- Start a quick integration — package import and setup steps are in the integration guide.
- Talk to us — get in touch about supported API levels or rebuild scheduling.