Friday, November 23, 2012

Two problems with android-ndk-r8c


I've been trying to get back in to Android development, and the first thing to do was update all the build tools to the latest releases. This revealed 2 irritating problems in the current NDK when using ndk-build.

The first one is that your native code now rebuilds all the time. Whenever you run ndk-build, it compiles everything from scratch again. This is a known bug that looks like it will fixed in an update in the near future, but it is a bit irritating. The cause is that the object directory is a dependency of each object file, which means make will execute the rule to create the directory before it builds the objects. But writing the objects into the directory causes the modification time of the directory to change, forcing a rebuild of the depending objects. A vicious cycle that causes make to think your objects are always out of date. How nobody spotted this bug before release is a mystery to me. Anyway, the fix is easy - open up android-ndk/build/core/definitions.mk and change line 289 to the following:

$1: | $$(__ndk_file_dir)
That adds in a | symbol before the $$. It's a GNU Make feature designed specifically for this problem.

The second issue is not such a clear cut bug. It is definitely a regression, but whether the bug is in the NDK or the Eclipse Android plugin is up for debate. This only affects you if you are trying to support older versions of Android and use native code.

When you want to support old releases and still use the latest SDK, you must specify the minimum SDK in your manifest XML file and specify the latest target platform in the project.properties file. Sadly with the r8c release the NDK part of the build spits out a warning like this:



WARNING: APP_PLATFORM android-8 is larger than android:minSdkVersion 4 in AndroidManifest.xml
Eclipse sees this warning and prevents you from launching the emulator with the usual "Run" command.

The easiest workaround is to add NDK_NO_WARNINGS=1 to the ndk-build invocation of your native part of the build. Right click your project and select Preferences > C/C++ Build. Uncheck the default option and change it to ndk-build NDK_NO_WARNINGS=1. This is just a workaround - if you have other warnings in your build then maybe you need to fix them :-) but as far as I can tell, the only other warning that could appear would be if you built with NDK_DEBUG set to something other than true or false.



Of course you mustn't actually use any new Android features at run time, or the application will crash.

Anyway I hope that helps someone out.

Oh, bit of editorialising now. It's interesting to see Google introduce Clang in this version of the NDK too. I fully expect them to bit-by-bit remove all the GPL code in the NDK and SDK, and GCC is the biggest piece there. Then they'll release the SDK binary-only with secret sauce. Similar to the way Chrome is a closed version of Chromium that includes Flash, and Google and co develop Android behind closed doors before releasing it to the Open Handset Alliance, but devices all ship with closed-source proprietary drivers. Currently the SDK is one of the few parts of Android that's developed in the open. I can't see that lasting, especially after Google added the recent "no fork" clause to the terms.

Saturday, September 29, 2012

A new MP3 player and other product placements

After the last post on that EZ Flash cartridge I bought for the GBA, this installment is another tale of rampant consumerism all about another new toy I've recently bought - a Sandisk Clip Zip MP3 player. Ah, and I also bought Batman Lego 2, which has been a great success with my eldest son. It's not a bad game, far better than the horribly bugged DS Star Wars Lego at least. Probably a bit easy for most of us older gamers. It came with this amusing Lex Luthor figure, made of tiny pieces that disappear under the sofa with surprising ease:

Lex Luthor, awwww


Speaking of consumer, I really despise the way that the word has taken over the American technology press. Nobody reads, listens or watches anything anymore - they only consume. We now consume books, consume music, consume films, consume TV shows. Consume, consume, consume. Arrrgghh! It's actually made me stop listening to the Tech News Today podcast. Heh, I feel like I ought to be writing "wake up sheeple!" at this point. You get the idea.

So then, MP3 player. Eager readers may recall that 3 years ago I got a Creative Zen Mozaic to replace another Creative model that was starting to fall apart. The Zen has been a pretty good MP3 player, it has a nice user interface and after fiddling I could use gnomad2 to transfer MP3s across to it. Sadly, what really lets it down is its on/off/lock switch.

Creative on-off-lock switch


This switch is vital. You press down to turn the device on or off, with the switch springing back to the middle when you let go, or you press it up to lock the screen, whereupon the switch clicks into place. If the screen is not locked then the backlight remains on, wasting precious battery life. As you can almost make out on that crappy photo, the button and surrounding plastic have been worn away by constant use over the years, and now the switch lever itself is below the level of the surrounding plastic, making it tricky to move. In addition, the underlying springyness part and electronic contact of the switch has become flakey - it sometimes doesn't register changes from on to off or to lock at all. This seems to be a fundamental flaw in the design of the Zen Mozaic - I already had to send one back to the manufacture after only a few months of use as its switch packed in completely - and a bit of a shame, because besides that it is a good player.

Having said all that, I have been wanting to try out Rockbox for a while now, and the Creative devices have never been supported by this interesting Free firmware for digital audio players. Some advances have been made on a couple of the newer Creative devices, but not for the older Mozaic model. Even for those it does sort-of work with, it is still early days. By comparison, the Sandisk MP3 players are very well supported. I decided to take the plunge. BTW, the Zip is rated as "unstable" by the project, but only because it lacks documentation screenshots and a couple of games are not formatted  correctly for its smaller screen. The music playing side of things works great.

I couldn't find a Sandisk Clip Zip for sale in any of the major retailers here in Madrid. They only seem to sell Apple, Samsung and Sunstech devices (big in India, apparently). The bottom has really fallen out of the MP3 player market, it seems. I ended up buying from Amazon. The UK version was surprisingly the cheapest, and with no charger included, 3pin or otherwise, it made no difference to me.

Once you buy a Zip and figure out how to get the player out of the box it comes in (pro tip: use a stanley knife, nobody is peeling that glue apart) the actual Sandisk build quality feels nastier than the Creative one. The buttons on the front face are a bit hollow-plasticky sounding, and the socket to plug in the headphones doesn't inspire confidence. It needed an ungodly shove to get the 3.5mm jack in there. I haven't dared take it out again, just in case the whole thing comes apart in my hands. On the plus side, it weighs next to nothing. Not that I exactly needed a trolley to wheel around the old Mozaic, which was itself a lightweight compared to the even older Micro, but the Zip feels like it's hollow it is that light.

I didn't spend much time with the Zip's stock original firmware (OF) - pretty much just long enough to confirm that the Zip turned on and played tracks correctly. Interestingly the OF lets you choose whether to use the device in MSC or MTP mode - that's massive storage, or media transfer protocol. The Mozaic had this partly built in, but only let you use up to 2Gb as regular storage, not the whole device.
MSC means the device is seen as a regular mounted disk and is typically what USB drives and cameras use. After you finish transferring files, you have to remember to unmount the device so that you don't lose any partially written data. MTP has a more proprietary history, being a Microsoft invention that up until recently was not a standard. In recent Ubuntus at least MTP has been quite well supported. It has the advantage of not needing to unmount after transferring files, and on really modern devices the software on the device itself can still read and write to the storage even if the computer it is connected to wants to do the same. With traditional MSC only one "thing" can use the drive at a time. This is one reason why newer Android versions have switched to MTP over having a mounted drive visible on external computers.

All that said, I tried MTP on the Sandisk, and though Gnomad2 recognized it, it gave a funny error ("-1" not recognized or something). And transferring a file with a "?" in the name cause the Sandisk to lock up! Ulp. So I quickly reverted to regular MSC mode. Besides, Rockbox mostly installs as regular files on the player's drive, so having it in regular USB mode would be an advantage there.

Installing Rockbox is really, really easy! I was expecting it to be a crazy ordeal involving partition tables or something. You do have to download the OF, since the Rockbox installer patches this to boot either the OF or the Rockbox code when you turn the device on, but apart from that you literally just plug the Zip in, start the installer, and click "Install". When you unplug the gizmo it says "updating firmware" for a minute or so, then reboots into the Rockbox UI!



Rockbox is Free Software. And like a lot of Free Software, it has a user interface that is rather "designed by programmers". This means you can do tons of things, it has a million options and tweaks, and everything is consistent with the model the programmers had. But it is initially overwhelming and looks a little bare-bones. You can see a couple of the default screens on this blog post. The Zip has a smaller screen than the Zen Mozaic, but the Zip OF had a fair amount of gratuitous bells and whistles. It "looked nicer" than Rockbox, I think you could say. However, one immediately irritating thing Rockbox fixes that the OF did was to rebuild its MP3 database index every time you unplugged the thing from the USB. Every f-ing time! The whole database! This took several minutes - the sandisk forum response is "buy a charger", or (hilariously) "it must be the antivirus software you have". Ha ha.

I use my MP3 player for 3 things: listening to music at work, listening to podcasts on my daily commute, and listening to music before falling asleep at night. For the music-at-work thing, I think things will be OK. I like the fact that Rockbox aggressively switches off the backlight and does so even without being locked. Having to constantly lock/unlock the Zen to get the backlight off is probably what wrecked the switch in the end.

For the daily commute, podcast support is improved over the Zen. First off, the bookmarks are created automatically when you stop a track and automatically resume (or asks you) if you play the same track. On the Zen you have to manually create bookmarks, and manually select them from the bookmark menu. Secondly, you can set the "skip length", so that instead of skipping to the next track when you press ">>" it can skip any number of seconds. I have this set to 30 seconds, which is perfect for skipping the otherwise-great Ubuntu UK Podcast's incredibly irritating and remarkably unfunny "Tomorrow’s Technology Today" segment, for example. Or for skipping adverts, I don't always want to "consume" these.

When I plug the MP3 in before going to bed, I set a sleep timer for 15 minutes. That way if I doze off, it doesn't play all night and waste the battery. On the Zen this could be placed on a shortcut and was easy to enable or disable. When set to "off" that was it, the sleep was off. When it was set to "15 minutes" it reset to 15 minutes each time you switched it back on.

On Rockbox it works a little differently and has 2 options and a "start/cancel" button. One option controls the default time, and the other determines if the timer should reset when you switch the Zip back on again. This is actually not that helpful, and I couldn't seen any way to make it so that you could have it either off, or on-and-always-resetting-on-reboot - you always have to fiddle with 2 options. e.g. if you have reset-on-start "on", but cancel the timer, then rebooting will start the timer again. You have to go in and press "cancel" again, which is 3 menus deep and can't be placed in a shortcut. But at night, you want the timer on if you reboot (because you haven't fallen asleep and want to restart the player for another 15 mins).

So my first hack-on-the-code patch was to make it work more like the Zen. I added 0 minutes to the list of default times, and if you select that it cancels the timer. Now, when I turn the Zip on for the commute, I set the timer to 0 minutes. And at night, I set the timer to 15 minutes. The "set default time" option can be placed on a shortcut, which means there's no need to dive deep into the options every time.

A bit of RTFMing revealed that you can hide entries on the main menu. This makes it a little less overwhelming, and I immediately got rid of the options I knew I'd never use, like FM radio and voice recorder. It's a shame that this is not more configurable - on the Zen you can hide menu items and "pull up" sub-menu items into the top menu, but I don't think the Rockbox code is really designed in a way to allow this level of flexibility. Another customization I made was on the "database" menu, which is the Rockbox name for where all the track filtering options are, like list songs by artist, album, genre, etc. This is really overloaded with zany selections I'll never use. I mean "order by composer" as a main menu item? Really? The database menu navigation configuration is a plain text file, and is easy to hack up to something a bit easier to manage - of course the devs recommend not doing this. But I'm a professional, don't try this at home :-) I even added the podcast menu item mentioned on the wiki.



As you can see on those images, I've set the text to resemble the classic green-on-black that is well known for being the greatest combination.

One acronym that comes up time and time again on the Rockbox Wiki but took me a while to find out what it meant is "WPS". WPS is short for the "While Playing Screen", which is the screen shown while a track is playing.

On device screenshot



There are dozens of skins for this screen, as well as the rest of Rockbox. You can mix and match skins. I found the default WPS skin a little hard to read, and a simpler design with big letters works better on the small screen. Here the functionality over looks of Rockbox trumps the Zen WPS. In less pixels, the custom screens manage to pack in a lot more info, such as bitrate, file type, genre, and the clever "next track" text.
Rockbox playlists are just text files! This is something I've always wanted on the Zen, since creating "complex" playlists on the device is fiddly, and Gnomad2 is not much better. Now I can create a list of tracks using find and edit that list in Vim, the text editor of champions. For example, to create a list of all the Super Furry Animals tracks, I can now do the obvious...

cd /media/SANSA\ CLIPZ/Playlists/
find ../MUSIC/Super\ Furry\ Animals/ -type f | sed 's/^\.\.//g' | sort > SFA.m3u8

Then in Vim move the lines around to get all the albums in chronological order. Doing that any other way always caused me to miss out on some tracks, like forgetting the Ice Hockey Hair EP or something. No danger now. Here, go and watch this '96 performance of "Something for the Weekend" on Later with Jools Holland and be nostalgic.

What else? Oh, I've been saying "MP3" in this post, but the Zip with Rockbox also plays .ogg files too. And .flac, and a million other formats - including video game formats like MOD, SID and NSF. The Zen was limited to MP3 and some Windows-specific codecs that nobody uses. One thing that using MSC rather than MTP does really force you to do is make sure that your MP3 ID3 tags are all correct. I used tagtool to fix file names, and id3v2 to get rid of empty or rubbish ID3 tags that transferring the files off my Zen had created. After that, it turns out that the FAT32 file format can't handle some "special" characters, including ?, : and ". I used a line like this in bash to fix the mess ups for each unsupported character:

find . -name '*:*'  | while read file ; do mv "$file"  "${file//:/_}"; done

Then there's all the "under the hood" stuff that Rockbox improves over most things - battery level that seems really accurate (the Zen only ever seemed to have 3 stages: 100%, 75%, 0%), random number generator for shuffling tracks that puts Nethack to shame, loads of equalizer knobs and buttons, etc, etc.

Compiling and testing custom versions of Rockbox is pretty similar to GBA development, except that instead of an emulator the Rockbox authors have created a simulator. Here you build the source for a native (e.g. x86) version of the source code, and executing the resulting binary simulates the device running on your computer in its own little window. This makes testing custom menus and firmware builds a lot easier, since there's no need to copy stuff across, uplug, and reboot. Once you want to test on the real thing, you need to use a GCC cross-compiler for ARM. Unlike devkitARM, which is distributed in binary form to quickly get you up and running, there's a "rockboxdev.sh" script that downloads, patches and compiles a suitable version of GCC and associated tools. This takes a while, but Just Works (or at least it did for me). After that, you run an autotools-like "configure" script and choose the device you want to build from the list of dozens, then run "make" to build the source code for your player.

Testing a custom build - once you have alread installed via the installation tool - involves copying your "rockbox.sansa" file onto the USB-mounted partition for your device. You don't even have to overwrite the original rockbox.sansa file that is on there. You can call it "custom.sansa", and run it from the File menu just once to test how it goes. When you're happy with the fix, overwrite the original file and you're done. The current firmware detects it has been replaced and reboots automatically.

There you have it. Rockbox. Totally recommended. Simple to install on supported devices, highly tweakable, easy to hack on, and has loads of useful features. Who thought MP3 players could do so much? :-)

Wednesday, September 19, 2012

EZ Flash IV For GBA


I've always used an ancient GBA flash cartridge that needed a parallel port connection to work. Since it is virtually impossible to buy a new laptop with a parallel printer port, I decided to buy a new flash cart that worked via USB. This will save me digging out my old Windows 98 laptop.




The idea is that you copy the ".gba" files onto the microSD card using whatever method you like. I plugged it into a card adapter and plugged that into the port on the side of my laptop. Hilariously Linux managed to mount the card read-only, which was quickly followed by a lot of searching for what could be the cause of the "mount: block device /dev/sdc1 is write-protected, mounting read-only" message. Turns out I had the lock switch in the "locked" position, making the card read only. Durrr..

The build quality of the cartridge is pretty bad, sadly. The shell is a couple of bits of plastic with a slot for its own micro SD card adapter. The microSD fits snugly into the adapter, a bit too snugly initially as I had to give it a fair old shove to get it in there. The adapter then fits equally as tightly into the cartridge itself. Once it's in you need to apply a little too much force to get the adapter out again. I'm worried something will give sooner rather than later.

On a phat DS: everything seems to work. I didn't realise this at first, but the cartridge boots up into DS mode, from where you can select GBA games from the menu and they boot in GBA mode.




On a GBA SP: everything works too, though my "GBA Rogue" port didn't launch :-( I tried a new build of PocketBeeb I've been semi-working on and that did boot on the GBA and DS, so I think perhaps it is a problem with really old homebrew. I also tried an English-patched ROM of Fire Emblem 6, and that worked too. Launching large games takes a while though - I guess this is because they get copied from the microSD onto internal RAM that the actual GBA reads. When I say a while, it takes maybe 10-20 seconds.



The cart boots up into Chinese on the GBA the first time you run it, which threw me a bit. The fourth option down changes the language to English though. One thing I'm not sure about is what the point of overwriting the flashcard "NOR RAM" is - I think this is similar to the old-style GBA carts, but all it seems to do is corrupt the main menu.

Saving seems to work OK too.

Ah, just tried Powder 117 on the DS - it doesn't boot there, but it did boot on the GBA SP. So there are some compatibility problems with homebrew games it seems. Unless Powder does something odd on start up, like checking the hardware type, causing a crash (I don't think it does though). I might try building it from source with a newer devkitARM, see if that fixes things.

All in all, not too bad. Better than having to use the smaller capacity, slower and obsolete parallel-port based flash cartridge that's for sure. Being able to load multiple GBA files is a bonus - the only way to do that on the old cartridge was using pogoshell (on Linux), FTP-ing the file over to the Windows 98 machine, then writing the ROM there with the special software. "Clumsy" is the word.

This new cart was a little pricey mind, costing €35 with a 2Gb card - although the older GBA cart I cost me more back in 2001 I'm pretty sure - but nowadays you don't have much choice about where to buy this stuff. I got this one from r4ds-ds.com and it took about 2 weeks to arrive from Hong Kong to here in Spain with the free shipping option.


Here is a link to the latest firmware


Tuesday, July 31, 2012

Why Some Remakes Are No Longer Available

You may have noticed that some of the remakes I wrote are no longer available. Here's the deal...

Back in April I received an email from Mike Singleton - of "Lords of Midnight" fame - asking me to take down the 2 remakes of his games that I had ported to Android. I've had the Game Boy Advance versions of these up for some years but now Mike is creating an iOS version and it's understandable that he wants exclusivity of his own work - Android is too close to home here. A bit of a shame, but there you go.

In his email, he points out the following:
A word of advice also - it seems you have also made some versions of Elite. I know for a fact that David Braben is very sensitive about his copyright in this, so be very careful.
In order to avoid any more problems I decided to pull down my Elite remakes too. In fact it felt good to know that I wouldn't see any more support emails asking for bug fixes ;-)

I believe that GBA and Nintendo DS remakes have flown under the radar as they are niche platforms. Android and iPhone are higher profile since they are mainstream and seem to be more "legit".
For example, in order to run homebrew on the GBA/DS you already need a piece of hardware that is associated with unauthorized copies of Nintendo games. Whereas the same remakes are easily downloadable by anyone for free from the app store without any extra hardware.

As it stands if I use the material from the original games (graphics, models, game data), then it is a textbook copyright infringement. The rest is then a matter of time until the copyright holder happens to notice and asks me to take the game down. I think changing art assets, place name text and not naming it the same as the original are a minimum for this not to happen. But then a remake loses its charm. Plus I'm pretty crap at art anyway :-)

The current status is that I've left my "Chaos" remake up on the Android store, plus the GBA remakes whose copyright seems to be in a state of limbo. I don't think anyone would care about the rights to Castle Master anymore, and Cyclone's author was last seen designing toys for Fisher Price. Julian Gollop has been quoted as saying he has released his early games to the public domain, so Chaos should be OK. He is still actively creating new games - I bought the rather underrated Ghost Recon game on the 3DS that he produced - so maybe even this is risky.

Anyway that's the story. At least I can say "it was all my own fault", not like poor ant512 who recently had to pull down his Earth Shaker remake - he sensibly asked permission from the original author - because the Boulder Dash copyright holders don't want anyone to make a 2D game involving dirt, rocks and diamonds but them.

Wednesday, February 22, 2012

On Doomdark's Revenge

According to my records today marks 8 years to the day since I released my GBA remake of Doomdark's Revenge. A few people have asked me "are you going to release an Android port of your remake?" - to mark the anniversary the answer is yes! and here it is! [Edit - or rather, there it was. I have removed these remakes at the request of Mike Singleton himself, who is working on his own Android versions]

"Is that Don Quijote?" asked my wife

In addition to an Android port, I've gone back and fixed several show-stopping bugs that were in the GBA remake. The updated GBA version is on my remakes site.
  • Lords artificial intelligence is no longer completely broken
  • Several crash bugs fixed
  • The game is faster (and smaller) thanks to using the right compiler flags
In the Android version I've changed the controls slightly compared to the original LOM remake. In particular, Google has now deprecated the Android menu button. I don't think this means they'll send someone round with a screwdriver to pry it off your old HTC Desire or whatever, but that we developers should stop using it. Up until now I'd always used Menu like the GBA Start button, but seeing this trend I didn't use it here and I've gone back to my LOM remake and removed the use of Menu there too. I don't think anyone will really miss my poor use of the Menu button, it was always a bit of a mystery what it was going to do.

While working on this, I spotted a bug in The War of the Solstice that caused it to crash on versions of Android prior to 2.1. Both remakes share a lot of common Android Java code, so fixing this in one remake also fixed the other. The lazy loading technique described in this blog post makes supporting older versions much less hassle.

In the near future, I am going to update the source code downloads on my GBA remakes site so it reflects the latest versions of everything. One thing at a time.

Back to that AI bug... A keen gamer brought it to my attention back in 2009, but I was busy doing other stuff at the time. Here's what he had to say:
However the AI seems not to work correctly. Using the Spectrum version thelords would usually catch up with their liege or head for their foe or weapon. Using your version there is no Anvildrak, Imgorarg or Kahudrarg heading for Luxor and I have yet to see any pair or group of lords. Instead I've seen several single lords right next to the Frozen Wastes.
At the time I wrote back saying that the bug was probably in the code that decided which way a CPU-controlled lord moves, but I didn't investigate further. Now I fired up GDB and stepped through the AI code. At the same time I also stepped through a suspiciously similar looking bit of Z80 assembly in the original game using fuse's built-in debugger. After comparing notes I immediately saw what the problem was - instead of going towards their targets, my code was sending the lords away from them! What a mess-up, but the fix was simple.

Another "bug" in my remake was a kind of meta-bug. Instead of compiling the code with optimizations on, I had compiled with gcc's defaults. This meant the 2004 remake was much larger and slower than it should have been. The binary came in at over 100kb! This new version is 77kb big - still over twice as much as would have fit in the Speccy's RAM you'll notice - and noticeably faster.

Saturday, January 21, 2012

How to recruit on LOM

I've had an email about how to recruit on my [edit - no longer available] Android Lords of Midnight remake - "the War of the Solstice". That means other people are probably stuck too and haven't asked. Here are the basics.

From the start of the game, go Northwest, Northwest, Northeast and you'll stand on the same spot as the Lord of Shadows. Here I've done it as Morkin, but you can use any of the starting group.


Now touch the name part of the text (where it says "Morkin. He stands in the Forest of Shadows, looking Northeast."). This brings up the "Think" screen.


On this screen, touch the right hand part of the text. This brings up the "Seek" screen, where you can do the recruiting.

On here, touch the option to recruit the Lord of Shadows. That's it!

Friday, January 13, 2012

Silly Predictions For Android Versions In 2012

English: The following chart presents the prev...Image via WikipediaLast week Google released the latest numbers with the percentage of each Android version accessing the Android Market. What really jumped out at me is the rise and rise of Gingerbread (2.3.x), and the fall of Froyo (2.2). In the past I've been a bit skeptical of Google's commitment to older versions of Android. Looking at the way things advance, it makes no sense for them to dedicate resources to try and make life easier for developers on older devices. Every year the release 2 versions ago more or less disappears, or that's the way things have been tending to go for the last couple of years at least.

Here's a graph of how the relative percentage has changed over the last 18 months. I've occasionally jotted down the percentage numbers in a spreadsheet, and the rest I got from the Wayback Machine. I've lumped minor releases together, so 2.3.1 and 2.3.2 are in the 2.3 bucket.



Version 2.1 (Eclair) is slowly disappearing, despite being at 55% back in July 2010. 2.2 (Froyo) is at 30% now, though in mid 2011 it peaked at 65% of the Google-approved devices online. Right now 2.3 (Gingerbread) is on the rise. I think the poor showing of 3.0 (Honeycomb) confirms that the driving force behind these numbers is mobile phones, rather than tablets. For those not paying attention, Honeycomb is only available on tablets, you see.

Given all that, here's my predict-o-graph of how things will go in 2012. The yellow area marks my completely arbitrary prediction values of how the percentages will change. I've pulled the numbers out my /dev/backside.



If everything follows the same pattern as previous years, by early summer 2012 Gingerbread will have peaked at about 60% of the market. By the end of 2012, Froyo will be on fewer than 10% of devices, Gingerbread will be on the slide, and the newest Android release - Ice Cream Sandwich, version 4.0 - will be taking over. I don't think Honeycomb is going to grow much this year, and the relative percentage of devices with 3.x may even shrink. No new tablets should be released with Honeycomb this year anyway - if they are released, they won't sell very well or will be upgraded to ICS pretty quickly - and most new or new-ish phones will have or get ICS too.

As for me, and the games I've put out on Android... I'll continue to target 1.6+, since I don't really do anything that warrants a newer release and 2.2. is all I've got (curse you HTC and your locked bootloaders!) I think that by the end of this year I may have to look at upgrading, by then a 2nd hand Samsung may have come down to the kind of cheapskate price I'm willing to pay :-)