Как проверить Android App Links для обеспечения мгновенного запуска приложений

Как проверить Android App Links в манифесте? Для проверки Android App Links необходимо разместить файл assetlinks.json в директории .well-known вашего домена, добавить атрибут android:autoVerify=“true” в activity запуска вашего манифеста и подтвердить подпись сертификата. Эта нативная проверка позволяет избежать появления диалоговых окон выбора браузера Chrome и неудобств, связанных с устаревшими URL-схемами, обеспечивая стабильность диплинков на уровне 98,7%.

В сфере мобильного роста и разработки приложений индустрия все чаще рассматривает Android SDK App Links как золотой стандарт для безопасной переадресации без лишних препятствий на устройствах Android. После обновления системы проверки пакетов Google ужесточила стандарты безопасности доменов. Без успешной верификации ссылки перенаправляются на стандартную веб-версию, вызывая диалоговые окна выбора браузера, что негативно сказывается на конверсии пользователей.

Признаем очевидное: принуждение пользователей выбирать браузер во время перехода по диплинку ухудшает пользовательский опыт. Вам необходим безопасный процесс верификации, который natively обходит диалоговые окна.

Мандат переадресации Android 12: почему неверифицированные домены перенаправляют пользователей в диалог выбора

Начиная с Android 12, Google ввела строгие требования автоматической проверки для intent-фильтров. Если ваше приложение объявляет пользовательские домены в манифесте с использованием схемы HTTPS, операционная система пытается проверить каждый из них во время установки.

Какова реальность? Одиночный сбой верификации нарушает всю цепочку:

• Системный диалог выбора: Если хотя бы один объявленный домен не проходит рукопожатие, Android отключает нативную маршрутизацию для всех доменов в манифесте, возвращаясь к системным подсказкам браузера.
• Принудительные веб-фоллбэки: Неверифицированные домены перенаправляют пользователей напрямую в Chrome, минуя ваши пути глубоких ссылок внутри приложения.
• Разрыв циклов конверсии: Пользователи вынуждены вручную искать целевые продукты в приложении, что приводит к массовому оттоку на этапе кампаний.

Чтобы предотвратить сбои переадресации, разработчики обязаны размещать действительный файл проверки активов на своем домене.

Спецификация Digital Asset Links: форматирование манифеста assetlinks JSON

Основой безопасных глубоких ссылок Android является манифест assetlinks.json. Диспетчер пакетов ОС запрашивает этот файл через безопасное HTTPS-соединение при установке приложения.

Схема assetlinks JSON: указание имен пакетов и отпечатков SHA-256

Файл assetlinks.json должен находиться в директории .well-known вашего домена. Ваш веб-сервер должен возвращать ответ HTTP 200 с заголовком content-type, установленным в application/json. Файл объявляет ассоциацию между вашим доменом и уникальной подписью сертификата приложения.

Обратитесь к приведенному ниже структурному стандарту для форматирования файла проверки активов Android:

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.opoinstall.travel",
      "sha256_cert_fingerprints": [
        "14:6D:E9:83:C5:30:06:22:98:5B:90:75:EF:C4:22:15:30:19:93:33:F4:6D:E9:83:C5:30:06:22:98:5B:90:75"
      ]
    }
  }
]

Декларации XML в Android Manifest: настройка Intent-фильтров и рукопожатий автоверификации

Чтобы дать операционной системе команду инициировать рукопожатие верификации, необходимо обновить файл AndroidManifest.xml. Целевая Activity запуска должна включать специальный intent-фильтр. Этот фильтр объявляет действие android.intent.action.VIEW, категории android.intent.category.DEFAULT и android.intent.category.BROWSABLE, а также атрибут android:autoVerify="true".

Обратитесь к стандартной XML-структуре ниже для настройки вашего манифеста:

<activity
    android:name=".MainActivity"
    android:exported="true"
    android:launchMode="singleTask">
    
    <!-- Включить автоматическую верификацию домена для Android App Links -->
    <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="http" />
        <data android:scheme="https" />
        <data android:host="travel.opwakeup.com" />
        <data android:host="travel-alternate.opwakeup.com" />
    </intent-filter>
</activity>

Android App Links против пользовательских URL-схем: проверка на уровне хоста и области безопасности

Чтобы оценить, как верифицированная привязка домена соотносится с неверифицированными пользовательскими протоколами в условиях современных ограничений безопасности Android, проанализируйте таблицу ниже:

Развертывание единого SDK для автоматизации рукопожатий домен-приложение

Ручное поддержание манифестов assetlinks для множества поддоменов и вариантов сборки — частая причина технических сбоев. Интеграция специализированной легкой платформы мобильной аналитики, такой как Opoinstall, автоматизирует всю архитектуру серверного хостинга.

Настройка вашего брендового домена в консоли разработчика

Ваша интеграция начинается с привязки доменов кампаний. Зарегистрируйте ваше приложение в консоли разработчика, чтобы получить AppKey. Этот токен связывает ваш скомпилированный мобильный клиент с центральной базой данных кликов.

Интеграция SDK на стороне клиента

Следующий шаг требует интеграции нашего легкого SDK для мобильных приложений с функцией запуска в один клик в ваши клиентские сборки. Эта неблокирующая библиотека подключается к методам входа вашего приложения, чтобы перехватывать входящие активности пользователей и разбирать контекстные данные.

Проверка активных утверждений хоста через API Digital Asset Links от Google

Чтобы убедиться, что ваш домен корректно отдает манифест, вы можете сделать запрос напрямую к API Digital Asset Links от Google:

https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://yourdomain.com&relation=delegate_permission/common.handle_all_urls

Этот программный вызов API проверяет, может ли поисковый робот Google корректно прочитать имя вашего пакета и отпечатки SHA-256. Это гарантирует, что ваши серверные конфигурации полностью синхронизированы.

Отладка сбоев верификации доменов: кейс потери 15% мобильных App Links

Крупное туристическое приложение прошло стандартное системное обновление. Во время стейджинга QA-команда сообщила, что диплинки в рекламных письмах перестали работать на устройствах с Android 12 и 13, вынуждая пользователей выбирать веб-браузер вместо нативного запуска приложения.

Аномальные симптомы: постоянные всплывающие окна выбора браузера на Android 12+

Глубокие ссылки корректно работали на старых устройствах. Однако строгая политика верификации в Android 12 означала, что из-за того, что один вторичный домен не прошел рукопожатие, ОС отключила App Links для всех доменов, объявленных в манифесте. Это привело к 15% падению конверсии при онбординге.

Отладка через CLI с помощью Android Debug Bridge и сверка состояний

Инженерная команда инициировала технический аудит. Сначала они подтвердили, что скомпилированный пакет приложения содержит верные разрешения. Они выполнили проверку разрешений через командную строку на подключенном тестовом устройстве с использованием Android Debug Bridge (ADB):

# Шаг 1: Сброс состояния проверки доменов для целевого пакета
$ adb shell pm set-app-links --package com.opoinstall.travel 0 all

# Шаг 2: Вручную инициировать рукопожатие автоматической проверки ОС
$ adb shell pm verify-app-links --re-verify com.opoinstall.travel

# Шаг 3: Запросить динамическое состояние проверки ваших объявленных доменов
$ adb shell pm get-app-links com.opoinstall.travel

Вывод командной строки вернул статус state: 1024 (unverified). Это подтвердило, что диспетчер пакетов Android отклонил ассоциацию домена с приложением при установке.

Разрешение блоков переадресации HTTPS и несоответствий списков утверждений

Разработчики опросили робота Google по проверке ссылок, чтобы локализовать ошибку. Логи робота выявили таймаут TLS-рукопожатия: веб-сервер разместил файл assetlinks.json за брандмауэром, который блокировал IP-адреса автоматизированных роботов Google.

Кроме того, сервер выполнял редирект 301 с порта HTTP на HTTPS. Поскольку система верификации Android строго запрещает HTTP-редиректы для App Links, автоматическое рукопожатие не удавалось.

Для устранения блокировки команда настроила свой веб-сервер на возврат прямого ответа HTTP 200 на порту 443 с заголовком application/json, минуя любые HTTP-перенаправления. Чтобы гарантировать активность пути фоллбэка, они убедились, что скрипт переадресации на стороне клиента использует стандартный API Google Play Install Referrer для захвата данных об установке.

Аудит после миграции: восстановлена 15% конверсия пользователей и достигнут 98,7% успех верификации

После переустановки обновленного пакета инженерная команда перезапустила инструмент проверки ADB. Команда вернула состояние verified.

SDK мгновенно перехватил intent-ы диплинков, не вызывая диалоговых окон выбора. Точность переадресации восстановилась до 98,7%, успешно вернув бесшовный опыт бронирования для всех пользователей кампаний и защитив ROI маркетинговых инвестиций клиента.

По мере того как мобильные ОС ужесточают требования к приватности в «песочницах», сфера глубоких ссылок должна развиваться. Устаревание традиционных идентификаторов отслеживания (таких как IDFA) означает, что передача данных при переадресации должна полностью опираться на безопасную ассоциацию доменов первого уровня. Платформы, автоматизирующие хостинг AASA и проверку подписей, останутся жизненно важными. Централизовав инфраструктуру маршрутизации на базе безопасных SDK, вы защитите свои воронки роста от будущих изменений в политике конфиденциальности, одновременно предоставляя пользователям бесшовный и безопасный путь взаимодействия.