Android App Links не проходят проверку: диагностика за пять минут с adb
С Android 12 App Link, не прошедший проверку домена, открывается в браузере вместо приложения — молча и не на всех устройствах. Вот adb-чеклист, который быстро находит причину, включая несовпадение ключа подписи Play, стоящее за большинством таких инцидентов.
Приложение установлено. Ссылка всё равно открывает Chrome.
Обычно это всплывает как тикет в поддержку, а не как ошибка. Человек нажимает ссылку на ваш домен, приложение стоит на телефоне, а открывается Chrome. С Android 12, согласно документации Android, https-ссылка открывает приложение только если система проверила домен при установке — и когда проверка проваливается, она проваливается молча. Ни креша, ни уведомления, ничего в ваших дашбордах.
Два свойства делают отладку мучительной. Проверка идёт по доменам: example.com может быть верифицирован, пока promo.example.com — нет. И по устройствам: одна и та же сборка проходит на Pixel и падает на Samsung — сочетание, о котором регулярно сообщают в ветках форумов разработчиков Samsung. Если вы читаете это посреди инцидента — переходите сразу к диагностике.
Два домена, два вердикта
Что на самом деле происходит при установке
При установке или обновлении Android читает каждый домен, объявленный с autoVerify, и скачивает https://вашдомен/.well-known/assetlinks.json для каждого. Согласно документации Android, файл должен вернуться прямым 200 по HTTPS с content type application/json — верификатор не следует редиректам. Результат кэшируется по доменам; поэтому один поддомен может быть верифицирован, а соседний — нет.
Внутри файла sha256_cert_fingerprints должен совпадать с сертификатом, подписавшим APK на устройстве. Ловушка номер один: при Play App Signing это ключ подписи Google — не ваш upload-ключ. Отпечаток из локального keystore отлично верифицирует сборки, установленные вручную, и проваливает каждую установку из Play Store.
Ещё одно свойство: вердикт кэшируется. Исправление JSON на сервере ничего не меняет на уже провалившихся телефонах, пока проверка не запустится снова — что, к счастью, можно форсировать.
Диагностика за пять минут
Подключите любое устройство с Android 12+ и установленным приложением и выполните команды по порядку. Большинство инцидентов решается на третьем шаге.
Прочитайте состояние проверки
adb shell pm get-app-links com.example.appКоманда печатает каждый объявленный домен с его состоянием. verified — рукопожатие прошло; none — верификатор так и не одобрил домен, именно он отправляет пользователей в Chrome. На многопользовательских устройствах проверьте и секцию по пользователям внизу вывода.
Скачайте assetlinks.json так, как это делает верификатор
curl -sI https://example.com/.well-known/assetlinks.jsonНужен прямой 200. Любой 301 или 302 проваливает проверку: согласно документации Android верификатор не следует редиректам. Убедитесь, что content-type — application/json, затем скачайте тело и прочитайте имя пакета и отпечатки своими глазами. Защита от ботов или авторизация перед /.well-known/ тоже считается провалом.
Сверьте отпечаток с ключом подписи Play
Play Console → App integrity → App signing key certificateОткройте эту страницу Play Console и положите SHA-256 рядом с вашим JSON. Они должны совпадать байт в байт. Если в файле отпечаток upload-ключа — вы нашли баг: добавьте отпечаток ключа подписи Play, а если распространяете сборки и вне Play Store, держите оба.
Форсируйте повторную проверку
adb shell pm verify-app-links --re-verify com.example.appПочинив серверную сторону, попросите устройство попробовать снова. Верификатор работает асинхронно: подождите несколько секунд, повторите первый шаг и смотрите, как none меняется на verified. На некоторых устройствах Samsung состояние не сдвигается до перезагрузки — паттерн, о котором сообщают на форумах разработчиков Samsung.
Запустите интент как настоящее нажатие
adb shell am start -a android.intent.action.VIEW -d "https://example.com/promo"Это сквозной тест. На верифицированном домене приложение открывается сразу, без выбора. Если появился браузер или окно выбора, состояние ещё не переключилось — перепроверьте первый шаг, прежде чем решать, что исправление не сработало.
Если не хочется вычитывать JSON глазами посреди инцидента, наш инструмент проверки ссылок скачает ваш assetlinks.json и за один проход проверит код ответа, content type и формат отпечатков.
Обычные подозреваемые
Пять причин покрывают почти все известные случаи. Слева причина, справа решение.
В JSON отпечаток upload-ключа, а не ключа подписи Play
Скопируйте SHA-256 со страницы Play Console → App integrity → App signing key certificate. Если распространяете сборки, подписанные upload-ключом, держите оба отпечатка.
assetlinks.json отвечает редиректом или 404
Отдавайте файл напрямую по /.well-known/assetlinks.json на каждом объявленном хосте. Для верификатора www и «голый» домен — два разных домена.
Неверный content type, например text/html или text/plain
Настройте сервер или CDN отдавать application/json по этому пути. Корректный JSON с неправильным заголовком всё равно проваливается.
Несколько flavor или имён пакетов, одного нет в файле
Файл — это массив: по одному заявлению на имя пакета, каждое со своими отпечатками. Пропущенный flavor падает только сам, что в QA выглядит бессистемно.
Samsung остаётся в none после исправления JSON
Задержка проверки на некоторых моделях Samsung — повторяющаяся тема на форумах разработчиков Samsung. Форсируйте повторную проверку, затем перезагрузите устройство, прежде чем делать другие выводы.
Что изменили Android 15 и 16
Два недавних релиза сдвинули планку в одном направлении: поддерживаемый путь — верифицированные https App Links, всё остальное сужается.
Добавил Dynamic App Links, согласно примечаниям к релизу: привязки доменов можно обновлять без выпуска нового APK, что сокращает цикл между исправлением JSON и его подхватом устройствами.
Ужесточил проверку кастомных URI-схем, согласно примечаниям к релизу. Если часть вашего потока всё ещё держится на схемах myapp://, считайте их наследием и переносите входные точки на верифицированные https-ссылки.
Где честно уместна smart-ссылка
Smart-ссылка маршрутизирует на сервере, до того как вся эта механика включится: когда кто-то открывает ссылку Appy, редирект читает устройство и отправляет посетителей Android, iOS и десктопа в разные назначения. Эта маршрутизация работает на всех тарифах и не зависит от проверки на устройстве, потому что происходит до того, как ОС увидит ваш домен.
Честно о том, чего она не делает: smart-ссылка не может обойти проверку App Links. Редирект заканчивается на вашем https-домене, и тот же статус verified-или-none решает, откроется приложение или браузер. Что она даёт посреди инцидента — управляемую входную дверь: направьте Android-трафик на страницу Play Store или веб, пока чините assetlinks.json, а потом верните назначение обратно, не трогая ничего напечатанного — динамические QR-коды остаются редактируемыми после печати. Аналитика покажет, сколько Android-трафика прошло через сломанный путь.
Проверку чините в любом случае. Deeplink-назначения на Pro и отложенный deeplink на Enterprise полезны, но они опираются на работающий assetlinks.json, а не заменяют его.
Частые вопросы
Почему одна и та же ссылка работает на одном устройстве и не работает на другом?
Проверка выполняется на каждом устройстве при установке, поэтому каждый телефон хранит собственный кэшированный вердикт. Сетевой сбой при установке, иначе ведущий себя OEM-верификатор — Samsung чаще всего фигурирует на своих форумах разработчиков — или установка до вашего исправления JSON дают разные состояния для одной сборки.
Нужно ли выпускать обновление приложения?
Обычно нет. Если манифест уже объявляет домен с autoVerify, поломка — в JSON-файле или отпечатке, и то и другое на сервере. Исправьте файл, форсируйте повторную проверку — и установленная сборка начнёт открывать ссылки. Обновление нужно только если домен вообще не был объявлен.
Обходит ли smart-ссылка проверку?
Нет — и остерегайтесь любых обещаний обратного. Редирект выбирает назначение на сервере, но когда посетитель попадает на ваш https-домен, система применяет тот же статус проверки, что и всегда. Smart-ссылка меняет то, что вы можете делать, пока проверка сломана — вести в стор или веб, — а не сам факт поломки.
Через сколько проверка повторится сама?
Согласно документации Android, верификатор повторяет проверку упавших доменов и запускается заново при обновлении приложения, но расписание не гарантировано и зависит от OEM. На практике — от часов до дней. Форсировать проверку через adb или переустановить приложение быстрее, чем ждать.
Продолжить изучение
Бесплатный план AppsFlyer только что сжался: что стало платным и какие у вас варианты
Deferred deep linking, брендированные домены, Smart Banners, массовые ссылки и API покинули бесплатный план Zero. Что изменилось, сколько стоит замена и как выполнить миграцию за один вечер.
Передача параметров в deeplink, Universal Links, магазины приложений и веб
Узнайте, как сохранять параметры кампании и контекста при переходе в приложение, стор, Universal Link или веб, не перезаписывая фиксированные значения.
Deferred deep linking: как это работает и когда применять
Переносите исходный intent ссылки через установку, чтобы новые пользователи попадали сразу на нужный экран, а не на дефолтную главную.
Ищете другое? Посмотрите все темы в блоге.
Дайте Android-трафику место для посадки
Создайте smart-ссылку, которая определяет устройство на сервере и ведёт Android-посетителей в приложение, стор или веб — а назначение поменяйте позже, не перепечатывая ни одного QR-кода.
Создать бесплатную smart-ссылку