Android developer on Slashdot detailing the Android "fragmentation" | Hacker News Reader

Android developer on Slashdot detailing the Android "fragmentation"

news.slashdot.org

125 pointspclark85 comments

In using OpenGL he is basically giving up all the features Android offers him to stay platform independent. I think it is clear, when you write a whole, complete rendering engine that doesn't use the android stack, you'll eventually have to deal with different screensizes, input methods, etc.

Most apps i use have been running on my G1 from day 1 and now on Android 2.2 on the Nexus One and i've had no big problems between android 1.5, 1.6, 2.1 and 2.2.

I guess the only thing for games to remain relatively platform independent is to use another intermediate layer (to substitute for a not used android "layer") like the unity3d engine.

You haven't had problems but how much of that is because a developer, like this one, put the effort into making sure you haven't had problem?

OpenGL itself exists to offer platform independence.

Not much if the developer stays to the standard UI. How do i know? First of all, i've written my own android programs. Running on a new version is generally no problem, there may be some minor changes that the developer docs usually tell you about. Nothing fancy that can't be done in a few minutes.

Second, when 2.2 was released most programs ran out of the box on 2.2, there where no app updates for a few days. Out of all the programs i have installed (there are quite a lot) only one had a minor graphic bug, that has been fixed now. Don't know what was causing this, though.

When you say "OpenGL is for platform independence" you are right. But if you look at all the versions, and _especially_ the vendor specific OpenGL extensions, you'll see that OpenGL is quite fragmented itself. Also, it doesn't abstract away screen sizes and such.

While his specific examples were about the OpenGL implementation(s), the spirit of his post rings true in other Android subsystems, as well.

For example, camera support can differ greatly across SDK versions and hardware. Camera callbacks need to be implemented conditionally based on whether autofocus is available and selected. EXIF orientation data isn't reliably recorded on some devices, and the EXIF interface class isn't available in older SDK versions. Lastly, your application will crash if you attempt to take or preview a photo using unsupported dimensions, but the function to query the list of supported dimensions isn't available on older SDKs.

Once he develops some stuff for non-Android, non-iPhone devices, he'll laugh at how minor his complaints are.

That was my first thought, that ye olden days of windows and/or dos programming were much worse.

But the market was also much bigger. And software sold for higher prices.

Android market is too small and prices too low for the platform to be so fragmented.

I've also have some experience in J2ME/ Symbian development. Reading this guys story made me cringe, it brought back some bad memories.

My feeling is that it seems minor now; but it should be focused on. You can't let something like this slide for too long before you've got a piece of junk.

Like Symbian? Just guessing, i'm interested in knowing more

Yes, Symbian is the platform I was thinking of. Some of the problems can be alleviated by ignoring old devices (N95 era and before) or by ignoring all non-touch devices. But, even then, you have lots of variations between the remaining devices.

Symbian had no fragmentation control..at all. Even within Nokia different teams would randomly change public API's in the most insidious of ways. The real issues on Symbian weren't different models/screen sizes (hell, S60 phones had more or less standardized feature sets). It was the lack of any real control over the platform itself. As a developer you had to constantly deal with functional side-effects changing (and Symbians lack of coherent architecture, design, and quality meant there are a LOT of functional side-effects).

So the situation is definitely not Apple-to-Apple's. I really think you need to start thinking about Android in two generations. 1.x was all about getting competitive with the iPhone. From 2.x onwards I think we're going to see much more platform stability. Fewer OS releases and a higher emphasis on maintaining phone compatibility. We've already seen that in the first two releases of the 2.x series.

Or Windows CE.

Or really, any computer supporting OpenGL. This stuff is always an issue: figuring out the correct depth buffer size (not as much of a problem as it used to be), finding the vendor-specific version of the extensions you need to use, different pixel/vertex shader versions which require completely different code... It's always a pain in the ass.

Don't forget the bugs! Apple in particular has done exactly what he's accusing Google of doing: They ignored GL bugs in older versions of OS X, since they were fixed by the newer versions. They go as far as to delete (or hide?) discussion threads from the public Apple forums that talk about bugs they don't want to fix.

In their case it's more evil, though: They actually profit by ignoring older bugs, because they sell new versions of the OS to people who get sick of things not working. But as a game developer, we've had to still work around their bugs so as to support the people who haven't upgraded.

Story's the same here, except now it's not even an option for the consumer to upgrade (short of jailbreaking their phones in most cases).

i once got a gps with windows CE. i tried to develope a small utility program. it took me a couple days just to figure out the windows CE type i had there.

While I agree (fragmentation on J2ME is hell), that's kind of a weak argument. If things are worse in place A, that's not an argument things could also improve in place B. Certainly if one is a lot newer, and supposedly better.

Agreed. J2ME is a nightmare to develop for. Devices with wildly different capabilities and features, many of which are often buggy.

Or he could develop for iPhone devices, and use the freed time to make his apps better. Or start on a new app. Or take a break.

Maybe Apple won't like his app. Or maybe they'll allow it for a bit, and then can it. Who wants to take that risk?

Is this a serious question? Because the answer is: plenty more developers than are developing for Android.

Or worry about arcane App Store screening policies.

Which he has a very low chance of actually running afoul of. Keep bringing the FUD, folks.

Unfortunately, Apple seems to be doing an excellent job creating fear, uncertainty and doubt among developers all on their own.

It's no doubt true that most app developers will never run afoul of Apple, but every time Apple yanks an application that it had formerly approved it makes people wonder if it could happen to them.

There is a very low chance of a house burning down, but most people still take out insurance policies. Unfortunately no one will sell you insurance against working for two or four weeks and then having it all go useless because some droid at Apple is having a bad day or because Steve is rethinking user experience today.

edit: wait, _the_ Dieter Rams? I'm honoured.

Is there really a way to make OpenGL development simple and consistent across a wide range of GPUs and screens? It sounds to me like he's complaining more about how hard low-level cross-platform graphics programming is, not Android itself.

It would be interesting to hear the comments other developers who had written an app that used stock UI components and didn't do anything too crazy. Games aside, a large percentage of the other apps on the marketplace do relatively sane things with common components.

I developed a very simple app (BenPaper); it runs fine on 1.5, all the way up to 2.2. It handles things like device rotation without me writing any code to deal with that because all the layouts are liquid etc. etc. Admittedly it's a very simple app, but on the whole I was impressed with the defragmentedness of the platform.

Compare that to writing a J2ME app, where you have to use a build tool like Polish to build 18 different binaries, run 6 different emulators on your development machine, keep an up to date list of devices and their hardware characteristics...

Provide one screen resolution. Change that resolution infrequently. Provide only high level access to the graphics capabilities of your platform regardless of how much the underlying hardware changes. Do not permit developer access to private APIs. Hmm, sounds familiar...

>Provide only high level access to the graphics capabilities of your platform

In other words, no.

obviously this is a reference to the iPhone, but I'm not sure your second two points relate well to the OpenGL side of things; Apple allow you to write direct (C, using the OpenGL libraries) OpenGL code.

There is a way to make development simple and consistent across a wide range of devices and it's called Flash. A platform that, last I checked, Google was going out of their way to integrate.

(Which is why it's funny that the author of the post points to .NET without mentioning Flash in his article)

The problem with this approach is that performance goes down the toilet (which is exactly what you see with Flash on mobile devices now). So what Google's doing is offering developers and device manufacturers a chance to write to the device itself through OpenGL.

Everything has disadvantages, openness included. The author seems to want it both ways (open platform with Apple like hardware consistency)

Just as a sidenote: I've tried some flashgames on my Nexus One and had no performance problems, at least for the 2 or 3 games i've tried.

It would be useful to have an API that'll provide device optimal settings given a set of minimum requirements. It wouldn't help with the bug based problems, of course, but it's a start.

Android is still in its infancy. Like all Google products, the early users are the beta testers. 1.5 and 1.6 were technology previews that were mistakenly marketed as phones you could actually use. (I have a 1.6 phone, the Sapphire. It works, but it isn't great. The hardware is low-end shit, and the software tries to make that less noticeable, but the goal of these Android devices was a price point, not a good user experience. And users can tell.)

I would just target my apps to 2.0+.

You can do what Google recommends and does themselves with their market based apps...

Target either 1.6 or 2.1 based on what APIs you need. 1.6 apps will work with all later releases just fine if you don't need a 2.1+ specific API.

Like many others, I'm not surprised by this post: of course devices will have different graphical capabilities and developers will need to take them into account for decent performance.

These complaints scream out for a framework/engine builder to come in and provide a uniform interface to the graphical capabilities of the many different Android devices.

Yes, but it's good that this is highlighted when Google is touting that 100K Android handsets is activated every day. It means that for App/Game developers, your can target a lot less than total number of activate (let alone shipped) devices.

Nokia/Symbian has used total number of shipped devices as an argument for their platform, but every Symbian dev knows that it is totally meaningless number. For example targeting S60 2nd edition devices is out of question, but Nokia/Symbian is still calculating 2nd ed. devices in their numbers. I once blogged about this and mobile stats in general: http://dirtyaura.org/blog/2009/01/05/worldwide-mobile-intern...

Detailed info about fragmentation issues is really useful for me and I assume that other mobile devs & companies too for estimating when and how to develop to different platforms.

While I think the guy has valid complaints I HATE the way that developers abuse the word "trivial". Trivial does not mean "possible" it means ridiculously brain-dead easy and requiring no effort whatsoever. Hello World is trivial, not abstracting part of the platform to be redistributable. Bloody hell.

So many talks on Android fragmentation. Don't remember any when iPhone 2G was left behind iPhone OS 4.0 wagon.

Did you check out the whole OP?

I feel the dev's complaint was more nuanced than complaining about fragmentation.

The dev was saying there were tons of easy back-ports left on the table that could make the fragmentation much easier for developers to deal with. I walked away feeling that some released Android versions were neglected, more than fragmented.

[edited last sentence to distinguish neglected versions from not caring about the whole platform, which Google obviously does.]

The problem is that some of the handset makers (or carriers) don't seem to have much interest in providing updates. Which does make sense, in that there is no money in it for them. It's hard to see what Google can do about that.

Yes, that is exactly the crux of the problem. I imagine the following could help:

- Ensure raw Android devices are as pleasant to use as Sense and Rachel. This means stock updates will work on any phone, rather than having to wait for Handset manufacturers to port their UIs to new Android releases.

- Ensure that handset makers have updated their existing units before allowing them to provide 'Google experience' prorietary apps (Gmail etc) to them for new devices.

Google could provide (paid) update services for handset makers or carriers. The incentive for those to pay for this service would be that those devices would be much more attractive for customers. As a consumer I would be willing to pay more for a phone if I could be sure to get updates for 3 years ASAP.

EXACTLY. Why are these updates PAID!. I know many phone users would love to pay for them.

Actually, the problem is deeper than just that. It's not just a lack of incentive - it's counter-incentive. The phone companies are using the OS version to segment their market (high-rollers get a 2.1 device like an Incredible, cheapskates get a 1.5 device like an Eris or a Tattoo). The phone companies don't want you to be able to cheat their pricing by upgrading your Eris to 2.1. Given how obsequious and accommodating the handset makers are (they have to be - their sales channel belongs to the phone companies and they effectively have to do all of their marketing to phone company execs rather than us), it's unlikely that they'll do extra work to piss the phone companies off.

The CDMA Eris in the US has 2.1.

That's good - when did that happen?

Or are you talking about XDADevelopers?

Back in May if the Googles are to believed. I only noticed today when I was helping a non-technical coworker get her phone working with our employers email.

Each fix might be an easy port by itself, but if there's tons of them then maintaining developers to run through integrating all of them, making sure they work, individually and with each other, is not a trivial task.

Andy Rubin stated that the release schedule is going to slow down soon to either 2 or 1 releases per year. At the moment, the platform is immature and they are focused on adding in features. I suspect it will all become a lot more stabilised shortly.

At least: "released versions of Android are neglected". Google is not neglecting Android itself.

Fair enough distinction, I'll edit.

Updating a device is not trivial. But the biggest obstacle is that the effort will be seen as wasted by the device manufacturer, who stopped making that device ages ago.

One of the things Apple has done brilliantly is to make updating painless.

Yes, if this trend continues Apple will fragment iPhone OS devices once every 3 years. Awful when you consider that Android is fragmenting every month with the introduction of yet another device.

You can buy an iPhone 3G today from Apple that does not support all the features in OS 4 that comes out next month.

"iPhone OS 4 will work with iPhone 3G, iPhone 3GS, and the second- and third-generation iPod touch this summer, and with iPad in the fall. Not all features are compatible with all devices."

Also, if the new iPhone does have a higher-rez screen, there is going to be even more fragmentation.

Not that this is awful or the end of the world, but Apple isn't magically exempt from these things.

But realistically it's much less of a problem in that ecosystem. And if you write for the 3G, it will work on the OS 4 devices. It's only an issue if your app needs the bleeding edge features or speed/mem.

I agree with what you said here, and upvoted, but I'm not sure that it's a correct statement. What appears to be the case is that iPhone OS devices will be considered software-obsolete in the third year of availability, if we're extrapolating the trend from the limited data we have.

That is, I fully expect that my iPhone 3G will not run iPhone OS 5 and that the iPhone 3GS will not run iPhone OS 6 (or whatever number they're up to in two years). It's still a solid story for iPhone OS development compared to other handsets.

It appears to be one of the lessons that Apple took to heart from the PalmOS example (they were at 160x160 for years, then 320x320 and only a few folks took it beyond that).

Well operating-system obsolete. You can probably still get apps as long as the developer targets an older version number.

Verizon is selling 1.5 and 1.6 devices right now - that's how they're segmenting their product line. AT&T and Apple haven't sold an iPhone 2G in years.

The Droid has an update to 2.1 available. The Eris has an update to 2.1 available. The Incredible shipped with 2.1.

While individual phones may ship with the old version all the Verizon Android phones I'm aware of have the ability to be updated to 2.1 in a carrier supported way.

I would expect the Droid and the Incredible to have at least 1 update in them, maybe more - they were/are both flagship Android phones and were sold to less-price-sensitive customers who will expect an up-to-date OS. It's the cheapskate-phones, as I mentioned, like the Eris, that I wouldn't expect to get updated.

I'm genuinely surprised, though, that the Eris has been updated.

In addition to OpenGL differences (which given how much the graphics hardware in these devices differs should probably be expected), 2.2 is going to be a really big compatibility break. 2.2 is the first OS version who's JVM (Dalvik) has a JIT compiler. The Android team is down-playing the performance gain, but benchmarks have shown that 2.1 Dalvik's performance is terrible and if the new Dalvik is even remotely competitive with other JIT-ing JVM's now, Android 2.1 and earlier are going to seem CPU-starved compared to Android going forward from 2.2.

That's a good thing, if you can count on most (many?) handsets being upgraded to 2.2. That's unlikely, though.

I have been using JIT on my ADP1 with 2.1, and it hasn't broken anything. Performance is great, 3.5mflops in linpack vs 2.4mflops. But I am confused, why do you think there is a compatibility break?

A compatibility break in that if you program something with a heavy CPU burden like a bunch of image FFTs or belief networks (as many of us have done on iPhone), you can't rely on a pre-2.2 device to complete the task in a reasonable amount of time. For anything CPU intensive, do you recode it in java or do you keep limping along with the C++ NDK?

When you say "compatibility break" I hear "your 1.5 to 2.1 apps won't run on 2.2" not "2.2's increased performance enables a new class of applications that won't work on phones with an older OS".

I'm not seeing the problem here...

For a developer targetting a new feature in a new release of the Android OS, it's a huge problem. If I want to make a program targetting a new feature in the iPhone OS, I can do that confident that 99% of all iPhones will be upgraded to $(CURRENT_OS_VERSION)+1 within a couple of months of the upgrade being available. It's simple. Everyone is on 3.1.3 - I don't have to worry about missing a big chunk of the market and reworking my code to accomodate old OS versions.

So do I recode my FFTs in Java and say goodbye to anyone running pre-2.2 until the carriers/handset makers get around to upgrading everyone in a couple of years time, or do I keep my code in it's little C++ NDK ghetto, safe from testing and rapid enhancements that Java would bring?

It's so frustrating that Google has fixed this problem NOW, but between carrier indifference and custom-'enhancement' inertia at handset makers, it's going to take forever for 2.2 to be a legitimate development target. This is a solved problem in iPhone-land.

So by compatibility break you mean that you are pissed that Android can run at any processor speed?

I have news for you, in iPhone-land the phones in a couple years will be faster too. :)

I've seen nothing indicating a compatibility break. Do you have any proof?

They seem to mean "because it's so much faster, it will make the slower ones looks worse", which is an odd idea for compatibility breakage.

I suppose it means apps might start doing that much more, thus performing so bad on old devices that they become unusable.

Android 1.5 is going to be the IE6 of the mobile world.

You'll have to code workarounds for it for years.

Nah, in October 2010 the first G1 owners' two-year contracts will start ending and they'll get offers for cheap or free upgrades to newer phones. Within a year or two this will happen to most people who bought a first- or second-generation Android device.

At least in the US, the carriers' subscription and hardware subsidy model will guarantee steady turnover in smartphones.

My G1 auto-updated to 1.6 a long time ago; it's other phones that haven't been updated from 1.5. Or non-US G1s? I'm on T-Mobile here in the US.

my htc on tmobile was stuck on 1.5, I had to do a bit of googling and some command line hackery to upgrade it. I'm guessing most moms & dads are not going to know what to with a command line prompt, even with great instructions.

The MOTO Cliq is stuck on 1.5. The G1 runs 1.6 just fine.

Or just don't support it. Most phones running 1.5 are underpowered, and if users haven't upgraded they probably don't care about being on the cutting edge and aren't buying many apps. I'd expect that the effort isn't worth it unless you have huge sales volume.

You are wrong. There's no way for me to update my HTC Hero from 1.5. HTC promises to provide update since December but has not yet delivered.

Sprint's Hero got 2.1 through an over-the-wire update and GSM Heros have gotten updates in other countries. Scream at your carrier if they don't have similar.

Nope.

There is nothing preventing people from abandoning Android 1.5. Contracts run up and people are thrown fancy new phones for free. Nobody has built mission-critical business apps around Android 1.5, as some big businesses have ActiveX/IE6.

Android 1.5 will simply be discarded. It's already closer to that than IE6 is!

On first reading, I couldn't see any problems mentioned that couldn't be addressed with a Factory pattern. Android game /graphics devs could band together and maintain a framework. iPhone devs would have licensing issues with such a project.

Stop spreading FUD. iPhone devs would not have licensing issues. How about I point you to a number of frameworks that iPhone developers ship with today and have been shipping with since near day one.

  http://wiki.developers.facebook.com/index.php/Facebook_iPhone_SDK
  http://code.google.com/p/gdata-objectivec-client/
  http://github.com/facebook/three20
  http://code.google.com/p/touchcode/
  http://code.google.com/p/oolongengine/
  http://code.google.com/p/cocos2d-iphone/

These don't go against 3.3.1? If so, I stand corrected.

They're all C++ or Objective-C. It's one of the insidious points of 3.3.1 that you can't used alternative languages (and it's questionable whether you could even use grammars or other code generators), but pure Obj-C or C++ libraries are all okay as long as they're statically linked.

There's actually plenty of precedent for scripting/interpreted languages being perfectly acceptable. Many emulators have been approved, as have games using Torque and Unity. And it's certain that plenty of games on the App Store are using Lua.

I thought the clause in question was for iPhone SDK 4 apps. Since v4 isn't shipping yet, it doesn't apply to any of the apps in the store now.

As for the question of interpreters, I though for the current generation of apps, the issue was with 3rd party interpreters that allow the interpretation of arbitrary code. Code that is embedded in the app at approval time isn't an issue. Isn't this why frotz can only run games that are bundled with the interpreter when it is distributed through the store.

Why would they have licensing issues?

Because they'll hold back the platform if Apple adds new features and they don't bother to update to take advantage of them?

I think that's the distinction that a lot of people miss (your post included). These are frameworks that work with apple's official dev environment, so if apple introduces a new feature, and if oolong or cocos2d or whatever is dragging their feet in incorporating it, a developer could just call directly into the SDK for it, no hoops to jump thru. Whereas if they were using Flash or Unity or something they'd have to wait for the middleware to support it.

Not that I approve of apple's stance on "original language" but I understand where they're coming from,

Reply on news.ycombinator.com