Category: Uncategorized

As expressed in a previous post I'm quite happy about the improvements of Firefox 4 even at the expense of not being able to run a few add-on's which have not yet been upgraded to run in this version. After a bit of research, however, I found out that what keeps add-on's from installing in FF 4 is just the highest supported version information in the add-on. However, that can be changed easily. And here's how:

Download the add-on to the desktop with a right-click and then "save as" instead of trying to install it. You should then have an .xpi file. Rename it to .zip, because that's basically what it is and open it. You'll find a directory structure in which root there are two files, one of them being called "install.rdf". Open it with a text editor and modify the following line to say "4.0":

<em:maxVersion>4.0</em:maxVersion>

Then save the file and make sure it ends up in the .zip file again. Next, rename .zip back to .xpi and open the file in Firefox. This will start the add-on installer. And that's it. Of course there is no guarantee the add-on will work flawlessly as there is always a chance it uses features that were changed or removed between versions. But at least for the add-on I tried this was not the case and things work flawlessly.

I've recently been in Taiwan for a couple of days and obviously I had to check out the local networks here. The first thing I noticed is that Taiwan Mobile (TWM) doesn't let my German SIM card roam on their 3G network. I get a nice and clean mm reject cause 15 (no suitable cells in this location area) together with a gmm reject cause 9 (MS identity can't be derived from the network) so the mobile gives up on 3G and re-selects to GSM. How interesting, haven't seen that anywhere in the world yet. Either there was not 2G and 3G roaming agreement at  all or I could roam in a 3G network of a network operator if it was available. O.k. no roaming business from me then for TWM, Chunghwa's 3G networks has no problem with me 🙂 And I guess other smartphone users will just do the same when coming to Taiwan when they experience this. Not good for TWM…

To take the next step in my exploration of Android, I've decided not only to research the theory but also get some hands on experience and do some programming. I was first a bit unsure as to how much time is required to set up the environment but when I tried, it was actually pretty much straight forward.

All Android apps run in the Dalvik Virtual machine and are programmed in Java and making use of the Android API for pretty much everything from displaying something on the screen to exchanging data with the network. The API and the whole virtual machine is supplied by Google so no matter from which manufacturer you have an Android based phone and what kind of extensions they have put in for the idle screen and additional applications, it will always work in the same way. This is a big difference to the previous Java approach that got very fragmented over time with developers complaining left and right. More about the API in a future post.

In this post I'd like to quickly mention a few things about how to get set up. Google does a superb job here at describing how to install the Eclipse development environment and the Android SDK and how to link the two together. For my first steps I installed Ubuntu in a virtual machine on my desktop PC so I could experiment without compromising my main installation just in case things didn't work out.

Another reason for using a virtual machine first was that I had some doubts the environment would work well on my Atom processor based netbook. At first I saw my doubts confirmed when starting the Android emulator which is slow at best and almost maxes out the "core duo" processor of my desktop even when just sitting there. But I soon found out how to run my experiments on a real device, removing this limitation. Therefore the next logical step was to get the programming environment set-up on my netbook as well. And to my pleasant surprise, it works surprisingly well and fast on the netbook as well. The small screen size is of course somewhat of a limitation but it is still quite workable.

Why on the netbook you might ask? Well, I commute a lot and I travel a lot and now that I'm hooked, I don't want to interrupt my activities for days and weeks just because I don't have the environment with me. In a number of follow-up posts I'll describe how apps interact with Android and the network with practical examples. And yes, I'll give out the app and the source for it as well. Consider the screenshot on the left of Eclipse running on my netbook as a sneak preview 🙂

One of the essential functionalities of my smartphone is to keep me informed about upcoming meetings and things to do throughout the day. On Symbian a good solution for the idle screen has existed for years right out of the box for showing the next couple of upcoming actions. On Android, however, it doesn't seem that there is anything with the same functionality right out of the box.

But there are tons of calendar widget applications that can be installed so I took some time to install a number of them and give them a try. Obviously widgets that request access to resources other than the calendar, especially access to the network, were excluded from the beginning. After some trial and error, I settled for the "Android Agenda Widget". Configurable in the extreme (!) it does exactly what I want, i.e. it shows me at least the next 4 upcoming actions in a font size that is not too small to be unreadable but also not too big and hence only showing the beginning of the text. Almost perfect 🙂

So this was part 7 of my excursion into Android. By now I've pretty much got the pieces together for life after Nokia has closed its books on openness and freedom for customers and have gone to a closed garden ecosystem. Now it's HTCs, Samsung's or someone else's job to build an Android based device with a good camera with xenon flash and a software company to offer a mapping and navigation application that works with offline maps and around the globe.

What do you do when the mobile network is switched off by the government to prevent you from communicating and there is no chance things are going to change anytime soon? Well, if you are in Libya, if you know people who know what they are doing and if have some money to buy needed equipment, you separate the part of the network covering your territory and run it on your own.

That's what's just happened earlier this month and I'm amazed I haven't seen the reports earlier. While the general mass media doesn't have a lot of details on how this was done, The Register has a detailed post on it that contains the details. While I would have guessed they somehow got a copy of the subscriber data from the centralized Home Location Register (HLR), the article says they made a dump of the subscriber data from the Visitor Location Register (VLR) of the Mobile Switching Center (MSC) for their area and then used the data to populate a new Home Location Register that was brought into the country in a hurry.

This piece of information ties in well with the statement that voice calls are not ciphered now as the copy of the subscriber data in the VLR does not contain the secret keys of subscribers and hence ciphering can't be activated. That also means that no authentication is performed but since calls are not billed at the moment that is likely only to be of second importance at the moment. SMS services are also not working at the moment which probably means that there was no SMS Service Center in the area and a new one has to be brought in first. The article didn't mention anything on GPRS services, so there is probably some equipment such as the GGSN and a backhaul link to the rest of the world still missing as well.

Also very interesting is the part of the story that explains how they hooked-up the separated network to the rest of the world via a satellite link. That works well for outgoing calls which, according to the article, seem to be restricted to some people at the moment as no billing is yet in place and the satellite link is probably not coming for free. Incoming calls seem to be possible via networks that know how to route a call to the satellite link when a Libyan cell phone number is dialed with a '9' prefixed or via a number of calling cards from operators that have also updated their routing tables.

All very well thought through.

It's a good thing that the majority of mobile device manufacturers are now using the USB port on their devices for charging as it reduces the number of power adapters I have to carry along. But there's one catch: While my Nokia charges have so far featured an ultra thin and flexible cable, standard USB cables are thick and quite inflexible.

So I was wondering if there are "thin" USB cables available for that purpose as so far I've never seen one. So I searched a bit on the web and found some shops that actually sell thin USB cables. (here's an example, but be advised, I don't endorse the company, it's just an example). The cable only supports low and full speed transmissions, i.e. USB 1.1 with 1.5 and 12 MBit/s.

I am not sure if that limitation causes problems when a USB 2.0 device wants to talk to another USB 2.0 device over the cable, which would be the case for most mobile phones today. Something that needs to be tried out once I get my hands on one. If you already have experience with thin cables for charging, please leave a note below. Thanks!

So far I thought that Skype calls always had to go over a relay computer in the network when both ends of the connection are behind a NAT router. Turns out that this is not the case at all.

When monitoring the establishment of a Skype call it can be seen that during call establishment Skype tries quite hard to find out how the UDP port mapping is done by sending UDP packets over many ports simultaneously and if there is a way to get through the NAT directly (e.g. with UPnP and also with the NAT Port Mapping Protocol NAT PMP). At the same time the protocol also seems to try to find relay nodes over which the voice and video traffic could run in case the NAT scheme can't be figured out. In case a direct channel between the two end points can be established the other end is alerted of the incoming call and the direct link between the two parties is used.

I was successful to establish "direct" calls between two computers that were behind two NAT DSL routers and also with one computer behind a DSL router and the other one connected to a public hotspot of a nationwide hotspot provider. When using a VPN tunnel, however, Skype could not establish a direct link and had to fall back to channel the voice packets over one relay in the network. The same IP address was used as destination address on both ends, i.e. exactly one relay was necessary.

In that regard, the number of relays shown in the call technical info does not reflect that. The technical info often showed 4 relays when in fact the call was direct or only going over one relay. So perhaps this relay indication is something else entirely?

I've had quite a number of posts in the past couple of weeks on Android but today it's time for a quick Symbian post as well: One of the features I particularly like is the SMS remote lock feature built into the OS that lets you lock the phone by sending an SMS with a user defined content. This way the phone becomes useless to anyone not knowing the unlock code. But what about access to the files on the Flash memory via the USB port? Ideally, the USB port would be locked as well when the phone is locked. But is it really? Turns out that it is. As soon as the phone gets locked, USB connectivity is disabled until the general unlock code for the phone is entered. Very nicely implemented!

Yes, app stores for mobile platforms are a great thing, no doubt about it, and for most people that's how they discover and where they get all their apps and content from. An app store mono-culture, however, also has its dangers as the store owner can block apps he doesn't like. And some do… But I don't want to discuss policy but rather how alternatives work in practice.

On Symbian, apps can be installed from an sd-card or if received via Bluetooth or other means pretty much since its inception. An app store has only come recently as an addition and I have since used both methods to install applications. Android is also open and apps can also be installed from the SD card. Until now, I haven't tried this in practice so it was time to see for myself how that works.

For the purpose, I've used a self-written app (more about that in a future post) so I could experience first hand what a developer has to do to publish an application in an app store or otherwise. Android applications need to be signed by the developer with a private key that he generates himself, i.e. there is no certificate authority that authorizes a developer or the deployment of an application. The purpose of signing an app is to identify the author of an app but since there is no central certificate authority, that's a relative thing. Furthermore, the signature can be used to build a trust relationship between applications but I am not sure how and if that is used in practice. For details on the signing process see here.

The result of packaging and self-signing an application by the developer is a single ".apk" file that can then be put on an SD card by whatever means. The app is then installed with the help of a file explorer on the mobile device which comes pre-installed on Samsung based Android devices such as the Galaxy S for example. With a tap on the filename the app installer is launched which then requests the user to confirm the access rights requested by the app in the same way as if the app had been loaded from an app store.

Android enforces access rights for functionality that could incur cost such as making phone calls, sending messages, accessing the network, etc. and also for privacy related features such as accessing location information, accessing the phonebook, calendar, sd-card contents, etc. During the installation process the user is presented with the list of access rights the application requests so he gets an idea if the application requests more rights than it actually needs. If, for example, a calendar widget requests full location and network access that's more than a bit suspicious. If the user agrees to give the requested permissions the app is installed, otherwise the process is aborted.

If an application tries to use functions it doesn't have requested permission for during the installation process it dies a quick death once it tries to access those parts of the system. That means that the virtual machine terminates the execution of the app with an ugly error message as I experienced myself with the demo app I installed when I forgot to ask for permission to access location information.

For the user, all of this is transparent. All he needs to do to install the app is to put the ".apk" file on the sd card, use a file explorer to start the installation process and confirm the access right requests made by the app.

A quick note about the recent release of Firefox 4: While I am usually bit reluctant to immediately update to new software versions that are likely to break some add-ons until the authors have caught up with the version numbering I gave Firefox 4 a try as I could install it in a separate directory on my Ubuntu netbook and could thus go back to 3.6 if I didn't like what I saw. And indeed, some add-ons I occasionally use don't work with the new version for the moment. However, there are two major new features that more than make-up for it:

• Two more lines: On netbooks, vertical screen resolution is a premium. In version 4 the status bar has been removed once the page is fully loaded and the main menu has been put into a drop down menu. In other words, two more lines of screen space for web pages. Fantastic, that makes a big difference! I am not sure if the reason this was done was because of netbook screen size limitations but in any case it's very helpful!

• Java script speed-up: This has been promised a number of times before but I've never experienced a big difference where it hurt most, the Java Script based editor of Typepad that I use to write blog entries. But with this version it's different, the speedup of the editor is remarkable!

Apart from those two features I like the new "eye candy" of the clockwise and counter clockwise rotation of the activity indication in the tabs. When you click on a link the activity indicator starts rotating in one direction and once the connection to the server has been established it changes color and starts turning the other way around.

A very worthwhile update indeed, kudos to the guys over at Mozilla!