Files
buzz/mobile/android
Wes f59b326568 Fix mobile onboarding policy loading, browser cancellation and pairing feedback (#8874)
Mobile onboarding could reject valid large legal documents, stay busy
after closing Android browser sign-in, and hide pairing-import errors
behind the community-link form. This change bounds join-policy responses
at 4 MiB while retaining 64 KiB for other responses, handles Android
browser cancellation through the native lifecycle/channel, keeps Cancel
sign-in usable, and shows friendly pairing errors on the landing screen
with a live-region announcement. Identity mismatch checks remain intact.

The browser-cancellation implementation incorporates the candidate from
#8847 (`cb241b3f1`); coordinate landing to avoid duplicate work. This PR
consolidates the three fixes exercised together during Android
onboarding acceptance.

## Validation

- Pixel 9 / Android 17, production hosted services, isolated debug
installs. Human acceptance plus native UI, saved public-identity and
restart checks as noted below. No iOS acceptance in this session.
- Latest build and invite-first acceptance: base
`a12ad1cdd29da8b2923eca5408e963a2659777ab` plus these patches.
- Focused tests on that base plus patches: **88 passed** across
hosted_journeys_test, hosted_admission_test, browser_auth_test,
pairing_hosted_handoff_test and pairing_provider_test, with
`BUZZ_AUTH_DOMAINS=communities.buzz.xyz`.
- Earlier baseline: 81 focused cases passed plus one
staging-configuration case passed separately (82 distinct cases across
seven onboarding/recovery files); these are historical, not current-head
certification.
- Earlier policy change: 41 focused tests, changed-file analysis and
isolated mutation check passed on the earlier base. Earlier browser
candidate native instrumentation/mutation evidence was not rerun on this
combined revision.
- Android debug APK built and installed successfully. Mandatory
commit/push hooks passed at `6442e5ff9`: analysis clean; mobile tests
4,047 passed / 34 skipped; additional package runs 4 and 27 passed;
file-size checks passed. These broad tests ran through the required push
hook, not a manually invoked suite. CI remains pending.

## Live testing report — October 31

| Journey | Result and evidence boundary |
|---|---|
| Fresh email signup / identity / hosted invite | Reproduced policy
response exceeding 64 KiB; after fix, admission and restart passed.
Profile/message visible locally; cross-account message receipt remains
unproven. Tested at `cfcaef4e9f` plus policy patch. |
| Browser close → retry → login → existing identity recovery → restart |
Passed at `d14f33a170` plus patches; recovered the expected public
identity and community. |
| Pairing a different identity into an existing install | Rejected
without replacing the original key. Initially hidden error became
visible with friendly copy; Back and restart preserved the community at
`b80217de3` plus patches. |
| Fresh pairing → wait for desktop approval → sign-in → community →
restart | Passed at `20742a236` plus patches; human confirmed approval
gate, saved public identity matched. |
| First-time desktop cancellation → welcome → fresh QR retry → community
→ restart | Passed at `20742a236` plus patches. Cancellation error
remained raw `user_denied`. |
| Android system Back while awaiting pairing approval | Human-confirmed
in already-onboarded Add Community; first-time phone-side Back variation
remains untested. |
| Wrong pairing code → rejection → correction → completion |
Human-confirmed at `a2540fbe3` plus patches. Exact error and
same-session versus fresh-QR retry were not independently captured. |
| Interrupt account onboarding at community picker → process restart →
recovery → admission | Passed at `a2540fbe3` plus patches. Restart
opened Add a community; Find my communities restored choices without
another login. Human completed admission. No destination had yet been
selected. |
| Invite-first into fresh signed-out app → intended community → restart
| Passed at `a12ad1cdd` plus patches; saved identity/destination
matched. Existing member and existing browser session. Initial Android
VIEW intent explicitly targeted the test package; ordinary HTTPS default
app-link resolution and new-member admission remain untested. |
| Malformed community input → error → Back → restart | Passed for `not a
community`; original community preserved. `not-a-community` is a valid
single-label hostname and was not counted as malformed-input evidence. |

## Remaining gaps and findings

Not release certification. Pairing landing-error regression/mutation
evidence is now recorded below. Current combined-revision native
instrumentation has not been rerun; its limited scope is described
below.

Deferred behavior, not implemented here:
- Wrong browser account after fresh pairing is correctly rejected, but
Retry reuses that app account session; in-app account switching must
preserve the transferred identity and destination. The live happy path
used a manual browser-account switch and fresh install.
- Pairing wait has no visible Cancel; tested system Back works.
- Desktop cancellation exposes raw error wording.
- Interrupted community selection requires an extra Find my communities
step.

Master checklist remains partial: seven categories exercised this
session, signup/community creation has historical coverage, seven
categories unexercised. New-member link-first admission, deeper
interruption/server-commit recovery, expiry/revocation/network failures,
key import, organization/self-hosted paths, phone-to-desktop transfer,
eligibility gates, accessibility/app-link variants and iOS require
separate coverage. Channel-discovery work is separate (#8869).

## Review checkpoint

[Carl’s
review](https://github.com/block/buzz/pull/8874#pullrequestreview-5724095754)
found no code blockers at `6442e5ff9`. Carl also reviewed test-only
follow-up `d43958653` and found no issues, accepting both validation
gaps as closed. A subsequent review identified stale callback → resume
cancelling a newer Android login. A narrow native fix and regression
validation are in progress; prior readiness attestation is withdrawn
pending this behavior change.

- **Android stack check passed (Pixel 9, Android 17):** after fresh
account sign-in, the human stopped at the community picker without
closing/restarting. `dumpsys activity activities` showed exactly one
MainActivity in Invite First task 567, with no CustomTab in that task or
the full component list. ChromeTabbedActivity remained in a separate
pre-existing browser task. This rules out a lingering duplicate activity
in this run; it does not independently trace `onNewIntent` or establish
all Android/browser variants. Binary production sources match
`6442e5ff9`.
- **Pairing regression/mutation passed:** extended the existing QR
journey using the real encrypted NIP-AB import and hosted coordinator.
Asserts visible friendly mismatch feedback, live-region wrapper,
unchanged stored community/account identity, and Back to home. Reused
the existing socket fake. Hosted journey + pairing provider files: 70
passed with configured auth domain; opt-out hosted journey file: 3
passed / 21 skipped; changed-file analysis clean. Isolated clone:
control passed, hiding the landing error failed the visible text
assertion, restoration passed. No production source change in this
follow-up.
- **Duplicate landing:** #8847 is superseded by this combined PR; its
Android slice is included here. No merge performed.

BrowserAuthPluginTest manually drives plugin hooks using an unmanaged
Activity and fake browser launcher. It proves the plugin state machine
only, not MainActivity wiring, real lifecycle order, process death, or
duplicate app_links callback delivery. Current CI does not run Android
instrumentation. Android ignores the debug ephemeral-login flag and
shares browser cookies.

Readiness checklist: agent review completed on production changes and
test follow-up; agent exercised the changed behavior; human completed
the documented Android journeys and final sign-in check.



## Stale callback follow-up (`b7aaaa788`)

Addresses [the later Android lifecycle
review](https://github.com/block/buzz/pull/8874#pullrequestreview-5724197312):
a recognized callback now clears browser-dismissal tracking before
rejecting a mismatched state. A stale callback cannot complete or cancel
the newer login. The existing native journey now includes the
intervening resume, successful current callback, and genuine browser
dismissal after a stale callback. Only two native files changed; policy
and pairing fixes are unchanged.

Validation: 88 focused Dart tests passed. Android app and test APK build
passed. On Pixel 9, the native plugin journey passed; in an isolated
source/Git/build clone, removing the reset failed at the newer attempt's
expected-zero-replies assertion; exact restoration passed. This proves
the plugin state machine on Android, not a real late browser callback
through OS lifecycle delivery. Carl reviewed `b7aaaa788` and found the
fix correct and minimal with no blockers. Human browser-close/retry
check remains pending; PR stays draft until that passes. Current-head CI
is also required for merge.

Accepted limitation: if a recognized stale callback arrives after the
current browser tab has already gone, automatic dismissal is suppressed
and the user may need the visible Cancel button. The callback cannot
complete sign-in without matching state; Dart validation remains
authoritative.

---------

Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Brain <1a02c72794dcd0f07058a353bc3a81f4028b8c77c92c87fce6d5c8b85970a20b@buzz.block.builderlab.xyz>
2026-10-31 12:43:01 -06:00
..