Crashlytics plugin writes build ID lists in directory listing order, so APKs can differ between machines

オープン 初心者向け
  • 何か問題がありますか？
#8,789 コメント 1 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@mrober がすでに取り組んでいます。

2026年11月6日 から。

  • #8801 @Nikhila-Dhevi-R による — オープン

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
72/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
android, java
領域
build-system, mobile

調査の方向性

firebase-crashlytics-buildtools の BuildIdInfoCollector.collect() から始めてください。そこでは FileUtils.listFiles() をループして BuildIdInfo の行を追加しています。ライブラリ名、アーキテクチャ、ビルド ID のリストがこの 1 つのリストからどのように導出されているかを確認してください。issue で提案されたフィールドを使い、collect() の最後に決定的なソートを追加し、ファイルをシャッフルした順序で渡す単体テストで出力を確認してください。同じ入力が常に同じ行順を生成し、3 つのリストの対応関係が保たれていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

api: crashlytics
[REQUIRED] Step 2: Describe your environment
  • Android Studio version: not used; command-line build with Gradle 9.3.1, AGP 9.1.1 and JDK 21
  • Firebase Component: Crashlytics Gradle plugin
  • Component version: 3.0.8
[REQUIRED] Step 3: Describe the problem

When nativeSymbolUploadEnabled is on, the plugin writes three lists into the app's resources:
com.google.firebase.crashlytics.build_ids_lib, _arch and _build_id.

The rows follow directory listing order and are not sorted. So the same source can produce a different
resources.arsc, which breaks reproducible builds. We verify open source Bitcoin wallets at WalletScrutiny,
and this is how we found it.

BuildIdInfoCollector.collect() loops over FileUtils.listFiles()
and adds rows in that order. That helper
does not sort either.

Steps to reproduce:
  1. Use an app with native libraries, and set nativeSymbolUploadEnabled true.
  2. Build it normally, and keep com_google_firebase_crashlytics_build_ids.xml.
  3. Mount the source with disorderfs --shuffle-dirents=yes --reverse-dirents=no --sort-dirents=no <source> <mount>.
  4. Build the same commit inside the mount.
  5. Compare the two files. The rows match, but their order differs.

We ran these builds with P.CASH 0.60.1, commit ab67f8e649, on one host:

Build List order
Normal, first same as second
Normal, second same as first
Under disorderfs shuffle different

The shuffled build still had the same 80 rows. After sorting them, the only decoded difference left was the
random mapping_file_id (#2570). Two of the three APK splits stayed byte-identical.

We also compared the developer's official builds with ours:

Release Official file Commit Rows Changed list lines
0.60.1 Google Play base.apk ab67f8e649 80 262
1.0.260 GitHub -google APK 596bf08522 74 246

Each pair has the same rows once sorted.

Limits of our testing:

  • We ran one shuffled build.
  • We did not build on two machines of our own.
  • We have no minimal sample project.

Expected: the same source gives the same list order, whatever the directory listing order is.

Relevant Code:

Part of the 0.60.1 diff (official <, ours >):

<         <item>libjnidispatch.so</item>
<         <item>libgojni.so</item>
<         <item>libcrashlytics-common.so</item>
>         <item>libc++_shared.so</item>
>         <item>libimage_processing_util_jni.so</item>
>         <item>libsecp256k1-jni.so</item>

A possible fix, at the end of collect(), which we have not compiled or tested:

buildIdInfoList.sort(
    Comparator.comparing(BuildIdInfo::getLibraryName)
        .thenComparing(BuildIdInfo::getArch)
        .thenComparing(BuildIdInfo::getBuildId));

All three lists come from this one list, so the rows should stay paired.

Related: #2570 covers the random mapping_file_id. This issue is only about list order.

主要言語
Java
スター
2.6k
フォーク
733
平均マージ
2日 15時間
マージ済み PR（30日）
72

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

firebase/firebase-android-sdk のほかの issue

firebase/firebase-android-sdk の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。