Identifying the build system

Background / history (theory — why these files matter)

  • Android’s build story evolved:

    • Early Android used GNU Make with Android.mk files (and top-level Makefiles). That’s the old Android build.

    • Google moved to Soong (written in Go) to replace (most of) Make. Soong uses Blueprint metadata files named Android.bp. Soong still integrates with the AOSP build system and produces the device images and platform artifacts.

    • Android Studio / app development uses Gradle (with the Android Gradle Plugin). Gradle projects have settings.gradle, build.gradle and often a gradlew wrapper to make builds reproducible.

  • Why file names are authoritative: each build system parses its own manifest files:

    • Soong parses Android.bp (and older Android.mk) to generate ninja build rules that produce system artifacts.

    • Gradle reads settings.gradle + build.gradle (and gradle.properties) to build apps/libraries for developers in Studio.

    • Because they use different file formats and toolchains, the presence and contents of those files tell you which build system the repo expects.

What to look for — concrete rules & why they mean what they mean

  • Android.bp present → Soong (AOSP)

    • Why: Android.bp is the Soong Blueprint syntax. Modules declared here are designed to be picked up by m / Soong during full AOSP builds.

  • Android.mk present → legacy Make-based AOSP (or compatibility)

    • Why: older AOSP used Make; many device/board/vendor repos still contain Android.mk.

  • settings.gradle, build.gradle, gradlew → Gradle / Android Studio

    • Why: these are the Gradle config files. gradlew is the Gradle wrapper script — a strong indicator the project can be built by Gradle/Studio.

  • Both Android.bp (or Android.mk) and Gradle files → hybrid (developer convenience + actual platform build)

    • Why: many AOSP components include Gradle setup so developers can import modules in Android Studio. But the AOSP build (Soong) is typically the authoritative one for producing system images.

  • WORKSPACE or BUILD files → Bazel (less common for systemui/core AOSP, but possible in other projects).

Key files and the important flags / properties to scan

(What to grep for and what it tells you.)

Soong / Android.bp (AOSP)

  • Module types to notice: cc_library, cc_binary, java_library, android_app, android_library, apex

    • These show whether the module is C/C++ or Java/Kotlin or an Android app/system package.

  • Important properties inside a module:

    • name: → module name used by Soong.

    • srcs: → source files included.

    • sdk_version: → which platform SDK/stub version is used (e.g., "current", "system_current", or a numeric API level).

    • static_libs:, shared_libs: → libraries this module links against (shows dependencies).

    • compile_multilib: or target: → host vs device or 32/64-bit hints.

    • visible:, vendor_available:, product_variables: → availability/visibility to other parts of tree.

  • Why these matter: these properties configure how Soong compiles and links the module into the system image. If you need to change how something is included in AOSP, edit Android.bp.

Legacy Make / Android.mk

  • Key patterns:

    • LOCAL_MODULE := <name>

    • LOCAL_SRC_FILES := ...

    • include $(BUILD_SHARED_LIBRARY) or include $(BUILD_STATIC_LIBRARY) or include $(BUILD_PACKAGE)

  • Why they matter: Kati (Make compatibility layer) reads these to generate build rules; used in older parts of AOSP.

Gradle / build.gradle, settings.gradle

  • Top signs of Android Gradle plugin:

    • plugins { id 'com.android.application' } or apply plugin: 'com.android.library'

    • android { compileSdkVersion 33; defaultConfig { minSdkVersion ...; targetSdkVersion ... } }

    • dependencies { implementation project(':something') ... }

  • settings.gradle:

    • include ':systemui', ':lib:foo' — shows subprojects that Gradle will assemble.

  • gradle-wrapper.properties:

    • Gives the Gradle version (used by gradlew).

  • Why they matter: these are the files Android Studio uses to build, run, and provide editor features. They control compilation options, flavors, signing configs, and dependency resolution.

How to tell which build actually produces the device artifact (authoritative)

  • Location in repository:

    • If the repo sits inside a full AOSP checkout (has build/, system/, frameworks/, device/ top-level directories), Soong/Make is likely authoritative.

    • A standalone app repo with only Gradle files and app//module/ folders is Gradle-first.

  • Search who depends on the module in AOSP:

    • If other Android.bp files static_libs or shared_libs reference the module name, Soong uses it.

  • Build commands used by maintainers:

    • For AOSP: source build/envsetup.sh && lunch <target> && m or mmm path/to/module - these are Soong/AOSP flows.

    • For Gradle: ./gradlew assembleDebug or build from Android Studio.

Hybrid projects — why they exist & how to handle them

  • Why hybrid happens:

    • Platform components (like SystemUI) must be included in the system image built by Soong, but developers want the convenience of Android Studio (layout previews, quick runs, lint). So authors add Gradle wrappers or a studio/ project that wraps sources for Studio.

  • Pitfall: Gradle and Soong may use different dependency names, package namespaces, or resource merging rules. Fixes meant for the device must be made in the AOSP/Soong metadata (Android.bp or Android.mk) — otherwise the change won't be included in m builds.

  • Rule of thumb: Edit Android.bp/Makefiles for production/system changes. Use Gradle for local dev/testing convenience only.

Quick checklist / commands you can use in a repo

  • Find build markers:

    • ls | egrep 'Android.bp|Android.mk|build.gradle|settings.gradle|gradlew'

  • Grep for Gradle Android plugin:

    • grep -R "com.android.application" -n || true

  • Grep for Soong module types:

    • grep -R "android_app\\|java_library\\|cc_library" -n Android.bp || true

  • If inside AOSP tree, use Soong build commands:

    • source build/envsetup.sh ; lunch <target> ; m (this is how AOSP builds device images)

  • To build just one module with AOSP tools:

    • mmm path/to/module (calls the module-level build)

Mini-summary (one-line memory helpers)

  • Android.bp → BluePrint → Soong → AOSP (system builds)

  • Android.mk → Legacy Make (older AOSP)

  • build.gradle / settings.gradle / gradlew → Gradle / Android Studio (developer builds)

  • Both → Hybrid (Studio convenience, Soong authoritative for system builds)

Quick diagnostic checklist (what to look for and what it means)

  • Android.bp (or many *.bp) → Soong / AOSP build. Soong modules look like cc_library, java_library, android_app, etc.

  • Android.mk or Android.bp + top-level build/ (in AOSP tree) → classic Android make / AOSP (older make system or mixed).

  • settings.gradle, build.gradle, gradle.properties, gradlew (or gradlew.bat + gradle/wrapper/gradle-wrapper.properties) → Gradle / Android Studio project. Look inside build.gradle for apply plugin: 'com.android.application' or plugins { id 'com.android.library' }.

  • WORKSPACE / Bazel files → Bazel (not relevant now, but watch for it).

  • Presence of both Android.bp and Gradle files often means a hybrid: the code is built by AOSP for device images but also has Gradle config so you can import/preview modules in Android Studio. Which system is authoritative depends on where the repo is intended to be built from (AOSP tree vs standalone).

Key places / flags to inspect

  • Android.bp: module type and key properties. Example bits to look for:

    • android_app { name: "...", srcs: [...], sdk_version: "current", }

    • cc_library { name: "...", srcs: [...], shared_libs: [...], } These lines show Soong/AOSP configuration.

  • Android.mk: include $(BUILD_SHARED_LIBRARY) etc. — indicates MAKE-based AOSP build.

  • settings.gradle: include ':systemui', ':othermodule' — shows Gradle subprojects included in Studio.

  • build.gradle (module or top-level):

    • plugins { id 'com.android.application' } or apply plugin: 'com.android.library' — Gradle Android plugin.

    • android { compileSdkVersion 33 namespace "com.example" } — Gradle Android config.

  • gradle-wrapper.properties: Gradle version used for Android Studio builds.

  • Top-level repo context: if the project lives under a full AOSP checkout (lots of device/, frameworks/, build/) it’s intended for Soong/AOSP builds. If it’s a standalone repo with app/ and Gradle files, it’s Studio/Gradle.

Hybrid notes

  • Hybrid projects exist. Common pattern: Soong builds the system image; a tools/ or studio/ Gradle setup exists so developers can open modules in Android Studio for editing and previewing. The source that actually is used in a device build is whatever Soong/Make in the AOSP tree consumes; Gradle is often there for convenience only.

  • Conflicts can arise when Gradle and Soong expect different source/layout or dependency names — so changes meant for AOSP should be made to Android.bp/Android.mk, not only build.gradle.

Okay — one small step now: please run this in the project root and paste the output (or just tell me which of the files are present):

(If you prefer, paste just the filenames you see: Android.bp, Android.mk, settings.gradle, build.gradle, gradlew, etc.)

I’ll use that to pick the next guided step.

PreviousProtocol BuffersNextAndroid Studio For Platform (ASFP)

Last updated