Hubbry Logo
LibhybrisLibhybrisMain
Open search
Libhybris
Community hub
Libhybris
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Libhybris
Libhybris
Libhybris
View on Wikipedia
from Wikipedia

Hybris
Original authorCarsten Munk
DevelopersMer, Jolla, Open webOS community, Canonical Ltd.
Initial release5 August 2012; 13 years ago (2012-08-05)[1]
Written inC, C++
Operating systemLinux
TypeCompatibility layer
LicenseApache License 2[2]
Websitegithub.com/libhybris
Repository
The GNU C Library (glibc) and libbionic act as a wrapper around the Linux system calls. Libhybris replaces Libbionic and works on top of the glibc, i.e. it hooks into glibc instead of into the Linux kernel system calls, thereby acting as a compatibility layer.
The Android operating system replaces the GNU C Library with libbionic. Both libraries are wrappers around the system calls of the Linux kernel, but while the GNU C Library has aimed to become and stay POSIX-compliant, libbionic does not. Programs written for libbionic can only run on GNU C Library with the help of another wrapper called libhybris.
While a programmer targets and uses an API, a compiled program can only use the resulting ABI. . After compilation, the binaries offer an ABI.

libhybris is a compatibility layer for computers running Linux distributions based on the GNU C library or Musl,[3] intended for using software written for Bionic-based Linux systems, which mainly includes Android libraries and device drivers.[4]

History

[edit]

Hybris was initially written by Carsten Munk, a Mer developer, who released it on GitHub on 5 August 2012[1] and publicly announced the project later that month.[4][5] Munk has since been hired by Jolla as their Chief Research Engineer.[6]

Hybris has also been picked up by the Open webOS community for WebOS Ports,[7][8] by Canonical for Ubuntu Touch[6][9] and by the AsteroidOS[10] project.

In April 2013, Munk announced that Hybris has been extended to allow Wayland compositors to use graphic device drivers written for Android.[6][11][12] Weston has had support for libhybris since version 1.3, which was released on 11 October 2013.[13]

Features

[edit]

Hybris loads "Android libraries, and overrides some symbols from bionic with glibc"[4] calls, making it possible to use Bionic-based software, such as binary-only Android drivers, on glibc-based Linux distributions.

Hybris can also translate Android's EGL calls into Wayland EGL calls, allowing Android graphic drivers to be used on Wayland-based systems. This feature was initially developed by Collabora's Pekka Paalanen for his Android port of Wayland.[6][14][15][16]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Libhybris

View on Grokipedia
from Grokipedia
libhybris is an open-source designed to enable the loading and execution of Android's Bionic-compiled layer (HAL) libraries and drivers within glibc-based or other libc environments on systems. Developed initially by Stskeeps as part of the Mer project, it acts as a libdl-like interface that overrides Bionic symbols with equivalents, bridging the gap between Android's userspace hardware adaptations and standard applications. This facilitates the use of proprietary Android drivers for components such as GPUs, cameras, audio, sensors, and on devices lacking open-source alternatives. Primarily utilized in mobile Linux distributions, libhybris has been integral to projects like , where it integrates Android Board Support Packages (BSPs) into the operating system's architecture, allowing hardware access through middleware components such as pulseaudio-modules-droid and gst-droid for audio and multimedia. It supports a wide range of ARM-based devices from manufacturers including HTC, , , , , , and , with adaptations covering smartphones and tablets running kernels from 2.6 to 4.9. Historically, it powered ports for , enabling Mir display server compatibility with Android GPU drivers, and was employed in to containerize Android components on downstream kernels for devices without mainline support. The library requires ARMv7 or architectures and 3.17 or later, often in conjunction with frameworks like Halium or Project Treble for Android 9 compatibility. While effective for accelerating development on Android hardware, libhybris has seen reduced adoption in some ecosystems, such as its deprecation in in favor of native drivers, though it remains active in adaptations via repositories like mer-hybris. Licensed under the 2.0, libhybris continues to support in Wayland-based environments and custom plugins for multimedia on libhybris-enabled devices.

Overview

Definition and Purpose

Libhybris is an open-source compatibility layer designed to enable the loading and execution of libraries compiled against Android's bionic libc—such as hardware abstraction layers (HALs)—within systems that use or libc implementations. This bridging mechanism translates bionic-specific calls into equivalents compatible with standard C libraries, allowing Android-compiled binaries to function in non-Android environments without extensive recompilation. The primary purpose of libhybris is to permit distributions to access and utilize proprietary or vendor-optimized Android hardware drivers on devices originally engineered for Android platforms, all while avoiding the overhead of a complete stack. By providing a lightweight interface for hardware interactions, it supports the integration of Android's userspace components into glibc-based systems, particularly for mobile and embedded applications. Key benefits include enabling for critical components like (via EGL/GLES), audio, sensors, and (through the Radio Interface Layer or RIL), which enhances performance in mobile operating systems without requiring full driver reverse-engineering. This approach significantly lowers the barrier for environments to locked-down mobile hardware. Developed within the Mer project in the early amid Android's growing dominance in the market, libhybris emerged to facilitate software stacks on devices reliant on Android-specific drivers.

Relation to Android Ecosystem

Libhybris serves as a that enables the integration of Android's bionic libc-compiled libraries into environments utilizing or libc implementations. By acting as a wrapper, it translates calls from the lightweight bionic C library—developed by for Android—to equivalent functions in , while also providing a custom implementation of libdl for dynamic linking of Android binaries. This layer depends heavily on vendor-supplied Android Layers () to facilitate hardware interactions, bridging the gap between non-Android user-space applications and device-specific drivers. For instance, it relies on the Gralloc HAL module for allocating and managing graphics memory buffers essential for rendering operations, and on AudioFlinger for routing and processing audio streams through the device's sound hardware. In the overall software stack, libhybris occupies a pivotal position between user-space applications and kernel-level drivers, many of which are derived from Android sources, thereby allowing accelerated features such as without requiring a complete . This setup supports the reuse of proprietary Android hardware blobs on standard distributions. To achieve this , libhybris employs mechanisms like LD_PRELOAD, which intercepts and redirects calls to Android libraries at runtime, ensuring binary compatibility for closed-source components that would otherwise be incompatible with glibc-based systems.

History

Origins in Mer Project

libhybris originated in 2012 within the Mer Project, an open-source initiative launched by the Finnish company as a community-driven successor to the operating system. Mer aimed to establish a robust, middleware-agnostic foundation for mobile distributions, addressing the challenges posed by Android's growing lock-in on hardware ecosystems, where proprietary drivers and adaptations were predominantly tailored for Android's Bionic libc rather than standard glibc-based systems. This context was critical for projects like , Jolla's mobile platform, which sought to leverage existing hardware without the need for extensive proprietary reinvestments. The library was primarily developed by engineers, with Carsten Munk, then Chief Research Engineer at , serving as the key initiator. Munk released an initial prototype in August 2012, driven by the need to port to devices originally designed for Android, thereby enabling broader hardware compatibility for Mer-based systems. Early contributions also came from community members associated with the Open webOS project, including developers like Florian Haenel, Thomas Perl, and Simon Busch, who collaborated on integrating Android components into glibc environments. The core motivation behind libhybris was to facilitate the reuse of Android's mature Layer (HAL) ecosystem—encompassing drivers for sensors, cameras, and processing units (GPUs)—directly within -based Linux distributions. By providing a translation layer between Android's Bionic libc and , it allowed developers to avoid the costly and time-intensive task of reimplementing hardware drivers from scratch, particularly for GPU acceleration via . This approach enabled efficient hardware access for non-Android systems like Mer and , focusing initially on and input handling to support Qt-based applications. The first public prototype appeared on in August 2012 under Munk's personal repository (stskeeps/libhybris), with a commit demonstrating basic Bionic-to-glibc translation for Android shared libraries. By early , the project gained visibility through Mer Project announcements, leading to a cleaned-up version released under the 2.0 and hosted in the mer-hybris organization on , where it focused on foundational compatibility for hardware adaptations.

Evolution and Key Milestones

In 2014, libhybris saw initial integration into , enabling ports to Android-based devices such as the Google Nexus 4 (codenamed "mako"). This marked a significant step in utilizing libhybris as a to leverage Android hardware abstraction layers () within a glibc-based environment, allowing to access proprietary Android drivers for graphics and other hardware without full Android dependency. By 2016, detailed installation guides for on the Nexus 4 further solidified this integration, demonstrating libhybris's role in facilitating multi-boot setups alongside Android. The period from 2017 to 2019 brought expanded adoption through forks and collaborative efforts. In April 2017, the Halium project was announced, uniting developers from (via UBports), , communities, and others to standardize HAL support using libhybris as the core compatibility mechanism. forked and adapted libhybris to work with libc, enabling compatibility with bionic-compiled Android libraries on musl-based systems, while extending support to ARM64 () architectures for devices running Halium 9 (targeting Android 9). similarly incorporated these forks via Halium, broadening libhybris's applicability to diverse Linux mobile distributions. Between 2020 and 2023, libhybris underwent enhancements to support newer Android HALs, including compatibility with and 11 through Halium branches like halium-10.0, which addressed evolving vendor interfaces for . Graphics improvements focused on integrating support via Android's graphics HAL, allowing better rendering performance in environments without native Vulkan drivers. In 2022, maintenance of the original Mer Project's libhybris repository shifted toward community-driven forks, such as the libhybris/libhybris repository, as upstream activity waned. From 2024 to 2025, updates emphasized compatibility with via Halium 14, incorporating branches like halium-14.0 to handle updated HAL requirements for modern devices. Recent discussions in the UBports forum in October 2025 highlighted versioning challenges with libhybris and Halium, particularly around aligning Android base versions with ongoing ports. The libhybris/libhybris repository remains active, with over 70 open issues as of late 2025 focused on bug fixes for HAL stability and device-specific integrations. Key milestones include the release of libhybris 0.1.0+git within layers, which standardized packaging for embedded Linux builds and facilitated broader adoption. Additionally, libhybris's integration into Nemo Mobile, a Mer-based distribution continuing MeeGo's legacy, enabled hardware adaptations for mobile devices using the Nemo stack alongside Android drivers.

Technical Architecture

Compatibility Layer Mechanics

Libhybris operates as a runtime shim that provides compatibility between Android's Bionic libc and glibc-based systems by implementing a libdl-API-like interface. This core mechanism includes a fake libdl.so, which loads Bionic-compiled libraries and resolves their symbols through a dedicated translation table. Wrappers for standard functions like dlopen and dlsym facilitate and symbol lookup, allowing Android hardware adaptations to function without full dependencies. The symbol translation process maps Android-specific functions—for instance, those defined in libhardware.so—to equivalent glibc implementations, ensuring seamless interoperability. This mapping addresses key differences between Bionic and glibc, particularly in threading models where pthreads are wrapped and sanity-checked for compatibility, and in memory management routines that require adjustments to avoid conflicts. By overriding Bionic symbols with glibc-based alternatives during resolution, libhybris enables applications to invoke Android APIs as if running in a native environment. During the loading process, applications link directly against libhybris, which intercepts calls directed at Android binary blobs, such as GPU or telephony drivers. These intercepted calls are then forwarded to the underlying via interfaces, bypassing the need for Android's full user-space stack while maintaining hardware access. This interception occurs at the level, ensuring that Bionic-linked code executes correctly on hosts. To build libhybris, developers compile it using the , which provides the necessary Bionic headers and toolchain for compatibility. Integration into Linux distributions, such as those using Yocto or , relies on files generated during the build to handle library paths and dependencies. The process typically involves cloning the source repository, running autogen.sh for configuration, and executing make for compilation and installation.

Integration with Hardware Abstraction Layers

Libhybris facilitates hardware access in non-Android Linux environments by wrapping and adapting Android's Hardware Abstraction Layers (HALs), enabling glibc-based systems to utilize bionic-compiled drivers originally designed for Android devices. This integration is central to projects like Halium, which standardize HAL usage across mobile distributions, allowing seamless bridging between Android's hardware interfaces and userland applications. Supported HALs include components such as Gralloc for buffer allocation and HWComposer for layer composition, AudioHAL for sound processing, Sensors HAL for device sensors, and telephony via integration with the RIL (Radio Interface Layer) daemon. The adaptation process involves libhybris providing specialized wrappers to intercept and translate Android HAL calls into compatible Linux operations. For instance, the hybris_gralloc wrapper manages graphics buffer allocation by handling Android's memory requirements, such as shared memory mechanisms, and mapping them to Linux-native equivalents to ensure efficient resource use without direct bionic dependency. Similarly, for audio, libhybris employs dlopen to load the AudioHAL directly, while middleware like pulseaudio-module-droid routes audio streams through the HAL. Sensors HAL integration follows a comparable pattern, with wrappers exposing sensor data to Linux frameworks, and telephony relies on socket-based communication with the RIL daemon to handle modem interactions. These wrappers minimize the need for deep Android code modifications, prioritizing compatibility layers for C++ interfaces where necessary. Libhybris supports HAL versions spanning Android 4.x through 10 (as of 2025), aligning with Halium versions from 6 to 10; for deprecated components like the legacy Camera HAL, it includes shims to maintain without requiring full driver rewrites. This version handling ensures ports remain viable on devices with varying Android firmware ages. At the kernel level, libhybris depends on Android-derived kernel modules—such as kgsl for GPUs—to expose hardware functionality, with ioctls passed through directly from user space to kernel drivers, avoiding unnecessary abstraction overhead. A representative workflow for GPU rendering illustrates this integration: libhybris loads Android's libEGL.so library, which interfaces with the graphics HAL, and maps the resulting calls to open-source drivers like Mesa or freedreno for GPUs, enabling hardware-accelerated rendering in applications such as Wayland compositors. This approach leverages existing Android blobs where full open-source kernel support is unavailable, providing a practical path to hardware utilization in distributions like and .

Implementations and Usage

Adoption in Linux Distributions

Libhybris has been a core component of , developed by , since its initial release in 2013, facilitating ports to Android devices by enabling the use of proprietary Android drivers within Sailfish OS's gesture-based . This integration allows , built on the Mer project, to leverage Android's layers (HAL) through libhybris's compatibility mechanism, supporting a wide range of smartphones without requiring fully open-source drivers. In , an Alpine Linux-based distribution for mobile devices, libhybris was adopted starting in 2017 to enable and proprietary driver support on devices with Android-derived kernels. Developers utilized pmbootstrap, postmarketOS's build tool, to create libhybris-enabled images via the hybrisaports repository, allowing the distribution to run on hardware lacking mainline compatibility. However, as of late 2024, libhybris support has been discontinued in , with the project shifting focus away from hybris-based adaptations. Halium, a libhybris-based framework, has been to Ubuntu Touch since 2017, providing a standardized HAL interface that bridges Android's proprietary drivers with the Lomiri . This setup enables ports on devices running Android 9 through 13 by translating bionic-compiled libraries for glibc-based systems, simplifying hardware integration for cameras, sensors, and other peripherals. Beyond these, libhybris has seen adoption in other Linux distributions for mobile and embedded use cases. Nemo Mobile, a continuation of the project, integrates libhybris through Halium compatibility, with ports to various devices including the Xiaomi 7 and Poco series via Halium. , KDE's mobile interface, initially relied on libhybris within Halium for on Android devices like the , though support is being phased out in favor of mainline kernel devices. Additionally, libhybris is integrated into and build systems through dedicated recipes in layers like meta-android, enabling its use in custom embedded Linux images for hardware adaptations. Distributions typically track libhybris via Git snapshots rather than stable releases, with Halium versions (e.g., 7.1 through 14) aligning to corresponding Android versions 7 through 14, including Halium 14 for as of October 2025, to ensure compatibility with evolving HAL APIs. This versioning approach allows projects like and to maintain support for newer Android hardware ecosystems.

Supported Hardware Platforms

Libhybris has been implemented on a wide range of Snapdragon-based devices, leveraging the compatibility layer to interface with GPUs through binary blobs or the open-source Freedreno driver stack. Notable examples include the MSM8916 SoC in the 5 (hammerhead), where libhybris enables for graphics and multimedia in non-Android environments. Support extends to the SDM845 SoC in devices like the , facilitating ports to distributions such as and postmarketOS. More recent implementations cover up to the SM8350 (Snapdragon 888) in 2021-era smartphones, with ongoing community efforts integrating Freedreno for improved open-source compatibility. For Samsung Exynos platforms, libhybris supports ports on S series devices, particularly those with GPUs. The 7420 SoC in the S6 (zeroltexx) utilizes libhybris to bridge Android hardware abstractions, enabling features like GPU rendering in Linux-based systems such as community adaptations. Similar support exists for earlier models like the S4 (jfltexx) with 4412, where the layer handles display and sensor integration. Sony Xperia devices receive extensive libhybris support, especially in community ports, due to their hardware and active developer involvement. The Xperia Z3 (thea), equipped with the 400 GPU on a Snapdragon 801 SoC, demonstrates robust compatibility for camera, audio, and graphics acceleration. This extends to variants like the Xperia Z3 Compact (aries), integral to early Mer Project adaptations and ongoing maintenance in projects like Halium. Other vendors feature targeted libhybris implementations through community efforts. HTC's One M7 (m7) with Snapdragon 600 benefits from established ports for and display. Huawei's P8 Lite uses libhybris for Kirin integration in . Motorola's (shamu) on Snapdragon 805 supports full hardware access in . Xiaomi's Mi A1 (tissot) with Snapdragon 625 enables Android 7.1-based ports via Halium. Limited community-driven support exists for NXP processors in select tablets and for SoCs in devices like certain Volla handsets, though these remain experimental and less mature. As of 2025, over 50 devices are documented in the wiki (though libhybris support has been discontinued there), with Halium accelerating new ports based on hardware abstraction layers for enhanced compatibility on Treble-enabled smartphones.

Limitations and Alternatives

Known Challenges and Limitations

Libhybris, as a bridging Android's Bionic-based hardware adaptations with systems, introduces challenges due to the translation of API calls between the two environments. Compatibility gaps persist with evolving Android hardware abstraction layers (HALs), as libhybris was primarily developed around older Android versions and may not fully support newer interfaces. For instance, support for advanced HALs such as for acceleration remains incomplete, limiting workloads. Additionally, changes in newer Android versions, including updates to the Vendor Interface Object (VINTF), can cause integration issues, requiring custom patches that are not always available or stable across devices. As of November 2025, libhybris support remains limited to Android versions up to 12 in projects like Halium, with community efforts for versions 14 and 15 requiring unofficial patches. Security concerns arise from libhybris's reliance on vendor blobs, which are closed-source binary drivers extracted from Android . These blobs often contain unpatched vulnerabilities, as vendors prioritize their own ecosystems over third-party updates, leading to potential exploits in outdated . Sandboxing mechanisms in libhybris implementations vary by distribution and may not always include equivalents to Android's SELinux, such as in some setups, potentially exposing the system to broader risks from unverified hardware interactions. The maintenance burden is significant due to the dependency on stagnant Android vendor blobs, which frequently break compatibility during kernel updates or hardware revisions. Porting libhybris to new devices requires extracting and adapting these blobs, a process that demands device-specific tweaks and can fail with upstream kernel changes, increasing the effort for maintainers. Persistent issues stemming from mismatched HAL implementations continue to challenge adaptations. Licensing for libhybris itself follows the Apache 2.0 license, promoting open reuse, but its integration with proprietary Android code—often under restrictive vendor terms—complicates redistribution and modification. This mix can conflict with GPL-licensed components in distributions, as the closed blobs cannot be freely altered or shared, hindering full open-source compliance in deployments.

Comparison with Other Solutions

Libhybris provides a lightweight for integrating Android's hardware abstraction layer (HAL) into glibc-based systems on mobile devices, contrasting with full Android emulation solutions like Anbox, which run a complete in a on desktops. Anbox, developed in 2017, leverages containers to boot a full Android system for app execution but requires significant overhead for the entire runtime environment, whereas libhybris avoids this by directly wrapping only the necessary bionic-based hardware adaptations without emulating a full Android userspace. This makes libhybris more resource-efficient for hardware access on resource-constrained mobile hardware, though it demands device-specific efforts tied to the original Android vendor blobs, unlike Anbox's more generic focus on x86 architectures for desktop integration. In comparison to native Linux drivers such as freedreno for GPUs or i915 for graphics, libhybris offers broader support for Android hardware components like cameras and sensors where open-source alternatives remain incomplete. Native drivers provide a purer (FOSS) implementation with lower overhead and better integration into mainline kernels, but they often lack full functionality for non-graphics peripherals on older or vendor-specific mobile SoCs. Libhybris, by contrast, incurs some performance overhead from the compatibility shim but enables functionality on devices without mature native driver support, prioritizing practicality over ideological purity. Halium extends libhybris by standardizing the HAL middleware for /Linux distributions on Android-based mobile devices, facilitating projects like and through unified interfaces for services such as telephony and audio. While Halium builds directly on libhybris for hardware bridging, alternatives like custom modifications maintain an Android-like user interface and app ecosystem without incorporating a full userspace, avoiding the need for HAL translation layers altogether. These Android-centric hacks emphasize continuity of proprietary app compatibility over the desktop-oriented environments enabled by libhybris and Halium. Waydroid, introduced around 2020, represents a more recent approach that runs a full Android system within a host for seamless app integration, often outperforming libhybris in Android app compatibility due to its complete runtime support. Unlike libhybris's HAL-only focus, which targets Linux userspace on mobile hardware with minimal Android components, Waydroid demands higher resource usage for the containerized environment but provides better isolation and broader desktop applicability, including Wayland sessions. Overall, libhybris excels in reviving legacy devices from around 2015, such as older Qualcomm-based smartphones lacking mainline kernel support, by leveraging existing Android drivers without requiring full OS overhauls. However, it trades off against modern features like advanced AI acceleration, where vendor-locked solutions or native drivers offer superior performance and future-proofing on newer hardware.

Development Status

Current Maintenance and Updates

Libhybris is primarily maintained through the libhybris/libhybris repository on GitHub, a fork of the original mer-hybris/libhybris project, with the upstream mer-hybris seeing its last significant activity in 2024 before maintenance shifted to community forks. Halium, a related hardware abstraction layer project, continues to integrate libhybris patches, particularly for Ubuntu Touch and similar mobile Linux initiatives, ensuring compatibility with evolving Android hardware interfaces. The project lacks formal versioning beyond its initial 0.1.0 release from 2013 and does not use release tags, though commits provide support for as of 2024-2025. Recent commits in 2025 have addressed compatibility issues, including a merge in June 2025. The last confirmed commit was on June 30, 2025. Activity in the original Mer Project has declined, with efforts increasingly led by communities around and Halium, though dropped libhybris support on November 17, 2024, in favor of mainline kernel approaches. As of November 2025, the primary repository reports 71 open issues and ongoing contributions, indicating sustained but modest involvement.

Community and Contributions

The libhybris project is primarily driven by open-source communities focused on mobile distributions, with key discussion hubs including the wiki for technical documentation and the IRC channel #postmarketos on for real-time collaboration. UBports maintains dedicated forums for Halium-related discussions, where libhybris integration in ports is frequently addressed by developers tackling hardware compatibility issues. Additionally, Jolla's Together platform serves as a forum for community ports of , often involving libhybris adaptations for non-official devices. Contributions to libhybris follow standard open-source practices on its GitHub repository, where developers fork the project, implement changes, and submit pull requests through the issue tracker for review. Testing is essential and typically requires deploying builds on target hardware, using tools like the Android Debug Bridge (adb) logcat to capture and analyze runtime logs for hardware abstraction layer (HAL) functionality. Prominent individual contributors include Oliver Smith, a lead developer in who has advanced libhybris support for newer Android versions and device ports. UBports teams have extended libhybris through Halium, enabling ports for devices like the S10. while corporate involvement from has diminished following its strategic pivot away from broad hardware support. Essential resources for engagement include the Mer Wiki's Adaptations/libhybris page, which provides porting guides and was last updated on June 23, 2025. Build instructions are available for integrating libhybris into Yocto-based systems via layers and for environments through APKBUILD recipes. Community efforts face challenges such as relatively low barriers to initial HAL porting but significant hurdles in updating vendor blobs across Android versions, which often require device-specific tweaks. There are ongoing calls within these communities to transition toward more (FOSS) drivers to reduce reliance on closed blobs and improve long-term maintainability.

References

  1. https://github.com/libhybris/libhybris
  2. https://www.phoronix.com/news/MTE5Mjk
  3. https://www.cnx-software.com/2013/04/08/libhybris-let-you-use-android-drivers-hw-libraries-in-linux/
  4. https://docs.sailfishos.org/Reference/Architecture/
  5. https://wiki.merproject.org/wiki/Adaptations/libhybris
  6. https://wiki.postmarketos.org/wiki/Hybris
  7. https://github.com/mer-hybris
  8. https://docs.sailfishos.org/Reference/Core_Areas_and_APIs/Multimedia/
  9. https://www.phoronix.com/news/MTQ1NTc
  10. https://lwn.net/Articles/560442/
  11. https://wiki.merproject.org/wiki/Adaptations/libhybris/gpu
  12. https://github.com/mer-hybris/audioflingerglue
  13. http://mer-project.blogspot.com/2013/04/wayland-utilizing-android-gpu-drivers.html
  14. https://www.cnx-software.com/2013/04/21/how-to-use-libhybris-and-android-gpu-libraries-with-mer-linux-on-the-cubieboard/
  15. https://www.osnews.com/story/27643/first-sailfish-os-build-for-nexus-4-released/
  16. https://wiki.merproject.org/wiki/Adaptations/libhybris/Install_SailfishOS_for_mako
  17. https://halium.org/announcements/2017/04/24/halium-is-in-the-air.html
  18. https://github.com/Halium/android/activity
  19. https://source.android.com/docs/core/graphics/implement-vulkan
  20. https://forums.ubports.com/topic/11484/android-version-and-libhybris
  21. https://github.com/libhybris/libhybris/issues
  22. https://layers.openembedded.org/layerindex/recipe/400071/
  23. https://wiki.merproject.org/wiki/Nemo
  24. https://docs.halium.org/en/latest/project/Scope.html
  25. https://github.com/mer-hybris/pulseaudio-modules-droid
  26. https://github.com/libhybris/libhybris/tree/master/compat/camera
  27. https://halium.org/
  28. https://docs.sailfishos.org/Tools/Hardware_Adaptation_Development_Kit/
  29. https://ubports.com/halium
  30. https://nemomobile.net/pages/nemomobile-in-may-2023/
  31. https://layers.openembedded.org/layerindex/recipe/49019/
  32. https://docs.halium.org/en/latest/supplementary/devices/index.html
  33. https://wiki.postmarketos.org/wiki/Devices
  34. https://project.inria.fr/resourcearbitration/files/2022/05/ipdps22_radr_white.pdf
  35. https://archive.fosdem.org/2022/schedule/event/mobile_kernel_mainline/attachments/slides/4856/export/events/attachments/mobile_kernel_mainline/slides/4856/Porting_mainline_Linux_to_mobile_phones.pdf
  36. https://docs.halium.org/_/downloads/en/latest/pdf/
  37. https://source.android.com/docs/core/architecture/vintf/match-rules
  38. https://arxiv.org/pdf/2410.11075
  39. https://canonical-mir.readthedocs-hosted.com/_/downloads/en/v2.17.2/pdf/
  40. https://blog.mobian.org/posts/2023/03/07/porting-to-new-devices/
  41. https://github.com/anbox
  42. https://lwn.net/Articles/597560/
  43. https://wiki.archlinux.org/title/Waydroid
  44. https://github.com/mer-hybris/libhybris
  45. https://github.com/libhybris/libhybris/releases
  46. https://github.com/libhybris/libhybris/commits/master
  47. https://libera.chat/
  48. https://forums.ubports.com/
  49. https://gitlab.com/postmarketOS/pmaports/-/merge_requests/665
  50. https://forums.ubports.com/topic/11131/halium-12.0-lineageos-19.1-ubuntu-touch-focal-20.04-for-samsung-galaxy-s10-beyond1lte-build-rootfs-from-scratch
  51. https://forum.sailfishos.org/t/jolla-c2-halium-version/25116
  52. https://layers.openembedded.org/layerindex/recipe/7594/
  53. https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/85586ffbed39a0919e915fb65644f9a3b5267e46/hybris/libhybris/APKBUILD
Add your contribution
Related Hubs
User Avatar
No comments yet.