7 ms·

Android developer on Slashdot detailing the Android "fragmentation"

125 points by pclark 16y ago

DrSprout 16y ago
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.
- m_eiman 16y ago
  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.
- swannodette 16y ago
  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 16y ago
    >Provide only high level access to the graphics capabilities of your platform In other words, no.
  - cubicle67 16y ago
    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.
- dabeeeenster 16y ago
  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...
- SamAtt 16y ago
  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)
  - buster 16y ago
    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.
lapusta 16y ago
So many talks on Android fragmentation. Don't remember any when iPhone 2G was left behind iPhone OS 4.0 wagon.
- swannodette 16y ago
  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.
  - halostatue 16y ago
    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).
    - veemjeem 16y ago
      Well operating-system obsolete. You can probably still get apps as long as the developer targets an older version number.
  - smackfu 16y ago
    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.
briansmith 16y ago
Once he develops some stuff for non-Android, non-iPhone devices, he'll laugh at how minor his complaints are.
- waterlesscloud 16y ago
  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.
- pistoriusp 16y ago
  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.
- barredo 16y ago
  Like Symbian? Just guessing, i'm interested in knowing more
  - Daemmerung 16y ago
    Or Windows CE.
    - a1k0n 16y ago
      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 16y ago
        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).
chwahoo 16y ago
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 16y ago
  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-internet-usage-stats-nokia-biggest-but-iphone-growing-fast 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.
stcredzero 16y ago
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.
- dieterrams 16y ago
  Why would they have licensing issues?
  - ZeroGravitas 16y ago
    Because they'll hold back the platform if Apple adds new features and they don't bother to update to take advantage of them?
    - joeld42 16y ago
      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,
- pkaler 16y ago
  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/
  - 16y ago
buster 16y ago
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 16y ago
  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 16y ago
    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.
- jparise 16y ago
  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.
ck2 16y ago
Android 1.5 is going to be the IE6 of the mobile world. You'll have to code workarounds for it for years.
- mbrubeck 16y ago
  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 16y ago
    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.
    - gte910h 16y ago
      The MOTO Cliq is stuck on 1.5. The G1 runs 1.6 just fine.
    - veemjeem 16y ago
      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.
- orangecat 16y ago
  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.
  - kapranoff 16y ago
CountSessine 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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 16y ago
        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.
weeksie 16y ago
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.
jrockway 16y ago
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 16y ago
  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.

125 points by pclark 16y ago

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.

m_eiman 16y ago
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.
swannodette 16y ago
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 16y ago
  >Provide only high level access to the graphics capabilities of your platform In other words, no.
- cubicle67 16y ago
  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.
dabeeeenster 16y ago
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...
SamAtt 16y ago
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)
- buster 16y ago
  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.

lapusta 16y ago

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

swannodette 16y ago
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.
- halostatue 16y ago
  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).
  - veemjeem 16y ago
    Well operating-system obsolete. You can probably still get apps as long as the developer targets an older version number.
- smackfu 16y ago
  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.

briansmith 16y ago

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

waterlesscloud 16y ago
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.
pistoriusp 16y ago
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.
barredo 16y ago
Like Symbian? Just guessing, i'm interested in knowing more
- Daemmerung 16y ago
  Or Windows CE.
  - a1k0n 16y ago
    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 16y ago
      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).

chwahoo 16y ago

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 16y ago
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-internet-usage-stats-nokia-biggest-but-iphone-growing-fast 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.

stcredzero 16y ago

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.

dieterrams 16y ago
Why would they have licensing issues?
- ZeroGravitas 16y ago
  Because they'll hold back the platform if Apple adds new features and they don't bother to update to take advantage of them?
  - joeld42 16y ago
    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,
pkaler 16y ago
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/
- 16y ago

buster 16y ago

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 16y ago
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 16y ago
  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.
jparise 16y ago
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.

ck2 16y ago

Android 1.5 is going to be the IE6 of the mobile world. You'll have to code workarounds for it for years.

mbrubeck 16y ago
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 16y ago
  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.
  - gte910h 16y ago
    The MOTO Cliq is stuck on 1.5. The G1 runs 1.6 just fine.
  - veemjeem 16y ago
    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.
orangecat 16y ago
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.
- kapranoff 16y ago

CountSessine 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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.

weeksie 16y ago

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.

jrockway 16y ago

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 16y ago
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.