Android zipCustomBuild command should produce exactly what is expected

jasonwinterpixel commented 2 years ago

Describe the project you are working on

Tank Kings, a cross platform 2D battle royale with a custom netcode solution allowing fast paced server authoritative multiplayer with client side prediction and rollback, and a CI/CD system based on github actions to allow us to rapidly iterate

Describe the problem or limitation you are having in your project

We are trying to write a CI/CD pipeline to produce an android app bundle using a custom build of godot containing custom c++ modules. This proposal is about a simple change that could be made to the build system's gradlew zipCustomBuild command that would lower the barriers to creating this CI/CD pipeline and would increase the correctness of the version check that godot performs when you attempt to export.

The current process for exporting an android app bundle using a custom build of godot is to run gradlew zipCustomBuild but then installing that custom build involves generating a version file and unzipping the contents into a specifically named nested folder. This logic is implemented in ExportTemplateManager::install_android_template(), which is not exposed to script or cmd line. This function is only called from Project -> Install Android Build Template, which by default will prompt the user to download and install the default managed export templates.

To install a custom android export template, you must either rename and move your androud_source.zip to where the default managed export templates are downloaded to and use the UI to click Project -> Install Android Build Template, or you must reverse engineer the installation process.

Specifically the file system requires the contents of android_source.zip to be in res://android/build and it requires a res://android/.build_version file with the exact contents of the current godot's version.

For CI/CD we cannot use the UI to click Project -> Install Android Build Template.

We must use shell scripts to 'install' the custom android export template by generating the res://android/.build_version file and unzipping the output of gradlew zipCustomBuild into res://android/build.

These 2 extra steps were hard to discover, required us to search the source code of Godot and then reimplement the behaviour of ExportTemplateManager::install_android_template() in shell scripts.

This proposal is about a simple change to gradlew zipCustomBuild which could improve this process for future developers (and will also increase the correctness of the version check)

Describe the feature / enhancement and how it helps to overcome the problem or limitation

This file system expectation is undocumented and could be made simpler by altering the gradlew zipCustomBuild to produce exactly what is expected to be in res://android

The output of zipCustomBuild should exactly match what is expected to be in res://android:

android/
  .build_version
  build/

This would lower the number of undocumented steps required by a CI/CD pipeline to generate an Android AAB, and it would increase the correctness of the version check itself.

Currently, the android/.build_version is created by the godot editor's installation of android_source.zip in ExportTemplateManager::install_android_template which is triggered by the UI action of clicking on Project -> Install Android Export Template. This step is only accessible from the Godot UI which is not conducive to CI/CD pipelines.

This also means that the version check on export is actually checking if the current version of godot matches the version of godot which installed the export template, not the version of godot that generated the export template. The version of godot which generated the export template is more relevant than the version of godot which installed the template.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Alter the gradlew zipCustomBuild to output a zip containing:

android/
  .build_version
  build/

If this enhancement will not be used often, can it be worked around with a few lines of script?

It can be worked around via shell scripting but it requires the development team to manually discover the godot exporter's file system expectations, this is a complex process to reverse-engineer.

Is there a reason why this should be core and not an add-on in the asset library?

Its a change to the build system for android

m4gr3d commented 2 years ago

@jasonwinterpixel The proposal looks fine to me; looking forward to the PR!

AdrKacz commented 1 year ago

@jasonwinterpixel do you any updates regarding your fix? ☺️

godotengine / godot-proposals