Forgot your password?
typodupeerror
Operating Systems Cellphones Google Handhelds Linux

Fragmentation vs. Obsolescence In the Android Ecosphere 315

Posted by timothy
from the can't-do-what-you-can't-do dept.
whisper_jeff writes "Engadget has an interesting article up discussing whether or not Android is fragmenting. While the article discusses the concept that it may be more about handsets becoming obsolete at a dramatic pace rather than the OS fragmenting, it also begins by noting that there are currently five different versions of Android on the market, which implies there is a notable degree of fragmentation. Regardless of it being fragmentation or handsets becoming obsolete to new feature sets in a terribly short period of time, I believe this development cycle could turn casual consumers away and hurt Android's chances for long-term mainstream success."
This discussion has been archived. No new comments can be posted.

Fragmentation vs. Obsolescence In the Android Ecosphere

Comments Filter:
  • by EmperorOfCanada (1332175) on Sunday May 23, 2010 @07:43PM (#32318174)
    As an iPhone developer who would love to make the jump to include android I am very scared about the large mishmash of versions and hardware. Talk about a testing nightmare. Simulator testing is great but as we all know nothing beats the real thing. I don't feel like buying enough handsets to cover my desk.
    I wouldn't be able to keep all the chargers straight anyway.
    • I don't feel like buying enough handsets to cover my desk.

      I wouldn't be able to keep all the chargers straight anyway.

      Just get a used vending machine, put each phone into a 'slot', attach the charger cord with a loose zip-tie and you're all set. Heck, if you set them each to cost $1 you'll save up enough for the next handset in no time ;-)

    • by Superken7 (893292) on Sunday May 23, 2010 @07:54PM (#32318270) Journal

      Actually, you can build with a modern SDK while having a minSDK attribute set to 3 (android 1.5) so your app will be compatible with android >=1.5 (99.9% android phones are 1.5 or newer), and on 1.5 you can have access to so many things, it will be difficult to really have a need of doing something which is not possible.
      Live wallpapers and maybe some advanced graphic functions will not be available, and the hardware of those "legacy" devices won't be able to handle that, anyways.

      So there are only a few things left which are not possible, like account manager integration, the cool Log.wtf() function and a few more, but nothing extremely important, I'd say...

      • Re: (Score:3, Informative)

        by Trepidity (597)

        There's hardware heterogeneity issues also, though: some phones have multitouch and some don't, for example, and the processor speeds and screen sizes are different. Even for devices with the same sensors, the sensors can behave differently, e.g. what kind of control over the camera you have and what data it feeds you, and what the accelerometer's characteristics are.

        Doesn't matter for a decent number of apps, but matters for, say, mobile games.

        • by Cyblob (800812) on Sunday May 23, 2010 @08:13PM (#32318408)
          You can specify the hardware and software requirements of your app in the manifest file and it will not show up in the market for devices which do not meet the requirements.

          You can be incredibly specific. If you app requires an auto-focus camera then you can specify that and it will only show up for phones which have one.
          • by ducomputergeek (595742) on Sunday May 23, 2010 @10:07PM (#32319168)

            And then one person with Android A can download it and tells their friend with Android B about it. Android B user goes to the market place and can't find or download that app and gets pissed off. It happens more than you'd think with a friend of mine. He has an HTC, his wife a motorola with the keyboard so she can send 500 texts a day. They've come across several apps that will work on his phone, but she can't even find it in the market place.

            As a developer, we're charging 4 - 5x's the price for an android app vs. an iPhone App. Reason being that Android is more expensive to develop for due to the number of phones on the market all with different OS & hardware specs. Since august of last year, we've spent over $6k now on Android and sets. To give you an idea, we spent $2500 from 2008 - present for iPhones and iPod touches.

            • by stephanruby (542433) on Monday May 24, 2010 @01:03AM (#32320116)

              He has an HTC, his wife a motorola with the keyboard so she can send 500 texts a day. They've come across several apps that will work on his phone, but she can't even find it in the market place.

              She should try again. From the sound of your post, it sounds like you're located in the US, and she has the Motorola Droid. That means her phone was upgraded to 2.1 a couple of weeks ago, and will probably get the 2.2 very soon.

              And anyway, there isn't really a big difference between 1.6 and 2.2. 1.5, yes. And anything below 1.5, no one is using anyway. And unlike the iPhone, which is changing its complete underlying architecture as we speak, the Android SDKs on the other hand are stabilizing, for instance Froyo is even being delivered six months ahead of schedule, and there are less and less changes that developers are clamoring for.

              And when I can't find an app that someone recommended to me, that's usually because many apps that were free a few weeks/months ago have transitioned to fully paid apps (and the developer has removed the free/lite version off the market as a way to get more sales, since he already has the word of mouth going for him, and the people that miss the free app can't leave new comments anymore -- unless they pay for the app at least once).

              As a developer, we're charging 4 - 5x's the price for an android app vs. an iPhone App.

              Hey, charge whatever the market can bear, that's what I say. Currently, there seems to be a big shortage of Android Developers on most job sites. So please, charge away. It's a good way to weed out the overflow of clients. And right now at least, taking on clients that want to commission an Android App is much more lucrative than making your own app (later on, that will probably be the reverse situation, but I'm only speaking of right now).

              Since august of last year, we've spent over $6k now on Android and sets. To give you an idea, we spent $2500 from 2008 - present for iPhones and iPod touches.

              This misses the point that you can only develop for the iPhone/iPad only if you're on a Mac (for the most part). And that's fine if you already have all the Mac equipment you need, but for many of us still, we still have Windows machines or Linux machines, so the barrier to entry is much lower on Android (not to mention the registration fee to be able to develop on the Market as opposed to the App Store).

              Also your entire testing strategy should be based on the type of Mobile Application you're making. For some applications, testing for every variation makes complete sense, for instance, if your application depends on the camera, it makes sense, for others, it simply doesn't. Besides, developers are organizing to share testing devices among themselves. Some companies are crowdsourcing testing and QA. And if you're near a Google office, and go to some of their events, you can usually check out devices from them free of charge. So if I were you, I'd hold off on buying the 39+ Android phones or the 50+ different Android devices that will be available this summer, and depending on the type of Application I was making, I'd give my client an itemized list of prices for the different SDKs that are out there, and let the client decide on the cut off point, on the type of support he wants to have, or not have.

        • Re: (Score:3, Interesting)

          by Simon Brooke (45012)

          There's hardware heterogeneity issues also, though: some phones have multitouch and some don't, for example, and the processor speeds and screen sizes are different. Even for devices with the same sensors, the sensors can behave differently, e.g. what kind of control over the camera you have and what data it feeds you, and what the accelerometer's characteristics are.

          Doesn't matter for a decent number of apps, but matters for, say, mobile games.

          This is mistaken, actually. They all have hardware multitouch, some don't have software multitouch enabled for legal reasons. But as people upgrade to newer versions of the OS, the multitouch magically appears! Also, as the virtual machine has got considerably faster, my original G1 is now much more performant than it was when new, and thanks to the nice folk at Cyanogen it already runs Eclair and will soon run FroYo. Yes, there probably are differences in the actual physical characteristics of things like

    • by mjwx (966435) on Sunday May 23, 2010 @08:27PM (#32318514)

      As an iPhone developer who would love to make the jump to include android I am very scared about the large mishmash of versions and hardware.

      Dont be.

      Fragmentation is mainly FUD. Android applications operate via the Dalvik virtual machine meaning the vast majority of applications will happily run on almost all hardware. Only when you start writing applications that require access to a version specific API does this become a problem, most of Android's API's are version agnostic. The simpler your application the fewer issues you will have with it, the so called "issue" of fragmentation is only true for the most complex of applications, if you are writing a simple XML parser then you wont have a problem.

      • Re: (Score:3, Insightful)

        by sortius_nod (1080919)

        The simpler your application the fewer issues you will have with it, the so called "issue" of fragmentation is only true for the most complex of applications, if you are writing a simple XML parser then you wont have a problem.

        I think this is the whole point of the fear. When you invest in creating a complex app you want to know it's going to work for everyone. There's an inherently higher risk involved with developing for a platform with such varied hardware & software.

        Saying that the fragmentation isn't an issue is glossing over the problem. Kind of like saying there's not fragmentation in desktop computers because you can run flash apps the same across different operating systems. Not every app developed is a fart soundboa

        • by salesgeek (263995) on Sunday May 23, 2010 @11:50PM (#32319762) Homepage

          Fragmentation is a non issue. Don't target the latest version, and life is good. Target the latest version and your market shrinks. It's not that hard. Oh, and anyone who says you have to buy a bunch of phones doesn't know how Java works.

          • Re: (Score:3, Insightful)

            by batkiwi (137781)

            Anyone who says you DON'T have to buy a bunch of phones doesn't know how development works.

            Yes we know it will technically run. But considering screen size/resolution/layout/keyboard (or not)/etc differences you really need to test your app on each representative phone. While not EVERY phone is necessary, you'd need at least 4-5 to cover the combinations.

            • by ppanon (16583) on Monday May 24, 2010 @04:26AM (#32320988) Homepage Journal
              Do you seriously think all PC developers buy 15", 17", 19", 21" and 24" monitors just to test their apps at different resolutions? Or every single graphics card made in the last 10 years by nVidia, ATI, and Intel? Maybe a few specialty app developers like Adobe and AutoCAD buy a representative set, but for most apps it just doesn't make enough difference to matter. If a device is sufficiently different from the norm in the market that a whole bunch of apps break on it, that device will be the one with the bad reputation, not all the apps that fail to run on it. Yes, it may be a bit of a support headache until that device's flaws become apparent to everyone, so take account of that in your cost model and charge accordingly. At least that's within your control, as opposed to iPhone App Market approval.
              • Re: (Score:3, Informative)

                by Builder (103701)

                That's completely different. On a computer, it's acceptable to have an application running in windowed mode and not taking up the whole of the screen. That is incredibly uncommon on a mobile platform - all apps are expected to use the whole of the screen. This very simple fact alone alters development considerably.

      • Re: (Score:2, Insightful)

        by DerekLyons (302214)

        Fragmentation is mainly FUD. Android applications operate via the Dalvik virtual machine meaning the vast majority of applications will happily run on almost all hardware. Only when you start writing applications that require access to a version specific API does this become a problem, most of Android's API's are version agnostic.

        "Mostly FUD", "the vast majority", "most API's"... In other words, there is truth to the claims of problems caused by fragmentation.

        The simpler your application the fewer

        • by mjwx (966435) on Monday May 24, 2010 @01:13AM (#32320174)

          "Mostly FUD", "the vast majority", "most API's"... In other words, there is truth to the claims of problems caused by fragmentation.

          In other words, I have experience with Android including very simple android development and do not believe the scaremongering caused by this so-called fragmentation.

          Which, like your statements quoted above, neatly dodges the issue

          Which, unlike your quotation, is not removed from it's context. How, did you somehow read that I didn't say "fragmentation" isn't a big issue? When the vast majority of developers will never encounter it, fragmentation is not a big issue.

          Android's application framework is based on the Dalvik virtual machine, if your are unfamiliar with how virtual machines work they serve as an intermediary between the hardware (or the HAL) and the application, the virtual machine is written for the hardware, the application only needs to be written for the virtual machine providing an identical framework for applications across divergent hardware platforms and versions. Finally, yes, Dalvik does this quite well.

          So take you scaremongering and out of context quotations elsewhere good sir until you actually learn about the "problems" you are spreading FUD about.

    • by Concern (819622) on Sunday May 23, 2010 @08:31PM (#32318538) Journal

      The fascinating thing about "fragmentation" is that it's a problem we just made up. Apple's Mac line, let alone the Windows world, have more hardware and software diversity in one minute than Android has all year. Yet no one goes around suggesting that "fragmentation will hurt the PC market's long term chances of success."

      This feels like a FUD bullet point created by an Apple astroturfing firm, whether it actually is or not. The whole "fragmentation" line of thinking presumes a world we have never had, and which I doubt anyone would willingly choose: one where a single manufacturer rules, producing a few nearly perfect products in a graceful, gradual schedule.

      The funniest part is that this meme is useful for identifying people with no Android developer experience. After having used both the Apple SDK and the Android SDK pretty extensively, you can see why Android will win in the marketplace, and win so quickly. Never has there been such a beautifully organized, transparent, open, easy zero-to-development experience. In a world where most platforms don't even think about API versioning until it's too late, Android builds in an elegant management system from the beginning. "All 5" API revisions are accessible via a pullout menu. You default to the lowest, so that your app is compatible with all devices. Easy done.

      And if you need something that a newer OS revision offers, everything about it makes it easy to target the minimum revision required.

      The documentation is organized and straightforward. Running and debugging your app is a keystroke away, with a hardware-level emulator that's trivially configured to match whichever devices you prefer to test on - or all of them.

      It's ironic, really. Hardly anyone has ever done such a good job of managing fragmentation, yet all this refinement for a platform that has less diversity (especially at this early point in its life) than almost any open platform I've seen that's this widely used.

      In short, LOL.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        The fascinating thing about "fragmentation" is that it's a problem we just made up.

        Exactly. Too much dumbing down is also to blame here. Any competent developer should be able to easily structure his/her application so that it detects at runtime what feature set is available and then adjusts itself accordingly. The APIs are all there and they are very well done. It's not like it's even a problem.

        And finally how is this different from Apple devices - some have cameras and some don't, some have bigger displa

      • by mgblst (80109)

        You described the iPhone development experience as well, and are yet to mention one way in which android development is more of a "beautifully organized, transparent, open, easy zero-to-development experience" than Apple.

        It might be so, and I have only just delved into Android a bit, but Xcode is such a great dev environment. I hate having to go to work and use Visual Studio to work on piece of shit .Net stuff.

      • by Anonymous Coward on Sunday May 23, 2010 @11:54PM (#32319788)

        That's great until you realize some things can't be lowest common denominator.

        And Desktops are a bad analogy, let me give you an example:

        To make desktops analogous to the mobile phone market - you can run multiple apps (multitasking) but can only have ONE on screen at any given time. That means the app take up the whole screen, and do so gracefully. This is great for web browsers, but how many apps do you know that scale well when they're stretched to random dimensions they weren't designed for? Oh, I'm sure they're usable, but do they look good or professional? Probably not.

        Now take it to mobile phones.

        Now take things like input paradigms. Is the user going to expect a multitouch system to interact, maybe not? Well if every app assumes not, then why the hell sell multitouch to begin with! Oh, so we should support multitouch but degrade to single touch, well, okay, that requires different UI input systems different UI design quite possibly, etc. Do you start to see the confusion here?

        For devices like phones, monoculture within an environment can be -VERY GOOD- for developers, because it reduces the specs you have to target, and because the device and apps have to be integrated in a very deep way. On operating systems, monoculture tends to do bad things though, because you end up with no options or creativity present.

        I'm not saying that the monoculture should be Apple, I'm just saying if all the android phones had to meet X requires and all had X resolution screens, and all of them has X input systems, and the extras were in size, and things that don't effect applications, you'd have a much more workable development environment.

        Just my $0.02, as a mobile application developer...

      • by _Sprocket_ (42527)

        The fascinating thing about "fragmentation" is that it's a problem we just made up. Apple's Mac line, let alone the Windows world, have more hardware and software diversity in one minute than Android has all year. Yet no one goes around suggesting that "fragmentation will hurt the PC market's long term chances of success."

        Actually - that's long been a claim of the Mac faithful. The Wintel world was just too complex due to no control over hardware. Apple's world was a comfortably controlled world of predictable product lines. This is just re-application of the same mindset to a new market.

      • by BOFslime (178524) on Monday May 24, 2010 @01:01AM (#32320108) Homepage
        I agree, in fact there was a blog article [blogspot.com] written by an android game developer that kinda mock'ed this notion of fragmentation.

        Quote from the blog: "I'm lucky enough to have occasional access to lots of different Android devices via my work. The whole point of the Android approach to apps is that you can write an app on one device (or even an emulator) and deploy it across everything. In my case, that's been pretty true."
      • by InakaBoyJoe (687694) on Monday May 24, 2010 @03:22AM (#32320656)

        Apple = red herring.

        Even worse, there's a huge elephant in the room. The crux of TFA is that fragmentation is the price paid for "the pace of innovation." But the problem is not new releases -- it's the failure of Google's Android Market (app store) to keep up with the needs of the marketplace. This has caused a bunch of carriers, hardware makers, and iTunes-wannabes to create their own app stores [slashdot.org] -- each with their own requirements and generally making life hell for developers. The reason is that Google's own Android Market was slow to launch internationally (especially to support paid apps), has an infamously poor UX, and -- shocking for a company called Google -- poor search capability.

        New hardware and OS releases are generally welcomed by developers. But if you're an Android developer, what's insane is having to support multiple app stores for the SAME hardware and SAME OS -- just because Google didn't bother to support paid apps in Canada until two months ago, for example. And don't even get me started on the joys of trying to make an app for China [slashdot.org].

        Hey Andy, before you pass off fragmentation as a necessary part of innovation, take a stroll down to the department responsible for creating Android Market and tell them to start innovating to rein in the chaos they've created.

    • by Z34107 (925136)

      I haven't done much Android development, but it's not as bad as it sounds. I started learning from a Android 2.1 book; all the sample code ran on a locked-down consumer 1.5 handset, 1.5 being the oldest version in common use. The one exception I found was a flag that told you if you were entering or leaving a given physical area didn't seem to be present on my 1.5 headset, but querying it didn't break anything.

      Android versions are like .NET versions; you can change the one you want to target, and your cod

    • by mweather (1089505)

      As an iPhone developer who would love to make the jump to include android I am very scared about the large mishmash of versions and hardware.

      If that scares you, PCs must be your worst nightmare. Android is a monoculture by comparison.

    • by poetmatt (793785)

      maybe you should try looking. the shit is quite well documented and not at all as complex as your spin is implying.

    • IMHO idiots like these manage to trick developers causing millions of dollars in potential revenue especially with independent developers.

      You don't need to jump the ship, keep shipping for iPhone and add Android, Symbian and even Windows Mobile to your platforms. Ignore what those "blog writers" and fanatics (including some devs) say, see yourself...

      Let me give a 2 applications as example: Nimbuzz and Fring. OK, they get great venture capital these days but it is likely 10 guys coding. They ship to any mobi

  • These "growing pains" need to be worked out, but app developers will quickly learn to check versions at runtime to make sure most of their features will work in older (or newer) versions of Android.

    Apple took care very well from the start, but they've had lots of consumer software experience. Goole & Android will get their act together ... it will just take a little time.
    • by causality (777677) on Sunday May 23, 2010 @07:56PM (#32318292)

      These "growing pains" need to be worked out, but app developers will quickly learn to check versions at runtime to make sure most of their features will work in older (or newer) versions of Android. Apple took care very well from the start, but they've had lots of consumer software experience. Goole & Android will get their act together ... it will just take a little time.

      I thought Apple's approach was to strictly control both the hardware platform and the developer's tools, both to ensure they will work together and also to make it highly inconvenient for developers to port their apps to other platforms like Android. That sounds like marketing and vendor lock-in experience. The term "software experience" seems to suggest that they have tackled the complexity involved with developing for diverse systems instead of avoiding it.

      • I thought Apple's approach was to strictly control both the hardware platform and the developer's tools, both to ensure they will work together and also to make it highly inconvenient for developers to port their apps to other platforms like Android. That sounds like marketing and vendor lock-in experience.

        Most app features will work on most iProducts ... but not all. When iPhone 4.0 comes out this summer some of the newer features won't work on earlier handsets (ie, multitasking won't work on a 3G or earlier handsets). Yes, Apple is evil for their lock-in, but I was referencing the article's main subject, which is fragmentation & obsolescence due to handset and OS vertsions.

        The term "software experience" seems to suggest that they have tackled the complexity involved with developing for diverse systems instead of avoiding it.

        Their Macintosh consumer software experience. They've had a lot of years of practice making sure most, but not all, software runs on

    • by JanneM (7445)

      "...app developers will quickly learn to check versions at runtime to make sure most of their features will work in older (or newer) versions of Android."

      AFAIK, they already do. You declare the minimum API version in the application manifest. All Android versions in use today (1.5 and upwards) are backward-compatible, so if you as a developer wants to maximise the number of users is to target the lowest version that still supports the features your app needs. Which, for most of them, is any version currentl

    • by mlts (1038732) *

      I think Android will end up thrashing its problems out probably by the end of this year, or first quarter of 2011, as the OS goes from having to be deployed as fast as possible to get marketshare before Apple locks down the market like they did with MP3 players, to changing to a mature app platform that is decently supported across handset makers and cellular carriers. Android 2.2 has taken some steps to get there, but what it will take is getting to where the iPhone OS is right now when it comes to encryp

      • You make some good points but you yield too much success for Android to the business market. Far more consumers use cells than business does, if not thousands to one then millions to one.

    • And Apple's computers and other consumer devices, including the iPhone are fragmented. Please stop using them as a bastion of solidarity.

    • by salesgeek (263995)

      I have to laugh at this because it smells of the finest astrotruf: "Apple took care very well from the start, but they've had lots of consumer software experience. Goole & Android will get their act together ... it will just take a little time."

  • by SavedLinuXgeeK (769306) on Sunday May 23, 2010 @07:46PM (#32318204) Homepage
    The flash runtime has experienced the same problems as it was a developing platform. Flash 8,9 and 10 are all still in use today and have different feature sets and programming models. I realize the analog is slightly different as android is an OS and not a runtime, but the fact remains that progress requires this. We as geeks bemoan long development cycles and slow progress. Well the way to get around slow progress is quick iterations, and that gets to you to fragmentation. Adobe has realized this and their rate of development has slowed as they have stabilized on where they want the platform to go. Give android a year or so, and once Google realizes where it wants android to go, the iterations should slow down dramatically, and fragmentation will be a thing of the past.
    • by causality (777677) on Sunday May 23, 2010 @08:20PM (#32318454)

      The flash runtime has experienced the same problems as it was a developing platform. Flash 8,9 and 10 are all still in use today and have different feature sets and programming models.

      With Flash I doubt that the features added between Version 8 and Version 10 were natural progressions and refinements of the concepts and principles on which that system is based. Instead, I see them as "we gotta give our customers a reason to buy the latest version so let's add more bloat!"

      We as geeks bemoan long development cycles and slow progress.

      It depends on how sound and useful the initial design was. The POSIX standard has a slow development cycle. So does the X Windowing Protocol. I haven't seen many fundamental innovations for the TCP protocol lately either. I have seen bugfixes and things of that nature, but not much bloat and feature creep. For those things, the design closely matched the intended purpose and philosophy and there was little or no marketing pressure to always have something new to sell. I think it's precisely because those things are the concern of geeks and are the "under the hood" type of thing that average end-users wouldn't directly work with. Things like Flash animations and iPhones are much more visible and immediately practical for average users and there we see marketing pressures and faster developments.

      Adobe has realized this and their rate of development has slowed as they have stabilized on where they want the platform to go.

      I think what Adobe has realized is that the proposed video functions of HTML5 could be a direct threat to their little proprietary standard fiefdom and that vendors like Apple have some good (business) reasons not to use their products. I think that would get them to concentrate on something more substantial than more bells and whistles and put pressure on them to produce a good, solid runtime. The only thing I wonder is whether they are prepared to address the absolute joke that Flash has been when it comes to security. It's easily up there with Sendmail and BIND so far as track records are concerned.

      Give android a year or so, and once Google realizes where it wants android to go, the iterations should slow down dramatically, and fragmentation will be a thing of the past.

      I hope so. The closed nature of Apple's products is my biggest single problem with them. Most users don't care so there is little reason for Apple to see this as a problem. Therefore, what it would take to change that would be another company (like Google) who can give them serious competition without such tactics.

      I realize the analog is slightly different as android is an OS and not a runtime, but the fact remains that progress requires this.

      Conscious or subconscious, that looks to me like what you realize is that some Slashdotters love to attack you based on things you never actually claimed. Had you omitted that line, I could see them now, the follow-up posts saying "huh huh, an OS is not a runtime, therefore you don't know what you're talking about and you're wrong and I'm right so hah!" The way I explain it is that if I didn't explicitly outright claim something, it's for a reason and is not the product of random chance.

      My approach to those would-be killjoys for whom feeling superior to somebody is more important than reading comprehension is different. I refuse to add little disclaimers like that because for more nuanced posts, those would be longer than the point I am making. I also refuse to do it because I won't cater to maladaptive behavior that disguises itself as useful critique. Instead, I let them try that on me and then show them why it was useless.

      • by SEE (7681)

        The POSIX standard has a slow development cycle. So does the X Windowing Protocol.

        The X Windowing Protocol went through 11 incompatible versions in its first three-and-a-half years. So by comparison, Android is downright stodgy.

        • by causality (777677)

          The POSIX standard has a slow development cycle. So does the X Windowing Protocol.

          The X Windowing Protocol went through 11 incompatible versions in its first three-and-a-half years. So by comparison, Android is downright stodgy.

          Not to be nit-picky but this situation calls for it: saying it "has" (present tense) a slow development cycle is not a claim that this has always been the case since its inception.

          • by SEE (7681)

            Not to be nit-picky but this situation calls for it: saying it "has" (present tense) a slow development cycle is not a claim that this has always been the case since its inception.

            You think the situation calls for being nit-picky? Wonderful, sir. Then let us pick the nit in context:

            It depends on how sound and useful the initial design was. The POSIX standard has a slow development cycle. So does the X Windowing Protocol.

            Saying that "[i]t depends on how sound and useful the initial design was" is an explicit invocation of the case at the inception. And so the state of your examples at their respective inceptions is plainly relevant to evaluating your statement.

            • by causality (777677)

              Not to be nit-picky but this situation calls for it: saying it "has" (present tense) a slow development cycle is not a claim that this has always been the case since its inception.

              You think the situation calls for being nit-picky? Wonderful, sir. Then let us pick the nit in context:

              It depends on how sound and useful the initial design was. The POSIX standard has a slow development cycle. So does the X Windowing Protocol.

              Saying that "[i]t depends on how sound and useful the initial design was" is an explicit invocation of the case at the inception. And so the state of your examples at their respective inceptions is plainly relevant to evaluating your statement.

              First of all, the X protocol of which I spoke has been around since Project Athena (MIT) in 1984. That's about 26 years. The first 3 years of those 26 years constitutes 11.5% of its history and only the earliest part thereof. The point you think you are making hinges on a small minority of its overall history that has nothing to do with the present-day case of which I explicitly spoke.

              You failed to properly understand the last two paragraphs of my initial post in this thread, where I said that the way

  • I think if handset makers and carriers can do this, getting Android 2.2 as a baseline onto all devices might be what the doctor ordered for this.

    The main reason is not just JIT compiling, nor the ability to run apps on the SD card (which is important for older phones). Instead, Android 2.2 offers a lot more modular upgrade path, where before devices in previous versions would have to be completely reflashed just to support one item.

    Time will tell if 2.2 gets adopted, or if we still have the version fragmen

  • Words of Wisdom (Score:4, Insightful)

    by grcumb (781340) on Sunday May 23, 2010 @07:51PM (#32318244) Homepage Journal

    With apologies to... Henry Spencer [wikipedia.org]:

    "Those who fail to understand apt-get are condemned to re-invent it, poorly."

    • by Blakey Rat (99501)

      Someone want to explain to me what makes this "Interesting?" Or for that matter, what makes it at all relevant...

      • Re:Words of Wisdom (Score:5, Informative)

        by grcumb (781340) on Sunday May 23, 2010 @11:08PM (#32319506) Homepage Journal

        Someone want to explain to me what makes this "Interesting?" Or for that matter, what makes it at all relevant...

        Because the people providing the operating systems for mobile devices are discovering, to nobody's surprise but their own (and apparently yours), that being able to manage and maintain a software base over a diverse number of architectures and platforms is a non-trivial task.

        In my professional experience, the inventors of apt-get were the first to create an adequate means of maintaining a largely stable system, managing compatibility and dependency issues over tens of thousands of applications, utilities and drivers.

        The implication of my statement, therefore, is that Google should be giving more thought to package management issues as a means of reducing their own software maintenance overheads.

        Unfortunately, that's not likely to happen in any useful way, because all the phone suppliers only dream of being Apple, so they're intent only on controlling every means of access to the apps and other software that runs on their phone.

        Therefore, these vendors - who fail to understand why apt-get is important - are condemned to creating their own proprietary update services and interfaces, and because they are neither unified nor open, it's quite likely that each of them will get it wrong in unique and entertaining ways.

        That one little sentence took a bit of unpacking, but there you go.

        HTH, HAND.

        • Re:Words of Wisdom (Score:4, Insightful)

          by IamTheRealMike (537420) <mike@plan99.net> on Monday May 24, 2010 @04:46AM (#32321060) Homepage

          It's not likely to happen because apt-get is a pretty terrible model for end-user facing software.

          The Android software distribution and versioning model is pretty much exactly what I spent a couple of years campaigning for in the desktop Linux world about 5-6 years ago. Some of the core ideas of apt are there - a central repository of software that vends package files which can be obtained via other means if you want.

          But Android nails so many things the desktop Linux guys just never understood. For one, apps depend on the platform and nothing else. Some apps can gain additional functionality when other apps are present and the OS makes that easy to code up, but those dependencies are always optional. The market doesn't have any concept of "dependency resolution" because otherwise you'd rapidly end up with what you get in the Linux world - uninstallable applications with no good way to explain why to the end user.

          The Android model allows software dependencies on a strongly versioned platform, and also allows hardware dependencies because they do vary by device (I'll note that apt has no concept of a hardware dependency). The versioning of the Android platform is "correct" in that it's what I always wanted Linux to move to - a single number that identifies a large range of APIs that are revved together every so often. GNOME follows this model most closely in the Linux world. But GNOME misses some key pieces. Firstly the Android dev tools make it easy to target old versions, so easy it's actually the default. Now try compiling an app on your up to date developer workstation that targets GNOME 2.0 - you'll find it's not possible. The development tools will conspire to stop you (typically header files). I complained about this several times and was told, basically, that there was no interest in fixing this.

          It's unsurprising then that the Linux model has collapsed into chaos so quickly, a chaos so profound that the only way to tackle it is to try and "stop the world" every 6 months. People might bitch about Android fragmentation today, but they'd bitch a lot more if only one version of their app was offered to each user, tied to OS upgrades!

  • by fuzzyfuzzyfungus (1223518) on Sunday May 23, 2010 @07:52PM (#32318250) Journal
    Arguably, there are two broad classes of users/applications for Android: the ones that need a cheap phone OS that sucks less than your average "dumbphone" or "featurephone" OS(both in terms of general usability, and in terms of the dev team's ease of getting things going) and the ones who want an "Android smartphone", and wish to run "Android applications" on it, and so forth.

    You would expect the former group to be heavily fragmented; but for that fragmentation not to matter very much. For any device where Android is simply being used as a cheaper or easier alternative to a dumbphone/featurephone OS, or even to some other embedded operating system(as with a cheap digital photoframe or GPS or something), the version, and most likely the applications, the device ships with will be the ones it dies with. Fragmentation will be inevitable; but also won't matter much(upgrades will generally not be expected, outside of a few tinkering geek who can roll their own, device developers will use the Android version of their choice when developing. No big deal.)

    The trickier case is the part of the market that directly competes with iPhones. Here, updates are generally expected, adding applications and having things work is a prerequisite for success, and fragmentation is a bad thing. Google's own blessed handsets seem to be avoiding this reasonably well(within the limits of hardware advance. The G1 is starting to show its age; but so is the gen-1 iPhone); but some of the tier-2 carrier stuff is looking a little more doubtful.

    Personally, I suspect that the critical thing will be whether or not expectations are correctly matched to devices. Having more or less fixed-spec "featurephones" being based on Android isn't bad for Android unless those phones are then sold to unwitting buyers as being equivalent to the high-end, frequently updated, fully app-compatible "Android Phones". If they are just sold as featurephones with decent browsers and mail clients, no harm, no foul. If they are (essentially dishonestly) sold as cheaper-but-equivalent alternatives to the properly updated Android devices, there will be a lot of unhappy customers stuck with outdated firmware.
  • by eparker05 (1738842) on Sunday May 23, 2010 @07:53PM (#32318262)

    My Droid Eris was on Android 1.5 for the last several months and I noticed very few differences between it and my father's Droid with 2.0. Yea he had voice nav, and he got live wallpapers when the 2.1 rolled out, but the core features that made me love the OS were largely identical (push gmail, widgets, great web browsing experience, etc.).

    The only people to be hurt by the 'fragmentation/obsolescence' issue is developers. I don't want to downplay the developer issue, but as far as consumers are concerned , most of the big-time apps have no trouble supporting multiple iterations of the platform.

    • by furball (2853)

      most of the big-time apps have no trouble supporting multiple iterations of the platform

      So it's a real problem to some big-time apps. This may also limit how many apps become big-time apps.

    • by Angst Badger (8636) on Sunday May 23, 2010 @09:15PM (#32318848)

      The only people to be hurt by the 'fragmentation/obsolescence' issue is developers. I don't want to downplay the developer issue, but as far as consumers are concerned , most of the big-time apps have no trouble supporting multiple iterations of the platform.

      On the contrary, please do downplay the developer issue. Obviously, it matters a great deal to us as developers, but the purpose of hardware and software -- at least in the commercial market -- isn't to please developers, it's to please customers so they'll give money to the companies that employ the developers. If enough customers want a device that requires the developers to read documentation in cuneiform and write code in assembly language, then we'll be reading documentation in cuneiform and writing code in assembly language, or the software companies will find someone who will.

      Don't get me wrong; *I* care about these issues as much as the next developer. But nobody but us cares about these issues or what we think about them. For the vast majority of us who don't work at mythical miracle companies that actually give a wet crap what their programming staff thinks, we'll end up coding for whatever platform the bean counters and bizdev monkeys decide is going to sell. And if they're wrong -- a decision that's ultimately going to be made by consumers with even less technical knowledge than the bean counters -- then we'll end up working on something else, possibly at another company if the last one didn't have enough capital reserves to withstand a product failure.

      That being the case, the author of TFA is either out of touch with the reality of the industry or, as several posters have suggested, this is just astroturf FUD designed to scare consumers away by using long, scary words -- like fragmentation, for example -- whose meaning they don't know, just as most of them probably have no idea what an operating system is or that Android is an OS. I'd be willing to wager a decent chunk of change that most non-technical customers would read the headline and the first couple of sentences of TFA -- they're certainly not going to read the whole thing -- and conclude that the gist of the article is that Android phones are more likely to physically break into little bits than iPhones.

  • by kidgenius (704962) on Sunday May 23, 2010 @07:55PM (#32318282)
    ...But is phone manufacturer. If you make the phone and it just runs a vanilla Android OS, then you can theoretically push the update out without too much pain. The problem comes from the phone manufacturers who are trying to "improve" the OS by adding things like Sense UI and Motoblur. Yeah, some of these improvements are better, but others aren't any better than what comes in vanilla, and even more are worse. The fact that the modding community can turn on OS around in a few weeks and push it back out to the device is testament to how easy it is to put these newer versions of software on the phone, and it just the manufacturers trying to add their own crap back on that is the issue.
    • The fact that the modding community can turn on OS around in a few weeks and push it back out to the device is testament to how easy it is to put these newer versions of software on the phone, and it just the manufacturers trying to add their own crap back on that is the issue.

      It is not that simple.

      As just one example, ROM modders are willing to put up with "brick rates" that would result in class action suits if a device manufacturer and carrier tried the same thing. A 99% success rate -- which a ROM modde

  • by kroyd (29866) on Sunday May 23, 2010 @07:57PM (#32318300)
    I've got an 2G iPod touch, with iPhone OS 2.x. This means there is software that simply won't run because it is not an iPhone (such as Sleep Cycle), and software which won't run because it is not the 3.x version of the OS (games - at least the Street fighter demo and some others). With an iPod Touch you have to buy the OS upgrades, which I haven't bothered to do.

    By this summer you'll have to support the 1G, 2G and 3G versions of the iPod touch, the 1G, 2G and 3G iPhones, the 3G iPhone with more RAM and a faster processor, and the 4G iPhone with both more RAM and a higher resolution. Oh, and the iPad of course.

    The biggest new challenge with "iphone 4g" is the higher resolution - some say this will be 960x640 (i.e 2x the current resolution hor/ver), which is imho unlikely as this would be the first use of such a LCD resolution ever.

    To me this doesn't sound simpler than the Android fragmentation, at least with Android the market lets you know which apps you can install, and the vast majority actually works with 1.5. With the Appstore you might only get "oh, don't install this on an iPod touch, it won't work".

    Android is also more developer friendly, e.g. the new feature introduced just before the 2.2 release - at least my N1 got a "report this crash button" before I upgraded to 2.2. (I don't want to speculate on the developer friendlyness of Apple, but recent news haven't been very good.

    • Re: (Score:2, Flamebait)

      by NiceGeek (126629)

      "you have to buy the OS upgrades, which I haven't bothered to do"

      $5 is that tough to part with?

      • by fandingo (1541045)

        Exactly. iPhone upgrades have always been free, so developers only need to target the current major version. iTunes prompts for upgrades whenever one is released, so it would be nonsensical to run an old OS. For iTouches, if someone won't pay for a $5-$10 (I think they are $10) upgrade every six months or so, then as a developer, why should I care about them? If my app is free, then there is no expectation that I spend extra work supporting legacy systems, and if it costs money, then why do I care about the

    • by jo42 (227475) on Sunday May 23, 2010 @10:21PM (#32319248) Homepage

      With an iPod Touch you have to buy the OS upgrades, which I haven't bothered to do.

      Not if you know where to download the appropriate ipsw file (from Apple's own CDN servers no less!). Google is your friend here.

  • by mveloso (325617) on Sunday May 23, 2010 @08:02PM (#32318328)

    "Andy's point was simple. Older Android devices that can't be upgraded to newer versions of the OS or run newer apps are no different than an iPhone from 2007 not being updated to OS 4."

    Rubin obfuscates the problem by trying to simplify things, which is working. The issues:

    * my android device can't be upgraded
    * my android app don't work on x version of android
    * my android app doesn't work on y version of hardware

    iPhone 4.0 is irrelevant, since it doesn't exist yet. And it is not like iPhone 3Gs not moving to iPhone 4. It's more like an app on an iPhone 3G with iPhone OS 2.0 can't run iPhone OS 3.0 because (a) the device itself can't be upgraded to iPhone OS 3.0, and/or (2) because iPhone OS 3.0 isn't backwards-compatible with iPhone OS 2.0.

    I have plenty of iPhone apps that were first-generation that still work. That sounds like an unlikely situation in the android world. I also have apps that work on all versions of OS and hardware. I have a few that require specific features (GPS) that don't exist on 1.0 hardware...so obviously don't work on newer devices. I had a few apps (WiFi scanners) that died under OS 3.0 that used to work.

    It sounds, however, that compatibility across android and handset versions is not only not guaranteed with android, but that the incompatibility is to be expected...according to their chief architect.

    Nice.

    • by amiga3D (567632)
      It seems some of Jobs hard headedness could be for a good reason.....maybe.
    • by Qubit (100461)

      * my android device can't be upgraded
      * my android app don't work on x version of android
      * my android app doesn't work on y version of hardware

      Interestingly, if Android were something like... say GPLv3, so that end users could update the OS, and if you had a compelling enough app, I think that you could then get people to upgrade their phone OS in order to run the new versions of your application.

      Certain issues, for example lack of an accelerometer or a GPS unit, are insurmountable. You'll just have to suck it up and deal with those hardware revs in your builds, or indicate that you're not officially supporting that hardware anymore.

      It sounds, however, that compatibility across android and handset versions is not only not guaranteed with android, but that the incompatibility is to be expected...according to their chief architect.

      Nice.

      Android isn't

    • Silly question I know, but reading your post just makes its title look all the more ironic.

      Hardware and legacy-OS "fragmentation" exists today in the iPhone ecosystem - nearly half [ilounge.com] of iPod Touches are running older systems, and there are already iPhone owners who will never be able to upgrade to OS 4 (even the beta). It's obviously greater in Android due to the larger choice of hardware and more rapid OS releases. Some may prefer a slower-moving target, but the monolithic, our-way-or-the-highway approach th

  • somewhat misleading (Score:4, Informative)

    by Tumbleweed (3706) on Sunday May 23, 2010 @08:27PM (#32318508)

    Of the '5' versions, only 3 have anything resembling significant usage in the wild (1.5, 1.6 and 2.1). Multiple phones have had 2.1 upgrades released for them since the statistics were gathered, thus throwing even those statistics out of whack. Once all the handsets that are capable of running 2.2 are upgraded, I think that will be a pretty stable platform for quite some time - most everything that people have been clamoring for in Android is either in or supported by, that version (Flash, App2SD, bluetooth voice calling, JIT, etc). Many of the handsets that are older and 1.5/1.6-based might not perform all that well with these new features (if at all) due to constrained physical resources (slower CPU, less RAM, etc).

    Coming out with new hardware now with anything less than 2.1 should be a crime, though. I'm glad they've said the EVO 4G will have a 2.2 upgrade in July. *whew*

  • Dear Hardware providers and cell carriers: Please give us our devices already rooted. The community can easily port new versions of Android to your phones so phones like the Motorola Backflip and Cliq can have decent versions of Android already.

    I mean, seriously? What do they have to lose for giving us pre-rooted phones?
    • Re: (Score:2, Interesting)

      by Microlith (54737)

      What do they have to lose for giving us pre-rooted phones?

      Control. If they give up that, they might not be able to force you on to their services.

      Motorola's the worst, since they sign the bootloader, kernel, and file system. The devices won't boot if any part of that has changed, and the only device you -can- change is the DROID (though the Milestone variant is locked down, last I checked.)

    • phone manufacturers don't care. service providers do.

      they have an interest in being able to control the software that runs on devices that connect to their network. the most obvious example is tethering. they don't want everyone to have it for free, they want to charge $30 / month extra. on a rooted phone they can't control that.

      so yes, they have a lot to lose.

  • Having one single unified Android market which adds terrific value to your handset, is going to ensure any fragmentation doesn't get too bad. This is the basis of why I dismiss these fears out of hand. I'd only worry if the market itself fragmented.
  • Apple zealots are getting nervous about Android so this story seeks to reassure them that the rapid improvement of Android is a bad thing.

    • by mgblst (80109)

      Ok, moronic comment aside, this is a problem.

      And, I want to into Android development, but new and better phones keep coming out. The droid was the first one I thought about getting, then Google released the Nexus one. But the Nexus one has a weird screen ( 2x green pixels to each red + blue), so I worried about that. Now there is the Evo, a newer phone. Plus, I worry about getting stuck with the g1's memory issue, where it can not take the newer OS version. Plus, I have to worry about motorola or HTC releas

      • Re: (Score:3, Insightful)

        by salesgeek (263995)

        Dude, we code in Java targeting a virtual machine (it's called Dalvic). You don't worry about the hardware underneath - Android's APIs and virtual machine takes care of all of that stuff for you. You don't even have to have an Android device to do development. The SDK comes with an emulator that lets you build and test your apps on Windows, Linux or MacOS.

        Now that we've cleared that up, head over to the Android site and download the SDK and learn to write an app instead of worrying about phone hardware. Th

      • Re: (Score:3, Informative)

        by bnenning (58349)

        The default for an Android developer should be the N1. The "weird screen" isn't a factor in practice, there still aren't any other phones with significantly better specs, and it's virtually guaranteed to get timely updates for the next few years because there are no incompetent and/or malicious middlemen.

    • You know the real interesting thing which is fortunate for some companies is: People ignoring numbers like 24 million, in first 6 months of 2010. That is Symbian, supposed to be "fragmented" while single sisx file installs to almost anything.

      You know what could drive all of them to real panic? If Nokia gets the neat idea of shipping a fully supported (and of course, working) Qt SDK for Android.

      While on it, a device very similar to Android sold 19 million too... Blackberry... If you add them, it makes 43 mil

  • I believe this development cycle could turn casual consumers away and hurt Android's chances at long term mainstream success.

    Sounds like the submitter is suggesting we artificially slow the rate of innovation. Hey, maybe we should just not release new devices with new features at all. That way no one will feel left out!

  • by Ilgaz (86384) on Sunday May 23, 2010 @11:39PM (#32319702) Homepage

    This is going on for years on Symbian scene and J2ME (Java Micro), same thing being said over and over and unfortunately some developers seem to actually believe it.

    I will give one single title: Opera. Opera Mobile runs on ANY Symbian S60 and Opera Mini runs on ANY J2ME client. There is no "Opera Mobile for Nokia E71", the drop down menus on some download may confuse you. It is just, some developers, especially the ones directly selling (no trial) apps want to make sure the application will run instead of living hassle to give money back or bad feedback. Another thing is, root certs which devices have. Some have Verisign, some hove Thawte or both. They want to make sure (especially with J2ME) that application won't be treated as "unsigned", especially network aware apps.

    Of course, if you see something like "S60 V3 FP2", it may confuse you. It just says "Devices with compass built in", much like iPhone 3G vs 3GS and I don't see anyone talking about fragmentation on iPhone scene.

    So J2ME is really "write once,run anywhere" and Symbian is really device independent. Of course, the Developer makes the difference.

Never make anything simple and efficient when a way can be found to make it complex and wonderful.

Working...