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
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
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
libs/ somewhere else, then recompile and test on
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.
Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!