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).'"
They forgot one bit of relevant information. So how long did it this massive job take?
This is not the penguin you're looking for.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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.
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 single, portable, upgradable OS like Apple and Microsoft are doing.
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
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!
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
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.
Obama's legacy: (N)othing (S)ecure (A)nywhere and (T)error (S)imulation (A)dministration
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
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.
You have an interesting definition of the verb "sell". Apple makes over 50% of all the profit in the mobile handset world despite their tiny market share (which is currently about the same as Google's if you exclude iPod Touch and iPad). Google gives Android away for free, and carriers are doing the same with free or buy-one-get-one deals. Profit drives innovation, so we'll see where things stand in a few years. No one can afford to keep giving things away for free indefinitely, so when users start paying the true costs are they still going to prefer it?
E pluribus unum
The flip side to that is it takes a whole lot less testing to hit the targets on the iphone / ipod / ipad. In fact a couple of my apps did not require any modification when the ipad was released it just ran.
Got Code?
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.
If the 'you can't give stuff away and make a profit' argument held in reality Google would be bankrupt instead of one of the most profitable companies in the world. That 'free' OS? First and foremost it ships by default with a ton of Google apps installed, all of which generate advertising revenue and market information that Google uses to generate it's profit. Secondly, since a ridiculously large majority of people still use Google for their search it stands to reason that the more connected people are to the internet the more money Google makes, even without their apps. Google makes money off of android the same way it makes money off of search: collecting information about its users, and selling ad space more effectively than the competition.
As for the carriers... really? You really think that they just give away phones 'for free'? Here's what you should hear when you listen to those advertisements:
We'll give it to you for 'free'*
*Where 'free' is equal to $720 ($30 per month * 24 months).
. . . 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.
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.
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.
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.
Maybe they should also stop doing Gmail and Google search for free. They are bound to run out of money soon. Poor idiots.
Why is it so hard to only have politicians for a few years, then have them go away?
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.
I don't think so.
The 'success' of Android is good for everyone (several strong competitors in the smartphone OS market push development and innovation) but too many versions and handsets at this young age of Android make the future easy to predict: it will only get worse.
There is going to be a small industry built simply to provide testing for Android devices until either a) Android flavors congeal or b) developers start focusing on specific segments of the Android market.
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.
In the course of every project, it will become necessary to shoot the scientists and begin production.
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 native development (which I would never recommend unless absolutely necessary).
Bye!
For most app development, I would be comfortable applying Pareto's Principle. I don't have any data, and unless I'm mistaken about how fractured the Android OS implementations are, then I imagine that 10% of my effort would work on 80% of the market. The rest of the market would be considered fringe and not worth a return. Caveat Emptor for those who bought those versions.
Finally, given time, there will be some certifications across vendors to assure compliance. It's messy, but that's the cost of freedom and access. It beats dictatorships and walled gardens.
Whoohoo!!!! The Microsoft astroturfer strikes again!!!!
This is a problem, and one of the things that risks ruining Android's "openness" - it's open to the carriers, who have the money & staff to spend on locking your device down just the way they like it. It's open for the carriers, not the *vast majority* of consumers, who will take what the carriers offer, and form their impression based on that.
In many ways, the iOS vs. Android 'battle' isn't really a battle between Google & Apple, it's a battle between Apple's "the phone maker dictates the feature set" & the carriers' "the phone carrier dictates the feature set" models. If you're smart enough to know how to root your Android device, great; if you're smart enough to know how to root your Apple device, great; but neither of the platforms at this point is particularly "open" in terms of what the *consumer* can do with it.
A user with a PC can add ram, change video cards, and upgrade CPU's to meet the requirements for a application. Users of phones locked into contracts are stuck with what they have until they can buy another phone. Also the performance levels between low end PC's and high end PC's are not as bad as with low end phones vs top model phones. Almost any app created on a PC is going to run because the hardware has the power to run a full OS plus many apps at the same time. Lots of room to work with. Low end phones that have just enough power to run the OS present problems for apps that demand more. The available features also present a problem. If something is in 2.2 but not in 2.0 the app isn't going to work. On a PC they all have the same abilities for the most part. On the OS end unless you design your app to only make use of a feature in vista or windows 7 and I can't think of anything that does it's going to work on XP too. Even if designed only for windows 7 HP, toshiba, Dell don't lock your PC from using a new OS. The customizations on android by cell companies also present a problem. PC makers don't replace the windows GUI for there own. A developer does not have to work with a custom Dell GUI or custom HP GUI. The machines that do have a custom GUI are specialized task machines that are not part of the picture like manufacturing tool machines. OS upgrades in the windows world are 3 years apart as well. It's easy to list a apple app as being for iPhone 3GS and iPhone 4 only. Or iOS 4 only. For android phones a developers best bet is to list app compatability like this, works on driod phones with android 2.2. Might work on others and might not. Even the most powerful phone is a small % of the power of a low end PC. Android is a fail and you can blame phone companies for it. And popularity has nothing to do with if a product is a win or fail. Windows is a fail to but is on 90% of PC's. Android sells well it's open which is a win but it's also a fail with fragmentation. Those that dismiss the issue saying it's not a problem are lying to themselves.
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!).
Twelve-and-three-quarter inches. Unyielding. This wand belonged to Bellatrix Lestrange.