AOSP contains the source code to build an operating system for thousands of different devices. Before you can type m to compile, you must tell the build system exactly which device you are building for, and what type of build you want.
This environment configuration is handled entirely by the lunch command.
The lunch Target Format
After you run source build/envsetup.sh in your terminal, the lunch command becomes available. A lunch target always follows a specific naming format:
PRODUCT-BUILDTYPE
For example, typing lunch aosp_coral-userdebug tells the build system to prepare an Android image for the "coral" hardware device (Google Pixel 4 XL) using the "userdebug" security profile.
# View the interactive menu of all available lunch targets
lunch
Build Types (Variants)
The second half of the lunch target dictates the security and debugging features of the final OS image. There are three primary build types in AOSP:
1. eng (Engineering)
- Purpose: Used by platform developers bringing up brand new hardware.
- Features: ADB is enabled by default.
adbdruns as root by default. The system partitions are usually mounted as read-write. Strict SELinux policies are often relaxed. - Warning: This build is highly insecure and should never be used outside a lab environment.
2. userdebug (User Debugging)
- Purpose: The standard build used by AOSP engineers developing framework features or testing apps.
- Features: It behaves exactly like a retail device, but it explicitly allows you to run
adb rootto gain elevated privileges when necessary. It provides the perfect balance between strict retail security and developer access.
3. user (Retail Production)
- Purpose: This is the final build type that gets flashed onto consumer devices sold in stores.
- Features: Root access is permanently disabled. ADB is disabled by default. SELinux is strictly enforcing. You cannot run
adb rootunder any circumstances.
Adding Custom Lunch Targets
When you port Android to a new custom board, it will not appear in the lunch menu by default.
To add your custom device to the menu, you must define it in an AndroidProducts.mk file located in your device's configuration directory (e.g., device/mycompany/myboard/AndroidProducts.mk).
Once defined, your engineers can type lunch myboard-userdebug, and the build system will instantly load the correct cross-compilers and hardware definitions required to compile the OS for your proprietary silicon.
# Bypassing the interactive menu to select a target directly
lunch aosp_arm64-eng