Category: Uncategorized

Today I read an article on the video quality of Facetime and Skype on an iPad2 here (sorry, article is in German). For both, the author came to the conclusion that the video quality is quite bad compared to Skype on a PC. So I wonder why this is so!? Perhaps it has something to do with the available processing power? I can observe similar things on my netbook where Skype video resolution and quality is far behind what I get on my fully-fledged notebook, despite the processor almost running at 100%. While things are probably not going to change on my Atom based netbook with a weak GPU, I wonder if the graphics GPUs built into mobile devices will be able to help in the near future with encoding and decoding the combined real time audio and video stream? I think it's quite an application. Let's see what Google has to say when they release their own video calling application on Android devices soon.

While TMN doesn't let me use their 3G network with my German SIM card as reported in an earlier post, they do offer SIM cards for Internet access which are interesting for occasional use or travelers in the country for a couple of days. For the details on the offer see here. While the throughput in their network is quite o.k. and in the range of 3 MBit/s, their network has some compatibility issues with my 3G dongles.

I don't see such issues often anymore but TMN is one of those networks that still seem to have a strange RAN software version running that make my 3G dongles get stuck every now and then when an RRC state change occurs. Sometimes the connection recovers after a minute or so, sometimes I have to reset the connection entirely. The only thing that helps is a constant ping to keep the RRC connection in Cell-DCH.

TMN, you might want to run a compatibility check against some mainstream UMTS hardware not necessarily sold in Taiwan…

After the general introduction to the programming environment used for Android App development, the second part of this series now focuses on two major concepts every Android App is based on. This is the basis for the details I’ll then describe about what my experimental app does and how.

The first concept of every Android App is that it is programmed in an object oriented language, namely Java. The core of object orientation can be described in two parts:

First, object orientation means that every line of code of an app is part of a class. On the highest level of abstraction, every app has at least one class and one method in the class that contains the code. This method is called when the app is started by the user. That method then creates what the user sees, i.e. it arranges text, buttons and other things on the display. If things start to get complicated a good approach is to put parts of the code into other methods which are then called by the main method. These methods then do their specific work and then return to the original method with a result that can be further processed.

The question that arises at this point is how Android knows which method to call when the App is launched. This can be answered by looking at the second idea of object orientation. Classes are a kind of blueprint if you will, and to make them come alive, they have to be instantiated. Think of the abstract term “car” as an example and what it represents. Your own (physical) car is an instantiation of the abstract term car. There can be several instances of a car, like for example, your car and my car. In object orientation, an instance is called an object. And to bring the three words together: An object is an instance of a class. What Android does with object orientation is describing the basic principles of how an app is supposed to work and defines the names and parameters of the methods that are called by the OS when specific things happen.

When the app is started, a specific method of an object is called. To make this approach useful the app uses the method definition, i.e. how the method looks to the outside but defines what is inside the method itself. This is called “overriding”. So if there are two apps running they both have the same method that is called by the OS when the app is launched. The content of that method, however, is defined by the programmer of each app.

The method that is called when the app is started is only one of many that are already contained in the basic app class and the application programmer is free to either use methods and variables as they are or override them and do their own things with it. What remains the same in all apps are the method names and the parameters the method exchanges with the external word. Thus, there is a uniform way for the OS to interact with an app as will be discussed in the next paragraph.

Object orientation is a means to an end. How the app interacts with the world is a different matter. For that purpose, the OS needs to provide an Application Programming Interface, an API. Apple’s iOS also offers an object oriented interface to programming but the API is quite different to that of Android. If you want to display an “OK” button on the screen for example, an object of the type “button” is instantiated from the button class. The text displayed on the button and many other things are then defined by the app by calling methods of that object that then do their job inside the class to bring the button to live.

The second major concept of Android app programming is call back methods. Whenever something happens that the app should become aware of, such as for example the user clicking on a button on the screen, the user pressing a hardware button, the app being sent to the background because the user starts another app, data arriving from the network for the app, etc., a callback method is called by the OS. But how can the OS know which method of the app to call? If the callback method is part of the general app class described above then there is nothing special to do because the callback methods are predefined and the programmer can simply override the existing methods for the different events. Most elements a user interacts with such as buttons for example are not part of the general Android app class. As described above, the user instantiates a button object from the button class and then the app object contains a button object. To be informed about the user clicking on the button, the programmer needs to define a method in the app class to receive the event. A reference to that method is then given to the button object. When the user then clicks on the button, the button object calls the given method.

Most apps that interact with the user are fully call-back controlled. When the app starts, everything is put on the screen and callback methods are put in place. Then, while nothing more happens for the moment, no further processing power is needed for the app and no code is executed. Only once the user interacts with the app by, for example, clicking on a button, a callback method is called. The callback method can then perform an action that is supposed to happen when the button is clicked, e.g. a calculation is made and an output is made to the screen, and then go back to sleep until a new event arrives.

And finally, in addition to call-back methods, an app can also spawn background threads for actions that are continuously performed without user interaction or for actions that take a long time to complete. A separate execution thread has to be used for this so the main thread with the callback methods can be called by the OS at any time the user interacts with the app.

There we go, so much for the theory. In part 3, I’ll put the stuff described above into practice.

The Verizon Thunderbolt manufactured by HTC is one of the early CDMA/LTE mobile devices on the market. An interesting question in this regard is whether it has a SIM card or not. Remember, CDMA devices usually do not have a SIM card. But LTE is a 3GPP technology just like GSM and UMTS where SIM cards are part of every device. So what about the Thunderbolt which includes both technology branches!? I would have speculated it doesn't have one. Why bother, Verizon has its own LTE band so the device will only run on Verizon's network!?

But strangely enough, the Thunderbolt does have a SIM card as shown in this Youtube video. While showing the SIM card the reviewer mentions that CDMA service is still available when the SIM card is removed. In other words, the SIM is only used for the LTE part of the device.

Very interesting indeed.

The Comodo SSL hack last month has shown quite dramatically that SSL is prone to man-in-the-middle attack if you live or use SSL protected websites and services in places that make it easy for attackers to spy-on and divert IP packets. The way the attack works is that the data traffic to an SSL protected site is redirected to another server that then poses as the original server by sending a fraudulent SSL certificate. Out of the box, web browsers today don't indicate this to the user if the fraudulent SSL certificate was issued by a trusted but compromised certificate authority. For the technical details, see the excellent article on Ars Technica.

So is there anything that can be done to protect yourself against it? Two things come to mind:

First, whenever in a non trusted part of the Internet, a VPN tunnel can be established to an endpoint that lies somewhere where a man-in-the-middle has no access to. Many VPNs use certificates, too but since they don't rely on certificate authorities, man-in-the-middle attacks with bogous certificates won't work. The only solution for an attacker is to block VPNs from being established, and that the user notices immediately.

The second way to detect against potential fraudulent SSL certificates is to be informed if a different certificate is presented to the web browser for a website than at a previous visit to the same site. There are valid reasons for this such as the old certificate being close to its expiry date but such certificate changes are very rate. The issue here is that web browsers do not show such a certificate change. For Firefox, however, there are add-ons that do just this. An easy and straight forward one is Certificate Patrol.

The problem with both solutions is that the ordinary user without a technical background is unlikely to use either one.

On mobile platforms, using a VPN is not quite as straight forward, as keep-alive packets will drain the battery very quickly. Let's at least hope Firefox mobile and other mobile browsers get a similar add-on soon. However, that still leaves data transfers vulnerable from other apps such as email programs that use SSL to potect SMTP, POP3 and IMAP connections as well as apps that use HTTPS for data exchange.

I agree with Ars Technica, the security architecture of the Internet needs a serious overhaul.

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.