Android Setup

このコンテンツはまだあなたの言語で利用できません。

On Android, passkeys work with your website when the app and the relying-party domain are connected through Digital Asset Links.

What the plugin handles

After you add the plugin config and run bunx cap sync, the plugin patches the generated Android host project:

injects the asset_statements manifest metadata
writes the generated string resource referenced by that metadata

What you still need to host

You must publish assetlinks.json on the relying-party domain:

https://signin.example.com/.well-known/assetlinks.json

Example:

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "app.capgo.passkey.example",
      "sha256_cert_fingerprints": [
        "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
      ]
    }
  }
]

Checklist

Set origin and domains in plugins.CapacitorPasskey in capacitor.config.*.
Run bunx cap sync.
Use your real Android package name in assetlinks.json.
Add every signing certificate fingerprint you need, including debug or internal signing keys if you test those builds.
Host the file on the same domain you use as the relying-party ID.

Important behavior difference from a browser

With Digital Asset Links configured, Android can use the same relying party and passkeys as your website. The remaining difference is the literal origin reported in native clientDataJSON.

A normal Android app does not behave like a privileged browser.
The assertion origin can be tied to the Android app signature instead of your website origin.
If your backend strictly validates clientDataJSON.origin, accept the Android app origin alongside the website origin.