Understanding Android -I (Architecture)
--
In this series of Android articles, I’ll explain how android works, starting with the architecture,
The foundation of the Android platform is the Linux kernel.
As the base for a mobile computing environment, the Linux kernel provides Android with several key security features, including:
- A user-based permissions model
- Process isolation
- An extensible mechanism for secure IPC
- The ability to remove unnecessary and potentially insecure parts of the kernel
As a multiuser operating system, a fundamental security objective of the Linux kernel is to isolate user resources from one another. The Linux security philosophy is to protect user resources from one another. Thus, Linux:
- Prevents user A from reading user B’s files
- Ensures that user A does not exhaust user B’s memory
- Ensures that user A does not exhaust user B’s CPU resources
- Ensures that user A does not exhaust user B’s devices (for example, telephony, GPS, and Bluetooth)
The HAL(Hardware Abstraction Layer) provides standard interfaces that expose device hardware capabilities to the higher-level Java API Framework. The HAL consists of multiple library modules, each of which implements an interface for a specific type of hardware components, such as the camera or Bluetooth module, for example. When a framework API makes a call to access device hardware, the Android system loads the library module for that hardware component.
ART is written to run multiple virtual machines on low-memory devices by executing DEX files, a bytecode format designed especially for Android that’s optimized for minimal memory footprint. Build tools, compile Java sources into DEX bytecode, which can run on the Android platform.
Android’s application security is enforced by the application sandbox, which isolates apps from each other and protects apps and the system from malicious apps. To do this, Android assigns a unique user ID (UID) to each Android application and runs it in its own process. Android uses the UID to set up a kernel-level Application Sandbox. By default, apps can’t interact with each other and have limited access to the OS.
Many core Android system components and services, such as ART and HAL, are built from native code that requires native libraries written in C and C++. The Android platform provides Java framework APIs to expose the functionality of some of these native libraries to apps.
The entire feature-set of the Android OS is available to you through APIs written in the Java language. These APIs form the building blocks you need to create Android apps by simplifying the reuse of core, modular system components, and services.
Android comes with a set of core apps for email, SMS messaging, calendars, internet browsing, contacts, and more. Apps included with the platform have no special status among the apps the user chooses to install. So a third-party app can become the user’s default web browser, SMS messenger, or even the default keyboard
The system partition contains Android’s kernel as well as the operating system libraries, application runtime, application framework, and applications. This partition is set to read-only. When a user boots the device into Safe Mode, third-party applications may be launched manually by the device owner but are not launched by default.
In a UNIX-style environment, filesystem permissions ensure that one user cannot alter or read another user’s files. In the case of Android, each application runs as its own user. Unless the developer explicitly shares files with other applications, files created by one application cannot be read or altered by another application.
Android provides a set of cryptographic APIs for use by applications. These include implementations of standard and commonly used cryptographic primitives such as AES, RSA, DSA, and SHA. Additionally, APIs are provided for higher-level protocols such as SSL and HTTPS.
Stay Tuned!
A new story, about Linux Kernel in Android, is on its way.
