Développement et portage d'une ROM

[azuss]

Ce sujet s'adresse principalement aux devs, rom customiseurs, etc.

 

J'ai eu envie de me mettre au développement de ROM sur android, et donc sur mon Cink Five. Pour commencer light, je me suis fixé comme objectif de bidouiller des roms déjà existantes.

Mon challenge personnel : réussir à créer une ROM flashable, à partir du backup de la ROM du cynus T5 (trouvé ICI) ROM stock donc pour commencer, deodexed et zipalign.

En fouinant sur le net à la recherche de tutos, j'ai décidé de me servir d'android kitchen de dsixda, voilà ce que j'ai fait pour l'instant :

J'ai créé un projet à partir du dossier /system, kitchen m'a généré un META-INF, j'ai ensuite inséré le boot.img contenu dans le backup (du cynus T5), j'ai deodexed les applis, zipalign toussa toussa. Le hic c'est que le update-script généré foire à l'installation de la ROM. J'ai donc copié bêtement l'update-script de la ROM paper HD de mathSGA (la rom étant aussi basé sur le cynus T5). Mais la aussi ça foire, status 7, erreur sur le set_perm de busybox.

Je pense que j'ai dû oublié des truc, mais bon c'est le flash qui plante.

Donc voilà ce que j'ai essayé : 

dé-zippé et re-zipper la paper HD (on sait jamais) flash OK

j'ai remplacé les app/ et framework/ de la paper HD par les miennes obtenues après deodexedisation (new word :)) des apk du backup ben ça re merdouille... 

 

Suite à de multiples essais je viens vers vous, oh grand customiseurs de ROM, partagez donc votre savoir et enseignez moi/nous ce qu'il y à savoir sur le portage de ROM d'autres clône du cink five.

 

L'utilisation de android kitchen est-elle nécessaire ? (l'utilisez vous ?)

Car personnellement je suis plus pour expérimenter par moi même, quitte à créer les scripts nécessaires, etc.

 

J'ai aussi vu plusieurs update-script différent, surtout au niveau des points de montages. Qu'elle est la méthode la plus approprié pour monter les dossiers (partition ?) qui vont bien ? Celle avec busybox à l'air plus simple, j'ai aussi vu un truc dans le genre :

mount("ext4", "EMMC", "/dev/block/mmcblk0p5", "/system"); à quoi correspondent les block ?

 

Voilà voilà je crois que c'est tout, j'ai bien sûr cherché pour trouver toutes ces informations. C'est que le NET est imense, et google n'est pas beaucoup mon ami sur ce sujet. (résultats peu pertinants).

 

Bref, ce sujet à pour but d'éclairer mes lanternes (et ceux des personnes qui comme moi veulent se frotter au ROM making). Je cherche avant tout à apprendre.

 

Ah oui dernière question, android kitchen avec cygwin... Pour le développement de ROM en générale, c'est mieux sous unix nan ? (Vous développez vos ROM sur quel OS ?).

 

[mathSGA]

l'updater-script utilise plusieurs méthodes pour écrire les données.

Soit tu spécifies les /dev/block en fonction de ce qui est établi par le constructeur dans la ROM d'origine (tu peux obtenir ça avec le scatter d'origine, en utilisant MTK Droid Root Tools)

Soit tu laisses le recovery déterminer les bons "block" à utiliser

En gros, il faut être sur de ne pas écrire au mauvais endroit et donc avoir un recovry bien adapté au téléphone !

 

Dans ton cas, tu as des erreurs au niveau du réglage des permissions, parce que dans l'updater-script il y a des références à des fichiers qui ne sont pas présents dans le système que tu veux créer à flasher.

Dans les ROMs que j'ai publié, il y a en général activé la fonction pour flasher des données dans la partition /DATA, ce qui n'est pas obligatoire mais peut être très pratique. Si tu n'utilises pas cette fonction dans la ROM que tu veux générer, il faut que tu supprimes ces parties dans ton updater script :

show_progress(0.1, 0);
ui_print(" montage de /data et /cache");
run_program("/sbin/busybox", "mount", "/cache");
run_program("/sbin/busybox", "mount", "/data");
ui_print(" effacement de /cache et Dalvik-cache ");
delete_recursive("/cache");
delete_recursive("/data/dalvik_cache");
ui_print(" installation des fichiers dans /data ");   < -- A PARTIR D'ICI
package_extract_file("check_data_app", "/tmp/check_data_app");
set_perm(0, 0, 0777, "/tmp/check_data_app");
run_program("/tmp/check_data_app");
package_extract_dir("data", "/data");
set_perm(2000, 2000, 0771, "/data/local");
set_perm_recursive(1000, 1000, 0771, 0644, "/data/app");

Bref, à toi d'adapter selon le contenu de ta ROM, le script renverra une erreur des qu'il va rencontrer des références qui sont absente dans ton ZIP à flasher.

pour le choix de l'OS de développement, en théorie oui, linux c'est bien. Mais Android Kitchen utilise essentiellement JAVA (donc ça marche bien sous Windows), et pas mal d'outils comme Winmerge, Notepad++ sont très pratiques sous Windows.

Au final c'est plus une question d'habitude à ce niveau là. Il n'y a pas de nécessité absolue d'être en environnement unix pour modifier une ROM. Ce n'est nécessaire que pour compiler Android depuis les sources AOSP / Cyanogen etc

[azuss]

Ok, merci d'avoir pris le temps de me répondre. Je vais refaire une tentative, sinon pour le portage d'une rom (celle du cynus t5 en l'occurrence), Faut-il copié des fichiers du WCF dans la ROM ou il est possible de faire fonctionner la ROM comme ça ? (juste avec les apks / scripts / etc du cynus T5)

[mathSGA]

tu n'as rien à modifier dans la ROM du cynus T5 pour qu'elle fonctionne sur WCF.

Il faut juste system et boot.img et un update-binary + updater-script valides

 

Pour des stock ROMs d'autres smartphones basées sur un MT6589, ça va dépendre. L'avantage du Cynus T5 c'est que quand cette ROM a été compilée, les développeurs ont du activer les modules de pas mal d'autres smartphones similaires ce qui fait que tout fonctionne sur nos WCF, bien qu'il y ait quelques différences matérielles. Sur d'autres ROMs de smartphone en théorie plus proches de notre WCF, la compilation a du être plus strict et parfois, bien qu'il y ait très peu de différence, le fonctionnement n'est pas aussi bon.

[azuss]

C'est bon j'ai réussi à flasher, merci à toi !

Le tout fonctionne bien, plus qu'à tweaker 2,3 trucs.

[jonathan974]

salut, n’oublie pas de posté je jouerai bien au bêta testeur, une question a MathSGA est il possible d'activer les compte utilisateur comme pour android 4.3 ?

[mathSGA]

réponse rapide : non

réponse un peu plus longue : c'est une option disponible uniquement pour les tablettes. Je ne pense pas qu'on puisse débrider cette fonction juste avec un simple mod au niveau framework ou application, ça doit tout simplement être absent des binaires disponibles pour notre plateforme.

[azuss]

J'ai une autre question, si je fais un format data (format("ext4", "EMMC", "/dev/block/mmcblk0p7"); ) cela supprime aussi le dalvik cache ? (puisqu'il est dans data)

 

J'ai aussi vu des cas ou les gens faisait un delete_recursive("/data/dalvik-cache"); puis un delete_recursive("/data");

[mathSGA]

Le format avec block, si tu n'es pas sûr d'être sur les bons blocks (selon le schéma de partition du recovery) risque de formater des zones de mémoire qu'il ne faut pas formater.

Le delete recursive suppose que la partition soit montée au bon endroit. Donc à partir du moment où tu arrives à monter /data tu sais que tu effaces les bonnes choses à effacer. C'est donc moins risqué.

[azuss]

Et un delete_recursive("/data"); supprime aussi le dalvik cache ?

[jonathan974]

réponse rapide : non

réponse un peu plus longue : c'est une option disponible uniquement pour les tablettes. Je ne pense pas qu'on puisse débrider cette fonction juste avec un simple mod au niveau framework ou application, ça doit tout simplement être absent des binaires disponibles pour notre plateforme.

 

Merci pour cet réponse aussi rapide, c'est dommage qu'une fois arriver a la maison le tel ne peut pas séparé automatiquement la vie pro et personnelle, et surtout de réglementé le tel pour l'usage des enfant. Peut être dans les prochaine versions.

[mathSGA]

Et un delete_recursive("/data"); supprime aussi le dalvik cache ?

oui. Après jene sais pas si c'est si bien que ça de forcer l'effacement de /data C'est le meilleur moyen d'être sûr de perdre les infos IMEI et autres (sur nos smartphones low cost) c'est plus sûr de faire du delete recursive sur les dossiers que tu veux vider pour ne pas interférer avec le contenu de la ROM que tu flash

[azuss]

oui. Après jene sais pas si c'est si bien que ça de forcer l'effacement de /data C'est le meilleur moyen d'être sûr de perdre les infos IMEI et autres (sur nos smartphones low cost) c'est plus sûr de faire du delete recursive sur les dossiers que tu veux vider pour ne pas interférer avec le contenu de la ROM que tu flash

D'accord, enfin après dans la majorité des rom de ce forum, il est conseillé de faire un full wipe (factory reset) sur cwm (ce qui supprime les data il me semble). Avec la cynus mes IMEI sont bien ceux de mon WCF (sans restaurer le nvram).

[mathSGA]

Wipe quand tu installes une nouvelle ROM. Mais si tu veux juste mettre à jour ou réinstaller sans perdre ta conf, si le format est forcé dans ton zip, tu ne peux plus...