Godot: Sobre el futuro de la exportación de Android

Voto a favor de la propuesta 2.

Si estamos hablando de refactorizar el mecanismo de exportación de apk, creo que podría ser importante saber qué característica falta en Godot Engine:

1. Contenido dinámico de APK : permite generar una apk más ligera
2. Aplicación instantánea de Google : el usuario puede jugar su juego / aplicación sin instalarlo
3. Iconos adaptables : la última versión de Android (Android P y algunos Android 7.1+) requieren iconos adaptables.
4. Controlador de fallas: A Godot Engine le falta una API que falla. Lo que significa que cuando Godot Engine falla, deberíamos exponer una función que permita a los usuarios enviarla a su aplicación favorita de análisis de fallas.
5. ANR ahora se bloquea , por lo que cuando el juego comienza, debemos usar AsyncTask en lugar de UIThread.

Mientras refactorizamos el mecanismo de exportación, también deberíamos agregar esas características a Godot Engine.

Mi voto => 2

¿Quizás un híbrido?
Use el enfoque anterior si no se encuentra sdk para probar en modo de depuración, pero requiere la instalación de SDK para el paquete de lanzamiento. Si se encuentra sdk, utilícelo en el modo de depuración y liberación.
Voto 2, porque siempre es un requisito si estás trabajando en Android.

@xsellier Agradecería que el punto de este argumento no vaya más allá de lo propuesto en el OP, si alguien quiere implementar lo que mencionas está bien, pero por favor no descarrilemos.

@HeartoLazor Menos código para mantener es mejor en mi opinión, por lo que si

También voto por la propuesta 2.

Una vez configuradas, las herramientas de Android hacen que gran parte del trabajo sea bastante sencillo, como descargar nuevos sdk y crear bibliotecas externas.

También sería más fácil agregar bibliotecas de terceros.

Voto por la opción 2

La opción 2 suena mucho más conveniente. Gradle es una gran herramienta, agregar bibliotecas y administrar el proceso de construcción es mucho más fácil que el flujo actual.

Mi voto es a favor de la propuesta 2

Una vez había creado un creador de plantillas de Android como complemento para 2.x
https://github.com/vinod8990/godot-addon-aetc

Sin embargo, voto a favor de la propuesta 2.
Si hacemos un estándar, entonces debemos asegurarnos de que un módulo elimine la API también. Es un PIA enorme cuando necesitamos eliminar un complemento nativo (como en el caso de Unity).

Voto -> Propuesta 2: Parece la opción más lógica, Godot es actualmente y en un futuro próximo el mejor motor de juegos para el desarrollo móvil y una mejor integración de admob / herramientas es imprescindible cuando se trata de exportar a Android y plataformas móviles.

¿Significa esto también que también se mejorará la exportación de iOS? Al menos en un futuro próximo.

Vote por propsal 2: se requiere cierta integración de la biblioteca para reconstruir apk con archivos específicos de la aplicación como google-services.json para firebase o personalización strings.xml para facebook api. En Godot 2, tenía el parche SConstruct / SCsub / methods.py y algunos archivos de plantillas para integrar correctamente algunos archivos lib.

Parece que hay mayor acuerdo aquí ... Así que supongo que la piratería de APK tendrá que desaparecer, y las plantillas de exportación deberían ser prácticamente el directorio de Android antes de que se ejecute Gradle ...

¿Alguien quiere hacer una propuesta o relaciones públicas para la opción # 2? :)

Bueno, en este momento he sufrido mucho al agregar el recurso compartido y los módulos de Admob, porque en este momento hay un error en el método get_data de la textura, así que después de compilar y de lo contrario pierdes.

También tengo que tener una configuración específica para que todo funcione en conjunto, java, gradle y demás, lo cual está bien pero es difícil.

También saber qué métodos de sombreado están disponibles y tener una física más fluida sería genial porque tengo que reescribir muchas cosas para cambiar la posición en lugar de aplicar velocidades simples porque algunos problemas que se cambiarán en el 3.1, por lo que tener una página con consejos sobre Android lo haría será también un gran paso.

Entonces, el # 2 con algunas casillas de verificación para optimizar para Android sería genial.

Por supuesto agradezco el esfuerzo que ha hecho creando todo este entorno exportador.

El número 2 parece más limpio, así que creo que es mejor que seguir trabajando en un truco que podría traer problemas en el futuro.
Mi única preocupación es el tiempo de implementación. Actualmente, las pruebas en Android son realmente rápidas, básicamente depende principalmente de qué tan grandes sean sus activos. ¿La opción 2 afectará gravemente al tiempo de construcción?
En cualquier caso, sigo pensando que es el camino a seguir. Sería una cuestión de depender más de la sincronización de escenas / guiones para las pruebas.

La propuesta 2 es mucho mejor porque Google Play siempre requiere que la apk se compile con su último SDK de Android.

Y también GDnative es doloroso cuando trato de integrarme con IAP y anuncios de terceros de Amazon, Leadbolt, etc.

Propuesta 2 seguro.

Ya se utilizan enfoques similares en algunos grandes proyectos como Cordova y Flutter . Una gran opción sería la posibilidad de abrir el proyecto en Android Studio si el usuario quiere tener más control sobre la creación del APK.

La opción 2 parece más limpia y más parecida al resto de Godot ... es decir, si se hace correctamente.

Acabo de pasar por el dolor de hacer que la exportación de Android funcione. Lo más doloroso fue instalar las (versiones de) herramientas correctas; configurar en Godot fue fácil.
En mi libro, si hacerlo bien implica una cantidad similar de dolor para instalar las herramientas adecuadas, sigue siendo un paso en la dirección correcta, por lo que también voto por el n. ° 2.
Comparto preocupaciones sobre la velocidad de lanzamiento en Android para la depuración, pero si no puedo lanzarlo a la tienda al final, entonces ese es un gran problema que debe abordarse; Necesito saber que la tienda estará disponible cuando esté listo para lanzar.

Definitivamente # 2 :)

Estoy a favor de la opción 2: instalar el SDK de Android no es un problema y abre muchas otras posibilidades.

En un nivel alto, parece similar a la forma en que Flutter hace las cosas, https://github.com/flutter/buildroot

¿La opción n. ° 2 significa que tenemos que compilar todo el motor, incluido el código C ++ y Java para exportar un archivo apk de Android para cada proyecto cada vez?

¡Eso sería un desastre! Cocos Creator usa un flujo de trabajo tan terrible.

@Geequlim Si entiendo bien, no c ++ sino java.

Estoy a favor de la opción n. ° 1. Cuando hago algún experimento o depuro el flujo de trabajo. No quiero un paquete de Android para depurar un proyecto pequeño. Sigue el camino del truco. Deja que el programador haga el flujo de trabajo del SDK.

@Geequlim Sí, esa también es mi preocupación. Si el proyecto necesita ser recompilado y empaquetado en un apk cada vez que tengo la sensación de que tomará bastante tiempo.

@Geequlim @JFonS No se necesita una recompilación completa. Gradle tiene mucha optimización del tiempo de compilación, por lo que la compilación completa (c ++ y Java) solo será necesaria la primera vez. Además, cuando aplica un complemento de terceros, modificará el código Java, Gradle verá que se cambiaron pocos archivos y se agregó una dependencia, y volverá a compilar solo las partes cambiadas. La mayoría de las veces, el exportador copiará los recursos del proyecto (escenas, scripts y activos) a la carpeta de Android, Gradle empacará un apk de los archivos de origen almacenados en caché y estos recursos y lo ejecutará en un dispositivo Android, esto no debería llevar mucho tiempo.

@ veloc1 Todavía tenemos que compilar el motor de pozo para cada evento de proyecto para demostraciones de prueba desde la biblioteca de activos, ¿verdad?

El flujo de trabajo de compilación de Gradle puede romperse por muchas razones:

• Se instaló la versión incorrecta del SDK.
• Las dependencias no se pueden descargar con una mala conexión de red (que es muy frecuente en China sin proxy).
• La memoria disponible de la máquina es de menos de 4 GB, pero algunos SDK de terceros tienen que habilitar multiDexEnabled true para compilar.
• ...

Y el gradle no siempre se vuelve a compilar como se esperaba.

Tal vez me equivoque, pero creo que el n. ° 1 es un vaso de leche y el n. ° 2 es una vaca lechera. ¿Estoy en lo correcto?

@Geequlim Como puedo imaginar, no necesitamos recompilar todo el motor. Todo el código se puede empaquetar en la biblioteca (por lo tanto, cada versión de Godot debe reconstruir la biblioteca de Android con el motor Godot). Cuando se crea el proyecto, el editor de Godot puede descomprimir la plantilla de Android en la carpeta "android" con una clase de Java, y el archivo Gradle con la dependencia de Android del motor Godot incluido de Maven (React Native funciona de la misma manera, como recordaba).
De esta manera podemos minimizar el tiempo de compilación, el uso de memoria y mejorar la simplicidad del proyecto de Android.

Pero tienes razón, esto también implica muchas limitaciones.

Y algunos comentarios a tu lista de cosas posiblemente rotas:

• SDK no juega mucho papel, porque el motor Godot no usa muchas características del nuevo sdk. Para proyectos simples, casi cualquier SDK estará bien. Además, se puede automatizar la descarga del sdk apropiado.
• El problema de dependencia que describiste puede ser un dolor. Podemos incluir dependencias con enlaces de maven, pero también podemos poner archivos de bibliotecas (jar o aar) en la carpeta del proyecto y usar la dependencia, por lo que con una mala conexión de red puede descargar todas las dependencias en otros lugares, ponerlas en una memoria USB y mover para proyectar. Pero esto debería describirse ampliamente en la documentación de exportación.
• Multidex y la memoria no se afectan entre sí. Multidex se puede habilitar siempre en el proyecto de plantilla. La memoria será una limitación más fuerte. No puedo decir exactamente qué cantidad de memoria disponible se necesitará para eso, pero debería ser superior a 2 GB.

Y hay un resumen de los cambios que deben implementarse en Godot (de acuerdo con la forma que describí anteriormente):

• Crea una biblioteca de Android, que contiene el motor y el sistema de complementos. (Esto es duro)
• Automatice la creación de la biblioteca de Android en el lanzamiento y póngala en maven.
• Hacer plantilla de proyecto de Android.
• Recopile un conjunto de scripts para validar el entorno, descargas Gradle, Java, Android Sdk
• Realice cambios en el motor Godot, de modo que cuando el usuario ejecute el proyecto en un dispositivo Android, el motor debería copiar todos los recursos y llamar a la tarea de Gradle para compilar y ejecutar el proyecto.
• Documentación para todas las cosas.

@Geequlim

¿La opción n. ° 2 significa que tenemos que compilar todo el motor, incluido el código C ++ y Java para exportar un archivo apk de Android para cada proyecto cada vez?

No ... Realmente no veo ninguna razón para eso. Este es el caso ahora, pero el nuevo flujo de trabajo simplemente pondría el proyecto de Android en un estado prediseñado (con los archivos Godot .so). Agregar módulos externos que descargó en otros directorios (como Admob) es realmente fácil con Gradle, por lo que, en teoría, podría simplemente descargar ese soporte de la biblioteca de activos y funcionará mágicamente.

@ veloc1

Ya existe un sistema de complementos que modifica la compilación de Gradle para agregar cosas, que probablemente no necesitarán ningún cambio o necesitarán pocos cambios.

El nuevo flujo de trabajo "ejecutar / exportar" consistiría en:
1) Construyendo Gradle (si no ocurrieron cambios, no se hará nada, eso debería ser bastante rápido
2) Es probable que ejecute la lógica de exportación actual para descomprimir el APK y agregar los archivos, complementos nativos, etc. y volver a comprimirlo ... para que la firma aún la realice Godot y no Gradle, supongo.

Del mismo modo, supongo que Godot podría hacer la edición requerida en AndroidManifest.xml antes de compilar (cambiar el nombre, agregar permisos y otras cosas), agregar íconos, etc. para que sea más fácil para los usuarios que aún no conocen cómo funciona el manifiesto. Lo bueno es que esto se hace de una manera no destructiva, por lo que aún puede agregar sus propias cosas a Manifest.

@reduz

No estaba seguro de que la firma debería estar del lado de Godot. El complemento de Android para Gradle tiene una gran función para https://developer.android.com/studio/build/build-variants#signing , por lo que en la exportación solo verificamos el almacén de claves y las contraseñas, y Gradle hace todo el trabajo.

Y para Manifest. Cuando digo sobre el sistema de complementos, me refiero exactamente a eso: cada complemento declara permisos y, en la exportación, recopilamos todos los complementos incluidos y generamos AndroidManifest.xml. Además, de esta forma podemos incluir servicios bibliotecarios y BraodcastReceivers.

Para recursos como el nombre y el icono, ¿qué pasa con los recursos de marcador de posición, y cuando se configura en la configuración del proyecto, simplemente reemplace los marcadores de posición con los valores de la configuración del proyecto? Por lo tanto, los usuarios finales no verán todas estas cosas terribles de Android en absoluto.

¿Será posible con el nuevo flujo de trabajo de exportación tener el paquete del juego fuera del APK en lugar de volverlo a comprimir (carpeta o .pck)?

@LinuxUserGD no es Apk Expansion (.obb) para eso?
ya está ahí.

Hagamos lo que hagamos, debería ser flexible y debemos asegurarnos de que no sea como las cosas de la unidad. Es un desastre cuando mezclamos y combinamos varios complementos que tienen las mismas dependencias.

En cuanto al manifiesto, también me gustaría mantenerlo editable manualmente.

La compilación actual es muy flexible, por lo que podría editar la plantilla y agregar / eliminar lo que quiera y nada interferirá al crear las plantillas.

¿Creo que funcionará algo como un sistema híbrido?

Sin duda la propuesta 2 suena mejor, más limpia y más "adecuada".
@reduz ¿ Contras de la propuesta 2? Me imagino que es una molestia solo cuando no hay Internet rápido disponible.
Godot, como Android Studio, probablemente podría pasar muy fácilmente (¿como un archivo de texto?) A sdkmanager una lista de paquetes necesarios para descargar https://developer.android.com/studio/command-line/sdkmanager

Propuesta 2, seguro.

Propuesta # 2. ¡La instalación del SDK de Android es bastante fácil hoy en día!

@reduz , voy a votar a favor de la propuesta 2. Pero, por favor, no se olvide de la # 18141

propuesta 2. Gradle también está documentado, por lo que tendremos más recursos. La mayoría de los desarrolladores móviles tendrán Android SDK instalado en algún lugar de su sistema de todos modos.

Propuesta 2

¿Cuándo se implementará esto, cualquier información o cualquier cosa?
@ akien-mga ¿Sigue siendo el hito de la 3.1?

Según esta publicación de godotengine.org/news del 23 de noviembre de 2018:

Godot 3.1 será una versión que cubre un área de superficie mucho más amplia de lo que esperan nuestros usuarios, por lo que ya no necesitamos tantas funciones nuevas. La única característica realmente grande planeada después de 3.1 es portar el renderizado a Vulkan ...

Bueno, la característica del número actual parece haber atraído suficiente atención como para ser considerada para 3.2. ¿Hay alguna razón por la que no se haya abordado en la publicación del blog?

Se nos acabó el tiempo para una gran refactorización de la exportación de Android, por lo que será para 3.2.

Dado que Android ofrece una variedad de complementos y bases de datos de terceros (Firebase, Cloud, ML), parece una buena idea tener Android sdk / jdk / ndk instalado para un desarrollo sostenido. La razón es que las bibliotecas de Android cambian con las versiones que existen. algunas bibliotecas de dependencia que faltan cuando la exportación se realiza sin tener instalada una versión adecuada del sdk. Pero este enfoque, por el contrario, requiere que el usuario o el desarrollador final envíe todo el producto a la plataforma Android solo por el bien de la prueba, lo que representa una sobrecarga de tiempo. Se puede hacer un enfoque alternativo, como crear una aplicación para Android que use el Android Studio SDK y el JDK en el dispositivo para realizar pruebas. El usuario simplemente puede ejecutar la aplicación, conectarse con la computadora con un puerto de cable y luego ejecutar el juego en el godot editor en sí mismo y ver los cambios en el teléfono o móvil. El móvil usa el sdk de Android de la computadora a través de su puerto y, en lo que respecta a Proposal1, hay poca sobrecarga de tiempo. y también es casi transparente, no se requiere piratería.
Debido a que hay ciertas bibliotecas en el código del kernel de Android que, si no se instalan, provocarán fallas en el tiempo de ejecución principalmente con java.lang.io.exceptions. las versiones de Android tienen cada una más dependencias que las anteriores. La propuesta 2 se puede hacer simplemente instalando Android SDK en la computadora y usando una aplicación de Android (que será construida) por los desarrolladores para verificar instantáneamente sus juegos en el móvil; más como un control remoto. Para la construcción completa de una aplicación o exportar el enfoque generalizado, se puede tomar 2.
En lo que respecta a las plantillas, se pueden utilizar plantillas adaptables android8 +. Además, para acortar el tiempo de creación de la aplicación (con el uso del sdk), se pueden realizar optimizaciones del motor para mejorar los recolectores de basura y también optimizaciones como el enfoque basado en estructuras. usó.
Esta es completamente mi perspectiva, si está bien, entonces tengo algunos planes hechos con respecto a la aplicación (Android) que usa el SDK del dispositivo para la construcción instantánea del juego de la aplicación.

Google Play ahora acepta aplicaciones cargadas en su nuevo formato Android App Bundle (AAB) .

Este formato permite que Google Play genere de forma dinámica APK para muchos tipos de dispositivos y una de las características que afectan directamente a los juegos creados en Godot es empaquetar APK que contengan solo la biblioteca nativa creada para esa arquitectura de CPU en particular.

Esto significa que el tamaño de la descarga se puede mejorar enormemente haciendo que el APK descargado por un dispositivo x86 solo contenga la biblioteca x86, el descargado por un arm64 solo contenga la biblioteca arm64 y así sucesivamente.

Creo que cualquier enfoque que tome Godot debería ser compatible con este nuevo formato de empaquetado, pero no sé qué tan fácil es "piratear" un paquete AAB en contraste con un paquete APK que es básicamente un archivo ZIP.

Esto significa que el tamaño de la descarga se puede mejorar enormemente haciendo que el APK descargado por un dispositivo x86 solo contenga la biblioteca x86, el descargado por un arm64 solo contenga la biblioteca arm64 y así sucesivamente.

Tenga en cuenta que esto ya es posible, pero requiere trabajo manual creando un APK por arquitectura y luego cargándolo en Google Play usando su soporte para múltiples APK .

Esto se corrigió con el número 27781, que básicamente implementa una combinación de 1 y 2. El sistema antiguo se conserva para la implementación con un clic, pero las versiones ahora se enviarán con la fuente de la plantilla precompilada que se puede volver a compilar en un nuevo APK con módulos personalizados. / cambios de manifiesto / etc. usando gradle.