There's Compatibility, and Then There's Compatibility
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:
the Android 4.2 regressions around changes to
the Android 4.1 regression around changes to
the Android 3.2 regression around changes to
the Android 3.1 regression around changes to
Some of these regressions are opt-in based on
but most are not. All of these regressions are understandable,
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
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.
Need an extra hand with your Android app development project? CommonsWare can help — reach out for details!