Forgot your password?
typodupeerror
Google Cellphones GUI Handhelds Operating Systems Technology

Devs Grapple With 100+ Versions of Android 386

Posted by CmdrTaco
from the propagation-of-the-androids dept.
Barence writes "The scale of the challenge facing Android developers has been laid bare by Twitter client TweetDeck. During beta testing of its new software, TweetDeck encountered more than 36,000 testers using an enormous pool of 244 different handsets. Not only was hardware for the platform fragmented, but Tweetdeck had to contend with more than a hundred different versions of Android, highlighting just how muddled the market is for the open-source platform. The splintering of Android is making life difficult for app developers. 'It's not particularly harder to develop for Android over iPhone (from a programming standpoint),' said Christopher Pabon, a developer who writes apps for both the iPhone and Android platforms. 'Except when it comes to final quality assurance and testing. Then it can be a nightmare (a manageable nightmare, mind you).'"
This discussion has been archived. No new comments can be posted.

Devs Grapple With 100+ Versions of Android

Comments Filter:
  • Question (Score:3, Insightful)

    by slaxative (1867220) on Thursday October 14, 2010 @11:30AM (#33894964)
    They forgot one bit of relevant information. So how long did it this massive job take?
  • by roc97007 (608802) on Thursday October 14, 2010 @11:31AM (#33894976) Journal

    ...being too successful.

    • 100+ versions? To make it easier they should just program to 99.99999999999.....+ versions.

  • So? (Score:5, Insightful)

    by RMH101 (636144) on Thursday October 14, 2010 @11:32AM (#33895004)
    Seriously, this is getting as bad as Engadget with their phantom Android Fragmentation issue.
    You have a basic hardware spec (number of buttons etc) laid out by the OHSA, you have processors of varying speeds and some have keyboards and better GPUs. The market can already limit what you see based on these requirements. App developers just need to think about the spec they want vs the number of handsets of that spec in the market. Hell, if your app's good enough, it'll drive the spec of the handset. It's just like what they have to do in the world of PC app development, made easier due to the rapid churn of handset specs as they get steadily faster and cheaper.
    Android's not doing at all badly compared to Apple's iOS, is it?
    • Re:So? (Score:5, Insightful)

      by revscat (35618) on Thursday October 14, 2010 @11:41AM (#33895156) Journal
      So?

      So it means that you have a lower return on investment, given that your testing costs are higher.

      Hell, if your app's good enough, it'll drive the spec of the handset.

      This is both irrelevant and wishful thinking. App popularity does not change the amount of testing required to get it popular in the first place, nor would popularity reduce the number of configurations you must test against even were the spec to change.
      • Re:So? (Score:5, Insightful)

        by delinear (991444) on Thursday October 14, 2010 @11:48AM (#33895270)
        So how is this different to developing games/apps for the desktop (or, hell, laptop, tablet, netbook variants thereof), or every other phone OS other than iOS to date? Is this really a surprise to these people? If so they only have themselves to blame for going into the market blindly, as I'd have thought this would be self evident to anyone developing for an OS that's deployed to multiple hardware platforms.
        • I assume that when you develop a game for the desktop, you develop it for the latest Windows version with some care over portability to the version prior to that and that's it. And you have only one type of input devices (keyboard plus mouse). You know that there anyway will be a big market of gamers using Win 7 with the latest generation of processors and graphic cards. I highly doubt that this variability compares to the one seen in the Android market.
          • by Rhaban (987410)

            I assume that when you develop a game for the desktop, you develop it for the latest Windows version with some care over portability to the version prior to that and that's it.

            You'd ignore the windows XP market?

            • by T-Bone-T (1048702)

              As far as I'm concerned, there want anything between XP and 7. Vista doesn't count.

        • Re:So? (Score:5, Insightful)

          by shadowrat (1069614) on Thursday October 14, 2010 @11:58AM (#33895452)
          it's different because apps cost $0.99 and don't have as large a potential consumer base. is $0.99 going to be profitable when you have to pay an army of testers overtime and have developers working feverishly to squash bugs for a year?
        • Re:So? (Score:4, Informative)

          by afex (693734) on Thursday October 14, 2010 @12:06PM (#33895580)
          it is not different, and we (android users) still have the same problem that PC gamers have: random video card glitches, this game doesn't work while i have program X open, game X performs better in SP3 compat mode, etc. I'm not for or against it, but it is absolutely an issue. One of the reasons i have moved 75% of my gaming to the console - just pop the disk in and get a polished experience.
        • Re: (Score:3, Insightful)

          by DJRumpy (1345787)

          It is different, at least for Windows and OS X, in that the OS is relatively unified under 4 or 5 variants (OS X 10.5-10.6) and Windows XP - Win7), whereas under Android, they have hundreds of different hardware variations (albeit the same basic chips for the most part), in additional to various Android OS flavors on top of each of those hundreds of hardware variations. It's probably more akin to a different Linux distro for each handset, although that may be a bit of a stretch.

          Personally I think software f

        • Re: (Score:3, Insightful)

          by jedrek (79264)

          It's not different than developing for any other phone... and that's why so few people used non-preinstalled apps on their phone before the iPhone. Look at Symbian, it's a clusterfuck of versions, headsets and implementations. My last Symbian phone would crash if I tried to used T9 in my favorite IRC app and GMail would just quit after 2-3 emails. Screw that.

          It is completely different than developing for a PC because computers are viewed by consumers as platforms while phones are viewed as tools/electronic

        • Re: (Score:3, Insightful)

          by Tharsman (1364603)

          So how is this different to developing games/apps for the desktop (or, hell, laptop, tablet, netbook variants thereof), or every other phone OS other than iOS to date? Is this really a surprise to these people? If so they only have themselves to blame for going into the market blindly, as I'd have thought this would be self evident to anyone developing for an OS that's deployed to multiple hardware platforms.

          You are almost right. For the most part, there are only 3 OS versions you can expect desktop users to be running (WinXP, Win7-32 and Win7-64.) Then comes the huge array of hardware differences, though.

          But as I said, you are almost right. Android is like Windows. iPhone is like the XBox or PS3. Develop a game for an XBox or PS3 and you are sure it will run on all of them. The iPhone has a tiny level of feature fragmentation that is not as different as seeing XBoxes with or without hard drive. Actually, the

      • Cost/Benefit (Score:5, Insightful)

        by bill_mcgonigle (4333) * on Thursday October 14, 2010 @12:09PM (#33895622) Homepage Journal

        So it means that you have a lower return on investment, given that your testing costs are higher.

        Right - this should be a simple cost/benefit analysis.

        "I want access to these additional six million customers and it's going to cost me an additional $4600 per year to test for them. Worth it or not?"

        Sure, 'free' would be lovely, in some kind of dream world. But "I want to have these customers and I don't want to bother testing for them," just smacks of greed and/or stupidity. Perhaps the smart developers will seek to stand out by letting people know they've actually tested their software on the device the potential customer owns.

        Is there some sort of contractual obligation that precludes the developers from saying, "sorry, we haven't tested our app on this $130 non-flashable off-brand 7-inch Android tablet that you got from the local bedding supply store on clearance?"

        • Re: (Score:3, Funny)

          by tgd (2822)

          p>"I want access to these additional six million customers and it's going to cost me an additional $4600 per year to test for them. Worth it or not?"

          That's great until your customers find out you're using a sweatshop of six year olds to test your apps ...

          • Re: (Score:3, Insightful)

            by adamstew (909658)

            Agreed. $4600 will pay for the salary, benefits, and expenses of one tester for maybe 1/2 a month...salary, rent, equipment, insurance, taxes, benefits, etc...Labor isn't cheap.

            One tester for 1/2 a month might get your app tested on two platform variants, depending on how complex (or not) your app is. There are now 100 platform variants... so getting enough testers, equipment, etc. for all variants of android can cost $230,000.

            That is, of course, if you are paying testers directly. If you do a public bet

        • Re: (Score:3, Insightful)

          by RobDude (1123541)

          Writing software is more and more like buying a very expensive lottery ticket. Most app developers end up working for pennies on the dollar.

          "But the picture starts out bleak. The average developer gets to pocket a mere $3,050 per year, and this is still considered 'above typically successful', and the most typical developer earns less than that per year."

          Software scales very, very, very well; but our price point expectations are set by the biggest, most successful companies. If you are a top-of-the-charts

      • Re: (Score:3, Interesting)

        by molnarcs (675885)
        To be successful on the Market, you need a) good ideas b) programming skills to implement them. There are lots of hugely popular applications on the Android Market that I haven't seen problems reported by users on any handset. Basically, this is the same as with other platforms - Windows, Linux, etc. Linux is a good example.

        We have thousands of applications and libraries on Linux. They not only work across different versions of the OS, most of them work across different versions AND different architecture

        • Re:So? (Score:4, Informative)

          by molnarcs (675885) <molnarcsNO@SPAMgmail.com> on Thursday October 14, 2010 @12:31PM (#33895988) Homepage Journal
          Eventually I just RTFA, yeah yeah I know - and what I said above is not targeted at this particular developer. For those who didn't RTFA, TweetDeck's blogpost only mentions how proud they are that their app runs on over a hundred combinations of hardware and ROM versions. Their app is exactly the kind of example I had in mind for the developers who can do (vs. the devs who just whine).
    • Re:So? (Score:5, Insightful)

      by shawn(at)fsu (447153) on Thursday October 14, 2010 @11:49AM (#33895288) Homepage

      Agreed.

      I don't see how it can be an issue. Look how prolific development is for windows is, you have no guarantee what the hardware is yet that didn't seem to hinder development for Windows esp if you compare Windows to Apple.

      • Re:So? (Score:4, Funny)

        by Anonymous Coward on Thursday October 14, 2010 @12:06PM (#33895572)

        Did you really just defend Windows? ... on Slashdot?

    • Re: (Score:3, Interesting)

      by pr0nbot (313417)

      App developers just need to think about the spec they want vs the number of handsets of that spec in the market.

      This translates to: "in the fragmented Android market, you need to choose your fragment".

      Or (if disparaging Engadget despite fundamentally agreeing with them makes you squeamish) perhaps this translation: "There is no such thing as the Android market, there is the Droid market, the Galaxy S market, the Desire market, etc."

      How easy is it to get information about all the shards of the Android market and so make a decision about what to target? All the pie charts I've seen have wedges that just say "Android" o

    • Re:So? (Score:5, Interesting)

      by jmichaelg (148257) on Thursday October 14, 2010 @12:11PM (#33895638) Journal

      You're missing a key point.

      Back in the early days of DOS, the OS was relatively stable but the hardware on which it ran was all over the map. We wanted to port Crystal Quest from the Mac to the PC but punted when we saw that we had no way of knowing how many PCs there were that had both a mouse, sound hardware and a video card that could handle bitmap video. All of those features were standard on a Mac but were customizations on a PC. It wasn't until Windows 95 came out that Microsoft started dictating minimum hardware specs that all machines had to have and Microsoft wouldn't let the manufacturer say the PC could run Windows 95 until Microsoft had QA'd the box.

      Android is still in the DOS days. Once Google gets around to learning the same lesson Microsoft learned (albeit slowly) and develops a QA test suite that they administer, the problem will only get worse.

    • You have a basic hardware spec (number of buttons etc) laid out by the OHSA, you have processors of varying speeds and some have keyboards and better GPUs. The market can already limit what you see based on these requirements.

      Your solution is to sell to less people ? Pissing off potential customers who bought into the Android hype but didn't spend enough money on their handset, brilliant bit of marketing there.

      Hell, if your app's good enough, it'll drive the spec of the handset. It's just like what they have to do in the world of PC app development, made easier due to the rapid churn of handset specs as they get steadily faster and cheaper.

      Aaand we're back in PC land : "don't worry people will just buy the hardware to accommodate us, the developer." I thought that attitude died along with PC gaming and Windows Vista.

  • by cheddarlump (834186) on Thursday October 14, 2010 @11:33AM (#33895030)
    It's interesting to me that this is the same problem facing PC's, where there are hundreds of different versions of open source OSes vs. Windows/OSX.
    • by _Sprocket_ (42527) on Thursday October 14, 2010 @11:47AM (#33895256)

      It's interesting to me that this is the same problem facing PC's, where there are hundreds of different versions of open source OSes vs. Windows/OSX.

      I believe you put Windows on the wrong side of that equation. The controlled platform is OSX. The wild-cards are Windows and Open Source OSes; much wider selection of hardware and much less control over OS tree / components / build.

      • Re: (Score:3, Interesting)

        by jank1887 (815982)

        actually, you shouldn't put windows and open source OSes on the same side of the equation.

        controlled platform = OSX

        varied hardware platform, consistent software interface = Windows

        varied hardware platform, varied software interfaces = OSSOS's.

        the common interface is the key to successful third party developer participation.

  • Apple by controlling the OS and hardware out of the starting gate had it right. Microsoft learned it the hard way after years of unsupportable carrier-specific hacks of their Windows Mobile OS, culminating in a much more rigidly defined Windows Mobile 7. Phones that are difficult to upgrade and that cannot run software that runs on other similar phones hurts brand loyalty. If Google wants to retain loyal customers in the mobile market, they are going to have to consolidate these variants and force a sing

    • It's too late.
      I wanted an Android phone but with Motorola's iPhone-like ambitions and HTC's If-rooted-Reload-default-OS feature, I'd rather go for a poorly guarded jail (iPhone) than a WW2 concentration camp.

      I tell people that Android is a failed experiment that proves that Carriers' and Manufacturers' greed will kill any open source advantages that Android could have brought.

      • Re: (Score:3, Insightful)

        by TooMuchToDo (882796)

        *You* may think Android is a failed experiment, although I'd argue that 250K Android activations a day is a success:

        http://tech.fortune.cnn.com/2010/10/04/google-approaching-quarter-million-android-activationsday/ [cnn.com]

        Reality is somewhere between being idealistic and pragmatic. Carriers and Manufacturers may try to kill Android's advantages, but that's the beauty of Android. You can simply pick a different carrier or manufacturer. What do you do if you don't like who makes or handles the connectivity of your iPh

      • Re: (Score:2, Insightful)

        I tell people that Android is a failed experiment that proves that Carriers' and Manufacturers' greed will kill any open source advantages that Android could have brought.

        Then sir, you are a fool. How exactly is is a failed experiment? My phone seems to work just fine, I can find any application I want...and...I can replace my battery!

      • by pspahn (1175617) on Thursday October 14, 2010 @12:05PM (#33895562)

        and HTC's If-rooted-Reload-default-OS feature,

        That's funny, my rooted Evo, which I bought a few weeks after its launch, is still rooted and I am under no obligation to run any OTA updates offered. So yeah, I enjoy being able to use my phone as a wifi hotspot paired up with my netbook, along with any other feature that requires root.

        failed experiment that proves that Carriers' and Manufacturers' greed will kill any open source advantages that Android could have brought.

        Exactly what advantages? How is a phone with a variety of options any better or worse than a phone without those options? The advantages I find with my phone are that I was able to choose which phone I wanted, nothing more. I don't really care that I can go and look at the code and modify it to do whatever I want. I care that I have a choice between a variety of hardware vendors and carriers. I wanted 4g speeds, and I wanted a plan that suited how I use my phone. So for my monthly price, I get unlimited data at speeds far greater than any other phone, and I can share that unlimited data with other devices. This is win.

      • by xaxa (988988)

        I've had my Android phone for three months now, and still haven't found a reason to root it. What's the point?

      • by stoanhart (876182) on Thursday October 14, 2010 @12:41PM (#33896246)

        Even with some manufacturers locking down their phones (in futility), your analogy still seems backwards. Even on a locked Android phone, you have the ability to install any app from any source, which alone makes it more open by orders of magnitude compared to the iPhone. If you really care about a phone which you can flash with your own ROM, there is always a set of phones that are capable of that right out of the box; just buy one of those. If anything, iOS is the WW2 concentration camp, and *some* Android hardware is the poorly guarded jail.

    • by pspahn (1175617) on Thursday October 14, 2010 @11:52AM (#33895348)

      If Google wants to retain loyal customers in the mobile market, they are going to have to consolidate these variants and force a single, portable, upgradable OS like Apple and Microsoft are doing.

      I disagree. One of the selling points of an Android phone is that there are many options when it comes to what kind of phone you want. Let's assume you are correct, and future versions of Android are standardized in a way that prevents hardware vendors from offering a variety of devices. If I, as the consumer, need to get a new phone, I can either time it just right so that the hardware options I desire are available the moment my carrier contract is up, or I will have to wait until such is offered.

      This is such a negative selling point for any type of iThing in my book. If I had needed a new phone several months before the current gen was released, I would either have to switch to something else, purchase the same phone I had previously, or go without a phone for several months. While it's possible I might just go without, it is not possible that I would fork out money for the same device I bought a couple years ago. This leaves me with switching to another phone as the best option, which is exactly what several people I know have done as they were looking to replace their iPhones several months prior to the launch of the current model.

    • by bhcompy (1877290)

      Phones that are difficult to upgrade and that cannot run software that runs on other similar phones hurts brand loyalty.

      Which is funny since WM7 phones aren't backwards compatible software wise.

  • by pscottdv (676889) on Thursday October 14, 2010 @11:34AM (#33895050)
    Programmers write software for a myriad of different versions of Windows running on thousands of different types of hardware without these QA issues. What is Android doing that causes this problem?
    • by alen (225700)

      every PC running Windows has a keyboard and mouse. there are cool keyboards out there with some cool shortcuts and functionality but that is handled by their drivers. the basic input is the same.

      on Android you have hundreds of different devices with different input mechanisms. some have touch, some keyboard. and then there are different touch screens to support multi touch and other forms of input and different gestures. i use an iphone, but i hear there is something called swype out there that a lot of han

      • Re: (Score:3, Insightful)

        by ADRA (37398)

        Um, where to start...

        The API's for accessing the touch screens, multitouch, and everything else you mentioned are all built in. There's no magic hand-waving for the N devices that you're developing for. The biggest hurdle for a developer is really supporting a variety of different screen form factors, and a well planned application can handle that well with planning and foresight. You may have to say 'if X' then do an extra step when a notable feature is absent, but you'll find that by far the majority of t

    • by molnarcs (675885) <molnarcsNO@SPAMgmail.com> on Thursday October 14, 2010 @11:54AM (#33895382) Homepage Journal

      Programmers write software for a myriad of different versions of Windows running on thousands of different types of hardware without these QA issues. What is Android doing that causes this problem?

      As you probably suspect... nothing. There are thousands of useful apps working on all handsets without problems. I have about 30 installed on my Nexus One, carefully read the user reviews for each on AppBrain, and there is a reason most of these have 4.5+ stars... In other words, there are programmers who can do, and programmers who can whine on their blog. What I don't understand is why Slashdot links to random whining programmer to inflate the issue of fragmentation. Actually, you're right on target with the windows analogy. There are shitty programmers whose apps suffer due to hardware/platform (win7/vista/xp) differences, and then there are apps that work fine across all versions of the OS/hw.

      • by molnarcs (675885)
        Correction - I actually clicked on the link, and TweetDeck is not a random whining programmer. The summary is bad as usual, but for those who didn't read the TFA (just like me at first) - they think it's pretty cool their app runs on 244 different handsets and dozens of different modified/hacked/cooked ROMs of Android. What I said still stands, but TweetDeck is the wrong target, sorry :)
      • The problem is real! (Score:3, Interesting)

        by King_TJ (85913)

        Sure, there are "thousands of Android apps working without problems" -- but that doesn't mean it was easy for everyone to get them there.

        Just last week, I did updates to the apps I use on my Android phone, and I think it found 4. Of those, 2 had "reviews" of 1 star, warning people not to download them because they caused massive crashes and issues. (I believe one was the "Trivial Droid" app, which supposedly was crashing so bad for some people on the latest update, they had to pull their batteries out of

    • by timeOday (582209)
      Windows is more centralized. BSD dissipated and basically died due to fragmentation. Linux, due to the GPL, seems to be treading a middle ground - with enough work most apps can be compiled for any distro, but to be useful to most people, each distro must have a maintainer for each application. And the end user is exposed to a mish-mash of widget sets, file dialogs, printer configurations, etc... which some find annoying.
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      You see, cell phones are magical.

      On desktops, multiple OS versions and enormous variations in hardware aren't a significant problem. But on cell phones this an insurmountable problem that can only be solved by locking down everything possible, down to one OS, one hardware manufacturer, and one carrier if at all possible.

      On desktops, a total lack of sandboxing or any filesystem security to speak of is not a significant problem as long as you have anti-virus and keep your browser up to date. But on cell phone

    • by jorenko (238937) on Thursday October 14, 2010 @12:09PM (#33895614)

      The way I see it, the issue is OS rev fragmentation, moreso than hardware. Imagine if Windows 95, 98, 2000, XP all came out 6 months apart, with Vista slated to launch next month and 7 in the spring, and 50% of computers shipping today had 98 installed, and no support for higher versions.

      Related is the carriers' insistence on adding a layer on top of android to make it their own, which just delays the release, meaning by the time they're done the next OS version is out.

    • by gutnor (872759)
      What do you mean without QA issues ?? There is tons of QA issues but they deal with it, if that's what you mean.
      One of the way they deal with it is to limit the scope by specifying min spec. Another way of dealing with it is to charge a lot more for a PC app than for a mobile app.

      Well, TFA says that they can deal with it aswell, and anyway they did deal with it in the days of WinME and J2ME.

      I guess it is still regrettable that so early in the development of Android there is already so much fragmentatio

  • I understand that platforms like consoles and the iCool stuff benefit from the unified platform, but why is this SUCH a big issue? Computers were always fragmented and no two machines were the same in my vicinity, yet still there was working software everywhere - sometimes even crossing OS-borders (playing q3 between different windows and linux versions was never a problem).

    I am not a coder, so could someone explain to me why all of a sudden diversity is such a problem?

    • But at least you had ONE version of the OS and the user could upgrade whenever he/she wanted.

      If your Android phone came with v1.6 and you want to install Android OS v2.2, you have to wiat for the manufacture of your Android phone to publish *its* version of Android OS v2.2.

      Oh, your phone is 2+ years old, too bad. The manufacturer doesn't see $$ in helping you.

    • by tnk1 (899206)

      Diversity is *always* a problem, but its not an insurmountable obstacle. It means you need to run the same tests on any likely platform. The more of these platforms there are, the more of a pain it is, and of course, the more money and time it takes to do it that comes out of the bottom line.

      Having said that, we've gotten rather good at testing multiple platforms in software design. Once you are actually forced to stand up a professional platform QA team, its not too difficult to scale their activities.

  • by Sockatume (732728) on Thursday October 14, 2010 @11:37AM (#33895088)

    2.2, 2.1 update 1, 2.1, something called 020201 (2.0?) and 1.6 account for almost all of the users. The remainder are custom ROMs you're not really obliged to support. Not that having five major releases operating in the wild is much better, mind.

    • Re: (Score:3, Informative)

      But handset manufacturers do not distribute vanilla versions of each OS. Sometimes the OS varies between different handsets from the same manufacturer running the same OS version.

      • Re: (Score:3, Insightful)

        by ADRA (37398)

        Sure, and unless you're making a game that requires a certain minimum benchmark, or if you're trying to do VERY specific measurements using the built-in sensors, who does this affect the developer at all? The API is there, and it pretty much covers all you need in order to insulate against the hardware / OS tweaks. If you decide that you want native blobs instead of Java/Dalvik, then you're into a brand new world of fragmentation, that's why you should be very careful about deciding to make the jump into na

    • by AndrewNeo (979708)

      And considering most of those custom ROMs are built on top of official build versions, they're almost irrelevant.

  • BS (Score:2, Insightful)

    by Anonymous Coward

    As an AC developer, I call BS - have you looked at the "versions" of Android they identified? "Baked Snack 1.0 Epic" or
    "5.0 Welcome to Prisneyland, Fish"? Most of the versions (I dont see the numbers, but I would guess about 80%+ from the chart) are 2.2, 2.1, and 1.6.

    If you have a custom android deployment on the phone, then you may have problems... but don't come whining to me about how you Baked Snack build doesn't support Angry Bird!

    • Re:BS (Score:5, Insightful)

      by delinear (991444) on Thursday October 14, 2010 @11:53AM (#33895364)
      Not to mention most of the custom builds are just vanilla builds with the UI tweaked, and where they do something different it's usually to add base functionality rather than removing it, so I'd be surprised if an app that was tested and working on the standard build failed to work on a custom ROM.
      • Re:BS (Score:4, Informative)

        by MrCrassic (994046) <deprecated@em a . il> on Thursday October 14, 2010 @12:52PM (#33896452) Journal
        Not entirely true; a good deal of Android ROMs implement changes at the system level. The latest version of Cyanogenmod, for instance, has a modified kernel that uses BFS scheduling instead of the default (round-robin?), uses a modified audio library stack (for supporting system-wide DSP effects and equalizer), and uses Apps2SD for space-constrained devices, just to name a few. Testing on all of *those* platforms IS a nightmare, especially since those ROMs have issues even with native apps! However, I would think that targeting the most popular platforms (Android 2.2, 2.1 and 1.6 stock, along with the Droid and Galaxy S ROMs) would be much more reliable, since most people run one of those variations anyway.
  • by RyanFenton (230700) on Thursday October 14, 2010 @11:45AM (#33895210)

    So, you've got to query for functionality, design to fallback in some cases for the features you work with/around, then design tests to make sure it works in the cases you design for. From that, you budget your time, allocate test machines/staff, and ballpark your costs.

    Doesn't sound too unusual - the more features you implement, the more combined testing you have to do for edge cases.

    It's just like with video cards and graphics programming - you design for a limited subset of possible cards, have code to query the cards capabilities, have fallback code for some cards, then test against a good range of cards. Blaming card manufacturers at large for their variety of design isn't productive - they're what makes the market you have the chance to code for.

    Ryan Fenton

    • Or, you could just scrap the majority of this "probing for feature X, running version Y" crap and just develop for a platform with (for the most part) a common set of features. I'd imagine most developers would pick the route of least resistance (not to mention the platform with a wider audience). This may not bode well with the Fandoid crowd, but the truth is the truth...
  • Android Dev (Score:5, Interesting)

    by tobes (302057) <.tobypadilla. .at. .gmail.com.> on Thursday October 14, 2010 @11:53AM (#33895356) Homepage
    As I say in the original post (http://blog.tweetdeck.com/android-ecosystem [tweetdeck.com]), it's great that our app can run on so many different devices. It has been a bit more work supporting all the custom ROMs and hardware specs, but there are more difficult platforms to develop for.

    One REALLY nice thing about developing for Android was that we could have a beta period that involved 36k users. Being able to distribute the APK outside the Market was a real blessing. It's much harder to test iPhone software before submitting it to Apple.
  • by osssmkatz (734824) on Thursday October 14, 2010 @11:56AM (#33895418) Journal

    I just want to thank US Cellular. They sell one phone with naked android, and one phone with HTC Sense. Both are running the Android 2.1, which is almost up to date. (Only the Nexus one and some tablets have 2.2).

    This is the key, I think: ship the Google code and only the google code, and ship an up to date OS.

    Many devices are still running 1.6 and some 1.5. This is unacceptable. Blackberry is no better. They sell their OS upgrades as a feature with their phones. Not OK.

    --Sam

    • by bem (1977) on Thursday October 14, 2010 @12:06PM (#33895576) Homepage

      (Only the Nexus one and some tablets have 2.2).

      Wrong. Droid, Droid 2, Droid X from Motorola are all on 2.2.

      HTC has several 2.2 Phones (Incredible, Evo 4G, Desire)

      Your information is dated.

    • by GweeDo (127172)

      There are a lot of phones other than the N1 with official releases of Android 2.2:
      - Droid 1
      - Droid X
      - Droid 2
      - HTC Incredible (and its varients)
      - HTC Evo
      Just to name a few...

    • by Lehk228 (705449)
      as long as the previous versions of Blackberry OS remain supported i don't see the issue. I don't want the code for supporting the torch touch screen and the UI adjustments for touch screen control on my 9700, i bought it specifically because it is a smartphone with a decent keyboard.
  • by El_Muerte_TDS (592157) <elmuerte@@@drunksnipers...com> on Thursday October 14, 2010 @12:04PM (#33895534) Homepage

    TweetDeck for the iPhone crashes way too often (about once a day on averahge), and for that there are only a handful of different versions. So TweetDeck for Android must be real garbage.

  • Since when were dozens of hacked ROM's "different versions of Android?"

  • I am just curious. (Score:4, Insightful)

    by drolli (522659) on Thursday October 14, 2010 @12:13PM (#33895666) Journal

    As a customer: Does Fragmentation mean that i actually have a choice what i buy?

    • by zill (1690130)
      No, it means it's time to run Disk Defragmenter.
    • Re: (Score:3, Insightful)

      by cibyr (898667)

      Nope. You'll choose a phone based on the hardware, and put up with the shitty manufacturer+carrier customisations. One of the best things about the iPhone is that Apple doesn't allow carrier customisations.

  • Sounds like there needs to be a more Standardized version of Open-Source
  • We are currently porting SoftMaker Office to Android, and we are not experiencing any extraordinary issues that weren't present when we developed for Windows Mobile. So there are different screen resolutions, different Android OS versions, phones and tablets and netbooks, but a well-designed application should be able to handle that.
  • by gklinger (571901) on Thursday October 14, 2010 @12:21PM (#33895830)
    In regards to the unending Android vs. iPhone debate, this story made me think of Eric S. Raymond's The Cathedral and the Bazaar [catb.org]. As a long time user and proponent of open systems I surprised myself when I realized that I while I'd rather my computers be bazaar, I prefer my phone to be a little more cathedral. I wonder how many others are comfortably embracing this dichotomy?
    • Google hasn't exactly done the best job of trying to coordinate things. Google can Open Source the platform, but do like Sun did with Java - anyone can implement Java, but you can't *call* it "Java", unless you passed a conformance test that Sun had. Google should have tried something similar to Android - make it so people can't market their phone as running "Android", unless they conformed to a certain definition of what Android is.

      It's too late for that now, of course, but for future releases of the OS,

    • Re: (Score:3, Insightful)

      by Nerdfest (867930)
      Whenever I hear people say "I realize it's a closed system, a walled garden, tends toward vendor lock-in, and the company that produces it has tended to be extremely arrogant and is practicing censorship, but it's really nice phone" I hear "Come to the dark side, we have cookies". Sometimes you need to show a little idealism, otherwise things get worse, not better. I'm fairly sure sure it's the existence of Android that has made Apple back off on a few of their more draconian policies.
    • Re: (Score:3, Insightful)

      by UnanimousCoward (9841)

      I have a very selfish view on the C&B analogy. I too like my cathedral-like iPhone, but I'm glad that the unwashed masses :-) are pumping up the bazaar to put pressure on the cathedral landlord to innovate and evolve (READ: hurry up and let me switch to Verizon!).

  • by NicknamesAreStupid (1040118) on Thursday October 14, 2010 @12:29PM (#33895970)
    . . . is that the implementations are not completely vetted. This was a problem with Windows Mobile 5.x and 6.x. Some OEMs did not implement everything (e.g., DirectShow), and apps that used certain hardware such as the camera would unpredictably fail. It is one thing to have a bug in your app and quite another to have a bug in the platform your app depends upon. Until you determine for certain that it is not your fault, a.k.a. proving the negative, you catch all the flack. Good luck with that.
  • by Xaroth (67516) on Thursday October 14, 2010 @12:36PM (#33896128) Homepage

    Many of the highly modded posts right now seem to be missing some key information about exactly how Android is fragmented. It's not just the hardware - that can usually, but not always, be worked around in the ways they suggest. But it's also the software - every carrier and handset manufacturer likes to put their own little spin on the underlying software, and this causes more problems than one might expect.

    You get scenarios where some functionality is partially implemented or simply broken on some devices but not others, so you can't rely on simply querying to see if that functionality is available. The OS will happily tell you it's working, but it won't, so you have to find ways to work around it and/or implement long lists of special cases in the code. On some devices, the way that some input elements are displayed will have forced styling that's inconsistent with the rest of the platform, which you won't learn about until you've actually tried it on that device and seen your layout get destroyed. The autocomplete functionality or keyboard input method can vary substantially from device to device, potentially impacting how one's UI flows work. The list goes on.

    Limiting supported major OS versions and querying for hardware only solves part of the fragmentation problem. The fact that most every device has its own little fork of Android is more what causes the QA challenge. Since - generally speaking - one doesn't have these kinds of problems for mainstream desktop OS's, that's why people keep bringing up fragmentation of the Android platform as a major sticking point.

  • by No. 24601 (657888) on Thursday October 14, 2010 @12:43PM (#33896294)

    As a potential customer for an Android smartphone, I have to admit that the one thing that is holding me off buy an expensive (and thus likely more profitable for its manufacturer) phone is the fragmentation issue with Android. This is a very real problem that is the source of many if not most of the problems with Windows. A fragmented platform is one that is more costly to test on. Pure and simple. I don't want to buy a $400 phone today and discover a year from now that I can't run an app that my phone should support hardware-wise, but simply doesn't work because that phone no longer supported by its developer. This is a problem that Google has to address very soon. And, no they haven't adequately addressed it yet, even though Android is selling so well.

    While I don't like the "uniformity" of iPhone, testing is going to be cheaper and thus more likely to occur on that platform as opposed to Android.

  • by Todd Knarr (15451) on Thursday October 14, 2010 @12:51PM (#33896424) Homepage

    Sure, there's lots of versions of Android out there. But how many of those really matter? No, not in the sense of market share or anything, but in the technical sense of you have to worry about them in the code.

    I run into this programming for Unix. Sure, there's probably hundreds of versions of Unix out there, hundreds of thousands if you count variations in installed software. But in large part I can ignore them. The major question is usually "SysV or BSD?", that is are the system's APIs based on BSD's or System V's. Some libraries I care about version but I often only care about large swathes of versions, eg. I care whether OpenSSL is 0.9.7 vs. 0.9.8 but I don't care about 0.9.8e vs. 0.9.8n (other than that 8e has bugs that're fixed in 8n, but that won't usually affect my code). And of course different hardware has different screen resolutions, but then I shouldn't be hard-coding for exact screen resolution anyway. Make the relevant calls to find out the screen size and just adapt to it, and you'll usually find you have a few general sizes you need to handle and a plethora of one real close to one of those general sizes that you can just handle automatically. Eg. a 328-pixel width probably can use the same layout, icon sizes etc. as a 320-pixel width, just make the main area 8 pixels wider or add a pixel to each side of padding and border spaces to make up the 8 pixels.

    You don't handle driving a car by learning how to drive a Ford Focus, and then learning how to drive a Ford Fusion, and then learning how to drive a Chevy Cobalt, and then learning how to drive a Toyota Camry, and so on, and then when faced with a Hyundai Sonata you have to sit there and wait for someone to teach you how to drive one because you haven't driven one before. You learn how to drive a car, and you apply that general method to the particular kind of car you're in at the moment. The controls may be a bit different on each make and model, but the truly basic ones boil down to "Manual or automatic?". Beyond that, things like the headlight switch, turn signals, wipers, radio and all the rest are usually a matter of a couple minutes to sort out. If someone complained that there's thousands of makes, models and years of car out there and it's so much work learning to drive all of them, you'd laugh at them I'm sure. Computer systems are the same way: you don't learn every variant individually unless you're just starting out, you learn different kinds of systems and how to categorize any particular system by what kind it is in a particular area.

  • War Stories (Score:3, Insightful)

    by smcdow (114828) on Thursday October 14, 2010 @01:22PM (#33897078) Homepage

    Anyone who doesn't see this as a problem probably has never really had to deal with configuration management and Q/A issues in a production environment.

    I have, and if I were an app developer, this info would scare the crap out of me. Keeping your product stable, repeatable, and traceable on a single platform is hard enough.

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

Working...