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
Permission to make digital or hard copies of all or part of this work for personal or
to guarantee predictable runtime performance for apps that
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 Linux Kernel Dalvik VM
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. For example, the UK has launched a satellite reduces the complexity of development and maintenance of
equipped with a regular control system as well as a smart- real-time apps.
phone (Google Nexus One) [7]. The goal of the satellite is We note that supporting such mixed-criticality scenarios
to experiment with transferring control from the standard 2
As of June, 2013 (https://play.google.com/about/
control system to the mobile device itself. apps/)
requires significant engineering effort to support download- tails). Simply modifying DVM or the OS is not enough to
ing and installation of real-time apps, validation of newly in- augment Android’s runtime model; the framework layer it-
stalled apps with regard to the schedulability of other apps self must be changed. Since the Fiji VM has mixed crit-
present in the system, JITing DEX bytecode to specialize icality support, we can execute system services either as
for the target platform [10], access to I/O and hardware threads within a single-app deployment, or as separate Java
sensors, and power management issues. Such challenges are programs executing in a partition of a single multi-VM in-
out of the scope of this paper. Instead, we focus on the core stance.
Android constructs and system services that are used not The third benefit of our architecture is the streamlining
only for single-app scenarios, but also for multi-app scenar- of real-time app development. Developers can leverage the
ios as those are essential to build Android compatibility as rich APIs and libraries already implemented and support for
we describe in the next section. various hardware components. Unlike other mobile OSes,
Android excels in supporting a wide variety of hardware
3. THE CASE FOR RTDROID with different CPUs, memory capacities, screen sizes, and
sensors. Thus, Android APIs make it easier to write a sin-
To support the scenarios discussed in the previous sec-
gle app that can run on different hardware. In addition,
tion, we advocate a clean-slate design for RTDroid. We
Android APIs allow a developer to use all hardware compo-
start from the ground up, leveraging an established RTOS
nents available on a mobile device, such as: a touch screen,
(e.g., RT Linux [4, 14], RTEMS [6]) and an RT JVM (e.g.,
Wi-Fi, GPS, Bluetooth, telephony, accelerometer, camera,
Fiji VM [19]). Upon this foundation we build Android com-
etc. Thus, Android compatibility can reduce the complexity
patibility. RTDroid provides a faithful illusion to an ex-
of real-time app development.
isting Android app running on our platform that it is ex-
ecuting on Android. This necessitates providing the same
set of Android APIs as well as preserving their semantics 3.2 Challenges
for both regular Android apps and real-time apps. For real- Providing Android compatibility means that we provide
time apps, Android compatibility means that developers can a faithful illusion that an app is running on Android, i.e.,
use standard Android APIs in addition to a small number of we should be able to take an existing Android app and run
additional APIs our platform provides to support real-time it on our platform. In addition, a developer should be able
features. These additional APIs provide limited RTSJ [13] to use Android APIs in a real-time app. This is where our
support without scoped memory. main challenge lies; due to the unique programming and
This approach, however, does not mean that we can sim- runtime model of Android, it requires careful consideration
ply “port” the existing Android code to run on an RTOS as to how to preserve the semantics of the APIs while us-
and an RT JVM. As a consequence, we do not have full ing an RT JVM and an RTOS. There are two main con-
freedom to re-architect the underlying implementation of cerns that Android introduces though its programming and
all the APIs. The unique programming and runtime model execution models: 1) Android leverages extensive usage of
of Android requires careful consideration as to how we can callbacks – callbacks registered by high priority threads will
simultaneously support Android compatibility while provid- not necessarily be executed in the high priority thread itself
ing real-time guarantees. In this section, we discuss why resulting in computation expressed in a high priority task
this is the case by first presenting the benefits of our design, to potentially execute at lower priority and 2) core Android
then discussing the challenges in realizing our design within constructs are not priority aware, most use FIFO ordering
the context of a concrete system. for processing.
More specifically, we need to consider the following four
3.1 Benefits aspects essential to Android to achieve our goal of providing
There are three major benefits of our clean-slate design. Android compatibility: 1) supporting the four main com-
First, by using an RTOS and an RT JVM, we can rely on ponents of Android that an app implements, 2) handling
the sound design decisions already made and implemented Android constructs that an app can use, 3) handling An-
to support real-time capabilities in these systems. For ex- droid system services, and 4) supporting Android’s byte-
ample, our RTDroid prototype uses Fiji VM [19], which code format, DEX. Two of the challenges—challenges 1 and
is designed to support real-time Java programs from the 4—are not necessarily research directions, but rather engi-
ground up. Fiji VM already provides real-time function- neering tasks. The other two challenges require more careful
ality through static compiler checks, real-time garbage col- consideration. In the rest of this section, we discuss these
lection [20], synchronization, threading, etc. and crucially challenges at a high level. In Section 4, we take two specific
provides mixed-criticality support necessary for executing examples that illustrate these challenges and discuss how we
multiple applications within a single VM. We note, however, address them within the implementation of RTDroid.
that RTDroid’s design is VM independent.
The second benefit of our architecture is the flexibility of
adjusting the runtime model for each use case discussed in 3.2.1 Supporting Android’s Four Main Components
Section 2. Using an RTOS and an RT JVM provides the The Android programming model provides four main com-
freedom to control the runtime model. For example, we can ponents for constructing apps—Activity, Service, Broad-
leverage the RTEMS [6] runtime model, where one process castReceiver, and ContentProvider—which are essentially
compiled together with the kernel with full utility of all the abstract Java classes that define callbacks that an app im-
resources of the underlying hardware, for single app deploy- plements. An Android app needs to extend and implement
ment. Using this runtime model is not currently possible at least one of these four classes to run on Android. Thus,
with Android, as Android requires most system services to supporting these four main components exactly the way An-
run as separate processes (Section 3.2.3 provides more de- droid does is critical to providing Android compatibility.
 start
Activity Processing Thread Client
onCreate() onStart() onResume()
Running Message Thread
Queue
Handler
end Object
Message
onDestroy() onRestart() onStop() onPause() Looper
handleMessage
Message loop

Message sendMessage

Figure 2: The State Transition for Activity.

Briefly speaking 3 , an Activity class controls the UI of
an app. A Service class implements tasks that run in the Figure 3: An Example of Looper and Handler. In the exam-
background, e.g., playing background music for an app. A ple, the client thread is sending a message to the processing
BroadcastReceiver class can receive and react to broad- thread. Both threads share the Handler object. The pro-
cast messages sent by other apps or the Android platform; cessing thread has a Looper and a message queue.
for example, Android sends out a “low battery” broadcast
message to alert apps that the mobile device is running low some or all of its methods through Binder, which takes care
on battery. Lastly, an app can have a DB-like storage by of all aspects of communication such as marshalling and un-
implementing a ContentProvider class. marshalling. Messenger is another IPC mechanism easier to
Each of these four main component classes defines call- use than Binder; however, it is not a separate construct as
backs that an app can implement. The Android platform the underlying implementation uses Binder and Handler.
invokes one of these callbacks at an appropriate time de- There are three reasons why a typical Android app uses
pending on what state the app is in. For example, an Ac- these constructs. First, any Android app that implements
tivity class defines a number of callbacks such as onCre- more than one of four main components discussed in Sec-
ate, onStart, onResume, onPause, onStop, etc. When an tion 3.2.1 needs to use either Binder or Messenger for inter-
app starts for the first time, the Android platform invokes component communication. Second, Android does not allow
onCreate and onStart in that order. When an app goes any long-running operations to run on its Activity thread
out of focus (e.g., when the user pushes the home button since the Activity thread manipulates the UI and long-
or the app switcher button), the platform invokes onPause. running operations can render the UI unresponsive. Thus, a
When an app returns to the foreground, the platform in- typical Android app creates multiple threads to handle long-
vokes onResume. Fig. 2 shows a simplified state transition running operations and leverages Looper and Handler for
diagram for an Activity. Likewise, all other main compo- inter-thread communication. Third, Android’s system ser-
nent classes define a set of callbacks as entry points to an vices run as separate processes (as we detail in Section 3.2.3)
app. In order to provide Android compatibility, our plat- and accessing these services also requires the use of Binder.
form needs to preserve the same execution flows of all the Among the constructs, the joint use of Looper and Han-
main components. dler is the ideal first choice to explore the design space in
our platform; this is because these constructs are used in all
3.2.2 Supporting Android Constructs three types of cross-entity communication, either directly
Android provides a set of constructs that facilitate com- (for inter-thread communication) or indirectly (for inter-
munication between different entities, e.g., threads, main component or inter-process communication through the use
components, and processes. There are four such constructs— of Messenger).
Handler, Looper, Binder, and Messenger. Since any typical Since Looper and Handler jointly handle messages, it raises
Android app uses these constructs, it is critical for us to a question for real-time apps when there are multiple threads
support these constructs properly in a real-time context. with different priorities sending messages simultaneously. In
We first briefly describe how these constructs work on Android, there are two ways that Looper and Handler pro-
Android as this is necessary to understand the challenges cess messages sent to their thread. By default, Looper and
for supporting these constructs. First, Looper and Handler Handler process messages in the order in which they were
jointly enable inter-thread communication. If two threads received. Additionally, a sending thread can specify a mes-
need to communicate, the receiving thread should first im- sage processing time, in which case Looper and Handler will
plement Handler’s abstract callback method handleMessage process the message at the specified time. In both cases,
and instantiate it. Then it should share this Handler object however, the processing of a message is done regardless of
with the sending thread, which uses Handler’s sendMessage the priority of the sending thread or the receiving thread.
or other similar methods to send a message. Internally, Consider if multiple user-defined threads send messages to
Looper bridges a sendMessage call to its corresponding han- another thread leveraging Looper and Handler. If a real-
dleMessage call; it maintains a message queue that stores time thread sends a message through a Handler, its mes-
all messages sent by sendMessage and dispatches those mes- sage will not be processed until the Looper dispatches every
sages to its Handler by calling handleMessage. Fig. 3 illus- other message in the queue regardless of the sender’s priority
trates the use of Looper and Handler. as seen in Fig. 4. The situation is exacerbated by the fact
Binder is the IPC mechanism of Android that allows dif- that Android can re-arrange messages in a message queue if
ferent components and processes to communicate. Its usage there are messages with specific processing times. For ex-
is similar to a typical IPC mechanism; a process can expose ample, suppose that there are a number of messages sent by
3
Android Developers website has more detailed informa- non-real-time threads in a queue received before a message
tion (http://developer.android.com/guide/components/ sent by a real-time thread. While processing those messages,
fundamentals.html). any number of low-priority threads can send messages with
 Message Queue
First, in our first use case of running a single real-time app,
RT Msg 1 Msg n Msg1
Looper there is no need to run system services as separate processes;
Thread
rather it is more favorable to run the app and the system
services as a single process to improve the overall efficiency
Handler of the system. Then the question is how to re-design the
Object system service architecture in our platform in order to avoid
creating separate processes while preserving the underlying
Msg 1 RT Msg1
Msg n behavior of Android.
The second question is how to mediate access to the sys-
tem services when multiple threads or processes with differ-
Thread Thread RT Thread
ent priorities access them simultaneously. Since it involves
multiple threads or processes, the question arises not only
in our first use case of a single real-time app but also in our
Figure 4: The thread in which the looper executes processes second use case of mixed criticality. The default policy for
the messages sent through this handler object in the order Android is first-come, first-served, which does not consider
in which they are received. priorities as a parameter, hence not suitable in real-time
App AlarmManager LocationManager systems.
Alarm Location We explore the answers to the above two questions in Sec-
Activity Manager Manager
Service Service tion 4 with AlarmManager as an illustrative example. Alar-
mManager provides a system timer that triggers at specific
LocationManager AlarmManager LocationManager times; it receives timer registration requests from different
.Stub.Proxy .Stub .Stub apps and sends a “timer triggered” message to each app when
its timer fires. Since it deals with both timing and message
libbinder
delivery, it is the ideal first choice to explore the solution
libbinder libbinder
space to answer the above two questions.

Kernel 3.2.4 Supporting DEX

Android apps use DEX as their bytecode format, which is
/dev/binder
different from typical Java bytecode [2]. Thus, in order to
run existing Android apps on our platform, we need to sup-
port DEX. Although this is not necessarily a research chal-
Figure 5: The example shows how an app accesses the Lo- lenge, it is nevertheless a challenge to address. Since Fiji VM
cationManager service through the Binder IPC. only supports Java bytecode, our current prototype assumes
that the source code is available to re-compile. However,
specific times. If those times come before finishing the pro-
there are other potential solutions; we can either implement
cessing of non-real-time messages, the real-time message will
DEX support in Fiji VM or leverage existing tools that con-
get delayed further by non-real-time messages.
vert DEX bytecode to Java bytecode, e.g., Dexpler [11] or
As a concrete example, consider a health monitoring app
dex2jar [3]. Exploring these options is our future work.
that communicates over Bluetooth with a nearby caretaker’s
device for alert information. Assume a real-time thread is
relying on another thread for sending an emergency response 4. ILLUSTRATIVE EXAMPLES
request over Bluetooth in the instance it detects a fall. To To discuss our current approach to adding real-time sup-
communicate with this networking thread, a thread must port to Android, we present two examples in this section.
access the networking thread’s Handler object. However, if The first example is the joint use of Looper and Handler
other non-real-time tasks also leverage the same network- to illustrate how we support Android constructs. The sec-
ing thread, they can delay the sending of the emergency ond example is AlarmManager to illustrate how we support
response request for an amount of time required to process system services.
the pending messages. Typically, to handle a message sent
to the networking thread requires creation of a packet and 4.1 Looper and Handler
the transmission of the packet. As mentioned in Section 3.2.2, Android’s implementation
for Looper and Handler simply processes incoming messages
3.2.3 Supporting System Services either in the order of reception or at specified times. This
Android mediates all access to its core system function- can create problematic scenarios for high priority threads
alities through a set of system services. Just to name a where their messages are delayed by messages sent by low
few, these services include ConnectivityManager that han- priority threads.
dles network connection management; PowerManager that To address this problem, we make two design decisions to
controls power; LocationManager that controls location up- support real-time. First, we assign a priority to each mes-
dates through either GPS or nearby cell tower information; sage sent by a thread. We currently support two policies for
and AlarmManager that provides a timer service. These sys- priority assignment. These policies are priority inheritance,
tem services run as separate processes and the APIs for ac- where a message inherits its sender’s priority, and priority
cessing these services use the Binder IPC. Fig. 5 shows an inheritance + specified where a sender can specify the mes-
example. sage’s priority in relation to other messages it has sent. We
The presence and the access model of these system ser- are exploring other types of policies in order to provide guar-
vices raises two questions that our platform needs to answer. antees depending on the context in which the Handler and
 Message Queue RT Message Queue
Looper Looper App
Msg n Msg 1 Thread RTMsg n RTMsg 1 Thread
(Non-RT) (RT) Activity AlarmManager
AlarmManager.set() Timestamp
Handler Handler Message
Object Object
BroadcastReceiver
Msg 1 Msg n RT Msg1 onReceive() Message

RT
Thread Thread
Thread
Figure 7: An Example Flow of AlarmManager. An app uses
AlarmManager.set() to register an alarm. When the alarm
Figure 6: An Example of Looper and Handler on RTDroid.
triggers, the AlarmManager sends a message back to the app,
Each message has a priority and is stored in a priority queue.
and the app’s callback (BroadcastReceiver.onReceive() in
Processing of messages is also done by priority. The example
the example) gets executed.
shows one high-priority thread and multiple non-real-time
threads.
App Thread Alarm Map
Looper are leveraged. For instance, we are investigating an
earliest deadline first processing scheme for soft-real-time UI AlarmManager.set()
updates. Fully exploring priority assignment policies is our
Timestamp
future work.
Our second design decision is to create multiple prior-
ity queues to store incoming messages according to their
priority. We then associate one Looper and Handler for Message
each queue to process each message according to its prior-
ity. Fig. 6 shows our new implementation for Looper and
Handler. Since we now process each message according to Figure 8: The Implementation of Alarm Registration on RT-
its sender’s priority, messages sent by lower priority threads Droid. The tree colored black at the top maintains times-
do not delay the messages sent by higher priority threads. tamps; the trees colored gray are per-timestamp trees main-
Although our conceptual model leverages one thread per taining actual alarm messages to be delivered.
priority level, the implementation of these constructs is backed est path of the tree. We use one red-black tree for storing
by a thread pool. We adopt a similar approach to imple- timestamps and pointers to per-timestamp red-black trees;
menting efficient Asynchronous Event Handler (AEH) in then we use these per-timestamp trees to order alarms with
RTSJ, proposed by Kim et al. [16]. To provide memory the same timestamp by their sender’s priority. Thus, our
safety we limit the size of the queue. We are currently in- alarm registration process is essentially one insert operation
vestigating which queue management schemes and size lim- to the timestamp tree and another insert operation to a per-
itations are appropriate for which service. timestamp tree. By organizing the alarms based on senders’
priorities, we guarantee that an alarm message for a low
4.2 AlarmManager priority thread does not delay an alarm message for a high
The AlarmManager is an ideal candidate to discuss how priority thread. Expired alarms are discarded. Note that
we address the following two questions for system services: this ensure that low priority threads whose alarm registra-
1) how to adapt Android’s multi-process architecture when tion rate exceeds the alarm delivery capacity of the system
running a single real-time app, and 2) how to mediate access cannot prevent a high priority alarm from being triggered.
to a system service from multiple threads with different pri- For alarm delivery, we create an AlarmManager thread and
orities. We first briefly overview how AlarmManager works assign the highest priority for timely delivery of alarm mes-
and discuss our approach. sages. With this thread, we replace the multi-process mes-
Android’s implementation for AlarmManager involves alarm sage passing architecture of the original AlarmManager with
registration and alarm delivery as shown in Fig. 7. When an RTSJ’s AEH. More specifically, the thread wakes up when-
app registers an alarm, it makes an IPC call to AlarmMan- ever an app inserts a new alarm to our red-black trees; then
ager with a message and a time. The message is associated it schedules an AEH at the specified time for the alarm.
with a callback of the app which gets executed when the We associate the app’s callback for the alarm message with
message is delivered 4 . When the alarm triggers at the spec- this AEH, so that we execute the callback exactly at the
ified time, AlarmManager sends the message back to the app, time specified in the alarm. In practice, most Android apps
and the callback gets executed. In both the registration and leverage only a few alarms. However, we are exploring an
the delivery, Android provides no guarantee on when or in alternative approach where we create one AEH per priority
what order the message is delivered. level and leverage a thread pool.
Thus, we re-design both registration and delivery of alarms
to support predictability. For alarm registration, we use
red-black trees to maintain alarms as shown in Fig. 8; this
5. EVALUATION AND RESULTS
means that we can make the registration process predictable To measure and validate our prototype of RTDroid, we
based on the complexity of red-black tree operations, i.e., tested our implementation on two system level configura-
the longest path of a tree is no longer than twice the short- tions. The first configuration utilizes an Intel Core 2 Duo
1.86GHz Processor with 2GB of RAM running Linux patched
4 with RT Linux v.3.4.45. For precise timing measurements
This is done by using Android’s Intent, though we do not
discuss the details here due to space considerations. we disabled one of the cores prior to running the experi-
 40 50
38
45
36

Microseconds

Microseconds
34 40
32
35
30
28 30
26
25
24
22 20
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Percentage Percentage

(a) With 30 low priority threads (b) With 300 low priority threads

Figure 9: The cumulative distribution of latency for RTDroid at 30 and 300 low priority threads configuration on Core 2 Duo
running RT Linux.

1800 4.5e+07
1600
4e+07
1400
Microseconds

Microseconds
3.5e+07
1200
1000 3e+07

800 2.5e+07
600
2e+07
400
1.5e+07
200
0 1e+07
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Percentage Percentage

(a) With 30 low priority threads (b) With 300 low priority threads

Figure 10: The cumulative distribution of latency for Android at 30 and 300 low priority threads configuration on Core 2 Duo
running RT Linux.
ments. cessing this message. To do this, we take a timestamp in the
For the second configuration we leveraged a stock LEON3 real-time thread prior to sending the message. This times-
embedded board manufactured by Gaisler. The experiments tamp is the data encoded within the message. A second
were run on a GR-XC6S-LX75 LEON development board 5 timestamp is taken within the Looper responsible for pro-
running RTEMS version 4.9.2. The board’s Xilinx Spartan cessing this message after the message has been received and
6 Family FPGA was flashed with a LEON3 configuration the appropriate callback invoked. The difference between
running at 50Mhz. The development board has an 8MB the timestamps is the messages latency. In addition, the
flash PROM and 128MB of PC133 SDRAM. experiments include a number of low priority threads which
In order to evaluate the performance of our approach, we also leverage the same resource though the same Handler
ran our experiments comparing two different configurations object. These threads have a period of 10ms and send 10
of Looper and Handler. The first configuration (Android) messages during each period.
is a direct port of the stock Android Implementation and To measure the predictability of our constructs under a
mirrors the previously proposed system architectures given loaded system, we increase the number of low priority threads.
in Fig. 1c and Fig. 1d. The second configuration (RTDroid) We have executed each experiment for 40 seconds, corre-
is our proposed extension. sponding to 400 releases of the high priority thread, and
have a hard stop at 50 seconds. We measure latency only
5.1 Experiments for the high priority messages. We scale the number of low
To measure the effectiveness of our prototype, we con- priority threads up to the point where the total number of
structed an experiment that leveraged Looper and Handler. messages sent by the low priority threads exceeds the abil-
Since these are two of the core constructs for inter-thread, ity to process those messages within the 40 second execu-
inter-component, and inter-process communication, show- tion window. We have varied the number of low priority
ing the predictability of this construct is crucial. Our mi- threads in increments of 10 from 10-100 and in increments
crobenchmark creates one real-time task with a 100ms pe- of 100 from 100-300 when running the experiments on the
riod that sends a high priority message. To measure the Intel Core 2 Duo running RT Linux. Considering memory
predictability of the system, we calculate the latency of pro- and other limitations of our resource constrained embedded
board, we have run the experiments increasing the low pri-
5
Additional board specification can be found at Gaisler’s ority threads in increments of 5 from 5-30 when running on
website: www.gaisler.com. the LEON3 board. Saturation of the message queue occurs
 40 50
38
45
36

Microseconds

Microseconds
34 40
32
35
30
28 30
26
25
24
22 20
0 50 100 150 200 250 300 0 50 100 150 200 250 300
Message sequence number Message sequence number

(a) (b)

Figure 11: The raw latency measurement for RTDroid at 30 and 300 low priority threads configuration on Core 2 Duo running
RT Linux.

1800 4.5e+07
1600
4e+07
1400
Microseconds

Microseconds
3.5e+07
1200
1000 3e+07

800 2.5e+07
600
2e+07
400
1.5e+07
200
0 1e+07
0 50 100 150 200 250 300 0 50 100 150 200 250 300
Message sequence number Message sequence number

Figure 12: The raw latency measurement for Android at 30 and 300 low priority threads configuration on Core 2 Duo running
RT Linux.
at around 15 low priority threads. Besides the measurement thread to the high priority thread and also the increased
of high priority message, we also calculate the overall mes- contention on the scheduling queue with a higher number of
sage throughput to test the broken point for the both of the threads. On the Android configuration, we observe an inter-
Android and RTDroid in the same scenario. esting phenomena. When the number of low priority threads
The data is discussed both in aggregate as well as in- is relatively small with 30 threads in Fig. 10a, 60% of the
trospecting a given run on each hardware platform. We messages have similar latency to that of RTDroid, but there
present three different types of plots: 1) the cumulative is a high spike in latency in the last 10% of messages. Fur-
distribution of the message processing latency for each re- ther, the difference between the best latency and the worst
lease of the high priority thread with differing numbers of latency is almost two orders of magnitude. Once the num-
low priority threads using the same Handler, 2) the raw ber of low priority threads increases to 300 in Fig. 10b, the
latency observed in handling messages from high priority latency distribution becomes almost linear with a very large
threads, and 3) the overall throughput of RTDroid com- difference between the best case and the worst case latency.
pared to Android. Raw data gathered from the experiments This occurs because before the first release of the high prior-
as well as scripts to generate the graphs are available at: ity thread, the queue is already saturated. We provide more
http://RTDroid.cse.buffalo.edu. details of the phenomena in the following subsection.

5.2 Result Overview 5.3 Raw Latency

We first present a summary of the results and show a In the latency plots for Android implementation, we ob-
more detailed view in the following subsection. Fig. 9 and serve that message processing delays vary arbitrarily, with
Fig. 10 show the overall cumulative latency distribution. We increase in latency being greater than an order of magni-
observe that the bounds of latency vary with increasing low tude in some cases (see Fig. 12). These plots clearly show
priority threads in Android, but stays relatively constant for the lack of real-time processing guarantees. The bound on
RTDroid; Fig. 9a and Fig. 9b show that all messages experi- latency is loose and there is no consistent or uniform latency
ence latency between 23µs and 49µs regardless of the num- distribution. The raw timing numbers do provide an expla-
ber of threads on RTDroid. Moreover, the observed worst nation for the phenomena we observed in the Android case
case latency increases only by 9µs even when the number when examining the cumulative distribution plots. Notice
of threads is increased by an order of magnitude from 30 to that the initial messages have the greatest latency and this
300. This increase is attributed to the fact that there is a decreases over time. What is occurring is that the low prior-
greater probability of context switching from a low priority ity threads fill the message queue faster than the messages
 bility. Based on our experiences with Android applications
100000 it is highly unusual for any app to leverage more than a
RTDroid few threads that interact with a given component. As such,
80000
Throughput Android these experiments serve to illustrate the maximum loads the
60000 system can realistically handle. We expect the throughput
of the Android configuration to mirror that of RTDroid, if
40000 additional threads were present in the system that did not
leverage the Handler, thereby increasing preemptions and
20000
reducing overall per unit time contention on the message
0 queue.
0 20 40 60 80 100 120
Number of threads
5.5 LEON3
The LEON3 results are summarized in Fig. 14, for the de-
Figure 13: A throughput comparison of Android and RT- fault RTEMS configuration leveraging 10 threads. We note
Droid scaled by the number of low priority threads on Core that the development board configuration can only report
2 Duo running RT Linux. timing results at a granularity of 400 µs since it does not have
a timing register and the hardware clock frequency cannot
can be processed, causing large initial delays. Eventually be adjusted. Based on the timing granularity, our LEON3
the processing thread catches up as the low priority threads results mirror the results obtained on the Intel Core 2 Duo.
complete their workloads.
Compared to the Android implementation, RTDroid shows
significantly better consistency in terms of message delay
6. RELATED WORK
bounds. More than 90% of the messages experience the la- Recent work has performed prelimnary studies on the real-
tency between 22µs and 50µs with any number of threads, time capabilities of Android. Maia et al. evaluated Android
with variance of around 20µs from the lowest to the highest for real-time and proposed the initial models for a high-level
latency for those messages in any given run. Further, the architecture [17]. The study did not explore the Android
largest latency variance is 26µs. This variance is attributed framework, services, IPC, nor core library implementations
to context switch costs and scheduling queue contention. We for their suitability in a real-time context. We believe our
have isolated these delays by profiling the execution times work further refines the proposed models.
of the threads themselves. For Android roughly 6% of mes- The overall performace and predictability of DVM in a
sages have similar latencies to RTDroid, however there are real-time setting was first characterized by Oh et al. [18].
significant spikes in the remaining 40% of messages. The Their findings mirror our general observations on Android.
standard deviation for Android is 1600µs for a reasonably In many situations Android is quite performant. However,
loaded system and 2 ∗ 107 µs for an overloaded system (ad- the core system does not provide any guarantees, and the
ditional plots are provided in the accompanying technical worst case execution time is parameterized by other apps
report [22]). and components in the system. Thus, to provide real-time
guarantees, we need to alter the core system constructs, the
libraries, and system services built from them.
5.4 Throughput Kalkov et al. [15] outline how to extend DVM to sup-
To measure the cost associated with our solution we com- port real-time; they observed that DVM’s garbage collection
pared the throughput of the Android configuration to RT- mechanism suspends all threads until it finishes garbage col-
Droid given in Fig. 13. To calculate the throughput we mea- lection. This design is obviously problematic for apps that
sured the rate in which all messages, both from high and low need predictability. The suggested solution is to introduce
priority threads, are processed. We observe that for the two new APIs that allow developers to free objects explicitly.
configurations, the throughput is roughly equivalent with While this design decision does not require a re-design of
low numbers of threads. This result is not unexpected as the whole Dalvik GC, relying on developers to achieve pre-
the primary overhead in RTDroid is the use of a Handler dictability adds a layer of complexity. Although, Kalkov et
object by a thread with a priority that has not communi- al. proposed more modest changes to the Android system,
cated through this Handler before. In such situations, a focusing on modifying DVM’s GC to provide real-time ca-
new queue and Looper thread are created for this priority. pabilities, they have not yet explored how different compo-
We observe that the system can be pre-configured and these nents within a single app (or across multiple apps) interact
resources allocated at boot time, but the current implemen- through Android’s core constructs. We have observed, that
tation does this dynamically. We also note that at around the structure of many of Android’s core mechanisms, from
100 low priority threads, we create enough contention on which many services and libraries are constructed, need to
the message queue and scheduling queue that throughput be augmented to provide real-time guarantees. Indeed, An-
decreases dramatically. Note, however, that even in extreme droid’s specialized programming model and execution pro-
cases of contention the latency of high priority thread’s mes- vide many design and implementation challenges. We be-
sages is only increased by the cost of preempting the low pri- lieve our implementation is synergistic to such proposals and
ority thread. For the Android configuration, this dramatic can be leveraged to provide predictability when apps lever-
drop occurs before the RTDroid configuration at around 50 age services, IPC, or the core Android constructs.
low priority threads. This happens because the high priority
thread introduces enough additional preemption to prevent
the low priority Looper from being starved by the low pri- 7. CONCLUSION AND FUTURE WORK
ority threads, which allows for additional throughput scala- In this paper we have shown that replacing DVM with
 950 950

900 900

Microseconds

Microseconds
850 850

800 800

750 750

700 700

650 650

600 600
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 50 100 150 200 250 300
Percentage Message sequence number

Figure 14: The cumulative distribution and raw measurement of latency for RTDroid at 10 low priority threads configuration
on LEON3 running RTEMS.
a RT JVM and Linux with an RTOS is insufficient to run [13] James Gosling and Greg Bollella. The Real-Time
Android application with real-time guarantees. To address Specification for Java. Addison-Wesley Longman
this shortcoming of the proposed real-time Android models, Publishing Co., Inc., Boston, MA, USA, 2000.
we presented RTDroid, an initial design of a real-time An- [14] D. Hart, J. Stultz, and T. Ts’o. Real-time linux in real
time. IBM Syst. J., 47(2):207–220, April 2008.
droid system focusing on supporting a single real-time app.
[15] Igor Kalkov, Dominik Franke, John F. Schommer, and
We have designed RTDroid to be VM and RTOS agnostic Stefan Kowalewski. A real-time extension to the Android
and with mixed-criticality in mind. We have validated our platform. In Proceedings of the 10th International
design and prototype, showing RTDroid has good observed Workshop on Java Technologies for Real-time and
predictability. Embedded Systems, JTRES ’12, pages 105–114, New York,
Our next step is about to adapt the solutions that we men- NY, USA, 2012. ACM.
tions in Section 4.2 to make the AlarmManager more efficient. [16] MinSeong Kim and Andy Wellings. An efficient and
predictable implementation of asynchronous event handling
Then we will move toward a mixed-criticality execution envi- in the RTSJ. In Proceedings of the 6th international
ronment and expand our IPC and service support to provide workshop on Java technologies for real-time and embedded
predictable, cross partition usage of the Android constructs. systems, JTRES ’08, pages 48–57, New York, NY, USA,
In addition, we plan to explore the use of scoped memory for 2008. ACM.
providing tighter memory guarantees within core Android [17] Cláudio Maia, Luı́s Nogueira, and Luis Miguel Pinho.
constructs. Evaluating Android OS for embedded real-time systems. In
Proceedings of the 6th International Workshop on
Operating Systems Platforms for Embedded Real-Time
8. REFERENCES Applications, Brussels, Belgium, OSPERT ’10, pages
63–70, 2010.
[1] Android and RTOS together: The dynamic duo for today’s [18] Hyeong-Seok Oh, Beom-Jun Kim, Hyung-Kyu Choi, and
medical devices. http://embedded-computing.com/ Soo-Mook Moon. Evaluation of Android Dalvik virtual
articles/android-rtos-duo-todays-medical-devices/. machine. In Proceedings of the 10th International
[2] .dex — Dalvik Executable Format. http: Workshop on Java Technologies for Real-time and
//source.android.com/tech/dalvik/dex-format.html. Embedded Systems, JTRES ’12, pages 115–124, New York,
[3] dex2jar. http://code.google.com/p/dex2jar/. NY, USA, 2012. ACM.
[4] Real-Time Linux Wiki. [19] Filip Pizlo, Lukasz Ziarek, Ethan Blanton, Petr Maj, and
https://rt.wiki.kernel.org/index.php/Main_Page. Jan Vitek. High-level programming of embedded hard
[5] Roving reporter: Medical Device Manufacturers Improve real-time devices. In Proceedings of the 5th European
Their Bedside Manner with Android. conference on Computer systems, EuroSys ’10, pages
http://goo.gl/d2JF3. 69–82, New York, NY, USA, 2010. ACM.
[6] RTEMS. http://www.rtems.org/. [20] Filip Pizlo, Lukasz Ziarek, Petr Maj, Antony L. Hosking,
[7] Strand-1 satellite launches Google Nexus One smartphone Ethan Blanton, and Jan Vitek. Schism:
into orbit. http://www.wired.co.uk/news/archive/ fragmentation-tolerant real-time garbage collection. In
2013-02/25/strand-1-phone-satellite. Proceedings of the 2010 ACM SIGPLAN conference on
[8] What OS Is Best for a Medical Device? Programming language design and implementation, PLDI
http://www.summitdata.com/blog/?p=68. ’10, pages 146–159, New York, NY, USA, 2010. ACM.
[9] Why Android will be the biggest selling medical devices in [21] Yunhe Shi, Kevin Casey, M. Anton Ertl, and David Gregg.
the world by the end of 2012. http://goo.gl/G5UXq. Virtual machine showdown: Stack versus registers. ACM
[10] B. Buzbee B. Cheng. A JIT Compiler for Android’s Dalvik Trans. Archit. Code Optim., 4(4):2:1–2:36, January 2008.
VM. http://www.google.com/events/io/2010/sessions/ [22] Yin Yan, Sree Harsha Konduri, Amit Kulkarni, Varun
jit-compiler-androids-dalvik-vm.html. Anand, Steven Y. Ko, and Lukasz Ziarek. [technical report]
[11] Alexandre Bartel, Jacques Klein, Yves Le Traon, and RTDroid: A Design for Real-Time Android. http:
Martin Monperrus. Dexpler: converting android Dalvik //rtdroid.cse.buffalo.edu/techreport/rtdroid.pdf.
bytecode to Jimple for static analysis with Soot. In
Proceedings of the ACM SIGPLAN International
Workshop on State of the Art in Java Program analysis,
SOAP ’12, pages 27–38, New York, NY, USA, 2012. ACM.
[12] D. Bornstein. Dalvik VM internals.
http://sites.google.com/site/io/dalvik-vm-internals.