-
aharsityolog
Article history:Available online 2 April 2010
Keywords:Intelligent transport systemsVehicular
platformOSGiAndroidCloud computing
assistance, navigation, driver aids, remote diagnostics,
entertain-ment, and web browsing. The telematics market is
currently quiteyoung, and most telematics technologies are
independent of eachother due to multiple platform standards. This
situation also makesit difcult for service providers to create
value-added telematicsservices. Consequently, numerous vehicle
manufacturers haveestablished and developed open/standard embedded
platforms for
(humanmachine interface) so that both service providers and
carmanufacturers can quickly deliver solutions to potential
marketsand simplify development. If service providers want to
remotelydeploy telematics services to an on-board terminal, or if
road-sidecenters need to diagnose vehicular devices or congure
telematicsapplications, they should use remote management services
thatrely on open/standard telematics platforms.
Telematics applications can be divided into four
categories,including VANET embedded systems, vehicularmultimedia
embed-ded systems, intelligent driver aid embedded systems, and
UrbanNomadic/Pedestrian Telematics embedded systems. First, a
VANET
* Corresponding author.
Computer Communications 34 (2011) 169183
Contents lists availab
m
elsE-mail address: [email protected] (J.-L. Chen).1.
Introduction
In recent years, sophisticated information technology has
al-lowed the automotive industry to mature in the eld of
telematics.Telematics in automobiles involves the automated
convergence oftelecommunications and information technology. So
far, automak-ers and third-party serviceprovidershavedevelopedquite
anumberof telematics services, including monitoring, emergency
road-side
vehicles. These platforms includeOSGi/VEG, AUTOSAR, AMI-C,
CVIS,OSEK/VDX, and Android.
Fig. 1 illustrates an open Linux operating system ported into
anembedded on-board terminal. This system does not only provide
avariety of device drivers, including CAN/LIN/FlexRay buses
andout-network connection modules, but also offers resources
man-agement. The open/standard telematics platforms in the
telematicsmiddleware layer mainly standardize APIs and
graphic/vocal HMI0140-3664/$ - see front matter 2010 Elsevier B.V.
Adoi:10.1016/j.comcom.2010.03.032With the enormous market potential
of the telematics industry and the rapid development of
informationtechnology, automotive telematics has attracted
considerable attention for mobile computing and Intel-ligent
Transport Systems (ITSs). However, as a result of varied platform
standards, not all telematics ser-vices can be used in telematics
terminals. The main issues are that most telematics technologies
dependon vertical, proprietary, and closed Original Equipment
Manufacturer (OEM) platforms. These platformsform islands of
non-interoperable technology and prevent third-party service
providers from creatingvaluable services. This study integrates the
Open Gateway Service Initiative Vehicle Expert Group(OSGi/VEG) into
an Android platform to generate a vehicular Android/OSGi platform
that has the advan-tages of both original platforms. These features
include remote management, rich class-sharing, proprie-tary
vehicular applications, security policies, easy management of
Application Programming Interface(APIs), and an open environment.
This study also integrates a cloud computing mechanism into
theAndroid/OSGi platform, allowing service providers to upload
their telematics bundles onto storage cloudsusing a provisioning
server. A management agent in the Android/OSGi platform can
simultaneouslyupdate its application service modules using remote
storage clouds and use visual intelligence to contin-ually change
the distinguishing features of applications based on
context-awareness without user inter-vention. To assess the
feasibility of the proposed Android/OSGi platform, this study
presents a vehiculartestbed to determine the functionalities of
different telematics applications. Android/OSGi
platformapplications require less memory and system resources than
those on the original Android platformwhen performing complicated
operations. Additionally, the Android/OSGi platform launches
telematicsservices more quickly than the original Android platform.
The proposed platform overcomes the problemof frequent
non-responsive exceptions in the original Android platform.
2010 Elsevier B.V. All rights reserved.a r t i c l e i n f o a b
s t r a c tAndroid/OSGi-based vehicular network m
Ming-Chiao Chen a, Jiann-Liang Chen b,*, Teng-Wen CaDepartment
of Computer Science and Information Engineering, National Taitung
UnivebDepartment of Electrical Engineering, National Taiwan
University of Science and TechncDepartment of Electrical
Engineering, National Taiwan University, Taipei, Taiwan
Computer Co
journal homepage: www.ll rights reserved.nagement system
ng c
, Taiwany, Taipei, Taiwan
le at ScienceDirect
munications
evier .com/locate /comcom
-
tics architecture.
mmsystem allows vehicles to communicatewith other vehicles or
road-side units using DSRC/IEEE 1609. For example, if a vehicle has
anaccident, it can broadcast an emergencymessage to vehicles
behindit using the VANET embedded system. The second type of
telematicsapplication is, amultimedia systemthat allowsdrivers
towatchDVBprograms, play on-line games, monitor home conditions,
and so on.This type of multimedia embedded system takes advantage
of high-performance graphics, SoC, or 3D engines when performing
compli-cated operations. Third, driver aid systems ensure the
security ofdrivers, economize the use of power, and so on. Finally,
anUrbanNo-madic/Pedestrians Telematics system provides interactive
servicesbetween users and service providers in a non-automotive
environ-ment, such as nding local gas stations in an unfamiliar
area. Other
Fig. 1. Telema170 M.-C. Chen et al. / Computer Cotelematics
services allowdrivers to download/upload or share infor-mation to
telematics information platforms using Web servers andout-network
connection capabilities.
This study discusses how to combine OSGi/VEG into an
Androidplatform to form a new vehicular Android/OSGi platform that
hasthe advantages of both original platforms, including remote
man-agement/deployment, rich class-sharing, proprietary
vehicularapplications, security policies, and more.
2. Related works
2.1. Android platform
The Android platform delivers a complete set of software
formobile devices: an operating system, middleware, and key
mobileapplications [1]. Windows Mobile and Apples iPhone provide a
ri-cher, simplied development environment for mobile
applications.However, unlike Android, theyre built on proprietary
operatingsystems that often prioritize native applications over
those createdby third parties and restrict communication between
applicationsand native data. Android offers new possibilities for
mobile appli-cations by offering an open development environment
built on anopen source Linux kernel. Real hardware can be accessed
through aseries of standard API libraries, allowing the user to
manage Wi-Fi,Bluetooth, and GPS devices. As Fig. 2 illustrates, the
Open MobileAlliance (OHA) [2] and Google support the Android
platform andhope to reach the goal of ensuring global mobile
services thatunications 34 (2011) 169183operate across devices,
geographies, service providers, operators,and networks.
Google has already released the open source Android
platform,providing the opportunity to create new adaptive mobile
platforminterfaces and applications designed to look, feel, and
function asdesired. Consequently, the Android platform has recently
beenported into mobile devices, such as notebooks, PDAs, and
automo-tive systems. In automotive system elds, the Intel and Wind
RiverSystems are actively integrating Android-powered
infotainmentoperating systems for vehicles.
2.1.1. Android software stackFig. 3 illustrates the Android
software stack [3], which con-
sists of a Linux kernel, a collection of Android libraries,
anapplication framework that manages Android applications
inruntime, and native or third-party applications in the
applicationlayer. The following list species these Android software
stackcomponents:
Fig. 2. Open environment for Android platform.
-
f An
mmFig. 3. Architecture o
M.-C. Chen et al. / Computer Co Linux kernel: A Linux 2.6 kernel
manages core services (includ-ing device hardware drivers, process
and memory management,security, network, and power management). The
kernel alsoprovides an abstraction layer between the hardware and
therest of the stack.
Libraries: Android includes various C/C++ core libraries
runningon top of the kernel. These libraries include libc and SSL,
and thefollowing: A media library for playing multimedia resources
A Surface manager to provide display management Graphics libraries
that include SGL and OpenGL for 2D and
3D graphics SQLite for data storage SSL and WebKit for
integrated web browser and Internet
security Android runtime: Including the core libraries and the
Dalvik vir-tual machine, the Android runtime is a runtime
environment fornormal Android applications.
Core libraries:While Android development is performed in
Java/C++, Dalvik is not a standardized Java VM. The core
Androidlibraries provide most of the functionality available in the
coreJava libraries and the Android-specic libraries.
Dalvikvirtual machine: Dalvik is a register-based virtual
machinethat is optimized to ensure the efcient and stable operation
ofmultiple instances. Dalvik relies on the Linux kernel for
thread-ing and low-level memory/process management.
Application framework: The application framework provides
theclasses used to create Android applications. It also provides
ageneric abstraction layer for hardware access and managesthe user
interface and application resources.
Applicationlayer:All applications, bothnative and third-party,
arebuilt on the application layer using the same API libraries.
Theapplication layer runswithin the Android runtimeusing the
clas-ses and services available from the application
framework.droid software stack.
unications 34 (2011) 169183 1712.1.2. Android platform
featuresAndroid offers several unique features that other mobile
plat-
forms do not possess:
Google map of navigation applications: Fig. 4 shows that
theAndroid platform provides a MapView widget that allows a userto
navigate, display, manipulate, and annotate a Google Mapwithin the
Activities to build map-based applications usingthe more familiar
Google Maps interface.
Background services and applications: Background services
allowAndroid applications to use an event-driven model that
workssilently while other applications are being used in
theforeground.
All applications are created equal: Android does not
differentiatebetween core applications and third-party
applications, and allapplications have equal access to a platforms
capabilities pro-viding users with a broad spectrum of applications
and services.
P2P inter-device application messaging: Android offers a
peer-to-peer messaging mechanism that supports presence,
instantmessaging, and inter-device/inter-application
communication.
Breaking down application boundaries: Android breaks down
thebarriers to building new and innovative applications. Users
cancombine information from the web with their own Androidplatform,
including user contacts, calendar, or geographic loca-tion, to
provide a more relevant user experience. Further, third-party
applications can be downloaded to the users Androidplatform from
the Android Market for free.
2.2. Open services gateway initiative (OSGi) service
platform
The OSGi platform standard [4] denes a standardized,
com-ponents-oriented computing environment for networked
servicesthat is the foundation of an enhanced Service-Oriented
Architec-ture (SOA). The OSGi specications were initially targeted
at
-
mm172 M.-C. Chen et al. / Computer Coresidential internet
gateways for home automation applications[11,12]. However, the
standard and extensible features of OSGimake enterprises regard
OSGi technology as key solutions. Forexample, Nokia and Motorola
adopted the OSGi technology stan-dard for next-generation smart
phones, and many car manufactur-ers have embedded OSGi specications
into their Global System forTelematics (GST) specications [5]. The
OSGi framework providesgeneral-purpose, secure support for
deploying extensible anddownloadable java-based service
applications, called bundles.OSGi bundles are applications packaged
in a standard Java Archive(JAR) le, and contain a manifest le that
describes the relation-ships among bundles and the OSGi framework,
a series of compiledJava classes, and native code. Fig. 5
illustrates the OSGi frameworkrunning on a Java virtual machine.
The OSGi framework provides ashared execution environment that
dynamically installs, updates,and uninstalls bundles without
restarting the system.
2.2.1. OSGi-based telematics gatewayThe OSGi Alliance whitepaper
[10] indicates that the research
and development of OSGi can be extended to any networked
envi-ronment, including automobile applications, and implemented
incomplex embedded devices that require deployable services.
TheOSGi framework makes it possible to access, download, and
useservices in an automotive mobile environment, creating an
enor-mous potential for automotive manufacturers and service
provid-ers to offer new proactive services to drivers and
passengers [13].The open standard-based, service-oriented
automotive infrastruc-ture for the telematics architecture [14,15]
includes a OSGi
Fig. 4. Location-based services for Android platform.gateway,
service infrastructure, and self-automobile. The centralcontrol
point of the service infrastructure, which is the
OSGi-basedtelematics gateway, can be interconnected with various
internaland external networks and buses. This gateway acts as an
execu-tion environment for mobile automotive services. The
followingbundles provide many critical services for OSGi-based
telematicsgateway:
Monitoring bundle: This bundle offers basic intelligent
vehiclefunctions. By monitoring the status and performance of
localvehicle devices, a driver can acquire vehicle information,
suchas temperature, various pressure levels, engine uid levels,
etc.
Navigation bundle: This bundle provides a navigation systemthat
offers navigational assistance to drivers. The systemreceives and
processes GPS position information signals todetermine the current
latitude and longitude coordinates, anddirection of travel.
Communication bundle: This bundle acts as an OSGi-based
tele-matics gateway for in-vehicle or out-vehicle network
connec-tions. This bundle extends the functionality of the
OSGi-basedgateway by remote deployment of OSGi bundles provided
by
Fig. 5. Architecture of OSGi framework.
unications 34 (2011) 169183the service provider. Through CAN,
LIN, or MOST [16], theOSGi-based telematics gateway realizes local
area connectionsamong in-vehicle devices, and by using GPRS, GSM or
even spe-cial ITS FM channels, this bundle allows wide area
connectionsamong vehicles, home gateways, remote service centers,
androad-side systems.
Driver aid bundle: This bundle provides driver assistance
andoffers some warning messages based on lane recognition.
Diagnostics bundle: This bundle provides remote diagnostic
ser-vices, allowing complicated diagnostic information to be
ana-lyzed and stored in remote systems. This technique is similarto
the MYCAREVENT project [17] in that it enables a telematicsgateway
to have the capacities of automatic repair and self-management.
Information/Entertainment bundle: Video and audio equipmentare
already widely applied in vehicles. Previous research dis-cusses an
infotainment server system for in-vehicle users thatallows the
network-enabled Information Appliances (IA) toaccess information
and entertainment services from an info-tainment server [18].
Automotive operating systems are also very signicant in
vehi-cles [19]. By supporting specic device drivers such as
CAN/LINbuses, which communicate with other Electronic Control
Units
-
(ECU) nodes for diagnostic purpose, previous studies have
embed-ded an OSGi platform in a vASOS automotive operating
system[20,21]. Fig. 6 illustrates OSGi-based middleware run on a K
VirtualMachine (KVM), which is a compact, portable Java virtual
machineintended for small, resource-constrained devices [5]. In
addition,previous studies use an OSGi R3 implementation of Oscar to
devel-op application bundles, including navigation and
CAN/LIN/MOSTaccess bundles. This study takes advantage of OSGi R4
implemen-tation of Apache Felix to integrate with the Google
Android plat-form, turning a variety of Google APIs into OSGi
bundles, such aslocation-based, peer-to-peer communication, and
network man-ager bundles. This approach not only allows service
providers todeploy telematics services, but also enhances Android
runtimelayer performance and remote management functionality.
The goal of the Vehicle Expert Group (VEG) is to tailor and
ex-tend the OSGi specication in order to meet
vehicle-specicrequirements. To achieve this, the VEG has dened a
list of topicsthat cover vehicle-specic issues. Working with the
automotiveindustry, the VEG has specied telematics APIs so that
both serviceproviders and car manufacturers can quickly deliver
solutions tomarket and increase customer loyalty. The OSGiVEG
organizationhas the following automotive projects:
M.-C. Chen et al. / Computer Comm 3GT: The 3GT project [6] is
designed to help establish OSGi-based in-vehicle telematics
platforms for the European massmarket by ensuring interoperability
between the products ofdifferent middleware providers, terminal
manufacturers, andservice providers. This will be done by
establishing commontelematics interfaces for OSGi-based service
delivery. Morespecically, 3GT will develop OSGi-based specications
for theinterface between vehicles and control centers and the
interfacebetween control centers and service providers.
ITEA EAST EEA: This automotive project [7] is funded by
theEuropean Union, and involves major European
automotivemanufacturers, rst-tier suppliers, and research
departments.The goal of EAST-EEA is to enable hardware and software
inter-operability of in-vehicle ECU nodes by dening an open,
mid-dleware-based architecture.
Stadtinfokoeln: Stadtinfokoeln is a Cologne-based project
[8],funded by the German Ministry of Education and Science(BMBF),
that focuses on parking services for the residents orFig. 6.
Architecture of vASOS and OSGi-based middleware for
vehicles.visitors of Cologne, Germany. The goal of this project is
to sat-isfy customer demand and to reduce trafc, which is relatedto
parking space availability. An important component of thisproject
is the rapid development of information and communi-cation
technology in a mobile environment. To fulll theserequirements, the
Stadtinfokoeln project managers decided touse an OSGi service
platform framework. This has enabled therapid development and
deployment of new services.
TOP-IQ: The Eureka-project TOP-IQ [9] focuses on the
develop-ment of a new generation of On-Board Computers (OBC) for
lux-ury cars and trucks. This type of OBC facilitates
telematicsservices for transport and logistics, and conducts the
manage-ment, billing, and delivery of new services such as on-line
nav-igation, trailer management/tracking, cargo tracking, and
more.
2.2.2. Safe deployment of OSGi bundlesThe security of deployment
vehicular services is a crucial issue
in the telematics environment. If vehicle owners install
third-partyapplications on their on-board vehicle system, they may
experi-ence hazardous conditions if those vehicular applications
havemany bugs, such as sending mass messages, accessing the
securitysensitive areas of the vehicle, and consuming excesses
system re-sources. Therefore, it is hard to establish meaningful
trust relation-ships in an open environment, and even when one can,
trust doesnot equal quality. Previous researchers have utilized
Aspect-Ori-ented Programming (AOP) to weave a security enforcement
policyinto OSGi bundles [22]. Additionally, AOP provides
cross-cuttingfunctionalities in complicated vehicular applications,
allowing pro-gram concerns in a software system to be captured and
encapsu-lated into so-called aspects. Fig. 7 illustrates the
weaving processscenario in a vehicular environment, which involves
an in-vehiclesystem, control center, and third-party service
providers.
Some vehicle owners install vehicular application bundles
bymaking a corresponding request in the GST standard.
Beforeinstalling this type of application bundle on an in-vehicle
systemover a wired/wireless network, the control center weaves
theapplication with security policies so that the woven bundle
canoperate with enforcement security policies on the
in-vehiclesystem.
2.3. Comparison of OSGi and Android
Fig. 8 shows that both OSGi and Android dene a
developmentplatform for developing service-oriented computing
mechanismsin mobile devices, and share similar VM technology,
service mod-els, component models and openness. The main difference
be-tween them is that the Android platform utilizes
process-basedisolation to enhance resource management, while the
OSGi plat-form uses a classloader-based isolation model. This
allows OSGibundles to selectively export some of their internal
packages toother consumer bundles. Bundles can declare their
package depen-dencies and the framework is responsible for managing
depen-dency relationships between consumer bundles and
providedbundles. Due to its classloader-based isolation mechanism,
theOSGi framework also has the advantage of rich class-sharing.
TheAndroid platform uses background services to perform
time-con-suming operations, but these services are usually
heavyweight,and only can be accessed utilizing inter-process
communication,which makes service access slower and more expensive.
In OSGi,service components are lightweight. They are called
directly whenfound in the service registry. Consequently, OSGi
services play asignicant role in keeping components lightweight and
looselycoupled. The OSGi specication denes many remote
management
unications 34 (2011) 169183 173services, including SNMP, CMISE,
CIM, and OMA DM [23]. Utilizingremote management services, managers
can easily remotelyadminister an OSGi framework in many situations.
These remote
-
mm174 M.-C. Chen et al. / Computer Comanagement services are not
available on the Android platform.The Android platforms lack of
class-sharing ability seriously limitsthe sharing of components and
remote device management. Thelack of versioning and management APIs
is a further limitation.Presumably, OEMs will provide some
solutions for these importantrequirements in the future.
3. Open embedded Android/OSGi platform for telematics
Fig. 9 illustrates the proposed architecture for a telematics
sys-tem. Here, the Android platform adopts the latest Android 1.5
ker-nel, allowing the proposed Android/OSGi platform to be
integratedinto real Android-based hardware devices. This design
also allowsthe OSGi R4 implementation to be operated normally in an
AndroidDalvik Virtual Machine (VM), developing the communication
inter-face between users and OSGi framework in the Android
applicationlayer, bridge Android/OSGi applications, and other
Android appli-cations. This study also develops an advanced
technique forembedding an OSGi instance into Android applications,
to make
Fig. 7. The weaving process in
Fig. 8. Comparisons ofunications 34 (2011) 169183them more
adaptive and exible. Any time-consuming operations,such as
continually loading the main class of OSGi framework andupdating
the Android GUI interfaces, will be performed by Androidbackground
services. As a result, the proposed Android/OSGi plat-form has
high-performance and responsiveness. In the proposeddesign, an
iPOJO service-oriented framework is ported and runon top of
Android/OSGi applications. The primary goal is to providethe
components with a self-management capacity and dynamicallyrespond
to service changes in capricious environments. We also in-stalled
indispensable OSGi bundles for developing some valuabletelematics
applications, such as the Web management console,remote deployment
interface, navigation, diagnostics, and so on.Finally, this study
develops the management agent to communi-cate with remote cloud
called Amazon EC2 through Restful API.The management agent
installs/updates local services synchro-nously with remote cloud,
and all of Android/OSGi bundles arestored in Amazon S3. This study
also implements a provisioningserver to remotely deploying packages
or OSGi bundles to the cli-ents Android/OSGi platforms based on
Amazon S3.
vehicular environment.
OSGi and Android.
-
of OSGi framework.
mm3.1. Location of OSGi framework in the Android platform
The Dalvik VM use the devices underlying Linux kernel to han-dle
low-level functions, including security, threading, process,
and
Fig. 9. Location
M.-C. Chen et al. / Computer Comemory management. Its also
possible to read and write C/C++applications that run directly on
the underlying Linux OS. How-ever, Dalvik VM can only execute
Dalvik executable les (e.g., clas-ses.dex), a format optimized to
ensure minimal memory footprint.Consequently it cannot perform
general Java packages and OSGibundles, causing OSGi framework
operations to fail when Androidencounters OSGi functionalities in
runtime. Besides, as Fig. 10shows, if the OSGi framework
successfully runs in the AndroidRuntime layer, it cannot directly
interact with users, because userscan only view Android Activities
(or applications) in the applica-tion layer. For this reason, the
Android/OSGi Activity must grab areport or log message from the
OSGi framework, and use the An-droid UI to present information to
the users. The proposed designuses the OSGi R4 implementation of
Apache Felix to integrate withthe Android platform because this
container is more portable andlightweight, and better-suited to
embedded hardware devices suchas telematics systems.
3.2. Android/OSGi conversion mechanism
The Android/OSGi conversion mechanism uses the OSGi frame-work
to dynamically load bundles through the Android Davik VM.Fig. 11
shows the Android/OSGi conversion mechanism, whichmakes the OSGi
framework perform a series of complied Java clas-ses from OSGi
bundles in the Android runtime layer using a clas-ses.dex le to
reference the OSGi bundles general Java classes.Therefore, the
classes.dex le plays a bridging role between theOSGi framework and
bundles. The proposed design implementsAndroid/OSGi conversion code
through Dalvik.system.dexFile API,and imports two parameters, the
package name (bundle API pack-ages) and ClassLoader (reading the
Java classes) objects. The con-version code then returns the
collection of Java classes, allowingunications 34 (2011) 169183
175the OSGi framework to indirectly perform the functionalities
pro-vided by the OSGi bundles.
After operating Android conversion mechanism, it is necessaryto
ensure that all OSGi bundles or general Java packages
containclasses.dex les. This allows the OSGi framework to assume
thatany bundle works, share API packages, and let consumer
bundlesquery the OSGi services provided by the OSGi framework. This
ap-proach adopts the DEX conversion tool from Android SDK. This
toolcan easily convert Java complied les into classes.dex les,
whichthat Dalvik VM is able to execute. Fig. 12 illustrates the
conversionow of OSGi bundles to apk les (Android executive
extension); in
Fig. 10. Location of OSGi framework.
-
3.3. Development of Android/OSGi application
This study had created Android/OSGi application in
Androidapplication layer, which can fetch the OSGi corresponding
informa-tion from Android runtime layer, and providing interactive
envi-ronment between users and OSGi framework. In rst integrationof
procedure, this study must to implement Android Activity
inter-face, letting Android/OSGi application to have Android
Activityproperties. Unlike most traditional environment, Android
applica-tions have no ability of control over their own life
cycles, Instead,Android application framework must to be in charge
of Androidapplications state, and react accordingly, taking
particular care to
176 M.-C. Chen et al. / Computer Communications 34 (2011)
169183original, this study had made the OSGi bundle projects to be
com-piled, and if no exception will generate a series of Java
compiledclasses. After converting into jar les, the DEX tool is
used to makejar les containing classes.dex, and he aapt command
transformsOSGi bundles into Android apk les. Finally, the adb push
com-
Fig. 11. Android/OSGi conversion mechanism.mand is used to push
converted the apk les to the Androidplatform.
With the Android conversion mechanism and converted OSGibundles,
it is possible to port the OSGi framework to the Androidunderlying
layer, along with other functional bundles such as tel-net,
deployment admin, http, and remote manager bundles etc.,so that the
Android platform can be operated and managed remo-tely. The
original platform does not have this ability. Fig. 13 showsthe
script of starting the OSGi framework in the Android runtimelayer,
and using a Dalvik VM to read the main class of the OSGiframework,
enter the OSGi console mode, and show a list of someinstalled
bundles. Nevertheless, because users cannot directlyinteract with
the OSGi framework in real hardware devices usingthis technique,
this study implements Android/OSGi Activity andGUI interface to
acquire corresponding OSGi information fromthe underlying layer,
and also embeds the OSGi framework intoan Android application to
make it more powerful and adaptable.
Fig. 12. Conversion ow of OSGibe prepared for untimely
termination. When main launch Activitywhich belongs to Android/OSGi
application has become activestate and need to operate continually,
the Android applicationframework will pay attention to ensure that
the Android/OSGiapplication remains responsive. Therefore Android
applicationframework has the capacity of monitoring platform
resources atany time, if necessary, will kill some empty or
background pro-cesses to free resources for high-priority
applications.
The Android application has various Activities, which representa
screen that an application can present to its users. Android
Activ-ity typically includes at least a primary interface screen
that han-dles the main UI functionality for Android application.
This isoften supporting additional by secondary Activities for
enteringinformation, and providing different perspectives on user
data.For example, this study had created the Android views of OSGi
con-sole, making users can enter OSGi commands and catch the sight
ofOSGi corresponding Information. Every Android Activity has an
ini-tializer method called onCreate, by using this initializer
method;Android platform can distribute the memory to perform
thelauncher thread which can make OSGi framework to be started.Fig.
14 illustrates the cross-communication operation that An-droid/OSGi
Activity launches the FelixService (Android backgroundservice)
which can represent the GUI interface of OSGi console andto load
the main class of OSGi framework after Android/OSGi Activ-ity
onCreate method had already been initialized. Android servicesrun
without a dedicated GUI, they usually silently perform back-ground
works that users cant perceive. Before FelixService torun, they
must to be attached with Android/OSGi Activity. Fromdifferent point
of view, the Android/OSGi Activity provides AndroidContext object,
which makes Android application framework to beable to manage its
life states, and communication betweenAndroid/OSGi application and
other native or third-partyapplications.
To ensure that the proposed Android/OSGi application
remainsresponsive, the proposed design moves all slow and
time-consum-ing operations off the main Activity thread and onto a
child thread.Examples of slow operations include continually
reading the mainclass of the OSGi framework, and updating the GUI
interface whenthe OSGi console view has been changed or GUI bundles
providebundles to become apk les.
-
mmM.-C. Chen et al. / Computer Conew screen services.
Consequently, this study implements theFelixservice to perform the
above-mentioned operations. Fig. 15shows that Felixservice can
directly determine the location of theOSGi framework in the Android
runtime layer and extract the mainjar le of the OSGi framework,
which is Apache Felix of R4 OSGiimplementation. Using the Dalvik
ClassLoader object to read themain class continually in child
thread, the Android/OSGi platformcan start the OSGi framework in
the Android application layer. Inaddition, this study also
implements a OSGi console view thatcan fetch the corresponding OSGi
message and display them tousers. The OSGi console view has two
input/output interfaces thatallow users to immediately interact
with the OSGi framework.
Fig. 16 shows that how the Android/OSGi Activity can transmitthe
received information to the OSGi framework after nishing
theabove-mentioned operation. The OSGi framework regards
thisinformation as permanent properties data (key/value pairs)
storedin the OSGi environment and OSGi bundles can retrieve
theseproperties through preference service to implement
advancedapplications, such as network manager, navigation bundle,
and so
Fig. 13. OSGi framework run
Fig. 14. Cross-communication operation.on. In the same way, when
OSGi bundles become ACITVE, theycan also transmit explicit or
implicit intents to launch useful Activ-ities. Based on the
strength of this two-way communication mech-anism, the proposed
design allows Android applications to easilyconnect with the OSGi
framework and bundles.
3.4. Embedding OSGi framework to Android application
in Android runtime layer.
unications 34 (2011) 169183 177In traditional devices, the
Android/OSGi platform utilizes theOSGi services and service
registry as an extensibility mechanism.This mechanism allows any
application to run completely on topof the OSGi framework, but this
is not always possible. In otherwords, system components must
follow the OSGi standard to beimplemented, which will result in
increasing the developmenttimes and costs. Besides, the system
components spend extra-timeto communicate with OSGi framework in
runtime layer. Therefore,if any Android application wants to use
either the OSGi services orthe APIs provided by bundles, it needs a
complicated Android/OSGicommunication mechanism. We created an
embedded mechanismthat allows the OSGi framework to tightly embed
into Androidapplications in the application layer, as Fig. 17
shows. In thisway, any Android application can host the instance of
OSGi frame-work by utilizing reection approach, and application
canexternally load the services which OSGi bundles provided.
Never-theless, the extender mechanism has some drawbacks in that
itlack dynamic changes in OSGi bundles/services and cannot cong-ure
OSGi instances. Therefore, this study combines two mecha-nisms with
the Android platform to create a more integratedAndroid/OSGi
environment.
The Felix framework instance does not utilize
ServiceReferencearray object to get referenced services, but on the
contrary, it usesthe Service Tracker interface to monitor services.
As a result ofutilizing traditional service-oriented mechanism, the
producerbundles should use the BundleContext object to register
servicesin the service registry. If referenced services have been
changed,the ServiceChanged event must be implemented to ensure
thatno exceptions have been generated. As a result, this
mechanismis more cumbersome then the service tracker mechanism.
For
-
mm178 M.-C. Chen et al. / Computer Coexample, Fig. 18 shows, if
referenced services have been modied,the server bundle
automatically callback the modiedServicemethod to rebind these
services without implementing the Ser-viceChanged event handler.
The service tracker also can take
Fig. 15. Inter-architectur
Fig. 16. Two-way communication mechunications 34 (2011)
169183advantages of a whiteboard pattern, allowing embedded
OSGiframework to utilize a server bundle to monitor listener
serviceschanges. The embedded OSGi Activity has the responsibility
oftracking UI services, and if these UI services exist, the
embedded
e of the Felixservice.
anism between OSGi and Android.
-
allowsanycomponentwith self-managing capability
topublish/dis-cover services using iPOJO handlers, but also reduces
system com-plexity. Besides, an Android/OSGi application can
dynamicallyreact to the changing availability of services in
capricious environ-ments. The iPOJO framework extends the
declarative service con-cepts dened in OSGi R4 version, which also
makes allows servicesto be dened in iPOJO metadata. Then, if the
provision componentbecomes valid, it will spontaneously inject
services to on-demandcomponents from metadata in runtime without
any interruptionsfrom the OSGi framework. In the same way, if the
provision compo-nent becomes invalid, the on-demand components will
unbind thereferenced services to ensure system reliability.
However, the iPOJOframework has two limitations in Dalvik VM that
prevent it fromsupport dynamic generated classes and composite
services. Fig. 19illustrates the SendRoadImage component, which
allows road-sidecenter to monitor the road conditions of remote
vehicle. It uses
M.-C. Chen et al. / Computer Communications 34 (2011) 169183
179Fig. 17. Tightly integrated Android/OSGi environment.OSGi
Activity utilizes a child thread to call the setContentViewmethod
to update the foreground screen for the user.
3.5. Self-managing middleware for the Android platform
We ported the iPOJO service-oriented framework into the
re-source directory of the Android/OSGi application using the
Filein-stall Activator, which has the main goal of making
Android/OSGiapplications more adaptive and exible. This approach
not only
assign the location of remote provision server. When this
agent
Fig. 18. Service tracker of embedded OSGi activity.
S1
S2
S1S3
iPOJO Components
OSGi(Felix)/iPOJO framework
Android Application
MMS Service
CameraService
SendRoadImageService
Service Component Binding
DynamicSer
Fig. 19. The iPOJO component inhas been started, it installs and
starts remotely downloaded appli-cations, and also manages their
packages and resources.
4.1. Vehicular Android/OSGi platform
The Android/OSGi bundles which mainly contain
standardizedBundleActivator interface and BundleContext object that
make
private MmsSender sender;private Camera[] cameras;public void
send() {
MMS mms = new MMS();synchronized (cameras) {
for (int i = 0; i < cameras.length; i++)
{mms.add(cameras[i].getImage());}
}sender.send("Road_Condition", mms);
}}
SendRoadImage By MMS implementation
ally Injection vicestwo services: the rst required service is
MmsService, which allowsa client to send anMMSmessage, and the
second service is Camera,which allows a client to take a monitor
image using camera hard-ware in theAndroidplatform.When
theSendRoadImagecomponentbecomes available, it can easily use the
above-mentioned servicesthrough dened iPOJO metadata. Therefore,
developers only needto be concerned with the logic design of this
component.
4. System design and implementation of Android/OSGi platform
Testing the proposed telematics applications in real vehicles
isinconvenient and expensive. Consequently as Fig. 20 illustrates,
avehicular testbed was built to test and verify the
functionalitiesand security of the proposed Android/OSGi
applications. This studyregards sensor-based LEGO robots as
simulated vehicles, andmakes the vehicular Android/OSGi platform
act as an on-board ter-minal for simulated vehicles. Instead of
utilizing car buses, this on-board terminal mainly controls
simulated vehicles using Bluetooth,like IBM iDrive systems.
Communications between different vehi-cles is conducted via Wi-Fi.
Finally, this study designs a provision-ing server responsible for
storing telematics applications anddeploying an admin bundle called
the management agent, whichiPOJO Metadata for SendRoadImage
Android application layer.
-
OSGi framework can manage their life cycle and service
registra-tion or publishing. They also include required Android
libraries
droid/OSGi platform can only update its foreground screen
aftercalling setContentView method, Android/OSGi application
must
Fig. 20. Vehicular testbed.
180 M.-C. Chen et al. / Computer Communications 34 (2011)
169183into their descriptive Manifest les, so that OSGi framework
can re-solve these special packages. Fig. 21 illustrates
inter-architecture ofVehicular embedded Android/OSGi platform, in
rst, because An-Fig. 21. Inter-architecture ofto provide
ViewFactory objects make other Android/OSGi bundlesbeing able to
provide or update their Android GUI interfaces intomain Activity
such as ImageView, MapView, VideoView, and soAndroid/OSGi
platform.
-
on. Additionally, the Android/OSGi application should register
itsActivity instance service, so that host bundle can fetch this
mainActivity, and push registered GUI interfaces into it. The host
bundleimplements a ViewFactory interface with the primary
responsibil-ity of providing DesktopApplication service to other
consumerbundles. The second service of DesktopApplication acts as a
con-tainer for any Android View in the bundles. Consequently, if
anybundles want to provide some Views for the main Activity,
theymust implement the DesktopApplication interface, and
registertheir DesktopApplication services with the OSGi service
registry.Besides, the host bundle implements
ServiceTrackerCustomizerinterface, which makes host bundle being
able to track primaryActivity service and other DesktopApplication
services simulta-neously in customized way. Supposing quantity of
DesktopAppli-cation service greater than zero in OSGi registry,
host bundle cancall getViewmethod belong to DesktopApplication
interface to ob-tain container instances of Android View which
GUI-based bundlesprovided. Finally, host bundle will add one of
instances into main
tional memory size of OSGi framework. In tested Android
hard-
ing application, however in pure Android platform same
applica-tion only needs to spend about 1.21 MB memory size. In
otherword, if this study compares pure Android/OSGi bundles with
An-droid applications, as Fig. 22 table shows, Android
applicationshould spend extra 0.96 MB size, but comprehensive look
at totalplatform, Android/OSGi platform spends extra 0.95 MB
memorysize. However, if existence of enormous applications,
Android/OSGiplatform can substantially lighten its system resources
based onOSGi mechanism.
Fig. 23 illustrates Android/OSGi platform spends approximately2
MB memory size to launch OSGi framework, and when OSGiframework had
been started, Android/OSGi platform can consumeless memory size to
start other applications. Total occupiedmemory size of probably
lies in between 2 MB and 3 MB inAndroid/OSGi platform, however,
pure Android platform hasincreased memory size, and grows up 5 MB.
Consequently, pro-posed Android/OSGi platform can spend less memory
size thanpure Android platform when OSGi framework had been
started.
4.2.2. Telematics servicesThis study presents various telematics
services to establish
intelligent vehicles in mobile environment, as Fig. 24 shows,
whichmainly consist of line follow, object detection, keep
distance, andso on. The rst part of service helps vehicles follows
guidelinesto ensure driver security and reduce route-nding
complexity tolighten the use of power. The second part of this
service provides
M.-C. Chen et al. / Computer Communications 34 (2011) 169183
181ware, it has total 990440 KB memory size, and
Android/OSGiplatform need to spend about 1.91 MB memory size for
initiatingand starting OSGi framework, and 0.25 MB memory size for
start-LinearLayout object, and return it to Android/OSGi Activity.
Inthe proposed mechanism, only one bundle can provide GUI ser-vices
to the main Android/OSGi Activity, based on user interaction.
4.2. Android/OSGi bundles
4.2.1. GUI-based bundlesThe original Android platform allows
developers to create map-
based Activities using Google Map as a user interface element.
Wehave full permissions to access the map, include change the
zoomlevel, move the centered location, use overlays, provide
map-con-textualized information and functionality, and so on. But
if serviceproviders want to design navigation applications based on
map-based Activities, they must to create many heavyweight
servicesto perform time-consuming operations. Besides, Android
platformlack of class-sharing among different applications and
islands ofno-interoperable processes, which often limit usage of
system re-sources and remain non-responsive. Fig. 22 illustrates
vehicularAndroid/OSGi platform has feature of lightweight bundles
suchas navigation bundle, which bundle size is less 11 KB than
originalAndroid application. But vehicular Android/OSGi platform
must tospend about 7.5 s to start OSGi framework in rst time, and
addi-Fig. 22. Lightweight navigation applicFig. 23. Used memory
analysis.ation for Android/OSGi platform.
-
vehicles with visual intelligence to identify objects like
trafcsignals. The third part of the service helps vehicles maintain
a setdistance from vehicles in front of back. The last component of
thisservice allows road-side centers to survey the condition of
vehicles.If some of services access the signicant components of
vehicle, thevehicular Android/OSGi platform can enforce security
policies toavoid accidents using a AOP-based OSGi weaving
mechanism. Forexample if one service makes the vehicle travel
faster than
agement, and remote deployment console. The rst part of
thetelnet console allows a remote manager to diagnose and
manageAndroid/OSGi applications though a telnet interface, which
ex-tends the telnet bundle provided by the Oscar R3
implementation.The original Android platform cannot utilize telnet
services to diag-nose or manage its applications or system
conguration. The sec-ond part of the web console allows remote
managers to diagnoseand manage Android/OSGi applications based on
web techniques.
Fig. 24. Android/OSGi applications.
182 M.-C. Chen et al. / Computer Communications 34 (2011)
16918370 km/h, this service will be rejected.
4.2.3. Remote managementFig. 25 illustrates vehicular
Android/OSGi platform mainly pro-
vide three management consoles, which include telnet, web
man-Fig. 25. Remote management of veThis web management console
relies on underlying OSGi bundles,including http service,
declarative service, log service, congadmin,deployadmin, metadata,
and so on. Although the original Androidplatform has http service
that allows users to surf the internet de-pend on a WebKit browser,
it does not have a web server, whichhicular Android/OSGi
platform.
-
allows remote users to log into or our out the platform. The
rest ofthe remote deployment console enables applications to be
de-ployed on a remote vehicular Android/OSGi platform. This is
simi-lar to the Android market deployment mechanism, but has
somedifferences. For example, the Android/OSGi platform uses a
man-agement agent to request deployment packages from a
provision-ing server, while a pure Android platform uses a web
server todirectly download Android applications from the Android
Market.This management agent communicates with remote cloud
calledAmazon EC2 through Restful API. Android/OSGi bundles are
storedin Amazon S3, and Android/OSGi platform uses management
agentto automatically install/update bundles with remote cloud same
asactive sync. way. Consequently, the Android/OSGi platform
candynamically recongure its application services by
communicatingwith a provisioning server in runtime based on
context-awareness.
out user intervention. This study also establishes a
vehiculartestbed to verify and analyze the functionalities of the
Android/OSGi and original Android platform. Finally, this study
proves that
References
[1] Android Platform Ofcial Site, .[2] Open Mobile Alliance
Ofcial Site, .[3] Google Android software stack in brief, .[4] OSGi
Alliance, OSGi service platform, core specication release 4. Draft,
July
2005.[5] GST Global System for Telematics Ofcial Site, .[6] 3GT
Project Website, .[7] European ITEA Project Website, .[8]
Stadtinfokoeln Project Website, .[9] Eureka-project TOP-IQ Website,
.[10] About the OSGi Service Platform, OSGi Technical Whitepaper
4.1, June 2007.[11] C. Lee, D. Nordstedt, S. Helal, Enabling smart
spaces with OSGi, IEEE Pervasive
M.-C. Chen et al. / Computer Communications 34 (2011) 169183
183the proposed Android/OSGi platform has lighter applications
andhigher performance than a pure Android platform when perform-ing
complicated operations. This study will continue to correct sys-tem
lack like combine other technology and architecture to achievethe
best performance.Besides, the Android/OSGi platform supports
partial renewal ofapplications, reducing system delay time and
enhancing systemperformance. The Android Market should also take
advantage ofOSGi remote deployment mechanism using the
above-mentionedadvantages.
5. Conclusion
This paper introduces the principles of an embedded
OSGiframework in a Google Android platform. The proposed
vehicularAndroid/OSGi platform provides various unique
features:
Rich class-sharing Loose-coupled and lightweight services Easy
API management Automatic service change response Remote device
management Dynamic application update services
Using the proposed vehicular Android/OSGi platform,
road-sidecenters can diagnose or manage the system status of
vehicularplatform remotely, and use visual intelligence to
continually up-date their application services based on
context-awareness with-Computing 2 (3) (2003) 8994.[12] K. Myoung,
J. Heo, W.H. Kwon, D.S. Kim, Design and implementation of home
network control protocol on OSGi for home automation, in:
Proceedings of theIEEE International Conference on Advanced
Communication Technology, vol.2, July 2005, pp. 11631168.
[13] N. Gun, A. Held, J. Kaiser, Proactive services in a
distributed trafc telematicsapplication, in: Proceedings of the
International Workshop on MobileCommunication Over Wireless LAN:
Research and Applications, September2001.
[14] Y. Li, F. Wang, F. He, Z. Li, OSGi-based service gateway
architecture forintelligent automobiles, in: Proceedings of the
IEEE International Conferenceon Vehicles, June 2005, pp.
861865.
[15] D. Zhang, H.W. Xiao, K. Hackbarth, OSGi based service
infrastructure forcontext aware automotive telematics, in:
Proceedings of the IEEE InternationalConference on Vehicular
Technology, vol. 5, May 2004, pp. 29572961.
[16] Y. Zhou, X. Wang, M. Zhou, The research and realization for
passenger car CANbus, in: Proceedings of the IEEE International
Forum on Strategic Technology,October 2006, pp. 244247.
[17] E. Weiss, G. Gehlen, S. Lukas, C. Rokitansky, MYCAREVENT
vehicularcommunication gateway for car maintenance and remote
diagnosis, in:Proceedings of the IEEE International Conference on
Computers andCommunications, June 2006, pp. 318323.
[18] R.C. Hsu, L.R. Chen, integrated embedded system
architecture for in-vehicletelematics and infotainment system, in:
Proceedings of the IEEE InternationalSymposium on Industrial
Electronics, vol. 4, June 2005, pp. 14091414.
[19] S.V. Alberto, M.D. Natale, Embedded system design for
automotiveapplications, in: Proceedings of IEEE Computer Society on
ComputerEngineering, vol. 40, October 2007, pp. 4251.
[20] Y. Ai, Y. Sun, W. Huang, X. Qiao, OSGi based integrated
service platform forautomotive telematics, in: Proceedings of the
IEEE International Conference onVehicular Electronic and Safety,
December 2007, pp. 16.
[21] Y. Sun, W.L. Huang, S.M. Tang, X. Qiao, F.Y. Wang, Design
of an OSEK/VDX andOSGi-based embedded software platform for
vehicular applications, in:Proceedings of the IEEE International
Conference on Vehicular Electronic andSafety, December 2007, pp.
16.
[22] P.H. Phung, D. Sands, Security policy enforcement in the
OSGi framework usingaspect-oriented programming, in: Proceedings of
the IEEE InternationalConference on Computer Software and
Applications, August 2008, pp. 10761082.
[23] R. Hyun, C. Sung, P. Shiquan, K. Sung, The design of remote
vehiclemanagement system based on OMA DM protocol and AUTOSAR
S/Warchitecture, in: Proceedings of the IEEE International
Conference onAdvanced Language Processing and Web Information
Technology, July 2008,pp. 393397.
Android/OSGi-based vehicular network management
systemIntroductionRelated worksAndroid platformAndroid software
stackAndroid platform features
Open services gateway initiative (OSGi) service
platformOSGi-based telematics gatewaySafe deployment of OSGi
bundles
Comparison of OSGi and Android
Open embedded Android/OSGi platform for telematicsLocation of
OSGi framework in the Android platformAndroid/OSGi conversion
mechanismDevelopment of Android/OSGi applicationEmbedding OSGi
framework to Android applicationSelf-managing middleware for the
Android platform
System design and implementation of Android/OSGi
platformVehicular Android/OSGi platformAndroid/OSGi
bundlesGUI-based bundlesTelematics servicesRemote management
ConclusionReferences