By I’m not going to hide that we’re Android enthusiasts and while we try to be as objective as possible, we certainly take more of a liking to Android than, well… any other mobile platform in the history of the universe. That being said, we understand there is an approaching “problem” with Android regarding potential hardware fragmentation. As Android grows and the number of carriers, manufacturers and handsets rises, developers will face an incredibly diverse range of circumstances on which they need to develop. Right or wrong?
Fake Steve Jobs would agree as he compares the Motorola Droid and Sprint HTC Hero:
… let’s say they’re both the most amazing pieces of hardware ever invented, way better than the iPhone, purely on a hardware basis. Now imagine you’re an app developer. Maybe you’ve got a game. Writing for Android means you do one version for this phone: (shows Droid) – and another version for this one: (shows Sprint HTC Hero) –
As you may notice, they’re not very alike. And let’s imagine there are loads more of these Android phone models, all slightly (or very) different from one another. Like this new vaporphone that Dell is working on. And you, lucky Android developer, have the pleasure of trying to guess which models are going to sell enough units to make it worth your while to port your application to them.
He makes it sound really difficult, doesn’t he? Its mostly smoke, mirrors and yearnful ignorance. No, you don’t need to redo your entire application or game for every single phone on the market. In fact, Google recently addressed this “issue” by simplifying every single Android Phone’s options as being one of 3 screen resolutions:
- QVGA (240×320)
- HVGA (320×480)
- WVGA (480×854)
Regardless of the screen’s actual “size” that means that each developer would need to account for THREE different hardware types in terms of the screen. And it isn’t like the developer needs to totally rework their application. I was tipped on this article (and the rebuttal concept) by Jeff from Codesector.com, the creator of 2 Android applications (Maverick and Here I Am) and this is what he had to say:
Hi Rob,
After reading (and laughing at) this post I made simple screenshot that demonstrated same app on all screen resolutions. Which include QVGA (240×320), HVGA (320×480) and WVGA (480×854).
The point is, Android system can automatically resize apps to any screen resolution – developers don’t need to adapt their programs to dozens phones. To make app look better on bigger screens like in Motorola Droid, a folder with hi-res graphics (e.g. 48x48px icons in addition to 32x32px) should be included in the application. It can’t be more simple than this :)
A little adaptation may be needed for small screen devices, but this is a few minutes of work. On a QVGA device, Android Market will filter out all apps that do not declare small screens support. So developers may want to check and update their applications to make them ready for HTC Tattoo and similar phones.
He continued by claiming other hardware variations were being addressed by Google to make it simpler for the developer to account for differences. For example: does the phone have a D-Pad or trackball? In terms of coding an app or game, the developer doesn’t have to write separate code for each – the trackball movement is correlated with D-Pad movement and the developer work load isn’t ridiculously increased as iFanboys may want you to believe. Here is the screenshot from one of Jeff’s applications that quickly illustrates the same application working on 3 different Android-safe screen resolutions/sizes:
And the iPhone enthusiast might say:
3 > 1 so you lose
But there are three things they aren’t taking into consideration:
- Taking 3 screens into consideration doesn’t mean 3 times the work
- Soon enough there will be more Android Phones than iPhones in the world. Developers will find it MORE than worth their time to go through a few extra steps to ensure their application is available all over the world, on numerous carriers, on phones made by numerous manufacturers.
And don’t forget the wild card in all of this – the customer. Despite what the Fake Steve Jobs, the Real Steve Jobs or any other Steve Jobs thinks – not everyone wants an iPhone. Not everyone wants a touchscreen. Not everyone wants a specific screen size, a specific shape, specific capabilities/needs, specific buttons, specific hardware layout, specific look, specific ANYthing.
The iPhone gives customers something very specific and I won’t lie – something very good. But Android gives options. And being able to choose from lots of very different, very specific and inevitably very good and *gasp* superior options is something many users/customers appreciate. I hate to burst any bubbles out there but not everyone wants an iPhone. Being able to choose from hundreds of different phones, knowing they can get pretty much all the same apps on each one regardless of which they prefer is pretty darn amazing. And… I’m guessing… it will probably be worth it for the developer to make a few little changes to some images so the user gets a nice view on each screen.
I heard you thinking “Hundreds of phones? Is he on crack?” To answer the latter question, yes. But the more important of the questions is the “hundreds” – am I serious? I wouldn’t be surprised to see 100+ Android Phones available by next year on a global scale. Probably the same reason I think those 2012 market share estimations are modest at best. And the Fake Eric seems to agree.
Damn straight.
Nice, I shall direct every ifanboy at fakesteve to this page
Excellent Article Rob :D
Completely agree, and I argue all these points when iPhone fans bring this up.
excellent response!
I can confirm that adapting my app to support standard hvga AND tattoo qvga screen size, has taken me 5-10 minutes of reading the guidelines (http://android-developers.blogspot.com/2009/10/support-for-additional-screen.html), and 1-2 minutes of coding (not really coding but some xml add/change). tested – that’s really easy.
I agree with your points Rob. I don’t think that hardware fragmentation will be an issue…I just hope that software fragmentation doesn’t become an issue as carriers/phone manufacturers create their custom builds that (sometimes) vary pretty far from the core OS.
I seem to remember when the iPhone went from OS 2.x to 3.0. Nearly all the applications had to be reworked to fun on the 3.0 software. Not to mention the different versions of iPhone hardware – 2G, 3G (1st and 2nd Gen), 3GS – all of which require special considerations when making an app.
Yeah but fake Steve has a point in a game being built for the Moto Droid will mostly definitely be shitty and crappy on a G1, i mean lets be real most emulators suck and only do 95% speed w/o sound. Also the certain phones being 1.5 and 1.6 till the developers update the phone is an using regarding api’s. And this will most likely happen again when 2.0 comes out and causes some fragmentation or devices like the G1 might not be able to update to it! Keep that in mind, look at Winmo phones….
Sorry for spamming, some corrections
Yeah but fake Steve has a point in a game being built for the Moto Droid will mostly definitely be shitty and crappy on a G1, i mean lets be real most emulators suck and only do 95% speed w/o sound. Also the certain phones being 1.5 and 1.6 till the carriers update the phone, is an issue regarding api’s. And this will most likely happen again when 2.0 comes out and causes some fragmentation or devices like the G1 might not be able to update to it! Keep that in mind, look at Winmo phones they been doing what android does, not being on one device but many.
Sorry for spamming, some corrections
Yeah but Fake Steve has a point for example for a game being built for the Moto Droid it will most definitely be shitty and crappy on a G1, I mean lets be real. The ram and rom of the initial devices are just not cutting it. Most emulators suck and only do 95% speed without sound. Also certain phones, on the Sprint network and the T-Mo Cliq, are already segmented and only running 1.5 while others are running 1.6 till the carriers update the phone, this is an issue especially regarding certain api’s. And this will most likely happen again when 2.0 comes out and causes some more fragmentation or there might be devices like the G1 that might not be able to update to 2.0! Keep that in mind, look at Winmo phones they have a big market share and many devices. The OHA and android are taking the same approach, we can only hope that Android can make certain standards across all devices and improve their devices spec wise so we can have an android device for 2-3 years without a problem.
If multi-faceted hardware was such an issue, PCs would never have outsold Macs nor would PCs have many more software options than Macs.
Sorry Fake Steve Jobs, the world just doesn’t work in the over-controlled way that Apple works. Apple products are not free and flexible simplicity, they are over-simplified dogmatism.
Google should plan for the next phone now, and spec out the next larger screen which will be supported in Android (e.g. 1024×640, or whatever is closest to a “standard” size.
That way, when new phones are introduced with larger screens, apps will work off the shelf w/o needing to re-code them.
Hm.
Then how do Android apps handle themselves on 1024×600 screens (as we’re now starting to see some of those)?
I’m afraid Fake Steve Jobs has a point. Applications written using the Android NDK – games using the OpenGL ES for example – will not scale. If a game is written to WVGA, it’s not going to scale properly to HVGA or QVGA. Its a good bit more work for the developer if they want to support the extra resolutions, never mind the work required with the assets to get them looking correct at different resolutions.
Apps that will scale are apps written using classes from or extended from the API. Games written using the Canvas class may scale fine.
All the iphone fanboys have forgotten that this push/pull between software developers and hardware manufactures has been going on with macs and PCs for decades.
@Daz:
I think you misinterpreted, he never said that apps will scale among W/H/QVGA. What was said was that apps written to WVGA will scale to whatever size the WVGA screen is, and the process to adapt to other resolutions is simple. Size =/= resolution.
And that, my friends, is why the Dalvik Virtual Machine is a good thing despite the fact that it takes better hardware than needed; by having apps work in a virtual machine, you just have to adapt said virtual machine to each phone, and then every app will work on every phone (in theory)
Here’s the other thing that I haven’t see in any of the comments either. Android provides a common java-based platform for all phones. You write a basic app, and it’ll work on every phone.
Also, in most apps such as the one in the example above, you don’t even have to worry about screen resolution. You simply add elements, and their sizes are automatically calculated.
Video games are a different story. You need to consider screen resolution, processor speed, and available inputs. Still, I don’t find it difficult to add something like: “This game requires a trackball/d-pad and a keyboard” in the description on the market.
In summation, it does make you think a bit more about hardware scenarios, but generally, not much. If that’s what you’re complaining about, then you’re just a lazy SOB. Windows has been running in all kinds of configurations, and I think that the platform is a bit of a success :)
@Paul T:
I don’t think it’s a valid point. Games will run better on phones with better hardware. So what? PC’s have been that way forever. We’re used to it.
@Daz
I don’t claim to know the ins and outs of OpenGL ES, but I do know that this is not a problem in OpenGL. In OpenGL, you specify how the camera maps to the screen at initialization, then everything from there on out pretty much boils down to placing pretty triangles in 3D space. So, if you wrote NDK code to initialize OpenGL ES, and if you chose to hard-code 320 and 480 into the initialization, then you’ll have to go back and query the screen size before initializing. If you did it right to start with, though, the process should be relatively painless, boiling down to shuffling around the GUI a bit on the longer aspect ratios.
@Others
As long as you stay in the Java VM (and don’t hard-code screen resolutions or place things with pixels), then there should be very little to worry about.
If you make high-res images that scale well, you may not even have to duplicate art for your app. Just include the high-res art and let Android automagically scale it down for you.
Finally, I think the real worry with fragmentation is with games and media apps that take advantage of special-purpose hardware like the GPU, signal processors, etc. that are included on the OMAP and Snapdragon processors. These apps simply won’t work on ARM 11 processors, or they’ll chug along at 2-5 FPS. Developers of 3D apps will segment into two groups. One will build multiple levels of detail in hopes of allowing Cortex-based processors to see the world in all it’s miniaturized beauty, while allowing our slower brethren to watch a pixelated, flattened rendering of the same world to keep their framerate up. The other group will just build beautiful apps that only run on high-end processors. The question becomes, just how many triangles can you push through a general purpose arm 11 processor? According to Qualcomm, you can render about 4 million triangles per second on a MSM720x (vs. 14 million on an omap and 22 million on a Snapdragon). At this speed ratio, it becomes relatively easy to quarter the number of triangles – a good decimator should be able to take your high-res objects built for snapdragon and build medium and low-res versions automatically that will work well for OMAP and ARM 11 processors, respectively. This change along with resizing textures can be the only changes needed to port from one platform to another.
I guess all in all I’m saying… you can run Crysis on integrated video, but who would want to? Let the games fragment the market. Maybe it will push the phone manufacturers to include good processors. If all the most popular games require Cortex/Snapdragon processors, then any phone that is marketed towards gamers will have one.
The biggest issue I see with all of this is, you can’t really test the Cortex GPU in an emulator. The solution for developers is: get a phone with a high-end processor as your personal phone and test the high-end content with it, and use the emulator as a good stand-in for the baseline experience on arm 11 hardware.
I’ve been programming for the Android and I don’t even look at the screen resolutions. If you build you program write it’ll work either way.
Apart from that you can chose to use one or more hardware input types. Every Android has a touch screen, and most have accelerometers.
The only real choice you have to make is wether or not to support a hardware keyboard only when creating games.
@Greven
It may well be that I am misinterpreting. I was picking up on the use of the Droid (WVGA) and Hero (HVGA) as examples Fake Steve used and how applications will scale between them. I have no idea how they would scale within WVGA or whatever hardware type is used. I was also looking at the screenshots posted from Jeff that show a QVGA screen and, judging by the 854 at the end of the window title, a WVGA screen. It’s a moot point anyway, Google have said themselves that apps will scale to a point – http://developer.android.com/guide/practices/screens_support.html – thanks to Dalvik.
@David
I’m only starting out in OpenGL ES myself. I’ve used Direct X a bit in college a few years back where I had fun setting the render resolution to be higher than screen resolution in a friends code :) My original comment – poorly written as it was and based on limited exposure – was intended towards 2D games and whether they’d translate well across the hardware types.
Since the marketplace will filter apps for you it shouldn’t be a problem. I’d hope that they wouldn’t assume someone to know what type of screen they have though, not everyone who uses android is will be that tech-savvy! :D
Hopefully the filtering in the Marketplace will also work to filter out games which require the higher end processors to run correctly. G1 users shouldn’t be able to download Droid-specific games which are simply not going to run on their phone. But developers should also not be forced to program for the lowest common denominator (they SHOULD make games for the Droid which take advantage of the hardware even if that means they wont run on the G1 etc).
I think QuantumRand makes a good point. “The iPhone” is not just one device. There are different models with different hardware. When you add the Touch to the mix it gets even more complex. Apple now has apps written specifically for the new Touch that are not available for the iPhone or old Touch.
@X3HaloEd you brought up the point, that better hardware will make games better, but unlike the PC you can’t simply upgrade your ram or your graphics card. Thus making the different hardware more challenging for developers. Device’s like the G1, MyTouch (US version), and the HTC tattoo will prove my point in the next couple of months. There needs to be more done standards wise to not segement an audience that much, and as much as we all love android, there is already a bunch of phones this year with 2 yr old qualcomm chips that are shitty for our phones performance wise. Buying a Cliq now, with the same specs as a G1 isn’t going to cut a year from now with new updates and new apps, why buy a phone exactly the same hardware wise as a G1 a year later. Makes no sense no matter how great Blur is. And that’s the reality of it.
this review is nuts! & a bit clueless. The Droid is going to be a maintenance nightmare. The Droid OS and there are different code sets with each hardware version. It’s like comparing TRUE cloud computing (The iphone)to the costly on-going maintenance and software breaking client server world of The Droid. Ever time you try to upgrade the Droid to the next release “buyers beware” it going to be ugly.
Verizon has only one thing going for it in this race. It’s Network is hands down the Best!
True. very true.
I’ve never had a problem with the multiple resolutions…I mean you already have to code for portrait and landscape, so there’s no reason to hard code any sizes. That being said, I’ve had lots of users complain about the trackball controls in my games. I developed my games on my G1 to work perfectly…and then it acts “glitchy” on my wife’s G1, so I can’t imagine how different the other phones are. I think that just shows how bad an idea trackballs are. Just give D-Pads, it’s hard to mess that up.
One more thing, I like what you said about options. I too like the iPhone, but it’s just not for me. I don’t want to use iTunes…heck it’s not even available on my OS (Linux). I need a phone that can be synced with a generic USB Mass Storage connection and used within a generic MP3 environment (Amarok). I want to be able to upgrade my MicroSD card instead of the entire phone. Perhaps I am an oddball with my geeky Linux OS, but the Android addresses that. My Verizon Commercial: “The Droid works with Linux…iDon’t”
These issues, of course, are also present on the iPhone. An application written to push the 3GS hard is going to suck on the 3G, 2G, and original. Particularly anything used 3D. Hard to criticize the DROID vs. other Android phones for this, when the iPhone has precisely the same issues. The 3GS also has twice the RAM (256MB vs. 128MB) versus the other phones (and iPodden)… that suggests things that fit on the 3GS may simply not fit on the older iPhones. A multitasking phone might actually tap the extra RAM just to keep more apps going, but iPhones don’t do that… so that extra RAM must be used for something, eh?
Then there’s screen size… Apple can’t have it both ways. Either they’re set at 480×320 forever, or they’re going to have the same issues of adaptation to new resolutions. Only, this isn’t known from the beginning, while with Android, it was.
So one way or another, the iPhone is going have “you suck” problems going forward. If they can’t match the higher resolution screens that EVERY other high-end phone is using, bad move. If they do go to that screen, now apps become even more segregated.
Or maybe, like Android, iPhone apps also use this amazing new invention called AN OPERATING SYSTEM. You don’t assume screen size, you ASK about screen size, and make simple adjustments accordingly. This has been done on personal computers for several decades now.. don’t ya bet that at least a few “phone” developers were present for that party, too?
You have all missed a big issue and that is screen size. The resolution-race that have been on the PC-side has been toe-to-toe with the screen size-race. I dont see that it can be represented on the mobile phones market because of the fact that we DONT WANT bigger phones (look at HTC Touch HD, what a joke).
I personally wouldnt mind if my future iphone (got a 3GS now) was a HVGA phone with OLED, super ultra 3D-accelleration, mkv-supporting, x/h264-rescaling-decoding-resizing-enabled and so on..
The problem is that i need to jailbraik my iPhone to make most of it, so if it gets harder and harder with new versions, ill go over to Android. But even on that platform i would like to see a standardisation when it comes to resolution (preferably to HVGA, but i could settle for a bigger one, as long as it becomes a STANDARD!)
damn sexy!!
I’ve to say that I like this website. I felt compelled drop a comment and say what a sweet position you have performed. I want alot more sites would put so much work into their website. Maintain the posts coming