Native Droid Games

Home/Tools

Tools we actually use

The list behind every measurement on this site. Names only, no links: version numbers move faster than pages and we would rather not publish a link that rots. All of these are free to use for development, and none of them require a rooted phone for the workflows described in our articles.

Build and toolchain

ToolVersion we useWhat it is for
Android NDKr28 stable, r29 previewC and C++ toolchain, headers and stub libraries. Pin the version per branch; r29 removes the legacy toolchain file.
CMake3.22 or newerThe build description we use in every sample. The NDK ships a toolchain file for it.
Ninja1.11 or newerGenerator for CMake. Noticeably faster than make on the same graph.
Gradle8.x with AGP 8Packages the native library and produces the bundle. Keep the native build out of it and call CMake from a task.
ccache4.xCaches compiler output between builds. Worth it when you switch branches often; not worth it on a single clean build machine.
sccache0.8The same idea with a server and remote storage. Useful when several people build the same revision.

Graphics

ToolVersion we useWhat it is for
Vulkan validation layersSDK 1.3The first tool to enable on any new device. Sync validation has found every hazard we have shipped.
RenderDoc1.3xFrame capture and inspection. Works with the layer packaged into a debug build; the Android path needs no root.
Android GPU InspectorcurrentSystem profile and frame capture for supported devices. Good for counters that a desktop debugger cannot see.
Arm Performance StudiocurrentStreamline and the Mali offline compiler. The compiler is useful even without a Mali device, for instruction counts.
Snapdragon ProfilercurrentVendor counters on Qualcomm devices. The only practical way to see some GPU stalls on that hardware.
glslang and shaderccurrentOffline shader compilation to SPIR-V. Compile at build time and ship the binary; do not parse GLSL on the phone.

Profiling

ToolVersion we useWhat it is for
PerfettocurrentSystem trace: scheduling, frequency, frame timeline. The one tool we use on every device, including retail phones.
simpleperfNDKSampling profiler for native code. Produces a call graph that maps back to your symbols.
Tracy0.11Frame profiler with a client library in your build. Its timeline view is the fastest way to see a long frame's shape.
ATraceplatformIn-app markers, read by Perfetto and by the platform's own tools. Cheap enough to leave enabled in release builds.
FrameTimelineAPI 31+The system's own view of when a frame was presented. Use it to check what the player actually saw.

Audio

ToolVersion we useWhat it is for
Oboe1.9C++ wrapper over AAudio and OpenSL ES. The stream builder handles the fallback path so your code does not.
AAudioAPI 26+The platform API. Use it directly if Android 8 is your minimum and you do not need Oboe's helpers.
OboeTestercurrentThe reference app for latency and glitch testing. Its loopback measurement is the method behind our numbers.

Memory

ToolVersion we useWhat it is for
heapprofdPerfettoNative heap profiling with call stacks, on a production build if you can afford the slowdown.
HWAddressSanitizerNDKCatches use-after-free and buffer overflows in native code. Debug builds only; the overhead is large.
mimalloc2.xThe allocator we use for engine allocations, with a per-frame arena on top.
dumpsys meminfoplatformPer-category memory for a running process. The first command to run when a report says “memory”.

Packaging

ToolVersion we useWhat it is for
bundletool1.17Builds and inspects APK sets from a bundle. The only way to see what a device will actually download.
apkanalyzercurrentSummary, size and dex information for an APK. Fast enough to run in a pre-commit hook.
zipalignNDK build toolsAlignment, including the 16 KB page option for newer devices. Run it on the final artefact, not an intermediate one.

What is missing

Three tools are absent on purpose. A commercial engine profiler, because the articles are about the platform and not about one engine. A crash reporting service, because we do not run one and would not recommend a choice we have not measured. And any “one-click optimiser”, because the only reliable optimisation is the one you can measure before and after.