entryready_wallet 0.2.0

Add EntryReady mobile keys to Apple Wallet and Google Wallet. Presents the platform's provisioning flow and reports what is already in the wallet.

Changelog

0.2.0

Adds Google Wallet provisioning for Android, alongside the existing Apple Wallet support.

Google Wallet is opt-in

Google's Tap and Pay client is distributed only to onboarded Service Providers and resolves from no public repository. Declaring it unconditionally would break the Android build of every application using this package, including those that never touch Google Wallet. So it is enabled by a Gradle flag, in the application:

# android/gradle.properties
entryreadyWallet.googleWallet=true

together with the Maven repository Google supplied. Without it the package still builds and runs on Android; the Google calls report GoogleWalletError.notSupportedInBuild, which names the flag. googleOpenSaveLink works either way, because the save step is an ordinary intent rather than an SDK call.

Added

• googleIsSupported() — whether this build was compiled with Google support. Ask before offering the action: once a call fails, "no support in this build" and "Google rejected this application" look alike and need opposite fixes.
• googleActiveWalletId(), googleCreateWallet(), googleEnvironment().
• googleLinkingToken(spAccountIdentifier) — the single-use token that goes to POST /mobilekeys/oems/getLink as the nonce, verbatim. EntryReady wraps and encodes it; doing either in the application double-wraps it.
• googleOpenSaveLink(saveUrl) — hands the save link to Google Wallet. The endpoint returns it in a field named digitizationReference, which is misleading: the value is a URL, not an identifier, and no SDK call accepts it.
• isProvisionedInGoogleWallet(events) with WalletProvisioningEvent — reads EntryReady's key events. The device cannot answer this question: Google's SDK lists only tokens the calling application is entitled to see, and a Hotel Key card is issued by the account hub rather than pushed by your application, so it never appears there. Three rules the function encodes: the newest conclusive event decides rather than the presence of any one, since a revocation is appended beside the provisioning rather than replacing it; WALLET_PROVISION_UPDATED is ambiguous and its status decides; unrecognised events are skipped rather than read as negatives.
• GoogleWalletException with GoogleWalletError, mirroring the Apple error taxonomy.

Note for existing users

0.1.x had no android/ directory, so Flutter skipped the package entirely on Android. From 0.2.0 your Android build compiles a Kotlin module it did not before — minSdk 21, Kotlin 1.9, kotlinx-coroutines-android. No action is needed, and the flag defaults to off, but it is a new module in your build.

Apple Wallet behaviour is unchanged, and nothing in the existing API was altered. Implementations of EntryreadyWalletPlatform keep compiling: the new methods have defaults rather than being abstract.

0.1.1

Documentation only. No code changes — the Dart and Swift sources are identical to 0.1.0.

• Adds an Install section. A new Flutter app targets iOS 15.0, so the first device build fails with The package product 'entryready-wallet-product' requires minimum platform version 16.0. The fix is the Runner target's Minimum Deployments setting in Xcode. A project on Swift Package Manager — the Flutter default — has no Podfile, so the platform :ios, '16.0' line applies only to projects still using CocoaPods.

0.1.0

First release.

Apple Wallet in-app provisioning for EntryReady mobile keys, covering the device half of an integration. The package does not call the EntryReady API — your application does, and hands the results here.

Added

• EntryReadyWallet.keyStatus(referenceIdentifiers:) — where a key's pass is, as a WalletKeyStatus (notProvisioned, onThisDeviceOnly, onPairedDeviceOnly, onBoth). A pass counts only when its primaryAccountIdentifier matches one of the supplied identifiers and the wallet reports it activated, so an unrelated credential in the same wallet cannot satisfy it.
• WalletKeyStatus.shouldOfferButton — Apple's display rule: hide only once the pass is on both the phone and a paired device.
• WalletKeyStatus.note — user-facing copy for the partial states, where a pass is on one device but not the other.
• EntryReadyWallet.addKey(credentials:, preview:) — presents Apple's provisioning sheet for a credential prepared by POST /mobilekeys/preparePushProvisioning. Takes PassCredentials and PassPreview.
• EntryReadyWallet.diagnose() — why provisioning is unavailable, as a WalletDiagnosis. Reports Wallet availability, Simulator, visible pass count, and whether the embedded provisioning profile carries the entitlement. Exists because a missing entitlement makes pass queries return empty rather than fail, which is otherwise indistinguishable from a user with no passes.
• AddToAppleWalletButton — Apple's PKAddPassButton as a platform view, since Apple requires their own control.
• EntryReadyWallet.passes() and isAvailable() — the raw queries, for diagnostics and for callers correlating several keys at once.
• WalletException with a WalletErrorCode, so callers branch on an enum instead of parsing message strings. isCancellation separates a dismissed sheet from a real failure.
• A plugin_platform_interface seam, so an integrating application can substitute a fake and test its wallet flow with no device and no entitlement.

Requirements

• iOS 16.0. The shareable-pass APIs this package uses — PKShareablePassMetadata's preview initializer and PKAddShareablePassConfiguration.forPassMetadata(_:action:completion:) — are both API_AVAILABLE(ios(16.0)). Only PKAddSecureElementPassViewController and the pass queries date back to 13.4, so a lower target compiles the queries and fails on the provisioning call.
• The com.apple.developer.contactless-payment-pass-provisioning entitlement with shareablecredential, granted through Apple's Wallet Access Key program and bound to your bundle identifier. Manual signing is required; automatic signing cannot mint a profile carrying it.
• A real device. The Simulator has no Secure Element.

Not included

No EntryReady API client, no authentication, and no reservation or booking concepts. Those belong to the integrating application.

Android is not implemented. Google and Samsung wallets need an oems/getLink nonce handshake that Apple's flow does not, so it is deliberately not stubbed in as if it were a minor difference.