O processo de transformar um app Android em uma página web

• O Travelbound, que mostra itinerários de viagem, informações de hospedagem e PDFs, na prática exibia conteúdo recebido da web e ainda incluía rastreamento e anúncios de viagem, então foi substituído por uma página web com as mesmas informações
• Ao fazer root em um dispositivo virtual Android e interceptar o tráfego com o HTTP Toolkit, foi confirmado que uma API que concatenava nome de usuário e senha na URL retornava em JSON todo o conteúdo do app
• Com script em Ruby e Cron, o JSON mais recente era buscado periodicamente e convertido em HTML, expondo apenas os arquivos necessários, como itinerário e PDFs, e excluindo os dados de anúncios
• A versão web permite copiar, imprimir, salvar, favoritar e pesquisar, funciona em uma variedade maior de dispositivos e também remove o código de rastreamento e os anúncios do app original
• Enquanto o app original vai de 43MB a 124MB após baixar o conteúdo, a página web tem 0.05MB e as imagens opcionais somam apenas 35MB, mostrando que a web é mais adequada para conteúdo documental entregue em HTML e HTTP

---

Travelbound, que poderia muito bem ser uma página web

• Para consultar o itinerário da viagem à Disneyland, transporte e hospedagem da escola de artes cênicas que a criança vai frequentar, era preciso instalar o app Travelbound
• O conteúdo principal do app era entregue pela web como texto, imagens e links para PDF
• As funções que o diferenciavam de uma página web eram duas, e ambas desfavoráveis ao usuário
  • Enviava aos desenvolvedores dados de rastreamento vinculados à Google Account
  • Anunciava outros produtos de viagem da mesma operadora sob o nome inspirations
• Em uma página web, seria possível copiar, imprimir, salvar, favoritar e pesquisar o conteúdo, além de usá-lo em praticamente qualquer dispositivo e potencialmente com melhor acessibilidade

Interceptando o tráfego do app Android

• No Virtual Device Manager do Android Studio, foi criado um novo dispositivo virtual e confirmado que adb shell funcionava
• O dispositivo virtual Android 33 foi rootado com o rootAVD

  ./rootAVD.sh system-images/android-33/google_apis_playstore/x86_64/ramdisk.img  
  

• O root era necessário para fazer apps que usam Certificate Pinning confiarem no certificado TLS autoassinado do proxy man-in-the-middle
  • Sem root, apps como o Travelbound consideravam o certificado inválido e recusavam a comunicação
• Após um cold boot, foi executado o Magisk e configurada a permissão automática de acesso su para os apps que solicitassem isso
  • Sem a permissão automática, o HTTP Toolkit era executado em modo não privilegiado sem esperar pela resposta do usuário
• O tráfego do dispositivo virtual Android foi interceptado com o HTTP Toolkit
  • Ele instala um provedor de VPN falso para encaminhar o tráfego do dispositivo ao proxy
  • Por limitações de segurança do Android, o certificado raiz da CA instalada precisava ser adicionado manualmente
• Depois de instalar o Travelbound pela Play Store, foi configurado o proxy para interceptar apenas o tráfego desse app, reduzindo o ruído

Chamadas de API e estrutura dos dados

• O app concatenava o nome de usuário e a senha do grupo de viagem e chamava uma URL de API no seguinte formato

  https://travelbound.api.vamoos.com/api/itineraries/…}  
  

• O nome de usuário e a senha eram credenciais compartilhadas por todo o grupo de viagem
• O JSON de resposta da API continha todo o conteúdo exibido pelo app
  • Um array com cada trecho do itinerário de viagem
  • Um array de anúncios inspirations
  • Um array de referências cruzadas com arquivos como imagens usados em outras seções
• Até o código HTML a ser exibido pelo app estava incluído nos dados, então a forma de entrega do conteúdo já era parecida com uma página web
• As URLs de imagens no S3 expiravam relativamente rápido, então era preciso buscar o JSON periodicamente mesmo quando o conteúdo não mudava
  • Outra alternativa seria armazenar as imagens localmente em cache, e o app original aparentemente seguia essa abordagem

Convertendo JSON em HTML

• Foi escrito um script em Ruby e configurado um agendamento no Cron para buscar periodicamente o JSON mais recente e gerar páginas HTML
• Durante a geração, os anúncios inspirations, correspondentes a overlayRows no esquema de dados, foram totalmente excluídos
• A página web exibia apenas as seguintes informações
  1. Itens do itinerário de viagem
  2. Todos os arquivos não referenciados por anúncios nem pelo itinerário
• A segunda lista foi usada como uma forma simples de reunir em um único lugar os links de download dos PDFs
• A página gerada foi protegida com a mesma senha fornecida ao grupo de viagem existente
• O JSON original foi colocado em um elemento <details> para permitir verificar se mais tarde surgiriam dados de esquema que o script existente ainda não identificasse

Uma versão web menor e mais flexível

• A página web não é tão chamativa quanto o app original, mas é muito menor e oferece os recursos básicos da web sem implementação adicional
• É possível copiar, imprimir, salvar, favoritar e pesquisar o conteúdo, além de acessá-lo em uma variedade maior de dispositivos
• Ao remover o código de rastreamento e os anúncios, também elimina as duas funções desnecessárias presentes no app original
• A acessibilidade não foi auditada formalmente, mas o app original tinha elementos que pareciam mais difíceis de usar com tecnologias assistivas do que uma versão web simples

Comparando tamanho e forma de distribuição

• O app Travelbound original começa com 43MB e cresce até 124MB após baixar conteúdo adicional
• A página web alternativa tem 0.05MB, e baixar todas as imagens opcionalmente adiciona 35MB
• Ambos os métodos foram compartilhados com o grupo de viagem, para que cada usuário pudesse escolher entre o app e a página web
• Em alguns casos um app faz sentido, mas o conteúdo do Travelbound, já escrito em HTML e entregue por HTTP, não é um caso em que um app seja necessário
• Distribuir via app store aumenta custo e esforço de desenvolvimento, e limitar esse tipo de conteúdo documental a um app reduz o número de pessoas que podem usá-lo e os recursos básicos disponíveis em comparação com publicar diretamente na web

[GN⁺]

Opiniões no Lobste.rs

• Eu estava cansado de ver serviços que, em essência, não passam de páginas web levando ao inchaço dos apps, então fico aliviado em saber que não sou o único
  No Android, criar atalhos para páginas web não é algo muito visível para o usuário, então dá para entender por que empresas preferem apps. Mas, se o serviço envia uma senha por mensagem junto com um link para o app, um web app é a opção mais adequada. Basta apontar diretamente para a página da senha
  A loja de apps do /e/OS também tem uma seção de “web apps” que reúne itens como a versão web do Google Maps. PWAs em si são fáceis de usar, mas não sei o quanto o Chrome padrão ou o Android dos fabricantes orientam de forma ativa e visível a criação de atalhos
  O método atual claramente não é voltado ao usuário, e é preciso pensar em como melhorá-lo

• Para usuários comuns, especialmente pessoas pouco familiarizadas com computadores, a diferença entre um app e uma página web é, na prática, apenas um atalho na área de trabalho ou na tela inicial
  Se fosse possível distribuir diretamente atalhos para páginas web, isso seria uma forma muito barata de desenvolver apps, e talvez a maioria dos apps pudesse ter sido feita assim

  • No Safari do iOS, depois de abrir uma página web, dá para tocar no botão de compartilhamento, passar por “View More” e escolher “Add to Home Screen” para adicionar um ícone à tela inicial
    Ao tocar nesse ícone, abre-se uma janela independente, como em um app normal, e não uma nova aba do navegador. Eu distribuí assim uma ferramenta de despesas familiares que fiz, sem publicá-la na App Store

• Inúmeros “apps” poderiam ser simplesmente páginas web. É frustrante haver tantas situações em que é preciso instalar um app primeiro só para usar um recurso trivial, sem nenhum bom motivo
  Usar um app para conexão com um dispositivo local é compreensível, mas há sistemas que fazem o app se comunicar com o dispositivo local passando por um servidor central. Com isso, até a única justificativa para exigir a instalação do app desaparece
  O iPhone inicial tentou usar páginas web como plataforma de apps, mas acabou virando o ecossistema bagunçado que temos hoje