9ee5a4e568
* Switch to FsBlockDb for caching CompactBlocks * Add RustBackend.getLatestHeight() method * Raise MSRV to 1.60 * Migrate to latest Rust crate API * Add RustBackend.findBlockMetadata() method * Add RustBackend.rewindBlockMetadataToHeight() method * [#765] implementation of FileCompactBlockRepository * writing block metadata to database * split write function into smaller easier to test blocks * testing for FileCompactBlockRepository * fixed rewinding * fixed tests * fixed FileCompactBlockRepositoryTest and SynchronizerFactoryTest * code review fixes * updated proto files * override all functions in FakeRustBackend * code review fixes * Fix function body formatting * Improve clear function clarity * Use length of string const * Delete single file instead of directory * Improve function clarity * Refactor outputs counting - Found a typo in intermediary model class JniBlockMeta parameter change of which does not impact encoding from rust to kotlin according to rust layer implementation. * Check blocks mkdir result * Remove unnecessary detekt warning suppression * Refactor buffer size check * Improve visibility annotations * Make file finalise obvious and self documenting * Remove prevHash logging * Move instantiation to the object itself * Enrich fixture with default values * Extend eror message * Rename benchmark blocks range fixture * Fix rebase changes * Improve FileCompactBlockRepositoryTest - "De-integrated" the test suite - it now works with fixture blocks - Created needed fixtures for a clear mocked blocks providing - Enhanced getting of FileCompactBlockRepository in FileCompactBlockRepositoryTest to clarify that it works with mock components * Fix ktlintFormat findings * Bump actions/cache from 3.2.4 to 3.2.5 in /.github/actions/setup (#927) Bumps [actions/cache](https://github.com/actions/cache) from 3.2.4 to 3.2.5. - [Release notes](https://github.com/actions/cache/releases) - [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md) - [Commits]( |
||
|---|---|---|
| .github | ||
| .idea | ||
| .run | ||
| build-conventions | ||
| darkside-test-lib | ||
| demo-app | ||
| demo-app-benchmark-test | ||
| docs | ||
| gradle/wrapper | ||
| lightwallet-client-lib | ||
| sdk-incubator-lib | ||
| sdk-lib | ||
| tools | ||
| .gitignore | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| MIGRATIONS.md | ||
| README.md | ||
| build.gradle.kts | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| responsible_disclosure.md | ||
| settings.gradle.kts | ||
README.md
This is a beta build and is currently under active development. Please be advised of the following:
- This code currently is not audited by an external security auditor, use it at your own risk
- The code has not been subjected to thorough review by engineers at the Electric Coin Company
- We are actively changing the codebase and adding features where/when needed
🔒 Security Warnings
- The Zcash Android Wallet SDK is experimental and a work in progress. Use it at your own risk.
- Developers using this SDK must familiarize themselves with the current threat model, especially the known weaknesses described there.
Zcash Android SDK
This lightweight SDK connects Android to Zcash, allowing third-party Android apps to send and receive shielded transactions easily, securely and privately.
Different sections of this repository documentation are oriented to different roles, specifically Consumers (you want to use the SDK) and Maintainers (you want to modify the SDK).
Note: This SDK is designed to work with lightwalletd. As either a consumer of the SDK or developer, you'll need a lightwalletd instance to connect to. These servers are maintained by the Zcash community.
Note: Because we have not deployed a non-beta release of the SDK yet, version numbers currently follow a variation of semantic versioning. Generally a non-breaking change will increment the beta number while a breaking change will increment the minor number. 1.0.0-beta01 -> 1.0.0-beta02 is non-breaking, while 1.0.0-beta01 -> 1.1.0-beta01 is breaking. This is subject to change.
Zcash Networks
"mainnet" (main network) and "testnet" (test network) are terms used in the blockchain ecosystem to describe different blockchain networks. Mainnet is responsible for executing actual transactions within the network and storing them on the blockchain. In contrast, the testnet provides an alternative environment that mimics the mainnet's functionality to allow developers to build and test projects without needing to facilitate live transactions or the use of cryptocurrencies, for example.
The Zcash testnet is an alternative blockchain that attempts to mimic the mainnet (main Zcash network) for testing purposes. Testnet coins are distinct from actual ZEC and do not have value. Developers and users can experiment with the testnet without having to use valuable currency. The testnet is also used to test network upgrades and their activation before committing to the upgrade on the main Zcash network. For more information on how to add testnet funds visit Testnet Guide or go right to the Testnet Faucet.
This SDK supports both mainnet and testnet. Further details on switching networks are covered in the remaining documentation.
Consumers
If you're a developer consuming this SDK in your own app, see Consumers.md for a discussion of setting up your app to consume the SDK and leverage the public APIs.
A primitive example to exercise the SDK exists in this repo, under Demo App.
There are also more comprehensive sample walletes:
- ECC Sample Wallet — A basic sample application.
- Secant Sample Wallet — A more modern codebase written in Compose. This repository is a work-in-progress and is not fully functional yet as of August 2022, although it will be our primary sample application in the future.
Maintainers and Contributors
If you're building the SDK from source or modifying the SDK:
- Setup.md to configure building from source
- Architecture.md to understand the high level architecture of the code
- CI.md to understand the Continuous Integration build scripts
- PUBLISHING.md to understand our deployment process
Note that we aim for the main branch of this repository to be stable and releasable. We continuously deploy snapshot builds after a merge to the main branch, then manually deploy release builds. Our continuous deployment of snapshots implies two things:
- A pull request containing API changes should also bump the version
- Each pull request should be stable and ready to be consumed, to the best of your knowledge. Gating unstable functionality behind a flag is perfectly acceptable
Known Issues
- Intel-based machines may have trouble building in Android Studio. The workaround is to add the following line to
~/.gradle/gradle.properties:ZCASH_IS_DEPENDENCY_LOCKING_ENABLED=false - During builds, a warning will be printed that says "Unable to detect AGP versions for included builds. All projects in the build should use the same AGP version." This can be safely ignored. The version under build-conventions is the same as the version used elsewhere in the application.
- Android Studio will warn about the Gradle checksum. This is a known issue and can be safely ignored.