Boost for Android is a compatibility matrix and two build scripts

The project compiles Boost, it does not wrap it

Boost for Android is a set of tools to compile the main part of the Boost C++ Libraries for the Android platform. The wording main part is doing deliberate work, and it matters for anyone expecting a complete Boost distribution on a device.

The upstream Boost project is a large collection of libraries, and several of them are not portable to a mobile platform at all, because they depend on POSIX facilities Android does not have, or on a desktop threading model. A build for Android therefore selects the subset that compiles, which is what the main part refers to. The libraries that do get built are the ones a C++ application would actually use on a device, the string handling, the container and algorithm headers, the smart pointer and the filesystem-adjacent pieces.

The alternative to this project is compiling Boost yourself with b2, the Boost build system, against the NDK toolchain. That is possible and people do it, but it means working out the right toolchain file, the right STL choice, the right defines for a platform that Boost's own build system did not know about when those Boost versions were released. This project is the accumulated answer to that problem for a specific set of version pairs.

The repository layout says the same thing. There is no C++ source of its own, there is no library implementation. The top level holds build-android.sh, build-android.bat, build-common.sh, a configs/ directory and a patches/ directory, alongside .drone.yml, .github/ and the licence file. The primary language of the repository is listed as Shell, which is the honest description of a project whose deliverable is a build system.

The compatibility table is the whole specification

The centre of the README is a matrix with NDK versions down the side and Boost versions across the top, and a mark in each cell where that pair is known to build.

The rows start at r4, which is a customized NDK from Dmitry Moskalchuk aka CrystaX, then r5 from the official Android repository and r5 customized by CrystaX, and then r7 customized, r8 in its plain, b, c, d and e revisions from the official repository, r10, the r16 to r21 series with its b, c, d and e revisions, and r23 with r23b and r25 with r25b.

The columns run from Boost 1.45 through 1.91, with the intermediate releases listed in the text as 1.45.0, 1.48.0, 1.49.0, 1.53.0, 1.54.0, 1.55.0, 1.65.1 and then the 1.66 to 1.91 series.

The pattern in the matrix is not random. The early NDKs pair with the early Boost versions, because that is when the combination was actually tested, and the r16 to r21 rows cover a wide block of the 1.65 to 1.74 range, with r23 and r25 extending the coverage to the 1.76 through 1.91 block. The 1.55.0 column is in the text but not in the table header, which is a small sign of how the table is maintained: it is edited as pairs get tested, not regenerated from a rule.

For someone picking a toolchain, this table is the deliverable. It answers the question you actually have, which is not which Boost is best but which Boost and which NDK have been shown to compile together.

Two build recipes: clang with libc++, or gcc with gnustl

The README splits the build into two regimes, and the split is the second half of the specification.

x86, mips, and 64-bit architectures are built with Boost 1.65.1 and NDK r16-beta2, and this version uses the clang toolchain with the llvm libc++ STL library. Every other Boost version is built only for the arm architecture, and those use the gcc toolchain and the gnustl library.

That constraint has a direct consequence. If you are targeting an x86_64 or arm64 device, which is most modern Android hardware, you are looking at Boost 1.65.1 unless you are prepared to do the work yourself. The rest of the Boost versions, up to 1.91.0, are arm-only, and arm-only in the 32-bit sense.

The choice of STL is the reason the two regimes exist. The gnustl is the older GNU C++ runtime, and it is what the older NDK toolchains shipped. The llvm libc++ is the modern runtime, and it came with the clang-based NDKs. A Boost version built against one runtime is not linkable against the other without rebuilding, so the toolchain and the STL are not independent knobs.

The practical question for an integrator is therefore narrow. Do you need a specific Boost version, and which architecture? A project that needs Boost 1.80 on an arm64 device is not served by the table as it stands, and the answer is to run the build scripts yourself with a modern NDK and clang, and to accept that the result is yours to maintain.

Shell and batch scripts, a config directory and a patches directory

The build system is a set of shell scripts with a Windows batch equivalent, which is the shape you would expect from a project that has to run inside an NDK environment where the only guaranteed tools are a shell and the compiler.

build-android.sh is the entry point on Unix-like systems and build-android.bat is the Windows counterpart, and build-common.sh holds whatever the two share. The configs/ directory holds the configuration, most likely the b2 user-config or toolchain definitions that tell Boost's build system which compiler and which STL to use, and the patches/ directory holds patches applied to the Boost sources before compiling.

The patches directory is the part that tells you about the state of the upstream project. Boost versions from 1.45 to 1.91 span many years of releases, and the amount of adjustment needed to make them build against a modern NDK varies a lot. Some of those versions will not configure correctly for Android without a patch, either because their build system has no Android target at all, or because it has one that does not match how a modern NDK lays out its headers and libraries.

There is also a.drone.yml at the root, which is a Drone CI pipeline configuration, so the project is built automatically somewhere. The.github/ directory is present as well, and the README carries a GitHub Actions build status badge, so the two CI systems coexist.

The last push was on 2026-07-05, and there are no GitHub releases, so the deliverable is the scripts in the repository rather than a published artefact.

Where Boost for Android is the wrong tool

The first wrong-tool case is a modern project on a modern NDK. The table's coverage of recent Boost versions is tied to NDK r23 and r25, and the newest NDK rows shown are r25 and r25b. Everything since then, and every Boost release after 1.91.0, is not in the matrix. A team building a new app in 2026 with a current NDK and a current Boost is not served by the table, and the honest answer is to compile Boost with b2 yourself against your toolchain, which is a known procedure rather than a novel one.

The second is the 64-bit gap. Only Boost 1.65.1 is built for x86, mips and 64-bit architectures, and every other version is arm only. A 64-bit Android target, which is the majority of devices in use, gets the oldest Boost in the list unless you rebuild. A library that depends on a Boost feature introduced after 1.65.1 cannot use the prebuilt path at all.

The third is the licensing and maintenance shape of the patches. The project is MIT licensed, but the patches it applies to upstream Boost are a maintenance liability. They are tied to specific Boost versions, and when a new Boost release lands, the patches have to be re-derived, and until they are, that version is not in the table. The upstream Boost project is not going to accept patches for old release branches, so that work stays here.

The fourth is what the project actually saves you. If you need one Boost version on one architecture for one NDK, and you have b2 and an hour, you can do it. The project earns its place when you are producing Boost for several NDK and Boost combinations, which is what the matrix and the shared build scripts are for, and where re-deriving the patches each time would be the bulk of the work.

Editorial conclusion

Boost for Android fits a developer with an existing C++ codebase that depends on Boost and needs to build it against a specific older NDK, and it does not fit a team starting a new Android project that wants a current Boost and a current NDK. Before using it, check the NDK and Boost pair you need against the table in the README, since the matrix is exhaustive and stops at NDK r25b for the versions shown, and note that only Boost 1.65.1 is built for x86, mips and 64-bit architectures while every other version is arm only.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. moritz-wundke/Boost-for-Android on GitHub
4. README