Commit Graph
4 Commits
Author SHA1 Message Date
bvandeusenandClaude Opus 5 20907abf6e android: a Kotlin/Compose app that drives the Rust core (M12 step 5)
Android / Kotlin + Rust (debug APK) (push) Failing after 1m20s
Desktop (Tauri) / Windows installer (cross-compiled) (push) Successful in 2m24s
Desktop (Tauri) / Tauri desktop (Linux) (push) Successful in 4m0s
Desktop (Tauri) / Update manifest (push) Successful in 5s
The skeleton, and the lane that builds it. Gradle invokes cargo-ndk to
cross-compile thoughtsync-ffi for four ABIs, generates the Kotlin bindings from
the resulting .so, and packages both.

BUILT ON MINSTREL'S TOOLCHAIN, not a fresh guess. Gradle 9.1.0 / AGP 9.0.1 /
Kotlin 2.3.21 on JDK 25 is the combination already proven in this family on
ci-android, including the JDK 22+ native-access opt-in the launcher JVM needs
and the artifact-upload action pinned by SHA (issues 2255 / 2270). It also
independently confirms the JDK 25 call made on ci-rust-android in step 3.

Gradle wiring worth noting:

  * ExecOperations, not project.exec — the latter was REMOVED in Gradle 9, and
    touching `project` at execution time is also what breaks the configuration
    cache this build enables.
  * The cargo task's inputs are the Rust SOURCES, not the workspace directory.
    Declaring the directory would make Gradle hash target/, which is gigabytes.
  * Bindings are generated with `--library` against the built .so, so they can
    never describe a different version of the Rust than the one being packaged.
  * cargo runs --locked, so an Android build cannot silently re-resolve the
    lockfile the desktop lanes are gated on.

JNA is a real dependency, with the @aar classifier. The plain jar builds fine
and fails at runtime with UnsatisfiedLinkError, which is the worst way to learn
it. R8 keep rules for JNA and the bindings are in for the same reason — that
failure would otherwise appear only in a minified release.

The UI is a working board, not a debug screen: capture field, note list, empty
state, error banner, and an honest failure screen for a store that won't open.
Rules 23/24 — a surface ships at quality from the first commit. Capture uses the
IME action key because the north star is a thought captured in under a second,
and leaves the title empty so the core derives it from the first body line.

Every core call runs on Dispatchers.IO: they are blocking FFI into synchronous
SQLite, and running them on the main thread is exactly the jank going native was
meant to avoid.

The launcher icon reuses frontend/public/icon-maskable-512.png as an adaptive
foreground on the brand #F5C518 — the same asset and colour the web app already
ships, so the three surfaces wear one face.

No signing config. A release keystore that has passed through an agent session
or shell history is compromised by construction (task 2136); it has to be
generated by the operator and reach CI only as a secret. CI builds debug.

CI can only prove this BUILDS — a Linux runner cannot execute an APK, so feel
and on-device correctness remain an operator pass on an emulator.

Scribe #2739.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-18 15:24:30 -04:00
bvandeusenandClaude Opus 5 0a7480cf9b core: extract the store and sync engine into a shared crate (M12 step 1)
Desktop (Tauri) / Tauri desktop (Linux) (push) Failing after 48s
Desktop (Tauri) / Windows installer (cross-compiled) (push) Successful in 1m50s
Desktop (Tauri) / Update manifest (push) Skipped
Android becomes a native Kotlin client over this same code (Scribe note 2730), so
the local store and sync engine stop being modules of the desktop app and become
`thoughtsync-core`, a crate with no UI framework in it at all.

This is a move, not a rewrite, and the measurement is why: every file in local/
and sync/ already carried ZERO Tauri references — 4,980 of 6,372 lines. The
coupling was 473 lines of command shim, which stays behind in the desktop crate
as src/commands/. Kept as git renames so history follows the files.

The desktop imports them under their old names (`use thoughtsync_core::{local,
sync}`) so every call site reads exactly as before. What moved is where they
live, not what they are.

Two things a workspace changes that are easy to miss, both caught before pushing:

[profile.release] now lives at the workspace ROOT. Cargo silently ignores
profiles declared by a non-root member — leaving it in the desktop crate would
have dropped lto/strip/opt-level from every release build with only a warning.

And a workspace shares ONE target dir, so the bundles moved from
desktop/src-tauri/target to target/. Thirteen references across publish-release,
debundle-graphics, verify.sh, package-prebuilt and the workflow now point there.
Pinning target-dir back would have been the smaller diff, but the Android lane
also produces Rust artifacts and they do not belong under desktop/.

Also retires the Tauri Android lane in the same push rather than leaving a path
that is being replaced: gen/android, android.yml and docs/android-dev.md are
gone, the mobile_entry_point attribute with them, and the lib drops to rlib —
staticlib/cdylib existed for Tauri mobile, and the .so Android loads will be
built from the core crate instead. Rule 22, no parallel path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-17 23:12:26 -04:00
bvandeusenandClaude Opus 5 40cb463be7 android: build the x86_64 ABI too, so an emulator can run it (task 1864)
Android (Tauri) / Android APK (debug) (push) Successful in 3m55s
arm64 is every real device, but a desktop emulator is x86_64 — an arm64-only APK
installs there and then dies unable to load its native library. A build nobody
can try on an emulator is a build nobody checks, which defeats the point of
producing an artifact at all while there is no phone in the loop.

armv7 and i686 stay out: 32-bit hardware we do not target, and the image carries
all four targets if that ever changes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-17 22:01:42 -04:00
bvandeusenandClaude Opus 5 1f140c7457 android: scaffold the Tauri mobile lane and build a debug APK in CI
Desktop (Tauri) / Windows installer (cross-compiled) (push) Successful in 2m38s
Android (Tauri) / Android APK (debug) (push) Failing after 21s
Desktop (Tauri) / Tauri desktop (Linux) (push) Successful in 4m26s
Desktop (Tauri) / Update manifest (push) Successful in 5s
The phone client is Tauri v2 mobile (operator decision), so it reuses the Vue
frontend and the Rust store and sync engine that already exist rather than
becoming a third implementation to keep in step by hand.

gen/android is committed. tauri android init generated it, its own .gitignore
already excludes the build outputs and every keystore file, and CI must not have
to regenerate a project that manifest edits will accumulate in.

What the scaffold confirms is that the image's JDK pin was load-bearing rather
than incidental: Tauri templated Gradle 8.14.3 with AGP 8.11.0, and CI-android's
versions.env records that JDK 25 needs Gradle 9.1.0+ and that anything older
fails with an opaque "25.0.3" message. Picking 17 for ci-tauri-android avoided
exactly that. namespace and applicationId came out as com.fabledsword.thoughtsync,
matching the desktop identifier, so the app-data story stays consistent.

The lane builds a DEBUG APK for arm64 only. Release APKs need signing, and the
keystore has to be generated by the operator and never pass through CI logs or an
agent session — the constraint recorded for the updater key applies unchanged.
Gradle's throwaway debug keystore needs nothing from anyone, so this can prove the
app compiles and packages today and grow a signed job when a key exists. arm64 is
every real device; the image carries the other three ABIs, so widening is a word.

Triggered by frontend/** as well as desktop/**, because generate_context! compiles
the frontend into the app — the same reasoning that widened desktop.yml. Android,
desktop and web are peers on one quality bar, and a frontend commit that skipped
this lane would ship a stale phone build.

Green here will mean it BUILT. A Linux runner cannot execute an APK, so nothing in
this lane proves the app runs, renders, or is usable by finger.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-16 23:01:32 -04:00