I read the article and kept hearing echos of the Microsoft strategy of the 90s as well.
History may not repeat, but it rhymes.
back
1 comments
I think that you hear whatever you want to hear, but the truth is very different: Google's apps and APIs are just cloud endpoints and weaving them into AOSP doesn't make sense and just delays updates, as the same author previously scribbled: http://arstechnica.com/gadgets/2013/09/balky-carriers-and-sl...
As for "strong-arm tactics", what is referred to is explained in this post: http://officialandroid.blogspot.com/2012/09/the-benefits-imp...
As Andy Rubin puts it, Google will not encourage non compatible forks, it is in their interest to have Android developed apps run on all Android devices. Anyone can still have a go but Google won't encourage it.
It's a very flawed and overwritten attack piece, seemingly coming out of nowhere.
I think the strongest argument the article makes is the claim about the new Location APIs. Location algorithms are not dependent on Google services and have always been part of the core APIs, but now Google is moving new location algorithms into their closed source app. It's an obvious power grab, they want AOSP to be less and less useful on its own.
Actually location APIs do use core Google backend services (the wifi geolocation database). Even Keyboard does (spelling). In a way they are doing the opposite, building their services into everything, which is a natural googly thing to do to add features/improve them. At that point they close source them as they dont want other people using the services without signing up.
The way to compete is either to make standalone apps that dont require services (ie like the old unmaintained ones) or to build your own services, either open or closed.
I think the location APIs may also use system-level facilities that aren't open to normal applications, such as the ability to detect nearby access points even when WiFi is off and the device is in standby. So it's not clear that apps can implement it themselves without relying on Google. Also, the APIs for newer stuff like geofencing are Google-proprietary and don't support alternative providers, so mobile phone makers that don't want to rely on Google's services can't substitute a different backend without breaking existing apps.
It does not use system-level facilities that aren't open to normal applications. People love to hate on Google; if they ever embed features into the OS only they are allowed to use you will hear about it very quickly.
There is a class called WifiManager[1] which lets you ask the user to allow background scans. It also lets you see the results of the last scan.
It is unfortunate that the Geofencing APIs are not part of the android platform, but I suppose it's possible they use Google services.
1: http://developer.android.com/reference/android/net/wifi/Wifi...
If they rolled the improvements out as part of the platform, it would inherit the slow rollout weakness as any other platform API (it would take months/years to become viable and unavailable on existing versions). If they went the static library route, it would balloon the size of of the apps and they wouldn't be able to do the same sort power/efficiency call coalescing as they would by having an always updated client on the device.
Is it really that obvious? What power are they grabbing? By this reasoning, Google may not augment any 'traditional' AOSP service with improved functionality. That's obviously ridiculous, so what solution would you envisage?
The article was pointing out how Google is moving more and more functionality from open source to closed source. So, one way to counter that would be to augment the "traditional AOSP service with improved functionality", but license the code as open source. The service endpoints can certainly be closed, but the code to access those endpoints could be open. And the license to use those endpoints could be open source friendly.
Now, that may not be a good business decision, but it certainly counters the argument of the post.
An aside: I appreciate what google is doing to fight Android fragmentation, but also see some of the tactics as anti-competitive.