Cómo navegar por la calidad multidispositivo y publicar más allá de los dispositivos móviles en Google Play

Hola a todos.

Muchas gracias por acompañarnos en esta sesión sobre cómo navegar por la calidad de las apps multidispositivo y publicar en Google Play para factores de forma más allá de los dispositivos móviles.

Soy Jan Kleinert, ingeniero de Relaciones con Desarrolladores del equipo de Android para vehículos.

Y yo soy Faustine Liao, jefa de Operaciones del equipo de Confianza y Seguridad de Play.

Nos alegra mucho que estén aquí hoy.

Durante años, cuando hablábamos de desarrollo para Android, la mayoría de nosotros pensaba en un dispositivo móvil, pero el ecosistema de Android se expandió mucho más allá de los smartphones.

Por lo tanto, hoy en día, tus usuarios interactúan con apps en sus salas de estar en Android TV, tal vez en la fila de autos compartidos o mientras cargan sus autos en Android Auto o Automotive OS, en sus muñecas con Wear OS y, cada vez más, en espacios inmersivos en 3D con Android XR.

Esta es una gran oportunidad de crecimiento, pero expandirse a estos factores de forma implica que hay algunas consideraciones marginales que debes tener en cuenta para tu estrategia de publicación.

El proceso general, desde la compilación de la app hasta su publicación y lanzamiento en Google Play, sigue siendo, en general, el mismo que usas para los lanzamientos para dispositivos móviles.

Compila y prepara tu app, crea la ficha en Play Console, pruébala, sube y envía la versión de producción, y espera a que se revise y apruebe.

Sin embargo, hay algunas consideraciones únicas para publicar apps en factores de forma más allá de los dispositivos móviles.

Hoy, te daremos un marco de trabajo claro para ayudarte a prepararte para un proceso de lanzamiento multidispositivo más fluido y predecible.

Comencemos con los aspectos básicos: cómo diseñar y empaquetar tu app.

Por lo tanto, antes de usar Google Play Console, debes tomar una decisión importante sobre la arquitectura.

¿Creas un solo paquete de aplicación unificado que contenga todo para todos los factores de forma que admites o divides tu app en módulos específicos para cada factor de forma y generas Android App Bundles, o AAB, para cada uno?

Cuando hablo de módulos o modularización, me refiero a una forma de estructurar la base de código para mejorar el mantenimiento.

Existen muchos enfoques para la modularización, pero, en general, lo que haces es organizar tu base de código en partes con acoplamiento bajo y elementos independientes, en las que cada parte es un módulo.

Por lo tanto, si bien un enfoque unificado de Android App Bundle puede parecer más sencillo de administrar, recomendamos el enfoque modular.

Este es un ejemplo que demuestra por qué recomendamos este enfoque modular.

Imaginemos que tienes una app que admite dispositivos móviles y Android TV.

Si envías un solo Android App Bundle en el segmento estándar para dispositivos móviles y tu app para Android TV no pasa una verificación de revisión, se detendrá todo el lanzamiento.

Por lo tanto, esto afectará el lanzamiento de tu app para Android TV y tu app para dispositivos móviles.

Por lo tanto, aunque no haya habido un problema con tu app para dispositivos móviles específicamente, deberás solucionar los problemas que causaron que no se aprobara la revisión de Android TV y volver a enviar la app para su revisión antes de que la versión esté disponible para los usuarios.

Por otro lado, los paquetes de aplicaciones de Android modulares para cada factor de forma te darán un control más detallado y te ayudarán a aislar esos lanzamientos de factores de forma de tus lanzamientos para dispositivos móviles.

En cambio, si tienes módulos de app independientes para tu app para dispositivos móviles y tu app para TVs, puedes generar Android App Bundles independientes para cada una.

Y, si hay un problema con la revisión de tu app para TVs, solo se bloqueará el lanzamiento de esa app hasta que puedas resolver el problema.

La versión de la app para dispositivos móviles se publicará según lo previsto.

Como mencioné antes, existen muchos enfoques para la modularización.

Este es solo un ejemplo de un enfoque para modularizar una app de audiolibros que tiene una experiencia para dispositivos móviles y una experiencia para el SO Android Automotive.

En la parte superior, en verde, tenemos un módulo de app para cada factor de forma, lo que ayuda a separar las dependencias específicas de la plataforma.

Luego, en amarillo, tenemos los módulos de funciones, que corresponden a partes aisladas de la funcionalidad de la app.

Los módulos de datos están en azul y, en la parte inferior, tenemos los módulos principales o comunes, que se suelen usar para contener el código que otros módulos usan con frecuencia.

Luego, en los archivos de configuración de Gradle de tu proyecto, puedes incluir y establecer esta configuración de Gradle de varios módulos para admitir este tipo de modularización.

...

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")

Por lo tanto, seguirás usando el mismo nombre de paquete o ID de aplicación para cada módulo y paquete de la app.

Ese enfoque modular se vincula directamente con tu estrategia de segmentos en Play Console.

Cuando publicas, tienes el segmento estándar para dispositivos móviles, pero también ofrecemos segmentos dedicados para factores de forma.

Para Android TV, Android XR y el SO Android Automotive, tienes una opción.

Puedes publicarlas junto con las de dispositivos móviles o usar sus segmentos exclusivos para factores de forma.

Sin embargo, hay dos excepciones.

En el caso de Wear OS, debes usar el segmento exclusivo para este sistema operativo.

En el caso de Android Auto, como es básicamente una extensión de tu app para dispositivos móviles proyectada en la pantalla del auto, la única opción es el segmento estándar para dispositivos móviles.

Si administras varios segmentos, el control de versiones es fundamental.

Un enfoque consiste en asignar los primeros dígitos del código de versión al factor de forma.

Por ejemplo, 01 para dispositivos móviles, 02 para Wear OS, 03 para el SO Android Automotive, etcétera.

En general, te recomendamos que los códigos de versión tengan al menos siete dígitos, de modo que los dígitos restantes se puedan usar para la versión de la app.

Esto ayuda a evitar colisiones de códigos de versión en Play Console.

Una vez que tu app esté empaquetada, será el momento de probarla.

El desarrollo de factores de forma requiere pruebas exhaustivas, y Google Play te ofrece tres canales distintos para hacerlo antes del lanzamiento a producción: pruebas internas, pruebas cerradas y pruebas abiertas.

Si usas segmentos exclusivos para factores de forma, también puedes combinarlos con tus factores de forma, lo que te dará un control aún más detallado del proceso.

Por ejemplo, podrías tener una versión de prueba cerrada para tu app para dispositivos móviles en el segmento estándar y otra versión de prueba cerrada para tu app para Android TV en el segmento exclusivo para el factor de forma de Android TV con diferentes conjuntos de verificadores si quieres configurarlo de esa manera.

Por lo tanto, las pruebas internas son un excelente punto de partida.

Te permite distribuir rápidamente tu app a un máximo de 100 verificadores y, lo que es más importante, no activa una revisión de Play.

Esto significa que tú y tus verificadores pueden instalar la app en dispositivos rápidamente y validar la experiencia en emuladores o en una TV, un reloj o cualquier otro dispositivo real.

En el caso de las pruebas internas, obtendrás una URL única que podrás compartir con esos verificadores.

Cuando estés conforme con los resultados de las pruebas internas, podrás pasar a las pruebas cerradas y abiertas.

Puedes expandir las pruebas internas con una versión de prueba cerrada, que te permite probar versiones previas al lanzamiento de tu app con un conjunto más amplio de verificadores para obtener comentarios específicos.

Puedes administrar tus grupos de pruebas cerradas como listas de direcciones de correo electrónico o a través de Grupos de Google.

Por otro lado, las pruebas abiertas te permiten realizar una prueba con un grupo más grande en Google Play.

Tu app será visible en Google Play, y cualquier persona podrá unirse al programa de pruebas abiertas.

No se necesita invitación, y podrán compartir comentarios privados contigo sobre la app.

Estos segmentos de pruebas abiertas y cerradas activan las revisiones.

En realidad, esto es una gran ventaja.

Te permite probar el proceso de revisión en sí y superar cualquier obstáculo mucho antes del esperado día del lanzamiento.

Hablando del proceso de revisión, hablemos un poco sobre lo que implica y por qué es importante.

En esencia, estas políticas y lineamientos se centran en la calidad de las apps.

Por lo tanto, las apps y los juegos de alta calidad aportan valor a los usuarios, son agradables de usar, aprovechan al máximo los dispositivos premium y están diseñados para brindar seguridad.

Por lo tanto, veamos cómo puedes preparar tu app para que apruebe las revisiones con la mayor facilidad posible.

Creo que el mejor lugar para comenzar es consultar los lineamientos de calidad de las apps, que se enfocan en cómo se ve una excelente experiencia del usuario.

Publicamos los lineamientos de calidad de las apps principales que se aplican a todas las apps y definen la calidad mínima que deben cumplir, así como los lineamientos de calidad de las apps adaptables, que te ayudarán a garantizar que tu app brinde una excelente experiencia, independientemente del factor de forma del dispositivo, el tamaño de la pantalla o el modo de visualización.

Estos dos conjuntos de lineamientos son un excelente punto de partida.

Sin embargo, también tenemos lineamientos de calidad de las apps específicos para cada uno de los factores de forma.

Nuestros revisores probarán tus apps en dispositivos reales y emuladores según estos lineamientos.

Por lo tanto, es muy importante que te asegures de que tu app las cumpla.

A continuación, se presentan los motivos más comunes por los que se rechazan las apps para cada factor de forma.

Sin embargo, ten en cuenta que estas no abarcan una lista exhaustiva de todos los lineamientos de calidad de las apps.

Por lo tanto, asegúrate de consultar esos lineamientos de calidad para cada factor de forma con el que trabajes en detalle para obtener el conjunto de criterios más sólido.

Comencemos con Android TV.

Por lo tanto, en la parte inferior de estas diapositivas de sección, verás un vínculo corto que te llevará a la lista completa de lineamientos de calidad de las apps para ese factor de forma.

Un motivo común por el que se rechazan las apps para Android TV es que no tienen una imagen del banner de la pantalla principal para cada idioma que admite la app.

Por lo tanto, lo que debes hacer es proporcionar una imagen de 320 por 180 píxeles que incluya texto localizado que identifique tu app.

La imagen de esta diapositiva muestra un ejemplo de un banner de la pantalla principal que cumple con esos criterios.

En segundo lugar, en la mayoría de las TVs, los usuarios interactuarán con el dispositivo usando un control remoto con pad direccional.

Por lo tanto, es muy importante que admitas correctamente la navegación y el enfoque con pad direccional.

Asegúrate de admitir, al menos, los controles mínimos del pad direccional para evitar rechazos basados en esos criterios.

Y el tercer motivo común por el que se rechazan las apps para Android TV es que falta el filtro de intents CATEGORY_LEANBACK_LAUNCHER en el archivo de manifiesto de 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>

Este filtro identificará tu app como habilitada para TVs y permitirá que Google Play también la identifique como una app para TVs ante los usuarios.

Por lo tanto, cuando un usuario selecciona tu app en la pantalla principal de la TV, este intent identifica qué actividad se debe iniciar.

Por lo tanto, asegúrate de haberlo incluido en tu manifiesto.

Android XR es el siguiente paso.

Cuando compiles para visores o lentes de RE con tecnología de Android XR, presta especial atención al rendimiento, la renderización y la estabilidad de tus apps.

Puedes usar Perfetto para generar perfiles de rendimiento de las apps que se compilan con el SDK de XR de Jetpack y asegurarte de que cumples con los requisitos mínimos de velocidad de fotogramas.

Y si estás compilando con un motor en tiempo real como Unity, puedes usar las herramientas de generación de perfiles integradas en ese motor para asegurarte de que cumples con los requisitos de renderización.

Luego, tenemos los vehículos, que incluyen Android Auto y el SO Android Automotive.

Para Android Auto y el SO Android Automotive, existe una noción de categorías, que son un poco exclusivas de este factor de forma en particular.

Solo se permite publicar ciertas categorías de apps en vehículos.

Por lo tanto, si envías una app a una categoría que no se alinea con una de las que admitimos, o si envías una app a pruebas abiertas o producción para una categoría que solo está en versión beta, se rechazará.

Te mostraré a qué me refiero con más detalle.

Aquí arriba, puedes ver un resumen de las categorías de apps que se admiten en los vehículos para cada plataforma, junto con su disponibilidad.

Es decir, si está en versión beta, abierta (lo que significa que está disponible de forma general) o aún no es compatible (lo que se indica aquí como próximamente).

Por lo tanto, algunas categorías, como las apps de navegación o de lugares de interés, tienen disponibilidad general, lo que significa que cualquier persona puede publicar una app en una de esas categorías para producción en vehículos.

Sin embargo, otras categorías, como las apps de comunicación para Android Auto, están en versión beta.

Por lo tanto, para esas categorías, puedes publicar en un segmento de pruebas internas o cerradas, pero no puedes publicar en producción, a menos que se te haya aceptado en uno de nuestros programas de acceso anticipado para esa categoría.

Puedes encontrar más detalles sobre esto y mucho más en nuestras guías para desarrolladores de Android para vehículos.

Allí encontrarás vínculos para postularte a esos programas de acceso anticipado.

Otro motivo común por el que se rechazan las apps es que las especificaciones de las capturas de pantalla del SO Android Automotive faltan o son incorrectas.

Por lo tanto, cuando proporciones capturas de pantalla del SO Android Automotive, asegúrate de incluir al menos dos capturas de pantalla con orientación vertical y al menos dos con orientación horizontal con las dimensiones que se indican aquí.

Puedes usar el emulador del SO Android Automotive para capturarlas.

Está configurado de manera que pueda capturar solo el tamaño correcto de las capturas de pantalla que necesitas.

Por último, la seguridad es primordial en las apps para vehículos.

Por lo tanto, si tu app no cumple con nuestros lineamientos sobre la distracción del conductor, se rechazará.

Por ejemplo, una app de video debe pausar la reproducción y no puede estar visible mientras el vehículo está en movimiento.

Por último, pero no menos importante, tenemos Wear OS.

Por lo tanto, las apps para Wear OS se pueden rechazar si no están optimizadas ni formateadas para pantallas pequeñas y redondas.

Por lo tanto, te recomendamos que uses la versión estable más reciente de Compose para Wear OS para asegurarte de que el contenido no se corte en los bordes en dispositivos de diferentes tamaños o, por ejemplo, para asegurarte de que aparezca la barra de desplazamiento cuando haya contenido que se pueda desplazar.

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

Al igual que lo que mencionamos para el SO Android Automotive, las apps para Wear OS también se pueden rechazar si faltan capturas de pantalla de Wear OS o si estas son imprecisas.

Este es un buen ejemplo de una captura de pantalla de la ficha de Google Play Store de la app de ejemplo Androidify, que cumple con los requisitos.

Por lo tanto, asegúrate de enviar al menos una captura de pantalla que muestre tu app en ejecución en un dispositivo Wear OS.

¿La conclusión?

Lee los lineamientos de calidad de las apps para tu factor de forma específico y realiza pruebas para asegurarte de que se cumplan antes de enviar la app.

Además, te daremos algunos consejos cruciales.

Si tu app requiere acceso, debes proporcionar una cuenta de demostración activa y credenciales válidas en la sección de acceso a la app de Play Console.

Si nuestros revisores no pueden acceder, no podremos probar tu app y se rechazará automáticamente.

Además, asegúrate de cumplir con lo que prometes.

No uses solo capturas de pantalla de dispositivos móviles.

Si tu app está disponible para Wear OS y Android TV, asegúrate de subir capturas de pantalla de alta calidad para esos factores de forma específicos en Play Console.

Por último, pero no menos importante, sé descriptivo.

Explica con precisión qué hace la app, por qué es valiosa y qué pueden esperar los usuarios cuando la instalen en cada tipo de dispositivo.

En resumen, llegar a los usuarios casi dondequiera que vayan es una oportunidad increíble. Si creas una arquitectura modular, aprovechas las pruebas internas para realizar iteraciones rápidas, diseñas según los lineamientos de calidad de los factores de forma y optimizas tus fichas de Play Store, podrás preparar tu app para un proceso de lanzamiento y revisión más fluido.

Muchas gracias a todos por su tiempo.

Esperamos con ansias ver las increíbles experiencias multidispositivo que todos ustedes llevarán a Google Play.