Please remember to add a category to the bottom of each page that you create.
See categories help for further details, but most will probably be [[Category:HTC ModelName]].

ROM-VS-Kernel

From XDA-Developers
Jump to: navigation, search

What is a ROM?

A ROM image is a data file that contains information used on a Read Only Memory chip. For our purposes, that means a complete system image of a device. Each Android device has its own ROM image that contains files and code needed to boot the device up and run Android on it. But this is only part of a ROM. A ROM also contains a GUI (graphical user interface), required and useful applications, support files for those applications and the kernel. Let’s have a look at the parts that make a ROM.

Parts of a ROM

The kernel

Android (like many other Smartphone operating systems) runs on the Linux kernel. The Linux kernel was created in the early 1990’s by Linus Torvalds from Helsinki Finland. It’s incredibly stable, incredibly friendly, and incredibly difficult for the layman to understand and modify. Thankfully it’s also very popular so it has been ported on to a multitude of hardware, including our Android devices.

Think of the kernel as an interface layer between the hardware and software on your device. The kernel decides when things happen, such as the LED indicator gets lit. An application sends a request to the operating system to blink the LED. The operating system then sends the request to the kernel, which makes the light flash for the amount of time requested by the OS.

What sounds like a round-about way to get things done is also what makes the system so scalable and robust. Application developers only have to code in a way the operating system understands and the kernel makes it work on the hardware. This also keeps the application running in it’s own user-space and separate from the kernel. That means when you run the latest uber-cool app that wasn’t designed for your particular OS version, or is still very beta and it crashes, the kernel gives you the option to Force Close the application and the kernel can run untouched.

In a standard Android ROM (we will leave developer images and the like for another discussion) the kernel is bundled along with a set of instructions that tell the device how to load the kernel and the OS during boot. This is the boot.img that you see inside a zipped ROM that you're not able to easily open. The device knows to extract this image to internal memory (the ramdisk) and follow a series of scripts (init scripts) to load the kernel and then the other portions of the OS. That’s what’s happening while you’re watching the boot animation. Interestingly enough this is done the same way for a PC, your smartphone, an Android tablet, or even a smart Linux powered toaster. If you’re feeling exceptionally geeky, plug your Android phone into the USB port on your PC and let the PC boot from the USB device. No, it doesn’t actually load, but you can watch the animation while it tries to match up the hardware support with what’s inside your PC. As I said, Linux is amazingly scalable and as a result so is Android.

The operating system

Once the kernel is loaded, the init scripts tell the Operating System to load. Android is the user interface for a custom built Java virtual machine called Dalvik. Dalvik was written by Dan Bornstein, who named it after the fishing village of Dalvik in Iceland, where his family originated from. The debate of which Java VM is superior is best left for another discussion, so I’ll simply say that DalvikVM is a register-based machine versus true JavaVMs which are stack based.

The Dalvik machine creates executable files (.dex files) which can be interpreted by the OS and run by the end user. These .dex files are OS version dependant. That simply means that applications and core functions built to work with one version of Android may or may not work well with other versions. Google provides the tools through it’s Software Development Kit (SDK) for applications to communicate with the OS.

Core functions

No smartphone would be complete without a set of functions that allow the device to be used as intended. Things like the phone and dialer interface, the calendar, the messaging system are core functions of the Operating System. In Android, these are run on top of the kernel as separate applications. The merits (or lack of) of providing these needed functions as separate applications is once again best left for another discussion, but this is what allows developers like HTC or Motorola to replace the standard functions with alternatives that provide a different look and feel from stock. HTC’s onscreen keyboard or Motorola’s MotoBlur contact list are great examples of this. The “little guy” isn’t left out of the mix either. Handcent SMS or Chomp SMS can integrate into the OS very well, as most of us already know.

An additional set of Core Functions are provided by Google. Popularly called GoogleBits, things like Gmail, sync, Gtalk and the Android Market are applications written by Google that give an extra set of useful functions to the OS. You’ll find these on all smartphones, as well as many other Android devices

Optional applications

These are applications provided by the manufacturer to give the device even more usability. Things like the Amazon MP3 store, PDF readers, Corporate Calendar etc.