Rork のプロジェクトで targetSdkVersion 36 を通すまでに直した3か所

実効値を報告するスクリプトを書きました

「宣言」ではなく「ビルドが実際に読む値」を出す必要があったので、判定を書き下しました。目視で3ファイルを追う作業は、プロジェクトが数本を超えると必ず取りこぼします。

#!/usr/bin/env node
// audit-target-sdk.mjs
// app.json の宣言ではなく「ビルドが実際に読む値」を報告する
import { readFileSync, existsSync } from "node:fs";
import { join } from "node:path";
 
const REQUIRED = 36; // 2026-08-31 以降に Google Play が要求する値
 
function readJson(p) {
  try { return JSON.parse(readFileSync(p, "utf8")); } catch { return null; }
}
 
// (1) app.json の expo-build-properties が宣言している値
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) android/gradle.properties が実際に持っている値
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) 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);
 
  // android/ がコミットされている場合、prebuild は既定で走らないため
  // app.json の宣言はビルドに届かない。実効値は properties → build.gradle の順で決まる
  const effective = hasNativeDir ? (props ?? fallback) : declared;
  const source = hasNativeDir
    ? (props != null ? "android/gradle.properties" : "android/build.gradle (既定値)")
    : "app.json (prebuild で生成)";
 
  const ok = effective != null && effective >= REQUIRED;
  if (!ok) failed++;
 
  console.log(`${root}`);
  console.log(`  app.json の宣言        : ${declared ?? "(なし)"}`);
  console.log(`  android/ の有無        : ${hasNativeDir ? "あり（bare 相当・prebuild は既定で走らない）" : "なし（managed）"}`);
  console.log(`  実効 targetSdkVersion  : ${effective ?? "(不明)"}  ← ${source}`);
  console.log(`  判定                   : ${ok ? "OK" : `NG（要 ${REQUIRED} 以上）`}`);
  console.log("");
}
 
console.log(`監査対象 ${roots.length} 件 / NG ${failed} 件`);
process.exit(failed > 0 ? 1 : 0);

判定の順序を gradle.properties → build.gradle の順にしているのは、Gradle の findProperty がその順で解決するからです。build.gradle の ?: の右側は、あくまで properties に値がなかったときのフォールバックです。ここを逆に読むと、build.gradle に 36 と書けば済むと勘違いします。

android/ の有無で分岐させているのが要点です。ディレクトリが存在する時点で、そのプロジェクトは prebuild を毎回通す前提ではなくなっています。app.json の値は参考情報として表示するだけで、判定には使いません。

実行した結果がこちらです。

$ node audit-target-sdk.mjs managed bare
managed
  app.json の宣言        : 36
  android/ の有無        : あり（bare 相当・prebuild は既定で走らない）
  実効 targetSdkVersion  : 36  ← android/gradle.properties
  判定                   : OK

bare
  app.json の宣言        : 36
  android/ の有無        : あり（bare 相当・prebuild は既定で走らない）
  実効 targetSdkVersion  : 35  ← android/build.gradle (既定値)
  判定                   : NG（要 36 以上）

監査対象 2 件 / NG 1 件

2件とも app.json の宣言は 36 です。それでも実効値は 36 と 35 に割れました。app.json を grep して確認する運用では、この差が一切見えません。

終了コードを NG 件数で返しているので、CI やリリース前スクリプトの手前に置けます。私は提出前チェックの一段目に組み込みました。

直した3か所

直した内容自体は地味です。地味なぶん、気づくかどうかで結果が分かれます。

3つ目について補足します。targetSdkVersion だけを上げて compileSdkVersion を据え置くと、Android 16 で追加された API を参照した時点でコンパイルが落ちます。逆に compileSdkVersion だけ上げても、Play の要求は満たされません。

審査が見るのは targetSdkVersion、コンパイルが見るのは compileSdkVersion。 別々の役割を持つ値なので、片方だけ上げる状態を作らないほうが安全です。buildToolsVersion を併記したのは、後から別の環境でビルドしたときに解決される版が揺れないようにするためです。

最終確認は、AAB を Play Console にアップロードしたあとの App bundle エクスプローラで行いました。ここに表示される対象 API レベルが、Play が実際に読み取った値です。ソース側の監査が通っていても、この画面で 35 と出たら直っていません。

引き上げ・更新停止・延長申請をどう分けたか

ここからが今回の本題です。全部を 36 に上げるのが正解、とは考えませんでした。

私が Google Play に出しているのは壁紙・癒し系のアプリ群で、更新の頻度はアプリごとにばらばらです。毎月のように画像アセットを足しているものもあれば、機能が固まっていて半年以上さわっていないものもあります。この差を無視して一律に引き上げると、13日で全部の実機確認まで終える計画になり、確実に破綻します。

判断はこう分けました。

真ん中の行に手を出さないと決めたのが、いちばん効きました。

私は当初、期限という言葉を見た時点で「全部やる」に寄っていました。表を書いて初めて、更新予定のないアプリに割く時間が丸ごと不要だと分かりました。期限は「全アプリの締切」ではなく「更新を出すアプリの締切」です。

延長申請を採用する場合は、出せるなら早めに出しておくほうが良いと考えています。申請を出したうえで期限内に引き上げが終われば、申請は無駄になるだけで害はありません。逆に、引き上げが終わらないまま8月31日を越えると、申請の窓口ごと使えなくなります。片方は損失がなく、もう片方は取り返しがつきません。この非対称性がある場面では、早く動くほうを選んでいます。

引き上げたあとに実機で見た箇所

targetSdkVersion を上げるということは、OS に対して「新しい挙動で動かして構いません」と宣言することです。ビルドが通ることと、挙動が変わらないことは別の話でした。

私が実機で優先して見たのは次の3点です。

1. 画面端のインセット — edge-to-edge の扱いが変わると、下端のナビゲーションバーにコンテンツが潜り込みます。壁紙アプリはプレビューを全画面に近い形で出すので、ここは真っ先に確認しました。API 35 に上げたときに同じ問題を踏んでいます（Rork で targetSdkVersion 35 にしたら Android のレイアウトが下まで埋まる問題の直し方）。
2. 画像の保存とメディアアクセス — ストレージ関連の権限は対象 API レベルの変更で最も挙動が動く領域です。壁紙の端末保存が通ることを、実機で1回ずつ確かめました。
3. 通知の表示 — 権限リクエストのタイミングと、拒否されたあとの再要求の扱いを確認しました。

エミュレータだけで済ませなかったのは、権限まわりが OS のバージョンと端末メーカーの実装の両方に影響されるためです。個人開発では手元に置ける実機の台数が限られますが、それでも1台通すのとゼロ台は違います。実機で1回動かしてから提出する順序は、いまも崩さないようにしています。

なお、android/ を生成し直す方向で揃える選択肢もあります。その場合は prebuild で手書きのネイティブ変更が消える点に注意が必要です（Expo SDK 57 に上げる前に、prebuild で消えるネイティブ変更を洗い出す）。今回は期限が近かったので、生成し直さず properties を直す最小の手を選びました。

いま手を動かすなら、最初の1つ

app.json を開く前に、android/gradle.properties を開いてください。

そこに android.targetSdkVersion の行が無ければ、app.json に何が書いてあっても、あなたのビルドは build.gradle の既定値で動いています。私はそれを、期限の13日前に知りました。

この監査は、うまくいけば何も起きません。何も起きないことにどれだけ意味があるかは、提出がはねられた経験のある方ほど分かっていただけるのではないかと思います。私自身、期限まわりの読み違いは何度もやっていて、今回も表を書くまでは全アプリを触るつもりでいました。お読みいただきありがとうございました。