[blocke]

When you say "compatibility break" I hear "your 1.5 to 2.1 apps won't run on 2.2" not "2.2's increased performance enables a new class of applications that won't work on phones with an older OS".

I'm not seeing the problem here...

[CountSessine]

For a developer targetting a new feature in a new release of the Android OS, it's a huge problem. If I want to make a program targetting a new feature in the iPhone OS, I can do that confident that 99% of all iPhones will be upgraded to $(CURRENT_OS_VERSION)+1 within a couple of months of the upgrade being available. It's simple. Everyone is on 3.1.3 - I don't have to worry about missing a big chunk of the market and reworking my code to accomodate old OS versions.

So do I recode my FFTs in Java and say goodbye to anyone running pre-2.2 until the carriers/handset makers get around to upgrading everyone in a couple of years time, or do I keep my code in it's little C++ NDK ghetto, safe from testing and rapid enhancements that Java would bring?

It's so frustrating that Google has fixed this problem NOW, but between carrier indifference and custom-'enhancement' inertia at handset makers, it's going to take forever for 2.2 to be a legitimate development target. This is a solved problem in iPhone-land.

[alphamerik]

So by compatibility break you mean that you are pissed that Android can run at any processor speed?

I have news for you, in iPhone-land the phones in a couple years will be faster too. :)