|Gentoo RAP on Android Devices|
|Description||Gentoo on Android aims to provide desktop experience on Android mobile devices. This project deploys Gentoo RAP, a variant of Gentoo that installs in a directory prefix, along with Android, sharing the same Linux kernel.|
No lead election date set
(and inherited members)
|Parent Project||Gentoo Prefix|
This project is about bringing Gentoo users and develops home to their mobile devices. It aims to produce an environment indifferent to that of desktop computers. It strives to liberate the computers in our pockets with Gentoo philosophy and style, as an ultimate response to Free Software Foundation(FSF)'s concerns on the freedom for mobile computing.
The mobile devices today become more powerful than desktop computers 10 years ago. As the hardware performance boosts, the software becomes a flexible part of the system. The pursuit of software freedom on desktop computers carries naturally to mobile ones.
FSF has recognized the freedom for mobile computing early on. With a GPL-licensed Linux kernel and a Apache-licensed userland, Android is a big step forward for the smartphones, tablets and multimedia centers. At the same time, as FSF points out, there is still a long way to go to regain full control of our own devices.
Vendors have put effort to make their source code open. However, it is rather challenging to figure out exactly how to build from the source a usable system. Linux kernels have patches from vendors that should be tracked. The proprietary binary blobs to drive certain hardware should be carefully analyzed and documented. The bootloaders and flashing tools vary across vendors and impose artificial restrictions for either practical or profit reasons.
Project cyanogenmod is another step forward in that its build system, finely version controlled, tracks the details needed to build a working system. The development cycle of cyanogenmod is to cross compile, flash the image and test. With the advancement of mobile computing power, native compiling right on the device becomes feasible.
The point of native compiling in-situ is to make development and porting more direct and easier. With the help of an additional GNU userland, the development and test on the mobile devices will be no different from developing desktop computers applications: our phone becomes more hackable and more enjoyable to tweak with.
Gentoo is exactly good at managing building recipes with utmost clarity and elegance by its Portage/Ebuild system. Ebuilds are the most suitable installation documentations that are able to be executed and verified to work. Gentoo has the potential to make native development environment for mobile devices reality.
To achieve our ultimate goal of mobile computation freedom, three stages are required. First, a set of tools familiar to a GNU/Linux user should be installed by Gentoo RAP. Second, the Linux kernel should be recompiled and customized using the Gentoo RAP tools by the user. Finally, GNU userland should be able to access input/output peripherals (like HDMI video/audio output, USB keyboard, etc.) and have an X window system. Android and GNU userlands should be integrated by message passing interfaces and framebuffer copying and sharing.
Android focuses on its touch screen user interface. The development does not happen in Android itself, but in the software development kit(SDK) elsewhere. When the end product is compiled and distributed, the only feasible way to change the system is to flash the whole partition again with another customized whole partition image.
This step is to provide a new way of development by deploying a powerful environment, Gentoo RAP, into the mobile device that feels natural to every UNIX user.
Gentoo RAP is a variant of Gentoo Prefix having its own libc, which installs an instance of Gentoo in to a directory prefix, along with Android userland, sharing the same Linux kernel. Because Android system usually sits in /system directory, it is possible to install a native Gentoo into root directory /. But since / is managed by initramfs in Android, the actual native Gentoo has to be installed to another directory and symlinked back to /. To avoid such a burden, Gentoo RAP is preferred. Furthermore, like Gentoo Prefix, RAP has the potential to be deployed with a normal user on non-rooted devices.
Anything available in Gentoo is in Gentoo RAP. A set of toolchain, an editor and a shell are especially useful for further development, debugging, and hacking.
The device list records all the device test results.
Android has deep (and sometimes in-house) customizations to the official Linux kernel. Third party vendors further customize the Android source. These sources scatters over the Internet. Using ebuilds to track patchsets and customized sources is the Gentoo-preferred way to handle this complexity.
When necessary, the ebuilds should acknowledge the fact that a set of git repositories are mananged by the repo tool, and leverage the information in repo metadata.
For every supported device, a set of default kernel config should be provided along with the kernel source and patchset. Portage should be able to compile a usable custom kernel from the ebuilds. To run the custom kernels, a bootloader unlocked device is necessary.
After gaining full control of the kernel, we could develop something new and cool.
Webtop (dead) from Motorola and prospect Ubuntu for Android, makes use of the HDMI output for their X servers. In such systems SurfaceFlinger of Android and X independently use two framebuffers, which in turn, relies on two independent graphics outputs, namely local display and HDMI.
It is also very helpful to have local display shared between SurfaceFlinger and X. HDMI output with an external monitor is not always available, and X on local display will become an interesting application on a Android tablet.
The feature can be realized by hacking framebuffer in the kernel. Write a framebuffer multiplexer: a void framebuffer driver, which can either drop the data written into it or forward the data to another framebuffer. Controlling this framebuffer multiplexer via sysfs will allow userland to select the real source of a framebuffer.
Motorola has demonstrated a revolutionary concept to have GNU and Android integrated together. Its Webtop product, until version 2.0, features a Ubuntu GNU userland running aside Android and introduced a data-exchange mechanism. In Webtop, the user is presented with an Ubuntu environment and has access to the Android system at the same time.
Canonical intended to carry this concept further under the project Ubuntu for Android after Motorola had abandoned the idea. Canonical does not give any technical details except advertising (from 2012) and collecting donations (from 2013). The advertisement by Canonical itself is nice because it presents the concept in an easy to understand way. As of 2014, the project delivered no end result.
The Webtop 2.0 system has several closed-source components to carry out data-exchange between GNU and Android. It would very nice to have tools with the same purpose available as free software.
With Gentoo RAP tools and a customizable kernel, we will reverse engineer the existing integration mechanism and write free alternatives.
RecruitmentWe are currently looking for users interested in helping the project with these jobs:
|Embedded Kernel Hacker||Maintain the kernel ebuilds for mobile devices.||Experience with kernel and embedded email@example.com|
|Android Developer||Develop a solution of Wayland based on Android graphic drivers based on libhybris, preferrably sharing framebuffer with Android.||Familiar with Gentoo Prefix (and its RAP variant), and Android. Familiar with X11 and Wayland. Experience with C.||firstname.lastname@example.org|