1. Verify the public association files
Open these exact URLs for the Mobile App’s hostname:200, use application/json, stay within 128 KB, and contain the exact active app identifiers. Redirects between hostnames or from HTTP to HTTPS do not satisfy platform verification.
Use Workspace settings → Mobile Apps → your app → Verify public files to compare the public documents with the expected Biqli configuration.
2. Verify Android App Links
The installed build’s signing certificate must appear inassetlinks.json. A locally signed debug build and a Google Play build normally have different certificates. When Play App Signing is enabled, include the App signing key certificate shown by Google Play for Play-delivered builds; include other fingerprints only for builds that must verify on the same domain.
On Android 12 or later:
verified and the final command should launch your activity.
Android 15 and later can periodically refresh association changes, but propagation can take up to seven days. Android 14 and earlier normally pick up changes when the app is installed or updated. Re-verification, reinstalling, and server caches can still delay a test. See Verify Android App Links.
3. Verify iOS Universal Links
Confirm the app hasapplinks:go.example.com in its signed associated-domains entitlement. Tap the link from Mail, Notes, or another application; typing it into Safari’s address bar is not the same test. The app should receive an NSUserActivityTypeBrowsingWeb activity.
Apple retrieves association files through its managed content-delivery network on iOS 14 and later. Apple states that its network requests a new file within 24 hours and installed devices may check for updates approximately weekly. Reinstall the app after the association is available when testing a changed entitlement or document. See Supporting associated domains and Debugging Universal Links.
4. Test installed-app resolution
Open a mobile-enabled short URL with the app installed. Confirm:- the operating system launches the correct app;
- the SDK sends the HTTPS deep link;
- the response is
exact_app_linkwith exact confidence; - the route and allowed attribution values match the current link; and
- the app rejects an unknown route safely.
none is handled as a successful result.
5. Test Android deferred installation
Use a Google Play internal test track. Uninstall the app, open the Biqli link on an eligible Android device, install from the Play page reached through that click, and launch the app. Expectexact_install_referrer on the first eligible resolution.
A sideloaded APK, Android Studio installation, or emulator-only flow can test the installed App Link and API, but cannot prove that Google Play delivered the referrer.
6. Test iOS deferred installation
Use a TestFlight or App Store build. Remove the app, open the link, select Continue on the Deep View, install the app, launch it, and select the explicit Biqli paste control. Expectexact_handoff.
Test these negative cases too:
- paste unrelated text and expect
invalidHandoffURL; - let a handoff expire and expect no exact match;
- deny consent when required and expect the SDK to stop before the request;
- disconnect the device, start resolution, reconnect it, and retry on a later cold launch; and
- reuse a completed handoff from a different installation and confirm it is rejected.
Common failures
Include the
X-Biq-Request-Id, approximate UTC time, platform, SDK version, and match/error code when contacting support. Never send a mobile publishable key, handoff token, signed receipt, or complete attribution payload in a public support channel.
