in zcash-light-client-ffi, the a newly generated unified spending key is passed back across the FFI as a binary value; in zcash-android-wallet-sdk it is passed via its string encoding. The behavior in zcash-light-client-ffi is a bit odd, because everywhere that the USK is provided as an argument to a FFI method, it is passed as a string that is then decoded in the same fashion is done in the Android FFI, but I don't see where the encoding is implemented. Not a blocker for deployment, just a puzzling inconsistency.
In zcash-android-wallet-sdk, a methods are provided to directly derive both UFVKs and UAs from the wallet seed, whereas in zcash-light-client-ffi the UFVK is derived from the spending key, and the only methods provided for UA derivation rely upon the internal state of the wallet database. Essentially, the Android API exposes key and address derivation in ways that the iOS sdk does not; an incautious user of the Android API could potentially derive addresses from keys that are not used for scanning by the wallet. We should consider removing the derivation tool from Android as it was previously removed from the Swift API.
zcash-light-client-ffi exposes WalletWrite::get_next_available_address; the Android SDK does not provide any comparable method.
zcash-light-client-ffi provides zcashlc_get_typecodes_for_unified_address_receivers and zcashlc_get_address_metadata; the Android SDK does not provide comparable methods.
zcash-android-wallet-sdk provides a isValidSpendingKey method; the iOS SDK does not provide this method.
zcash-light-client-ffi provides is_valid_sapling_extended_spending_key, whereas the Android SDK does not. This might be a legacy API that should be removed?
zcash-light-client-ffik provides is_valid_unified_full_viewing_key; the Android SDK does not. We should investigate the uses of this method.
zcash-light-client-ffi provides zcashlc_get_verified_transparent_balance (which operates per-address) and zcashlc_get_verified_transparent_balance_for_account; the Android SDK does not. We should investigate this discrepancy.
zcash-light-client-ffi provides zcashlc_get_total_transparent_balance_for_account; the Android SDK does not (total balance is provided at the address level only.) We should investigate this discrepancy.
zcash-light-client-ffi can retrieve binary memos with zcashlc_get_memo; the Android SDK appears to only be able to return UTF-8 memos using getMemoAsUtf8.
zcash-light-client-ffi provides zcashlc_get_seed_fingerprint; the Android SDK doesn't appear to provide this.
In zcash-light-client-ffi, two separate methods are used to insert subtree root data; in the Android SDK a single putSubtreeRoots method is used.
In both SDKs, use of ZIP 317 fees is still optional. The SDKs should migrate to always using ZIP 317 fees.
zcash-light-client-ffi provides support for proposing a transaction based on a ZIP 321 URI; the Android SDK does not yet provide this method.
Notable inconsistencies:
zcash-light-client-ffi, the a newly generated unified spending key is passed back across the FFI as a binary value; inzcash-android-wallet-sdkit is passed via its string encoding. The behavior inzcash-light-client-ffiis a bit odd, because everywhere that the USK is provided as an argument to a FFI method, it is passed as a string that is then decoded in the same fashion is done in the Android FFI, but I don't see where the encoding is implemented. Not a blocker for deployment, just a puzzling inconsistency.zcash-android-wallet-sdk, a methods are provided to directly derive both UFVKs and UAs from the wallet seed, whereas inzcash-light-client-ffithe UFVK is derived from the spending key, and the only methods provided for UA derivation rely upon the internal state of the wallet database. Essentially, the Android API exposes key and address derivation in ways that the iOS sdk does not; an incautious user of the Android API could potentially derive addresses from keys that are not used for scanning by the wallet. We should consider removing the derivation tool from Android as it was previously removed from the Swift API.zcash-light-client-ffiexposesWalletWrite::get_next_available_address; the Android SDK does not provide any comparable method.zcash-light-client-ffiprovideszcashlc_get_typecodes_for_unified_address_receiversandzcashlc_get_address_metadata; the Android SDK does not provide comparable methods.zcash-android-wallet-sdkprovides aisValidSpendingKeymethod; the iOS SDK does not provide this method.zcash-light-client-ffiprovidesis_valid_sapling_extended_spending_key, whereas the Android SDK does not. This might be a legacy API that should be removed?zcash-light-client-ffikprovidesis_valid_unified_full_viewing_key; the Android SDK does not. We should investigate the uses of this method.zcash-light-client-ffiprovideszcashlc_get_verified_transparent_balance(which operates per-address) andzcashlc_get_verified_transparent_balance_for_account; the Android SDK does not. We should investigate this discrepancy.zcash-light-client-ffiprovideszcashlc_get_total_transparent_balance_for_account; the Android SDK does not (total balance is provided at the address level only.) We should investigate this discrepancy.zcash-light-client-ffican retrieve binary memos withzcashlc_get_memo; the Android SDK appears to only be able to return UTF-8 memos usinggetMemoAsUtf8.zcash-light-client-ffiprovideszcashlc_get_seed_fingerprint; the Android SDK doesn't appear to provide this.zcash-light-client-ffi, two separate methods are used to insert subtree root data; in the Android SDK a singleputSubtreeRootsmethod is used.zcash-light-client-ffiprovides support for proposing a transaction based on a ZIP 321 URI; the Android SDK does not yet provide this method.