A platform document describing credential transfer does not, by itself, establish that two password-manager apps can complete a particular user’s move. For a product team reviewing portability, the first useful deliverable is a support matrix with both ends of the proposed transfer named.

Android’s credential-transfer guide describes same-device transfer between credential providers. It distinguishes an exporter holding credentials from an importer requesting supported credential types. The guide identifies passwords, passkeys, address information and custom fields, using the FIDO Credential Exchange Format, and states Android 8, API level 26, or later as the platform range for the API.

The FIDO Alliance overview supplies the broader credential-exchange specification context. Neither source is a compatibility result for every pair of apps, account type or software release.

A support matrix for a product conversation

Before writing a customer-facing portability promise, give each proposed route its own row. Keep these fields with the supporting documentation:

• Source provider: the exact application and version being considered as exporter. Record the provider’s own statement about that role.
• Destination provider: the exact importer and version. An export feature at the source does not answer what the destination accepts.
• Credential type: separate passwords, passkeys and other fields. Do not mark an entire vault supported because one category is documented.
• Environment: identify the device and Android version to which the evidence applies.
• Evidence state: distinguish platform documentation, provider documentation and a specifically scoped test result. Leave a result blank when no test has occurred.

Consider a hypothetical brief saying “the source exports passkeys”. If the destination’s documentation only describes password import, the matrix still contains an unanswered passkey-import question. The platform’s credential-type vocabulary helps name that gap; it does not fill it.

Keep the document version beside the promise

The dependency example in the Android guide read for this article names androidx.credentials:providerevents:1.0.0-alpha06. Retain that version in a technical review note instead of copying an undated claim into a launch checklist. A development example is not a statement that every implementation is released to all customers.

This article does not provide credential-transfer code, assess a provider’s security controls or instruct readers to export a real vault. Any implementation needs its own engineering and security review. Product communication can still become more precise now: describe the supported route, the documented scope and the evidence date, rather than promising universal portability.

Our product-launch source checklist applies the same evidence discipline to announcements. Here the specific question is narrower: which provider plays which role for which credential category?

Primary sources checked 10 November 2026: Android Developers and FIDO Alliance. No app-to-app test, provider certification, deployment coverage or successful customer migration is claimed.