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 sprawdzi, czy te adresy URL należą do Ciebie, system automatycznie przekieruje te intencje do Twojej aplikacji.

Aby potwierdzić, że jesteś właścicielem aplikacji i adresów URL witryny, wykonaj te czynności:

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

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

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

Powiązane informacje znajdziesz w tych materiałach:

Dodawanie filtrów intencji na potrzeby weryfikacji linków do aplikacji

Aby włączyć weryfikację obsługi linków w aplikacji, dodaj filtry intencji zgodne z tym formatem:

<!-- 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". -->
    <data android:scheme="http" />
    <data android:scheme="https" />

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

Chociaż uwzględnienie właściwości autoVerify w przypadku każdego hosta wystarczy w jednej deklaracji <intent-filter>, to nawet jeśli ten host jest używany w innych nieoznaczonych deklaracjach, zalecamy dodanie właściwości 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 ta znajduje się w elemencie <intent-filter> zawierającym dokładnie format określony we wcześniejszym fragmencie kodu.

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

System musi mieć możliwość zweryfikowania hosta określonego w elementach danych filtrów intencji URL aplikacji w porównaniu z plikami Digital Asset Links hostowanymi w odpowiednich domenach internetowych w ramach tego filtra intencji. Jeśli weryfikacja się nie powiedzie, system domyślnie powraca do standardowego zachowania, aby rozwiązać intencję, jak opisano w artykule Tworzenie precyzyjnych linków do treści aplikacji. Nadal można jednak zweryfikować aplikację jako domyślny moduł obsługi wszystkich wzorców adresów URL zdefiniowanych w innych filtrach intencji aplikacji.

Uwaga: na Androidzie 11 (poziom interfejsu API 30) i starszym system nie weryfikuje aplikacji jako domyślnego modułu obsługi, dopóki nie znajdzie pliku Digital Asset Links dla wszystkich hostów zdefiniowanych w pliku manifestu.

Na przykład aplikacja z tymi filtrami intencji przejdzie weryfikację tylko dla https://www.example.com, jeśli plik assetlinks.json znajdzie się w https://www.example.com/.well-known/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 zostały scalone, aby uwzględnić wszystkie odmiany ich połączonych atrybutów. Na przykład powyższy filtr pierwszego intencji zawiera element <data> deklarujący 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. W związku z tym, jeśli chcesz zdefiniować konkretne kombinacje schematów i domen identyfikatorów URI, 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 www.example.com i mobile.example.com jako akceptowane hosty adresu URL intencji. Dlatego prawidłowy 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 dla nazwy hosta używasz symbolu wieloznacznego (np. *.example.com), musisz opublikować plik assetlinks.json pod główną nazwą hosta (example.com). Na przykład aplikacja z tym filtrem intencji przejdzie weryfikację pod nazwą example.com (np. foo.example.com), dopóki plik assetlinks.json zostanie opublikowany pod adresem 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 wiele aplikacji powiązanych z tą samą domeną, każda z nich zostanie zweryfikowana. Jeśli jednak aplikacje mogą rozpoznać tego samego hosta domeny i tę samą ścieżkę (jak w przypadku wersji uproszczonych i pełnych), tylko ostatnio zainstalowana aplikacja może obsługiwać intencje internetowe w danej domenie.

W takim przypadku sprawdź, czy na urządzeniu użytkownika nie ma aplikacji będących w konflikcie, o ile masz niezbędną widoczność 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 pasujących aplikacji wyświetlanych w oknie.

Deklarowanie powiązań witryny

Aby wskazać aplikacje na Androida powiązane z witryną i sprawdzić intencje w adresach URL aplikacji, musisz opublikować w witrynie plik JSON Digital Asset Links. Plik JSON wykorzystuje te pola do identyfikowania powiązanych aplikacji:

  • package_name: identyfikator aplikacji zadeklarowany w pliku build.gradle aplikacji.
  • sha256_cert_fingerprints: odciski cyfrowe SHA256 certyfikatu podpisywania aplikacji. Do wygenerowania odcisku palca za pomocą narzędzia Java Keytool możesz użyć tego polecenia: 
    keytool -list -v -keystore my-release-key.keystore
    To pole obsługuje wiele odcisków cyfrowych, których można używać do obsługi różnych wersji aplikacji, np. do debugowania i kompilacji.

    Jeśli w swojej aplikacji korzystasz z podpisywania aplikacji przez Google Play, odcisk cyfrowy certyfikatu wygenerowany przez lokalne uruchomienie keytool zwykle nie będzie zgodny z odciskiem na urządzeniach użytkowników. To, czy korzystasz z podpisywania aplikacji przez Google Play, możesz sprawdzić na koncie dewelopera w Konsoli Play w sekcji Release > Setup > App signing. Jeśli to zrobisz, na tej samej stronie znajdziesz też prawidłowy fragment kodu JSON protokołu Digital Asset Links dla swojej aplikacji.

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

[{
  "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 zadeklarować 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 tego samego dostawcy hostingu witryn. Na przykład aplikacja app1 może zadeklarować filtr intencji dla elementu https://example.com/articles, a aplikacja app2 – filtr intencji dla elementu https://example.com/videos.

Uwaga: wiele aplikacji powiązanych z domeną może być podpisanych tym samym lub różnymi certyfikatami.

Powiązanie wielu witryn z jedną aplikacją

Powiązanie z tą samą aplikacją może zadeklarować wiele witryn w odpowiednich plikach assetlinks.json. 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"]
  }
}]

Na następnej stronie zobaczysz powiązanie domeny example.net z aplikacją 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 weryfikacyjnego pliku 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 parametrem content-type application/json.
  • Plik assetlinks.json musi być dostępny przez połączenie HTTPS niezależnie od tego, czy filtry intencji aplikacji deklarują HTTPS jako schemat danych.
  • Plik assetlinks.json musi być dostępny bez przekierowań (nie może to być przekierowania 301 ani 302).
  • Jeśli linki 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 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 zasada android:autoVerify="true" jest obecna w co najmniej jednym z filtrów intencji aplikacji, zainstalowanie jej na urządzeniu z Androidem 6.0 (poziom interfejsu API 23) lub nowszym powoduje, że system automatycznie weryfikuje hosty powiązane 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 w systemie obejmuje:

  1. System sprawdza wszystkie filtry intencji, które zawierają dowolny 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 powyższych filtrach intencji Android wysyła zapytanie o odpowiednie witryny do pliku Digital Asset Links pod adresem https://hostname/.well-known/assetlinks.json.

Gdy potwierdzisz listę witryn do powiązania z Twoją aplikacją oraz że hostowany plik JSON jest prawidłowy, zainstaluj aplikację na swoim 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żna 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 można było zweryfikować domenę, urządzenie testowe musi być połączone z internetem.

Obsługa zaktualizowanego procesu weryfikacji domeny

Jeśli aplikacja jest kierowana na Androida 12 lub nowszego, system automatycznie użyje zaktualizowanego procesu weryfikacji domeny.

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

adb shell am compat enable 175408749 PACKAGE_NAME

Resetowanie stanu linków aplikacji na Androida na urządzeniu

Zanim ręcznie wywołasz weryfikację domeny na urządzeniu, musisz zresetować stan linków aplikacji na Androida na urządzeniu testowym. Aby to zrobić, uruchom poniższe polecenie w oknie terminala:

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.

Wywoływanie procesu weryfikacji domeny

Po zresetowaniu stanu linków aplikacji na Androida na urządzeniu możesz przeprowadzić samą weryfikację. Aby to zrobić, uruchom następujące polecenie w oknie terminala:

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

Sprawdzanie wyników weryfikacji

Po odczekaniu czasu na zrealizowanie żądań przez agenta weryfikacji sprawdź jej wyniki. 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 w szczególności, że agent weryfikacyjny mógł jeszcze nie ukończyć procesu weryfikacji.

Na liście poniżej znajdziesz możliwe wartości zwracane przez weryfikację domeny:

none
Nic nie zostało zarejestrowane w tej domenie. Poczekaj jeszcze kilka minut, aż agent weryfikacyjny zakończy żądania związane z weryfikacją domeny, a następnie ponownie wywoła proces weryfikacji.
verified
Domena została zweryfikowana na potrzeby aplikacji deklarującej.
approved
Domena została zatwierdzona, zwykle za pomocą polecenia powłoki.
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 przywróceniu danych przez użytkownika. Zakładamy, że domena została już zweryfikowana.
legacy_failure
Domena została odrzucona przez starszego weryfikatora. Konkretna przyczyna niepowodzenia jest nieznana.
system_configured
Domena została automatycznie zatwierdzona przez konfigurację urządzenia.
Kod błędu: 1024 lub większy

Niestandardowy kod błędu przypisany do weryfikatora urządzenia.

Sprawdź, czy masz nawiązane połączenie sieciowe, i ponownie wywołaj proces weryfikacji domeny.

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

Innym sposobem na uzyskanie zatwierdzenia aplikacji w domenie jest poproszenie użytkownika o powiązanie z nią.

Sprawdzanie, czy aplikacja została już zatwierdzona w domenie

Zanim poprosisz użytkownika o potwierdzenie, sprawdź, czy Twoja aplikacja jest domyślnym modułem obsługi domen zdefiniowanych w elementach <intent-filter>. Możesz wysyłać zapytania o stan zatwierdzenia za pomocą jednej z tych metod:

Menedżer weryfikacji domen

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 programowania możesz uruchomić to polecenie, aby sprawdzić stan weryfikacji domen, które należą do Twojej organizacji:

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

W poniższych przykładowych danych wyjściowych nie udało się zweryfikować aplikacji w domenie „example.org”, jednak użytkownik 0 ręcznie zatwierdził aplikację w ustawieniach systemu i ż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ń jest dostępne w danych wyjściowych adb shell pm.

Podaj kontekst żądania

Zanim poprosisz o zatwierdzenie domeny, podaj kontekst dla użytkownika. 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, o co prosi Twoja aplikacja, wyślij prośbę. Aby to zrobić, wywołaj intencję zawierającą działanie intencji ACTION_APP_OPEN_BY_DEFAULT_SETTINGS oraz pasujący ciąg danych package:com.example.pkg dla aplikacji docelowej, jak to widać 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);

Po wywołaniu intencji użytkownicy zobaczą ekran ustawień o nazwie Otwórz domyślnie. Ten ekran zawiera opcję Otwórz obsługiwane linki, jak widać na rysunku 1.

Gdy użytkownik włączy opcję Otwieraj obsługiwane linki, w sekcji Linki do otwarcia w tej aplikacji pojawią się pola wyboru. Tutaj użytkownicy mogą wybrać domeny, które chcą powiązać z Twoją aplikacją. Mogą też kliknąć Dodaj link, by dodać domeny, jak pokazano na ilustracji 2. Gdy użytkownik kliknie później dowolny link w dodanych przez niego 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ń systemu, na którym użytkownicy mogą wybrać, które linki będą domyślnie otwierać się w aplikacji.
Każde pole wyboru oznacza domenę, którą możesz dodać. W tym oknie znajdują się przyciski „Anuluj” i „Dodaj”.
Rys. 2. Okno umożliwiające użytkownikom wybranie dodatkowych domen do powiązania z Twoją aplikacją.

Otwórz w aplikacji domeny, których aplikacja nie może zweryfikować

Główną funkcją aplikacji może być otwieranie linków przez firmę zewnętrzną bez możliwości weryfikowania obsługiwanych domen. W takim przypadku wyjaśnij użytkownikom, że po kliknięciu linku internetowego nie mogą wybrać między aplikacją własną a aplikacją innej firmy. Użytkownicy muszą ręcznie powiązać domeny z aplikacją innej firmy.

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.

Testuj linki do 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 instrukcji, możesz użyć narzędzia Generator i tester listy instrukcji.

Potwierdź listę hostów do weryfikacji

Podczas testowania musisz potwierdzić listę powiązanych hostów, które system powinien zweryfikować dla Twojej aplikacji. Utwórz listę wszystkich adresów URL, których odpowiednie filtry intencji zawierają te atrybuty i elementy:

  • android:scheme atrybut o wartości http lub https
  • Atrybut android:host z wzorcem adresu URL domeny
  • Działanie 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 trakcie 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 we wszystkich aplikacjach 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 i profili zdefiniowanych na urządzeniu poprzedzoną nagłówkiem w tym 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 domenami danego użytkownika:

  • Package – identyfikuje aplikację na podstawie nazwy pakietu zgodnie z deklaracją w pliku manifestu.
  • Domains – pokazuje pełną listę hostów, do których prowadzą linki internetowe obsługiwane przez tę aplikację, używając pustych pokoi jako separatorów.
  • Status – pokazuje aktualne ustawienie obsługi linków w tej aplikacji. Aplikacja, która przeszła weryfikację i ma w pliku manifestu wartość android:autoVerify="true", pokazuje 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. Ten błąd weryfikacji nie ma jednak znaczenia, czy użytkownik wyraźnie włączył w aplikacji obsługiwane linki bez pytania. Wynika to z faktu, że preferencje użytkownika mają pierwszeństwo przed weryfikacją automatyczną (lub jej brakiem). W rezultacie link prowadzi bezpośrednio do Twojej aplikacji bez wyświetlania okna, tak jakby weryfikacja się powiodła.

Przykład testowy

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 przedstawia konfigurację pliku manifestu ze zdefiniowanymi kilkoma linkami 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óbowała zweryfikować za pomocą 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 częstych 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 nazwa example.com jest używana jako zastępcza nazwa domeny. Podczas wykonywania tych testów 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

System nie weryfikuje żadnych linków aplikacji na Androida, jeśli skonfigurujesz przekierowanie, na przykład:

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

To działanie zapewnia bezpieczeństwo aplikacji.

Solidność serwera

Sprawdź, czy serwer może łączyć się z aplikacjami klienckimi.

Linki nieweryfikowalne

Na potrzeby testów możesz celowo dodać linki niemożliwe do zweryfikowania. Pamiętaj, że w Androidzie 11 i starszych wersjach te linki powodują, że system nie weryfikuje wszystkich linków aplikacji na Androida związanych z Twoją aplikacją.

Nieprawidłowy podpis w pliku assetlinks.json

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

  • Podpisać aplikację certyfikatem debugowania i mieć tylko podpis wersji w assetlinks.json.
  • Podpis pisany małymi literami w języku: 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ą.