Android Flow Diagram

URL : http://jazzlife.tistory.com/408

.....

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로 업그레이드 됨

    ** 최근 Android 4.4 KitKat은 Linux Kernel 3.8을 사용한다.

    (http://au.ibtimes.com/articles/511297/20131004/android-4-kitkat-top-6-major-changes.htm#.VEDAqfmsV2l)

    - Kernel enhancements를 통해 Android를 지원
            Alarm / Ashmem(Anonymous Shared Memory Subsystem) / 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