[ben-kaufman]

Fixes #1519 and #1535. Refs #1533.
Twin: synonymdev/bitkit-ios#1003

Description

• Let fresh USD requests and USDT subscriptions accept digits immediately while preserving existing cents.
• Keep request/subscription amounts leading-aligned, with compact trailing controls and a divider above the keypad. Preserve normal key height, stable BTC/USD control positions and scrolling on short screens.
• Scale the QR logo to the displayed code size so compact Receive codes remain scannable.
• Give USDT wallet, activity and deposit details opaque backgrounds during the existing wallet slide transition.
• Keep Receive footer positions consistent across Bitcoin and USDT and retain the hardware vendor’s tab label.

Parent #1564 is merged. This PR now targets master; signed integration 222df83117ee3bac6a5d852a53f9726e7315befc combines the prior published head with actual master 3ad6193b2bbe85ab18609bd90a0062f8fbda88a6, preserving published commits and the downstream stack. It preserves master’s single denomination toggle, BTC-only unit control, dot decimals, QR cache and Receive navigation. The conflict resolution retains this PR’s amount geometry, scrolling and zero-amount entry behavior. Amount conversion, payment/sharing behavior, fees, persistence and authorization are unchanged by the resolution.

Design

Request amount — Handoff v62 and amount layout — Refactor v63. Reuses existing wallet navigation, typography, buttons and divider. The receive-network warning design remains outside this change; the selected network stays visible.

Preview

Earlier captures at 320/375dp and normal/1.6× text show amount layouts and matching Bitcoin/USDT Receive footer bounds. Those captures remain evidence for their original heads, not a fresh visual/Figma review of this integration.

QA Notes

Journeys

• new paykit-amount-layout.xml — request/subscription alignment, fresh USDT amount entry, preserved cents, compact controls, divider and enlarged-text reachability.
• new usdt-wallet-receive-layout.xml — wallet slide, Receive footer stability and hardware vendor label.
• updated contact-request-or-pay.xml — selected-row progress and duplicate-payment guard, with endpointless-contact failure and retry.

The amount journey now describes master’s single denomination toggle and BTC-only unit control, matching the iOS twin. Full manual journeys, paired hardware, live provider/funded flows and a fresh Figma comparison were not rerun for this integration. Component tests below do not establish those journeys.

Current integration validation — October 26

Validated exact tree 3e38bf9adb53512579f94598a90d6d2523f8ca30 against actual master 3ad6193b in a separate checkout and private Gradle cache with one worker:

• Required just compile, just test and just lint passed. All 4,597 unit tests across 253 suites passed, with no failures or skips. Full Detekt SARIF and Android Lint XML/SARIF/text reports contain zero findings. App and instrumentation APK builds passed.
• Both existing PaymentRequestAmountLocaleTest methods and QrCodeImageTest passed on a fresh isolated API 36 ARM emulator: 3 methods, 0 failures/ignored, 45.044 seconds. Coverage includes exact cents and dot entry under German configuration, hardware-key input, all 24 compact/font-size/denomination configurations and all 12 rendered QR payload/size combinations. No tests or assertions were removed or weakened.
• All 13 changed-path hashes remained frozen through validation and independent final source review. That review found no verified introduced defect. All 12 commits in the current-base PR range are cryptographically signed and verified locally and on GitHub (verified=true, reason=valid).
• Diagnostics were inspected in full. Retained notices include the Detekt plugin’s deprecated Gradle reporting API, JVM class-sharing notices, a unit-test manifest removal notice, and four unclosed MatrixCursor warnings from unchanged SharedPubkyProviderTest/provider code. Those source/build inputs are byte-identical to actual master; no actual-base runtime reproduction is claimed. Device framework/renderer/ABI/Settings/GC notices are retained. This is not a warning-free runtime claim.

Fresh hosted CI on 222df831 is pending; local results do not substitute for its completion.

Earlier validation

At the prior published head aba8c0f8 and its then-current #1564 parent, compilation, 4,375 units, full Detekt/Android Lint and parent contact/payment-list checks passed. Earlier device checks covered amount entry, contact loading, Receive sharing/navigation and four USDT bridge-detail cases. Earlier empty-wallet navigation/Receive checks and source-reviewed hardware labels retain their original head/environment attribution; no fresh paired-hardware journey is implied.

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The changes affect several wallet and payment screens within the Android app.

The PR appears safe to merge, with a non-blocking layout issue on shorter amount sheets.

Findings

1.  Continue gets cut off ▶

Summary

This PR makes the USDT wallet background opaque and shares hardware vendor labels across Receive tabs.

• Payment and subscription amount screens keep controls aligned below the amount.
• USDT Receive keeps the hardware label and bottom spacing when tabs switch.
• The USDT wallet fills its screen with a black background.
• The contact payment journey spells out its loading and duplicate-flow checks.

_{Reviews (1) · Last reviewed commit: "fix: stabilize usdt wallet and payment l..." · Reviewed by Greptile}

[github-actions]

Regtest APK

Built from 222df83 (run).

Download bitkit-dev-debug universal APK (expires in 30 days).

[talosmachina]

No findings. Gives the USDT wallet an opaque background so the default slide no longer shows Home through it, keeps the Receive footer and hardware tab label stable on the USDT tab, and moves the request/subscription BTC/USD and unit controls into one trailing FlowRow above the divider. Reviewed 6da6a73, full tier, reasoned from the code and CI; the branch was not built here.

What I checked, and 5 candidates I ruled out

Read in full: CreatePaymentRequestScreen.kt (amount content and asset selector), UsdtDepositReceiveScreen.kt, the USDT branch and tab row of ReceiveQrScreen.kt, UsdtWalletContent in UsdtWalletScreen.kt, NumberPad.kt sizing, FillHeight in Spacers.kt
Call sites traced: PaymentRequestAmountContent (Receive sheet request flow and CreateSubscriptionScreen), UsdtDepositReceiveScreen (only ReceiveQrScreen), the Routes.UsdtWallet entry (deepLinkableComposable, default slide transitions)
CI: lint, detekt, build-local green; build and the local e2e shards still running at review time

Ruled out

• USDT wallet still fades: the route already uses the default slide transitions; the fade in #1519 was the transparent root Box showing Home underneath, and Colors.Black matches SavingsWalletScreen and SpendingWalletScreen.
• Hardware label lost on other USDT pages: the tab row only renders on ReceivePage.ADDRESS, and the same remembered tabLabels map now feeds both tab rows.
• Extra 16dp bottom spacer shifting the USDT sub-pages: it sits after every UsdtDepositReceiveScreen page equally and mirrors the VerticalSpacer(16.dp) under the Bitcoin footer button.
• Wrapped controls breaking the new test's edge assertions: with Arrangement.spacedBy(8.dp, Alignment.End) every wrapped line ends at the row's right edge, so divider.right == control.right holds whether or not the BTC row wraps.
• Continue clipped on short sheets: the column does not scroll and NumberPad sizes from the whole box height, so the two new FillHeight minimums add 28dp to the USD layout's fixed height (the BTC layout nets 28dp minus the unit row it dropped). Already raised in Greptile's thread on the Continue spacer, so not repeated here; the test only covers a 640dp box.

Merge confidence: 4/5, not built here and CI build/e2e still running; the short-sheet Continue question is open in the existing thread.

[ovi-reviewer]

Verdict: ⛔️ Request changes: the amount keypad becomes unreadable on short screens with large text.

The PR moved to df4d002 after this run; these results are for b4b8d2a.

Findings:

• MEDIUM app/src/main/java/to/bitkit/ui/screens/paymentrequests/CreatePaymentRequestScreen.kt:255: the request and subscription keypad shrinks with no floor.
  • heightIn(max = 300.dp).fillMaxHeight() gives NumberPad a fixed height, so it splits it into four rows with no minimum (NumberPad.kt:117). The other NumberPad call sites pass availableHeight and get 50–75dp keys.
  • The column does not scroll, so the keypad absorbs every dp that the larger amount and the wrapped BTC/USD row take.
  • On device, BTC digits are clipped at 360×640dp with 3-button navigation and 2.0× text (25dp keys), at 320×640dp with 2.0× and at 320×568dp with 1.6×. At 320×568dp with 2.0× the keypad is 6dp tall.
  • Continue stays fully visible in all of them, so the point in Greptile's thread is fixed, but the shortfall moved into the keys. A key floor plus a scrollable column, as synonymdev/bitkit-ios#1003 does with its ScrollView, keeps both.
• LOW app/src/main/java/to/bitkit/ui/screens/wallets/usdt/UsdtActivityDetail.kt:119: two USDT routes still show Home through their slide, the #1519 symptom.
  • A USDT row tapped on Home opens Routes.UsdtActivity, which renders UsdtActivityDetail with a root Column that has no background.
  • Cross-Network Deposits (Routes.UsdtDeposits, UsdtDepositsScreen.kt:223) has the same gap.
  • This PR fixes it only for UsdtWalletContent. On device both slide in with Home's balance and activity rows showing through, while Bitcoin activity detail is opaque.

QA for b4b8d2a: 2 of 3 tests passed, on two Pixel 9 emulators (API 36) with a paired Trezor (emulator). Test 1 failed on its compact, enlarged-text step.

Test 1: paykit amount layout ❌ Layout and 1.50 USD pass at full size, but the keypad digits are clipped on short screens with large text.

• At 411×923dp the request Amount (Receive › contacts › Bob) and the subscription Amount match the journey in BTC and USD:
  • the amount is leading-aligned
  • BTC/USD and the unit button are trailing-aligned below it
  • a divider sits above the keypad, with Continue below
• 1.50 USD stays 1.50 USD on request details. A USD subscription keeps only USDT selected, with Savings showing +. Nothing was sent.
• I opened a fresh sheet for each size. Continue was fully visible at every size. Key heights by size:
  • 320×640dp, 1.6×: 35dp, legible
  • 360×640dp, 3-button, 2.0×: 25dp, clipped
  • 320×640dp, 2.0×: 20dp, clipped, and the BTC/USD row wraps to two lines
  • 320×568dp, 1.6×: 18dp, clipped
  • 320×568dp, 2.0×: the keypad is 6dp tall
• The still shows 320×640dp/1.6× and 360×640dp/2.0× on top, and 320×568dp at 1.6× and 2.0× below. Taps on the clipped keys still register: 1000 sats entered at 360×640dp/2.0×.

case1-request-amount-2x.2x.mp4

case1b-subscription-amount-2x.2x.mp4

case1c-compact-keypad-2x.2x.mp4

Test 2: usdt wallet receive layout ✅ The USDT wallet slides like Savings, the Receive footer holds on every tab, and the Trezor label holds on USDT.

• Animations were slowed 5× to show the slide. USDT opens and closes over Home as opaquely as Savings.
• Show Details kept the same on-screen bounds, read from the layout dump, on Trezor, Savings, Spending and USDT across 10 switches.
• USDT shows Network: Arbitrum One. The network list opens and returns with the network still visible, and Show Details opens details.
• The hardware tab reads "Trezor" on every tab, USDT included.
• The same holds at 320×640dp with 1.6× text.
• Side check for the LOW finding: the still shows USDT activity detail and Cross-Network Deposits mid-slide over Home. The third video shows Bitcoin activity detail sliding in opaque for comparison.

case2-wallet-receive-2x.2x.mp4

case2c-compact-receive-2x.2x.mp4

case2b-usdt-siblings-2x.2x.mp4

Test 3: contact request or pay ✅ Only the selected row loads, all rows are disabled, a second tap opens nothing, and a failure re-enables selection.

• Contact Detail Pay opens Request or Pay. Pay shows a spinner with Request disabled, and the send amount sheet opens about 2.5 s after the tap. Request opens the Payment Request amount screen.
• In Send › Contact, tapping Bob puts the spinner on Bob's row only, and both rows are disabled. Tapping the other contact meanwhile changes nothing, and one amount sheet opens for Bob.
• A contact with no published endpoints shows "Unable To Pay Contact" after about 15 s of row spinner, and both rows are enabled again. Nothing was paid.

case3-contact-select-2x.2x.mp4

Coverage:

• The review covered fccb1f9..b4b8d2a in full, and every changed screen was driven.
• 3c1adce, pushed during this run, changes the amount layout and is not covered here.
• PaymentRequestAmountLocaleTest passes at this head because it checks that the keys are displayed, not their size.

Twin: synonymdev/bitkit-ios#1003 makes the same layout changes, and its three journeys match this PR's. It scrolls the amount screen at large text; Android has no scroll here (finding 1).

[jvsena42]

Code scan: no findings.

Checked and clean:

• Amount entry: PaykitAmount.parseInput, the decimal key and the separator display are unchanged, and the typed amount is the amount that reaches Continue.
• PaymentRequestDenominationLayout measures both denominations and places only the active one. The hidden one has its semantics cleared and is not hit-testable.
• The BringIntoViewSpec override only stops auto-scroll while the keypad has focus, so scrolling to Continue still works.
• ReceiveQrScreen tab labels are shared, and no address or URI state is touched.
• The USDT wallet, activity and deposit changes are background-only.
• No state is cleared, so there are no Back or cancel paths to check.

The two new journeys are byte-identical to synonymdev/bitkit-ios#1003. contact-request-or-pay.xml differs only in platform tags.

Device gate (partial): not run yet. Pending: paykit-amount-layout.xml, usdt-wallet-receive-layout.xml and contact-request-or-pay.xml, plus a Figma check of the changed screens. Perf: not relevant. The device result follows in a second review.

[piotr-iohk]

QA review

Scope: Full review of the complete PR diff against merge base fccb1f9a, at 2291408. No earlier assessment baseline was available.

No new actionable code findings.

The amount sheet scrolls and keeps the keypad on its normal 50–75dp key height, so a short screen reaches Continue without shrinking the keys. USDT wallet, activity, and deposit details use an opaque black root under the same slide as the other wallets. The USDT Receive tab keeps the hardware vendor label and places Show Details on the same 16dp bottom inset as the Bitcoin tabs. The contact journey text matches the existing selected-row loading and duplicate-payment guard. Compared with bitkit-ios#1003 at b087c501 for this amount and Receive layout.

The keypad-clipping comments on b4b8d2a are addressed at this revision (thread). Build succeeded at this head. This review inspected PaymentRequestAmountLocaleTest and did not run it or a device pass; the author reports those checks passed. Device testing: not performed in this review. Ready for device testing of the three journeys in the PR.

[piotr-iohk]

@ben-kaufman please resolve the merge conflicts. QA review has not been performed for this request.

[ben-kaufman]

Rebased onto the updated #1564 and resolved the shared journey conflict, preserving both the duplicate-selection check and explicit failure/retry setup. All five rebased commits are signed; the existing layout changes are preserved. Compile, 4,334 unit tests and complete lint pass with no introduced findings. The combined request-card and amount-layout device suite also passes (16 tests, including all 24 amount-layout configurations). Ready for another QA pass.

[piotr-iohk]

QA review

Scope: Full reassessment of the complete PR diff against merge base 595951a0, at 03e1952. The comparison base changed since the saved assessment, so no earlier coverage was inherited.

No new actionable code findings.

The amount sheet scrolls and keeps keypad keys on the component's normal 50–75dp height, so a short screen can reach Continue without shrinking the keys. Focusing the keypad does not scroll the amount off screen. BTC and USD are measured together and only the active one is placed, so switching denomination does not move the controls, divider, or keypad. Continue submits the active BTC view-model amount or the USD string. USDT wallet, activity, and deposit roots are opaque black under the same horizontal slide as the other wallets. USDT Receive uses the shared hardware-tab label and the same 16dp bottom inset as the Bitcoin tabs. The updated contact journey matches the existing selected-row spinner, disabled rows, and endpointless retry.

Compared with bitkit-ios#1003 at b087c501: the amount screen also splits leftover height above and below the keypad, and paykit-amount-layout.xml and usdt-wallet-receive-layout.xml match. The contact journey differs only by platform identifiers and an explicit endpointless retry. On a tall sheet that split leaves the keypad lower than the cited amount frame, which keeps the keypad against the divider; short screens have no leftover space. The keypad-clipping comments on older commits are outdated at this revision (thread).

Build and lint succeeded at this head. This review inspected PaymentRequestAmountLocaleTest and did not run it. Device testing: not performed in this review. Ready for device testing of paykit-amount-layout.xml, usdt-wallet-receive-layout.xml, and contact-request-or-pay.xml.

[ovi-reviewer]

Verdict: ⛔️ Request changes: the new compact Receive QR scan step fails.

Findings: No new code findings. Both earlier findings are fixed: the keypad keeps its normal key height and scrolls, and the USDT activity/deposit roots are opaque. The compact QR failure below also occurs with the new Receive bottom inset removed; I am not attributing it to that change.

QA for 03e1952: Android 16 emulators, regtest and test USDT. I built the app at this head. No payment or request was sent.

Test 1: request and subscription amount layout ✅ BTC/USD keeps the controls and keypad stationary, 1.50 USD reaches details, and compact enlarged-text entry scrolls to Continue.

• Both live callers retain the amount. Subscription details select USDT and deselect Savings.
• At 320×568dp with 200% system text, the initial amount remains visible. The wrapped controls and divider keep their positions across BTC/USD. Scrolling exposes the full keypad and Continue; the live keys measure 75dp high.
• PaymentRequestAmountLocaleTest passed on device. Its assertions check every key's minimum height and vertical text fit, stable denomination positions and scrolling across 24 layout configurations, plus exact comma-decimal submission.
• Positions and sizes were checked from UI bounds and rendered-text assertions. Both forms were closed without publishing.

amount-normal.2x.mp4

amount-compact.2x.mp4

amount-regression.2x.mp4

Test 2: opaque USDT activity and deposit routes ✅ Received-USDT details and Cross-Network Deposits slide over Home without showing Home through the destination.

I opened the received 25 test-USDT activity from Home and opened Cross-Network Deposits through Receive. Slowed transition frames show an opaque destination in both directions. Deposit history was empty; there was no saved provider-deposit detail to open. History and detail share the changed root background.

opaque-routes.2x.mp4

Test 3: compact Receive Copy and displayed QR ❌ Copy works, but the displayed USDT QR cannot be scanned at 320×640dp with 160% text.

• QR, Edit/Copy/Share, Network and Show Details remain separate. Copy leaves Receive open and puts the exact plain address on the clipboard, verified by pasting it into the contact input.
• Bitkit's gallery scanner rejects the captured display with No QR code found in the image. Core Image and ZXing also return no decoded code.
• At normal size, ZXing decodes the head's captured display to the correct Arbitrum URI and the same receiving address.
• A comparison build removing only this PR's new 16dp Receive bottom inset still produces a compact QR that ZXing cannot decode. The QR renderer is unchanged in this PR, so this is an existing limitation exposed by the new journey step.

compact-usdt.2x.mp4

compact-scan.2x.mp4

Normal-size control:

normal-usdt-control.2x.mp4

Comparison without the new bottom inset:

receive-before-inset.2x.mp4

Retained passing evidence for unchanged paths:

• The earlier review proves the original wallet slide, Receive footer stability, paired Trezor label, contact-detail flow and contact-row loading/failure behavior.
• The stacked PR's contact report proves endpointless failure followed by payable-contact retry. The contact runtime is unchanged here.

No planned case is unrun. A fresh Figma comparison was unavailable. The original hardware-label and footer checks were not repeated because their runtime code is unchanged.

Scope: inspected the requested b4b8d2a..03e1952 tree delta and both earlier findings. Because the branch was rebased, I also re-reviewed the full PR against 595951a0. Test, journey and changelog edits were source-reviewed; the live changed amount and background components were driven.

Twin: synonymdev/bitkit-ios#1003 fix: stabilize contact selection and amount layouts matches the amount stability, scrolling and shared journey intent. Its compact QR fix scales the logo; Android's QR renderer is unchanged. iOS was not rebuilt in this run.

[ben-kaufman]

Fixed the compact QR scanning failure in 47ffa20. The center logo now scales with the displayed QR bounds, matching iOS #1003. A real composable capture/decode test reproduced the previous ChecksumException and now passes for Bitcoin and USDT (with and without an amount) at 120, 160, 240 and 320dp. QR contents and copy/share payloads are unchanged. All 4,334 unit tests pass, the rendered QR test passes, and the full detekt report has no new findings. Independent review found no remaining issue in this fix.

[ovitrif]

@ben-kaufman one small addition for UsdtWalletScreen: the other wallet screens also chain .blockPointerInputPassthrough() after the background, so taps can't fall through to Home during or after the slide. Suggest Modifier.fillMaxSize().background(Colors.Black).blockPointerInputPassthrough() (from to.bitkit.ui.shared.util). I closed the duplicate #1589 in favour of this PR.

[ben-kaufman]

Integrated the updated #1564 parent in 83d34cd, resolving the stacked-branch conflict while keeping this PR based on #1564. The integration preserves master's app-locale handling and Receive wraparound gestures alongside the amount and footer layouts.

Validation: required compilation, all 4,375 unit tests, zero Detekt findings and zero Android Lint issues. Both locale/layout component tests pass on the isolated emulator, including all 24 compact/enlarged-text configurations. The German-locale fixture now supplies the app configuration that production uses. No payment or wallet reset was performed.

[jvsena42]

Device gate (partial 2): a4ce71c on Pixel_9 (emulator), USDT on.

paykit-amount-layout.xml: 7/7 passed (contact GateIOS, the iOS simulator wallet, linked).

• USD 1.50: the amount is leading near the header, the BTC/USD chips trail below it, then the divider and keypad.
• BTC ↔ USD ×3: the chips, N1, NRemove and Continue keep their y positions, and USD always comes back to exactly 1.50 (BTC 1840-1841 sats).
• 360×640 dp at font scale 1.3 and 2.0: keys stay legible and Continue is reachable by scrolling. Continue goes to details with $1.50 and recipient GateIOS.
• A subscription amount from $0 accepts 1.50 without deleting first, and reopening keeps it.
• Details accept USDT only. Tapping Savings switches to Savings only, ₿1 841; the two groups are never both selected.

payment-requests/contact-request-or-pay.xml (against the iOS wallet's published endpoints): steps 1-6 and 8-13 passed.

• RequestOrPaySheet appears, Pay shows its spinner while Request is dimmed, and Request opens PaymentRequestAmount.
• Step 7, "amount screen within 3 s", took 5-7 s twice. The PR doesn't touch this path, and no log line falls between the tap and the resolution. This looks like staging homeserver latency but is unverified until compared with master:

  10:41:58.378 Opened private Paykit payment for 'pubkyx6…bu1f1dy' using payment list version 79   (tap 10:41:51.4)
  10:42:42.440 Opened private Paykit payment for 'pubkyx6…bu1f1dy' using payment list version 79   (tap ~10:42:37)
  

• Step 14 is not finished yet.

Seen while testing, not from a journey action: changing the display size or font scale while the Payment Request sheet is open recreates it at Amount with 0 BTC, which loses the entered 1.50 and the details step.

Still running: step 14, step 5 of usdt-wallet-receive-layout.xml (hardware tab), the Figma comparison, and a master timing for step 7.

[jvsena42]

Device gate (partial 3): a4ce71c, usdt-wallet-receive-layout.xml step 5, with the Trezor emulator paired over Bridge ("Bitkit Test Trezor").

• Step 5: passed. The tabs are Trezor, Savings, Auto, Spending and USDT. Across three Trezor ↔ USDT switches the hardware tab reads "Trezor" every time, never "Hardware". The Trezor QR is bitcoin:bcrt1q5vqa… and the USDT QR is ethereum:0xFd08….
• Step 7, hardware part: passed. At 360×640 dp and font scale 1.3 on USDT, "Trezor" stays whole and the network and bottom controls stay visible. With five tabs the other labels ellipsize ("Savin…", "Spen…").

usdt-wallet-receive-layout.xml is now 7/7.

Figma, with frames from the Refactor v63 page (docs/screens-map.md):

• Request payment enter amount: amount leading, chips trailing, divider above the keypad, as designed. The frame's "SAVINGS ▾" dropdown with a "⇅ BTC" toggle and its converted-amount caption differ from the BTC/USD chip pair, but master has the same.
• Unified QR: the logo is about 0.18 of the QR width, matching the frame.
• Wallet USDT (funds & activity): matches.

No delta comes from this PR.

Still running: step 14 of payment-requests/contact-request-or-pay.xml, and a master timing for its step 7.

[piotr-iohk]

QA review

Scope: Full reassessment of the complete PR diff against merge base 43be1a92, at 83d34cd. The comparison base changed since the saved assessment, so no earlier coverage was inherited.

No new actionable code findings.

A zero non-BTC amount starts from an empty input, so the first digit is accepted, while a positive amount still restores its input text. Both denomination rows are measured and only the active one is placed, with semantics cleared on the hidden row. The keypad keeps its normal key height inside a scrolling column, and keypad focus does not pull the amount off screen. Compact QR logos scale to 20% of the displayed code, capped at 68dp. The USDT wallet, activity, and deposit screens are opaque, the wallet blocks touch passthrough, and USDT Receive keeps the hardware vendor label and the same 16dp footer inset as Bitcoin.

Validation: PaymentRequestAmountLocaleTest and QrCodeImageTest were inspected at this revision and not executed. Detekt and Android Lint succeeded on this commit. Device testing: not performed in this review.

Compared with bitkit-ios 56635438: a zero USD amount there is still initialized from its formatted input, and the QR logo stays a fixed 68pt.

Ready for device testing.

[jvsena42]

Approving. No issues found; the code-scan trace is in my earlier review today. The 83d34cd / 43be1a9 merges resolve import-only conflicts, so the device results from a4ce71c carry over. contact-request-or-pay.xml ran on 83d34cd.

Device gate: 83d34cd — journeys: 27 passed, 1 failed on environment (usdt-wallet-receive-layout.xml 7/7, paykit-amount-layout.xml 7/7, payment-requests/contact-request-or-pay.xml 13/14, step 7 over its 3 s budget on master too); perf: contact → amount screen 3.7-7.1 s vs master 4.4-6.6 s; Figma: 3 frames compared (Request payment enter amount, Unified QR, Wallet USDT), no delta from this PR; l10n: no UI text changed, checked at 360×640 dp with font 1.3 and 2.0; iOS: synonymdev/bitkit-ios#1003 has one LOW (QR offset) open.

Ran on Pixel_9 (emulator), with the Trezor emulator paired over Bridge for the hardware-tab step.

• Step 7 of contact-request-or-pay.xml ("amount screen within 3 s") misses its 3 s on master too. All the time sits before Opened private Paykit payment…, which is the private payment-list fetch from the staging homeserver. That makes it environment latency, not this PR; the journey's 3 s budget doesn't hold on staging.
• Step 14: a second tap while one contact loads starts no second flow. The no-endpoints contact shows "Unable To Pay Contact" after about 31 s of public resolution (PrivatePaykitRepo.kt:1172 → :866), and the list is selectable again afterwards.
• Seen while testing, not from this PR: changing the font scale or display size with the Payment Request sheet open recreates it at Amount with 0.

[piotr-iohk]

QA review

Scope: Re-reviewed the full PR at aba8c0f after no verified baseline coverage was supplied and earlier reviews used different merge bases. The complete diff against merge base afcf6ff was inspected, including amount entry, compact QR logos, USDT opacity and tap blocking, Receive footer alignment, and the contact-selection journey wording.

No new actionable code findings.

Fresh zero-dollar request and subscription amounts start empty so the first digits register, while a nonzero amount still restores inputValue and its cents. The keypad keeps its normal key height in a scrolling body, and keypad focus does not scroll the amount away. The center logo is 20% of the displayed QR, capped at 68dp. USDT wallet, activity, and deposit roots are opaque black, and the wallet blocks tap passthrough the same way as Savings and Spending. The USDT Receive tab keeps the hardware vendor label and the same 16dp footer inset as Bitcoin. The updated contact journey matches the existing single-resolution guard.

This review did not execute tests or a device. The layout and journey sources match 83d34cd, where an earlier device pass reported the new amount and Receive journeys passing; that run was not repeated here. The final parent merge only brings contact and receipt files that match the base. iOS default bcaa461 was compared for QR overlay size and zero-dollar seeding only; bitkit-ios#1003 was not reviewed.

Device testing: not performed in this review.

Ready for device testing.

[piotr-iohk]

Approve at aba8c0f. Current-head code review found no actionable issues. Earlier device coverage remains applicable to the unchanged amount and Receive layouts, including fresh USD entry, preserved cents, compact scrolling, QR decoding and hardware labels.

[ovi-reviewer]

Verdict: ✅ Approve

Findings: None.

QA for aba8c0f: Android 16 emulators (Pixel 9), with the app and instrumentation built at this head. Recordings play at 2×. No payment, request or subscription was sent.

Test 1: amount locale and compact layout ✅ Fresh comma-decimal input submits exact cents, and the layout regression passes.

PaymentRequestAmountLocaleTest exercises the production amount component with the app's German configuration. Its assertions verify exact 150.50 USD submission, initial amount visibility, hardware-key input, stable BTC/USD controls, keypad height and text fit, and scrolling to Continue across compact sizes and enlarged text.

Test 2: Contact Detail preparation timing ✅ Pay shows progress and opens the amount screen within the three-second target.

On warmed, mutually linked test wallets with regtest funds, Pay shows its spinner while Request is disabled. A timestamped full-screen capture shows Bitcoin Amount fully visible by 2.94 seconds after the touch began; the recording shows the same transition. Back cancels without paying. This proves the target for this run; earlier staging runs reported slower preparation.

Retained passing evidence for unchanged paths:

• The earlier amount and Receive review proves live fresh request/subscription entry, preserved cents, compact Copy and displayed-QR scanning. The locale integration is rechecked above.
• The completed layout journeys prove wallet/activity opacity, Receive footer and network controls, and the paired Trezor vendor label. Those implementations are unchanged since 83d34cd.
• The parent's contact device report proves the merged contact handoff survives rotation and font-scale recreation without reopening after Back. Its report also covers duplicate-selection prevention and endpointless failure/retry.
• The parent's device review proves Receive edge-tab wraparound and QR tap behavior in the exact code integrated here.

Scope: contiguous a4ce71c to aba8c0f delta, including both parent merges and the earlier findings. Other merged-base UI, resource and lint changes were source-reviewed only; no fresh Figma comparison was performed.

Pair PR: synonymdev/bitkit-ios#1003 fix: stabilize contact selection and amount layouts at 17e6533 matches the zero-dollar guard, proportional QR logo and shared layout-journey intent. iOS was source-compared only.

---

Reviewed by gpt-6.1-sol-high via gh-pr-review-loop skill
Commands: @ovi-reviewer review · test · retest

[ovitrif]

utAck

The base branch was changed.

[ovitrif]

@ben-kaufman #1564 merged into master at 3ad6193, and this PR now targets master. It has conflicts with master and the base change dismissed its approvals, so it needs a rebase onto master, then a re-approval. #1588 is stacked on this PR and merges after it.

[ben-kaufman]

@ovitrif Integrated current master after #1564 merged, published as signed commit 222df83117ee3bac6a5d852a53f9726e7315befc. This is a normal additive merge, preserving the existing commits and downstream stack. The PR now targets master and GitHub reports it mergeable.

The resolution preserves master’s single denomination toggle/dot decimals and this PR’s stable amount/keypad layout. Required compile, all 4,597 unit tests (253 suites), full Detekt/Android Lint reports and APK builds passed. The isolated API 36 component run passed all 3 methods, including 24 layout configurations and 12 rendered QR combinations; independent frozen-diff review found no introduced defect. All 12 commits against actual master 3ad6193b verify locally and on GitHub (verified=true, reason=valid).

Fresh hosted CI is pending. Full manual/provider/paired-hardware journeys remain unchecked; earlier runtime evidence retains its original head attribution. The PR description now records the exact validation and retained diagnostics. Existing pending review requests are preserved; affected re-reviews will follow the required CI gate.

[ovitrif]

@ben-kaufman Merged, as it was approved and green.