18 Apr

On Android and Fragmentation (early 2014)

Due to its origins and philosophy with respect to openness, Android is a fragmented mobile platform. This is illustrated next:


There are different kinds of fragmentation to keep in mind.

Android platform versions. To minimize fragmentation-related headaches, decide early on what versions of Android to support. As you can see above, Gingerbread (introduced in 2011) still commands close to 20% of the Android device distribution (data above is gathered from the new Google Play Store app). It is important to keep in mind is that the more versions you support, the more testing and maintenance and related costs that you will have.

Multiple screen sizes. When creating an Android app, you will have to decide the kinds of devices to support, for example Smartphones, vs. Tablets, each with different sizes and resolutions, and provide the appropriate assets, fonts and layouts that ensures the best possible experience across such different screen characteristics. See Design Apps for Tablets (Android Developers Blog).

Hardware support. Another kind of fragmentation is related to hardware support, for example, the supported sensors and/or UI facilities. Not all devices are created equal and different device manufacturers decide what to include. A couple of examples: not all devices may support the same kind of camera, or may or not provide support for Bluetooth or for that matter, Bluetooth Low Energy (introduced with Android 4.3 (API Level 18). NFC may or not be there. Another example is the Kindle, which is based on Android 2.3 but it doesn’t provide support for many of the hardware sensors or UI facilities found on other Android devices.

Consistent UX Design. Maintaining a consistent design is not necessarily easy and can lead to a fragmentation user experience. Learn and follow the Android Design Guidelines. Google has done a great job documenting the best design guidelines for Android apps. From design principles, to styles and patterns, to building blocks, you should spend time going over these great developer resources by Google.

The good news is that as you can see on the pie-chart above, the market is consolidating on 4.x and newer and devices are getting more consistent. The whole Android reminds me of the Java Micro Edition and Sun Microsystems back then, which wanted to be open with great intentions, but that caused a lot of fragmentation and problems. The answer to this is to enforce consistency across. Google is attempting to do so by “Forcing OEMs To Certify Android Devices With A Recent OS Version If They Want Google Apps“. Let’s keep in mind that the main reason the iPhone and iOS have been so consistent with respect to platforms version, functionality and distribution, is because Apple owns the whole stack (hardware and software). But in an open platform, consistency is very hard to achieve, especially when there is competition within the ecosystem.


Related to this see: 5 Tips to Get Started with Android Development.

16 Jan

Using Android’s Advertising ID

My most recent piece is about Using Android’s Advertising ID (Safari Online Books blog).

The ability to identify users is important for advertising, analytics and other purposes. Android developers typically rely on the Android Device ID or Telephony IDs such as the International Mobile Equipment Identity (IMEI) to uniquely identify users, but these approaches also introduce privacy concerns. Android 4.4 Kitkat introduces a new anonymous identifier for advertising purposes. Referred to as Advertising ID, it provides a user-resettable identifier that helps protect the user’s personal identity.

Read the rest of the blog Using Android’s Advertising ID


27 Nov

Android App Ops is a Step Forward

Update Dec/15/2013: Two weeks after I wrote this piece below, Google removed App Ops... See Android App Ops *WAS* a Step Forward, and stay tuned.

One of Android’s top limitations, one that totally drives me nuts, is its security model, in particular the app permissions model. This is a permission security model where developers (the app) requests permissions, and the user grants permissions during the installation process.

To get an idea of how the Android security model works in general, see an old article of mine titled Understanding security on Android (IBM developerWorks).

The problem with Android’s permission model today is that users are limited two options: 1) grant ALL requested permissions, or 2) not install the app at all.

…and that is a sucky permission model that needs revision.

For example, if I liked a new cool camera app, one that accesses the camera and my location, but I do not want the app to track my location, I have to compromise – either I grant all the permissions, including the ones I am not comfortable with granting, and if I don’t like that, even though I may like the app itself, the alternative is not to install the app at all.

Enter App Ops (Permission Manager)

It was with great excitement (yes, sounds geeky) when I learned about the native App Ops app.

I had totally missed the native App Ops app in Android 4.3 that allows users to grant individual permissions post-app installation. Then I learned the app was removed on Android 4.4. But the good news is that it was not removed, it was just hidden. App developers such as Color Tiger allows you to unhide the native App Ops app. With the native App Ops app I can now control and turn off specific permissions per app!

This of course means that apps must be robust and properly handle the unavailability of restricted, un-granted features — by properly testing for null values and handling security Exceptions — vs. just crashing when it cannot perform the (restricted) functions that have been turned off by the user. Perhaps this is the reason the native App Ops app was hidden by Google for now.

I did a quick test on my Nexus 4 (I finally got my Android 4.4 upgrade) – wrote a simple location-based app/activity and put some breakpoints to test/see this behavior while turning the location permission on/off via the native App Ops app.

Permission Test screenshot

In the case of the LocationManager.getLastKnownLocation(), turning off the Location permission, it returns a null value (which means that the provider is currently disabled). Note that I was expecting a SecurityException to be thrown instead! Hmm, need to think about that. Thus, I will continue researching this and in the meantime, for LocationManager.getLastKnownLocation() seems that all we have to do is to test for null, something you should be doing anyways.

Location loc = locMgr.getLastKnownLocation(LocationManager.GPS_PROVIDER);
if (loc == null)
    return; // Provider is not enabled

In summary, while the native App Ops app is a step forward (for end-users that is), the selection of permissions to grant for a given app, really should be part of the app installation process itself (an alternative is to prompt the user every time the app attempts to use a restricted API – I think I prefer the former). This will require that developers be aware and properly test for scenarios related to restricted features/APIs not being available, and perhaps new documentation related to permissions guidelines for developers. I am looking forward to see this happening.

Oh, and thank you, Color Tiger!!!


04 Nov

Android 4.4 (KitKat) is Here!

Check out the new guest post that I wrote on Android 4.4, for the Safari Books Online blog. It summarizes what is new on Android and related important information.

In this post we will explore the major changes introduced in Android 4.4. Android 4.4 is the newest version of the Android mobile operating system that was released at the end of October 2013. Also known by the codename KitKat, this version brings a number of very important internal memory-related improvements as well as improvements to the user interface, connectivity support, media and security support, and more.

Read Android 4.4 (KitKat) is Here! (source: Safari Books Online).


29 Sep

Android Platform Versions (2012)

Below is a snapshot of the Android platform distribution, as of September 2012.

Android Platforms Sept 2012

As you can see, the majority of the devices out there, close to 60%, are still 2.3 (Gingerbread). This is followed by ICS with close to 21%. Froyo 2.2 is 14%.

I hope that by March (but more likely, summertime or later) of 2013, that by then the majority of the Android devices out there are 4.0+. This would make the Android app developer’s life in general much simpler — by (1) minimizing the number of major Android platforms to deal with, and (2) making it easier/cheaper to implement (or move up to) the recommended Android design guidelines. The result of this includes (1) cheaper to develop/maintain apps, (2) consistent apps per developer, and (3) consistent look/feel/behavior across the app market.

For this to happen, device manufacturers and operators must help transform the above piechart to be mostly 4.0+ Android devices. They can help by literally selling less (and even better, stop selling) Gingerbread/2.3 and older devices. If you look around you will see that operators are still selling Gingerbread devices. And we need Google to have more cojones with respect to this and stimulate, if you will, both the device manufacturers and operators to move forward — this transition is taking forever! (Note: Gingerbread was introduced on December 6, 2010.)

Some customers may leave feedback as “why the app does not follow the Android UI guidelines”, or “why the app doesn’t support the ICS UI paradigm” — but again, 4.0+ is just a smaller fraction of what is out there!

In the meantime, there is the Android Support (Compatibility) library. Also, see Backwards Compatibility (Android Design Patterns).


15 Dec

Article: Introduction to Facebook SDK for Android

Write Facebook apps for the Android platform with the Facebook Android SDK…

You can incorporate Facebook functionality into your own applications. From the mobile perspective, the Facebook Platform supports APIs for mobile web applications, and mobile SDKs for native mobile applications for the iPhone, iPad, and Android platforms. In this article, explore the Facebook Platform APIs and the Facebook SDK for Android, the SDK released by the Facebook mobile team.

See my article Introduction to Facebook APIs (IBM developerWorks) which introduces the Facebook SDK for Android.


30 Nov

Article: Understanding Android local data store APIs

“The ability to store data locally on the mobile device is a critical function for mobile applications that are required to maintain essential information across application-executions or the lifetime of the application. As a developer, you constantly need to store information such as user preferences or application configurations. You must also decide if you need to tap internal or external storage, depending on characteristics, such as access visibility, or if you need to handle more complex, structured types of data. Follow along in this article to learn about Android data storage APIs, specifically the preferences, SQLite, and the internal and external memory APIs.”

See my article Understanding Android local data store APIs (IBM developerWorks) which introduces the different local data store APIs on Android.


29 Oct

Navigation (and maps) the killer app for LBS and Google Maps Nav potential to disrupt the whole Nav systems market


Yes, navigation and maps is the killer app for LBS.

Now it seems that Google Map with support for navigation has the potential to disrupt the whole Nav systems market. And if Google decides to make this new app available across different handsets beyond Android, wow, all the Nav vendors are going to be hurting.

And how can others compete?

Google Maps Nav is a free app, the traditional Map app but now with real-time always up to date maps and nav info, turn by turn directions, live traffic information and even street view and other goodies such as Layers of information! You can see the video, and read TechCrunch’s article Google Redefines GPS Navigation Landscape: Google Maps Navigation For Android 2.0.

(Side-note: Nokia paid $7.7 billion for NAVTEQ and yet I can’t recall anything from that deal with as much impact as this Google Maps Nav solution)

How can Google Map/Nav disrupt the whole Nav system’s market? Let me give you an example using TomTom since I’m more familiar with TomTom’s Nav system…

TomTom’s Nav app for iPhone cost $100 and if you add their $120 cradle the whole thing is $220. And I bet there are other “hidden” costs for things such as map updates; that is their cash cow.

Let’s now look at TomTom car nav system. Like 2 years ago my wife gave me a TomTom ONE XL as a present. I love the gadget I must say and it has saved my neck a couple of times already. My wife paid like $200 for it. Now, if I want live traffic (or other kinds of data) I have to pay extra (if I recall correctly, for each). And the big one – if I want to update my maps, I have to pay for new map content. Paying for new content is fine, it cost like $75 if I recall correctly. But, because I haven’t updated my maps in a while they want to charge me $75 for the next release after the one I’ve on the device, plus another $75 for the latest one. In short, they want to charge me twice! I felt that they were taking advantage of me by charging me for a version I won’t be really using and I realized map updates is their cash cow; I didn’t upgrade.

And now Google releases Google Maps with Navigation support, a complete solution, for free, for your smart-phone. Can’t wait to get my hands on it (seems I may have to wait for Android 2.0 or upgrade my phone).

You would think that after everyone gets hooked that Google will start charging after the Beta release, don’t you think? Maybe their business model remains search and advertising based, or they will have a new model around charging business to appear on their maps and layers.

…and once again, the mobile handset is at the center of disruption…

Google Maps Nav features:

  • Search in plain English (watch video). No need to know the address. You can type a business name or even a kind of a business, just like you would on Google.
  • Search by voice (watch video). Speak your destination instead of typing (English only): “Navigate to the de Young Museum in San Francisco”.
  • Traffic view (watch video). An on-screen indicator glows green, yellow, or red based on the current traffic conditions along your route. A single touch toggles a traffic view which shows the traffic ahead of you.
  • Search along route (watch video). Search for any kind of business along your route, or turn on popular layers such as gas stations, restaurants, or parking.
  • Satellite view (watch video). View your route overlaid on 3D satellite views with Google’s high-resolution aerial imagery.
  • Street View (watch video). Visualize turns overlaid on Google’s Street View imagery. Navigation automatically switches to Street View as you approach your destination.
  • Car dock mode (watch video). For certain devices, placing your phone in a car dock activates a special mode that makes it easy to use your device at arm’s length.

And yes, there is also a cradle coming for the Android-based phones that automatically will activate the Nav mode.

See the official Google Maps Nav website.


28 Oct

Motorola announces DROID, the world’s first smartphone powered by Android 2.0

Today I received this from the Motorola marketing folks, here for your reading pleasure:

Motorola today announced DROID, the first device powered by Android 2.0 and features the brainpower and breakneck speed of a modern smartphone. DROID is designed to outperform where other smartphones fall short. It features a solid exterior, intelligent interior and is one of the thinnest full-QWERTY slider phones available. DROID delivers high-speed Web browsing, voice-activated search, a customizable large touch screen and access to thousands of apps and hundreds of widgets from Android Market.

Key features of DROID include:

  • OS: Android 2.0
  • World’s thinnest slide-out QWERTY keyboard
  • 3G Web and full HTML browser
  • Cinematic 3.7” high-resolution display with more than 400,000 pixels
  • Powerful and fast Google voice-activated search
  • Run up to 6 apps simultaneously and customize the homescreen with thousands of apps and hundreds widgets from the Android Market
  • 5 megapixel camera with flash, DVD-quality video capture and 16GB memory card included
  • Integrated work and personal email pushed right to you
  • Google Maps Navigation (Beta) with free turn-by-turn directions

DROID by Motorola will be available Nov. 6 online and in stores from Verizon Wireless, nation’s largest and most reliable 3G network.

For more information, product specifications and images of DROID, please visit Motorola Media Center Fact Sheets. For multimedia assets visit DROID Press Kit.

To stay up to date with the latest product news and promotions, you can also find us on Facebook and follow us on Twitter.

Very nice piece indeed, and I can’t wait for such a device to be supported on T-Mobile. Note that it comes with native support for Exchange (which will give Android a big push in the Enterprise) and the new Google Maps Navigation application will definitely disrupt the current Navigation system market (with players such as TomTom, NAVTEQ and others; ouch!) with this new free app. More info below:

DROID by Motorola with Google™

Talk and Standby Time4

TT: 385 mins/6.4 hours

SB: 270 hours/11.25 days

Form Factor

Capacitive Touch; Full Qwerty Side Slider


800/1900, CDMA EVDO rev A


Android 2.0


169 g / 6 oz


60.00 (x) x 115.80 (y) x 13.70 (z) mm

2.4 (x) x 4.6 (y) x 0.5 (z) inches


Webkit HTML5 based browser; Flash 10 ready

Email Support1

GmailTM, Exchange, IMAP, POP, Macmail, GmailTM, MSN Hotmail, Yahoo and AOL®


1400 mAh


Bluetooth® v2.1+EDR, 3.5mm Headset jack, USB 2.0 HS


3.7”, 480×854 WVGA

Display Resolution

WVGA display houses 400,000 pixels


SMS/MMS, Full HTML5 Browser




Advanced Video record/playback at D1 resolution (720×480) with up to 24fps capture and 30fps playback, MPEG-4, H.263, H.264


5.0 megapixel, AutoFocus, dual LED Flash and image stablization


16GB card included in phone, Up to 32GB microSD expandable

Location Services1



802.11b/g, 3-axis accelerometer


26 May

Android 1.5 Cupcake Install Instructions

Below are modified instructions for Android 1.5 update/install:

  1. (Make sure the G1 is fully powered or connected to power)
  2. For Android 1.5 Cupcake download the update from: http://android-dls.com/files/ota/signed-kila-ota-148830.de6a94ca.zip
  3. Rename the downloaded file to “update.zip”
  4. Connect your G1 to your PC; mount the device
  5. Copy update.zip to your microSD card (the root directory)
  6. Shutdown the G1
  7. Start it again while holding down the Home key until you get a triangular caution icon next to a phone (this is after you see the normal G1 logo)
  8. Press ALT-L; this will open a menu of options, one of which is install the contents of “update.zip”; press ALT-S to start the installation
  9. Wait several minutes while the new firmware is installed; don’t touch / mess with the G1 — leave it alone!
  10. You’ll eventually be asked to push the Home and Back keys again; Back is near Home — not the Delete key on the keyboard; this will restart your Android device
  11. The firmware will be copied into ROM (this takes a couple of minutes or so)
  12. Your G1 will reboot itself

Good luck!

Disclaimer: if your G1 explodes during the installation process, I’m not responsible!


P.S. Adapted from / via: MobileCrunch.

09 May

Android Widgets coming soon and they look fantastic

Android Widgets, which will be made available with the release of Android 1.5 (Cupcake) is a great addition to the platform; I’ve been waiting for such widget API for a while now.

Android Widget

Android Widgets is an example of Local widgets (as opposed to Web-based widgets). And because they are Local, you get the benefit of the (Android) platform to its fullest.

Android define their widgets or AppWidgets as miniature application views that can be embedded in other applications (e.g., the Home). These views are called "widgets" and you can publish one with an "AppWidget provider." An application component that is able to hold other widgets is called an "AppWidget host."

Below is a glimpse at Android Widgets (thanks to PhoneDog):

When Android widgets are used with the AppWidget framework, see Introducing home screen widgets and the AppWidget framework, developers can write “widgets” that can be dropped onto the home screen. (And with “home widgets” we are getting closer to something that I wrote some time ago – see the bit old but still very relevant piece titled The Next Battlefront for Mobile Applications.)

For those interested in developing widgets for Android, there are a couple of good developer guides available at developer.android.com:

Plus see my Mobile Widgets Page which provides some background, definition, examples and related information about mobile widgets.


05 Nov

What will drive differentiation across Android platform providers?

The Android platform is an open platform, governed by the Open Handset Alliance (OHA). OHA has many members, and today it includes seven network operators and four handset manufacturers.

While the platform itself should be consistent across vendors/providers, thank God, I wonder what will be the differentiation challenges that handset manufacturers and network providers will face?

The handsets will all be capable of (from the S/W perspective) the same things, so will differentiation come purely from hardware design, for example, better handset footprint, layout, screen sizes, better battery consumption?

Or perhaps differentiation will come from the cost of ownership, as in monthly cost for voice/data/text plans?

Maybe it is all the above.

But I think a big part of this battle be in the User Interface. While the concepts of workspaces, and how S/W and UI is designed and written will or should remain consistent across platforms/vendors, we will see a plethora of UI designs and information architecture/organization. Is this a good thing? In theory it is, as it will allow for better and neater UIs and related innovation. I’m not sure yet the impact on the development and testing of Android applications… Also, will that UI innovation and differentiation make it back to the open source tree? Not sure yet, but I will find out soon, but my guess today, probably not.

Access to content and integration with the Web, which is based on applications and services, should be another differentiator. Integration to Google services have proven to be a winner, but Google services probably will be available to all Android platform vendors, providing no differentiation across Android vendors.

So differentiation between Android vendors will be a challenge, a challenge the iPhone doesn’t have, as there is only one iPhone vendor (and platform, unless you go across classes of iPods).


30 Oct

(Android G1) 3G’s main weakness: power usage

Call it 3G’s weakness, its Achilles’ heel, or 3G’s worst enemy….

==> Power consumption

Ironic it is, having a 3G device, but forcing it to 2.5G, to have a usable handset over time…

After a 1-day test running on EDGE vs. 3G/UMTS on my new Android G1, the battery did last much longer: the whole day and whole night…

The power consumption/management issue on Android really has to be addressed soon, as it makes 3G kind of impractical. In the meantime, if you’ve access to power sources, use it 3G, but if you are not sure, maybe because you on the road, force it to EDGE:

Go to “Settings” => Go to “Wireless Controls” => Go to “Mobile Networks” => Select “Use only 2G Networks”

I am hoping that very soon, we get a future Android S/W update that improves on power management so that we can use the handset on the 3G network without fear of ending up with a dead handset when we need it the most.


28 Oct

Android G1: First Impressions

So I got an Android G1 handset. Cool. I’ve been using it for 2 3 days now. Overall I think it is a fine handset and mobile environment with great potential. Below are my quick first impressions: the good, the bad and the ugly; if you are looking for a full detailed review just search the web where you will find lots of review articles already.

The Good

  • The software in general is pretty good and complete; you will find all you would expect from Google: email, SMS, contacts, browser, maps, plus the other stuff such as alarm, calculator and so on. The maps compass mode works well and is very cool.
  • The user interface, colors, visual feedback, workspaces, and its fluidness is neat, I like it.
  • The browser windows feature, which allows you to have multiple active browsing windows is neat.
  • Great integration to/with rest of Google software: the email, the contacts, IM (GTalk), the calendar, the reader, YouTube. The integration is so good that I ended up moving all of my contacts to Google Contacts and have them synchronized with the handset. And I also consolidated all of my email accounts via Gmail so that I’ve a single place to go to check for emails, both on desktop and handset. I’ve been using this a lot; the integrated apps are really great. Many of these apps are Android/local apps which is fine with me as they run fast and have background processing, for example the Gmail client.
  • Having touchscreen and keyboard is great; I always have been a touchscreen and keyboard kind of person.
  • The handset comes with support for WiFi, GPS, Bluetooth, accelerometer.
  • I feel it is a great development platform, allowing me to experiment and create neat applications.
  • There are many other goodies that I haven’t played with yet. And of course things like having a concurrent OS (Linux) with support for concurrent application execution, etc. is great.

The Bad

  • The battery utilization is bad. And I don’t have GPS, Wi-Fi or Bluetooth active! Just idle, browsing, texting and reading email will eat your battery I would say in 5 hours or so. They need work on that.
  • The keyboard feels a bit weird. I attribute this to its non-symmetrical design where you have to the right the trackball and buttons, taking maybe around 1 inch, but not having the same on the left-side. So while having a keyboard is great for me, the way it was implemented is not the best way. Symmetry is at the center of usability and beautiful design; it is a bummer they failed on this one. Over time with practice this may become a non-issue, but that is not the point; why fail to create a beautiful piece when you have the opportunity?
  • I’m afraid that if I drop this baby that it won’t survive… Insure it!
  • The hinge. This this is going to be a very weak spot for the handset. And it already started making (rubbing or friction) squeaky noises.

The Ugly

  • Did I say the battery is bad? Well, the battery is worst than bad, and it is the true ugly part. This can be fixed with better software, better power management. Being the G1 the first Android model I understand they didn’t get it perfect, but the software and power management must be revisited (same happened with the first generation iPhone).

My Wishlist

  • Better power management!
  • The keyboard symmetry spacing issue mentioned above.
  • A camera flash; check out the BlackBerry Curve as an example.
  • S/W-based keyboard (already on the road-map) for when I don’t want to flip/open the handset to type.
  • Infrared port.
  • NFC.
  • Headset Jack!
  • (More as I find more wishes)

See the Android G1 handset specs (cellubration.com).


02 Oct

Google Apps on Android

Google Apps for Android, which includes YouTube, Search w/ suggestions, Mail, Calendar, Maps, Contacts and Talk, all seem very well implemented and very well integrated with the web and their corresponding web-based applications:

The Android platform is looking good…


24 Nov

Richard Monson-Haefel on Is Android Fragmentation Inevitable?

Richard Monson-Haefel (author of a number of books in Java, Web Services and JMS) and who is a Sr. Analyst at the Burton Group, wrote a good piece on Andriod vs. fragmentation… I agree with most of his points.

Time will tell what will happen with Android and the industry, but it is not going to be straightforward. Unless there is a strong hand leading/managing, and yes controlling, “open and consistent” is like “water and oil”. And I am not even talking about network operators here who are the ones who decide what handets and what software runs on their networks; I am only referring to the implementation aspects such as APIs, behaviors, and so on.


14 Nov

James on Android


Good writeup by James Pearce, CTO at dotMobi, on Google Android – as told and used by its own developers. I met James at the Mobile 2.0 event, and he is a sharp guy, so you should listen to him :-).

I will say though that Android handsets will come out probably in 6 months or so. And I will reiterate that at the end of the day, the operator still rules (it is their networks), and that all the theory (and wishful thinking) introduced by Android will be put to the test very shortly.

Android is definitely a shakeup to the mobile Java community (more than just “shaking things up a little”), but let’s remember that shakeups are a good thing (typically); more about this on another post.


12 Nov

The Android SDK, Demo Video and Contest


Warning…Warning Will Robinson! The Android is out!

So the Android SDK is out… looks very interesting and well thought out.

Below is a video of Sergey Brin and Steve Horowitz discussing the availability of the SDK and demo applications on the Android platform:

As I was suspecting, Android is Java-based, but it is not Java ME-based; the package structure is android.os . The Android web runtime is based on the open source Web Kit, a logical choice, and is the underlying OS is based on Linux 2.6 kernel.

General Features:

  • 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 OpenGLES 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

The Android Application framework seems quite interesting: see Android’s Application Building Blocks. A great summary of the architecture can be found at See Androidology – Architecture Overview, Part 1.

The Platform (click to enlarge):

Android Platform

Video: The Architecture Overview, Part 1:

Google has set aside $10M to give away to developers who come up w/ good applications for Android.

See Android’s page at Google at http://code.google.com/android/index.html.

Last but not least, let’s see how the “Hello Android” application looks like in Android:

public class HelloAndroid extends Activity {
    /** Called when the activity is first created. */
    public void onCreate(Bundle icicle) {
        TextView tv = new TextView(this);
        tv.setText("Hello, Android");

Let the games begin!

Related to this see: