For the first time, a significantly different Android device has hit the market. The HTC Magic, being distributed already, runs Android 1.5 (before any other devices) and lacks a hardware keyboard.
Those changes are not dramatic, and will be less so as Android 1.5 is made available to T-Mobile G1 owners. However, we are also hearing rumors of other Android handsets, Android netbooks, and the like, and some of the changes necessitated by those devices will be far more substantial. For example, an Android netbook would likely run at a higher resolution than 480×320.
Hardware manufacturers that depart substantially from what has come before have an obligation to the independent Android developer community, to help the community understand how to build for these different devices. The bigger the difference between devices and the norm, the bigger the obligation.
Some people might bristle at my choice of the term “obligation”. I certainly do not mean to imply that the independent Android developer community is somehow owed anything. But, manufacturers have to realize that if they do nothing, nothing will happen – no applications will take advantage of, or even necessarily work well with, the hardware changes the manufacturers elected to make.
Take screen resolution, for example. Suppose somebody building an Android netbook decides to go with a 1024×600 display, akin to the Asus Eee 901. It is highly unlikely that any developer has tested their application against that size of display, so their user interfaces may look rather goofy when stretched out on the larger screen. It is even less likely that anyone has altered their user interface to do something useful with that size of display, such as converting a tabbed screen to one without tabs, taking advantage of the extra “real estate” to reduce the number of clicks a user has to make.
Some hardware changes cannot even be addressed well with updated emulator skins, or even full-fledged replacement emulators. New sensors, new forms of user input (e.g., fingerprint scanners), and the like all require testing with hardware to be effective.
I recommend that Android device manufacturers not only let independent Android developers purchase hardware directly, but also establish a hardware “loaner” program. With the latter, the manufacturer would set aside some number of units, sending them out to developers who request them, with a modest service fee. Developers would be required to return the units after the rental period, at which point they could be hardware reset and then loaned back out. This would put hardware devices in the hands of interested developers, yet it does not assume that developers are in position to buy each and every Android device ever made.
The sooner that manufacturers can get their Android devices into developer hands, the sooner their devices’ unique hardware features can be leveraged, leading to better user experiences and, hopefully, better sales.
