Basically, they argue, by extending the functionality available through Google Play (the new v3.1 release of which is being rolled out straight away) Google has quickly improved Android, to rival iOS, without increasing the fragmentation of the platform, i.e. minimising further headaches for developers.
We have written abut the new services and APIs available (for example, supporting real-time multiplayer modes and the use of leaderboards, for gaming, and the geofencing API and Fused Location Provider for new location-based development support, and there’s also a music subscription service).
I’m struggling to get my head around this – in terms of binaries and compatibility – because while people commonly refer to Google versions by the desert-themed codename – Froyo, Ice Cream Sandwich, Jelly Bean, etc – the releases are actually underpinned by API versions, too. For example, Android 4.1 (Jelly Bean) and 4.2 (Jelly Bean II, as I refer to it) are identified separately by API levels 16 and 17.
So are the new APIs not going to be recognised in a new API level? Google states the new version of Play is compatible all the way back to Froyo devices. Is such backwards-compatibility only possible now, or why not before with the various versions? Time for a new entry in our What is…? series, perhaps – What is Google Play’s position within the Android architecture (?)
Perhaps it is all just semantics – there is no new version if all versions are called the same thing (but they just have different identifying numbers “behind” them). In other words, surely a new form of Android is still a new version, whatever its name. Could Android “freeze” forever at 4.2 and we just see succeeding new releases of an ever more functional Google Play? Reductio ad absurdum, or a Straw Man argument? Google Play holds the key, it seems.