Godot: Androidエクスポートの将来について

私は提案2に投票します。

apkエクスポートメカニズムのリファクタリングについて話している場合、GodotEngineに欠けている機能を知ることが重要だと思います。

1. APK動的コンテンツ：より軽いapkを生成できるようにする
2. Google Instant App ：ユーザーはゲーム/アプリをインストールせずにプレイできます
3. アダプティブアイコン：最新のAndroid（AndroidPおよび一部のAndroid7.1以降）にはアダプティブアイコンが必要です。
4. クラッシュハンドラー：GodotEngineにクラッシュするAPIがありません。 つまり、Godot Engineがクラッシュしたときに、ユーザーがお気に入りのクラッシュ分析アプリケーションに送信できるようにする関数を公開する必要があります。
5. ANRがクラッシュするようになったため、ゲームの開始時にUIThreadの代わりにAsyncTaskを使用する必要があります。

エクスポートメカニズムをリファクタリングしている間、これらの機能もGodotEngineに追加する必要があります。

私の投票=> 2

多分ハイブリッド？
デバッグモードでのテスト用にsdkが見つからないが、リリースパッケージ用のSDKのインストールが必要な場合は、古いアプローチを使用してください。 SDKが見つかった場合は、デバッグおよびリリースモードで使用します。
あなたがアンドロイドで働いているなら、それは常に必要条件なので、私は2票を投じます。

@xsellierこの議論のポイントは、OPで提案されたものを超えないことを感謝します。誰かがあなたが言及したことを実装したい場合は問題ありませんが、脱線しないでください。

@HeartoLazor維持するコードが少ない

私も提案2に投票します。

Androidツールをセットアップすると、新しいSDKのダウンロードや外部ライブラリの構築など、多くの作業が非常に簡単になります。

また、サードパーティのライブラリを追加する方が簡単です。

オプション2に投票します

オプション2の方がはるかに便利に聞こえます。 Gradleは優れたツールであり、ライブラリの追加と構築プロセスの管理は、現在のフローよりもはるかに簡単です。

私の投票は提案2です

私はかつて2.xのアドオンとしてAndroidテンプレートクリエーターを作成していました
https://github.com/vinod8990/godot-addon-aetc

しかし、私は提案2に投票します。
標準を作成する場合は、モジュールがapiも削除することを確認する必要があります。 （Unityの場合のように）ネイティブプラグインを削除する必要がある場合、これは巨大なPIAです。

投票->提案2：最も論理的な選択のようです。Godotは現在および近い将来、モバイル開発に最適なゲームエンジンであり、Androidおよびモバイルプラットフォームへのエクスポートに関しては、AdMobとツールの統合を改善する必要があります。

これは、iOSのエクスポートも改善されることを意味しますか？ 少なくとも近い将来。

提案2に投票する：Firebase用のgoogle-services.jsonやFacebookapi用のstrings.xmlのカスタマイズなどのアプリケーション固有のファイルでapkを再構築するために必要なライブラリ統合。 Godot 2では、いくつかのlibを適切に統合するために、パッチSConstruct / SCsub /methods.pyといくつかのテンプレートファイルがありました。

ここではほとんど合意があるようです。したがって、APKのハッキングをなくす必要があると思います。また、Gradleを実行する前に、エクスポートテンプレートはほぼAndroidディレクトリになっているはずです。

オプション＃2の提案またはPRを行う人はいますか？ :)

さて、現時点では、共有モジュールとAdmobモジュールを追加するのに多くの苦労をしました。現時点では、テクスチャからのget_dataメソッドにバグがあるため、コンパイルした後、失うことになります。

また、Java、gradleなど、すべてが連携して機能するように特定の構成を用意する必要があります。これは問題ありませんが、難しいことです。

また、3.1で変更されるいくつかの問題があるため、Androidでヒントのあるページを作成すると、単純な速度を適用する代わりに、位置を変更するために多くのことを書き直す必要があるため、使用可能なシェーダーメソッドとより流動的な物理特性を知ることは素晴らしいことです。また、大きな一歩になります。

したがって、Android用に最適化するためのいくつかのチェックボックスを備えた＃2は素晴らしいでしょう。

もちろん、このすべてのエクスポート環境を作成する努力に感謝します。

2番目はきれいに見えるので、将来の問題を引き起こす可能性のあるハックに取り組み続けるよりも良いと思います。
私の唯一の心配は展開時間です。 現在、Androidでのテストは非常に高速で、基本的にアセットの大きさに依存します。 オプション2はビルド時間に深刻な影響を与えますか？
いずれにせよ、私はまだそれが行く方法だと思います。 テストのためにシーン/スクリプトの同期にもっと依存することになるでしょう。

Google Playでは常にapkを最新のAndroidSDKでビルドする必要があるため、提案2の方がはるかに優れています。

また、GDnativeは、AmazonやLeadboltなどのサードパーティのIAPや広告と統合しようとすると苦痛になります。

確かに提案2。

同様のアプローチは、 CordovaやFlutterなどのいくつかの大きなプロジェクトですでに使用されています。 ユーザーがAPKの作成をより細かく制御したい場合は、AndroidStudioでプロジェクトを開くことができます。

オプション2はよりクリーンで、Godotの他の部分に似ているようです...つまり、適切に実行されます。

Androidのエクスポートを機能させるのに苦労しました。 最も苦労したのは、適切な（バージョンの）ツールをインストールすることでした。 Godotでの設定は簡単でした。
私の本では、それを正しく行うことが適切なツールをインストールするのと同じくらいの苦痛を伴う場合、それはまだ正しい方向への一歩なので、私も＃2に投票します。
デバッグのためにAndroidで起動する速度について懸念を共有していますが、最後にストアにリリースできない場合は、対処する必要のある大きな問題です。 リリースの準備ができたら、ストアが利用可能になることを知っておく必要があります。

間違いなく＃2 :)

私はオプション2を求めています-AndroidSDKのインストールは問題ではなく、他の多くの可能性を開きます。

大まかに言えば、Flutterが行う方法と似ているようです。https：//github.com/flutter/buildroot

オプション＃2は、プロジェクトごとにandroid apkファイルを毎回エクスポートするために、C ++とJavaコードを含むエンジン全体をコンパイルする必要があることを意味しますか？

それは惨事でしょう！ Cocos Creatorは、このようなひどいワークフローを使用しています。

@Geequlim私が正しく理解していれば、c ++ではなくjavaです。

私はオプション＃1を求めています。実験やデバッグのワークフローを行うとき。そのようなAndroidバンドルで小さなプロジェクトをデバッグしたくない。ハックを続けてください。プログラマーにSDKワークフローを任せてください。

@Geequlimええ、それも私の懸念です。 プロジェクトを毎回再コンパイルしてapkにパックする必要がある場合は、かなりの時間がかかると感じています。

@ Geequlim @ JFonS完全な再コンパイルは必要ありません。 Gradleには多くのビルド時間の最適化があるため、完全なコンパイル（c ++およびJava）が必要になるのは初めてです。 また、サードパーティのプラグインを適用すると、Javaコードが変更され、Gradleはいくつかのファイルが変更され、1つの依存関係が追加されたことを確認し、変更された部分のみを再コンパイルします。 ほとんどの場合、エクスポーターはプロジェクトリソース（シーン、スクリプト、アセット）をAndroidフォルダーにコピーし、Gradleはキャッシュされたソースファイルとこのリソースからapkをパックして、Androidデバイスで実行します。これにはそれほど時間はかかりません。

@ veloc1アセットライブラリからのテストデモ用に、プロジェクトイベントごとにホールエンジンをコンパイルする必要がありますか？

Gradleビルドのワークフローは、多くの理由で壊れている可能性があります。

• 間違ったバージョンのSDKがインストールされています。
• 依存関係は、ネットワーク接続が悪いとダウンロードできません（これは、プロキシがない中国では実際によくあることです）。
• マシンの使用可能なメモリは4GB未満ですが、一部のサードパーティSDKはmultiDexEnabled trueをコンパイルできるようにする必要があります。
• ..。

また、gradleは常に期待どおりに再コンパイルされるとは限りません。

私は間違っているかもしれませんが、＃1はミルクのグラスで、＃2は乳牛だと思います。 私は正しいですか？

@Geequlim想像できるように、エンジン全体を再コンパイルする必要はありません。 すべてのコードをライブラリにパックできます（したがって、Godotのリリースごとに、Godotエンジンを使用してAndroidライブラリを再構築する必要があります）。 プロジェクトが作成されると、Godotエディターは1つのJavaクラスを含む「android」フォルダー内のandroidテンプレートと、mavenからのGodotエンジンandroid依存関係が含まれるGradleファイルを解凍できます（React Nativeは、私が覚えているように同じように機能します）。
このようにして、ビルド時間とメモリ使用量を最小限に抑え、Androidプロジェクトのシンプルさを向上させることができます。

しかし、その通りです。これには多くの制限も含まれます。

そして、壊れている可能性のあるもののリストへのいくつかのコメント：

• Godotエンジンは新しいSDKの多くの機能を使用しないため、SDKはあまり役割を果たしません。 単純なプロジェクトの場合、ほとんどすべてのSDKで問題ありません。 また、適切なSDKのダウンロードを自動化できます。
• あなたが説明した依存関係の問題は、苦痛になる可能性があります。 Mavenからのリンクに依存関係を含めることができますが、プロジェクトフォルダーにライブラリファイル（jarまたはaar）を配置して依存関係を使用することもできるため、ネットワーク接続が悪い場合は、他の場所にすべての依存関係をダウンロードしてUSBスティックに配置して移動できます映し出すために。 ただし、これはエクスポートドキュメントで詳しく説明する必要があります。
• マルチデックスとメモリは互いに影響しません。 Multidexは、テンプレートプロジェクトで常に有効にできます。 メモリはより強い制限になります。 そのために必要な使用可能なメモリの量を正確に言うことはできませんが、これは2GBを超える必要があります。

そして、Godotで実装する必要のある変更のまとめがあります（上記の方法によると）：

• エンジンとプラグインシステムを含むAndroidライブラリを作成します。 （これは難しい）
• リリース時にAndroidライブラリのビルドを自動化し、Mavenに配置します。
• Androidプロジェクトテンプレートを作成します。
• 環境を検証するための一連のスクリプトを収集し、Gradle、Java、AndroidSdkをダウンロードします
• Godotエンジンに変更を加えると、ユーザーがAndroidデバイスでプロジェクトを実行するときに、エンジンはすべてのリソースをコピーし、Gradleタスクを呼び出してプロジェクトをビルドして実行する必要があります。
• すべてのもののドキュメント。

@Geequlim

オプション＃2は、プロジェクトごとにandroid apkファイルを毎回エクスポートするために、C ++とJavaコードを含むエンジン全体をコンパイルする必要があることを意味しますか？

いいえ。その理由はよくわかりません。 これは現在のケースですが、新しいワークフローでは、Androidプロジェクトがビルド済みの状態になります（Godot .soファイルを使用）。 他のディレクトリ（Admobなど）にダウンロードした外部モジュールをGradleで追加するのは非常に簡単なので、理論的にはアセットライブラリからそのサポートをダウンロードするだけで、魔法のように機能します。

@ veloc1

Gradleビルドを変更して何かを追加するプラグインシステムはすでに存在しますが、ほとんどの場合、変更は必要ないか、ほとんど変更する必要はありません。

新しい「実行/エクスポート」ワークフローは、次のもので構成されます。
1）Gradleの構築（変更が発生しなかった場合、何も実行されません。かなり迅速に実行できるはずです。
2）現在のエクスポートロジックを実行してAPKを解凍し、ファイル、gdnativeプラグインなどを追加して、再度zipする可能性があります。したがって、署名はGradleではなくGodotによって実行されます。

同様に、Godotは、ビルドする前にAndroidManifest.xmlに必要な編集（名前の変更、権限の追加など）を行ったり、アイコンを追加したりして、マニフェストの動作にまだ慣れていないユーザーでも簡単にできると思います。 良い点は、これが非破壊的な方法で行われるため、マニフェストに独自のものを追加できることです。

@reduz

署名がGodot側にあるべきかどうか確信が持てませんでした。 Gradle用のAndroidプラグインには、 https： //developer.android.com/studio/build/build-variants#signingの優れた機能があるため、エクスポートでは、キーストアとパスワードを確認するだけで、Gradleがすべての作業を行います。

そしてマニフェストのために。 プラグインシステムについて言うとき、私はまさにそのことを意味します。各プラグインはアクセス許可を宣言し、エクスポート時に、含まれているすべてのプラグインを収集してAndroidManifest.xmlを生成します。 また、この方法で、ライブラリサービスとBraodcastReceiversを含めることができます。

名前やアイコンなどのリソースの場合-プレースホルダーリソースはどうですか？プロジェクト設定で構成されている場合は、プレースホルダーをプロジェクト設定の値に置き換えるだけですか？ したがって、エンドユーザーはこのひどいアンドロイドのすべてをまったく見ることはありません。

新しいエクスポートワークフローで、ゲームパックを再度圧縮する代わりにAPKの外に置くことは可能ですか（フォルダーまたは.pck）？

@LinuxUserGDはそのためのApk Expansion （。obb）ではありませんか？
それはすでにそこにあります。

私たちが何をするにしても、それは柔軟でなければならず、それが団結のやり方のようではないことを確認する必要があります。 同じ依存関係を持つ複数のプラグインを組み合わせて使用​​すると、混乱します。

マニフェストについても、手動で編集できるようにしたいと思います。

現在のビルドは非常に柔軟性があり、テンプレートを編集したり、必要なものを追加/削除したりできます。テンプレートのビルド時に干渉することはありません。

ハイブリッドシステムのようなものが機能すると思いますか？

間違いなく、提案2はより良く、よりクリーンで、より「適切」に聞こえます。
@reduz提案2の短所？ 高速インターネットが利用できない場合にのみ面倒だと思います。
Godotは、Android Studioのように、おそらく非常に簡単に（テキストファイルとして？）ダウンロードするために必要なパッケージのリストをsdkmanagerに渡すことができますhttps://developer.android.com/studio/command-line/sdkmanager

確かに提案2。

提案＃2。 最近のAndroidSDKのインストールは非常に簡単です。

@reduz 、私は提案2に投票します。しかし、＃18141を忘れないでください

提案2.Gradleも文書化されているため、より多くのリソースがあります。 ほとんどのモバイル開発者は、とにかくシステムのどこかにandroidsdkをインストールします。

提案2

これはいつ実装されるのか、情報など
@ akien-mgaそれはまだ3.1のマイルストーンですか？

2018年11月23日からのgodotengine.org/newsからの

Godot 3.1は、ユーザーが期待するもののはるかに広い表面積をカバーするリリースになるため、新しい機能はそれほど必要ではなくなりました。 3.1以降に計画されている唯一の本当に大きな機能は、レンダリングをVulkanに移植することです...

さて、現在の問題の機能は、3.2で検討するのに十分な注目を集めているようです。 ブログ投稿に追加されなかった理由はありますか？

Androidエクスポートの大幅なリファクタリングに時間がなくなったため、これは3.2になります。

androidはさまざまなサードパーティのプラグインとデータベース（Firebase、Cloud、ML）を提供しているため、継続的な開発のためにandroid sdk / jdk / ndkをインストールすることをお勧めします。適切なバージョンのSDKをインストールせずにエクスポートを行うと、一部の依存関係ライブラリが欠落しますが、逆に、このアプローチでは、テストのためにユーザーまたはエンド開発者が製品全体をAndroidプラットフォームに出荷する必要があり、時間のオーバーヘッドが発生しますテスト用のデバイスでandroidstudio sdkとjdkを使用するandroidのアプリケーションを作成するなど、別のアプローチを行うことができます。ユーザーは、ケーブルポートを使用してコンピューターに接続し、アプリケーションを実行して、ゲームを実行できます。 godotエディター自体と電話またはモバイルで変更を表示します。モバイルはそのポートを介してコンピューターのAndroidSDKを使用し、Proposal1に関する限り、時間のオーバーヘッドはほとんどありません。 また、ほぼ透過的であり、ハッキングは必要ありません。
インストールされていない場合、ほとんどjava.lang.io.exceptionsでランタイムクラッシュにつながる特定のライブラリがAndroidカーネルコードにあるためです。提案1が優先される場合、それは別々にハッキングすることを意味するという問題もあります。提案2は、コンピューターにandroid sdkをインストールし、開発者がandroidアプリ（ビルド予定）を使用してモバイルでゲームを即座にチェックするだけで、それぞれ以前のバージョンよりも多くの依存関係を持つandroidのバージョンを作成できます。 リモコンのようなものです。アプリを完全に構築したり、一般化されたアプローチ2をエクスポートしたりする場合に使用できます。
テンプレートの問題に関しては、android8 +アダプティブテンプレートを使用できます。さらに、アプリケーションの構築時間を短縮するために（sdkを使用して）、ガベージコレクターの強化に関するエンジンの最適化や構造体ベースのアプローチなどの最適化を行うことができます。中古。
これは完全に私の見解です。問題がなければ、アプリケーションゲームのインスタントビルドにデバイスのSDKを使用するアプリケーション（Android）に関していくつかの計画を立てています。

Google Playは、新しいAndroid App Bundle（AAB）形式でアップロードされたアプリを受け入れるようになりました。

この形式により、Google Playは多くのデバイスタイプのAPKを動的に生成できます。また、Godotで作成されたゲームに直接影響する機能の1つは、その特定のCPUアーキテクチャ用に作成されたネイティブライブラリのみを含むAPKをパックすることです。

つまり、x86デバイスでダウンロードされたAPKにx86ライブラリのみが含まれ、arm64でダウンロードされたAPKにarm64ライブラリのみが含まれるなど、ダウンロードサイズを大幅に改善できます。

Godotが採用するアプローチはすべて、この新しいパッケージ形式をサポートするはずだと思いますが、基本的にZIPファイルであるAPKパッケージとは対照的に、AABパッケージを「ハッキング」するのがどれほど簡単かはわかりません。

つまり、x86デバイスでダウンロードされたAPKにx86ライブラリのみが含まれ、arm64でダウンロードされたAPKにarm64ライブラリのみが含まれるなど、ダウンロードサイズを大幅に改善できます。

これはすでに可能ですが、アーキテクチャごとに1つのAPKを作成し、複数のAPKサポートを使用してGoogle Playにアップロードすることにより、手動で作業する必要があることに注意してください。

これは、基本的に1と2の組み合わせを実装する＃27781によって修正されました。古いシステムはワンクリックデプロイ用に保持されますが、リリースには、カスタムモジュールを使用して新しいAPKで再コンパイルできるコンパイル済みのテンプレートソースが付属しています。 /マニフェストの変更/など。 gradleを使用します。