Godot: Sobre o futuro da exportação para Android

Eu voto a favor da proposta 2.

Se estamos falando sobre refatorar o mecanismo de exportação de apk, acho que pode ser importante saber qual recurso Godot Engine está faltando:

1. Conteúdo dinâmico do APK : permitindo gerar um apk mais leve
2. Google Instant App : o usuário pode jogar seu jogo / aplicativo sem instalá-lo
3. Ícones adaptáveis : o Android mais recente (Android P e alguns Android 7.1+) requerem ícones adaptáveis.
4. Manipulador de travamento: Godot Engine está sem uma API de travamento. Ou seja, quando Godot Engine falha, devemos expor uma função que permite aos usuários enviá-lo para seu aplicativo de análise de falhas favorito
5. ANR agora trava , então quando o jogo está começando, devemos usar AsyncTask em vez de UIThread.

Enquanto estamos refatorando o mecanismo de exportação, devemos também adicionar esses recursos ao Godot Engine.

Meu voto => 2

Talvez um híbrido?
Use a abordagem antiga se o sdk não for encontrado para teste no modo de depuração, mas requer a instalação do SDK para o pacote de lançamento. Se o sdk for encontrado, use-o no modo de depuração e liberação.
Eu voto 2, porque é sempre um requisito se você estiver trabalhando no Android.

@xsellier Eu apreciaria que o ponto deste argumento não vá além do que foi proposto no OP, Se alguém quiser implementar o que você mencionou está bem, mas por favor, não descarrilhemos.

@HeartoLazor Menos código para manter é melhor, então, se for para o # 2, Hybrid é uma má ideia.

Também voto a favor da proposta 2.

Uma vez configuradas as ferramentas do Android, muito do trabalho é bastante simples, como baixar novos SDKs e construir bibliotecas externas.

Além disso, adicionar bibliotecas de terceiros seria mais fácil.

Eu voto na opção 2

A opção 2 parece muito mais conveniente. Gradle é uma ótima ferramenta, adicionar bibliotecas e gerenciar o processo de construção é muito mais fácil do que o fluxo atual.

Meu voto é para a proposta 2

Certa vez, criei um criador de modelos para Android como um complemento para 2.x
https://github.com/vinod8990/godot-addon-aetc

No entanto, voto a favor da proposta 2.
Se fizermos um padrão, então precisamos garantir que um módulo remova a API também. É um grande PIA quando precisamos remover um plugin nativo (como no caso do Unity).

Vote -> Proposta 2: Parece a escolha mais lógica, Godot é atualmente e em um futuro próximo o melhor motor de jogo para desenvolvimento móvel e uma melhor integração admob / ferramentas é uma obrigação quando se trata de exportar para Android e plataformas móveis.

Isso também significa que a exportação para iOS também será melhorada.? Pelo menos em um futuro próximo.

Vote na proposta 2: Alguma integração de biblioteca necessária para reconstruir o apk com arquivos específicos do aplicativo, como google-services.json para firebase ou personalização strings.xml para API do Facebook. No Godot 2, eu tinha o patch SConstruct / SCsub / methods.py e alguns arquivos de modelos para integrar corretamente algumas lib.

Parece haver um acordo maior aqui .. Então, acho que a invasão de APK terá que ser encerrada e os modelos de exportação devem estar praticamente no diretório do Android antes de o Gradle ser executado.

Alguém pode fazer uma proposta ou RP para a opção nº 2? :)

Bem, no momento eu tenho sofrido muito adicionando o compartilhamento e os módulos Admob, porque no momento há um bug no método get_data da textura então após compilar e senão você perde.

Também tenho que ter uma configuração específica para fazer tudo funcionar junto java, gradle e outros, o que é bom, mas é difícil.

Além disso, saber quais métodos de sombreador estão disponíveis e ter uma física mais fluida seria ótimo porque eu tenho que reescrever muitas coisas para mudar a posição, em vez de aplicar velocidades simples, porque alguns problemas que serão alterados no 3.1, portanto, ter uma página com dicas no Android seria ser também um grande passo.

Portanto, o número 2 com algumas caixas de seleção para otimizar para Android seria ótimo.

Claro que agradeço o esforço de criar todo esse ambiente de exportação.

O número 2 parece mais limpo, então acho melhor do que continuar trabalhando em um hack que pode trazer problemas futuros.
Minha única preocupação é o tempo de implantação. Atualmente, o teste no Android é muito rápido. Basicamente, depende principalmente do tamanho dos seus ativos. A opção 2 afetará severamente o tempo de construção?
Em qualquer caso, ainda acho que é o caminho a percorrer. Seria uma questão de confiar mais na sincronização cena / script para o teste.

A proposta 2 é muito melhor porque o Google Play sempre exige que o apk seja criado com o SDK do Android mais recente.

E também GDnative é uma dor quando tento integrar com IAP de terceiros e anúncios da Amazon, Leadbolt, etc.

Proposta 2 com certeza.

Abordagens semelhantes já são usadas em alguns grandes projetos como Cordova e Flutter . Uma ótima opção seria a possibilidade de abrir o projeto no Android Studio se o usuário quiser ter mais controle sobre a criação do APK.

A opção 2 parece mais limpa e mais parecida com o resto de Godot ... ou seja, feita corretamente.

Eu só passei pela dor de fazer a exportação do Android funcionar. O maior problema era ter as (versões das) ferramentas corretas instaladas; configurar em Godot foi fácil.
Em meu livro, se fazer da maneira certa envolve uma quantidade semelhante de dor para instalar as ferramentas certas, ainda é um passo na direção certa, então eu também voto no segundo lugar.
Compartilho minhas preocupações sobre a velocidade de lançamento no Android para depuração, mas se eu não conseguir liberar para a loja no final, esse é um grande problema que precisa ser resolvido; Preciso saber que a loja estará disponível quando estiver pronto para o lançamento.

Definitivamente # 2 :)

Estou a favor da opção 2 - instalar o SDK do Android não é um problema e abre muitas outras possibilidades.

Em um alto nível, parece semelhante à maneira como o Flutter faz as coisas, https://github.com/flutter/buildroot

A opção 2 significa que temos que compilar todo o mecanismo, incluindo código C ++ e Java para exportar um arquivo apk android para cada projeto sempre?

Isso seria um desastre! Cocos Creator usa um fluxo de trabalho terrível.

@Geequlim Se bem entendi, não c ++, mas java.

Sou a favor da opção nº 1. Quando faço algum experimento ou fluxo de trabalho de depuração. Não quero um Android Bundle para depurar um projeto pequeno. Continue hackeando. Deixe o programador fazer o fluxo de trabalho do SDK.

@Geequlim Sim, essa também é minha preocupação. Se o projeto precisar ser recompilado e compactado em um apk toda vez, tenho a sensação de que isso levará muito tempo.

@Geequlim @JFonS A recompilação completa não é necessária. O Gradle tem muita otimização de tempo de construção, portanto, a compilação completa (c ++ e Java) será necessária apenas na primeira vez. Além disso, quando você aplica um plug-in de terceiros, ele modifica o código Java, o Gradle verá que alguns arquivos foram alterados e uma dependência adicionada e recompilará apenas as partes alteradas. Na maioria das vezes, o exportador copiará os recursos do projeto (cenas, scripts e ativos) para a pasta do Android, o Gradle empacotará um apk dos arquivos de origem em cache e esses recursos e o executará no dispositivo Android. Isso não deve levar muito tempo.

@ veloc1 Ainda temos que compilar o mecanismo de buraco para cada evento de projeto para demos de teste da biblioteca de ativos, certo?

O fluxo de trabalho de compilação do gradle pode ser interrompido por muitas razões:

• A versão do SDK incorreta está instalada.
• As dependências não podem ser baixadas com uma conexão de rede ruim (isso é realmente frequente na China sem proxy).
• A memória disponível da máquina é inferior a 4 GB, mas alguns SDKs de terceiros precisam permitir a compilação de multiDexEnabled true .
• ...

E o gradle nem sempre é recompilado conforme o esperado.

Talvez eu esteja errado, mas acho que o nº 1 é um copo de leite e o nº 2 é uma vaca leiteira. Estou correcto?

@Geequlim Como posso imaginar, não precisamos realmente recompilar o mecanismo inteiro. Todo o código pode ser compactado na biblioteca (portanto, cada versão do Godot deve reconstruir a biblioteca do Android com o mecanismo do Godot). Quando o projeto é criado, o editor Godot pode descompactar o template android na pasta "android" com uma classe java, e o arquivo Gradle com a dependência android do mecanismo Godot incluída do maven (React Native funciona da mesma maneira, como me lembrei).
Desta forma, podemos minimizar o tempo de construção, o uso de memória e melhorar a simplicidade do projeto Android.

Mas você está certo, isso também envolve muitas limitações.

E alguns comentários sobre sua lista de coisas possivelmente quebradas:

• O SDK não desempenha muito papel, porque o mecanismo Godot não usa muitos recursos do novo SDK. Para projetos simples, quase qualquer SDK será adequado. Além disso, o download do SDK apropriado pode ser automatizado.
• O problema de dependência que você descreveu pode ser uma dor. Podemos incluir dependências com links do maven, mas também podemos colocar arquivos de bibliotecas (jar ou aar) na pasta do projeto, e usar dependência, então com conexão de rede ruim você pode baixar todas as dependências em outros lugares, colocá-las em um pendrive e mover projetar. Mas isso deve ser amplamente descrito na documentação de exportação.
• Multidex e memória não afetam um ao outro. Multidex pode ser ativado sempre no projeto modelo. A memória será uma limitação mais forte. Não posso dizer exatamente qual quantidade de memória disponível será necessária para isso, mas deve ser maior que 2 GB.

E há um resumo das mudanças que devem ser implementadas no Godot (conforme a forma que descrevi acima):

• Crie uma biblioteca android, que contém o motor e o sistema de plugins. (isto é difícil)
• Automatize a construção da biblioteca Android no lançamento e coloque-a no maven.
• Faça um modelo de projeto android.
• Colete um conjunto de scripts para validar o ambiente, baixe Gradle, Java, Android Sdk
• Faça alterações no mecanismo Godot para que, quando o usuário executar o projeto no dispositivo Android, o mecanismo copie todos os recursos e chame a tarefa Gradle para criar e executar o projeto.
• Documentação para todas as coisas.

@Geequlim

A opção 2 significa que temos que compilar todo o mecanismo, incluindo código C ++ e Java para exportar um arquivo apk android para cada projeto sempre?

Não .. Eu realmente não vejo nenhuma razão para isso. Este é o caso agora, mas o novo fluxo de trabalho simplesmente colocaria o projeto android no estado pré-construído (com os arquivos Godot .so). Adicionar módulos externos que você baixou em outros diretórios (como Admob) é muito fácil com o Gradle, então você poderia teoricamente apenas baixar esse suporte da biblioteca de ativos e ele funcionará magicamente.

@ veloc1

_Is_ já existe um sistema de plugins que modifica a compilação do Gradle para adicionar coisas que provavelmente não precisarão de nenhuma ou poucas mudanças.

O novo fluxo de trabalho "executar / exportar" consistiria em:
1) Construindo o Gradle (se nenhuma mudança acontecer, nada será feito, isso deve ser muito rápido
2) Provavelmente execute a lógica de exportação atual para descompactar o APK e adicionar os arquivos, plug-ins gdnative, etc. e compactá-lo novamente .. então a assinatura ainda seria feita por Godot e não Gradle, eu acho.

Da mesma forma, acho que Godot poderia fazer a edição necessária no AndroidManifest.xml antes de compilar (alterar o nome, adicionar permissões e outras coisas), adicionar ícones, etc. para tornar mais fácil para os usuários que ainda não entendem como o manifesto funciona. O bom é que isso é feito de uma forma não destrutiva, então você ainda pode adicionar suas próprias coisas ao Manifest.

@reduz

Não tinha certeza de que a assinatura deveria estar do lado de Godot. O plug-in do Android para Gradle tem um ótimo recurso para esse https://developer.android.com/studio/build/build-variants#signing , portanto, na exportação, apenas verificamos o armazenamento de chaves e as senhas, e o Gradle faz todo o trabalho.

E para Manifest. Quando digo sobre sistema de plug-ins, quero dizer exatamente isso: cada plug-in declara permissões e, na exportação, coletamos todos os plug-ins incluídos e geramos AndroidManifest.xml. Além disso, desta forma, podemos incluir serviços de biblioteca e BraodcastReceivers.

Para recursos como nome e ícone - e os recursos de espaço reservado e, quando configurados nas configurações do projeto, apenas substitua os espaços reservados por valores das configurações do projeto? Portanto, os usuários finais não verão todas essas coisas terríveis do Android.

Será possível, com o novo fluxo de trabalho de exportação, ter o pacote de jogos fora do APK em vez de ser compactado novamente (pasta ou .pck)?

@LinuxUserGD não é Apk Expansion (.obb) para isso?
já está aí.

O que quer que façamos, deve ser flexível e precisa ter certeza de que não é como as coisas da unidade. É uma bagunça quando misturamos e combinamos vários plug-ins com as mesmas dependências.

Quanto ao manifesto, gostaria de mantê-lo editável manualmente também.

A construção atual é muito flexível, pois eu poderia editar o modelo e adicionar / excluir o que eu quiser e nada vai interferir na construção dos modelos.

Eu acho que algo como um sistema híbrido funcionará?

Sem dúvida, a proposta 2 soa melhor, mais limpa e mais "adequada".
@reduz Contras da proposta 2? Imagino que seja um incômodo apenas quando a Internet rápida não está disponível.
Godot, como o Android Studio, provavelmente poderia muito facilmente (como um arquivo de texto?) Passar para o sdkmanager uma lista de pacotes necessários para baixar https://developer.android.com/studio/command-line/sdkmanager

Proposta 2, com certeza.

Proposta nº 2. A instalação do Android SDK é muito fácil hoje em dia!

@reduz , estou votando na proposta 2. Mas, por favor, não se esqueça do # 18141

proposta 2. O Gradle também está documentado, portanto, teremos mais recursos. A maioria dos desenvolvedores móveis terá o SDK do Android instalado em algum lugar de seu sistema.

Proposta 2

Quando isso vai ser implementado, qualquer informação ou qualquer coisa
@ akien-mga Ainda é o marco do 3.1?

De acordo com esta postagem do blog de

Godot 3.1 será um lançamento que cobre uma área de superfície muito mais ampla do que nossos usuários esperam, então não precisamos mais de novos recursos. O único recurso realmente grande planejado após o 3.1 é portar a renderização para Vulkan ...

Bem, a característica da questão atual parece ter reunido atenção suficiente para ser considerada para 3.2. Existe algum motivo pelo qual não foi endereçado na postagem do blog?

Ficamos sem tempo para um grande refator de exportação do Android, então isso será para o 3.2.

Como o Android oferece uma variedade de plug-ins e bancos de dados de terceiros (Firebase, Cloud, ML), parece uma boa ideia ter o android sdk / jdk / ndk instalado para desenvolvimento sustentado. A razão é que as bibliotecas do Android mudam com versões lá, talvez algumas bibliotecas de dependência ausentes durante a exportação são feitas sem ter uma versão adequada do SDK instalado. Mas esta abordagem, ao contrário, requer que o usuário ou desenvolvedor final envie o produto inteiro para a plataforma Android apenas para fins de teste, o que representa uma sobrecarga de tempo .Uma abordagem alternativa pode ser feita como fazer um aplicativo para Android que usa o android studio sdk e o jdk no dispositivo para teste. O usuário pode simplesmente executar o aplicativo conectado ao computador com uma porta de cabo e, em seguida, executar o jogo no godot editor propriamente dito e ver as mudanças no telefone ou no celular. O celular usa o SDK do Android do computador através de sua porta e, no que diz respeito à Proposta1, há pouca sobrecarga de tempo e também é quase transparente, não há necessidade de hacking.
Porque há certas bibliotecas no código do kernel do Android que, se não instaladas, levarão a travamentos de tempo de execução principalmente com java.lang.io.exceptions. Também há um problema a ser resolvido que se a Proposta 1 tiver precedência, isso implica hackear em separado versões do Android, cada uma com mais dependências do que as anteriores. A proposta 2 pode ser feita simplesmente instalando o android sdk no computador e usando um aplicativo Android (a ser construído) pelos desenvolvedores para verificar instantaneamente seus jogos no celular; mais como um remoto. Para a construção completa de um aplicativo ou exportação, a abordagem generalizada 2 pode ser adotada.
No que diz respeito aos modelos, um modelo adaptativo android8 + pode ser usado. Além disso, para encurtar o tempo de construção do aplicativo (com o uso do sdk), as otimizações do motor para melhorar os coletores de lixo e também otimizações como a abordagem baseada em estrutura podem ser usado.
Esta é inteiramente a minha perspectiva, se estiver tudo bem, então tenho alguns planos feitos em relação ao aplicativo (android) que usa o SDK do dispositivo para a construção instantânea do jogo do aplicativo.

O Google Play agora aceita aplicativos carregados em seu novo formato Android App Bundle (AAB) .

Esse formato permite que o Google Play gere APKs dinamicamente para muitos tipos de dispositivos e um dos recursos que afetam diretamente os jogos feitos em Godot é compactar APKs contendo apenas a biblioteca nativa feita para essa arquitetura de CPU específica.

Isso significa que o tamanho do download pode ser amplamente melhorado fazendo com que o APK baixado por um dispositivo x86 contenha apenas a biblioteca x86, aquele baixado por um arm64 contém apenas a biblioteca arm64 e assim por diante.

Acredito que qualquer abordagem que Godot adote deva oferecer suporte a esse novo formato de pacote, mas não sei como é fácil "hackear" um pacote AAB em contraste com um pacote APK que é basicamente um arquivo ZIP.

Isso significa que o tamanho do download pode ser amplamente melhorado fazendo com que o APK baixado por um dispositivo x86 contenha apenas a biblioteca x86, aquele baixado por um arm64 contém apenas a biblioteca arm64 e assim por diante.

Observe que isso já é possível, mas requer trabalho manual criando um APK por arquitetura e, em seguida, enviando-o para o Google Play usando seu suporte a vários APK .

Isso foi corrigido pelo nº 27781, que basicamente implementa uma combinação de 1 e 2. O sistema antigo é preservado para a implantação com um clique, mas as versões agora serão fornecidas com a fonte do modelo pré-compilado que pode ser recompilado em um novo APK com módulos personalizados / mudanças de manifesto / etc. usando gradle.