Slashdot Mirror
Google Targets Android Fragmentation With Updated Terms For SDK
SternisheFan 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.'"
Of course, the obvious solution to Android fragmentation is an updated EULA! That will fix everything!
Wouldn't that prohibit forking? If so, they can't claim it's open source.
There's no -1 for "I don't get it."
wouldn't updating all phones to the latest android version be a better solution ?
sounds more like it's targeting Acer/Aliyun. Which isn't the kind of fragmentation most people think of but is the kind Google doesn't like.
Do you even lift?
These aren't the 'roids you're looking for.
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.
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
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.
I still have more fans than freaks. WTF is wrong with you people?
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
I love my Motorola Defy. But it still ist stuck with 2.something stuck behind the refusal of T-Mobile to update it which in turn is stuck behind Moto's lack of eagerness to update it.
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 lint and team keys for 2 years by now and still goes on. March on, brave soldier march on.
Today I spent 2 hours searching for something to replace it. Something with more power and a bit more up to date. Oh sure, their were lots of trollops waving their OLEDs and HDs and other D-cups my way. And I have to admit for a moment I was tempted. BUT THERE IS NOTHING COMPARES TO MY DEFY!
Update it!
{insert picture of sadface testicles here}
On related news: Slashdot needs emeddable pictures. I'll even shave and call the Sinéad.
20 minutes into the future
I would have thought that it was targeting OUYA from forking the SDK and bundling it within their console.
A game has objectives and is competitive, anything else is just play
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 needed to be backward-compatible with the target version. The developer can update the app and change the target version in order to take control of any new features and differences.
Uhhh... I have a Defy as well (Defy+ actually but the difference is negligible). It runs Jelly Bean (4.1.2). 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 latest Jelly Bean versions run a custom kernel.
--frank[at]unternet.org
... 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...]
How will this affect the replacement images developed by the user community? I've been running community offshoots of Android for years now and I would hate that ecosystem hit by this.
You don't have to reinvent it poorly. It was invented poorly in the first place.
That will show em, AC.
The Kruger Dunning explains most post on
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 (most didn't - t-mobile in germany, O2 and Orange in UK did but mostly visual tweaks), was easily unlocked if needed and restored to stock, and then tweaked far further than even Android allows now (which can be considered both a good or a bad thing). In addition, there were a plethora of app stores not just from the carriers (with few offerings) but third parties.
It was never a highly popular platform, though - and that's the additional factor that Apple did bring to the table.
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.
Do not look at laser with remaining good eye.
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.
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 shows exactly why Apple need their features to be independent of the mobile carriers.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
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.
-Dave Haynie
i can't say anything about UI improvements on newer HTC devices but i liked the job they did on the HTC desire over the stock. there were lots of small but very useful changes. seems like a long time ago...