ハクソク

世界を動かす技術を、日本語で。

F-Droidのビルドサーバーは、古いCPUのために最新のAndroidアプリをビルドできません

286日前

概要

  • 2025年8月7日以降、F-Droid上の多くのAndroidアプリでビルド問題が発生
  • 原因はAndroid Gradle Plugin（AGP）8.12.0のaapt2バイナリが新しいCPU命令を必須化
  • F-Droidのビルドファームがこれら命令に非対応で、数百のアプリに影響
  • ダウングレードやプロファイル無効化など回避策が必要
  • ユーザー・開発者双方に混乱と負担が発生

F-DroidにおけるAndroidアプリのビルド問題（2025年8月）

  • 2025年8月7日、 F-Droid 上の多くの Androidアプリ でビルド不可問題が発生

  • Android Gradle Plugin（AGP）8.12.0 または Gradle 9.0 を利用するアプリが主な対象

  • 原因は、 Google製aapt2バイナリ が SSE4.1 や SSSE3 などのCPU命令を必須化

  • F-Droidの ビルドファームのハードウェア が、これらCPU命令に非対応

  • 過去（2021年）にも AGP 4.1.0 で同様の問題が発生した前例

具体的な影響事例

  • オープンソースアプリ MBCompass で同様のビルド失敗を確認
  • AGP 8.11.1 と Gradle 8.13 へダウングレードで一時的にビルド可能
  • それでも AGPのbaseline profile再現性バグ でF-Droid側はビルド失敗
  • 最終的な回避策は baseline profilesの無効化 と再リリース
  • この対応により、短期間で複数の「メンテナンス」版リリースが必要
  • ユーザーの混乱、開発者の工数増加

問題の本質と今後の課題

  • インフラ側の制約 による開発・リリースフローの複雑化
  • アプリ開発者が ハードウェア非依存 でビルドできる仕組みの必要性
  • F-Droid や Google による協調的な対応策の模索
  • ユーザー・開発者双方が安心して利用・開発できるエコシステムの維持

Hackerたちの意見

参考リンク: F-Droidの管理者問題: https://gitlab.com/fdroid/admin/-/issues/593 Catimaの例: https://github.com/CatimaLoyalty/Android/issues/2608 MBCompassのケース: https://github.com/CompassMB/MBCompass/issues/88

└

Catimaのスレッドを見てると、F-Droidってすごく扱いづらいコミュニティみたいに感じるね。これは一人のコメントと他の人たちの同意を基にしてるだけで、実際の知識や経験からじゃないけど。 >「でも、F-Droidに関してはいつもそうなんだ。何を言っても無駄な耳に届かない。」だから、もう無駄に時間を費やしたくないな。もし問題を提起して解決策を話し合うことでF-Droidが改善できると思ってたら、何年も時間とエネルギーを注いだ後にフラストレーションでプロジェクトを去ることはなかっただろうな。

これはかなり心配だね。特に今のところ、FDroidは非GoogleのAndroidストアの中で圧倒的に大きいから、Googleに対する気持ちに関係なく、これは本当に必要だと思う。これを解決するための計画を知ってる人いる？FDroidはサーバーを更新するのかな？Googleは要件を撤回する方向で動いてる？（これに関してはちょっと難しそうだけど）

└

確かにちょっと心配だけど、F-Droidはボランティアで運営されてるコミュニティプロジェクトだってことを忘れないでね。特にEUのいくつかの国がオープンソースソフトウェアに移行してるから、F-Droidのようなプロジェクトに公的資金が見られるといいな。

└

「FDroidは現在、非GoogleのAndroidストアの中で圧倒的に大きい。」サムスンのギャラクシーストアの方がずっと大きいよ。

└

「FDroidは現在、非GoogleのAndroidストアの中で圧倒的に大きい。」トップ10に入ってるかすら疑わしいね。

└

もしf-droidが大事なら、寄付して新しいビルドサーバーを買えるようにしたら？

F-Droidが実際にその命令セット拡張が登場する前のハードウェアで動いているのはかなり信じがたいね。最近は、そういうハードウェアが非常に稀になってきてるから、デフォルトで広く採用されてるんだよ。F-Droidがその命令をサポートしていないように設定されたVMを使ってるだけじゃないか、確かにそれはないの？

https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions#Late... 私の最後の、かなり古いデスクトップでもこれをサポートしてたし、ほぼ10年使ってから交換されたんだ。でも同時に、非アセンブリでのフォールバックパスも提供しないの？

└

でも同時に、非アセンブリでフォールバックパスすら提供しないの？ ここで問題になってるのは手書きのアセンブリじゃなくて、x86_64-v2をターゲットにしたコンパイラのことだと思う。RHEL 9やその派生版は、そういうオプションでビルドされてるし。（RHEL 10では最低スペックがx86_64-v3に引き上げられて、AVXが使えるようになった。）

└

問題を見てみると、彼らのビルダーはOpteron G3（K10？）みたいだね。[0] https://en.wikipedia.org/wiki/AMD_10h

└

フォールバックを提供する問題はテストだね。使える合理的なハードウェアがないから、全部古くて遅いって言ってる通りだよ。

どうやら、Googleが上流で修正したみたい？ https://gitlab.com/fdroid/admin/-/issues/593#note_2681207153 どれくらいで解決するかはわからないけど、そのスレッドは安心できる感じだね。直接的な修正のソースはないけど。

└

まだ解決してないよ。今のところ、ほとんどの開発者がこの根本的な問題に気づいてないみたい！

└

それは固定されていないよ。君がリンクしたスレッドでは、みんなが誤字修正（「mas fixed」を「was fixed」に）を、新しい問題が解決されたという主張と混同しているみたい。修正されたのは、数年前の似たような古い問題だよ。

Googleの新しいaapt2バイナリがAGP 8.12.0に含まれてる。F-Droidがビルド環境を隔離して保護することに重点を置いてるのに、上流のバイナリをそのまま使ってるのはちょっと驚きだな。ソースからビルドしないの？

└

関連して、今のところ最新の無料ソフトウェアビルドのAndroid SDKはないと思う。Androidアプリをビルドするには、みんなGoogleのバイナリに頼ってるけど、それは非無料なんだよね。https://forum.f-droid.org/t/call-for-help-making-free-softwa...

見る限り、sse4.1は2011年にCPUに導入されたみたい。もう10年以上前のことだね。なんでそんな古いサーバーがまだ使われてるのか不思議だ。現代のCPUなら、同じ作業をもっと少ないエネルギーでこなせると思うから、こんな古いハードウェアを使うのは経済的にも意味がないんじゃないかな。ビルドサーバーの数やスペックを知ってる人いる？

└

初期のx86_64マルチコアプロセッサの数世代以降のハードウェアは、ビルドファームに回すようなタスクでもサーバーとして使える十分な能力があるよ。

└

古いCPUの理由はCanoeboot/GNU Bootが使えるからだと思ったんだけど、KGPE-D16マザーボードにはSSE4.2 CPUを載せられるみたいだね。だから、よくわからん。

└

ここで疑ってる本当の答えは見たことないけど、ビルドサーバーはオープンファームウェアを動かすデュアルソケットのAMDボードなんじゃないかな。ME/PSPがないやつ。

└

これは2007年11月にIntel Penrynで導入されたんだ。でも、AMDのCPUはBulldozerまで実装しなかった、2011年の中頃までね。Bulldozerが提供する多くの追加命令、AVXやFMAも含めて、古いOpteron CPUはBulldozerベースのCPUよりも多くのアプリケーションでかなり速かったから、AMD Epycが2017年の中頃に出るまで、アップグレードするインセンティブはあまりなかったんだ。SSE 4.1は多くのソフトウェアパッケージが古いCPUをサポートする際の境界線になってる。古いCPUは、SIMD命令で並列化されたループ内の分岐計算（例えば、if ... else ...）に対して非常に高いオーバーヘッドがあるからね。

└

サーバー側では多分無理だけど、古いハードウェアは珍しくないし、特にデスクトップの分野では時間が経つにつれてますます一般的になると思う。2000年代に、古いデスクトップPCを持ってた時にこのシナリオに直面したことがある。10年くらい使ってたやつで、つまらない作業やランダムなブラウジングに使ってたけど、目的には全然問題なかった。時間が経つにつれて、SSEのバージョンで再ビルドされたプログラムが出てきたんだ。Firefoxが新しい命令セットに切り替えた時、完全に動いてたデスクトップPCを捨てざるを得なくなった。

└

サーバーのセットアップってめんどくさい作業だから、みんなできるだけ避けたがるよね。だから、AWSやAzure、Google Cloudの高いプランが儲かる理由もわかる。アプリケーションに集中していると、結構「うまくいく」んだけど、いざ高度なことをやろうとすると、難しいコマンドやクリックが裏目に出ることがあるんだよね。

└

現代のCPUは、古いハードウェアを使うよりもずっと少ないエネルギーで同じ量の作業をこなすと思うから、そんな古いハードを使うのは経済的にも意味がないよね。非うるう年には8,760時間あるし、アメリカの電気代は平均で1キロワット時あたり12.53セントだよね。500Wの電力をフル稼働させるようなすごく電力を消費するCPUを1年間使ったら、約550ドルの電気代がかかる計算になる。たとえ電力消費が半分になったとしても、それは新しいコンピュータのコストの約10%にしかならないから、アップグレードの元が取れるのは10年後ってことになるね（アップグレードの費用は無視できないし、リスクもあるし）。それに、新しいコンピュータを買うのは資本支出だけど、電気代は運営費用だからね。

よくわからないんだけど、gradleとaapt2ってオープンソースじゃないの？ buildrootやopenwrtをビルドするなら、まず自分のツールチェーンをコンパイルすることになるから、予測可能な結果が得られるんだよね。f-droidでも同じ理屈で、サポートされてない命令を使うバイナリのgradle/aapt2を使うより、ソースからツールチェーンを全部コンパイルした方が良くない？

└

Googleが提供するSDKバイナリはまだ使われています。詳しくは「https://forum.f-droid.org/t/call-for-help-making-free-softwa...」を見てね。

aapt2を正しいターゲットに再コンパイルするのはどう？ソースは公開されてるみたいだし。https://android.googlesource.com/platform/frameworks/base/+/...

└

AOSPを公開されているソースからビルドしてみたことある？バイナリがいっぱいあるよね。いくつかのソースを使って再ビルドしようとしたけど、あまりにも壊れちゃって無理だったわ。ほんと、ひどすぎる。

サーバーが古すぎて、全く別のアーキテクチャでx86_64をエミュレートしてもパフォーマンスが上がるくらいだよね。だから、OSSの議論はここにはないよ。タロスを買って、クローズドファームウェアがなくても、エミュレーションでパフォーマンスが上がるはずだし。ファームウェアにこだわらないなら、もっと安くて現代的なx86オプションがたくさんあるよ。

└

「彼らのサーバーはすごく古い」

これを読んだとき、ポップカルチャーのおかげで、こういう皮肉を期待しちゃうよね。「彼らのサーバーはすごく古い、幼稚園でベン・フランクリンの隣に座ってたんじゃない？」みたいな。