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
Motorola Droid is FWVGA, at 854x480
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.
Which you can just treat as 480x800, who will really notice the missing 54 pixels?
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.
So fragmentation will ALWAYS be an android issue until they say "here is our reference hardware platform(s) -- you must use of these three sets of features when building hardware."
To an extent that's already happening. Phone goliath Nokia among others are setting up an alternative to appstore:
Twenty-four mobile network operators have formed the Wholesale Applications Community to avoid fragmenting the apps market and to give developers one point of entry to all the members, the GSM Association announced on Monday.
The operators will now start working on uniting their existing developer communities, so developers will be able to go to one place to get their applications distributed instead of having to go through multiple application approval processes.
The community will also start working on a common development standard that should be ready within the next 12 months. The standard will be independent of phone type and operating system, according to the members.
That will allow them to better compete against Apple's App Store or Google's Android Market, which have independent and competing approvals processes tied to their phone or operating system.
"Developers are going to have a lot more access to a lot more customers," said Alex Sinclair, chief technology and strategy officer of the GSMA, at a news conference at the Mobile World Congress in Barcelona.
The Wholesale Applications Community members include: AT&T, China Mobile, Deutsche Telekom, NTT DoCoMo, Orange, Telefónica, Telenor Group, Sprint, Verizon Wireless and Vodafone. Together the operators in the group have about 3 billion subscribers, the GSMA said.
The group has the full backing of the GSMA and the list of supporters will grow in the coming days. "There are several people who are annoyed they couldn't get their name on the list in time," said Sinclair.
Apple is not among those clamoring to be added to the list, but if the company wants to join the group, "it will be welcome," he said.
Just like many phone manufacturers, operators have seen the success of Apple's App Store and want a piece of the pie. Some, including Orange, Verizon and Vodafone, have already launched their own application stores.
Mobile phone manufacturers LG Electronics, Samsung and Sony Ericsson have also voiced their support for the apps community.
The Wholesale Applications Community faces a number of obstacles, according to analysts at CCS Insight.
"Operators are trying to regain control of apps, but have a poor track record with this type of industry consortium," they said in a research note.
"Big challenges remain overcoming inconsistency between standards bodies like JIL and Bondi," the analysts continued, referring to the Joint Innovation Lab created by a group of mobile operators including Vodafone, China Mobile, Softbank and Verizon Wireless, which also has the support of phone manufacturers LG Electronics, Research in Motion, Samsung Electronics and Sharp.
There is no competition between the Wholesale Applications Community and JIL, as all members of JIL are also members of the community, according to Sinclair.
"The last thing we wanted was a Jack versus JIL situation," he said. The groups hope to converge their various specifications within 12 months, he said.
These are some seriously big names, big enough to knock it out of the park if they wanted to.
What he can't kill, he has sex on. Trent.
It amuses me to no end
Is that you, Lo Pan?
What he can't kill, he has sex on. Trent.
Even now lots of web developers want to treat the browser view like a physical sheet of paper, demanding iron-fisted control over placement of everything on the page. This leads to all kinds of work to maintain the control. I keep wishing more web developers would get over this. Not only would I find it a lot easier to actually make use of their work on smaller screens (my Android phone, my netbook...), I think in the end it would be a lot easier for the developers, too.
It sounds like mobile application developers often have the same problem...
Hacker Public Radio is our Friend
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.
Oh for.. look, how do you propose to make e.g. a GPS tracking app run on a device that doesn't have GPS? (yes, I'm aware all Android devices must have GPS) How is allowing apps to use specialised hardware on Android any worse than allowing apps to use the compass on an iPhone 3GS, but not on a 3G? or camera apps on an iPhone but not an iPod?
The only way to avoid fragmentation as you define it is to have one unchanging, stagnant piece of hardware that only runs one version of the OS, on one network from one vendor. Even Apple doesn't do that.
Why would anyone engrave "Elbereth"?
Indeed. There have been several occasions on which I was forced to upgrade the OS on my iPod Touch, just to use a new app. ("Forced" as in: The app would not bloody install on the software version I was running.)
And, of course: On the iPod Touch, OS upgrades sometimes cost actual money.
So. If we assume that fragmentation is a problem, then it is very plain that it is not an Android-specific problem.
Kid-proof tablet..
This is my thoughts exactly.
You're gaining a huge install base by having Android compatible with multiple handsets. People like choosing different feature sets, not everyone wants a keyboard for example, but some wouldn't live without one. Some people will pay extra for a phone with excellent gaming performance, others won't care.
This is akin to figuring out if a hypothetical game will run on User X's computer. Ship the game for a console if you don't want to deal with it.
To be fair, for the wide variety of devices Android supports, there are very very few compatibility glitches.
- Michael T. Babcock (Yes, I blog)