何度か同じような内容を人に伝える機会に遭遇するなと思ったのでブログ記事にしてしまおう、ということで、 Android の新しいバージョンのリリースに対してどういう流れで対応を進めるかについての自分の考え方のメモ。
Android バージョンアップによって発生する変更
以下の3種類に大別できる:
- アプリの target API level にかかわらず、当該バージョンで動くデバイス上でアプリを動かす際に関係する変更
- Android Developers の "Behavior changes: all apps" で列挙されるもの
- e.g. https://developer.android.com/about/versions/15/behavior-changes-all (Android 15)
- アプリの target API level (= target SDK version) をその SDK に合わせた時、当該バージョンで動くデバイス上でアプリを動かす際に関係するもの
- Android Developers の "Behavior changes: Apps targeting Android XX" で列挙されるもの
- e.g. https://developer.android.com/about/versions/15/behavior-changes-15 (Android 15)
- SDK の API 変更
バージョンアップ対応の進め方
まず自分の開発しているアプリへの影響について調査し、必要な対応タスクを上述の3種類に対応した3つのタスクグループとしてまとめる。着手は以下の優先順位で行う:
- "Behavior changes: all apps" 関連
- SDK の API 変更 ->
compileSdkを上げる - "Behavior changes: Apps targeting Android XX" 関連 ->
targetSdkを上げる
優先順位は実質的なデッドラインに当たるイベントに基づいている。つまり、1. に関しては新バージョンの final release, 2. は Jetpack などのライブラリが compileSdk を上げたリリースを行った時 (final release が行われてしばらく経ったくらい)、そして3. は Google Play の target API level requirements で要求されるようになったら (2024年現在の目安としては final release の翌年の8月末)、ということになる。
Final release 前後で全ての対応を完了できるならそのように進めるのが望ましいが、諸々の事情でもっとかかるみたいな状況になった場合は上記の優先順位とデッドラインをもとにいつからいつまでの間に取り組ませてほしいなど調整をしつつやっていくことになる。 Target SDK version を上げるための対応は素朴にデッドラインに合わせて計画を立てるとスケジュールが間延びしてダレがちなので、リリースされた年内で完了させられるように持っていきたいなと考えている。
なぜこういうことを考えるのか
主にはプロダクトオーナーとかプロジェクトマネージャーとかと計画づくりやスケジュール調整をする時に、どういう対応の段階があってそれぞれの対応が完了すると何がクリアになるかというのを共有するため。あとは何かしらの事情でスケジュール的に余裕がなくて、それぞれの対応に十分な期間や人員を確保しつつビジネス要望にも応えるには何がどの程度まで調整可能かみたいな相談というか交渉というかみたいなのが発生した時に必要になることもある。
