Deeper look into Google Android 1.5. Android 1.5 UI and Functionality

Google Android is gaining popularity by leaps and bounds inspiring Google to improving Android in terms of user interface UI and functionality. Google Android 1.5 is expected to come by end of April and the enhancements are quite visible. First of all Google is planning some noticeable changes to its user interface for Android 1.5. Following are few of the screen shots of Android early days user interface, there might be few additional changes in the final UI.

android-15-screenshotsThis is what it will look like if you try to add a new contact to your list. The user interface for new Google Android 1.5 is looking similar to iPhone applications and i think Google is trying hard to make it a standard set which is already familiar to many iPhone users.

Check how they have made the UI different and less cumbersome, the first image is in Android 1.1 and the second image is how the Add Contact will look in Android 1.5. There are other important changes as well which i am listing below.


You can see in this example that the buttons and checkboxes have a new appearance. Even though these changes do not affect binary nor source compatibility, they might still break the UI of your apps. As part of the UI refresh, the minimum size of some of the widgets has changed. For instance, Android 1.1 buttons have a minimum size of 44×48 pixels whereas Android 1.5 buttons now have a minimum size of 24×48 pixels. The image below compares the sizes of Android 1.1 buttons with Android 1.5 buttons.

android-button-gridIf you rely on the button’s minimum size, then the layout of your application may not be the same in Android 1.5 as it was in Android 1.1 because of this change. This would happen for instance if you created a grid of buttons using LinearLayout and relying on the minimum size yielded by wrap_content to align the buttons properly.

This layout could easily be fixed by using the android:layout_weightattribute or by replacing the LinearLayout containers with a TableLayout.

This example is probably the worst-case UI issue you may encounter when running your application on Android 1.5. Other changes introduced in Android 1.5, especially bug fixes in the layout views, may also impact your application—especially if it is relying on faulty/buggy behavior of the UI framework.

Consider all the options carefully before upgrading as the new UI may break your existing application. Buttons and check boxes have been tweaked with a simpler, streamlined look that would seem to make it easier to sort through various fields but could present problems for application developers who wrote their apps with the older button fields in mind. Of course, that’s why companies release things in beta, and the tweaks should be relatively easy for developers to incorporate into their apps before the OS goes live. It shows, however, that the UI for Android is still very much a work in progress and could evolve further before Android 2.0 comes out.

Google Android 1.5 Software Developer Kit (SDK)

Google Android 1.5 Software Developer Kit (SDK) is released for the programmers. Now they have access to several new features, such as video support and a faster browser that will appear in a forthcoming version of the company’s open-source mobile-phone operating system. Google Open Handset Alliance is here to stay and they are competing against Apple’s iPhone OS, Nokia’s Symbian, and Microsoft’s Windows Mobile. HTC is the only maker who is providing handsets more will come as the time progresses.

Following are the features which are incorporated in Google Android 1.5 release:

  • Video recording and playback, and videos can be uploaded to YouTube.
  • Stereo Bluetooth and auto-pairing for better Bluetooth headset support.
  • “Much faster” acquisition of location through the GPS system.
  • A “soft” screen-based keyboard.
  • A web browser with the latest WebKit technology, including the Squirrelfish technology for faster JavaScript. The browser also includes copy-and-paste support, search within the page, the unified search and address bar that debuted in Google’s Chrome browser, and faster scrolling.
  • More widgets on the home screen, including a music player and picture frame, along with the current search and clock widgets.
  • User interface improvements to messaging, Gmail, calendar, browser and other applications. The Gmail application supports batch operations so multiple messages can be deleted or archived at once, for example.
  • Applications can rotate when the phone’s accelerometer detects a new orientation.
  • Faster camera start-up and operation. Photos can be uploaded to Google’s Picasa photo-sharing site.
  • User photos in the contacts application.

There are more changes which are under progress too, including the new Linux kernel version, 2.6.27. Android applications run at a higher level, though, using a variation of the Java technology for writing and running programs, and here there are changes too. Developers will be able to tap into several new application programming interfaces, providing easier support for a number of phone features:

  • APIs for recording and playing back audio and video.
  • A text prediction engine to speed typing.
  • Some support for the OpenGL graphics technology.
  • A framework for speech recognition.
  • APIs for widgets on the home screen and frameworks for various widgets.
  • A framework to make it easier for background processes to interact with running applications’ interface processes.

Google Android 1.5 is looking great but its expected to come out by end of April so be prepared and gather all the resources to get going.

Have you started working with Android 1.5? If yes, then please share your experiences, problems etc. with us. If you’ve got any thoughts, comments or suggestions for things we could add, leave a comment! Also please Subscribe to our RSS for latest tips, tricks and examples on cutting edge stuff.

Android Underlying Source Code Open for Public

android_phone_source_codeGoogle Android is talk of the town and now its time when the underlying source code is shared with the community. Its not more than a year when Google announced their open source phone operating system Android. The Android Open Source Project site includes a project list, a feature description, guides to the roles people can have in the project and how to contribute, and of course the Android source code itself.

Google has one team of programmers building the software and another professional services group to help support phone makers building Android phones. Now, though, as T-Mobile’s G1 arrives on the market, Google hopes to multiply that by drawing upon the collective energy of outside contributors to the project.

“Our plan is a launching point for a much more vibrant open source community,” said Rich Miner, vice president of Google’s mobile platforms business. “For the past almost four years, this has been a large effort between Google and our partners. There have been a lot of people working on the code, but that’s going to be multiplied by several orders of magnitude.”

Open-source software can be freely used, modified, and redistributed by anyone, freedoms that make it a daunting competitor to proprietary software companies that charge for the code.

Although open source software rarely has been the sole basis for a thriving company, it can be a powerful tool to aid a broader agenda. Sophisticated technology companies such as IBM, Oracle, and even Apple often subsidize open source projects for that reason, and Android fits into that category.

Android beyond the T-Mobile G1
Four members of the Open Handset Alliance, which co-developed the Android software, build mobile phones: HTC, which build the T-Mobile G1, as well as Motorola, LG Electronics, and Samsung. And another alliance member, Wind River Systems, believes Android will power consumer electronics devices including set-top boxes and in-car computing systems.

Now that Android is open source software, though, other manufacturers may use it, and Miner said they will. Indeed, Wind River said Kyocera was building an Android phone. “Think what happed to PC clones in the 1980s and 1990s timeframe. We’re starting to see coming out of Taiwan the equivalent of a Micron motherboard,” inexpensive mobile phone hardware that now can be made useful with Android, Miner said.

This time, though, Microsoft Windows isn’t going to be the operating system that spreads like wildfire, if Google has anything to do with it. “There are a billion mobile phones sold every year that don’t have a good, highly connected mobile operating system,” Miner said. Android is intended as an answer to that issue, and one that sidesteps the controls over software by rival operating systems such as Windows Mobile and Nokia’s Symbian, he said.

“We feel fairly strongly, and it’s resonating loudly through the industry, that innovation is maximized when no one entity controls a platform,” Miner said. Adding open to open source

It’s a maxim among open source fans that projects that begin as open source fare better as such than those that begin as proprietary projects and are retrofitted with an open source governance. For example, the Linux kernel project has thrived as an open source project since its earliest days, with various different ways people or companies can involve themselves, but it took several painful years before the Mozilla open source Netscape project finally became relevant in the form of Firefox.

And some open source fans have criticised Google for being too closed with Android in its early stages. But Miner insists that Android, while initially developed in-house, is indeed a true open source project.

“It was built with the intention of open-sourcing it,” Miner said, pointing specifically to project details such as its architecture, comments in the code, and the code’s structure. “We decided we didn’t need to build release 1.0 as open source … We engineered 1.0 as a best-in-class, fully staffed, engineered product. Having delivered that, we think it’s time to start leveraging the benefits of what open source can bring.

The code is managed by the Android Open Source Project, and anyone contributing code to the project must sign a Contributor’s License Agreement, Google said. The project is separate from Google, the company said, but it’s not immediately clear just how independent.

Android Ingredients
Android is big, with 11 million lines of code, about 8.6 million of them open source according to an earlier interview with project leader Andy Rubin. But what’s in Android exactly? At the foundation is a stripped-down Linux kernel that communicates with a phone’s hardware, and Android supports multiple phone processors. Much of the Android work, though, takes place one level above that.

On conventional computers, software runs directly on that operating system kernel. Android, though, includes a “virtual machine” software layer called Dalvik that runs applications written in the Java programming language. Dalvik isn’t a part of the mainstream Java community built by Sun Microsystems, but it’s very close from a programming perspective.

A host of built-in applications are available to run on Dalvik, including software for dialing the phone, using online maps, browsing the Web, using e-mail and Gmail, and managing contacts. In addition, Open Handset Alliance partners contributed software, including a speech-recognition engine from Nuance and audio and video decoder software from Packet Video.

With this flexibility, though, can comes chaos. Google said it will offer a compatibility test suite to ensure various versions of Android remain compatible.

One advantage of using this virtual machine technology is that Android programmers don’t have to worry about what underlying hardware a phone uses. That’s an important factor when it comes to sharing software, most notably through Google’s Android Market download service, because programmers won’t have build different versions of software for one phone processor or another, and people won’t have to know this obscure information either.

However, Dalvik doesn’t get around all the complexities of the computing world. For example, a game might require a touch screen, but not all Android phones necessarily will have that higher-end feature. For that reason, Google plans to build a profiling feature into the Android Market so users will be able to download only software appropriate for their model. With only one Android phone on the market until 2009, that complication is a moot point for now.

Leave me a comment and let me hear your opinion. If you’ve got any thoughts, comments or suggestions for things we could add, leave a comment! Also please Subscribe to our RSS for latest tips, tricks and examples on cutting edge stuff.

Mobile Web Wars Videos: Does Anybody Care About Android?

A week ago, I put together a roundtable about the upcoming mobile platform wars between the iPhone, Google’s Android, and older platforms like Nokia’s. One thing I discovered as I was organizing the event was that it was really hard to find anyone developing Android apps other than the 50 people who won the Android Developer’s Challenge. (We tried to get someone from Android on the panel, but Google declined to participate).

Most of the 20 CEOs, developers and VCs on the roundtable were more interested in the iPhone, Nokia, and other platforms that actually exist as something other than a software emulation. Their attitude seemed to be: Show me the phones.

Pandora CTO Tony Conrad went even further, saying, “I need Android like I need a hole in the head.” To which Michael responded: “As soon as it launches, you are going to be kissing Google’s ass and you are going to be launching on their platform.” Here’s a clip with Tony and Michael going at it:

Another debate was whether the iPhone is really anything new. AdMob CEO Omar Hamoui (in T-shirt) argued that it indeed represents a fundamental shift because it is the first time most people are actually using the mobile Web, regardless of how long it’s been around. (This was basically the premise of the panel). Skydeck CEO Jason Devitt (in striped shirt) pointed out that the existing mobile Web is already a fairly large market, citing a figure of $700 million spent on mobile games alone. Devitt, though, is old-school (he previously founded Vindigo), and even he admits that he doesn’t browse the Web on most phones other than the Phone.

Source :

Google Android vs. iPhone: Same as Microsoft vs. Macintosh ?

android_vs_iphone_thumb4.jpegBack in 1984, Apple was on top of the computing world with top-notch sexy hardware and it partnered with Microsoft for some top-notch [not so] sexy practical software. It was a winning combination for both Apple and Microsoft. Microsoft’s strategy in 1984 was hardware agnostic making its software available on any popular platform. Apple’s strategy in 1984 was holistic. We’ll call the period between 1984 and 2000, Round 1.

In Round 1, it turned out that Microsoft’s strategy was the clear-cut winner. By being hardware agnostic, hardware vendors competed with one-another to drive down the price of hardware much faster than anyone could have imagined. Clone prices fell so fast and so much lower than the price of a Macintosh that it simply became impractical to own a Mac. Software vendors also took note and quickly the non-Mac-PC became the standard. Apple nearly died.

2007 set off Round 2. This time around it’s in the cell phone business. Once again, Apple is on top of the Cell Phone game with top-notch sexy hardware and it has partnered with Google this time for some top-notch [not so] sexy practical software (think Google Maps, YouTube and other web-based Google Apps for the iPhone). Once again, it’s a winning partnership for both Apple and Google. And Once again, Google’s strategy is exactly the same to that of Microsoft in 1984: stay hardware agnostic. Apple’s strategy is also identical to its own strategy back in 1984: stay holistic. Round 2 has begun.

The similarities are eery. In 1984, while Microsoft was building the most popular application software on the Mac, it had begun a similar hardware-agnostic operating system (Windows) on its own. In 2007, while Google has some of the most popular application software on iPhone, it has begun a similar hardware agnostic Cell-Phone operating system (Android) on its own. Apple’s strategy has not changed a single bit. It refuses to license its operating system or any other technology while it continues to want more and more control over the entirety of the experience. The iPhone in 2007 has set off a brand new race much like the original Macintosh did in 1984. Interestingly, 24 years later, the strategies are still identical on both sides.

So will Round 2 end in the same way with Google’s Android prevailing due to exceptionally cheap phones that are sure to emerge using Android? Maybe not. There is one key difference between Round 1 & Round 2: Steve Jobs. Steve didn’t get to finish fighting the strategy that he helped establish for Apple in Round 1. He left Apple in 1985. So there’s no telling how things would have turned out. The fact that Apple lost round 1 may have taught everyone a lesson and it might falsely embolden Google to think Microsoft’s winning strategy was the better strategy. After all, Google’s chief, Eric Schmit, has been learning from (and losing to) Microsoft for 20+ years. Eric is now using Microsoft’s own strategy to successfully beat them. Google is the new Microsoft.

But this time around Steve is much smarter than he was in 1984. So smart in fact, that he’s resurrected Round 1 from the dead and may still pull off a win (the Mac is coming back). It’s possible that Steve & Apple’s holistic approach will still be the winning approach for Round 1, assuming you extend round 1 to at least 2015. But in Round 2 Apple’s chances are a lot better. Everybody is at the beginning of the race. There are no clear winners and just like in 1984, Apple has a major lead. It’ll be interesting to see what happens.

I’m curious to know your thoughts on:

  • Who you think will win Round 2: will it be Google with its Android or Apple with its iPhone?
  • Is Round 1 over in your view or will the Mac eventually beat out Windows-based PCs in market share?
  • Is Microsoft even a player in Round 2? (I would never recommend a current Windows-Mobile phone to my worst enemy – so do they even stand a chance?)

A developer’s perspective on Google’s Android

On Monday, November 12, 2007, Google released Android, a complete Linux based software stack aimed directly at the cell phone marketplace. I’ll let others talk about what it means for other players in the marketplace, the intricacies of GPL2 vs the Apache License, etc. This article dives straight into the heart of the SDK and API itself, summarizing some of the documentation provided by Google, then jumping into building an application using Android.

Android Emulator

(Click to enlarge)

So, what Is Android?

Android is a complete software stack for mobile devices such as cell phones, PDAs and high end MP3 players. The software stack is split into four layers:

  • The application layer
  • The application framework
  • The libraries and runtime
  • The kernel

Cell phone users obviously work with applications in the application layer. Android developers write those applications using the application framework. Unlike many embedded operating environments, Android applications are all equal — that is, the applications that come with the phone are no different than those that any developer writes. In fact, using the IntentFilter API, any application can handle any event that the user or system can generate. This sounds a bit scary at first, but Android has a well thought-out security model based on Unix file system permissions that assure applications have only those abilities that cell phone owner gave them at install time. The framework is supported by numerous open source libraries such as openssl, sqlite and libc. It is also supported by the Android core libraries — more on that in a second. At the bottom of the stack sits the Linux 2.6 kernel, providing the low level hardware interfaces that we all expect from a kernel. This is a Unix based system — that is, the Unix C APIs are available — but don’t expect to drop to a shell and start executing shell scripts with your old friends grep and awk. Most of the Unix utilities are simply not there. Instead Android supplies a well thought out API for writing applications — in Java using the Android core libraries.

That’s right, Android applications are almost exclusively written in Java. The Android core library is a big .jar file that is supported by the Dalvik Virtual Machine — a fast and efficient JVM work-alike that enables java-coded applications to work on the Android cell phone. This is similar to, but not the same as using Sun’s JVM directly.

Building your development environment

Google provides three versions of the SDK; one for Windows, one for Mac OSX (intel) and one for Linux (x86). They also provide two development environments — one is Eclipse based, and the other is a “roll your own.” The Eclipse based environment is quite feature-rich and should suffice for most developers. There is no reason that you can’t use both Eclipse and “roll your own.”

If you get stuck in eclipse (like I did), you may find yourself dropping to the command-line interfaces to see what’s really going on. However for this article, I’ll assume that you’re using the Eclipse IDE for your Android software development needs. Once you’ve downloaded the Android SDK, Eclipse and the Eclipse Plugin, you should work through the first few sections of Google’s install document (System and Software Requirements, Installing the SDK, Installing the Eclipse Plugin). I’d leave the rest of the document for later as it does get quite detailed quickly.

Read the Friendly Manual

Google has done a good job of writing a lot of documentation for Android. However, there isn’t a great way of knowing what’s important to read now vs. what can wait. Here are some links to documents that are important to understand what Android is and how to develop applications using it. If you read them in the order listed, then you’ll gain understanding more quickly as you read increasingly detailed documents. Note that a lot of the documentation is available both online and in the SDK_ROOT/docs/index.html directory on your machine. If you have a fast enough connection, I would suggest using the on-line versions since they will be more up to date.

Here’s the order in which I suggest you read the documentation:

  • What is Android? Explains what Android is and gives a high-level overview of its features and architecture. Don’t dive into the links just yet — just get a feel for this overall document.
  • Read the Anatomy of an Android Application page. This details the four building blocks of an Android app: Activity, Intent Receiver, Service and Content Provider. Again, don’t follow the links just yet — just get an overview of the architecture. You may want to reread sections on Activities and Intent Receivers — gaining an understanding of these concepts is critical to understanding how to build an Android application. If you don’t get it yet, you’ll see it again when you go through the Notepad Application Tutorial.
  • Next read the Development Tools document. Again — just get a flavor, don’t dive into the detail yet.
  • Read the Lifecycle of an Android Application page.
  • Now, finally, it’s time to get your hands dirty. Work through the Hello Android page. Make sure you actually do it using Eclipse.
Note: I had a problem here. The first time I ran the application, it worked fine. However on subsequent runs my application would not appear on the emulator. I killed and restarted the emulator, killed and restarted eclipse several times — no joy. Finally, somewhat frustrated, I was going to re-install everything. However before I did, I found an invisible instance of the Android Debug Bridge (adb) running. I killed it and everything worked again. I thought I had to close the emulator after each run of an application, but this turns out not to be the case. When I closed the emulator after my first run, it left the instance of adb running, which interfered with the subsequent instances.
  • Now go back and read the rest of the Installing the SDK document — the bottom half of it details some great debugging tips and features.
  • Next, go through the Notepad Application Tutorial. This is where the rubber really meets the road. If you spend the time to go through this series of exercises and really understand the code, you will be well on your way to becoming an Android expert.
  • Read the Developing Android Applications pages. This will take some time — these articles go into a lot of detail about several topics including how to implement the UI, data storage/retrieval and the security model.
  • Finally, go back through this list and follow the links in the previous documents as topics interest you.

There’s a lot of documentation, but if flows together nicely, reflecting the architecture of the environment.

Dissecting the SDK

Whenever I download an SDK, I like to take a look at the files I’ve installed. Often, there is a wealth of information hidden in the SDK itself that is not readily visible from the documentation. So here’s what you’ll find in the Android SDK on a Windows machine:

  • android.jar – The Android application framework. Unzipping this jar reveals the entire class structure and all of the supporting classes of the framework. Currently there is no source.
  • docs – 100 megabytes worth of documentation, samples, etc.
  • samples – Six different sample applications – ApiDemos, HelloActivity, LunarLander, NotePad, SkeletonApp and Snake
  • tools – the various SDK binaries such as aapt, acp, and emulator live here.
    • lib – various templates and supporting jar files live in this directory
      • activityCreator – the activityCreator python application lives here.
      • images – The Linux file system images are found in this directory: ramdis.img, system.img and userdata.img. They are YAFFS2 file system images, so I couldn’t open them without additional kernel support on my Fedora system.
        • skins – supporting emulator graphics for HVGA and QVGA screens in both landscape and portrait format.

Exercising the SDK

Now that you have read the documentation and set up and debugged a simple project, it’s time to look at some real code. Since Google has provided us with several sample applications, the best place to begin is by examining them.

  1. If you have not already done so, execute the first few sections of Google’s install document. Stop after you’ve installed the Eclipse plugin successfully.
  2. Now work through the Hello Android page if you haven’t already. This will get you started working with Android applications and the debugger. Note that it’s probably a good idea to create a new workspace for your Android projects if you already use Eclipse.
  3. Next we’re going to set up Eclipse projects for each of the sample applications. You can never have too much sample code. I’ll walk through setting up the Lunar Lander example and leave it as an exercise to the reader to set up the rest.
    1. Bring up the same Eclipse workspace that you used for the Hello Android, and close the project (Right click on the project in package explorer->Close Project).
    2. File->New->Android Project
    3. Project Name: LunarLander
    4. Click the “Create Project from existing source” radio button
    5. Browse to the samples/LunarLander directory in the SDK. If you find the right directory, the Properties fields will auto-fill with the correct information from the Package.
    6. Click Finish
    7. Bring up Eclipse’s Console window (Window->Show View->Console) if it’s not already visible in a tab at the bottom of the screen. It will show you the build process that Eclipse went through to create the application.
    8. Create a Run Configuration: Run->Open Run Dialog
    9. Highlight “Android Application” in the treeview to the left.
    10. Click the “New button”.
    11. Name: Lunar Lander
    12. Click the Browse button next to Project
    13. Double-click the LunarLander project and hit OK
    14. Click the down arrow for the Activity and choose the one and only Activity:
    15. Click Apply
    16. Click Run
    17. Switch to the Emulator and play a few rounds of Lunar Lander. Kinda fun.

Repeat for the other applications in the samples directory. This exercise should only take a few minutes — besides, the Snake game is fun too! If you’ve taken the time to go through the Notepad Application Tutorial, then you’ll be familiar with the NotePad sample — however, the NotePad sample is fully developed and has features beyond the NotePad developed during the Tutorial.

A File System Explorer Application

Finally, we’ll use our new understanding of the Android to develop a simple file system explorer. The version in this article is pretty simple, but it can serve as a jumping-off point for a more serious application down the road.


Before we start writing code, let’s think about what a reasonable file system browser should do. It should

  • Phase I features
    • Show a list of files and directories
    • Allow the user to navigate through the directory structure by clicking on directories
    • Warn the user that he has clicked on a file
  • Phase II features
    • Allow the user to display a dump of a file when it is clicked
    • Use a tree view instead of a simple list
    • Show a dialog box with the filesystem information (size, permissions, etc) when the user clicks on an icon next to each file
    • Give this application permissions to read any file on the file system
  • Phase III features
    • Do all of phase II with pretty graphics, such as thumbnails, instead of boring dropdowns and list boxes
    • Execute applications that we understand, such as mp3 files


This article will only cover Phase I of the project — but when we’re done, we’ll have a functional file system explorer in just a few dozen lines of code.

To proceed with this hands-on example, click here.

New Android Project
(Click to enlarge)
It works!

If you clicked above to follow the hands-on example, you found that in about twenty lines of Java, and a small amount of XML, you’ve created a useful little application that will allow you to explore the Android’s file system. For example, I found the ringtones in /system/media/audio/ringtones, as shown below.

Oooh, ringtones
(Click to enlarge)

As I mentioned in the design section, a lot can be done with this application, and we’ve hardly touched the surface of what you can do with the Android application environment. There’s three billion cell phones out there. I suspect Google will get their fair share of them, so start cranking out code!


Android is a well-engineered development environment. Writing an Eclipse plug-in was a smart move by Google — one that should be emulated by other SDK developers. Eclipse gives a developer and environment where he can really think about the business problem without worrying about the boring details. Adding the functionality of the plugin helps developers just sit down and start coding — without having to worry about all the ins and outs of configuration files and the like.


Android is brand new to the general developer’s world. As I write this, it’s Wednesday, and the SDK came out on Monday of this week. Since it’s brand new, there are some little problems that will have to be solved in the coming releases.

  • Many more examples for the APIs.
  • A more thorough explanation of what does and does not work under the emulator. My first example application was a simple MP3 player.
  • Release the source code. This will make it a lot easier to debug Android applications, as well as write them in the style that the Google developers wrote them.


Theres a lot to like about Android:

  • It’s by Google — so it has a company with some clout behind it.
  • Application Developers write their code in Java. Since the learning curve for Java is much less than that of C/C++/ObjectiveC, there will be many many developers who are eager to start writing applications for Android.
  • The SDK and API are well designed. There is some complexity there, and as I mentioned, the Documentation needs improvement — but a well designed system is easier to understand and learn, even without lots of great examples.

HTC Developing Phone for Android

High Tech Computer (HTC) is developing a mobile phone that will use the open-source Android software created by Google for its operating system. The phone will be called Dream and have a large touchscreen LucidTouch-Profile Feb-08 and full QWERTY keypad. The handset is over 5 inches long and 3 inches wide and has a keypad that swivels out from underneath the

HTC is not the only company that is developing a mobile phone around the Android operating system. Samsung has joined the hunt to create a device that utilizes Android.

HTC was the first company to announce it was building a phone around Android. Other members of the Open Handset Alliance, a group dedicated to promoting Android, are also believed to be developing handsets designed around the operating system. Over 30 companies have joined the Open handset Alliance. Samsung and Motorola are two manufactures who belong to the alliance and may be developing Android phones of their own.

Google Android Developer Challenge Deadline Approaching Quickly

The Android Developer Challenge is proceeding nicely. We’re excited about the interest people have shown so far and have enjoyed talking to everyone working on new Android Apps.

As a quick reminder, the first phase of the challenge will be ending on April 14. In the Android Developer Challenge I, the 50 most promising entries received by April 14 will each receive a $25,000 award to fund further development. Those selected will then be eligible for even greater recognition via ten $275,000 awards and ten $100,000 awards.

Keep working on your applications, and be sure to post in the forums if you have any questions!

David McLaughlin
Android Advocate

Android SDK m5-rc14 now available

Android SDK m5-rc14 now available. There are a couple of changes in m5-rc14 which can be highlight:ed

    * New user interface – As mentioned once it was introduced the m3 version of the Android SDK, we’re continuing to refine the UI that’s available for Android. m5-rc14 replaces the previous placeholder with a new UI, but as before, work on it is still in-progress.
    * Layout animations – Developers can now create layout animations for their applications using the capabilities introduced in the android.view.animation package. Check out the LayoutAnimation*.java files in the APIDemos sample code for examples of how this works.
    * Geo-coding – android.location.Geocoder enables developers to forward and reverse geo-code (i.e. translate an address into a coordinate and vice-versa), and also search for businesses.
    * New media codecs – The MediaPlayer class has added support for the OGG Vorbis, MIDI, XMF, iMelody, RTTL/RTX, and OTA audio file formats.
    * Updated Eclipse plug-in – A new version of ADT is available and provides improvements to the Android developer experience. In particular, check out the new Android Manifest editor.

You can find more information about what’s changed in a couple of documents that have been published. First is an overview of the changes to the Android APIs in API Changes Overview. If you want a more granular view of what’s changed, an API diff between m3-rc37 and m5-rc14 is also available. Finally, Upgrading the SDK provides links to the two previously referenced documents and the release notes, as well as instructions on how to upgrade your development environment.

We still need your help in shaping the platform, so if you find issues with the Android APIs or the developer tools, please let us know through the Android Issue Tracker. If you have general comments or questions, please head on over to the Android groups to get in touch.

We’re looking forward to all the applications that developers will create using this new version of the Android SDK. Of course, you can use m5-rc14 or any older version of the SDK for your Android Developers Challenge submission.

Jason Chen, Developer Advocate
Google Android

Google Android – An Open Handset Alliance Project

The Android platform is a software stack for mobile devices including an operating system, middleware and key applications. Developers can create applications for the platform using the Android SDK. Applications are written using the Java programming language and run on Dalvik, a custom virtual machine designed for embedded use which runs on top of a Linux kernel.

If you want to know how to develop applications for Android, you’re in the right place. This site provides a variety of documentation that will help you learn about Android and develop mobile applications for the platform.

What is Android?

Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.


    * Application framework enabling reuse and replacement of components
    * Dalvik virtual machine optimized for mobile devices
    * Integrated browser based on the open source WebKit engine
    * Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional)
    * SQLite for structured data storage
    * Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
    * GSM Telephony (hardware dependent)
    * Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
    * Camera, GPS, compass, and accelerometer (hardware dependent)
    * Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE


Android will ship with a set of core applications including an email client, SMS program, calendar, maps, browser, contacts, and others. All applications are written using the Java programming language.
Application Framework

Developers have full access to the same framework APIs used by the core applications. The application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework). This same mechanism allows components to be replaced by the user.

Underlying all applications is a set of services and systems, including:

    * A rich and extensible set of Views that can be used to build an application, including lists, grids, text boxes, buttons, and even an embeddable web browser
    * Content Providers that enable applications to access data from other applications (such as Contacts), or to share their own data
    * A Resource Manager, providing access to non-code resources such as localized strings, graphics, and layout files
    * A Notification Manager that enables all applications to display custom alerts in the status bar
    * An Activity Manager that manages the life cycle of applications and provides a common navigation backstack


Android includes a set of C/C++ libraries used by various components of the Android system. These capabilities are exposed to developers through the Android application framework. Some of the core libraries are listed below:

    * System C library – a BSD-derived implementation of the standard C system library (libc), tuned for embedded Linux-based devices
    * Media Libraries – based on PacketVideo’s OpenCORE; the libraries support playback and recording of many popular audio and video formats, as well as static image files, including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG
    * Surface Manager – manages access to the display subsystem and seamlessly composites 2D and 3D graphic layers from multiple applications
    * LibWebCore – a modern web browser engine which powers both the Android browser and an embeddable web view
    * SGL – the underlying 2D graphics engine
    * 3D libraries – an implementation based on OpenGL ES 1.0 APIs; the libraries use either hardware 3D acceleration (where available) or the included, highly optimized 3D software rasterizer
    * FreeType – bitmap and vector font rendering
    * SQLite – a powerful and lightweight relational database engine available to all applications

Android Runtime

Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language.

Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool.

The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level memory management.

Linux Kernel

Android relies on Linux version 2.6 for core system services such as security, memory management, process management, network stack, and driver model. The kernel also acts as an abstraction layer between the hardware and the rest of the software stack.

Download the latest  SDK from here