✏Androidアプリの公開方法

Androidアプリの公開方法には大きく次の２パターンに分けられます。

• Google Playストアに登録して公開する
• 個人のホームページなどにアップして公開する

いずれの場合においても共通するのが、『アプリを公開するための専用のファイルを作成する必要がある』という点です。

プロジェクトのappディレクトリをまるごとコピーして、それをストアやサーバにアップロードすれば良い…といった単純なものではないということですね。

また、公開用ファイルを作成する際にアプリの署名が必要となるという点も重要な共通点です。

Google Playストアを通さず、個人のホームページなどでサイドローディング用にAndroidアプリを配布する場合であっても、アプリの信頼性と安全性を高めるために『署名』というステップを省略することはできない仕組みになっています。

署名といっても、当然ながらアプリのコードのどこかに自分の名前を記入するようなアナログなものではありません。アプリ署名について、その仕組みを事細かに把握しておく必要はありませんが、『秘密鍵』や『公開鍵』といった電子署名に関する必須ワードと、その基本的な仕組みぐらいは理解しておいた方が良いかもしれません。

簡単に言えば、開発者でしか生成することができない秘密鍵を利用してアプリ署名を行い、公開鍵を用いてその署名を検証することによって、アプリがその開発者によってリリースされた正当なものであることを確認できる仕組みになっています。

アプリ署名に関してもっと詳しく知りたい方は、Android Open Source Project公式サイトをご覧ください。

・アプリへの署名 Android Open Source Project
https://source.android.com/docs/security/features/apksigning?hl=ja

署名の仕組みはややイメージしづらいかもしれませんが、とにかく『このアプリは間違いなく私が作りました』と証明できる状態のファイルを作成できて初めて、アプリをストアに登録する手続きを進めたり、Webサイトで公開したりすることができるというわけです。

そして、その結果として作成されるファイルが AAB もしくは APK と呼ばれるファイルになります。これらの違いは次のステップで説明します。

📂 AABとAPK

前のステップで触れた通り、アプリの公開場所がGoogle Playストアであれ、個人のホームページであれ、署名された AAB もしくは APK が必要となります。

では AAB とか APK とかって一体何なのでしょうか？何が違うのでしょうか？

細かいことを一切抜きにすれば、次のようにまとめられます。

• AAB → Google Playストアに提出する用
• APK → サイドローディング可能なファイルとして、ホームページなどに掲載する用

基本的にはこのように理解してしまって大丈夫です。もう少し詳しく知りたい方は続きをご覧下さい。

AAB（Android App Bundle）は、GoogleがGoogle Playストアにアプリを提出する際に推奨している形式です。

APK形式でもPlayストアにアプリを提出することは可能ですが、AAB形式ではPlayストアによってファイルが最適化されるため、アプリのダウンロードサイズをグッと減らせるなどのメリットが得られます。だからこそ、GoogleはAAB形式の方を推奨しているとも言えます。

ここまでだとメリットしかないように聞こえるAAB形式ですが、AABはサイドローディング用としては使用できません。（Google Playストアによる最適化処理を受けられないため）

一方、APK（Android Package Kit）は、AAB形式の導入以前から使われているアプリのパッケージ形式です。

既に言及したように、こちらの形式でもGoogle Playストアに提出することが可能です。ただし、AABと違ってPlayストアで最適化されないため、AABで提出した場合と比べるとアプリのダウンロードサイズが大きくなってしまう傾向があります。

そのため、Google Playストアに提出する場合においては、あえてAPKを選択する理由はない（AABの方が良い）と言えるのですが、APKはサイドローディング用として配布可能というメリットがあります。すなわち、APKならばユーザーが直接端末にアプリをインストールできるということです。

結論としては、最初に述べたように、Google Playストアに提出するのであればAAB、サイドローディング用として配布するのであればAPKということになります。

名称や使用目的が微妙に異なるAABとAPKですが、これらのファイルの作成方法はほとんど同じです。次のステップでは、Android Studioを使った AAB・APK ファイルの作成方法をご紹介します。

🛠 はじめてのAAB・APKの作成

既にアプリが完成したという体で、AAB・APKファイルを実際に作成してみましょう。なお、両者とも作成方法はほぼ同じであるため、ここではAABで作成していきます。

Android Studioでプロジェクトを開き、メニューバーから Build > Generate Signed App Bundle or APK を選択します。

すると、AABとAPKどちらの形式でアプリ署名ファイルを作成するかを選択するダイアログが現れるので、作成したい方を選択し、Next をクリックします。（ここではAABを選択）

次に、アプリの署名鍵を指定するダイアログが現れます。今回は初めてアプリ署名を行う状況を想定しているため、全て一から作成していきます。 Create new… をクリックします。

すると下のようなダイアログが現れます。（下の画像は必要項目が既に入力された状態のものです）

はじめてAAB（APK）を作成する場合、ここでの設定に少し戸惑うかと思うので丁寧に解説していきます。

まず、ダイアログの上部に注目します。上部には、Key store path を設定するための項目が並んでいます。

Key store path（①） というのは、これから作成されるアプリの署名鍵（秘密鍵）を管理するためのファイルです。

自分にとって分かりやすく、管理しやすい場所であればファイルの作成場所はどこでも構いませんが、セキュリティ上安全な場所に保管することをオススメします。誤って削除してしまいやすい『ダウンロード』ディレクトリや、デスクトップなどは避けた方が良いでしょう。

そしてここで設定するパスワード（②）は、アプリ署名鍵を格納するファイルに対するパスワードです。後で署名鍵そのものにもパスワードを設定する必要があるため、合計２つのパスワードを設定することになります。

では次に、ダイアログの真ん中あたりに注目してみましょう。

Key（署名鍵）の Alias などを設定する項目が並んでいますね。順番に解説していきます。

Alias（①） というのは署名鍵を識別するための名前（ラベル）のようなものです。アプリの特徴を表すような、分かりやすい名前を付けると良いでしょう。（ここでは key0 としていますが、こういった分かりづらい名称はあまり推奨されません）

そして Password（②）ですが、これは署名鍵に対するパスワードです。先ほど設定した署名鍵を格納しておくファイルのパスワードとは異なるので、混同しないように注意しましょう。

Validity (years)（③） というのは、署名鍵の有効期限（年数）です。セキュリティ上、有効期限を定めておかなければならないことになっていますが、かなり長い期間を設定することができます。25年ぐらいに設定しておけば、とりあえず署名鍵の更新のことはあまり気にしなくても良くなるでしょう。

最後に、ダイアログの下の部分に注目してください。

この部分には、開発者の氏名などの個人情報を入力するフィールドが並んでいます。なお、開発者が法人やチームである場合も当然あり得ますが、ここでは個人開発の場合を想定して、入力例をご紹介します。

• First and Last Name:

  ファーストネームとラストネームを入力します。私は日本人なので日本人名を例にさせて頂きますが、例えば田中太郎さんであれば、Taro Tanaka と入力します。

• Organizational Unit:

  部門名やチーム名を記入するフィールドですが、個人開発の場合は Individual（個人）というふうに入力しても問題ないでしょう。

• Organization:

  組織名や会社名（Organizational Unitよりも規模が大きいもの）を記入するフィールドです。こちらも個人開発であれば、individual で問題ないかと思われます。

• City or Locality:

  居住している都市や地域名を入力します。日本で言えば、『市町村』単位が当てはまると言えます。例えば福岡県福岡市にお住まいであれば、このフィールドには Fukuoka-shi というふうに入力できます。

• State or Province:

  居住している州や県を入力します。日本で言えば『都道府県』単位です。福岡県ならば、Fukuoka-ken というふうに入力します。

• Country Code:

  国の識別コードを入力するフィールドです。国の2文字のISOコードを使用するのが一般的です。日本の場合は JP となります。

以上、内容を確認して OK をクリックすると、AAB（APKを選んだ場合はAPK）を作成する準備が整い、Next をクリックできるようになります。

最後に、relase を選択した上で Create をクリックします。

すると署名されたAAB（APK）が作成されます。

署名鍵とそれを管理するファイルは指定されたディレクトリに、AAB（APK）はプロジェクトディレクトリの app > release ディレクトリにそれぞれ作成されます。

あとは出来上がったAAB（APK）をGoogle Playストアに提出し、その他の必要事項の入力や要件をクリアしたらストアにアプリを公開できます。（※アプリの公開にあたっては審査をパスする必要があります）

サイドローディング版として配布する場合はAPKで作成し、APKファイルをダウンロード可能な場所（公開サーバーやファイル共有サービスなど）に配置して、ユーザーがダウンロードできるようにすればOKです。

⤴ アプリの更新（バージョンアップ）

通常、アプリは一回リリースしたらそれっきりではなく、機能の追加やバグの修正などを重ねてアプリの品質を高めていく必要があります。

その際、アプリを一から作り直す（別のアプリとしてリリースする）のではなく、既存のプロジェクトにファイルやコードを追加したり修正したりすることで、アプリをバージョンアップさせるのが一般的です。

アプリを初めてリリースするためのAAB・APKの作成方法は前のステップで確認した通りですが、２回目以降のAAB・APKはどのように作成すれば良いのでしょうか？

このステップでは、アプリのバージョンアップを目的とした２回目以降のAAB・APKの作成方法について、簡単にご説明します。

まず、Androidアプリにおけるアプリのバージョンナンバーは２種類あることを確認しておきましょう。

１つは、Playストアがアプリのバージョンを管理するための内部的な数値であり、ユーザーの目には触れない情報。

そしてもう１つは、Playストアのアプリ詳細情報や、インストールしたアプリの『アプリ情報』などの項目で表示される、ユーザーがアプリのバージョンナンバーを確認するための情報です。

これらは全くの別物であり、数値を一致させる必要はありません。後述しますが、前者は整数、後者は文字列で指定するようになっていることからも用途の違いが明確にされています。

これらのバージョン情報は、モジュールレベルの build.gradle.kts ファイルで確認・変更することができます。初回では次のようになっているはずです。

（中略）
defaultConfig {
    // ..Other Settings
    versionCode = 1
    versionName = "1.0"
    // ..Other Settings
}

versionCode が整数値（Int）で表す内部的なバージョン管理情報で、versionName が文字列（String）で表すユーザーに知らせるためのバージョン情報です。

アプリを更新する際は、versionCode を必ず増加させる必要があります。通常、1ずつ増やしていくと良いでしょう。

一方、versionName は文字列で指定できることから分かるように、表現の仕方に柔軟性が与えられています。

一般的には、"1.1.4" というふうに、メジャーアップデートやマイナーアップデートなどの種類に合わせて数値を増やしていくような表現を採用することが多いです。

アプリを更新する際のコードの変更例としては、次のようになります。

defaultConfig {
    // ..Other Settings
    versionCode = 2
    versionName = "1.1"
    // ..Other Settings
}

これらの設定により、Playストアや端末にインストールされているアプリが、このアプリを『同一アプリのアップデートバージョン』だと認識できるようになります。全く別のアプリとしてリリースし直したり、ユーザーがアプリを一旦アンインストールしたりしなくても良くなるので、開発者・ユーザーどちらにとってもメリットが生じます。

バージョン情報の修正が完了したら、再びAABもしくはAPKを作成することになりますが、ここでアプリの署名鍵（及びそのパスワード）が必要となります。

もし、署名鍵無しにアプリを更新できる仕組みになっていたら、第三者が勝手にアプリを更新できてしまう事態になりかねません。そうならないよう、アプリを更新できるのはそのアプリ署名鍵を持つ開発者だけに限定されています

言い換えれば、署名鍵ファイルを紛失したり、間違って消去したり、あるいは設定したパスワードがわからなくなってしまうようなことがあれば、開発者であってもそのアプリを更新できなくなってしまいます。

さらに言い換えれば、万が一アプリ署名鍵とパスワードが漏洩し、第三者の手に渡ってしまったら、第三者がアプリを勝手に更新できてしまう危険性が大幅に高まってしまいます。

そのため、アプリの署名鍵とそのパスワードは厳重に保管し、適切にバックアップを取り、データの消失や漏洩には十分に注意して下さい。

以上を踏まえた上で、アプリを更新する際の手順を確認していきましょう。

AAB（APK）の初回作成時と同様に、Build > Generate Signed App Bundle or APK を選択し、AABもしくはAPKを選択します。（ここは初回作成時と同じため、スクリーンショット画像は省略します）

次にアプリ署名鍵が格納されているファイルパスとそのパスワード、アプリ署名鍵のパスワードを入力して Next をクリックします。

release を選択して Create をクリックするとアプリを更新するためのAAB（APK）が作成され、初回作成時と同様に app > relase ディレクトリでファイルを確認することができます。

このファイルをGoogle Playストアに提出したり、ホームページで公開（サイドローディング版）したりすれば、ユーザーはアプリをバージョンアップできるようになります。（※Google Playストアにおいては、アプリの更新時にも審査があります）

おわりに

Jetpack Composeなどの便利なツール・フレームワークの登場や、YouTubeやSNSでそれらの情報をより簡単にキャッチできるようになったことで、Androidアプリの個人開発に興味を持つ人は益々増えているのではないでしょうか。

アプリ開発に興味を持ってくれる人が増えるのは喜ばしいことなのですが、最初のうちはどうしても『アプリを作ること』に全力を注いでしまいがちで、その後のアプリの継続的な改善、運用・メンテナンスのことまでは考えが及びづらいものです。

結果として、アプリを１〜２つ作ってみただけで飽きてしまったり、燃え尽きてしまったりする人も少なくないのではないかと想像します。

何らかのアプリを開発できる（完成させられる）だけでも素晴らしいことではありますが、それだけで終わってしまうのはとてももったいないことではないかと思います。

せっかくアプリを開発するのであれば、できるだけ長い期間をかけてアプリを育てていくつもりで開発することを強くおすすめします。長く自分が開発したアプリと関わり続けていくことで、開発力だけでなく、保守・運用スキルも磨くことができますよ！