Реализация 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-scheme.
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 дня. Стоимость рассчитывается индивидуально.