This process has been tested against the android-4.0.3_r1 branch, so if you’re using another branch you may encounter some issues not mentioned here.

1) Follow steps 1 to 4 from the instructions from yesterdays post, but check out the relevant ICS branch instead of master (Don’t forget to apply the patches from that post to the checked out ICS files).

2) Apply the following patch which has already been applied to the master branch but currently isn’t in the ICS branch;

external/elfutils project;

diff --git a/config-compat-darwin.h b/config-compat-darwin.h
index 7953bb6..f884b09 100644
--- a/config-compat-darwin.h
+++ b/config-compat-darwin.h
@@ -38,6 +38,7 @@ static inline char *dcgettext (char *__domainname, char *__msgid, int __category
 	return NULL;
 }

+#if __MAC_OS_X_VERSION_MIN_REQUIRED < 1070
 static inline size_t strnlen (const char *__string, size_t __maxlen)
 {
 	int len = 0;
@@ -45,6 +46,7 @@ static inline size_t strnlen (const char *__string, size_t __maxlen)
 		len++;
 	return len;
 }
+#endif

 static inline void *mempcpy (void * __dest, const void * __src, size_t __n)
 {

This is commit 72940dec691fa3255e13df01f8c53b620e446066 on the master branch and is currently only one commit ahead of the external/elfutils head commit in the android-4.0.3_r1 ICS branch (which is 84cf4183ba6f577ee01abe7f1f5a6d4b23df35a8). If the ICS branch external/elfutils head moves on you may encounter issues applying this patch.

3) Follow the build instructions.

This process comes with the same warnings as the master branch process; Some of the host scripts generated don’t have the files they need to run. You can still build fully functional images for devices such as the Galaxy Nexus, but it does mean you can’t run some of the end-user utility scripts which are generated as part of the build.

One last thing; If you do make some impressive changes to Android (or fix the end-user scripts to run on Lion) don’t forget to offer your patches back to the AOSP via the android-contrib Google Group .

My company has worked on some Android firmware projects in the past, but, due to the closed source nature of Honeycomb, that work pretty much dried up. Recently though Google released Android 4.0 to the masses and we’ve had a few enquiries about firmware work again, so I thought I’d see what the current state of building Android was for our default machine configuration.

The first problem I hit was the Android build system wasn’t compatible with Mac OS X 10.7 (Lion) and Xcode 4 (The Xcode version available for Lion), so I decided to use a bit of spare time to seeing if it could be fixed.

The following are the steps I found necessary to allow the build to complete on the current master branch (the android-4.0.3_r1 branch has some additional issues which I haven’t resolved yet, so please don’t assume this will work for that branch as well);

1) Install Xcode from the Mac App Store (this gave me Xcode version 4.2).

2) Install version 2.0.3 of MacPorts using the DMG installer image for Lion which is available from the MacPorts site. During the installation process you’ll be asked to install Java if you don’t already have it installed, select the install option.

3) Follow the Android build environment setup instructions skipping the instructions on installing Xcode & MacPorts (because you’ve already done that)

[Note: The instructions on the Android site indicate a reversion of the version of Make may be required, but the configuration I was left with straight after installing Xcode & MacPorts gave me make 3.81 by default, so you probably won't need to revert the make version either. I also noticed that my Lion installation didn't require the ulimit modification due to it already being unlimited.]

4) Apply the following patches I created for three different projects in the source tree to fix build issues;

build project;

diff --git a/core/combo/HOST_darwin-x86.mk b/core/combo/HOST_darwin-x86.mk
index 544a29e..407c74f 100644
--- a/core/combo/HOST_darwin-x86.mk
+++ b/core/combo/HOST_darwin-x86.mk
@@ -53,7 +53,11 @@ HOST_JNILIB_SUFFIX := .jnilib

 HOST_GLOBAL_CFLAGS += \
        -include $(call select-android-config-h,darwin-x86)
-HOST_RUN_RANLIB_AFTER_COPYING := true
+ifneq ($(filter 10.7.%, $(build_mac_version)),)
+       HOST_RUN_RANLIB_AFTER_COPYING := false
+else
+       HOST_RUN_RANLIB_AFTER_COPYING := true
+endif
 HOST_GLOBAL_ARFLAGS := cqs

 HOST_CUSTOM_LD_COMMAND := true

development project;

diff --git a/tools/emulator/opengl/tests/translator_tests/GLES_CM/Android.mk b/tools/emulator/opengl/tests/translator_tests/GLES_CM/Android.mk
index deb11b6..a73f6b8 100644
--- a/tools/emulator/opengl/tests/translator_tests/GLES_CM/Android.mk
+++ b/tools/emulator/opengl/tests/translator_tests/GLES_CM/Android.mk
@@ -8,6 +8,15 @@ LOCAL_SDL_CONFIG ?= prebuilt/$(PREBUILT)/sdl/bin/sdl-config
 LOCAL_SDL_CFLAGS := $(shell $(LOCAL_SDL_CONFIG) --cflags)
 LOCAL_SDL_LDLIBS := $(filter-out %.a %.lib,$(shell $(LOCAL_SDL_CONFIG) --static-libs))

+ifeq ($(HOST_OS),darwin)
+  DARWIN_VERSION := $(strip $(shell sw_vers -productVersion))
+  ifneq ($(filter 10.7 10.7.%,$(DARWIN_VERSION)),)
+    # Lion needs to be forced to link dylib to avoid problems
+    # with the dynamic function lookups in SDL 1.2
+    LOCAL_SDL_LDLIBS += /usr/lib/dylib1.o
+  endif
+endif
+
 LOCAL_SRC_FILES:= \
         triangleCM.cpp

diff --git a/tools/emulator/opengl/tests/translator_tests/GLES_V2/Android.mk b/tools/emulator/opengl/tests/translator_tests/GLES_V2/Android.mk
index ae0064f..efbe6bd 100644
--- a/tools/emulator/opengl/tests/translator_tests/GLES_V2/Android.mk
+++ b/tools/emulator/opengl/tests/translator_tests/GLES_V2/Android.mk
@@ -17,6 +17,12 @@ LOCAL_LDLIBS += $(LOCAL_SDL_LDLIBS)
 LOCAL_STATIC_LIBRARIES += libSDL libSDLmain

 ifeq ($(HOST_OS),darwin)
+DARWIN_VERSION := $(strip $(shell sw_vers -productVersion))
+ifneq ($(filter 10.7 10.7.%,$(DARWIN_VERSION)),)
+  # Lion needs to be forced to link dylib to avoid problems
+  # with the dynamic function lookups in SDL 1.2
+  LOCAL_LDLIBS += /usr/lib/dylib1.o
+endif
 $(call emugl-import,libMac_view)
 endif

external/qemu project;

diff --git a/Makefile.android b/Makefile.android
index e58f984..d638640 100644
--- a/Makefile.android
+++ b/Makefile.android
@@ -74,8 +74,8 @@ ifeq ($(HOST_OS),darwin)
     ifneq ($(filter 10.1 10.2 10.3 10.1.% 10.2.% 10.3.% 10.4 10.4.%,$(DARWIN_VERSION)),)
         $(error Building the Android emulator requires OS X 10.5 or above)
     endif
-    ifeq ($(filter 10.5 10.5.%,$(DARWIN_VERSION)),)
-        # We are on Snow Leopard or above
+    ifneq ($(filter 10.6 10.6.%,$(DARWIN_VERSION)),)
+        # We are on Snow Leopard
         LEOPARD_SDK := /Developer/SDKs/MacOSX10.5.sdk
         ifeq ($(strip $(wildcard $(LEOPARD_SDK))),)
             $(info  Please install the 10.5 SDK on this machine at $(LEOPARD_SDK))
@@ -191,6 +191,11 @@ endif

 ifeq ($(HOST_OS),darwin)
   QEMU_SYSTEM_LDLIBS += -Wl,-framework,Cocoa,-framework,QTKit,-framework,CoreVideo
+  ifneq ($(filter 10.7 10.7.%,$(DARWIN_VERSION)),)
+    # Lion needs to be forced to link dylib to avoid problems
+    # with the dynamic function lookups in SDL 1.2
+    QEMU_SYSTEM_LDLIBS += /usr/lib/dylib1.o
+  endif
 endif

 include $(LOCAL_PATH)/Makefile.common

5) Follow the build instructions and watch the build complete .

This process should be enough to get you a working environment to build for devices and has allowed me to build a fully functioning version of the master branch (as of 20th December 2011) for my Galaxy Nexus using the full_maguro-userdebug lunch target.

There are still some some runtime issues with some of the host scripts which are produced during a build. The main issue seems to be with auto-detection of their environment and not finding the 64bit variants of some libraries (e.g. the android script fails saying it doesn’t have any x86_64 SWT libraries available), but that’s a problem for another day….

If you have any questions about building the Android source code please use the android-building Google group to discuss them so that others can either help out or see how to resolve similar issues.

Versions before 4.0.3 were focused on the Galaxy Nexus and its hardware. 4.0.3 is a multi-device release which supports the Nexus S, Xoom, and should be used as the basis for other ports.

So if you see an Ice Cream Sandwich / Android 4.0 device you should look at the specific version it’s running, if it’s not a Galaxy Nexus and it’s running something before 4.0.3 then you might want to ask when it’ll get the update.

Size

I’m going to say straight off that the Galaxy Nexus is too big to become my daily ‘phone. I thought it would be when the specs started floating around, and, having had it a while now and travelled a bit with it, I still think it’s true.

Maybe it’s the clothes I wear, the way I sit, or the way I’m built, but I can always feel it when the Galaxy Nexus is in my pocket unlike the iPhone and the Lumia which are comfortable enough to forget about. This could be because I’ve spent a long time with my Nexus One and so I’m used to ‘phones of that size, but none the less it just feels uncomfortable (especially when sitting down).

The screen size isn’t so much of a problem. There are the occasional times when I’ve had to reach for something on the Galaxy Nexuses larger screen, but I’ve found the same is true on the other ‘phones too, so, to me the GN screen isn’t so big it causes problems, which was something I was pleasantly surprised at.

The iPhone and the Lumia are so similar in size it’s unnoticeable to me in daily use. I’m sure the specs will say there’s a millimetre or five here or there in one of the dimensions, but when they’re in my pockets or in my hands there’s really little difference, so I don’t see much use in trying to differentiate between the two.

If I had to pick one of the three as the most physically comfortable I’d got with the Lumia. It’s size gives it the edge over the GN for me, and the curved edges feel more comfortable to hold than the iPhone, but it’s a close run thing.

Battery

I’m a light-ish ‘phone user. I don’t spend all day using apps or making calls, I spend probably 30 minutes on the mobile each day (I don’t develop on the phone I use for calls), and over the last few days I’ve been switching between the devices to get a feel for how long they’d last with my usage pattern.

I’ve tried to limit the external factors as much as possible and kept them all within 3 meters of my WiFi hotspot and my FemtoCell, so network connectivity for both voice and data has always been what each of the devices show as “full” strength. Tests like this will always be very dependant on when you do them, so, although I’ve quoted figures for some tests, these are the figures for my tests, and even if you did the same you may see different figures.

First the most important point; All of the devices went for over 40 hours without charging with my usage pattern. That’s long enough to last from when I wake up, through one day and night, and another day, so there’s no problems with any of them running out half way through the first day.

I did an overnight battery loss test (because no-one calls me at night thankfully ), and the Galaxy Nexus showed the biggest loss (11%), with the iPhone next (10%), and the Lumia 800 showing the least (8%).

This quick battery test reflected the order in which the ‘phones went from full charge down to 15% with the GN reporting roughly 2 days 6 hours, the iPhone going for 2 days 15 hours, and the Lumia lasting a bit over 3 days.

In practical terms, if you’re happy with putting your ‘phone on charge every day (or every other day), and you’re a relatively light user like me, all of these ‘phones will not require a change to your usage charging patterns.

During the time I did actively use the ‘phones, however, I noticed the Galaxy Nexus drained noticeably faster than the other two. Fortunately Android gives you the ability see what’s using the battery the most, and on the GN, during heavy use, the screen seemed to be the number one battery drain.

On my recent trip to DroidCon Netherlands I passed the GN around to a few people and ended up having to recharge it after about 8 hours, with the screen showing up as being responsible for over 55% of the drain. I’ve been passing the iPhone and Lumia around to people and, although it they haven’t been used nearly as much, they’ve reported figures that looked as if they’d still last well over a day.

So in a nutshell, with low to average use, any of these ‘phones should be fine, but if you’re a heavy user it’s probably wise not to rely on the GN seeing you through a day.

Camera

Looking at the simple mega pixel ratings would make people think the Galaxy Nexus would be the outright loser here with its’ 5 MP resolution as opposed to the 8MP on the Lumia 800 and iPhone 4S. But I’m not so sure.

Both sets of 3 ‘photos available in my Google+ gallery were taken within a couple of minutes of each other and the lighting didn’t change dramatically. The outdoor iPhone shot is in landscape due to my personal brain-failure rather than an intentional orientation change, but all three give you a good idea of the colour and detail from outdoor pictures, which is what I tend to take most of. None of the 3 used the in-built flash for the photos, and yes, they were all on auto-flash mode.

To me the iPhone is the clear winner. To me the picture looks closer to how I saw the scene, and it’s a “brighter” picture (which I prefer) and, to me, makes detail easier to pick out.

The Lumia and the Galaxy Nexus are a pretty close run thing to me. I can, of course, zoom in to the picture to a greater level of detail on the Lumia ‘photo because of it has more pixels on the sensor, but in terms of looking at the whole picture on my monitor I couldn’t easily choose between them.

When it comes to indoor photos though the Galaxy Nexus seems to suffer. The iPhone maintains its crisp quality, and the Lumia does a pretty good job too, although the colours look a little weird, but the Galaxy Nexus photos always seem, to me, to be dully and muddy.

I’ve seen the GNs camera suffer a number of times in indoor or lower light photos, and given that all 3 phones were on their default settings I’m going to put it down as the worst of the lot. There may be ways of tweaking it to improve it, but I doubt many people will use their phone for much more than point and click photos.

So there we have it, to my eyes the iPhone is the winner in terms of photo quality because I found the photos it took both indoors and outdoors to be what I would consider the best representation of scene, the Lumia comes second, and, because I could adjust the colours of the Lumia picture after taking it, but not the level of detail in the GN photo, the Galaxy Nexus is third due to it’s indoor issues.

Browsers

The browsers on each of the ‘phones have a pretty good level of standards compliance. They all achieve 100/100 on the Acid3 test but all of them have a small error in the purple block in the top right of the result area (and it’s different on each one). All three have rendered the sites I’ve looked at as well as I would expect, and in terms of presentation there’s little to pick between them.

When it comes to performance, however, the Lumia really shows up as being sluggish.

The SunSpider 0.9.1 results give the best illustration of the performance difference; The GN managed 2023ms +/- 1.6%, the iPhone hit 2245ms +/ 0.6% and then the Lumia crawled in with 6769.6ms +/- 0.3%.

The performance lag of the Lumia also showed in my real page tests. Loading reasonably complex sites like ibm.com and yahoo.com. The iPhone usually came in just ahead of the Galaxy Nexus with the Lumia was always crawling in last, usually by a significant margin.

While it’s good to see Microsoft have made significant improvements in the browser from the first Windows Phone 7 release, they really need to allow OEMs to use more modern hardware in order to deliver the levels of performance a users of high-end smartphones should expect.

Personally I’ve never been a fan of Flash, and on mobile devices I turn it off. I’ve seen flash bring the rendering speed of a mobile browser to its’ knees enough times to form the opinion that enabling flash is rarely worth the content that needs it. I know others will want flash, and for them that makes an iPhone a non-starter, but, given Adobes’ recent decision to let flash on mobiles become a thing of the past, I’m not going to penalise the iPhone for not supporting it.

So in terms of raw browser page rendering speed, for me, the iPhone is just a nose ahead of the GN, and the Lumia comes in last. If Flash is important to you then the GN would be the winner here. The only solid conclusion is whatever way you look at it the Lumia is solidly bottom of the pack when it comes to browsing.

Email

Android has always separated GMail from GMail email, and in earlier versions the experience was very different. GMail had a vastly more polished experience and the non-GMail email client, was, well, basic. On the Galaxy Nexus this isn’t the case, and the non-GMail experience is as good as I’d expect from a mobile email client, so it’s been a good step forward.

The Lumia and the iPhone have one email client. It doesn’t matter if you’re using GMail, Microsofts Live, Apples iCloud, or another mail provider, you access them all via a single interface, and that has an advantage; the potential for a single inbox for all your accounts.

If you have, say, a GMail account, an iCloud account, and a Live account, there is no way of creating a single view of the inbox on all three accounts on the GN. On the Lumia you have to create Linked inboxes, which is a bit of a pain, and on the iPhone you simply have a unified inbox, so you can get a quick snapshot of all your accounts in one easy step.

Another issue I’ve found with using the GN maybe more of a server-side GMail issue; On my desktop I use Apples Mail client which accesses my GMail account via IMAP which seems to create some problems for GMail because email I delete in the desktop client stills appear in the inbox of the GMail app on the Galaxy Nexus, which is irritating.

In terms of rendering emails, the Lumia seems to be the worst of the three. If you read an HTML mail both the iPhone and the Galaxy Nexus will try to fit them on the screen, whereas the Lumia will zoom out to fit everything on screen, which, quite often, means you end up zooming in before you can read everything.

So my personal ratings; I’d put the iPhone mail client first, it’s unified inbox and ability to render HTML emails to be readable without zooming is great. After that the Lumia and Galaxy Nexus both have their pros and cons, the Lumias’ rendering isn’t great, but the linked inboxes are useful to me, whereas the Galaxy Nexuses rendering is better, but the lack of any way to have a single view of all mail accounts (GMail and non-GMail) is annoying to me, so it’d be difficult to say one was significantly better than the other, and I’ll give the Lumia and GN joint second place.

Apps

I’ve never believed that the size of an app store or market has any direct link to the quality of the apps in it so I’m not going to play the “most apps wins” game.

Part of the reason for this is that when my company owned AndAppStore we were asked by one OEM to guarantee there would be a certain number of apps in a certain timeframe and I refused to do that. When asked why I pointed out that we could easy reach the number by including an app for every RSS feed we could find, but that wouldn’t be of much use to their customers. The CEO thanked me for my honesty and the relationship was made stronger for it, and they then understood the limitations of using an app counter to rate a product.

What matters to me is a pretty small core of apps. The Lumia, iPhone, and Galaxy Nexus all come with usable Maps apps, Browsers and Email clients, so that’s done and dusted. Beyond that my main needs are; Twitter, Facebook, Dropbox, and 1Password. I also use, to a lesser extent, Skype, Google+, PogoPlug, and Stock tracking application.

Both the iPhone and the GN provide all these apps, whereas the Lumia falls short on all of the less important ones except for a stock tracking app. While I’m sure some people will take comfort in there being 39-odd thousand other apps, to me they’re pretty unimportant. Sure there may be some nice distractions in there, but nothing that’s going to change my core working practices.

In terms of quality though, both the Lumia and the iPhone benefit from the additional checking which goes on in their market places. Different apps look familiar when you use them, and there’s no sudden jarring in UI in the same way as when you go from, say, Dropbox to 1Password on the GN.

That’s not to say they’re perfect. I could reliably get the Facebook app on the iPhone to crash by attempting to post a specific link, so although they’re good they’re not perfect.

So, in conclusion, in terms of the range of apps, well, all three have a good range, but the iPhone and Galaxy Nexus have all the apps I need, whereas the Lumia is a little lacking, and when combined with the familiar feel that all the iPhone apps have I’d put the iPhone just above the GN due to the speed at which I can get to grips with new apps if I want to try them out.

Wrap-up

As you’ve probably guessed, I’m impressed with the iPhone. Given the tests I’ve been doing over the last week I can see why it is an aspirational device. Apps have a consistent feel and are wide ranging, the device is easily portable, it has a pretty decent camera, and it just comes together in a pretty simple to use package.

I’m also pleasantly surprised by Lumia. It falls short in terms of the variety of apps available, but Windows Phone 7 is only a year or so away from it’s public launch, so that’s to be expected. I have to admit I like it.

And then we come to the Galaxy Nexus. Whilst Android 4.0 does bring the device up to where Android tablets have been for a while in terms of user experience, the device seems, well, not that impressive. For me it’s too big, the camera isn’t good enough to rely on in all situations, and, after using the iPhone and the Lumia, I can see why people comment the Android experience not being a coherent one between apps.

So there you have it; After a week playing with all 3 devices I can now understand the view that the iPhone offers a superior phone experience and why people would queue to buy it, I can understand why Microsoft and Nokia have got behind the Lumia with some serious marketing money, and I can understand why, when the Galaxy Nexus was launched in one store in the UK (which was the only place in the world consumers could buy it), they’d only sold 60ish in the first four hours and you could just walk in and buy one.

Lets just hope we see some more inspiring Android 4.0 devices in the near future.

And today I had the first situation where I felt it made sense to use that feature on Google+.

In light of this I thought it might be worth making available the rules I use to determine when to block people and open them up for discussion.

I’m more than happy to discuss comments I’ve made and opinions I hold. Sometimes I’m convinced my view isn’t the “best” and so I’ll change my opinion, sometimes I can convince others to change theirs, and sometimes the discussions end with neither myself or the other party changing their views. All of these types of discussions I welcome as long as they’re constructive and well thought out.

My rules around “blocking” people are mainly aimed at those who don’t believe they need to back up their views and opinions. If something is said that I don’t agree with I’ll ask for some sources of information to back their position. If they don’t provide it I’ll ask again. If, third time around, they still don’t provide anything to back up their view then I’ll draw a line under the conversation and make the assumption that there isn’t anything to back their claims. I won’t block them, I just won’t engage in the discussion any more.

If, however, they start making claims which a third party shows are wrong and the they start attacking the third party on my posts, or they start throwing personal insults at me which don’t relate the the discussion, then we’re into the territory where I consider blocking people.

If, as was the case today, they hit both situations (three failures to provide sources and unreasonable behaviour), it’s a no brainer, they get blocked.

So if you encounter people telling you I’ve blocked them unreasonably, claim they were blocked just so that I could make it look as if I was right, or say I just stopped discussing something so they must have been right, then ask to see the conversation and make your own mind up. If, as a third party, you think I was unreasonable then tell me, because at the my views about blocking someone are just that; my views, and as I’ve said I’m always happy to discuss those.

There were two speakers who presented the 4 or 5 sessions, neither was from Microsoft or Nokia, and both made glaring mistakes, one to the extent they had to start a session by apologising for what they’d said in a previous session because it was wrong (it was about how WinPhone7 manages application instances to service requests to start the same application from different live tiles, so it wasn’t exactly an obscure feature).

One of the speakers, who was from Hull university, seemed to think taking shots at Android was interesting or useful, but his jibes missed some key points (e.g. saying people had to revert to tasks managers to handle apps that drain the battery, which indicated he’s not used Android since before 1.6 was released a couple of years ago which included the ability to see this info using Settings -> About phone -> Battery Usage).

They also presented information which encourages badly designed apps which ignore existing hardware features (e.g. focus on portrait unless you really have a need to address landscape because it involves more than twice the effort, which, to someone who owns an HD7 with a kickstand that holds it in landscape mode, seemed particularly short-sighted).

One of the speakers also encouraged something which highlights a problem with the WinPhone7 Market; He suggested moving your apps between categories to reach different users and said one application he knew of received a significant download spike each time the category changed. To me that shows app discoverability on WP7 Market must be pretty poor.

I sat next to a guy who’d been involved in the development of Psion handhelds which used what’s now called Symbian, and he, quite vocally, was pointing out the problems with the information given out (e.g. encouraging developers to programatically manipulate the back-stack due to the framework not handling it in an intuitive way, and the assurance all WinPhone7 hardware would be the same, followed a couple of sessions later by details of how some ‘phones currently have a gyroscope which needs to be checked for before you use it, followed later on by a statement on how there’ll be a variety of platforms coming along to address the budget market, mid-range market, etc.).

In some ways it was quite telling that a Microsoft employee approached myself and the Symbian guy to clearly point out the presenters weren’t from Microsoft and so their information should not be considered as having come from Microsoft or Nokia. Which I felt was not exactly a nice way to back up the people MS & Nokia decided to put on stage.

Personally I came away with the impression that if this was the best Microsoft and Nokia combined could offer developers then either they’re not serious about putting effort into developer relations, or the level of developer skill in the WinPhone7 world is so poor that they had very few options, which wouldn’t surprise me given a very amateur looking game with pretty simplistic physics which was demonstrated has more than 10,000 downloads. (It’s called Destruction Golf if you want to take a look at it)

The session moved me from being interested in WP7 to thinking of holding off until WP8 before looking at it again, and from talking to some of the other attendees I know I wasn’t alone, which, I suppose, is one step up from the guys who sat on the other side of me to the Symbian chap who thought it was such a wash out they walked out about half way through.

The device itself is technically not stunning; It seems to be roughly equivalent to last years Galaxy Tab 7 with 8GB of storage and missing a few features (e.g. a camera). It’s also not running Honeycomb, so it doesn’t really have the geek-chic appeal of the more recent Android tablets.

What it does have is content… and buckets of it. And I think because of that it’ll be at least a reasonable success, and could possibly sell by the bucket load.

Amazon is initially going into the territory where Honeycomb tablets are at their strongest, the US, which is a brave move. Outside the US, where users don’t get the Google digital content store services like Books, Movies, and Music, I can see the Fire grabbing large amounts of market share (if Amazon makes the content available as well), and with the price point Amazon have gone for I can’t see a 7″ iPad being considered a competitor by anyone other than bloggers who don’t understand the market or those whose main interest in life is their hit counter.

Will I get one?, well, if I can get video and TV programme rentals, then yes, but if it ships internationally as a 7″ tablet which is just for books, then I’ll stick to the eInk kindles, which, I guess, puts me in the content valuing camp.

First off you’ll need the AOSP source which can be obtained from an unofficial mirror in the absence of the primary official repository at kernel.org.

Once you’ve checked out the source from frameworks_base you can “re-use” the implementation available internally in Android which can be found in;

frameworks/base/core/java/com/android/internal/http/multipart

The instructions on how to use it are in the comments of MultipartEntity.java

This is internal Android code which comes with all the warnings about “there be dragons”, but, if you take the entire package and rename it to something in your own namespace, you should be safe from name space clashes and the like (I haven’t heard of any issues in the projects I’ve used it in).

Feel free to discuss this solution below (and don’t forget to ensure you comply with the license the code is under )….

Last year I spoke about taking Android beyond ‘phones, this year I’ll be speaking about developing apps which scale well on single and multi-core devices (from single core, to dual, to quad, and beyond), which is something that’s going to become more and more important as we see more low-end single core devices, mid/high-end dual core, and top-end quad core devices come to market.

So if you’re a developer, you’re interested in Android, and you can be in London on the 6th and 7th of October, I’d strongly suggest you get a ticket, and, of course, come along to my talk ;).

If you look at London (which most would consider the UKs’ strongest candidate for an event) it’s the most populated city in Europe with over double the population of its’ nearest rival (Berlin), has one of the worlds busiest international transport hubs (Heathrow Airport, the only european airport in the top 5 for passenger throughput), is home to Googles second largest engineering center outside the US (after Zurich), and if Google did fly people in from Mountain View there would be no language barrier.

So where did Google choose for the western Europe developer day? Berlin.

I have heard talk of the reason being its’ proximity to Zurich (Googles largest non-US engineering facility), but given the difference in fight time between Zurich and Berlin and Zurich and London is less than 30 minutes, and adding people from Zurich to the team already in London would combine the talent from the two largest non-US engineering centres, that argument seems a little thin.

The other reason  could be Germanys population. It has the largest population of any country in Europe, but that, as anyone will tell you, isn’t a good reason to hold an event in a single city. Germanys’ population is spread throughout the county (as can be seen in a population density map). To get a population equivalent to that of Londons’ you have to take the entire regions of Berlin and Saxony states. If population accessibility actually was the reason it would make more sense to hold the event in Dusseldorf which has a larger “local” population.

The only thing that seems to be the reason is habit. Berlin has hosted a GDD several times in the last few years, so maybe Google just finds it easier to repeat the process from previous years, but that’s little comfort to any developer who has to find the time and money to go to Berlin each year.

(As pointed out in the comments, I was mistaken about previous GDDs being in Berlin, they were, in fact, in Hamburg (2007) and Munich (2008 & 2010), so even habit can’t be the reason.)

So the main event isn’t in the UK (and hasn’t been held in the UK since 2008), so what about the smaller events (e.g. the newly announced DevFests)?

It seems Google doesn’t want to hold one of those in the UK either. Paris and Barcelona both get events, but, again, the UK misses out. Could population again be a factor?, well, France’s population is around 3 to 4 million larger than the UK, but Spains population is around 15 million less. Paris’s population is less than a third of London’s, and Barcelona’s is around a fifth.

In light of this I’d be interested to hear what people think is the reason for Google holding events in Berlin, Paris, and Barcelona, and nothing in the UK, because, at the moment, it seem to me that it’s more about Google not wanting to support and encourage UK developers than it is about anything else.