epic: Trezor Hardware Wallet UI

[ovitrif]

Design: Figma — Trezor Screens

Related (iOS): synonymdev/bitkit-ios#589

Context

Bitkit adds a Hardware Wallet balance type alongside Savings (on-chain) and Spending (Lightning), backed by Trezor. The hardware balance is a watch-only view of funds held on a paired Trezor: Bitkit displays the amount and the device's on-chain activity and never holds the keys. Removing a device stops Bitkit from displaying that balance.

Paired Trezor identities appear on Home, Hardware Wallet detail, Settings, and in the Connect Hardware flow. Transfer to Spending from a hardware wallet is a send signed on the device.

Trezor v2 (milestone 2.5.0) extends that surface:

• Send on-chain from a paired Trezor through the normal Send flow, signing on the device.
• Receive on-chain to a paired Trezor, including on-device address verification.
• Pair passphrase (hidden) wallets as separate watch-only identities.
• Keep hardware activity, tags, and custom names across backup and restore.

Device naming & connection indicator

• Display name = label ?: model ?: "Trezor" — label is the device name set on the Trezor (editable on-device / in Trezor Suite), model is the hardware model (e.g. "Safe 3" / "Safe 7").
• The Figma "LABEL FUNDS" field is a Bitkit-side display name for the balance, defaulting to the resolved device name; persisted per device so the user can rename within Bitkit without touching the device.
• Connection indicator = connection type (Bluetooth or USB), tinted green while the device is currently connected. Figma examples: bluetooth · usb.

[ovitrif]

Android implementation notes

Current follow-up split:

• Hardware wallet connection reliability and UX polish #1030 tracks runtime connection reliability and UX polish.
• Hardware wallet emulator E2E coverage #1038 tracks emulator/E2E coverage and automation.

The notes below are intentionally stale and kept as historical implementation guidance for comparing the original AI-generated spec against the later discovered work.

Order mirrors the original subtasks. All patterns confirmed in the codebase — reuse, don't reinvent.

1. Home Screen updates — extend BalancesSection() in ui/screens/wallets/HomeScreen.kt with the full-width hardware row; include hardware sats in the total; merge device activity into the home activity list. Suggestion card: add HARDWARE to models/Suggestion.kt (title/description/color/icon), add the drawable + cards__hardware__* strings, wire it into a suggestion-list builder and the onClickSuggestion when to open the Connect flow; dismissal is automatic.

2. Hardware Wallet detail screen — model on ui/screens/wallets/SavingsWalletScreen.kt / SpendingWalletScreen.kt: parent composable + inner Content(). New HardwareWalletScreen.kt in ui/screens/wallets/. Reuse BalanceHeaderView, activityListGroupedItems(), AppTopBar, SecondaryButton, EmptyStateView, and the existing confirm-dialog pattern for Remove. Ensure the bottom Send / Scan / Receive button bar (the overlay shown on Savings/Spending detail screens) also renders on this route.

3. Hardware Wallet settings — in ui/settings/SettingsScreen.kt add a SettingsButtonRow under Payments with SettingsButtonValue.StringValue(deviceCount), a HardwareWalletsClick : SettingsEvent, and a handler navigating to the new HardwareWalletsScreen.kt (list + Add), reusing the settings row components. Add settings__hardware_wallets_* strings.

4. Connect Hardware flow — the 4 steps are bottom sheets via the existing Sheet/showSheet mechanism, backed by HwWalletViewModel / HwWalletRepo (see Cross-cutting).

5. Transfer to Spending from HW device flow — also bottom sheets; mirror the existing Spending transfer flow, swapping local signing for on-device signing (Open Trezor Connect).

6. Automated testing — the repo already ships a TrezorBridgeTransport (services/TrezorBridgeTransport.kt, HTTP, default http://10.0.2.2:21325) gated by BuildConfig.TREZOR_BRIDGE / TREZOR_BRIDGE_URL, with a unit test that mocks an emulator:21324 device — i.e. the path for testing without physical hardware already exists. Plan: (a) add testTags on the new composables; (b) build the E2E APK with E2E=true TREZOR_BRIDGE=true pointed at a trezor-user-env emulator (ghcr.io/trezor/trezor-user-env, ports 21324/21325); (c) add a @hardware shard of flows to the external synonymdev/bitkit-e2e-tests repo covering connect + transfer-to-spending; (d) add adb/deep-link android-cli journeys so an agent can drive the same paths locally. Extend the existing TrezorRepoTest / TrezorViewModelTest / TrezorBridgeTransportTest unit coverage for the new VM/repo.

Cross-cutting

Navigation & routes — in ui/ContentView.kt: add the new @Serializable routes and register with composableWithDefaultTransitions. Use direct route navigation at the call site — do not add navigateToHardwareWallet()-style helpers (current preference).

ViewModels / Repo — keep the existing dev-settings integration but rename it for clarity: TrezorViewModel → TrezorDevSettingsViewModel and TrezorScreen → TrezorDevSettingsScreen (stays the dev-settings entry). Add a new, lighter HwWalletViewModel (named generically so it can back future vendors) for the production connect / balance / transfer flows. Introduce HwWalletRepo as the production hardware-wallet business layer (evolve/rename the existing repositories/TrezorRepo.kt — it already holds the device list, connect orchestration, and KnownDevice persistence via TrezorStore); keep the Trezor-specific TrezorTransport / TrezorBridgeTransport classes as-is underneath. Both TrezorDevSettingsViewModel and HwWalletViewModel consume HwWalletRepo. Repo methods return Result<T>; UiState is @Immutable/@Stable with ImmutableList fields and _uiState.update {}.

Changelog — one user-facing feat: fragment in changelog.d/next/ (<pr>.added.md).