634 posts
Thanks Meter: 356
Post Reply Email Thread
Jump To:
Possible Methods of Android-Linux Dual Booting: CHROOT vs. LXC vs. VM

[Q] I download setup (an ISO) of Windows or Ubuntu from internet and install it on my laptop. The same ISO is booted and installed on my office PC and on my friend's PC. Then why can't I download Windows or iOS or Linux for mobile and install it on my mobile phone and my brother's?
[Q] Why I can't install the Android OS designed for my phone on my friend's phone? Both have same architecture (ARM) and same SoC vendor (Qualcomm) and same hardware vendor / OEM (say Samsung).
[Q] Why I have to download a firmware/ROM specific for my device?
[Q] Why a generic/regular Android OS installer is not available for all Android devices?

Let me try to understand it and explain it.
For an OS to work on a hardware, two conditions must be met:
  1. Software (OS) developers and hardware vendors/manufacturers willing to work with each other.
    This is something purely related to business.
  2. Software (OS) and hardware willing to work with each other (compatibility).
    This can be due to first point i.e. commercial constraints or due to technical limitations of one for other. We can classify this incompatibility in further classes:
    • Difference of architecture
    • Difference of hardware other than CPU and hence of drivers required
    • Difference of booting process. It's also hardware related

Machines are to facilitate human beings. To interact with devices (digital machines), we need to talk to them in their machine language; the language of yes and no (0 and 1). They don't understand English. We (the laymen) don't understand zero's and one's. Operating systems solve this communication barrier by going through multiple layers of translating, interpreting , (de)compiling and (dis)assembling different languages between us and metal/silicon hardware. Human language is translated to some high-level language like C++, easily understood by human. Then it's translated to some low-level language like Assembly, easily understood by machine.

But as all humans don't understand same language, machines don't either. That's what define architecture. Since receiving and forwarding instructions is the responsibility of CPU, architecture is associated with CPU. Different CPU's understand different set of instructions like x86, arm, powerpc etc. Also there's difference how many number of instructions a CPU can process at a time i.e. 32-bit, 64-bit etc. While translating (compiling) a program from high level language to low level language, architecture is the primary concern. A program/binary/library compiled for one arch can't run on other and thus every OS (which is a set of programs/binaries/libraries) is not able to work with every arch. CPU architecture and the instruction set it uses form an ABI which decides the format of executable binaries, such as programs and shared libraries.

Broadly speaking, there are three flavors of OS's available to this day:
  1. Windows
    Most commonly used on home and office PC's and is proprietary i.e. we can't use it on any device according to our will unless the lord; Microsoft designs Windows for our device. They have very close ties with hardware vendors for better integration and compatibility with software.
  2. Mac/iOS
    Even hardware is proprietary and we can't use it on any device unless Apple does or permits to do so.
    Closed Source
    They both charge you a handsome amount for their software and/or hardware products providing a relatively stable solution but with very less flexibility for any further addition/subtraction. They don't want you know what's going on at back end, just enjoy what user interface offers and you may ask them if any support required. That's why they keep their source code (which is the translation between machine and human) closed because they invest in it. But to simplify our daily life tasks, we have a vast range of commercialized applications, software and utilities, available at a cost (or pirated; the other way ) that run on these proprietary platforms, Microsoft being on the leading edge due to it's easy availability and compatibility with large range of hardware. Thus, from a common user's perspective who doesn't want to indulge in technicalities, both of these are good options.
  3. Linux (most common of the Unix-like OS's) maintained by GNU and FSF
    Open-source and free and anyone can mold it to use in any device; a baby toy, a video game console, a music player, a monitor, a small network router, a TV or a server hosting a full website and even more.

Another thing we need to understand is,
PC (and Laptops etc.) vs MOBILE (and tablets etc.)
There is no concept of standardization for hardware in mobile world. And no one wants either. Every vendor devises it's own way to initialize the hardware, unique and signed bootloader, non-persistent methods to enumerate devices (often hardcoded and provided by a Device Tree Blob), and devices grouped / linked in ungraspable combinations etc.

PC's are standard (so far; thanks to efforts made by IBM in past). You can buy a motherboard and compatible CPU, graphics card, sound card, network card and hard drive, all from different manufacturers and make a PC yourself (though the concept is becoming obsolete and out of the box approach is preferred). Linux and Windows will run on that PC. However, Mac won't. It's because both parties (software and hardware) GNU or Microsoft and hardware manufacturers (Intel, Dell, HP whatever) follow those standard PC specifications. Mac doesn't follow because Apple wants just to run MacOS on hardware supplied by themselves (thought there's Hackintosh now). That's why Mac means a complete unit (OS and hardware), not just an OS on DVD like Windows. There is no "Windows Book" like "Mac Book". There's Surface Pro but Windows is easily available for PC's.

This is different in mobile phone scenario. There is "Windows Phone" like "iPhone". Both are tied to hardware. Due to the closed source nature of iOS and Windows Mobile, you can't even think of using them on a device other than provided by Apple or Microsoft. There are technical restrictions you can't cross and then legal aspects. They themselves own hardware and OS both but situation is slightly different in case of Android.

Android, like Linux, being open source can be used on any device but only if you can make them work on your device. In fact Android isn't open-source, AOSP is. If you go through the process of baking (or making) a new OS (i.e. ROM) for your device, you will come across device specific DTB, kernel and proprietary blobs / HAL's (hardware specific files). AOSP doesn't provide hardware drivers, those are OEM's intellectual property and are specific to the device hardware and AOSP version as well. So, Android for ABC device can't run on XYZ device. Project Treble is a recent attempt by Google to address this issue. Though it's primary goal is to enable hardware vendors to release more frequent AOSP updates for old devices without touching their hardware specific code but this project will enable ROM developers to easily port ROM's from one device to other since the HAL's / drivers won't be necessarily modified.

Google develops a "look but don't touch" type of open-source core OS "AOSP" (not considering hardware aspects) and hands over to device OEM's. They earn indirectly by binding OEM's in "Open Handset Alliance". By signing licenses with OEM's on strict terms and conditions for Google Play Services and apps, users are made captive of Google Services; the biggest app store, search engine, cloud storage, maps, YouTube etc. and selling ads through them. Any vendor trying to replace Google's closed-source products with their own alternates is rejected in Compatibility Test, hence unable to use Google's ecosystem i.e. no more Play Store. What a user will do of such a phone with apps store? You will be seeing gradual replacement of open-source AOSP Browser, Email, Gallery with closed-source Chrome, Gmail, Google Photos. List is long with Google Dialer, Contacts, Calendar, Keyboard, Messenger, Play Music and so on. May be one day AOSP will be fully closed-source. Na?

But for the time being, once the OEM's have AOSP source code, they mold AOSP to their needs not following any hardware standards (as in PC's) and feed it to their hardware (with closed source drivers). So here OS (AOSP) isn't proprietary but drivers are. Both components become essential for each other. Hardware can't run others' software and software can't run on other's hardware. You are left with no option other than using their "product". OEM's i.e. device manufacturers make changes to OS i.e. kernel and onward: DTB, initramfs, hardware interfaces, drivers for audio, RIL, GPS, Wi-Fi, bluetooth, camera, graphics and subsequently UI and apps. Some OEM's release kernel sources sooner or later as they are bound to due to GPL, but mostly (white-labelers) don't.

Prior to kernel in booting process, there are SoC vendors who embed their own peripherals on SoC's as well as from third parties to make things complicated. At very core low level, BootROM / IBL / PBL (bootloaders) which are hard-coded on SoC/CPU are signed to load only signed SBL (secondary bootloader) which loads only signed aboot (application bootloader) which loads only signed kernel (if not unlocked). Where this chain of trust protects users' privacy, it protects SOC vendor's benefits as well. You can't replace bootloader to adapt the boot process for some other OS. All the bootloaders and multiple partitions to assist bootloaders contain proprietary contents, leaving you with least chance of customization.

"Replicant", an FSF project (the same group behind free Linux), is trying to replace proprietry parts of Android with free open-source drivers. But it's very hard to reverse engineer proprietary components and maintain Replicant OS for every device.

Coming back to the technical aspects, PC's have a standard BIOS/UEFI on motherboard which can configure boot options and can boot from many bootable devices like USB or CD/DVD. So we can start installation of OS with a bare BIOS on PC which happily interacts with bootloader, whether of Windows or of Linux. OS have hardware support i.e. drivers from all possible manufacturers included in OS which are loaded and installed accordingly during installation process. Mobile devices are designed with lesser hardware resources and limited functionality. To make a mobile device multi OS supported, there come storage space and device compactness constraints and connectivity options thus installation media issues. There's no BIOS in mobile phones. You can't simply boot from a USB or optical drive and hence there's no installation of OS possible. Installation is somewhat irrelevant term for mobiles devices. Here, partitions are "flashed" i.e. ready-made material is extracted to them.

There have been successful attempts booting Android from USB / UART ports and before that using engineering SPL's when chain of trust inside SoC wasn't that tighter and it was possible to load IBL without integrity check. But it's impossible for most of Android and other phones due to electronically signed bootloaders. Read ANDROID BOOT PROCESS for further explanation.

PC's have hard drives which can be partitioned and re-partitioned. If something goes wrong, BIOS is there to handle booting part. You can put inside an old HDD living in your scrap box to boot your PC. PC OS's are bundled with utilities to handle this "partitioning" part automatically. And in most cases OS is installed on a single or two partitions. Mobile phones have eMMC's (flash media soldered to boards) which may have up to 50 partitions on it. And you can't think of playing with these partitions unless you are willing to buy a new phone which is the case when something goes wrong with partitions due to eMMC's completed number of read/write cycles after a year or two. You can hardly re-partition it. Addresses of partitions are hard-coded in SoC from where to load what. With a damaged bootloader partition, phone doesn't know what to do when you press its power button. There's a high probability that you will lose access to even Emergency Download Mode, which is the last resort. The same goes true when other parts are malfunctioning. Considering the cost of repair and replacement (if possible and available), you would definitely opt to replace whole phone.

In this scenario of so much hardware ambiguity and diversity, with "M" number of mobile phone models released today and with "O" number of operating systems available to till date, who and why will make "M x O" numbers of ports everyday so that users can enjoy the flexibility of desired hardware and software like on PC's?
What Linus Torvalds has to say about this scenario when comparing the silicon valley king of PC world; Intel (x86) and the major SoC vendor of Android phones; Qualcomm (ARM):

"I've been personally pretty disappointed in ARM. Not as an instruction set, although I've had my issues there, but as a hardware platform it's still not very pleasant to deal with... It doesn't have the same kind of unified models around the instruction set that we have in the PC space."

So from above discussion, answer to "Can Windows/iOS be installed on Android phone?" is NO. At least not simply. First technical reason is, it's harder. Microsoft's support for ARM architecture is only a few days old while Apple uses a custom-designed ARM version. They don't work on Android ARM devices. And even if they do, they don't work with other hardware included in Android devices. And even if they do, Windows/iOS is developed by one company: Microsoft/Apple. Android (not AOSP) is developed by every OEM (Samsung, HTC, Xiaomi, Huawei, Google, Nokia, OnePlus, LG, Motorola bla bla bla). How can Microsoft/Apple develop an individual version of Windows/iOS for every model of all these Android OEM's? Why Microsoft will engage their engineers to develop drivers for Samsung/HTC/Xiaomi phone? And why would Apple invest in making MacOS for Surface Pro? It's not justified, both, technically and commercially. Gadgets are low budget devices and users tend to change them now and then unlike PC's which are supposed to be used over years and years.

Second simple reason is, it's business. In mobile phones everything is proprietary; hardware and software, whether it's Windows or iOS or Android. If there's no commercialization and proprietorship, who will invest and bring improvements at such a high rate? If you use my software, why not my hardware? And vice versa. Making money by providing services and products isn't an ignore-able option in this materialistic world rather than running a sponsors' funded Free Software Foundation.

. . . continued . . .
The Following 4 Users Say Thank You to mirfatif For This Useful Post: [ View ] Gift mirfatif Ad-Free
16th March 2018, 07:15 AM |#2  
OP Senior Member
Thanks Meter: 356
Donate to Me
. . . continued . . .


It's both: YES AND NO.
Though there is no (or negligible) proprietorship in Linux, there are technical obstructions as discussed above which make it difficult to install Linux on Android device. "Ubuntu for Android" is a stance of such failed attempt. It made use of Linux Containers (LXC) to run Linux with Android kernel. Ubuntu did their homework but abandoned due to no support from Android side. "Ubuntu Touch" and "Ubuntu Phone" are subsequent projects, almost abandoned. But there is somewhat proprietorship involved i.e. dependence on closed-source drivers.

And there is SHR.

Lets have a look at Linux vs Android to know why and why not:
  1. Linux for ARM
    Due to its open-source nature, many Linux distributions are available for ARM architecture. ArchLinux ARM port is available mainly for mini single board computers and tablets. Ubuntu ports are available for arm/arm64 as well as officially available for servers. Fedora supports desktops, laptops and workstations as well. Debian supports development boards, network storage and QEMU (virtual machine / hardware emulator) too. There are many others as well, mostly in development or trial phases.
  2. Booting process of Android and Linux resembles up to some degree. Linux mainly focuses on PC-like systems or specially customized embedded solutions. PC's have a standard BIOS/UEFI to take control after power on unlike Android devices as discussed above in "PC vs Mobile" section. Android devices, being mobile phones / tablets, don't have any analogous of BIOS.
    Since there is no BIOS/UEFI, there is no standard ACPI (power management) on Android; apps use wake locks for ON state, otherwise device is sleeping.
    Android uses ARM devices mostly with SoC's manufactured by Qualcomm, which have very least support for mainline Linux kernel contrary to other silicon vendors like Allwinner and Atmel etc.
    Read ANDROID BOOT PROCESS for further explanation.
  3. Bootloader
    Most commonly used bootloader in Linux is GRUB which comes bundled with OS and often resides with OS on the same partition. It's open source and you can even configure it. Android's most common used bootloader is aboot (or its derivative like hboot) which is closed source and signed by Qualcomm (SoC vendor) and it lives on a separate partition with it's suppportive components residing on multiple other partitions. It's to secure the device from booting any other bootloader, again for commercial purposes or to protect user's privacy. Also aboot comes locked and can't boot unsigned kernel images other than officially provided by OEM. However, in most cases, it's unlockable. Thus, Linux bootloader can't replace Android's bootloader. There's u-boot, the traditional embedded Linux bootloader but that too is helpless here coming to the "signed" part.
  4. Kernel
    Kernel being the core of OS, manages all hardware resources particularly memory and CPU. It uses a scheduler to arbitrate which tasks take priority at any given moment, creating the illusion of many tasks being executed simultaneously.
    We have an agreement on this part. Android kernel is inherited from Linux and both are open source (at least by GPL T&C) and similar enough. Though again Android kernel lives on an independent partition named "boot", similar to partition or directory "/boot" on Linux which also contains grub. But the differences in implementation of kernel are enough for incompatibility and the reason is non-standard nature of Android devices. Linux kernel is designed for standard PC's and include drivers (or at least drivers support) for almost all hardware vendors as does Windows. On the other hand, Android kernel, as explained above, is different for every device because every vendor includes its own hardware drivers which are not open source. Practically it's impossible to develop a universal Linux kernel of a few hundred MB's that works with such a diverse range of mobile phones.

    In summary, we can run Linux on Android device if:
    • Android kernel provides all functionality of a Linux kernel (specifically compatible with glibc)
      This condition is impossible to meet. Neither we can modify Android kernel to meet all needs of Linux glibc, neither we can modify userspace libraries to be compatible with Android kernel. Later will cut down many standard functions of Linux.
    • Or we have a fully working Linux kernel for the device (specifically drivers)
      Compiling Linux kernel for Android is possible but the proprietary part (drivers) is almost impossible.

    However, one may try to compile Linux kernel (native booting) for a specific Android device:
    • Get:
      • Android kernel source code
      • Firmware blobs / source from Android
      • Kernel modules from Linux (matching with kernel source version)
    • Compile Linux kernel (/boot/zImage and /boot/*) and initramfs (/boot/initrd.img.gz)
    • Let's say we are going to install Linux on second partition of SD card. Unpack Android boot.img and repack with Linux kernel, Linux initramfs, Android kernel base and cmdline something like "root=/dev/mmcblk1p2 console=tty0". Or pass root argument to bootloader while testing with fastboot:
      fastboot -c "root=/dev/mmcblk1p2 rootwait" boot boot.img
      "rdinit=" or "init=" might also need to be specified in cmdline.
      "Framebuffer Console Support" and "Virtual Terminal Support" need to be enabled while compiling Linux kernel to enable "console=tty0" which is disabled by default on Android kernel.
    But it's not very simple to achieve because all above requirements are rarely met. Getting all hardware work aside, a lot of kernel patches would be needed to hardly boot the device. Simple is to make some compromise and share Android kernel to start up a basic Linux environment.
  5. Init (Startup service manager), sysV/systemD vs Android init
    Init, being the very first process (PID 1) started by kernel, has very deep integration with kernel design. Linux traditionally has (almost had) sysV, then came, for a while, Upstart (by Ubuntu) and a few others, and now systemD (by RedHat) is most accepted service manager. Android init is derived from sysV init but it has additional responsibilities of ueventd (analogous of udev in Linux) and watchdog. It's open source and creates somewhat similar filesystems as those are on Linux. Services started by Android init are totally different than started on Linux. So, we cannot use Android init to start standard Linux services. But we can start a few of them (non-systemD, only from legacy paths /etc/init.d and /etc/rc[N].d, or direct execute binary) manually as daemons, once we have a basic Linux environment sharing Android kernel. However, init and particularly systemD starts services at boot in a defined order with entangled chain of dependencies on other services going up to kernel. Therefore, altering init's behavior (changing code and recompiling shared libraries blobs) is equal to writing a new OS.
    Android init creates only one root filesystems from initramfs in which all other filesystem are mounted. While on Linux, usually rootfs created by initramfs is just for loading drivers etc. and it's subsequntly replaced by a persistent storage (partition) rootfs.
    Linux init provides a platform to add or remove init services when new packages are installed or removed, by adding simple shell scripts to /etc/init.d on sysV or .service files to /etc/systemd.
    But Android init has no such flexibility and it starts a fixed set of services at start, defined when ROM was made. Init configuration files found in initramfs/init*.rc and in /system/etc/*.rc or /vendor/etc/*.rc are meant to be used by vendors or ROM developers and not at user level. Though we can add a custom init .rc file, on Linux any user or package can modify and update initramfs at any time. We can add startup scripts to "/etc/init.d" on some rooted Android devices or custom ROMs which have init.d support enabled by modifying initramfs in boot.img. To start custom services/processes on boot, SELinux policy also needs to be modified such as daemon-su does.
    Some other tasks which aren't part of init implementation on Linux, are handled by Android's init, such as configuring kernel parameters at boot. Android does not support /etc/sysctl.conf, so the updates to the /proc/sys/ are part of the "init.rc" file.
    On a Linux system init along with scripts, binaries kernel drivers and modules (in initrd.img), kernel (vmlinuz executable) and bootloader configuration along with modules, they all reside on root or a separate partition (mounted) at /boot. While on Android, init along with a few binaries and configuration files and kernel reside in a separate partition named "boot" with a special filesystem.
    A simple comparison of Ubuntu 16.04 (systemD) and Android 8.1 processes is given here.
  6. Filesystems and Directories
    As long as kernel part is concerned, /sys, /proc and /dev filesystems are same on Linux and Android with negligible differences. Both depend on a single root "/" filesystem. But other filesystems related to runtime environment and userspace differ i.e. /bin vs /system/bin, /home vs /data/media, /var, /usr, /media etc. But we can make use of resemblance in kernel and its filesystems to run Linux on Android device, not independently, but depending on Android OS for hardware handling.
    A comparison of Android and Ubuntu is given here.
  7. Virtual Terminals and Consoles
    Linux kernel supports a native console and muxes multiple virtual consoles and terminals (accessible through Fn+F[N] keys) which are a primary method for user logins. Android uses modified Linux kernel, with only one /dev/tty which is the current terminal and the controlling terminal of any running process requiring a terminal. Like many eLinux systems, kernel console is either disabled on Android by default or not connected to any device and it's not muxing any virtual terminals because no text mode user login is intended and only GUI mode is used. However, support for both Virtual Terminal and Console in frambuffer mode can be enabled while compiling kernel.
    For more details, have a look here.
  8. Runtime Environment (Standard C library and Linker)
    Let's think in another direction. Due to above said differences between Linux and Android, why don't we skip the installation part and run a complete Linux environment inside Android when it's completely booted? We can't.

    As said at the start of this post, OS is a set of binaries/libraries compiled for a target OS and placed at specific paths to get maximum performance. These binaries/libraries execute in a certain order to perform required operations. For maximum utilization of hardware resources (i.e. to save space and minimize processing time), each program/biary/library isn't compiled independently (i.e. statically). In most cases, they are linked and dependent on each other (dynamically linked). A "linker" program (which is itself an OS specific static binary) links these binaries and libraries when they need to run. Dynamic linking makes executable files smaller and saves disk space, because one copy of a library can be shared between multiple programs.

    Static linking is performed at build time by linker after compilation of libraries / binaries. If all required functions are statically linked to a library / binary, it doesn't need any support from OS at runtime, with a few exceptions. It's loaded in RAM as a standalone program just needing syscalls to kernel. However, in order to facilitate developers updating code and to save storage as well, static linking is not desirable in most cases. If we compile every application as a whole package, we'll be including same code hundred of times in many applications. Instead shared/dynamic libraries are referenced (using symbols, pointers) in program code at compile time but not included in executable. These symbols are resolved by linker i.e. libraries are searched recursively (searching libraries needed by already loaded libraries and so on) and linked to the program by creating addresses/offsets table in RAM before the program is executed. So the required libraries are loaded directly in RAM at runtime instead of linking in an archive file (static library) or binary (executable program) at compile time.

    For dynamic linking, linker location is hard-coded in program (binary) code i.e. absolute path is set (can be specified by "--dynamic-loader" at compile time). Shared libraries are rarely hard-coded, instead those are searched in LD_PRELOAD, LD_LIBRARY_PATH, DT_RUNPATH directories, linker cache file or default directories.
    Dynamic linking is often, but not always, accompanied by Dynamic Loading. It's the responsibility of program to load the required library when needed (not always at the start of process). Such programs (compiled with "-ldl" option) use dlopen syscall through library for loading mechanism. In static loading, all libraries are loaded in RAM before execution of program starts.
    Libraries are implemented through library files (lib*.so) and header files (.h). Header files (used at compile time) include function names while actual functions are defined in .c files. After adding the header file in a program code, functions provided by that library can be called instead of making syscalls to kernel.

    One most important of these libraries is "libc" (Standard C Library) which is responsible for very core functions like memory management and input/output processing etc. Almost every single click or tap of yours on screen goes through the traditional libc API. libc provides very basic communication with kernel (through syscalls), acting as a bridge between kernel and userspace, so must be compatible with kernel (to make kernel understand syscalls).

    C is the choice of many OS's because it's small in size, speedy and more human firendly as compared to other languages for low level programming. Libc is the most frquently linked library, almost every programs links to it for interaction with kernel. So, linker is implemented as a part of libc. Dynamically linked programs make use of std C API (header + .so files) while statically linked programs and kernel work independent of libc.
    Similarly programs can make use of C++ Standard library which itself make use of all C header files (around 30 in no.) and a few additional. libz is also one of most excessively linked libraries.

    Android and Linux have a different linkers implementation (/system/bin/linker and /lib/ respectively) and a different libc (/system/lib/ and /lib/ respectively).

    Android owns a minimal set of Bionic (what Google calls it) libc while mainstream Linux uses glibc (GNU Library C) for its applications. They can't replace each other due to difference in functions they can perform and the locations too (filesystem hierarchy) where they reside along with other binaries/libraries. As mentioned in Filesystems, Android's major binaries and libararies reside in /system/bin, /system/vendor and /system/lib while that of Linux live in /bin, /usr/bin, /lib and /usr/bin. Therefore their linkers are compiled to look in these locations accordingly for the required libraries to link. But the main difference is in their capabilities.

    Bionic is a trimmed+modified version of glibc and OpenBSD/FreeBSD C library, small in size and providing a different set of functions than glibc, just enough to get Dalvik working. Bionic was designed keeping in view the space limits, slower CPU's, bloated glibc and open-source license issues. It implements libc, libm (math.h), libdl (dynamic loader) and libpthread (CPU/RAM management for running processes). Android linker has also been designed in accordance with C library, not only different in name and location but also links libraries of different format.

    Due to differences in libc and linker, dynamic binaries/libraries compiled for Linux won't always run on Android even if the architecture is same. Static libraries which have all functions (from different libraries) built-in and work independently of dynamic linker, even those have some dependencies on shared libraries at runtime. For instance, functions like dlopen (, related to locales and Name Services (getuid, getpwent, getpwnam, getservent, getaddrinfo etc.) require at runtime the shared libraries (such as and etc.) from the same glibc version used at the time of static linking, because paths are hard coded.

    Some other differences:
    • User/group management on Android is different than Linux Name Services (NSS, NSCD, /etc/passwd, /etc/group. . .). Programs like whoami and id, if compiled on Linux, don't work on Android for the same reason.
    • Android's login process is quite different than on Linux. Bionic doesn't provide glibc's standard utmp/wtmp functionality. But same do other Linux libc's such as musl libc.
    • Locales (Native Language Support) are not supported by Bionic at all, glibc implements locale through gconv modules
    • No wide characters support (no iconv.h, use only Unicode in coding)
    • Limited libpthread (POSIX incompatibility) and libm functionality
    • Not using Linux syslog, instead uses __libc_android_log_print. /dev/log interface is also no more used on Android.
    • Domain Name Resolver (DNS) doesn't support Linux Name Service Swith (NSS)
    • No SysV IPC (managing data sharing between apps)
    • Bionic additionally provides a large number of System Properties through interface (/dev/__properties__/) using init's property service.

    Unlike glibc, Bionic doesn't support C++ fully because it wasn't needed for Dalvik (Java). Android uses llvm libc++ (previuosly using libgnustl/libstdc++ and libstlport) to compensate this shortcoming for programmers. libandroid_support is a bridge to make libc++ compatible with Bionic.

    For apps part, Android uses Java instead of native languages (C / C++ etc.). Dalvik VM is a kind of emulator running on top of native libc (and other libraries) to translate Java bytecodes into ARM understandable (native) code. This is how Java works; "write once, run anywhere" (WORA).
  9. Root User and Linux Capabilities
  10. Display Server and Display Manager
    While binaries/libraries work at back end, a GUI (graphical user interface) is to facilitate the user at front end i.e. just click on a good looking button and OS will handle the execution of commands at back end, providing you with the required results. It frees the user from the trouble of remembering commands and their syntax.

    Linux being developed for PC's comes with a desktop environment backed by a windows server (display server) like most popular X server and Wayland. Display server (protocol) is directly talking to kernel through input and graphics drivers as explained in next section. On the client side, display server is accompanied by a session manager which handles user login/logout, a desktop manager which draws a desktop and a window manager which draws and moves windows on screen. Additionally there can be panels, launchers etc. in a typical desktop environment. It consists of a few hundred packages, like main utilities being settings manager, file manager, power manager, network manager etc. Sound isn't a part of X server and is implemented separately.

    Android's display server is SurfaceFlinger which draws surfaces (windows) in a quite different manner than Linux. It offers Java based apps. A launcher is an app equivalent to Desktop, a minimal UI to manage installed apps. File manager and settings are too separate apps. So the differences here too are large. Android's windowing system is totally different than that of Linux. "Mir", an amalgam of X, Wayland and Android, was a proposed display server for Ubuntu but the project is almost dead like "Ubuntu Phone". Wayland is closer to Android, a new project not designed for remote access, eliminating unnecessary parts of X windowing system. It's a compositor consisting of server and window manager as a single unit. It doesn't include input handling either, but implemented through "libinput" separately. However, the differences are large.

    Display server and Display manager (login manager) are directly associated to Linux console and virtual terminals. Linux init lands us on a login manager or a fully working virtual console where we can use network related services, install packages, start X server, launch DE/GUI apps etc. Android has almost no concept of using kernel consoles or virtual terminals as discussed above. This is also a major difference limiting the use of display managers and servers on Android.

    To conclude, we can't run Linux X server on Android in normal way, because init is different, libc is different and kernel is also different when it comes to display server. Android developers tried their luck to develop an X server for Android, like XServer XSDL. Though functional, these are very limited in functionality, mainly due to app sandboxing mechanism of Android. X server provides a basic security mechanism when started with "-auth" argument to use a cookie file (~/.Xauthority) i.e. using X authority, but Android app doesn't provide this options. Other option is Xvnc server which is X server + vnc server in a single package and unlike other vnc servers, it doesn't need a physical display. It runs X server in headless mode on a virtual display without need of a console connected to actual display. X server directs it output to vnc server which can be accessed from a vnc client (viewer) on localhost or remotely by entering the IP and port/display if phone is connected to network (wi-fi / hotspot).
  11. Graphics, Input and Sound
    DRM, evdev and ALSA drivers work in parallel inside Linux kernel.
    • Framebuffer (fbdev)
      • Traditional methods in which /dev/(graphics)/fb[N] device is provided by kernel which directly writes to GPU / graphics memory
      • Kernel is built with framebuffer driver (text console and video mode driver; fbcon), otherwise vesa generic driver can be used
    • Kernel Mode Settings / Direct Rendering Manager (KMS/DRM)
      • They live in kernel and exposed to userspace by device /dev/dri/card0
      • Gives more control over the graphics hardware
      • Mostly provided by hardware specific drivers as well
    • Xorg
      • Most commonly used method
      • Searches installed drivers for hardware specific drivers (Intel, AMD, Nvidia etc.); open source (mesa) or proprietary. Open source drivers also make use of libdrm for talking to kernel.
      • If not found, uses vesa generic driver, without acceleration
      • If not found, uses frambuffer device driver (fbdev)
      • If not found, uses KMS
        xlib or xcb are used by clients for graphics output to X server; either directly or through widget toolkit libraries such as GTK or QT for the actual drawing of buttons, menus etc.
      Android supports fbdev somewhat and X server can be configured to use fbdev driver. However, Qualcomm doesn't want you use msm framebuffer freely.
    Hardware specific drivers such as for Synaptic Touchpad can be used but mostly two methods are used:
    • libinput
      • A userspace library developed by Wayland, but now implemented by Xorg as well (pointer, touchpad, touchscreen etc.)
    • evdev
      • Traditional Linux kernel generic driver (keyboard, mouse through USB, PS/2, PCI etc.) exposes input device through /dev/input/*
      Android supports evdev and touchscreen can be used to operate Linux.
    • Advanced Linux Sound Architecture (ALSA) is a set of kernel modules + libraries that exposes sound card status and configuration interface through /proc/asound.
    • ALSA kernel module (drivers) for sound card is loaded at boot ('cat /proc/asound/modules' or 'lsmod | grep ^snd') which controls device.
    • Most distros run a sound server PulseAudio which receives audio streams from client libraries ( used by music apps / mic etc.) and directs the output to hardware device (speaker / headphone etc.) through ALSA drivers. PulseAudio client can also forward sound to other PulseAudio servers on network or stream to network audio devices through local PulseAudio server.
    • Android supports ALSA but devices on Android are quite different than on PC's. There is also difference in ioctl calls both kernel support.
    • Android kernel is often compiled without LKMs support (CONFIG_MODULES=y).
    • Proprietary drivers of Android sound cards (msm*sndcardm on Qualcomm devices, 'cat /proc/asound/cards') and their configurations (/usr/share/alsa/cards) are not supported by ALSA on Linux distros.

      Therefore sound won't work out of the box and manual configuration is needed to natively enable Linux sound on Android device. Android kernel populates control and PCM sound device interfaces in /dev/snd from /sys/class/sound which can be manipulated to direct ALSA towards Android sound card.
    Native support for Linux multimedia (display and sound) can be enabled on running Android device by modifying framebuffer and PCM devices. However, it usually involves disabling functionality of these devices for Android when we are using them for Linux. It's due to the fact that though the base is same, there are differences in implementations.

As a general rule, even if we have a Linux distro running on an ARM device, it'd be nearly impossible to run it on other boards, irrespective of how much resemblance in specification is.

. . . continued . . .
The Following 2 Users Say Thank You to mirfatif For This Useful Post: [ View ] Gift mirfatif Ad-Free
16th March 2018, 07:16 AM |#3  
OP Senior Member
Thanks Meter: 356
Donate to Me
rootfs on / type rootfs (ro,seclabel,size=1330868k,nr_inodes=332717)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,size=1436636k,nr_inodes=359159,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime,gid=3009,hidepid=2)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
none on /dev/memcg type cgroup (rw,relatime,memory)
debugfs on /sys/kernel/debug type debugfs (rw,seclabel,relatime)
tmpfs on /mnt type tmpfs (rw,seclabel,relatime,size=1436636k,nr_inodes=359159,mode=755,gid=1000)
none on /config type configfs (rw,relatime)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
none on /dev/cpuset type cgroup (rw,relatime,cpuset,noprefix,release_agent=/sbin/cpuset_release_agent)
pstore on /sys/fs/pstore type pstore (rw,seclabel,relatime)
tmpfs on /storage type tmpfs (rw,seclabel,relatime,size=1436636k,nr_inodes=359159,mode=755,gid=1000)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,seclabel,relatime)
adb on /dev/usb-ffs/adb type functionfs (rw,relatime)
/dev/block/platform/soc/7824900.sdhci/by-name/system on /system type ext4 (ro,seclabel,relatime,discard,data=ordered)
/dev/block/bootdevice/by-name/cache on /cache type ext4 (rw,seclabel,nosuid,nodev,noatime,data=ordered)
/dev/block/bootdevice/by-name/persist on /persist type ext4 (rw,seclabel,nosuid,nodev,relatime,data=ordered)
/dev/block/bootdevice/by-name/dsp on /dsp type ext4 (ro,seclabel,nosuid,nodev,relatime,data=ordered)
/dev/block/bootdevice/by-name/modem on /firmware type vfat (ro,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=437,iocharset=iso8859-1,shortname=lower,errors=remount-ro)
/dev/block/dm-0 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,data=ordered)
/data/media on /mnt/runtime/default/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid)
/data/media on /storage/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid)
/data/media on /mnt/runtime/read/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=23,derive_gid)
/data/media on /mnt/runtime/write/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7,derive_gid)

UBUNTU 16.04
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1930528k,nr_inodes=482632,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=391184k,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=14965)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=391184k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sda3 on / type ext4 (rw,relatime,errors=remount-ro,stripe=32735,data=ordered)
/dev/sda7 on /F type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/sda5 on /home type fuseblk (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)


4.9G	/
2.9G	/data
1.6G	/system
1.1G	/data/app
856M	/data/data
807M	/data/dalvik-cache
505M	/data/dalvik-cache/arm64
387M	/system/vendor
372M	/system/priv-app
354M	/cust
303M	/data/dalvik-cache/arm
303M	/cust/app
248M	/system/app
245M	/system/vendor/lib
159M	/system/lib64
135M	/system/vendor/lib64
110M	/system/lib

UBUNTU 16.04
4.4G	/
3.3G	/usr
1.7G	/usr/lib
1007M	/usr/share
966M	/usr/lib/x86_64-linux-gnu
458M	/usr/bin
426M	/lib
338M	/var
218M	/var/lib
216M	/lib/modules/4.10.0-28-generic
216M	/lib/modules
211M	/usr/share/fonts
211M	/lib/modules/4.10.0-28-generic/kernel
208M	/home
159M	/lib/firmware
134M	/var/lib/apt
127M	/usr/src
123M	/usr/share/fonts/opentype
118M	/usr/share/icons
115M	/usr/lib/jvm
111M	/usr/src/linux-headers-4.10.0-28
106M	/usr/lib/thunderbird
The Following 2 Users Say Thank You to mirfatif For This Useful Post: [ View ] Gift mirfatif Ad-Free
16th March 2018, 07:16 AM |#4  
OP Senior Member
Thanks Meter: 356
Donate to Me
    0     1 ?        /init
    1   402 ?        /sbin/ueventd
    1   428 ?        /system/bin/logd
    1   429 ?        /system/bin/servicemanager
    1   430 ?        /system/bin/hwservicemanager
    1   431 ?        /vendor/bin/vndservicemanager /dev/vndbinder
    1   446 ?        /system/bin/vold --blkid_context=u:r:blkid:s0 --blkid_untrusted_context=u:r:blkid_untrusted:s0 --fsck_context=u:r:fsck:s0 --fsck_untrusted_context=u:r:fsck_untrusted:s0
    1   458 ?        /system/bin/hw/[email protected]
    1   465 ?        /vendor/bin/hw/[email protected]
    1   460 ?        /vendor/bin/hw/[email protected]
    1   461 ?        /vendor/bin/hw/[email protected]
    1   462 ?        /vendor/bin/hw/[email protected]
    1   464 ?        /vendor/bin/hw/[email protected]
    1   466 ?        /vendor/bin/hw/[email protected]
    1   467 ?        /vendor/bin/hw/[email protected]
    1   468 ?        /vendor/bin/hw/[email protected]
    1   469 ?        /vendor/bin/hw/[email protected]
    1   470 ?        /system/bin/healthd
    1   476 ?        /vendor/bin/sensors.qcom
    1   472 ?        /vendor/bin/rmt_storage
    1   474 ?        /vendor/bin/tftp_server
    1   481 ?        /system/bin/lmkd
    1   477 ?        /system/bin/gx_fpd
    1   479 ?        /vendor/bin/pm-service
    1   480 ?        /vendor/bin/qseecomd
  480   568 ?         \_ /vendor/bin/qseecomd
    1   482 ?        /system/bin/surfaceflinger
    1   483 ?        /system/bin/thermalserviced
    1   485 ?        /vendor/bin/pm-proxy
    1   853 ?        /vendor/bin/hw/[email protected]
    1  2127 ?        /system/vendor/bin/cnd
    1  2129 ?        /system/vendor/bin/ipacm-diag
    1  2128 ?        /system/vendor/bin/netmgrd
    1  2130 ?        /system/vendor/bin/qti
    1  2131 ?        /vendor/bin/hw/rild -c 2
    1  2134 ?        /system/vendor/bin/adsprpcd
    1  2137 ?        zygote64
 2137  2267 ?         \_ xposed_logcat
 2267  2271 ?         |   \_ logcat -v time -s XposedStartupMarker:D Xposed:I appproc:I XposedInstaller:I art:F
 2137  2984 ?         \_ system_server
 2137  3238 ?         \_
 2137  3351 ?         \_ com.qualcomm.qti.telephonyservice
 2137  3365 ?         \_
 2137  3506 ?         \_ com.qualcomm.qcrilmsgtunnel
 2137  3993 ?         \_
 2137  4020 ?         \_ org.lineageos.audiofx
 2137  4070 ?         \_
 2137  4089 ?         \_
 2137  4106 ?         \_ com.teslacoilsw.launcher
 2137  4131 ?         \_ org.lineageos.profiles
 2137  4188 ?         \_
 2137  4205 ?         \_
 2137  4569 ?         \_
 2137  5673 ?         \_
 2137  5694 ?         \_ org.lineageos.lockclock
 2137  5747 ?         \_ org.omnirom.omnijaws
 2137  6128 ?         \_
 2137  7040 ?         \_ android.process.acore
 2137  7696 ?         \_
 2137  8096 ?         \_
 2137  8923 ?         \_
 2137 10345 ?         \_
    1  2136 ?        /system/vendor/bin/hvdcp_opti
    1  2133 ?        /system/vendor/bin/thermal-engine
    1  2135 ?        /system/vendor/bin/imsqmidaemon
    1  2139 ?        /system/bin/audioserver
    1  2138 ?        zygote
 2138  5142 ?         \_
    1  2140 ?        /system/bin/cameraserver
    1  2141 ?        /system/bin/drmserver
    1  2142 ?        /system/bin/installd
    1  2144 ?        /system/bin/keystore /data/misc/keystore
    1  2145 ?        /system/bin/mediadrmserver
    1  2156 ?        media.extractor aextractor
    1  2165 ?        /vendor/bin/hw/[email protected]
    1  2158 ?        media.metrics diametrics
    1  2159 ?        /system/bin/mediaserver
    1  2160 ?        /system/bin/netd
 2160  2276 ?         \_ /system/bin/iptables-restore --noflush -w -v
 2160  2277 ?         \_ /system/bin/ip6tables-restore --noflush -w -v
 2160  7456 ?         \_ /system/bin/dnsmasq-orig --keep-in-foreground --no-resolv --no-poll --dhcp-authoritative --dhcp-option-force=43,ANDROID_METERED --pid-file --listen-mark 0xf0063 --dhcp-range=,,1h
    1  2161 ?        /system/bin/storaged
    1  2162 ?        /system/bin/wificond
    1  2164 ?        /vendor/bin/hw/rild
    1  2163 ?        media.codec hw/[email protected]
    1  2170 ?        /system/bin/gatekeeperd /data/misc/gatekeeper
    1  2167 ?        /system/vendor/bin/loc_launcher
 2167  2239 ?         \_ slim_daemon --sap PREMIUM  
 2167  2240 ?         \_ xtra-daemon  
    1  2169 ?        /system/bin/mm-qcamera-daemon
    1  2231 ?        /system/vendor/bin/wcnss_service
    1  2229 ?        /system/bin/tombstoned
    1  2249 ?        /vendor/bin/mm-pp-dpps
    1  2274 ?        /vendor/bin/msm_irqbalance -f /system/vendor/etc/msm_irqbalance.conf
    1  3319 ?        /system/bin/webview_zygote32
    1  3610 ?        /system/vendor/bin/ims_rtp_daemon
    1  3611 ?        /system/vendor/bin/imsdatadaemon
    1  3724 ?        /system/vendor/bin/imsrcsd
    1  7453 ?        /vendor/bin/hostapd -e /data/misc/wifi/entropy.bin /data/misc/wifi/hostapd.conf
    1  8459 ?        /system/bin/adbd --root_seclabel=u:r:su:s0
    1  8463 ?        /system/bin/mdnsd
    1   440 ?        magisk_daemon -post-fs
  440 10948 pts/3     \_ sh -c LD_LIBRARY_PATH=/tmp/mirfatif/lib /tmp/mirfatif/xbin/sh
10948 10951 pts/3         \_ /tmp/mirfatif/xbin/sh
10951 11206 pts/3             \_ /tmp/mirfatif/xbin/sh /tmp/mirfatif/bin/pss
11206 11207 pts/3                 \_ /data/data/com.termux/files/usr/bin/ps f --ppid 2 -p 2 --deselect -o ppid,pid,tty,cmd

UBUNTU 16.04
    0     1 ?        /sbin/init
    1   328 ?        /lib/systemd/systemd-journald
    1   342 ?        /lib/systemd/systemd-udevd
    1   743 ?        /sbin/mount.ntfs-3g /dev/sda7 /F -o rw,nosuid,nodev
    1   744 ?        /sbin/mount.ntfs-3g /dev/sda5 /home -o rw,permissions
    1   775 ?        /lib/systemd/systemd-timesyncd
    1   871 ?        /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
    1   878 ?        /usr/sbin/rsyslogd -n
    1   880 ?        /usr/sbin/vnstatd -n
    1   881 ?        /lib/systemd/systemd-logind
    1   884 ?        /usr/sbin/acpid
    1   886 ?        /usr/sbin/sshd -D
    1   888 ?        /usr/lib/bluetooth/bluetoothd
    1   889 ?        /usr/bin/freshclam -d --foreground=true
    1   891 ?        /usr/sbin/cron -f
    1   892 ?        /usr/sbin/thermald --no-daemon --dbus-enable
    1   900 ?        /usr/sbin/clamd --foreground=true
    1   931 tty1     /bin/login --
  931  1145 tty1      \_ -bash
 1145  2192 tty1          \_ /bin/sh /usr/bin/startx
 2192  2215 tty1              \_ xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth /tmp/serverauth.yDCz6R4byp
 2215  2216 tty1                  \_ /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.yDCz6R4byp
 2216  2221 tty1                  |   \_ /usr/lib/xserver-xorg-video-intel/xf86-video-intel-backlight-helper intel_backlight
 2215  2232 tty1                  \_ /bin/sh /home/mirfatif/.xsession
 2232  2267 ?                         \_ /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/im-launch /home/mirfatif/.xsession
 2232  2280 tty1                      \_ /bin/sh /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc
 2280  2290 tty1                          \_ xfce4-session
 2290  2328 tty1                              \_ /usr/lib/x86_64-linux-gnu/indicator-application/indicator-application-service
 2290  2329 tty1                              \_ lxpolkit
 2290  2338 tty1                              \_ xautolock -time 10 -locker xflock4
 2290  2339 tty1                              \_ dhcpcd-gtk
 2290  2345 tty1                              \_ indicator-keylock
 2290  2356 tty1                              \_ indicator-netspeed-unity
    1   950 ?        /usr/sbin/irqbalance --pid=/var/run/
    1   964 ?        wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant-wlp2s0.conf -iwlp2s0
    1   971 ?        /sbin/dhcpcd
    1  1140 ?        /lib/systemd/systemd --user
 1140  1142 ?         \_ (sd-pam)
    1  1343 tty6     /sbin/agetty --noclear tty6 linux
    1  1467 tty2     /sbin/agetty --noclear tty2 linux
    1  2226 ?        /usr/lib/policykit-1/polkitd --no-debug
    1  2270 tty1     /usr/bin/dbus-launch --exit-with-session /usr/bin/im-launch /home/mirfatif/.xsession
    1  2271 ?        /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
    1  2295 ?        /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
    1  2299 ?        /usr/bin/gpg-agent --sh --daemon --write-env-file /home/mirfatif/.cache/gpg-agent-info
    1  2301 tty1     xfwm4
    1  2305 tty1     xfce4-panel
 2305  2390 tty1      \_ /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-1.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/ 6 16777244 whiskermenu Whisker Menu Show a menu to easily access installed applications
 2390  2517 tty1      |   \_ /usr/lib/notepadqq/notepadqq-bin
 2390  2526 tty1      |   \_ xfce4-terminal --maximize
 2526  2531 tty1      |       \_ gnome-pty-helper
 2526  2532 pts/0     |       \_ bash
 2532 10220 pts/0     |       |   \_ sudo chroot /alarm
10220 10221 pts/0     |       |       \_ /usr/bin/qemu-aarch64-static /bin/bash -i
 2526 11207 pts/2     |       \_ bash
11207 11435 pts/2     |           \_ /bin/sh /bin/pss
11435 11436 pts/2     |               \_ ps axf -o ppid,pid,tty,args
 2305  2391 tty1      \_ /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/ 7 16777248 indicator Indicator Plugin Provides a panel area for Unity indicators. Indicators allow applications and system services to display their status and interact with the user.
 2305  2415 tty1      \_ /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-1.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/ 15 16777249 systray Notification Area Area where notification icons appear
 2305  2416 tty1      \_ /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/ 4 16777250 pulseaudio PulseAudio Plugin Adjust the audio volume of the PulseAudio sound system
 2305  2417 tty1      \_ /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-1.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/ 11 16777251 datetime DateTime Date and Time plugin with a simple calendar
    1  2307 tty1     Thunar --daemon
    1  2309 tty1     xfdesktop
    1  2310 ?        xfsettingsd
    1  2350 ?        /usr/lib/dhcpcd-dbus/dhcpcd-dbus
    1  2352 ?        xfce4-power-manager
    1  2358 ?        /usr/lib/at-spi2-core/at-spi-bus-launcher
 2358  2363 ?         \_ /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
    1  2365 ?        /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
    1  2375 ?        /usr/lib/gvfs/gvfsd
    1  2376 ?        /usr/lib/upower/upowerd
    1  2386 ?        /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
    1  2444 tty1     upstart --user --startup-event indicator-services-start
    1  2449 ?        /usr/bin/pulseaudio --start --log-target=syslog
    1  2452 ?        /usr/lib/rtkit/rtkit-daemon
    1  2474 ?        /usr/lib/gvfs/gvfs-udisks2-volume-monitor
    1  2477 ?        /usr/lib/udisks2/udisksd --no-debug
    1  2485 ?        /usr/lib/gvfs/gvfs-goa-volume-monitor
    1  2490 ?        /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
    1  2495 ?        /usr/lib/gvfs/gvfs-afc-volume-monitor
    1  2501 ?        /usr/lib/gvfs/gvfs-mtp-volume-monitor
    1  2509 ?        /usr/lib/gvfs/gvfsd-trash --spawner :1.29 /org/gtk/gvfs/exec_spaw/0
    1  2741 tty1     /opt/google/chrome/chrome
 2741  2750 tty1      \_ /opt/google/chrome/chrome --type=zygote
    1  2812 ?        /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
    1  9366 ?        /usr/lib/gvfs/gvfsd-metadata
    1 10910 ?        adb -P 5037 fork-server server
The Following 2 Users Say Thank You to mirfatif For This Useful Post: [ View ] Gift mirfatif Ad-Free
16th March 2018, 07:16 AM |#5  
OP Senior Member
Thanks Meter: 356
Donate to Me
Why Linux-on-Android? And Possible Methods of Android-Linux Dual Booting
. . . continued . . .

When there are so much differences,
Because Android is non-POSIX Linux. Though kernels are very same (only a few syscalls differ), C libraries are quite different making it impossible to run every Linux program on Android natively.
Since Android has its origins from Linux, it can be considered a highly customized embedded Linux (distro?); mainly for ARM processors and Qualcomm SoC's. Android, unlike PC's, exposes users to a limited Linux and we can't utilize powers of Linux. This limited nature is justified somewhat considering the less powerful hardware resources and "mobile" nature of the devices, Android is designed for. Restricted access to core OS is necessary for security and privacy of users who want a ready made perfectly working out-of-the-box type solution. For those who want some more from Android device, the first thing to do after buying a device is unlocking bootloader and "root" the device. This makes possible at least the user access to shell (CLI), which is the biggest common feature Android shares with Linux. Then to compensate the absence of glibc, busybox type handy solution is availed. But it's designed with a small number of commandline utilities and that too with limited functionality.
  • You don't have access to repositories of thousands of free packages available for a wide variety of tasks, almost anything you can think of.
  • While on Android, even you don't have an option to encrypt your SD card.
  • Or you need to encrypt a folder containing your private pics for online backup?
  • Or what if you accidentally deleted some important stuff on internal memory and want to recover that?
  • Or if you want to make your device a tiny server for easy access from other phone or PC?
  • Android provides very limited data backup options as compared to Linux.
  • Compile programs in full environment
You are totally dependent on apps and their developers to achieve all this, what functionality they offer and what they do to you and to your private data. Thus one may wish to install Linux on an Android device.

And after all it's fun to have a phone with many possibilities that could be played with. Be a power user!

Due to (almost) same kernel, it's the chroot operation of Unix-like OS's which makes it possible to provide an isolated environment for new apps or a new OS inside a running OS without needing a dedicated rootfs. You can also use hardware emulator like QEMU to run cross-architecture Linux OS. Even Windows can be run in an emulator on Android device if your hardware has capability such as on Limbo PC Emulator. But it will be unbearably slow. Let's make a comparison of methods used to isolate OS environments on a single machine.

  • Chroot just changes the root of single or more processes, not booting a new OS, thus changing the filesystem hierarchy and binary environment for applications.
  • OS's still can view each others' processes, mounts etc. because every process is running on same OS natively.
  • Can't start init process and spawn all services and daemons like syslogd, cron etc. from it. Need to just start the required processes manually.
  • Containers are kernel feature which additionally make use of namespaces and cgroups to isolate the guest OS from host.
  • Namespaces limit what resources a process can see and use, while cgroups limit how much a process can use a resource.
  • Network namespaces provide isolated view of iface, firewall rules and sockets. It is necessary so that daemons like sshd can be started independently.
  • Mount namespace hides Linux mounts from host OS (Android in our case) or even from spawned processes. As well as it gives flexibility to unmount / move / remount all Android shared filesystems except rootfs (pivot_root fails on Android
  • User namespace maps unused UID/GID's on host (like higher number 10000) to the UID's/GID's of the guest thus avoiding conflict of identical ID's and letting ID's work independently. It also restricts unwanted access from guest to host OS.
  • UTS NS allows setting hostname independent of Android.
  • PID NS will show only Linux processes, not those of Android.
  • cgroups (/sys/fs/cgroup) and cgroup namespaces (/proc/[pid]/cgroup) make it possible to group processes with a defined limit on allocated system resources (RAM, CPU, I/O i.e. storage devices, network, devices allocation).
  • But both OS share same kernel, drivers and modules, using process isolation methods provided by Linux kernel.
  • Can't boot different OS's with incompatible kernels.
  • All hardware related stuff is handled by host kernel.
  • RAM allocation to running processes and CPU usage can be managed more efficiently by a single kernel with negligible overhead because namespaces and cgroups are already being used by host OS to manage it's own processes.
  • Hypervisors or virtual machines (kvm, VirtualBox etc.) emulate the hardware and provide a complete machine environemnt to use an independent kernel (and even a bootloader and BIOS as well), booting any OS which the virtualizer is compatible with.
  • Guest kernel thinks it's dealing with the real hardware, not emulated.
  • So there is a thick layer of software stack between OS and actual hardware, making it very slower.
  • Hardware resources are divided in between kernels and are allocated / managed independently.
  • Native or bare-metal hypervisors like Xen and Hyper-V give better performance as they talk directly to hardware, not through an OS.
systemd-nspawn is an isolation method provided by systemd and is very popular in containerization these days. It's something in between chroot and containers (LXC, docker etc.)

Performance: chroot > containers > virtualization
Isolation: chroot < containers < virtualization

In a nutshell, chroot needs more human effort to setup because it varies from device to device but it's least overhead on system resources.

  • We need a modified Android kernel with support for containers, pivot_root and all namespaces etc. Android by default supports entering namespaces using init .rc files on boot before starting a process.
  • In order to hide mounts from host, we can make use of mount namespace with private or slave propagation.
  • In order to hide future mounts from guest, we can make use of mount namespace with private propagation.
  • Already mounted mounts can be hidden from guest by using "unshare + pivot_root + chroot" (or may be "unshare + mount --move + chroot" as referred here, but so far can't figure out how). But pivot_root doesn't work on Android because of special kernel loading process. Unlike Linux, Android rootfs mounted from initramfs is retained and pivot_root is not used in booting process to switch rootfs to real hard drive partition.
  • So, we have to rely on namespaces + chroot combination. "unshare + chroot" both work on Android devices, though busybox 'unshare -m' doesn't work.
  • Only MNT and NET namespaces work on Android devices by default. PID, UTS and USER namespaces can be enabled by rebuilding kernel.

Moving towards practical details:

That's all from my side. You can correct me if I'm wrong or complete me if I missed something worth mentioning.
The Following 2 Users Say Thank You to mirfatif For This Useful Post: [ View ] Gift mirfatif Ad-Free
25th August 2018, 09:15 PM |#6  
OP Senior Member
Thanks Meter: 356
Donate to Me
Permissions, Root User and Linux Capabilities: Linux vs. Android

Linux makes use of file permissions (DAC, MAC) and file / process capabilities to restrict access to system resources such as files on a certain filesystem. SELinux and AppArmor are commonly used Mandatory Access Control systems. Discretionary Access Controls include classic UNIX RWX file modes, owner/group or UID/GID, Extended Attributes and Access Control Lists. XATTR and ACL are rarely used filesystem related attributes. DAC and Linux Capabilities are closely related. Filesystem capabilities are of three categories: Inheritable, Permitted and Effective, while processes have two additional types: Ambient and Bounding. A process with complete set of effective capabilities is said to have root privileges. Root user can bypass all permission checks imposed by kernel. So the kernel checks for effective UID and effective process capablities for permission checks.

Android users are not allowed to have admin privileges by default. Rooting is the process of gaining these privileges with user ID 0 and all Linux capabilities, which are dropped for common human users with nonzero user ID's. A user is basically a set of privileges/capabilities identified by a number (UID). All processes running under a user have same privileges. These privileges can be dropped and elevated depending on some conditions.

In Linux boot process, kernel starts "init" process with all capabilities i.e. as root. Subsequently different processes are started with different required capabilities/privileges. On completion of boot process when reaching a human user shell (at login), effective capabilities are dropped to minimal but bounding set is maintained so that effective capabilities can be elevated later on when required using some method such as libcap. So, the privileged tasks can be performed in two ways:
  • Using setuid
    An executable binary with suid bit set (a DAC file attrib set by command 'chmod u+s') will always run as root user. Setuid flag (set-user-id root) is equivalent to setting file's permitted and effective capabilities to all capabilities. CAP_SYS_ADMIN alone is almost near to all capabilities. Linux programs "su" and "sudo" makes use of "setuid" to gain effective UID 0 for temporarily performing some task with elevated privileges.
  • Using capabilities
    To start a process with refined elevated privilege and not fully root (on per user base), set appropriate file capabilities on executable binaries and start processes at login with appropriate capabilities using PAM (making use of libcap). File capabilities are extended attribs set by command 'setcap' e.g. 'setcap cap_net_admin+ep' and 'setcap cap_net_raw+ep'. Check links (1, 2, 3, 4) to see how a new process's capabilities depend on executable file's capabilities and parent process's capabilities.
A brief description is being given here.

  • Effective UID is used for most access checks, and is the owner UID for files created by that process
    • File system user ID (FSUID) equals EUID unless (NFS, SDCARDFS etc.) filesystem is mounted with fsuid= option
    • An unprivileged process (non-root) can change its EUID only to either its SUID or RUID. If EUID=0, it can be changed to anything.
  • Saved UID is the priveleged UID saved by a process running with elevated privileges before it temporarily lowers its privileges
    • After executing unpriveleged task, saved-UID is restored back
    • If a set-user-ID program is executed, saved-UID is the owner UID of file. Otherwise saved-UID = RUID
  • Real UID (RUID) is the UID of user starting the program. It controls which user can send signals to other program
    • An unprivileged process (non-root) can signal another process only if the sender’s RUID or EUID matches the receiver's RUID or SUID
  • A set UID (set-user-ID) program can switch between the UID of the user who invoked it (RUID), and the owner of the executable i.e. can change effective UID (EUID)
    • set-user-ID bit is ignored if prctl: NO_NEW_PRIVS operation is performed on calling process, or if filesystem is mounted with "nosuid", or if process is being ptrace'd (strace)
    • Same is for setgid

fI/fP       : File's Inheritable/Permitted capabilities
fE          : File's Effective capabilities bit
pI          : Process's initial Inheritable capabilities; not generally preserved when running as a non-root user
X           : Process's initial Bounding set; a security mechanism; inherited from parent; init begins with full set
              Can be dropped by a thread by prctl: PR_CAPBSET_DROP operation, if process has CAP_SETPCAP in pE; cannot be gained once dropped
              Can be read using prctl: PR_CAPBSET_READ
pP          : Process's initial permitted capabilities; if dropped, can't be reacquired without executing a privileged program binary
pI'/pP'/pE' : Process's new Inheritable/Permitted/Effective capabilities
pA          : Ambient capabilities; preserved across execution of a program that is not privileged
              Can be raised by prctl: PR_CAP_AMBIENT_RAISE operation, but overridden by setting SECBIT_NO_CAP_AMBIENT_RAISE on calling process
How capabilities are preserved when switching user (su; using setuid or setresuid):
  • If one/more of EUID/RUID/SUID is 0, and all 3 become non-zero , then pP', pE' and pA' are cleared
    • pP' and pE' can be preserved by setting SECBIT_KEEP_CAPS, but flag is cleared on every execve
  • If EUID is 0, and becomes non-zero, then pE' is cleared
  • If EUID is non-zero, and becomes 0, then pE'=pP
  • Setting SECBIT_NO_SETUID_FIXUP preserves all capabilities in pP', pE' and pA' when EUID changes

How capabilities are preserved when not exec'ing or fork'ing a process (using "capset" syscall as libcap / "pam_cap" module do):
  • Any task can remove capabilities from pE, pP, or pI at any time
  • If a task has a capability in pP,
    • It can add that capability to pI' masked by X
    • It can add that capability to pP'
    • It can add that capability to pE masked by pP'
  • If a task has CAP_SETPCAP, it can add any capability to pI, and it can remove capabilities from X

How capabilities are preserved when fork'ing a process:
  • All capabilities are preserved

How capabilities are preserved when exec'ing a process:
  • pA' = (file caps or setuid or setgid ? 0 : pA)
    • pA' = (pP' & pI') i.e. a capability is automatically dropped from pA' if that is dropped from pP' or pI'
    • Preserved when executing non-priveleged programs, cleared otherwise
  • pP' = (X & fP) | (pI & fI) | pA'
    • Cleared if calling process is non-root user (and if pA is empty?)
    • For dumb binaries, if X masks out some capabilities in fP, execution fails (to ensure that dumb binaries aren't executed with less than required privileges)
    • If file is set-user-ID-root or calling process has EUID 0, and X is full set, then pP' is also full set
    • If calling process has RUID 0, and X is full set, then pP' is also full set
  • pI' = pI (for root user)
    • pI' = (pI & pP) if user doesn't have CAP_SETPCAP in pE, so not preserved when running as a non-root user (i.e. with no pP and no pE)
  • pE' = (fE ? pP' : pA')
    • If fE bit is set for a capability, that capability in pP' (acquired from fP or fI) is also added to pE', otherwise ambient capabilities are assigned to the effective set
    • It means fI or fP won't appear in pE' if fE isn't set (for capability-dumb binaries)
    • Cleared if calling process is non-root user (and if pA is empty?)
    • If file is set-user-ID-root or calling process has EUID 0, and X is full set, then pE' is also full set
  • X is unchanged unless changed by capset
  • Privileged program/binary file is a program that has set-user-ID or set-group-ID bits or has any file capabilities set
  • Setting file capabilities requires CAP_SETFCAP
  • File capabilities are ignored if prctl: NO_NEW_PRIVS operation is performed on calling process, or if filesystem is mounted with "nosuid", or if process is being ptrace'd (strace)
  • A capability-dumb binary is a program that has file capabilities (even if empty capability set), but has not been converted to use the libcap API to manipulate its capabilities. Kernel consider a binary dumb if fE bit is set
  • A file with set-user-ID-root is considered to have full set of fI and fP, and fE bit set, same is considered if calling process has RUID or EUID 0
    • This can be overridden by setting SECBIT_NOROOT on calling process
  • File capabilities take precedence over setuid (even if empty capability set), though EUID and SUID becomes 0 if file is set-user-ID-root. But to make setuid effective for gaining all capabilities, execute 'setcap -r' or 'setfattr -x security.capability' on binary to remove xattr from file completely.

  • Can be locked to prevent further changes
  • Can be modified and retrieved using the prctl: PR_SET_SECUREBITS and PR_GET_SECUREBITS operations. CAP_SETPCAP is required for modification
  • Are preseved when fork'ing and execve'ing, except SECBIT_KEEP_CAPS is cleared on execve

Android restricts all of its apps (Java virtual machines) from gaining elevated privileges (by ignoring setuid and file capabilities) by setting PR_SET_NO_NEW_PRIVS as explained here and here. So the apps cannot run a binary with set-user-ID-root as root process because they (users/processes) don't have CAP_SETGID in Bounding Set (X).

Additionally a special patch CONFIG_ANDROID_PARANOID_NETWORK was applied to Linux kernel which maps certain capabilities to certain groups. For instance, user without CAP_NET_RAW capability cannot access internet. But Android allows users belonging to group AID_INET (3003) to create network sockets. However it's not applicable to raw sockets, commonly used by ping for echoing. Android's ping binary creates UDP sockets (uses SOCK_DGRAM in place of SOCK_RAW) in order to work without any special privileges (i.e. without CAP_NET_RAW).
So when using Linux on Android device, we need to add the user to group inet 3003 using /etc/group which is read at login by PAM and login programs (su, login, ssh etc.).

On Linux user login, PAM modules set process (login shell usually) capabilities according to its user / groups (uid, gid, secondary groups) as set in login files (/etc/{passwd,group} etc.) and PAM modules (such as can be configured to set desired capabilities for a user/group. Login files also let assign a name for a UID/GID to remember easily. But there is no login mechanism on Android and hence no pam/libcap to set required processes capabilities at runtime. However ambient capabilities (along with Permitted, Effective and Inheritable) for boot processes/services can be set from init *.rc files or filesystem capabilities can be set on binaries while building ROM.

In addition to Linux's access control mechanisms, Android enforces it's own manifest permissions control to installed apps within its Java framework. However, as explained above, some of the permissions are associated with UIDs and GIDs to enforce filesystem access control at kernel level. A common example is permission android.permission.INTERNET associated with group inet (GID 3003), necessarily required to create network sockets i.e. to access internet. Further reading: Android's permissions mapping with UIDs/GIDs.
The Following 3 Users Say Thank You to mirfatif For This Useful Post: [ View ] Gift mirfatif Ad-Free
25th August 2018, 09:15 PM |#7  
OP Senior Member
Thanks Meter: 356
Donate to Me
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes