Derecha ... Por lo que desea construir su propio árbol de dispositivos, siga leyendo.
responsabilidad: esto es de ninguna manera completa, y no habrá omisiones como han explicado todo esto parte superior de la cabeza y copiado pegado ciertos bits que tengo aquí en mi propio árbol de dispositivos.
El árbol de dispositivos, por ejemplo, /device/lg/gt540 consistiría en hacer que los archivos siguientes:
- Android.mk - esto le dirá al sistema de generación para incluir y construir fuentes específicamente para su dispositivo. Vea a continuación, para un ejemplo. Esto depende del dispositivo y del hardware, usted podría tener libsensors, liblights, subdirectorios libcamera bajo el árbol ejemplo dispositivo, es decir
/device/lg/gt540/libsensors, /device/lg/gt540/liblights, etc. /device/lg/gt540/libcamera
- AndroidBoard.mk - esto es para el kernel, el sistema de construcción usa eso para dejar caer la imagen del núcleo en su lugar (más sobre esto en unos pocos minutos)
- AndroidProducts.mk - especifica el archivo make del dispositivo apropiado, para usarlo en la construcción. es decir,
/device/lg/gt540/device_gt540.mk, esto es específico también.
- device_xxxxx.mk - especifica las propiedades y extras para copiar en la salida final, en este caso, que podría ser por ejemplo,
device_gt540.mk
- BoardConfig.mk - Esta es la carne de todo, aquí es donde se establecen los indicadores condicionales del compilador, los diseños de partición, las direcciones de arranque, el tamaño del disco de ramificación, etc.
Lets vistazo a cada uno de aquellos a dar un vistazo en cuanto a donde todo cabe en
Android.mk:.
ifeq ($(TARGET_BOOTLOADER_BOARD_NAME),xxxxx)
include $(call all-named-subdir-makefiles, recovery libsensors liblights libcamera ....)
endif
Esta es la forma utilizará la acumulación que para construir recuperación, sensores, luces y cámara (por supuesto que habrá más), dice 'Yo Builder, vaya a cada uno de los directorios especificados, y construya las fuentes respectivas plskthxbai '
AndroidBoard.MK:
LOCAL_PATH := device/lg/gt540/
#
# Boot files
#
TARGET_PREBUILT_KERNEL := $(LOCAL_PATH)/kernel
file := $(INSTALLED_KERNEL_TARGET)
ALL_PREBUILT += $(file)
$(file): $(TARGET_PREBUILT_KERNEL) | $(ACP)
$(transform-prebuilt-to-target)
Ahora bien, esto, le está diciendo al sistema de construcción, para ser capaz de soltar este núcleo en el out/target/product/lg/gt540
AndroidProducts.mk (nótese la correlación con el directorio de árbol de dispositivos?) :
PRODUCT_MAKEFILES := \
$(LOCAL_DIR)/device_gt540.mk
Su cuentan la construcción como en 'Yo Builder, leer ese dispositivo haga el archivo por favor y trátelo al finalizar la compilación. '
* device_xxxxx.mk: (para este ejemplo, device_gt540.mk) *
PRODUCT_NAME := lg_gt540
PRODUCT_DEVICE := gt540
PRODUCT_MODEL := LG GT 540
PRODUCT_COPY_FILES += \
... specific ...
PRODUCT_PROPERTY_OVERRIDES := \
ro.com.android.dateformat=dd-MM-yyyy \
... more stuff ...
Aquí es donde todos los detalles para el dispositivo, tales como controladores, bibliotecas patentadas, el apoyo a las secuencias de comandos específicamente para el dispositivo, se copia a out/target/product/lg/gt540/system/ en este caso. Observe cómo las anulaciones para las propiedades, estas terminan en el build.prop que se encuentra en la raíz del /system de la ROM de Android.
BoardConfig.mk:
LOCAL_PATH:= $(call my-dir)
TARGET_NO_BOOTLOADER := true
TARGET_PREBUILT_KERNEL := device/lg/gt540/kernel
TARGET_PREBUILT_RECOVERY_KERNEL := device/lg/gt540/recovery_kernel
# This will vary from device!
TARGET_BOARD_PLATFORM := msm7k
TARGET_ARCH_VARIANT := armv6-vfp
TARGET_CPU_ABI := armeabi
TARGET_CPU_ABI := armeabi-v6l
TARGET_CPU_ABI2 := armeabi
# OpenGL drivers config file path
BOARD_EGL_CFG := device/lg/gt540/egl.cfg
# Dependant, not to be taken literally!
BOARD_GLOBAL_CFLAGS += -DHAVE_FM_RADIO
# Dependant, not to be taken literally!
BOARD_KERNEL_BASE := 0x02600000
# this will be device specific, and by doing cat /proc/mtd will give you the correct sizes
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x00480000
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x00480000
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x0cf80000
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x0d020000
BOARD_FLASH_BLOCK_SIZE := 131072
Eso es un extracto, observe cómo se especifica la dirección base del núcleo, así es como el boot.img se genera después de la compilación está hecho y una vez más, se dejó caer en out/target/product/lg/gt540/boot.img. Además, lo que es más importante, le estamos diciendo al sistema de compilación que use la plataforma de destino para la compilación cruzada de las fuentes (* TARGET_BOARD_PLATFORM */* TARGET_CPU_ABI *) Habrá más información allí, como indicadores condicionales para pasar al compilador, para un ejemplo. especificamos la directiva HAVE_FM_RADIO para indicarle, cuando se trata de manejar la fuente del sistema de radio FM, compilar partes de la fuente de manera condicional. Nuevamente, esto es específico del hardware y el millaje variará, también esto se aplica a la dirección de arranque. En pocas palabras, esto es 'Yo Builder, lee las malditas variables y recuerdalas y aplícalas al compilar de forma cruzada esos archivos fuente. '
Ahora que se muestran las partes internas de cada uno de esos archivos de creación de Android.
Ahora, en la parte vendor/ de la misma, en AOSP, simplemente, una vez más, de correlación y se corresponde con el árbol device/, como en continuar con este ejemplo, vendor/lg/gt540/ que es recogido por el lunch. Hay más archivos make allí, pero el consenso general es que hay un directorio llamado proprietary que contiene las librerías propietarias (debido a fuentes cercanas, etc.) que se copian. La copia de las bibliotecas se especifica en el archivo device-vendor-blobs.mk, en este caso, gt540-vendor-blobs.mk.
Cuando sucede la magia de la siguiente manera:
. build/envsetup.sh
Esta es la lectura de la totalidad de los registros que se encuentran en cada una de las device/ subdirectorios y "les recuerda", por lo que el sistema de construcción sabe qué tipo de objetivo usado etc.
Cuando se invoca el . lunch, aparece un menú para seleccionar el dispositivo que se requiere para compilar. Ahora el último paso para hacer la construcción ...
make -j5 > buildlog.log 2>&1
corro multitail en otro terminal y controlar el archivo buildlog.log para comprobar y asegurarse de que su edificio.
Este último paso dependerá de la cantidad de núcleos que tenga (n núcleos + 1 como regla) y lleva un tiempo para compilarlo, la compilación GB tarda 40 minutos en mi computadora portátil con Arch Linux 64 bits, la construcción ICS tarda aproximadamente 2 horas 30 min. Por lo tanto, el kilometraje variará según el tipo de potencia que tenga su máquina.
Una vez finalizada la construcción, una pequeña campana se apaga y en la parte inferior de dicho archivo de registro, veo esto:
Combining NOTICE files: out/target/product/xxxxx/obj/NOTICE.html
Target system fs image: out/target/product/xxxxx/obj/PACKAGING/systemimage_intermediates/system.img
Install system fs image: out/target/product/xxxxx/system.img
out/target/product/xxxx/system.img+ total size is 108776448
Como cuestión de JBQ interés (Jean Baptiste Queru - el 'jefe' para administrar/distribuir la fuente de Google), su paso de compilación es este ...
make -j32
Yup! 32 núcleos! Eso ..... es bastante poderoso.
¡Estaba buscando esto!, ¡Gran respuesta! – DGomez
¿Sabes algo de documentación que puedo leer para comenzar con esto? – DGomez
Esto no puede ser más útil. Gracias. – korro