【ITニュース解説】F-Droid 2.0 Ships Six Days Before Google's Sideloading Lockdown. Here's What Developers Need to Know

F-Droid 2.0のリリースと、Googleが間もなく導入する新しいルールがAndroidアプリの配布に大きな変化をもたらす。この動きは、これからシステムエンジニアを目指す皆さんにとっても、Androidアプリの世界がどのように動いているかを知る上で非常に重要だ。

まず、F-Droid 2.0について説明する。F-Droidは、オープンソースのAndroidアプリだけを集めた、Google Playストアとは異なるアプリストアだ。開発者が自分のアプリをPlayストアに登録しなくても、F-Droidを通じて多くのユーザーに届けられるため、特定のポリシーに縛られずにアプリを公開したい開発者にとって重要な存在となっている。今回リリースされたF-Droid 2.0は、クライアントアプリが完全に作り直され、多くの改善が施された。例えば、プログラミング言語は古いJavaから最新のKotlinとJetpack Composeに置き換わり、Googleのデザインガイドラインに沿った、より洗練されたユーザーインターフェースが実現された。画面は「発見」「検索」「マイアプリ」の3つのタブに整理され、設定や近くのデバイスとのアプリ交換機能は上部のバーに移動し、使いやすさが向上している。

検索機能も大幅に強化された。アプリの説明文やカテゴリ、多言語翻訳までが検索対象となり、日本語や中国語といったCJK言語にも対応し、最近の検索履歴も記憶されるようになった。また、カテゴリやデバイスの互換性、さらにはプライバシー侵害の恐れがある「アンチ機能」と呼ばれる要素の有無でアプリをフィルタリングできる機能も追加され、ユーザーが求めるアプリをより簡単に見つけられるようになっている。自動アップデート機能もデフォルトで有効になり、Androidのアプリ事前承認インストールAPIを利用することで、よりスムーズな更新が可能になった。ただし、対応OSはAndroid 7以降となり、Android 6以前のサポートは終了した。この新しいバージョンは、独立したセキュリティ監査も受け、1年以上の開発期間と14回のテストリリースを経ており、セキュリティ面での信頼性も高められている。一方で、Torを使った通信のサポートは簡素化され、緊急時にアプリを消去する機能はメンテナンスのコストがかかるため削除された。

F-Droid 2.0のリリースは非常に好評だったが、一部には不満の声も上がった。特に、これまで一括でアップデートできていたアプリが、バージョン2.0では個別にクリックして更新する必要があるという変更は、一部のユーザーから使い勝手の低下だと指摘された。また、F-Droidのインフラでは新しい形式のインデックス（index-v2）に移行したが、一部のサードパーティ製F-Droidクライアント（Droid-ifyやNeoStoreなど）は、まだ古い形式（index-v1、SHA1署名）を利用しており、互換性の問題が残っている。

F-Droid 2.0のリリース時期は、Googleが発表した新しい開発者認証システム導入のわずか6日前という、非常に意味のあるタイミングだった。この新しい認証システムは、Androidアプリを「サイドローディング」、つまりGoogle Playストア以外からインストールする行為に大きな影響を与える。Googleの新しいルールは、2026年9月30日からブラジル、インドネシア、シンガポール、タイの4カ国で施行され、2027年には世界中に拡大される予定だ。このルールが適用されると、Googleが認定したAndroidデバイスには、「本人確認済みの開発者」として登録されたアプリしかインストールできなくなる。これはPlayストア経由だけでなく、手動でインストールするサイドローディングのアプリにも適用される。

開発者がこの新しいルールに対応するには、主に3つの方法が用意されている。一つ目は「完全な配布」で、開発者が本人確認を行い、アプリのパッケージ名と、アプリを署名する際に使用するキーを登録する方法だ。二つ目は「限定的な配布」で、趣味で開発している人や学生向けに、メールアドレスで登録し、最大20台のデバイスにのみ配布できるという制限付きの経路だ。そして三つ目は「上級者向けフロー」と呼ばれるもので、経験豊富なユーザーが、未登録のアプリでも「追加の安全策」を講じることでサイドロードできるようになるというが、まだ詳しい内容は不明だ。ただし、ADB（Android Debug Bridge）を使った開発者向けのインストールや、カスタムROMを使っているユーザーは当面このルールの対象外となっている。

F-Droidは、この新しいGoogleのルールによって特に大きな影響を受ける可能性がある。その理由は、F-Droidのアプリ配布方法にある。ほとんどのアプリストアでは、開発者が自分で署名したアプリのファイルをそのまま配布する。しかしF-Droidでは、提供されたソースコードからF-Droid自身がアプリをビルドし、F-Droid独自のキーで署名して配布しているアプリが全体の約85%を占めている。Googleの新しい認証システムは、アプリのパッケージ名と、それを署名した開発者のキーを紐付けるものだ。F-Droidが独自のキーで署名しているアプリの場合、そのキーは開発者のものではないため、Googleの認証システムに登録できないという問題が生じる。つまり、何千もの独立した開発者とF-Droidの間で、この問題を解決するための調整メカニズムが必要になるが、現状ではそのような仕組みは存在しない。

この問題のクリーンな解決策は「再現可能なビルド」を普及させることだ。再現可能なビルドとは、開発者が提供するソースコードからF-Droidがビルドしたアプリと、開発者自身がビルドしたアプリが、完全に同じファイルとして生成されることを意味する。これが実現できれば、F-Droidも開発者が署名したアプリをそのまま配布できるようになり、Googleの認証システムの問題を回避できる。しかし、現状では再現可能なビルドに対応しているアプリはごく一部に過ぎない。

もしあなたがF-Droidでアプリを公開している開発者であれば、いくつか対応すべき点がある。まず、自分のアプリが再現可能なビルドに対応しているかを確認し、もし対応していないなら、その実現に向けて努力することが重要だ。これにより、アプリの署名キーが開発者自身のものとして保持され、Googleの認証システムにも登録できるようになる。次に、もしあなたがGoogleの新しいルールが適用される地域にいるのであれば、たとえGoogle Playストアを利用していなくても、Googleのシステムにアプリのパッケージ名を登録することを検討する必要がある。さらに、Googleが今後発表する「上級者向けフロー」の詳細にも注目すべきだ。この仕組みが、どれだけパワーユーザーが未登録アプリをインストールできるかに影響する。最後に、アプリの「アプリケーションID」と署名に関する設定は、この移行期間中に変更せずに安定させておくことが求められる。

F-Droid 2.0は、最新の技術スタックを取り入れ、セキュリティ監査も受けた、非常に優れたアプリクライアントだ。しかし、今回の本質的な問題は、ユーザーインターフェースの改善ではなく、アプリの配布モデルそのものにある。Googleが、すべてのアプリのファイルを本人確認済みの開発者と紐付けようとする方針に対し、オープンソースのアプリをソースコードからビルドして配布するF-Droidのようなストアが、今後どのように共存していくかが、次の1年間で問われる大きな課題となるだろう。2026年9月30日は、その最初の試金石となる。この問題は最初は限られた国で始まるが、2027年には全世界に拡大される予定であるため、Androidアプリ開発に関わる誰もがその動向に注意を払う必要がある。