Android port on F-Droid / Google Play

[clintbellanger]

Going to set up a Google Play account for Flare on Android and post questions/info here.

[igorko]

Could we post Android gameplay video in flare blog? With notice the we release v1.0RC soon, and Android will be supported. @dorkster can you provide such video? I saw in youtube you got device and have flare on it.

For relsase we could update data package for Android with all available mods and upload it to github as release package (as I did some time before here https://github.com/igorko/flare-game/releases/tag/v1.0pre )

[dorkster]

I'll try putting together a video. Unfortunately, the quality probably won't be great, since my only recording device is an older digital camera.

[igorko]

Btw, I'm in favor of releasing game data for Android as another package that user should download manually, because releasing data package on Google Play is not so easy, it requires java programming for flare java wrapper. And we create engine in first place, so user should have ability to add his own mods. IIRC getting data package from Google Play doesn't allow to change data destination place, and editing mods can cause downoader to redownload data as corrupted. Anyway, it looks too complicated..

[dorkster]

One thing to remember is that the game is not able to be launched without the default mod. I'd like to add the default mod to the assets directory when making the base APK. However, when I last tried this, the game wasn't able to read those files. I think it was happening because we can't stat APK contents like we can normal filesystems (like the SD card). Maybe SDL_RWops can help there?

[igorko]

This http://www.dinomage.com/2013/05/howto-sdl-on-android-part-2-platform-details/ says you are right. Link is present in our README.android

[dorkster]

Another (and probably much easier) option would be to not use internal storage at all. Doing this would also allow end users to modify their save data and settings, which are currently locked away on internal storage.

[igorko]

I also was thinking about how to handle missing default mod on Android, this could be a solution https://wiki.libsdl.org/SDL_ShowSimpleMessageBox We could show ui error message using SDL api (no idea how it looks) or our MenuMessageBox.

[clintbellanger]

Ok, I just finished registration for the Google Play dev console so that we can publish Android stuff. Here are notes:

Before registration it suggests tying the account to a non-personal email address. I created [email protected] for this purpose. My personal phone number and email are the backup contacts.

I paid the $25 registration fee, which required setting up Google Wallet and associating it with a credit card. For now I put in my own personal credit card. If we end up sharing this email account (and not just forwarding/masking), I'll want to remove my card info.

Here's the status from the Google Play dev console:

Your payment is still processing, which will take up to 48 hours. You can already start to upload APKs and prepare Store listings but not publish any applications yet. We will notify you when the payment went through and you can publish your applications

As far as the blog: we could use a new website at some point, my crappy micro-blog software was fine when the project was still a tiny hobby. For now, if anyone wants to send me a full blog post I'll put it up. Also, if one or two of you want access to post new blog entries while the old site is still up, just email me.

[igorko]

@dorkster I have tried SDL_ShowSimpleMessageBox for displaying error if default mod was not found. and looks like it's still buggy (on Windows it truncates last word). We can draw our own error dialog without using textures, or use SDL_ShowSimpleMessageBox only for Android (needs to be tested there first).What do you think?

[igorko]

    SDL_ShowSimpleMessageBox(SDL_MESSAGEBOX_ERROR, "FLARE: Default mod not found", "Default mod should be installed to proceed. Game will exit.", NULL);

[dorkster]

I tried SDL_ShowSimpleMessageBox() on Android and it does nothing. It appears to not be implemented there.

[igorko]

@dorkster I just got feedback from SDL bugzilla, https://hg.libsdl.org/SDL/rev/6cd8e6b54f4d, are you sure you was trying latest hg version? It should be there now...

[dorkster]

You were right, I wasn't using the latest SDL version. Message boxes show up perfectly on Linux and Android. I haven't tested Windows, so I can't confirm any bugs there. If it's as you say and the last word gets truncated, displaying a message box is still better than nothing at all to let the player know something went wrong.

[igorko]

@dorkster I have created signing key for apk file, I can share it with you if you want to create official apk for Google Market. Or you can create it yourself if you want to upload apk. I can generate apk too, it doesn't matter I guess, but I would prefer to leave Android API support as it is currently in master (I saw you have changed minimal API version in you fork). Can you use current master Android API version for generating apk? We should agree this stuff, and I guess we can upload apk to Google Market(waiting for SDL release can take monthes so we can release only Android or release all platforms, ideas, guys? ). Well I see 3 more issues that imho should be resolved first.

1. WidgetInput issue I have opened. Can you look into it?
2. Allow text input on Android. This https://github.com/clintbellanger/flare-engine/commit/042d0a8ff0baa54901080d9d6014b064ddae1abc (see comment) could work, but again needs WidgetInput improvements.
3. Maybe add donation button to Android version? But this needs Java/C++ JNI magic.

[igorko]

I was able to get correct text input on Android (moved starttextinput and added stoptextinput sdl calls to widgetinput logic() ), but keyboard still doesn't resize app window and keyboard reacts very slowly on taps... maybe we should skip this at all...

[dorkster]

I saw you have changed minimal API version in you fork

That was by accident, since the lowest API version I have installed is 17. I'll install 13 later and make sure I can still make a valid APK. But I'll work on the WidgetInput issue first since that affects all platforms.

As for a release, I'd prefer all platforms being released at the same time. As always, we need game data to go along with the release. I've been continuing to work on it, mostly with classes/powers/base stats tweaking.

By the way, I should also make the error message for missing default mod more descriptive. Having to have the user download the game data manually is already bad enough, and some explanation might alleviate the "1 STAR DOES NOT WORK" reviews on the Play Store.

[igorko]

So, is anyone able to add Donate button to Android version?

[igorko]

As it is posted earlier google account was created. Can we upload engine and game data for version 1.05 (maybe wait if game/engine needs fixes)

[dorkster]

I wonder if the Google account is still valid at this point, as it was created and then left inactive. I'm sure Clint can answer that.

However, there are a few renaming tasks I'd want completed before putting the game on the play store:

1. Downloading of assets. The game data exceeds the maximum size of a play store apk. Plus, I could never get even loading the default mod from the apk assets directory to work. So ideally, the game would offer to download the mods as zip files from Sourceforge. This would require the engine to be able to:
   1. Download files. Not sure if this should be done on the Java side or the C++ side. On the C++ side, we could use libcurl, though that's adding another dependency.
   2. Load the game from a zip instead of a folder. PhysFS could be used so that we treat folders and zips the same. Another option would be to extract the zip somehow, but I'm kind of against this as its hard to push updates and most mobile devices have filesystems optimized for single large files.
2. Virtual controls. The current touchscreen controls require the player to have their finger covering the center of the screen, which is where all the action is happening. I'd like to add a dpad/joystick and two attack buttons (MAIN1/MAIN2). InputState will need to grab all finger events from SDL and store them separately, instead of only in the "mouse" variable. The rest of the touch interactions work fine as is.
3. Adjusting for screen DPI. Many mobile devices these days have very high DPI displays. Flare renders quite small on my 5" phone which has a 1280x720 display. Because of the resolution, Flare uses the 600p virtual height set in engine/resolutions.txt. I propose adding a virtual_dpi setting so modders can set a target DPI that the engine can factor into our resolution scaling. So if the system DPI is higher than the target, we can decrease the render resolution to make things bigger.

[igorko]

Maybe we could use this feature https://developer.android.com/google/play/expansion-files , or our location. It depends on what is better for us when game data will get updates.

[Wuzzy2]

It it's going to Google Play, then it should go to F-Droid, too.

[dorkster]

Changed the title of this, since I would consider getting the port on F-Droid a priority over Google Play.

[johndh]

Having just the engine APK on F-Droid would make it easier to get updates and bug fixes. There are games on F-droid that require separate downloading of the assets, so it wouldn't be an outlier.

[dorkster]

There are games on F-droid that require separate downloading of the assets, so it wouldn't be an outlier.

Actually, I think we could ship everything as a single APK on FDroid. For example, SuperTuxKart has a 154 MB APK currently, which is about the size of flare-game. That's another advantage of targeting FDroid over Google Play.

[Victor239]

Google Play allows large games nowadays, e.g. Wild Rift is 4GB on my phone.

[KOLANICH]

I think that assets must be shipped separately, because flash wear on engine update is lower in this case.

[dorkster]

Merge request for the F-Droid build is up thanks to a volunteer: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12349

Considering there are other games on F-Droid that require some manual setup, I am okay with getting the engine-only APK in its current state on to F-Droid.

Getting the game data in as part of the APK would require some code changes that I don't think we're ready to make. From a Discord conversation earlier, I wrote:

I think code changes would be required. Either to copy APK assets to "Android/data/org.flare.app/files", or to load directly from the APK assets. The latter seems like the way to "properly" do it. In terms of code change, the "easiest" part would be dropping std::ifstream in favor of SDL_RWops (at least for reading files within mod folders). I think there's more of a problem handling directories. SDL_RWops doesn't have a way to handle this AFAIK. That leaves the former method, which is very inefficient (app always has a copy of the assets, even though they aren't read beyond the initial copy).