Configuration d’appareil Android pour AOSP

J’ai téléchargé le code source Android. Maintenant, je veux le faire pour mon propre appareil (LG GT540). J’ai entendu dire que vous deviez créer une configuration de périphérique pour cela. Bien que plusieurs développeurs aient déjà créé des configurations de périphérique pour mon appareil, mais je veux créer les miens, juste pour apprendre.
J’ai vu beaucoup de fichiers comme BoardConfig.mk, AndroidProducts.mk, etc. Mais je ne sais pas ce qu’ils font. En outre, ils contiennent beaucoup de configurations. De plus, il n’y a pas de bonne documentation pour cela.
Quelqu’un peut-il expérimenté avec le portage Android et les configurations de périphérique m’aider?

Right … Donc, vous voulez créer votre propre arborescence de périphériques, lisez la suite.

Déni de responsabilité: ce n’est en aucun cas complet, et il y aura des omissions, car ils ont expliqué tout ce qui me préoccupe et copié certains bits que j’ai ici sur mon propre arbre.

L’arborescence des périphériques, par exemple, /device/lg/gt540 , comprendra les fichiers make suivants:

  • Android.mk – cela indiquera au système de construction d’inclure et de créer des sources spécifiquement pour votre appareil. Voir ci-dessous, pour un exemple. Cela dépend du périphérique et du matériel, vous pouvez avoir des sous-répertoires libsensors, liblights, libcamera sous l’exemple de l’arborescence des périphériques, à savoir /device/lg/gt540/libsensors /device/lg/gt540/liblights /device/lg/gt540/libcamera etc.
  • AndroidBoard.mk – ceci est pour le kernel, le système de compilation utilise cela pour supprimer l’image du kernel (plus de détails en quelques minutes)
  • AndroidProducts.mk – spécifie le fichier de création du périphérique à utiliser pour la construction. c’est-à-dire /device/lg/gt540/device_gt540.mk , cela est également spécifique.
  • device_xxxxx.mk – spécifie les propriétés et les extras à copier dans la sortie finale, dans ce cas, cela peut être, par exemple, device_gt540.mk
  • BoardConfig.mk – C’est tout cela, c’est là que sont définis les indicateurs conditionnels du compilateur, les dispositions de partition, les adresses de démarrage, la taille du disque virtuel, etc.

Jetons un coup d’œil à chacun d’eux pour voir où tout s’intègre.

Android.mk:

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

Voici comment la génération va l’utiliser pour construire la récupération, les capteurs, les lumières et la caméra (bien sûr, il y en aura d’autres), en disant ” Yo Builder, allez dans chacun des répertoires spécifiés, et construisez les sources respectives 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) 

Maintenant, cela dit au système de compilation, de pouvoir déposer ce kernel dans le out/target/product/lg/gt540 (notez la corrélation avec le répertoire de l’arborescence?)

AndroidProducts.mk:

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

Son rappel de la construction comme dans ‘ Yo Builder, lisez ce fichier s’il vous plait et traitez-le à la fin de la construction.

* device_xxxxx.mk: (pour cet exemple, 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 ... 

C’est ici que toutes les spécificités du périphérique, telles que les pilotes, les bibliothèques propriétaires, les scripts prenant en charge spécifiquement le périphérique, sont copiées out/target/product/lg/gt540/system/ dans ce cas. Notez comment les substitutions pour les propriétés, celles-ci se retrouvent dans le build.prop trouvé dans la racine du /system de la 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 

Ceci est un extrait, notez comment nous spécifions l’adresse de base du kernel, c’est comme ça que le boot.img est généré après la compilation et encore une fois, il est déposé dans out/target/product/lg/gt540/boot.img . De plus, plus important encore, nous disons au système de compilation d’utiliser la plate-forme cible pour la compilation croisée des sources (* TARGET_BOARD_PLATFORM * / * TARGET_CPU_ABI *). Il y aura plus d’informations telles que les indicateurs conditionnels à transmettre au compilateur, pour un exemple. Nous avons spécifié la directive HAVE_FM_RADIO pour lui indiquer, lorsqu’il s’agit de gérer la source du système radio FM, de comstackr certaines parties de la source de manière conditionnelle. Encore une fois, ceci est spécifique au matériel et le kilométrage varie, cela s’applique également à l’adresse de démarrage. En un mot, cela signifie ” Yo Builder”, lisez les fichues variables et mémorisez-les et appliquez-les lors de la compilation croisée de ces fichiers sources!

Maintenant que les composants internes de chacun de ces fichiers de compilation Android sont affichés.

Maintenant, sur la partie vendor/ , dans AOSP, une fois de plus, une fois encore, la corrélation correspond à l’ device/ arbre, comme dans l’exemple suivant, vendor/lg/gt540/ qui est pris en compte lors du lunch . Il y a plus de fichiers de création ici, mais le consensus général est qu’il y a un répertoire appelé proprietary qui contient les libs propriétaires (à cause de sources proches, etc.) qui sont copiées. La copie des bibliothèques est spécifiée dans le fichier device-vendor-blobs.mk , dans ce cas, gt540-vendor-blobs.mk .

Lorsque la magie se produit en procédant comme suit:

 . build/envsetup.sh 

Ceci lit les entrées entières trouvées dans chacun des device/ sous device/ répertoires et “s’en souvient”, donc le système de construction sait quel type de cible est utilisé, etc.

Quand le . lunch . lunch est invoqué, un menu apparaît vous invitant à choisir le périphérique à construire. Maintenant la dernière et dernière étape pour faire la construction …

 make -j5 > buildlog.log 2>&1 

Je lance multitail sur un autre terminal et surveille le fichier buildlog.log pour vérifier et vérifier sa construction.

Cette dernière étape dépendra du nombre de cœurs que vous avez (n cores + 1 en règle générale) et la construction prend quelques minutes sur mon portable sous Arch Linux 64 bits, la version ICS prend environ 2h30. Le kilométrage varie donc selon le type de puissance de votre machine.

Lorsque la construction est terminée, une petite cloche s’éteint et au bas du fichier journal, je vois ceci:

 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 

Comme point d’intérêt, JBQ (Jean Baptiste Queru – le «patron» de la gestion / dissortingbution de la source de Google), son étape de construction est la suivante …

 make -j32 

Ouaip! 32 cœurs! C’est ….. assez puissant.

Il y a quelques informations ici: http://elinux.org/Android_Device

Une excellente ressource pour quiconque construit Android pour un périphérique est ici: http://com.odroid.com/sigong/nf_file_board/nfile_board_view.php?bid=98

(Une approche pratique du développement de plates-formes Android sous ODROID)

Bien que certains éléments soient spécifiques à la carte ODROID, ils offrent néanmoins un aperçu intéressant du fonctionnement interne d’Android et de la personnalisation nécessaire pour une nouvelle carte.

Si vous cherchez à vous familiariser avec le matériel, la ressource la plus informative que j’ai trouvée a été:

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

Lisez la documentation qu’ils ont écrite pour les fabricants cherchant à créer des appareils Android, c’est la référence la plus complète / complète que vous trouverez.