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 múltiples APK en Google Play, Es importante adoptar algunas prácticas recomendadas desde el principio y evitar dolores de cabeza innecesarios en el proceso de desarrollo. En esta lección, se muestra cómo crear varios APK de tu app, cada una abarca una clase diferente de tamaño de pantalla. También obtendrás algunas herramientas necesarias para hacen que mantener 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 app que funciona en una amplia variedad de opciones de Android naturalmente, querrás que tu aplicación se vea lo mejor posible en cada dispositivo individual. Deseas aprovechar el espacio de las pantallas grandes, pero seguir trabajando en las pequeñas, para usar la nueva API de Android características o texturas visuales disponibles en dispositivos de última generación, pero no abandonan los más antiguos. Puede parece al principio que la compatibilidad con varios APK es la mejor solución, pero a menudo esta no es la para determinar si este 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, incluso sobre el uso de nuestra biblioteca de compatibilidad y los vínculos a recursos en la Guía para desarrolladores de Android.
Si puedes administrarla, limitar tu app 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 tiene que preocuparse por la preferencia del mercado ni por el comportamiento de las "actualizaciones". de un APK a la a continuación, o qué APK corresponde a qué clase de dispositivos
En el resto de esta lección, se supone que investigaste el tema y aprendiste material en los recursos vinculados y determinaste que múltiples APK son la ruta correcta para tu y mantener la integridad de su aplicación.
Cómo organizar tus requisitos
Comienza creando un gráfico simple para determinar rápidamente cuántos APKs necesitas y qué pantalla del tamaño que cubre cada APK. Por suerte, es fácil organizar tus requisitos de manera rápida, sencilla y tener una referencia fácil para más adelante. Supongamos que quieres dividir tus APK en dos dimensiones: API y el tamaño de la pantalla. Crear una tabla con una fila y columna para cada par de valores posible y un color en algunos "BLOB", cada color representa un APK.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| Pequeño | |||||||||||
| Normal | |||||||||||
| Grande | |||||||||||
| Extragrande |
Arriba se muestra un ejemplo con cuatro APK. El azul es para todos los dispositivos con pantalla pequeña o normal, y el verde es para los más grandes. dispositivos con pantalla grande, y el rojo es para dispositivos con pantallas extragrandes, todos con un rango de API de 3 a 10. El morado es un un caso especial, ya que es para todos los tamaños de pantalla, pero solo para el nivel de API 11 y versiones posteriores. Lo que es más importante, con solo mirar este gráfico sabrás inmediatamente qué APK cubre cada combinación de API/tamaño de pantalla. Para también tienes nombres internos elegantes para cada uno, ya que "¿Ya probamos el rojo en el es mucho es más fácil preguntarle a tu mascota que "¿Ya probamos el APK extragrande de 3 a 10 en el Xoom?". Imprimir esto y entrégaselo a cada persona que trabaje en su base de código. Ahora la vida es mucho más simple.
Cómo colocar todos los recursos y el código común en un proyecto de biblioteca
Ya sea que estés modificando una aplicación para Android existente o iniciando una desde cero, esto es lo primero que deberías hacer en la base de código y, por mucho, lo más importante. Solo se necesita actualizar una vez todo lo que entra en el proyecto de biblioteca (como cadenas localizadas para diferentes idiomas, temas de color, corrección de errores en el código compartido). De esa forma, mejorará el tiempo de desarrollo y habrá menos errores que podrían haberse evitado fácilmente.
Nota: Si bien los detalles de la implementación sobre cómo crear y incluir proyectos de biblioteca están fuera del alcance de esta lección, puedes ponerte al día Consulta Cómo crear una biblioteca de Android.
Si quieres convertir una aplicación existente para utilizar la compatibilidad con varios APK, haz lo siguiente: busca en tu base de código cada archivo de cadena localizado, lista de valores, tema los colores, los íconos de menú y el diseño que no cambiará de un APK a otro, en el proyecto de biblioteca. El código que no cambiará mucho debería también van en el proyecto de biblioteca. Probablemente descubras que extiendes estas para agregar uno o dos métodos de APK a APK.
Si, en cambio, estás creando la app 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 agregarlo a uno meses después, para averiguar si el BLOB se puede mover hacia arriba a la sección de la biblioteca sin atornillar nada.
Cómo crear nuevos proyectos de APK
Debe haber un proyecto de Android por separado para cada APK que vas a publicar. Para organizarte de manera sencilla, coloca el proyecto de la biblioteca y todos los proyectos de APK relacionados en la misma carpeta principal. Además, recuerda que cada APK debe tener el mismo nombre de paquete, aunque no necesariamente el nombre del paquete con la biblioteca. Si tuvieras 3 APK siguiendo el esquema que se describió antes, el directorio raíz podría tener el siguiente formato:
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-purple foo-red
Una vez que se creen los proyectos, agrega el proyecto de la biblioteca como referencia para cada proyecto de APK. Si posible, definir tu actividad inicial en el proyecto de biblioteca y extender esa actividad en tu APK en un proyecto final. Tener una actividad inicial definida en el proyecto de biblioteca te da la oportunidad de colocar la inicialización de tu aplicación en un solo lugar, para que no sea necesario que cada APK individual volver a implementar la estrategia “universal” tareas como inicializar Analytics, ejecutar verificaciones de licencias y cualquier otra procedimientos de inicialización que no cambian 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 cada APK se configuró para admitir todos los tamaños de pantalla más grandes que su tamaño de pantalla "objetivo". Veamos el gráfico de muestra anterior:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| Pequeño | |||||||||||
| Normal | |||||||||||
| Grande | |||||||||||
| Extragrande |
Como está bien que la cobertura se superponga, podemos describir el área que cubre cada APK de la siguiente manera: entonces:
- El azul cubre todas las pantallas, minSDK 3.
- El verde cubre pantallas Grandes y Extragrandes, minSDK 3.
- El rojo cubre pantallas Extragrandes (generalmente tabletas), minSDK de 9.
- El morado cubre todas las pantallas, minSDK de 11.
Ten en cuenta que hay muchas superposiciones en estas reglas. Por ejemplo, un Un dispositivo Extragrande con API 11 puede ejecutar cualquiera de los 4 APK especificados. Sin embargo, si usas el “número de versión más alto, gana” podemos establecer un orden de preferencia de la siguiente manera:
Morado ≥ Rojo ≥ Verde ≥ Azul
¿Por qué permitir todas las superposiciones? Supongamos que el APK púrpura tiene algún requisito que otras dos no. La página Filtros en Google Play de la guía para desarrolladores de Android contiene una lista completa de posibles culpables. A modo de ejemplo, supongamos que el morado requiere una cámara frontal. De hecho, el objetivo del morado es usa cosas entretenidas con la cámara frontal. Sin embargo, resulta que no todos los dispositivos con API 11 o versiones posteriores ¡incluso TENEMOS cámaras frontales! ¡Qué mal!
Afortunadamente, si un usuario explora Google Play desde uno de esos dispositivos, Google Play buscará la ve que Purple incluye la cámara frontal como un requisito e ignórala en silencio, que el Púrpura y ese dispositivo no son una combinación perfecta en el cielo digital. Verá que Rojo no solo es compatible con los dispositivos extragrandes, sino que también no importa si hay una cámara frontal. El usuario aún puede descargar la app de Google Play porque a pesar del contratiempo de la cámara frontal, todavía había un APK que admitía ese Nivel de API.
Para mantener todos los APK en "pistas" distintas, es importante tener un buen esquema de código de versión. El recomendado se puede encontrar en el área Códigos de versión de nuestra guía para desarrolladores. Vale la pena leer toda la sección, pero lo esencial es este conjunto de En los APK, usaríamos dos dígitos para representar el minSDK, dos para representar el tamaño de pantalla mínimo y máximo, y 3. para representar el número de compilación. De esa manera, cuando el dispositivo se actualice a una nueva versión de Android, (por ejemplo, de 10 a 11), cualquier APK que ahora sea apto y tenga prioridad sobre el que está instalado actualmente el dispositivo la consideraría una "actualización". El esquema de número de versión, cuando se aplica al conjunto de ejemplos de APK, podría tener el siguiente aspecto:
Azul: 0304001, 0304002, 0304003…
Verde: 0334001, 0334002, 0334003
Rojo: 0344001, 0344002, 0344003…
Púrpura: 1104001, 1104002, 1104003…
Si 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="0304001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Verde:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0334001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Rojo:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0344001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true" />
...
Morado:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1104001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Ten en cuenta que, técnicamente, varios APK funcionarán con la etiqueta de supports-screens o con la etiqueta compatible-screens. Generalmente se prefiere la compatibilidad con pantallas y, en general, es un problema ya que complican las cosas innecesariamente y aumentan las posibilidades de errores. Además, ten en cuenta que, en lugar de aprovechar los valores predeterminados (pequeño y normal siempre son verdaderos de forma predeterminada), los manifiestos establecen explícitamente el valor para cada tamaño de pantalla. Esto puede ahorrarte dolores de cabeza más adelante. A modo de ejemplo, un manifiesto con un SDK de destino de < 9 tendrán extragrande se configura automáticamente como false, ya que ese tamaño aún no existía. ¡Así que debes ser explícito!
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 específicamente relevantes para varios APK y de ninguna manera representan una lista de verificación completa para todos aplicaciones 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 APKs se superponen en la versión de la plataforma, el que tenga la minSdkVersion más alta debe tener un un código de versión superior.
- Cada tamaño de pantalla que deseas que sea compatible con tu APK se establece como verdadero en el manifiesto. Todos los tamaños de pantalla que quieres evitar, configúralo como falso.
- Comprueba si hay información contradictoria en los filtros del manifiesto (un APK que solo admita el pastelito en las pantallas extragrandes no será visible para nadie).
- El manifiesto de cada APK debe ser único en al menos una de las pantallas, texturas de OpenGL o versión de la plataforma.
- Intenta probar cada APK en al menos un dispositivo. Salvo eso, tienes uno de los emuladores de dispositivos personalizables en la empresa 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 app en Google Play. Esto es bastante simple en realidad usando “aapt” herramienta. Aapt (Android Asset Packaging Tool) es 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: 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
Cuando examines el resultado de aapt, asegúrate de verificar que no haya valores en conflicto para support-screens y compatible-screens, no contiene "uses-feature" no intencionales. valores agregados como resultado de los permisos establecidos en el manifiesto. En el ejemplo anterior, el APK será invisible para la mayoría de los dispositivos, si no todos.
¿Por qué? Cuando agregas el permiso necesario SEND_SMS, se agregó de manera implícita el requisito de función de android.hardware.telephony. Como la mayoría de los dispositivos extragrandes (si no todos) son tabletas sin hardware de telefonía, Google Play filtrará este APK en estos casos, hasta que aparezcan dispositivos futuros que tengan el tamaño suficiente para ser tratado como tamaño de pantalla extragrande y cuenten con 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.