Android reproducible build instructions for Play Store release (WalletScrutiny verification)

Hello Leather team, and thank you for open-sourcing the mobile wallet. We are reviewing **Leather Android (`io.leather.mobilewallet`)** as part of the reproducible-build verification work at **WalletScrutiny.com**, where our goal is to independently rebuild wallet apps from source and compare them against the exact artifacts distributed via Google Play. After reviewing `apps/mobile/README.md`, we see that the current documentation is sufficient for **development and emulator testing**, but it does not yet provide the information required to reproduce the **Play Store release artifact** in a verifiable way. Specifically, could you please clarify the following: 1. **Source ↔ Play release mapping** - Which **git tag or commit** corresponds to a given Play Store `versionName` / `versionCode`? - Are Play releases built from a protected branch (e.g. `main`) or specific tags? 2. **Release build process (Android)** - What is the **exact command** used to produce the Play Store Android build (APK/AAB)? - Is the Play release built via **EAS Build**, Gradle directly, or another pipeline? - If EAS is used, which **`eas.json` profile** corresponds to the Play release? 3. **Toolchain pinning** - Which versions are used for: - Node.js - pnpm - Java - Android SDK / Build Tools - Android Gradle Plugin / Gradle - Are these versions fixed for releases, or derived dynamically in CI? 4. **Environment variables** - Which `.env` variables are required for a **release build**? - Do any environment variables affect compiled output (feature flags, analytics IDs, endpoints), or are they runtime-only? 5. **Expected non-determinism** - Are there known, expected differences when rebuilding locally (e.g. asset ordering, timestamps, Hermes bytecode, native build IDs)? - If so, do you have guidance on what differences should be considered acceptable vs unexpected? Our intent is **not** to criticize the current setup, but to determine whether Leather Android can be classified as: - fully reproducible, - functionally reproducible, or - source-available but non-verifiable, using the same methodology applied consistently across wallets. We would be very happy to link to any existing internal documentation, CI config, or future plans around reproducible builds, and to reflect your answers accurately on WalletScrutiny. Thank you for your time, and for supporting transparency in the Bitcoin wallet ecosystem. — Daniel Garcia (dannybuntu) WalletScrutiny.com verification team