Android Compatibility and Fragmentation 211
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 (Score:5, Informative)
Fragmentation is mostly FUD, there are only a few screen sizes and the OS changes are pretty minimal.
Re:Fragmentation is mostly FUD (Score:5, Informative)
Because it means everything, it actually means nothing, so the term is useless. Stories on “fragmentation” are dramatic and they drive traffic to pundits’ blogs, but they have little to do with reality. “Fragmentation” is a bogeyman, a red herring, a story you tell to frighten junior developers. Yawn.
Re: (Score:2)
Just because you're paranoid doesn't mean they're not out to get you.
I have an HTC Tattoo, the I can't use a bunch of apps I'd love to use on it, a couple others crash. Fragmentation has pretty made Symbian a platform only the nerdiest geeks code for, I'd love to see that not happen to Android too.
Re: (Score:2)
I have an HTC Tattoo
I wonder if that's more or less geeky than having a Tux tattoo [google.com]?
Re: (Score:2)
Pay no attention to the man behind the curtain.
And in any mobile device (Score:4, Insightful)
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.
Re:And in any mobile device (Score:5, Insightful)
3b) apple makes sure to plan for a "incompatible" hardware upgrade when most of the early adopter contracts about to expire, and therefor they will be looking around for a replacement anyways.
planned obsolescence is a "wonderful" thing.
Re: (Score:2)
For sure, but that doesn't prevent fragmentation. People will refuse to upgrade. Just how it goes. Won't be the majority I suspect, most people who get smart phones like new gadgets and get new ones often. However there will be a non-trivial amount that won't. So as I said: You get fragmentation or stagnation.
Re: (Score:2)
And that is where the non user replaceable battery comes in. You see after 2 years my Iphone 3g is running about 70% of it's battery life than when i first got it. In 6 months my phone will be almost 2.5 years old and I will be ready for the next phone anyways.
The real question is will I find a decent android phone with a decent UI that can easily surf the web, and you know make calls, or will i have to upgrade to an Iphone HD that comes out in 6 weeks?
Droids always come off as half finished to me, with n
Re: (Score:3, Insightful)
1) 3GS has better processor, graphics, and more memory than 3G. iPhone has better location and a camera, iPod Touch does not. These differences exist, they just don't currently impact more than a few niches of applications.
2) Clearly not happening.
3) If you ignore the hyperbolic nonsense about remotely killing devices, this is happening. The original iPhone and iPod Touch devices are not supported by iPhone OS 4.0. The iPhone 3G is no longer available for sale, on the same trajectory as the original
Re: (Score:3, Insightful)
if you read your own post - point 1 applies to android just the same. the version differences only impact a few niches of applications.
Same with the screen resolution issue. "If [the developer] followed the UI guidelines and used auto-resizing and system fonts", an Android app will fit whatever size screen it's running on.
Re: (Score:2)
Software for these new phones will not run properly, if at all on the old ones.
What makes you say that? You don't think Apple has built iPhone OS APIs to take such things into account?
Re: (Score:2)
1. Apple introduces new devices once a year, and support reaches back for at least 2 years. With Android devices, you get new devices on the market a few times per month, and the manufacturer will not support devices older than 6 month, when they have become fossile devices. There is a big difference here. And Android devices are everything from phones to full size computers, all with different hardware and capabilities. It is like coding for the PC.
2. Apple will leave features out from old models. iPhone O
Re:Fragmentation is mostly FUD (Score:5, Informative)
Agreed on screen changes. But there's a major psychological issue with people shelling out hundreds of dollars for what they perceive as the "latest, greatest" phone, and then 6 months later being told they are stuck on version 1.6 when we've already gone through 2.0, 2.01, 2.1 and are about to see 2.2.
If you think this isn't real, go see the thread on Engadget right now on this topic. People are angry about it. Frankly, I'd be pretty angry if my phone was still running 1.5 (apparently a third of Android phones out there are still stuck on this old-ass version as of a few weeks ago, and a third or so were still on 1.6, with another third on 2.1).
Mind you, almost every phone has at least an *unofficial* community-produced ROM that will get them the 2.1 features and apps. Even the klunky G1 which was the first Android phone can get there - it's just not officially supported, presumably because Google, HTC and T-Mobile don't want to push down an update that replaces the SPL - I guess they think the support costs from doing that would be higher than the PR costs of not doing it.
So yeah, the issue is a bit overdone - or rather, it's not so much fragmentation of hardware specs that's the issue - I think allowing some hardware diversity is a good thing, it encourages innovation. The real issue is lack of hardware support from manufacturers and telcos after the point of sale. Google has up-to-now done basically nothing to force guaranteed support periods and guaranteed maximum release delays on a newly released OS version. I saw nothing in the article to address this.
*That* is the real issue that gets people riled up. *That* is what the users at Engadget are seething over. They want 2.1. They don't want to be told "we can't support 2.1 on your 8 month old handset, eat a dick" by HTC or Sprint or Verizon or whoever. Google is letting the carriers and hardware manufacturers release products, pimp them, then drop support 3 months later. They need to force some structure on customer support - I don't think every piece of hardware should be supported forever, but I think a year of official support for the latest version releases after the last date you sold the product is a minimum, and I think that a 2-3 month lag from Google's release of a new version to an officially supported ROM from the hardware vendor and carrier is a maximum. If a vendor falls outside of those parameters, every handset of their should be banned from the market, effective instantly.
That's the stick they need to support their customers. If Google doesn't man up and do this, I'm afraid it will do a significant amount of harm to the rapidly developing Android market.
Re:Fragmentation is mostly FUD (Score:5, Insightful)
I don't think every piece of hardware should be supported forever, but I think a year of official support for the latest version releases after the last date you sold the product is a minimum
If the contract period is 2 years, and the early termination fee is based on the contract period, they better support the phones for 2 years.
Re: (Score:2)
There's support and then there are upgrades. There's really no requirement, explicit or otherwise, for Sprint to offer a 2.1 upgrade for the HTC Hero.
Re: (Score:2)
Feh.
I'm on Verizon, no contract, and I still want updates.
Re: (Score:2)
That's the stick they need to support their customers. If Google doesn't man up and do this, I'm afraid it will do a significant amount of harm to the rapidly developing Android market.
Don't hold your breath waiting for good customer support from Google. Google has been great about bringing technologies to market. They have proven themselves nearly incompetent when it comes to end user support for those technologies. They really need to open up their hundred billion plus dollar bank accounts and fund a d
Re:Fragmentation is mostly FUD (Score:4, Insightful)
Android Market makes sure your app is only visible to those devices where it will run correctly, by filtering your app from devices which don't have the features you listed.
I've seen this a lot with friends who have different android phones. Friend A with HTC: "Hey try this really cool app". Friend B with Motorola: "What App? I can't find it anywhere in the market place." My understanding is that the app doesn't even show up if their phone is not compatible, it's invisible. I guess they don't want a bunch of apps that when you bring up the page says, "Sorry your phone is not compatible".
I also know from the QA side of the house that you can have the same phone hardware with 2 different OSs depending on the carrier. Usually we don't have major problems, but there can be glitches and bugs that are introduced. And then there is the speed of the upgrades. With the iPhone we looked at one major update per year. When we started working with Android last year it was 1.5 (which had been our for a while on the G1) and 1.6. Then suddenly it was 2.0, then 2.1, now 2.2 all the last 9 months or so. Apple has generally release a new OS every year with a minor .1 release shortly there after. Same with blackberry.
Re: (Score:2)
"I've seen this a lot with friends who have different android phones. Friend A with HTC: "Hey try this really cool app". Friend B with Motorola: "What App? I can't find it anywhere in the market place." My understanding is that the app doesn't even show up if their phone is not compatible, it's invisible. I guess they don't want a bunch of apps that when you bring up the page says, "Sorry your phone is not compatible"."
How does your beloved Apple handle this when someone builds an app for the iPad or 3GS th
Re: (Score:2)
When we started working with Android last year it was 1.5 (which had been our for a while on the G1) and 1.6. Then suddenly it was 2.0, then 2.1, now 2.2 all the last 9 months or so. Apple has generally release a new OS every year with a minor .1 release shortly there after. Same with blackberry.
Would you rather Google had named their Android updates in smaller numbers?
Or are you saying that Google should slow down the rate of improvements to the OS because you can't keep up?
If it's the second, then I advise you to target a release which offers you the features you need and stick to it. Android's backward compatibility works amazingly well.
Re: (Score:2)
I run a 1.6 Android phone. I heard that Google Earth was out and searched it. No such app.
Neat trick, keeping me from installing something that wouldn't work on my phone, but I'd prefer "This app is not compatible with your device" and removing the 'install' option perhaps.
At any rate, a minor user interface change.
Re: (Score:2)
Thats why I'm going for a N900 rather than a Android or iPhone.
The future has turned out to be Meego and there will be very well supported versions of it for the N900 (if not official).
So its a phone which will continue to get upgrades.
That plus you can tinker with it completely. :)
Want a new kernel? Sure.
Re: (Score:2)
Nokia have said it won't be porting Meego to the N900. The community probably will but that can take time and end up imperfect.
Nokia actually have quite a bad record of supporting their Nx00 devices once they release a new one.
Re: (Score:2)
Ditto the E series.
Re: (Score:2)
Erm the N900 is Nokia's development platform for Meego until the next hardware version.
There is already Meego for the N900, although it doesnt quite function as a phone yet.
Re: (Score:2)
If the customers really want free supported OS upgrades over other criteria, the first manufacturer that promises and implements it will get customers. Market forces will solve this issue. No need for Google to intervene
Re:Fragmentation is mostly FUD (Score:5, Insightful)
It's funny, I saw this article on my RSS and knew that the first post would be this. You don't give any reason as to why the fragmentation stories are FUD.
I am personally very hesitant to look at any android device due to the fragmentation. Hell, you have 1.6 devices being released alongside 2.1 devices. If this isn't fragmentation then what is?
As has been posted, read some comments from users about how pissed they are that their 1.6 device won't run certain apps or is lacking features that could be implemented by a 2.x release but their carrier won't deploy any updates.
While the fragmentation can't be squarely put at Google's feet, there's a shared responsibility between the hardware manufacturers, the carriers and Google to ensure that this doesn't happen. Unfortunately this hasn't happened and Android is headed squarely toward a cluster fuck.
Re:Fragmentation is mostly FUD (Score:5, Insightful)
The stories just say that fragmentation is killing Android, but they provide no evidence. They are making the claims, here. I have found no evidence that there's a fragmentation problem. There are apps that don't work for all devices, but iPhone OS has that issue, too, and it's only going to get worse.
Re:Fragmentation is mostly FUD (Score:4, Insightful)
Agreed, however the killing of the platform has started in minor ways, unless there's collaboration between carrier/manufacturer/Google it will end up as a platform that users don't want a bar of.
Let's face it, we're not talking about techies who can handle that some apps don't work, we're talking about users. They don't know the difference between a 1.6 & 2.1 device, they just see a phone with Android across the box. If it doesn't work they'll never buy another Android phone.
Sometimes it is difficult to step back and ask "What would a user do in this situation?". It's something that the IT industry seems to forget, that the users are what matters for a consumer device.
Re: (Score:2)
Got to agree with you. The "fragmentation" issue is a non starter, and is a good way to spot a pundit or expert that has no experience with Android other than molesting a phone at a cell phone booth in the mall.
Re: (Score:2)
The main problem with all the fragmentation, as I see it, is the uncertainty. Waiting for an update when your carrier/manufacturer etc. is unwilling to give any information as to when, or whether at all, an update is coming, is pretty crappy.
Will I be able to run the latest update to, say, Adobe Reader (which is already limited to 2.1) in half a year?
Will I be getting USB and WiFi tethering?
Will I be getting the JIT Dalvik compiler?
How about future upgrades, like browser support for coming technologies (Smo
Re: (Score:2)
As a former Windows Mobile developer, I am terrified. I now work on the iPhone, but my company is looking at the Android as a target platform. From what I've heard, Android seems like Windows Mobile all over again. And Windows Mobile was a disaster.
Re: (Score:2)
Well, here's the good news: Android is nothing like Windows CE. The fragmentation issue is a non starter, except with people who have no clue that Android apps run in a virtual machine, and are nearly totally insulated from the underlying hardware. Most of the whining about screen sizes comes from developers who want to use photoshop slicedowns as GUIs instead of using Android's GUI.
Re: (Score:2)
-- An angry Android user stuck with Android 1.6 on a six months old phone, which
Why fragmentation is FUD: (Score:3, Interesting)
You will find the answer to this mystery in "The Cathedral and the Bazaar" [catb.org] 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
Re: (Score:2)
Are you also hesitant to buy any Apple products because the original 3G won't run iPhone OS4? That's fragmentation, oh noes!@@#!@#
Re: (Score:2)
Blackberry and Nokia do release some upgrades for their phones - at least they own hardware of the devices they sell, so it's easier for them to do so, although carriers usually get in their way.
Google is in the worst position since it only controls the core software platform (except for the case of the Nexus One). A phone won't receive an upgrade
Re: (Score:2)
My olde iPhone (which isn't even a 3G) runs 3.13. It won't run OS4, but Apple doesn't even sell that model of iPhone. In fact, won't every iPhone that Apple currently sells run OS4?
In contrast, aren't there Androids currently selling with 1.6 or even 1.5? If so, that's a pretty big difference between the Android & iPhone in fragmentation.
Re: (Score:2, Insightful)
"It's funny, I saw this article on my RSS and knew that the first post would be this. You don't give any reason as to why the fragmentation stories are FUD."
It's actually been explained, and I have to question the motive for your posting, because it takes a certain selective ignorance to not see the given reasons. All the same, to give you the benefit of the doubt, here are the reasons they are FUD:
1) There's a choice between fragmentation and stagnation, if a set of devices does not change over time to avo
Re: (Score:2)
Somebody needs to find the genius that made the
This wasn't his point, but..... (Score:4, Insightful)
* 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.
Screen res (Score:2)
Are the screen sizes a big deal? Application and web developers have dealt with this problem for decades now.
Re:Screen res (Score:4, Insightful)
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.
Re: (Score:2, Interesting)
Motorola Droid is FWVGA, at 854x480
Re: (Score:3, Insightful)
Which you can just treat as 480x800, who will really notice the missing 54 pixels?
Re:Screen res (Score:4, Insightful)
Re: (Score:2)
Will I regret asking what the "F" stands for?
Re:Screen res (Score:4, Informative)
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).
"The Web is not a 'print' medium!" (Score:3, Insightful)
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
Re: (Score:2)
Actually Android is DPI aware -- your controls and images will be scaled according to the system's DPI.
The current solution with Android is to pack your images in different resolutions inside the app, and the system will use the correct version for the screen it's running on.
It works fairly well, but it's still not ideal. The ideal solution would be, as you say, to use vector graphics, but the problem on mobile apps is that vector images are more expensive to draw.
Current smartphone platforms are becoming a
Re: (Score:2)
bainstorming a bit here.
what if one make use of that GPU to do the vectoring the first time round (calculating vectors are what they are built for, no?), and then cache the output for future use?
Re: (Score:2)
Re: (Score:2)
This is a problem with a combination of poor APIs and lazy programming usually. On Windows this happens all the time because the tools for making UIs worked in pixels, which made scaling a problem. How many of you have heard a user complain that raising their screen resolution "made everything smaller". A 12 point font should be 12 points no matter the resolution. Points aren't defined in pixels but as fractions of an inch.
Resolution issues are best handled with APIs that are pixel-agnostic whenever the
Re: (Score:2)
Yes.
From what I've seen, they often deal with it poorly or not at all.
Now that 24" screens are cheap and plentiful a lot of bad web design is starting to show. For example "fixed width" layouts where all the content is in a narrow vertical strip bordered by eight inches of whitespace on both sides. Also sites that can't deal with anything but 96 dpi and overlap text or have it hanging off the
Unmaximize and show two web pages (Score:2)
Now that 24" screens are cheap and plentiful a lot of bad web design is starting to show. For example "fixed width" layouts where all the content is in a narrow vertical strip bordered by eight inches of whitespace on both sides.
Then unmaximize your window. Fixed width designs are meant for putting two web pages side-by-side. Windows XP and Windows 7 both support a split screen: in XP, you click one taskbar button, Ctrl+right click, and choose Tile Vertically, and in Windows 7, you drag each window to the left or right side of the screen.
Re: (Score:3, Informative)
This wasn't his point, but the author of the article described the android fragmentation perfectly.
Actually, that was specifically his point. From the preceding paragraph:
Now, that’s not to say that there aren’t real challenges in making sure that Android devices are compatible with each other, or that there aren’t very real concerns that keep app developers awake at night. There definitely are, and I spend a great deal of time indeed thinking about them and addressing them. The trick is to define them clearly.
..then he goes on to offer a definition for "Android Compatibility", and a few examples of problem areas (which you quoted). He then goes on to describe steps they have taken to mitigate the problems. The first step in solving a problem is to define the problem, and that's what he's doing.
Re: (Score:2)
Except the problem he's defining is 'making sure apps are compatible with at least one hardware/OS combo" - and he pretty much stops there and declares victory. If they have something in the works to prevent fragmentation, that's nowhere apparent in the article.
Re: (Score:2)
You managed to read the article with a large bias. It *does* explain how to deal with the issues of fragmentation: a) guarantee APIs are forward compatible; b) have apps declare their hardware needs; c) minimize bugs/incompatible APIs using extensive testing.
Google does assume fragmentation is inevitable. That seems to be under discussion by some people here on /. Personally, I can't fathom how is fragmentation avoidable, unless by stagnation. Stagnation is quite the opposite of the Android ecosystem, wh
Re: (Score:2)
Limit hardware options and use planned obsolesce seems to be working for apple very well. 1 new phone yearly and support that phone for 3+ years. Limit battery replacement optioons to make the consumer make a choice. buy a new battery, or just get a new phone.
what is it 80% of consumers just buy a new phone when their battery doesn't hold the charge that it used to anyways. I know that is what i do. the average battery so far lasts me 2-3 years. iphone 3G is 2 years old and the original is going on 3.
Re: (Score:2)
You managed to not actually read the article, or only read the parts that agreed with you. Read a paragraph or two beyond what you quote above and read how they have to hide the existence of fragmentation by hiding apps from people who can't run them.
Re: (Score:2)
I don't think that an Android device with a modified API should be allowed to be called an Android device. That said, I've never heard of any apps for which this was a problem.
The camera thing...well that's an issue with iPhone OS, too. But most importantly, you can restrict your device to certain features in the marketplace, so this shouldn't be an issue.
Here, let me have a go (Score:5, Insightful)
"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
Re: (Score:2)
Since the market will let you set which devices your phones works with you can very easily have two versions of each app to deal with the two screen sizes. This can also be used to restrict your app to phones running which ever android version you like.
Re: (Score:2)
my understanding is that it filters by minimum (and max if one want to) android version, and what specific "intents" (firmware/hardware features) the app requires. All this is feed by the device to the marketplace and so incompatible apps can be hidden away.
Re: (Score:2)
My mistake then. It filters by OS and hardware features, so you could use that to eliminate hardware you did not want to support. I should have been more clear.
Re: (Score:2)
Re: (Score:2)
I don't get your question. Just target Android 1.5. Aren't future versions backwards compatible?
Re: (Score:2, Insightful)
Aren't the newer versions of iPhoneOS not available for older ipods (and possibly iphones)? If that's true, I think the change in features between the versions is much less 'backward-compatible' than the change between Android 1.5 and Android 2.0, at least from an app's perspective.
For instance I doubt we'd find an iPhone developer willing to write their app for the iPhone OS 2.0 so that it'd work on older devices (and miss out on the cool multitasking of OS 4), whereas I'm sure that unless an Android devel
Re: (Score:3, Informative)
To date I believe every iPhoneOS device can run the latest version of the OS.
That won't be true for long. iPhone 4.x's pseudo-multitasking feature is only going to be available on the 3GS, not the 3G.
Any loser can develop apps for android. That does two things in my mind. 1) floods the market with garbage 2) opens the door for malware, which we have already seen.
We've seen malware for the iPhone too. A lot of good Apple's policy has done there, huh?
hrmf... (Score:5, Interesting)
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).
Re: (Score:3, Informative)
basically, google is lagging badly behind where third parties want to go with android.
That sound eriely familiar to the way they handled Google Apps. I was all gung ho to replace my Exchange server with Google Apps but there were a couple of not so minor little details to be addressed. I tried to get an answer from Google but couldn't get one. Everyone suggested talking to a GAPE partner. I tried to ask the GAPE partners the same questions and their response was, "Google assures us they're working on th
Re: (Score:2)
So you're saying, you want *more* fragmentation, is that it?
Let me suggest Windows Mobile. Wide range of hardware, all sorts of screen sizes and resolutions, non-phone devices - should meet all your requirements, does it not?
They openly admit fragmentation exists (Score:2)
The amusing part is TFA doesn't say what they submitter thinks it does - they openly admit fragmentation exists. And their response to fragmentation? "Android Market makes sure your app is only visible to those devices where it will run correctly, by filtering your app from devices which don't have the features you listed".
And thus, magically, since no one can download an app that they cannot run - fragmentation is gone. (It should go without saying this is laughable.)
Google is making sure that your app w
Re: (Score:3, Insightful)
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
Let me get this straight (Score:2)
1 - We hate apple beacuse they are closed ( but predicable )
2 - We hate android beacuse its not predictable ( but open )
Cant have it both ways...
Oh, and #3 - We hate windows phones, just beacuse..
Re: (Score:2)
I would hate Windows phones, but I'm having trouble finding one to hate on...
But let me answer your original point with a diagram [google.com].
Re: (Score:2)
2 - We hate android beacuse its not predictable ( but open )
I bought an Android phone because it was supposed to be "open". Then I found that it's locked down to the bootloader, that I can compile the code downloaded from source.android.com but then I have no way of running it on the phone, and that even if I found some warranty-voiding hack to do it, I would lose all google apps, the marketplace, and an assorted array of hardware functionality such as camera and FM radio. Sigh.
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)
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)
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?
Just a little off topic... (Score:2)
... but - are we starting to see fanboyism in the Android realm?
Windows is totally fragmented (Score:2)
Windows is totally fragmented. It's terrible. Why do people develop for it? Every machine has a different amount of memory, hard drive, resolution, aspect ratio, 3D capabilities. Some have mice, some have trackballs, some have joysticks. Plus, there's all these different versions: XP, Vista, Windows 7. For gamers it is worse: DirectX 9, DirectX 10, OpenGL. Even their flagship product has a mess of versions: .NET 1.0, 1.1, 2.0, 3.0, 3.5, and 4.0 are all found in the wild. Browser versions, service pa
Re: (Score:2)
the impression i have gotten on the default android keyboard at least is that it works independent of the ui of the app in use at the time. It will fade out the entire app, and display what your typing in a area above the keyboard rather then attempt to stuff it inside the ui of the app.
Re:This doesn't solve fragmentation (Score:5, Insightful)
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.
Re: (Score:3, Informative)
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 [networkworld.com] 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.
Re: (Score:2)
Re: (Score:2)
"You have to design a version for on-screen keyboards (because it'll use part of the screen real estate) separately from a version that uses a hardware keyboard. They don't need to be separate apps, but you need to design (visually at least) for both scenarios, or you end up locking out a good portion of the people who use android devices."
Please, tell me what the name of any of your apps are, since they would be the FIRST I have seen that bother to code for different keyboards. The rest all just let the s
Re: (Score:2)
So what happens if Apple releases an iPhone with a blackberry like keyboard - something which a lot of enterprises have asked for? You need to write a condition check to see if the device has a keyboard, or if it doesn't and act accordingly.
You can write a filter for your application manifest to filter the app so it doesn't appear on Android phones without a keyboard.
Or you could write two versions like you say.
There's 3 solutions for you.
This problem seemed to be solved ages ago on Symbian ;).
Re: (Score:2)
Or you could just use Android's libraries and widgets and let the OS pop up the onscreen keyboard when someone taps into a text field or accept keyboard input when a slider's keyboard is open. Ironically, those phones with keyboards actually use both the onscreen keyboard (when the phone is closed) and the hardware keyboard. The whole thing is largely invisible to the programmer.
Oh, and you have one app.
Re: (Score:2)
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." Coincidentally this is exactly what MS is doing with Windows Phone 7 -- three hardware platforms, that's it. You still have to design your app three times, but at least you know that if you design for one hardware platform, ANY device within that platform by ANY manufacturer on ANY carrier will have the same exact limitations and abilities.
Microsoft does that for desktops too, and probably any device that runs a Windows OS for that matter. In order to get the little Windows badge, the computer has to have certain minimum specs. It doesn't seem like much, but if they didn't have any kind of certification program, things could be much, much worse in Windows land. Windows Media Center PCs all had to have TV tuners and DVD/CD burners for example, and I'm sure there were more requirements besides the obvious.
Google will probably have to do the
Re:This doesn't solve fragmentation (Score:5, Interesting)
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).
Re: (Score:3, Insightful)
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
Re: (Score:2)
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).
Actually that's not completely true. You can target a newer API version and still define a previous version as your minimum API level in the manifest.
That's what the documentation proposes if you want to support different DPIs (introduced in 1.6) and still make your app available to devices running 1.5.
This will work well as long as you don't explicitly call any functions which are only available in the newer API. In fact, I haven't tried this, but I guess if you want to use a new API feature, you can do it
Re: (Score:2)
there are too many variables in the android world to code an app once to run successfully across the ecosystem.
Fail. There already are thousands of apps that work across everything from the original G-1 to the latest, greatest device from HTC, Moto, Samsung or whoever.
You have to design a version for on-screen keyboards
I suppose you could do that, if you wanted to spend 90% of your money rewriting libraries that are part of the Android operating system. And your app would be huge. It's a lot easier to use A
Re: (Score:2)
Coincidentally this is exactly what MS is doing with Windows Phone 7 -- three hardware platforms, that's it. You still have to design your app three times, but at least you know that if you design for one hardware platform, ANY device within that platform by ANY manufacturer on ANY carrier will have the same exact limitations and abilities.
It's a bit too convenient, because MS is just starting anew. What do you think will happen when those three platforms start getting obsolete?
Re: (Score:3, Informative)
It amuses me to no end
Is that you, Lo Pan [moviewavs.com]?