Upgrade your HTC droid eris to android 2.2
Posted by Kelvin on 10 Oct 2010 | Tagged as: android, programming
Why bother upgrading? 2 simple reasons: USB and wifi tethering.
Instructions courtesy of my friend Jack:
Step 1) Do a complete backup of your SD card data (just in case)
Step 2) Root your phone
– Go to http://forum.xda-developers.com/showthread.php?t=742228 and follow the instructions
Step 3) Do a Nand backup
– Make sure you have >=500Mb free on your SD card
– With phone off, hold Power + Volume Up to boot into recovery
– Choose the Nand backup option
– Copy the nandroid folder from your SD card to your computer
Step 4) Load the ROM of your choice
– Download a ROM (I recommend http://forum.xda-developers.com/showthread.php?t=745603)
– Follow directions from the ROM page, which generally will include
– Put the ROM in the root dir of your SD card
– Reboot phone into recovery mode (like in step 3)
– Wipe data / factory reset, and wipe Dalvik-cache
– Flash zip from SD card
– Wait for a long time
If you're having difficulty getting to the recovery console like me, try Volume Down + Power instead.
EVDO/3G as preferred network on Android 2.1+
Posted by Kelvin on 05 Jun 2010 | Tagged as: android, programming
Found this out through a friend:
1. Hit *#*#4636#*#*
2. Phone Info
3. Select WCDMA in Preferred Network.
More information on preferred networks available here: http://www.google.com/support/forum/p/android/thread?tid=6a327a95211ac789&hl=en
WCDMA preferred - The GSM phone is capable of using both 2G and 3G data communication and when signal strength is low 3G is favored more.
GSM only - The GSM phone is capable of using only 2G data communication. When the 2G signal is too low you get nothing at all.
WCDMA only - The GSM phone is capable of using only 3G data communication. When the 3G signal is too low you get nothing at all.
GSM auto (PRL) - The GSM phone is capable of using both 2G and 3G data communication and when signal strength is low 2G is favored more. This one is a bit confusing to me since PRL is associated mostly with CDMA technology and not GSM technology.
CDMA auto (PRL) - The CDMA phone is capable of using both 2G and 3G data communication and when signal strength is low 2G is favored more.
CDMA only - The CDMA phone is capable of using only 2G data communication. When the 2G signal is too low you get nothing at all.
EvDo only - The CDMA phone is capable of using only 3G data communication. When the 3G signal is too low you get nothing at all.
GSM/CDMA auto (PRL) - Some phones are equipped with both GSM and CDMA capabilities. This setting appears to just have the phone attempt to stay connected to the data communication type that works the best. (Maybe the Samsung Galaxy S will take advantage of this???)
Unknown - If none of the above fit or the phone is acting weird as far as connecting to the carrier, you will see your preferred network type is set to this
Accepting remote proxy connections on Android
Posted by Kelvin on 02 Jun 2010 | Tagged as: android, programming
Android's adb bridge, when performing port forwarding to the Android device, only accepts connections from localhost. This is most probably for security reasons, but is a nuisance when you want to be able to access the net via your Android device from >1 computer over the network.
The solution: http://rxwen.blogspot.com/2009/11/adb-for-remote-connections.html
Its a drop-in replacement for your ANDROID_HOME/tools/adb file.
[SOLVED] Android 2.1 + HTC Droid Eris on Windows XP
Posted by Kelvin on 28 May 2010 | Tagged as: android, programming
After updating to Android 2.1, Windows XP no longer recognized my HTC Droid Eris.
The fix:
1. download the USB Driver via the Windows Android SDK
2.check your Android's VID and PID via Windows Device Manager
3. Open android_winusb.inf in the usb_driver folder and check that the VID/PID combo exists in the file.
4. If it doesn't, add it in into the respective INI section. For example, I added this for Droid Eris under the [Google.NTx86] section:
%CompositeAdbInterface% = USB_Install, USB\VID_0BB4&PID_0C98&MI_01
5. Save and reinstall the USB driver and that's it!
Proxoid users
If you're currently using Proxoid's windows drivers, they're not updated for Android 2.1. Try using the Android SDK version instead.
Also, you'll need to copy over adb.exe and AdbWinAPI.dll from the android sdk tools folder over to the proxoid-adb folder.
[SOLVED] Connection Reset problems with Proxoid
Posted by Kelvin on 02 May 2010 | Tagged as: android, programming
Update
My patched version of Proxoid is available here: http://www.supermind.org/friends/SuperProxoid-debug.apk
Source code is available here: http://www.supermind.org/friends/superproxoid-snapshot-20101009.tar.gz
Note: I'm no longer using Proxoid, SuperProxoid, or even AziLink etc. I'm now using a rooted Android 2.2 which supports USB and wifi tethering! Way cool. Instructions here: http://www.supermind.org/blog/774/upgrade-your-htc-droid-eris-to-android-2-2
I've been using the excellent tether app, Proxoid to hook up my PC to my Android-based Droid Eris phone.
However, after a period of somewhat heavy usage/browsing, it inevitably barfs and refuses to take any more connections.
In Firefox, this appears as "Connection reset". In Chrome, pages simply refuse to load. The workaround I used for awhile was simply to stop the proxoid service on the Proxoid app, then start it again. This was fine (if somewhat annoying for surfing), but is a non-starter if you happen to be downloading anything at that point.
I decided to do abit of sleuthing, and installed the Log Collector app so I could see what was going on when Proxoid refused any more connections. Here's a snapshot of what the log file showed:
05-02 09:56:47.466 E/OSNetworkSystem( 6923): unclassified errno 24 (Too many open files)
05-02 09:56:47.466 E/OSNetworkSystem( 6923): unclassified errno 24 (Too many open files)
05-02 09:56:47.477 E/ProxoidService( 6923): null
05-02 09:56:47.477 E/ProxoidService( 6923): java.lang.NullPointerException
05-02 09:56:47.477 E/ProxoidService( 6923): at org.apache.harmony.nio.internal.SelectorImpl.prepareChannels(SelectorImpl.java:223)
05-02 09:56:47.477 E/ProxoidService( 6923): at org.apache.harmony.nio.internal.SelectorImpl.selectInternal(SelectorImpl.java:191)
05-02 09:56:47.477 E/ProxoidService( 6923): at org.apache.harmony.nio.internal.SelectorImpl.select(SelectorImpl.java:167)
05-02 09:56:47.477 E/ProxoidService( 6923): at com.mba.proxylight.RequestProcessor$1.run(RequestProcessor.java:72)
05-02 09:56:47.477 E/ProxoidService( 6923): at java.lang.Thread.run(Thread.java:1058)
05-02 09:56:47.486 E/ProxoidService( 6923): null
05-02 09:56:47.486 E/ProxoidService( 6923): java.net.SocketException: Operation failed
05-02 09:56:47.486 E/ProxoidService( 6923): at org.apache.harmony.luni.platform.OSNetworkSystem.createSocketImpl(Native Method)
05-02 09:56:47.486 E/ProxoidService( 6923): at org.apache.harmony.luni.platform.OSNetworkSystem.createSocket(OSNetworkSystem.java:85)
05-02 09:56:47.486 E/ProxoidService( 6923): at org.apache.harmony.nio.internal.SocketChannelImpl.(SocketChannelImpl.java:156)
05-02 09:56:47.486 E/ProxoidService( 6923): at org.apache.harmony.nio.internal.SelectorProviderImpl.openSocketChannel(SelectorProviderImpl.java:79)
05-02 09:56:47.486 E/ProxoidService( 6923): at java.nio.channels.SocketChannel.open(SocketChannel.java:95)
05-02 09:56:47.486 E/ProxoidService( 6923): at org.apache.harmony.nio.internal.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:131)
05-02 09:56:47.486 E/ProxoidService( 6923): at com.mba.proxylight.RequestProcessor.process(RequestProcessor.java:351)
05-02 09:56:47.486 E/ProxoidService( 6923): at com.mba.proxylight.ProxyLight$1.run(ProxyLight.java:127)
05-02 09:56:47.486 E/ProxoidService( 6923): at java.lang.Thread.run(Thread.java:1058)
05-02 09:56:47.496 E/ProxoidService( 6923): null
05-02 09:56:47.496 E/ProxoidService( 6923): java.lang.NullPointerException
05-02 09:56:47.496 E/ProxoidService( 6923): at org.apache.harmony.nio.internal.SelectorImpl.wakeup(SelectorImpl.java:332)
05-02 09:56:47.496 E/ProxoidService( 6923): at com.mba.proxylight.RequestProcessor.closeAll(RequestProcessor.java:323)
05-02 09:56:47.496 E/ProxoidService( 6923): at com.mba.proxylight.RequestProcessor.access$2(RequestProcessor.java:302)
05-02 09:56:47.496 E/ProxoidService( 6923): at com.mba.proxylight.RequestProcessor$1.run(RequestProcessor.java:246)
05-02 09:56:47.496 E/ProxoidService( 6923): at java.lang.Thread.run(Thread.java:1058)
05-02 09:56:47.496 E/AndroidRuntime( 6923): Crash logging skipped, already logging another crash
05-02 09:56:47.496 E/OSNetworkSystem( 6923): unclassified errno 24 (Too many open files)
Huh. Too many open files. That would explain the non-response of Proxoid.
Googling for the offending line (org.apache.harmony.nio.internal.SelectorImpl.prepareChannels(SelectorImpl.java:223), yielded this: Selector leaks file descriptors in Apache Harmony. Yikes! Bad news.
The reporter of the bug in Android's issue tracker said:
Thanks for the quick answer. The workaround I used is quite simple: create as few
selectors as possible and recycle them endlessly.
I took a look at the Proxoid source and realized the error was fatal. A new selector is opened for each new request.
Its technically not a bug in Proxoid, but its awful to have to keep restarting Proxoid.
So I decided to hack a replacement proxy server implementation for Proxoid which uses threads instead of non-blocking IO. Took me 2 days to work everything out, and I ended up using some code from Muffin Proxy Server but it looks like things work fine. I tested my app out on 10000 HTTP requests (Proxoid barfed after about 1000) and no errors thus far. 
Android's clever workaround of Sun's licensing
Posted by Kelvin on 08 Apr 2010 | Tagged as: android, programming
Just discovered this gem here: http://www.betaversion.org/~stefano/linotype/news/110/
- Android apps are developed in Java
- Android itself is licensed in APL, but Sun's source is licensed in GPL.
- Furthermore, Java is not open-sourced in mobile environments.
- How did Google do it?
Turns out that Android
- Uses Java as a development language but does not use Java bytecode or Java virtual machine for deployment.
- Has a virtual machine called Dalvik which does not claim to be a JVM
- First uses a regular java compiler to generate regular java bytecode (say, javac or the built-in Eclipse compiler) and then converts that bytecode into Dalvik’s bytecode (the “dx” tool does this: converts .class/.jar into .dex files)
- Supports only a subset of Java SE (AWT/Swing and JavaME classes are omitted) classlib. Instead of using Sun's implementation, it uses Apache Harmony's implementation.
That's quite a tour de force.