Slashdot Mirror
Devs Grapple With 100+ Versions of Android
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).'"
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?
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.
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?
this signature has been removed due to a DMCA takedown notice
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.
No kidding!!! What do you say at this point?
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
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.
Someone flopped a steamer in the gene pool.
As I say in the original post (http://blog.tweetdeck.com/android-ecosystem), 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.
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.
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.
Someone flopped a steamer in the gene pool.
(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.
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?"
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
As a customer: Does Fragmentation mean that i actually have a choice what i buy?
I am very happy that good languages like java and objective C have put C++ out of hype.
I don't think so. The main issue seems to be that of Android residing on multiple dissimilar handsets, the OS changes this necessitates, and the programming challenges to support same. Of course that's going to be tougher to program for than a closed single hardware platform. The upside is that an application that runs on a majority of Android handsets is more likely to be purchased on a majority of Android handsets.
My Android handset has a larger than average screen resolution, and a few widgets don't play nice with it. I'd rather have the hardware choice and deal with the small incompatibilities than have one company tell me to take their phone and love it.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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.
That green slime had it coming.
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.
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.
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.