Archive for the ‘hardware’ Category

Getting a Sony Tablet S to work with Android tools under Ubuntu

November 18, 2011 Leave a comment

I’ve had a Sony Tablet S for a while now. Getting it to work with Android development tools under Windows required some special sauce, as there is no official development driver from Sony (or, to be more exact, there was not one back when I bought the device).

Instructions for Windows are still available here, by way.

Under Ubuntu, I did the usual thing with editing /etc/udev/rules.d/51-android, which worked for all my other Android devices, and still, “adb devices” did not list the Tablet S. I entered the line in the udev rules file like this:

SUBSYSTEM=="usb", ATTR{idVendor}=="054c", MODE="0666", GROUP="plugdev"

… and here is my output from lsusb:

Bus 002 Device 005: ID 054c:05b4 Sony Corp.

After Googling for a bit, I got it to work. The missing step was to add 0x054C (Sony’s UPnP identifier) to my ~/.android/adb_usb.ini. I repeat, this was not necessary for any other of my Android devices, so the Sony must be special in some way.

kman@kman-P55-UD3R:~$ echo 0x054c > ~/.android/adb_usb.ini
kman@kman-P55-UD3R:~$ cat ~/.android/adb_usb.ini
kman@kman-P55-UD3R:~$ adb kill-server
kman@kman-P55-UD3R:~$ adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
42801024420f617 device


Categories: android, hardware

JS5 firmware for Samsung Galaxy S i9000 is garbage

April 10, 2011 2 comments

After a week or so of using the Voodoo lagfix kernel, my Galaxy S started to get somewhat laggy again. I think it’s related to Voodoo not being able to convert the system partition for lack of free space (update: Voodoo can convert the system partition with my current 2.2 JPP/JPB, but not with 2.2.1 JS5).

So I’ve decided to try the latest official firmware available – JS5.

My verdict: it’s garbage.

– It is still laggy.
– It has the somewhat famous bug where applications are denied access to their own preferences.

More on the second issue. This was discovered in their first 2.2.1 firmware, I believe it was available in Norway for a month or so earliy this year (Samsung was possibly doing staged rollout / testing). Here is a description on xda-developers.

This issue was also discussed on android-developers (an official Google Group for Android SDK), was confirmed, investigated, but no-one could find a way to report it to Samsung. Their Samsung Mobile Innovator (a pretty pompous name for a developer resource site) doesn’t even mention Android. The bug was reported on Samsung’s Java ME forum, for lack of better place, but didn’t get any attention.

And here it is, still not fixed in JS5: happens if you uninstall an application or two, and then reinstall in a different order. After this, reinstalled applications will not be able to write data to their own shared preferences. The way it shows is that applications lose their settings, but because Android doesn’t shut down applications immediately, it may only become apparent overnight, or even after a few days. When this happens for your users, you will get reports like “Your application randomly loses settings after a period of time”.

It’s really quite ironic that the data loss issue is caused by Samsung’s attempts to fix the lagging file system issue. It made no sense, because all internal storage on that phone is located on the same 16 GB memory chip, just partitioned, and thus would be equally subject to lagging.

It’s also really quite ironic that the laggging is caused by a combination of Samsung’s RFS file system and the “smart” storage controller used in the Galaxy S. I recenly bought a Galaxy Ace for my cousin, and while it uses RFS, it does not have the “smart” storage controller. Guess what, no lagging whatsoever.

Finally, it seems that Samsung sells their “smart” storage controller with RFS, as a complete solution. Guess they either don’t know about lagging, or don’t care, passing the problem on to their customers (hardware vendors) and then on to their customer’s customers.

I am back to JPB/JPP (2.2), which doesn’t lose settings. Might try the Voodoo kernel again.

One thing for sure: I will not be buying the Samsung Galaxy S II (GT-i9100) when it becomes available.

Categories: android, hardware

Voodoo kernel for the Galaxy S is fantastic

March 28, 2011 3 comments

Last week I updated my Samsung Galaxy S to use Voodoo Kernel. Took about ten minutes, and it kept all my data and settings.

I am just speechless at the difference it made.

The phone was barely usable for normal everyday activities, and just unusable for development, because of a slow file system (rfs) used by stock Samsung firmware. Writing to a file could take up to 3-4 seconds, compared to 50-90 milliseconds on my Motorola Milestone.

Voodoo kenel fixed that: the phone just files now, and most impressive, can actually be used for development work.

If you do update yours, remember that there is a way to donate to the project’s developer.

Categories: android, hardware

Moto Milestone supports 802.11n

The specs for Motorola Milestone says that the phone supports 802.11 b/g but not “n”.

However, my router’s status page shows that Milestone actually negotiates an “n” connection:

The in the screenshot is my Milestone. Now, 65 Mbit is not so much more than 54 Mbit for 802.11g, but clearly the hardware supports the high-speed standard. Perhaps with some tweaking, it could actually work at higher speeds?

Categories: android, hardware, wifi

WiFi on the Milestone – hmm, interesting…

May 20, 2010 2 comments

The Milestone (and I suppose, Droid) has an interesting glitch in its WiFi code.

When trying to connect to a protected network with an incorrect password, the networking code does not notify the application that the password is wrong. It just sits there trying to connect – the final notification is that a connection is in progress, but no notification of a successful connect (obviously) and no errors.

The problem is deep inside the firmware. This can be verified with Android’s built-it WiFi connection screen.

My code registers for WifiManager.SUPPLICANT_STATE_CHANGED_ACTION (“”). It is broadcast in many cases, but in case there is an authentication error there is supposed to be an integer extra, WifiManager.EXTRA_SUPPLICANT_ERROR set to WifiManager.ERROR_AUTHENTICATING.

On the Milestone, the action is never broadcast.

HTC Hero handles this case the way it’s supposed to.

Categories: android, hardware, wifi

Motorola Milestone probs – got a replacement

May 17, 2010 2 comments

Got my bad Motorola Milestone replaced today. I made sure to thoroughly test the phone before leaving the store, and this was certainly a good idea. Only the third device passed my quick tests – one had a non-working camera, and another one – broken GPS.

So I am all set to update my applications for Android 2.1, should take a few days…

Categories: hardware

Motorola Milestone light sensor problems

May 16, 2010 6 comments

So I got my Motorola Milestone yesterday. It just became available in Russia a few days ago, and I really wanted to get it fast because of two reasons:

– First, I had some reports of my software not working correctly on the Droid (the Milestone is the European version of the same phone), so I wanted to release updates with fixes.

– Second, it really seems like a nice phone. I was going to switch SIM cards, keep my HTC Hero around for compatibility testing, and use the Milestone as my day-to-day phone as well as for further development work.

I had read that the Droid had a somewhat buggy firmware, but that most problems were fixed in the update to Android 2.1.

Well, I was really excited when the phone was delivered, but later that same day it turned into a major disappoinment. My Milestone has a problem with the proximity sensor, which pretty much renders the phone useless for making phone calls.

When a call goes through, the screen turns black and can only be turned back on by sliding out the keyboard. The power button, as well as the sensor buttons do nothing. Apparently, the proximity sensor is faulty, and blanks the screen even though the phone is not held next to the ear.

The weirdest thing is that this happens in bright light. When using the phone inside, or outside on a cloudy day, it all works fine.

Apparently, a lot of people are having this problem with the Droid in the US, and there is no way to fix it short of getting the phone replaced. I am going to try to get an exchange or get my money back and buy it elsewhere.

Categories: hardware