fea9ab3091
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>
25 lines
1.1 KiB
Text
25 lines
1.1 KiB
Text
v1.2.8
|
|
|
|
🛠️ Amber finally pops up — signing works (the real fix)
|
|
The big one. On some Android setups (notably GrapheneOS), tapping delete,
|
|
accepting a crew invite, sending a zap, or editing your profile would spin
|
|
forever and Amber never appeared.
|
|
|
|
Root cause: the app's browser layer was silently dropping the request that
|
|
opens Amber, so the approval screen never launched. We added a native hand-off
|
|
so signing requests now open Amber directly — exactly like login already does.
|
|
|
|
Now every signing/encryption action launches Amber, you approve, and the
|
|
action completes. If Amber genuinely doesn't respond you get a clear message
|
|
in seconds instead of an endless spinner.
|
|
|
|
IMPORTANT: after updating, log OUT and log back IN once. Then delete, accept
|
|
invite, zap, and profile edits will just work.
|
|
|
|
🔔 Notification bell "Mark read" actually clears the badge
|
|
Marking notifications read now clears the count for crew items too, while
|
|
your pending invites and requests stay visible in the Crews tab until you
|
|
act on them.
|
|
|
|
🧹 Housekeeping
|
|
Behind-the-scenes reliability fixes across the signing and notification flows.
|