For the last two weeks, I’ve exclusively been using Google’s Android 4.0 “Ice Cream Sandwich” for all of my tablet computing needs.
As I explained in my last piece on January 4, I had already installed and tested various pre-release community versions for my Motorola XOOM. The XOOM, unlike other 10.1″ Honeycomb tablets is a Google Experience device, is popular with Android tablet developers because it is a stable piece of hardware, and thus has been one of the very first tablet devices to receive the latest Android software.
The version I eventually settled on and used for most of the last two weeks was one put together by the talented folks at Team EOS, formerly known as “Tiamat” which has produced various customized “rooted” ROMs and overclocked kernels for the XOOM in the past, as well as early support for the tablet’s MicroSD card even before Motorola itself provided it in an update months later.
It has only been in the last two days that I have been able to obtain and install the semi-official Motorola XOOM Android 4.0.3 ROM, build IML77. I say semi-official because it is considered to be a “soak build” that the company is currently seeding to a pilot group of testers.
However, it is almost certainly going to be very close to the finalized software that most XOOM owners will receive as an Over the Air (OTA) update very shortly.
That being said, my experience with the Team EOS and Motorola IML77 builds have been extremely similar. I have used the same group of applications with both, and have experienced similar behavior and issues with the OS, so the likelyhood of there being ROM-specific issues affecting my general observations is quite small.
Before I get accused of being an Android hater, let me make one thing perfectly clear, and that is I like Android a lot. I use an Android phone (a Verizon Galaxy Nexus) and I’ve been an Android user for the past two years. I’m also quite educated in the systems architecture of the OS itself.
So whatever comments that follow in this piece, please keep that in mind before pulling out the flame thrower.
I’ve been bringing the XOOM with Ice Cream Sandwich on the road with me for two weeks, back and forth to Chicago. I’ve used it extensively while tethering via Wi-Fi to 4G and also connected to fast broadband in my hotels and in my home, so I have a good sampling as to how it performs. Overall, I’m not happy with it.
Now, there are certain aspects of Ice Cream Sandwich which certainly feel more responsive than its predecessor, Honeycomb 3.2. I’ve said so previously. Generally speaking, the UI is snappier.
However, it doesn’t have the benefit of a year’s worth of bugfixes and thus there are times when the software is actually less stable than Honeycomb. A lot of apps have unusually long startup times and render slowly or freeze up on the screen, even if you force the GPU to render 2D operations in the “Developer Options” menu.
And then there’s the dreaded “This App is not responding” dialog which gives you the option to wait or force close the app. But sometimes you’re not so lucky and you need to shut down the OS and re-start to get a stable environment again.
I have a whole bunch of personal issues with the way the UI is designed and is implemented on Android tablets that I’ve documented previously which could very will hurt the platform’s market acceptance, but those could be boiled down to overall aesthetic issues, not actual functional problems. This is not to say that aesthetic issues and UI design isn’t important, but app compatibility and performance issues rank much higher on my list of peeves.
And yes, I still hate the way Android’s multitasking is implemented.
Having researched the multitasking changes in Ice Cream Sandwich a bit further, I now realize that the “Recent tasks” button is in fact a task switcher that can in fact stop tasks, but it’s not a particularly useful one because even though it is supposed to “nice kill” the processes when you stop them, it doesn’t stop services from re-spawning and it won’t necessarily kill badly-behaving applications, like say, Facebook, which has to be one of the most awfully written pieces of garbage since iTunes.
So you have to end up using the real task killer in the Settings menu anyway.
It also doesn’t distinguish between tasks you “recently started” and tasks that are actually still running either. And it won’t stop services and apps from re-spawning themselves when you don’t want them to, and there’s no way to control apps which re-spawn services on a global operating system level and on a granular basis, just like iOS has with push notifications which you can turn on and off on an app by app basis.
That sort of thing is left up to the Android app developer, which may or may not put in a setting to turn off things such as polling of the network, et cetera.
I’m also aware of the “unused memory is wasted memory” argument and that Android releases resources on its own and also caches processes and apps so they start up faster.
Well guess what. If the memory isn’t there when a demanding application needs it, and the task killer, automatic or not is unable to stop an errant process, you’re screwed. Sorry folks, but if kill an app using a task manager or switcher, I really want to know that it is actually gone. And I suspect so do a majority of end-users that don’t work with things like Linux every day.
Enough with the multitasking arguments that I’m never going to win with the fandroids. Let’s get back to apps.
The apps that seem to run slowly, have long startup times and freeze up in Ice Cream Sandwich are graphics intensive programs that are are built in Dalvik, aka Java bytecode. The worst offenders I have seen have been Netflix’s main movie browsing UI, the Pulse newsreader, Weatherbug HD and yes, Facebook.
It’s difficult to tell exactly if there is a pattern to which sort of apps are the most problematic because unlike Apple, which periodically makes their developers re-certify on new OS releases or face exclusion from their App Store, Google doesn’t blacklist apps on the Android Market that were built to older Android APIs which might not run correctly.
And the Android Market doesn’t classify apps by what level of APIs they use, so you can’t selectively choose the newest or most updated stuff. Or even filter out older apps accordingly.
But I suspect that anything that was not built to take advantage of Honeycomb’s APIs to specifically run as a tablet app is going to have issues.
Google has improved screen rendering issues by allowing apps that were designed for smartphones (such as FaceBook) to either stretch to fill the screen or rasterize in their native resolution, a la iPhone apps on the iPad. But it’s not a totally foolproof process as on Apple’s iOS.
For the most part when I found an app that was designed to take advantage of Honeycomb (3.0, 3.1, 3.2) and was pure Dalvik, such as IMDB or Flixter, it ran well, although still not as responsive as their iOS counterparts. But the vast majority of the apps which exist on the Android Market or Amazon’s own Appstore are written against APIs for 1.5, 1.6, 2.0, 2.1, 2.2 and 2.3.
Google’s own ICS 4.0.3 apps such as GMail, YouTube, G+, Google Books and the Browser all run well, but that’s to be expected, since the company knows its OS and APIs better than anyone else and can optimize accordingly.
3rd-party Applications built in the Native Development Kit (NDK) which are written in native C++ fare far better. But the majority of these apps are games, and the basic architecture of the NDK hasn’t changed substantially since Honeycomb, so you expect stuff that runs effectively on the metal to still run pretty well.
Aye, and there’s the rub. NDK apps which run in C++ run great. Optimized Honeycomb or Ice Cream Sandwich Dalvik (Java) apps run better than they did previously, but not as fast as native C++.
Of course, I’ve been running all my Ice Cream Sandwich tablet tests on a XOOM, which is an NVIDIA Tegra 2 dual-core design. Already, the Tegra 3 quad-core tablets with faster GPUs such as the Asus Transformer Prime are starting to ship, but there are a few Tegra 2’s that just started shipping as well.
So does that mean in order to get optimal Android 4.0 performance, one should get a newer quad-core tablet and lower their expectations on existing models receiving the update?
That’s a bit of a nasty flavor of ice cream to swallow, considering that Apple has managed to exact extremely fluid performance out of even the first-generation iPad on iOS 5, using all native C++ and Objective-C based applications, which has a measly single core processor and 256MB of RAM, nevermind the iPad 2 with dual-core A5, which only has half the RAM of last year’s Honeycomb tablets but compensates with a more powerful GPU and more efficient apps.
I think we have to manage our expectations about Android overall. Because it uses Dalvik as its primary application engine, we have to realize that it is less efficient than an OS that runs only native C++ or Objective-C applications. So that means it needs to use more RAM, and also more CPU horsepower to give you an equivalent experience with ambitious tablet apps.
And that also means that the trend for the Bill of Materials (BOM) on full-size Android tablets in order to keep pace with the iPad is going to tend to be higher than Apple’s no matter what, even if they keep pushing up the specs to keep pace on only a pure performance level.
Nevermind stuffing these tablets full of worthless stuff like high-res cameras and HDMI ports and expansion memory slots that nobody really uses just for the sake of competitive feature creep.
And I don’t even want to get into Apple’s supply chain advantages which Google’s OEM partners are going to have a very difficult time catching up with.
So I’ve used Android 4.0 for two weeks on a tablet. Is it better than Honeycomb? Yes. But it’s not without its own share of problems. It’s going to take some time for apps to catch up to it, and you might want to consider using hardware that is actually up to the task of providing an optimal experience with the new OS.
Have you used Android 4.0 on a tablet yet? Talk Back and Let Me Know.
