Configuración del dispositivo Android para AOSP

Descargué el código fuente de Android. Ahora quiero hacerlo para mi propio dispositivo (LG GT540). Escuché que necesitas crear alguna ‘configuración de dispositivo’ para eso. Aunque varios desarrolladores ya han creado configuraciones de dispositivos para mi dispositivo, pero quiero crear las mías, solo para aprender.
Vi muchos archivos como BoardConfig.mk, AndroidProducts.mk, etc. Pero no sé lo que hacen. Además contienen muchas configuraciones. Sobre eso, no hay una buena documentación para eso.
¿Puede alguien con experiencia en portar Android y configuraciones de dispositivos ayudarme?

Correcto … Entonces, si desea construir su propio árbol de dispositivos, siga leyendo.

Descargo de responsabilidad: esto de ninguna manera es completo, y habrá omisiones que me han explicado toda esta parte superior de mi cabeza y he copiado ciertos fragmentos que tengo aquí en mi propio árbol de dispositivos.

El árbol de dispositivos, por ejemplo, /device/lg/gt540 constará de los siguientes archivos make:

  • Android.mk : esto le indicará al sistema de comstackción que incluya y cree fonts específicamente para su dispositivo. Vea a continuación, para un ejemplo. Esto depende del dispositivo y del hardware, puede tener libsensors, liblights, subdirectorios libcamera en el árbol de dispositivos de ejemplo, es decir, /device/lg/gt540/libsensors , /device/lg/gt540/liblights , /device/lg/gt540/libcamera etc.
  • AndroidBoard.mk : esto es para el núcleo, el sistema de comstackción lo usa para colocar la imagen del núcleo en su lugar (más sobre esto en unos pocos minutos)
  • AndroidProducts.mk : especifica el archivo de creación del dispositivo apropiado, para usarlo en la construcción. es decir, /device/lg/gt540/device_gt540.mk , esto también es específico.
  • device_xxxxx.mk – especifica las propiedades y los extras para copiar en el resultado final, en este caso, podría ser, por ejemplo, device_gt540.mk
  • BoardConfig.mk : este es el meollo de todo, aquí es donde se establecen los indicadores condicionales del comstackdor, los diseños de partición, las direcciones de arranque, el tamaño del ramdisk, etc.

Echemos un vistazo a cada uno de ellos para echar un vistazo a dónde encaja todo.

Android.mk:

 ifeq ($(TARGET_BOOTLOADER_BOARD_NAME),xxxxx) include $(call all-named-subdir-makefiles, recovery libsensors liblights libcamera ....) endif 

Así es como la construcción usará eso para construir recuperación, sensores, luces y cámara (por supuesto que habrá más), es decir ‘ Yo Builder, ve a cada uno de los directorios especificados, y construye las fonts 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 esto, le está diciendo al sistema de comstackción, que sea capaz de dejar caer este kernel en out/target/product/lg/gt540 (¿notará la correlación con el directorio del árbol del dispositivo?)

AndroidProducts.mk:

 PRODUCT_MAKEFILES := \ $(LOCAL_DIR)/device_gt540.mk 

Está diciendo la comstackción como en ‘ Yo Builder, lea ese dispositivo y haga el archivo por favor y trátelo una vez que se complete la comstackció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 del dispositivo, como los controladores, las bibliotecas propietarias, los scripts de soporte específicamente para el dispositivo, se copian a out/target/product/lg/gt540/system/ en este caso. Observe cómo las anulaciones para las propiedades, estas terminan en el build.prop encontrado 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 

Ese es un extracto, observe cómo especificamos la dirección base del kernel, así es como se genera el boot.img después de que se realiza la comstackción y, una vez más, se coloca en out/target/product/lg/gt540/boot.img . Además, lo que es más importante, le estamos diciendo al sistema de comstackción que use la plataforma de destino para la comstackción cruzada de las fonts (* TARGET_BOARD_PLATFORM * / * TARGET_CPU_ABI *) Habrá más información allí, como indicadores condicionales para pasar al comstackdor, para un ejemplo. especificamos la directiva HAVE_FM_RADIO para indicarle, cuando se trata de manejar la fuente para el sistema de radio FM, comstackr condicionalmente partes de la fuente. 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 comstackr 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 el vendor/ parte de él, en AOSP, simplemente, una vez más, la correlación y se corresponde con el device/ árbol, como al 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 fonts 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 la magia ocurre haciendo lo siguiente:

 . build/envsetup.sh 

Esto es leer las entradas completas que se encuentran en cada uno de los device/ subdirectorios y “recordarlos”, por lo que el sistema de comstackción sabe qué tipo de objective se utiliza, etc.

Cuando el . lunch se invoca el . lunch , aparece un menú que le pide que elija el dispositivo que se requiere para comstackr. Ahora el último y último paso para hacer la comstackción …

 make -j5 > buildlog.log 2>&1 

multitail en otra terminal y buildlog.log archivo buildlog.log para verificar y asegurar su construcción.

Este último paso dependerá de cuántos núcleos tenga (n núcleos + 1 como regla) y tardará un tiempo en comstackrlo, la comstackción GB tarda 40 minutos en mi computadora portátil ejecutando Arch Linux 64 bits, la comstackción ICS tarda aproximadamente 2 horas y 30 minutos. Por lo tanto, el kilometraje variará según el tipo de potencia que tenga su máquina.

Cuando termina la comstackción, suena una pequeña campana 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 interés JBQ (Jean Baptiste Queru – el ‘jefe’ para gestionar / distribuir la fuente de Google), su paso de construcción es este …

 make -j32 

¡Sip! 32 núcleos! Eso ….. es bastante poderoso.

Hay información aquí: http://elinux.org/Android_Device

Un recurso excelente para cualquier persona que construya Android para un dispositivo está aquí: http://com.odroid.com/sigong/nf_file_board/nfile_board_view.php?bid=98

(Un enfoque práctico en el mundo real para el desarrollo de la plataforma Android en ODROID)

Aunque algunas de las cosas allí incluidas son específicas de la placa ODROID, aún ofrecen una gran idea del funcionamiento interno de Android y la personalización necesaria para una nueva placa.

Si está buscando entrar en el lado del hardware de las cosas, probablemente el recurso más informativo que he encontrado ha sido:

http://source.android.com/compatibility/overview.html

Lea la documentación que escribieron para los fabricantes que buscan construir dispositivos con Android, es la referencia más completa / completa que encontrará.