Forgot your password?
typodupeerror
Android Cellphones Google Handhelds Operating Systems Programming Technology

Google Targets Android Fragmentation With Updated Terms For SDK 154

Posted by timothy
from the eula-do-what-we-say dept.
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.'"
This discussion has been archived. No new comments can be posted.

Google Targets Android Fragmentation With Updated Terms For SDK

Comments Filter:
  • by Guspaz (556486) on Thursday November 15, 2012 @07:07PM (#41996917)

    Of course, the obvious solution to Android fragmentation is an updated EULA! That will fix everything!

    • by Fuzzums (250400)

      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.

    • by Anonymous Coward on Thursday November 15, 2012 @08:19PM (#41997445)

      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!

  • by MrEricSir (398214) on Thursday November 15, 2012 @07:08PM (#41996923) Homepage

    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

    Wouldn't that prohibit forking? If so, they can't claim it's open source.

    • Re:No SDK forks? (Score:5, Informative)

      by XanC (644172) on Thursday November 15, 2012 @07:10PM (#41996943)

      Being allowed to fork and being allowed to call your fork "Android" are different things.

      • In other news, RIM just renamed one [blackberry.com] of its Blackberry10 SDKs to LittleGreenRobotWithTwoAntennas Development Kit (LDK).

    • Wouldn't that prohibit forking?

      It would prohibit forking the SDK.

      If so, they can't claim it's open source.

      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.

      • Wouldn't that prohibit forking?

        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.

    • 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).

      • by robmv (855035)

        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

        • 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.

          • by robmv (855035)

            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

    • by mysidia (191772)

      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.

  • wouldn't updating all phones to the latest android version be a better solution ?
    • by sangreal66 (740295) on Thursday November 15, 2012 @07:30PM (#41997125)

      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

      • by idontgno (624372)
        THIS [wikipedia.org] is what this SDK EULA change is about. Google wants to throttle unauthorized Android work-alikes in the cradle. It probably sticks in their craws that legally anyone can build an AOSP-based phone, but there isn't much they can do about that. But completely non-Android systems with Android (Dalvik) runtime capability? Hells, no. You have to use the SDK to develop to that environment, so that's where we'll hit it... no SDK for you!
        • by BronsCon (927697)
          Anyone being able to build AOSP-based devices was kind of one of the original points of the OS. You're right about the rest, though.
        • Well technically you could develop for the "real" and "hijacked" android OS's at the same time if the hijacked one really did run regular android apps. You wouldn't have to admit (or even care) what phones you're targeting.
          • by JanneM (7445)

            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.

        • I'm pretty sure you're talking out of your ass. If Google was upset about AOSP-based phones, they could simply cut off the oxygen and end AOSP.

          I have absolutely no idea what the write-up is about. At a guess, I'd assume they're concerned about "cross platform" crap that isn't, but I'll wait for Google to actually state their intentions. What I can absolutely rule out is the notion that this is about Android being FLOSS (Google could end this at any time), or about sticking it to Amazon (the Fire's OS is

    • wouldn't updating all phones to the latest android version be a better solution ?

      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

  • Well, of course the Android has a problem with all the different flavors. Fragmentation is a problem for Google's baby.

    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
  • 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.

    • by bfandreas (603438)
      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
      • 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

        • by bfandreas (603438)
          Yep, found it just yesterday. The 4.1.2 port thread skyrocketed to 1200 pages over the course of a few months. So I'm not alone with my love of this thing.

          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
      • Plain old Defy is Android 2.2 - I got one with CyanogenMod 7.2 which gives it Android 2.3
        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.
        • by bfandreas (603438)
          I am Motorola-ambivalent. I also have a Xoom which I am preparing for my mother. It was the first Honyecomb tablet. And the first Tegra2 tablet. And yet Moto ports Jelly Bean for this thing. OTOH they had taken their own sweet time with other updates and I had a feeling they abandon their hardware after one year. Nice tablet, tho. A bit on the chunky side but apart from that it is quite nice.
      • 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".

        • by bfandreas (603438)
          I'm a neat little geekoid and I see no reason why I should run outdated software.

          Cyanogen mod it is. Never liked MotoBlur anyway. Over 2 years I couldn't really see the benefits of it.
    • by geekoid (135745)

      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

    • and, this article and the new terms of the agreement have nothing to do with that problem.

  • 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

    • by Wyzard (110714)

      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

    • by s73v3r (963317)

      Yes, that's all possible. But it's also a lot of extra work.

    • by geekoid (135745)

      Apps can be written to do that, but mist app writers don't really know what they are doing.

  • by fermion (181285)
    I thought android was OSS and as such the code was available. What is to keep people from using the old libraries, developing them as they wish, and then just interfacing with what other tools they need?
    • by p0p0 (1841106)
      I the device drivers for a specific hardware configuration aren't OSS and therefore it's incredibly difficult to build from source specifically for your device. I have a limited understanding but I believe it is something along those lines.

      Anyone with more insight care to comment?
  • Why (Score:5, Funny)

    by rossdee (243626) on Thursday November 15, 2012 @07:34PM (#41997161)

    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

    • by 0123456 (636235)

      Sequential reads and writes are still faster than random. Particularly on cheap flash drives.

  • 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.

  • 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.

    • 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++.

      • 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.

  • by MetricT (128876) on Thursday November 15, 2012 @08:24PM (#41997469) Homepage

    ... 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 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

  • 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.
  • Where "openness" is "doing only what Google says you're allowed to do"

  • by Lumpy (12016) on Thursday November 15, 2012 @09:16PM (#41997807) Homepage

    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.

    • Just HTC and sony? Is there ANYONE that pushes updates in a reasonable manner?

      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.
      • by Lumpy (12016)

        "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.

  • 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!

    • by Psyborgue (699890)
      Yeah. Carriers and manufacturers suck, but if you buy a Nexus device, you're set for a good few years.
  • by hazydave (96747) on Friday November 16, 2012 @03:33AM (#41999415)

    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.

Real Programmers don't write in PL/I. PL/I is for programmers who can't decide whether to write in COBOL or FORTRAN.

Working...