yellowjacket

1,250 Commits 84 Branches 13 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
logan	8d2109b87e	fix(android): install and launch the package the APK declares The four adb-driven tasks in build/android/Taskfile.yml began with `adb uninstall {{.APP_ID}}`, where APP_ID defaulted to "app.yellowjacket" -- the release id. `run` and `run:device` build the debug variant, whose applicationIdSuffix makes it "app.yellowjacket.dev", so both uninstalled the user's released app, took the library with it, installed a different package, and then failed to launch the one they had just removed. The id is read back from the built APK now (scripts/android-pkgid.sh, `aapt2 dump packagename`) rather than written down a second time, so the thing installed and the thing launched agree by construction -- whatever Gradle resolved the applicationId to, suffixes included, is in the file. An APK it cannot read is a hard failure and never a fallback to a default; guessing is the bug. APP_ID survives with no default as an assertion: it is checked against the artifact and refused, naming both, before anything is installed or a target is even chosen. The uninstall is gone rather than corrected. It was there to make the bare `install` on the next line work at all -- Android refuses an install over an existing package without -r -- so `install -r` removes the reason for it. What is left is the one case an uninstall is really the remedy, a changed signing certificate, and that is exactly the case where doing it silently costs the user their library. So it is reported with the command to run, which is the answer scripts/android-emulator.sh had already reached for `make android-install`. And the emulator tasks now say "emulator" to adb. A bare `adb install` with one device attached picks that device whatever it is, so with a phone plugged in and no emulator running, the task whose summary reads "in the Android Emulator" installed on the phone -- the same data loss, from the task whose name gives no warning. Several matching targets is an error naming them rather than a silent pick of the first. Closes #159	2026-08-20 14:34:59 -04:00
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.	2026-08-16 15:30:35 -04:00
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.	2026-08-16 15:30:13 -04:00

Author

SHA1

Message

Date

logan

8d2109b87e

fix(android): install and launch the package the APK declares

The four adb-driven tasks in build/android/Taskfile.yml began with
`adb uninstall {{.APP_ID}}`, where APP_ID defaulted to
"app.yellowjacket" -- the release id. `run` and `run:device` build the
*debug* variant, whose applicationIdSuffix makes it
"app.yellowjacket.dev", so both uninstalled the user's released app,
took the library with it, installed a different package, and then
failed to launch the one they had just removed.

The id is read back from the built APK now (scripts/android-pkgid.sh,
`aapt2 dump packagename`) rather than written down a second time, so
the thing installed and the thing launched agree by construction --
whatever Gradle resolved the applicationId to, suffixes included, is in
the file. An APK it cannot read is a hard failure and never a fallback
to a default; guessing is the bug. APP_ID survives with no default as
an *assertion*: it is checked against the artifact and refused, naming
both, before anything is installed or a target is even chosen.

The uninstall is gone rather than corrected. It was there to make the
bare `install` on the next line work at all -- Android refuses an
install over an existing package without -r -- so `install -r` removes
the reason for it. What is left is the one case an uninstall is really
the remedy, a changed signing certificate, and that is exactly the case
where doing it silently costs the user their library. So it is reported
with the command to run, which is the answer scripts/android-emulator.sh
had already reached for `make android-install`.

And the emulator tasks now say "emulator" to adb. A bare `adb install`
with one device attached picks that device whatever it is, so with a
phone plugged in and no emulator running, the task whose summary reads
"in the Android Emulator" installed on the phone -- the same data loss,
from the task whose name gives no warning. Several matching targets is
an error naming them rather than a silent pick of the first.

Closes #159

2026-08-20 14:34:59 -04:00

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.

2026-08-16 15:30:35 -04:00

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.

2026-08-16 15:30:13 -04:00