v0.8.0

Feature release: mesh names can be pulled from a node you run with fips-ui. Installs in place over any earlier release via the automatic update prompt, Check for updates, or sideload — identity, settings and app data are kept.

Changes since v0.7.0

• Sync mesh names from a fips-ui node (Overview → Mesh names → Sync from another node, off by default). The phone joins fips-ui's own name-sync scheme as a follower: it fetches the other node's name list over the mesh and keeps it next to your own names, so every mesh app can use the same name.fips names as the rest of your nodes.
  • Setup: on the fips-ui node, enable Access → Web UI over the mesh and add this phone's npub (Overview) as a viewer; on the phone, enter that node's npub — or a name you already gave it — plus its UI port (default 8321).
  • When: hourly by default and on Sync now, only while connected; a reconnect resumes the schedule rather than fetching again. (fips-ui's own default is every 5 minutes — too many wake-ups for a phone.)
  • What it changes: your own names stay as they are; a synced name wins over one of yours with the same name (marked overridden by sync). Invalid entries are skipped, at most 2000 are taken, and the names synced last stay in effect while the other node is unreachable (retries then drop to once a day; Sync now always tries at once). Turning sync off removes the synced names.
  • The other node lists the phone among the nodes syncing from it.
  • If the phone is not on the node's viewer list, fips-ui drops its connection silently, so the error is a timeout that points at the viewer list — not a "refused".
• Overview's mesh-names line and the Diagnostics probe also resolve synced names.

Under the hood: the app's own traffic sits outside its VPN whenever mesh apps are selected, so the fetch is made inside the embedded node by a small userspace TCP client (new dependency smoltcp, 0BSD; THIRD-PARTY-NOTICES.md lists it and its five dependencies). The embedded fips daemon is unchanged (android-hooks @ f4a811e).

Known issues

• After the mesh reconnects itself — a mesh-app or relay change, a !FIPS hotspot joining or leaving, an IPv6 route change — the link to a peer can take ~15 s to come back even though Overview already shows Connected. Under investigation; seen since 0.5.0.
• Peers listed in Diagnostics still show npubs, not the mesh names you gave them.

Install

Sideload the APK matching your device (adb install -r or open it on the phone); min SDK 26 (Android 8.0). Verify the download against the matching .sha256, or update from within the app.

• universal — all three ABIs in one file. Installs anywhere; larger. Use this if unsure.
• arm64-v8a — every 64-bit ARM phone from roughly 2016 on.
• armeabi-v7a — old 32-bit phones. Compiles and packages; not exercised on real 32-bit hardware.
• x86_64 — Android emulator, Chromebooks.

Release APKs are signed with the key whose certificate SHA-256 is
aa905e32bd0058874d252990abba26c78ddd8fca018195ebd1cd232a99a7a8e1 — check a
fresh download with apksigner verify --print-certs <apk>. This matters most on a
first install: there is no previously installed signature for Android to
compare against, so the checksum and this fingerprint are the only things
identifying a genuine build. Subsequent updates are enforced against the key
automatically.

Caveats

This release's arm64 APK was installed in place over 0.7.0 on a Pixel 9 Pro and works as expected (checked after publishing). The name sync was verified beforehand on the Android 14 emulator (x86_64, debug build) against a workstation running fips-ui 0.8.0: names synced as a viewer, an unlisted device got the viewer-list hint, a sync interrupted by a mesh restart retried after 30 s instead of backing off, and turning sync off removed the synced names. armeabi-v7a compiles and packages but has not been run on a 32-bit device.

v0.7.0

Feature release: three links into the mesh instead of one, and Nostr peer discovery as an opt-in. Installs in place over any earlier release via the automatic update prompt, Check for updates, or sideload — identity, settings and app data are kept.

Changes since v0.6.1

• Fallback bootstrap peers (Settings → Bootstrap peer, on by default). The node used to have exactly one link — the bootstrap server you picked — and everything else was routed through it, so that server going down meant no mesh until it came back. It now also peers with two more public servers in other regions (test-uk01 and test-us01 alongside the default test-de01), so one outage does not take the mesh with it. Each extra link is one short heartbeat every 20 seconds (10 with Battery saver off).
• Configured peers are re-found through Nostr. Every configured peer now carries via_nostr: its static address is dialed first, and the endpoints it advertises on the relays are appended as fallback, so a bootstrap that moves to a new address is found again without a settings change.
• Discover peers via Nostr (Settings → Connectivity, off by default). Turns on fips's open discovery — linking to nodes that announce themselves on the relays, not only the bootstraps — but capped at three such links, freshest announcements first, through a new fips knob written for this (open_discovery_max_peers: a ceiling on the discovered pool as a whole, where fips's own setting only bounded the queue and a phone would have gone on collecting links up to 128). Honest caveat, also on the Settings page: on the public test mesh most announcements are from nodes that no longer answer an offer, so expect fewer than three — in the maintainer's runs on an emulator and a Pixel, the cap held and none of the three picks answered. It stays off by default for that reason.

The embedded fips daemon moves to android-hooks @ f4a811e (the discovery ceiling and the address-family fix from 0.6.1). No dependency changed; THIRD-PARTY-NOTICES.md is unchanged.

Known issues

• After the mesh reconnects itself — a mesh-app or relay change, a !FIPS hotspot joining or leaving, an IPv6 route change — the link to a peer can take ~15 s to come back even though Overview already shows Connected. Under investigation; seen since 0.5.0.
• Peers listed in Diagnostics still show npubs, not the mesh names you gave them.

Install

Sideload the APK matching your device (adb install -r or open it on the phone); min SDK 26 (Android 8.0). Verify the download against the matching .sha256, or update from within the app.

• universal — all three ABIs in one file. Installs anywhere; larger. Use this if unsure.
• arm64-v8a — every 64-bit ARM phone from roughly 2016 on; the device-verified build.
• armeabi-v7a — old 32-bit phones. Compiles and packages; not exercised on real 32-bit hardware.
• x86_64 — Android emulator, Chromebooks.

Release APKs are signed with the key whose certificate SHA-256 is
aa905e32bd0058874d252990abba26c78ddd8fca018195ebd1cd232a99a7a8e1 — check a
fresh download with apksigner verify --print-certs <apk>. This matters most on a
first install: there is no previously installed signature for Android to
compare against, so the checksum and this fingerprint are the only things
identifying a genuine build. Subsequent updates are enforced against the key
automatically.

Caveats

Only arm64-v8a is exercised on real hardware. This release's arm64 APK was installed in place over the previous build on a Pixel 9 Pro (Android 17) and connected with the three bootstrap links as designed. The discovery toggle was exercised on the same phone on a pre-review build of the same change: it held its cap of three while none of the picked nodes answered; the two changes since (a bookkeeping fix in the daemon, text and constant changes in the app) are covered by tests and were checked on the Android 14 emulator. armeabi-v7a compiles and packages but has not been run on a 32-bit device; x86_64 is emulator-verified.

v0.6.1

Bug-fix release: connecting on an IPv6-only mobile network works again. Installs in place over any earlier release via the automatic update prompt, Check for updates, or sideload — identity, settings and app data are kept.

Changes since v0.6.0

• Bootstrapping on a DNS64/NAT64 carrier no longer fails every handshake. On an IPv6-only mobile network the node started, then logged Failed to send handshake message … Address family not supported by protocol (os error 97) for every attempt and sat at 0 links, while the same phone linked fine on Wi-Fi or an IPv4 carrier. The bootstrap peer is given as a hostname, and the UDP transport took the resolver's first answer for it — on DNS64 that is a synthesized IPv6 address, which the transport's IPv4 socket cannot send to. The transport now picks the answer in its own address family (the IPv4 one, carried by the 464XLAT every such network provides), and a name with no usable answer is reported with the families spelled out instead of an errno. This is a change in the embedded fips daemon (android-hooks @ 657886c); no screen changes.

Known issues

• After the mesh reconnects itself — a mesh-app or relay change, a !FIPS hotspot joining or leaving, an IPv6 route change — the link to a peer can take ~15 s to come back even though Overview already shows Connected. Under investigation; seen since 0.5.0.
• Peers listed in Diagnostics still show npubs, not the mesh names you gave them.

Install

Sideload the APK matching your device (adb install -r or open it on the phone); min SDK 26 (Android 8.0). Verify the download against the matching .sha256, or update from within the app.

• universal — all three ABIs in one file. Installs anywhere; larger. Use this if unsure.
• arm64-v8a — every 64-bit ARM phone from roughly 2016 on; the device-verified build.
• armeabi-v7a — old 32-bit phones. Compiles and packages; not exercised on real 32-bit hardware.
• x86_64 — Android emulator, Chromebooks.

Release APKs are signed with the key whose certificate SHA-256 is
aa905e32bd0058874d252990abba26c78ddd8fca018195ebd1cd232a99a7a8e1 — check a
fresh download with apksigner verify --print-certs <apk>. This matters most on a
first install: there is no previously installed signature for Android to
compare against, so the checksum and this fingerprint are the only things
identifying a genuine build. Subsequent updates are enforced against the key
automatically.

Caveats

The fix has not been exercised on a DNS64 network — none was available to the maintainer; it was reported from one and the fix is to the exact path the report identified. Verified otherwise: the fips transport's own tests (a DNS64-ordered answer picks the IPv4 address for an IPv4 socket), the host suite, and an emulator connect on a normal network through the same hostname bootstrap path, which still links. If you are on an IPv6-only carrier, this release is for you — please report back either way. Only arm64-v8a is exercised on real hardware; armeabi-v7a compiles and packages but has not been run on a 32-bit device; x86_64 is emulator-verified.

v0.6.0

Feature release: mesh names — use home.fips instead of npub1….fips. Installs in place over any earlier release via the automatic update prompt, Check for updates, or sideload — identity, settings and app data are kept.

Changes since v0.5.1

• Mesh names. Overview has a new Mesh names card: an address book that maps a readable name to a node's npub. Give npub1k3ae…wcl6n the name home, and every mesh app can open home.fips — in the browser, in an SSH client, anywhere a hostname goes. It works like a hosts file, and is one: the same name npub format as the fips daemon's /etc/fips/hosts, which an Android app has no way to write, so fips2go keeps its own and resolves the names in its DNS proxy.
  • No reconnect. Adding, re-pointing or removing a name applies to the very next lookup; the mesh stays up.
  • Saving a name that already exists re-points it (tap a row to load it into the fields). Several names may point at one npub. Each row has a copy button for name.fips.
  • A pasted npub1….fips or Home.fips is accepted and tidied up; a bad npub or name is refused with the reason.
  • Names are one label — letters, digits, hyphens — the same rule fips applies. www.home.fips does not resolve.
  • Names live on this device only: they are your address book, not something other nodes see, and they are not part of the identity backup.
• Diagnostics — the resolve / reachability field takes a mesh name as well as an npub.

No change to the embedded fips daemon (still android-hooks @ 876e62a).

Known issues

• After the mesh reconnects itself — a mesh-app or relay change, a !FIPS hotspot joining or leaving, an IPv6 route change — the link to a peer can take ~15 s to come back even though Overview already shows Connected. Under investigation; seen since 0.5.0. (Editing mesh names does not reconnect, so it does not trigger this.)
• Peers listed in Diagnostics still show npubs, not the names you gave them.

Install

Sideload the APK matching your device (adb install -r or open it on the phone); min SDK 26 (Android 8.0). Verify the download against the matching .sha256, or update from within the app.

• universal — all three ABIs in one file. Installs anywhere; larger. Use this if unsure.
• arm64-v8a — every 64-bit ARM phone from roughly 2016 on; the device-verified build.
• armeabi-v7a — old 32-bit phones. Compiles and packages; not exercised on real 32-bit hardware.
• x86_64 — Android emulator, Chromebooks.

Release APKs are signed with the key whose certificate SHA-256 is
aa905e32bd0058874d252990abba26c78ddd8fca018195ebd1cd232a99a7a8e1 — check a
fresh download with apksigner verify --print-certs <apk>. This matters most on a
first install: there is no previously installed signature for Android to
compare against, so the checksum and this fingerprint are the only things
identifying a genuine build. Subsequent updates are enforced against the key
automatically.

Caveats

Only arm64-v8a is exercised on real hardware. Mesh names were verified on a Pixel (arm64-v8a) after this release was published, and before that on the Android 14 (x86_64) emulator: with Chrome as the mesh app, home.fips resolved to the mapped node; a second name added while connected resolved on the next lookup with no node restart; and this release's x86_64 APK was installed in place over a release-signed 0.5.1 and the editor exercised in that build. The DNS translation itself is covered by host tests against the fips responder's own code. armeabi-v7a compiles and packages but has not been run on a 32-bit device; x86_64 is emulator-verified.

v0.5.1

Bug-fix release: connecting with no mesh apps selected no longer stalls. Installs in place over any earlier release via the automatic update prompt, Check for updates, or sideload — identity, settings and app data are kept.

Changes since v0.5.0

• No more ~10-second connect when no app is selected. With nothing selected the tunnel has to allow something (an empty allow-list would capture the whole phone), so it allows fips2go itself. It used to claim the default route and the in-tunnel DNS server as well — which sent the app's own DNS lookup of the bootstrap server into a tunnel whose resolver is not running yet while the node starts. The lookup sat in a ~10 s timeout, the first handshake failed, and the retry came ~15 s later: up to 25 s to a first link, on exactly the zero-config first run where nobody has picked an app yet. That tunnel now claims only the mesh prefix (fd00::/8); the app's own traffic never enters it. On a Pixel 9 Pro the node start went from ~10 s to 0.3 s, with the first peer linked 0.03 s later. Selecting an app still rebuilds the tunnel with the full routes, as before.

No change to the embedded fips daemon (still android-hooks @ 876e62a) or to any screen. Repository-side: a CI action pin was updated (Dependabot) and its version comment corrected.

Known issues

• After the mesh reconnects itself — a mesh-app or relay change, a !FIPS hotspot joining or leaving, an IPv6 route change — the link to a peer can take ~15 s to come back even though Overview already shows Connected. Under investigation; seen in 0.5.0 too.

Install

Sideload the APK matching your device (adb install -r or open it on the phone); min SDK 26 (Android 8.0). Verify the download against the matching .sha256, or update from within the app.

• universal — all three ABIs in one file. Installs anywhere; larger. Use this if unsure.
• arm64-v8a — every 64-bit ARM phone from roughly 2016 on; the device-verified build.
• armeabi-v7a — old 32-bit phones. Compiles and packages; not exercised on real 32-bit hardware.
• x86_64 — Android emulator, Chromebooks.

Release APKs are signed with the key whose certificate SHA-256 is
aa905e32bd0058874d252990abba26c78ddd8fca018195ebd1cd232a99a7a8e1 — check a
fresh download with apksigner verify --print-certs <apk>. This matters most on a
first install: there is no previously installed signature for Android to
compare against, so the checksum and this fingerprint are the only things
identifying a genuine build. Subsequent updates are enforced against the key
automatically.

Caveats

Only arm64-v8a is exercised on real hardware. This release's change was verified on a Pixel 9 Pro (Android 17) — a cold connect with no apps selected, then reselecting three apps while connected, which rebuilt the tunnel with the default route and the in-tunnel DNS — and on the Android 14 emulator. armeabi-v7a compiles and packages but has not been run on a 32-bit device; x86_64 is emulator-verified.

v0.5.0

A new interface, live settings, and a hotspot fix. Installs in place over any earlier release via the automatic update prompt, Check for updates, or sideload — identity, settings and app data are kept.

Changes since v0.4.1

New

• Redesigned interface, with a real dark mode. A complete Material 3 theme in light and dark (navy surfaces from the app icon). The old theme only set one colour, which left dark mode with dark teal on a dark surface, and light mode with white status-bar icons on white.
• One connect button. Overview's Connect/Disconnect pair is a single toggle that shows the state it is in — Disconnected, Connecting…, Connected, Reconnecting… — with tiles for mesh size, links and role. Tapping it while it is connecting cancels.
• Mesh apps apply while connected. Changing the app selection used to need a manual disconnect and connect. The mesh now reconnects once, for a couple of seconds, when you leave the picker. The picker also gained search and a live count, and sorts your selected apps first.
• Choose your Nostr relays. Overview → Manage relays: add your own or remove any of the three defaults. Addresses are validated before they are saved (a single address the relay client rejects would take the whole rendezvous down), the last relay cannot be removed, and a change made while connected is applied with one reconnect. Overview lists the relays in use, each with its live state.
• Settings are grouped into cards, and Save changes appears only while something is unsaved.
• Copy buttons for the public key and mesh address; the selected apps' icons on Overview; notices no longer cover the bottom navigation.

Fixed

• Joining a !FIPS hotspot no longer takes the node off the mesh. Since 0.4.0 the node's main transport failed to start once the hotspot transport was up (Address already in use), leaving it on the hotspot alone and unable to reach its bootstrap peer. Both transports now come up on the shared port. The embedded fips daemon moves to android-hooks @ 876e62a for this.
• Disconnect followed quickly by Connect could end "Disconnected" with a leftover tunnel interface, because the old session was still shutting down (about 5 s on a phone). The connect now waits its turn and then comes up.
• A settings change followed immediately by Disconnect could bring the VPN back up ~1.5 s later. It stays off.
• A second connect request arriving while one was in progress could tear down the live connection. It is ignored.
• If every selected app had been uninstalled, the tunnel captured every app on the phone. It now falls back to capturing nothing but fips2go.
• Restore and Regenerate identity are refused while a reconnect is in progress, not only while connected.

Changed

• Always-on VPN is no longer offered. It never worked — Android's always-on start was not treated as a connect, so with Block connections without VPN on, the selected apps had no connectivity until the app was opened. The app now declares the mode unsupported and Android greys both toggles out. If you had Always-on enabled for fips2go, connect from the app instead.

Known issues

• With no mesh apps selected, a connect can take ~10 s and the first link another ~15 s: the app's own DNS lookup of the bootstrap server is sent into a tunnel whose resolver is not up yet. Selecting any app avoids it. Fix planned for 0.5.1.

Install

Sideload the APK matching your device (adb install -r or open it on the phone); min SDK 26 (Android 8.0). Verify the download against the matching .sha256, or update from within the app.

• universal — all three ABIs in one file. Installs anywhere; larger. Use this if unsure.
• arm64-v8a — every 64-bit ARM phone from roughly 2016 on; the device-verified build.
• armeabi-v7a — old 32-bit phones. Compiles and packages; not exercised on real 32-bit hardware.
• x86_64 — Android emulator, Chromebooks.

Release APKs are signed with the key whose certificate SHA-256 is
aa905e32bd0058874d252990abba26c78ddd8fca018195ebd1cd232a99a7a8e1 — check a
fresh download with apksigner verify --print-certs <apk>. This matters most on a
first install: there is no previously installed signature for Android to
compare against, so the checksum and this fingerprint are the only things
identifying a genuine build. Subsequent updates are enforced against the key
automatically.

Caveats

Only arm64-v8a is exercised on real hardware. On a Pixel 9 Pro (Android 17): connect, cancel and disconnect; the live mesh-app and relay changes; Wi-Fi ↔ cellular hand-over; a 3-minute forced Doze; the quick disconnect/connect; and the !FIPS hotspot with both transports up. Emulator only: the relay editor's error messages and the Always-on opt-out. Not exercised: rotation inside the pickers and the uninstalled-app fallback. armeabi-v7a compiles and packages but has not been run on a 32-bit device; x86_64 is emulator-verified.

v0.4.1

Bug-fix release: the app picker now saves what it shows. Installs in place over any earlier release via the automatic update prompt, Check for updates, or sideload — identity, settings and app data are kept.

Changes since v0.4.0

• App selection is saved on every toggle. The picker used to persist the selection only on Save; leaving with Back discarded the change while the rows still showed it, so an app could look selected that the tunnel never captured (#26). Every tap is now written immediately, and the bottom button just closes the screen (Done).
• A note while connected. The tunnel takes the selection only when it is established, so a change made while the mesh is connected does not apply until the next connect. The picker now says so above Done whenever the node is running, and the note clears by itself after a disconnect.
• The set the tunnel was built from is logged at connect (mesh apps: [...]), so a "my app is not captured" report can be settled from logcat.

No change to the embedded fips daemon (still android-hooks @ cc03494, upstream v0.5.1+22) or to any other screen. Repository-side, the CI build was repaired after Google retired the legacy tools SDK package, and the automated security-review workflow was removed in favour of manual review.

Install

Sideload the APK matching your device (adb install -r or open it on the phone); min SDK 26 (Android 8.0). Verify the download against the matching .sha256, or update from within the app.

• universal — all three ABIs in one file. Installs anywhere; larger. Use this if unsure.
• arm64-v8a — every 64-bit ARM phone from roughly 2016 on; the device-verified build.
• armeabi-v7a — old 32-bit phones. Compiles and packages; not exercised on real 32-bit hardware.
• x86_64 — Android emulator, Chromebooks.

Release APKs are signed with the key whose certificate SHA-256 is
aa905e32bd0058874d252990abba26c78ddd8fca018195ebd1cd232a99a7a8e1 — check a
fresh download with apksigner verify --print-certs <apk>. This matters most on a
first install: there is no previously installed signature for Android to
compare against, so the checksum and this fingerprint are the only things
identifying a genuine build. Subsequent updates are enforced against the key
automatically.

Caveats

Only arm64-v8a is exercised on real hardware; this release's picker changes were verified on the Android 16 emulator. armeabi-v7a compiles and packages but has not been run on a 32-bit device; x86_64 is emulator-verified.

v0.4.0

A Wi-Fi ↔ cellular hand-over no longer drops the mesh. Installs in place over any earlier release via the automatic update prompt, Check for updates, or sideload — identity, settings and app data are kept.

Changes since v0.3.4

• Network switches are seamless. Until now every move between Wi-Fi and cellular restarted the mesh node: 1–2 s of outage, every session and route dropped, a fresh handshake with every peer. The node now stays up across the switch. The embedded fips daemon detects that the path to each peer moved and heartbeats those peers at once, so they re-pin to the new address; on the Pixel 9 Pro that takes about half a second from the moment Android reports the new network, with sessions, tree position and routes intact. The app tells the daemon the instant the network moved (Android denies apps the kernel event source the daemon would otherwise use), with a 5 s poll as backstop.
• fips updated to upstream v0.5.1+ (android-hooks @ cc03494), which carries the medium-change detector and, on the peer side, the fix for the stale-socket black hole the restart used to work around.

Two cases still restart the node, as before: an underlying network whose IPv6 status differs from the previous one (the tunnel's routes must change), and a FIPS Hotspot joining or leaving. A peer running a fips build older than September 2026 can still go quiet for up to its own liveness timeout after you switch networks; the fix for that peer is upgrading it.

Install

Sideload the APK matching your device (adb install -r or open it on the phone); min SDK 26 (Android 8.0). Verify the download against the matching .sha256, or update from within the app.

• universal — all three ABIs in one file. Installs anywhere; larger. Use this if unsure.
• arm64-v8a — every 64-bit ARM phone from roughly 2016 on; the device-verified build.
• armeabi-v7a — old 32-bit phones. Compiles and packages; not exercised on real 32-bit hardware.
• x86_64 — Android emulator, Chromebooks.

Release APKs are signed with the key whose certificate SHA-256 is
aa905e32bd0058874d252990abba26c78ddd8fca018195ebd1cd232a99a7a8e1 — check a
fresh download with apksigner verify --print-certs <apk>. This matters most on a
first install: there is no previously installed signature for Android to
compare against, so the checksum and this fingerprint are the only things
identifying a genuine build. Subsequent updates are enforced against the key
automatically.

Caveats

Only arm64-v8a is exercised on real hardware. armeabi-v7a compiles and packages but has not been run on a 32-bit device; x86_64 is emulator-verified.

v0.3.4

The app is now called fips2go. Installs in place over any earlier release via the automatic update prompt, Check for updates, or sideload — identity, settings and app data are kept.

Changes since v0.3.2

• Renamed to fips2go where the name refers to the app: the launcher caption, the entry in Android's Settings → Network → VPN, and the Zapstore listing. The Android package is unchanged (org.fips.android), which is why this updates in place rather than installing alongside your existing copy.
• Names referring to the mesh are unchanged, because they were never wrong: the in-app header, the "FIPS VPN" notification channel, "FIPS mesh connected", and "Mesh apps". You run fips2go; it joins the FIPS mesh.

Nothing else about the app's behaviour has changed since 0.3.2. There is no functional difference in this build beyond the naming.

(0.3.3 exists but contained no user-visible change — it was cut to produce artifacts under a fixed build-verification script. If you are on 0.3.2 or 0.3.3, this is the update that renames the app.)

Install

Sideload the APK matching your device (adb install -r or open it on the phone); min SDK 26 (Android 8.0). Verify the download against the matching .sha256, or update from within the app.

• universal — all three ABIs in one file. Installs anywhere; larger. Use this if unsure.
• arm64-v8a — every 64-bit ARM phone from roughly 2016 on; the device-verified build.
• armeabi-v7a — old 32-bit phones. Compiles and packages; not exercised on real 32-bit hardware.
• x86_64 — Android emulator, Chromebooks.

Release APKs are signed with the key whose certificate SHA-256 is
aa905e32bd0058874d252990abba26c78ddd8fca018195ebd1cd232a99a7a8e1 — check a
fresh download with apksigner verify --print-certs <apk>. This matters most on a
first install: there is no previously installed signature for Android to
compare against, so the checksum and this fingerprint are the only things
identifying a genuine build. Subsequent updates are enforced against the key
automatically.

Caveats

Only arm64-v8a is exercised on real hardware. armeabi-v7a compiles and packages but has not been run on a 32-bit device; x86_64 is emulator-verified.

v0.3.3

Installs in place over any earlier release (identity and settings kept) via the automatic update prompt, Check for updates, or sideload.

If you are already on 0.3.2, this update changes nothing you can see. No app source changed between 0.3.2 and 0.3.3 — the binary is functionally identical. The changes are to how releases are built and verified. Updating is harmless but optional.

Changes since v0.3.2

• A universal APK is now published. One artifact containing all three ABIs, so a first-time installer who is unsure which build they need can take -universal.apk and have it install on any device. It is ~40 MB against ~18 MB for arm64-v8a, so prefer the ABI-specific build if you know yours. The in-app updater always picks the ABI-specific one, whichever you installed.
• The per-ABI packaging check now works. The release script's assertion that a per-ABI APK contains only its own ABI had never once fired: a shell pipeline quirk turned its failure into a pass, and against a deliberately mispackaged APK it wrongly passed 20 out of 20 runs. It is fixed and tested. 0.3.2's per-ABI APKs were never actually verified by it; 0.3.3's are the first that have been.
• fips2go is now on Zapstore, with the APK signing certificate cryptographically linked to the publisher's Nostr identity.

Install

Sideload the APK matching your device (adb install -r or open it on the phone); min SDK 26 (Android 8.0). Verify the download against the matching .sha256, or update from within the app.

• universal — all three ABIs in one file. Installs anywhere; larger. Use this if unsure.
• arm64-v8a — every 64-bit ARM phone from roughly 2016 on; the device-verified build.
• armeabi-v7a — old 32-bit phones. Compiles and packages; not exercised on real 32-bit hardware.
• x86_64 — Android emulator, Chromebooks.

Release APKs are signed with the key whose certificate SHA-256 is
aa905e32bd0058874d252990abba26c78ddd8fca018195ebd1cd232a99a7a8e1 — check a
fresh download with apksigner verify --print-certs <apk>. This matters most on a
first install: there is no previously installed signature for Android to
compare against, so the checksum and this fingerprint are the only things
identifying a genuine build. Subsequent updates are enforced against the key
automatically.

Caveats

Only arm64-v8a is exercised on real hardware. armeabi-v7a compiles and packages but has not been run on a 32-bit device; x86_64 is emulator-verified.