Why Dropbox is Ditching Its Homegrown Android Build System

By late 2018, Dropbox's custom mobile build system had become a serious bottleneck. The system, known as BMBF (Buildy McBuildface Basic Modular Build Format), was a Python-based meta-build tool that auto-generated Gradle files for the company's Android and iOS apps. While it served a purpose when it was introduced in 2016, it had become slow, error-prone, and difficult for engineers to work with. After four months of planning and evaluation, Dropbox's Mobile Platform team decided to retire BMBF in favor of a standard Gradle-based setup.

The Problem with BMBF

BMBF was designed to modularize Dropbox's shared mobile codebase, known as Xplat, and to reduce boilerplate in build files. It enforced a strict file and directory structure, then generated build.gradle files and wired modules into settings.gradle. A module configuration file like device.bmbf.yaml:

dependencies:
  - dbx/base/async

java:
  src_maven_dependencies:
    - dagger
    - dagger_compiler
  jvm_test_maven_dependencies:
    - junit

would be parsed by BMBF to produce the actual Gradle build file:

apply plugin: 'com.android.library'
apply plugin: 'kotlin-kapt'

android {
    sourceSets {
        main {
            manifest.srcFile 'AndroidManifest.xml'
            java.srcDirs = ['java/src']
            test.srcDirs = ['jvm_test/src']
            androidTest.srcDirs = ['android_test/src']
        }
    }
}
dependencies {
    implementation project(':dbx:base:async')
    implementation project(':dbx:base:oxygen')
    implementation commonlibs.dagger2
    kapt annotationprocessors.dagger2_compiler
    api commonlibs.kotlinstdlib
    testImplementation testlibs.junit
}

That abstraction came with significant downsides. BMBF was deeply opinionated, so if engineers needed functionality that wasn't baked in, they had to file tickets with the Mobile Platform team or attempt to modify the tool themselves. The required file and folder conventions had a steep learning curve — engineers with six or more months at the company still regularly struggled to create new modules. The help channels were flooded with BMBF-specific error questions.

More critically, BMBF was incompatible with Gradle's incremental build features, because it regenerated build.gradle files on every build. And with the original maintainers having moved on, there was little internal enthusiasm for continuing to develop and support a legacy meta-build system — especially since Dropbox had already decided to move away from shared C++ code and toward platform-specific implementations.

Evaluating the Alternatives

The team spent several weeks building a sandbox environment to compare four options:

  1. Gradle + BMBF (status quo)
  2. Gradle only
  3. Bazel
  4. Buck

Gradle only served as the baseline — no migration work required. It's the industry standard for Android, gets the latest features and libraries first, and would carry a low maintenance burden.

Bazel was already widely used at Dropbox, and an engineer from the Developer Infrastructure team was able to generate all required BUILD.bzl files to successfully produce an APK. However, as of December 2018, Bazel was still missing critical Android features that Google had already shipped in Gradle — for instance, Android App Bundles, released in May 2018, were not yet available in Bazel. The Android Studio team is focused on Gradle, and Bazel support for Android tends to trail Gradle by one or two quarters. Dropbox would have needed to make a significant upfront investment in a Bazel MVP plus provide continuous long-term support.

Buck was ruled out early. It lacked community support, didn't support Kotlin at the time, and Dropbox had no in-house expertise. Supporting it would have required one or two dedicated mobile engineers — Uber, for example, maintains a three-person team for Buck support.

The Tradeoffs

The team compiled a detailed comparison of the major tradeoffs across the candidate systems.

Bazel advantages:

  • Toolchain managed by Dropbox's internal Developer Platform team, not mobile engineers
  • Already widely used across Dropbox
  • Unified build system for C++ and Java/Kotlin
  • Better performance at scale

Bazel disadvantages:

  • Not the industry standard for mobile development
  • Missing the latest features and libraries
  • Requires larger upfront and ongoing investment
  • Poor Android Studio integration; Google's tooling focus is on Gradle

Gradle advantages:

  • Industry standard for Android, familiar to new hires
  • No migration or maintenance burden beyond checking in build files and removing BMBF from the model management
  • All latest features and libraries available

Gradle disadvantages:

  • Poor support for cross-platform C++ development — that work would still need BMBF or Buck as an intermediary
  • Ongoing support needed for version bumps and guardrails

Keeping BMBF advantages:

  • Good support for cross-platform C++ code
  • Less risk of developers breaking Gradle configurations

Keeping BMBF disadvantages:

  • Tool is not externally maintained and not an industry standard
  • Maintenance burden sits entirely with the mobile team, with little enthusiasm for it

The Decision: Gradle First, Bazel Later

Dropbox chose to move forward with the Gradle build system. The primary reason was the low migration cost — moving from BMBF's generated Gradle files to hand-managed ones was a smaller step than jumping to Bazel. Although Bazel offered much faster build times, the team was concerned about the local developer experience, given the ecosystem's relative immaturity at the time.

The company plans to revisit Bazel in the future. For now, BMBF will continue to handle code generation and C++ development, while Java/Kotlin projects will be managed through standard Gradle files. The team also plans to invest in guardrails, like linting and templating, to keep the Gradle setup approachable — addressing one of the core frustrations engineers had with BMBF's steep learning curve.