Testare i link app

Quando implementi la funzionalità di collegamento delle app, devi testare la funzionalità di collegamento per assicurarti che il sistema possa associare la tua app ai tuoi siti web e gestire le richieste di URL come previsto.

Per testare un file di istruzioni esistente, puoi utilizzare lo strumento Statement List Generator and Tester.

Le sezioni seguenti descrivono come testare manualmente la verifica degli App Link. Se preferisci, puoi testare la verifica dallo strumento Deep link di Play o dall'assistente per app link di Android Studio.

Conferma l'elenco degli host da verificare

Durante i test, devi confermare l'elenco di host associati che il sistema deve verificare per la tua app. Crea un elenco di tutti gli URL i cui filtri per intent corrispondenti includono i seguenti attributi ed elementi:

• Attributo android:scheme con un valore http o https
• Attributo android:host con un pattern URL del dominio
• Elemento di azione android.intent.action.VIEW
• Elemento della categoria android.intent.category.BROWSABLE

Utilizza questo elenco per verificare che venga fornito un file JSON Digital Asset Links su ogni host e sottodominio denominato.

Conferma i file Digital Asset Links

Per ogni sito web, utilizza l'API Digital Asset Links per verificare che il file JSON Digital Asset Links sia ospitato e definito correttamente:

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

Per i link alle app dinamici, puoi anche controllare le estensioni di relazione.

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

Controlla le norme relative ai link

Nell'ambito della procedura di test, puoi controllare le impostazioni di sistema attuali per la gestione dei link. Utilizza il seguente comando per ottenere un elenco delle policy di gestione dei link esistenti per tutte le app sul dispositivo connesso:

adb shell dumpsys package domain-preferred-apps

Il comando seguente esegue la stessa operazione:

adb shell dumpsys package d

Nota: assicurati di attendere almeno 20 secondi dopo l'installazione dell'app per consentire al sistema di completare la procedura di verifica.

Il comando restituisce un elenco di ogni utente o profilo definito sul dispositivo, preceduto da un'intestazione nel seguente formato:

App linkages for user 0:

Dopo questa intestazione, l'output utilizza il seguente formato per elencare le impostazioni di gestione dei link per l'utente:

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

Questo elenco indica quali app sono associate a quali domini per quell'utente:

• Package: identifica un'app in base al nome del pacchetto, come dichiarato nel relativo manifest.
• Domains: mostra l'elenco completo degli host i cui link web sono gestiti da questa app, utilizzando spazi vuoti come delimitatori.
• Status: mostra l'impostazione di gestione dei link corrente per questa app. Un'app che ha superato la verifica e il cui manifest contiene android:autoVerify="true" mostra lo stato always. Il numero esadecimale dopo questo stato è correlato al record del sistema Android delle preferenze di collegamento dell'app dell'utente. Questo valore non indica se la verifica è andata a buon fine.

Nota: se un utente modifica le impostazioni dei link alle app per un'app prima che la verifica sia completata, potresti visualizzare un falso positivo per una verifica riuscita, anche se la verifica non è andata a buon fine. Tuttavia, questo errore di verifica non è importante se l'utente ha attivato esplicitamente l'app per aprire i link per la raccolta fondi senza chiedere. Questo perché le preferenze dell'utente hanno la precedenza sulla verifica programmatica (o sulla sua assenza). Di conseguenza, il link rimanda direttamente alla tua app, senza mostrare una finestra di dialogo, proprio come se la verifica fosse andata a buon fine.

Esempio di test

Affinché la verifica dei link alle app vada a buon fine, il sistema deve essere in grado di verificare la tua app con ciascuno dei siti web specificati in un determinato filtro per intent che soddisfa i criteri per i link alle app. L'esempio seguente mostra una configurazione del manifest con diversi link alle app definiti:

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

L'elenco degli host che la piattaforma tenterà di verificare dal manifest precedente è:

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

L'elenco degli host che la piattaforma non tenterà di verificare dal manifest precedente è:

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

Per scoprire di più sugli elenchi di istruzioni, consulta Creazione di un elenco di istruzioni.

Diagnostica la risoluzione dei link con il flag debug-link

A partire da Android 17, puoi utilizzare il flag --debug-link con il comando Activity Manager (am start) per diagnosticare il modo in cui il sistema risolve un URL specifico. Questo strumento fornisce un'analisi dettagliata delle app candidate che corrispondono all'intent, insieme alle regole specifiche del manifest dell'app e del file assetlinks.json (per i link alle app dinamici) che sono state valutate durante la risoluzione.

Per testare la risoluzione dei link per un URL specifico, esegui questo comando in una finestra del terminale:

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

L'output di diagnostica viene stampato sotto l'intestazione App Link Resolution Debug e contiene le seguenti sezioni per aiutarti a comprendere il processo di risoluzione:

• Dettagli target:identifica ogni app candidata corrispondente in base al nome del pacchetto e all'attività target.
• Corrispondenza del filtro per intent (AndroidManifest.xml): mostra quali attributi statici nel filtro per intent del manifest (come scheme, host, path, pathPrefix o pathPattern) corrispondevano all'URI.
• Verifica dei link alle app:mostra lo stato attuale della verifica del dominio (ad esempio STATE_SUCCESS).
• Link alle app dinamici:se l'app utilizza regole di corrispondenza dei link alle app dinamici nel file assetlinks.json, questa sezione elenca ogni regola valutata rispetto all'URI. Ogni regola indica i filtri URI corrispondenti (ad esempio prefissi o pattern di percorso) e un campo allow:
  • allow = 0: una regola di autorizzazione/inclusione (allow: true). Se questa regola corrisponde, l'app è autorizzata ad aprire l'URI.
  • allow = 1: una regola di blocco/esclusione (allow: false / exclude: true). Se questa regola corrisponde, l'app non può aprire l'URI.
  • Nota: una stringa di filtro vuota (filter =) indica un prefisso di percorso vuoto che corrisponde a tutti i percorsi nel dominio (funge da carattere jolly o catch-all).

Esempio di output di debug

Considera un'app (com.example.xyzapp) associata al dominio https://xyz.com che definisce regole dinamiche nel file assetlinks.json per escludere /foo* consentendo al contempo tutti gli altri percorsi:

[
  {
    "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},
          {"/": "*"}
        ]
      }
    }
  }
]

Durante la diagnosi dell'URL https://xyz.com/foo utilizzando --debug-link:

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

Il comando restituisce la seguente analisi diagnostica:

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

In questo esempio, il sistema ha valutato le due regole degli app link dinamici di assetlinks.json:

• Regola 0 (allow = 1, filter = /foo): generata da {"/": "/foo*", "exclude": true}, si tratta di una regola esclusiva (allow: false) che blocca gli URL che iniziano con il prefisso del percorso /foo.
• Regola 1 (allow = 0, filter =): Generata da {"/": "*"}, questa è una regola di inclusione (allow: true) con un prefisso di percorso vuoto (filter =), che corrisponde a tutti i percorsi sotto xyz.com ​​ (catch-all).

Come funziona la risoluzione in questo scenario:

1. Sia la Regola 0 che la Regola 1 corrispondono all'URL https://xyz.com/foo.
2. Le regole dei link dinamici alle app vengono valutate in ordine sequenziale dall'alto verso il basso (vince la prima regola corrispondente).
3. Poiché la Regola 0 appare per prima nell'elenco delle istruzioni ed è una regola di esclusione (allow = 1), ha la precedenza sulla regola di autorizzazione generale (Regola 1).
4. L'app è quindi esclusa dalla gestione di https://xyz.com/foo, il che comporta il ritorno del sistema al browser o la visualizzazione di una finestra di dialogo di disambiguazione.