Cómo crear varios APK para diferentes niveles de API

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 de las cuales abarca un rango ligeramente diferente de niveles de API. Además, obtendrás algunas herramientas necesario 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 app que funciona en varias generaciones de dispositivos Android natural, deseas que tu aplicación aproveche las nuevas funciones en dispositivos nuevos, sin sacrificar la retrocompatibilidad. Al principio, puede parecer que varios APK La asistencia técnica es la mejor solución, pero a menudo este no es el caso. La sección Uso de un único APK En su lugar de la guía para desarrolladores de varios APK, se incluye información útil sobre cómo lograr esto con un solo APK, incluido el uso de nuestra biblioteca de compatibilidad. También puedes aprender a escribir código que se ejecute solo en ciertos niveles de API en un único APK, sin recurrir técnicas costosas desde el punto de vista informático, como el reflejo de este artículo.

Si puedes administrarla, limitar tu aplicación a un solo APK tiene varias como 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 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 APK necesitas y qué API que abarca cada APK. Como referencia práctica, consulta la página Versiones de la plataforma de la El sitio web para desarrolladores de Android brinda datos sobre el número relativo de dispositivos activos que usan un determinado dispositivo de la plataforma de Android. Además, aunque al principio suena fácil, hacer un seguimiento de qué conjunto de niveles de API que cada APK va a orientar se vuelve difícil con bastante rapidez, en especial si que haya cierta superposición (a menudo, las hay). Por suerte, es fácil organizar tus requisitos rápidamente fácilmente 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 representen el diferentes niveles de API de la plataforma de Android. Agrega una celda adicional al final para representar el futuro. versiones de Android.

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 cierto rango de niveles de API.

Una vez que crees este gráfico, distribúyelo entre tu equipo. La comunicación del equipo en tu proyecto se volvió inmediatamente más simple, ya que, en lugar de preguntar "¿Cómo está el APK para los niveles de API 3 a 6, eh, es el de Android 1.x. ¿Cómo va todo?", Solo tienes que decir "¿Cómo viene el APK azul a la vez?”.

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. Todo que se agrega al proyecto de biblioteca solo necesita actualizarse una vez (piensa en las cadenas localizadas en un idioma, temas de color, corrección de errores en el código compartido), lo que mejora el tiempo de desarrollo y reduce el la probabilidad de 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 va a 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, por otro lado, estás creando la aplicación desde cero, intenta lo siguiente: Escribir código en el proyecto de biblioteca primero y, luego, moverlo hacia abajo 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. Fácil 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 el nombre del paquete con la biblioteca. Si tuvieras 3 APKs para seguir el esquema como se describió antes, 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 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 aplicación que usa varios APK a través de Google Play, el El APK 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 aún no hemos establece un nivel de API máximo para cualquiera de los APK. Tomado de forma individual, el rango posible de cada APK verse así:

Debido a que es obligatorio que un APK con una minSdkVersion más alta también tenga una 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:

Ahora, supongamos que el APK rojo tiene algunos requisitos que los otros dos no tienen. En la página Filtros en Google Play de hay una lista completa de posibles culpables. Para el Por ejemplo, supongamos que el rojo requiere una cámara frontal. De hecho, el punto de El APK rojo combina la cámara frontal con la nueva funcionalidad que se agregó en la API. Pero resulta que no todos los dispositivos compatibles con la API 11 tienen cámaras frontales. El ¡Terror!

Afortunadamente, si un usuario explora Google Play desde uno de esos dispositivos, Google Play buscará la ve que Red incluye la cámara frontal como un requisito e ignórala en silencio, lo que te permite determinó que Red y ese dispositivo no son una combinación perfecta en el cielo digital. Luego verá que El verde no solo es compatible con versiones futuras de dispositivos con el nivel de API 11 (ya que no se definió maxSdkVersion), pero tampoco le importa si tiene o no una cámara frontal. Aún se puede descargar la app de Google Play, porque a pesar del contratiempo con la cámara frontal, aún había una APK que admitía ese nivel de API en particular.

Para mantener todos tus APKs en "segmentos" separados, es importante tener un buen código de versión . El recomendado se puede encontrar en el área Códigos de versión de nuestra guía para desarrolladores. Como el conjunto de ejemplos de APK solo aborda uno de 3 posibles dimensiones, basta con separar cada APK por 1,000, establecer los primeros dos dígitos minSdkVersion para ese APK en particular y se 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 podrían ocultar tu aplicación 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 empaquetado de 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 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 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.