Skip to main content

Overview

Errors in the Seam Android SDK fall into two categories:
  • SeamError — Thrown by SDK operations such as initialize(), activate(), deactivate(), refresh(), and unlock(). These represent SDK setup, configuration, or API-level failures.
  • SeamCredentialError — Stored in SeamCredential.errors. These represent issues with a specific credential that must be resolved before it can be used for an unlock.
Handling both types ensures your app can present clear, actionable guidance to users.

SeamError

SeamError is a sealed class. Each subtype maps to a specific failure mode:

Handling SeamError in code


SeamCredentialError

SeamCredentialError is a sealed class stored in SeamCredential.errors. A credential may have zero or more errors simultaneously. Check errors before calling unlock():

Checking credential errors before unlock


SeamRequiredUserInteraction

When a credential has a SeamCredentialError.UserInteractionRequired error, the interaction property tells you exactly what the user needs to do:

Handling required user interactions


Handling unlock errors end-to-end

The following example shows a complete unlock handler that covers both pre-flight credential checks and runtime SeamError cases:

Best Practices

  • Check credential.errors before calling unlock() — An unlock attempt on a credential with unresolved errors will throw SeamError.CredentialErrors. Checking upfront lets you present better UX before the call.
  • Subscribe to unlockStatus before unlock()unlock() emits events immediately; subscribing after the call can miss early events like ScanningStarted.
  • Map errors to UI states — Distinguish loading states (SeamCredentialError.Loading) from actionable errors so you show spinners rather than error messages while credentials are provisioning.
  • Retry transient errorsSeamError.InternetConnectionRequired and SeamError.DeactivationInProgress are transient. Implement retry logic with backoff for these cases.

See Also