search

ohrrpgce / ohrrpgce

Official Hamster Republic RPG Construction Engine (mirror of SVN repository)
https://rpg.HamsterRepublic.com/ohrrpgce/Source
Other
72 stars 16 forks source link

Android apk export from distribute game menu #1228

Open bob-the-hamster opened 2 years ago

bob-the-hamster commented 2 years ago

The current android packaging system is based on rebuilding the whole commandergenius-based port of the ohrrpgce source with additional data files, but this is unnecessary and overcomplicated

Instead we should have a pre-compiled apk template, and then the distribute game menu can download it, and handle

template build

The template build will be similar to the existing ohrrpgce-game-android-debug.apk build, except that it will be a release build instead of a debug build, and that it will not attempt any signing

Getting this into the build system is a necessary prerequisite to have a template that can be used to perform all the other steps on

dependencies

We need to figure out the minimum set of tools necessary to make all the needed changes to the apk file. Then we can check the licensing on those, and determine if we can distribute them the same way as we currently distribute other helper applications. If that isn't possible, either because of licenses or because of the number of tools, or their own chain of dependencies, then it might turn out to be simpler to require the user to install the Android SDK themselves, and the distribute game menu would just have to know the location of it before it could proceed with exporting for android. (That would still be a big improvement on the current build android system)

Icon and button images

These could conceivable be included in the rpg file, although we would probably still make copies of them in the apk file. We could also just require them to be placed into a special subfolder with a simple naming scheme

Signing

The signing certificates can be automatically generated, but they CANNOT be embedded into the rpg file, and it will be important to let the users know the importance of protecting them and keeping them backed up, as we will not be able to recover lost certificates, and we need to make sure people understand the importance of not sharing them. Possible naming scheme: gamename-please-backup-this-file-and-seriously-do-not-share-it-with-anyone.keystore

rversteegen commented 2 years ago

The trickiest thing that needs (as far as I know) to change is to change the Java classpath in the compiled .dex files. I previously wrote on the mailinglist in 2013 in 'Android port' (the whole thread is worth rereading):

Don't forget that while allowing the user to select the namespace is low-priority, packaged .apks still need to have unique namespaces, otherwise Android will consider them all as the same program.

There's an additional problem. It turns out that in addition to all the Java code, lots of the C code in the SDL port requires the namespace to be compiled in too. I have no idea how JNI works, but it appears that Java code like...

package com.hamsterrepublic.ohrrpgce.game; class AudioThread { private native int nativeAudioInitJavaCallbacks();

requires an implemention provided by a C function named Java_com_hamsterrepublic_ohrrpgce_game_AudioThread_nativeAudioInitJavaCallbacks!

However perhaps by using Simon's library suggestion we can use a separate namespace for all of the code compiled into the .so files, leaving just the xml metadata and compiled Java files to worry about.

In order to edit the namespace in compiled Java code we would have to modify .dex files (targetting .class files instead would mean still having to convert them to .dex and requiring the NDK). Looking around a bit I see there are a couple projects like smali/baksmali (https://code.google.com/p/smali) for disassembling/reassembling a dex file. It sounds a whole lot simpler to just set up a web server which compiles the required java source files with desired on request :)

Unless creating a single trivial java module which includes everything else is enough; in that case smali/baksmali could be practical, or even a small edit to the right offset in the file...

Simon's "library suggestion" from an earlier email:

The simplest way would presumably be to make the ohrrpgce a library project and wrap it with the new namespace, I think:

package com.newnamespace.myrpg;

public class MainActivity extends com.ohrrpgce.games.OHRActivity

etc.

Simon also suggested that Proguard could be used to change the namespace in a compiled .dex. Of course this was 2013, so there might be other solutions now. But I see that Godot at least still requires the Android SDK+NDK to export for Android.

bob-the-hamster commented 2 years ago

Oh, wow, I had completely forgotten all of that, thank you for remembering!

That does complicate this goal considerably

rversteegen commented 2 years ago

If we manage to clean up the C code, as discussed, so that it doesn't contain the actual app namespace, then it would only be necessary to compile the namespace into the Java code, and this would only require the Android SDK.

I see a few options:

bob-the-hamster commented 1 year ago

My current favorite plan for this is to implement a docker image that can build android apks. I want to do this anyway for my own local apk building, but then it could be re-used for: