There's Compatibility, and Then There's Compatibility

My post yesterday regarding Android 4.3 got an unexpected reaction from a Google engineer. I had expressed concerns regarding this sentence from the Android 4.3 release notes:

For multithreaded processing, the renderer can also now use multithreading across multiple CPU cores to perform certain tasks.

The response from the Google engineer stated “We do care about compatibility you know :)”

I never claimed otherwise.

However, I’m not sure if there’s been a single Android release since 1.0 that didn’t break something for somebody.

Google definitely cares about compatibility. For all the wailing and gnashing of teeth that you hear in some circles, I’ve been impressed as to how well Android has maintained compatibility, backwards and forwards. However, Google cares about other things as well, such as privacy and security. Concerns are sometimes in conflict, and sometimes compatibility loses the fight.

Heck, just within the last two years of my blog, we have:

Some of these regressions are opt-in based on android:targetSdkVersion, but most are not. All of these regressions are understandable, even laudable.

However, they all broke apps.

Sometimes, we are told about these regressions, which is why I am grateful for the 4.3 notes regarding the impacts that restricted profiles will have on apps. Sometimes, we are not told about these regressions except via secondary channels, such as the READ_LOGS change.

We can’t even say that these sorts of things only affect ancillary behavior. For example, Android 1.5 broke a number of apps, because the view rendering logic bumped up how much stack space it consumed, causing apps with deep view hierarchies to run out of stack space. And the 3.1 BroadcastReceiver regression comes up at least once a month on StackOverflow, just in the questions that I happen to look at, despite all the documentation and blog posts and previous StackOverflow answers on the subject.

Moreover, I have seen some very scary code in my time with Android. I have seen stuff that I know runs counter to what Google wants, sometimes because Googlers even chimed in, pointing out how nasty the code is. Yet, I am sure that there are production apps running this code. Based on the one-sentence description of multithreading in the renderer, I certainly cannot assume that all of the million-plus apps on the Play Store will work. It’s not because Google doesn’t want them to work, but Google didn’t happen to test apps that contained scary code that somehow runs afoul of the multithreading.

Now, I will admit to perhaps being a bit too harsh in my statement of concern. However, I get really really nervous when the most “marketing” of the release notes contains a throwaway sentence about a core change to rendering logic… which is then never explained in greater detail anywhere else that I have seen. Call me paranoid if you wish. If your last name was Murphy, you’d be paranoid about this sort of thing too.

I do not wish for my concerns about compatibility to be considered statements accusing Google of malfeasance. On the contrary, I can certainly see where allowing rendering code to use multiple cores more effectively can be hugely beneficial, even worthy of some small amount of breakage of apps doing bizarre stuff in the view rendering area. But I need to help make sure that developers go into development with eyes wide open and are aware of potential pitfalls.

In other words, Android is a coal mine, and part of my role is to serve as a designated canary.

All that being said, I do apologize to anyone who interpreted my comments as an attack.

 

Meta


Creative Commons License