サイト内検索
全てのAndroid アプリは、com.example.myappといったJava パッケージ名のような重複のないアプリケーションIDを持っています。 このIDで、端末上や Google Playストア上であなたのアプリを一意で識別します。 新しいバージョンのアプリをアップロードしたい場合、 アプリケーションID(およびアプリを署名する証明書)は元のAPKと同一のものにしなければなりません。—アプリケーションIDを変更した場合、 Google PlayストアはそのAPKを全く別のアプリとして扱います。 そのため、いったんアプリを公開したらアプリケーションIDは決して変更しないでください。
アプリケーション ID は、以下で示すように、モジュールの build.gradleファイルの applicationIdプロパティで定義されています。:
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の命名規則には少し制限があります。:
メモ: 以前は、アプリケーション ID はコードのパッケージ名と直接関連付けられていました。;
そのため、いくつのかの Android APIではメソッド名やパラメーター名に"package name"という単語を使用していますが、実際はアプリケーションIDです。
例えば、Context.getPackageName() メソッドは戻り値としてアプリケーションIDを返します。
コードの正しいパッケージ名がアプリのコード外で必要になることはありません。
注意:WebViewを使用している場合は、
アプリケーションIDの頭にパッケージ名を付けることを検討してください; そうしないと、 issue 211768で説明されているような問題に直面する可能性があります。
アプリのAPK をビルドした時、ビルドツールは build.gradleファイルのdefaultConfig ブロックに定義されている(以下で示すような)タグをAPKに付けます。
しかし、異なるバージョンのアプリを作成してGoogle Playストアで "無料版"や"有償版"といったような 別の一覧として表示したい場合、
それぞれが異なるアプリケーションIDを持つ別個のビルドバリアントを作成する必要があります。
今回の場合、各ビルドバリアントは別個のプロダクトフレーバーとして定義する必要があります。
productFlavors {} ブロック内の各フレーバーについて、applicationIdプロパティを再定義したり、以下で示すようにapplicationIdSuffixを使って既定のアプリケーションIDにセグメントを追加したりすることができます。:
android {
defaultConfig {
applicationId "com.example.myapp"
}
productFlavors {
free {
applicationIdSuffix ".free"
}
pro {
applicationIdSuffix ".pro&qquot;
}
}
}
こうして、"free"プロダクトフレーバーのアプリケーションIDは"com.example.myapp.free"となります。
また、以下で示すように applicationIdSuffix を使い、ビルドタイプに基づいてセグメントを追加することもできます。:
android {
...
buildTypes {
debug {
applicationIdSuffix ".debug"
}
}
}
Gradle はプロダクトフレーバーの後にビルドタイプ設定を適用するので、ビルドバリアント"free debug" のアプリケーションIDは"com.example.myapp.free.debug"となります。 同一のアプリケーションIDを持つAPKを二つ持つことはできないので、これは同じ端末上にデバッグ用ビルドとリリース用ビルドを両方持ちたい場合に便利です。
Google Playストア上では、異なるアプリケーションIDを持つAPKは異なるアプリとして扱われるということを覚えておいてください。
そのため、異なる端末設定(APIレベルのような)を対象とする複数のAPKを配信するために複数のAPKを使うのではなく全て同じAPKを使いたい場合は、
各ビルドバリアントには同じアプリケーションIDを使って、
各APKには異なるversionCodeを設定する必要があります。
詳細についてはMultiple APK Supportを参照してください。
注意:
以前のバージョンSDKツールとの互換性のため、あなたがbuild.gradle ファイルでapplicationIdプロパティを定義していない場合、
ビルドツールはAndroidManifest.xmlファイルに記述されたパッケージ名をアプリケーションIDとして使用します。
その場合、パッケージ名をリファクタリングするとアプリケーションIDも変更されます。
ヒント: マニフェストファイル内でアプリケーションIDを参照する必要がある場合、マニフェスト属性にプレースホルダー${applicationId} を使用することができます。
ビルド時に、Gradle はこのタグを実際のアプリケーションIDに置き換えます。詳細についてはマニフェストにビルド変数を挿入するを参照してください。
既定では、ビルドツールは指定されたビルドバリアントのアプリケーションIDを使い、アプリケーションIDをインストルメンテーションテストに適用します。
アプリケーションIDには.testが追加されます。
例えば、ビルドバリアント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 ビルドツールは二つの事に 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をAPKの最終的なマニフェストファイルにコピーします。
ですから、ビルド後にAndroidManifest.xmlファイルを見て、package属性が変わっていても驚かないでください。
package 属性は、Google Play ストアとAndroid プラットフォームがあなたのアプリを識別するために実際に見る部分です。;
so once the build has made use of the original value (to namespace the
R class and resolve manifest class names), it discards that value
and replaces it with the application ID.