Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Testowanie linków aplikacji

Podczas wdrażania funkcji linkowania aplikacji należy przetestować jej działanie, aby upewnić się, że system może powiązać aplikację z witrynami i obsługiwać żądania URL zgodnie z oczekiwaniami.

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

W sekcjach poniżej znajdziesz informacje o tym, jak ręcznie przetestować weryfikację linków do aplikacji. Jeśli wolisz, możesz przetestować weryfikację za pomocą narzędzia Play Deep Links lub Asystenta linków do aplikacji w Android Studio.

Potwierdź listę hostów do zweryfikowania

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

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

Skorzystaj z tej listy, aby sprawdzić, czy plik JSON protokołu Digital Asset Links jest dostępny w każdym wymienionym hoście i subdomenie.

Potwierdź pliki Digital Asset Links

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

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

W przypadku dynamicznych linków do aplikacji możesz też sprawdzić rozszerzenia relacji.

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

Sprawdzanie zasad dotyczących linków

W ramach procesu testowania możesz sprawdzić bieżące ustawienia systemu dotyczące obsługi linków. Aby uzyskać 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 robi to polecenie:

adb shell dumpsys package d

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

App linkages for user 0:

Po tym nagłówku dane wyjściowe mają następujący format, który zawiera listę ustawień 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 w przypadku danego użytkownika:

Package – identyfikuje aplikację na podstawie nazwy pakietu zadeklarowanej w jej manifeście.
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 której manifest zawiera android:autoVerify="true", ma stan always. Liczba szesnastkowa po tym stanie jest powiązana z zapisem w systemie Android dotyczącym preferencji użytkownika w zakresie połączenia aplikacji. Ta wartość nie wskazuje, czy weryfikacja się powiodła.

bez wyświetlania okna, tak jakby weryfikacja się powiodła.

Przykładowy test

Aby weryfikacja linku aplikacji zakończyła się powodzeniem, system musi być w stanie zweryfikować aplikację w każdej z witryn określonych w danym filtrze intencji, który spełnia kryteria linków aplikacji. Poniższy przykład pokazuje konfigurację pliku manifestu z kilkoma zdefiniowanymi linkami do aplikacji:

<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ć zweryfikować na podstawie poprzedniego manifestu:

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

Lista hostów, których platforma nie będzie próbować weryfikować na podstawie poprzedniego 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 stwierdzeń znajdziesz w artykule Tworzenie listy stwierdzeń.

Diagnozowanie rozwiązywania linków za pomocą flagi debug-link

Od Androida 17 możesz używać flagi --debug-link z poleceniem menedżera aktywności (am start), aby diagnozować, jak system rozwiązuje konkretny adres URL. To narzędzie zawiera szczegółowe zestawienie aplikacji kandydujących, które pasują do intencji, a także konkretne reguły z manifestu aplikacji i pliku assetlinks.json (w przypadku dynamicznych linków do aplikacji), które zostały ocenione podczas rozwiązywania.

Aby przetestować rozpoznawanie linków w przypadku konkretnego adresu URL, uruchom to polecenie w oknie terminala:

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

Wyniki diagnostyki są drukowane pod nagłówkiem App Link Resolution Debug i zawierają te sekcje, które pomagają zrozumieć proces rozwiązywania problemu:

Szczegóły miejsca docelowego: identyfikuje każdą pasującą aplikację kandydującą według nazwy pakietu i docelowego działania.
Dopasowanie filtra intencji (AndroidManifest.xml): pokazuje, które statyczne atrybuty w filtrze intencji w pliku manifestu (np. scheme, host, path, pathPrefix lub pathPattern) pasowały do identyfikatora URI.
Weryfikacja linków aplikacji: pokazuje bieżący stan weryfikacji domeny (np. STATE_SUCCESS).
Dynamiczne linki do aplikacji: jeśli aplikacja używa reguł dopasowywania dynamicznych linków do aplikacji w pliku assetlinks.json, w tej sekcji znajdziesz listę wszystkich reguł, które zostały sprawdzone w odniesieniu do identyfikatora URI. Każda reguła wskazuje dopasowane filtry identyfikatorów URI (np. prefiksy lub wzorce ścieżek) oraz pole allow:
- allow = 0: reguła zezwalająca lub włączająca (allow: true). Jeśli ta reguła pasuje, aplikacja może otworzyć identyfikator URI.
- allow = 1: reguła blokowania lub wykluczania (allow: false / exclude: true). Jeśli ta reguła pasuje, aplikacja nie może otworzyć identyfikatora URI.
- Uwaga: pusty ciąg znaków filtra (filter =) oznacza pusty prefiks ścieżki, który pasuje do wszystkich ścieżek w domenie (działa jak symbol wieloznaczny lub uniwersalny).

Przykładowe dane wyjściowe debugowania

Rozważmy aplikację (com.example.xyzapp) powiązaną z domenąhttps://xyz.com, która w pliku assetlinks.json definiuje reguły dynamiczne, aby wykluczyć /foo*, ale zezwolić na wszystkie inne ścieżki:

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

Podczas diagnozowania adresu URL https://xyz.com/foo za pomocą narzędzia --debug-link:

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

Polecenie wyświetla następujące zestawienie diagnostyczne:

--- App Link Resolution Debug ---

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

All Matching Candidates:

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

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

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

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

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

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

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

W tym przykładzie system ocenił 2 reguły dynamicznych linków do aplikacji z assetlinks.json:

Reguła 0 (allow = 1, filter = /foo): wygenerowana z {"/": "/foo*", "exclude": true}, jest to reguła wykluczania (allow: false) blokująca adresy URL zaczynające się od prefiksu ścieżki /foo.
Reguła 1 (allow = 0, filter =): wygenerowana z {"/": "*"}, jest to reguła uwzględniania (allow: true) z pustym prefiksem ścieżki (filter =), która pasuje do wszystkich ścieżek w xyz.com (reguła ogólna).

Jak działa rozdzielczość w tym przypadku:

Zarówno reguła 0, jak i reguła 1 pasują do adresu URL https://xyz.com/foo.
Reguły dynamicznych linków aplikacji są oceniane po kolei od góry do dołu (zastosowanie będzie miała pierwsza pasująca reguła).
Ponieważ Reguła 0 pojawia się na liście instrukcji jako pierwsza i jest regułą wykluczającą (allow = 1), ma ona pierwszeństwo przed ogólną regułą zezwalającą (Reguła 1).
Aplikacja jest więc wykluczona z obsługi https://xyz.com/foo, co powoduje, że system wraca do przeglądarki lub wyświetla okno dialogowe z prośbą o wyjaśnienie.