Most applications don't use any sensors at all, yet you have to deal with the situation if you plan to use them. And there is a big difference in designing an application for devices having only a touchscreen keyboard and devices having a physical keyboard.

The sensors situation is the same on all platforms - if you want to use them, you have to handle them. If not, just ignore them. How is that more complicated on Android?

The difference with keyboards - the original point was "all the keyboards" (i.e. HTC IME, Swype, etc), not just hardware vs software. When you prepare your application for software keyboard, whether pan-and-scan or resize, it will just work with hardware keyboard (opposite is slightly more complicated: when you assume only hardware keyboard, then the software keyboard has surprises in layouts for you).

Getting OT: sometimes I wonder, how people could handle PCs 20 years ago. You had CPUs with different speeds (286 to 486), different graphics cards with different resolutions (EGA, VGA, SVGA), operating system that didn't abstract the differences and yet the PC was considered single platform, much more successful than competing unified platforms. There wasn't rampart rationalization against "fragmentation", like today.

>sometimes I wonder, how people could handle PCs 20 years ago.

They didn't. That's why the Mac was a runaway success and the fragmented PC marketplace floundered.

> You had CPUs with different speeds (286 to 486)

We had the turbo button back then. Maybe we need a turbo button on the Android. You could call it the "Anti-Frag" button.

</facetiousness>

Just getting the ASCII art right back then must have been the toughest part.

>Different keyboards do not enter the picture at all.

I think, this is not completely true: http://news.ycombinator.com/item?id=1860578

Different keyboards lead to different users experience with application.