integration/small-fixes
12
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 logan
|
0bfa2136be |
feat(dev): ask the phone instead of looking at it
The device tier could only take a screenshot and read what Go chose to log, and a screenshot cannot tell a dropped CSS declaration from a missing asset. This adds the third thing: the page's own answer, from the engine that is really rendering it. `make android-screenshot` grabs the screen, `make android-inspect` forwards the WebView's devtools socket, and `make android-eval EXPR=...` evaluates in the real page. Four details are load-bearing. Only a `debuggable` build opens that socket, so the debug build type takes `applicationIdSuffix ".dev"` and installs *beside* the release app -- the two carry different signing certificates, and Android's only remedy for a changed certificate is an uninstall, which takes the user's library with it. Playwright cannot drive a WebView (`connectOverCDP` calls `Browser.setDownloadBehavior`, which it answers "Browser context management is not supported"), so the eval is raw CDP over Node's built-in WebSocket. The socket name carries the pid, so it is resolved per launch rather than written down. And `exec-out`, not `shell`, for the screenshot: a pty translates LF and corrupts the PNG. What it immediately established is why it was worth having. The phone renders in Chrome 113 at 424x439 CSS px -- two years behind every browser the other tiers use, with no Popover API and no relaxed CSS nesting -- so a spec passing at that viewport says nothing about the device, and two conclusions drawn from version numbers alone were wrong. Both are corrected in NOTES.md and the plan. |
||
|
logan
|
d661836347 |
fix(android): keep the app out from under the system bars
Reported from the first device run: the playback controls are off screen. `targetSdk 35` is Android 15, which lays every app out edge-to-edge and ignores the deprecated `statusBarColor` and `navigationBarColor` the scaffold's theme still sets -- so a `match_parent` WebView draws the page's bottom band, which on a phone is the transport *and* the tab bar, underneath the gesture bar. `applyWindowInsets()` pads the container by `systemBars | displayCutout | ime` and returns the insets rather than consuming them, so the WebView is laid out inside them. The keyboard is in the mask because a search box the keyboard covers is the same bug one surface over. The window background goes black to match the app's own default ramp: that padding is what shows through, and a band of the scaffold's blue-grey above and below reads as the app failing to fill the screen. No tier we have can see this class of fault -- a browser viewport has no system bars, so `phone-shell.spec.ts` at 390x844 renders a shell that fits at the moment the device is clipping it. Verified only as far as the APK building; the insets need the next build on a phone. |
||
|
logan
|
b6651310ea |
build(android): drop the x86_64 ABI, which no Android can run
The fat APK's second half was 31 MB that cannot execute on any Android device. modernc.org/libc's Xlstat64 issues a raw lstat syscall on linux/amd64, and Android's seccomp policy forbids it because bionic never issues it, so the process takes SIGSYS the first time anything touches the database -- which for this app is startup. That is every x86_64 Android, x86 Chromebooks included, not merely the emulator. arm64 is structurally unaffected: the architecture has no lstat syscall at all, so modernc routes through fstatat. 27,059,130 bytes to 15,898,465, and one lib/ entry. Three places had to agree, and the third is what would have made this a silent no-op: abiFilters (what Gradle packages), android:package rather than package:fat (what Go *compiles* -- otherwise the library is still built and then discarded), and the native-code assertion in CI. That assertion is anchored, `native-code: 'arm64-v8a'$`, because without the anchor it also matches the fat APK's line and would pass on exactly the thing it exists to catch. Checked against a real artifact. Adding the ABI back, if modernc ever fixes Xlstat64, is those same three edits. |
||
|
logan
|
da38b865fc |
feat(android): playback that survives the screen locking
An app that plays audio becomes a music player at the point where the screen can lock, a call can interrupt, and the headphones can come out. None of that existed: the foreground service was typed for media but had no MediaSession, no transport notification and no audio focus, so oto would happily keep writing to a stream nobody could hear. The apparent blocker is that Wails' androidBridge* helpers are unexported, so Go cannot call arbitrary Java. It does not need to. StartForegroundService(json) *is* exported, and build/android/ is our tree, so widening the JSON WailsBridge already accepts is a local edit; coming back, WailsBridge.emitEvent lands on the application event bus, which Go subscribes to with app.Event.On. One document out, one command event back, and no new JNI. No new Gradle dependency either: minSdk is 21, which is exactly when android.media.session.MediaSession and Notification.MediaStyle arrived, so androidx.media buys two Build.VERSION branches' worth of nothing. Four things in it are load-bearing. **A duck is not a volume change.** Player.SetDuck holds the attenuation as an offset and re-applies the user's level through setVolumeLocked, so it cannot accumulate across repeated ducks and getUserVolume -- which feeds the event, the persisted state and every relative change -- still reports what the user chose. Writing through to the volume would let one notification tone permanently turn the music down. **The duck path is pre-Oreo only.** From API 26 the framework ducks the app itself and sends no CAN_DUCK focus change; asking to be told instead (setWillPauseWhenDucked) would mean pausing for every notification tone, and doing both would attenuate twice. **An unchanged payload is not an event**, the rule emitStatus already states one package over: every push crosses JNI and re-delivers an Intent, and the player pushes state on several paths that can agree. **After the first start, an update is startService.** From Android 12 a background app may not *start* a foreground service but may keep feeding one it already has, which is every track change with the screen off. Relatedly, every path through onStartCommand calls startForeground -- one that returns without it is killed. The contract with Java lives in androidpayload.go *without* the android build tag, and is tested. Everything left in android.go is untested by construction: make lint and make test are three tag sets on linux/amd64, so the only thing that compiles it is the cross-compiler in make android, and the only thing that can run it is a phone. None of the behaviour above has been observed on a device. The APK builds and both halves compile; that is the whole of what is verified. |
||
|
logan
|
e14a34fccf |
fix(android): let the app reach the user's music
Three of plan 016's four blockers. Each is a different reason the app could not work at all on a phone. **It had no permission to read anything.** The generated manifest asked for INTERNET, VIBRATE, biometrics, location and a camera, and nothing whatever about storage -- so at targetSdk 35 the app could see its own private directory and no music. It now declares READ_MEDIA_AUDIO, the two capped legacy storage permissions, and MANAGE_EXTERNAL_STORAGE. That last one is deliberate and is the load-bearing choice. This app is a library manager: audio_files.file_path is the primary key of ownership, the scanner walks a directory the user chose, and tagwriter rewrites files in place. MediaStore offers no stable directory to walk and no in-place write, so scoped storage is not "more work" here, it is a different application. MANAGE_EXTERNAL_STORAGE is Play-restricted, which is acceptable only because this ships as an APK through the package registry -- if it ever targets Play, that line is what has to go, and plan 016 says what replaces it. It is granted on a Settings screen rather than in a dialog, so it cannot be requested with requestPermissions(). MainActivity opens that screen on every cold start until access exists -- there is no degraded mode worth offering -- and re-checks in onResume, because the way back from another task is a resume, emitting android:storageAccess so the frontend can react. **The first-run flow could not complete.** All three call sites asked for a folder through the Wails dialog, which returns an error on Android: SAF yields tree URIs and this app is keyed on paths. So the app browses the filesystem itself, which it can now do. ListDirectories lists directories only (the thing being chosen is a library root), skips what it cannot stat rather than failing the listing (Android's storage root holds directories no app may enter), follows symlinks (os.DirEntry reports the link, so a symlinked music folder would silently vanish), and hides dotted entries. utils/pick-directory.ts is the one place that chooses between the two, so the three call sites changed by one line each. **Which platform is asked of the backend**, not of System.IsAndroid(): the dialog is backend code, so the backend is what knows whether it can open one; it answers for iOS at the same time; and it keeps the fallback testable through the ordinary transport fake rather than a module mock of the Wails runtime, whose platform helpers read build constants. **And MPRIS was compiled into the Android build**, because android implies the linux build tag, so it went looking for a session bus that does not exist. mpris_linux.go is `linux && !android` now and the stub covers Android, which means no lock-screen transport there yet -- a missing feature rather than a broken one, and the remaining blocker. The foreground service is typed mediaPlayback rather than the scaffold's dataSync, with the matching permission, so playback can survive the screen locking once there is a MediaSession to drive it. The type in the manifest and the one passed to startForeground must agree or startForeground throws. |
||
|
logan
|
6fbb62730d |
fix(android): build a release APK that is releasable
Three edits to the scaffold, each of which the generated tree gets
wrong for a shipped app.
**The phone ABI got a debug library.** Upstream's `build` task forwards
ARCH to compile:go:shared but not PRODUCTION, so the arm64 leg
recomputed BUILD_FLAGS against an unset variable and took the debug
branch -- while amd64, which package:fat calls directly with
PRODUCTION: "true", was correct. A release APK therefore shipped a 40MB
unstripped debug library for the only ABI a release is for, beside a
31MB production one for the emulator. 34MB APK before, 27MB after.
**The APK could be installed once and never updated.** Android orders
releases by versionCode and refuses anything not greater than what is
installed; the scaffold hardcodes 1, so the first install would have
been the last and the only way out is an uninstall, which takes the
user's library with it. It comes from YJ_VERSION_CODE now, which CI
derives from the tag (1.3.1 -> 10301, monotonic while minor and patch
stay under 100), with a default that keeps a local build working.
Integer.parseInt, not `(...) as Integer`: Groovy binds the call
parentheses to versionCode before the cast, so the latter reads as
`versionCode("1") as Integer` -- it sets a String, then casts the
setter's null return, and Gradle fails the whole project with "Value is
null" pointing at that line.
**And it identified itself as com.wails.app.** applicationId is
app.yellowjacket now, matching build/config.yml's productIdentifier,
and the label is YellowJacket rather than "Wails App".
Two things follow from that rename and both bite:
The identity is declared twice. applicationId is what Gradle installs;
APP_ID in build/android/Taskfile.yml is what every adb-driven task
uninstalls, launches and filters, and nothing enforces agreement.
ANDROID.md says to set APP_ID in build/config.yml -- that does nothing
in beta.8, checked both ways: `wails3 task` builds its var set from CLI
KEY=VALUE arguments and the Taskfile tree and never reads config.yml,
and even when set it feeds only those adb commands, never Gradle.
And `namespace` deliberately stays com.wails.app, because that is the
Java package MainActivity and WailsBridge live in and renaming it means
renaming their source. So the launcher activity is
app.yellowjacket/com.wails.app.MainActivity, and the short
`.MainActivity` form resolves the dot against the applicationId and
fails with a class-not-found that reads like a broken build.
|
||
|
logan
|
48b37f6301 |
build(android): carry the Wails Android scaffolding verbatim
Plan 015 phase 0 established that this app cross-compiles for Android with no source changes at all. A CGO_ENABLED=0 probe of the whole tree for android/arm64 fails on exactly two packages -- ebitengine/oto/v3 and wails/v3/pkg/application -- and both fail only because their Android implementation is cgo, which is what the NDK supplies. Notably modernc.org/sqlite, the entire database layer and the thing most likely to have no Android target, is clean. The fat APK (arm64-v8a + x86_64) builds in about 25 seconds. So build/android/ stops being ignored. This commit is the tree exactly as `wails3 generate build-assets` emits it, so that the next commit is a readable diff of what we changed and a future refresh has something to compare against. Two things about how it is carried: `wails3 update build-assets` does NOT generate it, contrary to what CLAUDE.md has claimed since the v3 migration. In beta.8 that command extracts only internal/commands/updatable_build_assets, which is darwin/ios/linux/windows; the android tree comes from `generate build-assets`, which rewrites the whole of build/. It was generated once into a scratch directory and copied across, so from here it is committed and hand-edited like source. Only its output is ignored -- jniLibs (~60MB of per-ABI c-shared libraries), gen/, overlay.json and Gradle's own directories. And it brings one Go file into ./... -- scripts/deps/install_deps.go, the interactive SDK installer behind `task android:install:deps`, which trips 24 of our strict linters. golangci excludes the directory rather than reformatting upstream's file, which the next refresh would undo and which would make the diff against upstream unreadable. This repo uses `make android-setup` instead. |
||
  yonluandClaude Opus 5
|
cad3d1339b |
fix(packaging): put the release recipes on v3's build
Neither packaging/arch/PKGBUILD nor the Homebrew formula had been run since Phase 1, and both were still calling v2's CLI: `wails3 build` takes -tags, -obfuscated and -garbleargs and nothing else, so `-clean -trimpath -ldflags` fails at the flag parser. Both also installed from build/bin/, which is v2's output path — v3 writes to bin/, and build/ is tracked build assets now. Three more things the tree needs that neither recipe had. The tasks invoke `wails3` by bare name, so scripts/toolbin has to be on PATH or the build dies at its first sub-task. `wails3 build` has no -ldflags at all, and build:native computes BUILD_FLAGS in its own vars: so a CLI variable cannot override it — LDFLAGS_EXTRA is appended inside the production -ldflags string instead, on linux and darwin alike, empty by default so make build-dev/build-prod are unchanged. And bundling is a separate step from building: `task build` produces a bare binary on both platforms, so the formula's macOS path runs `task package`. The build assets were the scaffold's, not this app's. Info.plist named CFBundleExecutable `yjref` and com.example.yjref, nfpm packaged ./bin/yjref, the .desktop template said "A yjref application" — an .app built from that plist would not have launched. They generate from build/config.yml, whose info block had never been filled from wails.json either; `wails3 task common:update:build-assets` is the fix. nfpm's homepage and license are not derived from it and are set by hand, which is noted in place, and the refresh regenerates build/ios and build/android, which this repo does not carry. arch-package.yml's pacman list moves to webkitgtk-6.0/gtk4 to match the PKGBUILD's depends(): makepkg installs nothing itself, so a mismatch fails at link time rather than at check time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm |
||
|
yonluandClaude Opus 5
|
453d5df0da |
fix(build): put wails3 on PATH for the Taskfile supervisors
`make sandbox`, `make dev`, `make build-dev` and `make build-prod` all died with "/bin/sh: wails3: command not found". `wails3 dev` and `wails3 task` are supervisors: they run the scaffold's Taskfile tree, which invokes `wails3` by bare name in 54 places across four files. The CLI is a vendored Go tool by design (plan 009, D3 — a global install would be this build's first undeclared dependency), so that name did not exist. scripts/toolbin/wails3 execs `go tool wails3`, and the Makefile prepends that directory only for the targets that start a supervisor. Rewriting 54 scaffold call sites would be churn to redo on every scaffold refresh; nothing global is installed either way. The shim does not cd. The first version did, to be sure `go tool` found the module — it does not need to — and that silently discarded the `dir:` a task had set, so generate:icons failed with "open appicon.png: no such file or directory" against a file that was there. Three things the build path needed once it got that far: - `frontend/package.json` gains `build:dev`, which build:frontend runs under DEV=true and which did not exist. - Vite binds 127.0.0.1. It defaulted to `localhost`, which resolves to `[::1]` only here, while wails3 dev's asset proxy dials IPv4 — so the first request for the dev server was refused and the first paint raced a retry. Zero proxy errors after. - The icons and the .desktop file are generated on every build. icons.icns/icon.ico are deterministic from our appicon.png (verified by regenerating), so the regenerated pair is committed and the churn ends; .task/ and the .desktop file are ignored. Also corrects a claim: build-prod strips and trims but does **not** UPX-compress — that was v2's `-upx` flag. Phase 1 recorded UPX as still working, but neither build target had been run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm |
||
|
yonluandClaude Opus 5
|
e7873bded3 |
build(wails): add the v3 toolchain alongside v2
Phase 1 of plan 009. The app still builds and runs on v2 — nothing in main.go or backend/ has moved yet — but the v3 CLI, its pinned runtime and its build-asset tree are now present, which is what Phase 2 needs. - wails/v3 v3.0.0-beta.8 pinned per D5, and wails3 added to the `tool` block beside the v2 CLI per D3. Both are vendored; neither is a global install. - build/ now holds the v3 build assets, copied wholesale from a `wails3 init` scaffold rather than hand-written. That collides with this repo's existing use of build/ as ignored build *output*, so .gitignore narrows to build/bin/ and bin/ and the assets are tracked. The mobile platforms are not carried: this is a desktop player (MPRIS over D-Bus, beep, XDG paths) and cannot target them. - build/config.yml's info block is filled from wails.json, which stays for now because the v2 CLI still reads it. - Taskfile.yml defaults PACKAGE_MANAGER to pnpm, since the scaffold assumes npm and frontend/package.json.md5 is part of the dep-caching scheme. One deviation from the plan worth recording. webkitgtk-6.0 is not installed on this machine, so the default GTK4 path is unavailable and the gtk3 fallback is in use. That also means `go tool wails3` does not work — the CLI itself fails to compile without webkitgtk-6.0 — while `go run -tags gtk3 .../cmd/wails3` does. The Makefile rewrite in the next commit has to account for that, and it goes away once the GTK4 dependency is installed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm |
||
|
logan
|
5097a6472a | removed build dir | ||
|
logan
|
abb60cb96a | initial commit |