Como verificar os Android App Links para garantir lançamentos instantâneos de aplicativos

Como verifico os Android App Links no manifesto? A verificação de Android App Links requer hospedar um arquivo assetlinks.json no diretório .well-known do seu domínio, adicionar android:autoVerify=“true” à atividade do seu iniciador no manifesto e validar a assinatura do certificado. Essa verificação nativa ignora os diálogos de seleção do Chrome e o atrito de popups de esquemas de URL legados com 98,7% de estabilidade no deep linking.

No cenário de crescimento mobile e desenvolvimento de aplicativos, a indústria considera cada vez mais os Android App Links do SDK como o padrão ouro para redirecionamentos seguros e sem atrito em dispositivos Android. Quando o Google atualizou o sistema de verificação de pacotes, os padrões de segurança de domínio foram reforçados. Sem uma verificação bem-sucedida, os links recorrem à renderização web padrão, disparando prompts de escolha de navegador que prejudicam as conversões de usuários.

Vamos ser francos: forçar os usuários a escolher um navegador durante a jornada de deep linking degrada a experiência. Você precisa de um processo de handshake seguro e verificado que ignore o atrito dos diálogos nativamente.

O mandato de redirecionamento do Android 12: Por que domínios não verificados recorrem ao diálogo de seleção

A partir do Android 12, o Google impôs requisitos rígidos de auto-verificação para filtros de intenção. Se o seu aplicativo declara domínios personalizados no manifesto sob o esquema HTTPS, o sistema operacional tenta verificar cada domínio durante a instalação.

A realidade? Uma única falha de verificação interrompe toda a cadeia:

• Diálogo de seleção do sistema: Se apenas um domínio declarado falhar no handshake, o Android desativa o roteamento nativo para todos os domínios do manifesto, recorrendo aos prompts de navegador.
• Fallbacks forçados para a Web: Domínios não verificados redirecionam os usuários diretamente para o Chrome, contornando os caminhos de deep linking dentro do aplicativo.
• Loops de conversão quebrados: Os usuários são forçados a navegar manualmente no seu aplicativo para encontrar os produtos desejados, causando perdas massivas em campanhas.

Para evitar essas falhas de redirecionamento, os desenvolvedores devem hospedar um arquivo de verificação de ativos válido em seu domínio.

A especificação Digital Asset Links: Formatando o manifesto JSON assetlinks

A base do deep linking seguro no Android é o manifesto assetlinks.json. O gerenciador de pacotes do sistema operacional consulta este arquivo através de uma conexão HTTPS segura durante a instalação do aplicativo.

O esquema JSON assetlinks: Especificando nomes de pacotes e impressões digitais SHA-256

O arquivo assetlinks.json deve residir no diretório .well-known do seu domínio. Seu servidor web deve retornar uma resposta HTTP 200 direta com um cabeçalho content-type como application/json. O arquivo declara a associação entre seu domínio e a assinatura exclusiva do certificado de assinatura do seu aplicativo.

Consulte o padrão estrutural abaixo para formatar seu arquivo de verificação de ativos Android:

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.opoinstall.travel",
      "sha256_cert_fingerprints": [
        "14:6D:E9:83:C5:30:06:22:98:5B:90:75:EF:C4:22:15:30:19:93:33:F4:6D:E9:83:C5:30:06:22:98:5B:90:75"
      ]
    }
  }
]

Declarações XML do Android Manifest: Configurando filtros de intenção e handshakes de auto-verificação

Para instruir o sistema operacional a iniciar o handshake de verificação, você deve atualizar seu arquivo AndroidManifest.xml. A atividade do iniciador alvo deve incluir um filtro de intenção específico. Este filtro declara a ação android.intent.action.VIEW, as categorias android.intent.category.DEFAULT e android.intent.category.BROWSABLE, e o atributo android:autoVerify="true".

Consulte a estrutura XML padrão abaixo para configurar seu manifesto:

<activity
    android:name=".MainActivity"
    android:exported="true"
    android:launchMode="singleTask">
    
    <!-- Ativar verificação automática de domínio para Android App Links -->
    <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="travel.opwakeup.com" />
        <data android:host="travel-alternate.opwakeup.com" />
    </intent-filter>
</activity>

Android App Links vs. Esquemas de URL personalizados: Verificação em nível de host e escopos de segurança

Para avaliar como a associação de domínio verificada se compara a protocolos personalizados não verificados sob as modernas restrições de segurança do Android, analise a comparação abaixo:

Implantando um SDK unificado para automatizar Handshakes domínio-app

Manter manualmente manifestos assetlinks em vários subdomínios e variantes de build é um ponto comum de falha de engenharia. Integrar um framework de medição mobile leve e dedicado como o Opoinstall automatiza toda a arquitetura de hospedagem do lado do servidor.

Configurando seu domínio de marca no Console do Desenvolvedor

Sua integração começa mapeando seus domínios de campanha. Registre seu aplicativo no console do desenvolvedor para obter sua AppKey. Este token conecta seu cliente mobile compilado ao seu banco de dados central de rastreamento de cliques web.

Integrando o framework SDK do lado do cliente

O próximo passo requer a integração do nosso SDK de lançamento com um clique em suas builds. Esta biblioteca não bloqueante conecta-se aos métodos de entrada do seu aplicativo para interceptar atividades de usuários e analisar payloads contextuais.

Verificando declarações de host ativas via API de Digital Asset Links do Google

Para verificar se seu domínio está servindo o manifesto corretamente, você pode consultar a API de Digital Asset Links do Google diretamente:

https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://seudominio.com&relation=delegate_permission/common.handle_all_urls

Esta chamada de API programática verifica se o crawler de verificação do Google consegue ler corretamente o nome do seu pacote e as impressões digitais SHA-256. Isso garante que suas configurações do lado do servidor estejam perfeitamente alinhadas.

Depurando falhas de verificação de domínio: Um estudo de caso de 15% de perda em Mobile App Links

Um grande aplicativo de viagens passou por uma atualização padrão do sistema. Durante o staging, a equipe de QA relatou que deep links em e-mails promocionais falhavam em dispositivos Android 12 e 13, forçando os usuários a escolher um navegador web em vez de iniciar o app nativamente.

Sintomas anormais: Popups de seleção de navegador persistentes em dispositivos Android 12+

Os deep links funcionavam corretamente em dispositivos mais antigos. No entanto, a política de verificação rigorosa do Android 12 significava que, como um único domínio secundário falhou no handshake, o sistema operacional desativou os App Links para todos os domínios declarados no manifesto. Isso resultou em uma queda de 15% na integração de usuários.

Depuração via CLI com Android Debug Bridge e reconciliação de estado

A equipe de engenharia iniciou uma auditoria técnica. Primeiro, verificaram se o pacote compilado continha os direitos corretos. Executaram uma verificação de direitos por linha de comando no dispositivo de teste conectado usando o Android Debug Bridge (ADB):

# Passo 1: Resetar o estado de verificação de domínio para o pacote alvo
$ adb shell pm set-app-links --package com.opoinstall.travel 0 all

# Passo 2: Disparar manualmente o handshake de auto-verificação do SO
$ adb shell pm verify-app-links --re-verify com.opoinstall.travel

# Passo 3: Consultar o estado de verificação dinâmica dos seus domínios declarados
$ adb shell pm get-app-links com.opoinstall.travel

A saída da linha de comando retornou um status state: 1024 (unverified). Isso confirmou que o gerenciador de pacotes Android rejeitou a associação domínio-app durante a instalação.

Resolvendo bloqueios de redirecionamento HTTPS e incompatibilidades na lista de declarações

Os desenvolvedores consultaram o crawler de verificação de Digital Asset Links do Google para isolar o erro. Os logs do crawler revelaram um timeout no handshake TLS: o servidor web hospedava o arquivo assetlinks.json atrás de um firewall que bloqueava IPs de crawlers automáticos do Google.

Além disso, o servidor estava executando um redirecionamento 301 da porta HTTP para HTTPS. Como o sistema de verificação do Android proíbe estritamente redirecionamentos HTTP para App Links, o handshake automático falhou.

Para resolver o bloqueio, a equipe configurou o servidor web para retornar uma resposta HTTP 200 direta na porta 443 com o cabeçalho application/json, contornando quaisquer redirecionamentos HTTP. Para garantir que o caminho de fallback permanecesse ativo, certificaram-se de que o script de redirecionamento do lado do cliente utilizasse a API padrão Google Play Install Referrer API para capturar payloads de instalação.

Auditoria pós-migração: 15% de conversão recuperada e 98,7% de sucesso na verificação

Após reinstalar o pacote atualizado, a equipe de engenharia executou novamente a ferramenta de verificação ADB. O comando retornou um estado verified.

O SDK interceptou instantaneamente as intenções de deep-link sem acionar diálogos de escolha. A precisão do redirecionamento cross-platform subiu de volta para 98,7%, restaurando com sucesso a experiência de reserva para todos os usuários de campanhas e protegendo o ROI de marketing do cliente.

À medida que os sistemas operacionais mobile reforçam os sandboxes de privacidade, o cenário de deep-linking deve evoluir. A depreciação de IDs de rastreamento legados como o IDFA significa que os redirecionamentos de passagem de dados devem depender inteiramente de associações de domínio proprietário seguras. Plataformas que automatizam a hospedagem AASA e a validação de assinaturas continuarão vitais. Ao centralizar sua infraestrutura de roteamento em redes SDK seguras e amigáveis aos desenvolvedores, você protege seus funis de crescimento contra futuras mudanças de privacidade, ao mesmo tempo em que entrega uma jornada de usuário fluida e segura.