TWA recusado no Google Play? Mude para WebView

Essa é uma das recusas mais frustrantes que um desenvolvedor indie pode sofrer. Seus testadores estavam de fato ativos. Você tinha suas 12 pessoas. Os 14 dias passaram. E o Google ainda respondeu com "your testers were not engaged enough." Se você construiu o app como Trusted Web Activity (TWA) ou wrapper PWA, não está imaginando o padrão: em mais de 7.400+ apps que acompanhamos, builds wrapper caem nessa recusa específica com bem mais frequência do que builds nativos padrão ou WebView. Este guia explica o porquê, mostra a diferença de arquitetura que importa e detalha a troca para WebView sem jogar fora os dias de teste que você já acumulou.

Por que apps TWA sofrem recusas no teste fechado?

Uma Trusted Web Activity renderiza seu site pela superfície de Custom Tabs do Chrome, em vez de desenhar as telas dentro do seu próprio app. É um caminho rápido para transformar um site ou PWA em algo instalável, e para muitos apps em produção funciona bem. O problema aparece especificamente quando uma conta pessoal de desenvolvedor precisa atender ao requisito obrigatório de teste fechado de 14 dias antes do acesso de produção.

Na nossa experiência ajudando mais de 7.400+ apps nesse processo, builds TWA e wrapper PWA recebem a recusa "testers were not engaged" com bem mais frequência do que apps nativos padrão, mesmo quando os testadores estavam de fato ativos todos os dias. O padrão é consistente o bastante para que hoje orientemos desenvolvedores a evitar TWA sempre que o app ainda precisar passar no teste fechado de 14 dias.

O que um TWA realmente é (e como é construído)

Antes de corrigir a recusa, ajuda entender exatamente o que você publicou. Uma Trusted Web Activity é um app Android que, em essência, é seu site rodando em tela cheia dentro de um motor de navegador real, sem barra de endereço, sem chrome do browser, nada que diga ao usuário que está olhando para uma página web. Para o usuário, parece e se sente como um app nativo. Por baixo, é o seu site ao vivo.

TWAs costumam ser gerados com a CLI Bubblewrap do Google ou com o PWABuilder, ambos sobre a biblioteca androidbrowserhelper do Google. Você aponta a ferramenta para uma URL, ela produz um projeto Android, você assina e envia o AAB ao Google Play.

Por que desenvolvedores escolhem um TWA

O trade-off que causa a recusa

A mesma coisa que deixa o TWA barato o torna frágil no teste fechado:

• Precisa de internet. É uma janela para o seu site, então conexão fraca significa app fraco, a menos que sua PWA tenha suporte offline sólido.
• Risco de recusa na Play Store. A política de funcionalidade mínima / conteúdo reempacotado mira apps que são "só um site em um wrapper". Um TWA sem capacidade nativa real pode ser recusado ou removido, especialmente em envios novos. Adicionar recursos nativos (push, modo offline, câmera, share targets) é como ficar do lado certo dessa linha.
• O problema dos sinais de engajamento coberto acima, que é por que contas pessoais diante do teste fechado de 14 dias continuam recebendo a mensagem "testers not engaged".

O equívoco: um TWA NÃO é um WebView

Esta é a parte que a maioria dos artigos erra, e vale ser preciso porque muda como você corrige o problema. Um TWA não usa o componente WebView do Android de forma alguma.

Como um TWA usa o motor por trás de Custom Tabs, você obtém o mesmo motor de renderização, JavaScript e sandbox de segurança do Chrome real, mais cookies e storage compartilhados com o Chrome (então um usuário já logado na web permanece logado), atualizações automáticas do browser e suporte completo à plataforma web. Isso é genuinamente poderoso para um app publicado normal, mas também significa que suas telas rodam fora de processo, dentro do Chrome, não dentro do seu app. Essa é a raiz tanto da diluição dos sinais de engajamento quanto das contagens baixas de usuários ativos.

O fluxo de lançamento, passo a passo

A checagem de confiança: Digital Asset Links

O Chrome só remove a barra de endereço se o app provar que é dono do site, usando Digital Asset Links. O app declara qual site representa, e o site deve servir um arquivo em /.well-known/assetlinks.json que nomeia o package do app e a impressão digital do certificado de assinatura (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
    ]
  }
}]

O caminho dos sinais de engajamento: TWA vs WebView

A forma mais simples de entender a recusa é seguir para onde a atividade do testador realmente vai. Em um TWA, suas telas vivem uma camada afastada do seu app, dentro da superfície de Custom Tabs do Chrome. Em um app WebView, as mesmas telas rodam dentro do processo da sua própria aplicação, atribuídas diretamente ao seu package. Essa única diferença é o que muda quão forte a atividade é registrada.

Como reconhecer um TWA (de fora e de dentro)

Não tem certeza se o app que você (ou um contratado) publicou é de fato um TWA? Veja como confirmar: primeiro a olho, depois de forma definitiva pelo APK ou por um dispositivo conectado.

Sinais visuais rápidos (como usuário)

• Comporta-se exatamente como o site, porque é o site.
• Se o desenvolvedor configurou mal, você verá uma barra de endereço do browser no topo: prova cabal (veja o bug de assetlinks acima).
• O conteúdo atualiza sem uma atualização de app aparecer na Play Store.

Sinais técnicos definitivos (inspecionando o APK / dispositivo)

Confirme com adb

Em um dispositivo conectado (ou emulador), dois comandos resolvem:

# 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 vs WebView no teste fechado: lado a lado

As duas arquiteturas encapsulam conteúdo web. A diferença que importa para passar no teste fechado de 14 dias é onde esse conteúdo roda e como a atividade é atribuída. Veja como elas se comparam nas métricas que decidem se você chega à produção em um ciclo.

A solução: construa um app WebView padrão

Em vez de remendar um TWA ou tentar extrair sinais melhores dele, o caminho mais limpo é reconstruir o app em torno de um componente WebView e publicar esse build. Há três rotas mainstream, todas carregando seu site dentro da sua própria aplicação:

O setup mínimo de WebView (pronto para copiar)

O núcleo é pequeno: um WebView que carrega sua URL com JavaScript e storage ativos, mantém a navegação dentro do app em vez de saltar para o Chrome, e conecta o handler do botão Voltar que a análise do Google espera. Troque a aba para a sua linguagem e copie a base:

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

As três coisas que você deve adicionar para passar na análise

Um WebView nu que só chama loadUrl() ainda é thin wrapper. Estas três adições o tornam um app real e mantêm os testadores longe de telas em branco:

Como trocar sem reiniciar o relógio de 14 dias

Se você já está no meio do teste, não precisa recomeçar. O contador de 14 dias sobrevive a uma atualização do app desde que você permaneça na mesma faixa com o mesmo package name. Esta é a migração segura:

Um app WebView ainda conta como "thin wrapper"?

Esta é a armadilha que pega desenvolvedores que acham que WebView é bala de prata. Trocar de TWA para WebView resolve o problema dos sinais de engajamento, mas não isenta você da política de Spam e funcionalidade mínima do Google. Um WebView que é só a homepage em um frame ainda pode ser recusado como thin wrapper (wrapper fino), do mesmo jeito que um TWA nu pode.

Ajuda ver isso como dois portões separados. Um serviço de teste ou um rebuild WebView pode ajudar a passar em um deles, mas não no outro.

Então o objetivo não é só "WebView em vez de TWA": é um app WebView com valor genuíno e comportamento nativo o bastante para se sustentar sozinho. Na prática, isso significa:

Quer o checklist mais profundo do que dispara uma recusa de qualidade? Nosso guia sobre por que o teste fechado é recusado detalha as falhas de política e análise mais comuns além do engajamento.

Não sabe se seu app é um TWA? Checamos no momento do pedido

Você não precisa rodar comandos adb nem vasculhar o APK sozinho. Sim: a PrimeTestLab pode confirmar se seu app é um TWA para você. No momento em que você pede nosso serviço de teste, nosso time inspeciona o build, identifica se é TWA ou wrapper PWA e, se for, diz exatamente o que corrigir antes de o relógio de 14 dias ser desperdiçado em uma arquitetura que será sinalizada por engajamento.

O que acontece no momento do pedido

Como a PrimeTestLab ajuda (a outra metade do problema)

A arquitetura é metade do problema. A outra metade, a que para a maioria dos desenvolvedores solo, é encontrar 12 testadores que de fato aceitem participar e continuem participando por 14 dias sem interrupção. É isso que a PrimeTestLab resolve.

Fornecemos testadores verificados, participando em dispositivos Android reais, que mantêm seu teste fechado ativo durante todo o requisito, para que a saída de um único testador nunca quebre sua sequência de 14 dias. Você compartilha o link de convite do teste fechado; cuidamos do convite, da verificação de participação, do monitoramento diário de engajamento e da retenção de 14 dias. Mais de 7.400+ apps, com taxa de sucesso de 99,9% na primeira tentativa.

Pacotes atuais

+5% de taxa de serviço · Novo teste grátis ou reembolso total

Perguntas frequentes

Conclusão