libhoudini: What It Means for Developers

At AnDevCon last week, I found out about libhoudini, so while it is a bit of tech that has been around for a while, I suspect that other developers may have missed out on it as well.

libhoudini is a proprietary ARM translation layer for x86-powered Android devices. It allows an app that has NDK binaries for ARM, but not x86, to still run on x86 hardware, albeit not as quickly as it would with native x86 binaries.

Given ARM’s near-stranglehold on the Android ecosystem, libhoudini is hugely useful for Intel and hardware vendors interested in using Intel’s mobile CPUs. Without it, only apps that ship x86 NDK binaries would be compatible with x86-powered devices like the Samsung Galaxy Tab 3 10.1” tablet. Some developers probably skip x86 NDK binaries, because they are not aware of popular x86-powered devices, or lack one for testing, or are concerned over APK size. The Play Store for x86 would shrink substantially from the million-plus apps available to ARM devices, to those that do not use the NDK or happen to ship x86 binaries. libhoudini makes ARM-only NDK binaries usable on x86, giving x86-powered Android devices access to more of the Play Store catalog.

However, it is slower.

As an experiment, I ran the test suite for SQLCipher for Android on an ASUS MeMO Pad FHD 10, both with the x86 binaries and without. After all, some developers are nervous about using SQLCipher for Android for encrypted data stores due to the size of the library. Supporting x86 in addition to ARM adds another 5MB to the app, on top of the 6.5MB spent for ARM and the platform-neutral pieces. Being able to use SQLCipher for Android without the x86 binaries might be useful, particularly for apps bumping up against APK size limits, like the 50MB limit on the Play Store.

The good news is that SQLCipher for Android runs nicely on libhoudini-equipped x86 hardware, without the x86 binaries.

The bad news is that the test suite takes about three times as long.

Now, the test suite is not geared towards performance testing, nor is is necessarily indicative of the performance you would see in production code. Hence, you may wish to do your own testing. Testing is easy enough: just temporarily move the x86/ directory from libs/ somewhere else, then recompile and test on libhoudini-equipped hardware. If you do not have your own libhoudini-equipped hardware, you may be able to take advantage of services like Samsung’s Remote Test Lab, which recently added the Galaxy Tab 3 10.1 to its lineup.

If you have the space for it, include the x86 binaries for your NDK-compiled libraries. This will give you maximum speed for little incremental engineering cost. However, if space is at a premium, libhoudini may allow you to reach many of the same x86 devices, but be sure that your app will run acceptably given the performance overhead.