ci: add release workflows

[ovitrif]

Closes #1006
Related: #953
Supersedes: #867 (closed as outdated in favor of #953)

This PR:

1. Adds protected manual release workflows for signed mainnet store and internal artifacts.
2. Adds debug-only Firebase placeholders so fresh clones can build dev and testnet debug variants without private Firebase files.
3. Adds a WalletScrutiny-oriented manual reproducible release workflow, local reproduction script, and documentation.

Caution

If you already have a private debug Firebase config at app/google-services.json, move it before checking out this PR or pulling master after this PR merges:

mkdir -p app/src/debug
mv app/google-services.json app/src/debug/google-services.json

app/google-services.json is now the tracked placeholder for fresh clones. Keep app/src/mainnetRelease/google-services.json unchanged for release builds.

Description

The core change is adding protected manual release and release-internal GitHub Actions workflows. Both workflows build signed mainnet release artifacts from protected environment secrets. release keeps both APK and AAB outputs for Play/GitHub release handling, while release-internal produces the mainnet APK signed with the internal keystore. These workflows do not run automatically on pushed tags; /release remains the release-process orchestrator until it is deliberately updated to consume workflow-produced artifacts.

The reproducibility support adds a manual Reproducible Release workflow and scripts/reproduce-release.sh to build bundleMainnetRelease, recreate APK splits with bundletool, extract arm64-v8a native libraries, and upload checksum evidence. When a comparison artifact is provided, diffoscope differences now fail the workflow while still uploading the generated report.

GitHub Actions setup:

• Created the release and release-internal GitHub environments for the protected release workflows.
• Configured the required release environment secrets:
  • MAINNET_RELEASE_GOOGLE_SERVICES_JSON_BASE64,
  • BITKIT_KEYSTORE_BASE64,
  • BITKIT_KEYSTORE_PASSWORD,
  • BITKIT_KEY_ALIAS, and
  • BITKIT_KEY_PASSWORD.
• Configured the required release-internal environment secrets:
  • MAINNET_RELEASE_GOOGLE_SERVICES_JSON_BASE64,
  • INTERNAL_KEYSTORE_BASE64,
  • INTERNAL_KEYSTORE_PASSWORD,
  • INTERNAL_KEY_ALIAS, and
  • INTERNAL_KEY_PASSWORD.
• GPR_USER and GPR_TOKEN remain optional fallback secrets; the workflows prefer the built-in GitHub Actions token with packages: read.

Remaining upstream work for #953:

• Update /release so it can trigger/download the release workflow artifacts instead of relying on local APK creation.
• Make bitkit-core-android / Rust-native AAR builds reproducible upstream.
• Pin Rust toolchain, Android NDK, Cargo.lock, build paths, SOURCE_DATE_EPOCH, path remapping, stripping, and published native .so checksums.
• Continue investigating third-party native outputs from androidx.datastore:datastore-core and net.java.dev.jna:jna with diffoscope evidence.

Preview

N/A

QA Notes

Manual Tests

• 1. 2026-05-25 → Firebase config setup: confirmed real debug Firebase config belongs in the ignored shared debug path (app/src/debug/google-services.json) so one file can override the checked-in app/google-services.json placeholder without dirtying Git; app/src/mainnetRelease/google-services.json remains the release-only path.
• 2. 2026-05-25 → Release workflow review: confirmed store release keeps APK + AAB outputs, internal release keeps APK output, and both run post-build signature verification before artifact upload.

Automated Checks

• bash -n scripts/reproduce-release.sh
• YAML parse for .github/workflows/release.yml, .github/workflows/release-internal.yml, and .github/workflows/reproducible-release.yml
• YAML parse for all workflows after moving debug Firebase secrets to the shared app/src/debug/google-services.json path while keeping release secrets at app/src/mainnetRelease/google-services.json
• bash -n for the release signature verification shell blocks
• git diff --check
• git check-ignore -v app/src/debug/google-services.json app/src/mainnetRelease/google-services.json
• Google Services plugin lookup order inspected from local 4.4.4 sources: src/debug/google-services.json resolves before the checked-in root app/google-services.json placeholder, while src/mainnetRelease/google-services.json remains the release override. The root placeholder intentionally omits the production to.bitkit client.
• go run github.com/rhysd/actionlint/cmd/actionlint@latest .github/workflows/reproducible-release.yml .github/workflows/release.yml .github/workflows/release-internal.yml
• GitHub checks on 4aa52470d: lint and detekt passed; build/E2E jobs were skipped while the PR was draft.
• Workflow behavior must be verified in GitHub Actions (after merge).

[ovitrif]

• Created the release and release-internal GitHub environments for the protected release workflows.
• Required release environment secrets:
  - MAINNET_RELEASE_GOOGLE_SERVICES_JSON_BASE64,
  - BITKIT_KEYSTORE_BASE64,
  - BITKIT_KEYSTORE_PASSWORD,
  - BITKIT_KEY_ALIAS, and
  - BITKIT_KEY_PASSWORD.
• Required release-internal environment secrets:
  - MAINNET_RELEASE_GOOGLE_SERVICES_JSON_BASE64,
  - INTERNAL_KEYSTORE_BASE64,
  - INTERNAL_KEYSTORE_PASSWORD,
  - INTERNAL_KEY_ALIAS, and
  - INTERNAL_KEY_PASSWORD.

These will be added AFTER the PR is approved.

Environments are now configured with the secrets enumerated above (excerpt from PR description)

Sample view of release repo environment:

We don't need GPR_USER and GPR_TOKEN, verified locally with:

GPR_USER='ovitrif' \
GPR_TOKEN='***' \
./gradlew compileDevDebugKotlin --refresh-dependencies --no-daemon

To honour the JVM settings for this build a single-use Daemon process will be forked. For more on this, please refer to https://docs.gradle.org/8.13/userguide/gradle_daemon.html#sec:disabling_the_daemon in the Gradle documentation.
Daemon JVM discovery is an incubating feature.
Daemon will be stopped at the end of the build 

> Task :app:compileDevDebugKotlin
w: ATTENTION!
This build uses unsafe internal compiler arguments:

-XXLanguage:+PropertyParamAnnotationDefaultTargetMode

This mode is not recommended for production use,
as no stability/compatibility guarantees are given on
compiler or generated code. Use it at your own risk!

w: file:///Volumes/ssd/r/synonym/bitkit-android-3/app/src/main/java/to/bitkit/models/PubkyProfile.kt:88:13 Redundant creation of Json format. Creating instances for each usage can be slow.
w: file:///Volumes/ssd/r/synonym/bitkit-android-3/app/src/main/java/to/bitkit/ui/screens/trezor/TrezorScreen.kt:93:34 'fun <reified VM : ViewModel> hiltViewModel(viewModelStoreOwner: ViewModelStoreOwner = ..., key: String? = ...): VM' is deprecated. Moved to package: androidx.hilt.lifecycle.viewmodel.compose.

BUILD SUCCESSFUL in 3m 34s
21 actionable tasks: 13 executed, 8 from cache

[piotr-iohk]

Not clear about the reproducible-release.yml. Also I think that /release command and process should be adjusted such that it takes into account release.yml producing release artifacts. Please see individual comments.

can't signal it was addressed by re-requesting review on the "changes requested" alert.

[jvsena42]

Local test: is the now-blocking diffoscope comparison safe?

Since the diffoscope compare is now blocking, I checked locally whether two honest builds with the same keystore yield byte-identical signed APKs, or whether signature non-determinism could cause false failures.

This only needs to exercise the script's signing path (bundletool build-apks + apksigner), so no Gradle build / GPR creds / Firebase config required — just an existing mainnetRelease AAB intermediate and a throwaway keystore.

Setup

WORK=.ai/repro-det-test; mkdir -p "$WORK"
# any mainnetRelease bundle works; I reused the on-disk intermediate
cp app/build/intermediates/intermediary_bundle/mainnetRelease/packageMainnetReleaseBundle/intermediary-bundle.aab \
   "$WORK/bitkit-mainnet-release-999.aab"
export BUNDLETOOL_JAR="$PWD/$WORK/bundletool.jar"   # shared across runs

keytool -genkeypair -keystore "$WORK/rsa.keystore" -storepass test1234 -keypass test1234 \
  -alias testkey -keyalg RSA -keysize 2048 -validity 30 -dname "CN=test, O=test, C=US"
keytool -genkeypair -keystore "$WORK/ec.keystore"  -storepass test1234 -keypass test1234 \
  -alias testkey -keyalg EC -groupname secp256r1 -validity 30 -dname "CN=test, O=test, C=US"

Test A — run reproduce-release.sh twice with the same RSA key, compare checksums

export SKIP_GRADLE_BUILD=true
export AAB_PATH="$PWD/$WORK/bitkit-mainnet-release-999.aab"
export KEYSTORE_FILE="$PWD/$WORK/rsa.keystore" KEYSTORE_PASSWORD=test1234 KEY_ALIAS=testkey KEY_PASSWORD=test1234

OUTPUT_DIR="$WORK/rsa-run1" scripts/reproduce-release.sh
OUTPUT_DIR="$WORK/rsa-run2" scripts/reproduce-release.sh
diff "$WORK/rsa-run1/checksums/extracted-apks.sha256" "$WORK/rsa-run2/checksums/extracted-apks.sha256"
# -> no diff: byte-identical extracted APKs across runs ✅

Test B — sign the same APK twice with apksigner (v2/v3), RSA vs EC

APKSIGNER=$ANDROID_HOME/build-tools/36.0.0/apksigner
base=$(find "$WORK/rsa-run1/extracted-apks" -name '*.apk' | head -1)
for alg in rsa ec; do
  for f in a b; do
    cp "$base" "$WORK/$alg-$f.apk"
    "$APKSIGNER" sign --ks "$WORK/$alg.keystore" --ks-pass pass:test1234 --key-pass pass:test1234 \
      --ks-key-alias testkey --v1-signing-enabled false --v2-signing-enabled true \
      --v3-signing-enabled true --min-sdk-version 24 "$WORK/$alg-$f.apk"
  done
  echo "$alg:"; shasum -a 256 "$WORK/$alg-a.apk" "$WORK/$alg-b.apk"
done

Results

Test	Key	Outcome
A — script ×2, same key	RSA 2048	extracted-apks.sha256 byte-identical ✅
B — apksigner ×2, same key	RSA 2048	both signatures identical ✅
B — apksigner ×2, same key	EC secp256r1	hashes differ ❌ (ECDSA random nonce)

Conclusion

The blocking diffoscope step is safe iff the release/internal keystores use RSA keys (RSA PKCS#1 v1.5 signatures are deterministic → two honest builds are byte-identical). This is the common case for Android signing keys. With an ECDSA key the signature block is non-deterministic and would cause false reproducibility failures.

Side note: bundletool build-apks --mode=default actually rejects an EC key outright (ECDSA signatures only supported for minSdkVersion 18 and higher, because v1/JAR signing is enabled without a minSdk), so an EC release key would break the workflow regardless.

So this reduces to confirming the key algorithm once:

keytool -list -v -keystore <release.keystore> -alias <alias> | grep -i 'Signature algorithm'

[ovitrif]

@jvsena42 @ben-kaufman wdyt of splitting this into 2:

1. for release workflows (stays here)
2. for reproducibility

I keep seeing it is getting dragged by reproducibility concerns, while release workflow could've been already useful for building 2.3.0 artifacts.