Giusto ... Quindi vuoi costruire il tuo albero del dispositivo, continua a leggere.
responsabilità: questo non è affatto completo, e ci sarà omissioni, come hanno spiegato tutto questo parte superiore della mia testa e copiato incollato alcuni bit che ho qui sul mio albero dei dispositivi.
L'albero dei dispositivi, per esempio, /device/lg/gt540 sarebbe composto dai seguenti rendere i file:
- Android.mk - questo vi dirà il sistema di generazione per includere e costruire fonti specificamente per il dispositivo. Vedi sotto, per un esempio. Questo dipende dal dispositivo e l'hardware, si potrebbe avere libsensors, liblights, le sottodirectory libcamera sotto l'albero ad esempio dispositivo, vale a dire
/device/lg/gt540/libsensors, /device/lg/gt540/liblights, /device/lg/gt540/libcamera ecc
- AndroidBoard.mk - questo è per il kernel, il sistema di generazione utilizza quello per rilasciare l'immagine del kernel in atto (maggiori informazioni in pochi minuti)
- AndroidProducts.mk - specifica il file di creazione del dispositivo appropriato, da utilizzare per la creazione. vale a dire
/device/lg/gt540/device_gt540.mk, anche questo è specifico.
- device_xxxxx.mk - specifica le proprietà e gli extra di copiare in output finale, in questo caso, potrebbe essere, ad esempio,
device_gt540.mk
- BoardConfig.mk - Questa è la carne di tutto, è qui che vengono impostati i flag condizionali del compilatore, i layout delle partizioni, gli indirizzi di avvio, le dimensioni del ramdisk e così via.
Lets sbirciatina in ciascuno di questi per dare un colpo d'occhio su dove tutto si a
Android.mk:.
ifeq ($(TARGET_BOOTLOADER_BOARD_NAME),xxxxx)
include $(call all-named-subdir-makefiles, recovery libsensors liblights libcamera ....)
endif
Questo è come la build userà che per costruire recupero, sensori, luci e macchina fotografica (ovviamente ce ne saranno altri), il suo dire 'Yo Builder, andare in ciascuna delle directory specificate e costruire le rispettive fonti 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)
Ora questo, sta dicendo il sistema di compilazione, per essere in grado di abbandonare questo kernel nel out/target/product/lg/gt540
AndroidProducts.mk (notare la correlazione con la directory struttura dei dispositivi?) :
PRODUCT_MAKEFILES := \
$(LOCAL_DIR)/device_gt540.mk
sua raccontano la costruzione come in 'Yo Builder, leggere quel dispositivo crea file per favore ed elaboralo al completamento della compilazione. '
* device_xxxxx.mk: (per questo esempio, 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 ...
Questo è dove tutte le specifiche per il dispositivo come driver, librerie proprietarie, supportano script specifico per il dispositivo, viene copiato su out/target/product/lg/gt540/system/ in questo caso. Si noti come gli override per le proprietà, questi finiscono nello build.prop trovato nella radice dello /system della ROM 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
Questo è un estratto, notare come specifichiamo l'indirizzo di base del kernel, questo è come il boot.img è prodotto anche dopo la compilazione è fatto e ancora una volta, viene scartato in out/target/product/lg/gt540/boot.img. Inoltre, ancora più importante, stiamo dicendo al sistema di compilazione di utilizzare la piattaforma di destinazione per la compilazione incrociata delle fonti (* TARGET_BOARD_PLATFORM */* TARGET_CPU_ABI *) Ci saranno più informazioni in là come flag condizionali da passare al compilatore, per un esempio. abbiamo specificato la direttiva HAVE_FM_RADIO per dirglielo, quando si tratta di gestire la sorgente per il sistema radio FM, per compilare in modo condizionale parti della sorgente. Di nuovo, questo è specifico dell'hardware e il chilometraggio varierà, anche questo si applica all'indirizzo per l'avvio. In poche parole, questo sta dicendo 'Yo Builder, leggi le dannate variabili e ricordale e applicale quando esegui la compilazione incrociata di quei file sorgente! '
Ora vengono mostrati gli interni di ciascuno di questi file di creazione di build Android.
Ora, sulla vendor/ parte di esso, in AOSP, semplicemente, ancora una volta, correlazione e corrisponde con l'albero device/, come nel continuare con questo esempio, vendor/lg/gt540/ che viene prelevato dal lunch. Ci sono altri file in là ma il consenso generale è che c'è una directory chiamata proprietary che contiene le librerie proprietarie (dovute a close-source, ecc.) Che vengono copiate. La copia delle librerie viene specificata nel file device-vendor-blobs.mk, in questo caso, gt540-vendor-blobs.mk.
Quando la magia accade nel modo seguente:
. build/envsetup.sh
Questa è la lettura in tutta risultati trovati in ciascuna delle device/ sottodirectory e "li ricorda", in modo che il sistema di compilazione sa che tipo di destinazione è usato ecc.
Quando viene invocato il numero . lunch, viene visualizzato un messaggio che richiede di selezionare il dispositivo che è necessario creare. Ora l'ultimo e ultimo passo per fare la build ...
make -j5 > buildlog.log 2>&1
corro multitail su un altro terminale e monitorare il file buildlog.log per controllare e assicurarsi che il suo edificio.
Quest'ultimo passaggio dipenderà da quanti nuclei si dispone (n core + 1 come regola) e ci vuole un po 'per costruire, GB accumulo prende 40 minuti sul mio portatile con Arch Linux a 64 bit, ICS costruire dura circa 2 ore 30 min. Quindi il chilometraggio varierà sul tipo di potenza della tua macchina.
Quando la costruzione è fatto, una campanella si spegne e sul fondo del suddetto file di log, vedo questo:
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
Come questione di JBQ interesse (Jean Baptiste Queru - il 'capo' per gestire/distribuire la fonte da Google), il suo passo di costruzione è questo ...
make -j32
Yup! 32 core! Quello ... è piuttosto potente.
stavo cercando questo !, ottima risposta! – DGomez
Sai, qualche documentazione che posso leggere per iniziare con questa roba? – DGomez
Questo non può essere più utile. Grazie. – korro