Home > software > On Android and CyanogenMod

## On Android and CyanogenMod

On Wednesday, I have bought myself an Android phone, as my good old S-E C510 suffered from worse and worse charging problems. I have found that I find it pretty much impossible to type on a touchscreen and did not see any improvement even after light practice (on a spare second hand Android phone I acquired just for its sensor – sometime in the future, maybe it will drive a quadcopter). So, I went for Sony-Ericsson Xperia Pro (codename iyukan) with its hardware keyboard. It’s a pretty neat phone, my only complaint is a difficult-to-press power button.

However, just after turning it on for the first time, the phone prompted me to upgrade it from Android 2.3 to Android 4. The fool I was, thinking that newer is better and wanting to summarily get rid of all the preloadware apps… And since a friend told me that CyanogenMod works all right on this phone, I would need a Windows PC to upgrade to Android 4 the Sony Ericsson way, I like to have full control over the systems I use and I like CM’s tray design ;-), I went for it.

First, some tips and tricks for fellow Googlers that come by this post in a need to get CyanogenMod working on their Xperia Pro:

• Do not expect CyanogenMod wiki to be a place to document even critical issues, learn about them and solving them. Your only shot is hitting the issue blindly and then followup wild googling and IRC. More on that below.
• Ignore stock CyanogenMod. What you want is using CyanogenMod fork FreeXperia (FXP) which contains CM tuned for Xperia phones, with both custom kernel and set of drivers and applications. Follow the regular CyanogenMod flashing howto, just use .zip files provided by FreeXperia. The latest CM9.1 Xperia version FXP136 worked quite well for me, aside of wifi troubles (more on that below), camera autofocus on touching the cmaera button and maybe some compass weirdness (I didn’t verify that yet, but there are workarounds in the tracker in case it proves to be a real issue).
• If you insist on stock CyanogenMod 9.0.0-rc2, replace the boot.img you will be flashing (kernel image) with the one from FXP136, or your phone will essentially refuse to start up with applications like the Setup Wizard crashing and if you manage to get past that, the phone being quite sluggish.
• New FXP WiFi drivers for Xperia Pro (wl12xx, specifically wl1271) have support for some extended powersaving features that depend on RX streaming. On some APs, that means the device will receive packets only up to 100ms after it transmits packets itself – any packets coming after that will be lost, which means that communication with sites that take a little to process your requests (e.g. the Market) or using any kind of streaming breaks.
I have spent the whole last night fiddling with wifi and binary patching wl12xx.ko to tweak the parameters, but I just didn’t manage to get it working with my Wifi AP. However, over the night I have tilted to thinking that this is slightly more likely bug in powersaving support of my AP rather than in the wifi firmware, which is simply using more aggressive powersaving modes now than other Android phones visiting my home wifi network before and other devices like notebooks. I have pretty much given up on debugging this now and will just buy a new AP, since with all other APs I have came by so far the phone works fine (but there are scattered reports about this problem on the net).
• My phone refuses to properly authenticate with my AP (always stuck in the “Obtaining IP address stage”, but in fact it never comes to DHCP, instead it fails right after authentication), wpa-supplicant logs WPA: EAPOL-Key Replay Counter did not increase - dropping packet and that’s it. After I restart my AP, the authentication succeeds… once; if I disconnect, I won’t connect again anymore. Again, this happens just with my AP, so maybe there is some connection to the previous problem, perhaps some authentication packets being dropped… This happens with WEP, WPA-PSK TKIP or AES, … The only workaround I have found is to restart the AP.
• Before, my phone would get stuck in a different way, believing that its rightful IP address is 169.254.222.something and never asking using DHCP for an actual IP address. The solution to that problem is to open a terminal, su, and rm /data/misc/dhcp/*.leases. Also, don’t panic if you are to connect to eduroam; even though the WiFi authentication dialog will show phase 2 to be “None”, that does not mean wpa_supplicant on the phone is not internally using MSCHAP. :-)

So, in the end, the phone has eaten much of my last three days, and it was not spent installing and fiddling with neat apps but debugging some frustrating issues. I hope it will serve me better from now on… :-)

But this has been also an interesting lesson in dysfunctioning open source projects – yes, I mean CyanogenMod and FreeXperia. First of all.

The problem is that the projects are very unfriendly to their audience. Sure, CyanogenMod has a pretty front website and after some very non-straightforward you may even reach a straightforward HOWTO for your phone that you may follow to do the installation, but the project becomes unfriendly once you need to do some powerusery things with your phone or even start taking look at the source and doing some development. First, I should take a note that some of the issues are probably FreeXperia specific. Let’s take a look at some of the problems:

• Bad overview documentation. I found no way to actually learn on my own about FreeXperia and its relationship to CyanogenMod (which is still not completely clear to me). Even long after first hints to “use FXP136” or whatever, I was clueless about what the “FXP” actually meant.
• Bad release documentation. On Xperia Pro, the latest CyanogenMod official is 9.0.0-RC2. There appears to be absolutely no way to learn about what kind of state is it in – what blocker bugs are there to keep this at RC2? Is it worth waiting for 9.0.0? It appears to be all just in the minds of the maintainers so the only way to decide which version of CM to pick is to waste time trying to install it. Also, FreeXperia homepage caries essentially no documentation either, not even linking a fairly essential companion forum thread.
• Bad detailed documentation. It appears that the only way to learn about issues and try to solve them is either asking on the forum and navigating its unwieldy paginated threads, or asking on IRC and hoping someone knowledgeable is by accident following the channel at that moment. There is a Wiki but most attempts to document issues and help out fellow users or simply correct factual errors appear to be reverted without explanation.
• Bad development documentation. Xperia Pro is actually a huge exception here since there is an actual HOWTO on compiling CyanogenMod for it using the arcane build system. However, trying to navigate the masses of github repositories of both CyanogenMod and FreeXperia and understanding how they relate, in which repository and in which branch can I actually find the kernel I’m running and where does my wl21xx module come from has taken me several hours anyway. While FreeXperia is supposed to be an “open source” project, there is actualy no word on its homepage about where to get the sources and how are they built; you are on your own in the GitHub maze (and no, there is no link to GitHub’s FreeXperia account on its homepage either). I’d say this is on the verge of violating GPL, though probably not quite behind the line yet…
• Less than ideal developer attitude. The people at IRC are mostly very helpful and I thank them again for all their help. But I have been rather discouraged by my wiki experience and why should I even bother reporting bugs?

I complained a bit about some of these issues in the past few days. A fellow IRC user asked “would you rather developers spend their time on documentation than fixing bugs?”. I think resounding “YES” is in order. Most basic documentation (what is what) does not take long to write and goes a long way. Also, putting effort to fixing bugs is usually no excuse for bad attitude to users.

It seems to me that to be a happy CyanogenMod user, you either do not actually put much effort in poking the system and you are lucky to have a most mainstream device with all the major issues ironed out, or you go all the way to become a core developer and learn about all the details. If you are stuck somewhere in-between, willing to get to the bones of the system to solve your problem but just wanting to solve your problem, CyanogenMod/FreeXperia gives you no choice but to spend days learning about all the ways things work and are getting done.

Given that, it is actually surprising to me that it still works as well as it does. It is an interesting case study in open source dynamics. I think it will be interesting to see whether FreeXperia can survive for long time as the original developers, who don’t work in a much open environment, wear out and enthusiasm of newcoming fresh developers will be required… Let’s watch and learn!

Categories: software Tags:
1. September 10th, 2012 at 10:36 | #1

Welcome to the Android community. Yes, it is a totally broken Open Source community and everybody just wants fame. Copying code is called “to kang” and normally nobody gives credits. You’re lucky if you find someone who shares code and experience with you.

2. September 10th, 2012 at 11:39 | #2

That link immediately shows me the changelog. And miraculously enough click on issues tab and you can see the issues users have reported.

And using some common sense you get https://github.com/freexperia

@Andreas

3. September 10th, 2012 at 15:26 | #3

You have some fair points there, I feel some others need a bit of clarification though:

1) “Do not expect CyanogenMod wiki to be a place to document even critical issues” – That’s why there’s an issue tracker with sorting/filtering facilities at https://code.google.com/p/cyanogenmod/issues/list

2) “Ignore stock CyanogenMod” – If it doesn’t work, report a bug like you would do with any other OS project, don’t just ignore it. Regarding a final release for iyokan, it should have had one (both on 9 and 9.1), but on reality it didn’t. The device maintaner is now aware of this and it should be resolved soon – from the looks of it, it seems to have been a simple oversight by the person launching the builds.

3) “Bad overview documentation” – As far as I’m aware, Freexperia is just the group of people who work on SEMC (and now Sony) phones. They keep their own trees to work and collaborate faster, and eventually, when stuff is ready, it gets merged back in CM. At times they might as well do releases out of CM to get user feedback, reports and the like. It is a certainly not uncommon practice, several other developer teams on CM do it as well.

4) “Bad release documentation.” – Forums like XDA-Developers and RootzWiki are usually good places to find this kind of information. Also, see 2) regarding your specific device.

5) “Bad detailed documentation” – See 1)

6) “Bad development documentation” – cm.dependencies on your device tree is a nice way to know repos and branches for device specific stuff. On your case, see https://github.com/CyanogenMod/android_device_semc_iyokan/blob/ics/cm.dependencies
Also note that all of the building guides are the same other than $devicename and$codename – it’s a wiki template.

Regarding collaboration, if you would like to fix an issue, by all means do so. The building guide you linked earlier should get you up to speed on how to build CM, and the Gerrit howto (http://wiki.cyanogenmod.com/wiki/Howto:_Gerrit) will help you get your code on the review system (http://review.cyanogenmod.com/). If you hit any bumps in the road, there’s pretty much always people on #cyanogenmod-dev that can help you out. Most device maintainers also idle on IRC too if you’d like to talk with them.

DISCLAIMER: I’m a CM device maintainer.

4. September 23rd, 2012 at 17:25 | #4

@Emilio
Thank you for much for all the details! Part of my point is that have I been able to find much of what you describe early in the process, the experience would be quite less painful. I hope that perhaps your comment here will help some fellow Google wanderers.

I still don’t think the bugtracker is a good way to provide release notes. For example, because (i) it may be non-trivial to extract good description of the problem and the proper workarounds from all the bug history in case of convoluted bug reports, and (ii) bug reports may get closed some time before next release (I’m not sure about CM’s policy in this regard; it seems that ShouldBeFixed is used in this case there?). It’s not terribly user-friendly either to make people sift through lists and reports. :-) Part of the problem is also that release notes in text form is *usual* (even for projects using bug trackers) while just relying solely in the bug tracker is I think fairly *unusual* – people (at least me) avoid trying things that are normally unexpected.

Still, a great reply, thanks again!