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

Aperta Adatta ai principianti
  • Qualcosa non va?
#8,789 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@mrober ci sta già lavorando.

Dal 6/11/2026.

  • #8801 di @Nikhila-Dhevi-R — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
android, java
Ambito
build-system, mobile

Direzione di ricerca

Inizia da BuildIdInfoCollector.collect() in firebase-crashlytics-buildtools, dove il ciclo su FileUtils.listFiles() aggiunge righe BuildIdInfo, e verifica come le liste del nome della libreria, dell'architettura e del build ID vengono derivate da quell'unica lista. Aggiungi un ordinamento deterministico alla fine di collect() usando i campi proposti nell'issue, e verifica l'output con un test unitario che fornisca i file in ordine casuale. È completato quando gli stessi input producono sempre lo stesso ordine delle righe e le tre liste restano associate.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
2.6k
Fork
733
Merge medio
2g 15h
PR unite (30g)
72

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di firebase/firebase-android-sdk

Tutte le issue di firebase/firebase-android-sdk

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.