Feature/android port

[psjuan97]

No description provided.

[Try]

Hi, @psjuan97 and thanks for PR!

It doesn't look as bad as was was expecting from android, however how do you handle AndroidManifest.xml / gradle / .java ? I'm pretty sure, that you shown manifest on discord discussion, but I don't see it in PR.

[Try]

Need to move into Tempest, as it's an implementation detail.

[Try]

Tempest::TextCodec::toUtf16

[psjuan97]

I have it in a separated project, when i know a good way to included i will push it

[Try]

Hi, @psjuan97 !

At this point we need to find a way to deal with "android-spaghetti" cause by gradle, java, and swarm of xml's

Logically, where we want to be:

• AndroidManifest.xml should be in root directory, same as Info.plist.in of iOS.
  • Same for icons eventually (minor thing, I don't want to focus on icons yet).
• gradle - essentially useless thing enforced by android. Need to remove/avoid/hide/minimize it
• Have special changes to root CMakeLists.txt is not acceptable. Proxy in android/app/cpp should be deleted.
• We don't need quirks like tempest_android_get_app - should be main as usual. But let's deal with build first.

To be clear, all above ^ it's a direction, where I think we want to end-up. It probably will take quite a work and several iterations to cleanup android build system issues.
I see two options to deal with gradle:

• Generate it on cmake configure step, same as for XCode project. Unfortunately cmake doesn't have such generator out of box AFAIK.
• Generate MSVC project. With AGDE plugin should be fine. However plugin is close-source owned by google and if any issue we would be able to only work around.
  Here is nice example on how MSVC project generation can look-like: https://github.com/lectorguard/Android-CMake-VisualStudio-Sample/tree/master
• Maybe non AGDE makefile project (this is a project template in MSVC) can be good option. This project typ supports custom build commands and suppose to be capable of debugging.
  But we would have to adjust it to newer NDK.

[psjuan97]

Hi @Try

What do you think about creating a new project for the "complex" platform that includes OpenGothic as a submodule? Something like this:

MyAndroidGame/ (The Wrapper Project)
├── app/
│ ├── src/main/cpp/
│ │ └── CMakeLists.txt <-- The "Bridge" CMake
│ └── build.gradle
├── external/
│ └── OpenGothic/ <-- Submodule to this repo
└── settings.gradle

So we separate the full Android (or iOS , etc.) build between the game and the platform-project. The main project will only generate a binary, so the responsibility of packing the binary in the correct way for each platform is for the new repository, no the game repo.

[Try]

Hi,

That's definitely doesn't look like a nice solution. While you can go for something-like, for your own sake, but it's mater of time, before upstream will get misaligned with you external project. Like I've mentioned before: it best to have solution, that is not "special", and works same as ios/windows/mac/etc.

Why don't you want to use CMake based generator? CMake has unit-test based on one of jni samples here: https://git.jukie.net/oss/cmake/-/tree/v3.30.8/Tests/VSAndroid
Basically you run something like:
cmake -S. -B./android -G "Visual Studio 17 2022" -A ARM -DCMAKE_SYSTEM_NAME=Android -DCMAKE_SYSTEM_VERSION=24 -DCMAKE_ANDROID_ARCH_ABI=armeabi-v7a in cmd and should have MSVC-android project generated.