The Register reports from Google I/O that Android will offer an i-Phone-like App Store.
The more interesting part of the report is at the end – after all, how will such an app store determine what applications are compatible with what phones?…
"They can add to it. They can remove from it. They make it their own," Rubin said. "They can rip out all the Google stuff and put in all Yahoo! stuff."
This goes for entire APIs (application programming interfaces) as well – an obvious a point of concern for some developers mulling apps for the platform. "I see Android and I see all its APIs. What’s to stop someone from turning off all those APIs?" one developer asked Rubin.
There’s nothing to stop them, Rubin said. But he indicated that Google will provide tools that enable developers to easily verify the make-up of each Android handset. "We’re providing a piece of technology – I can’t go into a great amount of detail – that tests the APIs," he explained. "This will be a script that you’ll be able to run…and determine whether all the APIs are there."
As a developer, I don’t see how this will work. First of all, developers need APIs to determine individual capabilities, not a script that does this all at once. I need to do this at runtime because capabilities may change over time as the phone software is upgraded and updated.
Even if I know a capability doesn’t exist, what do I do? I can’t code around potentially thousands of missing capabilities.
Finally, even when capability tests exist and they indicate a capability is present, this won’t guarantee compatibility. There’s already a similar situation in the Java ME world where Sun Technology Compatibility Kits (TCKs) are used to test JSRs. There are thousands of very detailed tests and despite the fact that Java runtimes (Java Virtual Machine,JVM) on phones are run through them, it’s not possible to guarantee that a Java ME application that runs on one JVM will also run on another JVM.
Why is this? Despite the large number of tests, they cannot test everything. It’s not just the presence of an API that’s important, it’s also the behaviour. An API might pass a test but have an obscure bug that only becomes evident under particular circumstances. An API might also only implement a sub-set of a capability that’s either enough to pass the test or due to lack of some phone hardware capability. Also, no matter how hard humans try, with thousands of APIs, the expected behaviour of some of them will be to some extent ambiguous and open to interpretation. There are also types of test, particularly UI related, that are very difficult if not impossible to automate (The JAVA TCK’s rely on manual tests for these).
Hence, I currently believe there will always be Android fragmentation – and certainly more so than with more controlled platforms such as Symbian, Windows Mobile and the iPhone.