The picture on the emulator Web site certainly looks intriguing. That was my first impression of Android, Google’s new operating system for handheld devices. The image I saw reminded me of Windows Vista, with a clock gadget and some folder icons on it.
To give Android a test run, I installed the emulator on my Windows machine. In this case, the emulator looks like a handheld device, and it has the entire Android OS running inside this “virtual device.” This is a way to actually try out the software without having a device at hand that can run Android. The emulator is a full ARM machine code emulator and an Android version of the Linux kernel, as well as supporting libraries.
Google Android was built for mobile devices, including phones. As such, it has telephony capabilities built into it. From my own experience, it’s vital that they get this part right.
I recently wrote an article for one of eWEEK’s sister publications touching on how to develop your own phone software for Windows Mobile. The reason was that the particular device I use is, at best, cumbersome. The phone program was written not by Microsoft but by the company that built the device, and it doesn’t fit together with the rest of the device.
The physical aspects of the phone hardware, the Windows Mobile operating system and the phone system combine to form a cumber??Ãsome, complicated phone experi??Ãence (such as when I bump the browser button and the browser starts up just as I need to unmute the call-and can’t). For this single reason, I’ve considered ditching it and going back to a more tradi??Ãtional phone. But at first I tried to write my own application.
I figured out how, and wrote an article about it, but it involved a sig??Ãnificant amount of coding, as well as one huge drawback: I couldn’t replace the existing phone app. The existing one is still there and I need to manually start my own. That gets to one of the fundamentals of Google Android.
Before getting into some of the features hands-on, let’s briefly look at the primary features Google lists on its main Android page:
Apps without borders: Early Mobile devices essentially allowed a single application to take over the device while running. In Android, however, apps can all work together with each other, “announcing” their capabilities to other applications. But even further, the applications can make use of all the features of the phone.
For example, one Google engineer created an application that uses the phone’s camera as a bar??Ãcode scanner. You hold the camera over a barcode, snap a photo, and the application will process the information in the barcode. But the application is also a widget of sorts in that other applications can use it to scan barcodes. This fea??Ãture is called “publishing intents,” where one application announces its services to other applications. In this particular example, another engineer created a personal book database so he can keep track of the books he owns. To get the informa??Ãtion, his program uses the barcode scanner, letting the user scan the barcode printed on the back of the book. The book application gets the book’s ISBN and then goes online and downloads the information about the book.
Apps can run in parallel: Today’s handheld devices are far, far more powerful than those that were devel??Ãoped in the early days of mobile OSes-in fact, they’re probably more powerful than the desktop computers were back then. As such, there’s no reason not to include full parallel and multi-threaded appli??Ãcations in today’s mobile devices, including the scheduling of back??Ãground tasks. Kudos to Google for including this.