AppSeedのアプリ開発ブログ

アプリ開発会社AppSeed(アップシード)開発担当のブログです。iOS、Android、Unity、Cocos2d-xなどアプリ開発関連のTipsや備忘録、アプリ開発に役立つ情報を発信します。

Google Playストアのアプリ登録で「パッケージ名がすでに使用されています」のエラーが出た場合の対処法のメモ

最近、新規でリリースしようとしていた複数のAndroidアプリで、Google Play Consoleでパッケージ名を入力すると「すでに使用されています」というエラーが出る現象が連続して発生しました。最終的に解決まで結構時間がかかったので、今後のためにメモとして残しておきたいと思います。

Google Playの「パッケージ名がすでに使用されています」エラー

新規でアプリを登録しようとしてGoogle Play Consoleでパッケージ名を入力すると、以下のようなエラーが表示される現象でした。

「com.appseed.xxxxx」はすでに使用されています。 このパッケージ名を登録するには、既存の署名鍵の所有権を証明する必要があります。

状況としては以下のような感じでした。

  • AppSeed Developer Accountは自分で管理していて他の人が使うことはない
  • 「すべてのアプリ」一覧にそのパッケージ名のアプリは存在しない(ドラフト含む)
  • 「APK署名アップロードによる所有権確認」の画面で要求されるSHA-256が、手元の本番リリース用キーストアと一致しない

自分で登録した覚えはないのに、Googleのシステム上ではすでに予約状態になっている、という不思議な状況でした。

原因の調査

最初は「Googleのバグかな?」と思いましたが、新規でリリースしようとしていた7つのアプリすべてで同じ症状が出ていたので、何か共通の原因があるはずだと思って調査しました。

各アプリで共通している点を整理すると、以下のような感じでした。

  • AdMobで収益化している
  • AdMob Consoleでアプリ IDを取得済み
  • AndroidManifest.xmlにAdMob ApplicationIdを記載
  • flutter runでデバッグ実行を何度かしている
  • Firebaseは使っているアプリと使っていないアプリがある

Firebaseを使っていないアプリでも発生していたので、原因はFirebase経由ではなさそうです。共通項として残ったのは「AdMobのアプリ ID取得 + デバッグビルドでのアプリ起動」だけでした。

そこで、Android Studioが自動生成する~/.android/debug.keystoreのSHA-256と、Google Play Consoleが要求するSHA-256を比較してみたところ、なんと完全一致していました。

keytool -list -v -keystore ~/.android/debug.keystore -storepass android -keypass android | grep "SHA256"

つまり、各アプリのパッケージ名にデバッグキーのSHA-256が登録されてしまっている状態だったわけです。

なぜデバッグキーが登録されたのか(推測)

正確な内部動作はGoogle側しかわかりませんが、おそらく以下のような流れだと推測しています。

  1. AdMob Consoleで新規アプリ IDを発行
  2. AndroidManifest.xmlにAdMob ApplicationIdを設定
  3. flutter runでデバッグビルドを起動
  4. AdMob SDKがGoogleサーバーと通信
  5. その通信で、デバッグキーで署名されたアプリのSHA-256が、AdMobのアプリ IDとパッケージ名と一緒にGoogleに記録される
  6. AdMobとGoogle Play Consoleは同じGoogleアカウント単位で連携している
  7. 結果として、Google Play Console側で「このパッケージ名はすでに使用されています」状態になる

AdMob SDKのドキュメントには明示的な記載は見つけられませんでしたが、複数アプリで同じ症状が出たことと、共通項としてAdMobしか残らなかったことから、この仮説が一番しっくりきます。

試してみたこと

調査の過程でいくつか試してみました。

  • 手元のキーストア(AppSeedで使っている全部)のSHA-256を比較 → 全部不一致
  • Firebase Consoleの全プロジェクトを確認 → Android版の登録なし
  • Google Cloud ConsoleのOAuthクライアントを確認 → 該当なし
  • Google Playの通常のサポート窓口に問い合わせ → 「Android Developer Verification専用フォームを使ってください」と返信

通常のサポート窓口では対応できない案件らしく、専用フォームへ誘導されました。

解決方法

最終的には、Google Play Consoleの「APKの署名とアップロード」機能で所有権を証明することで解決できました。

ちなみに、最初は要求SHA-256がデバッグキーのものでしたが、1日経過してから再度Play Consoleを開いてみたら、要求SHA-256がAppSeedの本番リリース用キーストア(oshi_note_release.jks)のものに変わっていました

これは推測ですが、Googleの新しいAndroid Developer Verificationシステムが、署名鍵の使用実績を見て「主要な鍵」を動的に再評価しているのかもしれません。AppSeedのoshi_note_release.jksが他のアプリで実際にリリースに使われている実績が評価されたのではないかと思います。

なので、もし要求SHA-256がデバッグキーのものだった場合は、すぐに諦めずに1〜数日待って再確認するのがおすすめです。

所有権確認の手順

実際にやった手順は以下の通りです。

1. スニペットを取得

Google Play Consoleの「APKの署名とアップロード」画面に表示されるスニペット(アカウント固有の識別子)をコピーします。コピーボタンから取得するのがおすすめです。目視で写すと文字数を間違えてしまう可能性があるので(実際1度間違えました)。

2. adi-registration.propertiesを作成

FlutterプロジェクトのAndroidネイティブ側のassetsフォルダに、スニペットを記載したファイルを作ります。

cd /Users/macmini/flutter-project/[アプリフォルダ名]
mkdir -p android/app/src/main/assets

cat > android/app/src/main/assets/adi-registration.properties << 'EOF'
[コピーしたスニペット]
EOF

ここでハマりやすいポイントなのですが、配置場所はFlutterのassets/ではなく、Android側のandroid/app/src/main/assets/になります。間違えやすいので注意です。

3. 要求SHA-256に対応する鍵で署名

android/key.propertiesで、要求されたSHA-256に対応するキーストアとエイリアスを指定します。

storePassword=(パスワード)
keyPassword=(パスワード)
keyAlias=oshi_note
storeFile=/Users/macmini/oshi_note_release.jks

4. リリースAPKをビルド

flutter clean
flutter pub get
flutter build apk --release

5. 署名と中身を確認

ビルドしたAPKが正しく署名されていて、adi-registration.propertiesがちゃんと含まれているか確認します。

# 署名のSHA-256確認
keytool -list -printcert -jarfile build/app/outputs/flutter-apk/app-release.apk | grep "SHA256"

# adi-registration.propertiesがAPKに含まれているか確認
unzip -p build/app/outputs/flutter-apk/app-release.apk assets/adi-registration.properties

6. APKをアップロード

Google Play Consoleの「APKの署名とアップロード」画面にAPKをドラッグ&ドロップしてアップロード。これで所有権が確認されて、パッケージ名が自分のアカウントに正式登録されます。

無事に登録されれば、あとは通常通りリリースAABをアップロードするだけです。

再発防止のために

今後同じ問題に遭遇しないように、新規アプリ開発時は以下を意識しようと思いました。

AdMob ApplicationIdをkDebugModeで分岐する

final adAppId = kDebugMode 
  ? "ca-app-pub-3940256099942544~3347511713"  // テスト用
  : "ca-app-pub-XXXXXXXXX~XXXXXXXXX";          // 本番

デバッグビルドではGoogle公式のテスト用ApplicationIdを使うようにすれば、自分の本番AdMob IDを発行する前から開発できます。

AdMobのアプリID取得はリリースビルドが安定してから

開発初期にAdMob Consoleでアプリ IDを発行すると、その瞬間からデバッグビルドのSHA-256が記録される可能性があります。リリース直前まで本番AdMob IDを発行しない、もしくは設定しない運用が安全そうです。

まとめ

新規Androidアプリで「パッケージ名がすでに使用されています」エラーが出た場合は、

  1. まず~/.android/debug.keystoreのSHA-256と要求SHA-256を比較してみる
  2. 一致したら、おそらくAdMobのアプリ ID取得が原因
  3. デバッグキーが要求されていたら、1〜数日待つと本番鍵に変わることがある
  4. Google Play Consoleの「APKの署名とアップロード」機能で所有権を証明する

という流れで解決できる可能性が高いです。

最初は「これは詰みかな…」と思いましたが、手順がわかれば1アプリあたり10〜15分程度で対応できました。同じ問題で困っている方の参考になれば幸いです。

新規アプリ開発時はAdMob ApplicationIdのkDebugMode分岐を最初から組み込むのがおすすめです。