· ReadyStack
Worked example
Real numbers from this tool, line by line.
Six lines in an ordinary Android build file are now enough for Google Play to refuse a release, and the indie Flutter and Kotlin developers who own the upload button usually find out only after the bundle has been built and rejected.
Three Play gates closed on 31 August 2026. A new release has to target Android 16 (API level 36). A new release has to use Play Billing Library 8 or later. And since 1 November 2025, releases targeting Android 15 and above have had to support 16 KB memory pages, with the Play Console extension for that one running out on 31 May 2026. The extension window for the first two shuts on 1 November 2026.
None of that is visible where you work. Android Lint checks API compatibility, not Google's publishing calendar, so a billing-ktx:7.1.1 dependency draws no warning at all. Gradle builds it happily. The Play Console does know, but it only tells you once you have uploaded the bundle, which means the fastest feedback loop available to a solo developer is: build, sign, upload, wait, get rejected, read the message, guess which of the three gates it was.
So I wrote the check into the editor.
Play Release Blocker Lint reads build.gradle, build.gradle.kts, libs.versions.toml, AndroidManifest.xml and Expo's app.json, and prints the lines that stop a release with the date each gate closed and the line to write instead:
8: [error] Play stopped accepting this on 2026-08-31: a new release must target
Android 16 (API 36). API 35 keeps the listing alive but no update can be
published. The extension window closes 2026-11-01. Fix: targetSdk = 36
16: [error] Play Billing Library below 8.0.0. Since 2026-08-31 Play rejects any
new release using it. Fix: com.android.billingclient:billing:8.0.0
25: [error] Compressed native libraries cannot be 16 KB aligned. Play has required
16 KB page-size support since 2025-11-01.
Fix: android:extractNativeLibs="false"There are 31 rules. The publishing gates with a date are only the first group. The second is what actually breaks on the day you raise the target: apps targeting API 36 can no longer opt out of edge-to-edge, and orientation, resizability and aspect-ratio restrictions are ignored on displays 600dp wide and above, so a screenOrientation="portrait" activity fills a tablet in whatever orientation the user is holding it. That is the part that turns a one-line version bump into a week of layout work, and it is worth knowing before you promise a date.
The third group is permissions that need an approved Play declaration before review will pass — QUERY_ALL_PACKAGES, MANAGE_EXTERNAL_STORAGE, REQUEST_INSTALL_PACKAGES, SMS and Call Log, exact alarms, untyped foreground services. The fourth is bundles Play refuses outright: a debuggable manifest, the deprecated monolithic Play Core library that crashes on Android 14 and newer, JCenter still sitting in your repositories block.
Checking the file you have open is free and it is the whole job — all 31 rules, every line, every date, every fix, no watermark and no run counter. The same 31 rules also run in the browser, so you can paste a file in and see the answer without installing anything.
What the licence adds is a different kind of work rather than a bigger helping of the same one: scanning every module, flavour and manifest in the repo in one command, because the blocker is usually in the library module you did not have open; a JSON output your CI can fail on, so the build breaks on your runner days before it breaks on the upload; a dated release-readiness report you can hand to a client; and a re-check on every save while you migrate.
15 seconds — what it actually does
Questions people ask
What does this actually do?
It reads your Gradle files, version catalogs, Android manifests and Expo app.json, and flags the exact lines that make Google Play refuse a release: a targetSdk below API 36, a Play Billing Library below 8, native libraries that cannot align to 16 KB pages, and permissions that need an approved Play declaration. Each finding carries the date that gate closed and the line to write instead.
Who is it for?
Indie Android developers and small studios who ship Kotlin, Flutter, React Native or Expo apps to Google Play and do not have a release engineer. If you own the upload button and find out about a policy deadline when the Play Console rejects your bundle, this is written for you.
Why is a free tool not enough?
Android Lint and the Gradle warnings check API compatibility, not Google Play's publishing calendar, so they stay silent on a Billing Library 7 dependency. Play Console does know, but it only tells you after you have built and uploaded the bundle. A chatbot confuses API 35, the availability floor, with API 36, the publishing gate, and quotes last year's date.
What is free and what is paid?
Checking the file you have open is free and complete: all 31 rules, every line, every date, every suggested fix, with no watermark, no time limit and no locked results. The licence adds a different kind of work: scanning every module in the repo at once, failing your CI, re-checking on save, and exporting a dated report you can hand to a client.
What would this cost otherwise?
Upwork publishes a $25 per hour median for Android developers, with a typical range of $15 to $35, and benchmarks for experienced freelance Android work run far above that. One rejected upload costs a rebuild, a re-upload and another review wait, which is more than an hour before anyone has fixed anything.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. Android Release Lint - target API 36, Play Billing and polic checks the file you open against 31 rules from a rule set dated 2026-09-20, and points at the exact line with the fix. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.