Weryfikacja linków aplikacji na Androida

Link aplikacji na Androida to specjalny typ precyzyjnego linku, który umożliwia adresom URL witryn natychmiastowe otwieranie odpowiednich treści w aplikacji na Androida bez konieczności wyboru aplikacji przez użytkownika. Linki aplikacji na Androida korzystają z interfejsu Digital Asset Links API, aby potwierdzić, że Twoja aplikacja została zatwierdzona przez witrynę i automatycznie otwiera linki w danej domenie. Jeśli system potwierdzi, że jesteś właścicielem tych adresów URL, automatycznie przekieruje te intencje do Twojej aplikacji.

Aby potwierdzić, że aplikacja i adresy URL witryn należą do Ciebie:

  1. Dodaj filtry intencji, które zawierają atrybut autoVerify. Ten atrybut sygnalizuje systemowi, że powinien on sprawdzić, czy Twoja aplikacja należy do domen URL używanych w filtrach intencji.

  2. Zadeklaruj powiązanie między witryną a filtrami intencji, publikując plik JSON protokołu Digital Asset Links w tej lokalizacji:

    https://domain.name/.well-known/assetlinks.json

Powiązane informacje znajdziesz w tych materiałach:

Dodawanie filtrów intencji do weryfikacji linków aplikacji

Aby umożliwić weryfikację obsługi linków w aplikacji, dodaj filtry intencji o takim formacie:

<!-- 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 shared link that uses the "http" scheme, your
         app should be able to delegate that traffic to "https". -->
    <!-- Do not include other schemes. -->
    <data android:scheme="http" />
    <data android:scheme="https" />

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

Chociaż wystarczające jest uwzględnienie autoVerify tylko w jednej deklaracji <intent-filter> dla każdego hosta, nawet jeśli jest on używany w innych nieoznaczonych deklaracjach, zalecamy dodanie autoVerify do każdego elementu <intent-filter>, aby zachować spójność. Dzięki temu po usunięciu lub przekształceniu elementów w pliku manifestu Twoja aplikacja pozostanie powiązana ze wszystkimi zdefiniowanymi domenami.

Proces weryfikacji domeny wymaga połączenia z internetem i może zająć trochę czasu. Aby zwiększyć wydajność tego procesu, system weryfikuje domenę aplikacji kierowanej na Androida 12 lub nowszego tylko wtedy, gdy domena znajduje się w elemencie <intent-filter> zawierającym dokładny format określony w poprzednim fragmencie kodu. Na przykład schematy inne niż „http” i „https”, takie jak <data android:scheme="custom" />, uniemożliwiają <intent-filter> wywołanie weryfikacji domeny.

Obsługa łączenia aplikacji w przypadku wielu hostów

System musi mieć możliwość zweryfikowania hosta określonego w elementach danych filtra intencji adresu URL aplikacji na podstawie plików Digital Asset Links hostowanych w odpowiednich domenach internetowych w tym filtrze intencji. Jeśli weryfikacja się nie powiedzie, system zastosuje standardowe działanie w celu realizacji zamiaru, jak opisano w artykule Tworzenie precyzyjnych linków do treści aplikacji. Aplikacja może jednak zostać zweryfikowana jako domyślny moduł obsługi dla dowolnego wzorca adresu URL zdefiniowanego w innych filtrach intencji aplikacji.

Uwaga: w Androidzie 11 (poziom interfejsu API 30) i starszych system nie weryfikuje aplikacji jako domyślnego modułu obsługi, chyba że znajdzie pasujący plik Digital Asset Links dla wszystkich hostów zdefiniowanych w pliku manifestu.

Na przykład aplikacja z tymi filtrami intencji przeszłaby weryfikację tylko w przypadku https://www.example.com, jeśli w folderze https://www.example.com/.well-known/assetlinks.json znaleziono plik assetlinks.json, ale nie 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>

Uwaga: wszystkie elementy <data> w tym samym filtrze intencji są ze sobą łączone, aby uwzględnić wszystkie warianty ich połączonych atrybutów. Na przykład filtr pierwszego zamiaru powyżej zawiera element <data>, który deklaruje tylko schemat HTTPS. Jest on jednak połączony z innym elementem <data>, dzięki czemu filtr intencji obsługuje zarówno http://www.example.com, jak i https://www.example.com. Jeśli chcesz zdefiniować konkretne kombinacje schematów adresów URL i domen, musisz utworzyć osobne filtry intencji.

Obsługa łączenia aplikacji w przypadku wielu subdomen

Protokół Digital Asset Links traktuje subdomeny w filtrach intencji jako unikalne, oddzielne hosty. Jeśli więc Twój filtr intencji zawiera listę wielu hostów z różnymi subdomenami, musisz opublikować prawidłowy elementassetlinks.json w każdej domenie. Na przykład ten filtr intencji zawiera adresy www.example.commobile.example.com jako akceptowane hosty adresów URL intencji. Dlatego prawidłowa wartość assetlinks.json musi być opublikowana w przypadku obu wartości https://www.example.com/.well-known/assetlinks.jsonhttps://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>

Jeśli natomiast deklarujesz nazwę hosta za pomocą symbolu wieloznacznego (np. *.example.com), musisz opublikować plik assetlinks.json w nazwie hosta głównej (example.com). Na przykład aplikacja z tym filtrem intencji przejdzie weryfikację dla dowolnej nazwy podrzędnej example.com (np. foo.example.com), o ile plik assetlinks.json jest opublikowany w adresie 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>

Sprawdzanie, czy z tą samą domeną jest powiązanych wiele aplikacji

Jeśli opublikujesz wiele aplikacji powiązanych z tą samą domeną, każda z nich zostanie zweryfikowana. Jeśli jednak aplikacje mogą rozpoznać dokładnie tę samą nazwę hosta i ścieżkę domeny, co może mieć miejsce w przypadku wersji lite i pełnej aplikacji, tylko aplikacja, która została zainstalowana ostatnio, może rozpoznać intencje internetowe dla tej domeny.

W takim przypadku sprawdź, czy na urządzeniu użytkownika nie ma aplikacji będących w konflikcie, o ile dysponujesz niezbędną widocznością pakietu. Następnie w aplikacji wyświetli się niestandardowe okno wyboru z wynikami wywołania queryIntentActivities(). Użytkownik może wybrać preferowaną aplikację z listy dopasowanych aplikacji wyświetlanych w oknie.

Deklarowanie powiązań z witrynami

Aby wskazać aplikacje na Androida powiązane z witryną i zweryfikować intencje związane z adresami URL aplikacji, musisz opublikować w witrynie plik JSON Digital Asset Links. Plik JSON używa tych pól do identyfikowania powiązanych aplikacji:

Ten przykładowy plik assetlinks.json przyznaje aplikacji na Androida com.example uprawnienia do otwierania linków:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

Powiązanie witryny z wieloma aplikacjami

Witryna może deklarować powiązania z wieloma aplikacjami w tym samym pliku assetlinks.json Poniższa lista plików zawiera przykład pliku oświadczenia, który deklaruje powiązanie z 2 aplikacją, a znajduje się pod adresem https://www.example.com/.well-known/assetlinks.json:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.puppies.app",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
  },
  {
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.monkeys.app",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

Różne aplikacje mogą obsługiwać linki do różnych zasobów tego samego dostawcy hostingu witryn. Na przykład aplikacja 1 może zadeklarować filtr intencji dla https://example.com/articles, a aplikacja 2 – dla https://example.com/videos.

Uwaga: wiele aplikacji powiązanych z domeną może być podpisanych tym samym lub innym certyfikatem.

Powiązanie kilku witryn z jedną aplikacją

W odpowiednich plikach assetlinks.json może być zadeklarowanych wiele stron internetowych powiązanych z tą samą aplikacją. Poniższe listy plików pokazują przykład zadeklarowania powiązania example.com i example.net z aplikacją app1. Pierwsza strona z informacjami pokazuje powiązanie domeny example.com z aplikacją app1:

https://www.example.com/.well-known/assetlinks.json

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.mycompany.app1",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

Następna lista pokazuje powiązanie example.net z app1. Różni się tylko lokalizacja, w której są one hostowane (.com i .net):

https://www.example.net/.well-known/assetlinks.json

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.mycompany.app1",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

Publikowanie pliku weryfikacji w formacie JSON

Plik weryfikacyjny JSON musisz opublikować w tej lokalizacji:

https://domain.name/.well-known/assetlinks.json

Upewnij się, że:

  • Plik assetlinks.json jest udostępniany z typem treści application/json.
  • Plik assetlinks.json musi być dostępny przez połączenie HTTPS niezależnie od tego, czy filtry intencji aplikacji wskazują HTTPS jako schemat danych.
  • Plik assetlinks.json musi być dostępny bez żadnych przekierowań (bez przekierowań 301 ani 302).
  • Jeśli linki w aplikacji obsługują wiele domen hosta, musisz opublikować plik assetlinks.json w każdej z nich. Patrz Obsługa łączenia aplikacji w przypadku wielu hostów.
  • Nie publikuj w pliku manifestu adresów URL wersji deweloperskiej lub testowej, które mogą być niedostępne dla ogółu użytkowników (np. adresów dostępnych tylko za pomocą sieci VPN). W takich przypadkach można skonfigurować warianty kompilacji, aby wygenerować inny plik manifestu dla kompilacji deweloperskich.

Weryfikacja linków aplikacji na Androida

Jeśli w przynajmniej 1 filtrze intencji Twojej aplikacji występuje parametr android:autoVerify="true", zainstalowanie aplikacji na urządzeniu z Androidem 6.0 (poziom interfejsu API 23) lub nowszym spowoduje automatyczne sprawdzenie przez system hostów powiązanych z adresami URL w filtrach intencji aplikacji. W Androidzie 12 i nowszych możesz też ręcznie wywołać proces weryfikacji, aby przetestować logikę weryfikacji.

Automatyczna weryfikacja

Automatyczna weryfikacja systemu obejmuje:

  1. System sprawdza wszystkie filtry intencji, które obejmują co najmniej jeden z tych elementów:
    • Działanie: android.intent.action.VIEW
    • Kategorie: android.intent.category.BROWSABLEandroid.intent.category.DEFAULT
    • Schemat danych: http lub https
  2. W przypadku każdej unikalnej nazwy hosta znalezionej w wymienionych wyżej filtrach intencji Android wysyła zapytanie do odpowiednich witryn internetowych o plik Digital Asset Links (https://hostname/.well-known/assetlinks.json).

Po potwierdzeniu listy witryn, które chcesz powiązać z aplikacją, oraz po potwierdzeniu, że hostowany plik JSON jest prawidłowy, zainstaluj aplikację na urządzeniu. Zaczekaj co najmniej 20 sekund na zakończenie procesu weryfikacji asynchronicznej. Aby sprawdzić, czy system zweryfikował Twoją aplikację i ustawił prawidłowe zasady obsługi linków, użyj tego polecenia:

adb shell am start -a android.intent.action.VIEW \
    -c android.intent.category.BROWSABLE \
    -d "http://domain.name:optional_port"

Weryfikacja ręczna

Od Androida 12 możesz ręcznie wywoływać weryfikację domeny w przypadku aplikacji zainstalowanej na urządzeniu. Możesz to zrobić niezależnie od tego, czy aplikacja jest kierowana na Androida 12.

Nawiąż połączenie z internetem

Aby przeprowadzić weryfikację domeny, urządzenie testowe musi być połączone z internetem.

Obsługa zaktualizowanego procesu weryfikacji domeny

Jeśli Twoja aplikacja jest kierowana na Androida 12 lub nowszego, system automatycznie stosuje zaktualizowany proces weryfikacji domeny.

W przeciwnym razie możesz ręcznie włączyć zaktualizowany proces weryfikacji. Aby to zrobić, uruchom w terminalu to polecenie:

adb shell am compat enable 175408749 PACKAGE_NAME

Resetowanie stanu funkcji Android App Links na urządzeniu

Zanim ręcznie wywołasz weryfikację domeny na urządzeniu, musisz zresetować stan Android App Links na urządzeniu testowym. Aby to zrobić, uruchom w oknie terminala to polecenie:

adb shell pm set-app-links --package PACKAGE_NAME 0 all

To polecenie powoduje, że urządzenie ma ten sam stan, co przed wybraniem przez użytkownika domyślnych aplikacji w przypadku dowolnej domeny.

Rozpoczęcie procesu weryfikacji domeny

Po zresetowaniu stanu Android App Links na urządzeniu możesz przeprowadzić weryfikację. Aby to zrobić, uruchom w oknie terminala to polecenie:

adb shell pm verify-app-links --re-verify PACKAGE_NAME

Sprawdzanie wyników weryfikacji

Poczekaj, aż agent ds. weryfikacji zakończy swoje działania, a potem przejrzyj wyniki weryfikacji. Aby to zrobić, uruchom to polecenie:

adb shell pm get-app-links PACKAGE_NAME

Wynik tego polecenia jest podobny do tego:

com.example.pkg:
    ID: 01234567-89ab-cdef-0123-456789abcdef
    Signatures: [***]
    Domain verification state:
      example.com: verified
      sub.example.com: legacy_failure
      example.net: verified
      example.org: 1026

Domeny, które przeszły weryfikację, mają stan weryfikacji domeny verified. Każdy inny stan oznacza, że nie udało się zweryfikować domeny. Stan none oznacza, że agent weryfikujący może nie ukończyć jeszcze procesu weryfikacji.

Poniższa lista zawiera możliwe wartości zweryfikowanej domeny dla danej domeny:

none
W tej domenie nie zostało zarejestrowane nic. Poczekaj jeszcze kilka minut, aż agent ds. weryfikacji zakończy przetwarzanie żądań związanych z weryfikacją domeny, a następnie ponownie uruchom proces weryfikacji domeny.
verified
Domena została zweryfikowana w przypadku aplikacji deklaracyjnej.
approved
Domena została zatwierdzona przymusowo, zwykle przez wykonanie polecenia w powłoce.
denied
Domena została odrzucona, zwykle przez wykonanie polecenia w powłoce.
migrated
System zachował wynik poprzedniego procesu, w którym użyto starszej wersji weryfikacji domeny.
restored
Domena została zatwierdzona po tym, jak użytkownik przywrócił dane. Zakładamy, że domena została wcześniej zweryfikowana.
legacy_failure
Domena została odrzucona przez starszego weryfikatora. Szczegółowa przyczyna niepowodzenia jest nieznana.
system_configured
Domena została automatycznie zatwierdzona przez konfigurację urządzenia.
kod błędu 1024 lub wyższy,

niestandardowy kod błędu, który jest specyficzny dla weryfikatora urządzenia;

Sprawdź, czy masz połączenie z siecią, i ponownie uruchom proces weryfikacji domeny.

Poproś użytkownika o powiązanie aplikacji z domeną

Innym sposobem na uzyskanie zatwierdzenia aplikacji w przypadku domeny jest poproszenie użytkownika o powiązanie aplikacji z tą domeną.

Sprawdź, czy aplikacja jest już zatwierdzona w przypadku domeny

Zanim wyświetlisz użytkownikowi prompt, sprawdź, czy Twoja aplikacja jest domyślnym modułem obsługi domen zdefiniowanych w elementach <intent-filter>. Stan zatwierdzenia możesz sprawdzić za pomocą jednej z tych metod:

DomainVerificationManager

Ten fragment kodu pokazuje, jak korzystać z interfejsu API DomainVerificationManager:

Kotlin

val context: Context = TODO("Your activity or fragment's Context")
val manager = context.getSystemService(DomainVerificationManager::class.java)
val userState = manager.getDomainVerificationUserState(context.packageName)

// Domains that have passed Android App Links verification.
val verifiedDomains = userState?.hostToStateMap
    ?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_VERIFIED }

// Domains that haven't passed Android App Links verification but that the user
// has associated with an app.
val selectedDomains = userState?.hostToStateMap
    ?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_SELECTED }

// All other domains.
val unapprovedDomains = userState?.hostToStateMap
    ?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_NONE }

Java

Context context = TODO("Your activity or fragment's Context");
DomainVerificationManager manager =
        context.getSystemService(DomainVerificationManager.class);
DomainVerificationUserState userState =
        manager.getDomainVerificationUserState(context.getPackageName());

Map<String, Integer> hostToStateMap = userState.getHostToStateMap();
List<String> verifiedDomains = new ArrayList<>();
List<String> selectedDomains = new ArrayList<>();
List<String> unapprovedDomains = new ArrayList<>();
for (String key : hostToStateMap.keySet()) {
    Integer stateValue = hostToStateMap.get(key);
    if (stateValue == DomainVerificationUserState.DOMAIN_STATE_VERIFIED) {
        // Domain has passed Android App Links verification.
        verifiedDomains.add(key);
    } else if (stateValue == DomainVerificationUserState.DOMAIN_STATE_SELECTED) {
        // Domain hasn't passed Android App Links verification, but the user has
        // associated it with an app.
        selectedDomains.add(key);
    } else {
        // All other domains.
        unapprovedDomains.add(key);
    }
}

Program wiersza poleceń

Podczas testowania aplikacji w trakcie jej tworzenia możesz uruchomić to polecenie, aby sprawdzić stan weryfikacji domen należących do Twojej organizacji:

adb shell pm get-app-links --user cur PACKAGE_NAME

W wyniku podanym jako przykład, mimo że aplikacja nie przeszła weryfikacji w domenie „example.org”, użytkownik 0 zatwierdził ją ręcznie w ustawieniach systemu, a żaden inny pakiet nie został zweryfikowany w tej domenie.

com.example.pkg:
ID: ***
Signatures: [***]
Domain verification state:
  example.com: verified
  example.net: verified
  example.org: 1026
User 0:
  Verification link handling allowed: true
  Selection state:
    Enabled:
      example.org
    Disabled:
      example.com
      example.net

Możesz też użyć poleceń powłoki, aby symulować proces, w którym użytkownik wybiera aplikację powiązaną z daną domeną. Pełne wyjaśnienie tych poleceń znajdziesz w wyjściu polecenia adb shell pm.

Podawanie kontekstu prośby

Zanim poprosisz o zatwierdzenie domeny, podaj użytkownikowi kontekst. Możesz na przykład wyświetlić ekran powitalny, okno lub podobny element interfejsu, który wyjaśnia, dlaczego Twoja aplikacja powinna być domyślnym modułem obsługi w danej domenie.

Prześlij prośbę

Gdy użytkownik zrozumie, czego wymaga od niego aplikacja, możesz wysłać prośbę. Aby to zrobić, wywołaj intencję zawierającą działanie intencyjne ACTION_APP_OPEN_BY_DEFAULT_SETTINGS oraz ciąg danych dopasowany do wartości package:com.example.pkg w przypadku aplikacji docelowej, jak pokazano w tym fragmencie kodu:

Kotlin

val context: Context = TODO("Your activity or fragment's Context")
val intent = Intent(Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
    Uri.parse("package:${context.packageName}"))
context.startActivity(intent)

Java

Context context = TODO("Your activity or fragment's Context");
Intent intent = new Intent(Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
    Uri.parse("package:" + context.getPackageName()));
context.startActivity(intent);

Gdy wywołasz intencję, użytkownicy widzą ekran ustawień o nazwie Otwórz domyślnie. Ten ekran zawiera opcję Otwieraj obsługiwane linki, jak pokazano na rysunku 1.

Gdy użytkownik włączy opcję Otwieranie obsługiwanych linków, w sekcji Linki otwierane w tej aplikacji pojawi się kilka pól wyboru. Użytkownicy mogą w nich zaznaczyć domeny, które chcą powiązać ze swoją aplikacją. Mogą też wybrać opcję Dodaj link, aby dodać domeny, jak pokazano na rysunku 2. Gdy użytkownicy klikną link w dodanych domenach, otworzy się on automatycznie w aplikacji.

Gdy ta opcja jest włączona, sekcja u dołu strony zawiera pola wyboru oraz przycisk „Dodaj link”.
Rysunek 1. Ekran ustawień systemowych, na którym użytkownicy mogą wybrać, które linki mają otwierać się domyślnie w aplikacji.
Każde pole wyboru reprezentuje domenę, którą możesz dodać. Przyciski w tym oknie to „Anuluj” i „Dodaj”.
Rysunek 2. Okno, w którym użytkownicy mogą wybrać dodatkowe domeny do powiązania z Twoją aplikacją.

Otwieranie w aplikacji domen, których nie można zweryfikować

Główną funkcją aplikacji może być otwieranie linków jako aplikacji zewnętrznej bez możliwości weryfikacji obsługiwanych domen. W takim przypadku wyjaśnij użytkownikom, że w momencie kliknięcia linku internetowego nie mogą wybrać aplikacji własnej ani aplikacji innej firmy. Muszą ręcznie powiązać domeny z Twoją aplikacją.

Dodatkowo rozważ wprowadzenie okna dialogowego lub aktywności trampoliny, które umożliwi użytkownikowi otwarcie linku w aplikacji własnego wydawcy, jeśli woli to zrobić. Zanim skonfigurujesz takie okno dialogowe lub aktywność trampoliny, skonfiguruj aplikację tak, aby miała widoczność pakietu w aplikacjach własnych, które pasują do filtra intencji internetowej aplikacji.

Testowanie linków aplikacji

Wdrażając tę funkcję, przetestuj ją, aby mieć pewność, że system będzie w stanie powiązać aplikację z Twoimi witrynami i obsługiwać żądania adresów URL zgodnie z oczekiwaniami.

Aby przetestować istniejący plik oświadczenia, możesz użyć narzędzia Generator i tester listy oświadczeń.

Potwierdź listę hostów do zweryfikowania

Podczas testowania sprawdź listę powiązanych hostów, którą system powinien zweryfikować w przypadku Twojej aplikacji. Utwórz listę wszystkich adresów URL, których odpowiadające im filtry intencji zawierają te atrybuty i elementy:

  • atrybut android:scheme o wartości http lub https,
  • atrybut android:host z wzorcem adresu URL domeny.
  • Element działania android.intent.action.VIEW
  • Element kategorii: android.intent.category.BROWSABLE

Na tej liście możesz sprawdzić, czy na każdym nazwanym hoście i w każdej subdomenie dostępny jest plik JSON protokołu Digital Asset Links.

Potwierdź pliki Digital Asset Links

W przypadku każdej witryny użyj interfejsu Digital Asset Links API, aby sprawdzić, czy plik JSON protokołu Digital Asset Links jest prawidłowo hostowany i zdefiniowany:

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

W ramach procesu testowania możesz sprawdzić bieżące ustawienia systemu dotyczące obsługi linków. Aby wyświetlić listę istniejących zasad obsługi linków dla wszystkich aplikacji na połączonym urządzeniu, użyj tego polecenia:

adb shell dumpsys package domain-preferred-apps

To samo dotyczy polecenia:

adb shell dumpsys package d

Uwaga: po zainstalowaniu aplikacji poczekaj co najmniej 20 sekund, aż system zakończy proces weryfikacji.

Polecenie zwraca listę wszystkich użytkowników lub profili zdefiniowanych na urządzeniu, poprzedzoną nagłówkiem w takim formacie:

App linkages for user 0:

Po tym nagłówku dane wyjściowe zawierają listę ustawień obsługi linków dla tego użytkownika w takim formacie:

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

Ta lista wskazuje, które aplikacje są powiązane z którymi domenami dla danego użytkownika:

  • Package – identyfikuje aplikację na podstawie nazwy pakietu zgodnie z deklaracją w pliku manifestu.
  • Domains – wyświetla pełną listę hostów, których linki internetowe obsługuje ta aplikacja, używając spacji jako separatorów.
  • Status – pokazuje bieżące ustawienie obsługi linków w tej aplikacji. Aplikacja, która przeszła weryfikację i ma w manifeście android:autoVerify="true", ma stan always. Liczba szesnastkowa występująca po tym stanie jest związana z ustawieniami połączenia aplikacji użytkownika zapisanymi w systemie Android. Ta wartość nie wskazuje, czy weryfikacja się powiodła.

Uwaga: jeśli użytkownik zmieni ustawienia linków do aplikacji przed ukończeniem weryfikacji, to nawet wtedy, gdy weryfikacja się nie uda, może wyświetlić się fałszywy wynik. Niepowodzenie weryfikacji nie ma jednak znaczenia, jeśli użytkownik wyraźnie zezwolił aplikacji na otwieranie obsługiwanych linków bez pytania. Dzieje się tak, ponieważ ustawienia użytkownika mają pierwszeństwo przed weryfikacją programową (lub jej brakiem). W efekcie link prowadzi bezpośrednio do aplikacji, bez wyświetlania okna dialogowego, tak jak w przypadku udanej weryfikacji.

Przykład testu

Aby weryfikacja linku aplikacji się powiodła, system musi móc zweryfikować Twoją aplikację za pomocą każdej witryny, którą określisz w danym filtrze intencji i która spełnia kryteria linków aplikacji. Przykład poniżej pokazuje konfigurację pliku manifestu z kilkoma zdefiniowanymi linkami do aplikacji:

<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>
        <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>

Lista hostów, które platforma będzie próbowała zweryfikować za pomocą powyższego pliku manifestu:

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

Lista hostów, których platforma nie próbuje zweryfikować na podstawie powyższego pliku manifestu:

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

Więcej informacji o listach instrukcji znajdziesz w artykule o tworzeniu listy instrukcji.

Naprawianie typowych błędów implementacji

Jeśli nie możesz potwierdzić linków do aplikacji na Androida, sprawdź, czy nie występują te typowe błędy. W tej sekcji jako nazwa zastępcza domeny jest używana nazwa example.com. Podczas wykonywania tych kontroli zastąp example.com rzeczywistą nazwą domeny serwera.

Nieprawidłowa konfiguracja filtra zamiaru
Sprawdź, czy w elemencie <intent-filter> nie ma adresu URL, który nie należy do Twojej aplikacji.
Nieprawidłowa konfiguracja serwera

Sprawdź konfigurację JSON serwera i upewnij się, że wartość SHA jest prawidłowa.

Sprawdź też, czy adres example.com. (z kropką na końcu) wyświetla te same treści co adres example.com.

Przekierowania po stronie serwera

Jeśli skonfigurujesz przekierowanie takie jak to:

  • Od http://example.com do https://example.com
  • Od example.com do www.example.com

To działanie zapewnia bezpieczeństwo aplikacji.

niezawodność serwera;

Sprawdź, czy serwer może połączyć się z aplikacją klienta.

Nieweryfikowalne linki

Do celów testowych możesz celowo dodawać nieweryfikowalne linki. Pamiętaj, że w Androidzie 11 i starszych te linki powodują, że system nie weryfikuje wszystkich linków aplikacji na Androida Twojej aplikacji.

Nieprawidłowy podpis w pliku assetlinks.json

Sprawdź, czy podpis jest prawidłowy i czy jest zgodny z podpisem użytym do podpisania aplikacji. Typowe błędy:

  • Podpisanie aplikacji certyfikatem debugowania i posiadanie tylko podpisu wersji w pliku assetlinks.json.
  • podpis w wersji małej w assetlinks.json. Podpis powinien być pisany wielkimi literami.
  • Jeśli korzystasz z podpisywania aplikacji przez Google Play, upewnij się, że używasz podpisu, którego Google używa do podpisywania poszczególnych wersji. Możesz zweryfikować te szczegóły, w tym pełny fragment kodu JSON, postępując zgodnie z instrukcjami deklarowania powiązań z witryną.