

Android developer on Slashdot detailing the Android "fragmentation" - pclark
http://news.slashdot.org/comments.pl?sid=1671914&cid=32426078

======
buster
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.

~~~
wvenable
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.

~~~
buster
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.

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

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

~~~
Daemmerung
Or Windows CE.

~~~
a1k0n
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.

~~~
SomeCallMeTim
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).

------
DrSprout
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.

~~~
swannodette
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...

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

In other words, no.

------
jrockway
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+.

~~~
blocke
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.

------
chwahoo
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.

~~~
dirtyaura
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...](http://dirtyaura.org/blog/2009/01/05/worldwide-mobile-internet-
usage-stats-nokia-biggest-but-iphone-growing-fast)

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.

------
weeksie
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.

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

~~~
thesethings
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.]

~~~
babblefrog
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.

~~~
biafra
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.

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

------
CountSessine
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.

~~~
alphamerik
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?

~~~
CountSessine
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?

~~~
blocke
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...

~~~
CountSessine
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.

~~~
alphamerik
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. :)

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

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

~~~
mbrubeck
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.

~~~
SomeCallMeTim
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.

~~~
veemjeem
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.

------
stcredzero
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.

~~~
pkaler
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/

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

~~~
halostatue
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.

~~~
dieterrams
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.

~~~
easp
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.

