Analysis: Google's Android Beta Shows Promise

That point could be driven home again this week when Apple releases its iPhone SDK, raising the competition in the rapidly expanding mobile platforms arena.

Google's Android, which the search giant updated this week, is far more sophisticated than Google's Gadgets for mobile devices and offers more hardware dependent code. The Android SDK is platform independent and supports G3, Bluetooth, EDGE and GSM protocols, including GPS, cameras and other embedded hardware. However, all of the protocols are not fully supported. Reviewers did not see any updates on the telephony API.

What sets Android apart from competitors is its deceptive use of Java as a hardware neutral platform. The framework rides on top of the Dalvik virtual machine. Dalvik is a curious VM because it is not a true Java VM but it consumes Java source code. Dalvik, instead, creates its own file format. This was probably Google's brainy move to circumvent Sun's Java Micro Edition (JME) license. Sun may be out of luck on this one.

The departure from Java bytecode might help Google in the long run if the company chooses to support other languages such as C/C++ and Python. The bytecode neutrality hints that Google could create its own ".Net"-like language independent platform for mobile devices.

Conversely, setting on Java might prove to be a hindrance. (Steve Jobs made headlines last year when he said Apple woudn't use Java on the iPhone, and referred to the programming language as a "ball and chain.")

VMs are notoriously slow in mobile devices because of the nature of processing code outside of the native hardware. C/C++ has traditionally been the lingua franca of mobile devices. In the meantime, the new bytecode might present a problem for solution providers that are migrating JME code into Android. Moreover, porting libraries may present the big the biggest headache for solution providers.

With close access to the hardware, Android developers have done some cool work by simplifying communication between applications running on the same device. This is a complex task because processes in mobile devices typically run in their own memory space. Android provides a definition language for inter-process communication so that data can be transferred between applications with few lines of code. The interface definition language also simplifies data traces between applications when debugging.

Android supports high-level resources for drawing and styling applications, including a XML based UI model. The XML UI construction provides developers with a non-programmatic view of UI panes. Application themes also can be defined in XML. This is an awesome way to track changes to UIs because it eliminates lots of headaches when debugging because developers only have to work with a single method in Java code. However, XML is bit tedious to trace visually, so we recommend using editors that are XML aware.

One key requirement for Android to claim market independence is having a neutral debugger by its side. To some extent, Android succeeded because the debugger works on emulators as well as devices. The Android debugger supports port forwarding so that applications can be scanned independently. The debugger runs VMs for each port connected to a process, so that processes run in their own memory space and be toggled independently. The debugger supports threads and garbage collection notices. Android also comes with its own emulator that runs on multiple Oses. The emulator supports networking, SMS and telephony emulation.

Earlier this week, Core Security reported the Android framework is using old media libraries with known security flaws. Core also stated that the framework introduces these vulnerabilities. The fix will require not only updating the libraries but also the framework itself.

At this time, it is unclear which smartphones and lesser handhelds will work with Android but we expect that most mobile 5/6 hardware should work. Keep in mind that Android runs on top of Linux. With the market hungrier for richer user interactivity, Android may not be agile enough to satisfy short development cycles that's needed to make an impact on the market. Android has the backing of major players in the industry.

On its Android developer blog, Google just announced an apps-for-android Wiki to showcase sample applications. Well, the samples were missing. Given the maturity of the product before the purchase and now that is at m5 stage, we need to see examples so that average developers can test the framework. And other languages will be fine too.