page.title=Building Android for a new Device pdk.version=1.0 @jd:body

In this document

Detailed Instructions

The directions below describe how to configure make files for new mobile devices and products.

  1. Create a company directory in //vendor/.
      mkdir vendor/<company_name>
  2. Create a products directory beneath the company directory you created in step 1.
      mkdir vendor/<company_name>/products/
  3. Create a product-specific make file, called vendor/<company_name>/products/<first_product_name>.mk, that includes the following code:
      $(call inherit-product, $(SRC_TARGET_DIR)/product/generic.mk)
  #
  # Overrides
  PRODUCT_NAME := <first_product_name>
  PRODUCT_DEVICE := <board_name>
  4. In the products directory, create an AndroidProducts.mk file that point to (and is responsible for finding) the individual product make files.
      #
  # This file should set PRODUCT_MAKEFILES to a list of product makefiles
  # to expose to the build system.  LOCAL_DIR will already be set to
  # the directory containing this file. 
  #
  # This file may not rely on the value of any variable other than
  # LOCAL_DIR; do not use any conditionals, and do not look up the
  # value of any variable that isn't set in this file or in a file that
  # it includes.
  #
  
  PRODUCT_MAKEFILES := \
    $(LOCAL_DIR)/first_product_name.mk \
  5. Create a board-specific directory beneath your company directory that matches the PRODUCT_DEVICE variable <board_name> referenced in the product-specific make file above. This will include a make file that gets accessed by any product using this board.
      mkdir vendor/<company_name>/<board_name>
  6. Create a product_config.mk file in the directory created in the previous step (vendor/<company_name>/<board_name>). If this directory does not include a product_config.mk file, the build will fail.
      # These definitions override the defaults in config/config.make for <board_name>
  #
  # TARGET_NO_BOOTLOADER := false
  # TARGET_HARDWARE_3D := false 
  #
  TARGET_USE_GENERIC_AUDIO := true
  7. If you wish to modify system properties, create a system.prop file in your <board_name> directory(vendor/<company_name>/<board_name>).
      # system.prop for 
  # This overrides settings in the products/generic/system.prop file
  #
  # rild.libpath=/system/lib/libreference-ril.so
  # rild.libargs=-d /dev/ttyS0
  8. Add a pointer to <second_product_name>.mk within products/AndroidProducts.mk.
      PRODUCT_MAKEFILES := \
    $(LOCAL_DIR)/first_product_name.mk \
    $(LOCAL_DIR)/second_product_name.mk
  9. vendor/<company_name>/<board_name> must include an Android.mk file with at least the following code:

      # make file for new hardware  from 
  #
  LOCAL_PATH := $(call my-dir)
  #
  # this is here to use the pre-built kernel
  ifeq ($(TARGET_PREBUILT_KERNEL),)
  TARGET_PREBUILT_KERNEL := $(LOCAL_PATH)/kernel
  endif
  #
  file := $(INSTALLED_KERNEL_TARGET)
  ALL_PREBUILT += $(file)
  $(file): $(TARGET_PREBUILT_KERNEL) | $(ACP)
		$(transform-prebuilt-to-target)
  #
  # no boot loader, so we don't need any of that stuff..  
  #
  LOCAL_PATH := vendor/<company_name>/<board_name>
  #
  include $(CLEAR_VARS)
  #
  # include more board specific stuff here? Such as Audio parameters.      
  #
  10. To create a second product for the same board, create a second product-specific make file called vendor/company_name/products/<second_product_name>.mk that includes:
      $(call inherit-product, $(SRC_TARGET_DIR)/product/generic.mk)
  #
  # Overrides
  PRODUCT_NAME := <second_product_name>
  PRODUCT_DEVICE := <board_name>

By now, you should have two new products, called <first_product_name> and <second_product_name> associated with <company_name>. To verify that a product is properly configured (<first_product_name>, for example), execute the following:

  . build/envsetup.sh
  make PRODUCT-<first_product_name>-user

You should find new build binaries located in /out/target/product/<board_name>.

New Product File Tree

The file tree below illustrates what your own system should look like after completing the steps above.

Product Definition Files

Product-specific variables are defined in product definition files. A product definition file can inherit from other product definition files, thus reducing the need to copy and simplifying maintenance.

Variables maintained in a product definition files include:

Parameter Description Example
PRODUCT_NAME End-user-visible name for the overall product. Appears in the "About the phone" info.
PRODUCT_MODEL End-user-visible name for the end product
PRODUCT_LOCALES A space-separated list of two-letter language code, two-letter country code pairs that describe several settings for the user, such as the UI language and time, date and currency formatting. The first locale listed in PRODUCT_LOCALES is is used if the locale has never been set before. en_GB de_DE es_ES fr_CA
PRODUCT_PACKAGES Lists the APKs to install. Calendar Contacts
PRODUCT_DEVICE Name of the industrial design dream
PRODUCT_MANUFACTURER Name of the manufacturer acme
PRODUCT_BRAND The brand (e.g., carrier) the software is customized for, if any
PRODUCT_PROPERTY_OVERRIDES List of property assignments in the format "key=value"
PRODUCT_COPY_FILES List of words like source_path:destination_path. The file at the source path should be copied to the destination path when building this product. The rules for the copy steps are defined in config/Makefile
PRODUCT_OTA_PUBLIC_KEYS List of OTA public keys for the product
PRODUCT_POLICY Indicate which policy this product should use
PRODUCT_PACKAGE_OVERLAYS Indicate whether to use default resources or add any product specific overlays vendor/acme/overlay
PRODUCT_CONTRIBUTORS_FILE HTML file containing the contributors to the project.
PRODUCT_TAGS list of space-separated words for a given product
PRODUCT_SDK_ADDON_NAME
PRODUCT_SDK_ADDON_COPY_FILES
PRODUCT_SDK_ADDON_COPY_MODULES
PRODUCT_SDK_ADDON_DOC_MODULE

The snippet below illustrates a typical product definition file.

$(call inherit-product, build/target/product/generic.mk)

#Overrides
PRODUCT_NAME := MyDevice
PRODUCT_MANUFACTURER := acme
PRODUCT_BRAND := acme_us
PRODUCT_LOCALES := en_GB es_ES fr_FR
PRODUCT_PACKAGE_OVERLAYS := vendor/acme/overlay

Build Variants

When building for a particular product, it's often useful to have minor variations on what is ultimately the final release build. These are the currently-defined build variants:

eng This is the default flavor. A plain "make" is the same as "make eng". droid is an alias for eng.
  • Installs modules tagged with: eng, debug, user, and/or development.
  • Installs non-APK modules that have no tags specified.
  • Installs APKs according to the product definition files, in addition to tagged APKs.
  • ro.secure=0
  • ro.debuggable=1
  • ro.kernel.android.checkjni=1
  • adb is enabled by default.
user "make user"

This is the flavor intended to be the final release bits.

  • Installs modules tagged with user.
  • Installs non-APK modules that have no tags specified.
  • Installs APKs according to the product definition files; tags are ignored for APK modules.
  • ro.secure=1
  • ro.debuggable=0
  • adb is disabled by default.
userdebug "make userdebug"

The same as user, except:

  • Also installs modules tagged with debug.
  • ro.debuggable=1
  • adb is enabled by default.

If you build one flavor and then want to build another, you should run "make installclean" between the two makes to guarantee that you don't pick up files installed by the previous flavor. "make clean" will also suffice, but it takes a lot longer.