Como navegar pela qualidade multidispositivo e publicar além de dispositivos móveis no Google Play

Olá, pessoal!

Agradecemos sua participação nesta sessão sobre como navegar pela qualidade de apps multidispositivo e publicar no Google Play para formatos além de dispositivos móveis.

Meu nome é Jan Kleinert, e sou engenheiro de relações com desenvolvedores na equipe do Android para carros.

E eu sou Faustine Liao, líder de operações na equipe de Confiabilidade e Segurança do Google Play.

É muito bom ter vocês aqui com a gente hoje.

Por anos, quando falávamos em desenvolvimento Android, a maioria de nós pensava apenas em um dispositivo móvel, mas o ecossistema Android se expandiu muito além dos smartphones.

Hoje, os usuários interagem com apps na sala de estar com o Android TV, talvez na fila de carona ou enquanto carregam o carro com o Android Auto ou o Automotive OS, no pulso com o Wear OS e, cada vez mais, em espaços 3D imersivos com o Android XR.

Essa é uma grande oportunidade de crescimento, mas a expansão para esses formatos significa que há algumas considerações marginais a serem levadas em conta na sua estratégia de publicação.

O processo geral, desde a criação do app até a publicação e disponibilização no Google Play, é o mesmo que você já conhece para lançamentos em dispositivos móveis.

Crie e prepare o app, crie a página "Detalhes do app" no Play Console, teste o app, faça upload e envie a versão de produção e aguarde a revisão e aprovação.

No entanto, há algumas considerações específicas para publicar apps em formatos além de dispositivos móveis.

Hoje, vamos apresentar um framework claro para ajudar você a se preparar para um processo de lançamento multidispositivo mais tranquilo e previsível.

Vamos começar com o básico: como arquitetar e empacotar seu app.

Portanto, antes mesmo de tocar no Google Play Console, você precisa tomar uma decisão arquitetônica importante.

Você cria um único pacote de app unificado que contém tudo para todos os formatos compatíveis ou divide o app em módulos específicos para cada formato e gera Android App Bundles (AABs) para cada um?

Quando falo em módulos ou modularização, estou me referindo a uma maneira de estruturar sua base de código para melhorar a manutenção.

Há muitas abordagens para a modularização, mas, em geral, o que você faz é organizar sua base de código em partes independentes e acopladas com flexibilidade, em que cada parte é um módulo.

Embora uma abordagem unificada de pacote de app para Android possa parecer mais simples de gerenciar, recomendamos a abordagem modular.

Veja um exemplo que demonstra por que recomendamos essa abordagem modular.

Imagine que você tem um app compatível com dispositivos móveis e Android TV.

Se você enviar um único Android App Bundle na faixa de lançamento padrão para dispositivos móveis e o app para Android TV for reprovado em uma verificação de revisão, todo o lançamento será interrompido.

Isso vai afetar o lançamento do app para Android TV e do app para dispositivos móveis.

Portanto, mesmo que não haja um problema específico com o app para dispositivos móveis, você precisa resolver os problemas que causaram a reprovação na revisão do Android TV e reenviar o app para revisão antes que a versão seja disponibilizada aos usuários.

Por outro lado, os pacotes de apps Android modulares para cada formato oferecem um controle mais granular e ajudam a isolar as versões de formato das versões para dispositivos móveis.

Por isso, se você tiver módulos separados para o app para dispositivos móveis e o app de TV, poderá gerar Android App Bundles separados para cada um.

Se houver um problema com a revisão do app de TV, apenas a versão dele será bloqueada até que você resolva o problema.

A versão do app para dispositivos móveis será publicada conforme o esperado.

Como mencionei antes, há muitas abordagens para a modularização.

Este é um exemplo de abordagem para modularizar um app de audiolivros que tem uma experiência para dispositivos móveis e outra para o Android Automotive OS.

Na parte de cima, em verde, temos um módulo de app para cada formato, o que ajuda a separar as dependências específicas da plataforma.

Em amarelo, temos os módulos de recursos, que correspondem a partes isoladas da funcionalidade do app.

Os módulos de dados estão em azul e, na parte de baixo, temos os módulos principais ou comuns, que geralmente são usados para conter códigos que outros módulos usam com frequência.

Em seguida, nos arquivos de configurações do Gradle do projeto, você pode incluir e definir essa configuração do Gradle de vários módulos para oferecer suporte a esse tipo de modularização.

...

rootProject.name = "MultiFormFactorApp"

// Define modules for each form factor
include(":app:automotive")
include(":app:mobile")
include(":core:network")
include(":data:books")
include(":data:reviews")
include(":feature:home")
include(":feature:player")
include(":feature:reviews")

Portanto, você vai continuar usando o mesmo nome de pacote ou ID do aplicativo para cada módulo e pacote de app.

Essa abordagem modular está diretamente relacionada à sua estratégia de faixas no Play Console.

Ao publicar, você tem a faixa padrão para dispositivos móveis, mas também oferecemos faixas dedicadas para formatos específicos.

Para Android TV, Android XR e Android Automotive OS, você tem uma opção.

Você pode publicar junto com o dispositivo móvel ou usar as faixas de formato dedicadas.

No entanto, há duas exceções.

Para o Wear OS, use a faixa dedicada.

E para o Android Auto, como ele é basicamente uma extensão do seu app para dispositivos móveis projetada na tela do carro, a única opção é a faixa padrão para dispositivos móveis.

Se você gerencia várias faixas, o controle de versões é fundamental.

Uma abordagem é atribuir os primeiros dígitos do código de versão ao formato.

Por exemplo, 01 para dispositivos móveis, 02 para Wear OS, 03 para Android Automotive OS e assim por diante.

Em geral, recomendamos que os códigos de versão tenham pelo menos sete dígitos para que os restantes possam ser usados na versão do app.

Isso ajuda a evitar colisões de código de versão no Play Console.

Depois de empacotar o app, é hora de testar.

O desenvolvimento de formatos exige testes completos, e o Google Play oferece três canais diferentes para fazer isso antes do lançamento para produção: teste interno, teste fechado e teste aberto.

Se você estiver usando faixas dedicadas para formatos, também poderá combinar essas faixas de teste com os formatos, o que oferece um controle ainda mais granular sobre o processo.

Por exemplo, você pode ter uma versão de teste fechado para o app para dispositivos móveis na faixa padrão e outra para o app para Android TV na faixa dedicada ao formato do Android TV, com diferentes grupos de testadores, se quiser configurar dessa forma.

Por isso, o teste interno é um ótimo ponto de partida.

Ele permite distribuir rapidamente o app para até 100 testadores e, o mais importante, não aciona uma revisão do Google Play.

Isso significa que você e seus testadores podem instalar o app em dispositivos rapidamente e validar a experiência em emuladores ou em uma TV, um relógio ou outro dispositivo real.

E, com os testes internos, você recebe um URL exclusivo para compartilhar com esses testadores.

Quando os resultados do teste interno forem satisfatórios, você poderá passar para os testes fechados e abertos.

Você pode ir além dos testes internos com uma versão de teste fechado, que permite testar versões de pré-lançamento do app com mais testadores para receber feedback direcionado.

Você pode gerenciar seus grupos de teste fechado como listas de endereços de e-mail ou pelos Grupos do Google.

Já o teste aberto ajuda você a fazer um teste com um grupo maior no Google Play.

Você vai ficar visível no Google Play, e qualquer pessoa poderá participar do programa de teste aberto.

Não é necessário enviar um convite, e eles poderão compartilhar feedback público e particular com você sobre o app.

Essas faixas de teste aberto e fechado acionam revisões.

Na verdade, essa é uma vantagem enorme.

Ele permite que você teste o processo de revisão e resolva qualquer problema antes do dia do lançamento.

Por falar no processo de revisão, vamos falar um pouco sobre o que ele envolve e por que é importante.

No fundo, essas políticas e diretrizes têm como objetivo garantir a qualidade dos apps.

Os apps e jogos de alta qualidade agregam valor para os usuários, são agradáveis de usar, aproveitam ao máximo os dispositivos premium e são projetados para garantir a segurança.

Vamos ver como preparar seu app para que ele seja aprovado nas revisões com o mínimo de esforço.

Acho que o melhor lugar para começar é analisando as diretrizes de qualidade do app, que se concentram em como é uma ótima experiência do usuário.

Publicamos as diretrizes de qualidade básica de apps, que se aplicam a todos os apps e definem a qualidade mínima que todos eles precisam atender, além das diretrizes de qualidade de apps adaptáveis, que ajudam a garantir que seu app ofereça uma ótima experiência, independente do formato do dispositivo, do tamanho da tela ou do modo de exibição.

Esses dois conjuntos de diretrizes são um ótimo ponto de partida.

Mas também temos diretrizes de qualidade específicas para cada formato.

Nossos revisores vão testar seus apps em dispositivos reais e emuladores de acordo com essas diretrizes.

Por isso, é muito importante garantir que seu app siga essas diretrizes.

Confira os motivos mais comuns para a rejeição de apps em cada formato.

Mas não se esqueça de que elas não cobrem todas as diretrizes de qualidade de apps.

Por isso, confira as diretrizes de qualidade de cada formato com que você trabalha para conhecer o conjunto de critérios mais robusto.

Vamos começar com o Android TV.

Por isso, na parte de baixo dos slides de cada seção, você vai encontrar um link curto que leva à lista completa de diretrizes de qualidade de apps para esse formato.

Um motivo comum para a rejeição de apps para Android TV é a falta de uma imagem do banner da tela inicial para cada idioma em que o app é disponibilizado.

Portanto, forneça uma imagem de 320 x 180 pixels que inclua um texto localizado que identifique seu app.

A imagem neste slide mostra um exemplo de banner da tela inicial que segue esses critérios.

Em segundo lugar, na maioria das TVs, os usuários vão interagir com o dispositivo usando um controle remoto com botão direcional.

Por isso, é fundamental que você ofereça suporte adequado à navegação e ao foco do botão direcional.

Confirme se você oferece suporte pelo menos aos controles mínimos do botão direcional para evitar rejeições com base nesses critérios.

O terceiro motivo comum para rejeições de apps para Android TV é a ausência do filtro de intent CATEGORY_LEANBACK_LAUNCHER no arquivo de manifesto do Android.

<application ...>
...
<activity
    android:name="com.example.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">
    <intent-filter>
      <action android:name=
           "android.intent.action.MAIN" />
      <category android:name=
           "Android.intent.category.
            LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>

Esse filtro vai identificar seu app como ativado para TV e permitir que o Google Play também o identifique como um app de TV para os usuários.

Assim, quando um usuário seleciona seu app na tela inicial da TV, essa intent identifica qual atividade deve ser iniciada.

Por isso, inclua-a no manifesto.

O Android XR é o próximo.

Ao criar para headsets ou óculos XR com tecnologia Android XR, preste atenção especial ao desempenho, à renderização e à estabilidade dos seus apps.

Use o Perfetto para analisar o desempenho de apps criados com o SDK do Jetpack XR e garantir que você esteja aderindo aos requisitos mínimos de frame rate.

Se você estiver criando com um mecanismo em tempo real, como o Unity, use as ferramentas de criação de perfil integradas para garantir que os requisitos de renderização sejam atendidos.

Em seguida, temos os carros, que incluem o Android Auto e o Android Automotive OS.

Para o Android Auto e o Android Automotive OS, há uma noção de categorias, que são um pouco exclusivas para esse formato específico.

Além disso, apenas algumas categorias de apps podem ser publicadas para carros.

Portanto, se você enviar um app para uma categoria que não se alinha a uma das que aceitamos ou se enviar um app para teste aberto ou produção em uma categoria que está apenas na versão Beta, ele será rejeitado.

Vou mostrar o que quero dizer em mais detalhes.

Aqui, você pode ver uma visão geral das categorias de apps compatíveis com carros em cada plataforma, além da disponibilidade delas.

Seja na versão Beta, aberta, ou seja, em disponibilidade geral, ou ainda não compatível, o que é indicado aqui por "em breve".

Algumas categorias, como apps de navegação ou de pontos de interesse, estão em disponibilidade geral, o que significa que qualquer pessoa pode publicar um app em uma dessas categorias para produção em carros.

No entanto, outras categorias, como apps de comunicação para o Android Auto, estão na versão Beta.

Para essas categorias, é possível publicar em testes internos ou em uma faixa de teste fechado, mas não em produção, a menos que você tenha sido aceito em um dos nossos programas de acesso antecipado para essa categoria.

Para saber mais detalhes sobre isso e muito mais, consulte nossos guias para desenvolvedores do Android para carros.

Lá você encontra links para se inscrever nesses programas de acesso antecipado.

Especificações ausentes ou incorretas para capturas de tela do Android Automotive OS são outro motivo comum para a rejeição de apps.

Portanto, ao enviar capturas de tela do Android Automotive OS, inclua pelo menos duas capturas de tela no modo retrato e pelo menos duas no modo paisagem com as dimensões listadas aqui.

Você pode usar o emulador do Android Automotive OS para ajudar a capturar essas imagens.

Ele é configurado de forma a capturar apenas o tamanho certo das capturas de tela que você precisa.

Por fim, a segurança é fundamental em apps para carros.

Portanto, se o app não seguir nossas diretrizes de distração do motorista, ele será rejeitado.

Por exemplo, um app de vídeo precisa pausar a reprodução e não pode ficar visível enquanto o veículo estiver em movimento.

Por último, mas não menos importante, temos o Wear OS.

Por isso, os apps para Wear OS podem ser rejeitados se não forem otimizados e formatados para telas pequenas e redondas.

Por isso, recomendamos usar a versão estável mais recente do Compose para Wear OS para garantir que o conteúdo não seja cortado nas bordas em dispositivos de tamanhos diferentes ou, por exemplo, para garantir que a barra de rolagem apareça quando houver conteúdo rolável.

@Composable
fun MyText() {
  Text(
    text = stringResource(R.string.compose_for_wear_os),
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    style = MaterialTheme.typography.titleLarge
  )
}

Assim como no Android Automotive OS, os apps para Wear OS também podem ser rejeitados se as capturas de tela do Wear OS estiverem ausentes ou forem imprecisas.

Este é um bom exemplo de captura de tela da página Detalhes do app Androidify na Google Play Store, que atende aos requisitos.

Por isso, envie pelo menos uma captura de tela que mostre o app em execução em um dispositivo Wear OS.

Que lição podemos tirar disso?

Leia as diretrizes de qualidade de apps para seu formato específico e faça testes antes de enviar.

Além disso, algumas dicas importantes.

Se o app exigir login, forneça uma conta de demonstração ativa e credenciais válidas na seção de acesso do app no Play Console.

Se os revisores não conseguirem fazer login, não poderemos testar o app, e ele será rejeitado automaticamente.

Além disso, cumpra o que você promete.

Não use apenas capturas de tela de dispositivos móveis.

Se o app estiver disponível para Wear OS e Android TV, faça upload de capturas de tela de alta qualidade para esses formatos específicos no Play Console.

Por último, mas não menos importante, seja descritivo.

Explique exatamente o que o app faz, por que ele é valioso e o que os usuários podem esperar ao instalar ele em cada tipo de dispositivo.

Para resumir, alcançar usuários em quase todos os lugares é uma oportunidade incrível. Ao criar uma arquitetura modular, usar testes internos para uma iteração rápida, projetar de acordo com as diretrizes de qualidade de formato e otimizar as páginas "Detalhes do app", você vai preparar seu app para um processo de lançamento e revisão mais tranquilo.

Agradecemos demais a presença de vocês aqui hoje.

Mal podemos esperar para ver as experiências multidispositivo incríveis que vocês vão trazer para o Google Play.