mirror of
https://github.com/pezkuwichain/pezkuwi-wallet-android.git
synced 2026-08-04 22:15:40 +00:00
b6642387ba
Two gaps, both invisible until you look for them. There was no update mechanism at all. Someone on an old build stayed on it until they happened to open the Play Store on their own. For a wallet that is worse than an inconvenience: today's multisig signing fix would have reached nobody who was not already looking. InAppUpdates asks Play on every foreground. A user a few days behind gets the flexible flow — the download runs in the background and the wallet stays usable, because interrupting someone mid-transfer to force an update is its own kind of harm. Past fourteen days of staleness, or on a release marked priority 4+ in Play Console, it switches to immediate. onResume finishes an interrupted immediate update and installs a flexible one that completed while the app was backgrounded; without that the first leaves a user stuck and the second never installs. Ratings had the same shape of gap: people who would happily rate the wallet never do, because nothing ever asks. Play's in-app card asks without sending them to the store. Play answers neither "has this user rated" nor "what did they choose" — by design. It also throttles to a handful of showings a year and silently drops the rest. So the gates in AppReviewTracker are not there to avoid nagging, which Play already handles; they exist to spend those few real chances well: three successful operations, three days since first use, ninety since the last ask, and not within two days of an error. Recording sits in RealExtrinsicService, the single point every on-chain action passes through, so transfers and staking are covered without a hook per screen. The tracker swallows everything it touches — a rating counter must never be able to fail a transfer. Both features no-op outside a Play install, so neither can be verified from a Firebase build; that needs an internal testing track. Version 1.2.0.