The three places I had to fix before a Rork project actually targeted API level 36

A script that reports the effective value

I needed the value the build actually reads, not the declaration, so I wrote the resolution out. Tracing three files by eye stops being reliable the moment you have more than a couple of projects.

#!/usr/bin/env node
// audit-target-sdk.mjs
// Reports the value the build actually reads, not what app.json declares.
import { readFileSync, existsSync } from "node:fs";
import { join } from "node:path";
 
const REQUIRED = 36; // What Google Play requires from 2026-08-31
 
function readJson(p) {
  try { return JSON.parse(readFileSync(p, "utf8")); } catch { return null; }
}
 
// (1) What expo-build-properties declares in app.json
function declaredInConfig(root) {
  const cfg = readJson(join(root, "app.json")) ?? readJson(join(root, "app.config.json"));
  const plugins = cfg?.expo?.plugins ?? [];
  for (const p of plugins) {
    if (Array.isArray(p) && p[0] === "expo-build-properties") {
      return p[1]?.android?.targetSdkVersion ?? null;
    }
  }
  return null;
}
 
// (2) What android/gradle.properties actually holds
function inGradleProperties(root) {
  const f = join(root, "android", "gradle.properties");
  if (!existsSync(f)) return null;
  const m = readFileSync(f, "utf8").match(/^android\.targetSdkVersion\s*=\s*(\d+)/m);
  return m ? Number(m[1]) : null;
}
 
// (3) The fallback default in android/build.gradle
function fallbackInBuildGradle(root) {
  const f = join(root, "android", "build.gradle");
  if (!existsSync(f)) return null;
  const m = readFileSync(f, "utf8")
    .match(/targetSdkVersion\s*=\s*Integer\.parseInt\(\s*findProperty\('android\.targetSdkVersion'\)\s*\?:\s*'(\d+)'\s*\)/);
  return m ? Number(m[1]) : null;
}
 
const roots = process.argv.slice(2);
let failed = 0;
 
for (const root of roots) {
  const hasNativeDir = existsSync(join(root, "android"));
  const declared = declaredInConfig(root);
  const props = inGradleProperties(root);
  const fallback = fallbackInBuildGradle(root);
 
  // When android/ is committed, prebuild does not run by default, so the
  // app.json declaration never reaches the build. Resolution order is
  // gradle.properties first, then the build.gradle default.
  const effective = hasNativeDir ? (props ?? fallback) : declared;
  const source = hasNativeDir
    ? (props != null ? "android/gradle.properties" : "android/build.gradle (default)")
    : "app.json (applied at prebuild)";
 
  const ok = effective != null && effective >= REQUIRED;
  if (!ok) failed++;
 
  console.log(`${root}`);
  console.log(`  declared in app.json : ${declared ?? "(none)"}`);
  console.log(`  android/ present     : ${hasNativeDir ? "yes (bare-like, prebuild does not run by default)" : "no (managed)"}`);
  console.log(`  effective target SDK : ${effective ?? "(unknown)"}  <- ${source}`);
  console.log(`  verdict              : ${ok ? "OK" : `FAIL (needs ${REQUIRED}+)`}`);
  console.log("");
}
 
console.log(`audited ${roots.length} / failed ${failed}`);
process.exit(failed > 0 ? 1 : 0);

The order matters: gradle.properties first, then build.gradle. That mirrors how Gradle's findProperty resolves. The right side of ?: in build.gradle is only a fallback for when the property is absent. Read it the other way around and you will conclude that writing 36 into build.gradle is enough.

Branching on whether android/ exists is the other key point. Once that directory is there, the project is no longer one that runs prebuild on every build. The app.json value gets printed for reference only. It never feeds the verdict.

Here is the run.

$ node audit-target-sdk.mjs managed bare
managed
  declared in app.json : 36
  android/ present     : yes (bare-like, prebuild does not run by default)
  effective target SDK : 36  <- android/gradle.properties
  verdict              : OK

bare
  declared in app.json : 36
  android/ present     : yes (bare-like, prebuild does not run by default)
  effective target SDK : 35  <- android/build.gradle (default)
  verdict              : FAIL (needs 36+)

audited 2 / failed 1

Both declare 36 in app.json. The effective values split into 36 and 35. Grepping app.json to confirm your fleet would show you none of this.

The exit code carries the failure count, so it drops in front of a release script or into CI. I put it as the first stage of my pre-submission check.

The three places I changed

The edits themselves are unremarkable. That is exactly why noticing them is the whole job.

A note on the third row. Raise targetSdkVersion while leaving compileSdkVersion behind and compilation breaks the moment you reference an API introduced in Android 16. Raise only compileSdkVersion and you have not satisfied Play at all.

Review looks at targetSdkVersion. The compiler looks at compileSdkVersion. They serve different purposes, so it is safer never to leave one raised without the other. I pinned buildToolsVersion alongside them so the resolved version does not drift when the project is built on a different machine later.

My final confirmation came from the App bundle explorer in Play Console after uploading the AAB. The target API level shown there is the value Play actually read. If your source-side audit passes but that screen still says 35, it is not fixed.

How I split raising, leaving alone, and filing an extension

This is the part I actually spent time on. Raising everything to 36 was not the answer.

What I publish on Google Play is a set of wallpaper and calming apps, and their update cadence varies a lot. Some get new image assets almost monthly. Others have settled feature-wise and have not been touched in over half a year. Ignore that difference, raise everything at once, and you have committed to finishing device testing on all of them within thirteen days. That plan breaks.

Here is how I split them.

Deciding to leave the middle row alone was what actually saved the schedule.

My first instinct on seeing the word "deadline" was to do all of it. Only after drawing the table did I see that the time budgeted for apps with no planned update was entirely unnecessary. The deadline is not a deadline for every app. It is a deadline for apps you intend to update.

On the extension, I lean toward filing early when filing is available at all. If you file and then finish the raise in time, the filing is simply unused and costs you nothing. If you do not finish and August 31 passes, the window itself closes. One path has no downside; the other is unrecoverable. When the asymmetry looks like that, I move early.

What I checked on a real device afterward

Raising targetSdkVersion is a statement to the OS that it may run your app under the newer behaviors. A build passing and behavior staying the same are two different things.

Three things I checked first, on hardware:

1. Window insets. When edge-to-edge handling shifts, content slides under the navigation bar. Wallpaper apps show previews at near-full-screen, so this was my first stop. I hit the same class of problem when moving to API 35 (Fixing Layout Bleed on Android 15 (API 35) in Rork Apps).
2. Saving images and media access. Storage permissions are the area most likely to shift with a target level change. I confirmed saving a wallpaper to the device once per app, on hardware.
3. Notifications. I checked when the permission prompt appears and how a re-request behaves after a denial.

I did not settle for the emulator here because permission behavior depends on both the OS version and the manufacturer's implementation. I do not have many devices on hand, but one device is still meaningfully different from zero.

Regenerating android/ is another way to line everything up. If you go that route, be aware that prebuild erases hand-written native edits (Find the native edits expo prebuild will erase before you upgrade to SDK 57). With the deadline close, I chose the smaller move and edited the properties instead.

If you do one thing now

Open android/gradle.properties before you open app.json.

If there is no android.targetSdkVersion line in it, your build is running on the build.gradle default no matter what app.json says. I learned that thirteen days out.

When this audit works, nothing happens. How much that is worth probably depends on whether you have ever had a submission bounce. I have misread deadline rules more than once, and until I drew the table this time, I was still planning to touch every app I own.