Adroitness: An Android-based Middleware for Fast Development of High-performance Apps

by   Oscar J. Romero, et al.
Carnegie Mellon University

As smartphones become increasingly more powerful, a new generation of highly interactive user-centric mobile apps emerge to make user's life simpler and more productive. Mobile phones applications have to sustain limited resource availability on mobile devices such as battery life, network connectivity while also providing better responsiveness, lightweight interactions within the application. Developers end up spending a considerable amount of time dealing with the architecture constraints imposed by the wide variety of platforms, tools, and devices offered by the mobile ecosystem, thereby diverting them from their main goal of building such apps. Therefore, we propose a mobile-based middleware architecture that alleviates the burdensome task of dealing with low-level architectural decisions and fine-grained implementation details. We achieve such a goal by focusing on the separation of concerns and abstracting away the complexity of orchestrating device sensors and effectors, decision-making processes, and connection to remote services, while providing scaffolding for the development of higher-level functional features of interactive high-performance mobile apps. We demonstrate the powerfulness of our approach vs. Android's conventional framework by comparing different software metric



There are no comments yet.


page 1

page 2

page 8


DELTA: Data Extraction and Logging Tool for Android

In the past few years, the use of smartphones has increased exponentiall...

Seamless Resources Sharing in Wearable Networks by Application Function Virtualization

The prevalence of smart wearable devices is increasing exponentially and...

Architectural Middleware that Supports Building High-performance, Scalable, Ubiquitous, Intelligent Personal Assistants

Intelligent Personal Assistants (IPAs) are software agents that can perf...

Studying Eventual Connectivity Issues in Android Apps

Mobile apps have become indispensable for daily life, not only for indiv...

A Framework for Android Based Shopping Mall Applications

Android is Google's latest open source software platform for mobile devi...

Smartphone-based Home Robotics

Humanoid robotics is a promising field because the strong human preferen...

Software Micro-Rejuvenation for Android Mobile Systems

Software aging – the phenomenon affecting many long-running systems, cau...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Mobile devices, services, and applications have been broadly adopted in everyday activities by users ranging from the business to entertainment domains with increasing demand. Mobile devices come with many a challenge such as limited resources (battery life, network connectivity etc), extending challenge to provide better responsiveness has become the quintessential goal for application architects, developers. [42] This ongoing evolution of mobile computing has led developers to develop larger, complex applications that increase the need for methods of reducing software complexity for developing large-scale mobile apps.  [11]. The Android Platform, the most used mobile platform by developers and users [15], provides a software stack comprising of several app building blocks that allow development of production-quality apps. Developing an Android app involves frequent implementation of new app features, app feature enhancements, fixing domain-specific bugs, refactoring, code clean up activities which constitute 48% of total development activities of a typical Android developer. [33] Additionally, consistently keeping up with frequent Mobile platform-level changes and also developing apps for other Mobile platforms only increases the development challenges.[23] However, acquiring a deep and proper understanding of the Android SDK requires a considerable amount of time for developers (approximately 2+ years [21]) due to the inherent complexity imposed by the over-engineered Android Java Framework (AJF), thereby deviating developers from their main goal: developing robust, interactive, high-performance, production-quality mobile apps. A common way to deal with AJF’s complexity is the use of application framework middlewares. These distinguish from Android’s native middleware which sits between the specialized Dalvik VM and the operating system layer and includes libraries for many functions including but not limited to data storage, graphics rendering, and web browsing that are compiled to machine language. Such an application framework middleware abstracts the underlying complexity of the development environment and masks the heterogeneity of networking technologies to facilitate app programming [36]. Although there exist several such middlewares for Android that range from incorporating context awareness, application awareness, and user awareness including user preferences and behavioral history, they have a significant performance footprint, imply that developers learn additional and complex architectural models yet fail to reduce app development complexity.

Fig. 1: Android Java Framework (AJF) vs. Adroitness Architectural Model

In this paper, we present ADROITNESS, an Android-based middleware architecture that (i) simplifies the implementation of interactive apps by providing programming abstractions from low-level Android app building blocks, (ii) provide a paradigm to avoid writing hundreds of lines of boilerplate code for each new application, and (iii) improve performance of already developed apps by minimal refactoring while meeting certain architectural significant requirements. In section II we present our motivation for this work related to existing work, in section III we present our architectural model that underlies the development of the proposed Android-based middleware; in section IV we describe the implementation details of the middleware; in section V we present a comparison between our approach and the Android app building blocks as in AJF which is currently used by most developers, and in section VII we summarize our conclusions and present future directions on our research.

Ii Motivation

Ii-a Issues with Android Java Framework (AJF)

One of the main issues with Android is that it imposes some design and implementation constructs for components to interact with each other, so the resulting apps becomes top-heavy and over-engineered. Another issue with Android is its concurrency architecture, where invoking a simple network request can be a minefield of subtle problems for which even developers with substantial mobile and Java experience may not be prepared [28]. To illustrate these issues, lets consider an app that sends a network request to a remote service. This simple action spawns several architectural considerations that have to be addressed: 1) Android modifies the user interface and handles input events from one single thread (the main thread) so any task that occupies it for any significant period of time will cause the UI (Android Activity) to become unresponsive; 2) the background tasks should be performed using any of the following Android components: a Handler (it provides a channel to send data to the main thread), an AsyncTask (it manages short background asynchronous operations that run on a different thread, so developers would have to deal with thread-safe references and synchronization), a Service (it has to spawn its own thread in which to do long-running work), or a Java Thread (in this case developers are completely responsible for managing the concurrency). The decision of which kind of component to use depends on several criteria, imposing strong constraints that cannot be verified automatically, e.g., is the background process tied to the UI? is this a long-lasting process? can the process be affected by the activity’s lifecycle? is the process shared by multiple components? 3) Android Services define cumbersome mechanisms to communicate with each other, e.g., it is necessary to implement Handlers, ServiceConnections (an interface for monitoring the state of a Service), Messengers (implementation of message-based communication across processes), Intents (an abstract description of an operation to be performed), IPC (inter-process communication) etc.; and 4) Services and Activities can share data across process boundaries by passing Bundles, objects that implement Serializable or Parcelable interfaces. This process of continuous serialization/deserialization has a significant performance footprint and requires developers to manually parse all the content of these bundles.

Ii-B Requirements:

Our work mainly focuses on the following requirements:

  1. the middleware should significantly decrease the amount of effort (person/day) and functional size in comparison to an app developed using the AJF.

  2. it must be latency-sensitive, more specifically, responses should not take longer than 100ms (events that complete in 100ms or less are believed to have imperceptible latency and do not contribute to user dissatisfaction [38]).

  3. it must abstract away the complexity of underlying layers (e.g., communication, concurrency, etc.).

  4. it must provide mechanisms for developers to make their apps more modular, pluggable, and easily extensible.

  5. it must provide any kind of mechanism for reasoning over the data collected by the smartphone’s sensors and services.

Iii Adroitness Architectural Model

Figure 1 illustrates an architectural model comparison between AJF vs. ADROITNESS in the development of a conventional mobile app. In Figure 1.a, we have identified 6 different scenarios for Activities and Services to communicate with each other: A) the Service is merely a local background worker running in the same process as the Activity, so developer has to create a Binder class and return it to the Activity so it In ADROITNESS, developer need to simply have to extend from ADROITNESS’s GenericService, which abstracts away the Android Service implementation, and hence enables developer to focus business logic, feature implementations. III-B B) the Activity uses an AsyncTask to perform background operations and publish results on the UI thread without having to directly manipulate threads and/or handlers; ADROITNESS uses service-oriented architecture combined with Message Broker and Resource Locator via Channel Adapters to interact between Activities and Services. C) Both Activities and Services communicate to each other by sending and receiving broadcast messages through a BroadcastReceiver; ADROITNESS, as we describe in III-C, developer need not worry about AsyncTask or publish results per se. ADROITNESS uses event-based mechanism to communicate between services and subscribers. D) Activities need to interact with Services running on different processes or apps using IPC, so in this case the developer instantiates the Messenger class inside the Service and defines a Handler that responds to different types of Message objects, also, this Messenger shares an IBinder with a ServiceConnection object, allowing the Activity to send commands to the Service using Message objects; ADROITNESS uses service-oriented architecture combined with Message Broker and Resource Locator via Channel Adapters to interact between Activities and Services. E) the Activity interacts with a Remote Service using AIDL (Android Interface Definition Language) where a RemoteService.Stub object returns an instance of the RemoteService to the ServiceConnection so it can then register callbacks that will monitor the service, then a handler is used to send/receive message objects that implement the interface Parcelable which is used for marshalling purposes; and

Additionally, ADROITNESS implements clean concurrency, without any overengineered Android Framework Api, by using pure thread based model. III-D F) an Activity needs to read data from built-in sensors (e.g., Accelerometer) so it connects to a Service that implements the SensorEventListener, then it gets an instance of SensorManager to register itself and starts listening to particular sensor events. It is worth noting that these scenarios are even more complex since they require additional effort that we have omitted for the sake of simplicity (such as registering Services and BroadcastReceivers on AndroidManifest, allowing permissions, access to native libraries and hardware, etc.).

ADROITNESS implements sensors that make external changes and uses effectors that performs actions. ADROITNESS abstracts away higher order functions to implement real-time scenarios such as detecting free-fall of phone. On the other hand, as we highlight the differences between AJF and ADROITNESS, ADROITNESS abstracts away the complexity of these 6 scenarios and simplify them to a single mechanism that connects Activities to the underlying Services, Sensors and Effectors (SSE) through a middleware layer that exposes only specific behavior to subscribe, post and receive messages to/from those components. Using the Clean Architecture principles for better separation of concerns and better modularization, ADROITNESS allows to decouple the system into well-defined layers such as Presentation layer (i.e., Activities, GUI), Domain layer (i.e., business objects and rules) and Middleware layer (i.e., SSE). The Middleware is divided into four sub-layers: 1) a set of controllers that orchestrate the operation of SSE; 2) a Resource Manager that serves as a service discovery mechanism, resource locator, and dependency injector; 3) a Decision Rule Engine that creates synergies (rules) among those SSE; and 4) a communication layer composed by a Message Broker component and multiple Channel Adapters. This layer uses minimal android dependencies, meaning that no Handlers, AsyncTasks, Messengers, BroadcastReceivers, Binders, nor ServiceConnections are used, instead, a lightweight but yet powerful concurrency and communication model is proposed, as described in further sections. It is worth noting that the only dependency between app GUI (Activity) and ADROITNESS on the class diagram in Figure 2 is the MessageBroker, this centralization reduces complexity and increases maintainability.

Fig. 2: Adroitness Class Diagram.

Iii-a Sensing and Acting

Sensors allow ADROITNESS to detect external changes (e.g., variation in acceleration), user’s events (e.g, gestures), and events among phones (e.g., phone1 notifies its proximity to phone2); whereas Effectors perform actions as the result of making a decision (e.g, make a phone call). ADROITNESS extends the Android SensorFramework (as described by scenario F in Figure 1

.a) and adds high-order functions while abstracting away the atomic operations, e.g., the Accelerometer sensor is equipped with a mechanism for detecting free-fall so developers do not need to check whether the phone’s 3-axis vector sum is equal to 0.

Iii-B Service-Orientation

Since sensors’ and effectors’ extensibility is limited by phone’s hardware, we enhanced them by using ADROITNESS Services (which extend Android Services), that is, application components that perform discrete functions either locally (in the phone) or remotely (on a server). Due to services extend far beyond the scope of phone’s built-in sensors and effectors, they can be considered as cyber-sensors/effectors. ADROITNESS was designed based on a Service-Oriented Architecture (SOA) in order to promote loose coupling between services. We defined a Resource Manager pattern in charge of: 1) maintaining a service registry which contains information about how to dispatch requests to services; 2) carrying out service discovery operations by using a resource locator pattern; 3) registering pluggable services that can be added or removed dynamically by using dependency injection; and 4) executing a Service Manager that controls the services lifecycle (start, destroy, bind, etc.). Our SOA architecture is empowered by the use of an event-driven mechanism that allows fast decoupled interaction between Android Services and Activities. ADROITNESS provides a set of pre-defined pluggable services (e.g, weather, calendar, email, Automatic Speech Recognition – ASR, access to Knowledge Bases, just to name a few, but developers can extend this set of services and add customized services that can be hooked into the middleware.

Iii-C Messaging and communication

Iii-C1 Message Broker

ADROITNESS’s architecture uses a Message Broker, an enterprise integration pattern that can negotiate and facilitate communication between a highly encapsulated set of services and UI components. It is in charge of routing, transforming, aggregating and decomposing messages. Using this pattern, our middleware provides a high level of abstraction, making transparent the communication between activities and services, that is, developers do not have to know the low level implementation details to interact with services, they only have to create a message broker request (MBRequest) instance and pass it to the message broker, then it will deliver the request to the corresponding service. This approach allows a clean way to maintain the code since all the interaction between components is centralized in the message broker. Finally, the message broker uses an event bus to communicate with services and activities through a publish/subscribe mechanism.

Iii-C2 Channel Adapter

A Channel Adapter acts as a messaging client to the messaging system and invokes ADROITNESS functions via a service-supplied interface. This way, any service can connect to the messaging system and be integrated with other services as long as it has a proper Channel Adapter.

Iii-C3 Messaging Gateway

We used a Messaging Gateway to encapsulate messaging-specific code and separate it from the rest of the ADROITNESS code. This way, only the Messaging Gateway code knows about the messaging system; the rest of the middleware code does not. This pattern allows ADROITNESS to communicate with external applications using a broad variety of protocols (i.e, http, tcp sockets, rtsp, etc.) and data formats (e.g., json, xml, protobuffs, etc.). Figure 3 depicts a simplified sequence diagram where the flow of messages within our middleware’s components can be seen.

Fig. 3: Sequence Diagram for end-to-end message passing.

Iii-D Concurrency

In order to improve ADROITNESS’s latency footprint, throughput and interactivity, we defined a clean concurrency model that, on the one hand, radically eliminate the use of overengineered Android Framework constructs such as Handlers, AsyncTasks, ServiceConnections, Messengers, etc. and replace them with a pure Thread-based model that uses thread pools and async executors, being consistent with the clean architecture’s principle that say: “Architecture is About Intent, not Frameworks” [26]; and on the other hand, uses a message-passing mechanism (the event bus) in order to pass messages between threads instead of sharing or accessing objects simultaneously, that way it is not necessary to protect the code by using locks, monitors and synchronized blocks that are computationally expensive.

Iii-E Pluggability and Extensibility

Services are plug-in components based on a set of reusable contracts (interfaces) that are agreed to by developers so that these services can interoperate and reduce the development burden of common tasks. Each service component implements a common interface, with a uniform way to reference entities inside different components and across different naming schemes. For instance, take a look at the structural view on Figure 4. As you can see, there exist two implementations for the ASR (Automatic Speech Recognition) service component, one that runs on the phone (local) and one that runs on the server (remote). These two components realizes the common interface ASR_Interface, which defines all the methods that both components have to implement. None component connects directly to another component, they do through interfaces. The ResourceManager dynamically bind a call against an interface to a specific implementation of the service at runtime based on the receiving parameters. This interface-centric design allows ADROITNESS to be scalable and extensible. By letting each service component have multiple interfaces, we reduce the dependency of any one component on irrelevant features of another service component that it connects with. Also, adding new services incrementally can be accommodated more easily: developers can introduce new service components and add the relevant interfaces to existing ones. Different services can simply plug together, via defined interfaces for their services, to build higher-level behaviors (as we will explain in section III-F). This makes it easier to replace or upgrade parts; if CS components support the same (or compatible) interface, one part can be replaced by another.

Fig. 4: Simplified Component Diagram for ASR Service.

Iii-F Decision Rule Engine

The Decision Rule Engine (DRE) is a rule-based system in charge of creating, validating, executing and specializing rules created by the user or developers. The DRE extends the

ADROITNESS’s scope by aggregating different SSE, that is, services that can accomplish more complex processes and provide higher-level abstractions that allow developers to easily assemble entire use cases and interactions. DRE is composed of a rule base (knowledge base); an inference engine in charge of the decision-making/reasoning loop that consists of three steps: matching the rule’s left-hand sides against the contents of a working memory, determining the rule that must be chosen for execution through a conflict-resolution mechanism, and triggering the actions of the rule selected by the conflict-resolution mechanism; an a working memory that temporarily stores the content of partial solutions and the information provided by sensors and services. A Rule is formally defined as a set of conditions so that <left-side><operator><right-side> and a set of actions so that <event-action>:<component>: <method>:<params>. The DRE extends the ADROITNESS’s services scope by aggregating different services, sensors, and effectors, producing Composite Services as a result, that is, services that can accomplish more complex processes and provide higher-level abstractions that allow developers to easily assemble entire use cases and interactions.

1RULE: Rule1
2  IF      Event.what equals Sensor.MIC.recording
3  THEN : Service.ASR.process : [MIC.bytes] AND
4 : Service.NVB : processAF : [MIC.bytes]
5RULE: Rule2
6  IF      Event.what equals Service.ASR.response
7  THEN : Service.NLU : getIntent : [ASR.utterance]
8RULE: Rule3
9  IF      Event.what equals Service.NLU.intent
10  THEN : Service.DM : getIntent : [NLU.intent]
11RULE: Rule4
12  IF      Event.what equals Service.DM.intent
13  THEN : Service.NLG : realize : [DM.intent]
14RULE: Rule5
15  IF      Event.what equals Service.NLG.utterance
16  THEN : Service.TTS : realize : [NLG.utterance]
Listing 1: Rules for a conversational interaction

For instance, the five rules on Listing 1 represent a scenario for voice-based (conversational) mobile app, where: Rule1 is activated when the microphone sensor is recording user’s voice and then triggers 2 services, the ASR and the Non-Verbal Behavior (NVB) that analyzes user’s acoustic features (e.g., pitch, shimmer, jitter, etc.); Rule2 invokes the NLU (Natural Language Understanding) service when it receives the ASR response, that is, user’s utterance transformed into text; Rule3 triggers the Dialog Manager (DM) service when the NLU has provided the intent; Rule4 invokes the NLG (Natural Language Generator) service once the DM has generated the system intent; and Rule5 synthesizes the utterance generated by NLG by triggering the TTS (Text-To-Speech) service. All this interaction is supported by an event-based mechanism. Rules do not make reference to specific component implementations (sensors, effectors, or services) but to generic contracts, that is, any component can be easily replaced by another component that accomplishes with the same contract. However, developers can add behaviors to reflect constraints, e.g., on Listing 2, when the microphone sensor starts recording, the DRE validates whether the WiFi network is off, if so, it will use an ASR implementation that runs locally and does not need internet connection (e.g., PocketSphinx), otherwise it will use a remote ASR (e.g., Google ASR).

1RULE: Rule1
2IF  Event.what equals Sensor.MIC.recording THEN
3  IF   WiFi.turnedOn equals false
4  THEN : Service.ASR : process : [ASR.Local,MIC.bytes]
5  ELSE : Service.ASR : process : [ASR.Remote,MIC.byte]
Listing 2: Rules for ASR activation

On Listing 3, we present a case where Rule1 is activated when DRE receives an event from the Facial Recognition (FR) service (given that camera sensor was previously activated), then it triggers the Emotion Recognition (ER) service, that in turn activates Rule2 which validates whether the inferred user’s emotion is SAD; if so and if news service is running then the news feeds will be filtered to present only encouraging news (discarding disasters news, etc.), otherwise, if the Movie Recommendation (MR) service is open then it will rank the movies and recommend comedies first.

1RULE: Rule1
2  IF    Event.what equals Service.FR.response
3  THEN : Service.ER.process : [Service.FR.AU]
4RULE: Rule2
5  IF    Event.what equals Service.ER.response
6  AND   Service.ER.Emotion equals Emotion.SAD
7  THEN UserModel : setEmotion : [SAD]
8RULE: Rule3
9  IF      UserModel.emotion equals SAD
10  AND     Service.NEWS.isOpen equals true
11  THEN : Service.NEWS : filter : [NEWS.Encouraging]
12RULE: Rule4
13  IF      UserModel.emotion equals SAD
14  AND     Service.MR.isOpen equals true
15  THEN : Service.MR : recommend : [MR.comedy]
Listing 3: Rules for creating composite behaviors based on FR and ER

Allowing users and developers to create rules that capture the behaviors they would like the phones to exhibit is not a new contribution, existing mobile applications such as IFTTT (IF This Then That [32]) allow end-users to create simple IF-THEN rules that link a set of triggers (e.g., sensors and web services) with specific actions (e.g., effectors and services). However, IFTTT only allows creating simple rules composed by one single condition and one single action, which results very limited when developers need to aggregate multiple sensors and services, which in turn may trigger multiple actions. Our DRE addresses this issue.

Iv Implementation

ADROITNESS’s implementation is a mixture of an in-house development111See our GitHub repo: and the extension of third-party libraries such as GreenRobot’s EventBus framework [18], Google’s Guava library, ZMQ and AWARE framework.

Iv-a Event-based Communication

MessageBroker component extends GreenRobot’s EventBus framework [18], an Android optimized event bus that simplifies communication between Activities, Fragments, background Threads, Services, etc. by decoupling event senders and receivers, removing dependencies, and using a publisher/subscriber pattern for loose coupling. We extended GreenRobot Event Bus source code by adding new communication patterns such as Request/Response, Pair, and Router/Dealer. This allowed us to dispatch the events faster and avoid an additional logic necessary to filter the subscribers. We added an event-based mechanism also to intercept all message-passing so the Decision Rule Engine can make decisions based on message content.

Iv-A1 Caching

Android uses various techniques to share objects across services and activities such as SharedPreferences, Intents and Serializable/Parcealable Bundles. The potential disadvantages of these mechanisms are that they are computationally expensive transformations for serialization/deserialization that lead to an increased CPU processing for real-time transformations. We used Google Guava LRU (Least Recently Used) cache memory which holds object references in the memory without serializing/deserializing them. LruCache is thread-safe, improves the latency and reduces the time to access shared objects.

Iv-A2 ZMQ messaging

We used ZMQ messaging framework for communication with external servers. ZMQ is a high-performance asynchronous messaging library aimed to be used in distributed and concurrent applications with minimal latency footprint. Using this library, ADROITNESS guarantees extremely low-latency responses, even when external servers, thanks to it access sockets directly. Using ZMQ, we could abstract away low-level communication details, such as dealing with different socket types, connection handling, framing, and even routing, so developers who is implementing a mobile app doesn’t have to take care about communication issues.

Iv-A3 Access to Sensors and Effectors

In order to abstract away details about how to access device’s sensors and effectors, we extended the pool of plug-ins provided by AWARE [14], a middleware dedicated to instrument, infer, log and share mobile context information by capturing hardware-, software-, and human-based data. For instance, AWARE provides an effector for processing TTS outputs, however, it lacks of a sensor for processing ASR inputs. ADROITNESS not only includes an effector for TTS but also provides a extensible API that allows to plug different kind of ASR implementations (e.g., Google Cloud ASR, Microsoft Bing Recognizer, CMU Pocket-sphinx, etc.) as well as an efficient streaming effector that streams out audio/video bytes to a remote server using RSTP (Real-Time Streaming Protocol) for those cases where user’s audio features (e.g., pitch, jitter, shimmer, etc.) are processed in the server-side. Another example of how we extended AWARE is the LocationPlugin, which adds an abstraction layer on top of Google Fused Location, an energy efficient API that intelligently combines different signals (GPS and WiFi) to provide the location information needed. ADROITNESS adds another abstraction layer on top of AWARE LocationPlugin (i.e., it exposes the same functionality to developers but using less code) and extends its functionality by keeping a location history (useful when no signal is available so the most recent location is used, or when some kind of inference based on regularities is required). Furthermore, ADROITNESS uses Yahoo WOEID (Where On Earth ID) which provides additional information such as locality, timezone, county, town, state, etc.

V Evaluation

In this section we present an empirical metric-based comparison between ADROITNESS and the Android’s Java Framework (AJF). We compared both approaches in the implementation of a conversational intelligent personal assistant that generated different kind of recommendations (e.g., movies, news, etc.) while keeping user’s engagement through social dialogue. The ADROITNESS approach was equipped with 7 different services: (Google ASR, Multisense for non-verbal behavior recognition [39], Microsoft NLU, NLG [27] , a Social Intention Recognizer (SIR) [43], a Social Reasoner (SR) for making decisions about conversational strategies [35]), and a Movie Recommendation System (MRS). For AJF we used 6 android’s components: an “Activity” for the UI, a “Service” which connects to external servers, a “ServiceConnection” that monitors the service’ state, an “AsyncTask” to perform background operations, and a “Messenger+Handler” to allow message-based communication across processes (see Figure 5).

Fig. 5: Test Scenario for Adroitness vs. AJF

V-a Measuring Latency and Performance

In order to measure the latency of both ADROITNESS

and AJF, we conducted 15 experiments classified in 3 categories (Hardware configuration: XIAOMI Mi4C Smartphone, Android 5.1, Snapdragon 808, 64-bit Hexa Core 1.44GHz, and 16GB ROM.): using 1, 5 and 10 services. For each group, we collected data for sending/receiving 1, 10, 100, 1,000, and 10,000 messages. For latency experiments, we measured the time for sending and receiving 1,

, , and

messages. Each experiment was performed 10 times and then their harmonic mean was calculated, as shown in table


. Finally, a performance improvement rate between both approaches was estimated using the equation:

. In general, ADROITNESS’s performance surpassed AJF’s performance in a high rate when sending/receiving 1 message () and then gradually decreased while the number of messages increased. It is worth noting that the performance rate was improved even more by our middleware when the number of services raised, and this pattern repeated across the experiments from 1 to 10K messages. For instance, when sending 10K messages using 1 single service, the difference between both approaches was almost insignificant (0.3%), whereas when using 10 services to send 10K messages each one, ADROITNESS improved the performance at a rate of up to . Finally, we ran a one-way ANOVA test to analyze the difference among the means of the 2 groups of data (ADROITNESS vs. AJF), and given that the obtained p-value was less than the significance level () then we could conclude that there was a statistically significant difference between the 2 groups. The performance experiments revealed a clear correlation between the number of services and the performance rate: the more services were running simultaneously the better ADROITNESS performed. This is due to the multiple optimization levels of concurrency and communication among components: we drastically reduced the message-passing latency by using low-level thread manipulation and object caching instead of using Android-based components for communication (e.g., handlers, asynctasks, etc.) and for object-passing (e.g., serialization/deserialization of SharedPreferences and bundles)

Metric 1 Msg. 10 Msg. 100 Msg. 1K Msg. 10K Msg. ADR 1S (ms) 1.3 14.4 104.4 671.2 5,337 AJF 1S (ms) 26 124 157 730 5,323 Perf. Rate (%) 95 88.4 33.5 8.0 -0.3 ADR 5S (ms) 18.6 162.7 765.5 4,594 48,556 AJF 5S (ms) 235 537 1,664.3 10,995 9,3343 Perf. Rate (%) 92.07 69.7 54.01 58.22 47.98 ADR 10S (ms) 18.9 405 2,204 16,810 17,9289 AJF 10S (ms) 631 1,523 5,196 37,696 38,7610 Perf. Rate (%) 97 73.4 57.6 55.4 53.7
TABLE I: Latency Comparison. ADR = Adroitness, 1S = 1 service

V-A1 Measuring Abstraction, Pluggability and Extensibility

Quantitatively measuring software abstraction seems to be a non-trivial task. There exist different approaches in this regard, but the general consensus is that the more abstract an application is, the less complex and effort-consuming its development is [16, 10]. So our initial hypothesis was: ADROITNESS should significantly decreased the complexity, size and effort to build the proposed scenario in comparison with AJF. We used the Cyclomatic Complexity metric (CC), which is defined as the number of linearly independent paths within a graph that represents the source code flows, and is calculated as: , where is the number of edges of the graph, is the number of nodes, and is the number of connected components [41]. Based on our analysis of measurements on Table II, we deduced that both ADROITNESS and AJF have low complexity (according to [41] high complexity is over 15), however, the improvement rate demonstrated that ADROITNESS reduces the complexity on in comparison with AJF. We also measured the level of abstraction in terms of the minimum amount of implementation details that were exposed to the developer without loosing information content (the lesser exposed the most abstract). To this purpose, we used two MOOD metrics (Metrics for Object Oriented Design) [1]: the Method Hiding Factor (MHF) and the Attribute Hiding Factor (AHF) which were calculated across all classes in the system. It is worth noting that while our approach improved method hiding in a , it only improved attribute hiding in a , which is not particularly a significant difference, and this is due to we focused on creating high-level abstraction methods/classes while keeping the same attributes on both apps. In terms of size metric, we used Function Points (FP), a widely accepted industry standard (ISO/IEC 20926:2009) for functional sizing222Lines of Code is often criticized as ambiguous and meaningless [10]. FP are units of measurement that express the amount of business functionality that an information system provides to a user. FP are estimated in terms of both data and transaction functions. As data functions, this metric estimates the amount and complexity of Internal Logical Files (ILF) and External Interface Files (EIF), and as transaction functions it estimates External Inputs (EI), External Outputs (EO) and External Inquiries (EQ). The corresponding FP’s for each function have associated a complexity measure that can be Low (L), Average (A) or High (H). Based on the results presented on Table II, we could observe that the main difference between both implementations was an increment of 5 FPs (for transaction functions) in AJF, which means that our approach reduced the amount of transactional functionality to be developed in %. These difference of 5 FP’s, when multiplied by the functional complexity factor (Low = 7), represents a 45% of the total FP’s for AJF, whereas it represents only a 23% for ADROITNESS. The Total Function Point measure (TFP), which represents the total number of FPs after applying both an adjustment and a calibration factor, reflects that the whole app is smaller in functionality 333This means that less functionality has to be implemented to meet the same system’s requirements, e.g., using reusable GUI components considerably reduces the amount of functionality to be implemented. when using ADROITNESS instead of AJF, which in turns represents a drop in effort in the same proportion.

Fig. 6: Code snippet for an end-to-end conversational interaction using ADROITNESS. developers only had to write lines of code (loc) for a two-step use case realization (i.e., in the 1st step, ASR is started on method onCreate and then, in the 2nd step, a NLG event that contains the utterance generated by the server is handled by onEventMainThread method), in comparison with more than 750 loc that the developers had to write in AJF for the same use case.

The Effort Person/Day (EPD) estimation is computed as , where DR is the delivery rate (in average, an android developer can implement 10 FPs per month [22]) and DPM is days per person-month (21.5 business days per month). EPD can be better understood in terms of time and number of persons required to develop the app, let’s say we have a team of 5 persons, using the AJF it would take 54.6 days (273.05/5) while using ADROITNESS would take 25.8 days (129/5), which means a reduction of of the required effort when using our approach (Figure 6 shows a code snippet to illustrate how effort is decreased by hiding low-level implementation details). However, our empirical study revealed that development effort can be reduced more than 60% when using our middleware, and this discrepancy with EPD may be due to unconsidered elements during the estimation.

Metric ADR AJF Improv. Rate
CC 1.2 1.7 29.55%
MHF (%) 42.04 23.53 78.67%
AHF (%) 97.79 93.33 4.78%
ILF + EIF (FP) 9 9 0%
EI + EO + EQ (FP) 9 14 35.71%
TFP (FP) 60 127 52.75%
EPD (person/day) 129 273.05 52.75%
CBO 2.99 3.18 5.97%
CF (%) 9 23.33 61.42%
LCOM 0.53 1.98 73.23%
TABLE II: Metrics Comparison of Adroitness (ADR) vs. AJF.

Measuring pluggability and extensibility can be achieved by calculating the amount of coupling and cohesion in the system: the more loosely-coupled and high-cohesive the system is the more pluggable and extensible is. For this comparison we used 3 different metrics [9]

: Coupling between Object classes (CBO), Lack of Cohesion methods (LCOM), and Coupling factor (CF). In CBO, two classes are coupled when methods declared in one class use methods or instance variables of the other class; LCOM defines the number of different methods within a class that reference a given instance variable; and CF is the ratio of the maximum possible number of couplings in the system to the actual number of couplings not imputable to inheritance. The results of the measurements using these metrics are presented in Table 

II. According to [9] a CBO 14 is too high, so the measurements suggest that both approaches have loose coupling, however, using CBO we could not conclude whether ADROITNESS significantly improved the amount of coupling (it was only ), so we run the second metric for measuring coupling (CF) and we obtained a more significant difference between both approaches, this time, ADROITNESS reduced the coupling between classes at a rate of . Also, CF should not exceed 12% [9] so AJF seems to be highly coupled (23.33%) in comparison with our middleware (9%). The main reasons why our approach lessen coupling are the use of dependency injection patterns and event-driven communication instead of direct invocations to classes. In LCOM metric, a result equals to 0 indicates a cohesive class, higher than 0 indicates that the class needs or can be split into two or more classes, since its variables belong in disjoint sets. Therefore, the results suggest that both approaches have certain lack of cohesion, however, ADROITNESS seems to be more cohesive than AJF. The main reason of this improvement is due to the architectural class decomposition into high-cohesive classes with a clear separation of concerns (e.g., communication, service discovery, reasoning, etc.). All the presented metrics are, in some way, biased and extremely sensible to the style of programming or errors during estimation, however, we fairly reduced the latter by using a reliable tool such as MetricsReloaded  [29].

Vi Related Work

In this section, other work regarding the use of middleware on mobile operating systems is reviewed with respect to the requirements given in SectionII. Besides, aforementioned AJF and ADROITNESS specifications, architectural differences and evaluation, we categorize Middleware architectures into 3 categories:

  1. Cross-platform Middleware

  2. Component-Oriented Middleware

  3. Agent-Oriented Middleware

  4. Other types of Middleware

Vi-a Cross-platform Middleware

There are many 3rd party libraries and frameworks for Android indicating that the standard Android APIs are inadequate [6]. One alternative is to use cross-platform (hybrid) mobile frameworks based on web technologies (JS, HTML, CSS). Cross-platform frameworks provide support to scripting languages such as JavaScript, TypeScript or Angular (e.g., Facebook ReactNative[13], NativeScript[31] and Xamarin[30]) and some others use a web engine to render elements such as HTML5, CSS, and SVG, and execute the logic in a browser instance (e.g., JQuery Mobile[JQueri:2018], TheAppBuilder[40], and Apache PhoneGap[5]). Using cross-platform frameworks has advantages such as code sharing between the web and the app, leveraging developers current web language skills, and a plenty of open-source tools available. However, there are some disadvantages regarding fragmentation, compatibility, performance, UX issues, and memory, because they use a full web-rendering engine loaded just for the app and take a lot of GPU/CPU resources increasing the app’s response time [24].

Vi-B Component-Oriented Middleware

Component-oriented middleware realizes the idea of interchangeable and reusable software components. They implement a component model, which defines syntax and semantics of component definitions and their relations[20]. Several approaches, all based on OSGi[3], have been proposed for the use on Android devices. Equinox was originally developed to provide a plugin-based architecture for the Eclipse IDE. In the progress of evaluating the application of Equinox on Android devices, necessary changes were added by[19]. For the time being, Equinox does not provide a concept for integrating UI. In consequence, it is uninteresting for many real-world scenarios. The Apache OSGi implementation Felix supports execution on Android since version 1.0.3. It is possible to use the Felix command line shell to add bundles and run console applications, just as with Equinox. Furthermore, Felix can be embedded in Android Apps and executed during the initialization of an app[4]. Based on this approach, Escoffier showed how to create Android apps that dynamically load .jar bundles[12]. The commercial OSGi implementation ProSyst mBS was designed for embedded hardware, and features explicit support for Android devices. As in Felix, application components are deployed as .jar bundles, which has to be implemented using the interface ApplicationFactory instead of Android activities. As opposed to the previously described OSGi implementations, the ProSyst platform is deployed inside a standalone Android application. To launch an individual application, a dummy app is installed on the device, instructing the platform application to load a specific application bundle[2]. This execution model enables sharing of the middleware platform between applications, while keeping the original user experience. Generally speaking, OSGi provides modularity and and pluggability features to Android-based apps, however, these implementations are tightly coupled to the AJF architecture, using Android components such as Activity, Service and Application factories, and Android-based communication protocols (e.g., AIDL – Android Interface Definition Language), producing the same performance issues we described in our motivation section.

Vi-C Agent-Oriented Middleware

Software agents provide a high-level approach to implement complex and concurrent software systems. In order to use such an abstraction, a runtime environment (platform) is required to provide services e.g., for executing or discovering agents. JaCa-Android[37] was specifically developed for Android and combines the Agents and Artifacts paradigm with an agent runtime called CArtAgO[34]. Agents are implemented using Jason, an AgentSpeak implementation[8]. The runtime model is based on embedding the runtime platform into applications, including a central JaCa-Middleware application, which provides several artifacts to enable using services like contact management, localization or SMS from within agents. User interfaces are developed using default Android activities and are represented to the agents as artifacts to enable communication between them. The Agents and Artifacts approach allows for an elaborated integration of agent and Android design principles, but introduces an implementation language that is very different from traditional languages. Another agent-oriented middleware is JADE, which also features an Android version. Jade-Android can either integrate with a back-end or be executed as standalone platform. In any case, the runtime platform is included in applications; increasing the application sizes and loading times[25]. Agents can communicate with Android activities using the Object-to-Agent Interface (O2A). O2A utilizes Android intents sent by agents and received by activities as well as Java interfaces, which are used by activities to call agent methods[7]. The main issue with Agent-oriented approaches is that additional layers have to be embedded into the middleware (in the case of AgentSpeak and JADE, they support almost all the FIPA standard specifications – The Foundation for Intelligent Physical Agents) resulting in a significant performance footprint.

Vi-D Android Architectural Components

Android Architecture Components [17] was introduced by Google Android in order to make make development efforts easier, address limited resources problems of Android devices and developing robust applications. For example life-cycle aware software or ViewModel or LiveData components [17] basically add additional abstraction layers to user interface and data layers. The architecture components do not still address problems of poor concurrent performance, service composition, QoS.

Vii Conclusions and Future Work

In this paper, we have presented an architectural middleware solution that supports the construction of robust, interactive, high-performance, production-quality mobile apps living on Android smartphone devices. Our main contributions can be summarized as follows: a) we used the clean architecture approach to guarantee a better separation of concerns and better modularization; b) we modeled specialized layers and modules with isolated responsibilities; c) the middleware architecture abstracts away the low-level design and implementation details such as communication, concurrency model, event handling, dependency injection, service discovery, among others; d) we improved the way Android Java Framework tackles quality attributes such as latency, extensibility, functional performance, and pluggability; e) latency was improved by avoiding the use of overengineered solutions to communicate Android components (e.g., Handlers, AsyncTasks, ServiceConnections, etc.) and replacing them by a lightweight threading model and a high-performance cache instead of using serialization/deserialization mechanisms; f) the architecture establishes reusable contracts for connecting (plug-in) service components that can be replaced any time; g) we defined a Decision Rule Engine that allows to create rules that binds sensors, effectors and services and facilitates the composition of more complex behaviors by aggregating multiple services; and h) we demonstrated that ADROITNESS reduced the complexity, coupling, size, and effort of mobile apps implementation while improving the performance and cohesion. Our future work will focus on several aspects: we are planning to make our system completely open-source, so the developer and research community can take advantage of the powerfulness of our middleware. The next steps in our development will be to use standards for flexibility, extensibility and pluggability such as OSGi (Open Service Gateway initiative). Also, we have identified the need of creating a semantic layer on top of our middleware in order to improve the service discovery process, provide more accurate and relevant information to higher-level layers, and make inferences about user’s context. Also, we will implement a machine learning mechanism to discover and refine the rules orchestrated by DRE.


The authors would like to thank the anonymous referees for their valuable comments and helpful suggestions.


  • [1] F. B. e. Abreu and W. Melo, “Evaluating the impact of object-oriented design on software quality,” in Software Metrics, 1996.
  • [2] A. Adjaz, S. Bouzefrane, D. Huang, and P. Paradinas, “An osgi-based service oriented architecture for android software development platforms,” ser. CEDRIC, 2014.
  • [3] O. Alliance. (2018, Aug.) The dynamic module system for java. [Online]. Available:
  • [4] Apache. (2015, Nov.) Apache felix framework and google android. [Online]. Available: {}
  • [5] ——. (2018) Apache cordova. [Online]. Available:
  • [6] S. Barnett, R. Vasa, and A. Tang, “A conceptual model for architecting mobile applications,” in Conf. Software Architecture, 2015, pp. 105–114.
  • [7] F. Bergenti, G. Caire, and D. Gotta, “Agents on the move: JADE for android devices.” in WOA, ser. CEUR Workshop Proceedings, C. Santoro and F. Bergenti, Eds., vol. 1260., 2014.
  • [8] R. H. Bordini, J. F. Hübner, and M. Wooldridge, Programming Multi-Agent Systems in AgentSpeak Using Jason (Wiley Series in Agent Technology).   USA: John Wiley &#38; Sons, Inc., 2007.
  • [9] S. R. Chidamber and C. F. Kemerer, “A metrics suite for object oriented design,” IEEE Trans. Softw. Eng., vol. 20, no. 6, pp. 476–493, Jun. 1994.
  • [10] R. Damasevicius, “On the quantitative estimation of abstraction level increase in metaprograms,” vol. 3, pp. 53–64, 01 2006.
  • [11] J. Dehlinger, “Mobile application software engineering: Challenges and research directions,” in Mobile Sw. Eng., vol. 2, 2011, pp. 29–32.
  • [12] C. Escoffier. (2008, Oct.) ipojo on android. [Online]. Available:
  • [13] Facebook. (2018) Facebook reactnative. [Online]. Available:
  • [14] D. Ferreira, “AWARE: a mobile context instrumentation middleware to collaboratively understand human behavior,” Ph.D. dissertation, University of Oulu, Sep 2013.
  • [15] Gartner. (2018). [Online]. Available: ""
  • [16] R. L. Glass, “Sorting out software complexity,” Communications, vol. 45, no. 11, pp. 19–21, 2002.
  • [17] Google. (2017, May). [Online]. Available:
  • [18] GreenRobot. (2017). [Online]. Available:
  • [19] B. Hargrave and N. Bartlett. (2015) Android and osgi: Can they work together? [Online]. Available: {}
  • [20] G. T. Heineman and W. T. Councill, Eds., Component-based Software Engineering: Putting the Pieces Together.   Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2001.
  • [21] INFOQ. (2017). [Online]. Available:
  • [22] ISBSG. (2017). [Online]. Available:
  • [23] M. E. Joorabchi, A. Mesbah, and P. Kruchten, “Real challenges in mobile app development,” in Empirical Software Engineering and Measurement, 2013 ACM/IEEE International Symposium on.   IEEE, 2013, pp. 15–24.
  • [24] J. B. Jorgensen, B. Knudsen, L. Sloth, J. R. Vase, and H. B. Christensen, “Variability handling for mobile banking apps on ios and android,” in 13th IEEE/IFIP Conference on Software Architecture, 2016, pp. 283–286.
  • [25] J. Kalinowski and L. Braubach, “Integrating application-oriented middleware into the android operating system,” UBICOMM 2015, p. 75, 2015.
  • [26] R. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design, 1st ed.   Prentice Hall., 2017.
  • [27] Y. Matsuyama, R. Zhao, O. Romero, and et al., “Socially-aware animated intelligent personal assistant agent.” in SIGDIAL, 2016, pp. 224–227.
  • [28] Z. Mednieks, G. B. Meike, L. Dornin, and Z. Pan, Enterprise Android: Programming Android Database Applications for the Enterprise, 2013.
  • [29] MetricsReloaded. (2018). [Online]. Available:
  • [30] Microsoft. (2018) Visual studio tools for xamarin. [Online]. Available:
  • [31] NativeScript. (2018) Create native ios and android apps with javascript. [Online]. Available:
  • [32] S. Ovadia, “Automate the internet with “if this then that”(ifttt),” Behavioral & social sciences librarian, vol. 33, no. 4, pp. 208–211, 2014.
  • [33] L. Pascarella, F.-X. Geiger, F. Palomba, D. Di Nucci, I. Malavolta, and A. Bacchelli, “Self-reported activities of android developers,” in Proceedings of the 5th International Conference on Mobile Software Engineering and Systems, ser. MOBILESoft ’18.   New York, NY, USA: ACM, 2018, pp. 144–155. [Online]. Available:
  • [34] A. Ricci, M. Viroli, and A. Omicini, “Cartago: A framework for prototyping artifact-based environments in mas,” in Environments for Multi-Agent Systems III, D. Weyns, H. V. D. Parunak, and F. Michel, Eds.   Berlin, Heidelberg: Springer Berlin Heidelberg, 2007, pp. 67–86.
  • [35] O. J. Romero, R. Zhao, and J. Cassell, “Cognitive-inspired conversational-strategy reasoner for socially-aware agents,” in

    26th Int. Joint Conf. on Artificial Intelligence, IJCAI

    , 2017, pp. 3807–3813.
  • [36] Z. Sanaei, S. Abolfazli, A. Gani, and R. Buyya, “Heterogeneity in mobile cloud computing: taxonomy and open challenges,” IEEE Communications Surveys & Tutorials, vol. 16, no. 1, pp. 369–392, 2014.
  • [37] A. Santi, M. Guidi, and A. Ricci, “Jaca-android: An agent-based platform for building smart mobile applications,” in Languages, Methodologies, and Development Tools for Multi-Agent Systems, M. Dastani, A. El Fallah Seghrouchni, J. Hübner, and J. Leite, Eds.   Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, pp. 95–114.
  • [38] B. Shneiderman, Designing the user interface: strategies for effective human-computer interaction.   Pearson Education India, 2010.
  • [39] G. Stratou and L.-P. Morency, “Multisense context-aware nonverbal behavior analysis framework: A psychological distress use case,” IEEE Trans. on Affective Computing, vol. 8, no. 2, pp. 190–203, 2017.
  • [40] TheAppBuilder. (2018) Mobile apps to connect with hard-to-reach people, really easily. [Online]. Available:
  • [41] M. Thomas, “A complexity measure,” in 2Nd International Conference on Software Engineering.   IEEE Computer Society Press, 1976.
  • [42] S. Yang, D. Yan, and A. Rountev, “Testing for poor responsiveness in android applications,” in Engineering of Mobile-Enabled Systems (MOBS), 2013 1st International Workshop on the.   IEEE, 2013, pp. 1–6.
  • [43] R. Zhao, T. Sinha, A. Black, and J. Cassell, “Automatic recognition of conversational strategies in the service of a socially-aware dialog system,” in 17th Annual SIGDIAL, 2016.