Pmbootstrap: Using all Android subsystems/drivers without libhybris

[twaik]

There is a way of building software that will let programs use Android's drivers and libraries without any compatibility layers like libhybris. I am talking about building programs on top of Bionic libc (see here). That will let programs use Android's libEGL, libGLESv2 etc.
I have working Pulseaudio OpenSL ES backend but it needs mediaserver process to be launched.
For now I am working on Android Xorg driver that will be able to output both to Android application and directly to Surfaceflinger. This way will let you use Android subsystems without need to write drivers. Also that way will let us launch system at the same time as Android runs (that will effect distribution popularity, some people prefer to test OS before installing it as a main system).
Something like that.

[ollieparanoid]

Welcome to postmarketOS, @twaik!

There is a way of building software that will let programs use Android's drivers and libraries without any compatibility layers like libhybris. I am talking about building programs on top of Bionic libc (see here). That will let programs use Android's libEGL, libGLESv2 etc.

I thought that it would be possible to use programs compiled against bionic libc to circumvent libhybris as well. But @NotKit told me that libhybris is needed because Linux programs can't communicate with proprietary OpenGL libraries directly. So if I understand you right, you're moving the compatibility layer from providing the standard GL libraries on Linux to directly being a X11 driver, right?

Related: @NotKit's xf86-video-hwcomposer which works on top of libhybris.

I have working Pulseaudio OpenSL ES backend but it needs mediaserver process to be launched.

Nice!

Also that way will let us launch system at the same time as Android runs (that will effect distribution popularity, some people prefer to test OS before installing it as a main system).

That sounds awesome!

[twaik]

GL libraries on Linux to directly being a X11 driver, right?
Not exactly. Linux programs can use Xorg even if it is built on top of foreign libc, it uses protocol, not device dependent libraries. That's why XServer XSDL can work properly with programs in glibc chroot. So I need programs to be built on top of Bionic not only for OpenGL but all SoC dependent libraries.
xf86-video-hwcomposer
It uses libhardware headers which differs from SoC to Soc. I tried to build libhardware's libcnativewindow test and it segfaulted without SoC's dependent libhardware headers. That's why I want to use Surfaceflinger and Android Activity APIs: they are unchanged by vendors. Also you won't be able to use Android's libEGL/libGLESv2 in glibc/Musl programs without libhybris. That's why I want to use Android native build to all GNU/Linux programs. You can use Pulseaudio for sound even without libOpenSLES (you need only Pulseaudio library/protocol), but you can't use hardware acceleration without libGLESv2 in glibc/Musl.
That's why I think that postmarketOS should be built on top of Bionic instead of Musl.

[twaik]

I think postmarketOS developers should just try to build DE and some programs on top of termux-packages build system to compare pros and cons of this way of building system.

[NotKit]

Regarding libhardware headers, that's a problem, but generally Qualcomm and MediaTek devices will work with LineageOS headers (most Qualcomm ones need QCOM_BSP defined though). The plan is to provide multiple versions of libraries compared around libhardware. What is your SoC?

As for building around bionic, I think the issue is that postmarketOS is based on Alpine Linux which uses musl, switching to bionic would require enormous effort.

The idea of running alongside Android could be implemented though, especially since OpenRC is used instead of systemd.

(Btw, @twaik, are you the Sparkle developer?)

[twaik]

What is your SoC?

RK2818, Snapdragon 400, Exynos 3 Quad 3475. But that does not matter if you use Surfaceflinger/Android Activity instead of using libhardware directly.

As for building around bionic, I think the issue is that postmarketOS is based on Alpine Linux which uses musl

Bionic is partially based on Musl. Functions missing in bionic are implemented in libandroid-support (you can find sources in NDK). Functions missing both in bionic and libandroid-support can be implemented in other, pmOS-specific static library. Some code like user management can be reimplemented using Musl code in the pmOS-specific library. Libc functions that are disabled on kernel level (e.g. shmget) can be implemented using android-shmem.
Termux-packages create standalone toolchain from NDK during build and patch headers to make them more glibc-like, pmOS can do the same thing.

switching to bionic would require enormous effort.

I did not ask for immediate switching to bionic, just for a some test local repo with some programs like LXDE (or just Openbox+pcmanfm), Leafpad/Geany, VLC/MPlayer to test window creating, input/output and GLES/Pulse. Maybe it can be based on termux-packages for the first time.
The distribution based on bionic will be a bit less secure because you will have no ability to patch kernel or to change it in any way but it will be able to be launched on any Android-based device, not only devices in list. For now I have Pulseaudio and Xorg patched to be launched on bionic, Android Activity/Surfaceflinger Xorg driver is in development.

are you the Sparkle developer?

No, I'm not. The main sparkle repo is here. The guy's nickname is Mogryph.

[twaik]

It looks like Alpine's APKBUILDs and termux-packages's build.sh are a bit of simillar.

[NotKit]

My point was that at least the common SoCs could be handled even with libhardware, but yes, "hybris" is somewhat fragile in general besides headers difference. Android Activity/Surfaceflinger Xorg driver sounded like Sparkle to me, that's why I asked. Is your driver different from it?

[twaik]

Sparkle driver needs to work on device where /dev/shm is available. Or you should have rooted device and create /dev/shm dir manually. My driver will use ashmem for shared memory segment. This driver will be able to work inside Native Activity on non-rooted device just like XServer XSDL does, just much faster.

[ollieparanoid]

Thanks for explaining your idea further.

That's why I think that postmarketOS should be built on top of Bionic instead of Musl.

I think postmarketOS developers should just try to build DE and some programs on top of termux-packages build system to compare pros and cons of this way of building system.

I did not ask for immediate switching to bionic, just for a some test local repo with some programs like LXDE (or just Openbox+pcmanfm), Leafpad/Geany, VLC/MPlayer to test window creating, input/output and GLES/Pulse. Maybe it can be based on termux-packages for the first time.
The distribution based on bionic will be a bit less secure because you will have no ability to patch kernel or to change it in any way but it will be able to be launched on any Android-based device, not only devices in list. For now I have Pulseaudio and Xorg patched to be launched on bionic, Android Activity/Surfaceflinger Xorg driver is in development.

What you're proposing here is a big change, even trying out if we could build the packages that way is a big effort. The big obvious downside is already listed: we would not be able to modify the kernel and ideally replace it with a mainline kernel, which conflicts with our goals.

Libhybris is acceptable for people who want it, because we can make it optional (the infrastructure for that is already in place, you can choose at installation time if you want proprietary firwmare/userspace drivers or not).

So I'm wondering a bit why you are reaching out to postmarketOS in the first place - creating new packages/a new distribution on top of termux-packages and their build system seems to be more in line with what you are trying to do.

Running something like postmarketOS on top of Android for demo purposes seems nice, but not important enough to change the libc for that. There will be compatibility issues, and we would not be able to directly use packages from Alpine anymore, which is an additional workload we could not handle at this point.

With that being said, I think your approach does sound interesting and if you're willing to go down that path and get it working, I'm sure there are lots of ways to collaborate in shared upstream projects that you could package for your own distribution.

[twaik]

OK. I got it. Looks like I should try creating my own distribution that will be compatible with Android libraries. Thanks :)
Anyway, using Bionic Pulseaudio and Bionic Xorg + Surfaceflinger driver will work with Musl/glibc/etc distributions but hardware acceleration will be unavailable.

[NotKit]

Anyway, using Bionic Pulseaudio and Bionic Xorg + Surfaceflinger driver will work with Musl/glibc/etc distributions but hardware acceleration will be unavailable.

It can be generally combined with hybris to get hardware acceleration as long as gralloc buffer sharing is working (may need root rights on Android side). libEGL/libGLESv2 themselves don't depend on libhardware headers.

[ollieparanoid]

OK. I got it. Looks like I should try creating my own distribution that will be compatible with Android libraries. Thanks :)

Best wishes then, and I'd be interested when you have something to show. So maybe you could post a link here when you get there :+1:

[michitux]

Some time ago I tried running an Arch Linux chroot using proot under termux using XServer XSDL. This kind of worked meaning I could start i3 and some other GUI software (of course not with ideal performance) though I somehow broke the chroot, meaning I could not use it anymore after the first time. My main idea back then was that this could be interesting with an external screen and keyboard (my phone has USB-C so this is easily possible). However, what I noticed is that keys that are fundamental for any window manager like the super/windows key or the combination alt+tab are bound by Android and cannot be used. Due to that I did not further continue with that idea. Is there any solution for that (apart from modifying android)?

[twaik]

@michitux Proot affects perfomance much and XServer XSDL is not the best X11 server I have seen. Even MaruOS's mflinger has some limitations. You can try to use Linux Deploy (chroot) + Sparkle driver. That would be much faster.

So maybe you could post a link here when you get there

I think you will surely know about it: I will post links everywhere :)

[eMPee584]

@twaik maybe you can roll your experiment with termux first, then try creating a bionic port of alpine linux?

[twaik]

@eMPee584 you have a point there.

[twaik]

Looks like that's not a pmOS issue.