Before you install, you might want to read more about the kernel’s features and design goals in my post about the S kernel. The Optimus V is not identical to the S (there are a couple of minor hardware differences between the phones, such as swapped Home and Menu buttons), but unlike some other kernels released for the V (such as ports of Xionia), mine is not a ported S kernel, it is a native V kernel. So, it is a drop-in replacement for the stock LG kernel.

If that didn’t make sense (“I thought you said to read about your kernel for the S, what gives?”), I’ll put it another way. Think of my kernel only as a changeset to the original (add overclock, add interactive cpu scaling, add TUN/TAP network and EXT filesystem drivers as modules; subtract debugging, ethernet and other unnecessary bloat; build the whole thing with a better toolchain). The S kernel is that changeset applied to the official LS670 sources from LG. The V kernel is that changeset applied to the official VM670 sources.

The end result is a kernel that is perfect for your Optimus V running either the stock OS or any LG-based ROM — that means, at present, Android 2.2.x or Froyo-based ROMs. But not perfect for Cyanogen or other Gingerbread/Android 2.3-based OSes. Just like you shouldn’t run a Gingerbread/2.6.35.7 kernel on a Froyo-based OS, you shouldn’t run this Froyo/2.6.32.9 kernel on a Cyanogen-based OS. Got it?

Of course, that’s just for now. As soon as LG does its official release of Gingerbread/2.3 for these phones, I’ll update this kernel from the new official sources.

Get it

This kernel has survived its initial shakedown on the Android Central forums, but if you choose to install it, the standard disclaimers apply: No warranties expressed or implied, it’s your responsibility to understand exactly what you’re doing, so if you kill your phone I assume no responsibility.

Requirements: To start with, you’ll need to have rooted your phone. You’ll also need a custom recovery. I’ve used koush’s AnyKernel template to package the .zip, so you should be able to flash this kernel over top of the stock LG OS or any custom ROM.

So, if you understood all of that, the rest should be easy. Download picasticks kernel picasticks-07a.zip, copy it to /sdcard/, reboot your phone to your custom recovery, and flash the .zip. Reboot and enjoy!

Home and Menu keys: These hardware keys are mapped by the kernel, but the mappings can also be reassigned in the file thunder_keypad.kl. If you have previously installed a custom ROM/kernel on your V, chances are that it contained an incompletely ported S kernel with the keys swapped, and this bug “fixed” by reswapping the key assignments in the thunder_keypad.kl keymap. My kernel, built for the V, doesn’t require this hack. So, my .zip installer includes a script that checks for a swapped mapping, and if found, replaces your keymap file with an original, unmodified copy. It should only do this if it finds the Menu key (139) incorrectly mapped to Home, but ignore other custom key assignments. In any case, if you’re concerned about your customized thunder_keypad.kl being overwritten, just back it up before flashing the kernel.

Source code

As we have learned from LG, source code release is an important part of distributing software covered by the GPL!

I’m not going to publish a giant tarball (yet) since it’s 100% LG source + my changeset, which I’ve made into a single patch. Therefore, to duplicate my build source:

1. LG source code is here (search for “VM670″ to get Optimus V source).
2. Apply this patch to the kernel tree, i.e.: cd lg_kernel && patch -p1 < kernel.diff

And here are my changes to the LG kernel configuration .config.

Both patches, by the way, are the same as the ones I'm using for the S, so these links are to the same files (that's what I meant earlier about applying the same changeset to both kernels!).

For more information and full credits, see my original post.

Changelog

07 released 2011-04-18

Adds ext2/ext3/ext4 filesystem drivers as modules. Includes original Optimus V keymap file thunder_keypad.kl and script to check the phone's current keymap for swapped Home/Menu keys and, if found, replace with the original.

06 released 2011-04-14

Initial public release for Optimus V (no known bugs or issues).

So, all is well in this small corner of the open-source world. I’ve downloaded the new source code (labeled “LGVM670(Thunder) Android Froyo/kernel bugs were fixed” on LG’s download site), and verified that the fixes were made and that the new code builds cleanly.

In case you’re interested in the differences between the Optimus S and Optimus V (LS670 and VM670, respectively), here’s a diff of the kernel sources that I’ve made.

They’ve also left out 15 files that are part of the Linux kernel’s netfilter and needed to build the kernel as configured by LG.

Update: LG has fixed the bugs, so keep reading only if you’re interested in the details.

I’ll detail the problems and explain how to (possibly) fix them below. However, the real issue is that the LG archive is broken as-is, so there’s no way it was used to build the actual Optimus V kernel. While I’m no GPL expert, it seems to me that LG is obligated to provide actual, working source code upon request, not an incomplete, broken fork. Let’s hope this was just an oversight, and one that LG will rectify.

What I found

Basically, I downloaded the VM670 source from LG’s open source code distribution site and tried to compile it, just as I have several times for the LS670. It’s worth noting here that, while the Optimus series is a popular model worldwide, with U.S. models including the T, U, M and Vortex, the S and V are particularly close because the V is based on the slightly older S, and both run on Sprint’s 3G network. They’re virtually identical, and it’s obvious from the source code that the VM670 code is derived from the LS670 code.

The first build error came on drivers/net/wireless/bcm4325/src/dhd/sys/dhd_sdio.c:

  CC [M]  drivers/net/wireless/bcm4325/src/dhd/sys/dhd_sdio.o
cc1: warnings being treated as errors
drivers/net/wireless/bcm4325/src/dhd/sys/dhd_sdio.c: In function 'dhdsdio_dpc':
drivers/net/wireless/bcm4325/src/dhd/sys/dhd_sdio.c:3997:1: error: ISO C90 forbids mixed declarations and code

Check out this diff and LG’s comment-scrubbing is clear. The block at line 3933 is where they accidentally deleted a closing brace. Putting the brace back in is easy enough.

Next:

  CC [M]  drivers/net/wireless/bcm4325/src/bcmsdio/sys/bcmsdh_sdmmc_linux.o
drivers/net/wireless/bcm4325/src/bcmsdio/sys/bcmsdh_sdmmc_linux.c: In function 'dhd_register_hwakeup':
drivers/net/wireless/bcm4325/src/bcmsdio/sys/bcmsdh_sdmmc_linux.c:725:2: error: expected expression before 'if'

Again, code-comment scrubbing caused an error. In the block at line 772, a function call spanning multiple lines is cut off. Again, easy enough to put back.

Finally, these 15 files relating to the Linux kernel’s netfilter code were all missing (apparently because the source code archive was made on a case-insensitive filesystem) in the VM670 source code, each time causing the compile to fail:

include/linux/netfilter/xt_connmark.h
include/linux/netfilter/xt_dscp.h
include/linux/netfilter/xt_MARK.h
include/linux/netfilter/xt_RATEEST.h
include/linux/netfilter/xt_tcpmss.h
include/linux/netfilter_ipv4/ipt_ECN.h
include/linux/netfilter_ipv4/ipt_TTL.h
include/linux/netfilter_ipv6/ip6t_HL.h
net/ipv4/netfilter/ipt_ecn.c
net/netfilter/xt_CONNMARK.c
net/netfilter/xt_dscp.c
net/netfilter/xt_hl.c
net/netfilter/xt_MARK.c
net/netfilter/xt_rateest.c
net/netfilter/xt_TCPMSS.c

In the end, I was able to build the kernel by restoring these files from the LS670 source.

Unfortunately, even though it compiled, it’s quite possible that my kernel is not the same as the official kernel (if the VM670 netfilter code is different, or if other code is broken in a way that doesn’t raise an error). The only thing that is certain is that LG’s production kernel couldn’t have been compiled from this source code.

Time to contact LG

After I wrap this post up I’ll try to contact LG to see if they’ll fix the source code release, and report back here. (If you actually know anyone at LG who could help, please tell me!)

It’s worth saying here that LG isn’t under any obligation to provide end-user support, or to include their code comments. I don’t expect any of that (although they may find that it’s easier just to distribute the unmodified code, including comments, than to fix the bugs in their comment-scrubber). However, if they do strip code comments, they ought to have a build system that works like this:

source code -> strip comments -> compile

rather than:

source code -> compile -> strip comments

to ensure that they distribute correct source code. That way, LG wouldn’t even have to test the separate, comment-scrubbed branch to see if it works (which they clearly failed to do in this case), because they’re always building from that branch.

Obviously, LG isn’t fully complying with the GPL (version 2.0 of which covers the Linux kernel) by supplying wrong source code, but on the other hand, these errors are minor and appear to be unintentional. I’ve been complimentary of LG in the past, and hopefully this is just an oversight on their part. We’ll see if I get anywhere.

Update: And I did, for once! Kudos to LG for addressing the issue so promptly.

My Android phone, the LG Optimus S, is only a few months old, but its ARMv6 processor isn’t supported. There’s a faint glimmer of hope there, but with the ARMv6 test builds already pulled, I’m not holding my breath. In the meantime, the stock Android browser and Opera Mobile are both great (Opera’s font rendering needs work in the hinting/character spacing department, but that’s it).

Meanwhile, my Powerbook G4 is still running happily along on OS X 10.4 Tiger, so I was happy to find the answer to my Firefox 4 woes in TenFourFox, a Firefox fork with builds optimized for various G5, G4 and G3 processors. Here’s a mini-review of my impressions after a week, and a look at what’s coming up in browser-land for those of us clinging proudly to the last generation of PowerPC Macintosh computers.

Introducing TenFourFox

First, let me point out that TenFourFox is a free, open-source project, and one unbacked by the deep pockets of the Mozilla Foundation and their Googlebucks, so let me thank the developer for this volunteer effort.

The good news is, TenFourFox is a big upgrade over Firefox 3. (So if you’re a Firefox user, check it out!) The two major complaints I have — UI tearing and crashes — are both caused by Adobe’s badly aging, abandonware Flash plugin for PowerPC. These are long-acknowledged issues, and the plan (partly forced because of upstream changes to Firefox) is to preference all plugins off by default in the 4.1 version.

Also, I have to say, the name is terrible. I’d love SilverFox, tolerate OlderFox, and, honestly, even prefer the mocked IceWeasel.

Other than that, it’s all good news, and getting better in the short term. TenFourFox’s JavaScript performance tested 3x faster than Safari or Opera 10 on my Mac, thanks to a custom PPC-native JIT (see graph on the homepage for full breakdown). All my Firefox 4-compatible extensions upgraded and worked flawlessly. Browser rendering and passes with flying colors. All of this, despite a number of not-insignificant architectural changes under the hood to be Tiger-compatible.

Coming soon is AltiVec-accelerated WebM video, and it’s looking good so far for TenFourFox to be able to keep up with Firefox’s new “rapid-release” schedule through at least the fully awesome Firefox 5 this summer.

What’s left for PowerPC Macs?

There are still a couple of decent browser alternatives for the PPC faithful. Opera 10 is only six months old, and it’s easily the next-best (or the best, if you’re a fan of Opera features like Opera Unite, syncing and long-beloved mouse gestures) and supports WebM and other emerging standards. Unfortunately, with the recent release of Opera 11, it joins Safari as abandonware for the PowerPC platform. Safari on PPC (along with its WebKit-bundling brethren iCab and OmniWeb) is usable at the moment, and it’s my browser du jour, but it’s in maintenance mode and goodies like WebKit2 aren’t in its future for PPC.

I’ve long been a fan and user of Camino, but it’s always badly lagged Firefox in terms of updating the underlying Gecko rendering engine. Version 2.1, due later this year, will bring it up to parity with Firefox 3.6, but with the end of Mozilla support for embedding Gecko, that’ll almost certainly be the end of Camino on PPC Macs.

Long-term, all of these abandoned products will grow even more out of date and — even for those who can do without new features or support for new web standards — insecure as well. Already, Flash is a problem no matter what browser you use.

Even TenFourFox expects to face serious challenges building a browser from the Mozilla codebase as soon as later this year, depending on how quickly Mozilla drops support for old APIs like Carbon. But, the developer is looking well ahead, and hopes at minimum to backport security fixes going forward.

So, I encourage you to take a look at TenFourFox. If it isn’t already the best browser for PowerPC Macintosh, it soon will be.

We all know the end is coming for our Power Macs — you know, the day when you either realize you’re part of an old-computer cult like Amiga and 68k Mac fans, dump MacOS for PPC Linux, or just break down and buy a shiny new Mac — but that doesn’t mean they have to go before their time is up.

The basic idea behind this kernel build is “stable performance” — other devs are doing a great job backporting the latest features from the mainline Android kernel and writing experimental patches. My goal is a lot less ambitious, but also less bleeding-edge: Build a kernel from official source, one that “just works” for me the user, but boost performance to get the most from the hardware.

I’ve also included the Linux TUN/TAP driver as a module, so that (among other things) you can use OpenVPN with your Optimus, if you like. Need some other module? Ask!

Features

• Uses current (2.6.32.9 Linux kernel for Optimus S with VD baseband) LG source code for simplicity and maximum compatibility. See “design goals,” below.
• CPU frequency scaling beyond 600 MHz (i.e. overclocking). By default, I’ve upped the maximum clock speed to 748 MHz, but you can enable higher speeds (and test them) using trusty SetCPU. At 748 MHz, SetCPU benchmarks run 20% faster.
• Adds the new “interactive” CPU frequency scaling governor for a more responsive UI. (The easiest way to use it by default is to have SetCPU select it on boot … or you can edit init.qcom.post_boot.sh in your boot.img ramdisk.)
• Removed a lot of unneeded debugging/development features, such as Ethernet, kernel debugging, debugfs etc. The end result is a kernel that’s 380K smaller than LG’s (2.2M vs. 2.6M).
• Minor performance tweaks (removed highmem etc.).
• tun.ko compiled as a module, since I use it for OpenVPN. Version 07 adds Linux ext2/ext3/ext4 filesystem drivers as modules. Future releases can include additional drivers as modules, if there’s interest.

Get it

I’ve been running variants of this kernel for a couple of weeks, and it works for me (so far), but if you choose to install it, the standard disclaimers apply: No warranties expressed or implied, it’s your responsibility to understand exactly what you’re doing, so if you kill your phone I assume no responsibility.

Requirements: To start with, you’ll need to have rooted your phone and installed a custom recovery. The kernel is compiled from LG’s LS670ZVD kernel source, so be sure your phone is updated to the VD baseband. I’ve used koush’s AnyKernel template to package the .zip, so you should be able to flash this kernel over top of the stock LG OS or any custom ROM.

So, if you understood all of that, the rest should be easy. Download picasticks kernel picasticks-07.zip, copy it to /sdcard/, reboot your phone to your custom recovery, and flash the .zip. Reboot and enjoy!

Design goals

Over the years I’ve built many, many Linux kernels, but I’m new to the Android kernel. I started because I wanted to compile essentially a stock kernel, and add TUN/TAP support. Then, I found that LG’s developers had left behind unnecessary debugging and debug hardware support (i.e. Ethernet and serial consoles via USB) worth taking out. (Housecleaning is the inevitable result of “make menuconfig.”) Next, I decided to enable overclocking past 600 MHz, since it had worked fine for me with various versions of ThundeROM and the Xionia kernel that supported it. Finally, I added the interactive CPU frequency scaling mode.

That leaves us with the following project principles:

• Build from the most current official LG source. Reliability and stability are the goals — I’ve had this phone for four months, and LG has updated the OS in three of them, so I don’t want to get into the maintenance nightmare that constantly remerging the latest upstream Android source would entail (for now). If you want to flash a new kernel every week, mine’s not for you, because I may not release again until LG does. So, I give up things like the BFQ scheduler (no biggie, Deadline is faster on Android) and interactive scaling (this one I miss, but ondemand is OK) (Update: interactive scaling backported!). Likewise, in my kernel configuration I’m trying to only deviate from the LG config when it’s an obvious win. Another part of reliability and stability is, don’t expect me to push a new release the same day LG publishes updated source — it’ll be more like a week (you know, for testing). Think of me as somewhere in between Gentoo and Debian-stable.
• Keep it small. Faster is better. That doesn’t mean I’ll be dumping SLAB for SLOB just to get a small binary, but my assumption is that you don’t need debugfs, or you’d be compiling your own kernel. I’m happy to add things as modules, so if you want CIFS or something to stream music off your LAN, let me know, but in general the simpler the better. (Personally, I want to get bluetooth HID, i.e. Apple bluetooth keyboard, working, but the userland part scares me, so I may have to give up my dream of typing 120 wpm in WordPerfect 5.1 on my phone, and go back to Angry Birds.)
• Overclocking, since it seems to work well and my phone is pretty new, so I’ll be stuck with it for a while, but it isn’t exactly a screamer.

Credits and source

Many thanks to the Android hackers and developers who have come before me, for making my learning curve much easier.

Full credit on overclocking goes to zefie. My patch to arch/arm/mach-msm/acpuclock.c is 99% cribbed from his changes to the LG V9 source.

Credit to Mike Chan (who’s since left Google) for backporting the interactive CPUFreq governor.

Thanks to LG for not just publishing source code (GPL requirement) but also including docs and a build script. Unlike another phone OEM with a patent-encumbered fruit for a logo, LG you give me a happy feeling, and it is not just from your smiley logo. You could have published your readme in Korean (which would not have worked, I live in a Korean neighborhood!), but you chose not to.

For my source code release, I’m not going to publish a giant tarball (yet) since it’s 100% LG source + the aforementioned patches to enable overclocking and the interactive governor. Therefore, to duplicate my build source:

1. LG source code is here (search for “LS670″ to get Optimus S source).
2. Apply this patch to the kernel tree, i.e.: cd lg_kernel && patch -p1 < kernel.diff

And, in case you’re interested, here are my changes to the LG kernel configuration .config.

Changelog

07 released 2011-04-18

Adds Linux ext2/ext3/ext4 filesystem drivers as modules.

06 released 2011-04-08

Code/config identical to 05. Recompiled with CodeSourcery toolchain including gcc 4.5.1. Improved DEFLATE compression using 7zip algorithm.

05 released 2011-04-03

Reverts RCU method to tree-based from preempt tree-based to fix lag issues with memory locking, for instance when network interfaces are brought up or down. Other minor regressions in kernel config.

04 released 2011-03-31

Initial public release using LG VD source.

The good news is, I think I’ve found the one true method. The bad news is, it still uses 3 programs. But, just like last time, the commands are short and sweet, and it’s easy to throw them into a shell script.

To summarize from before, we want to:

• Losslessly join multiple files together (no re-encoding).
• Correctly copy metadata (ID3 tags, including cover art etc.) to the final file, while stripping the metadata of the other input files (i.e., we don’t want to just do cat 1.mp3 2.mp3 > all.mp3 and end up with leftover tags in the middle of the MPEG data stream).
• Either remove the VBR (aka Xing) header or else correct it so that file duration is correct and seeking works in iTunes and on iPods, among others.

So, what’s new? The old way produces a file with no VBR header, while the new way corrects the VBR header. Should you care about this? Well, if you ask me, this Xing header should go the way of the company that spawned it back in the 1990s. But, until then … both files work the same in i(Tunes|Pod). There are some other programs (VLC is one) that display the wrong file duration with the old method, although playback and seeking aren’t affected.

I think the internals of the file created by the new method are cleaner, and including the VBR header can improve seek performance. But for you, the choice might only come down to which set of utility programs you’d rather use.

The revised method

First, we use mp3cat, which takes a bunch of mp3 files and joins their data frames together, dumping everything else. Then, like last time, we’ll use id3cp from id3lib to copy the metadata we want onto the joined file. Finally, VBRFix will re-sync the VBR header to the actual size of the resulting file.

In this example, 1.mp3 and 2.mp3 are merged into all.mp3, and metadata is copied from 1.mp3:

cat 1.mp3 2.mp3 | mp3cat - - > tmp.mp3
id3cp 1.mp3 tmp.mp3
vbrfixc --XingFrameCrcProtectIfCan tmp.mp3 all.mp3 && rm tmp.mp3

That’s it! I’ve tested this on both a Linux system and my trusty Powerbook, so it should work on any reasonable *nix.

Some tips: You can also use mp3cat to operate on a directory of files. The command-line version of VBRFix is a little hard to find (I did an svn export of the source, then ran setupNonQtBuild.sh). I also tried mp3tool for this purpose, and while iTunes liked the result end, VLC displayed an incorrect file duration.

Let me know what you think.

First, a few links: This is a good intro to kernel building (although you’ll want to get the kernel source code for your actual device, in my case from LG). Here’s a great walkthrough of the entire process of grabbing your device’s config, building and repacking (caveat: it’s for a specific device, so don’t use his mtd layout or base address setting without checking yours first). Finally, a better explanation of unpacking and repacking boot images that’ll clear up the aforementioned caveat.

Running split_bootimg.pl on a boot image pulled from your device will tell you what parameters to use with mkbootimg. But what about the base memory address? If you’re lucky, it’s in a technical spec or posted in a forum, and Google will turn it up, but for my device, that didn’t work (and if it had, forum posts that only say “use this number” would have left me wondering why).

The answer

The answer is going to be in the kernel source (either in the config, or hardcoded) for your device’s cpu. So, arch/arm is the place to look.

I’ll skip to the end: grep for PHYS_OFFSET and that should find your answer.

In my case, LG uses a kernel config variable, CONFIG_PHYS_OFFSET, to set PHYS_OFFSET. LG’s build system separates out various cpu- and model-specific kernel configuration parameters, which I found in arch/arm/configs. If you’ve got an LG device, your model-specific config is there.

LG’s README for my phone says to make thunderc-sprint-perf_defconfig before building the kernel (My phone, the Optimus S, is thunderc), so its config is in the matching arch/arm/configs file thunderc-sprint-perf_defconfig. And, that’s where the default value of CONFIG_PHYS_OFFSET for my phone is actually defined: 0x12200000. Hooray!

Of course, I didn’t even know I was looking for PHYS_OFFSET at the time, I was just looking for anything that looked like a memory address. For you, it should be much easier, and it shouldn’t matter whether your kernel source is organized like LG’s or not. Just grep all of arch/arm for PHYS_OFFSET and that should lead you to your base address.

The best part is, once I had my answer, Googling for “12200000″ returned all sorts of useful info, if I’d only had the solution to start with. The kicker is that, had I only read the very same forum thread I linked above all the way through, I would have found more than enough info to track down the answer!

Sort of like, if you want to know the meaning of life and you Google for it, you turn up all sorts of garbage. But once you know the answer is 42, the question is easy to find.

Which, now that I think about it, is basically how Watson works. But that’s going way off topic.

While we’re at it

Can’t leave without mentioning one of my favorite hobbyhorses, compression. When you’re gzipping your ramdisk (or almost anything else you’re just zipping once like this), use “gzip -9“!

(And then, if you’re a nut like me, advdef -z -4 to deflate the resulting file a few percent more.)

Not that it makes a huge difference in the case of the ramdisk (39K saved in my 863K gzipped ramdisk), but I’ve read umpteen posts on the subject in the 24 hours, and nobody does it. The “-9″ is only 3 extra characters to type!

So many Android ROM packagers like to say how many megabytes they’ve shaved off the stock OS to free up space in /data, but then their APKs are all zipped with default settings.

I recompressed my APKs with the 7z deflate algorithm (either use 7z to make your .zips, or advzip -z -4 them) and freed up 9 MB just in /data/app (or 12%, I started with 76 MB). That’s 9 MB for free, on my /data which had only 35 MB left.

Sure, anybody can do this, but it’s not the user’s job to re-zip their apps. Android developers, you can do better!

Google also removed the bad apps from the Android Market, contacted law enforcement, and is pushing a security update to protect devices’ identification codes. Needless to say, these are all good moves, and unlike some privacy advocates I’m not going to quibble with Google’s remote app removal power as long as it’s being used conservatively, in a security context, as in this case. Analogous to public health or combatting botnets, Google must be able to wipe malware from people’s phones to protect everyone, not just the infected.

What does bother me about this news is that these applications appeared in the Android Market at all, where they were available for some time before being reported to the Android security team. I’ve owned an Android phone for a couple of months now, so I thought I’d weigh in on one of the sad realities of the experience: I find myself increasingly worried about security, certainly more so than I have been about any personal computing device since the last time I ran a Windows PC 10 years ago.

An attacker’s dream

Think about it from an attacker’s perspective: Any smartphone is a ripe target. Android has built-in APIs for accessing all of my contacts, email, call and text history, credit card and even physical location. That’s information I’ve never even stored on any computer or other device I’ve ever owned, let alone one that’s Internet-attached, and thinking about someone stealing it is pretty freaky.

There are a lot of reasons to hate Apple’s App Store, but having a manual app review process looks pretty good when you think about the security implications, and when you compare the App Store’s security record with Android Market. The way average people use the App Store, browsing and installing things like it’s a shopping mall, is just not safe or smart on the Android Market (which much more resembles a shopping street in a dicier part of town).

Instead, when searching for an Android app, I find myself approaching it with the same fear and trepidation I would when evaluating whether to install a program on my computer from the web, which I try not to do. I make sure it’s from a trusted source, and if it isn’t, I make sure to read about it on a couple of familiar sites to make sure it’s legit. That’s still no guarantee the software is benign, but sometimes it’s the best I can do. When you’re browsing the Android Market, having to step back and do all this background work before tapping “install” is a major pain. Do I enjoy it? No. And I’m sure that the vast majority of people out there don’t bother.

If Google isn’t going to do a seriously good job of security on Android Market, then the market in the end is a huge disservice to users, because you’re getting the Google seal of authenticity and easy one-tap install for things you shouldn’t be installing. You’d be better off with no app market, just browsing the web and deciding what to install on your own — at least then basic intuition (“nope, this looks shady, better ask my techie friend”) and phishing defenses like checking the browser address bar would kick in.

Yes, Google has done a much better job of sandboxing and creating a secure OS. Yes, I still prefer Android (recompiling the kernel, doing any Linux stuff I want, it’s awesome) to the alternatives. Yes, there haven’t been any serious infections in the wild and there isn’t a known propagation model for malware (elective downloads in the Android Market aren’t going to spread anything far before it’s discovered, as in this case). But, threat assessment and vulnerability assessment are two different things: Just because few attackers have bothered so far doesn’t mean the vulnerability isn’t there, and as Android’s install base grows the incentive to devise more ingenious attacks grows as well.

I haven’t put any active-monitoring security software on my phone … yet. But, I probably will, and eventually Google will come around as well. It’ll probably be something along the lines of what Microsoft has done with Windows Defender (signature-based antivirus and memory access monitoring). Encrypting sensitive data (both on disk and in RAM), or all data by default, would be another win. It’s easier said than done, because securely managing the keys is hard to do in a user-friendly way, but worth doing.

Just expecting users to “be careful” isn’t enough.

What next?

The first step is for Google to “fix” the Android Market — to do serious work on its automated app review. Google has the tools — I love Courgette, which does binary diffs of partially disassembled binaries for updating Chrome — so they must be able to figure out a way to red-flag malware like this that is basically 95% a clone of an existing (legitimate) app. That would be an important anti-piracy measure as well. (Who knew you could just copy and republish an existing app the the market?)

I love that Android Market is more permissive than Apple’s App Store — what I don’t want is Apple-style censorship, for instance of apps that compete with Apple products — but a combination of better filtering and improved UI will add security without hurting users or developers. Crowdsourcing app review to users can work, but the bare-bones way Android Market uses and displays this data needs improvement.

Handset and other device manufacturers need to get on board as well, because Android device fragmentation has serious security implications. In this case, Google is pushing a security update to affected devices (Android versions prior to 2.2.2), but how many people with older phones will ever get it? And of those few who do, how long will it take for their handset’s manufacturer and wireless carrier to integrate and push the patch?

Microsoft and PC OEMs figured this out long ago: OEMs may add custom skins, application launchers, demos and other crapware to PCs, but the underlying OS is left alone and talks to Microsoft for updates. And Linux distributions have long since figured how to do the same thing, but on multiple architectures and with decentralized software mirrors — a great model for Android, its OEMs and carriers to follow.

Google and its OEMs need to address these problems sooner rather than later, because they’re playing with borrowed time. If users’ first experiences with Android are bad, they’ll go back to Apple, webOS or Blackberry. Or if attackers hit on the right distribution mechanism — or adapt an old one, like “spam links to malware in the Android Market, take over an address book, and repeat” — the platform could be massively compromised.

For now, Android users like me will just have to be careful

Now that you’ve got tun.ko

I’m not going to get into the basics, like installing the Android SDK on your computer, connecting via the adb shell, rooting your phone and flashing it with custom software. Here’s a great guide for that (pay attention when you do things like remounting the filesystem rw, because you’re going to have to do that before you can write to /system).

I started with my phone running ThundeROM 1.6 (already updated to 1.6.2 and probably updated again by the time you read this), the first version to include a recompiled kernel with tun.ko. (You could also choose to install just the Xionia kernel atop your stock software, compile your own kernel, or reflash with X or Y … but from here on out I’ll keep it simple and just diary what I did.)

Update 2/2011: Having now repeated these steps for ThundeROM 1.6.2 and now VCRom (which supports the Optimus updated to the VC baseband), you shouldn’t have any trouble following these directions with a slightly different configuration. One tip: When symlinking to route and ifconfig in the second step, be sure to symlink to wherever they actually are on your phone (VCRom puts them in bin instead of xbin).

What I did

1. First, I installed two apps via the App Market that make it easy to install a precompiled openvpn binary on your phone and then manage your OpenVPN connections: OpenVPN Installer and OpenVPN Settings. I used the installer app to install the openvpn binary into /system/xbin.
2. Unfortunately, this binary has hardcoded paths to route and ifconfig (it expects them to be in /system/xbin/bb), and on my phone (ThundeROM 1.6) these commands are in /system/xbin. So, I worked around this with a couple of symlinks. Connect to your phone using adb shell, remount /system read-write, create the directory /system/xbin/bb, and create symlinks in it to your route and ifconfig. (If you skip this step, you’ll figure this out later the way I did: I ran openvpn via the shell and saw it connect happily to my VPN, but then fail to add any routes to the system.)
3. Next, you’ll need to copy your OpenVPN config file and keys onto your phone. I won’t go into configuring an OpenVPN connection here, but all I had to do was take a working client config file (the same standard config I’m also using on Linux, Windows and Mac machines), keys and CA and drop them into /sdcard/openvpn. So, if you’ve called your connection “client1,” you’d be copying client1.conf, client1.crt, client1.key and ca.crt into a folder called openvpn on your SD card.
4. If you like, you can skip this step. But, what I did next was connect via adb shell and test out my connection. First, I did insmod /system/lib/modules/tun.ko and then lsmod to make sure the TUN module loaded. Then I connected to my VPN:

   cd /sdcard/openvpn
   /system/xbin/openvpn --config client1.conf

   Assuming it works, you should see lots of happy output. If you want, leave the connection open, connect via another shell, run ifconfig to verify that the TUN device has an IP address, and ping your VPN. Hit F4 to close the connection when you’re satisfied.

5. Last, you’ll want to set up OpenVPN Settings to manage your VPN connection so you won’t have to start/stop it from the shell. In my case, OpenVPN Settings auto-detected the VPN config I’d put in /sdcard/openvpn, but you can change this location through the Advanced settings if you need to. My settings are:

   Load tun kernel module

   checked

   TUN module settings

   Load module using

   insmod

   Path to tun module

   /system/lib/modules/tun.ko

   Path to configurations

   /sdcard/openvpn

   Path to openvpn binary

   /system/xbin/openvpn

   Fix HTC Routes

   unchecked

   Show Ads

   checked

From here, you should be good to go! Just tap your connection in OpenVPN Settings whenever you want to connect to your VPN.

The error message in question looks like this:

[android-sdk-linux_86]$ tools/android
Starting Android SDK and AVD Manager
No command line parameters provided, launching UI.
See 'android --help' for operations from the command line.
Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-gtk-3550 or swt-gtk in swt.library.path, java.library.path or the jar file
	at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
	at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
	at org.eclipse.swt.internal.C.(Unknown Source)
	at org.eclipse.swt.internal.Converter.wcsToMbcs(Unknown Source)
	at org.eclipse.swt.internal.Converter.wcsToMbcs(Unknown Source)
	at org.eclipse.swt.widgets.Display.(Unknown Source)
	at com.android.sdkmanager.Main.showMainWindow(Main.java:292)
	at com.android.sdkmanager.Main.doAction(Main.java:276)
	at com.android.sdkmanager.Main.run(Main.java:99)
	at com.android.sdkmanager.Main.main(Main.java:88)

There are lots of reasons you could be seeing this exception — such as not having SWT installed at all! In my case, Java wasn’t finding SWT even though I was 100% sure I had installed Eclipse, the JDK and all the SWT libs correctly.

It turned out that the SWT shared libs were being copied to /tmp but because I’d mounted /tmp to a separate partition that’s mounted noexec,nosuid,nodev (an age-old UNIX security practice), they couldn’t be executed. Incidentally, the files in question are these:

[android-sdk-linux_86]$ ls /tmp/swtlib-32/
libswt-gtk-3550.so  libswt-pi-gtk-3550.so

There may well be a better workaround, but my quick-and-dirty solution was to just edit the android/tools script and hardcode an alternate Java tmpdir (in this case, ~/tmp in my user directory). Just add a -Djava.io.tmpdir=/path/to/some/tmpdir to the last line in android/tools, so that it looks something like this:

exec "$java_cmd" -Djava.io.tmpdir=/home/sticks/tmp -Xmx256M $os_opts $java_debug -Dcom.android.sdkmanager.toolsdir="$progdir" -classpath "$jarpath:$swtpath/swt.jar" com.android.sdkmanager.Main "$@"