This repository has been archived by the owner. It is now read-only.

Add feature/hybris branch for experimenting with libhybris-based HW adaptations (issue #678) #1002

Merged
merged 6 commits into from Dec 12, 2017

Conversation

Projects
None yet
2 participants
@NotKit
Collaborator

NotKit commented Dec 12, 2017

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.

@ollieparanoid ollieparanoid referenced this pull request Dec 12, 2017

Closed

libhybris support? #678

@ollieparanoid ollieparanoid changed the base branch from master to feature/hybris Dec 12, 2017

@ollieparanoid ollieparanoid merged commit 71f1770 into postmarketOS:feature/hybris Dec 12, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage remained the same at 64.037%
Details
@ollieparanoid

This comment has been minimized.

Show comment
Hide comment
@ollieparanoid

ollieparanoid Dec 12, 2017

Member

I've merged this into a new feature/hybris branch, as you suggested in the title. And I've written down my thoughts about proceeding further in #678.

About the current status of Droid 4 port [...]

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!

Member

ollieparanoid commented Dec 12, 2017

I've merged this into a new feature/hybris branch, as you suggested in the title. And I've written down my thoughts about proceeding further in #678.

About the current status of Droid 4 port [...]

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!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.