How Google's Android would--could?--Stand out from the mobility pack.
Printer-friendly version Email this CRN article
Google Inc.'s purchase of mobile phone platform Android was more for the talent than for the mobility SDK that uses its name. With plenty of competition from small startups, open source projects from Nokia Inc., Intel Corp. and a plethora of APIs for just about every phone on the market, Google has its work cut out to gain search or any application dominance on the mobility space.
Android—which Mountain View, Calif.-based Google updated earlier this month—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, not all of the protocols are fully supported. Reviewers from the CRN Test Center didn't 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. The choice of Dalvik is curious because it's 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 Microsystems Inc.'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, settling on Java might prove to be a hindrance. 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 biggest headache for solution providers.
With close access to the hardware, Android developers have attempted to simplify 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 interprocess 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 nonprogrammatic view of UI panes. Application themes also can be defined in XML, which is a great way to track changes to UIs because it eliminates lots of headaches when debugging as developers only have to work with a single method in Java code. However, XML is a bit tedious to trace visually, so the Test Center recommends using editors that are XML-aware.
A Bug's Life
One key requirement for Android to claim market independence is to have a neutral debugger by its side. To some extent, Android succeeds because its 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 can run in their own memory space and be toggled independently, and it also supports threads and garbage collection notices. Android also comes with its own emulator that runs on multiple operating systems and supports networking, SMS and telephony emulation.
At the moment, it's unclear which smartphones and lesser handhelds will be compatible with Android but 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 are needed to make an impact on the market. What Android does have, however, is the backing of major industry players.
On its Android developer blog, Google this month announced an apps-for-Android Wiki to showcase sample applications. At press time, those alleged samples were missing. Given the product's maturity before the purchase and now that it's at m5 stage, it would be helpful to see examples so that average developers can test the framework and ensure that other languages will be fine too.