Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Add feature/hybris branch for experimenting with libhybris-based HW adaptations (issue #678) #1002
libhybris is a compatibility layer that allows to use Bionic-based Android libraries and drivers in glibc systems.
The way it's implemented has no particular dependency on glibc though, and most of changes required for musl were compilation fixes. Yet I had to disable some hooks due to hooked functions missing in musl, which might cause issues if bionic versions of that functions don't work properly with musl structs/without proper bionic initialization, but so far OpenGL acceleration has been tested to work on Moto Droid 4, Moto Z Play and OnePlus 2.
Using Android libraries in most of cases requires base/core Android system to be up and running, which includes its init system, property service, logger, servicemanager, device specific services and so on. It's mostly lightweight though, since this is limited to native code, so Java VM and higher level Android components are never started.
Currently there are two approaches to packaging Android base. libhybris requires patched versions of some Android libraries and components. Mer (SailfishOS base) uses customized Android tree (https://github.com/mer-hybris) to build them, then packages modified libs and init scripts into droid-hal-$device packages. Unmodified files are used as-is by mounting /system partition from corresponding CyanogenMod/LineageOS install. Android base runs in same root with "Linux" system.
Halium instead builds minimal self-content Android rootfs with patched components and runs it inside LXC. This is a cleaner solution overall. While it has halium-5.1 branch, only halium-7.1 branch is actively maintained so far, so it's way easier to build for newer devices than for older ones, especially if they don't have LineageOS 14.1 port.
Due to this I went packaging "droid-hal-maserati" from SailfishOS community port for Droid 4 and added simple OpenRC script to start droid-hal-init (renamed Android init). The device has old 3.0.8 kernel, so I wasn't sure if it can start LXC at all, but LXC website tells that it requires at least 2.6.32.
The issue is that libhybris must be built with Android headers extracted from device, or at least Android headers matching Android version on device and SoC vendor. I'm not sure how to go around creating multiple packages like libhybris-4.4, libhybris-7.1, libhybris-7.1-caf and so on. What's worse, software utilizing libhardware through libhybris (for example, interfacing with gralloc and hwcomposer) currently has the same kind of dependency on Android headers it's built with, so with current approach there will be say kwin-4.4, kwin-7.1, xf86-video-hwcomposer-4.4 and so on.
About the current status of Droid 4 port, which I included as example. It boots if encryption is disabled, osk-sdl won't display yet during initramfs stage, but will display after starting and finishing Xorg with xf86-video-hwcomposer backed. It seems PowerVR driver does some calls to activate/reset framebuffer. It can start Xorg server with mentioned driver and utilize 3D acceleration via libhybris (tested with hildon-desktop). Once Qt QML JIT bug fixed on armhf, it should be able to start LuneOS with 3D acceleration as well, if needed middleware is packaged. Wi-Fi works when wpa_supplicant is started with wext backend.
I've merged this into a new
Would you mind creating wiki pages for the devices you have been experimenting with, which contain links to the packaging you did for them? If you don't have a version that works without libhybris for them, you could add them to the wiki as "Not booting", and write something like "libhybris experiments (boots with 3D acceleration, not in master branch)" in the description.
@NotKit, thank you very much for your work and for the detailed and well structured explanation. It's obvious that you put a lot of effort into this!