Para publicar tu app en Google Play, debes compilar y subir un Android App Bundle. Cuando lo haces, Google Play genera y publica automáticamente APK optimizados para la configuración del dispositivo de cada usuario, por lo que este solo debe descargar el código y los recursos que necesita para ejecutar tu app. Publicar varios APK es útil si no publicas en Google Play, pero debes compilar, firmar y administrar cada APK por tu cuenta.
La compatibilidad con múltiples APK es una función de Google Play que te permite publicar diferentes APK para tu aplicación orientados a diferentes configuraciones de dispositivos. Cada APK es una versión completa e independiente de tu aplicación, pero todos comparten la misma ficha de aplicaciones en Google Play y deben compartir el mismo nombre de paquete y estar firmados con la misma clave de lanzamiento. Esta función es útil para casos en los que tu aplicación no puede llegar a todos los dispositivos deseados con un solo APK.
Los dispositivos con Android pueden diferir de varias maneras, así que, para que tenga éxito, es importante que tu aplicación esté disponible en tantos dispositivos como sea posible. Las aplicaciones para Android generalmente se ejecutan en la mayoría de los dispositivos compatibles con un solo APK, proporcionando recursos alternativos para diferentes configuraciones (por ejemplo, diferentes diseños para diferentes tamaños de pantalla), y el sistema Android selecciona los recursos apropiados para el dispositivo en tiempo de ejecución. Sin embargo, en algunos casos, un solo APK no puede admitir todas las configuraciones de dispositivos, porque los recursos alternativos hacen que el archivo APK sea demasiado grande o existen otros desafíos técnicos que impiden que un solo APK funcione en todos los dispositivos.
Con el objetivo de ayudarte a publicar tu aplicación para la mayor cantidad de dispositivos posible, Google Play te permite publicar varios APK en la misma ficha de aplicaciones. Luego, Google Play proporciona cada APK a los dispositivos apropiados según la compatibilidad con la configuración que hayas declarado en el archivo de manifiesto de cada APK.
Si publicas tu aplicación con varios APK, puedes hacer lo siguiente:
- Admitir diferentes formatos de compresión de textura OpenGL con cada APK
- Admitir diferentes tamaños y densidades de pantalla con cada APK.
- Admitir diferentes conjuntos de funciones del dispositivo con cada APK.
- Admitir diferentes versiones de la plataforma con cada APK
- Admitir diferentes arquitecturas de CPU con cada APK (como para ARM o x86, cuando tu app usa el NDK de Android)
- Optimizar tu app para que funcione en dispositivos de nivel de entrada, como los que ejecutan Android (edición Go)
Actualmente, estas son las únicas características del dispositivo que Google Play admite para publicar varios APK como la misma aplicación.
Nota: Para obtener información sobre cómo preparar y publicar el APK en Google Play, consulta el artículo de asistencia Cómo preparar y lanzar versiones.
Cómo funciona el uso de varios APK
El concepto de usar varios APK en Google Play es que solo tienes una entrada en Google Play para tu aplicación, pero diferentes dispositivos pueden descargar un APK diferente. Esto significa lo siguiente:
- Mantienes un solo conjunto de detalles del producto (descripción de la aplicación, íconos, capturas de pantalla, etc.). Esto también significa que no puedes cobrar un precio diferente por los diferentes APK.
- Todos los usuarios ven solo una versión de tu aplicación en Google Play, de manera que no se confundirán si has publicado diferentes versiones "para tablets" y "para teléfonos".
- Todas las opiniones de los usuarios se aplican a la misma ficha de aplicaciones, aunque los usuarios que se encuentran en dispositivos diferentes pueden tener APK diferentes.
- Si publicas diferentes APK para diferentes versiones de Android (que tienen como objetivo diferentes niveles de API), cuando el dispositivo de un usuario recibe una actualización del sistema que lo califica para un APK diferente que publicaste, Google Play actualiza la aplicación del usuario al APK diseñado para la versión posterior de Android. Se conservan todos los datos del sistema asociados con la aplicación (lo mismo que con las actualizaciones normales de la aplicación cuando se usa un solo APK).
Filtros compatibles
Los dispositivos que reciben cada APK están determinados por los filtros de Google Play especificados por los elementos correspondientes al archivo de manifiesto de cada APK. Sin embargo, Google Play te permite publicar varios APK solo cuando cada APK usa filtros para admitir una variación de las siguientes características del dispositivo:
- Formatos de compresión de texturas OpenGL
Se basan en los elementos
<supports-gl-texture>de tu archivo de manifiesto.Por ejemplo, cuando desarrollas un juego que usa OpenGL ES, puedes proporcionar un APK para dispositivos compatibles con compresión de textura ATI y un APK independiente para dispositivos que admiten compresión PowerVR (entre muchos otros).
- Tamaño de pantalla (y, opcionalmente, densidad de la pantalla)
Se basa en el elemento
<supports-screens>o<compatible-screens>de tu archivo de manifiesto. Nunca debes usar ambos elementos y, cuando sea posible, solo debes usar<supports-screens>.Por ejemplo, puedes proporcionar un APK que admita pantallas pequeñas y de tamaño normal, y otro APK que admita pantallas grandes y extragrandes. Para obtener más información sobre cómo generar archivos APK independientes según el tamaño o la densidad de la pantalla, ve a Cómo compilar varios APK.
Ten en cuenta las siguientes prácticas recomendadas para todos los tamaños de pantalla:
- El sistema Android proporciona compatibilidad para aplicaciones que admiten todas las configuraciones de pantalla con un solo APK. Debes evitar crear varios APK para admitir pantallas diferentes, a menos que sea absolutamente necesario; en vez de eso, sigue la guía Compatibilidad con diferentes pantallas para que tu aplicación sea flexible y se pueda adaptar a todas las configuraciones de pantalla con un solo APK.
- De forma predeterminada, todos los atributos de tamaño de pantalla del elemento
<supports-screens>son "verdaderos" si no los declaras de otra manera. Sin embargo, debido a que se agregó el atributoandroid:xlargeScreensen Android 2.3 (API nivel 9), Google Play supondrá que es "falso" si tu aplicación no estableceandroid:minSdkVersionoandroid:targetSdkVersionen "9" o más. - No debes combinar elementos
<supports-screens>y<compatible-screens>en tu archivo de manifiesto. Si usas ambos, aumentan las posibilidades de que se produzca un error debido a conflictos entre ellos. Si necesitas ayuda para decidir cuál usar, lee Cómo distribuir a pantallas específicas. Si no puedes evitar usar ambos elementos, ten en cuenta que, en caso de cualquier conflicto de acuerdo entre un tamaño determinado, prevalecerá el valor "falso".
- Conjunto de atributos del dispositivo
Se basan en los elementos
<uses-feature>de tu archivo de manifiesto.Por ejemplo, puedes proporcionar un APK para dispositivos compatibles con multitoque y otro APK para dispositivos que no admitan esta opción. Consulta Referencia de funciones para obtener una lista de las funciones compatibles con la plataforma.
- Android (edición Go)
Para orientar los anuncios a dispositivos que ejecutan Android (edición Go), tu APK debe declarar
<uses-feature android:name="android.hardware.ram.low" android:required="true">, orientarse al menos al nivel de API 26 y tener un código de versión más alto que el del APK de la edición que no es Go. - Nivel de API
Se basa en el elemento
<uses-sdk>de tu archivo de manifiesto. Puedes usar los atributosandroid:minSdkVersionyandroid:maxSdkVersionpara especificar la compatibilidad con diferentes niveles de API.Por ejemplo, puedes publicar tu aplicación con un APK que admita los niveles 16 a 19 de la API (Android 4.1.x a 4.4.4) —solo mediante API disponibles desde la API nivel 16 o inferior— y otro APK que admita la API nivel 21 y los niveles superiores (Android 5.0+) mediante las API disponibles desde la API nivel 21 o inferior. Para obtener información sobre cómo compilar APK independientes que se orienten a un rango diferente de API, ve a Cómo configurar tipos de productos.
Si utilizas esta característica como factor para distinguir varios APK, el APK con un valor de
android:minSdkVersionmás alto debe tener un valor deandroid:versionCodemás alto. Esto también es válido si dos APK se superponen con la compatibilidad de tu dispositivo según un filtro admitido diferente. Esto garantiza que, cuando un dispositivo recibe una actualización del sistema, Google Play puede ofrecer al usuario una actualización para tu aplicación (porque las actualizaciones se basan en un aumento en el código de versión de la app). Este requisito se describe con más detalle en la siguiente sección sobre Reglas para varios APK.Debes evitar el uso de
android:maxSdkVersionen general, porque, si has desarrollado adecuadamente tu aplicación con API públicas, siempre será compatible con futuras versiones de Android. Si deseas publicar un APK diferente para niveles de API más altos, no necesitas especificar la versión máxima, ya que, si el valor deandroid:minSdkVersiones"16"en un APK y"21"en otro, los dispositivos que admitan la API nivel 21 o una versión superior siempre recibirán el segundo APK (porque su código de versión es superior, según la nota anterior). - Arquitectura de CPU (ABI)
Algunas bibliotecas nativas proporcionan paquetes separados para arquitecturas de CPU específicas o interfaces binarias de aplicaciones (ABI). En lugar de empaquetar todas las bibliotecas disponibles en un APK, puedes compilar un APK separado para cada ABI e incluir solo las bibliotecas que necesitas para esa ABI. Si quieres obtener más información sobre la generación de APK independientes basados en la ABI objetivo, ve a Cómo compilar varios APK.
Otros elementos de manifiesto que habilitan los filtros de Google Play (pero no se mencionaron anteriormente) se siguen aplicando para cada APK como siempre. Sin embargo, Google Play no te permite publicar APK independientes según las variaciones de esas características del dispositivo. Por lo tanto, no puedes publicar varios APK si los filtros enumerados anteriormente son los mismos para cada APK (pero los APK difieren en función de otras características en el manifiesto o APK). Por ejemplo, no puedes proporcionar APK diferentes que difieran únicamente en las características de <uses-configuration>.
Reglas para varios APK
Antes de publicar varios APK de tu aplicación, debes comprender las siguientes reglas:
- Todos los APK que publiques para la misma aplicación deben tener el mismo nombre de paquete y estar firmados con la misma clave de certificado.
- Cada APK debe tener un código de versión diferente, especificado por el atributo
android:versionCode. - Cada APK no debe coincidir exactamente con la compatibilidad de configuración de otro APK.
Es decir, cada APK debe declarar una compatibilidad ligeramente diferente para al menos uno de los filtros de Google Play compatibles (indicados anteriormente).
Por lo general, diferenciarás tus APK en función de una característica específica (como los formatos de compresión de textura compatibles) y, por lo tanto, cada APK declarará la compatibilidad con diferentes dispositivos. Sin embargo, es correcto publicar varios APK que se superpongan ligeramente con su compatibilidad. Cuando dos APK se superponen (admiten algunas de las mismas configuraciones de dispositivo), un dispositivo que se encuentre dentro de ese rango recibirá el APK con un código de versión superior (definido por
android:versionCode). - No puedes activar un APK nuevo que tenga un código de versión inferior al del APK que está reemplazando. Por ejemplo, supongamos que tienes un APK activo para tamaños de pantalla de pequeño a normal con el código de versión
0400; luego, intentas reemplazarlo por un APK para los mismos tamaños de pantalla con el código de versión0300. Esto genera un error, porque significa que los usuarios del APK anterior no podrán actualizar la aplicación. - Un APK que requiere un nivel de API más alto debe tener un código de versión más alto.
Esto es cierto solo cuando los APK difieren únicamente en los niveles de API compatibles (ningún otro filtro compatible distingue los APK entre sí) o cuando los APK usan otro filtro compatible, pero hay una superposición entre los APK dentro de ese filtro.
Esto es importante porque el dispositivo del usuario recibe una actualización de la aplicación de Google Play solo si el código de versión del APK que está en Google Play es superior al código de versión del APK que está en ese momento en el dispositivo. Esto garantiza que, si un dispositivo recibe una actualización del sistema que cumple los requisitos para instalar el APK en niveles superiores de la API, el dispositivo recibe una actualización de la aplicación porque aumenta el código de versión.
Nota: El tamaño del aumento del código de versión es irrelevante; simplemente necesita ser más grande en la versión que admite niveles de API más altos.
Estos son algunos ejemplos:
- Si un APK subido para la API nivel 16 y superiores (Android 4.1.x+) tiene un código de versión de
0400, un APK para la API nivel 21 y superiores (Android 5.0+) debe ser0401o mayor. En este caso, el nivel de API es el único filtro compatible utilizado, por lo que los códigos de versión deben aumentar en correlación con la compatibilidad de nivel de API para cada APK de modo que los usuarios obtengan una actualización cuando reciban una actualización del sistema. - Si tienes un APK que es para la API nivel 16 (y niveles superiores) y para pantallas de pequeñas a grandes, y otro APK para la API nivel 21 (y niveles superiores) y pantallas grandes y extragrandes, los códigos de versión deben aumentar en correlación con los niveles de API. En este caso, el filtro de nivel de API se utiliza para distinguir cada APK, pero lo mismo ocurre con el tamaño de la pantalla. Debido a que los tamaños de pantalla se superponen (ambos APK admiten pantallas grandes), los códigos de versión deben estar en orden. Esto garantiza que un dispositivo de pantalla grande que reciba una actualización del sistema a la API nivel 21 recibirá una actualización para el segundo APK.
- Si tienes un APK para la API nivel 16 (y niveles superiores) y para pantallas de pequeñas a grandes, y otro APK para la API nivel 21 (y superiores) y pantallas grandes y extragrandes, los códigos de versión no necesitan aumentar en correlación con los niveles de API. Debido a que no hay superposición dentro del filtro de tamaño de pantalla, no hay dispositivos que puedan moverse potencialmente entre estos dos APK, por lo que no es necesario que los códigos de versión aumenten del nivel de API más bajo al nivel de API más alto.
- Si tienes un APK para la API nivel 16 (y niveles superiores) y CPU ARMv7, y otro APK para la API nivel 21 (y niveles superiores) y CPU ARMv5TE, los códigos de versión deben aumentar en correlación con los niveles de API. En este caso, se usa el filtro de nivel de API para distinguir cada APK, pero también se usa la arquitectura de la CPU. Debido a que un APK con bibliotecas ARMv5TE es compatible con dispositivos que tienen una CPU ARMv7, los APK se superponen en esta característica. Como tal, el código de versión para el APK que admite la API nivel 21 y niveles superiores debe ser más alto. Esto garantiza que un dispositivo con una CPU ARMv7 que reciba una actualización del sistema a la API nivel 21 recibirá una actualización para el segundo APK diseñado para la API nivel 21. Sin embargo, como este tipo de actualización hace que el dispositivo ARMv7 use un APK que no está completamente optimizado para la CPU de ese dispositivo, debes proporcionar un APK tanto para la arquitectura ARMv5TE como para la arquitectura ARMv7 en cada nivel de API a fin de optimizar el rendimiento de la app en cada CPU. Nota: Esto solo se aplica cuando se comparan APK con bibliotecas ARMv5TE y ARMv7, y no cuando se comparan otras bibliotecas nativas.
- Si un APK subido para la API nivel 16 y superiores (Android 4.1.x+) tiene un código de versión de
Si no cumples con las reglas anteriores, se producirá un error en Google Play Console cuando actives los APK. No podrás publicar la aplicación hasta que resuelvas el error.
Existen otros conflictos que pueden ocurrir cuando activas tus APK, pero que darán como resultado advertencias en lugar de errores. Las advertencias pueden deberse a lo siguiente:
- Cuando modificas un APK para "reducir" la compatibilidad con las características de un dispositivo y ningún otro APK admite los dispositivos que luego quedan fuera del rango admitido. Por ejemplo, si un APK actualmente admite pantallas pequeñas y de tamaño normal y lo cambias para admitir solo pantallas pequeñas, habrás reducido el grupo de dispositivos compatibles y algunos dispositivos ya no verán tu aplicación en Google Play. Para resolver este problema, agrega otro APK que admita pantallas de tamaño normal de modo que todos los dispositivos que antes eran compatibles sigan siéndolo.
- Cuando hay "superposiciones" entre dos o más APK. Por ejemplo, si un APK admite tamaños de pantalla pequeños, normales y grandes, mientras que otro APK admite tamaños grandes y extragrandes, hay una superposición, porque ambos APK admiten pantallas grandes. Si no resuelves esto, los dispositivos que cumplan los requisitos para ambos APK (dispositivos de pantalla grande en el ejemplo) recibirán el APK que tenga el código de versión más alto.
Nota: Si creas APK independientes para diferentes arquitecturas de CPU, ten en cuenta que un APK para ARMv5TE se superpondrá con un APK para ARMv7. Es decir, un APK diseñado para ARMv5TE es compatible con un dispositivo ARMv7, pero no sucede lo contrario (un APK con bibliotecas de ARMv7 solamente no es compatible con un dispositivo ARMv5TE).
Cuando se produzca ese tipo de conflicto, verás un mensaje de advertencia, pero podrás publicar tu aplicación de todos modos.
Cómo crear varios APK
Una vez que decidas publicar varios APK, probablemente debas crear proyectos de Android separados para cada APK que quieras publicar de modo que puedas desarrollarlos de manera independiente. Para ello, simplemente puedes duplicar tu proyecto existente y darle un nuevo nombre. (Como alternativa, usa un sistema de compilación que pueda generar diferentes recursos, como texturas, según la configuración de compilación).
Sugerencia: Una forma de evitar la duplicación de grandes porciones del código de tu aplicación es utilizar un proyecto de biblioteca. Un proyecto de biblioteca contiene código compartido y recursos, que puedes incluir en tus proyectos de aplicación reales.
Cuando creas varios proyectos para la misma aplicación, se recomienda identificar cada uno con un nombre que indique las restricciones del dispositivo que se colocarán en el APK con el objetivo de identificarlos fácilmente. Por ejemplo, "HelloWorld_21" podría ser un buen nombre para una aplicación diseñada para la API nivel 21 y los niveles superiores.
Nota: Todos los APK que publiques para la misma aplicación deben tener el mismo nombre de paquete y estar firmados con la misma clave de certificado. Asegúrate de comprender también cada una de las reglas para el uso de varios APK.
Asigna códigos de versión
Cada APK de la misma aplicación debe tener un código de versión único, especificado por el atributo android:versionCode. Debes tener cuidado cuando asignas códigos de versión al publicar varios APK, ya que deben ser diferentes, pero en algunos casos deben o podrían definirse en un orden específico según las configuraciones que admita cada APK.
Pide códigos de versión
Un APK que requiere un nivel de API más alto debe tener, en general, un código de versión más alto. Por ejemplo, si creas dos APK para admitir diferentes niveles de API, el APK para los niveles de API más altos debe tener el código de versión más alto. Esto garantiza que, si un dispositivo recibe una actualización del sistema que lo hace cumplir los requisitos para instalar el APK para niveles superiores de API, el usuario recibe una notificación de actualización de la aplicación. Si quieres obtener más información sobre cómo se aplica este requisito, consulta la sección anterior sobre Reglas para el uso de varios APK.
También debes considerar el modo en que el orden de los códigos de versión puede afectar los APKs que reciben tus usuarios, ya sea debido a la superposición entre la cobertura de diferentes APKs o los cambios futuros que puedas realizar en tus APKs.
Por ejemplo, si tienes diferentes APKs basados en el tamaño de la pantalla, como uno para pantallas de pequeñas a normales y otro para pantallas de grandes a extragrandes, pero prevés un momento en el que cambiarán los APKs para que sean uno para pantallas pequeñas y otro para pantallas de normales a extragrandes, entonces deberías hacer que el código de versión para el APK de pantallas grandes a extragrandes sea más alto. De esta manera, un dispositivo de tamaño normal recibirá la actualización correspondiente cuando realices el cambio, ya que el código de versión aumenta desde el APK existente al APK nuevo que ahora admite el dispositivo.
Además, cuando crees varios APK que difieran según el soporte para diferentes formatos de compresión de textura OpenGL, ten en cuenta que muchos dispositivos admiten múltiples formatos. Debido a que un dispositivo recibe el APK con el código de versión más alto cuando hay una superposición en la cobertura entre dos APK, debes solicitar los códigos de versión entre tus APK para que el APK con el formato de compresión preferido tenga el código de versión más alto. Por ejemplo, es posible que desees realizar compilaciones independientes para tu app mediante los formatos de compresión PVRTC, ATITC y ETC1. Si prefieres estos formatos en este orden exacto, el APK que usa PVRTC debe tener el código de versión más alto, el APK que usa ATITC tiene un código de versión inferior y la versión con ETC1 tiene el código más bajo. Por lo tanto, si un dispositivo es compatible con PVRTC y ETC1, recibe el APK con PVRTC, ya que este tiene el código de versión más alto.
En caso de que Google Play Store no pueda identificar el APK correcto que se debe instalar para un dispositivo de destino, es posible que también desees crear un APK universal que incluya recursos para todas las diferentes variaciones de dispositivos que desees admitir. Si proporcionas un APK universal, debes asignarle el versionCode más bajo. Debido a que Google Play Store instala la versión de tu aplicación que es compatible con el dispositivo de destino y tiene el elemento versionCode con valor más alto, asignar un elemento versionCode con valor más bajo al APK universal garantiza que Google Play Store intente instalar uno de sus otros APK antes de recurrir al APK universal más grande.
Usa un esquema de código de versión
Para permitir que diferentes APK actualicen sus códigos de versión de forma independiente de los demás (por ejemplo, cuando corriges un error en un solo APK y no necesitas actualizar todos los APK), debes usar un esquema para tus códigos de versión que proporcione espacio suficiente entre cada APK de manera que pueda aumentar el código en uno sin requerir un aumento en los demás. También debes incluir el nombre de versión real en el código (es decir, la versión visible para el usuario asignada a android:versionName) de modo que sea fácil asociar el código de versión y el nombre de la versión.
Nota: Cuando aumentes el código de versión de un APK, Google Play solicitará a los usuarios de la versión anterior que actualicen la aplicación. Por lo tanto, a fin de evitar actualizaciones innecesarias, no debes aumentar el código de versión para los APK que en realidad no incluyen cambios.
Te sugerimos que uses un código de versión con al menos 7 dígitos: los números enteros que representan las configuraciones compatibles están en los bits de orden superior y el nombre de la versión (de android:versionName). Por ejemplo, cuando el nombre de la versión de la aplicación es 3.1.0, los códigos de versión para una API nivel 4 y una API nivel 11 serán similares a 0400310 y 1100310, respectivamente. Los primeros dos dígitos están reservados para el nivel de API (4 y 11, respectivamente). Los dos dígitos intermedios corresponden a tamaños de pantalla o formatos de textura GL (no se usan en estos ejemplos). Los últimos tres dígitos corresponden al nombre de la versión de la aplicación (3.1.0). En la figura 1, se muestran dos ejemplos que se dividen en función de la versión de la plataforma (nivel de API) y el tamaño de la pantalla.
Figura 1: Un esquema sugerido para tus códigos de versión, con los dos primeros dígitos para el nivel de API y el segundo y tercer dígito para el tamaño mínimo y máximo de pantalla (1 a 4 para indicar cada uno de los cuatro tamaños) o para indicar los últimos tres dígitos de la versión de la app
Este esquema para códigos de versión es solo una sugerencia de cómo debes establecer un patrón que sea escalable a medida que evoluciona tu aplicación. En particular, este esquema no demuestra una solución para identificar diferentes formatos de compresión de textura. Una opción podría ser definir tu propia tabla que especifique un número entero diferente para cada uno de los diferentes formatos de compresión que admita tu aplicación (por ejemplo, 1 podría corresponder a ETC1, 2 a ATITC, y así sucesivamente).
Puedes usar cualquier esquema que desees, pero debes considerar cuidadosamente cómo las futuras versiones de tu aplicación necesitarán aumentar tus códigos de versión y cómo los dispositivos pueden recibir actualizaciones cuando cambia su configuración (por ejemplo, debido a una actualización del sistema) o cuando modificas la compatibilidad de configuración para uno o varios APK.