Android Flow Diagram

 

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