RTDroid: A Design for Real-Time Android Yin Yan, Sree Harsha Konduri, Amit Kulkarni, Varun Anand, Steven Y. Ko, Lukasz Ziarek University at Buffalo, The State University of New York {yinyan, sreehars, amitshri, varunana, stevko, lziarek}@buffalo.edu ABSTRACT Since its inception, there has been much interest in a real- There has been much recent interest in adding support for time Android variant; researchers have proposed four canon- real-time capabilities to Android. Proposed architectures for ical system architectures [15, 17] for extending Android with doing so fall into four broad categories, but only two sup- real-time capabilities. These architectural models are illus- port real-time Android applications. These two proposals trated in Fig. 1. The first proposed system architecture include a real-time garbage collector for real-time memory (Fig. 1a) is built around a clean separation between Android management and a real-time operating system for real-time and real-time components, allowing for real-time applica- scheduling and resource management. Although they pro- tions to run directly on top of a real-time operating system vide the fundamental building blocks for real-time Android, (RTOS). Although viable, this model prevents the creation unfortunately such proposals are incomplete. In this paper of real-time Android apps, instead opting for a system that we examine the Android programming model, libraries, and can run both Android apps and separate real-time appli- core systems services in the context of the Fiji real-time VM cations. In addition, real-time applications are prevented coupled with the RT Linux and RTEMS real-time operat- from leveraging the features offered by Android and cannot ing systems. We show that even with a real-time operating include any Android related services or libraries. The next system as well as real-time memory management, the pre- approach (Fig. 1b) is similar to the first, but instead of swap- dictability of core Android constructs is poor. To address ping the standard Linux kernel for an RTOS, it introduces a this limitation we propose a preliminary RTDroid design and real-time hypervisor at the bottommost layer, running An- show its applicability to real-time systems. droid as a guest operating system in one partition and real- time applications in another. This model suffers from the same deficiencies of the first. Categories and Subject Descriptors The last two models (Fig. 1c and Fig. 1d) permit the con- C.3 [Special-Purpose and Application-Based Systems]: struction of real-time Android apps by adding a secondary Real-time and embedded systems VM with real-time capabilities or by extending DVM with real-time support (alternatively, replacing DVM with a real- time JVM) respectively. These two approaches provide the 1. INTRODUCTION ground work for predictability and determinism within the Android's open source nature has prompted its ubiquitous Android system by replacing the standard Linux kernel with adoption in various embedded system domains. Instead of an RTOS as well as introducing real-time features at the being built around the Java Virtual Machine (JVM), An- VM level. Notably, these models support real-time Android droid uses the Dalvik Virtual Machine (DVM) [12]. Unlike apps, the use of Android features, in addition to Android a JVM, DVM leverages register based [21] bytecode (called services and libraries. The last two models, unfortunately, DEX [2]) instead of Java bytecode. The DVM supports just- provide little or no insight on how Android features, ser- in-time compilation (JIT) [10] to optimize for the target de- vices, and libraries can themselves be extended to support ployment device. Android, itself, runs on top of a modified execution of real-time Android apps. Linux kernel and provides a framework layer for applications In this paper, we demonstrate a new approach to achieving to leverage. The framework layer is built from Linux kernel real-time capabilities with the Android system. Our pro- functionality, third party libraries, as well as core Android totype, called RTDroid, focuses on extending an existing mechanisms. Applications targeting the Android system are real-time JVM 1 with Android constructs and leveraging colloquially referred to as \apps." an off-the-shelf RTOS. We have identified critical changes to the Android framework and core mechanisms necessary to guarantee predictable runtime performance for apps that Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed leverage Android mechanisms and services. Specifically, the for profit or commercial advantage and that copies bear this notice and the full cita- contributions of this paper are: tion on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- • An investigation of the core Android components and publish, to post on servers or to redistribute to lists, requires prior specific permission their suitability for real-time. and/or a fee. Request permissions from [email protected]. JTRES’13, October 09 - 11 2013, Karlsruhe, Germany 1 Copyright 2013 ACM 978-1-4503-2166-2/13/10 $15.00. Extending an RT JVM for Android requires DEX support; http://dx.doi.org/10.1145/2512989.2512993. we discuss this issue in Section 3.2.4. Applications Applications Applications Applications Application Framework Application Framework Application Framework Application Framework RT Core RT Apps Libraries Apps Core Core Core Dalvik VM Libraries Libraries RT JVM Libraries RT JVM / Dalvik VM Dalvik VM Linux Kernel Extend Dalvik RTOS Kernel RT Hypervisor RTOS Kernel RTOS Kernel (a) (b) (c) (d) Figure 1: Proposed RT Android System Architectures. Shaded components represent additions or changes to the Android architecture. • An initial system implementation of core Android con- The medical device industry has expended significant re- structs and services, which provides real-time guaran- sources in exploring Android as a future platform [5, 8, 9, tees for real-time threads. Our system is implemented 1]. They report that Android is well suited for envisioned on top of the Fiji VM, but is both VM and RTOS applications, such as remote patient monitoring devices in- agnostic. Our current design focuses on supporting a cluding cardio monitors and glucose analyzers, because such single real-time app, but its design can be generalized applications require support for wireless connectivity as well to support multiple apps. as good user interface design. Other proposed applications • A detailed evaluation study of our system leveraging include fall and gate monitoring for the elderly and patients two separate RTOSes, RT Linux and RTEMS. Our undergoing rehabilitation. performance results indicate that previously proposed In all of these scenarios, Android is used as a platform to models, without any changes to the framework layer, run a single real-time app. The underlying hardware can cannot provide real-time guarantees if real-time threads be a traditional embedded board or a mobile device. As and/or tasks leverage Android's core mechanisms and we detail in Section 3, the benefit of using Android in these services. scenarios is the rich APIs and libraries that exist on Android. It supports connectivity through Wi-Fi, Bluetooth, 3G, and The rest of paper is organized as follows: in Section 2, we 4G; it provides native support for various sensors such as provide two high-level motivating examples for RTDroid. In GPS, accelerometer, camera, and gyroscope; and it fosters Section 3 we outline Android details, specifically focusing an intuitive user interface design through a touch screen and on the challenges of adding real-time capabilities. We de- gestures. Control and medical apps typically require these tail our solution in Section 4. Evaluation and experiments functionalities and their development can be streamlined as are presented in Section 5. We discuss related work and well as standardized through the Android APIs and libraries. conclusions in Section 6 and Section 7 respectively. 2.2 Mixed-Criticality In addition to supporting a single real-time app, we en- 2. MOTIVATION vision allowing a mobile device to run multiple real-time This section presents two broad use cases as well as ex- apps along with regular apps through the use of a mixed- amples of their concrete deployments to motivate the design criticality system. For medical monitoring, the same mobile and utility of RTDroid. We envision RTDroid being lever- device that monitors its user's medical conditions can be aged in two distinct ways: 1) to run a single real-time app on used as a traditional smartphone. This reduces the number either specialized embedded hardware or a mobile device and of devices a user needs to carry. Similarly, if a user requires 2) to run real-time apps along with existing non-real-time multiple medical monitoring applications, they can be exe- apps in a mixed-criticality environment. The former case is cuted on the same device. the primary contribution of this paper, but important de- Google reports that its Play Store currently has 700,000 sign considerations must be made to support the latter in apps available for Android 2. The ability to install and lever- the same system. As such, we discuss salient implemen- age these apps will greatly simplify the development and tation details for supporting multiple real-time apps along maintenance of real-time apps. For example, any medical with non-real-time apps. monitoring device may be expected to send a report to the patient's doctor on a daily or weekly basis. Since there are 2.1 Single Real-Time App many apps that already provide such a functionality, e.g., As Android becomes increasingly popular, researchers have Gmail that allows other apps to send emails through it, the begun to explore its use as a platform for safety- and mission- monitoring app can simply leverage one of those apps; this critical apps.