Once you updated your Xperia X10 Mini Pro to Android Gingerbread, you will soon find out that the underlying Cyanogen Mod 7 is not able to pair automatically with this device. Every time the LiveView is disconnected you will have to turn on your mobile phone and press ok to confirm a re-pairing request. This defeats the purpose of the LiveView completely since you will have to pull out your device multiple times a day – just to give a stupid confirmation. Yet, there is a simple workaround that will fix this nerve-wrecking bug.
Sony Ericsson’s Liveview
The fix for the pairing problem is hinted in this post on XDA developer which points out that changing the values contained in the file that holds the Bluetooth link keys (i.e. /data/misc/bluetoothd/<local adapter address>/linkkeys) is working as expected. To really understand what was going on, I began to dig a little bit deeper. Since Android is using Bluez as its Bluetooth stack, I started browsing through their website to get some hints on the format of the link key storage file. Unfortunately, this seemed to be a dead end, so I went to their git repository and had a look at the source code.
After some code browsing, I finally ended up at storage.c which is responsible for reading and writing the link keys to the storage file. By looking at the write_link_key function, it became apparent that the lines in the link key file exhibit the following structure <remote peer address> <link key> <link key type> <pin length> where remote peer address is defining the 6 byte address of the remote Bluetooth adapter and link key is defining the key as a 16 byte number in hexadecimal format and both, link key type and pin length, are specified as integers.
After pairing the LiveView with the mobile phone, this file contains an entry that looks somewhat like this 01:23:45:67:89:AB 0123456789ABCDEF0123456789ABCDEF 4 –1. Apparently, this means that the device with the address 01:23:45:67:89:AB is using the link key 0123456789ABCDEF0123456789ABCDEF. Furthermore, it also means that the link key has not been generated using a pin (i.e. the length of the pin is –1) – which is correct since LiveView pairing does not require the manual specification of a pin. Instead, both devices will automatically agree on a random encryption key and, to prevent man-in-the-middle attacks, they will ask the user to confirm that both devices are showing the same 6-digit decimal number.
Due to this process, it is up to the user to confirm the authenticity of both communication end points – which he or she eventually accepts or declines (by pressing ok or cancel in the pairing dialog). However, it seems as if this authentication process is not reflected accurately but it is lost somewhere in the software stack – i.e. I guess that the key change from unauthenticated to authenticated is not propagated properly and only stored in memory. This is indicated by the fact that the link key file contains the value 4 as the link key type. Based on the definitions given in this patch, 4 represents an unauthenticated link key. Consequently, when the connection is lost and reestablished again, Bluez issues an authentication request to the user which results in the annoying but technically correct re-pairing dialog.
So in order to prevent the dialog from appearing, it is sufficient to signal the Bluez stack that the authenticity of the devices has been validated by turning the 4 into a 0. To do this, pair the LiveView device with the mobile phone. Copy the link key file on the phone (i.e. /data/misc/bluetoothd/<local adapter address>/linkkeys) to the SD card and find the line that starts with the LiveView Bluetooth address. Then change the 4 in the same row to a 0 and copy the file back to its original location. Thereby, make sure that you do not change the owner as well as the file permissions and correct them with chmod, chgrp or chown – if necessary.
To validate that your problem is fixed, simply power down the LiveView, turn it back on and see whether it is able to automatically get the date and time from the phone. If that is the case, you are done. If you see the re-pairing dialog, something went wrong and you need to repeat the whole procedure. Note that it is not sufficient to just copy the file from SD card back to the phone’s memory since the link key will have changed already – once you see the repairing dialog. Also note that at no point you have to turn off your phone, since Bluez reads the link key file every time a new connection is established.