github LedgerHQ/ledger-live live-mobile@4.22.0

3 hours ago

4.22.0

Minor Changes

  • #22003 40d296b Thanks @liviuciulinaru! - Record the provider app the Card login redirect names, and send x-us-env on every Card request of a US holder

  • #22149 4d1d640 Thanks @mcayuelas-ledger! - Add card reward wallet endpoint and mobile reward balance view

  • #21741 250c1c0 Thanks @tonykhaov! - Add a mobile card-numbers View/Hide control that flips to the provider numbers image

  • #22258 e82ab0c Thanks @mcayuelas-ledger! - Wire the card's Manage PIN and Access Baanx rows to open the Baanx hosted pages in the secure
    browser, and the Help row to open the support article externally.

  • #21520 0d90780 Thanks @pawell24! - Announce the receive QR code to screen readers

    The QR container on the shared receive confirmation screen carried a testID but no
    accessible prop, so it never joined the accessibility tree. It is now a focusable
    element with a role and a localized label, instead of being skipped or announced as
    an unlabeled node.

  • #21747 871e485 Thanks @claudiiafg! - Fix keyboard handling in the mobile Contacts add, edit, and send flows. Input sheets now open at full height with the keyboard, primary actions remain visible in a keyboard-aware QueuedBottomSheet footer, and name fields focus immediately and capitalize each word.

  • #22077 72367fc Thanks @mcayuelas-ledger! - Wire the card onboarding widget to real, derived onboarding data and remove the unused stub endpoint and legacy devtool mock path it replaces

  • #22093 2e94d90 Thanks @LucasWerey! - Fix available balance showing inflated value for DADA cross-network assets (e.g. Tezos + Etherlink)

  • #22192 c22ee67 Thanks @mcayuelas-ledger! - Add reusable Apple/Google Pay add-to-wallet CTA, instructions, and wallet-app opening.

  • #22218 285b50d Thanks @mcayuelas-ledger! - Open Google Wallet through its launch intent, and show iOS and Android error scenes when the wallet app is unavailable, with a Play Store fallback on Android.

  • #21999 724f029 Thanks @mdomanski-ext-ledger! - feat(aleo): share the bond pieces between Desktop and Mobile

    Replaces the ad-hoc messages getTransactionStatus returned for a rejected bond with typed
    error classes, translated on both clients and now distinguishing a closed validator from an
    unbonding one. Adds the isValidatorBondable / getMinBondAmount helpers to the coin
    module, moves the per-network default validator into the Aleo currency config so every
    client reads the same address, and adds a reusable Aleo bridge mock for Mobile.

  • #22336 b5d2be9 Thanks @mateuszpalosz-ext! - feat(aleo): add the claim unbonded staking flow on Mobile

  • #22137 353ed46 Thanks @mdomanski-ext-ledger! - feat(aleo): show the staking position and its status on the Mobile account page

  • #22123 b5338ec Thanks @mateuszpalosz-ext! - feat(aleo): add the shared staking hooks the delegation views read

  • #22212 49b535f Thanks @mdomanski-ext-ledger! - refactor(aleo): serve the validator committee from RTK Query

  • #22211 d137f01 Thanks @LucasWerey! - Offer biometrics on the unlock screen with the symbol the device actually uses.

    The field asked for biometrics with a generic touch symbol, because Lumen had no biometric one when the screen was built. It has since gained FaceId and Fingerprint, so a face device now shows a face and a fingerprint device a fingerprint.

    The device reports six kinds and there are two symbols: a touch is a fingertip on either platform, and everything the device reads from the face — iris and Optic ID included — takes the face symbol, since there is no iris symbol and an eye read is nearer a face than a fingertip. The capability is read asynchronously while the affordance comes from stored state, so the generic touch symbol still stands in for the moment before the device has answered, and for a read that fails.

  • #22275 35a5198 Thanks @LucasWerey! - Give a user protected by biometrics alone a way back when their face goes unread.

    The unlock screen already retried the prompt when tapped, but nothing said so: with no password set, a face the camera never saw left the Ledger mark on black and no visible way forward. The whole screen being the button is no help to someone who cannot tell there is a button.

    A real call to action now sits under the mark — "Unlock Ledger Wallet" — and it appears only once the prompt has gone. While the prompt is up the system dialog owns the screen, and at boot the bare mark is what keeps the handover from the launch screen invisible.

    The other half is the OS's and already works: while its dialog is up, the device credential the app asks for makes iOS draw "Try Face ID Again" and "Enter Passcode" itself. It is only after that dialog is cancelled, when nothing will reopen it, that the app has to offer the way back.

  • #22125 795e693 Thanks @LucasWerey! - Make biometrics a protection in its own right: password and biometrics become independent, and either one alone is enough to lock the app.

    Biometrics used to require a password. Its Settings row was disabled until one existed and reset itself whenever the password went away, and the legacy lock returned early without a password, so a biometrics-only user was never locked at all. The revamped path now derives the lock from both protections, so enabling biometrics alone locks the app — and Settings offers it with no password set.

    The row is hidden where the device has no biometrics, or has the hardware with nothing enrolled, rather than shown disabled: there is nothing the user could do about it from that screen.

    Biometrics is asked for before the unlock screen draws a field, so it is the first thing the user meets and the password is the fallback. While the prompt is up the screen stands in for the splash, with the mark at the splash's own size so the handover moves nothing. Only a refusal reveals the password field — and a user protected by biometrics alone never sees it: pressing the screen asks again, which is their only way in.

    The prompt is an explicit owner check through BiometricPrompt / LAContext, not a side effect of reading a protected keychain item. A biometry-gated read can resolve without the OS ever showing anything, and Android reports a correct device PIN as a success the keystore item cannot consume — either way the caller is told the user proved something they were never asked for. On Android 11 and above the OS draws its own "use PIN" button in place of the negative one, and every label it shows comes from the app rather than the library's English defaults.

    The keychain item is therefore a plain marker, not an authentication step: it records that biometrics is on, which the protection state cannot do on its own, being held in memory only. Enabling proves before it records, and a refusal stores nothing.

    The device credential is accepted, because biometrics can now be the only protection: a lockout after failed attempts would otherwise leave the owner with nothing to try. The consequence to accept is that someone who knows the device passcode can open the app — for a user who also set a password, the weaker path.

    Protection that outlived its install is destroyed at boot. iOS keeps keychain items when an app is deleted while Android wipes them, so a reinstall found the previous password and demanded it — for data that went with the uninstall, leaving an owner who had forgotten it locked out of an empty app, advised to reinstall, which is what they had just done. A marker in app storage settles which install the protection belongs to, since an uninstall clears that and not the keychain. The cost, worth stating: clearing app data now clears the lock too, which follows from the threat model this epic assumes — opportunistic access control, not data protection — since anyone who can wipe the data can reinstall anyway.

    Removing biometrics asks for it too. Removing a password requires typing it, so removing biometrics must cost as much: an unlocked phone in someone else's hands would otherwise strip the protection in one tap, with nothing asked. A refused prompt leaves both the canary and the switch as they were.

    The canary accepts the device passcode (BIOMETRY_ANY_OR_DEVICE_PASSCODE), superseding the earlier BIOMETRY_CURRENT_SET choice. That choice was made when biometrics released a key, where invalidating the item on re-enrolment was the right trade. With no key involved, its only remaining effect would be to shut a biometrics-only user out of their own app with nothing left to try — no password to fall back on and no material to recover. The consequence to accept is that someone who knows the device passcode can open the app; for a user who also set a password, that is a weaker path than the password itself.

  • #22163 944bd23 Thanks @LucasWerey! - Tell a user who has forgotten their app-lock password what their options are, from the unlock screen.

    The link was already on the unlock screen and the flow package already accepted the callback, but nothing in the app provided it — so the link never rendered and there was no answer to give.

    There is no recovery to offer, and that is the point of the scheme: the password is not stored, only a verifier derived from it, so nothing can reverse it. The sheet says so and names the one way back — reinstalling the app, which drops the lock along with the app's data. That advice is only true now that protection outliving its install is destroyed at boot; before, on iOS the keychain survived an uninstall and the reinstall demanded the very password the user had forgotten.

    The sheet is absent for a user protected by biometrics alone, who has no password to forget.

    The sheet lives in the flow package with the screen that raises it, which needed @shared/ui-info-state to offer ./native and ./web entries beside its conditional root: a features/flow package can only reach the root through the react-native condition, and that condition resolves Lumen to source and demands its whole native peer graph. Existing consumers keep importing the root, and keep the conditions they had.

  • #22045 1badf50 Thanks @LucasWerey! - Hold the app behind the lock on boot and when it comes back from the background, behind lwmPasswordRevamp.

    AppLockGate sits above the app, decides once on boot whether protection is configured, and locks again whenever the app is backgrounded. The unlock screen renders over the app rather than replacing it, so nothing below unmounts and the user lands where they left off.

    Two details carry more weight than they look:

    The protection state is read back from the keychain at startup — until now it only lived in memory, so a relaunch reported no password at all. The Settings row renders nothing until that read answers, rather than showing "off" and correcting itself a moment later. A read that fails counts as protected: the app would otherwise open itself on a keychain error.

    Backgrounding is judged per platform. On iOS only background locks, because the biometric prompt itself pushes the app to inactive — locking there would mean the prompt locks the app it was about to open.

    Which path the app takes is decided by the stored state, not only by the flag: a user who already holds a verifier keeps the revamped screens even if lwmPasswordRevamp is rolled back, since the legacy ones cannot remove it and ignoring it would silently drop their protection. That resolved scheme now governs the add and modify navigators too, which read the raw flag until now — on a rollback they sent a verifier holder to the legacy removal screen, which clears the legacy keychain entry and leaves the verifier in place, so the lock could not be turned off.

    Removing the last protection also releases the lock. A removal takes a slow derivation, and backgrounding during it locks the app; the removal then destroyed the verifier while the lock stood, leaving an unlock screen with nothing left to open it.

    While that read is in flight the app is covered rather than shown: the state starts unlocked, so rendering it would hand the app to whoever holds the phone for as long as the keychain takes. Once locked, the app below stays mounted — unlocking returns the user where they were — but leaves the accessibility tree, or a screen reader would walk into it.

  • #22098 8d1a795 Thanks @LucasWerey! - Move existing passwords off the plaintext scheme onto a verifier, without asking the user anything.

    Every user with a password today is on a scheme that stores it in plaintext and verifies it by string comparison — not only the short ones. The migration derives a digest from the password they already have, so it needs the plaintext: it runs right after a successful legacy unlock, the one moment the password has been proven and is in hand, and not at boot.

    Write, prove, only then delete. A crash between the write and the delete leaves the user a way in through the legacy entry; after the delete, through the verifier. Never through neither. That also makes it resumable: a verifier already present means an earlier run got that far, so the next one proves it and finishes rather than deriving a second time. A stored verifier the proven password will not open is derived over, since it can only be a half-written record or one this migration never put there, and the plaintext in hand at that moment restores a credential that works. Only a keychain that will not hold the record defers, leaving the legacy entry as the way in — as does one that declines to delete the legacy entry, since the plaintext is still there and needs the lock that stands over it.

    A run that died between the delete and retiring the legacy lock is repaired on the next boot: the entry gone with a verifier in its place can only mean the sequence reached its last step, so that verifier is what opens the app and the legacy flag is released. Without that the legacy screen asked for a password nothing could check.

    A completed migration retires the legacy lock, clearing privacy.hasPassword. Without it the app carries two independent guards: the old AuthPass screen renders over the new unlock screen, and the revamped Settings row hides the legacy toggle that could remove the old credential.

    Whether the password is under the six-character minimum is recorded as it migrates, because nothing can tell afterwards — a verifier says nothing about the length of the password behind it. The prompt that acts on it is LIVE-35981.

    The derivation queue is held for exactly one turn across the whole sequence. This shipped broken once: the migration took a turn and then called a password check that asked for another, so the inner call waited on the outer, the outer on the inner, and every later check waited on both — the app could not be unlocked at all. The check is now the unserialised primitive the public checks are built on, and a test fails if anything asks for a second turn.

  • #22179 a1a8b81 Thanks @LucasWerey! - Let any part of the app ask for the app to be protected before it continues, and answer for it.

    A feature that needs protection — the Card, first — now awaits one call: requestProtection(). The prompt decides what to ask for, so no caller looks at biometry: biometrics if the device has some enrolled, a password otherwise. An already-protected user is never interrupted and their action simply runs.

    The password path opens the existing add-password flow and comes back with a confirmation sheet, so the caller resumes where it left off. Dismissing the prompt, or backing out of the password flow, holds the caller's action instead — a request never resolves as protected unless protection is actually in place.

    Both sheets are mounted once, above the screens, so navigating away no longer closes the prompt the way a screen-owned sheet would.

    The card is the first caller: both ways out of its login lead to the provider, so signing up and logging in each wait for protection. The card flow takes the request as a prop, since a flow package cannot reach the app's prompt, and only the native entry passes one — desktop has no app lock and is unchanged.

  • #22220 b837ca4 Thanks @LucasWerey! - Let a reinstall actually clear an app-lock password, as it is meant to.

    Protection that outlives its install is destroyed at boot, which is the only way out for someone who has forgotten their password — the sheet on the unlock screen tells them so. Deciding whether protection belongs to this install fell back to "does app storage hold settings", for users whose protection predates the marker that now records an install. The app writes settings within a second of any launch, though, so a fresh install could read its own footprint as history and keep the protection the uninstall was supposed to take away.

    The fallback now asks whether onboarding was ever completed, which is the one thing a reinstalled user has not done yet by the time the lock decides, whatever else has already been written to storage.

  • #21984 675564f Thanks @LucasWerey! - Add the unlock screen and route every password check through one place.

    checkPassword becomes the only function that verifies a password, used by both unlock and deactivation, so neither can drift into comparing against something stored. It derives with the parameters carried by the verifier rather than the current defaults, which is what lets a password set before a cost change still be proven.

    The screen itself follows Figma: black full-bleed with the Ledger mark near the top, the shared password field under it, and the CTA labelled Confirm. It is forced to the dark palette rather than following the user's theme — the splash is black and this screen takes over from it with the mark in the same place, so a light rendering would flash on handover. It also carries no minimum-length rule, since the password may predate the six-character one.

    Nothing mounts it yet: the orchestration, the biometric path and the forgot-password sheet are the gate.

  • #22228 1ec8d15 Thanks @tonykhaov! - Refine the Pay card assets list with loading skeletons, translated states, funding information, and asset values in the details dialog.

  • #22312 319fbe4 Thanks @sarneijim! - Show the signed-off Touchscreen Upgrade Program copy only to Nano S users

  • #22278 95a1007 Thanks @tonykhaov! - Reveal card numbers as soon as the image loads and shorten the flip to 300ms

  • #22200 843f033 Thanks @alexstapenka-ledger! - Preserve protocol selection in Earn deposit deeplinks

  • #22182 1557452 Thanks @tonykhaov! - Reveal card numbers without a password unlock gate

  • #22076 83fd219 Thanks @0xMM-L! - Fix the Casper device confirmation step where the Fee and Amount values were blank: they are now rendered inside a Text node via DataRowUnitValue instead of being passed as a raw element to TextValueField.

  • #22229 905d26b Thanks @tonykhaov! - Add a manage dialog for reordering Pay card funding assets and starting the add-asset flow.

  • #22129 ea94dd0 Thanks @lysyi3m! - fix(concordium): drop the PLT error surface nothing can reach

    mapPltRejectReason turned a chain reject reason into a typed Error and had no
    caller. It could not gain one: an Error is what the pre-send checks return and
    what the signer throws, and neither ever sees a reject reason. A reject reason
    exists only on the wallet-proxy history response, and history renders an
    Operation, which carries failed: true and no cause. Surfacing the cause means
    a code in Operation.extra and a renderer for it, not this function.

    Removed with it: ConcordiumNonExistentTokenId and ConcordiumPltTransferRejected,
    whose only producer it was, and ConcordiumAccountNotAllowed and
    ConcordiumAccountDenied, which never had one — getAccountListStatus folds both
    list verdicts into one, so reporting the cause means widening the stored
    transferStatus first.

    A test in each app now pins that every PLT error a producer can raise has copy of
    its own, so the next one added without it fails rather than reaching a user as a
    class name.

  • #22139 7848066 Thanks @lysyi3m! - feat(concordium): show why the chain rejected a PLT transfer

    A rejected PLT transfer read as a failed row with no explanation. Operation
    details now name the cause, on desktop and mobile.

  • #22147 1648042 Thanks @lysyi3m! - fix(concordium): say which list refused a PLT sender

    A blocked sender was told to contact the issuer for access, which is wrong for a
    deny list. The send flow now reports the two causes separately.

    Removes the unused PltListStatus type.

  • #22186 eb2a2a5 Thanks @lysyi3m! - feat(concordium): surface PLT pause and sender restrictions

  • #22271 c52af21 Thanks @claudiiafg! - Fix the blank sheet that could appear when adding contacts one after another on iOS. A sheet is now dismissed once per presentation, and a dismissal nobody asked for puts the sheet back on screen instead of hiding the content of the presentation the user has just opened. A sheet that reaches the screen after being considered closed is dismissed once it animates, which is the point gorhom stops ignoring the request.

  • #22000 ed407de Thanks @mdomanski-ext-ledger! - feat: aleo staking bond flow

  • #22187 31ec33f Thanks @mateuszpalosz-ext! - aleo part 2 staking ui

  • #22089 6183efd Thanks @benruseau! - Add the create backup sub-step to the OS updates orchestrator

    Extract the device error cause recovery into a state machine shared by all sub-steps

    Refactor the OS updates debug screen

  • #22208 62a6f6c Thanks @vladyslavchupovskiy-ext-art! - feat(coin-cosmos): add the Gonka currency configuration

    Points Gonka at the Ledger-hosted LCD, sets its minimum gas price to 0 (the chain's fee
    consensus parameter), and disables delegation, which the runtime rejects. Hides the account-header
    stake action on Desktop and Mobile for any Cosmos chain whose config sets disableDelegation, and
    stops a zero minimum gas price being mistaken for a missing config when preloaded data is restored.

  • #22310 89a445a Thanks @LucasWerey! - Rename Ledger Live to Ledger Wallet in iOS permission prompts

  • #22497 80fa82a Thanks @dilaouid! - fix(send): retract the keyboard before the skip-memo warning opens in the new send flow LWM

  • #22261 791c54a Thanks @hedi-edelbloute! - Support Cardano firmware app v8.0.8 by bumping @cardano-foundation/ledgerjs-hw-app-cardano from 7.x to 8.0.0. The v7 host binding used an older APDU protocol incompatible with the rewritten v8 device app, breaking account scan, receive and signing flows on firmware 8.0.x. Also raise the Cardano nano app minVersion to 8.0.8 so users on an incompatible older app are prompted to update instead of hitting broken flows.

  • #22263 3bcd040 Thanks @gre-ledger! - Bump @react-native-community/netinfo to 12.0.1

  • #22116 214d382 Thanks @gre-ledger! - Enforce the QR code pairing sequence on both sides of the handshake

    The host and the candidate now run the pairing messages through an explicit single-use state
    machine: each message is only accepted at the one point of the sequence where it is expected,
    and the peer that initiated the handshake is bound for the whole session. Envelopes, keys and
    decrypted bodies are validated before being acted upon, so a duplicate, out-of-order, foreign or
    malformed message ends the session with a QRCodeProtocolError: Desktop then asks for a fresh
    QR code, Mobile goes to its existing retry screen.

  • #22190 0651158 Thanks @koda-apps! - Bump lumen-design-core to 0.1.29, lumen-ui-react to 0.1.59, lumen-ui-rnative to 0.1.62, and lumen-utils-shared to 0.1.13. In lumen-ui-rnative, OptionList (and its subcomponents, e.g. OptionListItem) is renamed to SelectList/SelectListItem, and resolveAvatarColor is renamed to useResolveAvatarColor, now a theme-reactive hook instead of a plain function; call sites in live-mobile and @features/platform-contacts are migrated accordingly. resolveAvatarColor in lumen-ui-react is unaffected by this bump.

  • #22306 845ac4a Thanks @LucasWerey! - Restore translucent status backgrounds with the Lumen -transparent tokens after status colors became solid.

  • #21494 4b1a3af Thanks @dilaouid! - feat(send): add skip memo confirmation bottomsheet in the lwm send flow

  • #22232 d7d2b9a Thanks @tonykhaov! - Add mobile card asset details and withdraw scenes.

  • #21690 727cd08 Thanks @pawell24! - feat(near): adapt NEAR UI to generic coin framework staking positions

  • #22305 fd6b9d0 Thanks @liviuciulinaru! - Open the provider withdrawal page from a card asset.

    • buildWithdrawalPath addresses /withdrawal, with the same app_id and currency query as buildTopUpPath.
    • Desktop opens it on the hosted manifest, mobile in the secure browser, both with the asset pre-selected.
    • Mobile also pre-selects the asset on the top up page.
    • Every mobile hosted page now opens in the same secure browser session, which shares the cookies of the login. openHostedLoginInSecureBrowser becomes openHostedUrlInSecureBrowser, and openHostedPageInSecureBrowser is removed.
    • Every hosted path now lives in state/hostedPaths.ts: signup, top up, withdrawal, manage PIN and the Baanx root. cardSettingsPaths.ts is removed, and the package exports the same names as before.
  • #22095 dc043f8 Thanks @philipptpunkt! - Price the card wallets in the Pay tab's Assets list.

    • Resolves the card's currencies and prices each wallet against the user's counter value.
    • Registers those pairs for the session, since no account holds a card wallet's currency.
    • Both are gated on the card being signed in, so a visitor who never opens it is charged neither.
  • #22267 8e556b1 Thanks @philipptpunkt! - Map Baanx's EUROC to its Ledger currency.

    • euroc.ethereum and euroc.euroc resolve to ethereum/erc20/euro_coin.
  • #22114 afb2750 Thanks @mcayuelas-ledger! - Add Crypto and Card tabs to mobile transaction history.

  • #22308 9677738 Thanks @liviuciulinaru! - Point the production and release builds at the live Baanx environment

  • #22184 75038d5 Thanks @liviuciulinaru! - Open the provider's top up page from the card on mobile.

    • The Top up button takes the place of the disabled "Coming soon" action on the card face, and it comes back at the bottom of the card details sheet.
    • Mobile opens /topup in the secure browser, which carries the provider session. A US card holder gets the US app_id on the query, so the page reaches the US tenant.
  • #22102 4b346a0 Thanks @philipptpunkt! - Show the card's balance on the Pay tab's card face.

    • The Pay tab passes the countervalue formatter the flow needs, so the face replaces the bare artwork.
    • Adds the payTab.card.balanceLabel copy the face reads; only desktop had it.
  • #22046 2aeb695 Thanks @mcayuelas-ledger! - Add a card transaction preview to the Pay card details view.

  • #22068 91531f2 Thanks @philipptpunkt! - Carry each card wallet's Ledger currency, so the app can price it.

    • useCurrenciesByIds resolves a list of Ledger ids to currencies: coins from the crypto registry, tokens from CAL. The lookups are dispatched rather than hooked, so the list can be any length.
    • A card wallet now carries ledgerCurrency instead of a counter value. Converting needs the app's rates, so it happens in platform code.
    • BAANX_LEDGER_CURRENCY_IDS lists every Ledger id the card catalog resolves to.
    • The Pay card devtool shows ledgerCurrencyId per joined wallet.
  • #22121 287f042 Thanks @philipptpunkt! - Answer the phone wallet step from the provider alone.

    • Mobile reads cardAddedToDigitalWallet from the card status for the onboarding step.
    • The device answer is gone: hasAddedCardToWallet, its two actions and its selector leave the widget state. The Add-to-Wallet CTA now hides on the provider's answer, and the instructions scene re-asks the card status instead of recording a local yes.
    • A tenant that does not send the flag leaves the step undone and keeps offering the CTA.
    • The onboarding mock gained cardAddedToDigitalWallet, so the dev tool's wallet toggle drives the mocked endpoint and follows request mocking like every other step.
  • #21841 d59d123 Thanks @Moustafa-Koterba! - feat(cosmos): migrate account resources to shared staking aggregate

  • #22214 72892c5 Thanks @sarneijim! - Track the Q3 product tour with the Generic Awareness carousel contract on mobile and desktop, including a primary continue CTA and last-step completion.

  • #22489 48af604 Thanks @LucasWerey! - Fix a bottom sheet reopening right after being swiped down before its entrance animation finished. Only a dismissal started for a previous presentation now puts the sheet back on screen.

  • #22234 b77b8f0 Thanks @tonykhaov! - Add asset-filtered mobile card transaction history.

  • #21945 1247cbc Thanks @jiyuzhuang! - Filter Braze Content Cards by local eligibility before Redux and re-evaluate on app state changes

  • #21967 40251b4 Thanks @sarneijim! - Remove the obsolete original Wallet V4 tour

  • #22299 470bca7 Thanks @mcayuelas-ledger! - Include send flow source in tracking properties on desktop and mobile.

  • #22056 cb866e1 Thanks @LucasWerey! - Add @shared/linking package for cross-platform external link handling with URL safety, localization and analytics

  • #22248 0164fac Thanks @dilaouid! - feat(send): minor adjustement ui new send flow lwm

  • #22236 43e1a21 Thanks @tonykhaov! - Add Pay Card devtools controls for transaction and wallet balance fixtures, and answer the mocked wallet reorder with the order alone so linked assets keep the amounts they were showing while the reordered row shows its spinner.

  • #21377 1603611 Thanks @live-github-bot! - Align Stellar coin family with @ledgerhq/coin-stellar 9.7.2 export subpaths: import the API from @ledgerhq/coin-stellar/api and expose memo validation through the new @ledgerhq/coin-stellar/logic-public encapsulation

  • #22337 e1c0c65 Thanks @mcayuelas-ledger! - Add legal agreement link to the Pay Card "More" menu

  • #21942 61362d0 Thanks @jiyuzhuang! - Extract a desktop BrazeProvider and share Braze refresh and identity synchronization lifecycles

Patch Changes

  • Updated dependencies [40d296b, 5649787, 4d1d640, 731ebd2, 250c1c0, 510465b, c7eb01d, 871e485, 6996290, 72367fc, c22ee67, 3d50917, cfa249c, 285b50d, d137f01, 35a5198, 795e693, 944bd23, 1badf50, 8d1a795, a1a8b81, 675564f, 1ec8d15, 386710a, 84bba64, c682542, 319fbe4, dd155a7, 95a1007, 233e44e, 1557452, 6741356, dafadf0, 9652494, 5492648, 905d26b, 98e3038, ea94dd0, 736a0d5, 7848066, 1648042, eb2a2a5, c52af21, 33e92e8, 387619d, a62ad28, 6183efd, 5d2f40f, 62a6f6c, 214d382, 0651158, 845ac4a, d7d2b9a, 29ce771, fd6b9d0, 8d073ca, 954ffbd, a915d4a, 99bf629, 853e47d, c48d6d7, 8e556b1, dbc9655, afb2750, eb06f77, 8dcb040, 75038d5, d9d1111, 4b346a0, 2aeb695, 91531f2, 287f042, 6fe6efb, d59d123, 48af604, bc43337, d19e4ae, 6844ca4, 40251b4, cb866e1, bb3e182, 43e1a21, e1c0c65, e2134f5]:
    • @shared/env@0.8.0
    • @shared/api-services@0.8.0
    • @features/platform-card@0.6.0
    • @features/flow-pay-card-auth@0.8.0
    • @features/flow-contacts-list@0.8.0
    • @domain/api-card-management@0.7.0
    • @features/flow-pay-card-details@0.5.0
    • @features/flow-pay-card@0.5.0
    • @shared/ui-queued-bottom-sheet@0.5.0
    • @features/platform-contacts@0.8.0
    • @features/flow-contacts-add-contact@0.7.0
    • @features/flow-contacts-edit-contact@0.6.0
    • @features/flow-contacts-edit-address@0.4.0
    • @features/flow-contacts-add-address@0.6.0
    • @features/flow-contacts@0.12.0
    • @features/flow-pay-card-widget@0.4.0
    • @devtools/bindings@0.9.0
    • @features/flow-app-lock@0.5.0
    • @features/platform-app-lock@0.4.0
    • @shared/ui-info-state@0.3.0
    • @features/flow-pay-card-assets@0.2.0
    • @features/flow-large-screen-upsell@2.2.0
    • @features/flow-pay-card-transactions@0.3.0
    • @domain/entity-currency-crypto@0.13.0
    • @ledgerhq/coin-concordium@1.4.0
    • @domain/entity-contact@0.10.0
    • @ledgerhq/coin-bitcoin@0.53.0
    • @ledgerhq/coin-canton@1.2.0
    • @ledgerhq/coin-casper@3.4.0
    • @ledgerhq/coin-cosmos@1.4.0
    • @ledgerhq/coin-filecoin@2.2.0
    • @ledgerhq/coin-multiversx@1.2.0
    • @ledgerhq/coin-stacks@0.31.0
    • @ledgerhq/hw-transport-http@6.38.0
    • @ledgerhq/ledger-wallet-framework@3.5.0
    • @ledgerhq/types-devices@7.1.0
    • @ledgerhq/types-live@6.125.0
    • @features/platform-env@0.4.0
    • @ledgerhq/live-dmk-shared@0.33.0
    • @ledgerhq/ledger-key-ring-protocol@0.23.0
    • @devtools/shell@0.10.0
    • @devtools/transport-panel@0.7.0
    • @ledgerhq/hw-ledger-key-ring-protocol@0.13.0
    • @shared/feature-flags@0.24.0
    • @domain/entity-card-asset-mapping@0.7.0
    • @features/platform-currencies@0.9.0
    • @features/flow-pay-balance@0.5.0
    • @features/flow-pay-feature-tour@0.6.0
    • @features/flow-pay-request@0.6.0
    • @features/platform-feature-flags@0.8.0
    • @shared/linking@0.3.0
    • @domain/api-aggregated-assets@0.5.2
    • @features/platform-aggregated-assets@0.5.4
    • @ledgerhq/live-dmk-mobile@0.29.9
    • @ledgerhq/transaction-observability@0.3.2
    • @ledgerhq/wallet-analytics@0.4.2
    • @ledgerhq/wallet-pnl@0.7.12
    • @domain/api-altcoins-sentiment@0.3.6
    • @domain/api-currency-fiat@0.4.5
    • @domain/api-currency-token@0.6.2
    • @domain/api-market-sentiment@0.3.6
    • @domain/api-push-devices@0.2.6
    • @features/flow-contacts-delete-contact@0.2.3
    • @features/flow-contacts-introduction@1.2.0
    • @features/flow-pay-bank-transfer@0.3.2
    • @features/flow-pay-contact@0.4.1
    • @features/flow-pay-deposit@0.4.1
    • @features/platform-device-action-content@0.2.1
    • @ledgerhq/live-send@0.1.1
    • @domain/entity-currency@0.4.4
    • @domain/entity-currency-token@0.5.3
    • @ledgerhq/live-currency-format@0.15.0
    • @ledgerhq/live-wallet@1.1.4
    • @ledgerhq/live-signer-evm@0.23.3
    • @ledgerhq/live-countervalues@0.26.1
    • @ledgerhq/live-countervalues-react@0.18.1
    • @ledgerhq/device-core@0.11.17
    • @ledgerhq/domain-service@1.8.20
    • @devtools/wire@0.5.1
    • @features/flow-analytics-consent@0.2.7

Don't miss a new ledger-live release

NewReleases is sending notifications on new releases.