mBS for Android Updates

Today ProSyst released the updated (0.2) version of mBS for Android, the Android port of the leading embedded implementation of OSGi Framework and services. The updated version can now be run on Android SDK 1.0 R2 as well as on the T-Mobile G1 device. Just like the previous version, this release is free of charge for non-commercial use.

Release Content

The 0.2 version contains:

• mbs.apk - the updated version of mBS for Android
• mconsole-proff-6.1.41.zip - ProSyst mConsole remote management tool
• demo.zip - Bundles demonstrating the use of OSGi services on top of Android
• readme.htm - Detailed installation instruction for the release and the demos
• License_Eula_ProSyst.txt

The changes made to mBS for Android

Classloading Changes

The Android platform does not allow to define classes using ClassLoader.defineClass(byte[]). Therefore the classloading mechanisms in mBS for Android had to be updated.

The Android platform provides special utility class for loading classes from external DEX files, class name is dalvik.system.DexFile. For this purpose new Class Provider was implemented, which uses the Android DexFile utility. When we start the mBS for Android application the starting process goes through the following steps:

1. The Android platform activates the main activity of the mBS Android application.
2. The main activity loads /res/raw/mbs_image.zip as resource and extracts it in the data directory of the application. The data directory is /data/data/com.prosyst.mbs.android.starter/app_mbs.
3. When the mBS image is extracted in the file system of the Android platform the main activity creates special java.lang.ClassLoader, which uses the dalvik.system.DexFile for loading classes from the serverjvm15.jar.
4. After the class loader is created the main activity loads the Start class of the mBedded Server and invokes its main(String[]) method in separated thread.
5. The the main method call is finished the mBedded Server application is started on the Android platform and the main activity updates the status of the provided information, the startup time and the used memory.

For debug purposes the output of the mBS is redirected to /data/data/com.prosyst.mbs.android.starter/app_mbs/bin/vms/mbs.log file, which can be opened using the Android SDK tools.

Network Permissions

In the previous version of the mBS Android application there was no need to add any permissions to the application for its normal work. In Android v1.0 the mBS needs special permissions for opening any server sockets. Therefore the following line was added in the AndroidManifest.xml file:

...
<uses-permission android:name="android.permission.INTERNET" />
...


Signed Application Package

In the previous version of mBS Android application its was allowed to install Android applications, which are not signed. In Android v1.0 it is not allowed to install such application. Therefore the new version of mBS Android application is signed.

Future Plans

ProSyst is working on additional demos and tools that help to leverage this technology. This release was created as a proof of concept to demonstrate the feasibility of using mBS on Android. However, ProSyst can productize this version if there is a significant interest in using this technology.

ProSyst publishes OSGi for Android

Today ProSyst released the beta version of mBS for Android. mBS is the leading OSGi implementation in the embedded market. The beta release of the Android version is available from ProSyst Developer Zone. This release is under ProSyst Non-Commercial License, which permits free use for non-commercial trials.

Why to use OSGi on top of Android?

OSGi and Android are both component platforms. However, due to the differences discussed in an earlier post about Android, there are significant benefits in using OSGi on top of Android:

• Lack of class-sharing: Android doesn't support the class sharing between application packages, which leads to class duplication between components of a modularly deployable application. Such class duplication puts high burden on platform maintenance as well if there are shared components.
• Fine-grained components: in Android, component communication involves interprocess communication which leads to coarse-grained components with high abstraction-level interfaces. The efficient communication between OSGi components - i.e. direct method calls - permits a much finer grained decomposition. The fine-grained component model enables plugin architectures like in Eclipse eRCP.
• Device Management: Remote manageability is an essential feature both for enterprises and mobile operator. Android currently doesn't include this feature, but OSGi offers an out of the box solution for this are.

Release Content and Requirements

Content of the release:

• mbs.apk - mBS for Android
• mconsole-proff-6.1.41-19-12-2007.zip - ProSyst mConsole remote management tool
• demo.zip - Bundles demonstrating the use of OSGi services on top of Android
• readme.htm - Detailed installation instruction for the release and the demos
• ProSyst Non-Commercial license.txt

mBS for Android

The mbs.apk package contains the mBS distribution as an Android application package. It can be directly deployed to Android using the adb tool. The product can then be found under the All desktop item.

This mBS distribution contains the full OSGi R4 framework implementation and the following services:

Configuration Admin IO Connector Console Data store (db.jar) Device Manager HTTP Service Servlet API Kit Installation Manager Log Service(log.jar) Metatype Service ProSyst Message Protocol Initial Provisioning Service ProSyst Utility Package Socket Connection Service Telnet Console User Admin Service Remote User Administration support

The mBS port works with Android M5 or later as it depends on some bugfixes introduced in the M5 release.

mConsole

The mconsole-proff-6.1.41-19-12-2007.zip contains ProSyst mConsole, a remote management console that allows the management of OSGi framework. This package can be installed to a PC and it can be used to remotely manage the OSGi framework running on Android. This version of mConsole uses the ProSyst Management Protocol for the management but other management protocols are supported as well. Using the management console allows:

• Installing/updating a bundle to the framework
• Uninstalling bundles
• Starting/stopping bundles

mConsole runs on Windows-based PCs.

Porting Experience

Porting Java applications to Android, if it doesn't involve the porting of UI should be easy. However, during the technical work, ProSyst team had to face some challenges due to some bugs in Android and the lack of documentation for the Dalvik Virtual Machine. The major issues are described here to help the work of other porting projects:

Stack Size

By default the stack size of the Dalvik VM is set to 1 KB. Which was a bit few when starting mBS with a large number of bundles. The stack size can be set using the -Xss command line argument. For example -Xss65536 sets the stack size to 64K. Unfortunately, it's not known how this argument can be specified for a regular Android application. As a workaround for this issue, mBS was modified to explicitly set the stack size when the corresponding Thread objects are created.

DEX converter bugs

There are some bugs in the dx tool provided in Android. ProSyst reported these bugs to Google, but it's good to be aware of these limitations until the problems are fixed.

The dx tool fails to generate code for the following try-catch-finally structure:

try {
// do something but do not return anything.
// If you have "return object" here the
// construction is OK.
} catch (Throwable th) {
// log the error
} finally {
// free the resources
// The DEX file generator fails to parse
// this section and starts eating memory
// and doing nothing.
}


Another failing construct is when Object[] is used to refer to different types of arrays, like in the code snippet below:

Object[] data = null;
if (condition1) {
data = new String[10];
} else if (condition2) {
data = new MyObject[10];
}


Future Plans

ProSyst is working on additional demos and tools that help to leverage this technology. This release was created as a proof of concept to demonstrate the feasibility of using mBS on Android. However, ProSyst can productize this version if there is a significant interest in using this technology.

A Comparision of OSGi and Android

Author's note: this article was originally posted to the ProSyst blog. I just publish it here as well, without changing the content.

Introduction

Google and the Open Handset Alliance announced the Android platform late last year. Shortly after that the Android SDK was published to the developer community and an exciting 10 million dollar developer challenge was announced too, which generated lots of developer interest. Due to this interest and the support of a number of industry players, Android is expected to gain significant market share in the future.

OSGi is a technology that has been developed for 10 years. Originally created to be the core platform of home gateways, slowly it was adapted in a number of verticals, including automotive industry or enterprise applications. In 2006, Release 4 of OSGi was published, which includes support for mobile phones and other handheld devices. Based on this technology, JSR-232 defines a dynamic, manageable component platform for mobile devices. Nokia eRCP platform, which is available for E90 and some other S60 3.1 devices, is based on JSR-232. The same technology is used by the Sprint Titan platform, for which devices will hit the market in 2008.

Both OSGi and Android define a development platform for component-based development and provide an implementation for the service-oriented architecture, within the mobile device. So, are they the same or completely different?

Admittedly, there are a number of similarities as well as some key differences. This article provides a high-level comparison of the two platforms, highlighting these key differences.

Comparison

Runtime Environment

Though somewhat external to the platforms, it worths to have a look at the runtime environments in which the two platforms are used.

OSGi can be used in a number of standard Java environments. It defines the minimum runtime requirements – so called Minimum Execution Environment – and any Java implementation that meets those requirements is sufficient to run OSGi. Minimum EE is a quite small API subset, which ensures that OSGi is usable in a wide variety of Java Runtimes, including JSE 1.1 or JME CDC1.0/FP1.0 as examples. This gives OSGi the required flexibility, which makes it applicable in a wide range of verticals from home automation to mobile devices. Frankly, OSGi extends a Java VM by introducing additional runtime execution environment features like the component model.

Android is an operating system with a new and proprietary application runtime technology. Though the applications are developed using the Java language, they are then compiled to a proprietary byte code format and are executed on the Dalvik Virtual Machine, a special VM created for Android. It is interesting to note that if converted to a Dalvik Executable, OSGi can be run on Android.

A key difference between the two platforms is that while Android applications are executed in separate instances of the DVM, OSGi executes all applications in the same JVM. Executing application in separate DVM instances – i.e. separate OS processes – has the advantage of easier resource management and resource reclamation, when applications need to be stopped forcefully. On the other hand, it requires more memory and communication between components is more complex and more expensive.

Component Model

Though both OSGi and Android are component platforms, there are a number of differences between their approaches. Probably the most important difference is the class-sharing ability of OSGi. Android components are executed in separate processes, which are fully isolated. It is not possible for a component to load a class from another one. This means that when a component uses the services of another component, all the service interfaces and parameter classes must be part of the client component as well, which creates a strong coupling between components and leads to unnecessary code duplication, which makes the maintenance very complicated. OSGi uses a classloader-based isolation model, which allows the components (bundles in OSGi terminology) to selectively export some of their internal packages to other bundles. Bundles can declare their package dependencies and the framework is responsible for matching the required and provided packages and make sure that the system is consistent. These mechanisms ensure that there’s no need to duplicate code among bundles and it helps to reduce the coupling of bundles and simplifies maintenance.

A related difference between the two models is component versioning. In OSGi, everything is versioned, while Android provides no support for versioning at all. Though at first glance, the extensive use of versioning may seem to be annoying in OSGi, the use of version numbers and version ranges enables the platform to very elaborately manage dependencies between components and thereby ensure that the whole system is in a consistent shape. This is extremely important for post-shipment maintenance of the platform.

Service Model

The key difference between the two platform’s service models is the service access. In OSGi, services are lightweight. They are accessed using direct method calls, they are easy and cheap to use. In Android, services are heavyweight. They are accessed using inter-process communication, which makes service access slower and more expensive. This leads to a different style of using services. In OSGi, services are used extensively and they play a very important role in keeping components lightweight and loosely coupled. In Android, services are coarse grained and will likely be used much less frequently. While in OSGi services can be used as plugins to other applications, in Android they are closer to the traditional web service model.

Application Model

Android defines its own application model. Applications can be constructed from components of four types. Activities are components, which interact with the device user. Services are background execution tasks. Content Providers are data stores and Intent Listeners are event handlers for system-wide events.

OSGi is application model agnostic. It defines a component model, where components – bundles – have a lifecycle, but it doesn’t define a concrete application model. Rather, it can host a number of application model. Eclipse Foundation defined (embedded) Rich Client Platform, an application model based on OSGi bundles. JSR-232 defines the Foreign Application Model, which allows OSGi to host any existing application model. This is particularly interesting in the light of the next wave of mobile application fragmentation. The number of open mobile application platforms grows rapidly. A variety of different Linux systems (LiMO, Qt, etc.) and Java platforms (Android, JavaFx, CDC Java) add to the well known “oldies” like MIDP, S60 and Win Mobile. How could a carrier or an enterprise ever support such a fleet? OSGi is one answer – pick the application model you like and run it on any platform!

Manageability

One of the key requirements for mobile devices – especially in the smart-phone segment – is remote manageability (often also referred to as MDM, Mobile Device Management). MDM includes device configuration, application deployment and maintenance, status monitoring, data backup and replication services. While device complexity, use cases and volumes increase, the ability to remotely manage devices becomes vital for mobile operators and enterprises. JSR-232 defines a mobile service platform, which is designed from the ground up to support device management. As a result, a device administrator is in full control of all components running on the device, he can monitor and control all aspects of the device without requiring the application developer to deal with this complexity. Device management is not visible in Android. Presumably, it is left up to OEMs and operators to take care of. Though a platform should make MDM as transparent to developers as possible, still there are some aspects developers are concerned with:

• Versioning – it is a simple feature but it’s the key for manageability. Without versioning support, it is impossible to manage updates and dependencies.
• Management-related APIs – though some basic APIs (configuration, logging) are present, there are a number of APIs missing, like deployment, lifecycle management or monitoring.

How can enterprises update their Android devices with a newer application version?

Standards

An important difference between the two platforms is their grounding on standards. OSGi is a standard that has been developed for ten years and reached a high level of maturity. It has been adopted by a number of JSR in JCP and there are number of independent commercial and open source implementations, optimized for different fields of use. In addition, the OSGi Alliance has very strong backwards compatibility requirements.

Android is an open source initiative, where APIs are defined by the implementation itself, which is currently managed by a single company. Though this approach is a lot more flexible, the lack of a specification standard, the lack of backwards compatibility and the lack of acceptance tests bear significant fragmentation risks to the community. How does Android look like tomorrow?

Does Open Mean Undefined?

The biggest challenge of comparing Android to another platform is the large number of open questions. Android so far published the SDK for application developers, which focuses on the areas that Google thinks are of developers’ concern. As long as you want to develop simple end user applications, you probably have what you need. But if you happen to develop a complex application package, maybe an enterprise application or an application suite, where security, deployment, configuration and other management functions are important, you realize that all these are left open i.e. the platform doesn’t specify them and you have to build your application on assumptions. Cross-implementation compatibility of Android will be an interesting topic to observe.

Conclusion

The two platforms give very different solutions for the same question. Process-based isolation model in Android is an advantage in resource management on the other hand the lack of class-sharing ability seriously limits the sharing of components and makes platform management very difficult. The lack of versioning and lack of management APIs is a further limitation. Presumably, OEMs will provide some solutions for these important requirements; however those will be proprietary and will lead to fragmentation of the platform. The lack of standard and acceptance testing also increase the fragmentation risk. Though Android has some promising features, there seems to be a long way to go to reach maturity.