Tag: android

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.

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:

  1. 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.
  2. 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.)
  3. 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.