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?
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.
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?