Inclusion to F-Droid and fmod.jar

[ClockGen]

Hello, is it possible to remove fmod.jar? As the original gzdoom port by nvllsvm, inclusion of this project to F-Droid is blocked by usage of a proprietary library fmod.jar.

[mkrupczak3]

Hi @ClockGen,

I'm pretty sure that fmod.jar could be safely removed from this app without any issues.

I think that fmod was used as the default midi device options in older versions of GZDoom such as the one used in this app. When porting nvllsvm's version though, I added in a hack to change the midi device to timidity anyways, so fmod.jar could probably be safely deleted unless it breaks the build.

My guess would be if the latter was the case, then a more involved process would be needed to figure out how to remove fmod more safely.

I'm not currently at a place where I have an environment to build and test an updated version of the app, but if anyone is willing to test it building and working without fmod.jar then I'd be willing to accept a pull request to remove it.

I think it would be neat to get a more compliant version of this app on F-Droid. The publishing requirements (ARMv8) of the Play store have seemed a bit cumbersome to me lately, It would be cool to be able to start working on this again and publishing new versions on F-Droid.

It would also be great to get more eyes on this project and more contributors involved for things like cool and new features with it being on F-Droid.

Context:
https://forum.f-droid.org/t/freedoom/1913
https://gitlab.com/fdroid/rfp/issues/1076

[mkrupczak3]

Also @ClockGen if I don't reply back to an email you send, just assume that I've missed it and feel free to submit a GitHub issue or comment.

[EmberHeartshine]

As a stopgap, I can include the releases in my personal F-Droid repo if that's okay with you; I have a few hundred folks pinging it a day.

[mkrupczak3]

@EmberHeartshine If you're willing, that would be cool.

In addition, people might find it useful to download the releases I have here on Github since they are more up-to-date than those on the Play Store due to #41

I think the issues brought up by F-droid are pretty important though. Chiefly, that fmod.jar and the like are pre-built, non-free binaries. I think it's a bit of a faux-pas to package and include this app in F-droid before these binaries can be removed, as some users of F-droid could have heightened security and code scrutiny concerns.

If there was a better way of informing users up front what they're getting "under the hood" I think that would be okay.

Eventually, I think most of these non-free binaries could be removed without much impact on the app though. I would like to have this happen for the health of the project.

Unfortunately, the current state of this project is pretty misshapen, and I'm unlikely to be able to make much progress in the near future without more external contributions or a rebase/donated code from my upstream's upstream: beloko / delta touch @emileb

[EmberHeartshine]

@mkrupczak3

If there was a better way of informing users up front what they're getting "under the hood" I think that would be okay.

The nice thing about F-Droid is that is has "anti-features" flags; in this case, the UpstreamNonFree flag. In the app, that looks like this:

(I've added a description and reference to this issue but the metadata hasn't updated in my cache yet.)

[mkrupczak3]

@EmberHeartshine

Oh nice, I like that a lot.

I think it would be great if you're willing to put the release in your personal F-droid repo, as long as you maintain that notice.

The updated releases on GitHub have more language translations and newer versions of the Freedoom wads than my Google Play release as well.

However you package it, I also recommend add translations for multiple languages to the F-droid store release if such functionality is available

Please let me know if you need a signed app release or anything.

[EmberHeartshine]

@mkrupczak3 The update script I've written pulls the release APKs from GitHub, so the way they're being updated now is fine. I'm not actually building them from source myself. (This is similar to the IzzyOnDroid repo except I write custom scripts for each of my apps.)

I'll have to look into localization; the way I'm handling metadata is a little outdated so it doesn't support multiple languages but I can fix that.

[ClockGen]

@mkrupczak3 any progress on removing fmod.jar?

[mkrupczak3]

@ClockGen No, sorry. I don't think I'll be able to make any progress on this going forward, either.

My Windows laptop where I had this entire Android Studio project on got wiped when I installed Linux a while back. Also, the build tools necessary to develop this app were completely deprecated by @google for no good reason.

Developing this app has been painful, but a very good experience. I know now to never rely on the Android ecosystem for a livelyhood, because there is absolutely no consistency, stability, or sanity to be found there.

If you're still interested in building a completely FOSS version of this app, might have to try it yourself. I've left some instructions in some of these GitHub issues, but you would have to set up a janky dev environment to get it done.

Also worth checking out, hound @emileb to see if he'd be willing to make a limited version of his "Delta Touch" android app as open source code.

It's unclear if his use of the GPL'd GZDoom engine technically obligates him to release a limited version of his launcher code to customers per the terms of the GPL, but it seems a bit unfair to make oodles of money off of open source code without giving a bit back.

[emileb]

Hi guys, sorry I didn't replay to this before, thanks for the ping! I am updating your last Freedoom-for-Android:

https://github.com/emileb/Freedoom-for-Android/commits/master

It now builds with latest Android Studio and NDK 21.0 ( I haven't updated to r22 yet) and I did a couple of fixes to the startup of the app.

I have removed the patching stuff and it now uses my copy of GZDoom 1.9 - the advantage of this versions is it includes OpenAL as an option for sound backend so FMOD can be removed.

Happy to make a branch with FMOD gone, is that the only stopping addition to F-Droid now?

[ClockGen]

@emileb most likely yes. I've been fixing it up on my own and got reproducible builds and started patching proprietaty stuff out. I patched out com.bda.controller library from your touchcontrols lib, since it's proprietary. I take it's used for hardware controller support, so, unless there's some other way, no hardware controller support for f-droid. But FMOD is more important, because so far my attempts to remove it produced builds that crash on startup and I'm in no environment to debug it. Plus I'm not familiar with gzdoom at all so all I can do is just delete the lib and patch out all of its uses and hope it wont break horribly.

[emileb]

Ah yes that Moga controller stuff needs to go also. Well feel free to give my copy a go, it builds for me on Windows - you will need to remove the patching commands from build.sh if using that.

Once you have that building I can remove the FMOD stuff. The issue with the build you have is if you remove FMOD it will then have no sound!

[ClockGen]

@emileb Haha I figured out that much already. I have patches to to remove moga lib already, it builds and works fine, at least with touchscreen, I can submit them as a PR in your repo.

[emileb]

Oh yeah BTW hw controller support will still work for 99% without that library, it's just needed for a very old specific Moga controller, Android has built in controller support for most gamepads.

[mkrupczak3]

Hi guys, sorry I didn't replay to this before, thanks for the ping! I am updating your last Freedoom-for-Android:

https://github.com/emileb/Freedoom-for-Android/commits/master

It now builds with latest Android Studio and NDK 21.0 ( I haven't updated to r22 yet) and I did a couple of fixes to the startup of the app.

I have removed the patching stuff and it now uses my copy of GZDoom 1.9 - the advantage of this versions is it includes OpenAL as an option for sound backend so FMOD can be removed.

Happy to make a branch with FMOD gone, is that the only stopping addition to F-Droid now?

Hey, thanks for the build @emileb. I apologize for the tone of my previous comment, I'm in great debt to your great codebase for making this project possible.

Excited a the prospect of a truly FOSS GZDoom running on Android. Keep up the great work!

[mkrupczak3]

Per FMOD, I don't know if its relevant, but I added a .ini file hack to the Freedoom app to change the sound device from the default FMOD ouptut to Timidity.

If FMOD is essential to the build, it may be possible to replace the jar with a dummy replacement that doesn't actually do anything. This would not have any impact on the sound output, but would allow the build to succeed.

[ClockGen]

It still includes various headers and cpp files from fmod (which are not gpl-licensed) as well as a shared library in build.

[emileb]

Hey @mkrupczak3 no it's all good, I should have replied earlier to this!

OK just in case there was any confusing here - There is FMOD which is the backend sound output device, the setups and open the audio in the version of GZDoom Freedoom currently uses - all audio output goes through this.

Then there are various music renderers - Fluidsynth, Timidity, GME, OPL etc, these generate the music data which ultimately goes through FMOD to play.

AFAIK all the music renderers are good to go, they all include the source code. We need to remove FMOD however, but in the current version of GZDoom you have it is the ONLY audio backend so this would break all audio in the app.

In the update I just did I am using a newer version of GZDoom which also includes FMOD and OpenAL as audio backend so we have the option to remove FMOD and use OpenAL instead. It should then behave essentially the same as before (possibly missing some useless audio features like 'Reverb' which are present in FMOD)

I'll look into remove FMOD from my build this week.

Hope that makes sense and sorry if you knew that already, cheers 👍

[emileb]

It still includes various headers and cpp files from fmod (which are not gpl-licensed) as well as a shared library in build.

I've not removed it yet, I wanted to make sure it was in a working state first.

[ClockGen]

No, I answered @mkrupczak3, that in the current state of this repo removing only fmod.jar is not enough, there's still native part of fmod present.

Anyway I'm having problems compiling your version, it seems that some sources are missing. I had to manually initialize some submodule (jwzgles is not listed as submodule), and fix some paths to compile it on linux (different letter cases), but now I'm getting this error:

[armeabi-v7a] Compile++ thumb: gzdoom <= parse_xlat.cpp
jni/gzdoom_android/mobile/..//mobile/../src/xlat/parse_xlat.cpp:43:10: fatal error: 'xlat_parser.h' file not found
#include "xlat_parser.h"

and this header is nowhere to be found in the whole project tree.

[emileb]

Ah yeah sorry! They were included in .gitignore so I missed them.
Try again: https://github.com/emileb/gzdoom/commits/freedoom_for_android_gz1.9

Edit: Fixed the submodules in master, now clones and builds properly (On Windows): https://github.com/emileb/Freedoom-for-Android

[ClockGen]

@emileb is no_fmod branch good to go? I merged it locally and it builds fine, audio seems to work (music and effects). If it is, can you merge it please? I'll start working on F-Droid inclusion then.

[emileb]

Yeah I think's good to go as a first pass.
Actually I was going to ask @mkrupczak3 if he wants to keep a branch going with FMOD/MOGA lib included in case he wanted to use it for Google Play? Or just remove FMOD completely for all builds from now on?

[mkrupczak3]

@emileb I'd say let loose and do whatever you can to remove non-free binary blobs.

I can't update the app on Google Play anymore because I haven't figured out how to compile for Armv8

I still feel that a fully FOSS release (such as on F-droid) would provide the most new value to users

[emileb]

OK I've merged no_fmod back into master. BTW @mkrupczak3 I should be able to fix it up to build on arm64-v8a, I'll take a look.

[ClockGen]

@emileb @mkrupczak3 I've opened a packaging MR on F-Droid gitlab, https://gitlab.com/fdroid/fdroiddata/-/merge_requests/8358, there's a few questions. If you don't have gitlab accounts you can just post here, I'll relay it.

[emileb]

com.android.vending.CHECK_LICENSE is a leftover as you say, it can be removed.
BTW does this fdroid build point to my repo or did you do a fork? Just so I know if to be careful and not break it.

[ClockGen]

@emileb no, I'm using your repo, all the submodules are yours anyway.

[ClockGen]

@emileb I opened another PR with some cleanup, to not cause confusion if some F-Droid users decide to visit the repo.

[emileb]

Thanks for the ping, for some reason I'm not getting notifications of pull requests. Now Merged.

[ClockGen]

It's merged now, and, hopefully, will appear in the next f-droid build cycle.

[mkrupczak3]

Thanks @emileb @ClockGen for making this app truly free and open source. This issue can be closed