v2.1.2 reproducibility: native libraries in split_config.arm64_v8a differ from Play Store release

[xrviv]

Hi Bitkit team,

WalletScrutiny independently verifies that Bitcoin wallet apps on the Play Store can be reproduced
from their published source code. We attempted to reproduce the v2.1.2 Play Store release and found
that most of the app reproduces cleanly — but three native libraries in split_config.arm64_v8a.apk
differ between our local build and the official release.

Build method

./gradlew bundleMainnetRelease --no-build-cache --no-configuration-cache

• Tag: v2.1.2 (commit 5e71129)
• JDK: Zulu 17
• Android SDK build-tools: 36.0.0
• Split APKs extracted from built AAB using bundletool with device-spec: arm64-v8a, xxhdpi, SDK 36
• Official APKs sourced from Play Store

Findings

base.apk and split_config.xxhdpi.apk match the Play Store release (only expected signing and Play
Store injection artifacts differ).

split_config.arm64_v8a.apk has three differing native libraries:

lib/arm64-v8a/libbitkitcore.so *** differs ***
lib/arm64-v8a/libdatastore_shared_counter.so *** differs ***
lib/arm64-v8a/libjnidispatch.so *** differs ***

All other files in this split are explained by Play Store signing artifacts (META-INF/,
stamp-cert-sha256, com.android.vending.derived.apk.id in manifest).

Questions

1. Is libbitkitcore.so built from source during bundleMainnetRelease, or is it a pre-built
   artifact? If built, is the Rust/C++ build expected to be reproducible?
2. Are libdatastore_shared_counter.so and libjnidispatch.so pre-compiled AAR/JAR dependencies? If
   so, are they pinned to specific versions and hashes?
3. Do you have reproducible build instructions or a known-good build environment (Docker image, NDK
   version, Rust toolchain version) that produces byte-for-byte matching .so files?

Thanks for building an open-source Bitcoin wallet.

— WalletScrutiny