Is it possible to run an operating system other than Android on Android devices? I know that the bootloader is hard-coded into the firmware and even if you tried you can't change what it does but what about from that bootloader you use the kernel that it loads to load another Operating System. Something like a secondary bootloader. Is that possible? Could you compile your own Operating System and install it on an Android device if all the necessary requirements are met? What about a "Hello World" Operating System? Is that possible too at least? And I don't mean Linux.
-
@beeshyams I know you can do that but I mean literally your own Operating System that you compiled with your own libraries. Thx for trying to help though!– JoeCommented May 18, 2020 at 20:07
-
1You would still need drivers for a particular device. Those would map to some set of chips and for Android maps into a particular version of the Linux kernel. You could do something like Write an OS for Raspberry Pi in C but the issue is how much beyond serial I/O is available to YOUR OS without replicating a Linux-like kernel to support the display/touchscreen/wifi network//etc.– Morrison ChangCommented May 18, 2020 at 20:31
-
3Addressed the limitations in very detail: How to boot Ubuntu persistent live USB on Android? and IS IT POSSIBLE TO INSTALL WINDOWS, iOS OR LINUX ON ANDROID DEVICE?– Irfan LatifCommented May 18, 2020 at 23:55
1 Answer
Something like a secondary bootloader. Is that possible?
Yes it's possible. As you mentioned, since the boot chain up to bootloader stage is closed source and binaries are signed with OEM's private keys, it's not possible to replace or modify the bootloader. However if bootloader is unlockable, it's possible to boot a custom kernel (your own OS). But the first thing is that you need to follow the standard format of boot.img
(i.e. fixed offsets and file formats for kernel binary, ramdisk, DTB etc.) as specified in Android (AOSP).
Secondly building a "Hello World" kernel (or even a bootloader) for a PC is rather simple because many of the buses and the hardware attached to them are already recognized by BIOS/UEFI. However mostly Android devices are ARM based, so they don't have ACPI like in BIOS/UEFI. Instead hardware mapping is provided in the form of Device Tree which is provided by the SoC vendor. The Android/Linux kernel source provided by OEM also includes drivers for all hardware components. So you need to include the Device Tree Blob (DTB) and relevant parts from kernel source with your custom kernel.
Bootloader itself is built with the DTB to use hardware components like eMMC/UFS, display, USB etc. to be able to flash partitions, show boot splash screen, connect to PC etc. For instance, splash_region
or freamebuffer
in DTB specifies memory addresses of display hardware, which is required to print e.g. Hello World on screen.
Thirdly many of the kernel interfaces are proprietary (not documented) and they don't work with standard Linux ioctls/syscalls. In order to fully make use of hardware features (camera, gps, modem an so on) you need proprietary binary blobs (HALs) in userspace, again provided by device OEM. Android framework uses HIDL to communicate with HALs, so you also need to rely on that.
So what you come up with is not a purely “other than Android” OS. For a large part you have to share the same codebase, specifications and resources that run in Android OS, whether it's kernel or userspace.
For more details see: