mobile – Andrew E. Scott

Android on Xperia

One of my handsets is a Sony Xperia E C1504 (code-name Nanhu) which was a low-end-ish Android handset when it launched in early 2013, and was apparently relatively popular in India. One of its claims to fame is that it was also one of the first handsets to have a version of Firefox OS available for it. But why I’m writing about it here is that Sony has been hassling me to upgrade it to the most recent version of firmware (11.3.A.2.23), and recently I gave in, but since I was mucking about with the firmware I thought I’d “root” it as well. And therein lies the tale.

Although, as is often the case with Android when wandering off the well-trod path, it’s more of a cautionary tale.

“Rooting” an Android device means to gain complete control over the operating system through installing a superuser tool in the system partition. When Android is running, the system partition is read-only, so this step has to be done outside of Android itself (unless an “exploit” is used, utilising a bug in an Android implementation to achieve this). The usual process for achieving root is: 1) unlock the bootloader, 2) install a custom recovery partition, 3) copy a superuser tool onto the device’s filesystem, and 4) install the superuser tool into the system partition from within recovery. Oh, if only it was that easy.

Step 0 – Install USB Drivers

Before you can do anything, you need to get the right USB drivers set up on your PC, which is a world of pain itself. Complications come from whether the PC is running a 32-bit or 64-bit operating system, whether the drivers are 32-bit or 64-bit, whether the drivers support ADB, fastboot, or (for Sony) flash modes, and which particular USB port the cable is plugged into (and for which mode). I’m running Windows 8.1 64-bit, which seems to have limited driver support for this sort of thing.

I had to:

Install the Android SDK from Google, so that the fastboot and adb tools were installed on my PC
Install the ClockworkMod universal USB drivers
Before going any further, make sure the drivers are working. Use “adb devices” or “fastboot devices” from the command line to list the devices that can be seen. To put the Sony Xperia E into fastboot mode: turn off the handset, ensure it is not connected to the PC via the USB cable, hold down the volume up button, then connect it to the PC via the USB cable.
When I connected the Xperia E in fastboot mode, the laptop reported it as an unknown device “S1 Boot”. I opened the Device Manager (press Windows-X and select it from the menu, for a quick way to get to that), right-clicked on the unknown device, selected “Update Driver Software”, then “Browse my computer for drive software”, then “List me pick from list” and I chose the Nexus bootloader driver from the ClockworkMod set of drivers.
I used my laptop’s powered USB port for ADB and fastboot modes, but an unpowered USB port for the flash mode.

Pro-tip: If something’s not working, try another USB port. Try all of them.

Step 1 – Unlock the bootloader

Sony provides an official way to unlock the bootloader. Be warned that although it’s “official”, it will still void your warranty, and potentially brick your device. Ensure everything that is valuable on the device has been backed up somewhere else. At the very least, all apps and configuration on the device will be lost anyway.

I followed the unlocking instructions from Sony Developer World. However, my device immediately stopped working afterwards. It would go into a boot loop, showing the Sony logo, then the boot animation, then back to the Sony logo, and so on. The solution was to reflash the operating system.

I download the Flashtool that’s available from Flashtool.net (I used Flashtool64 since I have a 64-bit Windows). It’s the one that’s commonly used in the Sony Android custom ROM community.

I followed the instructions at XDA Developers to flash the 11.3.A.2.23 version of the C1504 firmware onto the device (the newest version currently available). This happened to be an Indian build of the firmware, so I’ve ended up with some links to Shahrukh Khan videos on my device as a result. :)

It was pretty hard to find these instructions. Most Sony Xperia E firmware flashing instructions refer to the C1505 version, which has support for 3G at 900MHz instead of 850MHz. Since Telstra’s 3G network is 850MHz, I need this capability of the C1504, and didn’t trust that C1505 firmware would give me what I wanted.

Now my handset booted again, but aside from the Shak Ruhk Khan videos, I hadn’t gained anything new yet.

Step 2 – Install a custom Recovery partition

The Android fastboot mode gives access to the bootloader. Now that it was unlocked, the bootloader allowed a special partition called the recovery partition to be flashed with new firmware. The recovery partition is an alternate boot partition to the default system partition.

The two most popular Android recovery partitions are from CWM (ClockworkMod) and TWRP (Team Win Recovery Project). I’ve used both in the past, but this time I chose CWM since it seemed to be more widely tested on the Xperia E. Unfortunately, I found that most of the instructions for installing the CWM recovery resulted in Wi-Fi ceasing to work on my device. I also tried to build a new version of CWM for my device, but the CWM build tools didn’t support it.

However, I found someone had built a version of the ZEUS kernel (replacing the default Sony Xperia kernel) that included CWM recovery, and this wouldn’t have the Wi-Fi issue. I followed the instructions at XDA Developers to flash that onto my device.

Step 3 – Superuser tool

Now when I turned on the device, it booted as normal, but a blue light appeared at the base of the device at the beginning when the Sony logo is shown. When the blue light is shown, the device can be diverted to boot into CWM recovery rather than the default Android system by press a volume key. However, I needed to put a superuser tool onto the device’s SD card before this new feature would be useful.

The superuser tool is made up of two files (a system application called “su” and an Android app called “Superuser.apk”), but both are stored within a zip file for easy installation. I got the zip file from the AndroidSU site (the one labelled Superuser-3.1.3-arm-signed.zip).

I installed the zip file onto the sdcard simply by enabling the Developer Options on the device (under Settings) and ticking the USB Debugging option, then attaching the device to my PC via USB, and using the command on my PC:
adb push Superuser-3.1.3-arm-signed.zip /sdcard/

Step 4 – Install the Superuser tool

I disconnected and rebooted the device, and when the Sony logo appeared (and the blue light), pressed a volume key. The device booted into the recovery partition. I followed the instructions at XDA Developers (starting at step 5).

And that’s all (!). Now I can boot my unlocked, rooted Xperia E (C1504). Remember, if you’ve followed along with these instructions, you’ve voided your warranty. But at least now you can install whatever you want on the device, or change any of the configuration settings.

One thing you might want to install straight up is a build.prop editor, such as the mysteriously named Build Prop Editor, to change configurations. For example, tweaking the network settings for the Australian mobile operators seems to improve performance. I haven’t tried these myself yet, but it’s an example of the sort of thing that can be done.

Is mobile video-calling a device thing?

Ever since I’ve been involved in the telecoms industry, it seems that people have been proposing video calling as the next big thing that will revolutionize person-to-person calling. Of course, the industry has been proposing it for even longer than that, as this video from 1969 shows.

One thing not anticipated by that video is mobile communication, and video calling was meant to be one of the leading services of 3G mobiles. When 3G arrived in Australia in 2003, the mobile carrier Three sold its 3G phones as pairs so that you’d immediately have someone you could make a mobile video call to.

Needless to say, the introduction of 3G didn’t herald a new golden age of person-to-person video calling in Australia. So, despite all the interest in making such video calling available, why hasn’t it taken off? I’ve heard a number of theories over the years, such as:

The quality (video resolution, frame rate, audio rate, etc.) isn’t high enough. Once it’s sufficiently good to be able to easily read subtle expressions/ sign language gestures, people will take to it.
The size of the picture isn’t big enough. When it is large enough to be close to “actual size”, it will feel like communicating with a person and it will succeed.
The camera angle is wrong, eg. mobile phones tend to shoot the video up the nose, and PC webcams tend to look down on the head. If cameras could be positioned close enough to eye-level, people would feel like they are talking directly to each other, and video calling would take off.
People don’t actually want to be visible in a call, for various etiquette-related reasons such as: it prevents them multi-tasking which would otherwise appear rude, or it obliges them to spend time looking nice beforehand in order to not appear rude.

But despite the low level of use of video calling on mobiles, there is one area where it is apparently booming: Skype. According to stats from Skype back in 2010, at least a third of Skype calls made use of video, rising to half of all calls during peak times.

One explanation could be that Skype is now so well known for its ability to get video calling working between computers that when people want to do a video call, they choose Skype. Hence, it’s not so much that a third of the time, Skype users find an opportunity to video call, but that a third of Skype users only use Skype for video. Still, it’s an impressive stat, and also suggests that super-high quality video may not be a requirement.

Certainly, I’ve used Skype for video calling many times. I’ve noticed the expected problems with quality and camera angle, but it hasn’t put me off using it. I find that it’s great for sharing the changes in children across my family who are spread around the world, and otherwise difficult to see regularly. But a tiny fraction of my person-to-person calls are Skype video calls.

However, I’ve ordered an Apple iPad 2 (still waiting for delivery) and one of the main reasons for buying it was because of the front-facing camera and the support for video calling. I am hoping, despite all of the historical evidence to the contrary, that this time, I am going to have a device that I want to make video calls from.

The iPad 2 seems to be a device that will have acceptable quality (640×480 at 30fps), and it is large enough to be close to actual size, but not so large that the camera (mounted at the edge of the screen) is too far away from eye line. So, they may have found the sweet spot for video calling devices.

If you know me, be prepared to take some video calls. I hope that doesn’t seem rude.

A Java ME coder looks at Android

I’ve had a long association with Java programming.

I started playing around with Java software development back in 1995, before the platform was even released as version 1.0. In 2001, I got my hands on a Siemens SL45i handset and began to develop using Java ME (known as J2ME at the time), a cut-down version of Java for embedded devices such as mobile phones. For a time, I worked for mobile games developer Glu (known as Macrospace at the time) porting games to different Java ME handsets.

That’s all just so I can say that I got to know a lot of the ins and outs of doing Java development for mobiles. Although, I haven’t really done much of that recently, and these days Java ME has fallen out of favour, with the rise of smartphones that support other software platforms. However, Android-based smartphones are now becoming popular, and Android applications are written using Java.

So, I was rather curious as to what developing on Android was like, and over the last couple of months, I’ve spent an hour or two every 2-3 days tinkering around with an Android project as a hobby. This was my chief diversion during the weeks after our daughter was born in November.

I didn’t do an Android course or read an Android book. I simply took what Google provided on Android and ran with it, to see what I would learn.

Getting going

Google makes a lot of really good information and tools for Android available for free. I was able to easily set up a development environment on our laptop (an old Dell Inspiron 1501). Unlike if I’d been developing for, say, the Apple iPhone, I didn’t need to get a specific brand of computer, nor pay anyone to join their development program. In fact, they even make the full source code for Android available if you want to see how it works under the hood.

It made me think how empowering this is for people. In years gone by, if you wanted to tweak your car (or even build a car up from parts), you could easily get access to the information and tools to do it yourself. For modern cars, that’s not really the case. However, it is the case for your modern mobile phone, and given how important a tool it has become in our daily lives, that’s a really liberating thing.

In fact, our particular laptop has a comparable amount of grunt to a modern mobile phone (such as an HTC Desire), so it’s no wonder I find myself doing more tasks on a handset rather than this laptop. In addition, while with Java ME, it was common to test the software on an emulator (e.g. running on the laptop) before loading it onto a real device, but here, the inability of the laptop to emulate a modern handset at anything like real speed made that impractical. Also, the Android adb tool does a great job of exposing logging and debug information in real-time from devices, so there’s no real penalty in testing directly on the device.

Also due to the lack of grunt, rather than using the normal Eclipse development environment, I ended up using the much more lightweight ant and vi tools. Not very pretty, but fast on my machine.

Developing

Android development is theoretically done using the full Java SE, rather than the cut-down Java ME. While it is true that there is a lot more power and flexibility in the hands of developers than there was for Java ME, there are still a lot of wrinkles that make it unlike full Java SE.

Three examples of these wrinkles are:

AndroidManifest.xml: This is a text file that is included in every Android app, and basically describes how the system should interact with the app. Instead of this being specified in the Java code, it needs to be separately documented here. For example, it specifies which icons appear in the list of launchable applications and which classes should be invoked when those icons are selected. It also specifies how other applications on the device might interwork with the app.
Activity-oriented architecture: Every Android app is basically broken into components of four different types. These are the Activity (an interactive screen of some kind), Service (an invisible, background task), ContentProvider (a database-like interface to some content), and a BroadcastReceiver (waits for a system-wide event to perform a task upon). These components communicate with each other using a type of message called an Intent, which is typically a URI and some associated metadata. (My small hobby application used a ContentProvider, a Service, and several Activities.)
Dalvik Virtual Machine: Instead of compiled Java bytecode running on a Java virtual machine (the typical approach for Java SE), the compiled Java bytecode is converted into Dalvik bytecode and that is run on the Dalvik virtual machine. This is a pretty clever way to allow developers to reuse the well-known Java tools but allow the Android system to operate outside of them. However, as the Java to Dalvik conversion doesn’t have full knowledge of the original source code, it seems to find it difficult to optimise things automatically, and leads to strange advice like manually copying class fields into local variables to make execution more efficient.

Another interesting thing, from a mobile developer perspective, is that Android manages a “stack” of screens (Activities) in a similar way that was done for the old WAP/WML 1.1 browsers (and HDML browsers before them). The developer can push screens onto the stack in various ways, while the user hits the back button to pop them off. Given that this approach was dropped from the newer versions of WAP (and in the newer mobile browsers that followed), it is with some nostalgia that I see it come back again. However, it does make a lot of sense for mobile handsets and their small screens (i.e. the impracticality of having several windows open side-by-side).

Difficulties

While the Android SDK gives the developer a lot of power, it wasn’t as easy to use as I’d hoped. Not that Java ME was easy, by any means, but Android’s design and development has probably resulted in some strangeness that Java ME avoided.

You have to remember that Java ME evolved in a (some would say ponderously) slow fashion. It was effectively the product of a standards organisation, with a lot of smart minds spending time arguing about small details. For example, while JSR-37 (the original specification of the version of Java ME for mobile phones) was published in September 1999, it took until August 2002 for the specification for sending a text message to become available (JSR-120). The final result was typically elegant, consistent with overall Java ME design philosophy, and extensively documented. But you didn’t want to hold your breath for it.

I was developing to Android v2.2, which was the 8th release of the platform (not counting revisions). There had been five separate releases of the platform in the previous year (from the 3rd release in April 2009 to the 8th release in May 2010). It has been evolving very quickly, so I wasn’t too shocked to find things worked in unexpected ways.

I found the Android API library to be a bit confusing. Classes weren’t always in the packages that I expected to find them. For example, while Activity and Service are in android.app, ContentProvider and BroadcastReceiver are in android.content. Also, some UI elements are in android.view and others are in android.widget. And while some standard icons were available as constant values, others needed to be copied as files out of the SDK.

The Activity-oriented software architecture also took a while to get used to. It turned out that although one method I tried to use (startActivity) was available on some classes (such as a Service), they would throw an error if called because they were only meant to be called from particular components (an Activity, in this case).

Additionally, while ordinarily an application runs in a single process, it uses a number of threads. There is one special thread called the UI Thread. Again, one method that I tried to use (showDialog) was available in a class, but silently failed when it was called from a thread other than the UI Thread. In practice, you need to use an Android construct called a Handler to pass messages from one thread to another to allow the right thread to invoke the right method.

Also, seemingly harkening back to the days of Java ME, the media library seemed to have frustrating bugs. One API call I was expecting to use as documented (MediaPlayer.setDataSource) turned out not to work at all, and that I had to specify a FileDescriptor rather than a file path to load a media file. Also, another API (MediaPlayer.getCurrentPosition) returned completely erroneous values, and I had to develop a work-around. Thank goodness for StackOverflow in both these cases.

Conclusions

In the end, I got my little app working nicely. It was very satisfying to find that there was the ability to effectively add a new feature into my phone.

In that sense, Android gives user-developers a lot of power. And while I was expecting it to be a straightforward Java SE like development exercise, I discovered that it had a lot more in common with Java ME development. I had hoped that such platforms would easily attract the large pool of desktop developers, but it seems that there is still a mobile-specific learning curve that a developer will need to go through, and this will shrink the available pool of expert developers.

That said, I hope that Java developers will take a look at Android and see what kind of features they can innovate on top of it. As for myself, I hope to find the time for another hobby project again soon.

Metric of the Moment

Being on the technology-side of the telco industry, it’s interesting to see how all the complexity of technological advances is packaged up and sold to the end user. An approach that I’ve seen used often is reducing everything to a single number – a metric that promises to explain the extent of technological prowess hidden “under the hood” of a device.

I can understand why this is appealing, as it tackles two problems with the steady march of technology. Firstly, all the underlying complexity should not need to be understood by a customer in order for them to make a buying decision – there should be a simple way to compare different devices across a range. And secondly, the retail staff should not need to spend hours learning about the workings of new technology every time a new device is brought into the range.

However, an issue with reducing everything to a single number is that it tends to encourage the industry to work to produce a better score (in order to help gain more sales), even when increasing the number doesn’t necessarily relate to any perceptible improvement in the utility of the device. Improvements do tend to track with better scores for a time, but eventually they pass a threshold where better scores don’t result in any great improvement. Reality catches up with such a score after a few months, when the industry as a whole abandons it to focus on another metric. The whole effect is that the industry is obsessed with the metric of the moment, and these metrics change from time to time, long after they have stopped being useful.

Here are some examples of the metrics-of-the-moment that I’ve seen appear in the mobile phone industry:

Talk-time / standby-time. Battery types like NiCd and NiMH were initially the norm, and there was great competition to demonstrate the best talk-time or standby-time, which eventually led to the uptake of Li-Ion batteries. It became common to need to charge your phone only once per week, which seemed to be enough for most people.
Weight. Increasing talk-time or standby-time could be accomplished by putting larger batteries into devices, but at a cost of weight. A new trend emerged to produce very light handsets (and to even provide weight measurements that didn’t include the battery). The Ericsson T28s came out in 1999 weighing less than 85g, but with a ridiculously small screen and keyboard (an external keyboard was available for purchase separately). Ericsson later came out with the T66 with a better design and which weighed less than 60g, but then the market moved on.
Thinness. The Motorola RAZR, announced at the end of 2004, kicked off a trend for thin clamshell phones. It was less than 14mm thick (cf. 1mm thinner than the T28s). Other manufacturers came out with models, shaving off fractions of millimeters, but it all became a bit silly. Does it really matter if one phone is 0.3mm thicker than another?
Camera megapixels. While initially mobile phone cameras had rather feeble resolutions, they have since ramped up impressively. For example, the new Nokia N8 has a 12 megapixel camera on board. Though, it is hard to believe that the quality of the lens would justify capturing all of those pixels.
Number of apps. Apple started quoting the number of apps in the app store of its iPhone soon after it launched in 2008, and it became common to compare mobile phone platforms by the number of apps they had. According to 148Apps, there are currently over 285,000 apps available to Apple devices. One might think that we’ve got enough apps available now, and it might be time to look at a different measure.

In considering what the industry might look to for its next metric, I came up with the following three candidates:

Processor speed. This has been a favourite in the PC world for some time, and as mobiles are becoming little PCs, it could be a natural one to focus on. Given that in both the mobile and PC worlds, clock speed is becoming less relevant as more cores appear on CPUs and graphics processing is handled elsewhere, perhaps we will see a measure like DMIPS being communicated to end customers.
Resolution. The iPhone 4 Retina 3.5″ display, with 960×640 pixels and a pixel density of 326 pixels / inch, was a main selling point of the device. Recently Orustech announced a 4.8″ display with 1920×1080 pixels, giving a density of 458 pixels / inch, so perhaps this will be another race.
Screen size. The main problem with resolution as a metric is that we may have already passed the point where the human eye can detect any improvement in pixel densities, so screens would have to get larger to provide benefit from improved resolutions. On the other hand, human hands and pockets aren’t getting any larger, so hardware innovations will be required to enable a significant increase in screen size, eg. bendable screens.

But, really, who knows? It may be something that relates to a widespread benefit, or it may be a niche, marketing-related property.

The fact that these metrics also drive the industry to innovate and achieve better scores can be a force for good. Moore’s Law, which was an observation about transistor counts present in commodity chips, is essentially a trend relating to such a metric, and has in turn resulted in revolutionary advances in computing power over the last four decades. We haven’t hit the threshold for it yet – fundamental limits in physical properties of chips – so it is still valid while the industry works to maintain it.

However, it is really the market and the end customers that select the next metric. I hope they choose a good one.

iPhone Innovations

In my previous post, I described the iPhone as appearing to have incremental improvements, but also as allowing the promise of mobile data to be realised. Isn’t this a contradiction? How can minor innovations make such a difference?

I explained how Apple managed to do that with the iPod, compared to other digital music players at the time. It looks like they might have done it again with the iPhone, compared to other WiFi-enabled PDA-phones. Many of these PDA-phones appear to be functionally equivalent to the iPhone: they make calls, play music and movies, manage email and calendars, and allow you to browse the web. HTC has had such devices for a while, and we’ve also seen them from Motorola and Nokia. So, what’s new?

There are basically two types of data that you might want to access when mobile: your personal data, which can be synched to the mobile device; and external data, which these days is made available via the web. The former has been long solved (e.g. iPod) but the latter has been problematic for mobile devices. The main problem is basically that the web has been designed and developed for desktop computers, and not mobiles/PDAs.

Perhaps the most complained about difference between the web for PCs and the web for mobiles, is that on a mobile the web can be expensive and slow. Continual improvements to mobile plans (including caps and bundles), mobile CPUs (along the lines of Moore’s Law), and wireless broadband technologies (such as HSDPA) are addressing these complaints, and will eventually be good enough for this complaint to have little substance. However, for now, increasing numbers of mobile devices, including the iPhone, support Wi-Fi which will provide an equivalent experience to desktop computers in terms of cost and speed. As few people will need to browse the web as they walk or drive, Wi-Fi coverage in hotspots will often be suitable.

No, for the web to work on mobiles, three things need to work equivalently to a PC: input, output and page functionality. The iPhone has brought improvements to what is typical for a PDA-phone, and these are sufficient to gain PC equivalence in these areas.

Most web sites are designed with the assumption that the web browser has a PC keyboard and a PC pointing device like a mouse. The iPhone provides an on-screen QWERTY keyboard, and through its touch screen provides the ability to use your finger as a pointing device. Pretty much all previous touch-screen PDAs assumed that you would use a stylus as a pointing device, but this doesn’t work well on a phone as (i) it means you need to operate the device using two hands, and (ii) it slows the use of the device because before you can do anything, you need to extract the stylus from within the PDA first. The whole UI of the device needs to be completely overhauled if you don’t have the precision of a stylus, e.g. small ‘X’ icons in the corner of a window are too difficult to press to close applications, and scroll-bars along the side of windows are too difficult to manipulate. However, on the iPhone, to scroll a window, you simply wipe your finger along the screen. This is the first time a PDA-phone has managed to provide equivalent input to a PC without needing a stylus.

Most web sites are designed for a screen that is wider than it is tall, i.e. a landscape or horizontal layout. With more desktops and laptops coming with widescreen displays these days, this design principle is likely to become more extreme. However, because PDA-phones need to work when held as a phone, i.e. vertically, so that there is sufficient distance from the ear to the mouth, most mobile devices attempt to display web pages on a screen that is taller than it is wide. When web pages designed for a PC are shown on such devices, the browser either has to (i) shrink the font size so that it becomes unreadable, and needs to support some kind of zooming in-and-out, or (ii) reformat the web page so that it is laid out in a column, which is almost certainly not what the web page designer intended. The iPhone supports vertical display, but also horizontal display; all the user has to do is tip the device sideways. In horizontal display, standard web pages are apparently quite readable.

Most web sites are designed for display on a web browser with equivalent functionality to Microsoft Internet Explorer or Mozilla Firefox. This is not just that it support full JavaScript and dynamic HTML for all that Web 2.0 goodness, but that it supports all the really badly generated HTML out there which is ill-formed and certainly not standards compliant. The Apple Mac has had its own desktop web browser for a while now called Safari, and a version of Safari is included in the iPhone. This should cope with pretty much all those web pages out there that depend on full web browser functionality.

So, that’s it. Three apparently “incremental” innovations – stylus-free touch screen, ability to display horizontally, and a full web browser – are enough to provide an equivalent experience to browsing on the PC. Similar functions have all been seen before, but not quite the same, and not all together. And together they allow the promise of mobile data to be realised.