A brand-new install could stop connecting to Tor entirely. Not slowly —
permanently: exactly two bootstrap attempts, then silence. Reproduced on a
Samsung SM-T220 (benchmark build, fresh install, log in, 150s offline, network
back): Tor never reached Active in the following 600s, no profile, no relay
lists, "Feed is empty." With the fix, the same scenario recovers at net+51s.
Root cause: on a native bootstrap timeout `TorService.start()` deliberately
leaves status at Connecting and delegates the retry to `TorManager`'s watchdog,
but that watchdog was `status.transformLatest { if (Connecting) { delay(45s);
emit() } }` — it fires once per Connecting *span*, and a timeout produces no
status change, so no new span ever began and the signal was never re-armed.
Nothing else covered it: `onNetworkChange` fires only on a networkId *change*
and `AppModules` drops the first non-null one, so even a network arriving from
offline did not rescue it.
Lifecycle fixes:
- the watchdog re-arms while stuck instead of firing once per span;
- it skips an attempt that is genuinely running, so a reset can no longer
queue behind the blocking JNI call and tear down a client that just
succeeded;
- an install that has never bootstrapped retries on a 30s cooldown rather
than the 5-minute one meant to protect working state;
- `service.start()` is no longer awaited before `emitAll(service.status)`, so
the app observes Connecting when the attempt starts rather than when it
ends (on device the watchdog moved 105s -> 90s);
- a hard init failure and port exhaustion no longer set the terminal Off,
where neither the watchdog nor the failure dialog arms; both leave
Connecting to be retried. The init path also no longer wipes all Arti data
on any failure, which turned a transient "no network" into a lost guard
sample — with an escalation after 3 fruitless gentle resets so corrupt
state on a fresh install is still recovered.
Arti now bootstraps on demand. `create_bootstrapped` blocked the JNI call — and
the Kotlin lifecycle lock it holds — for the whole directory download (12.6s to
51.7s measured), during which `activePortOrNull` was null so every Tor-routed
dial fell back to 127.0.0.1:9050, the Orbot default, where nothing listens.
`create_unbootstrapped_async` + `BootstrapBehavior::OnDemand` returns in 124ms
and lets each stream wait for its own circuit. It does not make first paint
faster — the download is the real gate — but it removes the dead-port window
and the up-to-60s lock hold that also made "turn Tor off" appear frozen.
That forced a state split, and it is the load-bearing part. `Active` was
carrying two facts that used to coincide: "proxy routable" and "circuits
buildable". Android's `TorServiceStatus` gains `Bootstrapping(port)` plus
`socksPort` / `isFullyBootstrapped`, so callers state which they mean instead of
matching a variant that looks right for both. Commons gets the accessors only —
the desktop backend drives an external Tor and never sees the window, and a
variant nothing emits is dead weight.
Watchdogs are judged on forward progress, not elapsed time. Measured cold
downloads ran 12.6, 13.4, 14.0, 15.6, 17.9, 19.7, 19.8, 20.0, 34.4 and 51.7s on
one device and network, so no fixed patience separates slow from stalled: short
enough kills healthy downloads — and a reset discards the partial consensus, so
firing early can stop one ever finishing — while long enough sits uselessly on a
hang. A new `bootstrapProgressPermille()` exports `as_frac()`, and a download is
reset only after 60s with no movement at all, never with a state wipe. Device
run: a 51.7s download completed untouched where the previous code would have
reset and wiped its cache at 45s. `blocked()` is deliberately unused; Arti
documents it as best-effort and warns it misreports in both directions.
Readiness is read live (`bootstrap_status().ready_for_traffic()`) rather than
latching the one background `bootstrap()` result, which would report "not
bootstrapped" forever against a Tor that a later stream had already recovered.
`canDial` and `TorCircuitHealthTracker.isTorActive` gate on readiness, not
routability. Dialling on routability alone put ~190 relays into a backoff that
is never forgiven — the port is identical either side of Bootstrapping -> Active
so the transport never "changes" and `resetBackoff()` never runs — and it cost
nothing to wait: time-to-first-socket was unchanged by dialling early (n=3).
Both jniLibs ABIs rebuilt and verified reproducible from an upstream clone
(arm64 b53d20d2..., x86_64 36d41793...). `build-arti.sh`'s JNI symbol check
gained the new exports; it is a hardcoded list, and without them it silently
passed a stale .so.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BKYGEp22uGSzWrBDg8fAQ9
Arti Android Build Tools
Custom-built Arti (Tor in Rust) native libraries
for Amethyst Android. This replaces the Guardian Project's arti-mobile-ex AAR with a minimal
JNI wrapper built directly from Arti source.
Why custom build?
| Guardian Project AAR | Custom build | |
|---|---|---|
| Size | ~140MB | ~11MB |
| 16KB pages | No | Yes (NDK 25+) |
| Stop/restart | Broken (state file lock) | Works (TorClient persists, only SOCKS proxy stops) |
| Version | Behind | Pinned to latest (currently 1.9.0) |
Quick start
Pre-built .so files should be committed to amethyst/src/main/jniLibs/. You only need to
rebuild if you want to verify binaries, update the Arti version, or modify the JNI wrapper.
Reproducible builds
The shipped .so is built to be reproducible so anyone — F-Droid, Zapstore,
or an independent auditor — can rebuild it from this tag and confirm the
committed binary wasn't tampered with. Four things have to be fixed:
| Source of non-determinism | Pinned by |
|---|---|
rustc / cargo version |
rust-toolchain.toml (rustup auto-installs it) |
| transitive dependency versions | committed Cargo.lock; builds run cargo --locked |
| absolute paths embedded in the binary | --remap-path-prefix in repro-env.sh |
| codegen/link ordering keyed on the real build path | canonical build path (build-arti.sh builds in /tmp/amethyst-arti-build) |
repro-env.sh (sourced by both build scripts) also sets CARGO_INCREMENTAL=0
and a fixed SOURCE_DATE_EPOCH derived from the Arti tag. The size-optimized
release profile in Cargo.toml (lto, codegen-units = 1, strip,
panic = "abort") is itself deterministic for a fixed toolchain.
Why the canonical path matters. Verified empirically: with the toolchain, lockfile, and path-remapping all in place, two builds at the same path are byte-for-byte identical, but two builds at different paths still differ — not in any embedded string (no path leaks into the binary) but in the order rustc lays out functions/data, which it derives from the real on-disk artifact paths.
--remap-path-prefixonly rewrites embedded strings, not that internal ordering. Sobuild-arti.shalways compiles in a fixed location (/tmp/amethyst-arti-build, override withARTI_REPRO_DIR); F-Droid and any verifier must use the same path to get matching bytes. This is the standard way Rust libraries are reproduced (F-Droid builds Rust at a fixed path too).
Verify the committed binary reproduces
From tools/arti-build/, the helper builds twice from clean and diffs the output:
./verify-reproducible.sh # both ABIs (arm64-v8a + x86_64)
./verify-reproducible.sh --release # arm64-v8a only (faster)
It prints ✅ REPRODUCIBLE when two clean builds produce identical bytes, then
reports whether that matches the committed .so. Both builds compile in the
canonical /tmp/amethyst-arti-build, so the result is independent of where the
repo is checked out.
Prerequisites
-
Rust toolchain — the exact version is pinned in
rust-toolchain.toml; rustup installs it automatically. You only need rustup itself:curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -
Android targets
rustup target add aarch64-linux-android x86_64-linux-android -
cargo-ndk
cargo install cargo-ndk -
Android NDK 25+ (required for 16KB page size support)
# Via Android Studio: SDK Manager → SDK Tools → NDK (Side by side) # Or via command line: sdkmanager "ndk;27.0.12077973" # Set environment variable export ANDROID_NDK_HOME="$HOME/Android/Sdk/ndk/27.0.12077973"
Building
cd tools/arti-build
# Build for all targets (arm64 + x86_64)
./build-arti.sh
# Build arm64 only (for release APKs)
./build-arti.sh --release
# Clean rebuild from scratch
./build-arti.sh --clean
The script will:
- Clone official Arti source from
gitlab.torproject.org - Check out the version pinned in
ARTI_VERSION - Copy the JNI wrapper into the source tree
- Compile with
cargo-ndkfor each target architecture - Output
.sofiles toamethyst/src/main/jniLibs/{arm64-v8a,x86_64}/ - Verify JNI symbols are exported correctly
Output
amethyst/src/main/jniLibs/
├── arm64-v8a/
│ └── libarti_android.so (~5-6 MB)
└── x86_64/
└── libarti_android.so (~6-7 MB, emulator support)
Verifying 16KB page alignment
Google Play requires 16KB page-aligned native libraries. Verify with:
readelf -l amethyst/src/main/jniLibs/arm64-v8a/libarti_android.so | grep LOAD
The first LOAD segment alignment should be 0x4000 (16384 bytes).
Directory structure
tools/arti-build/
├── README.md # This file
├── ARTI_VERSION # Pinned Arti git tag (e.g., arti-v1.9.0)
├── rust-toolchain.toml # Pinned rustc version + Android targets (reproducibility)
├── Cargo.toml # Rust dependencies and build profile
├── Cargo.lock # Pinned transitive dependency versions (reproducibility)
├── repro-env.sh # Deterministic build env (path remapping, epoch) — sourced by both scripts
├── build-arti.sh # Build script (Android targets, shipped in APK)
├── build-arti-host.sh # Build script (host target, for JVM integration tests)
├── verify-reproducible.sh # Builds twice + diffs to prove byte-for-byte reproducibility
└── src/
└── lib.rs # JNI bridge (Rust → Kotlin)
# The Arti source is cloned into the canonical build path
# (/tmp/amethyst-arti-build/.arti-source), not under this dir — see
# "Reproducible builds" for why the build location is fixed.
Updating Arti version
-
Check available versions:
git ls-remote --tags https://gitlab.torproject.org/tpo/core/arti.git | grep 'arti-v' | tail -10 -
Update the version file:
echo "arti-v1.10.0" > ARTI_VERSION -
Update crate versions in
Cargo.tomlto match the new release. Check the crate versions at:https://gitlab.torproject.org/tpo/core/arti/-/raw/arti-v1.10.0/crates/arti-client/Cargo.toml -
Regenerate the committed lockfile so the new versions are pinned (builds run
--lockedand will fail until this is refreshed):./build-arti.sh --regen-lock # re-resolves + rewrites ./Cargo.lock, no compileIf you also bump the Rust toolchain, edit
channelinrust-toolchain.toml. -
Rebuild, then re-verify reproducibility (see "Reproducible builds" above) and commit the regenerated
.sofiles together withCargo.lock/rust-toolchain.toml:./build-arti.sh --clean
Architecture: JNI bridge
The Rust wrapper (src/lib.rs) exposes these JNI functions to Kotlin:
| JNI function | Kotlin | Purpose |
|---|---|---|
initialize(dataDir) |
ArtiNative.initialize() |
Create TorClient, bootstrap Tor network |
startSocksProxy(port) |
ArtiNative.startSocksProxy() |
Bind SOCKS5 listener on localhost |
stopSocksProxy() |
ArtiNative.stopSocksProxy() |
Abort listener, release port |
getVersion() |
ArtiNative.getVersion() |
Return Arti version string |
setLogCallback(cb) |
ArtiNative.setLogCallback() |
Register log callback |
Key design decisions
- TorClient is created once via
initialize()and persists for the app's lifetime. Its state file lock is tied to the object's lifetime and released only on GC/process exit. stopSocksProxy()only stops the TCP listener — it does NOT destroy the TorClient. This allows clean stop/start cycles without state file lock conflicts.- SOCKS5 is implemented in Rust using
tokio::net::TcpListener, not delegated to Arti's built-in proxy. This gives us full control over the listener lifecycle. - Bidirectional forwarding uses
tokio::io::copywithtokio::select!for efficiency.
Cargo.toml features
Default features are disabled (default-features = false) to minimize binary size.
| Feature | Purpose | Why included |
|---|---|---|
tokio |
Async runtime | Required by our SOCKS proxy |
rustls |
TLS via pure Rust | No OpenSSL dependency, smaller binary |
compression |
zstd/deflate relay traffic | Reduces bandwidth on Tor circuits |
onion-service-client |
Access .onion addresses | Amethyst routes .onion relay connections through Tor |
static-sqlite |
Bundled SQLite | Android native code can't use system SQLite |
Not included:
| Feature | Why excluded |
|---|---|
native-tls |
Using rustls instead (smaller, no system dependency) |
bridge-client |
Amethyst doesn't expose bridge configuration in UI yet. Add back if needed. |
pt-client |
Pluggable transports — same reason as bridges |
onion-service-service |
We only connect to .onion, we don't host them |
Release profile
[profile.release]
opt-level = "z" # Optimize for size
lto = true # Link-time optimization
codegen-units = 1 # Single codegen unit (smaller binary)
strip = true # Strip debug symbols
panic = "abort" # No unwinding (smaller binary)
Troubleshooting
cargo-ndk not found
cargo install cargo-ndk
NDK not found
export ANDROID_NDK_HOME="$HOME/Android/Sdk/ndk/<version>"
Rust targets not installed
rustup target add aarch64-linux-android x86_64-linux-android
Build fails with dependency errors
Try a clean build:
./build-arti.sh --clean
JNI symbols missing after build
The build script verifies symbols automatically. If verification fails, check that
src/lib.rs function names match the Kotlin package path:
Java_com_vitorpamplona_amethyst_ui_tor_ArtiNative_<methodName>