Slashdot Mirror
Android Compatibility and Fragmentation
tbray writes "Here are the details on the Android Compatibility Program — which combines the source, a formal compatibility spec, an open-source test suite, and access to the Android Market as reward for good behavior (program page). People like to rant about the subject of fragmentation, so here's TFM that they should be R'ing first."
Fragmentation is mostly FUD, there are only a few screen sizes and the OS changes are pretty minimal.
* Bugs - devices might simply have bugs, such as a buggy Bluetooth driver or an incorrectly implemented GPS API.
* Missing components - devices might omit hardware (such as a camera) that apps expect, and attempt to "fake" or stub out the corresponding API.
* Added or altered APIs - devices might add or alter APIs that aren't part of standard Android. Done correctly this is innovation; done poorly and it's "embrace and extend".
Each of these is an example of something that can make an app not run properly on a device. They might run, but they won't run properly. These are the things that I spend my time preventing.
The only thing I might add is that devices of different resolutions can be annoying, especially if your app has static images or custom widgets.
Qxe4
I think there's only two right now - HVGA (320x480), and WVGA (480x800), though there may also be VGA sized screens as well.
The big issue is that the density increases but the screen size remains the same, so if your app isn't DPI aware things get small and hard to control. Desktop app developers tend to be fixed DPI - a larger window lets you show more information. Ditto web developers. But high-DPI displays means you don't want to show more information, but you should scale everything up. Even pictures if it makes the picture grow from literal thumbnail to larger blob.
DPI-awareness is a difficult thing and many apps still get it wrong on the desktop, if you switch your Windows desktop to high-DPI mode.
"The thing is, nobody ever defined “fragmentation”"
Let me try: You have several different versions of Android 'in the wild' on different phones, different carriers, etc. There are different stances on whether these version of Android can be updated (based on manufacturer) etc. yadda yadda
Now, looking at that situation, I would say 'fragmentation' is more along the lines of 'Is it going to remain easy for to target Android phones in general considering how many versions currently exist [/not obsolete] concurrently?'
So yes, it is mainly about compatibility. But it also means (much like any other platform) if the version leaping continues (and so many versions exist concurrently all the time) playing to the 'lowest common denominator' of supported features will be required
this should have been made perfectly clear from google's side from day one. Yet everyone kept talking about android marketplace as if it was a part of the android source until the first android based devices without marketplace showed up, and none could figure out why.
i only ran into it after ranting about google's mismanagement of marketplace access on some forum, and got a link handed to me.
another issue is that 1.6 required that a compatible device could function as a phone. So any device thats been in development since 1.6 was first released, wont have marketplace unless its a phone or stalls its release until they can get 2.1 or newer working and approved by google. And even then the max resolution of the screen is 800x600, and i think the screen size is in the 5-7" range.
basically, google is lagging badly behind where third parties want to go with android. And its not helping that marketplace is only really usable in select nations so far (and when a sim is inserted into the device).
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
The hardware vs onscreen keyboard does not require two apps.
The iphone is not one platform, there are 3 different phones and there is about to be a forth.
You will have either fragmentation, or stagnation as the device gets older. Even something totally controlled like the iPhone. As time goes on, one of three things will happen:
1) Apple will introduce new iPhones with features the old ones do not, and cannot, have such as higher rez screens, faster CPUs, etc. Software for these new phones will not run properly, if at all on the old ones. The phones will fragment along the lines of new and old.
2) Apple will refuse to introduce any features that would break compatibility with older phones. They maintain total compatibility through keeping various things at one spec. This leads to stagnation of increasing proportions as time goes on, such that new iPhones are literally years behind competing products.
3) Apple discontinues all support for older iPhones. They have the service providers remotely kill the hardware so you are required to purchase new hardware.
There's just no way around it. If you want new devices to have new capabilities, well it will lead to fragmentation. There are plenty of things you can do to help, particularly in making sure newer devices can seamlessly run older software, but you can't have all sorts of new stuff and have everything work just like it did before.
DPI awareness is mostly a problem if your GUI toolkit is pixel based, rather then vector based. Especially if those pixels have hardcoded limits.
all the major linux UIs are moving towards using vector graphics for instance, and i think microsoft headed the same way with vista and later (tho win32 legacy programs will still be a pain, and why microsoft wants to see xp and older dead).
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
It's not 54, it's 54*480 which is 25920. Which is a non trivial amount on a device that small.
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
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.
Yet strangely many people are successfully doing this.
Completely wrong. Where are you getting this from?
Over 100,000 Android devices activated per day.
No you don't. You have no idea what you're talking about. And you're at Score:4 right now, which is shameful.
Ugh. You shouldn't have posted because almost everything you have said is just completely wrong.
The Android developer platform is extraordinarily universal. There's a density independent pixel format (which is how an app looks almost the same on a 320x480 screen as it looks on a 480x800 screen), support for varying screen ratios, a single way to inter-operate with the camera and send emails and read the GPS signal and get orientation signals, or even do advance OpenGL graphics.
One app to rule them all.
There are of course differences and occasionally "quirks". If you make a rich graphics game it's going to run terribly on a G1. Flash is only available on some devices. And of course if you have to target a newer API, presumably because it has a feature that you can't live without, you limit your app to that version and above (just as if I use Transactional Filesystem calls my Windows app would be Vista or newer).
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 targets 2.1. They wanted to use animated wallpaper, quick contact bars, and so on, to highlight the best of the contemporary platform. Aside from the fact that about 50% of Android phones are running 2.1 right now, most other phones are going to see a 2.1 upgrade in the relatively short term. I suspect Google intentionally targets 2.1 to try to motivate the vendors to expedite their upgrades.
You will find the answer to this mystery in "The Cathedral and the Bazaar" by Eric S. Raymond [1992].
Basically, Microsoft and Apple are code cathedrals. Using the Cathedral system they can organize the labor of a great many people. In a Cathedral you can do anything that is permitted to be done in that Cathedral - which can be almost anything that brings the controlling powers profit really. But if you want to do something they don't want you to do, then you can't and there's nothing you can do about it but leave the cathedral or accept that you can't do that thing.
Android and the Linuxes are the Bazaar. It's noisy and chaotic. It can be harder to find things. Some of the things you find in a Bazaar are quite crude. But in the Bazaar you can do anything you want any way you want. The Bazaar is run by everybody in it, for each to his own benefit. Almost anything that can be found in the Cathedral can also be purchased in the Bazaar by a man with ready cash. Almost anything.
One thing that can be bought in the Cathedral but not in the Bazaar is the preventing of things you don't want others to do. If somebody wants to prevent the use of VP8 or Flash in the Cathedral, or the development of hardware platforms that don't run Windows, well, anything can be proscribed if the price is right. The Cathedral is run by the head priest, and not specifically for your benefit but primarily for the benefit of the Cathedral - because it's this self serving nature that makes Cathedrals persistent and powerful.
One is not necessarily better than the other. Each has merits, each has uses.
Help stamp out iliturcy.