Comment by DCKing | Hacker News Reader

Comment by DCKing | Hacker News Reader

What are they talking about, exactly? It's perfectly possible to "unbundle" Android and Google's services. Google goes furthest in unbundling possibilities for any popular operating system, since they give away the source code for the operating system to be freely modified and be bundled with other cloud services. Amazon, Microsoft+Nokia (Bing) and many Chinese smartphone vendors (Baidu mostly) have all shown that this is possible. People pretend that Android without Google Play Services is somehow worthless or necessarily incomplete, which I don't agree with in the slightest.

It seems to me that what they're talking about is actually that Google's cloud services package bundles default Google Search, and Google does not provide the user or vendors with enough flexibility here. Okay, I'll definitely grant them that. So they want to use Google's cloud infrastructure selectively for the Play Store, but not for other profitable and integrated cloud services? Sounds a bit like eating your cake and having it too. If you look at this way, it doesn't seem such a reasonable request, although I guess it would be better for the market if Google was forced to give in.

It is possible to unbundle Android, but if you are a phone manufacturer that makes Google Android phones, you get very strong pressure from Google if you try to also make non-Google Android phones.

So any large manufacturer can not try new innovative Android variants at fear of being cut off from Google Android.

It's not just pressure. They outright cut you off. You cannot ship Google Androids and non-Google Androids. It's part of the MARA.

> You cannot ship Google Androids and non-Google Androids.

Any source for this?

http://www.wsj.com/articles/SB100008723963904447090045776523... and various other articles on the same incident. OHA members are required to agree not to ship devices running Android forks.

That article doesn't say what you have claimed.

And, apart that Aliyun store had pirated Google apps, it was not an Android fork.

Still waiting those MADA clauses forbidding non Google Android

MADA is confidential unfortunately. (Wonder why?)

And no, that incident had nothing to do with whether or not Google apps available in Aliyun's store were pirated. Acer was told they'd be removed from the OHA if they shipped Aliyun's fork of Android.

> MADA is confidential unfortunately. (Wonder why?)

If MADA is so confidential why you talk about some clauses as facts? Or you have proofs of them or you're just inventing things

> cer was told they'd be removed from the OHA if they shipped Aliyun's fork of Android.

Second time, Aliyun is not an Android fork

Why do you talk about things you clearly don't know? Are you just spreading FUD because of your hate against some companies?

It has already been discussed even in the mainstream news quite some time ago: http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-...

Presumably (judging by comments on Russian websites), Yandex has got an agreement to include (or included) in the report documents that show you have to play by Google's rules and install Google services on every model in every region of the world once you signed the service agreement, or (even better for them) direct prohibition to pre-install Yandex services.

Yes, I know that has been discussed, but there is no article (and not even in the Ars one) were it is said that an OEM is forbidden to launch a non Google Android device like the op is repeatedly claiming

Again: See the Acer/Alibaba incident.

Apart that what the OHA forbids are forks that doesn't pass the ACT, Aliyun was not an Android fork

Please, stop talking about what you clearly don't know.

Still waiting those clauses that you post as facts. Can you link to them or not?

The case may actually let us see a new version of the MADA if they can require it be in public court records.

The MARA agreement Google mandates is very anti-competitive. It protects some services by mandating their inclusion in order to get others. Google now mandates almost 20 apps be packaged on devices, when the manufacturer really only wants the Play Store.

If that is anti-competitive, then Apples locked down operating-system running only entirely Apple sanctioned code must make the FTC explode.

Then of course, the market is smartphones, not Android phones. If something is anti-competitive comes down to the market situation, and has usually very little to do with any specific behavior.

The non-free Google Play APIs, which are heavily used by many Android apps. This makes it a real pain to run popular Android apps on Blackberry, for example. So in practice, very few users do.

Edit: Warning - lots of downvotes in this thread, seemingly for any Google critical comments.

> The non-free Google Play APIs, which are heavily used by many Android apps.

I think this is an exaggeration. Some developers make too many assumptions, sure, but I don't think you'll find many high-profile non-Google apps that don't run on a Kindle Fire tablet for this reason.

EDIT: People seem to think that Google Services contain the bread and butter of the Android OS, but if you look at what APIs are actually provided by them [1], it doesn't contain anything that is not a client of Google's cloud services.

[1]: http://developer.android.com/google/index.html

The high profile ones have a properly adjusted version in Amazon's store. When I got my Kindle Fire in 2013, I ran into a lot of apps in Amazon's store that refused to run or broke in weird ways for lack of Google's APIs.

I don't know if it's improved any since I gave up on low profile apps when using my Kindle.

Even OpenGL extensions are now only available through the Google Play API. It is NOT an exaggeration.

I think you misinterpreted some of Google's documentation here, or are deliberately FUD'ing. You made me look around in Android's documentation and the web and I did not find anything about this. Care to share a link?

I my experience, this is not an exaggeration. Most of the top popularity apps expect the Google Play APIs to be present. Have you had the experience that this is no longer the case?

You have to be specific here.

1) How many apps will flat out refuse to run if Google Services are not present, as opposed to have reduced functionality? Having a dependency on Google's Services library only means that the app will use it if it is available, not that the app will fail if it's not.

2) How many apps use more than the Location / Maps / In-app Purchases API, which are implemented in a compatible way by all of the other parties I mentioned?

> it doesn't contain anything that is not a client of Google's cloud services

What about the Chromecast and Android Wear APIs?

I know that Chromecast OS and Android Wear they are both (sadly) based on closed operating systems and somewhat rely on Google APIs, but that shouldn't be an excuse to prevent people that don't want Google Services on their phone from using smartwatches over bluetooth or mirroring the screen to their TV in their own local network.

> What about the Chromecast and Android Wear APIs?

The Chromecast does not operate over a local connection. It is actually operated 'through the cloud' - if you are controlling your Chromecast, you're sending operations to your Google account over the internet, which are then relayed to your Chromecast which is also tied to your Google account. Note that Google supports a non-cloud dependent sort-of-alternative for Chromecasting called Miracast in AOSP.

Android Wear is heavily dependent on Google Now, Google Search's voice recognition techniques. An Android Wear device cannot do anything without access to Google's services - it is far more than 'somewhat dependent'.

So yeah, both are in Google Services because they actually fully depend on Google's services.

Both of these things being intentional choices to develop crippled hardware that's reliant on proprietary services. A huge disservice to consumers.

Documentation for Miracast in Android seems very lacking. According to Wikipedia, Google decided not to support Miracast on the Chromecast, probably because it is an open standard that would have made the effect of selling the Chromecast cheaply weaker on their goal of raising Android adoption and locking in customers. I don't think that all commands are relayed over Google, since if that were true, Android should be clever enough find my Chromecast if I was connected to another WiFi network. The delay would also make it impractical for quite a lot of people. IMO chromecast should have been based on open standards.

Android Wear would be just be as heavily "reliant" on Google Now as Android is. Google just decided to give it a proprietary version of Android that is heavily integrated with Google Now. Android Wear could do quite a lot without access to Google Services. It is actually pretty pleasant to use without talking to your watch.

It seems like we both have different points of view on this, but in my opinion Google has acted in a way that favours their interests over their customers' freedom.

While the GoogleCast API’s are part of Play services, the rest isn’t true. Communication between a GoogleCast device and your phone takes place mostly locally.

Communication with Chromecast happens directly over Wifi and does not involve Google services. Chromecast uses the DIAL or mDNS protocol to discover apps on the local network. Some apps like Netflix can use DIAL protocol to control app on other devices, like Tivo or smart TVs, on the local network.

Chromecast does have a new guest mode that allows guests to control Chromecast without connecting to Wifi network. Those commands presumably are relayed through Google servers. But it isn't turned on by default.

Chromecast does need to be connected to the Internet to download the receiver app that runs on the Chromecast. If the Chromecast could cache the app, or get it from the controlling app, it could run completely disconnected from the Internet.

For clarification, to initiate a ChromeCast session it talks to google, but the sender and receiver then establish a local websocket connection for local control.

It is developers fault not to use the other API's like the Amazon App store ones.

Perhaps the downvoting is not from Google supporters but fro now accurate information

Here's what Google says about the location API:

> This API is not the recommended method for accessing Android location.

> The Google Location Services API [...] is the preferred way to add location-awareness to your app.

http://developer.android.com/reference/android/location/pack...

It seems like Google is intentionally encouraging developers to switch to their closed APIs. Most developers will probably follow what the red warning message says instead of spending more time building another solution.

Google wants to keep control of all Android clone OSs, so they add convenience features to their closed-source libraries, encourage developers to use them, and force phone manufacturers to bundle them with their OS.

Bundling an alternative implementation of the API is probably a bad idea because of copyright.

They deprecated a mapping API in AOSP because AOSP is not tied to a cloud service and should not depend on cloud services. AOSP on its own cannot assume that a mapping service is available, and neither can Android apps. For the same reason, there are no app store, social networking or cloud storage APIs in AOSP. AOSP does not depend on a cloud service.

They introduced a mapping API for Google Maps in Play Services because Play Services contains all client libraries for Google's services. The Google Services APIs are a container for all libraries to consume Google's cloud services.

This is not symptomatic of Google's evilness.

Bundling an alternative implementation of the API is probably a bad idea because of copyright.

That'd be a fun case; you could just use their own arguments in Oracle v. Google against them.

Probably because Google got a lot of negative PR for forcing manufactures away from more accurate Location API implementations so now they need to use a private API as an excuse to kill location service competition in the future.

You can see the internal Google emails here where they note SkyHook was more accurate than their implementation http://www.businessinsider.com/google-skyhook-emails-2011-5?...

And they force Motorola to stop shipping devices unless Motorola agrees to not use SkyHook.

> And they force Motorola to stop shipping devices unless Motorola agrees to not use SkyHook

The trial stated that this was not the case

Reply on news.ycombinator.com