The "transaction sent" animation erupted #, $ and ₿ out of the money sack. A
Wownero-first wallet that celebrates every send by throwing somebody else's
coin is advertising for them on the one screen a user reaches directly after
parting with their own money.
Adds Monero and Wownero glyphs and re-spaces the stagger across ten particles
so the fan stays even. WOW leads and is the largest, because that is the coin
this wallet is for.
The sprites are rendered at 128px from res/pictures/crypto_full_icons, which is
the same artwork the chain icons elsewhere in the app use, so the bag throws
the coins the rest of the UI draws rather than a second opinion about what they
look like. 128x128 RGBA to match the three that were already there.
The About screen has been showing Cake Wallet's app icon, and the receive QR
page — the screen a user screenshots to get paid — has been showing Cake's
wordmark. In CI builds only, which is why nobody caught it.
compile_graphics.sh compiles res/pictures/*.svg into assets/new-ui/*.svg.vec,
and every platform workflow runs it. That makes res/pictures the source and
assets/new-ui the output. The August de-cake pass replaced three files under
assets/new-ui and left res/pictures untouched, so each CI build faithfully
recompiled Cake's artwork straight over the top of ours. Locally it looked
right, because locally nobody re-runs the compiler.
Three files, all of them branding: hash_squircle_icon.svg, hash-wordmark.svg,
hash-wordmark-light.svg. The sources are now the Hash Bags artwork, so the
compiler produces what the filenames have claimed since August.
This is the third time somebody else's artwork has reached users through this
repo, and the second time an audit missed it, so it gets a test rather than
another careful look: any SVG present in both res/pictures and assets/new-ui
must be byte-identical. Drift means a hand-edit that the next CI build will
silently revert. The test also asserts it compared something, because a silent
zero is how the previous two got through.
AGENTS.md has had the rule the whole time: generated files are never
hand-edited, fix the source and regenerate. The trap here is that the generated
copies sit beside the sources under identical names, and the ones the Dart code
references are the generated ones.
Three desktop targets, three different states, one destination.
macOS did not build at all. There was no workflow, only Cake's from-source
scripts and an Xcode project. It turns out most of the work was already done:
monero_c ships aarch64-apple-darwin and x86_64-apple-darwin, and
Runner.xcodeproj already references both dylibs with CodeSignOnCopy. So this
fetches the same prebuilt bundle the iOS and Android legs use, lipos the two
slices into universal libraries, and builds. One download serves Apple Silicon
and Intel, because a single-arch build looks correct on the machine that made
it and fails on half of everyone else's.
It signs with a Developer ID Application certificate, which is NOT the Apple
Distribution certificate the TestFlight workflow uses. They are not
interchangeable: an App Store cert on a directly downloaded app is refused by
Gatekeeper. Signing is inside-out by hand rather than --deep, which Apple
deprecated and which skips nested code it does not recognise. Then notarytool
with the App Store Connect key this repository already has, then stapler, so
Gatekeeper clears the app without a network round trip.
Every credential is optional and the preflight says, before spending forty
minutes, exactly which stages the run can reach and what the user will see if
it cannot reach them. Absent secrets downgrade the build loudly; they do not
fail it and they do not pass silently.
Windows and Linux already built. Windows already Authenticode-signs through the
Fleet broker. What both lacked was a way to get the artifact to anybody:
upload-artifact is the only publication and Gitea Actions artifacts here upload
and then list as zero, so the signed Windows zip has never been reachable. Both
now publish to the GitHub release, on the smirk pattern: tag-triggered, the
release must already exist so a half-populated one never goes public, and a
same-named asset from an earlier attempt is replaced rather than duplicated.
Windows does its API work in PowerShell because git-bash there has neither
python nor node guaranteed and ConvertFrom-Json is native.
Tags now build automatically on all three. A tag is the thing a release is cut
from, and the artifact that gets signed should come from it rather than from
whatever was dispatched by hand.
scripts/release/sign-release.sh detach-signs the collected artifacts and signs
SHA256SUMS, which is the signature that matters when a download reaches someone
from a mirror without its .asc. It verifies even immediately after signing: a
signature written but never checked invites trust it has not earned.
Not done here, and both need a human: GH_RELEASE_TOKEN does not exist in this
repository's Gitea secrets, and the release key's user ID still says Smirk.
Windows built 1.0.3 against Flutter 3.38.5 while every other platform used
3.32.0. Dart 3.10 removed the _macros package, so pub could not solve
hive_generator against build_resolvers and the build died in dependency
resolution, on the same commit Android and Linux had just built cleanly.
The SDK was not missing. C:\flutter is exactly where provisioning puts it and
exactly what PATH resolved; it had been upgraded in place. Provisioning never
corrected it because it skipped on Test-Path alone, so a drifted SDK was
reported as done every time it ran. It now compares the version and replaces
the SDK when it does not match, which is the actual fix and the reason this
went unnoticed for however long the machine has been ahead.
The workflow stops guessing. My first attempt installed Flutter per build via
subosito/flutter-action, which fails on this runner anyway because its setup
script needs jq, and which would have downloaded a gigabyte every run to work
around a machine provisioning already owns. It now refuses early and prints
what is wrong and which script to run.
A build machine's toolchain must not decide which dependencies resolve, and
when it has drifted the build should say so rather than fail eighty steps
later inside pub.
No app code changes; hash-bags-ios-1.0.3 stays at 0697f41c7. Android and Linux
artifacts from that commit are unaffected.
Windows took whatever Flutter the runner happened to have. On 2026-09-19 that
was 3.38.5 with Dart 3.10.4, and Dart 3.10 removed the _macros package, so pub
could not solve hive_generator against build_resolvers:
macros >=0.1.3-main.0 depends on _macros from sdk which doesn't exist
So, because hash_wallet depends on both build_resolvers ^2.4.4 and
hive_generator ^2.0.1, version solving failed.
The build died at exit 69 before compiling anything, on the same commit that
Android and Linux built successfully minutes earlier. They differ only in
that both run inside the cake_wallet debian13-flutter3.32.0 image, and iOS
installs 3.32.0 explicitly. Windows was the only platform whose dependency
resolution was decided by a machine somebody had updated.
It now checks for 3.32.0 and installs it when absent, the same two steps iOS
already uses. No app code changes; hash-bags-ios-1.0.3 stays at 0697f41c7.
The detection branch found the toolchain, wrote RUSTUP_HOME and CARGO_HOME to
$GITHUB_ENV, and then verified with `rustc --version` in the same step.
$GITHUB_ENV only reaches later steps, so that verification ran with neither
variable set and the rustup shim fell back to %USERPROFILE%\.rustup. On this
runner that path is a file, so it failed with os error 183 while a perfectly
good toolchain sat at C:\Rust.
The step's own comment already explained why the shims need RUSTUP_HOME. It
just never exported it for its own use. The install branch does export before
its check, which is why only the detection path broke, and why it broke on a
runner that already had Rust rather than on a fresh one.
No app code changes, so hash-bags-ios-1.0.3 stays where it is: Android, Linux
and iOS are building from that commit and the artifacts are unaffected.
Audit of every surface that could show somebody else's logo. Most of it was
already ours: the transaction success screen draws hash_bag.png and the
hashbag_sym_* glyphs, cake_logo_light/dark.svg and the Android icon set were
redrawn from the Hash Bags mark in May and only kept their old filenames, no
user-visible string contains "Cake", and every cupcake reference is a
HardwareWalletType icon sitting next to Ledger and Trezor, which is interop
rather than branding.
Two places were not ours.
The Flatpak manifest installed cakewallet_icon_180.png as the Linux desktop
icon, and that file is upstream Cake artwork from 2025 that the rebrand never
touched. So the Linux build has been shipping a Cake Wallet icon. It now uses
the Hash Bags mark. The macOS icon script had the same fault, latent only
because no workflow builds macOS; it gets a proper Hash Bags set at all seven
sizes rather than a landmine for whoever turns that build on.
Deleted the Cake artwork nothing needs: cake_logo.png, cakepay.png, the three
cakewallet_icon_* files and the macOS set. assets/images/ is bundled whole, so
unreferenced files were shipping inside the binary regardless of whether any
code could draw them.
Also fixes a bug the audit turned up rather than a branding one. The theme
picker chose its preview icon by matching theme.title, which is built from the
accent colour's display name, so renaming an accent silently changed the icon.
It had: the list still named Cake Primary, Tron Red and Frosting Purple, none
of which ship, while our own Such Pink and Such Blue were absent and fell
through to the plain dark icon. It asks the theme what it is now, not what it
is called.
Version to 1.0.3+13. pubspec_description.yaml is the single source for all five
platforms; the checked-in pubspec.yaml is a build artifact.
Still there, reported not removed: cake_pay_icon.png, reachable only through
the Cake Pay order provider, which is the only provider, has an empty API key
and cannot produce an order in this app. Removing it means removing the orders
feature, which is not a branding change.
An error report that cannot be tied to a binary tells us a bug exists and
nothing about whether we already fixed it. Of the ten reports received since
May, five carry the Wownero addresses crash that shipped fixed in 1.0.2, and we
could only tell by reading timestamps buried in the traces themselves.
Two gaps, both closed here. The body carried "App Version: 1.0.0" without the
build number, and 1.0.0 shipped as Play builds 9 and 10 which encrypted under
different keys, so the version alone cannot identify the binary that wrote a
wallet we are being asked to heal.
And the body is the part of this flow we do not control. It reaches us only if
the user pastes what we put on their clipboard. On 2026-09-17 somebody typed a
sentence into the trace box instead, and the report arrived with no version, no
platform and no stack at all. So the app now also puts its version and platform
in the query string of the link it opens, where the form reads it rather than
the user. Someone who reaches the page without the app simply reports nothing,
which is honest and stays empty rather than guessing.
The Windows lane already runs on the machine that physically holds the Sectigo
EV code-signing token, but the runner there is NT SERVICE\act_runner, which
cannot use it: SafeNet holds the token login per user and an operator
establishes that login interactively. So the build queues the launcher for the
signing broker that Fleet installs (such-fleet roles/windows_code_signing) and
waits for it to come back signed.
CI never holds the private key -- it is non-exportable on FIPS 140-2 Level 2
hardware -- and never holds the token password. Sectigo allows three
consecutive failed password attempts before the token needs vendor unlocking,
and a job that never supplies a password cannot spend one.
Only HashWallet.exe is signed. The bundled MSVC runtime DLLs are already
Microsoft-signed and must not be re-signed, and the plugin DLLs are loaded by
an already-trusted process; it is the launcher the user double-clicks that
SmartScreen judges.
The signature, its RFC 3161 timestamp and the expected signer are verified on
the exe that actually goes into the zip, and any of the three failing fails the
build. If the broker's circuit breaker is tripped the job says so and stops
rather than shipping an unsigned binary.
Procedure: docs platform/windows-hardware-token-signing.md.
- res/pictures/balance_card_icons/wownero.svg had an opaque background rect
(+#FFF5FD fill), so the ChainIcon's srcIn colorFilter flooded the whole
circle solid grey. Replaced with a clean alpha glyph (white W-in-circle on
transparent, like monero.svg) so the dark bg shows through the negative
space. Source in res/pictures → compile_graphics.sh regenerates the .vec.
- dark theme surface #0B1F14 → #10281B (a bit less dark, per feedback)
Bundles wownerod (aarch64-linux-android, built via monero depends) as
jniLibs libwownerod.so; EmbeddedNode.java execs it from nativeLibraryDir
(the exec-exempt path), binds RPC on 127.0.0.1:34568 for the wallet, pruned
mode by default, capped concurrency for phone thermals. Dart EmbeddedNode
service (start/stop/status/waitUntilReady) drives it over a method channel.
Verified: builds into the APK (binary bundled, arm64), and the daemon
executes on real hardware (moto g stylus) — inits core, binds RPC, connects
peers, and syncs blocks. UI toggle + foreground-service lifecycle are the
next layer; binary is provisioned like the wallet libs (gitignored).
package:yaml (used by the app) throws 'Duplicate mapping key' on the two
useSSL entries; PyYAML tolerated it so it slipped through. Adds a test that
parses every bundled YAML asset with package:yaml to prevent regression.
- validate legacy-decoded wallet passwords are real generateKey() output
(696 chars, base64 of 512-byte key + 8-byte iv) so a wrong AES key that
unpads to printable bytes can't be re-saved as a bogus password
- test/legacy_decode_test.dart: proves 1.0.0->1.0.2 recovers PIN+password
and 16k wrong keys yield zero false-accepts
CI ran tool/generate_new_secrets.dart unpinned, so every release binary
shipped different AES keys/salts for the stored PIN and wallet passwords.
Updating the app then failed to decrypt what the previous build stored:
'Invalid or corrupted pad block' at PIN entry and the 'Corrupted seeds'
dialog, with wallet files fully intact.
- entities/encrypt.dart: legacy-key fallback decode for PIN and wallet
password blobs (candidate sets recovered from the shipped 1.0.1 binary;
output validated to reject PKCS7 false positives)
- key_service/auth_service: on successful legacy decode, re-encrypt under
the pinned key — installs self-heal at first unlock
- all build workflows: inject the eight pinned CRYPTO_* repo secrets after
secret generation and hard-fail if any is missing, so crypto salts can
never silently rotate again (values pinned via
~keys/set-gitea-crypto-secrets.sh)
- bump 1.0.2+12
App Store Connect warning 90068 on the last two uploads: from Spring
2027 all iOS apps must set MinimumOSVersion 15.0 or later. Raising from
13.0 costs almost no devices (iOS 15 still covers iPhone 6s and SE 1).
Rides the next iOS build.
generated/i18n.dart and several .g.dart parts are untracked generation
outputs too; without them a fresh checkout analyzes with thousands of
undefined_identifier errors. Run model_generator.sh and
generate_localization exactly as the build lanes do.
pubspec.yaml, the cw_* dependency wiring, wallet_types.g.dart, and the
.secrets.g.dart files are generated and untracked, so the workflow's
bare pub get failed on every push since the workflow landed. Mirror the
build lanes: description -> generate_pubspec -> coin configure ->
generate_new_secrets (empty defaults), then analyze and test. This also
makes the CI resolve identical to release builds, so descriptor drift
like the cake_backup ref conflict fails here in minutes instead of at
release-build time.
Pub requires identical git descriptors across the graph: the root's
pinned SHAs (pubspec_base) conflicted with cw_core's ref:main /
unpinned declarations, failing CI's pub resolve after the configure
step regenerates pubspec.yaml. Local resolution had masked it because
the untracked working-tree pubspec.yaml predated the pins. Pins now
identical everywhere (audit script confirms no remaining multi-ref git
deps); sibling lockfiles re-locked.
User report 05ebf86e: monero?.getCurrentAccount on a Wownero wallet. The
null-aware operator guards plugin presence, not wallet type, so the
Monero bridge always ran and CWMonero's cast threw before the ?? chain
could reach the wownero branch. Dispatch by wallet.type instead. Swept
lib for the same anti-pattern: account_customizer already dispatches
(fixed 2026-08-07) and the settings_store call sites take no wallet
argument; this was the last live instance.
Server-side forex (ECB daily reference rates) shipped in
hash-wallet-prices; the wallet needed no code change. Comment updated so
the file stops claiming USD-only.
- Wownero default becomes node.wownero.org:443 (SSL, ours) instead of a
third-party plaintext host
- Arbitrum's default was arbitrum.nownodes.io, which requires an API key
we don't ship (nowNodesApiKey is empty) — every fresh install had a dead
default RPC; now arbitrum-one-rpc.publicnode.com
- remove the other NOWNodes entries from node lists and the EVM chain
registry for the same reason; historical migration maps keep their
entries so old users still get migrated off
Deposit side: natives of shipped chains (WOW, XMR, BTC, BCH, DOGE, XNO,
ETH, ETH-Base, ETH-Arb, BNB, POL) plus major stables (USDT/USDC variants,
DAI). Receive side: same minus BNB (inherited upstream restriction) plus
LTC as a receive-only target. ZEC, DASH, SOL, AVAX, Zano, Haven, ADA,
EOS, XLM, XRP, TRX, TON and the rest disappear from the swap UI; their
CryptoCurrency entries stay defined because the raw ids back Hive-stored
trade history.
The 10 language wordlists were byte-identical between cw_monero and
cw_wownero (16,291 duplicated lines). A single copy now lives in
cw_core/lib/mnemonics/, and the configure.dart code-gen templates import
from there.
- Cake Pay: 36 files (~5.3k LOC) plus DI registrations, routes, and UI
branches (feature was hard-disabled and unreachable)
- unreachable buy providers: robinhood, dfx, onramper, meld, kryptonim
(~1.7k LOC); MoonPay untouched
- exchange providers that only existed as commented-out wiring:
changenow, sideshift, chainflip, exolix, swaptrade, letsexchange,
stealthex, xoswap, swapsxyz, thorchain, simpleswap (~5.2k LOC);
Trocador untouched; ExchangeProviderDescription values and Hive
adapters kept so stored trades and orders still deserialize
- di.dart setup() split from one 1,452-line function into 10 sequential
chunk functions; registration execution order verified identical
before and after (251 register calls)
Address-field input no longer leaves the device except toward
infrastructure implied by the typed name itself:
- remove Twitter, Mastodon, Nostr, Yat, Unstoppable Domains, FIO,
ThorChain-name, zcash.me, and Zano alias lookups (Nostr and FIO ran
with no setting gate at all; Zano is not even a supported chain)
- keep OpenAlias, BIP-353, .well-known, LNURL, and ENS, each toggleable
in Settings -> Domain lookups
- BTC fee/block/restore-height queries move from mempool.cakewallet.com
to public mempool.space (also fixes two /api/v1 paths that 404 on
standard mempool deployments)
- PRIVACY.md updated to disclose the remaining flows (mempool.space,
name lookups, opt-in silent payments and payjoin); issue templates and
the translation prompt de-Caked
- delete the stock Flutter counter widget_test (always failed) and the
lightning invoice tests (network-dependent, and the feature is off)
- fix rotted assertions: removed-chain wallet types (solana, tron, zano,
decred) and mainnet-only BTC/LTC pattern expectations
- new test.yml workflow: pub get + analyze + test on push/PR to dev/main
- analysis_options: drop excludes for deleted paths, stop excluding the
five live coin facades, enable empty_catches and 7 other correctness
lints (still 0 analyzer errors)
- integration_test_runner: clean hash_wallet data dirs, not cake_wallet
- resetToDefault omitted Wownero: the reset button null-crashed and left
WOW wallets with an empty node list
- accountLabel was missing a return and rendered blank for WOW wallets
- sec_random now throws instead of returning empty bytes when the native
entropy channel fails or under-delivers
- iOS builds no longer register the leftover cakewallet:// URL scheme
- WOW fee estimate now fetched from the connected daemon's
get_fee_estimate RPC and cached; the inherited XMR constant table
remains only as a pre-fetch fallback
- pin cake_backup, flutter_local_authentication, and bech32 git deps to
their locked SHAs for reproducible builds
flutter build windows materialises plugins under
windows/flutter/ephemeral/.plugin_symlinks/ as NTFS symlinks. Flutter gates
this on the AppModelUnlock registry key rather than the actual privilege, so
the build failed with "Building with plugins requires symlink support".
Sets AllowDevelopmentWithoutDevLicense=1 in HKLM (what the Settings toggle
does); LocalSystem can write it, so no interactive login. Idempotent.
storeshots.py (website-dark theme), storeshots_ipad.py (2048x2732), and
storeshots_play.py (1290x2580, Play's 2:1 cap). Compose the funded demo captures
onto the Hash Bags brand background for the store listings.
Replace the static success illustration with HashBagSuccessAnimation: the money
sack sits at the bottom and #/$/₿ glyphs erupt from its mouth, rising and fading
on a loop. Glyphs are PNG assets (the app bundles no font with a ₿ glyph).
InfoPage gains an overridable buildIllustration() hook (default unchanged:
static HashImageWidget); only TransactionSuccessPage overrides it, so every
other InfoPage is untouched.
NOTE: written without a local Flutter build (Dart pub can't resolve here) —
verify on the next CI/device build. Self-contained and revertible; the static
hash_bag.png remains the fallback via imageLightPath/imageDarkPath.
Send-success art: replace the Cake birthday cake with a Hash Bags money sack
that has a # on it and erupts #/$/₿ (assets/images/hash_bag.png). Used by the
success page, send-confirm sheet, exchange-trade, and dEURO savings.
Asset renames (files + refs):
- birthday_cake.png -> hash_bag.png
- restore_cupcake(.png/_dark) -> restore_hashbag.png
- qr-cake.png -> qr-hashbag.png
- arrow_bottom_cake_green.png -> arrow_bottom_green.png (+ 2.0x/3.0x)
Identifier renames:
- CakeImageWidget -> HashImageWidget (widget + file + 93 refs)
- typography _cakeRegular/_cakeBold/_cakeSemiBold -> _hash*
Transaction filter: drop the Cake Pay "Orders" row and every non-Trocador
trade provider; the swap gate is already Trocador-only, so this just aligns the
filter UI with reality.
Android launcher: add breathing room to the adaptive-foreground # (all
densities, monochrome included); iOS icon unchanged.
About page: swap the Cake easter eggs for Hash Bags ones.
Deferred (needs a build to verify): new-ui .svg.vec filename renames
(cake_squircle_icon, cakewallet-wordmark, cake-setting) — already Hash Bags in
content, only the filenames are cake, and they route through the .vec precompile.
Composes App-Store-ready 1290x2796 (6.9" iPhone) screenshots from the raw
1080x1920 harness captures: crops the mobile status bar (per-screen — deeper
for bottom-sheet modals), frames each capture with rounded corners + soft
shadow on the Hash Bags brand gradient, and burns a headline + subhead.
Copy is factual and benefit-driven (no price/return/"investment" claims) to
stay inside App Store Review 3.1.5 and the no-misleading-claims rules. Reads
brand colors/fonts from packs/hash/pack.json; needs Pillow.
Output (funded demo wallet, real 13.37 WOW): dashboard / receive / send / swap
under ~/Build/hash-wallet/demo/appstore/. Same source works for the Play
listing; frame + resize for other required device sizes as needed.
getWalletPassword force-unwrapped the secure-storage read, so a null iOS
Keychain result (item written by an older build under different Keychain
params, e.g. after a TestFlight update) hard-crashed the app and the wallet
showed "Corrupted seeds" — reported by a tester whose older Wownero and BTC
wallets broke on update.
Now it:
- falls back to the legacy readNoIOptions path (queries the OTHER iOS Keychain
accessibility), which can AUTO-RECOVER such wallets without a seed restore;
- falls back to the #__<name>_bak__# backup password the Monero migration
writes before re-encrypting;
- throws a catchable error instead of a null-check crash, so the loader can
offer seed/restore recovery rather than the app dying.
Only changes behavior on the previously-crashing null path — strictly safer.
Not the file cipher (iOS is always Salsa20) nor the Monero migration
(Wownero/BTC don't run it): the wallet files are intact, only the Keychain
password was unreadable. flutter_secure_storage stays pinned (ca897a08) and the
accessibility stays first_unlock; those must not change without a migration
(see docs/internal-notes.md).
Adds DEMO_WALLET_SEED/DEMO_WALLET_HEIGHT support so a demo build restores a
fixed (throwaway, funded) Wownero wallet instead of creating a fresh one, via
WalletRestoreViewModel.create. Balance lives on-chain against the seed, so it
survives any emulator wipe and is reproducible.
Three real bugs fixed on the way:
- build-apk.sh built the --dart-define args as a word-split string; the 16-word
seed's internal spaces split into separate argv tokens and flutter treated a
seed word as a build target ("Target file '<word>' not found"). Now a bash
array keeps each --dart-define one token.
- WalletRestoreViewModel.getCredentials reads name/passphrase from the options
MAP (not the vm field) and casts name as non-null String, so the restore
options must include 'name' and 'passphrase'.
- forward DEMO_WALLET_SEED/HEIGHT into the build container; source demo.env.
Verified end to end: demo build restores the wallet, its address matches the
funded one exactly (QR-decoded), it syncs at height 861800, and the dashboard
shows the real 13.37 WOW balance + tx history. Send shows Max 13.37.
The seed lives only in gitignored tools/demo/demo.env (never committed).
docs/internal-notes.md (gitignored) documents the FailedDecryption gotcha.
The iOS fastlane snapshot UITest already passes --dart-define=SCREENSHOT_MODE=
true; accept it as an alias for DEMO_MODE so the Mac screenshot path drives the
same demo-wallet boot without changing the UITest. Trivial const OR; validated
on next build.
Adds a debug-only capture mode so screenshots/video never depend on the
onboarding/PIN flow, whose synthetic taps are unreliable under the headless
emulator (both flutter_test and adb input drop taps on the PIN confirm screen).
lib/entities/demo_mode.dart: on launch, when kDebugMode AND
--dart-define=DEMO_MODE=true, create a fresh throwaway Wownero wallet through
the real WalletNewVM.create() (so walletInfo/derivation/paths/persistence and
changeCurrentWallet all happen exactly as in the UI), then set the PIN and
allow auth — landing on the dashboard. Reuses the wallet on later launches.
Both halves are compile-time const/kDebugMode, so this is tree-shaken out of
release: DEMO_MODE cannot be enabled in a store binary.
lib/main.dart: call maybeSetupDemoWallet() during bootstrap and force the
initial route to the dashboard in demo mode.
tools/demo/{build-apk,capture}.sh: DEMO=1 bakes the define into a local build;
flutter drive passes it so scenarios start at the dashboard.
Verified end to end: demo build boots to a live Wownero wallet and captured a
clean 1080x1920 store set (dashboard/receive/send/swap/settings) with no PIN.
This also implements the SCREENSHOT_MODE the iOS UITest scaffold already
references (store/SCREENSHOTS.md Path B).
Note: the API-35 emulator needs -gpu host (real GPU) for deep-page rendering;
-gpu software hard-crashes qemu on the Receive page. Stills use screencap
(screenrecord's encoder is unrelated).
Hardening from the first real end-to-end runs against the app:
- build-apk.sh: guard bitbox on the api.aar artifact (not the dir); unshallow
the reown_flutter tarball so prepare_reown.sh can checkout its pinned commit
(the tarball ships a shallow repo -> "unable to read tree"); generate reown
uniffi bindings when absent.
- capture.sh boot: API 35 + `-gpu software -feature -Vulkan`. API 36.1's guest
encoder is broken (screenrecord err=-38, screencap DMA assert) under both
swiftshader_indirect and -gpu host; API 35 works.
- capture.sh: defer screenrecord until the app is foregrounded (flutter drive
builds for minutes; the 180s cap must cover the scenario, not the build);
match the target device by AVD name so a co-running emulator isn't hijacked;
record to /data/local/tmp (headless /sdcard FUSE is flaky).
- README: document the API-35 requirement and reasoning.
integration_test/ has not compiled since 784a082f1 removed SOL/TRX/ZEC/DCR/
ZANO/Haven: common_test_flows.dart and common_test_constants.dart still
referenced WalletType.solana/.tron/.zano/.decred/.zcash/.haven and secrets that
were never generated, and wallet_keys_robot branched on .solana/.tron. Any
`flutter drive` over these components failed at kernel compile.
- common_test_flows.dart: drop removed chains from both wallet-type switches.
- common_test_constants.dart: default test wallet SOL -> WOW (Wownero-first;
SOL no longer exists), with a real WOW address.
- wallet_keys_robot.dart: EVM-only branch (solana/tron gone).
- common_test_cases.dart tapItemByKey: wait for the widget (up to 20s) instead
of pumping a flat 500ms then asserting. Screens behind an async transition
(PIN-setup success button) were a coin flip; this makes the failure honest
("not there after 20s") and the pass reliable. Pump loop, not pumpAndSettle,
since the dashboard sync animation never settles.
The Appfile and Runner.xcodeproj carried 32J6BB6VUS (a stale leftover). The
real Such Software LLC team is D8PL9F7X33. This did not affect CI signing:
build-ios-testflight.yml rewrites DEVELOPMENT_TEAM to the APPLE_TEAM_ID secret
before archiving, so TestFlight builds already signed with the correct team.
This aligns local Xcode and the fastlane snapshot path (which are NOT rewritten
by CI) with what CI actually uses.
Team IDs are public identifiers (embedded in every distributed app's
provisioning profile), not secrets.
jwinterm
such-gitea