Real-Time Android with RTDroid

Yin Yan, Shaun Cosgrove, Varun Anand, Amit Kulkarni,Sree Harsha Konduri, Steven Y. Ko, Lukasz Ziarek

University at Buffalo, The State University of New York{yinyan, shaunger, varunana, amitshri, sreehars, stevko, lziarek}@buffalo.edu

ABSTRACTThis paper presents RTDroid, a variant of Android that pro-vides predictability to Android applications. Although therehas been much interest in adapting Android in real-time con-texts, surprisingly little work has been done to examine thesuitability of Android for real-time systems. Existing workonly provides solutions to traditional problems, includingreal-time garbage collection at the virtual machine layer andkernel-level real-time scheduling and resource management.While it is critical to address these issues, it is not sufficient.After all, Android is a vast system that is more than a Javavirtual machine and a kernel.

This paper goes beyond existing work and examines theinternals of Android. We discuss the implications and chal-lenges of adapting Android constructs and core system ser-vices for real-time and present a solution for each. Our sys-tem is unique in that it redesigns Android’s internal com-ponents, replaces Android’s Java VM (Dalvik) with a real-time VM, and leverages off-the-shelf real-time OSes. Wedemonstrate the feasibility and predictability of our solu-tion by evaluating it on three different platforms—an x86PC, a LEON3 embedded board, and a Nexus S smartphone.The evaluation results show that our design can successfullyprovide predictability to Android applications, even underheavy load.

1. INTRODUCTIONThere is a growing interest in adopting Android in em-

bedded, real-time environments. A DARPA project utilizingAndroid is currently in development, which creates a plugand play navigation and sensor network that can scale frompersonal devices up to aircraft navigators [4, 25]. The UKhas recently launched a satellite equipped with an Androidsmartphone to explore the possibility of using a smartphoneas a control system [8]. In medicine, much discussion iscurrently ongoing as to how the medical device industry canadopt Android [6, 9, 10, 1]. In these domains, the benefitsare numerous; developers can leverage Android’s rich set ofAPIs to utilize new types of hardware such as sensors andtouch screens; Android’s well-supported, open-source de-velopment environment eases application development; andmany applications published in online application stores give

an opportunity to incorporate creative functionalities withless effort.

Surprisingly little work, however, has been done in ac-tually adding real-time capabilities in Android. The cur-rent literature only provides a short overview of potentialhigh-level architectural models [23] and extensions to An-droid’s Java VM (Dalvik) that enable real-time garbage col-lection [21, 15]. The fundamental question of how to addreal-time support to Android as a whole system has not beenexplored.

This paper is a first step to answering that question. Weanalyze the real-time capabilities of Android and identify itslimitations. We propose and implement redesigns of An-droid’s internal components in order to provide real-timesupport. We recognize, however, that Android is a vast sys-tem with many components, and that it is difficult to evalu-ate every aspect of Android. Thus, our approach is to iden-tify and redesign core components central to Android, with agoal of supporting the execution of a single real-time appli-cation. As this paper shows, there are many hard challengesassociated with this goal alone and it is a prerequisite to sup-porting multiple real-time applications (i.e., mixed critical-ity [19, 17] — the ability to execute multiple componentswith different criticality levels safely.). In addition, support-ing a single real-time application has broad applicability inutilizing smartphones in real-time domains such as control,medical, and military devices.

More concretely, this paper makes the following four con-tributions. The first contribution is the analysis of Android’sreal-time capabilities. In addition to the kernel and JVMlayers, we examine Android’s application framework, whichprovides programming constructs and system services to ap-plications. We show that Android, due to its heavy relianceon unpredictable message passing mechanisms, does not pro-vide predictable timing guarantees. We also show that sys-tem services (understandably) were not designed to supportreal-time.

Our second contribution is an implementation that addre-sses the problems. We redesign three of the core componentsin the application framework—a message-passing mecha-nism (Looper-Handler), the timer service (AlarmManager),and the sensor architecture (SensorManager)—to provide

1

Applications

Application Framework

Android Runtime

Linux Kernel

Dalvik Virtual Machine

Constructs and APIs System Services

Native Libraries

(a) Simplified Android Architecture

Applications

Application Framework

RT Runtime

RTOS Kernel

Fiji Virtual Machine

RT AlarmManager

RT SensorManager

Native Fiji Runtime Interface

Libraries

Bionic lib with RT extension

RT Handler

RT Looper

(b) RTDroid Architecture

Figure 1: Comparison of Simplified Android and RTDroid Architectures

predictable timing guarantees. We have chosen these com-ponents in order to support a class of real-time sensing appli-cations such as fall detection (“man down”) applications [20,30], medical monitors, and control applications.

Our third contribution is the report of our experience inreplacing non-real-time building blocks (Dalvik and Linux)with real-time building blocks. We utilize the Fiji real-timeVM [28] as our Java runtime and two real-time OSes (RT-Linux [5, 18] and RTEMS [7]) as our kernel options. Thesebuilding blocks give us a good starting point with soundlower-layer real-time guarantees. In replacing these com-ponents, we have encountered practical challenges in modi-fying both the JVM as well as the kernel layers. We discussthese challenges and their solution in this paper.

Our fourth contribution is the demonstration of the real-time capabilities of our redesigns on three different plat-forms with varying degrees of guarantees: (1) hard real-timeon a LEON3 embedded board with the RTEMS RTOS, (2)soft real-time on an x86 PC with RTLinux, and (3) soft real-time on a Nexus S smartphone with the RTLinux patch ap-plied on Android’s version of Linux. In all three platforms,we show that our redesigns provide predictability to applica-tions even under heavily-loaded conditions. As part of thiseffort, we have implemented, executed, and measured thefirst real-time Android application: an automatic fall detec-tor deployed on a Nexus S smartphone and on a LEON3 de-velopment board. We show that even with hundreds of non-real-time “noise” generating threads, the application showsgood timeliness and predictability.

This paper is an extension to our previous workshop pa-per [32], which mainly focused on preliminary redesigns

of Looper-Handler and AlarmManager. This paper goesdeeper into a more comprehensive set of challenges includ-ing updated versions of Looper-Handler and AlarmMana-

ger, redesigned real-time SensorManager, and a prototypethat runs on a smartphone and a LEON3 embedded board.Additional performance measures, experiments, raw data,and plotting scripts are publicly available on our website:http://rtdroid.cse.buffalo.edu.

2. OVERVIEWIn this section, we first examine the architecture of An-

droid and explore the question of how to add real-time capa-bilities to the system, specifically focusing on time, memory,and resource predictability. We then present an overview ofour system, RTDroid.

2.1 BackgroundFig. 1a shows a simplified version of the Android archi-

tecture. The purpose of the figure is not to give a detailedview of Android; instead we highlight only those compo-nents relevant to our discussion in this section.

As Fig. 1a shows, we can divide Android into roughlythree layers below the application: (1) the application frame-work layer, (2) the runtime and libraries layer, and (3) thekernel layer. Android leverages a modified Linux kernel,which does not provide any real-time features such as priority-based preemption of threads, priority inversion avoidanceprotocols, and priority based resource management. Previ-ous work [21, 15] has also shown that Android’s runtimeand libraries provide no real-time guarantees and Dalvik’sgarbage collector can arbitrarily stall application threads re-

2

gardless of priority, resulting in non-deterministic behavior.Thus, it is currently well-understood that the bottom layersneed real-time support in order to provide a predictable plat-form.

However, we show in this paper that even with the properreal-time features at the kernel and VM layers, Android can-not provide real-time guarantees. This is due to the fact thatthe application framework layer does not provide predict-ability for its core constructs, allowing for arbitrary priorityinversion.

Broadly speaking, the application framework layer posestwo problems for real-time applications, one rooted in eachof its two categories shown in Fig. 1a. The first problemlies in the category shown on the left, constructs and APIs,which provides programming constructs 1 and APIs that ap-plication developers can use such as Looper, Handler, andAsyncTask. This category poses a problem for real-timeapplications since the constructs do not provide any time ormemory predictability as well as priority awareness.

Among the many constructs provided, Looper and Han-

dler are the most problematic ones as they are pervasivein the Android system. As we detail in Section 3, even ap-plications that do not explicitly make use of these constructsimplicitly utilize them. This occurs because the Android run-time controls the execution of every application and it usesLooper and Handler when controlling an application. Theissue is that the latency of message delivery in these mech-anisms is unpredictable; lower priority threads can unneces-sarily prevent higher priority threads from making progress.In Section 3, we discuss this problem in more detail andpresent our solution. Section 7 demonstrates the problemexperimentally.

The second problem is from the category shown on theright, system services, which provides essential system ser-vices. For example, SensorManager mediates access tosensors and AlarmManager provides system timers. The is-sue with these system services is that the implementation ofthe services does not consider real-time guarantees as a re-quirement. In Sections 4 and 5, we show how two core sys-tem services necessary to run a single sensing application,AlarmManager and SensorManager, exhibit this generalissue and discuss how we redesign these services for real-time support.

2.2 Overview of RTDroidOur system, RTDroid, aims to add real-time support in

Android as a whole system, thereby providing the abilityto execute a single real-time application that leverages thebuilt-in system services, such as AlarmManager and Sen-

sorManager. This necessitates that our system is predictablein time and memory usage as well as resource management.Once again, our system design targets a uni-process environ-

1By constructs, we mean abstract Java classes provided by the An-droid application framework. Application developers can extendthese abstract classes to leverage advanced functionalities.

ment where only a single user-level process (i.e., the appli-cation process) executes.

2.2.1 RTDroid ArchitectureIn order to provide real-time support in all three layers

depicted in Fig. 1a, we advocate a clean-slate redesign ofAndroid as shown in Fig 1b. Our redesign starts from theground up, leveraging an established RTOS (e.g., RT Linuxor RTEMS) and an RT JVM (e.g., Fiji VM). Upon this foun-dation we build Android compatibility. In other words, ourdesign provides a faithful illusion to an existing Android ap-plication running on our platform that it is executing on An-droid. This entails providing the same set of Android APIsas well as preserving their semantics for both regular An-droid applications and real-time applications. For real-timeapplications, Android compatibility means that developerscan use standard Android APIs in addition to a small numberof additional APIs our platform provides to support real-timefeatures. These additional APIs provide limited Real-TimeSpecification for Java (RTSJ) [16] support without scopedmemory.

2.2.2 Benefits of RTDroidThere are three major benefits of our clean-slate design.

First, by using an RTOS and an RT JVM, we can rely onthe sound design decisions already made and implementedto support real-time capabilities in these systems. Our RT-Droid prototype uses Fiji VM [28], which is designed tosupport real-time Java programs from the ground up. FijiVM already provides real-time functionality through staticcompiler checks, real-time garbage collection [29], synchro-nization, threading, etc. We note, however, that RTDroid’sdesign is VM independent.

The second benefit of our architecture is the flexibility ofadjusting the runtime model for different use cases. This isbecause using an RTOS and an RT JVM provides the free-dom to control the runtime model. For example, we canleverage the RTEMS [7] runtime model, where one processis compiled together with the kernel with full utility of all theresources of the underlying hardware, for single applicationdeployment. Using this runtime model is not currently pos-sible with Android, as Android runs most system services asseparate processes. Simply modifying Dalvik or the OS isnot enough to augment Android’s runtime model; the frame-work layer itself must be changed.

The third benefit of our architecture is the streamliningof real-time application development. Developers can lever-age the rich APIs and libraries that are already implementedand have support for various hardware components. Unlikeother mobile OSes, Android excels in supporting a wide va-riety of hardware with different CPUs, memory capacities,screen sizes, and sensors. Android APIs make it easier towrite a single application that can run on different types ofhardware. Thus, Android compatibility can reduce the com-plexity of real-time application development.

3

2.2.3 Deployment ProfilesRTDroid supports three different types of deployment pro-

files with varying degrees of guarantees provided by the un-derlying platform and RTOS kernel. Not all of the deploy-ment profiles currently support hard real-time guarantees dueto their use of the RTLinux kernel and closed source driversas we explain below.

• Soft Real-time Smartphone: This profile providesthe loosest guarantees due to its reliance on unveri-fied closed source drivers and a partially preemptibleRTLinux kernel as opposed to a fully preemtible RT-Linux kernel. 2 As we detail in Section 6, the An-droid patch to Linux is incompatible with the RTLinuxpatch, which prevents us from putting the kernel intoa fully-preemptible mode. As such, it is only suitedfor soft real-time tasks. However, most applicationsdomains, such as medical device monitoring are softreal-time systems. In this profile, task deadlines can bemissed due to jitter from the kernel or blocking fromthe drivers. Nevertheless, we demonstrate in Section 7that we can still provide tight latency bounds and pre-dictability even on this profile with RTDroid.• Soft Real-time Desktop: This profile provides stricter

guarantees than that of the smartphone as it leveragesa fully preemptible RTLinux kernel. In this profile,we can leverage verified-and-certified drivers. How-ever, RTLinux, even in the fully preemptible kernel isnot typically used in hard real-time systems. Based oncurrent best practices, this deployment should only beused for soft real-time systems. In this profile, dead-lines can be missed due to jitter from the kernel.• Hard Real-time Embedded: By moving away from

RTLinux and using a certified RTOS such as RTEMSas well as a development board with certified driversfor its hardware sensors, much stricter guarantees canbe provided. No deadlines can be missed due to jitterfrom the kernel or the drivers.

2.2.4 Roadmap for RTDroid DesignWe show how we redesign the core components in the

application framework layer in Sections 3, 4, and 5. In Sec-tion 6, we report our experience in replacing non-real-timebuilding blocks (Dalvik and Linux) with real-time buildingblocks for Android on the three different deployment pro-files described above. Finally, we demonstrate RTDroid’sreal-time predictability in Section 7.

3. RT LOOPER AND RT HANDLERAs discussed in Section 2, the first issue that the applica-

tion framework poses lies in its message-passing constructs.These constructs do not provide any predictability or priority-

2With a fully preemptible kernel, all parts of the kernel becomepreemptible by a high priority thread.

Sender Thread

handler instance

Receiver Thread

Looper

Message Queue

Handler Implementation

dispatchMessage()

sendMessage()

Message 1

Message n

...... handleMessage()

Figure 2: The Use of Looper and Handler

awareness. We detail this issue in this section and discusshow we address it in RTDroid.

3.1 Background and ChallengesAndroid provides a set of constructs that facilitate com-

munication between different entities, e.g., threads and pro-cesses. There are four such constructs—Handler, Looper,Binder, and Messenger. Since any typical Android appli-cation uses these constructs, we need to support these con-structs properly in a real-time context.

Among these four constructs, Looper and Handler arethe most critical constructs for our target scenario of run-ning a single real-time sensing application. This is becauseBinder and Messenger are inter-process communicationconstructs, while Looper and Handler are inter-thread com-munication constructs. Further, Looper and Handler areused not only explicitly by an application, but also implic-itly by all applications. This is due to the fact that Android’sapplication container, ActivityThread, uses Looper andHandler to control the execution of an application. Whenan application needs to make transitions between its execu-tion states (e.g., start, stop, resume, etc.), ActivityThreaduses Looper and Handler to signal necessary actions.

Fig. 2 shows how Looper and Handler work. Looper isa per-thread message loop that Android’s application frame-work implements. Its job is to maintain a message queue anddispatch each message to the corresponding Handler thatcan process the message. The developer of the applicationprovides the processing logic for a message by implement-ing Handler’s handleMessage(). A Handler instance isshared between two threads to send and receive messages.

The Looper and Handler mechanism raises a questionfor real-time applications when there are multiple threadswith different priorities sending messages simultaneously.In Android, there are two ways that Looper and Handler

process messages. By default, they process messages in theorder in which they were received. Additionally, a send-ing thread can specify a message processing time, in whichcase Looper and Handler will process the message at thespecified time. In both cases, however, the processing of

4

HandlerObject

Thread Thread RT Thread

Msg 1Msg n

RT Msg1

LooperThread

Msg1Msg nRT Msg 1

Message Queue

Figure 3: The thread in which the looper executes processesthe messages sent through this handler object in the order inwhich they are received.

a message is done regardless of the priority of the sendingthread or the receiving thread. Consider if multiple user-defined threads send messages to another thread. If a real-time thread sends a message through a Handler, its mes-sage will not be processed until the Looper dispatches everyother message prior to its message in the queue regardless ofthe sender’s priority as seen in Fig. 3. The situation is exac-erbated by the fact that Android can re-arrange messages ina message queue if there are messages with specific process-ing times. For example, suppose that there are a number ofmessages sent by non-real-time threads in a queue receivedbefore a message sent by a real-time thread. While process-ing those messages, any number of low-priority threads cansend messages with specific times. If those times come be-fore finishing the processing of non-real-time messages, thereal-time message will get delayed further by non-real-timemessages.

3.2 RedesignTo mitigate the issues mentioned, we redesign Looper

and Handler in two ways. First, we assign a priority to eachmessage sent by a thread. We currently support two policiesfor priority assignment. These policies are priority inher-itance, where a message inherits its sender’s priority, andpriority inheritance + specified where a sender can specifythe message’s priority in relation to other messages it sends.

Second, we create multiple priority queues to store incom-ing messages according to their priorities. We then asso-ciate one Looper and Handler for each queue to processeach message according to its priority. Fig. 4 shows ournew implementation for Looper and Handler. Since wenow process each message according to its sender’s prior-ity, messages sent by lower priority threads do not delay themessages sent by higher priority threads. For memory pre-dictability, queues can be statically configured in size.

4. RT ALARM MANAGERThe second issue that Android’s application framework

layer poses for real-time support is that system services do

HandlerObject

HandlerObject

Thread Thread RT Thread

Msg 1 Msg n RT Msg1

LooperThread

(Non-RT)Msg 1Msg n

Message Queue LooperThread

(RT)RTMsg 1RTMsg n

RT Message Queue

Figure 4: An Example of Looper and Handler in RTDroid.Each message has a priority and is stored in a priority queue.Processing of messages is also done by priority. The ex-ample shows one high-priority thread and multiple non-real-time threads.

not provide real-time guarantees. Since Android mediatesall access to its core system functionalities through a set ofsystem services, it is critical to provide real-time guaranteesin the system services. Just to name a few, these servicesinclude PowerManager that controls power; SensorMana-ger that mediates all sensor access and data acquisition; andAlarmManager that provides a timer service.

The presence of these system services raises two ques-tions. First, in our target scenario of running a single real-time app, there is no need to run system services as separateprocesses; rather it is more favorable to run the applicationand the system services as a single process to improve theoverall efficiency of the system. Then the question is how toredesign the system service architecture in our platform inorder to avoid creating separate processes while preservingthe underlying behavior of Android. Second, as we show inthis section and the next section, the internals of these sys-tem services do not consider real-time support as a designrequirement.

To answer these two questions, we redesign two of thesystem services—AlarmManager and SensorManager. Inthis section we first show how we redesign AlarmManager

to provide real-time guarantees. In the next section, we dis-cuss our SensorManager redesign.

4.1 Background and ChallengesAlarmManager receives timer registration requests from

applications and sends a “timer triggered” message to theseapplications when its timer fires. Since real-time applica-tions frequently rely on aperiodic and sporadic tasks, it isimportant to provide real-time guarantees in AlarmMana-

ger.Fig. 5 shows how AlarmManager works, including alarm

registration and alarm delivery. An IPC call, with a mes-sage 3 and execution time, is made to the AlarmManager

every time an application registers an alarm. When the thealarm triggers at the specified time, the AlarmManager sendsa message back to the application, and the associated call-3This message is associated with a callback for the applicationwhich gets executed when the message is delivered.

5

AlarmManager

App

TimestampMessage

ActivityAlarmManager.set()

BroadcastReceiveronReceive() Message

Figure 5: An Example Flow of AlarmManager. An ap-plication uses AlarmManager.set() to register an alarm.When the alarm triggers, the AlarmManager sends a mes-sage back to the application, and the application’s callback(BroadcastReceiver.onReceive() in the example) getsexecuted.

Alarm MapApp Thread

AlarmManager.set()

Timestamp

Message

Figure 6: The Implementation of Alarm Execution on RT-Droid. The tree colored black at the top maintains times-tamps. The trees colored gray are per-timestamp trees main-taining actual alarm messages to be delivered.

back is executed. The issue with AlarmManager is that itprovides no guarantee on when or in what order alarm mes-sages are delivered, hence does not provide any timing guar-antee or priority-awareness.

4.2 RedesignWe redesign both alarm registration and delivery mecha-

nisms to support predictable alarm delivery. For alarm regis-tration, we use red-black trees to maintain alarms as shownin Fig. 6. This means that we can make the registration pro-cess predictable based on the complexity of red-black treeoperations, i.e., the longest path of a tree is no longer thantwice the shortest path of the tree. We use one red-blacktree for storing timestamps and pointers to per-timestampred-black trees. Per-timestamp trees are leveraged to orderalarms with the same timestamp by their sender’s priority.Thus, our alarm registration process is essentially one insertoperation to the timestamp tree and another insert operationto a per-timestamp tree. By organizing the alarms based onsenders’ priorities, we guarantee that an alarm message fora low priority thread does not delay an alarm message for ahigh priority thread. Expired alarms are discarded. Note thatthis ensures that low priority threads whose alarm registra-tion rate exceeds the alarm delivery capacity of the systemcannot prevent a high priority alarm from being triggered.

For alarm delivery, we create an AlarmManager threadand assign the highest priority for timely delivery of alarm

messages. This thread replaces the original multi-processmessage passing architecture of Android. It wakes up when-ever an application inserts a new alarm into our red-blacktrees, then it schedules a new thread at the specified time forthe alarm. We associate the application’s callback for thealarm message with this new thread. For precise executiontiming of this callback thread, we implement AsynchronousEvent Handlers (AEH) that Real-Time Specification for Java(RTSJ) [16] specifies the interface for.

We have implemented two versions for AEH. The first isa per-thread AEH implementation used in our workshop pa-per [32], which creates one thread per handler to process agiven event type. This simple mechanism is efficient in han-dling low numbers of events, but can create memory and pro-cessing pressure due to large number of handling threads ifa large number of events occur within the same time period.Although most Android applications do not register alarmsat a frequency that would cause problems, our system mustbe resilient to such behavior nonetheless.

The second mechanism leverages a thread pool with a stat-ically configured number of threads, which reduces the num-ber of threads that we need to create. Our implementation isbased on Kim et al.’s proposed model [22] and is similar tohow the jRate [13] implements RTSJ’s AEH. The benefit ofthis implementation is a hard, statically known limit on thenumber of threads to handle asynchronous events. There islower memory usage due to less threads being created andthe output is deterministic with a well-known, predictablebehavior [13].

5. RT SENSOR ARCHITECTUREAnother system service we redesign in our system is Sen-

sorManager. Modern mobile devices are equipped withmany sensors such as accelerometers, gyroscopes, etc. An-droid, mainly through its SensorManager, provides a setof APIs to acquire sensor data. This section examines thecurrent sensor architecture of Android and presents our newdesign for real-time support.

5.1 Background and ChallengesOn Android, sensors are broadly classified into two cate-

gories. The first category is hardware sensors, which are thesensors that have a corresponding hardware device. For ex-ample, accelerometer and gyroscope belong to this category.The second category is software sensors, which are “virtual”sensors that exist purely in software. Android fuses differenthardware sensor events to provide software sensor events.For example, Android provides an orientation sensor in soft-ware. On Nexus S, Android 4.2 has 6 hardware sensors and7 software sensors.

These sensors are available to applications through Sen-

sorManager APIs. An application registers sensor eventlisteners through the provided APIs. These listeners pro-vide the application’s callbacks that the Android frameworkcalls whenever there is any requested sensor event available.

6

SensorManager

JNI: Native SensorManager

SystemSensorManager

SensorManager.cpp

SensorEventQueue

Framework Sensor Libraries

Client Side Server Side

SensorThread

SensorService (binder proxy)

BinderService

BnSensorService

SensorDevice

SensorService

SensorEventConnection

SensorThread

HAL

BitTube

SensorEventConnection instance

SensorFusion

LinearAccelerometer Orientation...

SensorBase

Accelerometer Gyroscope...

Sensors.cpp

Drivers.so

Kernel

Event handler

Event Device

Input Core

input device ...

Figure 7: Android Sensor Architecture

When registering a listener, an application can also specifyits desired delivery rate. The Android framework uses thisas a hint when delivering sensor events.

Internally, there are four layers involved in the overallsensor architecture: the kernel, HAL, SensorService, andSensorManager. Fig. 7 shows a simplified architecture.

1. Kernel: The main job of the kernel layer is to pullhardware sensor events and populate the Linux /dev

file system to make the events accessible from the userspace. Each sensor hooks to the circuit board throughI2C bus and registers themselves as input devices.

2. HAL: The HAL layer provides sensor hardware ab-stractions by defining a common interface for each hard-ware sensor type. Hardware vendors provide actualimplementations underneath.

3. SensorService: SensorService is a system serverto convert raw sensor data to more meaningful data us-ing application-friendly data structures. This involvesthree steps. First, SensorService polls the Linux/dev file system to read raw sensor input events. Sec-ond, it composites both hardware and software sensorevents from the raw sensor input events. For hardwaresensors, it just reformats the data; for software sensors,it combines different sources to calculate software sen-sor events via sensor fusion. Finally, it writes the sen-sor event to the SensorEventQueue via SensorE-ventConnection.

4. Framework Layer: SensorManager delivers the sen-sor events by reading the data from SensorEventQueue

and invoking the registered application listeners to de-liver sensor events.

There are two issues that the current architecture has inproviding predictable sensing. First, there is no priority sup-port in the sensor event delivery mechanism since all sen-sor events go through the same SensorEventQueue. Whenthere are multiple threads with different priorities, the eventdelivery of lower-priority threads can delay the event deliv-ery of higher-priority threads. Second, the primary eventdelivery mechanisms poll and buffer at the boundary of dif-ferent layers (e.g., between the kernel and SensorService

and between SensorService and SensorManager) by useof message passing constructs. Android does not provideany guarantee on how long it takes to deliver events throughthese mechanisms.

5.2 RedesignWe redesign the sensor architecture for RTDroid to ad-

dress the two issues mentioned above. Our design is inspiredby event processing architectures used for Web servers [27,31]. We first describe the architecture and discuss how weaddress the two problems with our new architecture.

As shown in Fig. 8, there are multiple threads specializedfor different tasks. At the bottom, there is a polling threadthat periodically reads raw sensor data out of the kernel.This polling thread communicates with multiple processingthreads. We allocate one thread per sensor type as shown inFig. 8, e.g., one thread for accelerometer, one thread for gy-roscope, and one thread for the orientation sensor. The mainjob of these processing threads is to perform raw sensor dataprocessing for each sensor type. For example, a processingthread for a hardware sensor reformats raw sensor data toan application-friendly format, and a processing thread for asoftware sensor performs sensor fusion. Once the raw sen-sor data is properly processed, each processing thread noti-

7

RT SensorManager

ProcessingComponent

PollingComponent

DeliveryHandler (Real-time Handler)

RT Looper

RT Handler

RT Looper

RT Handler

RT Looper

RT Handler...

AccelerometerProcessingThread

GyroscopeProcessingThread

OrientationProcessingThread...

PollingThread (Periodic RT Thread)

Fusion

Kernel: Device Event

native interface

Figure 8: RTDroid Sensor Architecture

fies the delivery thread whose job is to create a new threadthat executes the sensor event listener callback registered byan application thread. To provide predictable delivery, weuse notification, not polling, for our event delivery except inthe boundary between the kernel and the polling thread. Weprovide additional predictability through our priority inheri-tance mechanism described next.

We address the two issues mentioned earlier by priorityinheritance. When an application thread of priority p reg-isters a listener for a sensor, say, gyroscope, then the pro-cessing thread for gyroscope inherits the same priority p. Ifthere are multiple application threads that register for thesame gyroscope, then the gyroscope processing thread in-herits the priority of the highest-priority application thread.In addition, when the delivery thread creates a new threadthat executes a sensor event listener callback, this new threadalso inherits the original priority p of the application thread.We assign the highest priority available in the system to thepolling thread to ensure precise timing for data pulling.

This combined use of event-based processing threads andpriority inheritance has two implications. First, when an ap-plication thread registers a listener for a sensor, we effec-tively create a new, isolated event delivery path from thepolling thread to the listener. Second, this newly created pathinherits the priority of the original application thread. Thismeans that we assign the priority of the application thread tothe whole event delivery path.

6. REAL-TIME BUILDING BLOCKSIn this section, we report our experience in replacing non-

real-time building blocks (Dalvik and Linux) with off-the-

shelf real-time counterparts (Fiji VM and RTOSes). As men-tioned earlier, we support three deployment profiles, an x86PC environment, an embedded environment with a LEON3development board, and an ARM-based smartphone envi-ronment with a Nexus S smartphone. The x86 and the LEON3environments do not require any more than replacing thenon-real-time kernel with either real-time Linux kernel (byapplying an RT-Preempt patch, i.e., RTLinux) or the real-time RTEMS kernel. The same strategy, however, does notwork for the smartphone environment because Android hasintroduced extensive changes in the kernel that are not com-patible with RTLinux patches. Thus, we first briefly describeour x86 and LEON3 environments. We then report our ex-perience with the smartphone environment in detail.

6.1 x86 PC and LEON3For the x86 environment, we apply an RTLinux patch

(patch-3.4.45-rt60) to Linux 3.4.45, and use Fiji as the real-time VM. Fiji already runs on RTLinux, thus it did not re-quire any additional effort. This configuration represents oursoft real-time deployment. Tighter bounds are provided asRTLinux makes the kernel fully preemptible. Similarly, wecan introspect the drivers on the machine to guarantee theirtimeliness or leverage off-the-self drivers that have alreadybeen vetted.

To create the LEON3 environment, we use a LEON3 em-bedded board, GR-XC6S-LX75, manufactured by Gaisler.We then use RTEMS as the real-time kernel and Fiji as thereal-time VM. RTEMS has native support for LEON3 andFiji already supports RTEMS. This configuration representsour hard real-time embedded board deployment, avoidingthe issues that plague RTLinux and closed source drivers.The LEON3 manufacturers provide drivers that have previ-ously been certified for automotive, aerospace, and civilianaviation.

In order to test the SensorManager on the LEON3 sys-tem, we have designed and implemented an accelerometerdaughter board as well as the associated RTEMS compliantdriver.

6.2 Nexus S SmartphoneUnfortunately, the same approach is not adequate for ex-

ecution on an Android phone. This is mainly due to the in-compatibilities between Android and the real-time buildingblocks in the kernel layer as well as in Android’s C library,Bionic. The following are the main challenges to integration.

6.2.1 BionicAndroid does not utilize glibc as the core C library, in-

stead it uses its own library called Bionic [14]. Bionic isa significantly simplified, optimized, light-weight C libraryspecifically design for resource constrained devices with lowfrequency CPUs and limited main memory. Its architecturaltargets are only ARM and x86.

Bionic becomes a problem when replacing Dalvik with

8

Fiji; this is because it does not support the real-time ex-tensions for Pthreads and mutexes, which are required byFiji (or any other real-time Java VM). In addition, it is notPOSIX-compliant. Thus, we have modified Bionic to in-clude all necessary POSIX compliant real-time interfaces.This includes all the real-time extensions for Pthreads andmutexes.

6.2.2 Incompatible Kernel PatchesAndroid has introduced a significant amount of changes

specializing the Linux kernel for Android, e.g., low memorykiller, wakelock, binder, logger, etc. Due to these changes,automatic patching of an Android kernel with an RTLinuxpatch is not possible, requiring a manually applied RTLinuxpatch.

Even after manual patching, however, we have discoveredthat we are still not able to get a fully-preemptible kernelwhich can provide tighter latency bounds. The reason is sim-ply that Android’s changes are not designed with full pre-emption in mind. We are currently investigating this issueand it is likely that this is an engineering task. Neverthe-less, we are not aware of any report of a fully-preemptibleAndroid kernel.

6.2.3 Non-Real-Time Kernel FeaturesDuring our initial testing and experimentation, we have

discovered that there are two kernel features that are notreal-time friendly. They are the out of memory killer (OOMkiller) [3] and CPUFreq governors [2]. The OOM killer istriggered when there is not enough space for memory allo-cation. It scans all pages for each process to verify if the sys-tem is truly out of memory. It then selects one process andkills it. We have found out that this causes other threads andprocesses to stop for an arbitrary long time, creating unpre-dictable spikes in latency. For our target scenario of runninga single real-time application, the OOM killer is not only notnecessary, but a source of missed real-time task deadlines.Memory management is provided by Fiji VM’s Schism real-time, fragmentation tolerant GC [29]. It is therefore, criticalto disable OOM killer.

CPUFreq governors offer dynamic CPU frequency scal-ing by changing the frequency scaling policies. Androiduses this to balance between phone performance and batteryusage. The problem is that when a CPUFreq governor chan-ges the frequency, it affects the execution time of all run-ning threads, again introducing jitter in the system. More-over, frequency scaling is not take into consideration whenscheduling threads. The result is missed task deadlines andunpredictable spikes in latency. Real-time scheduling thattakes into consideration voltage scaling has been vetted forhardware architecture that provide predictable mechanismsfor doing so [12].

In our experiments, we show the behavior of RTDroidwith two governors—the “ondemand” governor, which dy-namically changes the CPU frequency depending on the cur-

rent usage, and the “performance” governor, which sets theCPU frequency to the highest frequency possible. We leaveit as our future work to handle dynamic frequency scaling.For example, we can apply an existing method for worsecase execution time analysis [24] to validate the hardwareand leverage this timing analysis to modify the kernel andVM schedulers appropriately.

7. EXPERIMENTAL RESULTSTo measure and validate our prototype of RTDroid, we

tested our implementation on three system level configura-tions, each of which represents one of our target deploy-ments outlined in Sections 2.2.3. The first configuration uti-lizes an Intel Core 2 Duo 1.86 GHz Processor with 2GB ofRAM. For precise timing measurements we disabled one ofthe cores prior to running the experiments. The second con-figuration is a Nexus S phone equipped with a 1 GHz Cortex-A8 and 512 MB RAM along with 16GB of internal storageand an accelerometer, gyro, proximity, and compass sen-sors running Android OS v4.1.2 (Jelly Bean) patched withRT Linux v.3.0.50. For the third configuration we lever-aged a GR-XC6S-LX75 LEON3 development board run-ning RTEMS version 4.9.6. The board’s Xilinx Spartan 6Family FPGA was flashed with a modified LEON34 config-uration running at 50Mhz. The development board has an8MB flash PROM and 128MB of PC133 SDRAM. We havedesigned and developed a daughter board with interface cir-cuitry based on the Freescale Semiconductor MMA8452Qtriple axis accelerometer. We have developed an RTEMSdriver for the accelerometer and integrated it into our RTEMSbuild.

Due to space constraints, we only show a subset of ourexperimental results. All of our results are available throughour website: http://rtdroid.cse.buffalo.edu.

7.1 RT Looper and RT HandlerTo measure the effectiveness of our prototype, we con-

structed an experiment that leveraged RT Looper and RT

Handler. Our microbenchmark creates one real-time taskwith a 100 ms period that sends a high-priority message. Tomeasure the predictability of the system, we calculate the la-tency of processing the message. To do this, we take a times-tamp in the real-time thread prior to sending the message.This timestamp is the data encoded within the message. Asecond timestamp is taken within the RT Handler respon-sible for processing this message after the message has beenreceived and the appropriate callback invoked. The differ-ence between the timestamps is the messages latency. Inaddition, the experiments include a number of low-prioritythreads which also leverage RT Looper and RT Handler.These threads have a period of 10 ms and send 10 messagesduring each period. To compare the Looper and Handler

designs between RTDroid and Android, we have ported the4The LEON3 core was reconfigured to allow access to a specificI2C bus

9

0

20

40

60

80

100

0 50 100 150 200 250 300 350 400

Mic

rose

cond

s

Message Sequence Number

(a) RTDroid: 30 low-priority threads

0

20

40

60

80

100

0 50 100 150 200 250 300 350 400

Mic

rose

cond

s

Message Sequence Number

(b) RTDroid: 300 low-priority threads

0

200

400

600

800

1000

1200

1400

1600

1800

0 50 100 150 200 250 300 350 400

Mic

rose

cond

s

Message Sequence Number

(c) Android: 30 low-priority threads

Figure 9: The observed raw latency of Looper and Handler on x86.

0

500

1000

1500

2000

0 50 100 150 200 250 300 350 400

Mic

rose

cond

s

Message Sequence Number

(a) RTDroid: 5 low-priority threads

0

500

1000

1500

2000

0 50 100 150 200 250 300 350 400M

icro

seco

nds

Message Sequence Number

(b) RTDroid: 30 low-priority threads

0

5000

10000

15000

20000

0 50 100 150 200 250 300 350 400

Mic

rose

cond

s

Message Sequence Number

(c) Android: 5 low-priority threads

Figure 10: The observed raw latency of Looper and Handler on LEON3.

0

200

400

600

800

1000

0 50 100 150 200 250 300 350 400

Mic

rose

cond

s

Message Sequence Number

(a) RTDroid: With Ondemand Governor

0

200

400

600

800

1000

0 50 100 150 200 250 300 350 400

Mic

rose

cond

s

Message Sequence Number

(b) RTDroid: With Performance Governor

0

1e+06

2e+06

3e+06

4e+06

5e+06

6e+06

7e+06

8e+06

9e+06

1e+07

0 50 100 150 200 250 300 350 400

Mic

rose

cond

sMessage Sequence Number

(c) Android: Base System

Figure 11: The observed raw latency of Looper and Handler on Nexus S.

relevant portion of Android’s application framework, includ-ing Looper and Handler, so we can compile and run ourbenchmark application on x86. Thus, on Android, all threads,regardless of their priorities, use the same Looper and Han-

dler – this is the default behavior. On RTDroid, each threaduses a different pair of RT Looper and RT Handler accord-ing to its priority – this is opaque to the application developerand handled automatically by the system.

To measure the predictability of our constructs under aloaded system, we increase the number of low-priority threads.We have executed each experiment for 40 seconds, corre-sponding to 400 releases of the high-priority message, andhave a hard stop at 50 seconds. We measure latency onlyfor the high-priority messages and scale the number of low-priority threads up to the point where the total number ofmessages sent by the low-priority threads exceeds the abilityto process those messages within the 40 second executionwindow. On both Intel Core 2 Duo and Nexus S, we havevaried the number of low-priority threads in increments of10 from 0-300. Considering memory and other limitationsof our resource constrained embedded board, we have run

the experiments increasing the low priority threads in incre-ments of 5 from 5-30 when running on the LEON3 board.

Fig. 9 and Fig. 10 demonstrate the consistent latency ofour RT Looper and RT Handler implementation. On thedesktop, we observe most of the latency for messaging is be-tween 22 µs and 50 µs with any number of threads, and thevariance is around 20 µs from the lowest to the highest la-tency in any given run. The worst observed latency varianceis 26 µs. This degree of variance on the system is attributedto context switch costs and scheduling queue contention. Onthe LEON3 development board, the result shows a similarpattern. On both platforms, the latency variation of Androidis an order of magnitude greater than that of RTDroid.

Fig. 11 shows the results on Nexus S. We run two series ofexperiments, one with the ondemand governor and the otherone with the performance governor. It was observed that thelatency of the tests with the ondemand governor decreaseswith an increasing number of low-priority threads. This isdue to the extra load on the system, which results in theCPU’s frequency being increased by the ondemand gover-nor. The tests with the performance governor show a consis-

10

0

200

400

600

800

1000

1200

1400

0 20 40 60 80 100

Mic

rose

cond

Number of Low-Priority Alarms

Delivery Latency AEvent Fire Latency

(a) RTDroid: Per Thread AEH

0

200

400

600

800

1000

1200

1400

0 20 40 60 80 100

Mic

rose

cond

Number of Low-Priority Alarms

Delivery Latency AEvent Fire Latency

(b) RTDroid: Thread Pool AEH

Figure 12: RTSJ’s AEH implementation - Per Thread vs Thread Pool on x86.

0

200

400

600

800

1000

1200

1400

0 20 40 60 80 100

Mic

rose

cond

Number of Low-Priority Alarms

Delivery Latency AEvent Fire Latency

(a) RTDroid: Per Thread AEH

0

200

400

600

800

1000

1200

1400

0 20 40 60 80 100

Mic

rose

cond

Number of Low-Priority Alarms

Delivery Latency AEvent Fire Latency

(b) RTDroid: Thread Pool AEH

Figure 13: RTSJ’s AEH implementation - Per Thread vs Thread Pool on Nexus S.

tent latency in any given run, since the CPU frequency doesnot change. On the other hand, the latency variation fromAndroid is several orders of magnitude greater than that ofRTDroid as shown in Fig. 11a.

7.2 RT AlarmManagerMeasuring the performance of the RT AlarmManagerwas

done with an experiment consisting of scheduling of a sin-gle high-priority alarm at the current system time + 40 ms,while increasing the number of low-priority alarms sched-uled at the exact same time. We measure two types of la-tency for the experiment: 1) the entire latency of the alarmdelivery (Delivery latency), which is the difference betweenthe scheduled time and actual execution time of the high-priority alarm, and 2) the latency of the asynchronous eventfire (AEvent fire latency), which is the difference betweenthe scheduled time and the actual firing time by the Alarm-Manager. The difference between the two types of latencymeasures shows how long it takes for the system to deliveran alarm from the AlarmManager to the app. We run theexperiment on all three platforms. These results show thetiming and latencies of the alarm execution process and in-

dicate that the RT AlarmManager is efficient at prioritizinghigh-priority alarms and scheduling them at their specifiedtime.

As mentioned in Section 4, we have implemented twotechniques for alarm management in RT AlarmManager—one with a per-thread AEH implementation used in our pre-vious workshop paper [32] and another implemented witha thread pool. We show the predictability of RTDroid witheach technique by using threads ranging from 5-100 and athread granularity of 10. To induce queueing in the threadpool implementation, only 3 worker threads are allocated forthe thread pool.

7.2.1 x86 DesktopFig. 12 shows the results of the per-thread AEH and the

thread pool AEH experiments running on RTLinux. The la-tency of the entire alarm delivery for per-thread AEH on thex86 is bounded from 220 µs to 331 µs with a 32 µs standarddeviation. The Asynchronous event fire latency is consis-tently around 105 µs. The thread pool implementation ex-hibits a slightly slower performance with the alarm deliverybounded from 255 µs to 355 µs with a 29 µs standard devi-

11

0

30000

60000

90000

120000

0 5e+06

1e+07

1.5e+07

2e+07

2.5e+07

3e+07

3.5e+07

4e+07

Mic

rose

cond

s

Event Sequence Timestamp

(a) RTDroid: 1 Comp Thread

0

30000

60000

90000

120000

0 5e+06

1e+07

1.5e+07

2e+07

2.5e+07

3e+07

3.5e+07

4e+07

Mic

rose

cond

s

Event Sequence Timestamp

(b) RTDroid: 100 Comp Threads

0

500000

1e+06

1.5e+06

2e+06

2.5e+06

3e+06

0 5e+06

1e+07

1.5e+07

2e+07

2.5e+07

3e+07

3.5e+07

4e+07

Mic

rose

cond

s

Event Sequence Timestamp

(c) Android: 100 Comp Threads

0

30000

60000

90000

120000

0 5e+06

1e+07

1.5e+07

2e+07

2.5e+07

3e+07

3.5e+07

4e+07

Mic

rose

cond

s

Event Sequence Timestamp

(d) RTDroid: 1 Mem Thread

0

30000

60000

90000

120000

0 5e+06

1e+07

1.5e+07

2e+07

2.5e+07

3e+07

3.5e+07

4e+07

Mic

rose

cond

s

Event Sequence Timestamp

(e) RTDroid: 100 Mem Threads

0

500000

1e+06

1.5e+06

2e+06

2.5e+06

3e+06

0 5e+06

1e+07

1.5e+07

2e+07

2.5e+07

3e+07

3.5e+07

4e+07

Mic

rose

cond

s

Event Sequence Timestamp

(f) Android: 100 Mem Threads

Figure 14: Memory and Computation stress test for the Fall Detection Application on Nexus S.

ation. This small performance drop is expected and causedby alarm queuing in the thread pool itself.

7.2.2 Nexus S SmartphoneFig. 13 demonstrate the results with the same experimen-

tal scenario on the Nexus S smartphone. It shows the samepattern as the x86 does, but with a lager value. It is notsurprised since the different hardware architecture betweenX86 and smartphone in terms of the type and frequency oftheir CPU and available memory. On average,the thread poolshows less than 1 ms latency and the worst observed case is1.2 ms for both of the the per-thread AEH and thread poolimplementations, with 108 µs and 92 µs deviation.

7.2.3 LEON3 Embedded BoardWe have conducted a similar set of experiments on LEON3.

Our results, however, show little difference from our x86 andNexus S results. Due to this reason and space considera-tions, we do not include the graphs in this paper. Overall,for both AEH implementations across platforms, our experi-ments show that high-priority threads execute in a determin-istic fashion and with tight bounds. This is irrespective ofthe number of low-priority threads that exist in the system.

7.3 Real-Time Fall DetectorTo validate the predictability of our sensor architecture in

data delivery, we have created a soft real-time fall detectionapplication that leverages our SensorManager outlined inSection 5. We designed two experiments with two differ-

ent types of workloads: (1) a memory intensive load and(2) a computation intensive load. The memory intensive ex-periment creates a varying number of non-real-time prior-ity threads that each allocate a 2.5 MB integer array stor-ing integer objects. The thread then assigns every other en-try in the array to null. The effect of this operation is tofragment memory and create memory pressure. The com-putation intensive experiment creates low-priority, periodicthreads with a period of 20 ms. Each thread executes a tightloop performing floating point multiplication for 1,000 iter-ations.

The fall detection application is registered as a Sensor-

EventListener with SensorManager and executed withthe highest priority in system. After receiving events fromthe SensorManager as outlined in Section 5, the applica-tion consumes the SensorEvent with the value of x, y, andz coordinates and computes the fall detection algorithm. If afall is detected the application notifies a server through a di-rect socket connection using Wi-Fi. Since network does notprovide any real-time guarantees, we measure data-passinglatency between the time of the sensor raw data detected inthe kernel and the time that the sensor event is delivered bySensorManager to the fall detection application.

7.3.1 Nexus S SmartphoneFig. 14 illustrates the observed latency of the sensor event

delivery for the fall detection application. To stress the pre-dictability of our SensorManager implementation, we haveinjected memory and computationally intensive threads into

12

4000

5000

6000

7000

8000

9000

10000

0 1e+06

2e+06

3e+06

4e+06

5e+06

6e+06

7e+06

8e+06

9e+06

1e+07

Mic

rose

cond

s

Event Sequence Timestamp

(a) RTDroid: No Low-Priority Thread

4000

5000

6000

7000

8000

9000

10000

0 1e+06

2e+06

3e+06

4e+06

5e+06

6e+06

7e+06

8e+06

9e+06

1e+07

Mic

rose

cond

s

Event Sequence Timestamp

(b) RTDroid: 30 Comp Threads

4000

5000

6000

7000

8000

9000

10000

0 1e+06

2e+06

3e+06

4e+06

5e+06

6e+06

7e+06

8e+06

9e+06

1e+07

Mic

rose

cond

s

Event Sequence Timestamp

(c) RTDroid: 30 Mem Threads

Figure 15: Memory and Computation stress test for the Fall Detection Application on LEON3.

the application itself that run alongside of the fall detect-ing thread. We set these additional threads to a low priority.The Fig. 14a, Fig. 14d and Fig. 14b, Fig. 14e show the la-tency of sensor event delivery with one low-priority threadand 100 low priority threads. The upper bound of these fourruns was always around 30 ms, and there is no perceivabledifference between executing the app with or without mem-ory and computationally intensive threads. For comparisonwe provide Android performance numbers in Fig. 14c andFig. 14f to show the effect of low-priority threads on sensorevent delivery in stock Android.

7.3.2 LEON3Fig. 15 lists the results of running the system unloaded,

with 30 computational threads and with 30 memory inten-sive threads. The typical latency is 5.5 ms with a very lowstandard deviation. The memory intensive test shows a greatervariability in the sensor event delivery times but they still fallunder 6.5 ms and are also typically 5.5 ms also. RTDroiddeployed on this platform creates a very stable system, es-pecially when compared to the results of both Android andRTDroid running on the Nexus S as is shown in Fig. 14.

8. RELATED WORKRecent work has performed preliminary studies on the

real-time capabilities of Android. Maia et al. evaluatedAndroid for real-time and proposed the initial models fora high-level architecture [23]. The study did not explore theAndroid framework, services, IPC, nor core library imple-mentations for their suitability in a real-time context. Webelieve our work further refines the proposed models.

The overall performance and predictability of DVM in areal-time setting was first characterized by Oh et al. [26].Their findings mirror our general observations on Android.In many situations Android is quite performance. However,the core system does not provide any guarantees, and theworst case execution time is parameterized by other appsand components in the system. Thus, to provide real-timeguarantees, we need to alter the core system constructs, thelibraries, and system services built from them.

Kalkov et al. [21] outline how to extend DVM to sup-

port real-time; they observed that DVM’s garbage collectionmechanism suspends all threads until it finishes garbage col-lection. This design is obviously problematic for apps thatneed predictability. The suggested solution is to introducenew APIs that allow developers to free objects explicitly.While this design decision does not require a redesign ofthe whole Dalvik GC, relying on developers to achieve pre-dictability adds a layer of complexity. Although, Kalkov etal. proposed more modest changes to the Android system,focusing on modifying DVM’s GC to provide real-time ca-pabilities, they have not yet explored how different compo-nents within a single app (or across multiple apps) interactthrough Android’s core constructs. We have observed, thatthe structure of many of Android’s core mechanisms, fromwhich many services and libraries are constructed, need tobe augmented to provide real-time guarantees. Indeed, An-droid’s specialized programming model and execution pro-vide many design and implementation challenges. We be-lieve our implementation is synergistic to such proposals andcan be leveraged to provide predictability when apps lever-age services, IPC, or the core Android constructs.

9. CONCLUSIONSThis paper has presented RTDroid, a variation of Android

that aims to provide real-time capabilities to Android as awhole system. We have shown that replacing DVM witha RT JVM and Linux with an RTOS is insufficient to runan Android application with real-time guarantees. To ad-dress this shortcoming, we have redesigned Android’s coreconstructs and system services to provide tight latency bo-unds to real-time applications. Our experiments with threeplatforms—an x86 PC, a LEON3 embedded board, and aNexus S smartphone, show that RTDroid has good observedpredictability on several microbenchmarks as well as a real-time application across three distinct deployment profiles.Our future work entails expanding our system to supportmultiple real-time and non-real-time app executions, aug-menting and adding Fiji’s mixed-criticality support [11, 33]to RTDroid.

13

References[1] Android and RTOS together: The dynamic duo for today’s med-

ical devices. http://embedded-computing.com/articles/android-rtos-duo-todays-medical-devices/.

[2] Cpu frequency and voltage scaling code in the linux(tm) kernel.https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt.

[3] Linux kernel memory management: Out of memory killer. http://linux-mm.org/OOM_Killer.

[4] Northrop to demo darpa navigation system on an-droid. http://www.govconwire.com/2013/04/northrop-to-demo-darpa-navigation-system-on-android/.

[5] Real-Time Linux Wiki. https://rt.wiki.kernel.org/index.php/Main_Page.

[6] Roving reporter: Medical Device Manufacturers Improve Their Bed-side Manner with Android. http://goo.gl/d2JF3.

[7] RTEMS. http://www.rtems.org/.

[8] Strand-1 satellite launches Google Nexus One smartphone into or-bit. http://www.wired.co.uk/news/archive/2013-02/25/strand-1-phone-satellite.

[9] What OS Is Best for a Medical Device? http://www.summitdata.com/blog/?p=68.

[10] Why Android will be the biggest selling medical devices in the worldby the end of 2012. http://goo.gl/G5UXq.

[11] E. Blanton and L. Ziarek. Non-blocking inter-partition communica-tion with wait-free pair transactions. In Proceedings of the 11th Inter-national Workshop on Java Technologies for Real-time and EmbeddedSystems, JTRES ’13, pages 58–67, New York, NY, USA, 2013. ACM.

[12] J.-J. Chen and C.-F. Kuo. Energy-efficient scheduling for real-timesystems on dynamic voltage scaling (dvs) platforms. In Embeddedand Real-Time Computing Systems and Applications, 2007. RTCSA2007. 13th IEEE International Conference on, pages 28–38, 2007.

[13] A. Corsaro and D. Schmidt. The design and performance of the jratereal-time java implementation. 2519:900–921, 2002.

[14] A. Developers. Bionic c library overview. http://www.kandroid.org/ndk/docs/system/libc/OVERVIEW.html.

[15] T. Gerlitz, I. Kalkov, J. Schommer, D. Franke, and S. Kowalewski.Non-blocking garbage collection for real-time android. In Proceed-ings of the 11th International Workshop on Java Technologies forReal-time and Embedded Systems, JTRES ’13, 2013.

[16] J. Gosling and G. Bollella. The Real-Time Specification for Java.Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA,2000.

[17] D. Goswami, M. Lukasiewycz, R. Schneider, and S. Chakraborty.Time-triggered implementations of mixed-criticality automotive soft-ware. In Proceedings of the Conference on Design, Automation andTest in Europe, DATE ’12, pages 1227–1232, San Jose, CA, USA,2012. EDA Consortium.

[18] D. Hart, J. Stultz, and T. Ts’o. Real-time linux in real time. IBM Syst.J., 47(2):207–220, Apr. 2008.

[19] M. G. Hill and T. W. Lake. Non-interference analysis for mixed crit-icality code in avionics systems. In Proceedings of the 15th IEEEInternational Conference on Automated Software Engineering, ASE’00, pages 257–, Washington, DC, USA, 2000. IEEE Computer Soci-ety.

[20] iOmniscient. Fall and man down detection. http://iomniscient.com/index.php?option=com_content&view=article&id=155&Itemid=53.

[21] I. Kalkov, D. Franke, J. F. Schommer, and S. Kowalewski. A real-time extension to the Android platform. In Proceedings of the 10thInternational Workshop on Java Technologies for Real-time and Em-bedded Systems, JTRES ’12, pages 105–114, New York, NY, USA,2012. ACM.

[22] M. Kim and A. Wellings. An efficient and predictable implementationof asynchronous event handling in the RTSJ. In Proceedings of the6th international workshop on Java technologies for real-time andembedded systems, JTRES ’08, pages 48–57, New York, NY, USA,2008. ACM.

[23] C. Maia, L. Nogueira, and L. M. Pinho. Evaluating Android OS forembedded real-time systems. In Proceedings of the 6th InternationalWorkshop on Operating Systems Platforms for Embedded Real-TimeApplications, Brussels, Belgium, OSPERT ’10, pages 63–70, 2010.

[24] S. Mohan, F. Mueller, M. Root, W. Hawkins, C. Healy, D. Whal-ley, and E. Vivancos. Parametric timing analysis and its applica-tion to dynamic voltage scaling. ACM Trans. Embed. Comput. Syst.,10(2):25:1–25:34, Jan. 2011.

[25] Y. Murphy. Northrop grumman news release: DARPA ASPN projectarticle. http://www.irconnect.com/noc/press/pages/news_releases.html?d=10029353.

[26] H.-S. Oh, B.-J. Kim, H.-K. Choi, and S.-M. Moon. Evaluation of An-droid Dalvik virtual machine. In Proceedings of the 10th InternationalWorkshop on Java Technologies for Real-time and Embedded Systems,JTRES ’12, pages 115–124, New York, NY, USA, 2012. ACM.

[27] V. S. Pai, P. Druschel, and W. Zwaenepoel. Flash: An efficient andportable web server. In Proceedings of the 1999 USENIX AnnualTechnical Conference, USENIX ATC’99, 1999.

[28] F. Pizlo, L. Ziarek, E. Blanton, P. Maj, and J. Vitek. High-level pro-gramming of embedded hard real-time devices. In Proceedings of the5th European conference on Computer systems, EuroSys ’10, pages69–82, New York, NY, USA, 2010. ACM.

[29] F. Pizlo, L. Ziarek, P. Maj, A. L. Hosking, E. Blanton, and J. Vitek.Schism: fragmentation-tolerant real-time garbage collection. In Pro-ceedings of the 2010 ACM SIGPLAN conference on Programminglanguage design and implementation, PLDI ’10, pages 146–159, NewYork, NY, USA, 2010. ACM.

[30] M. E. Systems. Rugged handheld computers suit up with an-droid on the battlefield. http://mil-embedded.com/articles/rugged-suit-with-android-the-battlefield/#.

[31] M. Welsh, D. Culler, and E. Brewer. Seda: An architecture for well-conditioned, scalable internet services. In Proceedings of the Eigh-teenth ACM Symposium on Operating Systems Principles, SOSP ’01,pages 230–243, New York, NY, USA, 2001. ACM.

[32] Y. Yan, S. H. Konduri, A. Kulkarni, V. Anand, S. Y. Ko, and L. Ziarek.Rtdroid: A design for real-time android. In Proceedings of the 11thInternational Workshop on Java Technologies for Real-time and Em-bedded Systems, JTRES ’13, 2013.

[33] L. Ziarek. Prp: Priority rollback protocol – a pip extension for mixedcriticality systems: Short paper. In Proceedings of the 8th Interna-tional Workshop on Java Technologies for Real-Time and EmbeddedSystems, JTRES ’10, pages 82–84, New York, NY, USA, 2010. ACM.

14