自社のサービスではGoogle Playの他にAmazon Appstoreでもアプリを公開しているのだが、fastlaneにはAmazon Appstoreへリリースする機能が無く、Issueも長い間開きっぱなしになっていたのでプラグインを作った。

https://github.com/ntsk/fastlane-plugin-amazon_appstore

プラグインを使うと、Supplyと同じようにAmazon Appstoreへ最新のapkをアップロードし審査に提出することができる。 はじめは、apkをアップロードするくらいFastfileに直接処理を書いちゃえば良いと思っていたのだが、調べてみると審査に提出するまでに複数のエンドポイントをそれなりの回数叩く必要があることが分かり、プラグインにすることにした。

しかし、完成した4日前に、@joshdholtz 氏が対応に取り組み始めたとのコメントを書いており、このGemは将来的にいらないものになりそうだった。 公式で対応してくれるのが嬉しい一方で、少し悲しい気持ちになったので、この記事で供養する。

使い方

fastlane add_plugin コマンドでプラグインを追加する。

fastlane add_plugin amazon_appstore

API Authentication のページに記載の通りの手順で、事前にClient ID/Client Secretを取得し、Fastfileでapkのpathとともに指定する。

upload_to_amazon_appstore(
  apk: "app/build/outputs/apk/release/app-release.apk",
  client_id: <YOUR_CLIENT_ID>,
  client_secret: <YOUR_CLIENT_SECRET>
)

デフォルトではアップロード後に審査にそのまま提出するが、Supplyと同様、changes_not_sent_for_reivew パラメータを利用することで、審査前でストップして手動で確認してGUIから審査へ提出する運用もできる。

また、Supplyと同様に、metadata配下などにそのバージョンのchangelogsを配置することで、言語ごとに更新も行うことができる。デフォルトのpathはSupply同様に ./fastlane/metadata/android となっているが、Google PlayとAmazon Appstoreで違うchangelogsを利用したい場合には、metadata_path を個別に指定することで変更できる。

内部的にどのようにAPIを叩くか

App Submission API のドキュメント に記載のPython APIの例のようにAPIを叩いている。というより、各エンドポイントのパラメータ等に関する説明ページは存在しないため、このPythonのコードを見て実際に叩いてみるしかない。

複数のエンドポイントを叩く必要があるという話を最初にしたが、図にすると審査に提出するまでに以下のように叩く必要がある。

図の補足として、(1)のOAuth2トークンの取得のためのAPIは、https://api.amazon.com/auth/o2/token で、取得したトークンを利用する(2)以降のAPIは、https://developer.amazon.com/api/v1/applications となっている。

リクエスト回数が増える理由として、PUTリクエストを行う際、事前にGETリクエストでEtagを取得し、それをリクエストヘッダにつけて更新する必要があることにある。これは、リソースの更新が複数箇所から同時に行われた場合の整合性を維持するためのもので、リソースが更新されるとEtagも更新される。Etag取得後にリソースが更新されている場合には、再度取得して最新のEtagを利用しないとリソース更新ができない。

情報がなく、必要なEtagの取得にどのエンドポイントを叩けば良いのか最初はよく分からなかったのだが、PUTしたいエンドポイントにそのままGETするのではなく、PUTのためのaction(replaceやcommitなど)を除く1つ前のPATHのエンドポイントに対してGETを行う必要があるようだった。

今後の改善点

Google Playと異なり、Amazon Appstoreではchangelogsの更新がマストになっている。 このため、changelogsがmetadataディレクトリから取得できない場合には、-をデフォルトで入力するようにしている。未入力や空文字では審査提出ができず提出を妨げない目的でこのようにしているのだが、他に良い対応案があれば改善したい。

また、図のように現状のプラグインでは、1つのapkを更新することしか対応していない。返却されたapksのうち先頭(APK1)のみを更新する形となっている。複数apkへの対応や、スクリーンショットなどのストア情報の更新の対応なども需要があれば対応したい。(その前に公式がサポートしそうだが…)