Android Verifier SDK v7.0.0 Migration Guide

Create a verifier application on your MATTR VII tenant

SDK Tethering requires a verifier application configured on the MATTR VII tenant your SDK connects to. If you already use remote mobile (app-to-app) verification you will have created one; the same application is reused for tethering. If you have not, create one now.

To register your Android application, make a request to create a verifier application:

POST /v2/presentations/applications

{
    "name": "My Android Verifier Application",
    "type": "android",
    "packageName": "com.yourcompany.verifierapp",
    "packageSigningCertificateThumbprints": [
        "1232584b6f6a892d356899fb9576c5f226a179e6199f2b7a1d837b5c234c5a8e"
    ]
}

• name: A unique name to identify your verifier application.
• type: Must be android for an Android application.
• packageName: The package name of your Android application.
• packageSigningCertificateThumbprints: SHA-256 hex-encoded fingerprints of the signing key certificates used to sign your APK or app bundle. This ensures the tenant only accepts requests from known and trusted applications. Refer to Android app signing for more information.

The response will include a unique id for your application, used by the SDK to identify and authenticate your application.

Supply PlatformConfiguration and handle tethering errors at initialization

PlatformConfiguration is now required on initialize. Previously it was optional and only used for remote mobile (app-to-app) verification flows; it now also drives SDK Tethering, registering the app instance with your MATTR VII tenant and obtaining a license on first initialization.

Always pass a PlatformConfiguration, and handle the new InvalidLicenseException and FailedToRegisterException that initialize can now throw:

- val platformConfiguration = PlatformConfiguration(
-     tenantHost = URL("https://your-tenant.vii.mattr.global")
- )
- MobileCredentialVerifier.initialize(context, platformConfiguration)
+ val platformConfiguration = PlatformConfiguration(
+     tenantHost = URL("https://your-tenant.vii.mattr.global"),
+     applicationId = "1ef1f867-20b4-48ea-aec1-bea7aff4964c"
+ )
+ try {
+     MobileCredentialVerifier.initialize(context, platformConfiguration)
+ } catch (e: FailedToRegisterException) {
+     // Registration with the MATTR VII tenant failed — check connectivity and configuration
+ } catch (e: InvalidLicenseException) {
+     // The SDK license is missing, invalid, or expired
+ }

• tenantHost: The URL of your MATTR VII tenant where your verifier application is configured.
• applicationId: The id of your configured MATTR VII verifier application.

The majority of the SDK's other APIs can now also throw InvalidLicenseException when a valid license is not present. Network access is required the first time the SDK initializes (for registration) and when the license is renewed on subsequent initializations. Update your error handling, logging, analytics, and support diagnostics to account for these cases.

Remove the applicationId argument from requestMobileCredentials

MobileCredentialVerifier.requestMobileCredentials (remote mobile, app-to-app) no longer takes an applicationId parameter. It now uses the application ID supplied in PlatformConfiguration during initialization. Remove the argument from your call sites:

  val result = verifier.requestMobileCredentials(
      request = listOf(mobileCredentialRequest),
      challenge = challenge,
-     applicationId = "your-application-id"
  )

Ensure you provide applicationId via PlatformConfiguration (see the previous step) instead.

Update revocation status list method and type names

The revocation status list management API has been renamed from TrustedIssuer-prefixed terminology to Revocation terminology to better reflect its purpose — managing the lists used to check the revocation status of credentials. Update all call sites:

- val result = verifier.updateTrustedIssuerStatusLists()
+ val result = verifier.refreshRevocationStatusLists()

- val cacheInfo = verifier.getTrustedIssuerStatusListsCacheInfo()
+ val cacheInfo = verifier.getRevocationStatusListsCacheInfo()

Update revocation status list refresh result handling

RevocationStatusListsRefreshResult (formerly UpdateTrustedIssuerStatusListsResult) has been converted from a data class to a sealed interface with Success and Failure variants, and the .success: Boolean field has been removed. Replace boolean branching with when/is pattern matching:

- val result = verifier.refreshRevocationStatusLists()
- if (result.success) {
-     // Handle success
- } else {
-     // Handle failure
- }
+ when (val result = verifier.refreshRevocationStatusLists()) {
+     is RevocationStatusListsRefreshResult.Success -> {
+         // Handle successful refresh
+     }
+     is RevocationStatusListsRefreshResult.Failure -> {
+         // result.failedLists is available here
+     }
+ }

Update online presentation session result handling

OnlinePresentationSessionResult has been converted from a data class to a sealed interface with Success and Failure variants. Replace field-based branching with when/is pattern matching:

- val result = ... // OnlinePresentationSessionResult
- if (result.mobileCredentialResponse != null) {
-     // Use result.mobileCredentialResponse
- } else {
-     // Use result.error
- }
+ when (result) {
+     is OnlinePresentationSessionResult.Success -> {
+         // result.mobileCredentialResponse is guaranteed
+     }
+     is OnlinePresentationSessionResult.Failure -> {
+         // result.error is guaranteed
+     }
+ }

Remove optional handling on MobileCredentialResponse collections

MobileCredentialResponse.credentials and MobileCredentialResponse.credentialErrors are now required non-nullable List fields, instead of nullable fields. Remove null checks and ?. navigation, and provide both arguments when constructing the type:

- for (credential in response.credentials.orEmpty()) { ... }
+ for (credential in response.credentials) { ... }