A compatibility break in that if you program something with a heavy CPU burden like a bunch of image FFTs or belief networks (as many of us have done on iPhone), you can't rely on a pre-2.2 device to complete the task in a reasonable amount of time. For anything CPU intensive, do you recode it in java or do you keep limping along with the C++ NDK?
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".
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.
