Эта страница переведена с помощью Cloud Translation API.

Добавить фильтры намерений для ссылок приложений

App Links — это прямые ссылки, использующие протоколы HTTP или HTTPS и проверяемые Android на связь с вашим веб-сайтом. Для регистрации и обработки App Links выполните следующие шаги:

Добавьте в манифест вашего приложения один или несколько фильтров Intent, указывающих домен или URL-адреса вашего веб-сайта.
Добавьте autoVerify="true"attribute к элементам фильтра Intent. Это сигнализирует системе о необходимости проверить схему и домен(ы) хоста на соответствие конфигурации assetlinks.json вашего веб-сайта.
Укажите связи веб-сайта с другими ресурсами.

Ниже приведён пример объявления App Link с указанием схем и хостов, а также autoVerify="true ":

<activity
    android:name=".MainActivity"
    android:exported="true"
    ...>
    <!-- Make sure you explicitly set android:autoVerify to "true". -->
    <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" />

        <!-- If a user clicks on a link that uses the "http" scheme, your
             app should be able to delegate that traffic to "https". -->
        <!-- Do not include other schemes, as this will prevent verification. -->
        <data android:scheme="http" />
        <data android:scheme="https" />

        <!-- Include one or more domains that should be verified. -->
        <data android:host="www.example.com" />
        <data android:host="*.example.com" />
    </intent-filter>
</activity>

Основные моменты, касающиеся кода.

AutoVerify : Атрибут android:autoVerify="true " обязателен для App Links. Он сигнализирует системе о необходимости проверить связь между вашим приложением и схемами и доменами, указанными в тегах <data> . Рекомендуется добавлять autoVerify="true " к каждому фильтру Intent, который вы хотите сделать проверяемым.
Элементы данных : Каждый фильтр App Links Intent должен включать один или несколько элементов <data> , которые указывают схемы и форматы хостов, соответствующие вашему проверяемому домену веб-сайта.
Схемы : Фильтр намерений должен включать элементы <data> как для схем http , так и https .
Хосты : При желании вы можете добавить элементы <data> для сопоставления одного или нескольких хостов. Используйте подстановочный знак ( * ) для сопоставления нескольких поддоменов (например, *.example.com ). Система попытается проверить каждый хост на соответствие вашему файлу assetlinks.json на вашем веб-сайте. Обратите внимание, что любая маршрутизация на уровне пути должна обрабатываться файлом assetlinks.json (см. раздел «Рекомендации» ниже).
Несколько хостов : Если вы указываете несколько доменов хостов, система (на Android 12 и выше) пытается проверить каждый из них. Если какой-либо хост проверен, приложение становится обработчиком по умолчанию для ссылок с этого проверенного хоста. На Android 11 и ниже проверка завершается неудачей, если не удается проверить хотя бы один хост.
Фильтры для нескольких намерений : Важно создавать отдельные фильтры, если вы хотите указать уникальные URL-адреса (например, определенную комбинацию схемы и хоста), поскольку несколько элементов <data> в одном фильтре намерения объединяются для учета всех вариаций их комбинированных атрибутов.

Поддержка ссылок на приложения для нескольких хостов

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

Например, приложение со следующими фильтрами намерений пройдет проверку только для https://www.example.com , если файл assetlinks.json будет найден по адресу https://www.example.com/.well-known/assetlinks.json , но не по https://www.example.net/.well-known/assetlinks.json :

<application>

  <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="http" />
      <data android:scheme="https" />
      <data android:host="www.example.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="www.example.net" />
    </intent-filter>
  </activity>

</application>

Примечание: Все элементы <data> в одном фильтре намерений объединяются, чтобы учесть все варианты их комбинированных атрибутов. Например, первый фильтр намерений включает элемент <data> , который объявляет только схему HTTPS. Но он объединяется с другим элементом <data> , так что фильтр намерений поддерживает как http://www.example.com , так и https://www.example.com . Таким образом, вам необходимо создавать отдельные фильтры намерений, если вы хотите определить конкретные комбинации схем URI и доменов.

Поддержка связывания приложений для нескольких поддоменов

Протокол Digital Asset Links рассматривает поддомены в ваших фильтрах намерений как уникальные, отдельные хосты. Поэтому, если ваш фильтр намерений перечисляет несколько хостов с разными поддоменами, вы должны опубликовать действительный файл assetlinks.json для каждого домена. Например, следующий фильтр намерений включает www.example.com и mobile.example.com в качестве допустимых URL-адресов хостов намерений. Таким образом, действительный файл assetlinks.json должен быть опубликован как по адресу https://www.example.com/.well-known/assetlinks.json , так и по https://mobile.example.com/.well-known/assetlinks.json .

<application>
  <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>
  </activity>
</application>

В качестве альтернативы, если вы указываете имя хоста с подстановочным знаком (например, *.example.com ), вам необходимо опубликовать файл assetlinks.json на корневом хосте ( example.com ). Например, приложение со следующим фильтром намерений пройдет проверку для любого под-имени example.com (например, foo.example.com ), если файл assetlinks.json опубликован по адресу https://example.com/.well-known/assetlinks.json :

<application>
  <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:host="*.example.com" />
    </intent-filter>
  </activity>
</application>

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

Если вы публикуете несколько приложений, каждое из которых связано с одним и тем же доменом, каждое из них может быть успешно проверено. Однако, если приложения могут определить один и тот же хост и путь домена, как это может быть в случае с облегченной и полной версиями приложения, только приложение, установленное последним, сможет определять веб-интенты для этого домена.

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

Технология Dynamic App Links обеспечивает обратную совместимость с Android 14 и более ранними версиями.

Функции динамической привязки приложений, включая расширенные правила сопоставления в assetlinks.json и использование <uri-relative-filter-group> , полностью поддерживаются только на Android 15 (уровень API 35) и выше.

В Android 14 (уровень API 34) и ниже система учитывает для проверки App Link только scheme и host , указанные в элементах <data> вашего манифеста. Правила, исключения и динамические обновления, специфичные для пути, из файла assetlinks.json не применяются.

Это означает, что если в вашем манифесте указаны только scheme и host , ваше приложение может неожиданно перехватить все пути для проверенного домена на Android 14 и ниже, независимо от правил, специфичных для путей, определенных в вашем assetlinks.json для Android 15 и выше.

Для более старых версий Android следует использовать резервную стратегию без глубоких ссылок.

Чтобы предотвратить обработку всех ссылок для домена в Android 14 и ниже, если вы планируете использовать динамические ссылки приложения для более конкретных путей в Android 15 и выше, добавьте несоответствующий путь в фильтр намерений вашего манифеста. Добавьте элемент <data> с атрибутом android:path , который вряд ли когда-либо будет допустимым путем для ваших ссылок. Это гарантирует, что фильтр намерений не будет соответствовать всем путям в более старых версиях.

Пример:

<activity
    android:name=".MainActivity"
    android:exported="true"
    ...>
    <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="www.example.com" />

        <!-- Add a non-matching path for backward compatibility -->
        <data android:path="/no_match_for_older_android_versions" />

        <uri-relative-filter-group android:allow="true">
          <data android:pathPattern="/.*"/>
        </uri-relative-filter-group>
    </intent-filter>
</activity>

Добавив <data android:path="/no_match_for_older_android_versions" /> , вы гарантируете, что на Android 14 и ниже этот фильтр намерений не будет соответствовать входящим ссылкам, при этом позволяя проверять домен для использования с динамическими ссылками приложений на Android 15 и выше на основе расширенных правил сопоставления в вашем файле assetlinks.json .

Внимание: Если вы настроили <uri-relative-filter-group> в манифесте для Android 15 и выше, убедитесь, что действительный файл assetlinks.json доступен на указанном хосте. Если файл assetlinks.json отсутствует или недействителен, проверка App Links завершится неудачей на Android 15 и выше, и ваше приложение не будет обрабатывать ссылки для этого домена. В других случаях, когда файл assetlinks.json действителен, но отсутствует динамическая конфигурация, приложение может открываться для всех путей на Android 15 и выше на основе статического объявления манифеста.

Перенос существующих ссылок на приложения

Если у вас уже есть ссылки на приложения с определенными правилами пути (например, android:pathPrefix ) в манифесте и вы хотите начать использовать динамические ссылки на приложения в Android 15 и выше, вы можете безопасно добавить элемент <uri-relative-filter-group> непосредственно в существующие фильтры намерений.

Поскольку Android 14 и более ранние версии игнорируют элемент <uri-relative-filter-group> , ваши существующие ссылки на приложения продолжают работать точно так же, как и сейчас, на устройствах с более старыми версиями Android.

Однако необходимо внимательно изучить, как Android 15 и более поздние версии оценивают "смешанную" конфигурацию:

Двухуровневая фильтрация: на Android 15 и выше система оценивает фильтры намерений как единое целое. URL-адрес проходит проверку манифеста, если он соответствует либо вашим устаревшим статическим тегам <data> , либо общим правилам в вашем <uri-relative-filter-group> . После того, как URL-адрес проходит эту первоначальную проверку манифеста, система применяет динамические правила, определенные в вашем файле assetlinks.json , в качестве второго уровня более детальной фильтрации. Это означает, что правила JSON на стороне сервера в конечном итоге определяют, какие из соответствующих URL-адресов фактически открывают приложение.

Пример гибридной конфигурации:

<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:host="www.example.com" />

    <!-- Legacy rule: Android 14 and lower use this. Android 15 and higher
         also use this. -->
    <data android:pathPrefix="/store" />

    <!--
      Dynamic rule: Android 14 and lower ignore this. Android 15 and higher
      evaluate this as a union between all paths and the configuration
      specified in the assetlinks.json file. Make sure to apply further
      refinements in the assetlinks.json file to prevent all URL paths from
      opening in the app.
    -->
    <uri-relative-filter-group android:allow="true">
        <data android:pathPrefix="/" />
    </uri-relative-filter-group>
</intent-filter>