Amiberry runs stable on Android (Termux/X11/XFCE4) but the executable only runs from parent of build dir..

[PTz0uAH]

Hoi @midwan behold Amiberry on Android.. (non-root)

Hacked the code a bit to make it work.. committed to the fork..

Maybe an interesting new target for Amiberry..

with kind regards,

Peter

[giantclambake]

That would be expected... see -> https://github.com/BlitterStudio/amiberry/wiki/Amiberry-directories

Follow that up with --> tox-dev/platformdirs#70

Edit: Forgot to mention, I have trouble envisaging the usefulness of amiberry on Android ... actually, more to the point Amiga emulation on Android point blank, primarily because of user (game) input controls. It's fine of course on a handheld with dedicated joysticks etc...but straight-up Android tablets or 'phones? I'm not so sure....you'd have change the amiberry path logic to suit androidOS layout...provide accelerometer input (or onscreen widget) to do joystick, and do mouse/keyboard...and like Gekko, support BT gamepads as well... seems like an awful amount of work imho, for very little reward...that's just me though, perhaps midwan sees it differently... /2cents

[midwan]

@PTz0uAH
Thanks for that!
From a quick look, I think the hacked changes you made could be better incorporated into the main code, perhaps with some checks.

I'm not familiar with Termux, but there have been some attempts to bring Amiberry to Android in the past. We never got it further than a first alpha version, and eventually the person helping with this disappeared, so the effort was never completed. I think bringing it to Android in general would be interesting, even if it will need some further changes (like on-screen controls).

[PTz0uAH]

Well, I run Termux-app for terminal emulation+ Termux-X11 (XFCE4) which is providing a Linux desktop as an Android app, so the path logic is non-android.. Amiberry is compiled as a normal desktop program yet needs to be a position-independent-executable.. to move it to any folder..which needs recompilation..

The usecase for me would be creating on-device Amiga environments to also be used with the great Uae4arm which runs in parallel on the "normal" app-side.. with JIT & HW-acceleration enabled..which is amazing.. for me as Oldschool Amiga fan..

Everything was compiled on-device so the tablet became a full blown workstation.. for dev stuff..

[PTz0uAH]

@midwan

I want to make the hacks/edits more complient to master-origin so I need to introduce a {$define TERMUX} , so what unit would be best to create such a global define? Furthermore I need to auto-detect the termux environment somehow to set perhaps a global var for later.. I'll dive into it..

[midwan]

@PTz0uAH
Yeah, after checking out Termux a bit more, it's more like running Amiberry on a Linux sandbox, on Android. :)
I assume you had to install X11 and XFCE yourself inside Termux first?

It might be easier to just install the deb/rpm package inside that then, instead of doing a manual build - of course, that would be possible after the fixes are included, and a package is generated.

The TERMUX define would be one way, which could be defined in the main CMakeLists.txt file as an option (there are already a few there, as you can see). I think at least some of those changes could be changed however, to check for something in the system instead, and not special-case everything with #ifdef TERMUX.

[PTz0uAH]

@midwan
Well, there is Termux-app which is the base apk for the terminal emulation and there is the nightly build Termux-X11 apk which serves as a companion for Termux.. all is configured from Termux-app and after adding repo-X11 installing XFCE4 was possible.. (native, without proot or croot for max performance..)

The Termux packaging system is Debian-alike but Debian packages cannot be used.. though it seems also to be possible to create Termux deb packages working from DebianOS..

I can build an Amiberry Termux deb package with termux-create-package but we need to have to make Amiberry a Position Independent Executable.. that is mandatory for Android 5+ (and also for modern linuxes), at the moment if Amiberry is run from build-dir or placed outside build-dir-parent I get an unsupported eh_frame_hdr error and Amiberry exits silently..

B.t.w. how can I create a Release build with cmake since the executable is huge and not stripped..? (when stripped manually the exe shrunk from 121MB to 23MB which is more suitable for packaging..)

Anyway.. to keep it positive, Amiberry runs my oldschool setup for hours and hours in full window mode without crashing like Uae4arm often tends to do..

Here some screenshots..

[midwan]

Building with pie enabled is not an issue (though JIT will then not work), the macOS builds do that already, since that's forced in the compiler. We can use a CMake option for it, I guess.

Release builds should not be that large, and CPack should strip them before packaging anyway. If Termux can use DEB packages, but it has a different directory structure for example, it would be best to use the CPack options already available and perhaps use a different PREFIX value? Not sure what else is different there.

Alternatively, maybe a Flatpak can be used in Termux? There's already one on Flathub, and it will be updated with the new release as soon as it's ready.

[PTz0uAH]

@midwan some remarks concerning compiling a release version..

I used cmake -B build && cmake -DCMAKE_BUILD_TYPE=Release build && cmake --build build --parallel 8 which resulted in a 26MB sized executable which is according to readelf -d amiberry a "NOW PIE" executable so that is Android 5+ complient..

But the problem unsupported eh_frame_hdr error still remains if moving the executable outside build-parent-dir.. which is related to some debug-stuff which I do not understand since building a release cuts out the debug stuff imho.. but I can be wrong of course..

So if I would make a package, the only dir I can install the executable to would be $HOME/dev/amiberry at the moment.. which is a bit of a showstopper..

Hmm.. any ideas? Yeah.. I had one.. a workaround..

"solved? this works!"
Well after I did a git clone to $HOME/Amiberry cd $HOME/Amiberry + creating a fresh release build.. + performed a cp build/amiberry . it seems amiberry runs and is fit for custom termux packaging..

The $HOME/Amiberry directory was created after running cmake --install which places the executable in an unwanted location so that install procedure needs to be "Termuxified" too.. until the eh_frame_hdr error is resolved I don't mind having $HOME/Amiberry as location for amiberry..

LIBSERIALPORT.SO: Termux packages does not have libserialport.so so that would be a dependency package for amiberry-7.0.aarch64-termux.deb.. I guess.. so I will make that one available too for testing..

[PTz0uAH]

@midwan , the latest mainstream commits to Amiberry resulted in a buggy executable starting up with a segmentation fault, so I created a tmx-branch with latest knowing working version where I can do the experimentation for my non-standard approach.. and (re)implement with as clean as possible code..

It is clear lots of Termux/Android specific workarounds and patches do not belong in mainstream until the code is complient..

I will keep the forked master code on par (and test with wsl) and hunt those (for me) buggy sections.. in my amyberry tmx branch of amiberry.. hence there are some peculiarities which are Termux specific and also makes it difficult/impossible to use cpack or flatpack methods for those are not supported by Termux..

Unofficial experimental packages I create during WIP will be marked as such so the intended official debs are renamed with workingtitles amiberry-7.0.0.aarch64-termux.deb & amiberry-7.0.0.arm-termux.deb to avoid confusion.. (got amiberry also running on 32bit android devices but maybe amiberry-lite can be compiled too for lowspec android-termux to get some better performance )..

Normally only packages complient to Termux path standards are accepted but there is triage for special packages and circumstances like usefullness.. such as with Amiberry..

Since the android-bosses recently announced making linux terminal/gui available within the future android products and Termux is pioneering that same path.. I believe Amiberry would be a nice addition.. albeit Android-Termux being a bit off-standard..

The usecase I work with had some highlights which I would like to share..

Beside the absence of JIT Amiberry runs rocksteady and most features just work..

Hope also to get JIT working in Android -fpie/-pie compiled executables maybe the library approach just like the Uae4arm app manages who provides JIT to 64bit aarch64 systems which works excellent on my Andorid 13/Termux tablet.. (68040 at 1Ghz according to SysInfo) could work.. Getting JIT to work is speculative but if the Amiberry main executable loads a amiberry-jit.so like a normal app like uae4arm would do loading via JNI.. then maybe JIT can work.. and one is also another step closer to getting an amiberry android apk build natively..

Wow.. the host-multiview and host-run work fine.. and via newshell or a Dopus dock I can startup Uae4arm which runs in parallel.. both connected to the local bftp server.. sharing files without permission issues like normal via the restricted filesystem.. Also running vAmigaWeb webapp via Firefox or "just" Gimp are handy tools to start from the workbench..

So now I can start a game which would crawl in amiberry offloading it for running at full speed on the uae4arm jit engine side on the same device.. (and after closing uae4arm jump back to the Amiberry Amiga Workbench..)

screen-20241024-230622_small.mp4

I will keep you posted about relevant progress.. hope to get my finger on those nasty bugs..