B2G OS est traditionnellement construit sur une base AOSP. Cependant, cela ne signifie pas que nous devons utiliser uniquement AOSP. Il en existe plusieurs forks qui ont pour objectif de supporter une gamme de matériel plus large. CyanogenMod, le plus populaire des forks d'AOSP, comporte des milliers d'ajouts, modifications, et bidouilles pour prendre en charge des centaines d'appareils Android du commerce. Cet article explique comment porter Firefox en utilisant CyanogenMod.
En construisant B2G OS sur une base CyanogenMod, il devient potentiellement possible de supporter autant d'appareils que le fait ce système. En raison de la multiplicité des appareils supportés par CyanogenMod, il est hautement probable que vous en ayez déjà un sur lequel il peut être compilé !
Si vous n'avez jamais construit CyanogenMod pour votre appareil, nous vous conseillons fortement d'apprendre comment le faire avant de porter B2G OS. Cela pour deux raisons : vous apprendrez à utiliser les outils nécessaires au portage de B2G OS, et vous vérifierez la qualité du portage de CyanogenMod.
Pour être plus clair : ce guide part du principe que votre appareil est déverrouillé et que CyanogenMod est installé dessus. Ce guide ne va pas vous apprendre à rooter et/ou déverrouiller votre appareil, ni à mettre en place votre machine de compilation ou utiliser git pour résoudre des échecs de fusion.
Voici un résumé des étapes :
- Télécharger le code source
- Modifier les dépôts de l'appareil
- Modifier le noyau
- Compiler et installer
Télécharger le code source
Nous disposons de plusieurs outils utiles pour compiler B2G OS, tous contenus dans un unique dépôt. Téléchargez ces outils via git pour créer votre répertoire de travail.
git clone https://github.com/cm-b2g/B2G.git && cd B2G
À présent, nous devons télécharger le code source.
./config.sh cm-porting
Le script config.sh initialise l'outil repo en utilisant le manifeste base-l-cm.xml situé dans le dépôt b2g-manifest. Ce fichier XML est une liste de dépôts spécifiques à l'OS nécessaires à la compilation de B2G OS. Il fait ensuite appel à l'outil repo pour télécharger la totalité du code source.
Le téléchargement de tous ces dépôts, dont certains font plusieurs giga-octets, va prendre un certain temps, il est donc recommandé de le faire pendant la nuit si la connexion est lente, ou juste avant manger si la connexion est plus rapide.
Cette étape va également créer un fichier .config qui devra être éditer plus tard.
Manifeste local pour votre appareil
Le manifeste susmentionné ne contient aucun dépôt spécifique pour les appareils, ce qui diffère d'un manifeste classique. Nous avons besoin de créer un fichier local_manifest.xml avec tous les dépôts pour votre appareil. La manière la plus rapide de le faire consiste à utiliser breakfast, un outil automatisé écrit par CyanogenMod pour créer un manifeste local et télécharger les dépôts supplémentaires directement depuis le compte GitHub de CyanogenMod.
. build/envsetup.sh && breakfast 123
Remplacez 123 par le nom de code de votre appareil.
Si votre appareil n'est pas officiellement supporté par CyanogenMod mais qu'il existe un portage non officiel, vous pouvez créer manuellement le fichier local_manifest.xml dans le dossier .repo/local_manifests. Un exemple est donné plus bas.
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="xyz" fetch="git://github.com/xyz/" revision="cm-12.1" />
<project name="device_oem_123" path="device/oem/123" remote="xyz" />
<project name="device_oem_1xx-common" path="device/oem/1xx-common" remote="xyz" />
<project name="kernel_oem_1xx" path="kernel/oem/1xx" remote="xyz" />
<project name="vendor_oem" path="vendor/oem" remote="xyz" />
</manifest>
Rappelez-vous d'exécuter repo sync après avoir créé votre manifeste !
Modifier les dépôts de l'appareil
Une partie de la configuration des appareils se trouve dans des fichiers overlay XML utilisés par le système de compilation d'AOSP pour définir les options par défaut des applications Android. Comme B2G OS ne les utilise pas, il faut donc réimplémenter certaines de ces options, comme le bouton d'accueil, le stockage émulé etc.
Il est possible de définir les options par défaut les plus raisonnables en incluant deux fichiers issus de vendor/cm. La première ligne doit être ajoutée au début de device.mk et la seconde à la fin de BoardConfig.mk:
# Extra mk import at the top of device.mk
$(call inherit-product, vendor/cm/config/common_full.mk)
# Extra mk import at the bottom of BoardConfig.mk
include vendor/cm/BoardConfig.mk
D'autres options sont encore nécessaires car beaucoup sont très spécifiques au matériel. Voici ci-dessous une liste des ajouts et suppressions habituels spécifiques aux appareils. Cette liste n'est pas exhaustive, mais l'ajout des deux lignes citées plus haut et définir tout ce qui suit vous donnera un système fonctionnel.
# for Gecko to use the correct resolution assets
# Valid options are: 1.5 | 2 | 2.25
GAIA_DEV_PIXELS_PER_PX := 2.25
# for Gecko to use the correct boot animation
# Valid options are: hvga | fwvga | qHD | 720p | 1080p
BOOTANIMATION_ASSET_SIZE := 1080p
# for Gecko to support separate internal storage partition
# This is for legacy devices only. You must prvide your own volume.cfg file
GECKO_BOARD_SEPARATE_STORAGE_PARTITON := true
# for Gecko to support virtual home button
PRODUCT_PROPERTY_OVERRIDES += \
ro.moz.has_home_button=0
# for Gecko to support usb mass storage
# You may need to add mass_storage to init.oem.usb.rc
PRODUCT_DEFAULT_PROPERTY_OVERRIDES += \
- persist.sys.usb.config=mtp
+ persist.sys.usb.config=mass_storage
# for Gecko to support NFC
PRODUCT_PROPERTY_OVERRIDES += \
ro.moz.nfc.enabled=true
PRODUCT_PACKAGES += \
nfcd
# Changes in init.device.rc
-on property:init.svc.bootanim=running
-on property:init.svc.bootanim=stopped
-on property:service.bootanim.exit=1
+on property:sys.boot_completed=1
Modifier le noyau
B2G OS a besoin d'avoir certaines fonctionnalités de sécurité supplémentaires activées dans le noyau. Jusqu'à Marshmallow, ces fonctionnalités étaient absentes des noyaux Android, quelques patches supplémentaires devront donc être rétroportés sur le noyau pour de nombreux appareils. Pour référence, consultez Bugzilla: 790923.
Il suffit de faire le tri dans les patches pour votre noyau ; le système de construction va automatiquement activer les nouvelles fonctionnalités. Pour un exemple fonctionnel, voir le noyau LGE MSM8994.
Compiler et installer
Vous vous souvenez du fichier .config créé précédemment ? Il faut maintenant remplacer cm-porting par le nom de code de votre appareil.
$ grep -r PRODUCT_NAME device/oem/123
Note : n'utilisez pas la valeur dans cm.mk, utilisez celle de device.mk, elle devrait ressembler à quelque chose du genre full_123. Vous pouvez effectuer le remplacement à la main, ou le faire simplement avec sed :
$ sed -i "s/cm-porting/full_123/g" .config
À présent, il est temps de lancer la compilation !
$ ./bldcm.sh
Cela va prendre dans tous les cas de 30 minutes à deux ou trois heures, en fonction de votre PC, ça peut donc être le bon moment pour aller faire les magasins ou acheter un peu de popcorn.
Installation de B2G OS via fastboot
Dans le cas où votre appareil supporte fastboot, il est possible de flasher directement les images de partition :
cd out/target/product/123/
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot flash system system.img
fastboot flash userdata userdata.img
Installation de B2G OS via recovery
Si votre appareil ne supporte pas fastboot, vous pouvez alors utiliser update.zip ià la place. Celui-ci peut être installé sur l'appareil en copiant le zip sur une carte SD ou via adb sideload. Entrez en mode recovery selon la méthode spécifique à votre appareil puis tapez :
adb sideload out/target/product/123/fota/fullimg/update.zip
Dépannage
Quelque chose ne fonctionne pas ? Il est temps de retrousser ses manches !
Essayez tout d'abord de déterminer si la fonctionnalité est disponible dans CyanogenMod. Il pourrait s'agir simplement d'une configuration manquante dans B2G OS.
Si ça ne fonctionne pas sur CyanogenMod, cela signifie alors que vous devez l'implémenter dans votre portage. Cela serait utile de soumettre votre correctif en amont également !
Appareils 64bits
La plupart des appareils fabriqués depuis mi-2015 intègrent un SoC 64 bits. B2G ne peut pas être construit sous la forme d'un exécutable 64 bits mais heureusement les exécutables 32 bits fonctionnent. Nous pouvons forcer la construction de B2G en 32 bits avec deux correctifs situés dans le bogue #1245088.
Après cela, il suffit de définir :
BUILD_MULTILIB_GECKO_AS_2ND_ARCH := trueAppareil photo
Certaines parties d'Android ont été retirées du processus de construction car elles ne sont pas nécessaires. Si le blob de l'appareil photo signale des fonctions manquantes, vérifiez frameworks/base pour voir si celles-ci ont été supprimées. Il peut être possible de les réintégrer.
WiFi
L'appareil peut ne pas voir certains points d'accès s'ils utilisent des canaux non officiels. Il semble que cela soit un problème de CyanogenMod ou même d'AOSP car différents matériels et fabricants sont concernés.