Godot: Über die Zukunft des Android-Exports

Ich stimme für den Vorschlag 2.

Wenn wir über das Refactoring des APK-Exportmechanismus sprechen, denke ich, dass es wichtig sein könnte zu wissen, welche Funktion Godot Engine fehlt:

1. APK Dynamische Inhalte : Ermöglicht die Generierung einer leichteren
2. Google Instant App : Der Benutzer kann Ihr Spiel/Ihre App spielen, ohne es zu installieren
3. Adaptive Symbole : Die neuesten Android-Versionen (Android P und einige Android 7.1+) erfordern adaptive Symbole.
4. Absturz-Handler: Godot Engine fehlt eine abstürzende API. Das heißt, wenn Godot Engine abstürzt, sollten wir eine Funktion bereitstellen, mit der Benutzer sie an ihre bevorzugte Absturzanalyseanwendung senden können
5. ANR stürzt jetzt ab , daher sollten wir beim Start des Spiels AsyncTask anstelle von UIThread verwenden.

Während wir den Exportmechanismus umgestalten, sollten wir diese Funktionen auch zu Godot Engine hinzufügen.

Meine Stimme => 2

Vielleicht ein Hybrid?
Verwenden Sie den alten Ansatz, wenn sdk nicht zum Testen im Debug-Modus gefunden wird, aber die Installation des SDK für das Release-Paket erfordert. Wenn sdk gefunden wird, verwenden Sie es im Debug- und Release-Modus.
Ich stimme mit 2, weil es immer eine Voraussetzung ist, wenn Sie in Android arbeiten.

@xsellier Ich würde es

@HeartoLazor Weniger zu wartender Code ist imo besser. Wenn Sie sich also für #2 entscheiden, ist Hybrid eine schlechte Idee.

Ich stimme auch für Vorschlag 2.

Sobald die Android-Tools eingerichtet sind, ist ein Großteil der Arbeit ziemlich schmerzlos, z. B. das Herunterladen neuer SDKs und das Erstellen externer Bibliotheken.

Auch das Hinzufügen von Bibliotheken von Drittanbietern wäre einfacher.

Ich stimme für Option 2

Option 2 klingt viel bequemer. Gradle ist ein großartiges Werkzeug, das Hinzufügen von Bibliotheken und das Verwalten des Erstellungsprozesses ist viel einfacher als der aktuelle Ablauf.

Meine Stimme ist für Vorschlag 2

Ich hatte mal einen Android Template Creator als Addon für 2.x erstellt
https://github.com/vinod8990/godot-addon-aetc

Ich stimme jedoch für Vorschlag 2.
Wenn wir einen Standard machen, müssen Sie auch sicherstellen, dass ein Modul die API entfernt. Es ist eine riesige PIA, wenn wir ein natives Plugin entfernen müssen (wie im Fall von Unity).

Abstimmung -> Vorschlag 2: Es scheint die logischste Wahl zu sein, Godot ist derzeit und in naher Zukunft die beste Spiele-Engine für die mobile Entwicklung und eine bessere Admob/Tools-Integration ist ein Muss, wenn es um den Export auf Android und mobile Plattformen geht.

Bedeutet dies auch, dass auch der iOS-Export verbessert wird? Zumindest in naher Zukunft.

Stimme für Vorschlag 2: Einige Bibliotheksintegration erforderlich, um apk mit anwendungsspezifischen Dateien wie google-services.json für Firebase oder strings.xml-Anpassung für Facebook-API neu zu erstellen. Auf Godot 2 hatte ich den Patch SConstruct/SCsub/methods.py und einige Vorlagendateien, um einige lib richtig zu integrieren.

Hier scheint es größtenteils Einigkeit zu geben. Ich denke, APK-Hacking muss verschwinden, und Exportvorlagen sollten sich so ziemlich im Android-Verzeichnis befinden, bevor Gradle ausgeführt wird.

Jemand bereit, einen Vorschlag oder eine PR für Option 2 zu machen? :)

Nun, im Moment habe ich viel Mühe beim Hinzufügen des Shares und der Admob-Module, weil im Moment ein Fehler in der get_data-Methode aus der Textur besteht, so nach dem Kompilieren und Sie verlieren sonst.

Außerdem muss ich eine bestimmte Konfiguration haben, damit alles mit Java, Gradle und anderem zusammenarbeitet, was in Ordnung ist, aber schwer ist.

Auch zu wissen, welche Shader-Methoden verfügbar sind und eine flüssigere Physik haben, wäre großartig, da ich viele Dinge neu schreiben muss, um die Position zu ändern, anstatt einfache Geschwindigkeiten anzuwenden, da sich einige Probleme in der 3.1 ändern werden, so dass eine Seite mit Tipps zu Android wäre auch ein großer Schritt sein.

Die Nummer 2 mit einigen Kontrollkästchen zur Optimierung für Android wäre also großartig.

Natürlich schätze ich den Aufwand, der mit der Schaffung all dieser Exportumgebung verbunden ist.

Nummer 2 scheint sauberer zu sein, daher denke ich, dass es besser ist, als weiter an einem Hack zu arbeiten, der zukünftige Probleme mit sich bringen könnte.
Meine einzige Sorge ist die Bereitstellungszeit. Derzeit ist das Testen auf Android sehr schnell, es hängt im Wesentlichen davon ab, wie groß Ihr Vermögen ist. Wird Option 2 die Bauzeit stark beeinträchtigen?
Auf jeden Fall denke ich, dass es der richtige Weg ist. Es wäre eine Sache, sich zum Testen mehr auf die Szenen- / Skriptsynchronisierung zu verlassen.

Vorschlag 2 ist viel besser, da Google Play immer erfordert, dass die APK mit dem neuesten Android-SDK erstellt wird.

Und auch GDnative ist schmerzhaft, wenn ich versuche, IAP und Anzeigen von Drittanbietern von Amazon, Leadbolt usw. zu integrieren.

Vorschlag 2 auf jeden Fall.

Ähnliche Ansätze werden bereits in einigen großen Projekten wie Cordova und Flutter verwendet . Eine großartige Option wäre die Möglichkeit, das Projekt in Android Studio zu öffnen, wenn der Benutzer mehr Kontrolle über die APK-Erstellung haben möchte.

Option 2 scheint sauberer und mehr wie der Rest von Godot zu sein ... dh richtig gemacht.

Ich habe gerade den Schmerz durchgemacht, den Android-Export zum Laufen zu bringen. Am schwierigsten war es, die richtigen (Versionen von) Tools zu installieren; Die Konfiguration in Godot war einfach.
In meinem Buch ist es immer noch ein Schritt in die richtige Richtung, wenn es mit einem ähnlichen Aufwand verbunden ist, die richtigen Tools zu installieren, also stimme ich auch für #2.
Ich teile Bedenken hinsichtlich der Geschwindigkeit des Starts auf Android zum Debuggen, aber wenn ich am Ende nicht im Store veröffentlichen kann, ist das ein großes Problem, das angegangen werden muss. Ich muss wissen, dass der Store verfügbar sein wird, wenn ich zur Veröffentlichung bereit bin.

Definitiv #2 :)

Ich bin für Option 2 - die Installation des Android-SDK ist kein Problem und eröffnet viele andere Möglichkeiten.

Auf hoher Ebene scheint es ähnlich zu sein, wie Flutter Dinge tut, https://github.com/flutter/buildroot

Bedeutet die Option #2, dass wir die gesamte Engine mit C++- und Java-Code kompilieren müssen, um jedes Mal eine Android-APK-Datei für jedes Projekt zu exportieren?

Das wäre eine Katastrophe! Cocos Creator verwendet einen so schrecklichen Workflow.

@Geequlim Wenn ich das richtig verstehe, nicht C++, sondern Java.

Ich bin für Option Nr. 1 .Wenn ich einige Experimente durchführe oder einen Workflow debugge.Ich möchte nicht, dass ein solches Android-Bundle ein kleines Projekt debuggt.Behalte den Hack-Weg.Lass den Progammer den SDK-Workflow ausführen.

@Geequlim Ja, das ist auch meine Sorge. Wenn das Projekt jedes Mal neu kompiliert und in eine APK gepackt werden muss, habe ich das Gefühl, dass es ziemlich lange dauern wird.

@Geequlim @JFonS Eine vollständige Neukompilierung ist nicht erforderlich. Gradle hat viele Build-Zeitoptimierungen, so dass eine vollständige Kompilierung (c++ und Java) nur zum ersten Mal benötigt wird. Wenn Sie ein Plugin von Drittanbietern anwenden, ändert es auch den Java-Code, Gradle sieht, dass einige Dateien geändert und eine Abhängigkeit hinzugefügt wurde, und kompiliert nur geänderte Teile neu. Die meiste Zeit kopiert der Exporter Projektressourcen (Szenen, Skripte und Assets) in den Android-Ordner, Gradle packt eine APK aus zwischengespeicherten Quelldateien und diesen Ressourcen und führt sie auf einem Android-Gerät aus. Dies sollte nicht so viel Zeit in Anspruch nehmen.

@veloc1 Wir müssen immer noch die Loch-Engine für jedes Projektereignis für Bibliothek kompilieren, oder?

Der Gradle-Build-Workflow kann aus vielen Gründen unterbrochen werden:

• Die falsche SDK-Version wurde installiert.
• Die Abhängigkeiten können bei einer schlechten Netzwerkverbindung nicht heruntergeladen werden (das ist in China wirklich oft ohne Proxy).
• Der verfügbare Arbeitsspeicher des Computers beträgt weniger als 4 GB, aber einige SDKs von Drittanbietern müssen multiDexEnabled true zum Kompilieren aktivieren.
• ...

Und die Gradle wird nicht immer wie erwartet neu kompiliert.

Vielleicht irre ich mich, aber ich denke, #1 ist ein Glas Milch und #2 ist eine Milchkuh. Hab ich recht?

@Geequlim Wie ich mir vorstellen kann, müssen wir nicht wirklich die gesamte Engine neu kompilieren. Der gesamte Code kann in eine Bibliothek gepackt werden (also sollte jede Godot-Version die Android-Bibliothek mit der Godot-Engine neu erstellen). Wenn das Projekt erstellt wurde, kann der Godot-Editor die Android-Vorlage im Ordner "android" mit einer Java-Klasse und der Gradle-Datei mit der enthaltenen Godot-Engine-Android-Abhängigkeit von Maven entpacken (React Native funktioniert auf die gleiche Weise, wie ich mich erinnere).
Auf diese Weise können wir die Build-Zeit und die Speichernutzung minimieren und die Einfachheit des Android-Projekts verbessern.

Aber du hast recht, das bringt auch viele Einschränkungen mit sich.

Und einige Kommentare zu Ihrer Liste möglicherweise kaputter Dinge:

• SDK spielt keine große Rolle, da die Godot-Engine nicht viele Funktionen des neuen SDK verwendet. Für einfache Projekte ist fast jedes SDK in Ordnung. Auch das Herunterladen geeigneter SDKs kann automatisiert werden.
• Abhängigkeitsproblem, das Sie beschrieben haben, kann schmerzhaft sein. Wir können Abhängigkeiten mit Links von Maven einschließen, aber wir können auch Bibliotheksdateien (jar oder aar) im Projektordner ablegen und Abhängigkeiten verwenden, sodass Sie bei einer schlechten Netzwerkverbindung alle Abhängigkeiten an anderen Orten herunterladen, auf einen USB-Stick legen und verschieben können zu projizieren. Dies sollte jedoch in der Exportdokumentation ausführlich beschrieben werden.
• Multidex und Speicher beeinflussen sich nicht gegenseitig. Multidex kann immer im Vorlagenprojekt aktiviert werden. Das Gedächtnis wird eine stärkere Einschränkung sein. Ich kann nicht genau sagen, welche Menge an verfügbarem Speicher dafür benötigt wird, aber dieser sollte größer als 2 GB sein.

Und es gibt eine Zusammenfassung der Änderungen, die in Godot implementiert werden sollten (so wie ich oben beschrieben habe):

• Erstellen Sie eine Android-Bibliothek, die Engine und Plugin-System enthält. (Das ist schwer)
• Automatisieren Sie die Erstellung der Android-Bibliothek bei der Veröffentlichung und stellen Sie sie auf Maven.
• Erstellen Sie eine Android-Projektvorlage.
• Sammeln Sie eine Reihe von Skripten, um die Umgebung zu validieren, laden Sie Gradle, Java, Android Sdk . herunter
• Nehmen Sie Änderungen in der Godot-Engine vor. Wenn der Benutzer ein Projekt auf einem Android-Gerät ausführt, sollte die Engine alle Ressourcen kopieren und die Gradle-Aufgabe aufrufen, um das Projekt zu erstellen und auszuführen.
• Dokumentation für alle Dinge.

@Geequlim

Bedeutet die Option #2, dass wir die gesamte Engine mit C++- und Java-Code kompilieren müssen, um jedes Mal eine Android-APK-Datei für jedes Projekt zu exportieren?

Nein.. Ich sehe keinen wirklichen Grund dafür. Dies ist jetzt der Fall, aber der neue Workflow würde das Android-Projekt einfach in den vorgefertigten Zustand bringen (mit den Godot .so-Dateien). Das Hinzufügen externer Module, die Sie in anderen Verzeichnissen (wie Admob) heruntergeladen haben, ist mit Gradle wirklich einfach. Sie könnten also theoretisch diese Unterstützung einfach aus der Asset-Bibliothek herunterladen und es wird auf magische Weise funktionieren.

@veloc1

Es _gibt_ bereits ein Plugin-System, das Gradle-Build modifiziert, um Dinge hinzuzufügen, die höchstwahrscheinlich keine oder nur geringe Änderungen benötigen.

Der neue Workflow "Ausführen/Exportieren" würde bestehen aus:
1) Gradle bauen (wenn keine Änderungen vorgenommen wurden, wird nichts getan, das sollte ziemlich schnell gehen
2) Führen Sie wahrscheinlich die aktuelle Exportlogik aus, um das APK zu entpacken und die Dateien, gdnative-Plugins usw. hinzuzufügen und erneut zu zippen.

Ebenso könnte Godot vor dem Erstellen die erforderliche Bearbeitung an AndroidManifest.xml vornehmen (Namen ändern, Berechtigungen hinzufügen und andere Dinge), Symbole hinzufügen usw., um es Benutzern zu erleichtern, die möglicherweise immer noch nicht mit der Funktionsweise von Manifest einverstanden sind. Das Gute daran ist, dass dies nicht destruktiv geschieht, sodass Sie Manifest immer noch Ihre eigenen Sachen hinzufügen können.

@reduz

Ich war mir nicht sicher, ob die Unterzeichnung auf Godot-Seite erfolgen sollte. Das Android-Plugin für Gradle hat eine großartige Funktion dafür https://developer.android.com/studio/build/build-variants#signing . Beim Export überprüfen wir also nur den Schlüsselspeicher und die Passwörter, und Gradle erledigt die ganze Arbeit.

Und für Manifest. Wenn ich von Plugin-System sage, meine ich genau das: Jedes Plugin deklariert Berechtigungen, und beim Export sammeln wir alle enthaltenen Plugins und generieren AndroidManifest.xml. Auf diese Weise können wir auch Bibliotheksdienste und BraodcastReceiver einbinden.

Für Ressourcen wie Name und Symbol – was ist mit Platzhalterressourcen, und wenn sie in den Projekteinstellungen konfiguriert sind, ersetzen Sie einfach Platzhalter durch Werte aus den Projekteinstellungen? Endbenutzer werden also all diese schrecklichen Android-Dinge überhaupt nicht sehen.

Wird es mit dem neuen Export-Workflow möglich sein, das Game-Pack außerhalb des APK zu haben, anstatt es erneut zu komprimieren (Ordner oder .pck)?

@LinuxUserGD ist dafür nicht Apk Expansion (.obb)?
es ist schon da.

Was auch immer wir tun, es sollte flexibel sein und sicherstellen, dass es nicht wie bei der Einheit ist. Es ist ein Durcheinander, wenn wir mehrere Plugins mischen und abgleichen, die dieselben Abhängigkeiten haben.

Was das Manifest betrifft, möchte ich es auch manuell bearbeitbar halten.

Der aktuelle Build ist sehr flexibel, sodass ich die Vorlage bearbeiten und hinzufügen/löschen kann, was ich will, und nichts stört beim Erstellen der Vorlagen.

Ich denke, so etwas wie ein Hybridsystem wird funktionieren?

Vorschlag 2 klingt ohne Zweifel besser, sauberer und "richtiger".
@reduz Nachteile von Vorschlag 2? Ich kann mir vorstellen, dass es nur dann umständlich ist, wenn kein schnelles Internet verfügbar ist.
Godot könnte wie Android Studio wahrscheinlich sehr einfach (als Textdatei?) eine Liste der benötigten Pakete an sdkmanager übergeben, um sie herunterzuladen https://developer.android.com/studio/command-line/sdkmanager

Vorschlag 2, auf jeden Fall.

Vorschlag #2. Die Installation des Android SDK ist heutzutage ganz einfach!

@reduz , ich

Vorschlag 2. Gradle ist ebenfalls dokumentiert, damit wir mehr Ressourcen haben. Die meisten mobilen Entwickler haben sowieso Android SDK irgendwo auf ihrem System installiert.

Vorschlag 2

Wann wird das umgesetzt, irgendwelche Infos oder so
@akien-mga Ist es immer noch der Meilenstein für 3.1?

Laut diesem Blogpost von godotengine.org/news vom 23. November 2018:

Godot 3.1 wird eine Version sein, die einen viel größeren Bereich von dem abdeckt, was unsere Benutzer erwarten, daher brauchen wir nicht mehr so ​​viel neue Funktionen. Das einzige wirklich große Feature, das nach 3.1 geplant ist, ist die Portierung des Renderings auf Vulkan...

Nun, das Feature der aktuellen Ausgabe scheint genügend Aufmerksamkeit auf sich gezogen zu haben, um für 3.2 in Betracht gezogen zu werden. Gibt es einen Grund, warum es im Blogpost nicht angesprochen wurde?

Wir haben keine Zeit mehr für eine große Überarbeitung des Android-Exports, also wird dies für 3.2 sein.

Da Android eine Vielzahl von Plugins und Datenbanken von Drittanbietern anbietet (Firebase, Cloud, ML), scheint es eine gute Idee zu sein, Android sdk / jdk / ndk für eine nachhaltige Entwicklung zu installieren. Der Grund dafür ist, dass sich die Android-Bibliotheken möglicherweise mit den dortigen Versionen ändern Einige Abhängigkeitsbibliotheken fehlen beim Exportieren, ohne dass eine ordnungsgemäße Version des SDK installiert ist. Dieser Ansatz erfordert jedoch im Gegenteil, dass der Benutzer oder Endentwickler das gesamte Produkt nur zum Testen an die Android-Plattform sendet, was einen Zeitaufwand bedeutet .Ein alternativer Ansatz kann wie das Erstellen einer Anwendung für Android erfolgen, die das Android Studio SDK und das JDK auf dem Gerät zum Testen verwendet. Der Benutzer kann einfach die Anwendung ausführen, eine Verbindung mit dem Computer herstellen und dann das Spiel im Godot-Editor selbst und sehen Sie sich die Änderungen auf dem Telefon oder Mobiltelefon an. Das Mobiltelefon verwendet das Android-SDK des Computers über seinen Port und was Angebot1 betrifft, gibt es wenig Zeitaufwand und ist auch fast transparent, es ist kein Hacken erforderlich.
Da es bestimmte Bibliotheken im Android-Kernel-Code gibt, die, wenn sie nicht installiert werden, zu Laufzeitabstürzen führen, meistens mit java.lang.io.Exceptions Versionen von Android, die jeweils mehr Abhängigkeiten aufweisen als die vorherigen. Vorschlag 2 kann durch einfaches Installieren von Android sdk auf dem Computer und Verwendung einer (noch zu erstellenden) Android-App von den Entwicklern erstellt werden, um ihre Spiele sofort auf dem Handy zu überprüfen; eher wie eine Fernbedienung. Für den vollständigen Aufbau einer App oder den Export kann der verallgemeinerte Ansatz 2 gewählt werden.
Was die Vorlagen betrifft, können adaptive Vorlagen für Android8+ verwendet werden. Um die Erstellungszeit der Anwendung (mit der Verwendung des SDK) zu verkürzen, können außerdem Engine-Optimierungen zur Verbesserung von Garbage Collectors und auch Optimierungen wie der strukturbasierte Ansatz vorgenommen werden Gebraucht.
Dies ist ganz meine Perspektive. Wenn es in Ordnung ist, habe ich einige Pläne für die Anwendung (Android), die das SDK des Geräts zum sofortigen Erstellen des Anwendungsspiels verwendet.

Google Play akzeptiert jetzt Apps, die im neuen Android App Bundle (AAB) -Format hochgeladen wurden.

Dieses Format ermöglicht es Google Play, APKs für viele Gerätetypen dynamisch zu generieren, und eine der Funktionen, die sich direkt auf in Godot erstellte Spiele auswirken, ist das Packen von APKs, die nur die native Bibliothek enthalten, die für diese bestimmte CPU-Architektur erstellt wurde.

Dies bedeutet, dass die Downloadgröße erheblich verbessert werden kann, indem das APK, das von einem x86-Gerät heruntergeladen wird, nur die x86-Bibliothek enthält, das von einem arm64 heruntergeladene nur die arm64-Bibliothek und so weiter und so weiter.

Ich glaube, dass jeder Ansatz, den Godot verfolgt, dieses neue Verpackungsformat unterstützen sollte, aber ich weiß nicht, wie einfach es ist, ein AAB-Paket im Gegensatz zu einem APK-Paket zu "hacken", das im Grunde eine ZIP-Datei ist.

Dies bedeutet, dass die Downloadgröße erheblich verbessert werden kann, indem das APK, das von einem x86-Gerät heruntergeladen wird, nur die x86-Bibliothek enthält, das von einem arm64 heruntergeladene nur die arm64-Bibliothek und so weiter und so weiter.

Beachten Sie, dass dies bereits möglich ist, jedoch manuelle Arbeit erforderlich ist, indem Sie ein APK pro Architektur erstellen und es dann mithilfe der Unterstützung für mehrere APKs auf Google Play hochladen .

Dies wurde von #27781 behoben, das im Grunde eine Mischung aus 1 und 2 implementiert. Das alte System wird für die Bereitstellung mit einem Klick beibehalten, aber Versionen werden jetzt mit der vorkompilierten Vorlagenquelle geliefert, die in einem neuen APK mit benutzerdefinierten Modulen neu kompiliert werden kann /manifestierte Änderungen/etc. Gradle verwenden.