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 desarrollas tu aplicación para Android para aprovechar múltiples APK en Google Play, es es importante adoptar algunas prácticas recomendadas desde el principio y evitar más dolores de cabeza innecesarios en el proceso de desarrollo. En esta lección, se muestra cómo crear varios APK para tu app, cada uno y admitir un subconjunto diferente de formatos de textura OpenGL. 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 aplicación que funciona en todas las aplicaciones disponibles naturalmente, querrás que tu aplicación se vea lo mejor posible en cada dispositivo individual, independientemente del el hecho de que no son compatibles con el mismo conjunto de texturas GL. Puede parecer que, al principio, La compatibilidad con varios APK 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, incluida la forma de detectar texturas compatibles durante el tiempo de ejecución. Según la situación, podría ser más fácil agrupar todos los formatos con y elige cuál usar en el tiempo de ejecución.
Si puedes administrarla, limitar tu aplicación a un solo APK tiene varias ventajas, como:
- 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
La Guía para desarrolladores de Android ofrece una referencia práctica de algunas de las texturas compatibles más comunes en el recurso supports-gl-texture . Esta página también contiene algunas sugerencias sobre qué teléfonos (o familias de teléfonos) admiten formatos de texturas particulares. Ten en cuenta que es buena idea que uno de tus APK admita ETC1, ya que ese formato de textura es compatible con todos los dispositivos con Android que admiten OpenGL ES las especificaciones de 2.0.
Dado que la mayoría de los dispositivos con Android admiten más de un formato de textura, debes establecer una orden de preferencia. Crear un gráfico que incluya todos los formatos a los que se aplicará tu aplicación y asistencia. La celda del extremo izquierdo será la de menor prioridad (probablemente será ETC1, una configuración predeterminada sólida en términos de rendimiento y compatibilidad). Luego, colorea el gráfico de manera que cada uno la celda representa un APK.
| ETC1 | ATI | PowerVR |
Los colores del gráfico no solo hacen que esta guía sea menos monocromática: y facilitan la comunicación dentro del equipo. Ahora puedes simplemente referirte a cada APK como "azul", "verde" o "rojo", en lugar de "El que admite formatos de textura ETC1", etc.
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 algunas 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.
- Si alguno de los formatos de texturas enumerados en tu APK es compatible con un dispositivo que se encuentra en el mercado, ese dispositivo se considera apto
Con respecto a las texturas GL, esta última regla es importante. Significa que deberías, por Por ejemplo, ten mucho cuidado cuando uses diferentes formatos GL en la misma app. Si usar PowerVR el 99% de las veces, pero ETC1 para, digamos, la pantalla de presentación... Entonces, tu manifiesto indicaría necesariamente la compatibilidad con ambos formatos. Un dispositivo que solo admita ETC1 se consideraría compatible, la aplicación se descargaría y el usuario experimentaría un error emocionante mensajes nuevos. Lo más común es que, si usas varios APK para orientar para diferentes dispositivos, según la compatibilidad con texturas GL, será un formato de textura por APK.
Esto hace que la compatibilidad con texturas sea un poco diferente de los otros dos APK múltiples. dimensiones, nivel de API y tamaño de pantalla. Todos los dispositivos tienen solo un nivel de API y una pantalla. y depende del APK admitir una variedad de ellos. En el caso de las texturas, el APK generalmente una sola textura y el dispositivo admitirá muchas. A menudo, habrá una superposición que admita muchos APK, pero la solución es la misma: códigos de versión.
A modo de ejemplo, toma algunos dispositivos y observa cuántos de los APK definidos anteriormente se ajustan a cada uno de ellos. dispositivo.
| FooPhone | Nexus S | Evo |
| ETC1 | ETC1 | ETC1 |
| PowerVR | ATI TC |
Suponiendo que se prefieren los formatos PowerVR y ATI en lugar de ETC1 cuando estén disponibles según “el número de versión más alto gana” si configuramos el atributo versionCode en cada APK rojo ≥ verde ≥ azul, entonces se elegirán siempre rojo y verde en lugar de azul compatibles con las versiones. Si llega un dispositivo compatible con los colores rojo y verde, rojo.
Para mantener todos tus APK en "segmentos" separados, es importante tener un buen 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. Desde el conjunto de ejemplos de APK solo abarca una de 3 dimensiones posibles, sería suficiente para separar cada APK por 1,000 y aumentar a partir de allí. El aspecto podría ser el siguiente:
Azul: 1,001, 1,002, 1,003, 1,004…
Verde: 2,001, 2,002, 2,003, 2,004...
Rojo:3,001, 3,002, 3,003, 3,004...
Tras juntar todo esto, es probable que los manifiestos de Android se vean así: lo siguiente:
Azul:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1001" android:versionName="1.0" package="com.example.foo"> <supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" /> ...
Verde:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="2001" android:versionName="1.0" package="com.example.foo"> <supports-gl-texture android:name="GL_AMD_compressed_ATC_texture" /> ...
Rojo:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="3001" android:versionName="1.0" package="com.example.foo"> <supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" /> ...
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.
- 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 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: '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.