MythTV Update

I just updated my MythTV box from Karmic to Lucid. There were a few things that needed updating, and it became a little like pulling on a piece of thread - one thing lead to another until it became quite the saga. I thought I'd document things so that others don't have quite the same pain.

There were two big things that changed: I updated my data store filesystem from zfs to btrfs. I updated my lirc configuration to use the new devinput driver.

zfs to btrfs

My machine has one 64Gb SSD with the root filesystem (ext4), and two 1Tb HDDs. Under Karmic I was using zfs-fuse on the HDDs in a raid1 (mirrored) configuration. They were one big pool, but I then had a number of filesystems on that pool that I could mount in different places - e.g. /var/lib, /home, /srv, etc. I had to do this because zfs-fuse gets harder to use the earlier you try to load it. By just using it for sections of the directory structure that load relatively late it was possible to use it for large data stores, but still have it be relatively easy to use.

Under lucid, zfs-fuse is now in the ubuntu repository, rather than an extra ppa. This made me think that the setup was likely to keep working... unfortunately that wasn't the case. After the dist-upgrade I ended up with a problem whereby certain of my zfs filesystems didn't show up in a zfs list and didn't mount with a mount -a. Given that I knew the names of some of the filesystems, I could mount them, but I didn't remember the names of some of the snapshots, and I couldn't figure out how to list them... so I decided to move to btrfs.

I've been thinking about switching to btrfs for a while. Having something natively supported in the kernel is likely to be faster, and I suspect the support on linux will be better. The question is then how to move from a raid1 zfs setup to a raid1 btrfs setup. Given that they're both raid1, you'd think it would be easy. Unfortunately, btrfs cannot currently add a second disk in a raid1 configuration after the filesystem creation - you have to have two disks at creation time. So I used a loopback device backed by a sparse file as my second device...

btrfs raid1 array creation

The two drives we're talking about are /dev/sdb and /dev/sdc. I initially removed /dev/sdb from the zfs pool leaving the pool in degraded mode. Then I did the following to turn /dev/sdb into the start of the btrfs pool: (I was basing this on the btrfs information here: http://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices)

# get the size of the disk you want to move from (in 1k blocks)
cat /proc/partitions # look for /dev/sdb1
# create the large, sparse data file
dd if=/dev/zero of=large.img bs=1k count=1 seek=<size of disk in blocks>
# mount it on a loopback device
losetup /dev/loop0 large.img
# make the raid1 btrfs filesystem
mkfs.btrfs -m raid1 -d raid1 /dev/sdb1 /dev/loop0
# mount the filesystem once
mount -t btrfs /dev/sdb1 btrfs-mnt
# if that didn't work, try mounting it using /dev/loop0
# then unmount it again
umount btrfs-mnt
# undo the loopback setup
losetup -d /dev/loop0
# remove the sparse file
rm large.img
# mount the drive again in degraded mode
mount -t btrfs -odegraded /dev/sdb1 btrfs-mnt

# make btrfs subvolumes and copy stuff onto the drive
cp -rp stuff btrfs-mnt/

# unmount zfs
# use gparted to re-partition /dev/sdc into one big partition

then I tried the following, which didn't work:

btrfs-vol -a /dev/sdc1 btrfs-mnt
btrfs-vol -r missing btrfs-mnt
# remount btrfs volumes in the right places and not in degraded mode

This began a saga trying to make btrfs to work as a raid1 system. Luckily, all my data was there and accessible on /dev/sdb1 in degraded mode (although I had a few heart-stopping moments - this procedure is for the brave at the moment).

The solution ended up being to update to a newer version of btrfs :). Lucid runs kernel 2.6.32 which was just as btrfs became at all usable, and it still appears to have some issues. I wanted to update to at least 2.6.34 and preferably newer.

There are two parts to btrfs - the kernel and the tools. I updated the tools by downloading the latest source package (for Natty) for btrfs-tools from https://launchpad.net/ubuntu/+source/btrfs-tools and building it locally on Lucid. It built just fine.

I also updated to a backported natty kernel. I added the ubuntu kernel ppa from https://launchpad.net/~kernel-ppa/+archive/ppa and then installed the linux-image-generic-lts-backport-natty package and associated headers.

Once these updates were done I was able, with only a little bit of playing, to get /dev/sdc1 added to the btrfs pool using the new style btrfs commands.

Remember to re-balance after adding the new drive to copy all the data across both.

There is still a weird issue removing the 'missing' devices - I don't get an error, but the 'missing' devices are still flagged as 'missing':

root@willvo:~# btrfs filesystem show
failed to read /dev/sr0
Label: none  uuid: f929c413-01c8-443f-b4f2-86f36702f519
    Total devices 3 FS bytes used 578.39GB
    devid    1 size 931.51GB used 604.00GB path /dev/sdb1
    devid    2 size 931.51GB used 604.00GB path /dev/sdc1
    *** Some devices missing

Btrfs Btrfs v0.19
root@willvo:~# btrfs device delete missing /data
root@willvo:~# btrfs filesystem show
failed to read /dev/sr0
Label: none  uuid: f929c413-01c8-443f-b4f2-86f36702f519
    Total devices 3 FS bytes used 578.39GB
    devid    1 size 931.51GB used 604.00GB path /dev/sdb1
    devid    2 size 931.51GB used 604.00GB path /dev/sdc1
    *** Some devices missing

Btrfs Btrfs v0.19

But it seems to be working anyway, so we'll leave that for the moment and move to the other issue. The new kernel doesn't just change the way btrfs works - it also changes the IR drivers. That means an update to the lirc configuration.

Updating lirc

The backstory for this update is covered here, http://wilsonet.com/?page_id=95, but the short story is that the drivers have changed and you need to switch to using devinput.

I have an Antec Veris system with a imon IR receiver and an Antec_Veris_RM200 remote. I don't actually use that remote though - it has too many keys and that just invites people to either a) complain it is too complex, b) press the keys and complain they don't do anything or c) both of the previous. Rather I use a LogiTech Harmony 525 programmable remote.

When I first set up my system, Logitech's auto-setup system didn't know about the RM200 remote - I had to use their learning system to program the Harmony. This worked ok, but I was never quite satisfied with it. When I set things up this time I figured out that with the new drivers I can switch the receiver into 'rc-6' mode which allows it to understand Microsoft Media Centre remotes. This is great as Logitech certainly does know about them. I followed this guide to set up my remote to act as a media-centre remote. I found there were a few buttons that my system couldn't interpret, so I had to switch some around - that wasn't a problem as there are plenty of options to choose from and most work just fine (but see below). One other caveat is that I couldn't get any of the 'Microsoft Keyboard' buttons to work reliably, just the remote buttons.

The setup on the linux side is a little more tricky. I found this thread useful, but did not follow it exactly.

Firstly, you need the ir-keytable tool, which I had to build from source.

git clone http://linuxtv.org/git/v4l-utils.git
cd v4l-utils
make
cd utils/keytable
cp ir-keytable /usr/local/bin/
cp rc_keymaps /etc/

Then when you run it, it will tell you the device to use for your remote:

# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event4) with:
    Driver imon, table rc-imon-pad
    Supported protocols: RC-6   Enabled protocols: 

But we don't want to use /dev/input/event4 directly as that may change when you connect or disconnect another input device. Rather, use ls -l /dev/input/by-id/ to see which device there points to the right device. In my case I want to use /dev/input/by-id/usb-15c2_0038-event-mouse because that points to /dev/input/event4, but will keep pointing to the right device even if it changes.

Now, switch your lirc configuration to using devinput:

sudo dpkg-reconfigure lirc

and then select

Linux input layer (/dev/input/eventX)

I selected None for the IR Transmitter, and then /dev/input/by-id/usb-15c2_0038-event-mouse for the device.

Next, we need to tell HAL not to grab the device. Following the advice here I looked in /usr/share/hal/fdi/preprobe/20thirdparty/ and noticed there was already a lirc.fdi file. I edited it to add the following:

 <match key="info.product" contains_ncase="iMON Remote">
    <merge key="info.ignore" type="bool">true</merge>
 </match>

Next, we need to switch the remote into rc-6 mode and update its keymap. This can be done using the ir-keytable command we built earlier. For example:

ir-keytable -c -w /etc/rc_keymaps/imon_mce

should do both. I had some problems with that however and played around with a few things. I'm not exactly sure which of these fixed the problems.

• At the top of the keymap, you'll notice it has a type: RC6. If you feed that to ir-keytable -p, then you sometimes seem to get an error. I think this should be RC-6.
• Secondly, a bunch of keys didn't work. In the end I made my own keymap file, imon_will, with the type changed to RC-6, all the keycodes from imon_mce and all the keycodes from rc6_mce
• Then you need to make sure the new keymap is loaded. I did this with brute force: I added the line /usr/local/bin/ir-keytable -c -w /etc/rc_keymaps/imon_will to /etc/init.d/lirc

And even that isn't enough to make the whole system work. I still found that lirc wasn't getting some keys. So I copied /usr/share/lirc/remotes/devinput/lircd.conf.devinput to /etc/lirc/lircd.conf.devinput and edited it as follows (basically adding 0x200 to some of the event codes - not sure why they need this):

--- /usr/share/lirc/remotes/devinput/lircd.conf.devinput    2009-02-08 05:00:41.000000000 +1100
+++ /etc/lirc/lircd.conf.devinput   2010-10-30 00:45:19.529971238 +1100
@@ -11,20 +11,21 @@
   pre_data_bits   16
   pre_data       0x8001
   gap          132799
+#  gap          39995
   toggle_bit_mask 0x0

       begin codes
-          KEY_0                    0x000B
           KEY_102ND                0x0056
-          KEY_1                    0x0002
-          KEY_2                    0x0003
-          KEY_3                    0x0004
-          KEY_4                    0x0005
-          KEY_5                    0x0006
-          KEY_6                    0x0007
-          KEY_7                    0x0008
-          KEY_8                    0x0009
-          KEY_9                    0x000A
+          KEY_0                    0x0200
+          KEY_1                    0x0201
+          KEY_2                    0x0202
+          KEY_3                    0x0203
+          KEY_4                    0x0204
+          KEY_5                    0x0205
+          KEY_6                    0x0206
+          KEY_7                    0x0207
+          KEY_8                    0x0208
+          KEY_9                    0x0209
           KEY_A                    0x001E
           KEY_AB                   0x0196
           KEY_AGAIN                0x0081
@@ -191,7 +192,8 @@
           KEY_KP7                  0x0047
           KEY_KP8                  0x0048
           KEY_KP9                  0x0049
-          KEY_KPASTERISK           0x0037
+#          KEY_KPASTERISK           0x0037
+          KEY_KPASTERISK           0x020A
           KEY_KPCOMMA              0x0079
           KEY_KPDOT                0x0053
           KEY_KPENTER              0x0060
@@ -200,7 +202,8 @@
           KEY_KPLEFTPAREN          0x00B3
           KEY_KPMINUS              0x004A
           KEY_KPPLUS               0x004E
-          KEY_KPPLUSMINUS          0x0076
+#          KEY_KPPLUSMINUS          0x0076
+          KEY_KPPLUSMINUS          0x020B
           KEY_KPRIGHTPAREN         0x00B4
           KEY_KPSLASH              0x0062
           KEY_L                    0x0026

Having made those changes you still need to tell lirc to use them, so edit /etc/lirc/lircd.conf to include /etc/lirc/lircd.conf.devinput instead of the default (for devinput) /usr/share/lirc/remotes/devinput/lircd.conf.devinput.

At this point your remote should work.

Lirc and gdm

There is one other tweak I made. I still use gdm on my system rather than booting directly into mythtv. I have the mythtv user set up to auto-login after 10 seconds. Before Karmic, this used to wait 10 seconds and then start mythtv every time. On Karmic and now Lucid, this only auto-login only works on the initial boot. If you exit myth then it will not re-auto-login. As I have no easily accessible keyboard, this is somewhat annoying.

I just added some extra irexec commands that run on KEY_UP, KEY_DOWN and KEY_OK events. These check if the 'mythtv' user is logged in, and if not then they use xdotool to generate approprate keyboard events. This allows you to use the remote to select the myth user. On Lucid you can then add that user to the nopasswdlogin group so that they don't need a password to login on the console (you want to make sure your remote access is still secure!), and people can now restart the myth frontend effectively with just the remote.

Android Lock Screen API Design

I want a better lock screen on my Android phone.

Moreover, I don't really want Google or HTC to design one. I really want a good API that allows others to design one. This is much the same design concept behind intents, widgets, etc; build the framework right, rather than building one particular implementation.

Which brings up the question: What would be a good lock screen framework for android?

Background

I made a previous Lock Screen Rundown. Since then I've also come across:

• WidgetLocker: A standard apk that replaces the lock screen. This allows widgets to be placed on the lock screen.
• AVLock: This patch requires root. It replaces the default home screen directly, and hence has none of the issues that others have been having with the current API.

It is also important when thinking about this to know what Google has said about the current API.

Desiderata

• Security
  • Phone security
  • It shouldn't be possible for an 'app widget' added to a lock screen to grant access to the phone when the phone is 'secure'.
  • Not a trojan
  • No Denial of Service (intentional or otherwise)
• Flexibility
  • Able to replicate the default lock screen on any commercial hardware (e.g. Eclair, Sense, etc.)
  • Able to replicate the 'lock screen replacement' apps currently on the market. (This is less important than the previous.)
  • Able to adjust what (hardware buttons/shaking/???) wakes the device (but see security/DoS)

Use Cases

There appear to be two classes of use cases for the lock screen: standard and secure. By secure I'm referring to the 'pattern lock' that tries to keep prying eyes out of the phone.

• A simple lock screen that displays the time and has a keylock so you don't pocket-dial.
• A more complex lock screen that displays some simple information and also allows basic interaction (e.g. control the music playback). Has a keylock so you don't pocket-dial.
• A very detailed lock screen with lots of information and interaction, like FlyScreen.
• A simple secure lock screen designed to stop someone briefly alone with the phone from accessing it. The lock function doubles as a keylock to stop pocket-dialing.
• A secure lock screen that displays some information. e.g. transparently overlay the pattern lock on top of something like Pure Calendar.
• A secure lock screen that displays information and has some very basic interaction (e.g. a play/pause button)
• A complex secure lock screen that has multiple 'pages', some of which you can interact with. There is a mechanism to 'unlock' the

Design Ideas

I'm going to start with phone security ideas. The 'unlock' swipe pattern, either simple for a keylock, or complex for something more secure, is going to be an important part of the configurability of the lock screen. This means that it needs to be configurable too. BUT, it also has stronger security requirements. Hence my initial plan would be to separate these: have a plugable 'lock' widget and a separate pluggable information screen. The information app can be complex. The lock widget is significantly more tightly constrained.

Information screen

I'd imagine that the information screen is like a home screen. It can do whatever it likes, but all intents sent from this screen are ignored. There are two ways that this app can be dismissed:

• If the menu button is held down for 5 seconds then you're taken to a built-in back door that lets you in if you succeed at Google verification. This stops DOS attacks, intentional or otherwise.
• The lock swipe is implemented using (something like) the widget API. That widget has access to the API that dismisses the lock screen.

This ends up looking much like the current lock-screen apps, but cannot exit itself. If it does exit it could be restarted, or their could be a fallback.s

Lock Widget

As noted above, the lock widget is significantly constrained.

• When the lock widget is displayed, it is carefully drawn in its own window on top of the information screen. It can be transparent, showing the information screen behind, but no events in the lock screen pass through the information screen app. This stops password 'sniffing'.
• The lock widget's pixel values should never be visible to other user code.
• The lock widget's apk should never have any permissions (except reading from the sd-card?). (The idea here is that the plugin can get information from outside, but it cannot send any information anywhere. It can only get information from outside in ways that don't leak information, so net access is forbidden as information could be encoded in the URL accessed.)
• The lock plugins should never be able to broadcast or call any intents.

• The currently designated lock plugin (and the menu-key override) are the only ways to dismiss the lock screen.

• If the user specified a lock widget that just automatically dismissed the lock screen, then it is possible to pass control of unlocking back to the information screen.

Implementation Issues

• How do you make sure the information screen is sufficiently locked down? I think this could be similar to the current behaviour.
• How do you make sure that events for the lock widget cannot be captured by anyone else? This seems relevant. I don't know how that relates to widget embeddings. Is it possible to make a widget that keeps its events and pixels private?

I'm looking for a good android lock screen.

Desiderata

• Lock screen with some form of security - e.g. pattern lock
  • What I'd really like here is a pattern lock that does NOT require me to swipe, then swipe again for the pattern.
• Lock screen can show me my calendar agenda
• Lock screen can show me the time
• Lock screen can do other lock-screen-esque things, like pause music, show new SMS's, missed calls, etc.
• Lock screen should include 'if found please call' information.
• Lock screen should include 'emergency dial' capability (but protected somehow so I don't pocket-dial).

Options

• Executive Assistant is a well implemented app that does most of what I want.
• myLock is looks like it is heading the right direction. Not sure it does everything I want yet, but is pretty close, and is open source so I might be able to make it do exactly what I want.

Previous attempts

I had a rooted HTC Hero rom installed previously. With that ROM I was able to make the lock screen transparent and put all the widgets I wanted on the home screen. I then used HomeSeek to make sure that the main home screen was showing behind the lock screen. This was good in that it showed my what I wanted without losing any of the standard Hero lock-screen functionality. It wasn't perfect however it in that it still required a double-unlock; I had to swipe down and then do the pattern unlock.

Current Thoughts

If I had freedom to design my own lock screen, I'd take myLock, and use the 'widget embedding' version. Embedding widgets allows me to get most of the other functionality without having to put it in the lockscreen app itself. I'd then use the android gestures API and put a GestureOverlayView over the top. The lock screen would unlock when the user enters the correct gesture.

This gives me more flexibility with the unlock gesture. It means that I don't have to swipe to get the 'pattern lock' screen - the front screen is the gesture lock screen.

Hi all,

I recently rooted my HTC Hero. I was a little disappointed to find out how insecure the result is. There is a sudo-like app called superuser that behaves as a basic gate-keeper. Any other app that wants something done as root asks the superuser app to do it. The superuser app checks its list of allowed apps, and if the app isn't listed then the user is asked.

The problem is that there is no password. This means that if you have a rooted phone, anyone who plays with your phone can quickly get a root shell (go to one of your shell apps, su and click 'allow', then you have a root shell). They can then use the installed sqlite3 app to, for example, get your Google password.

Ugh.

The MoDaCo Hero 3.1 rom also makes the usb shell (accessed through adb shell) default to a root shell.

Now, it is clear that if someone has physical access to your device then they have your data. Even if you have a stock phone, they could root it and then go looking through your data. But in this case the attack goes from rooting the phone (which requires multiple reboots, takes at least 10 minutes, and leaves an obvious trace) to running a few shell commands (limited more by typing speed than anything else).

Anyway, as mitigation I decided to enable the pattern based lock screen. But that is annoying. I use widgets on my home screen to get information regularly, and constantly entering the pattern is slow. (It is also not wonderfully secure, in that your finger leaves greasy trails on the screen and they show up fairly clearly if you hold the phone at the right angle in the light.)

I spent a while looking for a lock screen replacement app that allowed me to place widgets on the lock screen. I couldn't find one that I liked. The two best were Flyscreen and Executive Assistant, but neither of them was perfect.

I then stumbled across the fact that the default HTC Lockscreen can be made transparent. A standard HTC phone allows you to personalise the lock screen wallpaper. By default it saves a jpeg file to use as the lockscreen in /data/misc/lockscreen/lock_screen_port (note that the trailing .jpg is not there). Luckily, the app can use more than just jpegs. If you put a png file there, the lock screen will happily use it, and png files have an alpha channel - transparency. You can have anything from a totally clear lock screen to a 50% dimmed lock screen, or anything else.

My new lock screen image is completely transparent except for a brief "If found please contact" message. This means that when the phone awakens, I can see the last used screen behind the lock screen. As long as I hit 'home' before I switch off my device, I get my standard home screen, with its useful widgets showing right through my lock screen. I also get all the normal HTC additions like Music controls on the lock screen, etc. When I touch the screen and start dragging down to unlock, the patten unlock view immediately appears.

Thanks to the xda developers for pointing me in the initial direction for this (they recommended deleting the /system/etc/lockscreen/port directory to get a completely transparent lock screen). It was starting from that approach (which requires modifying your system image), that I discovered the lock_screen_port file above that is accessible without modifying your system image (although it might still require root permissions to modify).

I've been wanting to get a street map on my phone that doesn't require a net connection. I have 16Gb of sdcard - I'm happy to use it for maps. It also seems a shame to pay for map data when OpenStreetMap does such a good job. Or rather, if I'm going to pay someone, I'd pay them for the service of updating the OSM data. I wouldn't subscribe to streetmap data.

But, there is no Android app out there that scratches all my itches yet. As I noted last week, the Android content provider concept should allow the separation of the data store from the display and allow the data to be used for different things. This seems like a nice idea. Exactly what those provider interfaces should be is a more interesting question. Before we get to that, let's review the current OpenStreetMap offerings for Android.

Current Apps

There is a list of Android OSM apps on the OSM wiki. I've now tried a bunch of them, and here are my current thoughts (at time of writing - this will get old fast I suspect).

MapDroyd is a vector map viewer on Android. It is commercial. It uses a proprietary map format which 'Breaks "sonic barrier" of loss-free street map compression' by using lossy compression. MapDroyd displays quite quickly. The problem with this is that their maps appear to be poor quality. I've discovered problems with them in the region near my house - problems that don't appear in the OpenStreetMap data.

Navit on Android is a port of the Navit project. Navit works, but the port I tried was extremely SLOW on my Hero. This was a 2D map display. I understand that Navit uses its own C++ renderer under the hood.

osmdroid is the grandaddy of OSM apps for Android. It uses 2d tiles, downloaded from the web - the same as the OSM slippy map. These map tiles are cached on your android device, but the default cache is small. It appears fairly easy to modify this app to read from a tile cache on the sd-card.

osm-android is an open source vector map viewer. It is SLOW, even though it uses its own binary format. It is both slow to convert an OSM XML file into its format, and slow when in use on the phone. It was in looking to speed this app up that I reached most of the conclusions below.

Design Discussion

Lets break the discussion into two parts: map display and route finding.

Map Display

Looking at the OSM-Android code, I noticed a few things. It uses the fairly standard 'tile' concept to index its data. The tiles are stored at variable resolution. The slow performance appears to be because there is not enough approximation in the data - figuring out what to display takes time because the data contains more information than is needed for the display. (Note - this is talking about display speed. Conversion speed is slow because OSMAndroidConverter loads the entire .osm file it is converting into ram, and this runs out of ram and swaps badly.)

So then I started looking at inventing a variable resolution data structure for the map data that would only contain relevant data at any level. It would smoothly drop out detail as you zoomed out. It would also drop out detail from the edges of regions when you're in the centre of them.

For example, imagine you're displaying a small town in central Australia. You need to know that you're in the middle of Australia, and hence use the appropriate background colour, but you don't need to know the exact shape of the coast near Sydney.

I came up with a data structure to do this. To make things efficient, there was a bunch of processing that I was offloading to the format converter. But as I offloaded more and more, it started looking very much like a vector graphics format (not exactly, but there were similarities). If I'm going to store vector graphics, why not jump straight to SVG and use Mapnik to do the rendering? I'd get much nicer looking maps.

Furthermore, once you've jumped to using an image format, why bother staying with a vector format - whether you use a vector or a raster format depends on storage size, and for very pretty maps I could easily imagine the compressed raster format being smaller.

The big loss with jumping to an image format is that the maps no longer rotate nicely. In particular, text and some icons should be written the correct way up. But text and icons are usually the top/last layer of any rendering process. One could store multiple tile-sets. One of base map that can be rotated, and then four more with labels printed at the four compass directions. The labels would compress very well as those images would be mostly transparent. The result would be names and icons that are never more than 45 degrees out.

Even if you were doing 2.5d maps, this pre-rendering approach should still work well - treat the map tiles as textures for OpenGL. Again, the text and icons are the bits you might want to add later.

Choices

If I was to decide on a solution today, I'd go with cached image tiles. Having said that, there is no reason why the map tiles couldn't be generated on the phone if that is really needed, although a pre-generated set would probably work just fine. You could use osmdroid to display the map, have a map cache on the sdcard, and also have a map tile provider that generates map tiles which are not in the cache from streetmap data. Locally generated tiles would take longer to display, but you don't often need to display the map for a completely new area.

Route finding

The issue with using an image format for map display is that you can't use the same data for route finding. On the other hand, it frees you from having to use the same format for both - a separate data-structure can be used for storing the map that you route-find over. I haven't given this as much thought.

Having listed the Android Apps I currently have installed on my phone in my blog post from last night, I'd now like to list the things that are missing from my android phone.

Mapping and Localisation

The first thing that is missing is a decent turn-by-turn navigation app. I'm looking closely at CoPilot Live, but they don't seem to be releasing Australian maps yet.

I'd want something that runs offline. It would be great if I could get something that works with the OpenStreetMap data. There are a number of people working on this, some listed on the OpenStreetMap Wiki. Unfortunately none of them are quite there yet.

If I was designing an application of this sort, I'd split it up so that different apps supplied different bits of functionality. This would allow the functionality to be used by different parts of the system and hopefully increase the rate of development of all the apps.

Vector Map Data

I'd like an app that supplies information about the local streets to other apps. I imagine an assistant app with an API published on Open Intents. This can then be used to display a picture of those streets, to plan a path, or anything else.

The app would take a level of resolution and a location and return a 'tile' of data that includes the point supplied. There would also need to be APIs to get neighbouring tiles of data.

I imagine that the standard implementation would read OpenStreetMap data from the sdcard. A more advanced version could incrementally download the OSM data from the OSM web-site.

It might be good to define APIs for things like traffic data too so that these could be added later where they're available.

Filtering

I'd like to have an App that uses the vector data supplied by the program above and the Location Provider android API. It should take the provided location as an observation for a multi-hypothesis bayesian filter. Each hypothesis is constrained to be on a nearby road. See this paper for the ideas.

The overall goal of this filter is to help fix the poor localisation I get with plain GPS on my Hero. In many situations it is great, but sometimes it can return a position blocks away from my actual location. This is unhelpful for a Turn-By-Turn directions system. Moreover, it doesn't always seem to correct itself as I walk around.

The aim of this filtering system is to combine knowledge of the road network with knowledge of the GPS position to improve the accuracy of the localisation. If I turn a corner, then any of the hypotheses on a road that doesn't have a corner should be ruled out. In this way the system should converge on a good position estimate even if the GPS unit is being confused by buildings or power lines.

Having tracked the location, this app should then provide it again using the Location Provider API so it can be used by any other app.

Offline WiFi location

It would be nice to be able to localise without either the GPS unit (which uses a fair amount of power) or network access. This could be combined with the Locale app to have low-power location-aware switching of phone state.

A simple app that allowed you to specify particular WiFi Base station MAC addresses and their locations, and which then provided those locations using the Location Provider API with large range, would solve this problem.

This is similar to SkyHook Wireless or Google maps, but keeps a small number of MAC addresses for offline location detection.

Indoor mapping

You could do this to localise indoors. Not sure this is worth the effort over the simple approach above.

Map Display

It would be good to have something that can take vector maps from the map supplier above and produce a nice map for display on the phone. Something like MapDroyd or OSM Android.

It would be great if it could also do 2.5D maps, and allow overlays. It should also respond to the same set of intents as OSMDroid and Google Maps, so it neatly replaces the standard maps.

Contour maps

It would be nice to be able to overlay contour maps. Some Australian contour maps appear to be available.

Route Planning

It would be nice to implement a simple app that asks for a source and destination and then plans a route for that trip. In 'tracking' mode it should be repeatedly re-planning and alert the user when they need to turn around. It should be possible to layer the path on top of the Map Display above.

Turn By Turn Directions

With Route-Planning already implemented, adding turn directions is the final layer on the cake to replace something like CoPilot Live.

Timetables

Together with this tracking, it would be nice to detect when people are on a bus and display current locations of the busses in a city. If this worked well, then we wouldn't have to worry about the NSW STA locking down their data. We could just generate our own.

Locale Changes

The extra Location Providers above would already help Locale make sensible decisions. There are some extra features that could be good for it though.

Carry detector

Add another condition that looks at the g-sensor over time to detect if the phone is being carried or is sitting on a desk. I assume that people move enough that you could tell the difference between a phone is someone's pocket and a phone sitting on a desk, even if they're sitting quite still.

Renotification

It would be nice if Locale could be made to re-notify the user if there are any notifications active when the ringer is turned back on. e.g. If I get an SMS when in a meeting and so my phone doesn't beep, but then I leave the meeting, when Locale resets to the default ring volume it should beep to let me know an SMS had arrived.

Persistent Notify

Add a way to have the phone re-notify if there are active notifications. Should also have a Locale Plugin to switch it on and off.

Combined with the 'carry detector' described above and Locale this could be made to only repeat notifications when the phone is being carried.

Javascript Calculator

I use the Calculate widget on my Mac and really like it. I'd love to see a similar app on Android. It would need to have a nice calculator keypad with the option to bring up the standard ASCII virtual keyboard. I want something that includes these functions. There are other javascript calculators apart from the one above, e.g. Mochikit.

AusLan Dictionary

I'm currently learning Australian Sign Language (at TAFE). It would be nice to have a dictionary like SignBank on my phone. Perhaps a sign-english dictionary would also be possible (Using something like the system in this book).

MobileOTP

MobileOTP is a One Time Password system. It would be nice to have an android app rather than having to use the J2ME one.

---

A few more quick things I forgot to add this morning...

Sync

I want a contacts sync app for my mac that doesn't suck. Syncing the calendar through Google is OK, although I'd be just as happy not to give them all my data, but syncing my contacts through Google to MacOS address book just doesn't work well enough. I'm hoping that Missing Sync will fill this niche soon.

Things are quite close to working. Funambol have an android SyncML client for contacts. The problem is that Apple's core sync services don't speak SyncML. The iSync app translates their core sync service into SyncML, but it is based around the OBEX protocol for USB and Bluetooth, and the HTTP bearer isn't easy to get working. Either OBEX on the Hero, or HTTP on the Mac would complete the connection... for contacts at least. I think missing sync is probably a better option.

PPTP VPN

NICTA uses a VPN for its internal wireless network. While I get the reasons for this, it means I can't use my phone at work until I have a PPTP VPN. I need to either root my phone or wait for donut to be ported to the Hero.

Having just got a new phone, I spent a while looking for good apps to put on it. I found most of the markets pretty useless. I don't know if I have different taste from everyone else, but there just seems to be a lot of dross there. The reviews tell you basically what the app does, but if there are a bunch of apps that do the same thing, it was hard to get a decent rating between them. Also, the apps are not very well categorised - 'Tools' is just too broad a category.

One, perhaps uncommon, constraint I have is that I don't have a data plan for my phone. While I'm within WiFi range I'm fine. When I'm mobile I have my net connection switched off.

Here are the Apps that I have on my phone at the moment:

TouchPal

This is a great app made by CooTek who have been making virtual keyboards for Windows Mobile for a while. It replaces the default virtual keyboard on my Hero (or any other android phone). Its predictive text seems to be better than most others, and it just seems to work better. When I downloaded this app it was free, but I'd pay for it.

There are still some rough edges on this app. While the keyboard itself is great, there are some oddities in the way it interacts with the rest of the system. I hope that these are sorted out soon.

Pure Calendar Widget

The Pure Calendar Widget is one of the few apps that I paid for. It is great! It allows me to have a large agenda for the next few days displayed on the home page of my phone. It does this simple job well. Surprisingly, this wasn't a common feature in many of the calendar apps I saw.

MoreLocale

While I purchased it in Australia, my HTC Hero was imported from Taiwan. It came with a default set of international locales, which do not include Australian English, British English or American English as selections. I assume this is to help HTC segment their market.

Anyway, MoreLocale allows you to set your phone to any of the many locales supported by Android regardless of the subset the standard preference app gives you. Useful for both developers and users of imported phones.

SIM Checker Lite

SIM Checker Lite is an app that will send you an SMS and/or an email when someone puts a different SIM card in your GSM phone. Given that the Hero is not exactly cheap, this seems like a good app to have. The nice thing about it sending an SMS when the SIM card changes is that you get the number of the new SIM card.

Security is one of those areas where I have a strong preference for Open Source. There don't seem to be any good Open Source solutions for android that I could find, so I currently use this and the following application.

Kor.im Phone Locator

Phone Locator does exactly what it says -- it allows you to locate you phone. You can send it one of two SMSs. The first one has the phone respond with its location. The second has ring on full volume -- more useful if you phone is lost at home rather than being stolen.

Share Your Board

Share Your Board is a great app for saving a whiteboard of information. The camera on your phone takes a picture of the whiteboard. An edge-detector detects the rectangle that is the whiteboard, crops out the surrounding walls, and then a perspective projection is applied to square the photo up. White balance is then applied to clean up the image. The end result is a much better image of the whiteboard than you could otherwise take. Great for archiving whiteboards after a discussion.

Wifi Analyser

Wifi Analyser is a very simple app. It prints out the available WiFi networks with their channel and signal strength in a very simple format. Useful if you want it, useless for most people.

OI Flashlight

This is a very simple flashlight app. No ads, low memory footprint, can have the colour adjusted; but basically just gives you a white screen. There are a few apps out there that do this. I chose the Open Intents one because I like what they're trying to do. Given the choice between two equally good, free apps, I'll take the open source one over the closed source one. Then I'll take the well-maintained one over the poorly maintained one. OI gives me both.

OI File Manager

Again, there are many file managers. I went with the Open Intents one. It works fine.

Shazam

Shazam is a great app if, like me, songs you like, but don't know their names. Simply let to record some music and it will

ConnectBot

ConnectBot is an ssh client for Android. Unfortunately there are some adverse interactions with TouchPal.

A useful feature here is port forwards. Using a port forward from this device I can access my home web server securely from the net on the android web browser.

Scientific Calculator

Scientific Calculator is the best calculator I've seen. That's not to say it is as good as I can imagine - i.e. it isn't as good as the Calculate widget I use on my mac. But it is a reasonable, albeit simple, scientific calculator.

Locale

Locale is an app that allows you to schedule certain things to happen on certain triggers. e.g. Turn the phone to vibrate only when my calendar shows I'm in a meeting.

There are various plugins available that allow you to add extra effects. Unfortunately there is no way to add extra triggers.

While I feel this should be useful, I find that I don't actually use it all that much.

MythDroid

MythDroid is the best of the MythTV remote control apps I've seen. It actually acts as a remote control, as well as giving access the EPG.

This app is not available through the market - its .apk must be downloaded and installed separately using the Android SDK.

Aldiko

Aldiko is an e-book reader. I also needed to install Stanza on my Mac to convert some eBooks to the correct format. I'm not particularly wedded to Aldiko, but it seemed the best (performance/price) of the few e-book readers out there.

MapDroyd

I wanted a map application that used the OpenStreetMap map data offline. MapDroyd does this, and seems better than the alternatives, but I'm using it because it is the best of what is available, not because it satisfies me.

SipDroid

I have SipDroid installed on my phone, but I haven't got around to setting it up yet. I used to have a sip server running on my home server, but that's down at the moment. I have this installed, waiting.

Text to Speech library

The Text to Speech Library doesn't do anything by itself. It allows other apps to speak text though. There are some other eyes-free apps available that I tried briefly, but I didn't use them, so I removed them from my phone.

MyTracks

MyTracks is a GPS logging app for android phones.

Barcode Scanner

BarCode Scanner is both an app and a library that can be used by other apps. It provides scanning of multiple kinds of barcodes, including the square QR ones. It can then do a google product search on the UPC code. There are more full-featured barcode scanners out there, but I don't actually use this it that much so I just wanted something simple. This seems to be the simplest of the full-featured readers.

Google Sky Map

Google Sky Map is a fun little app. It uses the G-sensor and compass in the phone to detect where you are pointing your phone. It then displays a labelled map of the sky in that direction.

AnyCut

AnyCut is an app that allows you to make a home screen shortcut to execute any Android intent. Very powerful. There is a simple user-interface for the basic uses of the application. There is a complex user-interface for the full power of the application. I found myself a little stuck with this app. The simple part is too simple for my liking, but the powerful part a little complex. It really needs some work on the complex UI.

I can think of two things that would improve the complex UI of this app:

• It would be great if it could record all intents that were triggered on the phone in a short period of time, and allow you to select from those. This would allow you to program shortcuts by example. (On my Hero I have multiple intents that are detected by AnyCut with the same name. I don't want to have to figure it out by trial and error.)
• It would be nice if there was a web site that recorded which intents are used by various apps so that you could crowdsource the intents - something like the secrets list for MacOS X.

TasKiller Free

TasKiller is one of a number of Task Killer apps on the Market. I don't really know how to choose between them. I chose a high ranked free one as I haven't really had to kill many tasks. It seems to work OK.

There is a button to kill all tasks. This doesn't seem to be something you really want to do, at least on my Hero. You'll spend a little while waiting for the TouchFLO home screen to start back up.

Android Intent Playground

The Android Intent Playground allows you to send arbitrary intents within the android system. Sometimes useful for developers (and tweakers?). Note really useful for end users.

Android Scripting Environment

The Android Scripting Environment gives you a number of scripting languages on your phone, e.g. Python, Lua, JRuby. Also comes with a Locale plugin so that the scripts can run as the effects of locale actions. Allows Locale to do most things.

This app is not available through the market - its .apk must be downloaded and installed separately using the Android SDK.

Bubble

There are many bubble-level apps out there. Bubble is the one I chose. It seems fine.

Compass

A simple compass app.

AndFTP

AndFTP is a simple FTP/SFTP/FTPS client. Given that there are no Bluetooth OBEX file transfer profiles on android yet, and Androbex doesn't work on the Hero (at time of writing), this is one way to get files to and from the phone apart from the USB cable.

AutoLock

The android OS blanks the screen to save power relatively quickly (it is adjustable, but you want to relatively quick to save power ). It has an annoying habit of turning off just as you're about to get back to it. If you have your phone locking for security, this can be annoying.

AutoLock allows you to have a longer timeout on the lock than there is on the screen blank. This keeps the security of the screen lock, but makes it much less annoying if you're using your android phone intermittently.

Places Directory

The Google Places Directory app allows you to find shops near your current location. Requires a net connection.

OI Update

OI Update is a support program mainly for use by developers. It provides a mechanism so that any apps that use it don't have to develop their own update procedure. The google Market already does some of this, telling you if an app is up to date, but google Market requires you to look at it. This app checks itself and notifies you.

Something like (albeit much simpler than) Sparkle for MacOS X.

OI About

OI About is another Open Intents support library. It is only useful for end-users if they have another app that uses it.

OI Safe

OI Safe stores encrypted data for both the user and other applications. The data can be unlocked once and then auto-lock at various times.

OI Notepad

A simple Notepad add. Can use OI Safe to encrypt notes, although I don't use this feature.

Google Search by Voice

This is an app that allows you to search by voice. The result is that you don't need to type long search queries. Requires net access, but then so does searching.

My Maps editor by Google

MyMaps for android is a google app for playing with maps. It allows you to overlay your own maps on the maps app.

Java/J2ME Runner

While Android is based around Java, it uses its own VM rather than the standard Java VM. This means it, by default, cannot run normal Java apps. The Java/J2ME Runner allows you to take normal J2ME apps and run them on an Android device.

In general this doesn't work amazingly well. The apps run, but they aren't pretty. You'd be much better off with a native app. But, if you need to run a particular app, and there is only a J2ME version, then this is a great solution.

In my case, I wanted to run MobileOTP... until I get a proper android port written.

DeTeXify

DeTeXify allows you to draw a LaTeX symbol on the touch screen and it will try to figure out the tex to give you that symbol. I assume this app uses this web service. Requires a net connection, and isn't perfect. There are times when I'd just like a nice PDF latex reference manual so I can look up the command myself.

aiMinesweeper

A Minesweeper game.

TiltMazes

TileMazes is a Sokoban/puzzle style game, not a NeverBall/arcade style game. Controlling it with the 'tilt' sensor is actually a bad way to play. Fun though.

Sudoku Free

This is a simple Sudoku app.

BreakTheBlocks Lite

BreakTheBlocks is a simple Breakout clone. You have to move the paddle to hit the ball. The ball has to hit all the blocks to end the level. Touch control is an interesting addition to the standard breakout game.

I've been hacking on the Ikiwiki wiki software for a while in my spare time. I've used it for the COMP3431 class wiki. I've just decided today to use it to clean up my CSE web pages. Hence these shiny new pages.

That means I've spent a chunk of today porting my old html pages to Markdown. There are probably bugs there. It also means that the creation dates on all those old files are wrong. Hopefully I'll get to fixing the rendering bugs before too long.

Hello dear readers,

I've recently purchased a shiny new HTC Hero. It is a nice phone. It runs the Android OS.

My first impression is that it works very nicely. The Android apps are less polished than those I've played with on the iPhone, but the design of the OS seems nicer -- there is more opportunity to replace parts of the system and customise.

The HTC apps appear more polished than the default Android versions, but it still isn't quite as nice as the iPhone for end users. For tinkerers, the android phone wins I think.