Reproducible Builds

[IzzySoft]

I'm just trying to set up verification of Reproducible Builds for Amaze, but I got stuck – I guess due to missing details. Build currently fails with:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':file_operations:cargoBuildArm'.
> Process 'command 'cargo'' finished with non-zero exit value 101

The build recipe used (running in a Podman container with Debian bookworm, OpenJDK 17, and NDK 28.2.13676358 (aka 28c)):

build:
  - sed -r '/signingConfigs.release/d' -i app/build.gradle
  - RUST_TOOLCHAIN="1.92.0"
  - RUSTUP_VERSION="1.28.2"
  - git clone https://github.com/rust-lang/rustup.git -b $RUSTUP_VERSION
  - export ANDROID_NDK=/opt/sdk/ndk/${PROVISIONING_NDK}
  - ${BUILD_REPO_DIR}/rustup/rustup-init.sh -y --default-toolchain=$RUST_TOOLCHAIN --target armv7-linux-androideabi --target aarch64-linux-android --target i686-linux-android --target x86_64-linux-android
  - source $HOME/.cargo/env
  - pushd file_operations
  - chmod +x setup_rust_android.sh
  - ./setup_rust_android.sh
  - rustup target list --installed | grep android || { echo "No Android targets found"; exit 1; }
  - if ! test -f .cargo/config.toml; then
  - echo "❌ .cargo/config.toml missing"
  - exit 1
  - fi
  - popd
  - chmod +x gradlew
  - ./gradlew assembleFdroidRelease

For several things I had to make assumptions, as your repo doesn't state (or I didn't find it), e.g. the Rust toolchain and Rustup versions used (other projects have that in some toolchains.toml). I also don't (yet) know the build path, which will be important here for RB to succeed.

Can you please give me some pointers? Thanks in advance!

[EmmanuelMess]

Fdroid's reproducibility report marks it as correct, maybe that is useful? Here is the Cargo.toml.

Here are some rust details from the CI:

rustc 1.92.0 (ded5c06cf 2025-12-08)
binary: rustc
commit-hash: ded5c06cf21d2b93bffd5d884aa6e96934ee4234
commit-date: 2025-12-08
host: x86_64-unknown-linux-gnu
release: 1.92.0
LLVM version: 21.1.3

And:

 📋 Configuration summary:
  - OS Platform: linux-x86_64
  - Android SDK: /usr/local/lib/android/sdk
  - NDK Version: 29.0.14206865
  - API Level: 21
  - Config file: .cargo/config.toml

ping @TranceLove.

[IzzySoft]

Fdroid's reproducibility report marks it as correct, maybe that is useful?

@EmmanuelMess funny, as the app is not established as RB at F-Droid (at least not according to the app's metadata there) – so the status there can only mean that they got the same/identical APK their own builder produced in the first run, at a second run on their own verification builder. But yes, you are correct: it means at least that they were able to build, even twice. While for us, the build fails.

They use the same toolchain as we did in the above recipe, just an older Rustup (still 1.27.1; I could try that of course, but that would IMO not explain why our build fails – nor does the target, which is identical to ours). Moreover, they use NDK 28.2.13676358, as do we – but you say it should be 29.0.14206865 (but then, your specs are for 4.0, while we're trying 3.11.2 here). Translating the F-Droid build recipe to the syntax of the build recipe above, so we can compare:

      - sed -i -e '/jcenter/d' -e '/liferay/d' {..,.}/build.gradle
      - RUST_TOOLCHAIN="1.92.0"
      - RUSTUP_VERSION="1.27.1"
      - git clone https://github.com/rust-lang/rustup.git -b $RUSTUP_VERSION
      - ${BUILD_REPO_DIR}/rustup/rustup-init.sh -y --default-toolchain $RUST_TOOLCHAIN --target armv7-linux-androideabi aarch64-linux-android i686-linux-android x86_64-linux-android
      - source $HOME/.cargo/env
      - sed -i -e "/cargoCommand/s|\"cargo\"|\"$(which cargo)\"|" -e "/rustcCommand/s|\"rustc\"|\"$(which rustc)\"|" ../file_operations/build.gradle
      - ./gradlew assembleFdroidRelease

So that just skips the ./setup_rust_android.sh step your Github action suggests to be needed (which mostly checks the requirements, installs the Rust targets, and creates the .cargo/config.toml – if that's really requirements, I wonder how the F-Droid build works without), plus the checks whether Rust is correctly set up. The sed before the ./gradlew call is IMHO superfluous, as sourcing $HOME/.cargo/env takes care for updating the PATH accordingly (works fine for our other Rust recipes) – but is the only thing left that could be the culprit. But before making "wild guesses and tries", I'd rather wait for what instructions you might give.

Re JCenter: as that has shut down last year, I guess it's safe to remove it from your build.gradle files. No idea about the liferay one.

Here is the Cargo.toml.

Not the one I meant. I meant a TOML that gives the required versions of Rustup, Toolchain, etc. For comparison, see e.g. this tools.versions.toml.

[TranceLove]

Not the one I meant. I meant a TOML that gives the required versions of Rustup, Toolchain, etc. For comparison, see e.g. this tools.versions.toml.

Sounds fair. Let me take a look at this, along with the repo cleanup things.

And BTW: shall we use dependabot?

[TranceLove]

OK, I must confess I didn't take account of how F-Droid builds are done.

For the missing Cargo.toml, we do have documentation detailing setup of the environment, including generating the Cargo.toml.

Github Actions also included the steps as well.
https://github.com/TeamAmaze/AmazeFileManager/blob/release/4.0/.github/workflows/android-main.yml#L64-L80

I may make the setup_rust_android.sh step automated using Gradle scripts, but honestly one cannot control the rust toolchain versions easily - perhaps that's why florisboard you took reference from use Docker to build the Rust library instead.

[IzzySoft]

Having it automated in a script that is run during build is best – because any changes you need to make over time, would automatically be applied at our builders as well. With ~800 apps in our builder repo, we already have more than enough to do dealing with failed RBs for all kind of reasons. Having to dig through rather complex setup instructions to find out what might have changed, is nothing we could afford there (we simply do not have the resources for that).

I'm not familiar enough with Rust to tell about the difficulties on choosing the toolchain – or what makes that more complex than, say, choosing the Flutter version with a Flutter project. Isn't that a choice you make? Or what decides on that? And whatever decides, can't that write the results in some TOML file? Forgive my ignorance there, I simply don't know.