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:
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.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 plikubuild.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 sekcjiRelease > 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:
[{ "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
):
[{ "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-typeapplication/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:
- System sprawdza wszystkie filtry intencji, które zawierają dowolny z tych elementów:
- Działanie:
android.intent.action.VIEW
- Kategorie:
android.intent.category.BROWSABLE
iandroid.intent.category.DEFAULT
- Schemat danych:
http
lubhttps
- Działanie:
- 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:
- interfejs API
DomainVerificationManager
(w czasie działania), - Program wiersza poleceń (podczas testowania).
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.
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ścihttp
lubhttps
- 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
Sprawdź zasady dotyczące linków
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 stanalways
. 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 coexample.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
dohttps://example.com
- Od
example.com
dowww.example.com
To działanie zapewnia bezpieczeństwo aplikacji.
- Od
- 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ą.
- Podpisać aplikację certyfikatem debugowania i mieć tylko podpis wersji w