Inside Google's mobile future

Android is Google's foray into the handheld OS realm. It follows a path trodden by -- among others -- Symbian's Quartz, the SavaJe operating system, and J2ME. In fact, one of Android's stated goals is to overcome some of J2ME's shortcomings. Whether or not Android succeeds, either at that specific goal, or in general, remains to be seen.

This article addresses a specific question: What is it like to work with the Android SDK? And to a lesser extent: What is under the Android hood? As these questions are answered, bear in mind that the version of the Android SDK I used was not in final form. Some of the problems described may have -- in fact, I hope will have -- been corrected by the time you read this. In addition, while Android development is supported on Linux, Mac OS X, and Windows, I did all my testing on Windows systems.

Inside an Android

Peel away Android's carapace, dig down to its marrow, and you'll find a Linux kernel. Libraries are a layer above, a variety of frameworks above that, and a final layer of applications sits on the top. The library layer is home to code for entities such as media processors for playback and recording of audio and video, the core of the Web browser, font rendering, and the SQLite relational database engine. The Android runtime also lives in the library layer.

Above the libraries reside frameworks, which are sets of reusable services and common components available to applications. For example, one sort of framework is a content provider, which is any service that handles the storage and retrieval of data. The application interface into the SQLite engine is a specific instance of a content provider.

Applications run at the top of the OS stack. Android will ship (assuming that it eventually does ship) with a set of core applications, including an e-mail client, a calendar, a Web browser, and more. And, of course, it is toward this topmost layer that all of the faculties of the Android SDK are directed.

When a developer writes an Android application, that developer codes in Java. The Java source is compiled to Java bytecodes, but -- to execute the application on Android -- the developer must execute a tool called dx. This tool converts Java bytecode to what is referred to as dex bytecodes. "Dex" is short for "Dalvik executable," Dalvik being the virtual machine that actually executes Android applications.

From a developer's perspective, Dalvik looks like a Java Virtual Machine, but strictly speaking, Dalvik is not a JVM. As stated above, Dalvik executes dex bytecode, not Java bytecode. And there are differences in the structure of Dalvik class files as compared to Java class files. Nevertheless, for all intents and purposes, building an Android application is really an exercise in building a peculiar sort of Java application.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email ARN
• Follow ARN on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark