Comment by mooreds

11 years ago

I read the article and kept hearing echos of the Microsoft strategy of the 90s as well.

History may not repeat, but it rhymes.

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.

      2 replies →

    • 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?

      1 reply →