Skip to content

Establish an App for RB

Apart from you who develops your app following the hints on reproducible builds , is there anything we who run the builders would need to know to establish your app as RB? That often depends on what you use to develop your app. Most Java and Kotlin apps are easy to handle without specific hints. But with other frameworks, it's a little different. If you host your code at Github and use their CI to build your app, we can get most details from your .github/workflows/*.yml files. But if or not, here are some specifics:

General

In general, if there are any specific build requirements (packages needed, specific commands to be run, etc) we of course need to know them. Having a document with build instructions available in your app's repo is always welcome! Helpful information here also includes:

  • JDK used.
    We support the LTS versions of OpenJDK – i.e. OpenJDK 11, 17, 21. Please don't use non-LTS versions for „production builds“: experience shows they are prone to cause problems with Reproducible Builds. For example, some features introduced with OpenJDK 18/19 were no longer present with 21. Further, those non-LTS versions are usually not available via the standard repositories of Linux distributions used with our builders.
    Please avoid using JBR (Jetbrains JDK), as this very often causes issues with RB. When using Github workflows, temurin was found the most „stable“ variant of OpenJDK. Often, zulu worked as well.
  • The OS you are building on.
    This often helps to narrow down potential issues. For example, Fedora 21 replaced zlib with zlib-ng by default, causing issues with different compression.
  • Number of CPU cores on your build machine.
    Luckily, this we rarely need to know. But there is a known bug in the build tools where this detail helps to work around it.

Knowing these things in advance can help reducing the number of try-and-err loops.

Flutter

With Flutter apps it's important to know which Flutter version you were using when building your app. You can ensure we both use the same version by integrating Flutter as a git submodule: a git submodule always points to a specific commit – so it's „glued“ to that commit until you update it. Another possibility is to point it out in your pubspec.yaml file:

environment:
  sdk: '>=3.2.1 <4.0.0'
  flutter: ^3.24.5

In this case you should make sure it always reflects what you are using. Using a git submodule takes care for that automatically, provided you commit your changes properly.

In addition to that, we need to know the path you build from, as Flutter embeds path information into its libraries. Using Github workflows, this is easy: your home directory then is /home/runner, and your repo directory is /home/runner/work/<repoName>/<repoName> (so if your repo is github.com/johndoe/jane, the repo dir is /home/runner/work/jane/jane). Which, on a side-note, means we are pretty unlikely to establish RB for your app if you build it on a Windows machine, sorry…

Rust

Quite similar to Flutter, we need to know the exact versions of rustup and the Rust toolchain used. And the build directory, as Rust, too, embeds paths into its libraries (so again: if you build on Windows, we cannot match those, and thus cannot establish reproducible builds for your app). In addition to that, we will also need to know the exact NDK version you are using (e.g. 27.2.12479018). See e.g. here on how those details can be provided so changes can be picked up by our builders automatically.

Javascript

There are several frameworks utilizing NodeJS. We generally try to use the latest stable version of NodeJS – but depending how your project is set up, there are special commands needed at specific steps. Like npm install -g yarn and the specific yarn commands to run, or specific npm commands. As pointed out at the top of this document: a document with build instructions can never hurt!

The build recipe

Of course, if you've already set up your own verification builder and have a ready-to-use recipe to share, each builder operator will probably happily accept it and add it to their recipe collection. You can also reach out to them for assistance, especially if your app is already available in the IzzyOnDroid repo – in which case we happily assist you establishing Reproducible Builds for your app.