1 Introduction
What is Android?
Android is a software platform and operating system for mobile devices, based on the Linux kernel, developed by Google and later the Open Handset Alliance. It allows developers to write managed code in the Java language, controlling the device via Google-developed Java libraries. Applications written in C and other languages can be compiled to ARM native code and run, but this development path is not officially supported by Google.
The unveiling of the Android platform on 5 November 2007 was announced with the founding of the Open Handset Alliance, a consortium of 48 hardware, software, and telecom companies devoted to advancing open standards for mobile devices. Google released most of the Android code under the Apache license, a free-software and open source license.
What is The Open Handset Alliance?
Open Handset Alliance, is a consortium of several companies which include Google, HTC, Intel, Motorola, Qualcomm, T-Mobile, Sprint Nextel and NVIDIA, ... These companies which aim to develop technologies that will significantly lower the cost of developing and distributing mobile devices and services. The Android platform is the first step in this direction -- a fully integrated mobile "software stack" that consists of an operating system, middleware, user-friendly interface and applications.
License
Android is under version 2 of the Apache Software License (ASL). The Apache license allows manufacturers and mobile operators to innovate using the platform without the requirement to contribute those innovations back to the open source community.
2. Platform
2.1 Hardware
First and foremost, Android is a software stack for mobile devices. This means that high on the list of priorities is the preservation of battery power and the efficient management of limited memory resources. There are five distinct layers to the Android system stack:
- The Acorn RISC Machine (ARM) Linux core forms the solid base upon which all the other layers stand. Linux is a proven technology that is highly reliable, and the ARM processor family is known for high performance on very low power requirements.
- The libraries provide the reusable and sharable low-level code for basic functions such as codecs — software for coding and decoding digital sound and video — functions for the presentation of rich graphics on a small displays, secure shell support for encrypted TCP/IP traffic into the cloud, as well as component support for Web browsing (WebKit), SQL database functionality (SQLite), and standard C library functionality you would expect in a Linux system.
- The Dalvik run-time byte-code interpreter, which strongly resembles the Java™ language byte-code interpreter, adds a few distinct features that uniquely define the security and power-preserving model of Android. Every application currently running, for example, has its own user ID and its own copy of the interpreter running to strictly separate processes for security and reliability.
- The Android application framework enables you to use and replace components as you see fit. These high-level Java classes are tightly integrated components that define the Android API.
- The Android core applications include the WebKit browser, Google calendar, Gmail, Maps application, SMS messenger, and a standard e-mail client, among others. Android applications are written in the Java programming language, and you can download many more from the Android market on the fly.
Android is not a single piece of hardware; it's a complete, end-to-end software platform that can be adapted to work on any number of hardware configurations. Everything is there, from the bootloader all the way up to the applications. And with an Android device already on the market, it has proven that it has what it takes to truly compete in the mobile arena.
2.2 Operating System(s)
Android uses Linux for its device drivers, memory management, process management, and networking. However you will never be programming to this layer directly.
The next level up contains the Android native libraries. They are all written in C/C++ internally, but you’ll be calling them through Java interfaces. In this layer you can find the Surface Manager (for compositing windows), 2D and 3D graphics, Media codecs (MPEG-4, H.264, MP3, etc.), the SQL database (SQLite), and a native web browser engine (WebKit).
Next is the Android runtime, including the Dalvik Virtual Machine. Dalvik runs dex files, which are converted at compile time from standard class and jar files. Dex files are more compact and efficient than class files, an important consideration for the limited memory and battery powered devices that Android targets.
The core Java libraries are also part of the Android runtime. They are written in Java, as is everything above this layer. Here, Android provides a substantial subset of the Java 5 Standard Edition packages, including Collections, I/O, and so forth.
The next level up is the Application Framework layer. Parts of this toolkit are provided by Google, and parts are extensions or services that you write. The most important component of Android Team 2009 4
the framework is the Activity Manager, which manages the life cycle of applications and a common “back-stack” for user navigation.
Finally, the top layer is the Applications layer. Most of your code will live here, along side built-in applications such as the Phone and Web Browser
2.3 Network Connectivity
It supports wireless communications using:
- GSM mobile-phone technology
- 3G
- Edge
- 802.11 Wi-Fi networks
2.4 Security
Android is a multi-process system, in which each application (and parts of the system) runs in its own process. Most security between applications and the system is enforced at the process level through standard Linux facilities, such as user and group IDs that are assigned to applications. Additional finer-grained security features are provided through a "permission" mechanism that enforces restrictions on the specific operations that a particular process can perform, and per-URI permissions for granting ad-hoc access to specific pieces of data.
Security Architecture
A central design point of the Android security architecture is that no application, by default, has permission to perform any operations that would adversely impact other applications, the operating system, or the user. This includes reading or writing the user's private data (such as contacts or e-mails), reading or writing another application's files, performing network access, keeping the device awake, etc. An application's process is a secure sandbox. It can't disrupt other applications, except by explicitly declaring the permissions it needs for additional capabilities not provided by the basic sandbox. These permissions it requests can be handled by the operating in various ways, typically by automatically allowing or disallowing based on certificates or by prompting the user. The permissions required by an application are declared statically in that application, so they can be known up-front at install time and will not change after that.