Android support?

[zen0bit]

Not tried yet, just found your repo.

Looks like you enabled support for aarch64 in AppImages.

First necessary step to make AppImages run under Android.

Are you thought about that?

theoreticaly could be posible..

Just thinking

PS: Will study your script more, and try
PPS: ❤️ AppImages

[mgord9518]

Unfortunately, Android doesn't seem to have support for FUSE without some modifications (that seem to require root access) but I do occasionally mess with this project on my Android phone.

I have thought about possible solutions/ workarounds. This script embeds squashfuse binaries to mount the filesystem image, but if your application is a single, static binary, it could be embedded in place of them, removing the need for FUSE. This would essentially turn the shImg into a compressed executable. The advantage here over just distributing the binary would be inclusion of desktop integration info, update info and support for multiple CPU architectures.

Obviously the use cases for this kind of thing would be limited because it's not nearly as flexible as being able to mount the whole app directory, but might be useful for certain console applications and would work on Android. This would only require changing a couple lines of code in the shImg runtime and is high on my list to get implemented.

Another option is to use --appimage-extract on the shImg, then run the application from its appdir. The binaries in shImg are statically linked, so it runs on Android as-is. The extracting is currently a little janky but I'm working on fixing it.

[mgord9518]

@zen0bit after some more research and thinking, there might be a couple other ways to support Android.

1: A simple wrapper interface could be created, which projects could be patched to use, making opening SquashFS'd files identical to opening an actual file on the system. Assuming a C/C++ project, it would be a simple #define open squashfs_open and linking in the wrapper.

2: Similar to the first solution, except the wrapper would be built as an entire libc, which could be loaded over the actual libc using LD_PRELOAD. This isn't the best solution, but could potentially be used for proprietary software. The use-cases for this would probably be slim, but I'm sure they exist

3: Apparently it's possible to intercept syscalls using ptrace, which I think is what proot does. I'd have zero clue where to even start with this, but it's probably the only solution which would be within the scope of shImg.

I believe solution #1 is probably the most practical, which I'd be happy to implement basic functionality for with C, Zig and maybe Go. This wouldn't be part of shImg, but I'd advise it as a good practice so that FUSE isn't required for running. This could also potentially shrink executable sizes quite a bit for those who use it.

[zen0bit]

Don't know
But maybe @ivan-hc could bring some ideas?

He knows more about AppImages then me...

[ivan-hc]

In all my workflows I use appimagetool from https://github.com/probonopd/go-appimage

The main advantage of it is that bundles AppImages "Type3", i.e. they don't need libfuse2 to work.

Download any of my x64_64 AppImages and remove libfuse2, then run them... if you don't believe me.

How to use it:

wget -q $(wget -q https://api.github.com/repos/probonopd/go-appimage/releases -O - | grep -v zsync | grep -i continuous | grep -i appimagetool | grep -i "$(uname -m)" | grep browser_download_url | cut -d '"' -f 4 | head -1) -O appimagetool
chmod a+x ./appimagetool
ARCH="$(uname -m)" VERSION=$(./appimagetool -v | grep -o '[[:digit:]]*') ./appimagetool -s ./*.AppDir

this is the workflow used in "nolibfuse.am" trying to convert Type2 AppImages to Type3, in "AM"/"AppMan"

I've set wget to download the last available release for your architecture here

Also, the last command uses your architecture and the version of appimagetool.

NOTE: you can't skip the Appstream check validation, so your program must be a regular one, with metadata info in place... or as workaround you can try to remove the content of /usr/share/metainfo and... pray 😉

[mgord9518]

@ivan-hc I haven't used go-appimage in a couple years, what exactly is AppImage type 3? What technique is being used to not require FUSE?

[ivan-hc]

@mgord9518 about how it works without fuse, you should see https://github.com/probonopd/static-tools

about the name Type3... its a long story. This is something that was suggested to me during a chat with another italian develper that have strongly influenced the development of this "Type3 AppImage", but not directly involved into the AppImage project (the developer of Bottles), so I keept calling it Type3 until the developer of the AppImage project have said that this name does not exist yet... so I was wrong calling them like this... but for this mistake I wrote it in all commits of my 60+ AppImages packages I distribute in my repositories. Fine.

So I keept calling all new generation AppImages that does not use libfuse2 to work "Type3" on my own risk. And they are amazing! Another level! The big ones can be 20-30 MB smaller! I've seen this reduction almost all big AppImage packages I distribute and on those I have installed with "AM". I've also created an option in my package manager that tries to convert the old format with this new one, and I was amazed.

EDIT: think that if your AppImage uses zsync to be updated and you have converted a "Type2" to a "Type3", the latter will be updated without loosing the new status.

[mgord9518]

@ivan-hc after a quick peek, is it static linking? shImgs use a custom version of squashfuse that's also static linked, which works on almost all Linux distros, but unfortunately not Android due to the kernel requirement for FUSE.