Przejdź do treści

Naprawa podpisu TWA

SHA-256 w assetlinks.json po Play App Signing: usuń pasek przeglądarki z TWA

Twoja Trusted Web Activity otwiera się na pełnym ekranie, gdy instalujesz ją z Android Studio, ale kopia zainstalowana z Google Play pokazuje pasek przeglądarki. Najpierw sprawdź certyfikaty: Google Play może dostarczać Twoją aplikację podpisaną swoim kluczem podpisywania aplikacji, a plik assetlinks.json na Twojej stronie może zawierać tylko certyfikat, którym podpisujesz aplikację na własnym komputerze. Dodaj właściwy SHA-256, udostępnij plik tak, jak wymaga tego Google, a potem przetestuj wersję, którą faktycznie instaluje tester.

SHA-256Certyfikat klucza podpisywania aplikacji
1 plik/.well-known/assetlinks.json
HTTP 200Bezpośrednio, bez przekierowań
Bez stałego czasuKażda warstwa ma własną pamięć podręczną

Szybka odpowiedź

Jeśli TWA działa na pełnym ekranie, gdy instalujesz własną wersję, ale pokazuje pasek przeglądarki po instalacji z Google Play, najpierw sprawdź, czy Twoja strona zawiera certyfikat, którym podpisuje Google Play. W Play Console otwórz Play app signing w sekcji Protected with Play i skopiuj SHA-256 certyfikatu klucza podpisywania aplikacji. Dodaj go do tablicy sha256_cert_fingerprints w pliku https://your-domain/.well-known/assetlinks.json, udostępnij ten plik przez HTTPS z bezpośrednią odpowiedzią HTTP 200, bez przekierowań i jako application/json, a potem przetestuj ponownie wersję zainstalowaną ze ścieżki testów w Google Play. Jeśli odcisk już się zgadza, sprawdź, czy aplikacja nie opuszcza zweryfikowanego originu, czy nie ma przekierowań i jakiej przeglądarki używa urządzenie.

Napraw w tej kolejności

Potem przetestuj wersję zainstalowaną z Google Play, a nie wersję zainstalowaną samodzielnie.

Ten poradnik dotyczy jednej naprawy: powiązania między Twoją stroną a wersją, którą dostarcza Google Play. Nie opisuje budowania samej TWA ani weryfikacji aplikacji przez Google Play, które mają własne poradniki podlinkowane niżej. Każdą cytowaną tu stronę Google sprawdziliśmy 16 października 2026 r., a źródła znajdziesz na końcu.

Dlaczego pasek przeglądarki pojawia się tylko w instalacji z Google Play

Chrome weryfikuje TWA, porównując certyfikat, którym podpisano zainstalowaną aplikację, z odciskami cyfrowymi publikowanymi przez Twoją stronę. Gdy ta kontrola się nie powiedzie, według przewodnika szybkiego startu TWA od Chrome przeglądarka wyświetla Twoją stronę jako Custom Tab. Ten tryb awaryjny to właśnie pasek adresu, który widzisz.

Przy Play App Signing zwykle istnieją dwa certyfikaty. Pakiet, który przesyłasz, podpisujesz swoim kluczem przesyłania, a Google podpisuje dostarczane pliki APK kluczem podpisywania aplikacji. Strona Chrome Android concepts for web developers podaje, że to odcisk klucza podpisywania aplikacji odpowiada Twojej aplikacji pobranej ze Sklepu Play. Plik, który zawiera tylko Twój lokalny certyfikat, przechodzi więc kontrolę na Twoim biurku i zawodzi na każdym telefonie, na którym zainstalowano aplikację z Google Play.

Te dwa klucze nie zawsze się różnią. Dokumentacja podpisywania aplikacji Androida opisuje konfiguracje, w których ten sam klucz pełni rolę klucza podpisywania aplikacji i klucza przesyłania. Rozwiązaniem jest więc porównanie prawdziwych certyfikatów, a nie zgadywanie, który masz.

Który certyfikat podpisał testowaną przez Ciebie wersję
Skąd pochodzi wersja Podpisana kluczem Czego potrzebuje assetlinks.json
Zainstalowana ze ścieżki testów lub z wersji produkcyjnej w Google Play Podpisana kluczemKlucz podpisywania aplikacji Google Play Czego potrzebuje assetlinks.jsonSHA-256 certyfikatu klucza podpisywania aplikacji. To on naprawia instalację z Google Play.
Twój własny plik APK wersji release, zainstalowany ręcznie Podpisana kluczemTwój klucz przesyłania lub klucz wersji release Czego potrzebuje assetlinks.jsonSHA-256 tego klucza, tylko jeśli chcesz, aby te wersje też przechodziły weryfikację
Uruchomienie debug z Android Studio Podpisana kluczemTwój lokalny klucz debug Czego potrzebuje assetlinks.jsonSHA-256 klucza debug, tylko jeśli chcesz, aby wersje debug przechodziły weryfikację. Inny identyfikator aplikacji wymaga osobnego wpisu (statement).
Link do wewnętrznego udostępniania aplikacji Podpisana kluczemOsobny klucz wewnętrznego udostępniania aplikacji Czego potrzebuje assetlinks.jsonGoogle ponownie podpisuje takie przesłane pliki kluczem Internal App Sharing, więc poprawkę testuj zamiast tego na ścieżce testów
Wersja wydana po zmianie klucza podpisywania na nowszy Podpisana kluczemCertyfikat, którego Google Play używa teraz dla tej wersji Czego potrzebuje assetlinks.jsonKażdy certyfikat dla wersji, które nadal obsługujesz. Nie usuwaj starszego tylko dlatego, że pojawił się nowszy.

Testerzy w teście zamkniętym też to widzą

Testerzy w teście zamkniętym instalują wersję podpisaną przez Google Play, dlatego to często pierwsze miejsce, w którym pojawia się pasek. To nie jest wada testów zamkniętych: zmienną jest certyfikat zainstalowanego pliku APK. Jeśli testujesz wyłącznie plik APK zainstalowany ręcznie, możesz całkowicie przeoczyć problem.

Znajdź SHA-256 klucza podpisywania aplikacji w Play Console

Dokumentacja Google podaje obecnie dwie nazwy tego samego miejsca. Obie zaczynają się od Protected with Play w lewym menu Twojej aplikacji.

Dwie udokumentowane ścieżki do tego samego certyfikatu (sprawdzono 16 października 2026 r.)
Strona Google Ścieżka w menu Skąd skopiować
Pomoc Play Console: Use Play App Signing Ścieżka w menuProtected with Play > Play Store distribution > Go to Play app signing Skąd skopiowaćSekcja App signing key
Dokumentacja Android App Links Ścieżka w menuProtected with Play > Play Store protection > Manage Play app signing Skąd skopiowaćApp signing key certificate > SHA-256 certificate fingerprint

Starsze poradniki, w tym niektóre strony Google, nadal podają Release > Setup > App signing lub Setup > App integrity. Jeśli widzisz tylko te nazwy, szukasz tej samej strony pod starszą nazwą.

1

Otwórz aplikację w Play Console

Wybierz aplikację, której nazwy pakietu używa Twoja TWA. Każda aplikacja ma własny klucz podpisywania aplikacji.

2

Przejdź do Play app signing

Użyj dowolnej ścieżki z tabeli powyżej. Obie prowadzą do strony z kluczem podpisywania aplikacji i kluczem przesyłania.

3

Skopiuj SHA-256 klucza podpisywania aplikacji

Skopiuj odcisk cyfrowy certyfikatu SHA-256 z sekcji klucza podpisywania aplikacji, a nie z sekcji klucza przesyłania i nie z wiersza SHA-1. To 32 pary znaków szesnastkowych rozdzielone dwukropkami. Wklej go w całości; skrócony przykład z wpisu na blogu nie przejdzie weryfikacji.

4

Zachowaj każdy certyfikat podpisywania aplikacji, który ma zastosowanie

Aktualna strona Pomocy Google opisuje hybrydowe podpisywanie gotowe na erę kwantową, w którym kopiujesz odciski trzech kluczy: nowych kluczy klasycznego i postkwantowego, używanych na nowszych urządzeniach, oraz klucza klasycznego używanego na starszych urządzeniach. Jeśli Twoja strona pokazuje więcej niż jeden certyfikat podpisywania aplikacji, wpisz każdy, który mogą otrzymać obsługiwane przez Ciebie urządzenia. Dotyczy to tylko aplikacji korzystających z tej konfiguracji; większość aplikacji ma jeden certyfikat podpisywania aplikacji.

Odczytaj odcisk klucza, który masz u siebie

Dla klucza przesyłania lub klucza debug narzędzie keytool z Javy wypisuje odcisk w tym samym formacie. Zastąp plik magazynu kluczy i alias własnymi, a potem skopiuj wiersz oznaczony SHA256:

Terminal
keytool -list -v -keystore my-upload-key.jks -alias upload

Jeśli zarządzasz wieloma aplikacjami, Google Play Developer API też może zwrócić skrót certyfikatu plików APK wygenerowanych przez Google Play (pole certificateSha256Hash na liście wygenerowanych plików APK). Przy pojedynczej poprawce prościej jest skopiować go z Play Console.

Przygotuj i udostępnij poprawny plik assetlinks.json

Plik to tablica JSON z wpisami (statements). Dla TWA relacja to delegate_permission/common.handle_all_urls, a celem jest Twoja aplikacja na Androida: przestrzeń nazw android_app, Twój dokładny identyfikator aplikacji i tablica odcisków SHA-256. Minimalny plik wygląda tak:

assetlinks.json
[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.twa",
      "sha256_cert_fingerprints": [
        "PLAY_APP_SIGNING_KEY_SHA256",
        "UPLOAD_KEY_SHA256"
      ]
    }
  }
]

Zastąp com.example.twa swoim identyfikatorem aplikacji, a każdy symbol zastępczy pełnym SHA-256 rozdzielonym dwukropkami. Usuń drugi wpis, jeśli potrzebujesz weryfikacji tylko dla instalacji z Google Play. Wyłącznie ścisły JSON: bez komentarzy, bez przecinków na końcu i bez wartości SHA-1.

Jak według Google trzeba udostępniać plik

  • Dokładna lokalizacja. https://your-domain/.well-known/assetlinks.json, z kropką w .well-known. example.com i www.example.com to różne originy; opublikuj plik na każdym, który otwiera Twoja aplikacja. Kopia w podkatalogu, na przykład /app/.well-known/, się nie liczy.
  • Bezpośrednia odpowiedź HTTP 200. Dokumentacja Digital Asset Links od Google mówi: „Każda odpowiedź serwera inna niż HTTP 200 jest traktowana jako błąd i skutkuje pustą listą wpisów.”
  • Bez przekierowań. Odpowiedzi 301 i 302 nie są śledzone. Dotyczy to także przejścia z http na https oraz z domeny bez www na www.
  • HTTPS z prawidłowym łańcuchem certyfikatów oraz nagłówek Content-Type: application/json. Strona logowania albo strona błędu HTML, która odpowiada kodem 200, nie jest prawidłowym plikiem.

Sprawdź aktualną odpowiedź z dowolnego terminala. Pierwszy wiersz statusu musi zawierać 200, typ treści musi być JSON, a przed nim nie może być żadnego 3xx:

Terminal
curl -sI https://example.com/.well-known/assetlinks.json

Więcej niż jeden odcisk, więcej niż jedna aplikacja

Przewodnik po powiązaniach ze stronami Androida mówi o tablicy odcisków: „To pole obsługuje wiele odcisków cyfrowych, których można użyć do obsługi różnych wersji aplikacji, na przykład wersji debug i produkcyjnej.” Dodawaj odcisk klucza przesyłania lub debug tylko dla wersji, którym ta strona ma naprawdę ufać. Wersja z innym identyfikatorem aplikacji, na przykład osobny pakiet debug, potrzebuje w tablicy własnego wpisu.

Jeśli TWA powstała w Bubblewrap lub PWABuilder

W istniejącym projekcie Bubblewrap dodaj odcisk z Google Play i wygeneruj plik ponownie:

Terminal
bubblewrap fingerprint add "PLAY_APP_SIGNING_KEY_SHA256" --name="Play app signing"
bubblewrap fingerprint list
bubblewrap fingerprint generateAssetLinks

Wygenerowanie pliku to jeszcze nie wdrożenie: prześlij nowy assetlinks.json na swoją stronę i sprawdź go przez curl. bubblewrap validate sprawdza Twoją PWA pod kątem kryteriów jakości; nie sprawdza powiązania podpisu, więc pozytywny wynik nic nie mówi o odcisku. Aktualne instrukcje PWABuilder mówią to samo o podpisywaniu: „Po przesłaniu pliku .aab Google Play ponownie podpisuje Twoją aplikację”, i każą dodać odcisk z Google Play do wygenerowanego pliku. Poprawka odcisku to zmiana na Twojej stronie, a nie w pliku binarnym aplikacji.

Zweryfikuj powiązanie, potem przetestuj instalację z Google Play

W grę wchodzą cztery warstwy: plik na Twojej stronie, Digital Asset Links API od Google, weryfikacja linków w samym Androidzie i przeglądarka, która uruchamia Twoją TWA. Przejście jednej warstwy nie dowodzi przejścia następnej, więc sprawdzaj je po kolei i zakończ na urządzeniu.

1

Plik na stronie

Uruchom powyższe sprawdzenie przez curl. Usuń każde przekierowanie, zły typ treści lub status inny niż 200, zanim zaczniesz szukać gdzie indziej.

2

Statement List Generator and Tester od Google

Narzędzie Statement List Generator and Tester od Google przyjmuje Twoją domenę, nazwę pakietu i SHA-256 i sprawdza, czy wpis istnieje. To najszybsza wizualna kontrola.

3

Dokładne sprawdzenie przez API

Metoda assetlinks.check odpowiada na jedno precyzyjne pytanie: czy ten pakiet z tym certyfikatem jest powiązany z tą stroną? Zastąp origin, pakiet, odcisk i klucz, zakoduj wartości do URL i szukaj "linked": true:

Adres żądania
https://digitalassetlinks.googleapis.com/v1/assetlinks:check?source.web.site=https%3A%2F%2Fexample.com&relation=delegate_permission%2Fcommon.handle_all_urls&target.android_app.package_name=com.example.twa&target.android_app.certificate.sha256_fingerprint=URL_ENCODED_SHA256&key=YOUR_API_KEY

Źródłem jest origin, a nie adres URL pliku. Metoda statements.list tylko wypisuje to, co publikuje strona, więc niepusta lista nie dowodzi, że są na niej Twój pakiet i certyfikat. Przewodnik Google wymaga klucza API; błąd autoryzacji lub limitu to problem z dostępem do API, a nie nieudane powiązanie.

Aby zobaczyć wszystko, co publikuje strona, żądanie listy przyjmuje tylko origin i relację. Przejrzyj zwrócone cele i szukaj swojego dokładnego pakietu i certyfikatu:

Adres żądania
https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https%3A%2F%2Fexample.com&relation=delegate_permission%2Fcommon.handle_all_urls
4

Aplikacja, którą instaluje tester

Zainstaluj aplikację ze swojej ścieżki testów w Google Play, a nie z ręcznie wgranego pliku APK ani z linku do wewnętrznego udostępniania aplikacji, a potem ją otwórz. Jeśli pasek nadal jest widoczny, odczytaj log weryfikacji Chrome przez adb. Dokumentacja Chrome mówi, że jeśli widzisz Statement failure matching fingerprint., podpis aplikacji nie zgadza się z Twoim assetlinks.json:

Terminal
adb logcat -v brief | grep -e OriginVerifier -e digital_asset_links

App Links Assistant w Android Studio (Tools > App Links Assistant) sprawdza powiązanie Android App Links i Twój manifest. Przydaje się do tego, ale nie powie Ci, czy Twoja TWA otwiera się na pełnym ekranie; to pokaże tylko test na urządzeniu.

Zaawansowane: stan weryfikacji w samym Androidzie

Na Androidzie 12 i nowszym przewodnik po weryfikacji Androida dokumentuje te polecenia dla App Links. Zastąp nazwę pakietu, uruchom dwa pierwsze polecenia, odczekaj kilka minut, a potem odczytaj stan:

Terminal
adb shell pm set-app-links --package YOUR_PACKAGE 0 all
adb shell pm verify-app-links --re-verify YOUR_PACKAGE
adb shell pm get-app-links YOUR_PACKAGE

verified opisuje weryfikację domeny w Androidzie, a nie to, czy Twoja TWA otwiera się bez interfejsu przeglądarki. Kody 1024 i wyższe to błędy specyficzne dla weryfikatora, a nie diagnoza błędnego SHA-256. Dla samej TWA korzystaj z logu Chrome opisanego wyżej.

Odcisk się zgadza, ale pasek zostaje

Widoczny pasek nie dowodzi, że SHA-256 jest błędny. Gdy powyższe sprawdzenie zwraca linked: true, a pasek nadal jest widoczny, przejdź po kolei przez te przyczyny.

Inne przyczyny paska przeglądarki w zweryfikowanej TWA
Co widzisz Prawdopodobna przyczyna Co zrobić
Pasek pojawia się po kliknięciu linku, logowaniu lub przekierowaniu Prawdopodobna przyczynaOpuszczono zweryfikowany origin Co zrobićPrzewodnik Chrome o wielu originach mówi: „Gdy użytkownik opuści zweryfikowany origin, wyświetlany jest interfejs Custom Tab.” Zadeklaruj w aplikacji każdy origin, który kontrolujesz, i opublikuj assetlinks.json na każdym z nich. Strona logowania w domenie innej firmy, na przykład dostawcy tożsamości, jest poza Twoim powiązaniem: nie możesz opublikować tam pliku, więc interfejs przeglądarki jest w tym miejscu spodziewany.
Pasek widać od pierwszego ekranu, a Twoja domena przekierowuje Prawdopodobna przyczynaStartowy URL i zadeklarowany origin to różne hosty Co zrobićUstaw ten sam host dla adresu startowego, zadeklarowanego originu i pliku, na przykład wszędzie www. Jeden zgłoszony przypadek z Bubblewrap, w którym odcisk się zgadzał, rozwiązano dokładnie w ten sposób.
Pełny ekran w Chrome, pasek przy innej domyślnej przeglądarce Prawdopodobna przyczynaWybór dostawcy przeglądarki Co zrobićWedług przewodnika szybkiego startu Chrome używana jest domyślna przeglądarka, jeśli obsługuje TWA, w przeciwnym razie inna zainstalowana przeglądarka, która je obsługuje, a w ostateczności Custom Tab. Uruchom adb logcat -v brief | grep -e TWAProviderPicker, aby zobaczyć, którą przeglądarkę wybrano.
Świeża instalacja przy słabej sieci lub bez sieci Prawdopodobna przyczynaWeryfikacja nie mogła się wykonać Co zrobićPołącz się ponownie z siecią i otwórz aplikację jeszcze raz. To wzorzec zgłaszany przez społeczność, a nie udokumentowane zachowanie.
Android zgłasza verified, ale TWA pokazuje interfejs przeglądarki Prawdopodobna przyczynaKontrola Androida i kontrola przeglądarki to dwie osobne rzeczy Co zrobićPrzechwyć komunikat przeglądarki o weryfikacji originu za pomocą powyższego polecenia logcat; wyjaśnia on wynik TWA, a nie stan w Androidzie.
Krótki komunikat, że aplikacja działa w Twojej przeglądarce, a potem pełny ekran Prawdopodobna przyczynaMożliwe, że to powiadomienie przeglądarki, a nie stały pasek Co zrobićZapisz dokładną treść komunikatu i czas jego wyświetlania, zanim uznasz go za nieudane powiązanie. Ten objaw zgłasza społeczność i nie jest on udokumentowany przez Google.

Po jakim czasie poprawiony plik zaczyna działać

Google nie podaje jednego czasu oczekiwania dla TWA, ponieważ w grę wchodzi kilka pamięci podręcznych, a każda ma własne zasady:

  • Twój serwer lub CDN może nadal serwować stary plik. Wyczyść pamięć podręczną i potwierdź aktualną odpowiedź przez curl.
  • Digital Asset Links API podaje w polu maxAge, jak długo każda odpowiedź pozostaje ważna.
  • Android App Links ma osobne terminy. Przewodnik po weryfikacji Androida mówi, że na Androidzie 15 i nowszym zmiany mogą potrzebować do siedmiu dni, aby dotrzeć do wszystkich urządzeń, a na Androidzie 14 i starszym plik jest zwykle pobierany przy instalacji lub aktualizacji aplikacji.
  • Przeglądarka może przechowywać własny stan. Jeden deweloper zgłosił, że pomogło mu wyczyszczenie danych Chrome.

Wyczyść więc pamięć podręczną, potwierdź aktualny plik i zainstaluj aplikację ponownie z Google Play. Na urządzeniu testowym świeża instalacja lub wyczyszczenie danych przeglądarki pozwala wykluczyć zapisany stan; to krok diagnostyczny, a nie coś, o co należy prosić każdego użytkownika. Nie planuj w oparciu o stałą liczbę godzin.

Odrzucenie, weryfikacja i testy zamknięte

Brakujący lub błędny assetlinks.json nie jest udokumentowany jako samodzielna przyczyna odrzucenia. Dokumentacja opisuje natomiast przejście na Custom Tab z interfejsem przeglądarki. Weryfikacja to osobna kwestia: zasady dotyczące funkcjonalności Google Play mówią: „Nie zezwalamy na aplikacje, które ulegają awarii, wymuszają zamknięcie, zawieszają się lub w inny sposób działają nieprawidłowo”, i dotyczy to aplikacji niezależnie od stanu powiązania. Poprawny odcisk usuwa pasek; nie rozstrzyga weryfikacji. Jeśli otrzymałeś odrzucenie, zacznij od zasady wskazanej w e-mailu.

Niektóre starsze artykuły twierdzą, że Chrome zamknie awaryjnie TWA, która nie przejdzie kontroli jakości. Chromium usunął kod QualityEnforcer 4 maja 2023 r., więc traktuj tę radę jako historyczną, a nie jako opis dzisiejszych przeglądarek.

Jeśli otrzymałeś odrzucenie, pracuj na podstawie powodu podanego w powiadomieniu: odrzucenie za Broken Functionality omawia krok po kroku najczęstsze powiadomienie dotyczące funkcjonalności. Nie przebudowuj TWA na WebView tylko z powodu paska przeglądarki. Jeśli Twoja aplikacja powstała w kreatorze AI, poradnik publikowanie aplikacji z vibe codingu w Google Play opisuje całą drogę od projektu do Google Play.

Testowanie TWA na nowym osobistym koncie

Osobiste konta dewelopera utworzone po 13 listopada 2023 r. nadal muszą przeprowadzić test zamknięty z udziałem co najmniej 12 testerów, którzy nieprzerwanie uczestniczą w nim przez 14 dni, zanim poproszą o opublikowanie wersji produkcyjnej. Ci testerzy instalują wersję podpisaną przez Google Play, czyli dokładnie tam, gdzie ten błąd się ujawnia. PrimeTestLab zapewnia 12+ prawdziwych testerów od $19.99 (plus 5% opłaty serwisowej), a jeśli po pełnym teście Google nie przyzna dostępu do wersji produkcyjnej, wybierasz bezpłatny ponowny test lub pełny zwrot pieniędzy. Zobacz, jak działa usługa 12 testerów.

Najczęściej zadawane pytania

Który SHA-256 wpisać do assetlinks.json, gdy używam Play App Signing?

SHA-256 certyfikatu klucza podpisywania aplikacji widoczny na stronie Play app signing w Play Console. Ten certyfikat podpisuje wersje, które ludzie instalują z Google Play. Odcisk klucza przesyłania lub debug dodaj dodatkowo tylko wtedy, gdy chcesz, aby weryfikację przechodziły też wersje instalowane przez Ciebie.

Dlaczego moja TWA działa z Android Studio, a z Google Play pokazuje pasek adresu?

Wersje, które instalujesz sam, są podpisane Twoim kluczem debug lub kluczem przesyłania, a Google Play dostarcza aplikację podpisaną kluczem podpisywania aplikacji. Jeśli Twoja strona zawiera tylko lokalny certyfikat, weryfikacja instalacji z Google Play się nie udaje i Chrome przechodzi na Custom Tab z paskiem przeglądarki.

Gdzie jest klucz podpisywania aplikacji w obecnej wersji Play Console?

W sekcji Protected with Play. Google dokumentuje obecnie dwie ścieżki: Play Store distribution, a potem Go to Play app signing, oraz Play Store protection, a potem Manage Play app signing. Skopiuj SHA-256 certificate fingerprint z sekcji certyfikatu klucza podpisywania aplikacji.

Czy assetlinks.json może zawierać więcej niż jeden odcisk SHA-256?

Tak. Pole sha256_cert_fingerprints jest tablicą i obsługuje wiele odcisków dla tego samego pakietu, na przykład dla wersji debug i wersji podpisanej przez Google Play. Inny identyfikator aplikacji wymaga osobnego wpisu.

Po jakim czasie od poprawienia assetlinks.json znika pasek przeglądarki?

Google nie podaje jednego czasu oczekiwania dla TWA. Wyczyść pamięć podręczną CDN, potwierdź, że aktualny plik zwraca HTTP 200 jako JSON bez przekierowań, i zainstaluj aplikację ponownie z Google Play; na urządzeniu testowym wyczyszczenie danych przeglądarki pozwala wykluczyć zapisany stan. Weryfikacja Android App Links ma własne terminy i na Androidzie 15 i nowszym może potrwać do siedmiu dni.

Czy błędny assetlinks.json powoduje odrzucenie TWA w Google Play?

Obecna dokumentacja opisuje przejście na Custom Tab z interfejsem przeglądarki, a nie automatyczne odrzucenie. Weryfikacja w Google Play ocenia, czy aplikacja działa i daje prawdziwe doświadczenie, więc poprawny plik usuwa pasek, ale sam w sobie nie rozstrzyga weryfikacji.

Czy testerzy w teście zamkniętym też widzą pasek przeglądarki?

Tak, jeśli na stronie brakuje certyfikatu klucza podpisywania aplikacji, ponieważ testerzy w teście zamkniętym instalują wersję podpisaną przez Google Play. Testuj poprawkę na takiej instalacji, a nie na ręcznie wgranym pliku APK, i pamiętaj, że linki do wewnętrznego udostępniania aplikacji są podpisane innym kluczem.

Sprawdzenie Digital Asset Links przechodzi. Dlaczego pasek nadal jest widoczny?

Sprawdź, co dokładnie przeszło. Lista wpisów może zawierać powiązanie dla innego pakietu lub certyfikatu, a nawet dokładne sprawdzenie testuje tylko podane przez Ciebie wartości. Potwierdź, że zainstalowana wersja ma tę tożsamość, prześledź origin, na którym aplikacja faktycznie się otwiera, i odczytaj log weryfikacji przeglądarki. Stan App Links w Androidzie to osobny sygnał.

Czy przekierowanie na www albo strona logowania mogą przywrócić pasek?

Tak. Weryfikacja TWA dotyczy originów, a opuszczenie zweryfikowanego originu wyświetla interfejs przeglądarki. Sprawdź, gdzie aplikacja trafia po przekierowaniach, i skonfiguruj każdy kontrolowany przez Ciebie origin zarówno w aplikacji, jak i w jego własnym pliku assetlinks.json. Strona logowania w domenie innej firmy nie jest objęta Twoim plikiem i nie możesz opublikować jej powiązania.

Czy bubblewrap validate sprawdza mój odcisk podpisu z Google Play?

Nie. Bubblewrap opisuje validate jako sprawdzenie Twojej PWA pod kątem kryteriów jakości, więc pozytywny wynik nic nie mówi o tym, czy aplikacja zainstalowana z Google Play pasuje do Twojej listy certyfikatów. Użyj poleceń fingerprint, aby przygotować assetlinks.json, opublikuj plik, sprawdź dokładną domenę, pakiet i certyfikat, a potem przetestuj instalację z Google Play.

Czy muszę przenieść TWA na WebView, aby usunąć pasek?

Nie jako pierwszy krok. Popraw tożsamość podpisu zainstalowanej aplikacji, sposób udostępniania pliku przez stronę i originy, które otwiera aplikacja, a potem przetestuj ponownie. Jeśli prawdziwym problemem jest nieobsługiwane zachowanie przeglądarki, uwierzytelnianie lub konkretne powiadomienie o naruszeniu zasad, zbadaj to osobno, zanim zdecydujesz, czy Twojej aplikacji lepiej posłuży inny rodzaj opakowania.

Podsumowanie

Podsumowanie

Pasek przeglądarki w TWA zainstalowanej z Google Play zaczyna się od jednego porównania: certyfikatu, którym podpisano zainstalowaną wersję, z odciskami w pliku assetlinks.json na Twojej stronie. Skopiuj SHA-256 klucza podpisywania aplikacji z Play app signing, opublikuj ścisły JSON w dokładnym originie z bezpośrednią odpowiedzią HTTP 200, sprawdź dokładny pakiet i certyfikat, a potem przetestuj wersję, którą zainstalowałby tester. Jeśli odcisk już się zgadza, sprawdź originy, przekierowania, przeglądarkę i pamięci podręczne, zanim cokolwiek przebudujesz.

Nazwy menu Play Console to najszybciej zmieniający się fakt na tej stronie. Jeśli powyższe ścieżki nie pasują już do Twojej Konsoli, szukaj Play app signing w sekcji Protected with Play albo wyszukaj w Konsoli frazę app signing.

Kefayatullah Khadem - Software Engineer & Google Play Publishing Specialist

Autor

Kefayatullah Khadem

Software Engineer & Google Play Publishing Specialist

Kefayatullah Khadem jest inżynierem oprogramowania z ponad 8-letnim doświadczeniem w budowaniu skalowalnych aplikacji. W PrimeTestLab pomaga niezależnym deweloperom spełnić wymaganie testów zamkniętych Google Play, po tym jak zobaczył, jak wielu z nich się z tym zmaga. Do tej pory pomógł 12 100+ aplikacjom na Androida ukończyć zarządzane testy zamknięte w 120+ krajach, przy wskaźniku ukończenia zarządzanych testów wynoszącym 99,9%. Kiedy nie pomaga deweloperom w publikacji, pisze o zasadach Google Play, schematach odrzucania aplikacji i procesie testów zamkniętych.

12 100+ Przetestowane aplikacje
99,9% Wskaźnik ukończenia testów
120+ Kraje
4,9/5 Ocena

Testy zamknięte dla TWA

Odcisk poprawiony. Teraz przeprowadź 14-dniowy test.

12+ prawdziwych testerów instaluje Twoją wersję podpisaną przez Google Play na prawdziwych telefonach z Androidem i uczestniczy w teście nieprzerwanie przez pełne 14 dni.

Od $19.99 · plus 5% opłaty serwisowej

Testy startują w ciągu 4-6 godzin · 120+ krajów · Bezpłatny ponowny test lub pełny zwrot pieniędzy

Zdobądź 12 testerów od $19.99 WhatsApp