I've developed 7 Android apps and the huge diversity of Android versions and devices out there really is a nightmare. I have an enormous number of extra code paths due to it. All this extra complexity makes apps tougher to write, tougher to test, tougher to debug, tougher to enhance.
Some examples of bizarre stuff I have to do: Android 1.5 has a Java NIO bug that forces me to copy data to a temporary array on its way to buffers to be rendered via OpenGL. This hurts performance on older phones that often need it the most. It also means I have to do more testing to make sure both code paths are well exercised. I bet many developers don't even realize the bug is there an just have broken OpenGL apps on Android 1.5. The bug fix would be trivial to port back to Android 1.5, which would make it drastically more likely to get on to these older phones, but there's no sign this will ever happen. Do I keep code paths like this? Or do I give up the 25% of the market that is Android 1.5? Neither is desirable.
Another really frustrating one is how I have to detect specific devices and request certain size depth buffers just to get decent performance. Hardware graphics acceleration is only enabled on the Samsung Galaxy for depth buffer size 16, for example, not for no depth buffer. Depth buffer size 24 works best on the Droid, etc.. The Galaxy has had this bug for a very long time. The Archos tablet has no hardware acceleration and there are promises that cheaper phones will be similar. Do I write all the extra code for adjusting rendering for each of these? Or do again give up large swaths of the market?
Anyway, I'm constantly dealing with issues like this. It is really disappointing that Android team, the carriers, and the device manufacturers don't do more to prevent it. Doing things like back porting fixes so that older phones can be more trivially updated would help enormous numbers of apps and app developers compared to the very few resources needed on Google's part to do it.
Meanwhile Google isn't even interested in solutions to these problems from what I've seen. One developer brought up another potential solution during a session at Google IO. He suggested making the highest level of Android a distributable framework, like.NET. This would allow updating it much easier. Not nearly as many phones would be stranded with old, buggy versions of the Java portion of Android at least. The Google staffers just brushed the idea off without even discussing it. They said fragmentation should really be called progress and to deal with it.
This isn't really surprising. If you look at a recent app produced by Google, the Twitter app, you'll see that it is unavailable to a huge percentage of the market because they don't support older versions of Android with it. Independent developers can't afford to ignore large sections of the marketplace like that. Google isn't in the app business, so the Googlers just go ahead and ignore the issue. You can see a graph of the versions of the devices on Android Market here: http://developer.android.com/intl/fr/resources/dashboard/platform-versions.html [android.com]
And of course there are plenty of devices not on Google's market, many of which are even less likely to receive updates because they are updated by PC software rather than over the air.
So Googlers aren't even eating their own dog food on this issue. They just make app developers put up with it on their own, never experience it themselves, and then ridicule the issue as a bogeyman. I think I was happier before I read the blog post. At least then I could imagine they were working hard on the issue and just doing terrible at it. Now I know they don't even consider it an issue.
Or do I give up the 25% of the market that is Android 1.5?
Most of the phones that run 1.5 right now are terribly underpowered -- OpenGL on a G1 is almost a sick joke.
If you're targeting OpenGL, you probably should cut your losses and cut them.
If you look at a recent app produced by Google, the Twitter app, you'll see that it is unavailable to a huge percentage of the market because they don't support older versions of Android with it.
The Twitter application is an Android showpiece app, which is why it targe
The GPU of the G1 is horribly underpowered, the processor not supporting NEON, and the RAM on the device is barely capable of running the OS alone. The G1 is the reason gaming on the Android platform is still so immature.
Phones like the Nexus One, the Samsung Galaxy S, and the Moto Droid are magnitudes more powerful in the graphics department.
But a lot of the time you don't need that much juice. Any 3D hardware has the power to run something with the complexity of the original GLQuake, for example. Most game developers aren't after staggering graphical performance. They just need hardware that will draw a few textured objects.
But a lot of the time you don't need that much juice. Any 3D hardware has the power to run something with the complexity of the original GLQuake, for example. Most game developers aren't after staggering graphical performance. They just need hardware that will draw a few textured objects.
Maybe Droid developers. Meanwhile, the big studios are targetting the iPhone.
I have to agree with csartanis: Hacked system images like Cyanogen show that G1 hardware is, at least, adequate.
The problem is OEMs have no incentive to put money into handsets they sold two years ago. Google has to take up the slack, either by creating incentives to update older handsets, or legitimizing hacks like Cyanogen as a form of "aftermarket upgrade."
The problem is OEMs have no incentive to put money into handsets they sold two years ago.
The OEMs should be profiting from their own app stores.. profits being driven from their customers. That they don't get this yet is hugely disappointing.. appstores - and naturally, software updates - are of huge interest to "next-gen" cell users.. but the carriers just don't want to get into it.
I suppose its because of the draconian US laws about content delivery over telephone networks, in the end, though..
He suggested making the highest level of Android a distributable framework, like.NET
I thought Java was a distributable framework, like.NET. And I doubt every.NET runtime (including Mono etc) is completely bug-free either.
And Google have already said they planned to spin off components of the OS, where possible, to make updating those components much easier.
Look, you make a fair point about dealing with different hardware and different bugs, and I sympathise, but these sort of time/market tradeoffs are nothing new, especially on popular platforms (Windows and Linux PCs, Macs too, huge var
The bug fix would be trivial to port back to Android 1.5, which would make it drastically more likely to get on to these older phones, but there's no sign this will ever happen. Do I keep code paths like this? Or do I give up the 25% of the market that is Android 1.5? Neither is desirable.
If they made an update, say 1.5.1, you would still want the old code path for the devices that hadn't upgraded - which leaves you in exactly the same position you are in now.
Another really frustrating one is how I have to detect specific devices and request certain size depth buffers just to get decent performance.
I'm not sure what you want Google to do about this. Do you want Google to dictate a certain hardware spec to all the vendors? If you favor a consistent platform (more or less) from a well-known set of hardware on a single carrier, you should go with Apple.
This is simply software engineering - taking one set of trade-offs for others.
I'm not sure what you want Google to do about this. Do you want Google to dictate a certain hardware spec to all the vendors? If you favor a consistent platform (more or less) from a well-known set of hardware on a single carrier, you should go with Apple.
This is simply software engineering - taking one set of trade-offs for others. If you want newer features, you target the later API, at the cost of a smaller audience. These are all very straight-forward cost/benefit decisions, that YOU get to make, not Go
Yet, you're having to ignore large portions of that install base if you're going with newer features of the OS. You have to decide if that new feature that may be required for your app is worth alienating a significant part of the Android install base. At least with Apple, if they add a feature to the OS, you can reliably begin using it when its released, and be assured that most of your install base can use it.
The features that didn't exist before wouldn't exist today if they wanted to make you happy.
The options are either properly predicting the future and making all future features available in advance, but not letting them work (since they can't yet), or waiting till those features are relevant and adding them to the api.
Either way, unless you want a stagnant platform that never evolves, you're going to have API changes to deal with.
That's not the point and you know it. The point is that there is a significant number of phones out there that do not have access to these new features, and in all likelyhood never will. Over half the phones out there are on 1.5 or 1.6.
The point is that the iPhone doesn't have this problem, or at least in any way close to Android, because the vast majority of the handsets are running the latest OS. You really only have to target the latest version. With Android, you can't do that. You either use the reall
Everything you describe seems to apply to Windows, Linux, and just about every other operating system there is. If you look at most games, they have to do serious optimization to handle older video cards, including separate code paths. It sucks, but it isn't Android only. I am confused though as to why there are phones running these older versions. Why is that?
HTC doesn't offer a 2.1 upgrade for my HTC Tattoo. Period. It's supposed to "real soon now", it doesn't. Is Google at fault? Is Android? Is HTC? You know what, I don't care, it just doesn't work.
I honestly believe that 1.5 users (and some 1.6) are not heavy users that will be purchasing a lot of apps.
the iphone set a trend of buying a replacement phone at least every 18 months. how many 1.5 users are just about to buy a new phone?
Also, what is the volume of market usage (sells) on this bracket (1.5 users)
I agree that fragmentation is not effective, but is far from being an issue or something unacceptable.
I think that newer phones deserve better attention. If I bought a new phone 2.2 or 2.1 I di
There are still 1.5 and 1.6 devices being sold. The Hero, the Droid Eris, and the G1 are still being sold, and with the exception of the Hero, have no plans of being updated.
I had to read this a few times to make sure this post wasn't a few months old. Both the hero and eris have received an OTA 2.1 upgrade in may. The only US 1.5/6 devices are the G1, MyTouch and Behold 2.
Wow, you just made me re-animate my/. account.
You have just described some of the major reasons I have gone in a great big circle around the Android phones, even if I find the *idea* of a Linux-based phone OS by Google very appealing. I have an iPhone that has all the same advantages of the Apple computers, only amplified: Complete hardware control and testability. They might be a little more expensive, and Apple might be dickheads, but they still deliver a better end product to the users.
Maybe in a ye
"When it comes to humility, I'm the greatest."
-- Bullwinkle Moose
It's a huge issue to app developers, not Googlers. (Score:5, Informative)
I've developed 7 Android apps and the huge diversity of Android versions and devices out there really is a nightmare. I have an enormous number of extra code paths due to it. All this extra complexity makes apps tougher to write, tougher to test, tougher to debug, tougher to enhance.
Some examples of bizarre stuff I have to do:
Android 1.5 has a Java NIO bug that forces me to copy data to a temporary array on its way to buffers to be rendered via OpenGL. This hurts performance on older phones that often need it the most. It also means I have to do more testing to make sure both code paths are well exercised. I bet many developers don't even realize the bug is there an just have broken OpenGL apps on Android 1.5. The bug fix would be trivial to port back to Android 1.5, which would make it drastically more likely to get on to these older phones, but there's no sign this will ever happen. Do I keep code paths like this? Or do I give up the 25% of the market that is Android 1.5? Neither is desirable.
Another really frustrating one is how I have to detect specific devices and request certain size depth buffers just to get decent performance. Hardware graphics acceleration is only enabled on the Samsung Galaxy for depth buffer size 16, for example, not for no depth buffer. Depth buffer size 24 works best on the Droid, etc.. The Galaxy has had this bug for a very long time. The Archos tablet has no hardware acceleration and there are promises that cheaper phones will be similar. Do I write all the extra code for adjusting rendering for each of these? Or do again give up large swaths of the market?
Anyway, I'm constantly dealing with issues like this. It is really disappointing that Android team, the carriers, and the device manufacturers don't do more to prevent it. Doing things like back porting fixes so that older phones can be more trivially updated would help enormous numbers of apps and app developers compared to the very few resources needed on Google's part to do it.
Meanwhile Google isn't even interested in solutions to these problems from what I've seen. One developer brought up another potential solution during a session at Google IO. He suggested making the highest level of Android a distributable framework, like .NET. This would allow updating it much easier. Not nearly as many phones would be stranded with old, buggy versions of the Java portion of Android at least. The Google staffers just brushed the idea off without even discussing it. They said fragmentation should really be called progress and to deal with it.
This isn't really surprising. If you look at a recent app produced by Google, the Twitter app, you'll see that it is unavailable to a huge percentage of the market because they don't support older versions of Android with it. Independent developers can't afford to ignore large sections of the marketplace like that. Google isn't in the app business, so the Googlers just go ahead and ignore the issue. You can see a graph of the versions of the devices on Android Market here:
http://developer.android.com/intl/fr/resources/dashboard/platform-versions.html [android.com]
And of course there are plenty of devices not on Google's market, many of which are even less likely to receive updates because they are updated by PC software rather than over the air.
So Googlers aren't even eating their own dog food on this issue. They just make app developers put up with it on their own, never experience it themselves, and then ridicule the issue as a bogeyman. I think I was happier before I read the blog post. At least then I could imagine they were working hard on the issue and just doing terrible at it. Now I know they don't even consider it an issue.
Re: (Score:3, Insightful)
Most of the phones that run 1.5 right now are terribly underpowered -- OpenGL on a G1 is almost a sick joke.
If you're targeting OpenGL, you probably should cut your losses and cut them.
The Twitter application is an Android showpiece app, which is why it targe
Re: (Score:2)
My G1 runs 2.1 and opengl apps run great... where have you been?
Re: (Score:1)
The GPU of the G1 is horribly underpowered, the processor not supporting NEON, and the RAM on the device is barely capable of running the OS alone. The G1 is the reason gaming on the Android platform is still so immature.
Phones like the Nexus One, the Samsung Galaxy S, and the Moto Droid are magnitudes more powerful in the graphics department.
Re: (Score:1)
Re: (Score:1)
But a lot of the time you don't need that much juice. Any 3D hardware has the power to run something with the complexity of the original GLQuake, for example. Most game developers aren't after staggering graphical performance. They just need hardware that will draw a few textured objects.
Maybe Droid developers. Meanwhile, the big studios are targetting the iPhone.
Re: (Score:1, Informative)
The graphics-intensive, pretty 3D games on the iPhone are mostly horribly sluggish. Not very impressive. The iPad is better, but not amazingly so.
Nobody, nobody targeting mainstream mobile devices is doing 3D stuff beyond what we saw on PCs ten years ago.
Re: (Score:1)
pretty 3D games on the iPhone are mostly horribly sluggish. Not very impressive. The iPad is better, but not amazingly so.
Woohoo Apple bashing the form of an unsubstantiated anecdote. Weee slashdot!
Re: (Score:2)
I have to agree with csartanis: Hacked system images like Cyanogen show that G1 hardware is, at least, adequate.
The problem is OEMs have no incentive to put money into handsets they sold two years ago. Google has to take up the slack, either by creating incentives to update older handsets, or legitimizing hacks like Cyanogen as a form of "aftermarket upgrade."
Re: (Score:2)
The problem is OEMs have no incentive to put money into handsets they sold two years ago.
The OEMs should be profiting from their own app stores .. profits being driven from their customers. That they don't get this yet is hugely disappointing .. appstores - and naturally, software updates - are of huge interest to "next-gen" cell users .. but the carriers just don't want to get into it.
I suppose its because of the draconian US laws about content delivery over telephone networks, in the end, though ..
Re: (Score:2)
He suggested making the highest level of Android a distributable framework, like .NET
I thought Java was a distributable framework, like .NET. And I doubt every .NET runtime (including Mono etc) is completely bug-free either.
And Google have already said they planned to spin off components of the OS, where possible, to make updating those components much easier.
Look, you make a fair point about dealing with different hardware and different bugs, and I sympathise, but these sort of time/market tradeoffs are nothing new, especially on popular platforms (Windows and Linux PCs, Macs too, huge var
Re: (Score:2)
The bug fix would be trivial to port back to Android 1.5, which would make it drastically more likely to get on to these older phones, but there's no sign this will ever happen. Do I keep code paths like this? Or do I give up the 25% of the market that is Android 1.5? Neither is desirable.
If they made an update, say 1.5.1, you would still want the old code path for the devices that hadn't upgraded - which leaves you in exactly the same position you are in now.
Another really frustrating one is how I have to detect specific devices and request certain size depth buffers just to get decent performance.
I'm not sure what you want Google to do about this. Do you want Google to dictate a certain hardware spec to all the vendors? If you favor a consistent platform (more or less) from a well-known set of hardware on a single carrier, you should go with Apple.
This is simply software engineering - taking one set of trade-offs for others.
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Your statement is a red herring.
The features that didn't exist before wouldn't exist today if they wanted to make you happy.
The options are either properly predicting the future and making all future features available in advance, but not letting them work (since they can't yet), or waiting till those features are relevant and adding them to the api.
Either way, unless you want a stagnant platform that never evolves, you're going to have API changes to deal with.
On that note, how come my 1994 Newton MessageP
Re: (Score:2)
That's not the point and you know it. The point is that there is a significant number of phones out there that do not have access to these new features, and in all likelyhood never will. Over half the phones out there are on 1.5 or 1.6.
The point is that the iPhone doesn't have this problem, or at least in any way close to Android, because the vast majority of the handsets are running the latest OS. You really only have to target the latest version. With Android, you can't do that. You either use the reall
Re: (Score:2)
Its exactly the point. If new iphones come out with lets say dual cameras, the new OS and API will support that but the old phones never will.
New features will always cause fragmentation. Your only way out is to stagnate in hardware development or to have perfect forward knowledge.
Re: (Score:2)
This is the strength of the open platform.
Having a limited audience and increased development costs is a strength? Awesome.
Re: (Score:2)
Everything you describe seems to apply to Windows, Linux, and just about every other operating system there is. If you look at most games, they have to do serious optimization to handle older video cards, including separate code paths. It sucks, but it isn't Android only. I am confused though as to why there are phones running these older versions. Why is that?
Re: (Score:2)
HTC doesn't offer a 2.1 upgrade for my HTC Tattoo. Period. It's supposed to "real soon now", it doesn't. Is Google at fault? Is Android? Is HTC? You know what, I don't care, it just doesn't work.
Re: (Score:2)
Again: I don't care. And Cyanogen doesn't run on my phone.
Re: (Score:1)
Everything you describe seems to apply to . . . just about every other operating system there is.
One exception is Palm/HP's webOS. New versions of the operating system are pushed over the air to all phones shortly after release by Palm.
Re: (Score:1)
Reddit picked up on this thread here http://www.reddit.com/r/programming/comments/cal37/comment_on_slashdot_detailing_the_so_called/
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re:It's a huge issue to app developers, not Google (Score:1)