DEV Community: Tim

Google Play's API 36 deadline passed — here's the extension and the upgrade checklist

Tim — Sat, 03 Oct 2026 11:12:40 +0000

On August 31, 2026, Google Play stopped accepting new apps and app updates that don't target Android 16 (API level 36). If you haven't upgraded yet, you're not reading a warning about the future — your next upload is already blocked.

The good news: there is a documented way to buy time. The bad news: it's a one-time extension to November 1, 2026, requested through a form in Play Console. It's not automatic, and November 1 is a hard date. If you're blocked, file the extension today — then do the work, because the extension is not a plan.

The rule, precisely

Phones, tablets, foldables: new apps and all updates must target API 36+. The block hits at submission in Play Console — even a one-line crash fix can't ship until targetSdk goes to 36.
Wear OS and Android Automotive: API 35+. Android TV and Android XR: API 34+.
Apps you never touch again don't vanish, but they stop being available to new users on devices running a newer OS than your target. An app left on API 34 quietly stops being installable on current phones — which looks identical to your install rate dying for no reason.
Permanently private apps restricted to one organization and internal distribution only are exempt.

Two companion gates ride the same deadline: apps using Play Billing must be on Billing Library 8.0.0+, and if you ship native code, Play starts refusing uploads without 16 KB page-size support on February 1, 2027. Check both while you're in there.

What actually breaks when you raise targetSdk to 36

Changing the number takes a minute. Everything after that is the work:

Edge-to-edge is now mandatory. The opt-out is dead. Deprecated flags like systemUiVisibility and setDecorFitsSystemWindows(false) misbehave at target 36. Use enableEdgeToEdge() plus proper WindowInsets handling, and audit every screen for content hidden under system bars.
Predictive back is default-on. If you still override onBackPressed(), migrate to the OnBackPressedDispatcher / BackHandler APIs.
Orientation and resizability restrictions are ignored on large screens (sw ≥ 600dp). If you lock orientation, test on a tablet.
16 KB page sizes. Native libraries compiled for 4 KB pages fail on 16 KB devices. Check every .so with readelf -lW — every LOAD segment needs p_align of 0x4000.
The toolchain moves together. You can't just bump targetSdk: AGP ~8.13, Gradle 8.13 (the documented pairing), Kotlin 2.x, compileSdk 36. Bump them in the safe order and keep a green build at each step.
Billing v8 migration. enableOneTimeProducts() and the new query APIs are the most-reported breakage — outdated wrappers like old react-native-iap versions can pin an old billing client transitively, so check the resolved dependency tree, not just your declaration.

Per-framework gotchas differ: Flutter devs hit edge-to-edge insets and plugin native code; React Native devs hit the billing wrapper pin and Hermes/NDK alignment; Capacitor/Cordova devs often discover a plugin ships a 4 KB-aligned .so they never knew about.

The verification pass

After the upgrade, verify from the built artifact, not from your source constants:

aapt2 dump badging app-release.aab | grep -i targetSdk
./gradlew :app:dependencies | grep billingclient
readelf -lW path/to/every/arm64-v8a/*.so | grep LOAD

Then test on a real Android 16 emulator — and if you ship native code, on a 16 KB system image too. The Play Console pre-launch report won't catch a page-alignment crash reliably.

The full checklist

I've packaged everything above into a complete upgrade kit — the 5-question blockage self-check, the extension-filing walkthrough (exact Play Console path), the toolchain matrix with safe step order, 8 behavior changes with copy-paste fixes, per-framework notes, the 16 KB verification commands, a 12-symptom breakage catalog, and the 7 mistakes that cost devs the most time: https://8286544375711.gumroad.com/l/yuwbzo

Disclosure: the kit is a paid $29 product. Everything in this article is free and standalone — the kit is for people who want the complete checklist in one place instead of assembling it from the docs.

(Independent guide — not affiliated with Google. Verify deadlines against the official target API requirements page; policy details evolve.)

The EU put a 24-hour clock on your side project's vulnerabilities

Tim — Fri, 02 Oct 2026 11:12:30 +0000

On September 11, 2026 — three weeks ago as I write this — the EU Cyber Resilience Act's reporting obligations went live. If you ship software into the EU, you are now a "manufacturer" with a legal clock: an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure (or one month for a severe incident). All filed through ENISA's Single Reporting Platform.

A late-September Bitkom survey of 1,003 German companies found only 29% understand what the CRA means for their own business, and 28% have never heard of it at all. If you're a solo dev shipping an app, you're probably in the 71%.

Does this apply to you?

The CRA covers "products with digital elements": software whose foreseeable use involves a data connection. Mobile apps, desktop apps, browser extensions, Electron apps, plugins, firmware, container images — yes. It applies regardless of where you're headquartered, and it covers products already on the market, not just new launches.

Pure SaaS (everything runs on your servers, users only see a website) is generally out — that's a different regime. But if your SaaS ships a downloadable client, mobile app, or agent, that component is in scope. Commercial open source is in; pure non-commercial open source is out.

The part everyone gets wrong

The 24-hour clock does NOT start when you first hear a rumor. Per Commission guidance, it starts when an initial assessment gives you reasonable certainty of active exploitation or a severe incident — not on first suspicion, not on a scanner finding. And every CVE in your dependency tree is not a 24-hour event: presence ≠ exploitation. Only actively exploited vulnerabilities and severe incidents are reportable.

The solo-dev setup (do this week, not during an incident)

One intake channel. A security@ address plus a SECURITY.md in every repo. The clock starts while you're searching inboxes if reports scatter.
A 15-minute triage checklist. Is it my product? Is there evidence of active exploitation? How many users affected? Write it down — this log entry is your "awareness timestamp," and every deadline counts from it.
Pre-written drafts. Your 24-hour early warning, 72-hour notification, and user notice, written now while you're calm. Filing should take 20 minutes at 2am, not 20 hours.
ENISA platform readiness. EU Login accounts for you and one backup person. Know your CSIRT routing now (if you have no EU establishment, there's a decision tree — work it out in advance).
A dated evidence log. Product inventory, your role per product, every intake record, every filing with timestamps. If a regulator ever asks, this is your answer.

The honest framing: enforcement against tiny indie teams is unlikely to be anyone's first priority. But the duty is live now, and "we had no process" is the worst possible position during an actual incident.

The five mistakes I keep seeing

Treating every CVE as a 24-hour event (burns credibility with the CSIRT).
No intake channel — reports arrive via DMs and forgotten inboxes.
"I'm too small to matter" (the duty applies regardless of size).
Designing the process during the incident.
Forgetting to inform users — if you don't, the CSIRT can do it for you, and their version will be worse for your reputation.

Disclosure: I build small compliance kits for indie devs. This article's playbook is expanded in my $29 CRA 24-Hour Reporting Kit — the manufacturer decision tree, the full reporting cascade, what counts as reportable, the solo intake pipeline, copy-paste filing drafts for each stage, the ENISA walkthrough, and the evidence-log template: https://8286544375711.gumroad.com/l/cra-reporting-kit

Google's Android developer-verification enforcement is live (first wave) — what sideloading devs should do now

Tim — Thu, 01 Oct 2026 07:13:22 +0000

On September 30, 2026, Google's developer-verification enforcement went live in the first wave: Brazil, Indonesia, Singapore, and Thailand. Here's the scope, straight from Google's own documentation: right now it covers apps downloaded from participating stores (Google Play, Samsung Galaxy Store, Xiaomi GetApps, OPPO App Market, vivo V-Appstore, HONOR App Market, Transsion Palm Store) on certified Android devices in those four countries. Google says the same requirement expands globally to all install sources in 2027.

What does that mean if you distribute Android APKs outside Google Play — direct downloads, F-Droid, GitHub Releases, your own site? Your exact deadline depends on your distribution:

If your app is on Google Play (even alongside other channels): you're in the participating-store set everywhere. Check Play Console now — unregistered apps are at risk of removal from Play globally.
If your users install via Galaxy Store / GetApps / etc. in BR, ID, SG, or TH: they're hitting the block today.
If you distribute via F-Droid or direct APK download: F-Droid is not a participating store, so the September wave doesn't block those installs — but the 2027 global rollout covers all install sources, which is when your distribution falls in scope. The rules are already written; the only question is your timeline.

A few facts worth knowing: verification means a $25 full-distribution Play Console account plus government photo ID (organizations additionally need a D-U-N-S number, which can take ~28 days — that's the long pole). When an install is blocked, users get a one-time bypass in settings — high-friction by design, not a viable distribution strategy. ADB installs are unaffected.

The checklist for this week

Check your Play Console status. If your app is on Play, confirm it's registered — that's the urgent one.
Decide your deadline honestly. Users in the four launch countries installing via participating stores: you're already affected. Everyone else distributing outside Play: your enforcement date is the 2027 global rollout — start the process now while review queues are short.
Verify your identity. $25 Play Console account with full distribution, government photo ID. Start now — review takes time and rejections happen.
Back up your signing key. Export it, store it offline in two places, record the SHA-256 fingerprint. If you lose the key you lose the ability to update your app, verification or not.
Register your package names + key fingerprints once verification clears.
Orgs: request D-U-N-S today. ~28 day turnaround.

Who should act first

Apps on Google Play that were published years ago under accounts nobody actively maintains — check registration status today.
Devs with users in Brazil, Indonesia, Singapore, or Thailand installing via participating stores.
F-Droid and direct-APK devs — your scope date is the 2027 global rollout; getting verified now means you're covered for both.

Pure Play Store devs who registered years ago: you're likely already verified through your existing Play Console account. Check anyway.

Free audit

I built a free 2-minute audit that takes 7 answers and generates a prioritized action plan for exactly this situation: https://8286544375711.gumroad.com/l/ffqtov

Disclosure: I also sell a $19 printable Readiness Kit with the complete walkthrough (registration steps, signing-key backup guide, package registration, recovery path): https://8286544375711.gumroad.com/l/rwqasc. The audit above is free and standalone.

(Scope per Google's official support documentation as of September 2026; enforcement details are evolving — verify against the current docs.)

Age verification for apps in 2026: what indie devs actually have to do

Tim — Wed, 30 Sep 2026 16:33:36 +0000

Your app probably needs age verification now — and "we'll deal with it later" stopped being an option in 2026.

The UK's Online Safety Act (age checks live since July 2025), Texas's App Store Accountability Act, Utah's App Store Accountability Act, and Louisiana's age-verification law have created a patchwork where the app stores, not just your app, are in the chain of responsibility. The EU's Digital Services Act adds risk assessments for services used by minors, and Australia's social-media age rules keep expanding.

What actually triggers an obligation

It's not "does my app have adult content." The triggers are things like: user-generated content or messaging, algorithmic feeds, loot boxes or gambling-adjacent mechanics, and operating in the UK, Texas, Utah, Louisiana, the EU, or Australia. A journaling app with no social features in most US states: probably fine. A social app with DMs available in the UK: you need a plan now.

The decision tree I wish someone gave me

Map where your users are. UK and the named US states are the strictest right now.
Classify your features. Social/UGC/messaging = highest risk. Pure utility with accounts = medium. No accounts, no UGC = lowest.
Pick your assurance level. Self-declaration of birthdate is the weakest and increasingly insufficient where laws bite. Document-based checks and age estimation are stronger but add friction and cost.
Never build verification yourself. Use a vendor (Stripe Identity, Veriff, Yoti, Persona, Jumio all have app-friendly options — pricing varies, check their current pages) or the platform-level checks where they exist.

The mistakes that get indie devs in trouble

Assuming COPPA-style "under 13" thinking covers it (new laws target under-16s and under-18s).
Collecting MORE data to verify age than the law allows you to keep (data minimization cuts both ways — verify, then delete).
No paper trail: if a regulator asks, "we used a vendor" is not documentation. Keep your decision record.

I put together a drop-in age-verification widget plus a compliance guide covering the UK, Texas, Utah, Louisiana, EU, and Australia rules with the decision tree above, vendor comparison, and documentation templates: https://8286544375711.gumroad.com/l/age-verification-kit

Disclosure: that's my $29 product. Everything in this article stands alone — the kit is there if you want the implementation shortcut.