数字をひとつ変えるだけだと思っていた
Google Play の target API 要件は毎年上がります。コンソールに警告が出て、ビルド設定の数字をひとつ上げる。ここまでは五分で終わります。
問題はその先です。ビルドして実機に入れてみると、画面の上下がシステム UI に食われていたり、戻るボタンが効かなかったり、タブレットで固定していたはずの画面の向きが外れていたりします。
target API を上げるというのは、このアプリは新しい動作ルールに従いますと宣言することだからです。 数字を変えた瞬間、それまで免除されていたルールがまとめて適用されます。
そしてこれは後回しにできる宿題ではありません。期限を過ぎると、そもそも更新を出せなくなります。
以下は、そのうち Unity ゲームで実際に表に出てくるものです。
要求される水準と期限は年ごとに変わります。現在の基準は必ず Google Play の target API 要件で 直接確認してください。動作変更の全体像は Android の動作変更ドキュメントにあります。 ここに書くのは、引き上げるときに何を確認するかです。
先延ばしにするとどうなるか
この締め切りには期限が決まっていて、過ぎると二つが同時に起きます。
1. 更新を出せなくなります。 新規アプリもアプリの更新も、要件を満たさないと提出できません。 target API を上げるまではどんな更新も出せません。 コンテンツの追加も、クラッシュ修正も、 緊急のセキュリティ修正も同じです。
2. 新規ユーザーに届かなくなります。 要件を下回るアプリは、自分の target API より新しい Android バージョンの端末に新規インストールできなくなります。そうした端末の比率は時間とともに増えるので、 新規の流入がじわじわ止まります。
正確に言うと、アプリがストアから削除されるわけではありません。 すでにインストール済みのユーザーは 遊び続けられます。ただ、新しいユーザーは入ってこられず、こちらは何も直せない状態になります。 運営中のタイトルでは後者のほうが厄介です。何かあっても手の打ちようがないからです。
期限を過ぎてしまったら、コンソールで延長申請の導線が開いているか確認してください。ただし延長は 時間を稼ぐ手段であって、免除ではありません。
ルールは二種類に分かれます
Android の動作変更には、性格の違う二つが混ざっています。これを分けると対応範囲がかなり狭まります。
| 種類 | いつ適用されるか | 対応 |
|---|---|---|
| すべてのアプリに適用 | OS が上がれば target API と無関係に | 先送りできない |
| target API を上げると適用 | こちらが数字を上げた時点から | 引き上げと一緒に確認 |
以下で扱うのは二つ目です。こちらが自分で有効にしたものなので、何を有効にしたか把握して確認すれば済みます。
Unity ゲームで実際に表に出てくるもの
1. 画面がシステム UI に食われる — エッジツーエッジ
アプリが画面全体に描画され、ステータスバーとナビゲーションバーがその上に重なります。以前はこの動作を切る属性がありましたが、その逃げ道はふさがれました。
ゲームでは UI の端から表に出ます。左右上部の通貨表示、下部のボタン列のように、画面の端に寄せたものがステータスバーやジェスチャーバーに隠れます。
Unity で見るべきなのは Screen.safeArea です。システム UI を除いた実際に使える領域を返す値なので、キャンバスを画面全体、つまり Screen.width と Screen.height を基準に組んでいると、その差の分だけずれます。ノッチのある端末に対応した際にすでに処理してあるプロジェクトはおおむね無事で、その対応を飛ばしたプロジェクトがここで引っかかります。
2. 戻るが以前のようには来ない — 予測型戻る
onBackPressed() は呼ばれなくなり、戻るキーのイベントも以前の方法では届きません。
Unity ゲームは Android の戻るを KeyCode.Escape で受けて処理することがよくあります。ポーズメニューを開く、前の画面に戻るといったコードがここにぶら下がっているなら、必ず実機で確認してください。 マニフェストで以前の動作に戻すフラグはありますが、あれは時間を稼ぐ手段であって解決ではありません。
3. タブレットや折りたたみで向きの固定が外れる — ただしゲームは例外
大画面では、マニフェストの画面の向き、サイズ変更不可、アスペクト比の制限が無視されます。縦固定で作ったゲームがタブレットで横に伸びうる、ということです。
ここにゲームの例外があります。 マニフェストでアプリのカテゴリをゲームとして宣言すると、この強制から外れます。
<application android:appCategory="game">
<activity android:screenOrientation="portrait" />
</application>
Unity プロジェクトではこの属性が抜けていることがよくあります。大画面でレイアウトが崩れるなら、まずここを見てください。 一行で終わる問題かもしれません。
4. たまった定期処理がまとめて実行されない — 主にプラグイン側の話
一定間隔で繰り返し予約した処理が、端末が休止していたなどの理由で何度も飛ばされたとき、以前は飛ばされた回数だけまとめて実行されました。今は一度だけ実行して先に進みます。
先に範囲を絞ります。これは Unity の C# コードよりも Android ネイティブ側の話です。 ゲームでよくあるオフライン報酬の計算は、たいてい復帰時に時刻を比較して処理するので、ここには該当しません。
引っかかりうるのは、ネイティブプラグインやサードパーティ SDK が内部で繰り返し処理を回している場合です。分析イベントの送信、プッシュトークンの更新、定期同期といったものがそれにあたります。多くは提供側が対応するので、こちら側の作業は、その SDK を目標 API に対応したバージョンへ上げたかの確認になります。
運営中のタイトルなら、ここにもう一枚あります
まだリリース前なら、上の項目を直してビルドすれば終わりです。すでにサービス中なら事情が変わります。
target API の引き上げは、作り直して、審査を通して、ユーザーが更新を受け取って初めて終わります。 期限が決まっている以上、審査期間から逆算して日程を組む必要があり、その間、既存のビルドはそのまま動き続けます。
この構造は、エンジンのセキュリティ勧告を受け取ったときとまったく同じです。あのときと同様、日程を組む前に、今そのビルドを作り直せるのかどうかから確認してください。ビルドマシンが変わっていたり、署名鍵に触れる人がいなかったりすると、日程そのものが成り立ちません。
セキュリティ側で一緒に見ておくこと
target API を上げるついでに確認しておくとよいものがあります。どのみち作り直して審査も受け直すからです。
- 署名の体系は変わっていないか — 作り直す過程で、署名鍵と手順が以前と同じか確認します。
- プラグインと SDK が目標 API に対応しているか — ネイティブバイナリを含むものは特にそうです。提供側のドキュメントで、どのバージョンから対応したかとそのバージョンがいつ出たかを合わせて見てください。長く触っていないプラグインが足を引っ張ることがよくあります。
- ビルドに残ってはいけないものが増えていないか — 対応の過程で入れた一時的なログやデバッグフラグが、そのまま出ていかないようにします。
- 改ざん判定の基準を作り直したか — ビルドが変われば、正常なビルドの基準も一緒に変わります。リパッケージの判定はUnity の MOD APK 対策ガイドで扱いました。
チェック項目
上げる前に
- 現在の要求水準と期限を公式ドキュメントで確認した。
- 今ストアにあるビルドがどの target API で作られたか把握している。
- 使用中のプラグインと SDK が目標バージョンに対応しているか確認した。
上げたあと、実機で
- 画面の端の UI がシステム UI に隠れない。
- 戻るでポーズや前の画面への移動が正しく動く。
- タブレットや折りたたみで、画面の向きとレイアウトが意図どおり保たれる。
- 繰り返し処理を回すプラグインや SDK が、目標 API のバージョンで正常に動く。
リリース手順
- 審査期間から逆算して日程を組んだ。
- 署名の体系とビルドの再現性を合わせて確認した。
- 一時的に入れたログやフラグを取り除いた。
OZero Security を使っている場合
担当しない領域
- ストアのポリシー対応を代行することはありません。 target API の引き上げ、審査日程、マニフェストの設定はチームの作業です。
- 上の動作変更で生じた UI や入力の問題も、ゲームコード側の担当になります。
担当する領域
- ネイティブライブラリを含む SDK である以上、Google Play が要求する API 水準に合わせて互換性を保つのは私たちの役割です。 現在どの範囲まで対応しているかは、マニュアルかお問い合わせでご確認いただけます。
- 作り直した成果物に対して、実行ファイルのバイナリ改ざん、デバッガの接続とフック、エミュレータや Root のような信頼できない実行環境を識別し、迂回の難度を上げます。
ポリシー対応でどのみち作り直しと再審査をする時点なら、保護の適用を同じサイクルに入れたほうが安く済みます。 あとから別に行うと、審査をもう一度受けることになります。
おわりに: 上がるのは数字ではなく動作ルールです
target API の引き上げをビルド設定の変更だと考えていると、実機で驚くことになります。実際には、それまで免除されていた動作ルールをまとめて受け入れる宣言です。
なので順序はこうなります。数字を上げて、実機で画面と入力と大画面を自分の目で見て、そのあとに審査日程を組む。エミュレータだけで済ませると、先の三つはなかなか表に出てきません。
そしてこの締め切りは毎年やってきます。今回確認した項目を記録しておけば、来年はずっと短く終わります。
次のステップ
- 保護範囲を確認する — プラットフォーム別の対応仕様と、プラン別 (Standard / Pro) の防御範囲をご確認ください。
- すぐに導入を始める — パッケージのインポートと設定手順は統合ガイドにあります。
- 技術的なお問い合わせ — 対応 API 水準や作り直しの日程についてご相談ください。