Ars's headline is inaccurate. These are the licensing terms for Google's closed-source suite of ecosystem apps that turn a generic AOSP-based port into a Google-logo commercial product.
The restrictions stem from a choice you have to make: If you use the Google ecosystem in your products, you have to use all of it, and you can't use parts of Android to compete with the Google ecosystem. You can make the other choice, but, in those cases, Google doesn't want you to have their closed, proprietary apps. That might be hard-nosed dealing, but it isn't more restrictive than Google's competitors are in similar circumstances.
There are some seemingly nonsensical parts to the agreement, especially the prohibition against distributing an SDK derived from the Android SDK. I'm having a difficult time imagining what harm that might cause. Some OEMs, like Samsung, are shipping SDK extensions that Google apparently is fine with.
The openness of AOSP is not compromised by this contract. Amazon is an example of a partly direct competitor using AOSP. Google has done nothing to thwart Amazon, not even a hint of FUD. If only Oracle were that straightforward about Java.
> There are some seemingly nonsensical parts to the agreement, especially the prohibition against distributing an SDK derived from the Android SDK. I'm having a difficult time imagining what harm that might cause.
as somebody who has had to deal with vendor proprietary SDKs for devices, I can assure you that only having to deal with one stock Android SDK that has not been tempered with by hardware-engineers under time pressure doing software is a very, very good thing.
This way the really ugly crap is contained within vendor specific SDK extensions (which can be abstracted away) instead of the crap being sprinkled all over the basic OS SDK which would require one SDK per device you're targeting and would inflict all sorts of bugs on you even when not touching vendor-specific parts.
In general, most of the terms mentioned in the article are, while being horrendous for the device maker, are very nice for both users and developers targeting these devices.
Yes, it's nowhere near "open", but also, yes, this ensures some level of quality for both users and developers.
I imagine not shipping a derivative SDK is to prevent one vendor from making an incompatible "Android+" (and the next vendor, etc) which would cause fragmentation. Instead they get to expose extra APIs through the updater app in the one true Google Android SDK (and you use the same mechanism to get the Google APIs).
AOSP is getting smaller. Google's closed source Android (aka GMS) is getting bigger. On a standard Android phone, a ton of it is closed source and under a proprietary license. It's now at the point that the majority of the most popular Android apps are not Android apps any more. They're GMS apps and they won't run on AOSP. Any app that implements modern location services, in-app purchases, etc, simply won't work on AOSP or any Android variant that isn't Google's with all the GMS bits.
I don't think I would expect to do in-app purchases without my own e-commerce capability, or using some ecosystem's IAP support, and AOSP never had an open source IAP framework.
There are other places where one can complain that Google has effectively abandoned open source components of AOSP. These are places where Google has made previously standalone apps part of their ecosystem.
On the other hand, alternative distributions like CyanogenMod have become sustainable VC-fundable businesses based on the relative reliability that important new core OS features do go into AOSP on a timely basis. ART, for example. It's there to read and study and try long before any Google-label OEM benefits from it.
1) Location API changes - Moving these into GMS is a bad decision, and I think hurts the core platform
2) Hangouts - Moving messaging into a non-standards compliant and closed source solution hurts everyone (except Google, at least in the short-term)
These to me indicate a move towards a more closed model within Google generally, and I think that is terribly unfortunate.
WebRTC is a transport/application level API for building things on top of, it is NOT an open interoperability standard of the same sort XMPP is at all.
iMessage uses TCP, but that doesn't make it an open source application with an open protocol.
One third of all Android devices being sold (that's over half a million a day) don't have GMS on them. If you want to find them I'd suggest you start in China, or a FSF meetup, or Amazon headquarters.
I have GMS on my Nexus phone, but I also have the F-Droid repository, the Humble Bundle store (and briefly had the Amazon App store too).
I also have Chrome installed on my Ubuntu desktop (though I mostly use Firefox, and have Chromium too). And Steam.
that your phone has "fucking" GMS on it.
that.. is the point. The phones sold without GMS in china are sold that way because of licensing reasons. Everyone puts GMS on them at purchase time.
> The restrictions stem from a choice you have to make: If you use the Google ecosystem in your products, you have to use all of it, and you can't use parts of Android to compete with the Google ecosystem. You can make the other choice, but, in those cases, Google doesn't want you to have their closed, proprietary apps. That might be hard-nosed dealing, but it isn't more restrictive than Google's competitors are in similar circumstances.
Yes but that choice is not made on a per-product basis but on a global company wide basis. I could easily see this as being viewed as anti-competitive conduct (as I also saw MS deals penalising OEMs who shipped any products without Windows).
> The openness of AOSP is not compromised by this contract.
I disagree with that conclusion. As I read the article any company that accepts the agreement promises not to fork Android. Amazon does not sign this agreement and therefore can still use AOSP freely and openly but a large bulk of the world's consumer electronic companies cannot. This doesn't make AOSP closed but it does compromise its openness.
I'd agree but for one fact. OEMs have entered into these agreements freely. Amazon (and CyanogenMod&co) aren't the lucky outsiders, they're the ones proving the openness of Android.
The inability to separate AOSP from Google's services irritates me. Google is leaving the door open for anyone to compete with them; use AOSP -a fully functional OS- and provide a better service than Google products offer, you won't owe Google a dime, and you'll be a serious competitor.
As far as I know, there's nothing stopping an independent OEM from releasing unlocked devices. An end user is free to install gapps on his own, and it's laughably easy to do.
> I'd agree but for one fact. OEMs have entered into these agreements freely.
The OEMs aren't the (only?) victims of the anticompetitive behaviour. It reduces the market for services competing with the Google services (as they can't sell to anyone who is also a Google customer) and it affects their customers (end users and telcos) and the choices available to them.
By "independent OEM" do you mean one who doesn't sign the contract?
Ars' headline is not just inaccurate. It's part of what now seem like a clear design of FUD against android.
I don't know their rationale for that but I'm starting getting sick of it. Every. Damn. Article. They insinuate, more or less clearly, that you should be very careful with android, it's not open! The best thing being: they are always talking about Google play services instead of android. Even when they explicitly say AOSP, they make it sound like is a minor part, not enough to run an actual phone (which, for being any useful, requires google apps, is their thesis I guess)
It's part of what now seem like a clear design of FUD against android.
Basically it comes down to if you're being pedant or a layperson.
A pedant is very careful to consider "Android" the AOSP and noting else.
To almost anyone that hasn't tried to install non-stock firmware on a device "Android" includes the proprietary addons.
As someone who knows the difference, I find it my responsibility to translate in my head as necessary and not get bogged down in the weeds and only bring it up when it's significant.
With all that in mind, I see what Ars is saying, think the title is appropriate for the audience and that the content of the article is clear in what the restrictions cover.
I'm not into being pedantic just for the sake of pedantics and fail to see why people think bringing up the distinction meaningfully changes the article.
>>when they explicitly say AOSP, they make it sound like is a minor part, not enough to run an actual phone (which, for being any useful, requires google apps, is their thesis I guess)
It is 2014. Modern phones need to do more than just make phone calls.
Mobile app developers want to build with the best APIs available. Location, in-app advertising & search features are best when they use the api's associated with google's custom services.
The hair you're trying to split misses the point about modern mobile apps & modern smart phones. Google is clearly using API compatibility as a wedge against the OEMs.
Samsung's Taizen project wouldn't exist if this pressure was not a real problem. Google is behaving like mid-90's microsoft. This deeper link paints a bleak picture of what's going on:
Ben Edelman is literally paid by Microsoft (and admits as much), with his one goal being to target Google.
So i'm not wildly surprised that he would paint a bleak picture of what is going on - that's what they pay him to do!
Before this he used to paint a bleak picture of google advertising:
So, I'm all for context and appreciate this color.
I don't think Edelman's stooge status damages the argument.
If Samsung is a comfortable success in android, why in the world would they invest in Taizen? You don't build your business on someone else's property. I work with many people in mobile. These complaints about Google are not anecdotal.
The squeeze has been on for years. Google is ramping up the contractual requirements without investing in support infrastructure for the OEMs- only one of which is not dying. This is a real thing and not zeitgeist or blogger drama.
The real reason is that the promise of "open source" in Android has always been wildly overstated.
Over time, the OEMs have come to realize that Android is prone to vulnerabilities, they don't get the support for updated code that they do fully purchased OS's, and google is rapidly eliminating any opportunity for differentiation of experience. Google wants the OEMs to only focus on the plastic covers of the phones, which does not make a sustainable business model.
That forceful negotiation over time has resulted in Samsung's investment in Taizen and a legitimate opportunity for FirefoxOS & Ubuntu for Phones. All it's going to take is for someone to create a VM on windows phone and the other OS's for executing android sdks- google is going to be in real trouble with their OEMs. The OEMs won't drown without lashing out for survival.
I don't know if I'd call it every article yet, but it seems to be getting more common. What I think makes this a strange thing to harp on is that, while you can make the argument that Android is getting less open, it's still way more open than any of the other major mobile OSes.
Okay, Android isn't a perfect bastion of OSS, but what can you do with iOS without Apple's permission? IIRC, you can't even write apps in their own language and IDE on their hardware to use on your Apple devices without buying a membership to their developer program. Don't even try to put it on non-Apple hardware. It's at least possible for OEMs to install Windows Phone on their hardware, and I'm not sure what development is like there, but there sure isn't anything remotely free or open-source about it.
"There are some seemingly nonsensical parts to the agreement, especially the prohibition against distributing an SDK derived from the Android SDK. I'm having a difficult time imagining what harm that might cause."
If google does all the development work to build an SDK, and then, say, Amazon, comes along and reuses it for a completely separate incompatible ecosystem with essentially no changes, that kind of freeloading can cost Google a lot.
If that is the mentality, then why is android even open source to begin with, after all people can come and "freeload" off AOSP.
Google is attempting to gain the marketing benefits of being "open" while in actuality exerting the same kind of platform level control apple or Microsoft do.
You can't have both and really be open. Its the same kind of stupid games Sun played with Java for years.
Right... which makes the argument then pretty obvious: if freeloading is a serious concern, maybe Android should be released in a way that doesn't allow that (closed, GPL, whatever). You are just being needlessly pedantic if you insist the person you are responding to should have said "under a permissive license that leads to the freeloading problem".
Except his complaint was about openness. So exerting control through GPL would be open, but exerting control outside of GPL is not, even if you exert less control and over less people?
... the comment went so far as to ask why it was open source at all if there was such concern of a freeloading. The fact that it could remain open source and still avoid freeloading just strengthens that argument and undermines your attempt to defend Google's response to the freeloaders. You also brought up the GPL as the open source way to avoid freeloaders, so your new goal of pretending I'm the one claiming GPL would be "open" (especially when I directly compared it to "closed", not "open") seems to be nothing more than trying to hope I'm too stupid to notice.
Again: this is a very simple argument: you seem really angry about freeloaders, and yet you chose the license that allows them to exist: as the person you are responding to said, if you care this much, why did you make everything this open? You could have just made it closed source, or you could have used a more closed (yet user-benefiting!) license such as GPL. To be clear: I empathize with your pain (I made similar licensing mistakes a while ago, and ended up with tons of freeloaders), but I can't empathize with your continued complaints and name-calling as if this is something other people did to you :(.
As it stands, you have now built a scenario where the people who play along with you (comply with the CTS, get the Google apps, etc.) are handcuffed (making it not exactly "open" anymore for them anyway) and the people who don't (Amazon) are on your "shit list" (leading to any of new SDK-related terms, new closed critical components, temporary closures that aren't "owned up to" as "closed", and when all else fails: bitter tongue lashings on online forums with negative terms like "freeloader" bandied about)... you are trying to have your cake and eat it too, and that's really disingenuous and entirely low of Google.
Actually, Amazon does not use the Google Play services and app suite, so they can do anything they like, and they do, with the Android SDK which is also mostly Apache licensed.
In a sense they are freeloading. But Google long ago took the gamble that having a broad community, that might include competitors, using the Android OS and creating apps for the Android runtime environment is better than trying to do it all in-house and proprietary.
I'm getting very tired of this. What's happened to ars and why do they seem so anti-android these days? Where's the FUD against windows phone or IOS?
Here's some perspective: Every time Apple releases a new OSX version, ars does a 20 page spread covering every tiny detail. This is an OS that is developed using a model very similar to Android, yet, the reception is totally different. I don't get it. Does Ars now employ shills?
Anybody else a bit worried that this basically comes down to the good old "embrace extend extinguish" ? It's slightly different in that the "embrace" step was the purchase of Danger and open sourcing of the base AOSP - but the "extend" bit is pretty clearly in full effect here.
Google is very consistent in their treatment of AOSP. That's not to say it's a bed of roses. AOSP was and maybe still is under-resourced. It hasn't always had stable hardware targets. That's not a good way to treat a resource that is instrumental to creating a community of developers that know how to keep Android updated on a wide range of SoC platforms. Google makes no attempt to create an independent AOSP governance and pool of maintainer resources. I can go on. How much time do you have?
But the bottom line is AOSP has been remarkably free of shenanigans. Very unlike some other in-house but nominally open source projects I can think of.
That's not the point that GP is making. The point is that AOSP has been extended through google play services in the same way MS used to extend open protocols. It has used that to bring up a lot of people who associate android more closely with the google play services ecosystem than the AOSP ecosystem.
If google said "we're ditching AOSP but we're making a new closed source OS with google play services and a compatible API layer" then really would people move to AOSP or the new google OS?
The potential for "extinguish" is there. Had this all happened the other way around or had AOSP been around and MS had embraced it and extended it in this manner then I think people would be acting differently.
That new OS is Chrome OS. Notice that the Chrome OS device manufacturers don't get to rebrand it, modify it in any way, or control delivery of the updates. It is far more closed than Android ever was.
Google are applying their lessons from Android to Chrome OS.
That's a rather bizarre way of putting it. Another way of looking at it is that Chromium is completely open source and anyone who wants to build a Web-browser based netbook could do so, they just couldn't call it ChromeBook. Since all the apps are web apps, everything would continue to work as normal. There's no "if you don't agree to all of this, you can't use the GMail Web App or Google Maps on your device"
AFAIK, you can install apps and extensions without going through the Chrome store, and if you have the source, you can certainly hack it to use an alternate store host.
The thing you might not get access to is cloud based Chrome services like Chrome Sync. But since these are Javascript APIs, you can easily polyfill them to use your backend.
I don't think forking ChromeOS is as difficult as forking Android.
That's like arguing that iOS is open since you could all become developers and distribute the ObjC. Not all Chrome apps are web apps ( http://developer.chrome.com/apps/about_apps.html ) and you can't distribute those packages trivially to end users, so the whole distinction is almost identical to the iOS situation, by design. Google's Chrome group have a serious case of Apple envy, and this is how it manifests itself.
The whole point is forking Android is unnecessary - you can build all you want on top of the base platform without needing to make many lower level changes. To fork Chrome OS to add hooks for app delivery would be a far harder undertaking, whereas implementing an Android app to download an apk and run it is about 10 minutes of work.
fwiw, I don't think there is currently anything preventing you from accessing the Chrome Web Store from Chromium, without any kind of API key or proprietary extension. Of course that could theoretically change if someone started commercially distributing a forked Chromium OS, but we shouldn't blame Google for something it hasn't done.
Irrelevant, since your users would still need a Google account to use that store, and developers would still need to publish through it. The whole problem is duplicating that store.
The discussion originated in a claim that "anyone who wants to build a Web-browser based netbook could do so, they just couldn't call it ChromeBook". If the Web Store remains freely accessible, then they could do that without needing to duplicate it.
edit: i.e. the Web Store is playing the same role as any other website. You wouldn't criticize Chrome OS for the difficulty of making an alternative to Facebook for your fork.
For Chromium, developers do not need to publish apps through the Chrome Store, nor do you need a Google account to use such apps. Chrome has the same side-loading capability of Android allowing install from unknown sources. There are apps that Google refuses from the Web Store that are distributed this way.
I don't think you're going to get many people to believe that apps which target a platform that is mostly based on a spec controlled by a consortium, and for the most part, are cross-platform, are somehow more locked down and proprietary than a native apps platform. This is pretty much the first time I've seen anyone on HN try to argue that web apps, even chromium apps, are harder to port, and more of a walled garden than Android. It's a difficult to pull off argument, and I don't think it works.
Except Chrome increasingly doesn't implement the standard. For example, Adobe's recent CSS stuff isn't in, and instead an early version of the shadow DOM stuff which even Mozilla doesn't agree with is going in, on top of all the Chrome app API itself.
As I keep pointing out, you can literally implement something that presents the user a button and on pressing it downloads an apk, installs the package and runs the content in about 10 minutes. Can you do that with crx files in Chrome or Chromium without it triggering a nasty popup? Can your locally installed app then provide services to this other app we just downloaded without needing an intermediary server? If not, it's not as open as Android is.
This is really a red herring grasping for straws. All browsers have proprietary extensions and have differences from the spec. HTML5 for the most part works because people use what's portable. Html5test.com wouldn't need to exist if this weren't true.
The fact of the matter is, Web apps are more portable than Android apps, period. Take a random sample of the Chrome Web Store apps, how many of them do you think are tightly bound to be Chrome proprietary API only and won't run elsewhere? How many of them won't install or run on a forked Chromium?
Now go take a random sample of the Play store. And test those apps on say, a Chinese AOSP fork or Amazon's fork. How many of them will run without breaking? In no way can you compare GMS dependencies to a handful of Chrome-only APIs that barely any web developers use.
And when we talk about open-ness, we're talking about open source and how open the project is developed. Web standards have working groups to agree upon a spec. For the most part, the majority of new CSS or Javascript features are decided on at the W3C and TC39. That is a far cry different than the way say, future versions of Android are developed in secret. I understand some of the restrictions on why Android is developed like that but to compare it to the web or iOS is a false equivalence.
The fact that Web apps can't do the kinds of things you're talking about with respect to inter-app services has nothing to do with openness and more to do with the sandbox that the web puts apps into.
That said, locally installed apps can provide services to other apps through multiple techniques:
* Background pages (invisible HTML pages running in the background)
* Shared Web Workers (spawned process that lives at a known address)
* Custom Protocol Handler
* Service Workers (intercept HTTP requests for resources)
* Chrome Extension content page
* WebRTC or local web server
* Web Intents/Web Activities (got shelved by Google and Mozilla)
From your perspective, you're talking about what's presented to the developer. But this discussion is about Independent Hardware Vendors. What does it take for someone to build their own usable ChromeOS device vs build a modern smartphone starting with only open source. For ChromeOS, you get very very far with the existing open source and most apps will run unchanged. For Android, if you start only from AOSP, any apps dependent on the Google cloud will be broke, and the question is, how easy is it to shim those services out and replace them, and it is far more work.
This is not a bash on AOSP or Android. It's just a retort to the ridiculous idea that somehow web apps on ChromeOS are more locked in than Android.
It's not clutching at straws at all - they very clearly are diverging from the spec everyone else is using, moving to not prefixing, and shipping as on by default. This might as well be in secret, since the Chrome group are developing the habit of dictating specs by pushing implementations out regardless of the community, and thus is no better than the OHA, who at least talk amongst themselves. There are also proprietary Android libraries that exist for different manufacturers, but you're probably insane if you rely on them.
I used to work doing games on Android across all varieties of it, and the differences are nothing like as big as people that haven't looked properly seem to think. In fact for many titles without push or in app billing it was simply a question of testing, and these things ran perfectly, or no worse than any other issue you might have with a device on the Play Store. It is most definitely less than the difference between different web browsers, and far better defined. Do this a few times and it can be abstracted away (to the point of portability to iOS abstracted).
Let's say I'm an OEM without an existing contract with Google. I could either build a Chromium device or an Android one, and shove some other app store on it. Unsurprisingly many are doing the latter, and they're in the wild, but has anyone seen a Chromium device actually out there? Given how many Chromebooks are selling you'd think maybe one enterprising Chinese OEM would do it, but they seem far keener on Android. I wonder why.
You are greatly overestimating how hard it is to implement services on the device. The only hard part of implementing a store and in app billing, for example, is the server. The clients practically write themselves by comparison. Given that the entire Chinese Android market exists without Google's cloud services it's clearly nothing like as big a deal as you and Google wish it were.
Apples to Oranges. You're asking why there aren't as many ChromeBook vendors as there are Android vendors? Maybe it has something to do with the fact that consumers are buying less traditional computers and buying more phones and tablets.
No one is wishing anything is a big deal. I am not attacking Android or the bogus Ars Technica articles which keep pushing the line that AOSP isn't open. I'm criticizing this weird claim that ChromeOS is more of a walled garden, which it most decidedly is not.
Chromium is "more" open source than Android because it is developed continuously in the open, there's no "code bomb" that publishes the entire Next version once a year. Secondly, the surface area of Chrome-specific APIs or services are tiny and insignificant compared to native devices. Those two features limit platform lockin and increase portability.
The Chrome Web Store/Chrome Apps are simply a red herring. The vast vast majority of ChromeOS "apps" are links to hosted sites, the majority of which work on any browser. That's been the major problem getting people to pay for stuff in the CWS as you can cut/paste the URL and avoid the store entirely for many apps.
Leaving aside Chromium, many people have taken WebKit and made desktops based on it. WebOS, the new SteamBox uses a frontend built with WebKit, the PlayStation UI has various parts built with a browser. There was also Jolicloud.
It is not hard to take a Linux distribution and slap a browser on it as the desktop launcher. Sorry, it's just not. Whether people are interested in doing that and think it is something they could sell for a profit is a different story that has nothing to do with the technical difficulty of doing it.
As I pointed out, Blink devs are now code-bombing. Yes they tell you about it in advance, but you're damned if you want any input on what's in it if you don't agree with them. I fail to see how this is any better.
> And test those apps on say, a Chinese AOSP fork or Amazon's fork. How many of them will run without breaking?
API compatibility in Android is excellent. This is because you don't need to touch the bits that make the runtime. It's the same runtime, and the exact same bits that apps touch, in Mountain View as in the Two Chinese Guys Making Handsets factory. Most developers of widely used apps test on Kindle devices, at least, if not other Android-derived OSs.
Web apps face multiple implementations of a standard. That's going to be less the same.
Both of you are missing the point. The context of this thread is Google Play Services, and any apps dependent on them, won't be available on the Chinese AOSP fork.
Also, compiling without breaking, and running without breaking for two different things. If the binary compatibility alone was the main problem, there'd be no issues with Android fragmentation and testing.
If you go to Google Play, pick "Top Apps" and read the reviews of any top apps, you'll see plenty of "It's not working", "won't launch", "freezes my phone" type comments.
You're spouting nonsense that you've heard and not reality. The errors people run into are largely just bugs in the apps not being written to deal with the different cases that exist, because developers are lazy and tend to write just for whatever device they have in front of them. Cases with RAM usage, storage assumptions, and so on. That and GL driver issues used to be a headache (less so these days), but Chrome OS is hardly going to help there. Since Android 4.0.3 the stability of the framework itself has been exemplary with very few exceptions.
You happen to be missing our rather epic point that apps which are 100% dependent on GPS and cannot be moved from them are in practice rather thin on the ground.
Almost identical to iOS? Absolutely ridiculous analogy. ChromeOS doesn't compare to iOS at all and Chrome is far more open than Android in terms of development (All new Chromium development is done in the open and new releases happen nightly and every 6 weeks. Do you know what Android 4.5 will have in it yet?)
1. The majority of iOS apps can't be side loaded, are locked to the App Store. Vast majority of ChromeOS apps are not "Chrome Apps", it's a red herring. Plus, Chrome Apps can still be side loaded and are not locked to the Web Store. None of Google's major apps: GMail, Maps, Docs, YouTube, etc are actually "Chrome Apps" in this regard. Then will run on any ChromeOS fork. Chromium today supports side loading any app from the Extensions page without going through the Chrome Store.
Simply put, it is not possible to create the kinds of Google-service lock-in agreements for ChromeOS that have been created for Android, because ChromeOS is just a web browser.
2. ChromeOS doesn't need to add hooks for app delivery contrary to your claims. The Chrome equivalent of an APK is a CRX file and CRX files can be self hosted, see "Hosted Apps". In fact, they used to auto-install if you just clicked a link pointing at one, but phishers/hackers took advantage of this, so now you have to go through the Extensions page.
Any Web app you build for Chromium will work on any subsequent ChromeOS fork without needing to make any lower level changes, because Web apps don't have huge dependencies on local OS services. Many ChromeOS apps will even work on Firefox because again, the vast majority of Chrome apps don't really depend on local OS privileges like getting access to the USB port.
Implementing a different app distribution mechanism is trivial.
In practice, Android apps are far more likely to depend on non-AOSP services (like Google Play Services) than Web Apps are to depend on Chrome Web Store required services (of which there is only a tiny few, like push messaging). That's just the facts, so the practical reality is, forking AOSP creates more incompatibility than forking Chromium.
Nope, look at the docs - you need developer stuff enabled to side load. The rest is being removed "for user safety". This makes it just like iOS, where if I'm a developer I can likewise sideload anything I have the source to.
Chrome OS is _not_ just a web browser, as that link to the Chrome Apps stuff very clearly demonstrates. It's not "pure web" at all. This is PR nonsense, when there's a whole extra API.
Clearly you don't like it being pointed out, but Chrome OS is Google's walled garden.
How about actually owning a ChromeOS device before making comments? "Developer Stuff Enabled" = "Menu -> Extensions -> Developer Mode Checkbox". It's not different than going to Android settings and saying "allow apps from unknown sources."
Besides, the whole argument is how easy it would be to fork Android vs Chrome, and the reality is, turning off install restrictions in Chrome in a few lines of code. Replacing Google Play Services/GMS are far far harder.
I'm still convinced that Chrome OS is mostly a ploy to get device manufacturers to sell devices that can run Linux unmodified without paying a Windows OEM tax.
That can only be partly fixed. AOSP could be improved by creating a parallel out-of-house project. But, maybe, CyanogenMod and other downstream distros serve that purpose. I'm not up to the minute about what kind of job Google is doing accepting fixes and improvements from downstream, but I'd guess that could stand to improve.
I don't see a fix for parts of the open Android app layer migrating into dependence on the Google ecosystem, apart from allowing downstream distros to maintain and/or replace the open versions. If Google wants to integrate Photos with G+ what are they going to do about that that would be consistent with their "All of our ecosystem or none of it" approach to licensing?
I think the only two real sticking points are what was mentioned about this agreement having to be a company wide deal, and also that stuff against forking the SDK giving Google far too big a veto over proceedings. Ideally to fix this the OHA should become independent of Google, but that would rely on the other members being remotely competent.
It's like Ars is on a mission to discredit Google here.
I've actually been waiting for Google to take a harder stance on OEMs and force them to provide better support to their users for a long time. It will also make things a lot easier for developers in the future, as this will have the effect of reducing fragmentation, and not having to use APIs that are 5 years old.
With Android, for some, it's damned if Google does and damned if they don't! Kind of amusing to watch lately - bloggers, writers, whoever - going out and writing inflammatory stuff that is bound to get page views and comments.
Hangouts - people were pissed that there wasn't a integrated, one stop messaging solution on Android in 2013. Google tries to do something like that - integrating Google Talk and SMS and now suddenly it's a move to take all your bases.
There was lot of cry about the F word. Google does the only thing they could - put reasonable amount of control while keeping their business interests in mind - to reduce fragmentation and offer a more uniform experience. Now people are crying too much control. If on the other hand they would have said here's Android, and here are freely downloadable GApps that you can freely use to avail Google services, you can do whatever you want with them - I am sure there would be an article somewhere claiming the F word, "dumping", lack of uniform experience and few other things vaguely implying malaise.
You also notice that this drivel is coming mostly from two sources - sites benefiting from page views and user interaction via comments and people who kind of feel threatened by Android's success - techies on the other mobile platform for example.
Problem is none of these articles provide any practical solutions for Google to implement - I guess doing that would be too inconvenient for a future article they might need to write claiming what Google was doing then was bad! If one of these articles articulated the path Google should take to keep Android successful, have no fragmentation, have singular, uniform experience without violating any of their future whiney articles ( [2015]How Google screwed up - Android went from 78.1% market share to 1.5% by following what we said in 2014) - it would be worthwhile paying attention.
But of course that is impossible to do - you can only have your cake OR you can eat it! Why solve that when you can just keep writing nonsense drivel and 'engage' you audience.
>Problem is none of these articles provide any practical solutions for Google to implement
Practically speaking, it would be pretty easy for Google to make many of its already standalone updated apps fully standalone. Anyone could distribute the Gmail package, Google just won't let them.
It's very useful that Google Play is integrated in a way that reduces the friction of payments and protects the users and developers from various kinds of fraud. I don't know how to allow multiple stores to be installed where a high-stakes third party developer doesn't get ruined by fraud when they reach a sufficient scale.
> Practically speaking, it would be pretty easy for Google to make many of its already standalone updated apps fully standalone. Anyone could distribute the Gmail package, Google just won't let them.
CM and ton of other ROMs are distributing GApps as standalone Zip - Google isn't doing anything to stop them. Tomorrow if Huawei does that - it would be a different story. Then Huawei can ship with 2.3 and outdated/incomplete Gapps (no browser, just gmail, no Google location APIs, instead incompatible APIs, and do a bunch of other things that could be bad for everyone else - which brings me to the point I made - that will result in people then complaining - In China you don't get uniform Google experience - Huawei phones ship with HuaweiKit instead of Blink, HuaweiBrowser instead of Chrome - so site owners can't even create a web app that works on all "Android" devices etc.
you are operating under the assumption that Gapps stuff must be closed source, OEMs could still easily be bound by these agreements, and the stuff be open source.
> you are operating under the assumption that Gapps stuff must be closed source, OEMs could still easily be bound by these agreements, and the stuff be open source.
In other words you don't know what you are talking about. (Hint: Try working through all the consequences of it.)
So then a competitor can get the Open Source GDrive app, modify it in whatever way they want and prevent Google from making any server side improvements because the OEM's version will become incompatible? Or worst case, the OEM might build their own compatible cloud with their own OEMDrive server that implements their own APIs and fully cuts out Google?
Remember Google isn't a charity - they are a business and they have to protect their business interests. Once you start under the incomplete premise of Google with their Open stuff and without their business interests - that's when you start demanding 100% open. IMHO they are as of today doing a fair job balancing both their interests and AOSP's openness. Conflate AOSP and GApps and that's when you get into silly land.
The overarching problem here for Google is that they set an expectation of openness from the outset which in reality was probably an unreasonably high expectation. As Google realized they need more control to provide a better user experience over time they have had to make moves that fall short of those expectations.
Apple doesn't get this sort of flack because from the very beginning expectations were set that they would exert full control over iOS. So if they make a dick move no one is surprised.
There is something to be said about how setting reasonable and even lower expectations is always a good route in all sorts of aspects of business. It leaves you options, room to improve, and it changes to those expectations are less jarring to fans and customers.
This has been part of the PR strategy against Android from the beginning. Remember when not releasing Honeycomb meant that Google was taking Android closed source? Or the list of AOSP apps that Ars claimed were abandoned but then got major updates in KitKat?
So by the standard of the mud being thrown at them Google are actually exceeding expectations for openness. And it's just odd to see Apple and Microsoft boosters take positions that are more extreme than RMS just to minimize this advantage.
From a game theoretic point of view the OEMs are probably grateful for most of the restrictions because they apply to their competitors too.
It's the same reason that GPL often make sense for shared projects, the restrictions on "freedom" prevent defection and so enable cooperation.
The OEMs rejected the GPL, but they probably want some kind of protection from say Samsung freezing them out of the market, or just as bad, everyone trying but failing and ending up like Unix.
As such, the software which makes up "Android" resembles OS X to me: open source in parts (even large parts), but the bit which most people (including developers) use is closed source and restricted to running only on sanctioned hardware.
80 comments
[ 3.6 ms ] story [ 143 ms ] threadThe restrictions stem from a choice you have to make: If you use the Google ecosystem in your products, you have to use all of it, and you can't use parts of Android to compete with the Google ecosystem. You can make the other choice, but, in those cases, Google doesn't want you to have their closed, proprietary apps. That might be hard-nosed dealing, but it isn't more restrictive than Google's competitors are in similar circumstances.
There are some seemingly nonsensical parts to the agreement, especially the prohibition against distributing an SDK derived from the Android SDK. I'm having a difficult time imagining what harm that might cause. Some OEMs, like Samsung, are shipping SDK extensions that Google apparently is fine with.
The openness of AOSP is not compromised by this contract. Amazon is an example of a partly direct competitor using AOSP. Google has done nothing to thwart Amazon, not even a hint of FUD. If only Oracle were that straightforward about Java.
as somebody who has had to deal with vendor proprietary SDKs for devices, I can assure you that only having to deal with one stock Android SDK that has not been tempered with by hardware-engineers under time pressure doing software is a very, very good thing.
This way the really ugly crap is contained within vendor specific SDK extensions (which can be abstracted away) instead of the crap being sprinkled all over the basic OS SDK which would require one SDK per device you're targeting and would inflict all sorts of bugs on you even when not touching vendor-specific parts.
In general, most of the terms mentioned in the article are, while being horrendous for the device maker, are very nice for both users and developers targeting these devices.
Yes, it's nowhere near "open", but also, yes, this ensures some level of quality for both users and developers.
Sounds like the exact argument for iOS.
There are other places where one can complain that Google has effectively abandoned open source components of AOSP. These are places where Google has made previously standalone apps part of their ecosystem.
On the other hand, alternative distributions like CyanogenMod have become sustainable VC-fundable businesses based on the relative reliability that important new core OS features do go into AOSP on a timely basis. ART, for example. It's there to read and study and try long before any Google-label OEM benefits from it.
1) Location API changes - Moving these into GMS is a bad decision, and I think hurts the core platform 2) Hangouts - Moving messaging into a non-standards compliant and closed source solution hurts everyone (except Google, at least in the short-term)
These to me indicate a move towards a more closed model within Google generally, and I think that is terribly unfortunate.
iMessage uses TCP, but that doesn't make it an open source application with an open protocol.
Whether XMPP or WebRTC are open, and open source, is different from whether services that run on them are open to federation.
But what the post I responded to claimed was about the tech, and the tech will be just as standardized and just as open source.
i'd like to see ONE full time user of AOSP without GMS. I bet you got GMS, or non-android phone, or else its not your main phone.
and that's the fucking point.
I have GMS on my Nexus phone, but I also have the F-Droid repository, the Humble Bundle store (and briefly had the Amazon App store too).
I also have Chrome installed on my Ubuntu desktop (though I mostly use Firefox, and have Chromium too). And Steam.
What was the fucking point again?
Your arguing is senseless.
That's ludicrous, and the rest of your post isn't much better, but its a good example of the worldview that Ars is currently pushing.
Yes but that choice is not made on a per-product basis but on a global company wide basis. I could easily see this as being viewed as anti-competitive conduct (as I also saw MS deals penalising OEMs who shipped any products without Windows).
> The openness of AOSP is not compromised by this contract.
I disagree with that conclusion. As I read the article any company that accepts the agreement promises not to fork Android. Amazon does not sign this agreement and therefore can still use AOSP freely and openly but a large bulk of the world's consumer electronic companies cannot. This doesn't make AOSP closed but it does compromise its openness.
The inability to separate AOSP from Google's services irritates me. Google is leaving the door open for anyone to compete with them; use AOSP -a fully functional OS- and provide a better service than Google products offer, you won't owe Google a dime, and you'll be a serious competitor.
As far as I know, there's nothing stopping an independent OEM from releasing unlocked devices. An end user is free to install gapps on his own, and it's laughably easy to do.
The OEMs aren't the (only?) victims of the anticompetitive behaviour. It reduces the market for services competing with the Google services (as they can't sell to anyone who is also a Google customer) and it affects their customers (end users and telcos) and the choices available to them.
By "independent OEM" do you mean one who doesn't sign the contract?
I don't know their rationale for that but I'm starting getting sick of it. Every. Damn. Article. They insinuate, more or less clearly, that you should be very careful with android, it's not open! The best thing being: they are always talking about Google play services instead of android. Even when they explicitly say AOSP, they make it sound like is a minor part, not enough to run an actual phone (which, for being any useful, requires google apps, is their thesis I guess)
Basically it comes down to if you're being pedant or a layperson.
A pedant is very careful to consider "Android" the AOSP and noting else.
To almost anyone that hasn't tried to install non-stock firmware on a device "Android" includes the proprietary addons.
As someone who knows the difference, I find it my responsibility to translate in my head as necessary and not get bogged down in the weeds and only bring it up when it's significant.
With all that in mind, I see what Ars is saying, think the title is appropriate for the audience and that the content of the article is clear in what the restrictions cover.
I'm not into being pedantic just for the sake of pedantics and fail to see why people think bringing up the distinction meaningfully changes the article.
It is 2014. Modern phones need to do more than just make phone calls.
Mobile app developers want to build with the best APIs available. Location, in-app advertising & search features are best when they use the api's associated with google's custom services.
The hair you're trying to split misses the point about modern mobile apps & modern smart phones. Google is clearly using API compatibility as a wedge against the OEMs.
Samsung's Taizen project wouldn't exist if this pressure was not a real problem. Google is behaving like mid-90's microsoft. This deeper link paints a bleak picture of what's going on:
http://www.benedelman.org/news/021314-1.html
Before this he used to paint a bleak picture of google advertising:
http://techrights.org/2011/08/30/ben-edelman-works-for-monop...
I don't think Edelman's stooge status damages the argument.
If Samsung is a comfortable success in android, why in the world would they invest in Taizen? You don't build your business on someone else's property. I work with many people in mobile. These complaints about Google are not anecdotal.
The squeeze has been on for years. Google is ramping up the contractual requirements without investing in support infrastructure for the OEMs- only one of which is not dying. This is a real thing and not zeitgeist or blogger drama.
In samsung's ideal world, they are Apple. That's why. Plus, you always need a plan b.
The real reason is that the promise of "open source" in Android has always been wildly overstated.
Over time, the OEMs have come to realize that Android is prone to vulnerabilities, they don't get the support for updated code that they do fully purchased OS's, and google is rapidly eliminating any opportunity for differentiation of experience. Google wants the OEMs to only focus on the plastic covers of the phones, which does not make a sustainable business model.
That forceful negotiation over time has resulted in Samsung's investment in Taizen and a legitimate opportunity for FirefoxOS & Ubuntu for Phones. All it's going to take is for someone to create a VM on windows phone and the other OS's for executing android sdks- google is going to be in real trouble with their OEMs. The OEMs won't drown without lashing out for survival.
Okay, Android isn't a perfect bastion of OSS, but what can you do with iOS without Apple's permission? IIRC, you can't even write apps in their own language and IDE on their hardware to use on your Apple devices without buying a membership to their developer program. Don't even try to put it on non-Apple hardware. It's at least possible for OEMs to install Windows Phone on their hardware, and I'm not sure what development is like there, but there sure isn't anything remotely free or open-source about it.
If google does all the development work to build an SDK, and then, say, Amazon, comes along and reuses it for a completely separate incompatible ecosystem with essentially no changes, that kind of freeloading can cost Google a lot.
Google is attempting to gain the marketing benefits of being "open" while in actuality exerting the same kind of platform level control apple or Microsoft do.
You can't have both and really be open. Its the same kind of stupid games Sun played with Java for years.
I'm not sure I follow. Freeloading is a huge problem, even in the open source community. This is for example, one of the reasons the GPL exists.
Again: this is a very simple argument: you seem really angry about freeloaders, and yet you chose the license that allows them to exist: as the person you are responding to said, if you care this much, why did you make everything this open? You could have just made it closed source, or you could have used a more closed (yet user-benefiting!) license such as GPL. To be clear: I empathize with your pain (I made similar licensing mistakes a while ago, and ended up with tons of freeloaders), but I can't empathize with your continued complaints and name-calling as if this is something other people did to you :(.
As it stands, you have now built a scenario where the people who play along with you (comply with the CTS, get the Google apps, etc.) are handcuffed (making it not exactly "open" anymore for them anyway) and the people who don't (Amazon) are on your "shit list" (leading to any of new SDK-related terms, new closed critical components, temporary closures that aren't "owned up to" as "closed", and when all else fails: bitter tongue lashings on online forums with negative terms like "freeloader" bandied about)... you are trying to have your cake and eat it too, and that's really disingenuous and entirely low of Google.
In a sense they are freeloading. But Google long ago took the gamble that having a broad community, that might include competitors, using the Android OS and creating apps for the Android runtime environment is better than trying to do it all in-house and proprietary.
Here's some perspective: Every time Apple releases a new OSX version, ars does a 20 page spread covering every tiny detail. This is an OS that is developed using a model very similar to Android, yet, the reception is totally different. I don't get it. Does Ars now employ shills?
They swallow whatever any PR person is feeding them.
Google is very consistent in their treatment of AOSP. That's not to say it's a bed of roses. AOSP was and maybe still is under-resourced. It hasn't always had stable hardware targets. That's not a good way to treat a resource that is instrumental to creating a community of developers that know how to keep Android updated on a wide range of SoC platforms. Google makes no attempt to create an independent AOSP governance and pool of maintainer resources. I can go on. How much time do you have?
But the bottom line is AOSP has been remarkably free of shenanigans. Very unlike some other in-house but nominally open source projects I can think of.
If google said "we're ditching AOSP but we're making a new closed source OS with google play services and a compatible API layer" then really would people move to AOSP or the new google OS?
The potential for "extinguish" is there. Had this all happened the other way around or had AOSP been around and MS had embraced it and extended it in this manner then I think people would be acting differently.
Google are applying their lessons from Android to Chrome OS.
Chrome OS is closer in spirit to iOS than it is to Android.
The thing you might not get access to is cloud based Chrome services like Chrome Sync. But since these are Javascript APIs, you can easily polyfill them to use your backend.
I don't think forking ChromeOS is as difficult as forking Android.
The whole point is forking Android is unnecessary - you can build all you want on top of the base platform without needing to make many lower level changes. To fork Chrome OS to add hooks for app delivery would be a far harder undertaking, whereas implementing an Android app to download an apk and run it is about 10 minutes of work.
edit: i.e. the Web Store is playing the same role as any other website. You wouldn't criticize Chrome OS for the difficulty of making an alternative to Facebook for your fork.
I don't think you're going to get many people to believe that apps which target a platform that is mostly based on a spec controlled by a consortium, and for the most part, are cross-platform, are somehow more locked down and proprietary than a native apps platform. This is pretty much the first time I've seen anyone on HN try to argue that web apps, even chromium apps, are harder to port, and more of a walled garden than Android. It's a difficult to pull off argument, and I don't think it works.
As I keep pointing out, you can literally implement something that presents the user a button and on pressing it downloads an apk, installs the package and runs the content in about 10 minutes. Can you do that with crx files in Chrome or Chromium without it triggering a nasty popup? Can your locally installed app then provide services to this other app we just downloaded without needing an intermediary server? If not, it's not as open as Android is.
The fact of the matter is, Web apps are more portable than Android apps, period. Take a random sample of the Chrome Web Store apps, how many of them do you think are tightly bound to be Chrome proprietary API only and won't run elsewhere? How many of them won't install or run on a forked Chromium?
Now go take a random sample of the Play store. And test those apps on say, a Chinese AOSP fork or Amazon's fork. How many of them will run without breaking? In no way can you compare GMS dependencies to a handful of Chrome-only APIs that barely any web developers use.
And when we talk about open-ness, we're talking about open source and how open the project is developed. Web standards have working groups to agree upon a spec. For the most part, the majority of new CSS or Javascript features are decided on at the W3C and TC39. That is a far cry different than the way say, future versions of Android are developed in secret. I understand some of the restrictions on why Android is developed like that but to compare it to the web or iOS is a false equivalence.
The fact that Web apps can't do the kinds of things you're talking about with respect to inter-app services has nothing to do with openness and more to do with the sandbox that the web puts apps into.
That said, locally installed apps can provide services to other apps through multiple techniques:
* Background pages (invisible HTML pages running in the background)
* Shared Web Workers (spawned process that lives at a known address)
* Custom Protocol Handler
* Service Workers (intercept HTTP requests for resources)
* Chrome Extension content page
* WebRTC or local web server
* Web Intents/Web Activities (got shelved by Google and Mozilla)
From your perspective, you're talking about what's presented to the developer. But this discussion is about Independent Hardware Vendors. What does it take for someone to build their own usable ChromeOS device vs build a modern smartphone starting with only open source. For ChromeOS, you get very very far with the existing open source and most apps will run unchanged. For Android, if you start only from AOSP, any apps dependent on the Google cloud will be broke, and the question is, how easy is it to shim those services out and replace them, and it is far more work.
This is not a bash on AOSP or Android. It's just a retort to the ridiculous idea that somehow web apps on ChromeOS are more locked in than Android.
I used to work doing games on Android across all varieties of it, and the differences are nothing like as big as people that haven't looked properly seem to think. In fact for many titles without push or in app billing it was simply a question of testing, and these things ran perfectly, or no worse than any other issue you might have with a device on the Play Store. It is most definitely less than the difference between different web browsers, and far better defined. Do this a few times and it can be abstracted away (to the point of portability to iOS abstracted).
Let's say I'm an OEM without an existing contract with Google. I could either build a Chromium device or an Android one, and shove some other app store on it. Unsurprisingly many are doing the latter, and they're in the wild, but has anyone seen a Chromium device actually out there? Given how many Chromebooks are selling you'd think maybe one enterprising Chinese OEM would do it, but they seem far keener on Android. I wonder why.
You are greatly overestimating how hard it is to implement services on the device. The only hard part of implementing a store and in app billing, for example, is the server. The clients practically write themselves by comparison. Given that the entire Chinese Android market exists without Google's cloud services it's clearly nothing like as big a deal as you and Google wish it were.
No one is wishing anything is a big deal. I am not attacking Android or the bogus Ars Technica articles which keep pushing the line that AOSP isn't open. I'm criticizing this weird claim that ChromeOS is more of a walled garden, which it most decidedly is not.
Chromium is "more" open source than Android because it is developed continuously in the open, there's no "code bomb" that publishes the entire Next version once a year. Secondly, the surface area of Chrome-specific APIs or services are tiny and insignificant compared to native devices. Those two features limit platform lockin and increase portability.
The Chrome Web Store/Chrome Apps are simply a red herring. The vast vast majority of ChromeOS "apps" are links to hosted sites, the majority of which work on any browser. That's been the major problem getting people to pay for stuff in the CWS as you can cut/paste the URL and avoid the store entirely for many apps.
Leaving aside Chromium, many people have taken WebKit and made desktops based on it. WebOS, the new SteamBox uses a frontend built with WebKit, the PlayStation UI has various parts built with a browser. There was also Jolicloud.
It is not hard to take a Linux distribution and slap a browser on it as the desktop launcher. Sorry, it's just not. Whether people are interested in doing that and think it is something they could sell for a profit is a different story that has nothing to do with the technical difficulty of doing it.
API compatibility in Android is excellent. This is because you don't need to touch the bits that make the runtime. It's the same runtime, and the exact same bits that apps touch, in Mountain View as in the Two Chinese Guys Making Handsets factory. Most developers of widely used apps test on Kindle devices, at least, if not other Android-derived OSs.
Web apps face multiple implementations of a standard. That's going to be less the same.
Also, compiling without breaking, and running without breaking for two different things. If the binary compatibility alone was the main problem, there'd be no issues with Android fragmentation and testing.
If you go to Google Play, pick "Top Apps" and read the reviews of any top apps, you'll see plenty of "It's not working", "won't launch", "freezes my phone" type comments.
You happen to be missing our rather epic point that apps which are 100% dependent on GPS and cannot be moved from them are in practice rather thin on the ground.
1. The majority of iOS apps can't be side loaded, are locked to the App Store. Vast majority of ChromeOS apps are not "Chrome Apps", it's a red herring. Plus, Chrome Apps can still be side loaded and are not locked to the Web Store. None of Google's major apps: GMail, Maps, Docs, YouTube, etc are actually "Chrome Apps" in this regard. Then will run on any ChromeOS fork. Chromium today supports side loading any app from the Extensions page without going through the Chrome Store.
Simply put, it is not possible to create the kinds of Google-service lock-in agreements for ChromeOS that have been created for Android, because ChromeOS is just a web browser.
2. ChromeOS doesn't need to add hooks for app delivery contrary to your claims. The Chrome equivalent of an APK is a CRX file and CRX files can be self hosted, see "Hosted Apps". In fact, they used to auto-install if you just clicked a link pointing at one, but phishers/hackers took advantage of this, so now you have to go through the Extensions page.
Any Web app you build for Chromium will work on any subsequent ChromeOS fork without needing to make any lower level changes, because Web apps don't have huge dependencies on local OS services. Many ChromeOS apps will even work on Firefox because again, the vast majority of Chrome apps don't really depend on local OS privileges like getting access to the USB port.
Implementing a different app distribution mechanism is trivial.
In practice, Android apps are far more likely to depend on non-AOSP services (like Google Play Services) than Web Apps are to depend on Chrome Web Store required services (of which there is only a tiny few, like push messaging). That's just the facts, so the practical reality is, forking AOSP creates more incompatibility than forking Chromium.
Chrome OS is _not_ just a web browser, as that link to the Chrome Apps stuff very clearly demonstrates. It's not "pure web" at all. This is PR nonsense, when there's a whole extra API.
Clearly you don't like it being pointed out, but Chrome OS is Google's walled garden.
Besides, the whole argument is how easy it would be to fork Android vs Chrome, and the reality is, turning off install restrictions in Chrome in a few lines of code. Replacing Google Play Services/GMS are far far harder.
I'd suggest you try writing some Android services, and you'll find you don't have to modify the OS at all.
I don't see a fix for parts of the open Android app layer migrating into dependence on the Google ecosystem, apart from allowing downstream distros to maintain and/or replace the open versions. If Google wants to integrate Photos with G+ what are they going to do about that that would be consistent with their "All of our ecosystem or none of it" approach to licensing?
I think the only two real sticking points are what was mentioned about this agreement having to be a company wide deal, and also that stuff against forking the SDK giving Google far too big a veto over proceedings. Ideally to fix this the OHA should become independent of Google, but that would rely on the other members being remotely competent.
I've actually been waiting for Google to take a harder stance on OEMs and force them to provide better support to their users for a long time. It will also make things a lot easier for developers in the future, as this will have the effect of reducing fragmentation, and not having to use APIs that are 5 years old.
Hangouts - people were pissed that there wasn't a integrated, one stop messaging solution on Android in 2013. Google tries to do something like that - integrating Google Talk and SMS and now suddenly it's a move to take all your bases.
There was lot of cry about the F word. Google does the only thing they could - put reasonable amount of control while keeping their business interests in mind - to reduce fragmentation and offer a more uniform experience. Now people are crying too much control. If on the other hand they would have said here's Android, and here are freely downloadable GApps that you can freely use to avail Google services, you can do whatever you want with them - I am sure there would be an article somewhere claiming the F word, "dumping", lack of uniform experience and few other things vaguely implying malaise.
You also notice that this drivel is coming mostly from two sources - sites benefiting from page views and user interaction via comments and people who kind of feel threatened by Android's success - techies on the other mobile platform for example.
Problem is none of these articles provide any practical solutions for Google to implement - I guess doing that would be too inconvenient for a future article they might need to write claiming what Google was doing then was bad! If one of these articles articulated the path Google should take to keep Android successful, have no fragmentation, have singular, uniform experience without violating any of their future whiney articles ( [2015]How Google screwed up - Android went from 78.1% market share to 1.5% by following what we said in 2014) - it would be worthwhile paying attention.
But of course that is impossible to do - you can only have your cake OR you can eat it! Why solve that when you can just keep writing nonsense drivel and 'engage' you audience.
Practically speaking, it would be pretty easy for Google to make many of its already standalone updated apps fully standalone. Anyone could distribute the Gmail package, Google just won't let them.
It's very useful that Google Play is integrated in a way that reduces the friction of payments and protects the users and developers from various kinds of fraud. I don't know how to allow multiple stores to be installed where a high-stakes third party developer doesn't get ruined by fraud when they reach a sufficient scale.
CM and ton of other ROMs are distributing GApps as standalone Zip - Google isn't doing anything to stop them. Tomorrow if Huawei does that - it would be a different story. Then Huawei can ship with 2.3 and outdated/incomplete Gapps (no browser, just gmail, no Google location APIs, instead incompatible APIs, and do a bunch of other things that could be bad for everyone else - which brings me to the point I made - that will result in people then complaining - In China you don't get uniform Google experience - Huawei phones ship with HuaweiKit instead of Blink, HuaweiBrowser instead of Chrome - so site owners can't even create a web app that works on all "Android" devices etc.
stop the appologetics.
In other words you don't know what you are talking about. (Hint: Try working through all the consequences of it.)
Remember Google isn't a charity - they are a business and they have to protect their business interests. Once you start under the incomplete premise of Google with their Open stuff and without their business interests - that's when you start demanding 100% open. IMHO they are as of today doing a fair job balancing both their interests and AOSP's openness. Conflate AOSP and GApps and that's when you get into silly land.
Apple doesn't get this sort of flack because from the very beginning expectations were set that they would exert full control over iOS. So if they make a dick move no one is surprised.
There is something to be said about how setting reasonable and even lower expectations is always a good route in all sorts of aspects of business. It leaves you options, room to improve, and it changes to those expectations are less jarring to fans and customers.
So by the standard of the mud being thrown at them Google are actually exceeding expectations for openness. And it's just odd to see Apple and Microsoft boosters take positions that are more extreme than RMS just to minimize this advantage.
It's the same reason that GPL often make sense for shared projects, the restrictions on "freedom" prevent defection and so enable cooperation.
The OEMs rejected the GPL, but they probably want some kind of protection from say Samsung freezing them out of the market, or just as bad, everyone trying but failing and ending up like Unix.