Google Play Console を使ってアプリのバージョンをテスターやデベロッパーとすばやく安全に共有する方法について説明します。
また、過去のリリースへのアクセス、デバッグ可能なビルドをアップロードできる内部アプリ共有など、改善された機能についても紹介します。
まずは背景情報から
テスターへの APK の配信は、メールへの添付やファイル ストレージ サーバーへのアップロードを通じて、簡単に行うことができます。そうすると、テスターは APK をダウンロードしてスマートフォンにインストールできます。これは、ファイルを入手できるすべての人にも同じことが言えます。
そこで登場したのが、Android App Bundle(AAB)です。AAB は、Android 用のアプリ公開形式です。分割された APK を使って、必要なリソースのみを簡単にユーザーに提供でき、デベロッパーによる追加の作業も必要ありません。AAB はアプリの公開形式です。つまり、Google Play はエンドユーザーの端末に配信する一連の APK を生成します。そのため、エンドユーザーがインストールする厳密なアーティファクトをテストするのが難しくなります。ダイナミック配信やアプリ内アップデートなどの高度な機能を考慮する場合は、特にこれがあてはまります。
大規模なチームや複数の利害関係者、外部テスターと一緒に作業をしている方なら、インストール可能なアーティファクトを直接共有する方法を探していることでしょう。デベロッパー ツールをインストールしてコマンドを実行してもらうのは、現実的な方法ではないかもしれません。また、bundletool を使って Android App Bundle を APK に変換し、端末にインストールすることができたとしても、アプリ内アップデートやオンデマンド配信の実装はテストできません。
しかし、悩むことはありません。Google Play Console を使えば実現できます。
限定されたテスターによるアプリのテスト
Google Play Console は、限定されたユーザーとアプリを共有する複数の方法を提供しています。アクセスを制限するには、URL をオプトインする、特定のメーリング リストに参加する、Google Play ユーザー アカウントに関連付けられたメールアドレスを使って個別に設定する、のいずれかの方法を使います。
テストトラック
一般ユーザーではアクセスできない複数のトラックを使用することができます。つまり、誰がどの開発段階でアプリにアクセスできるかを厳密に決めることができます。各トラックの特に重要な違いを説明します。
内部テストトラック
- アプリ 1 つにつき、テスター 100 名まで
- 幅広いチームでリリース候補をテストする場合に最適
- 即座に利用可能
クローズド トラック
- 個々のユーザーまたはグループ全体を招待
- 一般公開前の組織規模でのテストに最適
- 公開前レビューが必要
オープン トラック
- 一般ユーザーが直接オプトイン可能
- 本番公開前の大規模なユーザーのグループによるテストに最適
- 公開前レビューが必要
上記のトラックに関する一般的な補足事項
上記のいずれかのトラックを経て本番環境に移行できるのは、1 つのバージョンのみです。
テストトラックで公開するアーティファクトには、Play Console でテスト プログラムをオプトインしたユーザーがアクセスできます。
各トラックには、1 つの Android App Bundle または 1 つの APK をアップロードできます。
内部アプリ共有の詳細
上記のトラックと合わせて、Google Play Console は特別なデベロッパー ツールである
内部アプリ共有を提供しています。
内部アプリ共有の最も重要な特徴は、ここに APK または AAB をアップロードしても、Play Console で公開しているリリースには何の影響も与えないことです。つまり、内部アプリ共有をテストトラックや本番環境に直接移行することはできません。
また、
デバッグ可能なアプリを内部アプリ共有にアップロードすることもできます。つまり、Play Console からインストールできるようになるビルドにデバッガーをアタッチすることができます。
さらに、新しいバージョンをアップロードするために
バージョン コードをインクリメントする必要はありません。そのため、開発用にバージョン コードを空けておいたり、バージョン コードが枯渇することを心配する必要はなくなります。アップロードしたアプリごとに異なるリンクを共有することで、お互いに干渉し合うことなく、独立して複数のバージョンをテストすることができます。
開発チームから
アップロード担当者を認定することもできます。内部アプリ共有のみへのアクセスを許可することができ、Play Console の他の部分へのアクセス権を与える必要はありません。
ダウンロード可能者を認定するには、Play Developer Console の [Development tools] > [Internal app sharing] にアクセスします。リンクを共有するために、オプトインした人のメールアドレス一覧を使ってユーザーをホワイトリストに登録することができます。これにより、リンクを知っているすべての人がテストビルドを端末にダウンロードできるようになります。
注: 現在、端末上の複数アカウントに関する制限があることは承知しています。これを回避するには、すべてのアカウントが内部アプリ共有にアクセスできるようにするか、メールアドレス一覧にないテスターも Play Console でダウンロードできるようにします。
内部アプリ共有で高度な機能をテストする
内部アプリ共有を使うと、実際の環境で本物のユーザーと同じ状態でダイナミック機能モジュールの
オンデマンド インストールをテストすることができます。デバッグ可能なバージョンをアップロードすると、Android Studio でデバッガーをアタッチし、正しいコードが実行されているかどうかを確認することまでできます。
また、古いバージョンのコードを内部アプリ共有にアップロードすれば、
アプリ内アップデートのテストも可能です。これを行うには、次のフローに従います。
- 異なる versionCode 属性を持つ 2 つのバージョンを内部アプリ共有にアップロードします。
- 内部アプリ共有 URL から、バージョンが低い方のアプリをインストールします。
- バージョンが高い方のアプリのリンクを開きますが、ここではインストールは行いません。
- 再度インストールしたバージョンを開きます。
- アップデートが可能な旨が表示されます。
ただ、古いバージョンのアプリに簡単にアクセスでき、それをすぐに他のユーザーと共有できたらいいのにとは思いませんか?
過去のリリース機能を使う
過去のリリース機能を使うと、すばやく確実にアプリの古いバージョンにアクセスできます。
内部アプリ共有にアクセスできるユーザーは、本番トラックにアップロードされたすべてのバージョンにアクセスすることもできます。そのために知っておく必要がある情報は、リリースの
バージョン コードと
パッケージ名だけです。
この情報さえあれば、次の URL スキームからアプリの過去のバージョンをインストールできます。
https://play.google.com/apps/test/<package name>/<version code>
ただし、
Bundle Explorer で認定テスターを管理する画面でも、バージョン コードとリンクを確認できます。[Internal app sharing] セクションには、特定のバージョンをインストールするために必要なすべての情報が表示されています。すべてを設定すると、この URL を使って過去の AAB や APK リリースをインストールできるようになります。
参考資料と次のステップ
公開トラックや
内部バージョンの共有に関するドキュメントをお読みください。
また、
Wojtek Kaliciński が
ローカルでオンデマンド モジュールを開発およびテストする方法の概要をブログ記事で解説(英語)しています。