Aplikacja TWA odrzucona w Google Play? Przejdź na WebView

To jedno z najbardziej frustrujących odrzuceń dla niezależnego dewelopera. Testerzy naprawdę korzystają z aplikacji, wymagane 12 osób uczestniczy w teście, mija 14 dni, a Google odpowiada: "your testers were not engaged enough." W przypadku aplikacji zbudowanej jako Trusted Web Activity (TWA) lub opakowanie PWA ten schemat jest realny. Wśród 7 400+ aplikacji objętych naszą pomocą kompilacje opakowujące treść internetową otrzymują ten komunikat znacznie częściej niż standardowe kompilacje natywne lub WebView. Ten poradnik wyjaśnia przyczynę, pokazuje istotną różnicę architektury i opisuje przejście na WebView bez utraty dni już zaliczonych w teście.

Dlaczego aplikacje TWA bywają odrzucane w teście zamkniętym?

Trusted Web Activity wyświetla witrynę przez Chrome Custom Tabs, zamiast renderować ekrany wewnątrz Twojej aplikacji. To szybki sposób na zmianę witryny lub PWA w instalowalną aplikację i w wielu opublikowanych aplikacjach działa prawidłowo. Problem pojawia się wtedy, gdy osobiste konto dewelopera musi spełnić obowiązkowe wymaganie 14-dniowego testu zamkniętego przed uzyskaniem dostępu do wersji produkcyjnej.

Z naszego doświadczenia z 7 400+ aplikacji wynika, że kompilacje TWA i opakowania PWA znacznie częściej otrzymują odrzucenie "testers were not engaged" niż standardowe aplikacje natywne, nawet gdy testerzy rzeczywiście korzystają z nich codziennie. Ten schemat jest na tyle wyraźny, że zalecamy odejście od TWA, jeśli aplikacja musi jeszcze przejść 14-dniowy test zamknięty.

Czym naprawdę jest TWA i jak powstaje

Przed naprawą przyczyny odrzucenia warto dokładnie zrozumieć opublikowaną architekturę. Trusted Web Activity to aplikacja na Androida, która w istocie jest Twoją witryną działającą na pełnym ekranie w prawdziwym silniku przeglądarki. Nie ma paska adresu ani interfejsu sugerującego, że użytkownik ogląda stronę internetową. Wygląda i zachowuje się jak aplikacja natywna, lecz pod spodem działa Twoja witryna.

TWA zwykle powstaje za pomocą Google Bubblewrap CLI albo PWABuilder. Oba narzędzia korzystają z biblioteki Google androidbrowserhelper. Podajesz adres URL, narzędzie generuje projekt Android, a następnie podpisujesz go i przesyłasz AAB do Google Play.

Dlaczego deweloperzy wybierają TWA

Kompromis, który prowadzi do odrzucenia

To, co sprawia, że TWA jest tania, zwiększa ryzyko podczas testu zamkniętego:

• Wymaga internetu. Jest oknem na Twoją witrynę, więc słabe połączenie oznacza słabe działanie aplikacji, chyba że PWA zapewnia solidną obsługę offline.
• Ryzyko odrzucenia w Play Store. Zasady dotyczące minimalnej funkcjonalności i przepakowanych treści obejmują aplikacje będące tylko witryną w opakowaniu. TWA bez rzeczywistych funkcji natywnych może zostać odrzucona lub usunięta, zwłaszcza przy nowym zgłoszeniu. Dodaj funkcje natywne, takie jak push notifications, tryb offline, aparat lub share targets, aby aplikacja oferowała samodzielną wartość.
• Problem z sygnałami zaangażowania opisany wyżej. To dlatego konta osobiste objęte 14-dniowym testem zamkniętym nadal otrzymują komunikat "testers not engaged".

Nieporozumienie: TWA NIE jest WebView

W tej kwestii wiele artykułów wprowadza zamieszanie, a precyzja ma znaczenie dla sposobu naprawy. TWA w ogóle nie korzysta z komponentu Android WebView.

Ponieważ TWA korzysta z silnika Custom Tabs, otrzymujesz ten sam silnik renderowania, JavaScript i piaskownicę zabezpieczeń co Chrome, a także wspólne pliki cookie i pamięć. Użytkownik zalogowany w witrynie pozostaje zalogowany, przeglądarka aktualizuje się automatycznie, a aplikacja obsługuje pełną platformę internetową. To duża zaleta zwykłej opublikowanej aplikacji, lecz ekrany działają wtedy poza procesem aplikacji, wewnątrz Chrome. Stąd bierze się zarówno osłabienie sygnałów zaangażowania, jak i niska liczba aktywnych użytkowników.

Uruchamianie krok po kroku

Weryfikacja zaufania: Digital Asset Links

Chrome usuwa pasek adresu tylko wtedy, gdy aplikacja potwierdzi powiązanie z witryną za pomocą Digital Asset Links. Aplikacja deklaruje reprezentowaną witrynę, a witryna musi udostępniać plik /.well-known/assetlinks.json zawierający package aplikacji i odcisk certyfikatu podpisującego SHA-256.

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourapp.name",
    "sha256_cert_fingerprints": [
      "AB:CD:EF:...:99"  // your signing cert SHA-256
    ]
  }
}]

Droga sygnałów zaangażowania: TWA a WebView

Najprościej zrozumieć odrzucenie, śledząc miejsce, do którego trafia aktywność testera. W TWA ekrany działają o jedną warstwę dalej od aplikacji, w Chrome Custom Tabs. W aplikacji WebView te same ekrany działają w procesie Twojej aplikacji i są bezpośrednio przypisywane do Twojego package. Ta różnica wpływa na siłę rejestrowanej aktywności.

Jak rozpoznać TWA z zewnątrz i od środka

Nie masz pewności, czy opublikowana aplikacja, także przygotowana przez wykonawcę, rzeczywiście jest TWA? Najpierw sprawdź ją wzrokowo, a potem potwierdź wynik w APK lub na podłączonym urządzeniu.

Szybkie oznaki widoczne dla użytkownika

• Zachowuje się dokładnie jak witryna, ponieważ nią jest.
• Przy błędnej konfiguracji u góry widać pasek adresu przeglądarki. To jednoznaczna oznaka opisanego wyżej błędu assetlinks.
• Treść aktualizuje się bez aktualizacji aplikacji w Play Store.

Jednoznaczne oznaki techniczne w APK lub urządzeniu

Potwierdź za pomocą adb

Na podłączonym urządzeniu lub emulatorze wystarczą dwa polecenia:

# Is it a TWA? Look for the delegation service:
adb shell dumpsys package <package.name> | grep -i DelegationService

# Which site does it wrap, and is the trust check passing?
adb shell pm get-app-links <package.name>
#   -> "verified"  = Digital Asset Links pass (fullscreen)
#   -> "1024"      = verification failed (address bar shows)

TWA a WebView w teście zamkniętym: porównanie

Obie architektury opakowują treść internetową. Dla przejścia 14-dniowego testu zamkniętego liczy się miejsce działania treści i sposób przypisywania aktywności. Poniższe kryteria wpływają na możliwość uzyskania dostępu do wersji produkcyjnej w jednym cyklu.

Rozwiązanie: zbuduj standardową aplikację WebView

Zamiast poprawiać TWA lub próbować wymuszać lepsze sygnały, przebuduj aplikację wokół komponentu WebView i opublikuj tę kompilację. Dostępne są trzy popularne drogi. Każda ładuje witrynę wewnątrz Twojej aplikacji:

Minimalna konfiguracja WebView gotowa do skopiowania

Podstawa jest niewielka: WebView ładuje adres URL z włączonym JavaScript i storage, utrzymuje nawigację wewnątrz aplikacji zamiast przechodzić do Chrome oraz obsługuje przycisk Wstecz w sposób oczekiwany podczas weryfikacji Google. Wybierz język i skopiuj bazę:

val webView = findViewById<WebView>(R.id.webview)
webView.settings.apply {
    javaScriptEnabled = true          // most sites need this
    domStorageEnabled = true          // localStorage / sessionStorage
    cacheMode = WebSettings.LOAD_DEFAULT
}

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.webViewClient = WebViewClient()
webView.loadUrl("https://yourwebsite.com")

// The exact back-button handler Google looks for
onBackPressedDispatcher.addCallback(this, object : OnBackPressedCallback(true) {
    override fun handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack()
        } else {
            finish()
        }
    }
})

WebView webView = findViewById(R.id.webview);
WebSettings settings = webView.getSettings();
settings.setJavaScriptEnabled(true);      // most sites need this
settings.setDomStorageEnabled(true);      // localStorage / sessionStorage
settings.setCacheMode(WebSettings.LOAD_DEFAULT);

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.setWebViewClient(new WebViewClient());
webView.loadUrl("https://yourwebsite.com");

// The exact back-button handler Google looks for
getOnBackPressedDispatcher().addCallback(this, new OnBackPressedCallback(true) {
    @Override
    public void handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack();
        } else {
            finish();
        }
    }
});

# Wrap an existing web/PWA project in a native WebView shell
npm install @capacitor/core @capacitor/cli
npx cap init "YourApp" "com.yourapp.name"

# Point Capacitor at your live site (capacitor.config.ts)
#   server: { url: "https://yourwebsite.com", cleartext: false }

npm install @capacitor/android
npx cap add android
npx cap sync

# Capacitor handles back-button + DOM storage natively.
# Open in Android Studio to build a signed AAB:
npx cap open android

Trzy elementy potrzebne do przejścia weryfikacji

Prosty WebView wywołujący wyłącznie loadUrl() nadal jest thin wrapper. Poniższe trzy elementy zmieniają go w pełnoprawną aplikację i chronią testerów przed pustymi ekranami:

Jak przejść na WebView bez resetowania licznika 14 dni

Jeśli test już trwa, nie musisz zaczynać od nowa. Aktualizacja aplikacji nie resetuje licznika 14 dni, o ile pozostajesz na tej samej ścieżce testów i zachowujesz ten sam package name. Bezpieczna migracja wygląda tak:

Czy aplikacja WebView nadal jest uznawana za thin wrapper?

To pułapka dla deweloperów, którzy uznają WebView za automatyczne rozwiązanie. Przejście z TWA na WebView usuwa problem sygnałów zaangażowania, ale nie zwalnia z zasad Google dotyczących spamu i minimalnej funkcjonalności. WebView wyświetlający tylko stronę główną w ramce nadal może zostać odrzucony jako thin wrapper, czyli cienkie opakowanie witryny bez rzeczywistej wartości natywnej, podobnie jak prosta TWA.

Potraktuj to jako dwie osobne bramki. Usługa testowa lub przebudowa do WebView może pomóc przejść jedną z nich, ale nie zastąpi drugiej.

Celem nie jest więc sam WebView zamiast TWA, lecz aplikacja WebView z wystarczającą rzeczywistą wartością i natywnym zachowaniem. W praktyce oznacza to:

Potrzebujesz dokładniejszej listy przyczyn odrzucenia jakościowego? Nasz poradnik o przyczynach odrzucenia testu zamkniętego opisuje najczęstsze problemy z zasadami i weryfikacją, niezależne od zaangażowania.

Nie wiesz, czy aplikacja jest TWA? Sprawdzimy to przy zamówieniu

Nie musisz uruchamiać poleceń adb ani zaglądać do APK. PrimeTestLab może potwierdzić, czy Twoja aplikacja jest TWA. Po zamówieniu usługi testowej nasz zespół sprawdza kompilację, rozpoznaje TWA lub opakowanie PWA i w razie potrzeby wskazuje konkretne poprawki przed zmarnowaniem 14-dniowego cyklu na architekturę obarczoną problemem zaangażowania.

Co dzieje się po zamówieniu

Jak pomaga PrimeTestLab, czyli druga połowa problemu

Architektura to połowa problemu. Drugą, która zatrzymuje wielu samodzielnych deweloperów, jest znalezienie 12 testerów, którzy rzeczywiście dołączą do testu i pozostaną aktywni nieprzerwanie przez 14 dni. W tym pomaga PrimeTestLab.

Zapewniamy zweryfikowanych testerów na prawdziwych urządzeniach z Androidem. Uczestniczą w teście zamkniętym przez cały wymagany okres, aby rezygnacja jednej osoby nie przerwała 14-dniowej ciągłości. Ty udostępniasz link do testów, a my obsługujemy zaproszenia, weryfikację uczestnictwa, codzienne monitorowanie zaangażowania i utrzymanie testerów przez 14 dni. Obsłużyliśmy już 7 400+ aplikacji ze skutecznością 99,9% przy pierwszej próbie.

Aktualne plany

Plus 5% opłaty serwisowej · Bezpłatny ponowny test lub pełny zwrot pieniędzy

Często zadawane pytania

Podsumowanie