ビルド連携

Gradle で Android 登録確認を本番バリアントに追加

Gradle は application ID とビルド バリアントを把握しているため、信頼できる照会入力を出力する場所に適しています。Status API 呼び出しは毎回のローカル debug ビルドではなく、リリース タスクとして実行します。

概要

Gradle での Android 登録確認では、固定パッケージ値ではなく最終 application ID と署名済みアーティファクトの ID を使います。

対象: 多数のバリアントや product flavor を管理する Android エンジニア。

確認手順

  1. 選択したリリース バリアントから applicationId を解決する。
  2. 本番アーティファクトの署名後だけ照会を実行する。
  3. Android build-tools で証明書 SHA-256 を抽出する。
  4. 資格情報を出さず、小さな機械可読結果を CI へ渡す。

要点

正しい入力元最終リリース バリアント
避けるもの固定された debug パッケージ名
実行時点毎ビルドではなくリリース前
注意点

product flavor と applicationIdSuffix は、誤った NOT_REGISTERED を生む代表的な原因です。

詳しい解説

選択バリアントから値を解決する

現在の Android ビルドは複数の application ID と署名設定を持てます。別の固定 ID リストを保守せず、リリース専用タスクを選択バリアントと署名済み出力へ接続します。

通常の compile と test からネットワーク照会を外します。パッケージ名とフィンガープリントを小さな機械可読アーティファクトとして出力し、保護された API 呼び出しは CI に任せます。

  • 開発者の全 debug ビルドで実行しない。
  • namespace と applicationId が同じと仮定しない。
  • リリース確認に debug 署名設定を使わない。
アーティファクト確認
./gradlew assembleRelease
apksigner verify --print-certs app/build/outputs/apk/release/app-release.apk

製品版のパッケージ名を入力し、署名も照合する場合は配布 APK の証明書 SHA-256 を追加します。ストア審査やアプリの安全性とは別の確認です。

ステータスを確認 →

よくある質問

全 Gradle ビルドから直接 API を呼ばない理由は？

割り当てを消費し、ローカル ビルドを遅くし、より多くの環境へ資格情報を置くことになるためです。管理されたリリース前確認として実行します。

flavor はどの値で確認しますか？

最終バリアントの application ID と、そのバリアントの署名済みアーティファクトにある証明書を使います。

出典と更新情報

最終確認日: