Android Basic

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