Why is Android so different from Linux distros?

In today's open source roundup: The differences between Android and Linux distros. Plus: Linus releases Linux kernel 4.0. And the best apps and extensions for Chromebooks?

Why is Android so different from Linux distros?

Android is based on Linux, but that doesn't mean that it's the same as your average Linux distribution. A redditor wanted to know why Android is so different from the desktop distributions that we all know and love.

Fcu5r5 asked his question:

Might not be relevant or off-track here, inform me if i do. But I was trying to get a custom rom for my phone, but it seems "flashing" was required for the phone. Flimsy and inconsistent applications such as Odin/Heimdall are involved. As far as I know, android is Linux-based. What is so different about Android that it requires flashing the system? What technical problems awaits me if I were to wipe the entire internal memory and reinstall from scratch like I do for my Linux distros?

More at Reddit

His fellow Linux redditors responded with their thoughts about the differences between Android and Linux distributions:

082726w5: "Do you know the meme about linux actually being GNU/Linux? well, Android is linux without gnu.

However, the problem you describe has more to do with the underlying platform. You are used to the way things work on PC, a mostly open platform where we have free drivers to run pretty much everything.

Phones are the antithesis of that, every single phone is different and we need proprietary drivers for everything. You know how people complain about amd proprietary drivers being a pain? The average mobile driver is way worse than that, like it will only work with a particular kernel version compiled with certain flags and a custom patch set."

ThatCrankyGuy: "...Deep down inside, they all follow pretty much similar architectures, ARM for majority of the phone. However, the devices and components at the end of those buses and interfaces can't be driven with generic commands. Everything is convoluted, red-taped, and overly complex in the world of telecom.

Without a datasheet and/or drivers you're either stuck with reverse engineering using oscilloscopes and interfaces spying mechanisms (good luck with that if it's encrypted interchange) or you're SOL."

Orsagent: "It's not that Android is different Linux distros, it's that mobile phones and tablets are very different from PCs.

The PC industry has standardised/commoditised to a large extent, the PC industry really took off after the "IBM PC compatibles" flooded the market, so maintaining compatibility was a pretty big deal for PC manufacturers everywhere. And over the years and the various Linux distros have managed to support the bulk of hardware out of the box, but it wasn't always like this, even today open source distros cannot enable full performance from your graphics cards, and a few years ago, you had to jump through all kinds of hoops to get your wifi working, including ugly hacks like installing the windows drivers!

Mobile phones and tablets on the other hand are highly customised devices and a lot of components have no open source drivers, so even if you managed to build a one-size-fits-all android distro, it wouldn't be usable on the vast majority of devices which require binary blobs and drivers.

For a PC equivalent, try getting any existing distro to boot up the newly released 12" Macbook and see how much of the hardware works out of the box.

And the other factor is available storage on the device, unlike modern PCs which have close to a TB of storage, most mobile phones are starved for storage, so having the drivers for 100s of other phones/tablets is a waste of space, and for really storage starved devices you may not even be able to fit all of those different drivers into the available space."

CalcProgrammer1: "Exactly. ARM devices lack anything equivalent to BIOS or EFI. On PC hardware, the BIOS/EFI describes the hardware available and the kernel can configure itself around it. PC interfaces such as PCI, PCIe, AGP, and USB are all self-identifying, meaning that the kernel can probe each PCI device to find out what it is and then determine what driver to load for it. PC displays have EDID as well as a standard VGA "fallback" mode, allowing the GPU to probe monitor timings, supported resolutions, native resolution, and more. The few "legacy" devices that aren't self-identifying (SMBUS, I2C, etc) are identified using the BIOS/EFI.

On mobile hardware, there is only a simplistic bootloader that boots up and hands off to the kernel. Phones tend to use much simpler interfaces - I2C, SPI for sensors and touchscreens, MIPI DSI for displays, I2S/I2C for audio DACs, UART for Bluetooth, and SDIO for eMMC/SD storage and SDIO WiFi. In addition, many peripherals are built into the SoC (system-on-chip) itself and only addressable by writing to specific registers (memory addresses) so the kernel must know it is running on a certain SoC to be able to know to write to that register and turn on that hardware. The majority of these interfaces (SPI, I2C, I2S, UART, MIPI DSI) are NOT self-identifying. The devices do not offer a standard way to request "who am I" messages so the kernel must know ahead of time that I2C address X is sensor Y or that MIPI DSI display on port 0 has a 1080x1920 resolution in video mode. This is done by building "board files" in the kernel that lay out the entire hardware setup in kernel code. You then compile the kernel targeting the specific machine you're running it on and so the kernel never has to probe for any hardware info, it just powers up and assumes all the hardware it tries to load is physically there. That's why every ARM phone, tablet, and devboard has to have its own kernel source released.

You can actually take this kernel source and modify it to run your favorite non-Android distro, but the other issue is that many bits of hardware on the Android side don't fully power up in kernel space. Instead they rely on userspace code to write to certain special /sys or /dev locations to power them up or have proprietary userspace drivers altogether. This makes getting GNU/Linux 100% working on mobile devices a huge pain, and since you're stuck with whatever kernel version the manufacturer gives you it limits your future upgrade options."

BowserKoopa: "Don't forget the bit that the Android modding community is naive and unpleasant to deal with (in my experience). I don't know that most of them actually understand the Linux portion of the system that they are working with, nor open source licenses. For instance, there is a modified version of coreutils for android; however, there are no clear instructions on how to compile it, nor are the patches that were applied documentated.

Another good example is the Kernel mod community, who release useful modifications, but usually fail to release the source code to their modifications."

More at Reddit

Linux kernel 4.0 released

Linus has been busy lately, and the fruits of his labor can be seen in the release of Linux kernel 4.0. This release contains some improvements, but it's not an earth-shattering update to the Linux kernel.

The Register reports on the release of Linux kernel 4.0:

The new number isn't a sign of a major upgrade. As we've chronicled, Torvalds thinks that it looks a bit silly when version numbers go beyond x.19. He therefore decided it would be best to tick over from 3.19 to 4.0 for the sake of neatness...

...Notable inclusions are the addition of non-disruptive patching, support for Intel's Quark systems-on-a-chips and better support for the Z13 silicon powering IBM's latest mainframes. A handful of new ARM chips also get support and there's the usual round of improvements and tweaks to graphics and sound performance.

More at The Register

You can read Linus' announcement on the Linux Kernel Mailing List:

Shortlog - for the final changes since rc7 - appended. It's mainly driver fixes (media, sound, pci, scsi target, drm, thermal..), misc arch updates (nios2 and x86) and scattered fixes elsewhere. Really not a lot during the last week.

More at Linux Kernel Mailing List

1 2 Page 1