すべての Android アプリには、「com.example.myapp」など、Java パッケージ名に似た一意のアプリケーション ID があります。この ID によってアプリがデバイスと Google Play ストアで一意に識別されます。アプリの新しいバージョンをアップロードする場合、アプリケーション ID(および署名に使用する証明書)は元のアーティファクトと同じでなければなりません。アプリケーション ID を変更すると、Google Play ストアは新しいバージョンのアプリをまったく別のアプリとして扱います。そのため、アプリを公開したら、絶対にアプリケーション ID を変更しないでください。
アプリケーション ID は、次に示すように、モジュールの build.gradle
ファイル内の applicationId
プロパティで定義されます。
Groovy
android { defaultConfig { applicationId "com.example.myapp" minSdkVersion 15 targetSdkVersion 24 versionCode 1 versionName "1.0" } ... }
Kotlin
android { defaultConfig { applicationId = "com.example.myapp" minSdkVersion(15) targetSdkVersion(24) versionCode = 1 versionName = "1.0" } ... }
Android Studio で新しいプロジェクトを作成した場合、applicationId
は、セットアップ時に選択した Java スタイルのパッケージ名と完全に同じになります。ただし、この点を除けばアプリケーション ID とパッケージ名は互いに独立しています。コードのパッケージ名(コード名前空間)を変更してもアプリケーション ID は変わらず、その逆も同様です(ただし、前述の理由からアプリの公開後はアプリケーション ID を変更しないでください)。なお、パッケージ名の変更による影響については注意が必要なため、パッケージ名の変更に関するセクションをご確認ください。
アプリケーション ID は従来の Java パッケージ名に似ていますが、アプリケーション ID の命名規則はもう少し厳密になっています。
- 2 つ以上のセグメント(1 つ以上のドット)が必要
- 各セグメントは文字で始まる必要がある
- 使用できる文字は英数字とアンダースコアのみ(a~z、A~Z、0~9、_)
注: アプリケーション ID は、以前はコードのパッケージ名に直接紐付けされていました。そのため、一部の Android API のメソッド名とパラメータ名に「package name」という語が含まれていますが、これは実際にはアプリケーション ID を指します。たとえば、Context.getPackageName()
メソッドはアプリケーション ID を返します。コードの本来のパッケージ名をアプリコードの外部に公開する必要はありません。
注意: WebView
を使用している場合は、アプリケーション ID の接頭辞としてパッケージ名を使用することをおすすめします。使用しないと、issue 211768 で説明している問題が発生する可能性があります。
ビルド バリアント向けにアプリケーション ID を変更する
アプリの APK または AAB をビルドすると、ビルドツールは、以下の例に示すように build.gradle
ファイルの defaultConfig
ブロックで定義されたアプリケーション ID をアプリにタグ付けします。ただし、アプリのさまざまなバージョン(無料版の「free」やプロフェッショナル版の「pro」など)を作成し、Google Play ストアで別々の掲載情報として表示したい場合は、アプリケーション ID がそれぞれ異なるビルド バリアントを作成する必要があります。
この場合、ビルド バリアントはそれぞれ別のプロダクト フレーバーとして定義する必要があります。productFlavors
ブロック内のフレーバーごとに、applicationId
プロパティを再定義するか、以下の例に示すように applicationIdSuffix
を使用してデフォルトのアプリケーション ID の末尾にセグメントを付加することができます。
Groovy
android { defaultConfig { applicationId "com.example.myapp" } productFlavors { free { applicationIdSuffix ".free" } pro { applicationIdSuffix ".pro" } } }
Kotlin
android { defaultConfig { applicationId = "com.example.myapp" } productFlavors { create("free") { applicationIdSuffix = ".free" } create("pro") { applicationIdSuffix = ".pro" } } }
これにより、「free」プロダクト フレーバーのアプリケーション ID は「com.example.myapp.free」となります。
また、以下の例に示すように、applicationIdSuffix
を使用し、ビルドタイプに基づいてセグメントを末尾に付加することもできます。
Groovy
android { ... buildTypes { debug { applicationIdSuffix ".debug" } } }
Kotlin
android { ... buildTypes { getByName("debug") { applicationIdSuffix = ".debug" } } }
Gradle ではプロダクト フレーバーの後にビルドタイプ設定を適用するため、「free debug」ビルド バリアントのアプリケーション ID は「com.example.myapp.free.debug」となります。2 つのアプリで同じアプリケーション ID を使用することはできないため、この方法はデバッグビルドとリリースビルドの両方を同じデバイスに組み込みたい場合に便利です。
Google Play で APK を使用して配信している旧式アプリ(2021 年 8 月より前に作成)の場合、同じアプリ掲載情報を使用して、異なるデバイス設定(API レベルなど)をそれぞれ対象とする複数の APK を配信するには、各ビルド バリアントに同じアプリケーション ID を使用して、各 APK にそれぞれ異なる versionCode
を付与する必要があります。詳しくは、複数 APK サポートをご覧ください。AAB を使用した公開は、デフォルトで 1 つのバージョン コードとアプリケーション ID を使用する単一のアーティファクトを使用するため、影響を受けません。
注意: 以前の SDK ツールとの互換性維持のため、build.gradle
ファイルで applicationId
プロパティを定義していない場合は、ビルドツールでは AndroidManifest.xml
ファイルのパッケージ名がアプリケーション ID として使用されます。その場合、パッケージ名をリファクタリングすると、アプリケーション ID も変更されます。
ヒント: マニフェスト ファイルでアプリケーション ID を参照する必要がある場合は、任意のマニフェスト属性で ${applicationId}
プレースホルダを使用できます。Gradle はビルド時にこのタグを実際のアプリケーション ID に置き換えます。詳しくは、マニフェストへのビルド変数の追加をご覧ください。
テスト用にアプリケーション ID を変更する
デフォルトでは、ビルドツールは、指定されたビルド バリアントのアプリケーション ID の末尾に .test
を付加したものを使用して、インストゥルメンテーション テスト APK にアプリケーション ID を適用します。たとえば、com.example.myapp.free
ビルド バリアントのテスト APK では、アプリケーション ID は com.example.myapp.free.test
です。
必須ではありませんが、defaultConfig
または productFlavor
ブロックで testApplicationId
プロパティを定義することにより、アプリケーション ID を変更できます。
パッケージ名を変更する
プロジェクトのパッケージ名は、デフォルトでアプリケーション ID と一致していますが、変更することもできます。ただし、パッケージ名を変更する場合は、以下の例に示すように(プロジェクトのディレクトリ構造で定義されている)パッケージ名が AndroidManifest.xml
ファイル内の package
属性と常に一致する必要があることにご注意ください。
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myapp"
android:versionCode="1"
android:versionName="1.0" >
Android ビルドツールは、次の 2 つの目的で package
属性を使用します。
- アプリの生成された
R.java
クラスの名前空間としてこの名前を適用する。たとえば、上記のマニフェストでは、
R
クラスはcom.example.myapp.R
になります。 - マニフェスト ファイルで宣言されたすべての相対クラス名を解決する。
たとえば、上記のマニフェストでは、
<activity android:name=".MainActivity">
として宣言されたアクティビティはcom.example.myapp.MainActivity
に解決されます。
このように、package
属性内の名前は、プロジェクト内でアクティビティや他のアプリコードを保持する基本パッケージ名と常に一致する必要があります。プロジェクトにサブパッケージを含めることはもちろん可能ですが、そうすると、それらのファイルが package
属性の名前空間を使用して R.java
クラスをインポートする必要が生じます。また、マニフェスト内で宣言されたすべてのアプリ コンポーネントが、欠落しているサブパッケージ名を追加する(または完全修飾パッケージ名を使用する)必要が生じます。
パッケージ名を完全にリファクタリングする場合は、必ず package
属性も更新してください。Android Studio のツールを使用してパッケージの名前を変更してリファクタリングすれば、パッケージは自動的に同期が維持されます(同期が失われると、アプリコードは R
クラスを解決できません。これは、アプリコードが同じパッケージに含まれなくなり、マニフェストによってアクティビティまたは他のコンポーネントが識別されなくなるためです)。
プロジェクトのメイン AndroidManifest.xml
ファイルで必ず package
属性を指定してください。追加のマニフェスト ファイル(プロダクト フレーバーやビルドタイプ用)がある場合、マージされた最終のマニフェストでは、優先度が最も高いマニフェスト ファイルによって提供されるパッケージ名が常に使用されることにご注意ください。詳しくは、複数のマニフェスト ファイルをマージするをご覧ください。
補足情報: マニフェストの package
と Gradle の applicationId
で名前が異なる場合がありますが、ビルドツールは、ビルドの最後に、アプリケーション ID をアプリの最終マニフェスト ファイルにコピーします。したがって、ビルド後に AndroidManifest.xml
ファイルを検査する際は、package
属性が変更されていることに驚かないでください。Google Play ストアと Android プラットフォームは、実際に package
属性を確認することでアプリを識別します。そのため、ビルドで(R
クラスに名前空間を設定してマニフェスト クラス名を解決するために)元の値が使用されると、その値は無視されてアプリケーション ID に置き換えられます。