Downloading and scanning blocks are requirements for updating sync
progress, but block deletion from the cache is not. This change moves
block deletion into "the background" alongside transaction enhancement.
Co-authored-by: Honza <rychnovsky.honza@gmail.com>
- This ensures that the SDK supports apps switching between different lightwalletd servers
- Synchronizer.validateServerEndpoint API added
- Demo app updated to leverage this new feature
- Changelog update
- Closes#1393
* [#1385] Adopt `AccountBalance` fields in Kotlin layer
- Adds the Kotlin side changes for #1380
- Changed WalletBalance to contain these three fields: available, changePending, and valuePending, instead of total and available, and change the transparent flow to StateFlow<Zatoshi>, as we don't distinguish there.
- Related connected APIs changed
- Closes#1385
* Add WalletBalanceFixture
Placed in the public directory to be visible for clients as well
* Changelog update
* Remove `getVerifiedTransparentBalance ` API entirely
Co-authored-by: str4d <jack@electriccoin.co>
* backend-lib: Expose `AccountBalance` fields across the FFI
* Update related fixture class
---------
Co-authored-by: Honza <rychnovsky.honza@gmail.com>
* Migrate to `librustzcash` tag `ecc_sdk-20240130a`
This includes the fix to the empty transaction request serialization
bug, which was preventing shielding from working.
* Release zcash-android-wallet-sdk 2.0.6
* Fix ktlint warnings
* Other CBP minor/formatting changes
---------
Co-authored-by: Honza <rychnovsky.honza@gmail.com>
This improves performance in two ways:
- The `SdkSynchronizer` now reports balances of existing wallets and
sync progress almost immediately, instead of after the first batch
of blocks is scanned.
- In the steady state case, only a few subtree roots are downloaded,
reducing the time until the first batch of blocks is scanned.
ClosesElectric-Coin-Company/zcash-android-wallet-sdk#1310.
Previously we only showed balance updates for the default address; this
could potentially undercount transparent balance in some cases.
We also now use the total zero-conf transparent balance for both "total"
and "available", because we only allow transparent balance to be
shielded, and we use a zero-conf transaction to do so.
- Closes#1287
- This refactored out all the occurrences of LightWalletEndpointExt and its functions and variables from the SDK’s public API. It preserves it in tests, demo app, and in the PersistableWallet for backward compatibility, although it’s not available from outside of the SDK.
- Changelog updated
* [#1248] Clean up unused exceptions
Closes#1248
* Changelog update
* Suppress detekt warning
Creating these private functions is required by the compiler
* Replace Sapling balance and scan progress FFIs with wallet summary FFI
Closeszcash/zcash-android-wallet-sdk#1282.
* Using test fixture for JniAccountBalance
* Minor documentation changes
* Fix typo
---------
Co-authored-by: Honza <rychnovsky.honza@gmail.com>
- Removed all uses of the incorrect 1000-ZAT fee as defined with deprecated zip-313
- Default is now 10k zatoshi, the minimum defined by zip-317
- Changelog updated
- Closes #1273
* [#1249] Continuity error rewind
- Fixed the Rust FFI bug that caused us to be unable to catch the Continuity error
- Improved logging
- Moved handling the Continuity error to the outer synchronization loop, which works better with synchronization mutex
- Closes#1249
* Resolve minor comments from older PR #1247
- Off-by-one in determining whether a transaction is confirmed.
- Expiry logic was inverted for non-zero expiry heights.
- Transactions with zero (disabled) expiry heights happened to work
because this case is currently detected in the database logic and
mapped to `null`, which the old code mapped to `Long.MAX_VALUE`
which gave the correct result for the old conditional expression.
With the fixes to `v_transactions` and `v_tx_outputs`, there are
several more data fields that may have no data (for rows corresponding
to purely-transparent transactions); their fields are made nullable.
* [#1241] Remove rewind for every verify scan range
- The original solution comes from the pseudocode requirement: Download the blocks in `scan_range` into the block source, overwriting any existing blocks in this range.
- Removed
* [#1243] Rewind only after continuity-error
- Rewind is done only when Continuity-error appears now. In case of other sync failures, the sync loop sleeps for a short time and then retries. Internal actions like fetching subtree roots, fetching chain tip, downloading, scanning, etc., still have their internal retry mechanisms.
- For the calculation of the rewind height, we use the existing checkContinuityErrorResult method, originally used only for validation use cases but later incorrectly used for other failures too.
- Closes#1243
- Closes#1222 as it was created to determine which failure type comes and don’t rewind for all of them
- Tested manually in several scenarios, e.g. lost internet connection or app going to background
* Handle Continuity and other sync errors
- Call handleContinutyError and its rewind logic directly without checking failed attempts. This ensures that we keep trying to reorg.
- And return the correct type of error in that case.
- Add fail logic to the handling of the other types of errors.
* Add JniScanProgressTest
* Remove unnecessary testnet workaround
As this was fixed with the last rust changes.
* Simplify batchCount calculating
* Fix ratio typo
* Docummentation comments changes
- TypesafeBackend.createAccountAndGetSpendingKey now works with a type-safe TreeState model class instead of ByteArray.
- New type-safe TreeState added. Once we get the TreeState object from the lightwalletd server, potential validation comes into this object.