Detailed Instructions
The steps below describe how to configure makefiles for new mobile devices and products running Android.
- Create a company directory in
//vendor/
.
mkdir vendor/<company_name>
- Create a
products
directory beneath the company directory you created in step 1.
mkdir vendor/<company_name>/products/
- Create a product-specific makefile, called
vendor/<company_name>/products/<first_product_name>.mk
, that includes at least the following code, all values should contain no space:
$(call inherit-product, $(SRC_TARGET_DIR)/product/generic.mk)
#
# Overrides
PRODUCT_NAME := <first_product_name>
PRODUCT_DEVICE := <board_name>
- Additional product-specific variables can be added to this Product Definition file.
- 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 \
- 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>
- Create a
BoardConfig.mk
file in the directory created in the previous step (vendor/<company_name>/<board_name>
).
# These definitions override the defaults in config/config.make for <board_name>
#
# TARGET_NO_BOOTLOADER := false
#
TARGET_USE_GENERIC_AUDIO := true
TARGET_CPU_ABI := x86
- 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
- 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
- An
AndroidBoard.mk
file must be included in vendor/<company_name>/<board_name>
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.
#
- 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.
<company_name>
<board_name>
AndroidBoard.mk
BoardConfig.mk
system.prop
products
AndroidProducts.mk
<first_product_name>.mk
<second_product_name>.mk
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 |
|
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