Ссылки тестового приложения

При внедрении функции связывания приложений следует протестировать её функциональность, чтобы убедиться, что система может связать ваше приложение с вашими веб-сайтами и обрабатывать URL-запросы так, как вы ожидаете.

Для проверки существующего файла с инструкциями можно использовать инструмент «Генератор и тестер списков инструкций» .

В следующих разделах описано, как проверить проверку ссылок в приложении вручную. При желании вы можете проверить проверку с помощью инструмента Play Deep Links или помощника по проверке ссылок в приложении Android Studio.

Подтвердите список хостов для проверки.

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

• Атрибут android:scheme со значением http или https
• Атрибут android:host с шаблоном URL-адреса домена
• элемент действия android.intent.action.VIEW
• android.intent.category.BROWSABLE category element

Используйте этот список, чтобы убедиться, что файл JSON с ссылками на цифровые активы предоставлен на каждом указанном хосте и поддомене.

Подтвердите файлы ссылок на цифровые активы.

Для каждого веб-сайта используйте API ссылок на цифровые активы, чтобы убедиться, что JSON-файл ссылок на цифровые активы правильно размещен и определен:

https://digitalassetlinks.googleapis.com/v1/statements:list?
   source.web.site=https://<var>domain.name</var>:<var>optional_port</var>&amp;
   relation=delegate_permission/common.handle_all_urls

Для динамических ссылок приложений вы также можете проверить расширения связей.

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

Проверьте правила размещения ссылок.

В рамках процесса тестирования вы можете проверить текущие системные настройки обработки ссылок. Используйте следующую команду, чтобы получить список существующих политик обработки ссылок для всех приложений на подключенном устройстве:

adb shell dumpsys package domain-preferred-apps

Следующая команда делает то же самое:

adb shell dumpsys package d

Команда возвращает список всех пользователей или профилей, определенных на устройстве, с предварительным заголовком в следующем формате:

App linkages for user 0:

После этого заголовка в выходных данных отображается список настроек обработки ссылок для данного пользователя в следующем формате:

Package: com.android.vending
Domains: play.google.com market.android.com
Status: always : 200000002

В этом списке указано, какие приложения связаны с какими доменами для данного пользователя:

• Package — идентифицирует приложение по имени пакета, указанному в его манифесте.
• Domains — отображает полный список хостов, веб-ссылки которых обрабатывает это приложение, используя пробелы в качестве разделителей.
• Status — отображает текущие настройки обработки ссылок для этого приложения. Приложение, прошедшее проверку и чей манифест содержит android:autoVerify="true" , отображает статус « always ». Шестнадцатеричное число после этого статуса связано с записью в системе Android о предпочтениях пользователя в отношении связывания приложений. Это значение не указывает, была ли проверка успешной.

Тестовый пример

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

<activity android:name="MainActivity">
        <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" />
            <data android:scheme="https" />
            <data android:host="www.example.com" />
            <data android:host="mobile.example.com" />
        </intent-filter>
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="https" />
            <data android:host="www.example2.com" />
        </intent-filter>
    </activity>

    <activity android:name="SecondActivity">
        <intent-filter>
            <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" />
            <data android:host="account.example.com" />
        </intent-filter>
    </activity>

      <activity android:name="ThirdActivity">
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <data android:scheme="https" />
            <data android:host="map.example.com" />
        </intent-filter>
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="market" />
            <data android:host="example.com" />
        </intent-filter>
      </activity>

</application>

Список хостов, которые платформа попытается проверить на основе приведенного выше манифеста, выглядит следующим образом:

www.example.com
mobile.example.com
www.example2.com
account.example.com

Список хостов, которые платформа не будет пытаться проверить на основе приведенного выше манифеста, выглядит следующим образом:

map.example.com (it does not have android.intent.category.BROWSABLE)
market://example.com (it does not have either an "http" or "https" scheme)

Чтобы узнать больше о списках утверждений, см. раздел «Создание списка утверждений» .

Диагностика разрешения связей с использованием флага debug-link.

Начиная с Android 17, вы можете использовать флаг --debug-link с командой диспетчера активности ( am start ), чтобы диагностировать, как система разрешает определенный URL-адрес. Этот инструмент предоставляет подробную информацию о приложениях-кандидатах, соответствующих заданию, а также конкретные правила из манифеста приложения и файла assetlinks.json (для динамических ссылок на приложения), которые были оценены во время разрешения.

Чтобы проверить разрешение ссылки для конкретного URL-адреса, выполните следующую команду в окне терминала:

adb shell am start --debug-link -a android.intent.action.VIEW -d "https://xyz.com/foo"

Результаты диагностики выводятся под заголовком App Link Resolution Debug и содержат следующие разделы, которые помогут вам понять процесс устранения проблемы:

• Информация о целевой активности: Идентифицирует каждое подходящее приложение-кандидат по названию пакета и целевому виду деятельности.
• Параметр Intent Filter Match ( AndroidManifest.xml ): показывает, какие статические атрибуты в фильтре Intent в манифесте (такие как scheme , host , path , pathPrefix или pathPattern ) соответствуют URI.
• Проверка привязки приложения: Отображает текущее состояние проверки домена (например, STATE_SUCCESS ).
• Динамические ссылки приложения: Если приложение использует правила сопоставления динамических ссылок приложения в файле assetlinks.json , в этом разделе перечислены все правила, которые были проверены на соответствие URI. Каждое правило указывает фильтры URI (например, префиксы путей или шаблоны) и поле allow :
  • allow = 0 : Правило разрешения/включения ( allow: true ). Если это правило выполняется, приложению разрешается открыть URI.
  • allow = 1 : Правило блокировки/исключения ( allow: false / exclude: true ). Если это правило выполняется, приложению запрещается открывать URI.
  • Примечание : Пустая строка фильтра ( filter = ) указывает на пустой префикс пути, соответствующий всем путям в домене (выступает в качестве подстановочного знака или универсального шаблона).

Пример отладочного вывода

Рассмотрим приложение ( com.example.xyzapp ), связанное с доменом https://xyz.com , которое определяет динамические правила в своем файле assetlinks.json , исключающие путь /foo* но разрешающие все остальные пути:

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.xyzapp",
      "sha256_cert_fingerprints": ["..."]
    },
    "relation_extensions": {
      "delegate_permission/common.handle_all_urls": {
        "dynamic_app_link_components": [
          {"/": "/foo*", "exclude": true},
          {"/": "*"}
        ]
      }
    }
  }
]

При диагностике URL-адреса https://xyz.com/foo с помощью --debug-link :

adb shell am start --debug-link -a android.intent.action.VIEW -d "https://xyz.com/foo"

В результате выполнения команды выводится следующая диагностическая информация:

--- App Link Resolution Debug ---

URI: https://xyz.com/foo
Resolution: Ambiguous (Multiple apps or Browser fallback)
This usually happens when multiple apps can handle the link and no default is set.

All Matching Candidates:

Target:
  Package: com.example.xyzapp
  Activity: com.example.xyzapp.MainActivity

  Intent Filter Match (AndroidManifest.xml)
    Scheme: 'https' matched android:scheme="https"
    Host: 'xyz.com' matched android:host="xyz.com"

App Link Verification:
  Verification status: STATE_SUCCESS
  Dynamic App Links:
    -> Matched Rule 0: UriRelativeFilterGroup { allow = 1, uri_filters = {UriRelativeFilter { uriPart = PATH, patternType = PREFIX, filter = /foo }},  }
    -> Matched Rule 1: UriRelativeFilterGroup { allow = 0, uri_filters = {UriRelativeFilter { uriPart = PATH, patternType = PREFIX, filter =  }},  }

Target:
  Package: org.chromium.webview_shell
  Activity: org.chromium.webview_shell.WebViewBrowserActivity

  Intent Filter Match (AndroidManifest.xml)
    Scheme: 'https' matched android:scheme="https"

---------------------------------

Starting: Intent { act=android.intent.action.VIEW dat=https://xyz.com/foo }

В этом примере система оценила два правила динамических ссылок на приложения из assetlinks.json :

• Правило 0 ( allow = 1 , filter = /foo ): Сгенерировано из {"/": "/foo*", "exclude": true} , это правило исключения ( allow: false ), блокирующее URL-адреса, начинающиеся с префикса пути /foo .
• Правило 1 ( allow = 0 , filter = ): Сгенерировано из {"/": "*"} , это правило включения ( allow: true ) с пустым префиксом пути ( filter = ), которое соответствует всем путям в xyz.com (полный список).

Как работает разрешение в этом сценарии:

1. И правило 0, и правило 1 соответствуют URL-адресу https://xyz.com/foo .
2. Правила динамической ссылки на приложение оцениваются последовательно сверху вниз (побеждает правило, совпавшее первым).
3. Поскольку правило 0 стоит первым в списке утверждений и является правилом исключения ( allow = 1 ), оно имеет приоритет над общим правилом allow ( правило 1 ).
4. Таким образом, приложение исключается из обработки запроса https://xyz.com/foo , в результате чего система переключается на браузер или отображает диалоговое окно для уточнения.