android/ndk: a three-file repository that points at the real source

Three top-level entries, and none of them is source

The listing for this repository contains .github/, CONTRIBUTING.md and README.md. That is the whole thing. A toolkit that compiles native code into JNI shared libraries for Android application packages is not built from anything on this branch, and the README says so in its third paragraph: the source for the NDK is maintained in AOSP. So this repository is a signpost, and the signposting is its entire function. What it does hold is a coordination surface. There is a milestones page for what is currently being worked on, an RFC section for in-progress features with open discussion bugs, and a pointer to a roadmap document hosted alongside the AOSP source for anything further out. Those three links are the closest thing here to a project plan. Worth noting for anyone deciding where to spend attention: the RFC section currently reads as empty, with the project stating that nothing is in progress and inviting discussion. An empty design queue is a real signal about a project's immediate direction, and it is unusual to be able to read it directly.

Four destinations for one project, and bugs go elsewhere

Here is the concrete friction. The source is at android.googlesource.com under platform/ndk. The roadmap document sits in that same tree under docs. The bug tracker is at github.com/android-ndk/ndk/issues, which is not this repository, and neither is the release calendar, which lives in the wiki of that other repository. Discussion happens on the android-ndk Google Group. So a question about the code, a defect report, a release date and a design discussion have four different homes across two hosting providers and a mailing list archive. Nothing is wrong with that arrangement, and it is common for platform toolchains that straddle an internal source system and a public issue tracker. But it means the README cannot answer the two questions newcomers ask first. Where do I read the code, and where do I report a problem. It answers the first by pointing at AOSP and the second by pointing at a repository whose name differs from this one by a single hyphen, which is easy to misread as the same place. Verify the tracker name before you file anything, because a report filed against the wrong repository has no obvious route to the people who would act on it.

Two build systems for users, a third document for maintainers

The NDK and Android Studio support ndk-build and CMake out of the box, and the README adds a Build System Maintainers Guide for the people who integrate a new host platform into the toolchain. That is a three-way audience split in one paragraph, and it is the clearest statement of scope the repository makes. The application developer reading this is being pointed at guides for building, for debugging and profiling, and at tutorials for three specific areas: high-performance audio, Vulkan and neural networks. None of those three is a general tutorial, which tells you the intended entry point is somebody who already has a task involving native code and wants the specific tutorial for it. The person wanting to change the NDK itself is pointed at the README in the AOSP source tree, not at anything here. So there is no single reader this repository serves well, and the practical consequence is that almost none of the README's value is the text itself. The value is the map, and it is a good map, because the destinations it selects are specific and few.

r30 and a three-stage cadence you can read off the tag dates

Three releases appear here for the same version: r30-beta2 on 2026-07-08, r30-rc1 on 2026-08-24 and r30 on 2026-09-08. That is a little under seven weeks from the second beta to the release candidate, then two more weeks to the final tag. The last push to the repository was on 2026-09-08, the same day the final tag was published, which tells you the README work and the release landed together. The repository is not archived, so this is a project receiving changes as of that date. Two cautions. First, these are release tags, not a version history: the README does not describe what changed in r30, and with only these three tags visible there is nothing here to diff against r29 or any earlier version. Second, the cadence above describes tagging, not delivery. The release calendar is in a different repository's wiki, and the README points at the milestones for what is being worked on, so if you need to know whether r30 is what your build should target, that question is answered elsewhere or not at all here.

The documentation the README deliberately does not reproduce

Every technical claim in this README is a link, and the selection of links is the only editorial content. For the C library, three documents matter, each aimed at a different failure. The bionic status page covers which APIs exist in which releases and how behaviour has changed between API levels, which is the page you want when the same call behaves differently on two devices. The changes for NDK developers page covers dynamic linker changes across releases, described as invaluable if you are having trouble loading your .so files. The 32-bit ABI page documents issues specific to 32-bit code, which is a category that still exists in a toolkit that also ships 64-bit targets. Crash investigation is split the same way, with an overview of crash dumps and a reference to common crashes. The structure suggests the intended reading path for a broken native build: start at the common-crash reference, move to the linker changes if the library will not load, and use the status page if the code compiles but misbehaves. None of that guidance is written down here, and the repository is not trying to be the place where it lives.

What this repository cannot answer, and what to use instead

Four questions a newcomer will ask have no answer on this branch. How do I install the NDK is one; the README links the guides and stops, and gives no package name, no version to request and no path on disk. What licence governs the code is a second, and no licence is recorded for this repository. What changed in the newest release is a third, since r30 has a tag and no notes. Whether the roadmap promises something relevant is a fourth, since the roadmap lives in the AOSP tree. The alternative to using this repository for those four is not another GitHub project but the destinations it names: the guides on the Android developer site for using the toolkit, the AOSP source README for changing it, and the tracker in the other repository for reporting defects. The difference in approach between the two surfaces is the point. This branch curates and routes; the AOSP tree holds the code, the per-release build machinery and the roadmap. If you are deciding whether to adopt the NDK, this repository will not be where the decision is made, and reading it as though it were the toolkit's documentation would be a mistake.

Editorial conclusion

Use android/ndk as an index, not as a codebase. It is the right place to answer what the NDK release cadence looks like, which documentation covers a given problem, and where a design discussion is happening, and it is the wrong place to look for source, build files or a licence, because the working tree is three entries deep and the code is maintained in AOSP. Anyone adopting the NDK should start at the guides rather than here, and anyone who finds a defect should note that the tracker is github.com/android-ndk/ndk/issues, a different repository from this one. Before treating any of this as current, confirm against the r30 release, which is the newest tag here and shares its date with the last push on 2026-09-08.

Frequently asked questions

Official sources

1. android/ndk on GitHub
2. Issues
3. README
4. Releases