Cómo publicar en Google Play aplicaciones para dispositivos Android basados en x86 con soporte para múltiples APK

Google Play ha agregado compatibilidad con múltiples APK para la arquitectura de CPU x86. Esta funcionalidad le permite publicar diferentes APK para su aplicación, cada uno dirigido a la arquitectura de CPU x86. El APK es una versión completa e independiente de su aplicación, pero comparte el mismo listado en Google Play y debe tener el mismo nombre de paquete y estar firmado con la misma clave de versión. Esto es muy útil para los casos en que su aplicación no pueda funcionar en todos los dispositivos con un único APK, como es el caso de aplicaciones desarrolladas con el NDK para Android. Encontrará información completa en la Página de soporte para múltiples APK de Google, dentro del sitio de desarrolladores para Android.

Las siguientes sesiones se han creado específicamente para desarrolladores para Android que quieran empaquetar sus aplicaciones de manera que sean compatibles con dispositivos Android basados en x86:

Creación de múltiples APK

Si decide publicar varios APK, es probable que necesite crear proyectos Android separados para cada APK que tenga la intención de publicar, de modo que pueda desarrollarlos apropiadamente por separado. Hacerlo es muy sencillo: solo tiene que duplicar el proyecto que ya tenga y darle un nuevo nombre (otra opción es utilizar un sistema de compilación que pueda tener como salida diferentes recursos, como podrían ser texturas, de acuerdo con la configuración de compilación).

Sugerencia: una manera de evitar duplicar gran parte del código de la aplicación es usar un proyecto de biblioteca. Los proyectos de biblioteca contienen código y recursos compartidos que se pueden incluir en los proyectos de la aplicación en sí.

Cuando se crean varios proyectos para la misma aplicación, es recomendable identificar cada uno con un nombre que indique las restricciones que tendrá el APK relativas a dispositivos, para que se los pueda identificar con facilidad. Por ejemplo, "HelloWorld_8" podría ser un buen nombre para una aplicación creada para nivel 8 de API y superiores.

Atención: todos los APK que publique para la misma aplicación deben tener el mismo nombre de paquete y estar firmados con la misma clave de certificado. Asegúrese también de entender todas las reglas para múltiples APK.

Asignación de códigos de versión

Cada APK para la misma aplicación debe tener un código de versión único, especificado por el atributo android:versionCode. Hay que ser cuidadoso al asignar códigos de versión cuando se publican múltiples APK, porque cada uno debe ser distinto, pero en algunos casos, deben o deberían definirse en un orden específico, en función de las configuraciones que admita cada APK.

Ordenación de códigos de versión

Los APK que requieren un nivel de API superior deben tener, por lo general, un código de versión más alto. Por ejemplo, si crea dos APK para admitir niveles de API diferentes, el APK para los niveles más altos debe tener el código de versión más alto. Así se garantiza que si un dispositivo recibe una actualización de sistema que le posibilita instalar el APK para niveles de API superiores, el usuario reciba una notificación para actualizar la aplicación. Si desea saber más acerca de cómo se aplica este requisito, consulte la sección anterior sobre reglas para múltiples APK.

También hay que tener en cuenta cómo el orden de los códigos de versión podría afectar qué APK reciben los usuarios, ya sea por superposición de diferentes APK o por futuros cambios que se hagan a los APK.

Por ejemplo, si tiene diferentes APK para distintos tamaños de pantalla, como podría ser uno para pequeñas y normales y otro para grandes y extragrandes, pero prevé que en algún momento los cambiará de manera que haya uno para pantallas pequeñas y otro para normales a extragrandes, entonces el código de versión del APK para grandes y extragrandes debería ser más alto. Así, los dispositivos de tamaño normal recibirán la actualización apropiada cuando se efectúe el cambio, porque el código de versión aumenta del APK anterior al nuevo que ahora es compatible con el dispositivo.

Además, cuando se crean múltiples APK que difieren según su compatibilidad con diferentes formatos de compresión de texturas de OpenGL, hay que tener presente que muchos dispositivos admiten diversos formatos. Como los dispositivos reciben el APK con código de versión superior cuando se produce una superposición de cobertura entre dos APK, conviene ordenar los códigos de versión de modo tal que el APK con el formato de compresión preferido tenga el código más alto. Por ejemplo, se podrían realizar compilaciones separadas para la aplicación que usen los formatos de compresión PVRTC, ATITC y ETC1. Si este es el orden de preferencia de los formatos, entonces el APK que use PVRTC debería tener el código de versión más alto, el APK que use ATITC debería tener uno más bajo, y la versión con ETC1, el más bajo de los tres. De esta manera, si el dispositivo admite tanto PVRTC como ETC1, recibe el APK con PVRTC, porque es el que tiene el código de versión más alto.

Muchos dispositivos admiten también múltiples ABI; por ejemplo, ARMv7 y ARMv5TE. Muchos dispositivos ABI x86 también pueden ejecutar binarios ARMv7 y ARMv5TE. Los códigos de versión se deben ordenar de manera que en cada dispositivo se ejecute el APK de mejor rendimiento. Por ejemplo, podrían ordenarse de modo que el APK x86 tenga el código de versión más alto, seguido del ARMv7, y luego el ARMv5TE. De esta forma, el APK x86 será el preferido para dispositivos x86, y el APK ARMv7 lo será para los dispositivos ARMv7.

Uso de un esquema de códigos de versión

Con el fin de permitir que diferentes APK actualicen sus códigos de versión independientemente de otros (por ejemplo, para no tener que actualizar todos los APK cuando se corrigen errores en uno solo), hay que usar un esquema de códigos de versión que deje suficiente margen entre cada APK para poder aumentar el código en uno sin tener que hacerlo en los demás. También se debe incluir el nombre de la versión actual en el código (es decir, la versión visible para el usuario asignada a android:versionName), para que sea fácil relacionar el código de versión con el nombre de versión.

Atención: cuando se incrementa el código de versión para un APK, Google Play indica a los usuarios de las versiones anteriores que actualicen la aplicación. Por eso, para evitar actualizaciones innecesarias, no se debe incrementar el código de versión de los APK que no incluyan cambios.

Sugerimos usar un código de versión de al menos 8 cifras. Los enteros que representan las configuraciones admitidas están en los números de orden mayor, y el nombre de versión (de android:versionName) en los de orden menor. Por ejemplo, si el nombre de versión de la aplicación es 3.1.0, el código de versión para ABI ARMv7 y un APK de nivel 4 de API sería algo parecido a 20400310. Otro ejemplo: si el nombre de versión de la aplicación es 3.1.0, el código de versión para ABI x86 y un APK de nivel 11 de API sería algo similar a 61100310. La primera cifra indica la ABI admitida, la segunda y la tercera están reservadas para el nivel de API (4 y 11, respectivamente), la cuarta y la quinta son para tamaños de pantalla o formatos de textura GL (no se usan en estos ejemplos), y las últimas tres son para el nombre de versión de la aplicación (3.1.0). En la figura 1 se muestran dos ejemplos que se diferencian según la ABI, la versión de plataforma (nivel API) y el tamaño de pantalla. La clave para ABI es: 7 - x86_64, 6 - x86, 3 - ARM64-V8A, 2 - ARMv7, 1 - ARMv5TE.

Figura 1. Esquema sugerido para los códigos de versión. Se usa la primera cifra para la ABI, la segunda y la tercera para el nivel de API, la cuarta y la quinta para el tamaño de pantalla mínimo y máximo (cada tamaño se indica con los números 1 a 4) o para denotar los formatos de texturas, y las últimas tres para la versión de la aplicación. La clave para ABI es: 7 - x86_64, 6 - x86, 2 - ARMv7, 1 - ARMv5TE. Por ejemplo, el código de versión para ABI x86_64 y un APK de nivel 19 de API sería algo así como 71900310.

Este esquema es solo una sugerencia de cómo establecer un patrón que se pueda ir aumentando a medida que la aplicación evolucione. En particular, este esquema no muestra una solución para identificar diferentes formatos de compresión de texturas. Una opción sería definir una tabla propia que especifique un entero diferente para cada uno de los formatos de compresión que admita la aplicación (por ejemplo, 1 podría corresponder a ETC1, 2 a ATITC, y así continuaría).

Se puede utilizar cualquier esquema que uno quiera, pero se debe considerar cuidadosamente cómo se necesitará incrementar los códigos de versión para futuras versiones de la aplicación y cómo pueden recibir actualizaciones los dispositivos cuando cambia su configuración (podría ser debido a una actualización de sistema) o cuando se modifican las compatibilidades de uno o varios APK.