http://modian.tistory.com/entry/Android-Basic
Android Anatomy
Linux Kernel
- Android는 Linux Kernel을 기반으로 하고 있다. 왜 Linux System이 아닌 Kernel인가?
- 어찌보면 당연하다. Mobile Device 상에서 full linux는 필요없다. 하지만 Android를 넷북이나 UMPC 등으로 영역을 확장한다면 좀 다른 얘기가 될지도 모른다
- Android is not Linux
- Android는 Linux Kernel을 기반으로 하는 Mobile Platform이라고 정의하길 선호한다.
- Native windowing system, glibc support(gnu c library), 표준 linux utilities 등을 포함하지 않고 있다.
- 일종의 file system 및 하드웨어를 제어하기 위한 드라이버 등, 최소한의 Linux를 채용하고 있다고 볼 수 있다.
- Android는 Linux Kernel의 안정적인 System 운영 측면을 가져온 것이다. Linux의 지속적인 업데이트 또한 장점이 되었을 것이다.
- Linux 2.6.24를 기반으로 하였으나 최근 발표된 Android 1.5에서는 Linux 2.6.29로 업그레이드 됨
- Kernel enhancements를 통해 Android를 지원
- Alarm / Ashmen(Android shared memory) / Binder / Power Management / Low Memory Killer / Kernel Debugger / Logger
- Why Linux kernel?
- Great memory and process management
- Permissions-based security model
- Proven driver model
- Support for shared libraries
- It's already open source
- Application과 Service는 별개의 process에서 동작을 하지만 상호 communicate 하거나 data를 공유할 필요가 있다. 이는 IPC (Inter Process Communication)를 통해 지원 : Binder
- High performance through shared memory
- Per-process thread pool for processing requests
- Reference counting, and mapping of object reference across processes
- Synchronous calls between processes
- AIDL(Android Interface Definition Language)
- PM (Power Management) Solution
- 기본적으로 Linux Power Management를 기반으로 구성 (on top of it)
- More aggressive power management policy - 결국 좀 더 타이트한 policy를 통해 pm을 한다는 내용
- Components make requests to keep the power on throught "wake locks"
- Support different types of wake locks
- Android.os.PowerManager - use wake locks carefully!
Native Libraries
- Bionic Libc
- What is - 일종의 c library로 android에서는 다음과 같은 이유로 standard c lib가 아닌 bionic libc를 쓰기로 함
- Bionic은 custom libc implementation, optimized for embedded use
- License 문제 - standard c lib는 GPL이므로 사용자는 자신의 code를 open 해야 함으로 이로부터 자유롭게 하기 위해
- BSD License
- Size - android에서는 will load in each process 해야 함으로, so it needs to be small
- Small size and fast code paths
- Fast - mobile device와 같은 한정된 CPU에 최적화되어 빠르다
- Very fast and small custom pthread implementation
- 단점 or 장점?
- Doesn't support certain POSIX features
- Not compatible with Gnu Libc (glibc)
- All native code must be compiled against bionic
- Function Libraries
- WebKit - 현재까지 알려진 Web 엔진 가운데 가장 괜찮음 : 애플사파리(아이폰포함), Nokia 등이 WebKit 기반 Web 엔진 사용
- Based on open source WebKit browser
- Renders pages in full (desktop) view
- Full CSS, Javascript, DOM, AJAX support
- Support for single-column and adative view rendering
- Media Framework
- Based on PacketVideo OpenCORE platform
- Supports standard video, audio, still-frame formats
- Support for hardware/software codec plug-ins - 기본 지원외에 format은 plug-in을 통해 또는 hardware accelerator등이 장착된 mobile device에도 plug-in을 사용하여 fully 지원할 수 있다.
- SQLite
- Light-weight transactional data store
- Back end for most platform data storage
- Native Servers
- Surface Flinger
- Provides system-wide surface "composer", handling all surface rendering to frame buffer device
- Can combine 2D and 3D surfaces and surfaces from multiple applications
- Surfaces passed as buffers via Binder IPC calls
- Can use OpenGL ES and 2D hardware accelerator for its compositions
- Double-buffering using page-flip
- Audio Flinger
- Manages all audio output devices
- Processes multiple audio streams into PCM audio out paths
- Handles audio routing to various outputs
- Hardware Abstraction Libraries
- User space C/C++ library layer
- Defines the interface that Android requires hardware "drivers" to implement
- Separates the Android platform logic from the hardware interface
- Why do we need a user-space HAL? - HAL 영역이 왜 필요한가 : 당연 - Linux에서 kernel driver가 존재할 텐데 왜 굳이 Android용 HAL을 제공하는가에 대한 문제
- Not all components have standardized kernel driver interface - 현재 제공되는 Linux system 상에서 모든 component의 driver interface에 대한 표준화가 되어있는 것은 아니다
- Kernel drivers are GPL which exposes any proprietary IP - kernel driver는 현재 GPL로 되어 있어 그대로 사용하게 되면 연계 소스코드에 대해 오픈을 해야 한다
- Android has specific requirements for hardware drivers
Android Runtime
- Dalvik Virtual Machine
- 사용자에게 Java를 이용해 app을 작성하게 하고 이러한 Java platform 기반 app을 모바일 device상에서 동작하게 하기 위한 최적의 환경을 제공하기 위해 기존의 Java VM과는 별도로 Google이 제공하는 VM이라고 할 수 있다
- 일반 VM과는 다음과 같은 다른 특징을 가지고 있다
- The VM was slimmed down to use less space
- Dalvik has no Just-in-time compiler
- The constant pool has been modified to use only 32-bit indexes to simplify the interpreter
- It uses its own bytecode, not Java bytecode
- Android's custom clean-room implementation virtual machine
- Provides application portability and runtime consistency
- Runs optimized file format (.dex) and Dalvik bytecode
- Java .class/.jar files converted to .dex at build time
- Designed for embedded environment
- Supports multiple virtual machine processes per device
- Highly CPU-optimized bytecode interpreter
- Uses runtime memory very efficiently
- Core Libraries
- Core APIs for Java language provide a powerful, yet simple and familiar development platform
- Data structures, Utilities, File access, Network Access, Graphics, …
Application Framework
- Core Platform Services
- Services that are essential to the Android platform
- Behind the scenes - applications typically don’t access them directly
- Activity Manager, Package Manager, Window Manager, Resource Manager, Content Providers, View System
- Hardware Services
- Provide access to lower-level hardware APIs
- Typically accessed through local Manager object
- LocationManager lm = (LocationManager) Context.getSystemService(Context.LOCATION_SERVICE);
- Telephony Service, Location Service, Bluetooth Service, WiFi Service, USB Service, Sensor Service
Android Physiology
Start-up Walkthrough
- Runtime Walkthrough
- It all starts with init… - similar to most Linux-based systems at startup, the bootloader loads the Linux kernel and starts the init process.
- Init starts Linux daemons, including:
- USB Daemon (usbd) to manage USB connections
- Android Debug Bridge (adbd) to manage ADB connections
- Debugger Daemon (debuggerd) to manage debug processes requests (dump memory, etc.)
- Radio Interface Layer Daemon (rild) to manage communication with the radio
- Init process starts the zygote process:
- A nascent process which initializes a Dalvik VM instance
- Loads classes and listens on socket for requests to spawn VMs
- Forks on request to create VM instances for managed processes
- Copy-on-write to maximize re-use and minimize footprint
- Init starts runtime process:
- Initializes Service Manager - the context manager for Binder that handles service registration and lookup
- Registers Service Manager as default context manager for Binder services
- Runtime process sends request for Zygote to start System Service
- Zygote forks a new VM instance for the System Service process and starts the service
- System Service starts the native system servers, including:
- Surface Flinger, Audio Flinger
- Native system servers register with Service Manager as IPC service targets:
- System Service starts the Android managed services:
- Android managed Services register with Service Manager:
- After system server loads all services, the system is ready..
- Each subsequent application is launched in it's own process
Layer Interaction
- There are 3 main flavors of Android layer cake:
- App -> Runtime Service -> lib
- App -> Runtime Service -> Native Service -> lib
- App -> Runtime Service -> Native Daemon -> lib
- App -> Runtime Service -> lib
- App -> Runtime Service -> Native Service -> lib
- App -> Runtime Service -> Native Daemon -> lib
