ExifTools

I upgraded my Galaxy SII to a custom version of Android 4.0.4 Ice Cream Sandwich the other night, and it’s been brilliant – except for one little bug. If I go into the Gallery app, images on my microSD are in a semi-random order. If I tell Android to group by time, the problem becomes apparent: large numbers of images, always in contiguous blocks, are thought to have been taken between 1992 and 2018. I didn’t have an Android phone in 1992, and 2018 hasn’t happened yet – clearly, it’s a bug.

A quick search turned up this Google Code issue, which matches what I’m seeing exactly: GPS data is sometimes corrupted as it writes to the image. Worryingly, the bug dates back to at least Android 2.3 Gingerbread – which I can confirm, as the images in question were taken while the Galaxy SII was still running 2.3.4 – but Google promises a fix is incoming.

Here’s an example of the problem. The GPS Date tag from a non-corrupt image reads 2012:10:30 – year, month, day with a colon delimiter. The GPS Date tag from a corrupt image reads 0112:09:26 – a clearly invalid date which is confusing the heck out of the Gallery app. (You can check this out yourself with the command exiftool -gps:GPSDateStamp filename.jpg)

But why have I only just spotted the problem? Simple: the ICS – and Jelly Bean – Gallery app has changed its behaviour from previous versions. Where the old Gingerbread Gallery used to use the file modified date to sort the images, the ICS and newer Gallery uses the GPS Date Stamp tag from the EXIF data – the very tag that is being corrupted by the bug. Why it does that, I have no idea: there are numerous other EXIF tags which have the right date stamp and would be more appropriate for sorting, such as the Date Time (Original) tag. Perhaps that’s Google’s fix: modify the Gallery to sort on a different tag.

A pending fix doesn’t solve the fact that I’ve got a few hundred images with corrupt EXIF information, though. Switching to a third-party image viewer, like QuickPic, orders the images correctly, but that’s a workaround at best. So, I’ve written a quick tool to correct the invalid EXIF data on all my images.

It’s a bash shell script, and simple enough: it calls the ExifTool Perl package to copy the date from the Date Time (Original) tag over the top of the GPS Date Stamp tag. The result: the invalid tag goes away, Android knows what year the image was taken, and it orders the gallery correctly. It’s a hack: it overwrites the GPS Date Stamp of all JPG images in the current directory, regardless of whether the year makes sense or not, but it fixes the problem – albeit slowly.

You can find the script on GitHub. Hope it helps!

When you’ve corrected your images, you’ll need to go into Settings and Applications on your Android phone. Choose ‘All,’ find the Gallery app and tap it to get into the menu. Hit ‘Force Stop’ and then ‘Clear Data’ – don’t worry, you won’t lose any images, this just deletes the file database and thumbnail cache. If you don’t, the Gallery will still use the old ordering data and you’ll still have a problem. When that’s done, load the Gallery, let it find your files, and enjoy having all your images in the right order.

Oh, and one other thing: take a backup of your images before running the script. Although it worked fine for me, I can’t guarantee it won’t corrupt images further – and I don’t want to be responsible for you losing your precious photos.

Android Terminal Emulator running on a Milestone

Android Terminal Emulator running on a MilestoneRooting your Android smartphone can offer some pretty amazing benefits, from simple things like the ability to take screenshots to the option to use your handset as a Wi-Fi hotspot.  Perhaps the most impressive, however, is the option to change the apps that are pre-installed on your ‘phone, and replace them with your own.

In the case of my handset, a Motorola Milestone, app memory is at a premium: with just 196MiB of user-accessible storage on-board, larger apps can often mean having to remove something that’s already installed.  Thankfully, there’s a cheater’s way of freeing up some much-needed space: turn your optional apps into pre-installed versions.

First things first: you’re going to need a rooted handset.  If it’s not rooted, this tutorial will get you nowhere.  If you’re new to rooting, try the Easy Root Compatibility Test which offers certain ‘phones a one-stop solution.  If your handset isn’t supported, try one of the many guides on-line.

Once you’re rooted, you’re going to need a terminal emulator.  Install that, and you can get access to a shell – which is where the fun begins.

Step one – find out what’s mounted where with the command

 mount

You’ll see that we have a bunch of devices mounted in a bunch of locations, but the one we care about is /dev/mtdblock6, mounted as /system.  It’s in this special directory that Android stores all its internal gubbins – and to stop you from fiddling around with it, Google has very sensibly made it read-only.

Sadly, that also stops us from moving apps from the very limited user memory into the otherwise wasted system memory – and from deleting unwanted pre-installed apps, such as the Motorola-branded sat nav package that comes with the Milestone or the Facebook app that arrived unexpectedly as part of Android 2.1.

So, what can we do?  Easy: we re-mount the device as read-write.  You’ll need to become root using su, after which you can remount the block device.  Just type the following commands in to the terminal:

su -
mount -o remount,rw /dev/mdtblock6 /system

Now we have full read-write access to the /system file system. Bring up a directory listing of /system/app/ with:

ls -l /system/app/

You’ll notice that all the .apk files for the pre-installed apps are here.  Delete any .apk with rm and it’s gone for good – so for goodness’ sake be careful.

We can use the same command to take  a look at the .apk files for the apps we’ve got installed in user memory, too:

ls -l /data/app/

To move a package from user memory to system memory, making it ‘pre-installed’ and freeing up useful user memory, just do the following:

cp -f /data/app/com.publisher.packagename.apk

The file will be automatically removed from user memory and appear to vanish – but when you restart your ‘phone, it will re-appear as a pre-installed ‘system’ application.  Do this with a larger app, and you can free up a lot of valuable space.

A note about updating: because /system is mounted as read-only, the Android Market can’t write to it in order to update packages.  Instead, if an update for a pre-installed package is available, it will write the data back into user memory.  So, if you’ve saved 4MiB by moving Google Maps into /system, you’ll lose it all again the next time Google releases an update.

While it’s possible to get the space back – simply repeat the method of moving the file to /system again – it’s probably better to move applications that don’t get updated all that often.

That’s it: you can now enjoy significantly more space for apps!

The WePad slateAll this talk in the media about the iPad – and there’s plenty of it, with an estimated 80% of the articles in my RSS feeds over the last few days being iPad related in one way or another – has whet my appetite for a slate-style device, but one that offers a little more flexibility than Apple’s locked-down PoS.

The first thing to catch my eye was the WePad from German manufacturer Neofonie.  The specifications call out to me – 11.6″ 1366×768 display, SDHC card support, USB ports, Android operating system, and a 1.66GHz Atom processor all pretty much crap on the iPad from a very great height, with the sole exception being the mere 6 hour battery life to the iPad’s 10 – and it looks shiny enough, but sadly it’s not yet available to buy.

Okay, so Android – if not rooted – is still a locked-down platform, but compared to the iPhone OS – as found on the iPod Touch, the iPhone (obviously) and the iPad – it’s as free as a kilt and no knickers.  Neofonie has even promised that, despite the fact they’re aiming the WePad as a platform for its WeMagazine digital publishing platform, full access to the Android Market will be granted – meaning third-party applications can be installed without restriction.

I’m still undecided as to the relative merits of the slate form factor, but the WePad has certainly got my attention – and not just because it sounds like a euphemism for Tena Lady.

AppBrain screenshotI’ve stumbled across a neat toy in the form of AppBrain, a snazzy bit of kit for Android ‘phones that finally brings the one feature I’ve been missing since getting my Milestone: a desktop interface to the Android Market.

It’s a simple concept: you install a client app on your ‘phone, and then it syncs to the AppBrain website – free of charge, of course – and allows you to browse your installed applications.  Where things get clever is that you can queue up tasks – such as uninstalling an application or installing a new one from the Android Market, which is fully accessible from AppBrain’s site – and then sync them to the client app, which carries out your demands.

It’s a neat solution to a thorny problem – finding decent applications while using the quite frankly cramped Android Market interface on the handset itself – and the fact that it’s free is the icing on the cake.

Oh, and it allows you to share your installed apps too – like so:

Although as you can possibly see, it has a tendency to limit itself to the first few in the list.  Still, if you want to install it and give it a go yourself just scan the QR Code below.

QR Code for AppBrain