Category: Uncategorized

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!

In my ongoing exploration of the Android OS I've arrived at Wi-Fi tethering. Quite simple to set-up on Android 2.2 and while I wished the settings would also allow WPA to be used as an encryption algorithm instead of WPA2, I don't think one can really ask for it. Too bad one of my notebooks will only do WPA and is thus not usable with it. But apart from that things work straight out of the box.

Performance is also great with the full speed of the HSPA chip forwarded to the Wi-Fi interface as proven by the 6 MBit/s throughput I got. Impressive! Also, the stability is impeccable. I tried the tethering over two days and the device didn't crash once. Also, on-board apps remain fully usable even while tethering is active and share the same network connection. There's not much more you can ask for.

Two little quirks though in addition to the missing WPA encryption:

• Power consumption: The battery of my Galaxy S lasts for about 3 hours when a notebook is connected over Wi-Fi and modest web surfing is done in addition to having a continuous ping running (see next bullet point for the reason). One can of course connect the mobile via USB to supply power.

• Fast dormancy (pre-Release 8) while tethering: The Galaxy S interrupts the RRC connection after 3 seconds of inactivity resulting in long waiting times especially during web browsing on the PC. While fast dormancy is great when only background applications are running on the device itself, it should really be switched off while tethering for performance sake. O.k. you can have a ping running on the tethered device to keep the mechanism from kicking in but that's a bit of a kludge…

Thanks Google, a very worthwhile functionality that will find it's way into my everyday use for special scenarios!

How many IP addresses does an IP packet have when it is sent between two devices? In a simple world only two, i.e. one for the destination and one of the source. The fun thing is how often that changes between source and destination due to all the tunneling and NATing applied. Let me give you an example of a typical setup of mine, a netbook connected via a Wifi / 3G bridge with a VPN tunnel established:

Leg 1: Netbook – WiFi / 3G bridge

As the VPN is established an IP packet is tunneled over IP. Thus there are 2 IP addresses to identify me as the source and two IP addresses for the destination:

• IP-1: IP address given by the Wifi bridge to the netbook
• IP-2: IP address of the VPN remote endpoint

    Inside the VPN tunnel:

• IP-3: IP address given by the VPN service to the tunnel end point (i.e. netbook)
• IP-4: IP address of the destination (e.g. the web server)

Leg 2: Wi-Fi / 3G bridge to Mobile Network Gateway (GGSN)

• IP-5: IP address given to the WiFi bridge from the GGSN (NAT)
• IP-2: -unchanged-

    Inside the VPN tunnel:

• IP-3: -unchanged-
• IP-4: -unchanged-

Leg 3: GGSN to VPN remote endpoint

• IP-6: IP address of the GGSN after NAT translation
• IP-2: -unchanged-

    Inside the VPN tunnel:

• IP-3: -unchanged-
• IP-4: -unchanged-

Leg 4: VPN remote end point to web server

• IP-7: IP address of the VPN remote endpoint after NAT translation
• IP-2: -unchanged-

    Inside the VPN tunnel:

• IP-3: -unchanged-
• IP-4: -unchanged-

Leg 1 to 4 are not the full story, there's also tunneling performed in the wireless network:

Tunneling between SGSN and GGSN

User data packets are tunneld over IP in the wireless core network. Here the packet looks like this:

• IP-7 SGSN network internal IP address
• IP-8 GGSN network internal IP address

    User data packet:

• IP-5: -unchanged-
• IP-2: -unchanged-

    Inside the VPN tunnel:

• IP-3: -unchanged-
• IP-4: -unchanged-

Base Station to RNC

While in the past the 3G radio access network was based on ATM, it is more and more replaced with Ethernet and IP for routing. This gives the packet another two IP addresses in this part of the network:

• IP-9 Base station network internal IP address
• IP-10 RNC network internal IP address

    User data packet:

• IP-5: -unchanged-
• IP-2: -unchanged-

    Inside the VPN tunnel:

• IP-3: -unchanged-
• IP-4: -unchanged-

RNC to core network IP address

No, we are not finished yet, the interface between RNC and SGSN is also based on IP these days and again tunneling is applied:

• IP-11 RNC network internal IP address on core network bound interface
• IP-12 SGSN network internal IP address on RAN bound interface

    User data packet:

• IP-5: -unchanged-
• IP-2: -unchanged-

    Inside the VPN tunnel:

• IP-3: -unchanged-
• IP-4: -unchanged-

12 different IP addresses are used in the course of transfering a packet between source and destination! WOW!