Commit graph

7 commits

Author SHA1 Message Date
shakespeare.diy
955a823b02 fix(android): ship stock MainActivity so the app launches (fixes crash) (1.2.11)
The manifest launches org.skatespots.app.MainActivity; when that class was
missing/wrong the app crashed on startup. Add a STOCK MainActivity (extends
BridgeActivity, no WebViewClient override) plus an idempotent injector that
guarantees it's always present after cap add / rm -rf android. This is the safe
default — the earlier custom version broke startup. Delete fix (setPackageName)
remains intact. Bump to 1.2.11.

Co-authored-by: shakespeare.diy <assistant@shakespeare.diy>
2026-09-04 22:20:18 +07:00
shakespeare.diy
88685262ce fix(android): remove custom MainActivity that broke app startup (black screen)
The injected MainActivity overrode Capacitor's WebViewClient, wiping out the
client Capacitor needs to load the web layer — causing a black-screen crash on
launch. Remove the MainActivity template, its injection script, and the build
wiring. The real signing fix (setPackageName before signEvent) is unaffected and
remains in place. Bump to 1.2.10.

Co-authored-by: shakespeare.diy <assistant@shakespeare.diy>
2026-09-04 22:02:23 +07:00
shakespeare.diy
fea9ab3091 fix(android): native intent hand-off so Amber actually opens for signing (1.2.8)
Amber never appeared for delete/accept-invite/zap because Capacitor's default
WebView silently drops JS-initiated intent:/nostrsigner: navigations — the
request that opens Amber never reached the OS. Login worked only because it
uses the plugin's native startActivityForResult.

Add a custom MainActivity (android-templates/MainActivity.java) that overrides
shouldOverrideUrlLoading to launch intent:/nostrsigner: URLs via startActivity()
— a real native launch that opens Amber on GrapheneOS, matching login. Injected
into the generated android/ project at build time by inject-main-activity.mjs,
wired into android:build/sync/init. Simplify the JS launcher to navigate the
WebView (now intercepted natively). Bump to 1.2.8.

Co-authored-by: shakespeare.diy <assistant@shakespeare.diy>
2026-09-04 21:23:38 +07:00
shakespeare.diy
677ccb8a82 v1.2.0: Spedn label, multi-relay community stats, GrapheneOS Near-Me fix
1. Map filter: renamed the "Bitcoin" toggle to "Spedn" (matches the toolbar
   button); tooltip now says "Spedn your sats".

2. Community stats (/stats): useGrowthStats now queries the same relay set as the
   rest of the app (community relay + user relays) via useSkateRelays instead of
   only the single hardcoded SKATE_RELAY. Lab profiles / spots / etc. that live on
   a user's own relay are now counted, so the numbers match what /lab shows.

3. Near Me on GrapheneOS: even after granting the OS location permission, the
   WebView's navigator.geolocation stays blocked → "permission denied". Fixed by
   fetching the position from the native Capacitor Geolocation plugin first
   (LocationManager, honours the granted permission), falling back to
   navigator.geolocation only if that fails. Also auto-inject
   ACCESS_FINE/COARSE_LOCATION into AndroidManifest via the manifest script.

Bump version to 1.2.0 (versionCode 10200).

Co-authored-by: shakespeare.diy <assistant@shakespeare.diy>
2026-08-27 14:54:00 +07:00
shakespeare.diy
07699592da Fix Amber "Waiting…" hang on GrapheneOS: unblock setPackageName + auto-inject <queries> (v1.1.9)
Two concrete root causes for the eternal "Waiting for Amber…":

1. setPackageName could hang forever on GrapheneOS. getPlugin() awaited it with
   no timeout, so getPublicKey() (and its 90s timeout) was never even reached.
   Now setPackageName races a 3s timeout and continues regardless — the Amber
   package is passed explicitly on every call anyway, so it's non-essential.

2. AndroidManifest.xml had no <queries> block. On Android 11+/GrapheneOS the OS
   silently blocks the nostrsigner intent without it, so Amber never opens. Added
   scripts/inject-amber-queries.mjs (idempotent) and wired it into android:init /
   android:sync / android:build so the block is guaranteed present in every APK,
   surviving cap sync regeneration.

Bump version to 1.1.9.

Co-authored-by: shakespeare.diy <assistant@shakespeare.diy>
2026-08-27 14:27:00 +07:00
shakespeare.diy
4bef95132b Bump to 1.0.93 (1.0.92 already live) + versionCode scheme matches published 1.0.x
1.0.92 was already published to Zapstore, so move to 1.0.93. Adjusted
sync-android-version.mjs so 1.0.x maps versionCode = patch (1.0.93 -> 93),
continuing the existing published scheme instead of jumping to 10093.

Co-authored-by: shakespeare.diy <assistant@shakespeare.diy>
2026-07-30 22:43:32 +07:00
shakespeare.diy
41595159d9 Auto-sync Android version from package.json (no more manual gradle bumps)
Adds scripts/sync-android-version.mjs which writes versionName (semver) and a
monotonic versionCode (major*10000+minor*100+patch) into android/app/build.gradle
from package.json. Wired into `npm run android:build` and `android:sync`, plus a
standalone `npm run android:version`. Now you bump ONE number (package.json) and
never hit Zapstore's "already exists" again. Exits quietly if android/ isn't
generated yet.

Co-authored-by: shakespeare.diy <assistant@shakespeare.diy>
2026-07-30 22:38:13 +07:00