シナリオ
あなたはレガシーView、Jetpack Compose、サードパーティSDKが混在するAndroidアプリを担当しています。Android 16+をターゲットとするアプリではwindowOptOutEdgeToEdgeEnforcementが削除されるため、アプリはウィンドウインセットを正しく処理する必要があります。リスクの特定、レイアウトの変更、デバイスフォームファクタの検証、およびリリースリスクの制御をどのように行うか説明してください。
面接官が評価するポイント
- 「Android 16上で互換性を保って動作すること」と「targetSdkVersionを16に引き上げること」の分離。
- システムバー、IME、カットアウト、ジェスチャー領域、スクロールコンテナの体系的なチェック。
- View、Compose、ライブラリ、SDKの組み合わせの網羅。
- 互換性トグル、カナリアリリース、観測可能なロールバックの設計。
明確化のための質問
ターゲットおよびコンパイルSDK、サポート対象のAndroidバージョン、View/Composeの割合、縦向き/横向きおよび折りたたみデバイスのカバー範囲、全画面カメラ、マップ、またはWebViewの使用有無を確認します。スクリーンショットテスト、クラッシュ、レイアウトの不具合報告のベースライン、およびサードパーティSDKがEdge-to-Edgeサポートを文書化しているかどうかを質問します。
30秒の回答
私は2つのフェーズを用います。まず、ターゲットを引き上げずにAndroid 16での動作変更を顕在化させ、その後インセットの修正とターゲットのアップグレードを分離します。ViewとCompose全体でルートレイアウト、バー、IME、ジェスチャー領域、スクロールをチェックします。互換性対応のみのビルドを小さなコホートに配信し、クラッシュ、要素の遮蔽（オクルージョン）に関する報告、主要フローの完了率を監視します。スクリーンショットのデグレードテストとデバイスマトリクステストに合格した後にのみターゲットを引き上げます。不正なレイアウトをクリーンにロールバックできるよう、ターゲットの変更は大規模な機能開発から分離しておきます。
段階的な思考プロセス
1. 互換性とターゲットアップグレードの分離
Androidの移行ガイダンスでは、まず既存のアプリをAndroid 16でテストすることを推奨しています。多くの修正は即座のターゲット変更を必要としません。その上でAndroid 16をターゲットとするアプリ向けの動作変更に対処し、リグレッションの原因を明確に保ちます。
2. インセットチェックリストの構築
ルートレイアウトがシステムバーのインセットを消費しているか、ツールバー、ボトムナビゲーション、リストの最後のアイテム、入力フィールド、ダイアログが遮蔽されていないかを確認します。Compose用に統一されたインセット規則を確立し、レガシーViewでの二重パディングを防ぎます。カメラ、マップ、WebView画面は独自のセーフエリアルールでテストします。
3. スコープを絞り込むための互換性ツールの使用
Android 16の互換性トグルを使用すると、targetSdkVersionを変更することなく対象の動作を有効にできます。4 KB/16 KBページサイズ、画面の向き、3ボタン/ジェスチャーナビゲーション、折りたたみ式デバイス、フォントスケーリングをカバーする自動デバイスマトリクスにこれらを追加します。変更IDとスクリーンショットの差分を記録します。
4. カナリアリリースとロールバック
レイアウトのみの互換性ビルドを配信し、その後ベータ版および本番トラフィックの1%でターゲットを引き上げます。起動クラッシュ、ANR、主要ページのタップ成功率、画面下部の遮蔽に関する不具合報告、SDKエラーを監視します。ターゲット移行は分離した状態を保ち、必要に応じて前のビルドにロールバックするか、影響を受けるエントリーポイントを無効化します。
高品質な回答例
私はまず、現在のプロダクションビルドをAndroid 16のエミュレータおよび実機にインストールし、すべてのフローを実行して端の領域をキャプチャすることで互換性のベースラインを確立します。次に、互換性トグルを通じてEdge-to-Edgeの動作のみを有効にし、問題の原因がルートレイアウト、SDK、またはターゲットの変更のいずれにあるかを特定します。インセット処理レイヤーを1つ作成し、上部、下部、IMEの消費を明示的に割り当ててView/Composeの二重パディングを防ぎます。カメラ、マップ、WebView、ダイアログには個別のセーフエリアテストを実施します。ターゲットを変更せずに互換性修正をリリースします。スクリーンショット、アクセシビリティ、画面の向き、折りたたみ式、IMEのテストに合格した後、ターゲットの引き上げを独立した変更として実施します。まずはベータ、次に1%のカナリアです。クラッシュ、ANR、コアコンバージョン、遮蔽のフィードバックを追跡し、リグレッション発生時にはロールバックまたは新しいエントリーを無効化します。これにより、明確な原因特定とロールバック性を維持しながらプラットフォームの変更に対応できます。
よくある間違い
- targetSdkVersionを即座に引き上げてしまい、リグレッションの原因特定ができなくなること。
- ステータスバーのみを修正し、ナビゲーション、IME、折りたたみ式、リスト末尾、ダイアログを見落とすこと。
- 複数のレイヤーでインセットを消費して二重パディングを発生させること。
- エミュレータのみでテストし、SDK、実機、フォントスケーリングをスキップすること。
- Edge-to-Edge移行を大規模機能とバンドルしてしまい、独立したロールバックができなくなること。
追加の質問と回答
「targetSdkVersionはすぐに16にする必要がありますか？」
いいえ。まずは現在のターゲットのままAndroid 16でテストし、互換性を修正してください。ターゲットのアップグレードは、Playの要件とプロダクトのタイミングに合わせて別途行います。
「サードパーティSDKはどのように扱いますか？」
それらを棚卸しし、互換性トグルを用いて実機でテストします。Edge-to-Edgeサポートを文書化しているバージョンを優先し、そうでない場合はセーフエリアラッパーを追加するか、影響を受ける画面を分離します。
「古いAndroidバージョンが引き続き動作することをどのように証明しますか？」
サポートされている最小バージョン、Android 15、Android 16において、画面の向き、ナビゲーションモード、フォントスケール全体にわたり同じスクリーンショットおよびクリティカルフローマトリクスを実行します。起動の成功だけでなく、タップ可能な領域や遮蔽の有無を比較します。