Banana Run

Setting Up a Banana Run Build — What Actually Happens

You pull the source, configure your environment, and start building. The Banana Run phase is where things start to diverge from a standard AOSP build. Not because it is some mysterious black box, but because there are specific board-level configurations that most people gloss over until their build breaks at 2 AM. I have been through this more times than I want to count, usually because I assumed a configuration file was optional. The Banana Run is not a standalone framework or a separate toolchain. It is a build configuration workflow used when targeting particular board-level hardware setups, mostly within the Android open-source ecosystem. The name comes from the device codenames that fall under that particular run branch, and it ties together kernel configs, boardDefinitions, recovery partitions, and vendor blobs into one coherent flashable output. If you are just flashing a generic rom, you probably do not need to touch this. If you are customizing boot images or debugging kernel panic loops, you need to understand it. Start with a clean Ubuntu installation. I use 22.04 because newer releases tend to break older build scripts without warning. Install the standard dependencies first: git-core, gnupg, flex, bison, build-essential, curl, libxml2-utils, python3, and repo. Do not skip the 32-bit compatibility libraries even if your host is 64-bit. The build system will complain later if you skip them, and the error messages are not helpful.

Set up your ccache before you download anything. This alone cuts rebuild times significantly on repeated builds. Run the following to initialize it properly: ccache -M 50G That gives you enough room for multiple build cycles without constantly evicting cached objects. Without ccache, a full Banana Run build on a typical machine takes around three to four hours. With it, the same build after the first run drops to roughly forty-five minutes depending on how much you change between iterations.

Pulling the Source Tree

Initialize the repository with the correct manifest. The Banana Run uses a specific brancheset that differs from the default AOSP tree. You need to point repo init at the right manifest URL, usually something tied to the device vendor or the custom build project you are working with. Pull the source with the -j flag matching your core count, but do not push it beyond your RAM limit. Downloading too many threads at once will stall your build machine even if the source check itself succeeds. Once the pull finishes, verify the tree with a quick ls on the top-level directories. If vendor or device folders are missing, the manifest did not resolve correctly. Re-running repo sync with the --force-sync flag usually fixes stale references, but do not use that flag blindly. It overwrites local changes without warning, and you will lose work if you have already modified board files.

Configuring the Build for Banana Run

Run the setup script in the root of your source tree. The command varies by project, but it generally looks like sourcing envsetup.sh and then choosing a target. For Banana Run specifically, the target naming convention follows a pattern that includes the codename and the build variant. Pick the variant that matches your hardware exactly. Picking the wrong one produces a boot image that will compile successfully but fail to load on the device. This is where I made a mistake early on that cost me two days. I selected the wrong variant because the naming scheme looked identical between two similar boards. The build completed without errors, flashed cleanly, and then the device would not post. Kernel logs showed a mismatch in the device tree overlay. I had to rebuild from scratch with the correct target. Always double-check the board codename against your actual hardware revision before you kick off the build.

Building the Tree

Start with make -j$(nproc). This runs the full build using all available cores. Do not use ccache flags incorrectly. If you enabled ccache earlier, the build system uses it automatically. If you want stricter cache management, add the appropriate export before running make. Watch the first compilation pass carefully. Early errors are easier to fix than late-stage linker failures that force you to backtrack through twenty different dependency chains. If you hit a compilation error, read the full output before assuming the problem. Build systems often report the actual failure deep inside a long stream of warnings. Use grep or scroll back to the first error line. Fix that first. Do not chase the warning that looks scarier but is actually harmless.

Common Pitfalls and How I Got Around Them

One issue that keeps appearing is vendor blob extraction. Some projects expect prebuilt blobs that do not match your kernel version exactly. When the build refuses to link due to missing symbols, check whether your blob directory contains files from a different branch. I solved this by pinning the vendor submodule to a specific commit hash instead of letting it track the latest tip. That kept my blobs stable across rebuilds. Another problem is recovery partition mismatches. Banana Run builds sometimes package a recovery image that conflicts with your custom boot image. If your device boots to fastboot but never reaches the OS, check the recovery.img size and checksum. Rebuilding recovery separately and flashing it independently often resolves the issue without needing a full tree rebuild.

Where Banana Run Builds Fall Apart

Let me be blunt about the limitations. This approach requires a working manifest, correct board configs, and matching vendor blobs. If any of those pieces are outdated or misaligned, the build will either fail visibly or succeed silently and produce a non-functional image. There is no middle ground. The process also demands significant disk space. A full tree with vendor data and ccache can easily exceed one hundred gigabytes. Make sure your build machine has room before you start. If you are looking for a quicker path and do not need deep customization, consider using a prebuilt Banana Run image from a trusted source instead of compiling from source. You save hours and avoid the dependency headaches. The tradeoff is that you give up control over kernel patches and board-level modifications. Choose based on what you actually need to change.

Final Notes on Flashing and Verification

After a successful build, locate the output files in the out directory. The exact paths depend on your target, but you are generally looking for boot.img, recovery.img, and system.img. Flash them in the correct order using fastboot or your device-specific tool. Verify each partition with fastboot getvar all before rebooting. This takes thirty seconds and saves you from guessing why the device is not booting later. I do not recommend skipping verification. I have flashed incomplete builds multiple times and wasted hours diagnosing symptoms that turned out to be a missing partition. A quick verification step catches those issues immediately.