WordPress clients are available for many devices, but since I’m an Android fan I get to use WordPress for Android.
Yesterday, I came across a bug report outside of the developer ecosystem, managed to reproduce the bug using the release version, and, decided to write and submit a patch to fix the bug.
The main WordPress for Android repository is over at GitHub. But as it turns out…
…one does not simply build WordPress for Android.
After tampering with a signed apk using tools like smali/baksmali or even apktool here are the steps to rebuild and resign the Android application (from application root):
keytool -genkeypair -alias androiddebugkey -dname 'CN=Android Debug,O=Android,C=US' -keystore /tmp/debug.keystore -keyalg RSA -validity 10000 generate a valid Android debug keypair (Signing in Debug Mode) with password ‘android’ for both the keystore and the keys
rm -rf META-INF if such exists
zip -9 -r out-unaligned.apk . to zip things up
jarsigner -sigalg MD5withRSA -digestalg SHA1 -keystore /tmp/debug.keystore out-unaligned.apk androiddebugkey sign it
zipalign 4 out-unaligned.apk out.apk align it
keytool -printcert -jarfile out.apk check it
adb install -s out.apk install it (you may need to uninstall a previous version of the application in case of certificate errors
If you ever played around with the adb shell you may have found that the ps utility, which lists process lists, is not as verbose as you would expect it to be. And, to make things worse, there’s no inline help or man entries. Here’s the ps utility usage line: ps -t -x -P -p -c [pid|name].
-t show threads, comes up with threads in the list-x shows time, user time and system time in seconds-P show scheduling policy, either bg or fg are common, but also un and er for failures to get policy-p show priorities, niceness level-c show CPU (may not be available prior to Android 4.x) involved
[pid] filter by PID if numeric, or…[name] …filter by process nameAndroid’s core toolbox (shell utilities) are more primitive than the ones you may be used to. Notice how each argument needs to be separated and you can’t just -txPc it all, the command line argument parser is non-complex.
It’s a pity how command line arguments are not shown. If you need something that’s not available by the stock ps shell utility, try manually combing through the /proc directory. For the command line one would do cat /proc/<pid>/cmdline.
There don’t seem to be many reasons to want to forward a local Android port (listening for connections from localhost only) to a port that can be accessed externally (via LAN, etc.). There are some applications around that allow to forward an Android local port to another one but they offer a lot of overhead, are confusing and some even require root access.
Compiling netcat for Android was the way I decided to go, it’s only known to be the “swiss-army knife” of networking. The Android source code contains a limited version of nc which can be compiled by the simple make nc (after having setup the build environment of course). This version of netcat does not offer port forwarding functionality.
Continuing into Command Line Android Development (last week I did a piece on Command Line Android Development: Basics), today I’d like to go over some of the techniques that allow for debugging applications from the command line.
I personally have a distaste towards IDEs, preferring lightweight solutions, with maybe less convenience. I addition to saving resources and having direct control over what happens and what doesn’t, I find that by doing things the low level way you begin to better understand how things work.
Sure, Eclipse will let you debug in 2 clicks, but what do you learn besides that you application has a bug? There should always be time to learn a thing or two about the underlying technologies. What if one day, you have to SSH into a server and debug a Java application right there and then? If you’ve never seen anything beyond Eclipse in your life you’re in for some hair pulling. So let’s learn some low level stuff.
Although the Android ADT plugin in Eclipse provides some of the fanciest and most convenient development tools, with its graphical interfaces for resource editing, for one, and the million and one Eclipse IDE features on top of it all, I prefer to handle things at a lower level. There’s much more to learn from hitting the docs than to hit “Import missing packages” and “List override methods”, isn’t there?
