Реалізація App Links для Android-додатку
App Links — це верифіковані deep links, які Android відкриває напрямку в додатку без діалогу вибору браузера. Різниця принципова: звичайний intent-filter з http-схемою показує користувачеві «відкрити в браузері чи додатку». App Links з верифікацією через .well-known/assetlinks.json — відкривають додаток відразу. Для маркетингових посилань, email-кампаній та QR-кодів це безпосередньо впливає на конверсію.
Технічний механізм
У маніфесті intent-filter прописується з android:autoVerify="true" та схемою https. Android при встановленні додатку (і при оновленні, з API 31 — асинхронно у фоні) звертається до https://your-domain.com/.well-known/assetlinks.json та перевіряє, що SHA-256 fingerprint підпису додатку збігається з записом у файлі.
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="https" android:host="example.com" />
</intent-filter>
Файл assetlinks.json розміщується на сервері з Content-Type application/json та без редиректів — верифікатор не слідує редиректам. Типова помилка: файл віддається з редиректом http → https або з неправильним MIME-типом text/plain. Верифікація падає мовчки — у логах adb shell pm get-app-links --user 0 com.example.app видно статус 1024 (failed).
Fingerprint підпису — не той, що в debug.keystore. Production App Links працюють тільки з release-підписом. При використанні Google Play App Signing потрібен fingerprint із Google Play Console → Setup → App signing, а не локального keystore.
Де частіше за все ломається верифікація
Кілька доменів. Додаток хоче відкриватися і по example.com, і по www.example.com, і по m.example.com. Кожен домен потребує свого intent-filter та свого assetlinks.json на кожному поддомені. Забули про www — посилання з www відкриваються в браузері.
Субдомени та wildcards. android:host не підтримує wildcards типу *.example.com. Кожен субдомен — окремий запис. Для додатків з динамічними субдоменами (мультитенантні SaaS) App Links не підходять — потрібна кастомна URI-схема.
API 31+ та Package Visibility. З Android 12 змінилась поведінка верифікації: якщо домен верифікувався раніше, переверифікація при оновленні відбувається асинхронно. У період до завершення верифікації посилання можуть відкриватися з діалогом вибору. Рішення — adb shell pm verify-app-links --re-verify com.example.app для форсованої верифікації у тестуванні.
Обробка в Activity. Intent з ACTION_VIEW приходить в onCreate (при холодному старті) та в onNewIntent (якщо Activity вже запущена з launchMode="singleTop" або singleTask). Пропустити onNewIntent — означає втратити deep link при переході з фону.
Що налаштовуємо крім базової верифікації
Параметри в URI-шляху потрібно коректно парсити — через Uri.getQueryParameter(), а не ручним розбором строки. Якщо додаток використовує Navigation Component, NavDeepLinkBuilder та deepLink {} у NavGraph обробляють маппінг URI → екран декларативно.
Для аналітики кожен оброблений deep link повинен логуватись з джерелом — це дозволяє відслідковувати конверсію маркетингових кампаній через Firebase Analytics або Amplitude.
Строки: налаштування App Links з верифікацією — 1-2 дні. Якщо потрібна обробка кількох доменів, параметрів та інтеграція з навігацією — 2-3 дні. Вартість розраховується індивідуально.