1. set up a virtualised Android development environment
2. try out yet another distribution

I did something similar a couple of days ago: I created a virtual machine, installed Arch Linux on it and assembled an “on demand” server with Nginx, Apache, MySQL and PHP. “On demand”, in this case, means “it’s started when I demand it to start”. It’s great because when I’m not using the computer for web development I don’t have any of these services running, plus they are completely isolated, so if I break something configuring them I don’t end up with an unusable system!

Encouraged by this success, I wanted to do the same with Android. The reason for using a virtual environment for Android development is that it wouldn’t “pollute” my main system with all the stuff that is needed for Android. Or in other words: the Android SDK, with the different platforms that can be used, plus the Java SDK/JRE (I don’t use Java for anything else), udev rules for mounting phones and other devices, Eclipse and/or IntelliJ IDEA, and environment variables for $JDK_PATH, etc.

Since the recommended distribution for Android is Ubuntu (i.e. it’s the one the official tools are tested with) I thought I would create a virtual instance of Lubuntu, which is based on LXDE, a very lightweight environment that looked like the perfect candidate to run in a virtual system.

However I found a huge blocker for my purposes, and several other glitches :-(

The huge blocker is that I have failed to configure my physical device for deploying directly to the phone from within VirtualBox. I installed the extra packages for VirtualBox in order to use USB2.0, added the filter for my phone, also added a “magic line” to /etc/fstab (in the host), and created udev rules both in the host and in the guest… but still keep getting the dreaded

error message. Not to tell you about the number of times I attempted reloading udev rules, logging in and out, restarting in desperation… Meh!

On the distro test side: Lubuntu looks quite nice and lightweight, although it’s got a good share of visual oddities. For example, the installation system uses one of those mouse cursors in which the arrow points to the right instead of to the left as we’re used to.

Once the installation finishes, a relatively familiar environment shows up. It looks like good old GNOME 2, but somehow leaner. For example, there’s only one panel, and they use Chromium instead of Firefox, and Abiword instead of LibreOffice’s Writer. Also, as with GNOME 2, odd things happen from time to time, such as when the icons decide to change themselves spontaneously to another theme, and that sort of stuff that leaves you wondering: wasn’t that icon black a second ago? why is it red now?

Unfortunately it also lacks some polish that we take for granted in GNOME 2. For example, the menus have to be edited by manually creating and editing files in ~/.local/applications if I remember correctly, as there isn’t any menu editor GUI. Not a huge problem for me, but definitely not something you’ll be telling a non tech-savvy friend to do. Arranging items in the panels is also clunky: you have to edit the panel and move things around by selecting them first then clicking “up” and “down” buttons in order to rearrange them.

But the worst glitch I found was with the file manager, PCManFM. I actually had experienced it before with another ArchLinux install, but I thought that had been due to a bad configuration on my side. Turns out that if you open a compressed file with file-roller (as happens when double clicking any compressed file), and then try to drag anything from the compressed file to a location in PCManFM, you get an error like follows:

Extraction not performed: You don’t have the right permissions to extract archives in the folder “”

And that’s it. You can’t close the dialog, as none of the buttons are responsive. You can’t close it with CTRL+W either. You can’t switch to another window. Maybe you could log in with ssh from another computer and try to kill the pcmanfm process, if you enabled ssh before. What you’ll probably do is reset the computer/instance, anyway. Not nice if you hadn’t saved your work.

Conclusion: I won’t be installing, or advising the installation of, Lubuntu on relatively underpowered computers, as the defaults seem “slightly” buggy :-P

Now I’ve got to install the Android SDK and company on Arch, but it shouldn’t be too hard anyway. Of course, if you know how to deploy to physical devices from a VirtualBox environment, please let me know before I completely nuke that virtual machine! :-D

~~~

Previously on this saga: XFCE.

Or more exactly, the double spacing that I was seeing, instead of just a single line as in the original!

Initially willing (or expecting) to put the blame on me, I examined my back-end code first, but there is nothing dealing with double spacing or “Windows spacing” correction, such as automatically replacing \r\n with \n only.

I then remembered that when I developed this section a year ago I was using Chrome as my main browser, so I wondered if it was a Firefox-only error that had slipped thru back then. Therefore, I repeated my test with Chrome: opened a FILE_ID.DIZ with gedit, copied the text and pasted it to the corresponding textarea. Clicked on save… and the result came out OK! Simple single line-endings were received by PHP, as one would expect.

So it’s a Firefox thing then, I thought. Not so fast, it can still get more bizarre. But before I get to that, let me show you a little piece of test code I wrote to ensure nothing else was interfering in the process:

(you can download it from here, in case you want to test it too)

What the test code does is simply highlight ‘\n’ characters with red, and ‘\r’ characters with green, so I can visually see what has been added. It’s not exactly like a full-grown hex editor, but it’s more practical for testing in the browser.

Then, if I use the following test text (please ignore the fact that some characters are garbled because of the encoding–though if you don’t understand Spanish it should all look fine to you!):

When run with Firefox, I get this:

(notice the double spacing: there are double sequences of \n\rs)

And with Chrome it’s fine:

And here comes the fun: when I copy the text from Chrome and paste it in Firefox. What do you think will happen? Will it double the space when I press Submit?

No! This time it works properly! Crazy! Or what? Well, I have made more tests to try to pinpoint what’s happening.

Test one: copy from a txt file that I created on this computer (so it’s all Linux line endings), paste into Firefox: WORKS. Paste into Chrome: WORKS.

Some guy reported (for another product) that copying from Gnome terminal or gedit to Firefox got him strange results, so I tested the Gnome terminal bit too. Works on Firefox and Chrome: no extra line endings.

Test two: I converted the original text file from Code Page 437 (the old MSDOS encoding) to UTF-8, and opened it with gedit, and pasted it into Firefox: DOESN’T WORK! Double line spacing again! I guess a \r is a \r is a \r, no matter what the encoding! (fortunately).

Test three: Opened the file with GVim. Copied everything and pasted into Firefox: WORKS. Single line spacing as expected.

Conclusion?

Before drawing up a conclusion, I’ll summarise the facts:

1. In all the tests that “fail”, the copy-paste source is gedit, and the content is a file with MS-Dos line endings.
2. It only fails with Firefox

So this is what I think is happening: gedit is getting confused by the MS-Dos line endings, and “something is wrong” in the data it puts in the clipboard when I press CTRL+C. Then Firefox gets sort of crazy when it gets those “wrong” characters or whatever gedit is storing in the clipboard, and tries to correct it… but ends up adding double the required line spacing.

On the other hand, Chrome seems to be able to “recover” from possibly malformed data, and proceeds in the normal way we expect: not duplicating content.

However I’m not too sure about this theory. I’d like to see the raw clipboard contents (this time, with a proper hex editor), to find out what is in there, but I haven’t been able to find any program which does it. And I’m not sure I want to start digging X-Clipboard protocol RFC’s or whatever it is that they use for their specs in order to find out how to communicate with the daemon which is listening to CTRL+C/CTRL+V key presses.

Do any of you have any pointer? Any idea? (other than telling people to not to use gedit!). A server-side solution is not exactly the best idea, since although I can detect whether the user is using Firefox, I don’t have any way to detect if a text was pasted from gedit! And blindly replacing groups of \r\n\r\n with just \r\n won’t work either: what if the text file indeed contains two carriage returns?

Decisions, decisions!

Update: found a gedit bug which might be related to this issue!

What an ironic, unfortunate coincidence–maybe we should retitle the phone as Xperia NOT PLAY.

And the worst is… I don’t even know where to report it! I can’t find any Sony Ericsson bug tracker, and since I’ve tested this on other several phones and even the Galaxy Tab, and it works on them, I’m pretty sure it’s only the PLAY that decided to act silly.

But having in mind this was a developer phone, and probably it had many rough edges still to be polished, I thought: maybe there’s a software update and this is old news already? Yes, some sources said so, it was exactly released on the 2nd of August. Excellent!

So I have gone to Settings — About phone — Software update — Update now. First it complained with a “Could not connect to network” error. Some forum searches after, I’ve found some people suggested taking out the SD and SIM cards. There wasn’t a SIM card in place anyway, so I’ve taken out the SD card too.

Repeated the process… and again “Could not connect to network”. Gah!

But then I remembered that this update was meant to be rolled first to European customers. Aha! Maybe that’s why it complains about not being able to connect to a network–it wants the GSM network to find out where I am! So maybe it’s not a problem of Wi-Fi connectivity?

Third attempt: I’ve re-inserted the mini SD card, and placed a SIM card too on the phone. Turns out I was right: the phone did find the network it was looking for, also found where I am, and then it checked for updates.

Unfortunately, it also decided that my phone is already using “the latest version”. Err… no, 2.3.2 is definitely not the latest version. Oh well, maybe it is according to Sony’s security standards.

But despair not! For there’s still another way to update, using Update service, which is… a Windows-only program!?

No, I don’t think I’m going to install that. We’re past the age of installing software in our computers in order to update our phones, right? RIGHT?

Update: I’ve filed a bug in Android’s bug tracker. Although I have the feeling it will be useless, but at least it will be documented… and you can even star it! Oooh!

So it was failing well outside my domains–in a native method! There wasn’t even a line number to have a look at. But was it because of something I did? I thought maybe it was because I wasn’t synchronizing things properly–so I went to make sure everything was properly initialised, nothing was done before it was due… and still it crashed.

Then I paid even more close attention and I noticed that the difference between ‘crash’ and ‘no crash’ was that before it crashed it always output a mHardware->setOverlay() failed with status -2147483648 message

So since I couldn’t find any solution or pointer anywhere, I decided to have a look at the native code–that way, I could at least find out what was that setOverlay() failed message about.

It took me a bit to navigate the code, since there are lots of messages and calls going back and forward between Samsung’s specific code and Android’s core, and I’m not sure I have totally understood how it works, but it seems that the firmware for the Nexus S (alias Samsung Crespo) requires that

• the preview surface width is a multiple of 8 (and at least 8), and
• the preview surface height is at least 16

That is defined in the check_fimc_dst_constraints function in mydroid/device/samsung/crespo/liboverlay/overlay.cpp

I changed the preview size to 8×16, and now the app doesn’t crash on the Nexus S, although there’s an unfortunate side effect: the preview is more visible than it was before –yes, it was visible. It was a 1×1 sized preview, and that’s why it was failing on the Nexus S (and probably any other setup with that kind of surface size restriction). Now I need to find a way to hide it… oh wait, I found it! The answer, on the following post :P

Introducing an even nicer, more elegant preferences panel:

… which uses a bit of this*:

Guess where, it’s not complicated :-)

The wallpaper also works properly now in the Evo 4G (and potentially other phones using the same UI than the Evo uses).

The Evo reports a really bizarre value for xOffsetStep: instead of the expectable ~0.14f (from 1.0f / 7 == horizontal number of virtual screens), it is reporting -1 (how can a screen have a width of -1?).

This looks to me like a bug, but since it uses that revamped HTC UI I’m not sure who’s responsible for sending values to the wallpaper, whether it’s the OS or the UI. I’ve got to research this… if it’s the OS maybe I can file a bug in the usual place. I’ll let you know.

You can also read more about Cube Clock 1.5 and prior versions.

* Somehow gratuitous drawing executed with Inkscape –it’s ages since I did my last technical drawing and I didn’t know of a better program for it. Consequently the dimension marks are a bit wrong and everything is slightly inaccurate position-wise, but you get the point. Anyway, suggestions for more appropriate CAD programs are welcome. Specially if they also support formulas.