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.
Cuando desarrolles tu aplicación para Android con el objetivo de aprovechar varios APK en Google Play, es importante que adoptes algunas prácticas recomendadas desde el principio y evites dolores de cabeza innecesarios en el proceso de desarrollo. En esta lección, se muestra cómo crear varios APK de tu app, de modo que cada uno cubra un rango levemente distinto de niveles de API. También obtendrás algunas herramientas necesarias para que el mantenimiento de una base de código APK múltiple sea lo más sencillo posible.
Cómo confirmar que necesitas varios APK
Cuando intentas crear una aplicación que funcione en varias generaciones de la plataforma de Android, es natural que busques que la app aproveche las funciones nuevas en dispositivos nuevos, sin sacrificar la retrocompatibilidad. Al principio, puede parecer que la compatibilidad con varios APK es la mejor solución, pero a menudo este no es el caso. La sección Cómo usar un solo APK de la guía para desarrolladores de varios APK contiene información útil sobre cómo lograrlo con un solo APK, incluido el uso de nuestra biblioteca de compatibilidad. En este artículo, también puedes aprender a escribir códigos que se ejecuten solo en algunos niveles de API en un solo APK, sin recurrir a técnicas de procesamiento costosas en términos de procesamiento, como la reflexión.
Si puedes administrarla, limitar tu aplicación a un solo APK tiene varias ventajas, entre las que se incluyen las siguientes:
- Es más fácil realizar publicaciones y pruebas.
- Solo hay que mantener una base de código.
- Tu app se puede adaptar a los cambios de configuración del dispositivo.
- Funciona el restablecimiento de apps en dispositivos.
- No tienes que preocuparte por la preferencia del mercado, por el comportamiento de las "actualizaciones" de un APK al siguiente, o por el APK adecuado para cada clase de dispositivos.
En el resto de esta lección, se supone que investigaste el tema, absorbiste detenidamente el material de los recursos vinculados y determinaste que varios APK son la ruta correcta para tu aplicación.
Cómo organizar tus requisitos
Para comenzar, crea un gráfico simple para determinar rápidamente cuántos APK necesitas y qué rango de API cubre cada APK. Como referencia práctica, la página Versiones de la plataforma del sitio web para desarrolladores de Android proporciona datos sobre el número relativo de dispositivos activos que ejecutan una versión determinada de la plataforma de Android. Además, aunque suene fácil al principio, realizar un seguimiento del conjunto de niveles de API que cada APK va a orientar pronto se vuelve muy difícil, en especial si habrá cierta superposición (lo que sucede con frecuencia). Por suerte, es fácil organizar tus requisitos de manera rápida y sencilla, y tener una referencia fácil para más adelante.
Para crear tu gráfico de varios APK, comienza con una fila de celdas que represente los diversos niveles de API de la plataforma de Android. Agrega una celda adicional al final para representar versiones futuras de Android.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Ahora solo debes colorear el gráfico de manera que cada color represente un APK. Este es un ejemplo de cómo puedes aplicar cada APK a un determinado rango de niveles de API.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Una vez que crees este gráfico, distribúyelo entre tu equipo. La comunicación con el equipo del proyecto ahora es más simple, ya que, en lugar de preguntar: "¿Cómo está el APK de los niveles 3 a 6 de la API, ya saben, Android 1.x? ¿Cómo va todo?", Solo tienes que decir "¿Cómo viene el APK azul?".
Cómo colocar todos los recursos y el código común en un proyecto de biblioteca
Si vas a modificar una app para Android existente o comenzar una desde cero, esto es lo primero, y lo más importante, que deberías hacer con la base de código base. Todo lo que entra en el proyecto de biblioteca solo debe actualizarse una vez (piensa en cadenas localizadas para el idioma, temas de color, errores corregidos en el código compartido), lo que mejora el tiempo de desarrollo y reduce la probabilidad de errores que podrían haberse evitado fácilmente.
Nota: Si bien los detalles de la implementación sobre cómo crear e incluir proyectos de biblioteca están fuera del alcance de esta lección, puedes consultar Cómo crear una biblioteca de Android para obtener más información.
Si estás convirtiendo una aplicación existente para usar la compatibilidad con varios APK, examina tu base de código en busca de todos los archivos de cadenas localizadas, listas de valores, colores de tema, íconos de menú y diseños que no vas a cambiar entre los APK, y pon todo en el proyecto de la biblioteca. El código que no cambiará mucho también debe ir en el proyecto de biblioteca. Es probable que estés extendiendo estas clases para agregar uno o dos métodos de un APK a otro.
Si, por el contrario, vas a crear la aplicación desde cero, primero intenta escribir el código en el proyecto de la biblioteca y, luego, transfiérelo a un APK individual, si es necesario. Esto es mucho más fácil de administrar a largo plazo que agregar código a uno, luego a otro y a otro, y meses más tarde intentas averiguar si se puede transferir este BLOB a la biblioteca sin arruinar nada.
Cómo crear nuevos proyectos de APK
Debe haber un proyecto de Android por separado para cada APK que vas a publicar. Para facilitar la organización, coloca el proyecto de biblioteca y todos los proyectos de APK relacionados en la misma carpeta superior. Además, recuerda que cada APK debe tener el mismo nombre de paquete, aunque no necesariamente deben compartir el nombre del paquete con la biblioteca. Si tuvieras 3 APK que siguen el esquema descrito anteriormente, tu directorio raíz podría verse de la siguiente manera:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-red
Una vez que se creen los proyectos, agrega el proyecto de la biblioteca como referencia para cada proyecto de APK. Si es posible, define tu actividad inicial en el proyecto de biblioteca y extiende esa actividad en tu proyecto de APK. Tener una actividad inicial definida en el proyecto de biblioteca te da la oportunidad de colocar toda la inicialización de tu aplicación en un solo lugar, para que cada APK no tenga que volver a implementar tareas "universales", como inicializar Analytics, ejecutar verificaciones de licencia y cualquier otro procedimiento de inicialización que no cambie mucho de un APK a otro.
Cómo ajustar los manifiestos
Cuando un usuario descarga una app que usa varios APK mediante Google Play, el APK correcto que se usará se elige según dos reglas simples:
- El manifiesto tiene que mostrar que un APK en particular es apto.
- De los APK aptos, se da prioridad al que tiene el número de versión más alto.
A modo de ejemplo, tomemos el conjunto de varios APK descritos anteriormente y supongamos que no establecimos un nivel de API máximo para ninguno de los APK. Tomado de forma individual, el rango posible de cada APK tendría el siguiente aspecto:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Debido a que es obligatorio que un APK con una minSdkVersion más alta también tenga un código de versión más alto, sabemos que, en términos de valores de versionCode, rojo ≥ verde ≥ azul. Por lo tanto, podemos contraer con eficacia el gráfico para que tenga el siguiente aspecto:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Ahora, supongamos que el APK rojo tiene algunos requisitos que los otros dos no tienen. En la página Filtros en Google Play de la guía para desarrolladores de Android, se incluye una lista completa de posibles culpables. A modo de ejemplo, supongamos que el rojo requiere una cámara frontal. De hecho, el objetivo completo del APK rojo es combinar la cámara frontal con una nueva funcionalidad que se agregó en la API 11. Pero resulta que no todos los dispositivos compatibles con la API 11 tienen cámaras frontales. ¡Terror!
Afortunadamente, si un usuario explora Google Play desde uno de esos dispositivos, Google Play observará el manifiesto, verá que Red incluye la cámara frontal como un requisito y la ignorará en silencio, ya que determinó que Red y ese dispositivo no son una combinación perfecta en el cielo digital. Verás que el color verde no solo es compatible con dispositivos con API 11 (ya que no se definió maxSdkVersion), sino que no le importa si hay o no una cámara frontal. El usuario aún puede descargar la app de Google Play, porque a pesar del contratiempo con la cámara frontal, todavía había un APK que admitía ese nivel de API en particular.
Para mantener todos los APK en "pistas" distintas, es importante tener un buen esquema de código de versión. Se recomienda usar el que se encuentra en el área Códigos de versión de nuestra guía para desarrolladores. Como el conjunto de ejemplos de APK solo abarca una de 3 dimensiones posibles, basta con separar cada APK por 1, 000, establecer los primeros dos dígitos en la minSdkVersion de ese APK en particular y aumentar a partir de allí. El aspecto podría ser el siguiente:
Azul: 03001, 03002, 03003, 03004…
Verde: 07001, 07002, 07003, 07004…
Rojo:11001, 11002, 11003, 11004...
Cuando se junta todo, es probable que los manifiestos de Android se vean así:
Azul:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="03001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
...
Verde:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="07001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="7" />
...
Rojo:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="11001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
...
Cómo revisar tu lista de tareas previa al lanzamiento
Antes de subir tu proyecto a Google Play, verifica los siguientes elementos. Recuerda que estos son solo pertinentes para varios APK, y de ninguna manera representan una lista de tareas completa para todas las apps que se suben a Google Play.
- Todos los APK deben tener el mismo nombre de paquete.
- Todos los APK deben estar firmados con el mismo certificado.
- Si los APK se superponen en la versión de la plataforma, el que tenga la minSdkVersion más alta debe tener un código de versión más alto.
- Comprueba que los filtros de manifiesto no tengan información contradictoria (a un APK que solo admita Cupcake en las pantallas extragrandes no lo verá nadie).
- El manifiesto de cada APK debe ser único en al menos una de las pantallas, texturas de OpenGL o versiones de plataforma compatibles.
- Intenta probar cada APK en al menos un dispositivo. Salvo eso, tienes uno de los emuladores de dispositivos más personalizables de la industria en tu máquina de desarrollo. ¡Disfruta a lo grande!
También vale la pena inspeccionar el APK compilado antes de lanzarlo al mercado para asegurarte de que no haya sorpresas que puedan ocultar tu aplicación en Google Play. Esto es bastante simple con la herramienta "aapt". Aapt (Android Asset Packaging Tool) forma parte del proceso de compilación para crear y empaquetar tus aplicaciones para Android, y también es una herramienta muy útil para inspeccionarlas.
>aapt dump badging package: name='com.example.hello' versionCode='1' versionName='1.0' sdkVersion:'11' uses-permission:'android.permission.SEND_SMS' application-label:'Hello' application-icon-120:'res/drawable-ldpi/icon.png' application-icon-160:'res/drawable-mdpi/icon.png' application-icon-240:'res/drawable-hdpi/icon.png' application: label='Hello' icon='res/drawable-mdpi/icon.png' launchable-activity: name='com.example.hello.HelloActivity' label='Hello' icon='' uses-feature:'android.hardware.telephony' uses-feature:'android.hardware.touchscreen' main supports-screens: 'small' 'normal' 'large' 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
Cuando examines el resultado de aapt, asegúrate de verificar que no tengas valores en conflicto para supports-screens y compatible-screens, y que no tengas valores "uses-feature" no deseados que se hayan agregado como resultado de los permisos que estableciste en el manifiesto. En el ejemplo anterior, el APK no será visible para muchos dispositivos.
¿Por qué? Cuando agregas el permiso necesario SEND_SMS, se agregó de manera implícita el requisito de función de android.hardware.telephony. Dado que la API 11 es Honeycomb (la versión de Android optimizada específicamente para tablets) y ningún dispositivo Honeycomb tiene hardware de telefonía, Google Play filtrará este APK en todos los casos, hasta que aparezcan futuros dispositivos que tengan un nivel de API superior y hardware de telefonía.
Por suerte, esto se soluciona fácilmente si agregas lo siguiente en el manifiesto:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
También se agrega de forma implícita el requisito android.hardware.touchscreen. Si quieres que el APK sea visible en TVs sin pantalla táctil, debes agregar lo siguiente en el manifiesto:
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
Cuando completes la lista de tareas previa al lanzamiento, sube los APK a Google Play. Es posible que la app demore un poco en aparecer cuando navegas por Google Play. Cuando aparezca, realiza una última comprobación. Descarga la app en cualquier dispositivo de prueba para asegurarte de que los APK estén orientados a los dispositivos previstos. ¡Felicitaciones! Eso es todo.