2600 Magazine_ The Hacker Quarterly - Digital Edition - Summer 2011 - 2600 Magazine [12]
Android is made up of several software layers which are intended to make the OS more modular and easier to develop for. Android is based on the 2.6.x Linux kernel which handles hardware interaction, GNU userspace utilities for low-level system management, and various open source libraries such as OpenGL, SQLite, and FreeType.
While this technically makes Android a GNU/Linux OS, Android applications (or "apps" as they are usually referred to) are not native Linux binaries. Rather, Google has developed a Java virtual machine called Dalvik and a large framework of libraries which developers can use without ever touching the underlying Linux system. This means that developing for Android requires no previous knowledge of Linux programming, and allows the developer to work within a well documented and defined environment, regardless of what device their code will eventually run on.
The idea that a developer should be able to write one application and be able to deploy it on essentially every piece of hardware Android itself supports is a core element of the OHA. In theory, this should be a boon for developers, but in practice, it introduces a number of problems, one of which being that Android applications are never truly optimized for a specific device, and are always limited by the capabilities of the Dalvik VM. Updates to Dalvik and the introduction of the Native Development Kit (NDK), which allows developers to bundle in native C code with their Java applications, are beginning to alleviate the issue, but hardware intensive applications like 3D games are still noticeably absent from Android's software library.
While not a viable option for large-scale Android development, it is also possible to write (or adapt) Linux C code for use with Android. In theory, this means you could take existing Linux tools and applications and cross-compile them for the ARM architecture most Android devices are running on. In practice however, there are a number of limitations imposed by the abridged nature of Android's Linux implementation that make things more difficult. Most notably, Android doesn't include libc, but rather uses its own library known as Bionic. All native Linux code must be compiled against Bionic, but as Bionic is not 100 percent compatible with libc, there is no guarantee that code will work as expected (or at all). In addition, Android doesn't use an X server, so graphical Linux applications are out of the question.
As with all UNIX-like operating systems, Android has a very strict set of permissions, which in this case extend from the core Linux components all the way up to the Dalvik VM. Since anyone can write an Android application and publish it in the Android Marketplace, it is extremely important for the system to monitor and limit the capabilities of everything the user installs. Every application must list its capabilities in regards to the Dalvik VM for the user upon installation, and Linux's standard per-user filesystem permissions prevent even rogue applications from accessing the underlying OS and doing system-wide damage.
While that is fine for the average user, those of us who want more control over our systems can start to feel a little caged in. Just like in a full Linux OS, if you want to get complete access to the system, you need to elevate your user level to root. Gaining root privileges is not technically supported by Android, and doing so usually requires making use of some exploit or glitch in that particular device's build of Android. Accordingly, the process of "rooting" an Android device differs greatly depending on the hardware and what version of Android it's running, which makes it considerably out of the scope of this particular article. I can say that,