バージョニングは、アプリのアップグレードおよびメンテナンス戦略を構成する重要な要素です。バージョニングが重要である理由は次のとおりです。
- ユーザーは、デバイスにインストールされているアプリのバージョンと、インストール可能なアップグレード バージョンに関する具体的な情報を必要とします。
- 他のアプリ（スイートとして公開される別のアプリを含む）は、互換性の判定と依存関係の識別のために、アプリのバージョンをシステムに照会する必要があります。
- アプリを公開するサービスも、ユーザーにバージョンを表示するために、アプリにバージョンを照会する必要がある場合があります。公開サービスは、互換性の判定とアップグレード / ダウングレード関係の確立のために、アプリのバージョンをチェックする場合もあります。
Android システムは、ダウングレードを防止するためにアプリのバージョン情報を使用します。サードパーティ アプリのアップグレードまたは互換性に制限を課すためにアプリのバージョン情報を使用することはありません。バージョン制限と、バージョン制限に関するユーザーへの通知は、アプリから行う必要があります。
Android システムは、ビルドファイルの minSdk 設定で指定されているとおりに、システム バージョンの互換性を適用します。この設定によって、アプリは互換性がある最小レベルのシステム API を指定できます。
API 要件の詳細については、API レベル要件を指定するをご覧ください。
バージョニングの要件はプロジェクトによって異なります。ただし、多くのデベロッパーは、セマンティック バージョニングがバージョニング戦略の適切な基盤であると考えています。
アプリのバージョン情報を設定する
アプリのバージョン情報を定義するには、Gradle ビルドファイルでバージョン設定の値を指定します。
Groovy
android {
namespace 'com.example.testapp'
compileSdk 33
defaultConfig {
applicationId "com.example.testapp"
minSdk 24
targetSdk 33
versionCode 1
versionName "1.0"
...
}
...
}
...
Kotlin
android {
namespace = "com.example.testapp"
compileSdk = 33
defaultConfig {
applicationId = "com.example.testapp"
minSdk = 24
targetSdk = 33
versionCode = 1
versionName = "1.0"
...
}
...
}
...
バージョン設定
使用可能なバージョン設定（versionCode と versionName）の値を両方とも定義します。
versionCode- 内部バージョン番号として使用される正の整数。この数値は、バージョンを比較してどちらが新しいかを判断するのに役立ちます。数値がより大きければ、バージョンがより新しいことを示します。この数値は、ユーザーに表示されるバージョン番号ではありません。ユーザーに表示される番号は、
versionName設定で指定された値です。Android システムは、ダウングレードを防止するためにversionCode値を使用し、現在デバイスにインストールされているバージョンよりもversionCodeが小さい APK をユーザーがインストールできないようにします。この値は正の整数であるため、他のアプリはプログラムでこの値を評価できます。たとえば、アップグレード / ダウングレード関係をチェックできます。この値には、任意の正の整数を設定できます。ただし、アプリの後続リリースでは、前のリリースよりも大きい値を使用する必要があります。
注: Google Play で使用できる
versionCodeの最大値は 2100000000 です。以前のバージョンですでに使用した
versionCodeで APK を Play ストアにアップロードすることはできません。注: 状況によっては、
versionCodeが最新バージョンよりも小さいバージョンのアプリをアップロードしたい場合があります。たとえば、複数の APK を公開する場合、特定の APK にversionCodeの範囲が事前設定されていることがあります。複数の APK にversionCode値を割り当てる方法については、バージョン コードの割り当てをご覧ください。一般的に、アプリの最初のバージョンをリリースするときは
versionCodeを 1 に設定し、リリースを重ねるたびに、メジャー リリースかマイナー リリースかにかかわらず、単純に値を増やします。つまり、versionCode値は、ユーザーに表示されるアプリのリリース バージョンを必ずしもなぞっているわけではありません。アプリと公開サービスでは、このバージョン値をユーザーに表示するべきではありません。 versionNameユーザーに表示されるバージョン番号として使用される文字列。この設定には、未加工の文字列か、文字列リソースへの参照を指定できます。
値は文字列であるため、アプリのバージョンを <メジャー>.<マイナー>.<ポイント> という形式の文字列として、または他のタイプの絶対または相対バージョン識別子として記述できます。ユーザーには
versionNameの値のみが表示されます。
バージョンの値を定義する
上記の設定のデフォルト値を定義するには、モジュールの build.gradle または build.gradle.kts ファイルの android {} ブロック内にネストされている defaultConfig {} ブロックでそれらを指定します。個々のビルドタイプまたはプロダクト フレーバーに応じて異なる値を定義すると、アプリのバージョンごとにデフォルト値をオーバーライドできます。下記のファイルは、defaultConfig {} ブロックの versionCode および versionName 設定と、productFlavors {} ブロックを示しています。
これらの値は、ビルドプロセス中にアプリのマニフェスト ファイルにマージされます。
Groovy
android {
...
defaultConfig {
...
versionCode 2
versionName "1.1"
}
productFlavors {
demo {
...
versionName "1.1-demo"
}
full {
...
}
}
}
Kotlin
android {
...
defaultConfig {
...
versionCode = 2
versionName = "1.1"
}
productFlavors {
create("demo") {
...
versionName = "1.1-demo"
}
create("full") {
...
}
}
}
この例の defaultConfig {} ブロックでは、versionCode 値は現在の APK にアプリの 2 番目のリリースが含まれていることを示し、versionName 文字列はそれがバージョン 1.1 としてユーザーに表示されることを示します。このファイルでは、「demo」と「full」という 2 つのプロダクト フレーバーも定義しています。「demo」プロダクト フレーバーでは versionName を「1.1-demo」として定義しているので、「demo」ビルドではデフォルト値の代わりにこの versionName が使用されます。「full」プロダクト フレーバーのブロックでは versionName を定義していないので、デフォルト値の 1.1 が使用されます。
注: アプリがアプリのバージョンを <manifest> 要素で直接定義している場合は、Gradle ビルドファイルのバージョン値によってマニフェストの設定がオーバーライドされます。また、Gradle ビルドファイルでこれらの設定を定義すると、アプリのバージョンごとに異なる値を指定できます。柔軟性を高め、マニフェストのマージの際に設定が上書きされる危険を避けるには、これらの属性を <manifest> 要素から削除し、代わりに Gradle ビルドファイルでバージョン設定を定義する必要があります。
Android フレームワークには、アプリのバージョン情報をシステムに照会できる API が用意されています。バージョン情報を取得するには、
PackageManager.getPackageInfo(java.lang.String, int) メソッドを使用します。
API レベル要件を指定する
特定の最小バージョンの Android プラットフォームがアプリに必要な場合、アプリの build.gradle または build.gradle.kts ファイルで、そのバージョン要件を API レベル設定として指定できます。ビルドプロセス中に、この設定はアプリのマニフェスト ファイルにマージされます。API レベル要件を指定すると、互換性のあるバージョンの Android プラットフォームを実行しているデバイスにのみアプリをインストールできるようになります。
注: API レベル要件をアプリのマニフェスト ファイルで直接指定すると、マニフェスト ファイル内の設定がビルドファイル内の対応する設定によってオーバーライドされます。また、Gradle ビルドファイルでこれらの設定を定義すると、アプリのバージョンごとに異なる値を指定できます。柔軟性を高め、マニフェストのマージの際に設定が上書きされる危険を避けるには、これらの属性を <uses-sdk> 要素から削除し、代わりに Gradle ビルドファイルで API レベル設定を定義する必要があります。
次の 2 つの API レベル設定を使用できます。
minSdk- アプリが実行される Android プラットフォームの最小バージョン。プラットフォームの API レベル識別子で指定します。targetSdk- アプリの本来の実行対象である API レベル。これにより、場合によっては、最小 API レベルで定義されたマニフェスト要素や動作だけでなく、ターゲット API レベルで定義されたマニフェスト要素や動作をアプリで使用できるようになります。
build.gradle または build.gradle.kts ファイルでデフォルトの API レベル要件を指定するには、android {} ブロック内にネストされている defaultConfig{} ブロックに API 設定を 1 つ以上追加します。ビルドタイプまたはプロダクト フレーバーに応じて設定を追加することで、アプリのバージョンごとにデフォルト値をオーバーライドすることもできます。
下記のファイルでは、defaultConfig {} ブロックでデフォルトの minSdk および targetSdk 設定を指定し、1 つのプロダクト フレーバーで minSdk をオーバーライドしています。
Groovy
android {
...
defaultConfig {
...
minSdk 21
targetSdk 33
}
productFlavors {
main {
...
}
afterNougat {
...
minSdk 24
}
}
}
Kotlin
android {
...
defaultConfig {
...
minSdk = 21
targetSdk = 33
}
productFlavors {
create("main") {
...
}
create("afterNougat") {
...
minSdk = 24
}
}
}
システムは、アプリのインストールを準備する際にこれらの設定の値をチェックし、システムのバージョンと比較します。minSdk 値がシステムのバージョンより大きければ、システムはアプリのインストールを回避します。
これらの設定が指定されていない場合、システムは、アプリがすべてのプラットフォーム バージョンと互換性を持つと見なします。これは、minSdk を
1。
詳細については、API レベルとはをご覧ください。Gradle ビルドの設定については、ビルド バリアントを設定するをご覧ください。