2013 IEEE International Conference on Green Computing and Communications and IEEE Internet of Things and IEEE Cyber, Physical and Social Computing
Towards a Modular and Lightweight Model for Android Development Platforms
Mussab Zneika*, Hasan Loulou*, Fatiha Houacine*, Samia Bouzefrane** CEDRIC Laboratory Conservatoire National des Arts et Métiers Paris, France {First_name.Last_name}@auditeur.cnam.fr*
[email protected]** Abstract— With the growing complexity of embedded systems, new development platforms based on modular decoupled components and a pluggable dynamic service design are needed for implementation, and maintenance of heterogeneous mobile applications. As mobile devices have limited resources, these platforms need to be lightweight to achieve required performances. New middleware layers are added to the mobile devices to provide more modularity and loose coupling between components. However, most of these multi-layer designed middlewares are complex and heavy, and need important resources that become the bottleneck for reactive services. This article aims to introduce service oriented approach to integrate modularity and dynamic service management into the mobile Android platform to make the software development adaptive without altering performances. The main contribution of this paper is the establishment of a low level solution incorporating modularity into Android software development platform. The proposed solution is a service-architecture for Android-based applications without adding a multi-layer middleware while maintaining the initial performances. Keywords— OSGi; Component model; Service Oriented Architecture; Android platform
I.
INTRODUCTION
The increasing complexity of the applications in embedded systems and the integration of high-level services within these systems (such as the integration of a Web service in Java Card 3.0 [2] or the proposition of OSGi (Open Service Gateway Initiative) ME [1] for embedding OSGi in sensors) led to the development of new methodologies to reduce the complexity of the software and to supply a support facilitating its re-use. Service oriented approach (SOA) is viewed as a new paradigm to guarantee more control, re-use and reliability of the software. This article focuses on how to convert the mobile Android platforms to a service oriented framework. Many SOA approaches have been presented for mobile phones such as [4, 5 and 6]. However, in previous works, the service notion is synonym of Web services based on SOAP protocol with the objective of securing mobile communications. OSGi was originally designed for machine configurations of high resource footprint [3]. OSGi ME [1] was proposed for constrained embedded systems. Noubissi et al. in [8] address the application of OSGi technology in Java Card platforms. Other solutions based on 978-0-7695-5046-6/13 $26.00 © 2013 IEEE DOI 10.1109/GreenCom-iThings-CPSCom.2013.400
2129
OSGi related to Android platforms are EZdroid project [7] and ProSyst’smBS Mobile SDK [9]. Houacine et al. propose in [10] the establishment of a middleware solution incorporating OSGi Felix into Android software development platform. This solution is based on traditional OSGi bundles where a bundle is the OSGi deployment unit encapsulating services. The bundles defined in ProSyst’smBS Mobile SDK are slightly different from the traditional bundles while the bundles of EZdroid project are identical to traditional OSGi ones but the bundle updates require the recompilation of the EZdroid application. All these solutions try to provide modularity by incorporating frameworks as intermediary layers between the applications and the operation system. Several native packages of the framework are launched on the mobile device before running any application. Unfortunately, this can negatively impacts the end to end applications performances. In addition, with the development of the mobile Operation Systems, a large part of the frameworks functionalities are already available on the mobile OS and need only a modular orchestration. The service duplication introduced by the installed frameworks impact the memory consumption in mobile devices. To address the drawbacks of existing research works, we have proposed a new adaptation incorporating OSGi-based SOA primitives directly into Android OS layer. Hence, modularity and dynamicity are assured without introducing multilayer bottlenecking middlewares. In fact, our methodology defines a new design on Android terminals to manage the life cycle of the services that are used by Android applications. Regarding performance issues, the proposed solution implements a model based on components called Andro-modules, that makes Android operation System layer natively service oriented. In the rest of this paper, we recall briefly in Section 2 the first solution based on OSGi architecture as proposed in [10]. In section 3, we detail the solution we propose in this article to make Android platform more robust by defining a native service model to handle SOA features. Section 4 gives the first experiments that have been carried on. Section 5 concludes the paper.
II.
FIRST SOLUTION: INTEGRATION OF OSGI WITHIN ANDROID PLATFORMS
Before describing our native service model for Android platforms, we recall briefly the solution proposed in [10] to integrate OSGi within Android. For this purpose, we give a brief description of OSGi and Android platforms. A. Description of Android and OSGi Platforms In this section, we describe the principal features of OSGi and Android platforms in order to highlight the differences and to show the contribution of OSGi for Android platforms. OSGi technology [3] allows composing services dynamically for Java-based applications relying on the notion of components. The deployment of these components is called bundles that cover all the bundle-related operations such as, loading, installing, activating, updating, or uninstalling. One major benefit of using OSGi is that these operations are carried out dynamically without restarting the OSGi platform. The platform checks the bundle dependencies (and their versions) before authorizing the activation of an application on which it depends. A bundle is a Jar file that contains a compiled code, resources as well as meta-data. The meta-data is stored in a configuration file called Manifest. This file is necessary to the deployment of the bundles in the OSGi framework as it describes the services provided by the bundle and the required bundles (called dependencies) for its own execution.
Fig. 1.
III.
THE SERVICE MODEL FOR ANDROID PLATFORMS
A. Motivation for a new service based Architecture In the solution briefly described in the preceding section, OSGi Framework has been integrated as a middleware on the mobile OS to bring SOA features such modularity, reusability and dynamic updates. However, this solution shows some drawbacks such as: In the context of a cloud of mobile devices: the interaction of mobile devices using OSGi bundles requires that all the mobile nodes install the OSGi framework previously.
Android is an open source operating system based on Linux and dedicated to mobile phones. The Android platform is organized around various layers like an application layer that supplies standard applications, and a framework layer based on C/C++ libraries that facilitates the application development. Every application runs on a distinct virtual machine called Dalvik Virtual Machine (DVM) to avoid altering the functioning of the other applications. The executable files .dex (Dalvik Executable) are generated from class files. In Android platform, a service is a component that runs in background. It is defined by an “.aidl” specification called Android Interface Definition Language (AIDL), from which a Java interface is automatically generated with an abstract Stub class. B. Android platforms based on OSGi In [10], we choose the Apache Felix platform as implementation of OSGi due to its small size compared to other OSGi implementations. To integrate Felix within an Android platform, we choose to implement Felix as an Android remote service, called AndroLix that extends the android.app.Service class. The access to Felix being made via an RPC communication mechanism, AndroLix provides to clients an AIDL description containing different methods that are implemented by this service. The AndroLix middleware allows the management of bundles’ life-cycle, and calls bundles through the AndroLix AIDL, which is shown Figure 1. The AndroLix methods are designed so that to start Felix, to install, uninstall, start and stop bundles, and allows a dynamic class-loading through the call of bundle services.
Overview of Androlix architecture.
In the context of a local mobile device: the OSGi-based Android is a multi-layer platform. To execute the services of a local bundle, the Android application (apk) triggers a bundle proxy by running Android API, then the proxy asks the OSGi middleware that calls the requested bundle. The bundle seeks for elementary packages of the Java virtual machine, and then the mobile OS layer triggers the physical capacity. These drawbacks introduce at the same time performance impacts and compatibility limitations. Since we want a SOA support for Android, we propose here to adapt the Android platform by implementing analogically to OSGi “bundles” components called Andromodules without adding an OSGi framework (such as Felix) on Android that may alter the performances. B. Andromodule based Architecture As shown in Figure 2, any Andromodule A is a dynamic Android module composed of:
a service interface providing a set of APIs
a service body that is an Android Dalvik Code
and a Manifest file that is an XML file that describes the API and the services offered by the Andromodules on which A depends for its execution.
2130
across Andromodule service providers and decouple services from consumers. The principal functions of the service management system are the following:
Fig. 2.
Andromodule structure.
The Manifest file contains executive and non executive information. The non executive information is related to the version of the Andromodule, to the author and to some other descriptions, while the executive information corresponds to the prerequisite Andromodules, to the services or API publicly available to other Andromodules and to the requirements for minimum performance execution.
installModule(location): installs a module from a specified location and assigns it an ID automatically.
start(Id): It verifies the existence of a module corresponding to the given ID, tries to resolve this module and starts it if it succeeds to resolve it. The moduledependency resolving depends on the information that exists in the XML file. Additionally, it invokes the method activate().
activate(Id): It verifies the existence of a module corresponding to the given ID and registers the service in the registry.
stop(Id): It verifies the existence of a module corresponding to the given ID and stops the service if it is in a start or active state.
uninstallModule(Id): It verifies the existence of a module corresponding to the given ID and uninstalls it if it is resolved or stopped. IV.
Note that the idea of the Andromodule is analogous to the OSGi bundle unit except that the Andromodule is executed directly as a Dalvik code, avoiding the dexification process used in the first solution with Androlix middleware to convert Byte code to DEx code.
FIRST EXPERIMENTS
In this paper, we proposed a native service model to implement embedded framework design across “Andromodules” on Android mobile platforms. To highlight the benefit of our proposed solution, we evaluate the performance of two distinct architectures while measuring in the same conditions the execution time of each life-cycle operation respectively with OSGi-based architecture and with Andromodule-based architecture (see Figure 4).
As shown in Figure 3, the Andromodule based architecture is a lightweight platform in comparison with the OSGi-based architecture because in the former the Android applications interact directly with Andromodules for execution without going through different middleware layers. In addition, the Andromodules are part of the OS modules for which the management is launched upon launching the Android OS. As a consequence, no performance impact on application running.
These two solutions have been tested on an emulator with the following characteristics: Device Nexus S (4.0”, 480 * 800: hdpi)); Android 2.2 – API level 8; Ram 343; VM Heap: 32; Internal Storage: 60; SD card 60 MB.
Fig. 4.
Fig. 3.
Execution Delay.
Figure 4 depicts that Andromodule-based platform is so promising to solve the problems caused by the huge number of bundles’ dependencies, because the operations are executed in few milli-seconds while the same operations take few seconds with OSGi-based platform.
OSGi based Architecture vs. Andromodule based Architecture.
The service management system, implemented as an Android class, includes many methods used to manage the life cycle of the Andromodules and to register and share services
2131
V.
CONCLUSION
We present in this work a new modular design platform for application development. This design is directly implemented on the mobile OS to provide optimal performances. In Android platforms, each application is executed on a distinct Dalvik Virtual Machine. In the opposite, in an OSGi design all OSGi applications run in one shared JVM Java Virtual Machine. In the first case, Android platform has the drawback of components duplication within DVMs. In the second case, with a single VM in OSGi, the classes are shared and for each bundle is associated a distinct class loader that allows selective export of internal packages and selective import of required dependencies, but can also introduce latency in application execution since it requires the launching of many layers ( JVM, OSGi framework (Androlix or Felix …)).
REFERENCES
[1]
Andre Bottaro and Fred Rivard, “OSGi ME - An OSGi Profile for Embedded Devices”, Eclipse Summit, Germany, 2009. [2] Java Card, 2011: http ://java.sun.com/javacard/3.0/ [3] OSGi, 2011: http ://www.osgi.org. [4] Johnneth Fonseca, Zair Abdelouahab, Denivaldo Lopes and Sofiane Labidi, A security framework for SOA applications in mobile environment, International Journal of Network Security and Its Applications (IJNSA), Vol.1, No.3, October 2009. [5] Decker, M, and Bulander, R. "A Platform for Mobile Service Provisioning Based on SOA Integration", In Communications in Computer and Information Science, Vol 23, 2009, Springer Berlin Heidelberg, pp 72-84. [6] Natchetoi, Y. Kaufman, V. and Shapiro, A. "Service-oriented architecture for mobile applications", Proceedings of the 1st international workshop on Software architectures and mobility / International Conference on Software Engineering, pp 27-32, 2008. [7] EZdroit project, 2011 : http://www.ezdroid.com/ [8] Agnes C. Noubissi, Julien Iguchi-Cartigny and Jean-Louis Lanet, Convergence OSGi-Java Card : Fine-grained dynamic update, Esmart10, 21-24 September 2010, Sophia Antipolis France. [9] ProSyst, 2011 : http://www.prosyst.com/index.php/de/html/content/49/mBS-Mobile-forAndroid/ [10] Fatiha Houacine, Samia Bouzefrane, Li Li and Dijiang Huang, "MCCOSGi: A OSGi-based Mobile Cloud Service Model", The IEEE ISADS (Eleventh International Symposium on Autonomous Decentralized Systems), March 2013, pp.37-44, Mexico.
The proposed design is an intermediary solution which offers the same performance execution as a classic Android execution since it is integrated within the Android OS without additional layers. Moreover, it offers modularity facilities for sharing services and reduces duplication in mobile devices thanks to the introduction of the Andromodule components. In fact, with the emergence of mobile applications and the high performance requirements facing a big data and remote cloud services, we need to consider modularity and life cycle of the services directly inside the design of the mobile operating systems. As a perspective, we aim to complete the performance evaluation by measuring the response time of the applications that are based on Andromodules, and the footprint of the Andromodule management system, before extending this work to a distributed environment through a Cloud of interacting mobile devices.
2132
