Google is defragging Android(arstechnica.com)
arstechnica.com
Google is defragging Android
http://arstechnica.com/gadgets/2013/09/balky-carriers-and-slow-oems-step-aside-google-is-defragging-android/
220 comments
Notably, Play services is totally closed. So Google has abandoned the open source part of Android and is now developing the operating system as a completely closed product.
Edit: downvotes don't change the truth of the observation. Android is no longer meaningfully open, other than a years old core of basic functions. Just like OSX and Darwin.
Edit: downvotes don't change the truth of the observation. Android is no longer meaningfully open, other than a years old core of basic functions. Just like OSX and Darwin.
downvotes don't change the truth of the observation. Android is no longer meaningfully open, other than a years old core of basic functions.
The problem is that your observation isn't true. Here are some of the under-the-hood changes in just the most recent releases of Android:
The problem is that your observation isn't true. Here are some of the under-the-hood changes in just the most recent releases of Android:
-OpenGL ES 3.0
-Bluetooth low energy/Bluetooth AVRCP
-restricted profiles
-VP8 encoder
-new DRM framework
-SELinux
-various other optimizations and APIs
The key problem here is that it's open source. The meaning of that term has become very vague, not that OSI's definition is unclear but rather since many people apply the term to so many things. Open source is usually applied for marketing and convenience now days rather than actually showing that this software provides the essential freedoms for the user.
"Open source" has always been about marketing and convenience. If you're looking for "freedom", you should join the "free software" movement instead, which is a distinct one.
Back in the days, people argued that free software will not survive if they keep being idealistic. Instead, people argued that free software should market more, and compromise more with proprietary software. Well, here is the result.
Back in the days, people argued that free software will not survive if they keep being idealistic. Instead, people argued that free software should market more, and compromise more with proprietary software. Well, here is the result.
Please put "Free Software (c)(tm)(r) FSF" or some appropriate similar notice. Otherwise people not familiar with the overloaded meaning of "Free" used by FSF would get a wrong impression that they are actually free to do whatever they want with it.
You are free to do whatever you want with the software. The only real restriction under the GPL is that you are not allowed to distribute modified binaries of GPL software without releasing the corresponding source code.
It's just as restrictive as any commercial license, except that instead of being prohibited from releasing the source, you are required to do so.
That is not 'free to do whatever you want'.
That is not 'free to do whatever you want'.
All of the commercial licenses I've dealt with have prohibited distributing the software, hypothetical modifications thereof, and any and all hypothetical source code.
The GPL speaks for itself. You are free to modify GPL-licensed software and distribute your modified version with the caveat that you make the source code available. Thus you are in fact free to do whatever you want to the software. The restriction is on the distribution of the software, not the modification you make.
Why does that one restriction cause so much distress?
The GPL speaks for itself. You are free to modify GPL-licensed software and distribute your modified version with the caveat that you make the source code available. Thus you are in fact free to do whatever you want to the software. The restriction is on the distribution of the software, not the modification you make.
Why does that one restriction cause so much distress?
The GPL arguably has close to the minimal level of restrictions - it allows you to 'do whatever you want', except where that 'whatever you want' prevents someone else from doing whatever they want.
I know the story behind it. I agree with you though, here's the result of open source and it ain't pretty.
Like most things open source is a continuum of subtle differences rather than a category.
In my opinion the following software is much more open than Android:
Linux, Apache, FreeBSD, OpenBSD, GCC, clang, and generally most open source products developed by the community.
In my opinion the following software is less open than Android: C#, OSX, iOS, and generally most software developed by major corporations.
The real keys are that your Android device is locked down, fixing it voids your warranty, and development does not take place in the open, rather every few months a major patch is released and there is no way for the community to contribute to the project in any meaningful way.
In my opinion the following software is much more open than Android:
Linux, Apache, FreeBSD, OpenBSD, GCC, clang, and generally most open source products developed by the community.
In my opinion the following software is less open than Android: C#, OSX, iOS, and generally most software developed by major corporations.
The real keys are that your Android device is locked down, fixing it voids your warranty, and development does not take place in the open, rather every few months a major patch is released and there is no way for the community to contribute to the project in any meaningful way.
> The real keys are that your Android device is locked down, fixing it voids your warranty
As it should. There's nothing in open source that requires a warranty. Here's a snippet from the MIT license, generally considered open:
"THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT."
And from the GPL, also open:
"THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW."
When manufacturers go out of their way to lock down a device, I agree that's a jerk move. But I also don't think it's reasonable to expect them to agree to replace your device if it bricks after you've hacked the firmware. Obviously, the device may be bricked for reasons entirely unrelated to whatever you've hacked, but I don't begrudge manufacturers for drawing a line in the sand and not wanting to expend resources beyond it.
As it should. There's nothing in open source that requires a warranty. Here's a snippet from the MIT license, generally considered open:
"THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT."
And from the GPL, also open:
"THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW."
When manufacturers go out of their way to lock down a device, I agree that's a jerk move. But I also don't think it's reasonable to expect them to agree to replace your device if it bricks after you've hacked the firmware. Obviously, the device may be bricked for reasons entirely unrelated to whatever you've hacked, but I don't begrudge manufacturers for drawing a line in the sand and not wanting to expend resources beyond it.
Perhaps you shouldn't have to modify a firmware to install your own OS on an 'open' platform.
IBM somehow figured out how to do it on an IBM 5150 back in the early 80s and my Raspberry Pi supports it on ARM systems.
I'm happy to use my iPhone which doesn't allow firmware mods under warranty, however, I've never heard Apple talk about the iPhone being an open platform. Google's stance on the openness of Android strikes me as disingenuous.
IBM somehow figured out how to do it on an IBM 5150 back in the early 80s and my Raspberry Pi supports it on ARM systems.
I'm happy to use my iPhone which doesn't allow firmware mods under warranty, however, I've never heard Apple talk about the iPhone being an open platform. Google's stance on the openness of Android strikes me as disingenuous.
What part of Android requires keys to install?
Oh, you mean the _hardware_ is locked down? Guess what, I can't install Ubuntu on an Iphone either. I guess that makes Ubuntu non-open then?
Oh, you mean the _hardware_ is locked down? Guess what, I can't install Ubuntu on an Iphone either. I guess that makes Ubuntu non-open then?
Apple talking point # 3124: we never claimed our platform was open so we can be more hardline than RMS when critiquing Android.
Yeah, that one never gets boring.
Yeah, that one never gets boring.
You'll find very similar disclaimers in nearly all licensed, closed-source software as well.
anyone can make a license that is both open source and providing warranty btw.
open source licenses generally don't provide warranty because they don't have to and devs, providing free stuff, certainly do not want to bother with warranties. Companies could.
open source licenses generally don't provide warranty because they don't have to and devs, providing free stuff, certainly do not want to bother with warranties. Companies could.
Sure, they could. But it would be insane. (at least at the current prices)
Just compare how much an insurance costs that covers damages caused by yourself (being negligent) as opposed to those covering only damages caused by hardware/software defects.
Just compare how much an insurance costs that covers damages caused by yourself (being negligent) as opposed to those covering only damages caused by hardware/software defects.
> The real keys are that your Android device is locked down, fixing it voids your warranty
That's not an issue about Android though, it's an issue with manufacturers.You are free to release an Android device that is not locked down.
That's not an issue about Android though, it's an issue with manufacturers.You are free to release an Android device that is not locked down.
thats effectively a distinction without a difference to consumers, to run android you still need an android device.
There is tons of open hardware you run Android on. It's just not phones.
https://www.google.com/search?q=android+arm+computer
Just curious, what are the pros and cons to Android manufacturer to lock down a device? Are these Android manufacturer each trying to create its own platform based on an open OS?
Mostly carriers demand it. There is no reason to lock the bootloader otherwise.
Of course a more cynical mind can see a reason in planned obsolescence - if you stop updating a device after an year you will buy your next sooner.
Of course a more cynical mind can see a reason in planned obsolescence - if you stop updating a device after an year you will buy your next sooner.
You mean manufactures like Google themselves?
It seems to be an issue with 'Android' as no one, including Google, makes an Android phone on which you can install a modified version of Android without voiding the warranty.
It seems to be an issue with 'Android' as no one, including Google, makes an Android phone on which you can install a modified version of Android without voiding the warranty.
Geeksphone (the same folk that do a Mozilla phone) do.
Looking at www.geeksphone.com I don't see any phones available for purchase.
Android is partly open source. It's neither open nor closed in the same way as gray isn't black or white.
Google has all the right to change the openness of it's software, but generally should be truthfull in their marketing. I haven't lately found them promoting Android for being open source, so all we need to be aware of is that Android, iOS, WP, BB are not open and are of course made to create profit for their companies from their users.
Google has all the right to change the openness of it's software, but generally should be truthfull in their marketing. I haven't lately found them promoting Android for being open source, so all we need to be aware of is that Android, iOS, WP, BB are not open and are of course made to create profit for their companies from their users.
Although "meaningful" is very subjective, one can use Google's rhetoric under which Android was initiated as a touchstone: http://www.openhandsetalliance.com/press_110507.html
Of course when you do that, the current level of openness is not just "no longer meaningful", it's bordering on parody.
Of course when you do that, the current level of openness is not just "no longer meaningful", it's bordering on parody.
Could you explain? Looking at the document you cited, I'm not sure what you mean. For example, the document says that Android would give "mobile operators and device manufacturers significant freedom and flexibility to design products" and that "Handset manufacturers and wireless operators will be free to customize Android in order to bring to market innovative new products faster and at a much lower cost." Both of those things seem to hold true, even with the changes being made to Google Play Services. Am I missing something?
Well, the new DRM framework definitely isn't open, and essentially all the things you list are stuff that's too low-level to be implemented as part of Google Play Services. Basically, if they could put it in the closed source Google Play Services, they have - including relatively core functionality like improvements to the location APIs and push notifications.
I agree. I worked for a company that was building their own TV platform on top of Android. From their (and my) point of view, Android was meaningfully open.
You don't need Google's closed services to have a working and meaningful platform. You also still benefit from the large developer mindshare and identical APIs compared to Google's Android.
You don't have the added benefit of the content discovery & delivery platform Google provides, nor of any of the closed Google API's. Depending on your use case, that may make it "meaninglessly open", but I would definitely argue that this isn't a universal statement.
I also have multiple Android devices that don't have access to Google Play (a set-top box and a system-on-a-stick) and I really don't mind that they don't have access to Play.
You don't need Google's closed services to have a working and meaningful platform. You also still benefit from the large developer mindshare and identical APIs compared to Google's Android.
You don't have the added benefit of the content discovery & delivery platform Google provides, nor of any of the closed Google API's. Depending on your use case, that may make it "meaninglessly open", but I would definitely argue that this isn't a universal statement.
I also have multiple Android devices that don't have access to Google Play (a set-top box and a system-on-a-stick) and I really don't mind that they don't have access to Play.
On the other hand, Google Play Services largely encompasses those features that were /always/ closed source in Android: maps, google+ and GCM. The Google applications that are core to the "standard" Android experience for most users have also always been closed source: Maps, Gmail, Google Calendar.
There are still a lot of new features being introduced to the core Android APIs, with fragmentation issues being mitigated by a provided support library [0] which essentially backports the newer APIs to older versions of Android (some new features are only in the support library).
Android as it's sold in most consumer devices obviously isn't entirely open, but Google still seem to be attempting to strike a balance between supporting the open-source platform on the other, and building up a suite of closed userland features on the other. You might disagree with their judgement on where the balance is, but I think it's unfair to say it's being developed as a completely closed product.
[0] http://developer.android.com/tools/support-library/index.htm...
There are still a lot of new features being introduced to the core Android APIs, with fragmentation issues being mitigated by a provided support library [0] which essentially backports the newer APIs to older versions of Android (some new features are only in the support library).
Android as it's sold in most consumer devices obviously isn't entirely open, but Google still seem to be attempting to strike a balance between supporting the open-source platform on the other, and building up a suite of closed userland features on the other. You might disagree with their judgement on where the balance is, but I think it's unfair to say it's being developed as a completely closed product.
[0] http://developer.android.com/tools/support-library/index.htm...
Not just that, Google is devoting its energy to develop the closed platform rather than developing android. The example you give are relatively minor updates with major new functionality now being developed outside of core android as the author points out.
Google also devotes energy to search, email, robot cars, internet balloons... the idea that having a closed source set of APIs for google products is stealing resources away from android is specious.
The point is that more energy being put on closed source Android development rather. Yes, Google has a lot of money but money is not it's only resource. Unnecessary projects have been closed off like Google Labs, Reader etc etc.
Google has a limited range of focus, Google's Android developers have a limited range of focus and Google would seek to guard them against unsupported distribution systems (open source ones). Maybe Google will open source more?
They're also migrating some functionality from core Android into Play Services. For example, the replacement for the (effectively broken) proximity alerts is the new geofencing API. But that's not in core Android, it's in Play Services, even though it's all on-device functionality, that doesn't need to interact with any Google central machinery.
That's inaccurate. Location services doesn't just use GPS - it depends on data from Google when determining location via wifi, which is more battery efficient. So there are definitely Google-specific elements in there.
Proximity Alerts are part of the released AOSP core source. The replacement is not. They can interact with the WIFI location provider, but don't have to, and are still functional even if it's disabled (which is easy to do from the stock UI). So, this is a function which has been moved from core AOSP to Play Services.
Outside of APIs to interact with GPS and sensor data, the location APIs in the Android framework have always operated with Google APIs for determining things like locations, addresses, etc. This is really nothing new and devs are free to write their own geofencing API.
Everything in Play Services is application level. Just because Apple bundles a mail app and browser in with their OS doesn't mean that those kinds of things make up an operating system. Any tablet maker in China can still use Android to get a complete mobile operating system for free, without even telling Google they are going to do it. So can Amazon. Can I make a new phone with iOS for free, as long as I don't include Apple mail? Not even close. So let's not start pretending that Android is just like iOS now.
Just because Apple bundles a mail app and browser in with their OS doesn't mean that those kinds of things make up an operating system.
Yup. People bashed Microsoft about this for years because everything was so tied together, there was even an agreement to unbundle it as part of a European Anti-Trust case[1]. As developers, we are ALWAYS talking about decoupling systems, making things easier to manage and exchanging data using APIs. Don't see what the problem is with this, and if it means Google is able to get security patches out quicker rather than relying on manufacturers, then this is a win-win situation.
I wonder if Apple will ever get the Microsoft treatment
[1] http://en.wikipedia.org/wiki/European_Union_Microsoft_compet...
Yup. People bashed Microsoft about this for years because everything was so tied together, there was even an agreement to unbundle it as part of a European Anti-Trust case[1]. As developers, we are ALWAYS talking about decoupling systems, making things easier to manage and exchanging data using APIs. Don't see what the problem is with this, and if it means Google is able to get security patches out quicker rather than relying on manufacturers, then this is a win-win situation.
I wonder if Apple will ever get the Microsoft treatment
[1] http://en.wikipedia.org/wiki/European_Union_Microsoft_compet...
People aren't suggesting that Apple is significantly open, what they are now observing, is that Google is becoming more "closed" - and to call "Play Services" an application is a little bit of a misnomer. It's a system level service that enables higher level applications. The Mail.App doesn't do anything of the kind (though, the rendering engine is an apt comparison).
Everything in play services is most certainly not Application level. I presume you didn't read the linked article or the other comments here about the APIs that are migrating there.
Isn't GooglePlayServices by definition app level? My understanding is it runs in app space. Any other developer could accomplish the same thing.
The article clearly states that new platform APIs are showing up in Google Play services instead of in core Android. The article mentions this as a benefit - 3rd party app developers get access to new APIs quickly and consistently across all Android devices.
The downside is the new APIs are showing up in the closed-source Google Play services, and not in the open source Android project.
The downside is the new APIs are showing up in the closed-source Google Play services, and not in the open source Android project.
Here is the API:
http://developer.android.com/reference/gms-packages.html
The only thing there that is not explicitly tied to Google itself is the new location stuff. The rest is game, maps and Google+. I could totally see an argument that the location stuff (geo-fencing and such) would be more appropriate in AOSP, but that's about it. I'm going to keep my pitchfork holstered until I see a real pattern. Well, probably not even then since I don't see closed-source as a personal affront, but you get my drift.
http://developer.android.com/reference/gms-packages.html
The only thing there that is not explicitly tied to Google itself is the new location stuff. The rest is game, maps and Google+. I could totally see an argument that the location stuff (geo-fencing and such) would be more appropriate in AOSP, but that's about it. I'm going to keep my pitchfork holstered until I see a real pattern. Well, probably not even then since I don't see closed-source as a personal affront, but you get my drift.
I too thought about OSX and Darwin when I saw this. Except that before, with Android, you had an open userland system on an open kernel. Now you have a huge binary blob that can do everything without control, on top of a open userland with an open kernel. It's a closed layer on top of two open layers. And the best of all, more and more things seem to depend on the closed layer instead of just on the other two.
From what I see, as it "defrags" Google has been moving core functionality, previously open, into that closed-source Play Services thing. I think the plan is probably to take everything related to UX into the closed part, that Samsung, HTC and etc. won't then be able to change to create their own UX, and leave as open source the essentials needed for porting to new devices.
I have mixed feelings about this... it's great if they manage to dismiss those who think there's a fragmentation problem in the platform. But they are doing it at the cost of decreased openness, and I don't like that.
"I think the plan is probably to take everything related to UX into the closed part, that Samsung, HTC and etc. won't then be able to change to create their own UX,"
I doubt it. The manufacturers would revolt at that point, and potentially fork the entire platform.
I doubt it. The manufacturers would revolt at that point, and potentially fork the entire platform.
Nonsense. You can certainly argue that "less" of Android is being open sourced than a few years ago, but it's still orders of magnitude more open than any of the other mobile OS available on the market. Especially OS X and iOS, which are both 0% open source.
Open source fanatics are impossible to satisfy, they will always find a reason why the flavor of open source that a company or an organization picked is not the "real" open source, but the simple truth is that I can load up the source of Android in any IDE and start debugging into Android's system libraries any time I need it.
Good luck getting this from Apple.
Open source fanatics are impossible to satisfy, they will always find a reason why the flavor of open source that a company or an organization picked is not the "real" open source, but the simple truth is that I can load up the source of Android in any IDE and start debugging into Android's system libraries any time I need it.
Good luck getting this from Apple.
While I'm not suggesting that OS X is as open as, say, Android, I don't think the parent is speaking Nonsense. OS X does have and open source element, http://en.wikipedia.org/wiki/Darwin_(operating_system), so claiming iOS and OS X are "0% open source" is somewhat incorrect.
I think the parent is correct in that Google is now moving the value added components of their Operating System (as opposed to the more "core" elements of the OS, into closed source and fully under Google's control. It's a rational move, and I applaud them for their cleverness.
I think the parent is correct in that Google is now moving the value added components of their Operating System (as opposed to the more "core" elements of the OS, into closed source and fully under Google's control. It's a rational move, and I applaud them for their cleverness.
Unless something has changed, there is no darwin for iOS and never has been.
http://en.wikipedia.org/wiki/Darwin_%28operating_system%29
"Darwin is now only available as source code,[5] except for the ARM variant, which has not been released in any form separately from iOS."
http://en.wikipedia.org/wiki/Darwin_%28operating_system%29
"Darwin is now only available as source code,[5] except for the ARM variant, which has not been released in any form separately from iOS."
While I agree with your reasoning in the latter sections, comparing android to basically every other mobile os and calling it an order of a magnitude of a difference is a bit strange when they are basically 0.
Good point, I should have said "infinitely" instead of "orders of magnitude".
> it's still orders of magnitude more open than any of
> the other mobile OS available on the market.
Symbian? OpenMoko? The upcoming SailfishOS, Tizen, Firefox OS, and Ubuntu phone? Oh, you meant in the U.S., I guess. (Yes, I know that all the above have either already largely failed or have sketchy futures. That's an entirely different kettle of fish.)
> Open source fanatics are impossible to satisfy
All I want is the ability to make arbitrary changes to the software running on my phone. Why is that so hard?
Symbian? OpenMoko? The upcoming SailfishOS, Tizen, Firefox OS, and Ubuntu phone? Oh, you meant in the U.S., I guess. (Yes, I know that all the above have either already largely failed or have sketchy futures. That's an entirely different kettle of fish.)
> Open source fanatics are impossible to satisfy
All I want is the ability to make arbitrary changes to the software running on my phone. Why is that so hard?
Arbitrary changes? But then how can we ensure that you are charged the proper price for tethering bandwidth versus phone bandwidth? How can we ensure you are paying the right price to blacklist phone numbers? My goodness what if you remove the default apps from the phone? No, that won't do at all.
> All I want is the ability to make arbitrary changes to the software running on my phone. Why is that so hard?
What mainstream OS makes this easier than Android?
What mainstream OS makes this easier than Android?
> Firefox OS
Considering the closed source bits of Android have no equivalent in Firefox OS I would say it's equally open source as Firefox OS.
Considering the closed source bits of Android have no equivalent in Firefox OS I would say it's equally open source as Firefox OS.
Firefox and Ubuntu phone both run on top of an Android layer so they're not great argument against the openess of Android.
No, absolutely not. Ubuntu on existing Android phones uses the Linux kernel with the Android patches so it can use the OEM binary drivers. It doesn't use any bits of Android. FirefoxOS is the same.
I didn't say they run on top of Dalvik, I'm saying they share some of the lower level foundations like e.g. "the Linux kernel with the Android patches so it can use the OEM binary drivers", which is important because that kind of stuff is what separates a smartphone from a brick.
No. Android layer means Dalvik + bionic. Ubuntu and FirefoxOS run on top of the Linux kernel, which happens to be supplied by Google/OEM vendors on some devices. Both can run on an unmodified Linux kernel if a device supports it, and both are trying to come up with their own devices.
Btw, the Linux kernel is the only GPL piece of code in Android. However closed Android is or will become, the kernel will still be provided because of the virulent license. Arguing Android is open because they ship the kernel that allows FirefoxOS and Ubuntu to boot on some devices is wrong because they are legally bound to ship this kernel, it's not an act of good will (but doesn't mean they wouldn't do it out of good will).
Btw, the Linux kernel is the only GPL piece of code in Android. However closed Android is or will become, the kernel will still be provided because of the virulent license. Arguing Android is open because they ship the kernel that allows FirefoxOS and Ubuntu to boot on some devices is wrong because they are legally bound to ship this kernel, it's not an act of good will (but doesn't mean they wouldn't do it out of good will).
> Especially OS X and iOS, which are both 0% open source
http://opensource.apple.com/release/mac-os-x-1084/
http://opensource.apple.com/release/ios-61/ (and a lot is shared with OS X, such as the xnu kernel)
http://www.cups.org
http://opensource.apple.com/release/mac-os-x-1084/
http://opensource.apple.com/release/ios-61/ (and a lot is shared with OS X, such as the xnu kernel)
http://www.cups.org
To be fair, CUPS was around before Apple's involvement and they purchased the source + hired the developer.
That applies to a zillion other parts of Mac OS X, too, but does that matter?
If it matters: to be fair, Android was around before Google's involvement and they purchased the source + hired the developer (1), and the Linux core of Android also wasn't developed by Google, IIRC.
(1) they probably did more work on Android than Apple did on CUPS, but that's a gradual difference.
If it matters: to be fair, Android was around before Google's involvement and they purchased the source + hired the developer (1), and the Linux core of Android also wasn't developed by Google, IIRC.
(1) they probably did more work on Android than Apple did on CUPS, but that's a gradual difference.
It's always fun to remember a time when Mac OS X's printer support was so bad (mostly due to low marketshare) that they had to adopt the Linux printing solution, and it was an immediate and massive improvement.
And you try and tell the young people of today that ..... they won't believe you.
And you try and tell the young people of today that ..... they won't believe you.
They bought Howl software, its developers, and renamed it Bonjour and made it open-source - that became the de-facto standard for their network "plug-n-play" support for devices because Microsoft was trying to convince standards groups to make its (failed) protocol the standard for this.
OSX printer support wasn't bad because of low marketshare. It was bad because it was a new operating system. And it wasn't just printers but everything. Drivers, applications, utilities. They all took years to move to OSX.
And most technologically astute people (young or old) know that OSX relies extensively on UNIX software of which CUPS is just one part.
And most technologically astute people (young or old) know that OSX relies extensively on UNIX software of which CUPS is just one part.
No, the parent comment is correct.
"It was bad because it was a new operating system." -- it was already bad in the pre-OSX Mac era (mostly due to low marketshare).
"And it wasn't just printers but everything. Drivers, applications, utilities. They all took years to move to OSX." -- for applications and most other things Apple had migration alternatives (Carbon APIs for pre-OSX Mac apps, the Classic environment for emulation of pre-OSX and even Rosetta for emulating PowerPC on Intel).
For the case of printers, they really just dropped whatever they had and went with the Linux solution.
"It was bad because it was a new operating system." -- it was already bad in the pre-OSX Mac era (mostly due to low marketshare).
"And it wasn't just printers but everything. Drivers, applications, utilities. They all took years to move to OSX." -- for applications and most other things Apple had migration alternatives (Carbon APIs for pre-OSX Mac apps, the Classic environment for emulation of pre-OSX and even Rosetta for emulating PowerPC on Intel).
For the case of printers, they really just dropped whatever they had and went with the Linux solution.
I don't see the problem here. Play is part of Google's ecosystem, not the Android OS platform. I can download Android's source code, compile it and put it in any device I want (provided I have the technical capability to do so of course). In fact, this is what Android distributions like Cyanogenmod do, and they also provide a binary blob with Google's stuff as an option, if you want to install it. I don't see the reason to demand the Play store app to be open source nor what could be gained from it.
The problem isn't Play. It's that people are being bound more tightly to the ecosystem.
As a developer, one of the things that was more appealing to me about Android was that Android seemed to be a more level playing field. But this approach tilts things substantially in favor of Google.
In particular, this solves fragmentation for Google, and maybe for Google trusted partners, but it doesn't seem to do so for any other Android developers.
I don't think anybody's saying the Play app should be open source. But if I were making my living from Android apps, I'd worry that Android improvements would be few and far between. Both the technical and business incentives push to improving Play Services, not the base OS.
As a developer, one of the things that was more appealing to me about Android was that Android seemed to be a more level playing field. But this approach tilts things substantially in favor of Google.
In particular, this solves fragmentation for Google, and maybe for Google trusted partners, but it doesn't seem to do so for any other Android developers.
I don't think anybody's saying the Play app should be open source. But if I were making my living from Android apps, I'd worry that Android improvements would be few and far between. Both the technical and business incentives push to improving Play Services, not the base OS.
I don't see any reason why the play app shouldn't be Free software. So, while I might be a minority, I'd certainly like to see all of it opened up.
I'd much prefer a reality where the play service and app is open, and which upstream source you trust is defined by which certificates you trust, and nothing else. That'd make it trivial to set up trusted sources for a company, for example.
I'd much prefer a reality where the play service and app is open, and which upstream source you trust is defined by which certificates you trust, and nothing else. That'd make it trivial to set up trusted sources for a company, for example.
Why should it be free software? What gives you a reason to feel that level of entitlement?
I want the freedom to control what software runs on my device. One straightforward way to do that is for the play app and service (or at least the service api) to be Free software.
So, I would like to run Free software on my devices. Thankfully the kernel is still Free software, so there's still hope we can have open distributions going forward. It seems a shame to double the work to achieve that goal, so I think it makes sense for the software to be opened up.
So, I would like to run Free software on my devices. Thankfully the kernel is still Free software, so there's still hope we can have open distributions going forward. It seems a shame to double the work to achieve that goal, so I think it makes sense for the software to be opened up.
Note that you can replace the Play apk on your device, and create a Free implementation of its (documented) APIs.
I want a pony, too. But unless I am willing to pay for it, I won't get one.
You didn't answer the question--what makes you believe you are entitled to free software from a company that employs thousands of people to write it?
You didn't answer the question--what makes you believe you are entitled to free software from a company that employs thousands of people to write it?
If I had spent a million constructing a virtual pony, and I could give you a copy of it without any additional cost, I'd give you a copy of my pony.
However, the pony in this analogy is the device, not the software. The software is more like the saddle -- and Google are selling ponies with their own custom designed saddle, making it hard to ride it any other way than bareback if you don't use Google's saddle - so that they can sell adwords printed on the saddle, and take a cut from everyone that sells Google compatible stirrups.
At any rate, I didn't say I was entitled to it, just that I couldn't see any reason to keep it closed. I do see many reasons to keep it open.
However, the pony in this analogy is the device, not the software. The software is more like the saddle -- and Google are selling ponies with their own custom designed saddle, making it hard to ride it any other way than bareback if you don't use Google's saddle - so that they can sell adwords printed on the saddle, and take a cut from everyone that sells Google compatible stirrups.
At any rate, I didn't say I was entitled to it, just that I couldn't see any reason to keep it closed. I do see many reasons to keep it open.
I see a great many reasons to keep it closed, not least of which is many millions of dollars worth in intellectual property.
What intellectual property do you think are in the pieces that are closed, in the Google apps and apis for android?
There's certainly a lot of work put into making the stuff work -- but opening up the code won't make it stop working for Google. And I really doubt there's much fancy in there - mostly just grunt work to implement some straightforward ideas. I fail to see how opening that up under something like the GPL or AGPL, preventing someone to (legally) take the code and "run away" with it -- will lower the value of the Android system.
There's certainly a lot of work put into making the stuff work -- but opening up the code won't make it stop working for Google. And I really doubt there's much fancy in there - mostly just grunt work to implement some straightforward ideas. I fail to see how opening that up under something like the GPL or AGPL, preventing someone to (legally) take the code and "run away" with it -- will lower the value of the Android system.
They tried that before, and we got fragmentation. Play Services is supposed to be the solution to that. I think it very well might be a huge improvement.
Well, from a business standpoint, there are a lot of companies planning to piggyback off of Android to launch their own OS platforms. These competitors represent a real threat to the Android platform. When Google was all alone in the smartphone OS space (chief competitors being BBOS and iOS, which aren't licensed to 3rd party manufacturers) they didn't have to worry about competing for the attentions of manufacturers... companies got to choose between Android or making Symbian featurephones. So it was easy for Google to be generous with the source.
Now that Google has to worry about de-Google'd Android products, they need to keep more of their work for themselves.
Now that Google has to worry about de-Google'd Android products, they need to keep more of their work for themselves.
Android was open as long as people did what google wanted with it.
That's the antithesis of open.
That's the antithesis of open.
Like other commenter said, only the Sith deal in absolutes :) In this regard, I'm okay with Google protecting their IP and internal infrastructure, I am not really interested in how they process payments or any of the other details. Open source philosophy does not entitle you to any of that info, you could write your own app store if you so want, like Amazon did.
I remember when Android was starting to gain popularity (around 1.6 I suppose), one of the key decisions that I really liked was that Google apps would have no more access to the OS than any other apps. There was no preference to Google. This has now all changed.
Further, what's to stop other vendors doing this, possibly without users knowledge? How many users will click "allow" on a permissions box that gives the vendor a huge amount of permissions like this just so that they can use the latest MyTwitFace?
Further, what's to stop other vendors doing this, possibly without users knowledge? How many users will click "allow" on a permissions box that gives the vendor a huge amount of permissions like this just so that they can use the latest MyTwitFace?
Where has this changed? Google's apps are still built on top of the SDK. The only real change was the centralization of Google Play Services, but that doesn't change the level of OS access at all and 3rd-party developers can still tap in to these services.
Play Services having a custom updater and the ability to silently gain more permissions is definitely not something available to average 3rd party developers.
Both are available. Any app can request complete control over the system, at which point it can do whatever the hell it wants, short of root. Update? Sure thing, install an APK.
Of course the user has to accept your huge list of permissions first.
Of course the user has to accept your huge list of permissions first.
Normal apps can't install any APK without explicit user consent. The Play Store auto-updates in a similar way.
There are various other Android app store apart from the official play Store
(Amazon, F-droid, etc). Any app can request permission to install other apps silently, or may be even a newer version of itself. Play Store uses no private API which is not available to other Android developer. Ask your users to download the apk from your website, if Google Play store won't carry your app, and then built-in a mechanism to auto-update at will.
Yes, there's a permission to install apps silently (android.permission.INSTALL_PACKAGES), but this isn't a permission that can be granted to a third party app. Other bundled app stores can if they're signed appropriately, or if the device is rooted.
Pretty sure even Facebook used this for a few days when they had their auto-updating beta channel. Nobody seemed to really mind.
That's not 'silently'.
Are you sure this is correct? How is this even possible when you can install Play Services on Android versions before Play Services was even conceived. How can you do this on custom AOSP builds?
Play Services must be playing by the same rules as everyone else or it just wouldn't work on as many devices as it does.
Play Services must be playing by the same rules as everyone else or it just wouldn't work on as many devices as it does.
AFAIK system apks are signed with a special key, that gets special privileges.
I'm not an Android dev, but I would assume that Play Store has always had special permissions in order to be able to install applications, so Google need only deploy an updated version of Play Store for both old/new devices, and that updated version of Play Store have the necessary code to use its privileges to install Play Services and grant Play Services special privileges.
You could write an app which does this, it would just have a huge permissions list.
You're technically correct, which is obviously the best kind. However, on lesser kinds of correctness, I would argue that the Google Services type model at least violates the spirit of that decision. IMHO, the ability to silently add permissions is either a violation of the agreement or a vulnerability in the OS. I doubt any app would last long on the Play store if it did that.
Yes, downvotes don't change the truth of the observation because it was never true. Your observation is unfortunately based on a typical fallacy.
Android has always been, and still is meaningfully open. Google apps are closed source and proprietary. You don't have to use Google services and Google apps.
Almost every single Android app in the Play Store (including the Play Store itself) has always been closed source and proprietary. Nothing really changed. Apps that are related to core functionality are open source and free software. Stock dialer, stock browser etc. are all such examples.
Android has always been, and still is meaningfully open. Google apps are closed source and proprietary. You don't have to use Google services and Google apps.
Almost every single Android app in the Play Store (including the Play Store itself) has always been closed source and proprietary. Nothing really changed. Apps that are related to core functionality are open source and free software. Stock dialer, stock browser etc. are all such examples.
Android is about as open as it used to be. The core OS is mostly open source, the drivers are mostly closed binaries owned by chip vendors, the apps are closed binaries owned by Google. Google Play services, by its name and nature, is part of Google service. So it is just as closed as it used to be.
Over time, more features are added OS, drivers, apps. That doesn't really change the overall picture much. Amazon and Chinese companies like Xiaomi are pretty successful using the core Android OS for their devices.
Over time, more features are added OS, drivers, apps. That doesn't really change the overall picture much. Amazon and Chinese companies like Xiaomi are pretty successful using the core Android OS for their devices.
Almost no major producer of Android phones in China (mainland) IIRC, has deployed or would deploy Google Play, perhaps as a result of both their marketing strategies, that favors some local mobile Internet service providers, and consequence of the back-off stance of Google to the Chinese govn't, the cause of which is quite complicated though. As status quo, Google's services are largely compromised due to unknown or you-guess-what reasons.
Most Google services are blocked in China by Chinese government. Chinese companies, like Xiaomi and Baidu, want to build their own ecosystems to make profit. Their management said so publicly during talks that I attended in person.
Sure android was a great step forward from ios, but after using it for a couple years I can't wait for a real linux phone and android to be a distant memory. The reason Google chose to back android instead of porting a real linux distro to mobile is because they wanted a market to sell programs, not an OS that already has 1000s of top quality open source programs already available. Google wanted an OS where you don't even get a file manager so people can be conned into paying for even the simplest features.
I love Linux, but I disagree with you. The amount of money Google makes from the Play store is negligible compared to their overall revenues. I highly doubt they don't include a file manager so they can make a few more bucks. It probably has more to do with the fact that most people don't need a file manager (mobile computing has a totally different paradigm than desktop computing).
Also, the "1000s of top quality" apps don't exist. Where are they? Most aren't designed for a touch interface so they'd have to be redesigned. Wait, they'd have to be redesigned to give an experience that we already have? How is that not a waste of time? Having seen Ubuntu OS.. It's garbage. "real linux" for the sake of being able to say it isn't worth it if the platform is slower, takes more battery life, and has less apps. Yes, you can improve on those three things, but you'd be putting in so much effort to replicate an OS that is already open source.
A fork of Android is a much better idea than starting from scratch. Look where Maemo, Meego, and Tizen went. Look at where Ubuntu OS will go.
Also, the "1000s of top quality" apps don't exist. Where are they? Most aren't designed for a touch interface so they'd have to be redesigned. Wait, they'd have to be redesigned to give an experience that we already have? How is that not a waste of time? Having seen Ubuntu OS.. It's garbage. "real linux" for the sake of being able to say it isn't worth it if the platform is slower, takes more battery life, and has less apps. Yes, you can improve on those three things, but you'd be putting in so much effort to replicate an OS that is already open source.
A fork of Android is a much better idea than starting from scratch. Look where Maemo, Meego, and Tizen went. Look at where Ubuntu OS will go.
Open Source has an accepted definition. The Open Source Definition was created for the purpose of clarifying what should b required to label something Open Source. Just because they don't go beyond that to the point that others in the community do doesn't mean it isn't open source.
http://opensource.org/osd
In particular:
>License Must Not Restrict Other Software
>The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
Not only does Open Source not imply everything on the platform should be Open Source, it's explicitly against its definition. Google Play services does does not affect the base android operating system. It is given root permissions on the Google backed distributions of the Android Operating System.
It's perfectly fine to complain about Google giving itself a root level backdoor into their official distro. If a less trusted company were to do the same thing, there would be a perfectly validated uproar. But don't change the definition of open source to bolster your argument. In your edit you say "Android is no longer meaningfully open". That's fine, but don't say that it isn't open source, or that it's closed source. That's blatantly by definition false, and the open source community takes their definitions seriously for a reason.
http://opensource.org/osd
In particular:
>License Must Not Restrict Other Software
>The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
Not only does Open Source not imply everything on the platform should be Open Source, it's explicitly against its definition. Google Play services does does not affect the base android operating system. It is given root permissions on the Google backed distributions of the Android Operating System.
It's perfectly fine to complain about Google giving itself a root level backdoor into their official distro. If a less trusted company were to do the same thing, there would be a perfectly validated uproar. But don't change the definition of open source to bolster your argument. In your edit you say "Android is no longer meaningfully open". That's fine, but don't say that it isn't open source, or that it's closed source. That's blatantly by definition false, and the open source community takes their definitions seriously for a reason.
It is amazing how big of an ass you are. Make an assertion --> people provide counter-arguments and downvote you. You --> provide no explanation to your initial assertion and ass-ily mention that downvotes are meaningless.
Be a man and get into the argument if you really believe what you are saying. Otherwise keep blowing yourself to fool yourself into thinking that it is the same thing.
Be a man and get into the argument if you really believe what you are saying. Otherwise keep blowing yourself to fool yourself into thinking that it is the same thing.
It's not quite as bad, but close. Open-source Android is a full-stack operating system, the problem is that as far as everyone is concerned, that's not enough. You need an ecosystem of apps and services (from maps, to push, to youtube, to .. ) to have a competitive mobile platform.
If I was a betting man, I would go long on Google.
If I was a betting man, I would go long on Google.
I never really got why they kept so much of Android open-source. It didn't seem to make sense both from Google's business perspective and from the user's end. Why does Google need to let companies like Amazon create competing platforms using their operating system? And why do they need to be so beholden to the OEMs? It makes sense they're moving more functionality away from it.
(See my question here: http://www.quora.com/Why-did-Google-make-Android-open-source )
(See my question here: http://www.quora.com/Why-did-Google-make-Android-open-source )
When Cyanogenmod closes down, THEN I might consider Android not open source for all intents and purposes. But currently, they're doing fine without the closed Google bits (usually installed as a separate gapps zip file).
There is still one major difference between play service and osx or ios -it is free and can be installed on any compatible devices, so I wouldn't call it "totally" closed at least not as close as iOS.
Darwin is free and can be installed on any compatible devices.
I'd say that Google does quite a bit more by providing the user layer too, if people want it. It's kind of the best of both worlds between Apple's OS X strategy and Microsoft's Windows strategy: open core and available for OEM hardware.
Android is no longer meaningfully open, other than a years old core of basic functions.
This is so utterly and complete wrong, and is the sort of ultra-polarized, hysterical comment that does not belong on HN. I suspect that the single and only reason it isn't dim gray is the appeal-to-sympathy "you downvote the truth!" noise that manipulates the weak-willed.
Just to be clear, Google has always had closed source, proprietary Google bits (gmail, maps, etc. Originally they even built these as a big binary blob in the platform image, and it was "fixing fragmentation" when they moved them to separate apps), and the open source Android bits. Everything you heard about Android 4.3 is in the open source bits ("years old core of basic functions" -- what obnoxious, noisy prattle).
This is so utterly and complete wrong, and is the sort of ultra-polarized, hysterical comment that does not belong on HN. I suspect that the single and only reason it isn't dim gray is the appeal-to-sympathy "you downvote the truth!" noise that manipulates the weak-willed.
Just to be clear, Google has always had closed source, proprietary Google bits (gmail, maps, etc. Originally they even built these as a big binary blob in the platform image, and it was "fixing fragmentation" when they moved them to separate apps), and the open source Android bits. Everything you heard about Android 4.3 is in the open source bits ("years old core of basic functions" -- what obnoxious, noisy prattle).
not an expert in this area, so I won't comment on the accuracy of your claims, but your comment is full of ad hominem vitriol. please keep it civil, whether you agree or not. HN is better than this.
Ad hominem? I am specifically criticizing the comment, so yet another showing of some ignorantly misplaced Latin isn't worthwhile.
Yes, you're criticising the comment, but your criticisms constitute mainly of strong attacks on its tone (ultra-polarized, hysterical, noisy, prattle) and perceived effect (manipulative, obnoxious), plus some extremely strong contradictions without supporting evidence of matching strength (utterly and complete wrong, does not belong on HN).
I do think that you're probably correct with the meat of what you're saying, but there's no question that at best half of your comment is relevant to the actual discussion and the other half describes itself at least as well as it describes the comment it purports to.
My suggestion: your vitriol should be proportional to the strength of the evidence you present rather than to the strength of your feeling.
While technically your comment isn't an ad hominem since you attribute all these terrible things to the comment rather than the person, I can completely see why it rang a lot of the same bells as an ad hominem argument would for some people.
I do think that you're probably correct with the meat of what you're saying, but there's no question that at best half of your comment is relevant to the actual discussion and the other half describes itself at least as well as it describes the comment it purports to.
My suggestion: your vitriol should be proportional to the strength of the evidence you present rather than to the strength of your feeling.
While technically your comment isn't an ad hominem since you attribute all these terrible things to the comment rather than the person, I can completely see why it rang a lot of the same bells as an ad hominem argument would for some people.
You're right, it's not ad hominem, but your post is chock full of overly emotive (read, manipulative) language. To illustrate, I'll remove the emotive language and you can see the difference:
>Android is no longer meaningfully open, other than a years old core of basic functions.
This is wrong, and things I think are wrong don't belong on HN. I suspect you weren't voted down because of the (logically fallacious) appeal to consequences.
Just to be clear, Google has always had closed source, proprietary Google bits (gmail, maps, etc. Originally they even built these as a big binary blob in the platform image, and it was "fixing fragmentation" when they moved them to separate apps), and the open source Android bits. Everything you heard about Android 4.3 is in the open source bits.
>Android is no longer meaningfully open, other than a years old core of basic functions.
This is wrong, and things I think are wrong don't belong on HN. I suspect you weren't voted down because of the (logically fallacious) appeal to consequences.
Just to be clear, Google has always had closed source, proprietary Google bits (gmail, maps, etc. Originally they even built these as a big binary blob in the platform image, and it was "fixing fragmentation" when they moved them to separate apps), and the open source Android bits. Everything you heard about Android 4.3 is in the open source bits.
what obnoxious, noisy prattle! (lol)
This is the sort of hysterical comment that does not belong on HN, to quote you.
The problem is that people have built false expectations for themselves about what Android is, and even created false definitions of what open source is. All Android is is the operating system. Take any Linux distro, and strip out all the applications bundled with it and you don't have much. All open source means is that you can legally fork it.
People have created their own definitions for these things on no basis. There's a reason why there are so many terms in the open source world. There's Open Source. There's Free software. There's Free and Open Source software. They all mean different things, and the reason we nerds have so many definitions is precisely to avoid these kinds of misconception and false expectations. Ironically they've become complicated enough that everyone else ignores their definitions.
People have created their own definitions for these things on no basis. There's a reason why there are so many terms in the open source world. There's Open Source. There's Free software. There's Free and Open Source software. They all mean different things, and the reason we nerds have so many definitions is precisely to avoid these kinds of misconception and false expectations. Ironically they've become complicated enough that everyone else ignores their definitions.
This is 100% correct. The google apps have always been proprietary, custom roms for example arent allowed to include them.
"So Google has abandoned the open source part of Android and is now developing the operating system as a completely closed product."
Not sure what's new here.. Play always came with strings attached. OEMs can choose Play or use AOSP and roll their own Play analogue like Meizu or Xiaomi or Amazon.
Not sure what's new here.. Play always came with strings attached. OEMs can choose Play or use AOSP and roll their own Play analogue like Meizu or Xiaomi or Amazon.
Correct me if I'm wrong. From 4.0 Play is mandatory if you want drivers. That's why Barnes and Noble had to put Play on their devices.
That's just incorrect as far as I know. It remains possible to support all drivers with an AOSP build.
B&N decided they wanted to "mainstream" their Android in terms of enabling it to be a "Google-logo" device. Probably a good choice if you haven't got the scale of Amazon's ecosystem.
B&N decided they wanted to "mainstream" their Android in terms of enabling it to be a "Google-logo" device. Probably a good choice if you haven't got the scale of Amazon's ecosystem.
I am OEM app developer and can confirm this.
One of our apps rely on GPS, and the manufacturers that bought that app from us could only make it work after installing Play Services, and they could not figure a way to make it work without Play Services.
One of our apps rely on GPS, and the manufacturers that bought that app from us could only make it work after installing Play Services, and they could not figure a way to make it work without Play Services.
Location Services is a special API, in that Google bears some costs to enable it for geocoding, for example.
It is possible to have access to basic location data from a built-in GPS receiver in AOSP, so the system is not completely dependent on Google Play Services.
It is possible to have access to basic location data from a built-in GPS receiver in AOSP, so the system is not completely dependent on Google Play Services.
Exactly. "GPS" data is certainly available and part of the standard open source framework: http://developer.android.com/reference/android/location/pack...
But access to e.g. Google's giant wifi-to-location database isn't part of that API. And it's a good service, and something that is hard to replicate and thus a competetive advantage.
But to speak to the upthread parent: it has nothing to do with "drivers". The HAL interface for GPS data is part of AOSP.
But access to e.g. Google's giant wifi-to-location database isn't part of that API. And it's a good service, and something that is hard to replicate and thus a competetive advantage.
But to speak to the upthread parent: it has nothing to do with "drivers". The HAL interface for GPS data is part of AOSP.
> And it's a good service, and something that is hard to replicate and thus a competetive advantage.
It's a service that Google will not let manufacturers replace even if they want to. Horribly anti-competetive. http://www.mobileburn.com/news.jsp?Id=14923
It's a service that Google will not let manufacturers replace even if they want to. Horribly anti-competetive. http://www.mobileburn.com/news.jsp?Id=14923
If Google had allowed this, it would mean using Google branded android apps that use a completely different location API. I would be nervous about this if I were Google, when something goes wrong or doesn't work with the API, my apps will take the heat since the average user won't know the difference between Skyhook and Google location APIs. Further, as a consumer I would have never been able to switch back to the Google location APIs without flashing. Of course, manufacturers can still have their own apps using Skyhook's SDK.
That's not exactly correct. Amazon, for example, is free to use whatever location services they want, since they use an Android-based system that uses no part of the Google ecosystem.
So if you want Google Play and everything else Google in your device, you have to take Google's location services, too. That may not be unreasonable.
So if you want Google Play and everything else Google in your device, you have to take Google's location services, too. That may not be unreasonable.
That may be true, but it's not an issue of denying "GPS" data, which is what the upthread parent was confused about. You can get location output from GPS (or in fact anything else that your platform has wired into the HAL -- it's not specific to GPS per se) data.
It's Google's extra, proprietary services that are, well, proprietary. And that's hardly notable IMHO. There are lots of players in this space, it just happens that Google has done it better and is using that (among other features obviously) to drive sales of its "Play Services" product to OEMs.
Non-free software is non-free. If you care about that stuff, you wouldn't use it anyway.
It's Google's extra, proprietary services that are, well, proprietary. And that's hardly notable IMHO. There are lots of players in this space, it just happens that Google has done it better and is using that (among other features obviously) to drive sales of its "Play Services" product to OEMs.
Non-free software is non-free. If you care about that stuff, you wouldn't use it anyway.
> Google has done it better and is using that to drive sales of its "Play Services" product to OEMs
Google aren't competing in the "Wifi to location" space on merit. They're competing on "we won't let you use our platform if you use a competitor in this space". They're becoming the 1990's Microsoft. This is exactly the shit people talk about when they say Android isn't open anymore.
Google aren't competing in the "Wifi to location" space on merit. They're competing on "we won't let you use our platform if you use a competitor in this space". They're becoming the 1990's Microsoft. This is exactly the shit people talk about when they say Android isn't open anymore.
Oh stop. Google is limiting access to their Play Services Location API (a feature so obscure that even the technical folks in this very thread don't seem to understand what it does and think it controls access to GPS data) to OEMs willing to license the whole Play Services package.
Are you seriously arguing that that is somehow equivalent to Microsoft using their monopoly position in the market (something Google doesn't even have) force OEMs into bundling their own web browser (the single most important app of the past two decades)? No. Just no.
I'm sorry, but people who want wifi-to-location data in their Android apps or devices can get it. That's simply not anticompetetive in any sane use of the term.
Your last sentence, telling, pivots your argument pretty wildly from "anticompetetive" to "not open". And yes: if you want to complain about Play Services being proprietary software, non-open, non-collaborative and ultimately freedom-denying, I tend to agree. But the idea of this being somehow an antitrust issue is ridiculous.
Are you seriously arguing that that is somehow equivalent to Microsoft using their monopoly position in the market (something Google doesn't even have) force OEMs into bundling their own web browser (the single most important app of the past two decades)? No. Just no.
I'm sorry, but people who want wifi-to-location data in their Android apps or devices can get it. That's simply not anticompetetive in any sane use of the term.
Your last sentence, telling, pivots your argument pretty wildly from "anticompetetive" to "not open". And yes: if you want to complain about Play Services being proprietary software, non-open, non-collaborative and ultimately freedom-denying, I tend to agree. But the idea of this being somehow an antitrust issue is ridiculous.
> Horribly anti-competetive
Did the lawsuit finish?
Did the lawsuit finish?
I think there might be a need for providing a decent layer between the various closed layers created by Amazon, Google et al. At least, that would allow apps to be friendly to Android without marrying Google Play.
(Is there one?)
(Is there one?)
I'm not sure what drivers you refer to, but Play definitely isn't mandatory to use the AOSP. Barnes and Noble presumably had all the drivers they needed to make the Nook functional without Play?
Interesting. Everyone put it as an attempt to keep the Nook relevant (because you get all the google apps with it), but I'd be interested in seeing more on that side of things. Which drivers, though? Usually you'd get the graphics driver from the chipset manufacturer, for instance, who they would already be contracting with because they make the device.
Wonder what Andy Rubin thinks about how this fits into the definition of open https://twitter.com/Arubin/status/27808662429
I think this is great for Android as a whole, users will be better served.
It does cut into the openness of Android though. Unless Amazon bends to Google's way of doing things a little bit their platform will stay even further behind, for instance.
It does cut into the openness of Android though. Unless Amazon bends to Google's way of doing things a little bit their platform will stay even further behind, for instance.
Indeed it makes an increasingly important part of Android closed. It would have been better to make all of the parts of Android OS that run in a Dalvik instance updatable - or something like that. Unfortunately that part of Android is effectively held hostage by OEM modifications.
It would be nice that if an OEM commits to limiting their modifications to, say, at worst, some privileged apps, that there would be a workflow from Google's OS development to the SoC makers' chipset support engineering, to the OEMs so that new versions could be continuously integrated and therefore delivered to each product shortly after release. That plus some kind of community support model for EOL'ed products would harness openness in the cause of timely updates and long-term support.
It would be nice that if an OEM commits to limiting their modifications to, say, at worst, some privileged apps, that there would be a workflow from Google's OS development to the SoC makers' chipset support engineering, to the OEMs so that new versions could be continuously integrated and therefore delivered to each product shortly after release. That plus some kind of community support model for EOL'ed products would harness openness in the cause of timely updates and long-term support.
[deleted](1)
defragmenting
defragging
I used to work with a guy who would omit a few vowels in one of those gigantzor java-hostage symbol names, like AbstractTemplateSignalsProviderFactoryBn, as if leaving the "ea" out of "Bean" had helped anyone at all.
Three letters, a syllable, and sounding better to the technical crowd who understands the jargon (and, if you're outside that technical crowd, you won't understand "defragmenting" any better).
The video game community might misinterpret it:
http://en.wikipedia.org/wiki/Frag_%28video_gaming%29
http://en.wikipedia.org/wiki/Frag_%28video_gaming%29
That's exceedingly unlikely.
Not really - that was how I understood it too, and the title just didn't make any sense. Is "defragging" a common substitute for "defragmenting"? I have never encountered it before.
Yes it is. When MS-DOS introduced defrag.exe, the term defragging came into existence and never left :)
It'd be interesting to see how it pans out for OEMs that don't, for various reasons, bundle Play Framework/Services with their phones. This could be fixed by having the user install a GApps zip through recovery, but it'd be a pain to the average user. Also, are there, or will there be, any manufacturers forbidden to use the Play Store and its framework? It seems for the vast majority of people, this move is great, but for a tiny minority, i'm not so sure.
It is difficult to say if manufacturers might get locked out. So far Google has let B&N come in to the Google Play ecosystem when they wanted to do that, and Amazon evidently prefers to cultivate their own ecosystem.
If Google could make licensing transparent and accessible to 3rd tier OEMs, that would improve the customer experience at the low end.
If Google could make licensing transparent and accessible to 3rd tier OEMs, that would improve the customer experience at the low end.
Would Google object to having Play on devices made in and/or for North Korean officials, or Iranians etc? Would Google be forced to restrict access to them? Granted, the amount of people this realistically affects is very small.
It's worth noting how closely Android's apparent path going forward mirror's Apple's strategy with both OS X and iOS: closed end-user components built on top of an open source core. I guess Google's realized that "openness" isn't a meaningful market differentiator for the average consumer.
Google didn't choose the open-source route because it figured consumers would find that enticing. They did that to encourage development on a low marketshare platform. Android exploded in popularity in exchange for fragmentation.
And we have to assume that Google will do exactly the same thing with Chrome and Chrome OS when it is to their advantage to do so.
I'd like to know what technical benefits there are, if any, from this roundabout approach by Google. I suspect there aren't many, if any, and this is more of a tactic to 'circle around' and retroactively gain tighter control over the OS. (Also, see Google's purchase of Motorola with the intention of making phones with better hardware-software integration...)
They (Google) can release new versions of these core services to almost all users immediately, without those users having to wait for their devices' manufacturers to go through the usual testing and shittification (aka "skinning and customization") process.
I'm interested, what is the open source core in OSX and iOS? I was not aware of any. I know they share code with BSD but I didn't think it was to the extent that one could compare Apple's OS relationship with BSD to Android's relationship with Linux.
[deleted]
So, the ultimate nail in the coffin for open, fragmented services. If you want to build a good OS, you ultimately have to take almost complete control. (Google is basically following Apple's route.)
The reason I think the Google system is worse is that theoretically any application can achieve this level of control. So while I might trust Google, it seems all too easy to trick users into installing a different process which can take complete control of their phone. With iOS, only Apple is capable of this level of control, thus decreasing the attack vectors.
EDIT: Admittedly it's highly unlikely that Google would ever let such an application into the Play Store, thus limiting its distribution potential.
The reason I think the Google system is worse is that theoretically any application can achieve this level of control. So while I might trust Google, it seems all too easy to trick users into installing a different process which can take complete control of their phone. With iOS, only Apple is capable of this level of control, thus decreasing the attack vectors.
EDIT: Admittedly it's highly unlikely that Google would ever let such an application into the Play Store, thus limiting its distribution potential.
Also, Google do some kind of scanning of applications you want to install (optional), last time i checked, so that would probably limit the distribution potential even further. AFAIK, Google's services have root access to the system (they can freely download .apk, install them silently and more), but rogue apps would need a 0day on non-rooted phones,
Smart move by google. Potentially they've regained control of their platform past, present and future...
In one fell swoop they can resolve fragmentation, keep everyone up to date on functionality/APIs, bypass OEM/carrier update issues (be it carrier QA, OEM lack of interest, or just crapware). Most importantly google can keep any OEM's (ie samsung) in check and prevent them branching away from android.
The downsides: what happens when google break an entire range of phones/functionality with an update? Are they going to QA every android product in existence? Will older models slow down and become unusable as the baseline resource requirements increase? (I'm looking at you IOS7)...
In one fell swoop they can resolve fragmentation, keep everyone up to date on functionality/APIs, bypass OEM/carrier update issues (be it carrier QA, OEM lack of interest, or just crapware). Most importantly google can keep any OEM's (ie samsung) in check and prevent them branching away from android.
The downsides: what happens when google break an entire range of phones/functionality with an update? Are they going to QA every android product in existence? Will older models slow down and become unusable as the baseline resource requirements increase? (I'm looking at you IOS7)...
So Rubin departs leadership of Android just before Android becomes "not open". Seems like there's a backstory here that I'd love to hear about.
Moving some functionality into the Play Services package is a direction that Google have clearly been going in for at least a year: last year both Google+ integrations (understandably) and an updated Google Maps SDK being released.
Android Community's original description of Play Services as "In a nutshell, Google Play services allows app developers to integrate other Google services, like Google Plus, into their apps" is still accurate today.
Android Community's original description of Play Services as "In a nutshell, Google Play services allows app developers to integrate other Google services, like Google Plus, into their apps" is still accurate today.
Again, I'm not going to argue the point, but it does seem like Play has gained a lot more significance after Andy's sidestep.
I found the Google memos from the Java trial absolutely fascinating… I imagine the story (going back a couple of years) on this would make great literature.
I found the Google memos from the Java trial absolutely fascinating… I imagine the story (going back a couple of years) on this would make great literature.
As always, everyone forgets to mention the poor, slow and by now outdated Android WebView - which by the way will finally be getting a very important upgrade in the form of WebViewFactory. This may allow using alternative WebViews, such as a chromium-based webview - another important step towards defragmentation.
Some more info is available at http://danosipov.com/?p=572
Some more info is available at http://danosipov.com/?p=572
Having written a mobile app framework targeting both UIWebView (iOS) and WebView, and several apps with a single codebase for both platforms, this can't come soon enough. The current Android-Browser-based WebView uses a disgustingly out of date WebKit release, while the iOS UIWebView is basically the current Mobile Safari version with a few features disabled.
The sad state of WebView is the biggest cause of difficulty writing cross platform HTML5/JS apps, even more so than device hardware fragmentation.
The sad state of WebView is the biggest cause of difficulty writing cross platform HTML5/JS apps, even more so than device hardware fragmentation.
I've been working on something similar myself, since Google has indicated Chromium WebView isn't a priority for them right now https://github.com/davisford/android-chromium-view
How does your work compare to this?
https://github.com/pwnall/chromeview
https://github.com/pwnall/chromeview
Read the first couple sentences on the github page
I don't see how that answers my question. I did not ask "did you steal this guy's code"... I am curious what your project does differently, when I would choose to use one over the other, and why your project exists.
To provide a example, if someone asks me "how does Cydia compare to Installer", I say that it is based on an industry standard packaging system (as opposed to a one-off proprietary one), has package dependencies, a fast local search feature, installs by default with useful repositories, and is open source. It is not useful to say "Cydia is inspired by Installer but shares no common code".
To provide a example, if someone asks me "how does Cydia compare to Installer", I say that it is based on an industry standard packaging system (as opposed to a one-off proprietary one), has package dependencies, a fast local search feature, installs by default with useful repositories, and is open source. It is not useful to say "Cydia is inspired by Installer but shares no common code".
ChromeView is unfinished business; the author has stated that he doesn't have time to commit to it right now. Certain things are broken in it like native scrolling. I started using it, and the more I got into the Chromium source, I realized that Content Shell is a better starting point (he started with AndroidWebView). Mine uses Chromium Content Shell -- native scrolling works great. The browser seems to be fully functional and performs quite well. What is left for you, or anyone interested, is to write your own Java/C++/JavaScript glue to make it into what you want it to be.
If you read the second paragraph, you'll notice the difference: android-chromium-view is a toolkit to help you build your own chromeview-alike using the latest version of Chromium.
Its a really great project - I'll be trying it out with my own apps.
Its a really great project - I'll be trying it out with my own apps.
Alas, the system UI (button bar, switching, etc) are not included in the updateable components :(.
>>This is how you beat software fragmentation.
This does help defragment Android from a Google (developed) app perspective.
However, it doesn't do anything for 3rd-party developers. It doesn't do anything for regular consumers who wish to upgrade their 2.3.3 phones or 4.1 phones to the latest version of Android. So Google has a long way to go before they really defragment Android.
This does help defragment Android from a Google (developed) app perspective.
However, it doesn't do anything for 3rd-party developers. It doesn't do anything for regular consumers who wish to upgrade their 2.3.3 phones or 4.1 phones to the latest version of Android. So Google has a long way to go before they really defragment Android.
What? It absolutely helps 3rd party app developers. Need a new and better video/gps/network/etc.. api? Right now you stuck depending on a new OS Version. if they start tying api's to play store updates, as they have with things like geolocation/gps functions, they worrying which OS and about fragmentation mostly goes away for 3rd party developers of apps.
How is Play going to update the kernel without the OEM's involvement?
Some software improvements and new libraries will be available, and that's a plus for users. But this is still a far distance from REAL OS updates. I'd worry this disincentives OEMs to do real updates.
Some software improvements and new libraries will be available, and that's a plus for users. But this is still a far distance from REAL OS updates. I'd worry this disincentives OEMs to do real updates.
Sure certain very low level items are going to be difficult to update outside of the kernel. Let's use video as an example, it's something I'm really familiar with. At the Kernel android provides an OEM version of the stagefright lib and the actual video drivers, those would be hard to update outside of the kernel. What the play store can easily update is newer and better API's to those low level lib's. Right now those encoder/decoder API's were new in OS version 4.1 ( I think 4 something, just woke up :) ) but using the google play updates new and better API's could be rolled out at anytime.
I'm not sure about the extent of the 'mostly' part. You still have the huge differences in CPU speed, GPU capabilities, screen sizes and amount of memory to cater with.
That 5 year old phone may have the latest Play Services, but what good is that if that leaves only 10 kilobytes of RAM for your app?
That 5 year old phone may have the latest Play Services, but what good is that if that leaves only 10 kilobytes of RAM for your app?
You have the same problem with, for example, iOS devices though - there are games out there that don't run on older devices even though they're all nominally running the same OS because the older devices are too slow.
I think that's the "acceptable" end of fragmentation. Of course technology will get better, and old devices will be left behind. It doesn't matter what platform you are on.
That's a different issue. This is about Software fragmentation. Hardware fragmentation is alot harder to solve IMO.
I feel like most people aren't version number junkies, and as long as their phone does all (or most) of the same things that neighbour Jones' Nexus phone does they'll be happy.
The whole point of it is to help 3rd party developers with the API's, so they homogenize the API's through Play Services.
However, you're right about the user part. It will help the users slightly, better apps with latest API's will come along, but the users still won't get the latest features of the OS unless the phone is upgraded to the latest version.
However, you're right about the user part. It will help the users slightly, better apps with latest API's will come along, but the users still won't get the latest features of the OS unless the phone is upgraded to the latest version.
i think this will ultimately prove to be a terrible move for google. android's success is largely a function of how attractive it is to device manufacturers and carriers. stripping control from them is going to force them into a corner where forking android or moving to another platform (amazon's fork of android, firefox os, windows phone 8 and ubuntu mobile are all potentially technically competitive even if they are not currently feasible).
I don't see what the issue is. It seems to me that the OEMs are still perfectly able to build their own skins and bundle their own apps. They just can't let their recently released devices rot with outdated tech.
Not to mention that if OEMs completely leave Android, they lose the app ecosystem. Having already launched an Android app store was a big boost to for the Kindle Fire. Not many other companies can pull that off though.
Not to mention that if OEMs completely leave Android, they lose the app ecosystem. Having already launched an Android app store was a big boost to for the Kindle Fire. Not many other companies can pull that off though.
No better news for the industry and users could have been know today.
The headline made me think Android 4.3's fstrim feature (defragging flash storage) is delivered via Play too!
That only really benefited the Nexus Devices. Far as I know no other popular device has had issues due to lack of fstrim. And all recent Nexus devices already got the 4.3 update.
But since Play Services has system level access I am wondering if they could've technically been able to stuff the fstrim daemon along with the app updates. All it does is wakes up on idle and issues trim ioctls - Linux kernel proper has had TRIM support for a while.
But since Play Services has system level access I am wondering if they could've technically been able to stuff the fstrim daemon along with the app updates. All it does is wakes up on idle and issues trim ioctls - Linux kernel proper has had TRIM support for a while.
You can get an app that does it already, but it requires root:
https://play.google.com/store/apps/details?id=com.grilledmon...
And I think this affected more than Nexus devices, HTC One gets mentioned in the app description.
https://play.google.com/store/apps/details?id=com.grilledmon...
And I think this affected more than Nexus devices, HTC One gets mentioned in the app description.
They could, but I seem to recall issuing TRIM commands can brick the onboard eMMC Flash chip on some Samsung devices.
This is an interesting move on Google's part. It is a lot more mature (from the perspective of running a software business) to have this level of control over your destiny. It is also another step away from the engineering driven focus toward the business goals focus. One of the more difficult things to do is have the conversation why something is correct for the business, even if it is an inferior engineering solution. I hope they manage that transition well.
The other part of this story seems to be that if you move to this as your "api" then you can move the underlying OS tech to something else as well. (away from Linux to something perhaps smaller for a budget phone.) Should be easier than it was for Microsoft to move everyone to the WinAPI and off DOS.
The other part of this story seems to be that if you move to this as your "api" then you can move the underlying OS tech to something else as well. (away from Linux to something perhaps smaller for a budget phone.) Should be easier than it was for Microsoft to move everyone to the WinAPI and off DOS.
Hackers need to do something about the big companies abusing the app store system. Google, Apple, Amazon are taking far too much fees from independent developers.
- Apple's store especially needs to be killed fast for innovation to thrive, Apple is turning out to be the new Microsoft, Tim Cook should fear the wrath of developers
- and Google needs to be reminded that it's business could swiftly vanish if it isn't pro-developer and pro-consumer, a 30 percent cut for what amounts to hosting a file is way too much.
- Apple's store especially needs to be killed fast for innovation to thrive, Apple is turning out to be the new Microsoft, Tim Cook should fear the wrath of developers
- and Google needs to be reminded that it's business could swiftly vanish if it isn't pro-developer and pro-consumer, a 30 percent cut for what amounts to hosting a file is way too much.
Hosting a file
+ handling payments (in all major currencies)
+ providing worldwide visibility via search and app categories
Those last two are pretty big, if you ask me.
Those last two are pretty big, if you ask me.
"It has its own silent, automatic update mechanism that the user has no control over. In fact, most of the time the user never even knows an update has happened."
Great. So, if it was difficult to trust your phone/tablet/tv before it is now impossible. I'm looking more forward to Ubuntu and FirefoxOS than ever before - I want to be able to control what software runs on my devices!
Great. So, if it was difficult to trust your phone/tablet/tv before it is now impossible. I'm looking more forward to Ubuntu and FirefoxOS than ever before - I want to be able to control what software runs on my devices!
Yeah. You and the thirty other people (minor exaggeration) who reads this page might want to but perhaps even among them there are a few who can't care less. The general public? You know that well.
I don't understand what the all negativity over these changes is about. Has a significant amount of mainstream Android features being incorporated into play been from the ecosystem, rather than Google? If so, I can see how this could result in a worse end-user experience. But if not, how does providing timely updates and a less fragmented ecosystem such a horrible outcome? Feel free to enlighten me if I'm missing something.
I'm sorry but this makes it sound like Google has come up with this magic way of beating fragmentation. It shouldn't have happened in the first place.
Contrast this with iOS upgrade path or what webOS had been doing. Seamless (for the most part) and a great UX.
Google is able to do this; see Chrome. What is strange is why they did not adopt the same strategy for Android as for Chrome.
Contrast this with iOS upgrade path or what webOS had been doing. Seamless (for the most part) and a great UX.
Google is able to do this; see Chrome. What is strange is why they did not adopt the same strategy for Android as for Chrome.
Easier said than done. Microsoft tried to beat fragmentation in Windows Phone by mandating a specific hardware spec, and even they have had huge issues getting manufacturers to clear updates in time, and they won't even let you update to the new major version.
The elephant in the room here is security.
A lot of security updates can be pushed out for the apps and Play Services. However, the underlying OS still needs regular, frequent updates to stay secure, and that's just not happening for the vast majority of Android devices. Who needs 0-day exploits when you have millions of Android devices out there that are vulnerable to exploits that are one, two, or even three years old!?
A lot of security updates can be pushed out for the apps and Play Services. However, the underlying OS still needs regular, frequent updates to stay secure, and that's just not happening for the vast majority of Android devices. Who needs 0-day exploits when you have millions of Android devices out there that are vulnerable to exploits that are one, two, or even three years old!?
Google/Android really can't win now that this "fragmentation" frame has stuck.
Google's been updating core parts of the system like this from day one. The Android Market/Play Store, Maps, Youtube and many other things have received massive updates and been pushed out to millions of people. However, the dominant storyline at the time was that "Android devices don't get upgrades, because fragmentation".
Then suddenly, for no obvious reason, the tech bloggers all noticed at once that this was happening (possibly because they had started actually using Android?) and it was portrayed as sudden U-turn by Google. A weapon in their "war" against Samsung (don't get me started on that one).
Google's been updating core parts of the system like this from day one. The Android Market/Play Store, Maps, Youtube and many other things have received massive updates and been pushed out to millions of people. However, the dominant storyline at the time was that "Android devices don't get upgrades, because fragmentation".
Then suddenly, for no obvious reason, the tech bloggers all noticed at once that this was happening (possibly because they had started actually using Android?) and it was portrayed as sudden U-turn by Google. A weapon in their "war" against Samsung (don't get me started on that one).
Who cares about the tech bloggers? Android customers don't care about fragmentation. They care about having working apps. Developers care about fragmentation, and this approach (unlike updating Youtube in this way) helps with their problem, regardless of what bloggers say and who is in a "war" with whom.
They've always had working apps. My whole point is that nothing in reality has changed. That's why I'm focussing on what bloggers say, because that's the only thing that is different.
A closed source app that can update itself without notifying the user, and has full permissions? How is this any different from the 'loss of control' to American institutes, like the Windows 8.1 / TPM 2.0 warning from the German government. Isn't this exactly the same thing?
I've not tried to, but Android surfaces an option to disable Play Services.
Some services are totally unreliable, for example the Geocoder service.
This sounds like Microsoft .net Framework all over again.
Only boring updates in 4.3? Have you seen app ops [1] functionality? Hands down the greatest thing to happen to a mobile OS in a long time. I know there's Xprivacy, but having this thing built in is awesome.
[1] http://www.androidpolice.com/2013/07/25/app-ops-android-4-3s...
[1] http://www.androidpolice.com/2013/07/25/app-ops-android-4-3s...
The author of this Ars article is the same person as the author of that androidpolice article discovering app ops. so yes, i'm pretty sure he's heard of them.
App Ops aren't in android 4.3 though. it's not a released feature, it's just a development experiment that never got fully disabled prior to release.
App Ops aren't in android 4.3 though. it's not a released feature, it's just a development experiment that never got fully disabled prior to release.
It seems that this article doesn't really separate between user concerns (having the latest google apps) and developper concerns (access to latest APIs).
From what I understand, this means developpers will be able to rely on android "services" being updated more often and more consistently available.
However, what about things like using new UI components ? For this, you still need the latest OS version, right ? If that's the case, then maybe this would mean users caring even LESS about updating their OS, and thus an even worst situation.
i suppose Google thought about it, so there's probably something false in my statement, could anyone confirm ?
From what I understand, this means developpers will be able to rely on android "services" being updated more often and more consistently available.
However, what about things like using new UI components ? For this, you still need the latest OS version, right ? If that's the case, then maybe this would mean users caring even LESS about updating their OS, and thus an even worst situation.
i suppose Google thought about it, so there's probably something false in my statement, could anyone confirm ?
Well it already happened before, with the tabs and other UI components, the solution is a third party library that implements the new UI components in older OS versions, google itself has released backward compatilibity libraries to support new APIs in older OS versions.
One problem is the article specifically states that API updates will still be tied to OS updates. I know different people have different concepts of fragmentation, but to me the key was the un-updated 2.2 device didn't have the API to support newer apps.
Unlike Apple, where the iOS landscape is 100% consistent (minus physical hardware variations) Android is a mess. Before going to town on Google for "closing" the operating system, let's at least look at the problem they are trying to solve and how this attempt - I'm not saying it's correct, or good - addresses those issues.