Chris Buerger

“Good” Android

Following a recent trip to China, I acquired an Android tablet running Release 1.6 (Donut). Total retail price: $90. Unlike an iPad, it is both 'Designed and Made in China.' Running on an ARM platform and containing an 802.11 interface, SD card slot and a touch screen, it is actually a reasonably speedy experience. However, that is where the positive news ends.

The bad news is that the device reboots on average every 15 minutes, does not hold its battery charge for more than half an hour, does not allow application downloads from the standard Android Market Place and contains a rather temperamental touch screen. Clearly, a number of issues are related to the choice of low-end hardware components, which is also reflected in the incredibly low retail price. However, most problems are likely either software or system integration issues for this Android device. This led me to the following question:

"What is Good Android?"

Even at such a low price, end-users will expect a stable device. Given the tablet form factor, users will expect to use the device in mobile scenarios. I would expect that I could download some market place games to keep the kids entertained. If you look at it from a use case perspective, I would expect that many use cases from my Nexus One are replicable. If you look at it from a brand perspective, I would also expect that the user experience from my other Android devices extends to anything that runs the Android stack. Which leads to the next question:

"Who is responsible for ensuring Good Android?"

Well, it is not Google. Android is an open source distribution. The quality of the Android stack on a specific device is the primary responsibility of the manufacturer and/or the operator selling the device. For tablets, there often is no operator distribution at this time, especially for low-end devices in China. In its SDK, Android contains a compatibility test suite (CTS) that tests for API level compliance, but it contains no comprehensive reliability and performance tests (e.g. for power management). So, the question becomes:

"What can you do to create a Good Android software stack?"

The development of a high-quality software stack that is efficiently brought to market focuses on two main points. One, a stable development base that is well documented and supported. Wind River’s Platform for Android is an example. Two, a comprehensive test plan and, ideally, automated test execution harness containing thousands of test cases to ensure the stability of the devices. Wind River’s FAST for Android is one possible solution. I am sure there is more that can be done to ensure consistent quality of Android distributions is maintained – what do you think?

Creating Success For Your Android Device (a.k.a lessons learned from the iPhone 4)

The avalanche of customer issues following the launch of Apple’s latest iPhone device illustrates a lesson that is not only eternally true for any consumer electronics device, but especially impactful for a highly subsidized mobile phone. The lesson is simple – test your device and software thoroughly or pay a high price. A high price in RMA costs, brand value, customer switching costs, emergency engineering expense as well as a surge in costs for customer relationship management.  

Today, we at Wind River are taking the wraps off a brand-new solution called Wind River FAST (Framework for Automated Software Test) for Android to determine the functional readiness, stability, performance and compliance of devices running the Android stack. We have been closely working with a number of operators, device manufacturers and application processor providers over the last nine months to tailor-make the unique capabilities of this automated test solution to meet their requirements to rapidly test an Android device.  Primarily focused at Smartphones and other mobile Android platforms, FAST for Android contains thousands of Wind River authored test cases to thoroughly test your Android device from the hardware abstraction layer, lower layer drivers and protocols such as Bluetooth, telephony and Wi-Fi, through to middleware layers and finally to the UI. It also includes tens of thousands of useful open source test suites such as LTP and Iozone, as well as the latest version of the Android Compatibility Test Suite (CTS). In effect, FAST is not just an automated test tool, it is also a full mobile device test plan and set of benchmark test results to help QA departments.

FAST for Android is available for evaluation right now, so if you are planning to deliver a high-quality Android device to meet your customer’s performance and reliability expectations and keep post-launch costs low, check us out and evaluate the new Wind River FAST software solution.

The ‘Big Reveal’ Release Approach in Mobile Linux – How Android and MeeGo Differ

A couple of weeks ago, I read through a somewhat heated email thread about the ‘Big Reveal’ mentality that Intel and Nokia were claimed to apply to the pending MeeGo 1.0 release. By coincidence, the timing overlapped with the excitement Google was stirring up for its 2.2 (Froyo) release of Android. Both events made me wonder about the value of a ‘big reveal’ approach in mobile open source stacks, and whether there might not be developments that occur within rapidly maturing software stacks that are native and systemic to the open source model, and that at the same time change the potential impact of ‘Big Reveal’ releases of either Android or MeeGo.

Don’t get me wrong, working for a commercial mobile Linux provider, I can see many benefits to having a big reveal release approach. It forces engineering, integration, testing and documentation discipline, it helps upstream users of the SW stack to rebase their commercial or otherwise public offering to the latest version and, last but not least, it also drives predictability in realizing (as opposed to prototyping) innovative technology. Now, both Android and MeeGo have organizations like Google, Intel and Nokia willing to heavily invest into a the structured development of innovation technologies, and the maintenance and the community development aspects of their respective open source stacks. However, if you look at the overall percentage of code that is maintained specifically for the purpose of creating the next big mobile software stack release versus code coming from general open source projects (OpenSSL etc…), it becomes clear that the vast majority of code comes from mature, well-maintained projects with their own ‘To-Do’ lists and functional update plans. Of course, one could argue that the percentage and importance of Google authored/sponsored code is much higher than for MeeGo, however, I believe this is really more a reflection of the different maturity of the respective stacks rather than a fundamental difference in approaching code development and community involvement. In other words, the difference is temporary.

Where I can see a difference in the approach between Android and MeeGo is that, under the guidance of the Linux Foundation, MeeGo release predictability is also being driven by initiatives like opening up the 1.1 development tree at the same time as releasing the 1.0 version. Google, by comparison, is still keeping its cards close to its chest when it comes to future functionality, only allowing close ecosystem partners such as major OEMs, operators and selected commercialization partners such as Wind River a limited level of visibility.

Where this difference matters is that it forces companies building Android and MeeGo devices to adopt a different planning model for their own mobile projects. For Android, one has to accept that the big reveal approach is ‘the way’ to rebase your own work to get the latest functionality. And Google has become quite adept at using its developer relationship cloud to create ‘Christmas present’ like eagerness to explore it. With MeeGo, on the other hand, the development model appears to be much more organic, like growing (watering, fertilizing) your own apple tree that gives you apples once a season (i.e. for a major release). 

For your planning requirements and independent of the OS itself, which approach works better for you?

Android Market Integration - Do You Still Care?

In the mobile phone world, content management systems to allow users to download a variety of monetizable content and (largely J2ME based) applications have been around for more than a decade. Of course, the popularity of the iPhone and its associated AppStore have put a special spotlight on the importance of having a well-stocked offering to personalize a mobile device with, well, anything looking like a software application that you could possibly imagine you ever needed to have access to on a device that primarily lives in your pocket or purse.

 

One of the main developments during the last couple of years is that the aspect of ensuring API compliance and adequate performance of the mobile application with the underlying OS/virtual machine/execution environment, which previously was largely hidden because it was operator managed, has become a hotly discussed area. This is creating much friction between application developers, handset manufacturers, system integrators, operators and the OS gate keeper to the market place. In the case of the iPhone and Android, this responsibility is now largely assumed by Apple and Google respectively.

 

In particular, Android device compliance and getting access to the vaunted “With Google” label was often directly associated with getting ‘Android market’ access.

 

Well, it seems that manufacturers bringing out Android devices increasingly stopped caring.

 

Consider this:

1) A series of established service providers to the mobile industry such as Cellmania, True North and Arvato have announced Android application management services, either to act as an enabler to ensure app compliance prior to loading them onto an operator’s content management system or to add Android .apk distribution capabilities to their hosted offering. In some cases, this is driven by a perceived lack of Android market support to integrate with highly custom pre-paid and no contract rating and billing systems. In other cases, the point is simply made that it is more efficient to aggregate all content types for all phone operating systems in one repository.

 

2) There is a whole new ecosystem of CE and other non-phone devices types (we at Wind River call them ‘embedded Android devices’) that contain Android and associated branding, alas, there is no Android market place. The upcoming Archos 7 Home tablet (http://www.engadget.com/2010/05/06/archos-7-home-tablet-ships-to-android-lovers-in-june/) is an example for such a device; go to smaller Korean, Chinese and Taiwanese consumer electronics manufacturers and you will find a whole slew of Android powered consumer electronics devices without the Android market.

 

So, unlike the iPhone OS or other mobile operating systems like BREW, the importance of market access for Android as a catalyst, carrot or big stick to ensure device compliance seems to have met a real world reality check. In their frantic adoption of Android, device makers are increasingly and skillfully using all of the benefits of Android without caring about its application market and the ‘With Google’ label.

 

And, as evidenced during my visit to the back alleys of Shenzen/China, don’t be surprised to see more devices sporting a ‘With Coogle’ mark ;-).