Weryfikacja linków aplikacji na Androida

Link aplikacji na Androida to specjalny rodzaj precyzyjnego linku, który umożliwia natychmiastowe otwieranie odpowiednich treści w aplikacji na Androida po kliknięciu adresu URL witryny bez konieczności wybierania 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ę do automatycznego otwierania linków w tej 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 refaktoryzacji elementów w pliku manifestu aplikacja pozostanie powiązana ze wszystkimi zdefiniowanymi jeszcze 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>, więc 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 z wieloma subdomenami

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 atrybut assetlinks.json w każdej domenie. Na przykład ten filtr intencji zawiera adresy www.example.com i mobile.example.com jako akceptowane hosty adresów URL intencji. Dlatego prawidłowy atrybut assetlinks.json musi być opublikowany zarówno na stronie https://www.example.com/.well-known/assetlinks.json, jak i na 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>

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>

Sprawdź, czy nie ma wielu aplikacji powiązanych z tą samą domeną

Jeśli opublikujesz kilka aplikacji powiązanych z tą samą domeną, każda z nich może zostać 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, które mogą wchodzić w kolizję z Twoją aplikacją. Możesz to zrobić, jeśli masz odpowiednią widoczność pakietu. Następnie w aplikacji wyświetl okno wyboru z wynikami wywołania funkcji queryIntentActivities(). Użytkownik może wybrać preferowaną aplikację z listy dopasowanych aplikacji wyświetlanych w oknie.

Deklarowanie powiązań z witrynami

W witrynie musi zostać opublikowany plik JSON protokołu Digital Asset Links, który wskazuje aplikacje na Androida powiązane z witryną i potwierdza intencje URL aplikacji. 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żej znajdziesz przykład pliku z instrukcjami, który deklaruje powiązanie z 2 aplikacjami oddzielnie i znajduje się w lokalizacji 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 w ramach tego samego hosta internetowego. 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 różnymi certyfikatami.

Powiązanie kilku witryn z jedną aplikacją

Powiązanie z tą samą aplikacją może zadeklarować wiele witryn w odpowiednich plikach assetlinks.json. W tych listach plików pokazano przykłady deklarowania 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. Inna jest tylko lokalizacja, w której są przechowywane te pliki (.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

Pamiętaj o tych kwestiach:

  • 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. Zapoznaj się z sekcją Obsługa łączenia aplikacji w przypadku wielu hostów.
  • Nie publikuj aplikacji z adresami URL rozwojowymi/testowymi w pliku manifestu, które mogą nie być dostępne publicznie (np. takie, które są dostępne tylko przez VPN). W takich przypadkach obejściem tego problemu jest skonfigurowanie wariantów kompilacji w celu wygenerowania innego pliku 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.

Weryfikacja automatyczna

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.BROWSABLE i android.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. Poczekaj co najmniej 20 sekund na zakończenie procesu weryfikacji asynchronicznej. Aby sprawdzić, czy system zweryfikował 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 wykonać ten proces niezależnie od tego, czy Twoja aplikacja jest kierowana na Androida 12.

Nawiązywanie połączenia 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 ustawia urządzenie w takim samym stanie, w jakim jest, zanim użytkownik wybierze domyślne aplikacje dla dowolnej domeny.

Rozpoczęcie procesu weryfikacji domeny

Po zresetowaniu stanu linków aplikacji na Androida na urządzeniu możesz przeprowadzić samą 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 następujące 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 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
Wymuszone odmowa dostępu do domeny – zwykle za pomocą polecenia powłoki.
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 już zweryfikowana.
legacy_failure
Domenę odrzucił starszy weryfikator. 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 przypisany do 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 poprosisz użytkownika o potwierdzenie, 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:

KotlinJava
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 }
 
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ń w powłoce, aby symulować proces wyboru przez użytkownika aplikacji powiązanej 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 kontekst dla użytkownika. Możesz na przykład wyświetlić ekran powitalny, okno dialogowe lub podobny element interfejsu użytkownika, który wyjaśnia użytkownikowi, dlaczego Twoja aplikacja powinna być domyślnym modułem obsługi dla danej domeny.

Przesyłanie prośby

Gdy użytkownik zrozumie, o co prosi Twoja aplikacja, wyślij 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:

KotlinJava
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)
 
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ą.

Zastanów się też nad wprowadzeniem aktywności w oknie lub akcie trampoliny, która (jeśli użytkownik tego chce) otworzyć link w aplikacji własnej firmy, w roli serwera proxy. Zanim skonfigurujesz aktywność w oknie lub trampolinie, skonfiguruj aplikację tak, by miała widoczność pakietów w aplikacjach własnych, które pasują do filtra intencji w sieci.

Testowanie linków aplikacji

Podczas wdrażania funkcji łączenia aplikacji należy przetestować funkcję łączenia, aby mieć pewność, że system może 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

Użyj tej listy, aby sprawdzić, czy plik JSON protokołu Digital Asset Links jest dostępny w przypadku każdego nazwanego hosta i poddomeny.

Potwierdź pliki protokołu Digital Asset Links

W przypadku każdej witryny użyj interfejsu API Digital Asset Links, 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

Możesz też użyć tego kodu:

adb shell dumpsys package d

Uwaga: odczekaj co najmniej 20 sekund od zainstalowania aplikacji, aby system mógł przeprowadzić 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 wyświetlają się w formacie podanym poniżej, aby wyświetlić ustawienia obsługi linków dla danego użytkownika: 

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ę po nazwie pakietu, zgodnie z zadeklarowaną 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 linku aplikacji przed zakończeniem weryfikacji, możesz zobaczyć fałszywie pozytywny wynik weryfikacji, mimo że weryfikacja zakończyła się niepowodzeniem. Ten błąd weryfikacji nie ma jednak znaczenia, czy użytkownik wyraźnie włączył w aplikacji obsługiwane linki 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 mieć możliwość zweryfikowania aplikacji na każdej z witryn określonych w filtrze intencji, który 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 próbuje zweryfikować na podstawie 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 zweryfikować linków aplikacji na Androida, sprawdź, czy nie występują poniższe 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 intencji
Sprawdź, czy w elemencie <intent-filter> podajesz adres 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 funkcja example.com. (z końcową kropką) udostępnia te same treści co 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

Takie działanie chroni aplikację.

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. Te informacje, w tym pełny fragment kodu JSON, możesz sprawdzić, wykonując instrukcje dotyczące deklarowania powiązań z witrynami.