Evaluating Android OS for Embedded Real-Time Syst em

1. Evaluating Android OS for Embedded Real-Time System Background Introduction Android OS Architecture Feasibility and Necessity Android RTS Architecture Limitation Improvement Lei Cui

2. Android platform has been instantly improved either in terms of features or supported hardware, as well as the extension-based new types of devices, which has attracted much attention from the various industries fields gradually. In other words, the utilization of Android OS based on Linux kernel has covered the whole daily life related to the E-control. However, there is a feature that has not been explored yet - the RT capabilities. This paper provides an idea of adding some RT features into Android platform to make it a RT architecture in order to be used in open real-time environment. Background Introduction

3. Android OS Architecture Android Architecture Details of Android Architecture

4. 1. Why does Android architecture utilize DVM but JVM? Less instruction dispatch and memory access——30% Less CPU resource and computation time More bytes in the instruction stream——35% 2. What is the principle of Dalvik VM? Android OS Architecture(DVM)

5. Feasibility and Necessity Dalvik-VM Linux Kernel Resource Management Capability

6. Feasibility and Necessity(Dalvik-VM) Child processes Fork() Pre-initialization & Pre-loading Of Android APIs and Classes (initial Andriod Runtime & setup VM) VM father process All the scheduling activities are delegated by the VM to the kernel

7. Feasibility and Necessity(Linux Kernel)

8. Feasibility and Necessity(Resource Management Capability)

9. Pros predict priority inversion; better resource management; more-seamless integration; predictability and determinism; Cons Drivers supported natively implement during integration phase; Android RTS Architecture Difference(RTSJ) Android Full RT Platform Android Extended Pros:bound-based memory management; RT scheduler in RT-JVM; better synchronisation mechanisms; avoid priority inversion; Cons: integration issues Pros: beneficial for incorporating a more deterministic RT behavior in the VM level; Con: keep up with release cycle of Android Both works ensure resource reservation& RT tasks schedulingin order to guarantee resource bandwidth to apps, within an interval of time

10. Guest OS Apps that need VM will not benefit from this model Low Integration Android RTS Architecture Parallel No need for VM Apps are limited by RT Hypervisor; If RT apps hangs, the sys may hang; High Priority High Priority Android Partly RT Android with a RT Hypervisor

11. RT Linux Limitation Linux system scheduling unit is 10ms, which is coarse-granularity and cannot provide the precise timing; Until now, when a task or process is called into kernel state from userland it is unpreemptedthat cannot guarantee the predictability & undeterministics; The utilization of virtual memory technology; ……. 5. Lack of effective and efficient RT scheduling algorithms & policies;

12. Improvement Improve the accuracy of the CPU clock via Clock Counter Register to solve the Linux coarse-granularity issues; eg. RT-Linux& Kurt-Linux; By insert preempted points into kernel functions to solve unpreempted issues that cannot guarantee the predictability & undeterministics; for instance, RED-Linux; ……. Define OS scheduling RT framework & algorithms to solve the issues lack of effective and efficient RT scheduling algorithms & policies; RED-Linux, Qlinux, H-SFQ, Cello, SILK, etc.

13. Real-Time Android: Deterministic Ease of Use Background Introduction Architecture Implementation & Evaluation Lei Cui

14. The preferences of end-users Developers with consistent usability A convenient development environment Background Introduction Android Platform(upper) Linux Kernel(bottom) Rich & Mature feature set Android Architecture Exclusive concern in the industrial embedded domain Remedies for user & programmer of embedded RTS Android stack with RT capabilities in a minimally invasive way via adding a crucial Linux building block

15. Architecture Linux Kernel(Kernel State) Android Framework (User State) Communication & Data exchange

16. RT support by the OS kernel is obviously a mandatory requirement for RT architectures RTAI RTLinux, XenomaiPreempt_rt Litmus-RT … Architecture---Linux Kernel Preempt_rt is not a RT kernel owing to the complexity of the Linux kernel ——impossible to prove upper bounds on all operations under all possible circumstances ——allow to determine upper latency bounds

17. Architecture--- User State The Android userland is heavily based on the Dalvik VM, based on register rather than stack architecture. Obsolete--why Android Full RT Platform Android Extended Exceed constrained developer resources Provide an insufficient return on investment Linux C without translation by VM

18. Architecture--- Data exchange Communication Channel Reject unbounded delays Shared-memory & Mutual exclusion  avoid data corruption Easily result in unbounded latencies Shared-memory & Synchronization algorithm lock-free & wait-free

19. Implementation & Evaluation A. Basis Component Integration Based on the preempt_rt release 2.6.33, back-port the BSP from 36 to 33, and forward-port the Android patch set from 32 to 33. B. Shared-memory 1. A system service creates a shared-memory via mmap() sys call; 2. The service registers at Binder; 3. All programs acquire reference via Binder call; 4. Native clients receive pointer directly; JNI library provides access methods to Android apps.

20. C. Demo Implementation & Evaluation D. Latency Measurements E. Efforts