Google Targets Android Fragmentation With Updated Terms For SDK 154
A reader writes "Google has expanded its legal agreement with developers working on Android applications to specifically prohibit them from taking any action that could lead to a fragmentation of the operating system. The prohibition was added to the terms and conditions for Google's Android SDK (software development kit), which developers must accept before using the software to build Android apps. The previous version of the terms of service, published in April 2009, didn't address the issue, but the new terms published on Tuesday include this new paragraph: 'You agree that you will not take any actions that may cause or result in the fragmentation of Android, including but not limited to distributing, participating in the creation of, or promoting in any way a software development kit derived from the SDK.' Google did not respond to several requests for comment. The issue of Android fragmentation has been gaining increased attention, but it's happened largely as a result of actions taken by Google and Android handset makers, not developers. It's a problem because it means that Android applications may not run properly across all Android devices. 'It continues to be a problem, both on smartphones and tablets,' said Avi Greengart, research director at Consumer Devices. 'Google has talked about multiple initiatives for dealing with it, but none of them have successfully addressed it.'"
Why didn't I think of that? (Score:5, Funny)
Of course, the obvious solution to Android fragmentation is an updated EULA! That will fix everything!
Re: (Score:2)
Managing access rights to the address book, camera, gps and other more interesting parts (like sending sms) of the system will be fixed next week.
Re:Why didn't I think of that? (Score:4, Insightful)
This isn't an attack on fragmentation. This is an attack on Amazon.
Google is furious that people are able to take the "open" Android source and release their own non-Google-approved devices. Even worse, those non-Google devices are more popular than the Google approved ones!
No SDK forks? (Score:3)
Wouldn't that prohibit forking? If so, they can't claim it's open source.
Re:No SDK forks? (Score:5, Informative)
Being allowed to fork and being allowed to call your fork "Android" are different things.
Re: (Score:2)
In other news, RIM just renamed one [blackberry.com] of its Blackberry10 SDKs to LittleGreenRobotWithTwoAntennas Development Kit (LDK).
Re: (Score:3)
The GPL applies to gcc if it is bundled with the SDK, but mere bundling -- also known as aggregation -- doesn't cause the GPL to infect other software that it is bundled with.
Re: (Score:2)
but mere bundling -- also known as aggregation -- doesn't cause the GPL to infect other software that it is bundled with.
It depends on the distinction between "mere aggregation" and "as part of a whole". Those phrases are straight from GPLv2. The former doesn't apply GPL to every part, while the latter does. If the GPL piece serves a useful function for the distribution, and the distribution can be considered as a whole work, then the GPL applies.
That said, I don't know what is GPL and what isn't in the Android SDK bundle.
Re: (Score:2)
It depends on the distinction between "mere aggregation" and "as part of a whole".
It's not mere aggregation; the components of the ADT are complementary, and are integrated.
Re: (Score:2)
Re: (Score:2)
IIRC, it's also about how the software is connected.
What counts is what you distribute and the nature of the distribution. If you are creating a greater work based on a GPL program, and distribute that GPL program as part of the work, then the GPL clearly applies. This is exactly what the license was written for.
If GPL'd libraries are linked, then the software that links to the library has to be GPL'd [..] However, if the GPL'd software is a separate executable, it's much less certain
This is a common myth not based on the text of the license. The GPLv2 wisely doesn't specify that linking is the only way to create something "as part of a whole".
(and many would argue that any software can make a process call to GPL'd software without breaking the license)
If you aren't distributing the GPL software as part of yours, then I would agree. It's
Re: (Score:2)
They're not suing you for use of gcc, they're suing you because you downloaded a package full of proprietary software that happened to include gcc.
However, nothing stops you from using the gcc in the SDK or downloading it some other way, as long as you don't make use of the Android specific stuff. If all they are doing is providing gcc as-is to compile with, but not linking in GPL'ed code, then the GPL doesn't apply to their own code, which they can license any way they want.
Of course, they do still have t
Re: (Score:2)
No, sorry, you're missing the point. One of the core features of the GPL is that you can't ask anyone downstream to waive their GPL rights. This EULA doesn't just say "you can't use this SDK to fragment the Android platform," it says "if you ever want to use this SDK, you can't fragment this platform either with the SDK or without it."
Yes, the grandfathered clauses say you have the usual rights to the code, but the SDK EULA limits what you can do with it -- hence it's a GPL violation.
Google should be usin
Re:No SDK forks? (Score:4)
Re: (Score:2)
It would prohibit forking the SDK.
Did they ever claim that the SDK is open source? They certainly claim that the code that is part of the AOSP is open source, but that's the unbranded version of the OS, which is neither Android nor the Android SDK.
Re: (Score:2)
It would prohibit forking the SDK.
Not exactly -- it appears to prohibit users of the SDK from forking the platform by any means "including but not limited to" building stuff with the SDK.
Re: (Score:2)
You can fork Android (the FLOSS proyect, not what comes on your phone that usually has aditional software), but not it's SDK.
While Android (or parts of it) are free, the SDK is not (and yes, this does go a bit against the principles of open source software).
Re: (Score:2)
sure? the last time I read you can do a "make sdk", I remember that I built and emulator, not sure if there are other parts not open source, Eclipse ADT tools are there in sdk/eclipse source directory
Re: (Score:2)
The Android open source proyect and what comes pre-installed on your phone are different thing. There's plenty of stuff that's part of Android that's not open source. IIRC, the chat program, market, and maps are included in this category.
The same applies for the SDK, the binaries they provide include extra stuff that's not FLOSS.
Re: (Score:2)
and we are talking about an SDK, and SDK is not a phone, this is a license over the SDK, not a phone, the SDK (at least the emulator and eclipse plugins are open source the last time I checked). I can use the SDK without a phone. Don't confuse proprietary applications and drivers on a phone and an emulator
I can build my own emulator and emulator image without any of the Google APIs binaries added on the ready to use SDK. So for me the Android SDK is open, the Google libraries added on top of the SDK aren't
Re: (Score:2)
Wouldn't that prohibit forking? If so, they can't claim it's open source.
Indeed. The actual SDK has a EULA; it's not Open source, even though Android itself is.
Re: (Score:3)
I think that applies to the binary SDK, if you go and download sources and build your own SDK you don't need to accept that license, so in my opinion Google is telling Android forkers, go and build your own SDK and don't promote our official SDK as the one for your platform. In other words, Amazon, Baidu and others, do your own work and stop using the binary Android SDK and for the Android developers, stop using the official SDK to distribute your applications on Android forks, go and use their SDK
How will a license agreement solve fragmentation? (Score:2)
Re:How will a license agreement solve fragmentatio (Score:4, Insightful)
Yes, but this is almost certainly just a shot at Amazon (and a preemptive shot at Samsung). It doesn't do anything to address the real fragmentation problem: hardware and other issues causing manufacturers to abandon OS updates a few months after launching phones
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Which I believe is the point. As long as your stuff will work on regular mainstream Android you're fine. This gives an incentive for actors like Amazon, RIM and so on to kep their stuff fully compatible.
Re: (Score:2)
Re: (Score:2)
It limits the use of the SDK in the process of creating non-Android-branded Android-like OS's, which is one aspect of fragmentation.
Google more aggressively pursuing and releasing updates for Google-branded (e.g., Nexus) devices would, for example, be a means of creating pressure on other Android device makers to be better at updating devices and reducing that aspect of fragmentation. (Which is, though, less of a problem for
Re: (Score:2)
Apple has the new two year contract (optionally now), but updates the iPhones for at least a few years for each model.
Re: (Score:2)
Re: (Score:2)
Android is open right? (Score:2)
Buuuuuuut, if Android is open, of course people are free to fork it, expand it, trim it, and do whatever they want with it. Any action which restricts our ability to do that is... well... wrong.
If they wanted there to be a clear winner, they should just you know, pick one and publicly say "HERE. THIS ONE. THIS GUY RIGHT HERE. HE'S HAS JUST WON THE INTERNET AND HIS VERSION OF THE ANDROI
fragmentation not due to developers (Score:2)
The fragmentation problem is because there are so many different versions of Android still out there, with different screen sizes, hardware capabilities, sensor availability, etc.
I don't really see how this is going to change much.
Re: (Score:3)
I am not exaggerating when I say this is one of the best phones I ever had(before that I had a Nokia E61...it ran DoTT!) and nobdy seems to want to build something similar. I keep it in my trouser pocket together with a menacing set of keys and all the lint I can find. It as shielded my valuable, precious testicles from team
Defy can run Jelly Bean, no need to replace it (Score:3)
Uhhh... I have a Defy as well (Defy+ actually but the difference is negligible). It runs Jelly Bean (4.1.2) [xda-developers.com]. There is now an early demo of Jelly Bean 4.2, the version just launched with the new Nexus 4 and Nexus 10.
You don't need to replace your Defy. Just root it if you haven't already, and install one of the many available roms on it - everything from Gingerbread through ICS and JB 4.1.2. The Defy is actually a good example of how futile those locked boot loaders and restricted systems really are: the lat
Re: (Score:2)
The interesting thing is that the availability of up-to-date Android releases is being pushed by the community. That should be a way out of the fragmentation issue. At least on the OS side of things.
Android hardware still is highly diverse. Which IMHO is a good thing.
But Google Play seems to limit software compatibility checks to screen size and OS ve
Re: (Score:2)
Motorola Defy XT and Defy+ are Android 2.3
Sony has a rugged phone called the Xperia go with Android 4.0. I personally didn't buy an Xperia because I hate Sony.
Re: (Score:2)
Re: (Score:2)
I am not exaggerating when I say this is one of the best phones I ever had
that's an amazing feat no doubt. so why are you begging them to change it? seriously, you sound like the type of person that values function over fashion. get over the fact that your version is two numbers lower than newer phones, and be happy with your "best phone ever".
Re: (Score:2)
Cyanogen mod it is. Never liked MotoBlur anyway. Over 2 years I couldn't really see the benefits of it.
Re: (Score:2)
My phone needs to be a no-fuss affair, lint tolerant, not have problems with pointy stuff and serve as a wirless hotspot for my tablet. Since LTE still is a bit of a non-event at this time I will wait until next year.
Spent some time on xa-developers and the 4.1 port to Defy thread is already 1200 pages long. With 4.2 in the works. So I'm not alone with my love of this thing.
Re: (Score:2)
fragmentation is due to developers. A lot of the developers don't know how to handle different devices. It's not really that hard, but you know how Noobs are.
Fragmentation is an issue in two forms. OS version, and Cell phone fragmentation.
OS version is pretty easy. Just list min requirements and detect if the device meets them when your app starts.
Phone fragmentation is harder, in that 2 phones could be running 4.1 but one manufacture may have shut down a particular feature. Essentially creating a fork with
Re: (Score:2)
and, this article and the new terms of the agreement have nothing to do with that problem.
but its Java? (Score:2)
what happened to the write-once, run anywhere concept?
See, if Google made Android as part OS features, part Java API, then you could run an updated app against an old phone and the new features you expect to be present would simply not work - it'd throw an exception at runtime if the user attempted to use the missing API call (assuming the dev didn't look for and hide that option).
Android fragmentation isn't any more of a problem than the existing problem of having lots of phones running different stock And
Re: (Score:3)
Apps can be written to use new features where available but degrade gracefully where they're not.
Every app has both a "minimum SDK version" that identifies which version of Android it requires, and a "target SDK version" that identifies the latest version of Android that it knows about. At runtime, the app can check which version it's actually running on, and enable or disable features as appropriate.
If an app is is run on an Android version newer than the app's "target", the OS itself will do whatever's n
Re: (Score:2)
Yes, that's all possible. But it's also a lot of extra work.
Re: (Score:2)
Apps can be written to do that, but mist app writers don't really know what they are doing.
OSS (Score:2)
Re: (Score:2)
Anyone with more insight care to comment?
Why (Score:5, Funny)
Why does fragmentation matter on Android devices? They all use Flash RAM drives, so its not spending time seeking like the old physical hard drives
Re: (Score:2)
Sequential reads and writes are still faster than random. Particularly on cheap flash drives.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
And you handle it like Windows applications do:
Min requirement
OS 4.0.4
Yeah, a game developed for phones released today don't work on something that's 2 years old. shocking.
Virgin is still selling 2.x handsets (Score:2)
Re: (Score:2)
The Biggest Market Share (Score:2)
Haha... maybe that's why Android's market share has increase. People need to by multiple phones for different apps.
Maybe fragmentation isn't so bad after all.
Is this targeting Amazon? (Score:2)
I thought the Fire was basically a forked version of Android. So this would seem to say, if you want to publish with Google you could not also publish for Amazon.
Perhaps I am misreading this, but it seems like the only way it could actually have an effect on fragmentation.
Re: (Score:2)
I thought the Fire was basically a forked version of Android. So this would seem to say, if you want to publish with Google you could not also publish for Amazon.
no. kindle is 100% android so it runs all android apps (theoretically).
this just says that android devices must come with the android SDK- amazon can't take the android SDK and modify it into something else such that apps written to the kindle SDK won't run on other pure android devices.
note that it doesn't prevent amazon from create a kindle SDK that sits on top of the android SDK.
think back to the old MSFT - Sun lawsuit where MSFT took the Java SDK and created J++.
Fire is not "100% Android" (Score:2)
no. kindle is 100% android so it runs all android apps (theoretically).
Just because it runs all Android apps does not mean it is not a modified version of Android. It has for example a very revised home screen, and a whole different app store.
What if you wanted to write an Android app that modified the Fire home screen when present? That would seem to be against the new Google TOS.
Unfortunately for Amazon... (Score:3)
... Google failed to appreciate how popular its new terms would be, and sold out in less than an hour, so it will take 3 more weeks until the next shipment of terms arrives.
I pity Amazon, having to wait 3 more weeks for terms.
[No, not bitter at all about being backordered, why do you ask...]
I like Android..but (Score:2)
I like android devices. I like to be able to just drag any music or file over from any computer.
I like that it gets a lot of tech before the iPhone
I like that I can switch to a different manufacture and have it largely be the same. Some manufactures may radically change it, but that's rare.
Clearly, not an Android haters.
However there is a problem.
I got the Nexus S at best buy. And I got the replacement warranty.
After a year I dropped my phone and broke it. My fault.
So I take it to best buy for a replacement
No SNI on Android 2.x (Score:2)
Cyanogen and others? (Score:2)
In conclusion, open (Score:2)
Where "openness" is "doing only what Google says you're allowed to do"
I have the answer that will solve it overnight... (Score:5, Insightful)
You cant call it android unless it is the current version or the previous version. Anything older can NOT be called or branded android in any way.
Suddenly the Lazy bums at HTC and Sony will actually use the latest OS for their phones and push out updates.
Re: (Score:2)
Samsung took quite a while to upgrade to their version ICS. ICS was released in october 2011, it didn't come to the note or skyrocket until July 2012. Which is weird, because they seemed to have done very little aside from changing the graphics. They broke "unauthorized" tethering, maybe that counts as a feature. I guess they figured everyone who would bother upgrading had already installed cyanogenmod.
Re: (Score:2)
"Is there ANYONE that pushes updates in a reasonable manner?"
Yes, My Nexus HSPA+, my new Nexus 4, and My Nexus 7 get updates instantly.
Great job, Google! (Score:2)
Now all you need to do is follow up on your "swift updates for all devices" promise from 18 months ago [arstechnica.com] and we'll be all set!
Re: (Score:2)
Only New to Developers (Score:3)
That's actually part of the Open Handset Alliance agreement, and has been from the get-go. Carriers can change things to an extent, but can't mess with the APIs... all Android devices are supposed to be compatible at the app level. And they largely are -- the fragmentation thing has been blown way out of proportion, mostly by Apple fans as they ran out of other arguments as to why their iOS wasn't better than Android.
There are two problems Google needs to address. One is the initial OS in a device: you have had developers releasing devices on 2.2 even, well after Android 4.0 was out. Google needs to address that.
The second problem is getting the new OS out in the first place. An ordinary development model for an OS will have early releases available to developers long before the new version ships. This gets them an early start on porting and testing, etc. Google's current M.O. is to select one vendor and one device to work on (usually a Nexus device these days), then work intensely with that partner. The new OS version isn't released to other OEMs until that new device ships. This is a big delay in getting the new OS adopted. And it results in far less testing than would otherwise take place. Maybe this is needed for Google's two-release-per-year schedule to be kept, but that, too, is part of the reason new devices don't always have new OSs.
There are a few things Google could do. Ideally, they could re-engineer the basis of Android, and build a hardware abstraction layer under Linux. Android/Linux would have class-drivers (display, touchscreen, keyboard, etc) that hit the vendor-supplies HAL layer. The HAL layer would contain all hardware dependencies, cell phone baseband, etc. This would basically allow any new version of Android to run on any device without the need for the manufacturer or cellular provider (argh!) to be involved. In short, just what PCs do.
Re: (Score:2)
Re:So... (Score:4, Interesting)
Re: (Score:2)
Re: (Score:2)
It doesn't matter who it's targetting, this moves Google firmly out of the "open source" category into "merely visible source". It gives the impression that Google, sensing an opportunity to go far beyond the original goal of just ensuring that the mobile market remains open to advertising by Google, now has its eyes set on exerting monopoly control of the mobile market. With this, it would seem that Google has declared war on open source.
Re: (Score:2)
Re: (Score:2)
OK, true, this is the licensing terms of the SDK, not of the underlying operating system. BUT.... you could still argue that it's against the GPL because of the phrase "including but not limited to". The clause is "you won't fragment the OS, whether or not by using the SDK" -- ie in order to use the SDK you have to forego your rights to modify the OS source code.
Can people sign away that right? Sure -- but by doing so, you're refusing the terms of the GPL... and are no longer allowed to use the GPLed cod
Re: (Score:2)
That sounds a lot like what Sun thought about Java. Then again, Sun failed to execute on a mobile Java-based platform, so Google might have a better chance of making that line of attack work for them.
Re: (Score:2)
That sounds a lot like what Sun thought about Java...
Sun didn't own an advertising empire.
Re:So... (Score:5, Informative)
Letting carriers have more control of the handsets was one of the "ins" that android had.
People have really short memories, and forget how some carriers were infamous for disabling features so they could sell them back to you nickle-and-dime. Ringtones, wallpaper, hell they even liked to charge a premium to get photos off of your device. Verizon was known as "the phone raper". They'd sell devices that were hollow shells of their non-US counterparts.
Apple turned that model completely upside down, taking control away from the carriers. This pretty much started the smart phone boom (as we know it). Because of apple, you're not forced to buy apps through the Verizon store. The iphone is an APPLE device. Not an At&T one. Not a verizon one. Apple correctly puts the carriers in their place as commodity bit fingers and communication infrastructure maintainers. (Which the carriers hate with the fury of a billion suns)
Google was looking to be more flexible and "open". They were also willing to play ball with carriers (to boost market share and adoption) and let them molest the devices to a greater extent. But not completely. Google has a baseline standard that has to be followed. Play by Google's terms or no Google apps for you. There's been some friction over this, mostly by companies that think they can remove google maps and charge a premium rate for another product.
Re: (Score:3)
I'll happily agree that Apple started the smart phone boom as we know it, but it certainly wasn't "they didn't allow carriers to customize/lock-in" that did so.
If anything, while Apple is keeping carriers from locking you into their services (well, mostly. Visual Voicemail was AT&T-only, right? right. Sure that was a collaborative effort, but I'm not sure that doesn't make it worse.) they instead lock you into their services.
Windows Mobile (going a long way back), while letting carriers customize (mos
Re:So... (Score:5, Insightful)
I completely disagree. Carriers are actively customer hostile entities. Everything they touch becomes worse for the end user. The apple phone experience was so good because they didn't let the carriers have their way. It's why Verizon turned down apple for so long. It took Steve Job's massive reality distorting balls to to convince At&t to try it their way. Bam. Smart phone boom.
Just look at Europe, where the GSM standard mandated interoperability. Customers were free to use whatever device they wanted just by slipping in a sim, and they picked devices that weren't carrier crippled. The mobile market there boomed while it stagnated in the US with our carrier-oriented market.
Now we've got devices with a higher degree of consumer control (Yes, apple's walled garden isn't "open" but it's 1000's of times better than anything verizon ever attempted) and the market is huge.
Re: (Score:2)
If anything, while Apple is keeping carriers from locking you into their services (well, mostly. Visual Voicemail was AT&T-only, right? right. Sure that was a collaborative effort, but I'm not sure that doesn't make it worse.) they instead lock you into their services.
You are right and you are missing the point. If the services come from Apple, then that guarantees that the services will be updated to support the latest features of their newest phones. This stopped the carriers messing with the phone interface for short term commercial gain.
N.B. Visual voicemail is an Apple patented feature. It could be available on any network that wants it working. I guess they have to pay or do some integration though? I guess this article about visual voicemail in Britain [mobileindustryreview.com] show
Re: (Score:2)
Re:This is even worse than a walled garden (Score:4, Interesting)
It doesn't prohibit things like Swype. If they wanted to kill Swype, they could do it in one blow- delete the InputMethodService class in the next version. Without it, no more 3rd party keyboards (source: I worked at Swype). As much as Google seemed to love making me jump through hoops to work around their code, I don't see them doing that anytime soon.
I dislike how vaguely this is worded, but it doesn't block libraries either. What it blocks is people making phone specific SDKs, or taking the SDK and making it compile Android app to non-Android devices. Its meant as a counter to some Chinese OEMs doing just that. The only thing I really see that it blocks that was good are things like the original x86 sdk/ndk that people used before Google finally moved from ARM only.
Re: (Score:2)
I think they are trying to be sure that phones with a specific OS version have all the expected feature from the SDK. So a manufacturer doesn't block a feature, thus making certain apps not work
Re: (Score:2)
Re: (Score:2, Insightful)
tl;dr
An on-topic post really can be overrated with a score of 1, just as it can be on-topic and a troll, or one of the other negative scores aside from off-topic. While I usually use Overrated as a dissenting vote on up-mods (very rarely), I have also used it for a post (base Karma 1) that adds simply nothing to the topic under discussion. I've done that maybe twice in the years I've been here.
I just happen to have mod points again (happens abut every two to three days), but I was not the person that did
Re: (Score:3)
That will show em, AC.
Re: (Score:2)
Re: (Score:2, Funny)
Re: (Score:2)
The dalvik interpreter isn't java. Never claimed to be. It's not a fork either, it merely uses java as its intermediary language for programming.
Re: (Score:2)
What I think this means: Amazon can create their own SDK, fork everything they want, the SDK is on Android source repositories, emulator, eclipse plugins, etc (I don't know if all of it), Developers can use Amazon SDK if they like, but developers can not use the Google SDK binary if they promote other non compatible forks. So if someone build an independent SDK from the sources, this is solved, until Google add rules like this to Google Play
Re: (Score:2)
what makes google so nefarious
do you know what that words means? google doesn't hide the fact that they gather information. it's well known. heck, even you know it.
You give one company that power, for what?
for the massive number of free services they offer? ever heard of google search? when's the last time you dug into your wallet to pay for that service? do you understand how much infrastructure and development resources go into google search? they offer you a product for allowing them to track you. that product is search, email, calendar, google apps on android, and so on. if
Re: (Score:2)
If you aren't the customer, you're the product.
ooooh intense.
yes, everyone knows that. we understand how the advertising world works. we're okay with it.
Yep, almost any company you come across aggregates your data, Google isn't alone in this. They are just the best.
good, and i hope you don't use any of those products or visit and ad-supported websites. or maybe you just like talking the talk?
Re: (Score:2)
UHm so if I wanted to have an android based system for something like controlling my thermostat and give it access to google market, I shouldn't be allowed to because it doesn't have a discrete GPU?!
Umm..... why would you want your thermostat to be supported by the Google Market? Do you want to play Angry Birds every time the temperature rises above 25 degrees C or something...?!?
Re: (Score:2)
Re: (Score:2)
Providers are.
Exactly this... Guess what? If you're a provider, and you use the new SDK, you just agreed not to keep fragmenting Android by preventing upgrades to the newer versions to make new phones more appealing...