- NI GÉNÉRATION MOBILES NI MOI-MÊME NE SERONT TENUS POUR RESPONSABLE EN CAS DE DOMMAGE SUR VOTRE APPAREIL ANDROID - /!\ Un Nandroid Backup est fortement recommandé avant toute modification /!\

Présentation & Objectifs

Quand on flashe une ROM Custom, on peut vouloir ajouter ou supprimer des applications avant même que le premier démarrage de la ROM ne soit fait.
Il est évidemment possible de geler, d'ajouter ou de désinstaller des applications systèmes manuellement une fois la ROM Custom installée mais c'est trop long et répétitif.
Un Zip flashable permet de faire beaucoup de choses et une fois bien configuré, vous êtes tranquille pour plusieurs flashs de ROMs.

Pour vous mettre dans l'ambiance, voilà en résumé ce que fait le mien :

1. Installation script AFWall+, Viper4Android, de sauvegarde et configuration
2. Installation/Suppression d'applications système : Viper4Android, BBS, Blankstore
3. Installation/Suppression de fichiers : gps.cong, hosts.og, hosts.alt
4. Modification de fichiers : audio_policy, build_prop
5. Tout ça est automatiquement maintenu lors d'un dirty flash (mise à jour ROM sans effacer les données utilisateur)

Pré-requis

Il faut 4 choses :
1. Un bon gestionnaire de fichiers fiable. Je vous recommande Solid Explorer ou MiXplorer.
2. ZipSigner pour signer votre fichier zip final.
3. Un Nandroid backup via le TWRP Recovery pour revenir en arrière en cas de soucis.
4. Du temps. Il vous faudra faire quelques tests pour expérimenter cet outil et surtout le personnaliser selon vos besoins.

---

Je vais vous proposer différents exemples pour expliquer comment je fais. Cela devrait vous donner des idées et vous aider à comprendre les différentes étapes à suivre. Ces fichiers doivent être flashés en dernier (après la rom, les GApps, le kernel custom, etc...) /!\ FICHIERS SCRIPT : LES ESPACES SONT INTERDITS EN FIN DE LIGNE /!\ Si vous souhaitez aller dans le détail, je vous invite à lire ceci.

---

Structure du zip flashable

Voilà à quoi ressemble l'organisation de mes fichiers :



Pour simplifier la visualisation, je n'ai pas indiqué le dossier META-INF. Ce dernier englobe plusieurs fichiers, seul le fichier updater-script nous intéressera.

Téléchargement

→ Modèle_vide : C'est un fichier avec les fichiers obligatoires. À vous de le compléter si vous voulez partir de zéro. D'autres fichiers sont téléchargeables pour chaque exemple.
→ ExempleX : le zip flashable correspondant à chaque exemple
→ Primokorn-signed.zip : le fichier que j'utilise actuellement. Ne pas flasher. C'est juste à titre d'exemple et pour mieux expliquer le schéma présenté précédemment.
Désormais, un seul fichier : mon zip flashable que j'utilise actuellement. Ne le flashez pas si vous ne savez pas ce qu'il fait !



Scannez ou cliquez le QRCode pour télécharger l'appli


Note : tous les fichiers devraient fonctionner sur des appareils ARM. Si vous avez une architecture ARM64 ou x86, vous ne pourrez pas flasher ces fichiers. Remplacez le fichier updater-binary situé dans META-INF/com/google/android par celui d'une ROM custom qui fonctionne sur votre appareil.

Compresser et signer

Peu importe le contenu de votre zip flashable, vous devez le compresser et le signer, sinon TWRP vous indiquera un message d'erreur lors du flash.

1. On sélectionne les dossiers et on les compresse (Zip et compression "Aucune")


2. Le fichier .Zip est créé


3. On ouvre ZipSigner, on sélectionne le fichier Zip créé et le chemin de destination, puis le type de clé


4. Le fichier "xxxx-signed.zip" est prêt à être flashé depuis le recovery

Exemple 1 : Supprimer des applications système

Dans ce cas, on va voir comment supprimer des applications système.
Ce Zip ne fonctionne qu'une fois. Autrement dit, les applications seront réinstallées si on reflashe la ROM Custom (lors d'une mise à jour par exemple). Pour éviter cela, il faut créer un script de sauvegarde qui va empêcher leur réinstallation.
Note : il est aussi possible de reflasher ce fichier Zip à chaque mise à jour de la ROM mais on perd un peu le côté "automatisé".

Tout se passe dans le fichier updater-script :



Enregistrez le fichier, qui se trouve dans /META-INF/com/google/android/updater-script.
Compressez le dossier META-INF au format .zip et signez-le avec ZipSigner.

Exemple 2 : Ajouter des applications système

Les choses se complexifient un petit peu.
C'est un peu le même principe que l'Exemple 1, les applications disparaîtront dès lors que vous reflashez la ROM custom. Un script de sauvegarde est donc le bienvenu.

Il y a deux étapes à respecter : préparer les dossiers et créer le updater-script.

1. Préparation des dossiers
Les applications système sont stockées dans /system/app/ ou /system/priv-app/. Dans mon précédent schéma, on voit que j'ajoute 3 applications dans /system/priv-app/ : Blankstore, Viper4Android et BetterBatteryStats.

À la racine de votre répertoire (au même niveau que META-INF/), créez un dossier system, puis un autre priv-app. À l'intérieur, vous pouvez soit mettre directement des fichiers .apk, soit mettre les apks dans des dossiers spécifiques pour chaque application.

On cherche à reproduire l'emplacement des dossiers et fichiers, comme si ils étaient dans le "vrai" répertoire. C'est simple à faire mais difficile à expliquer lol
Ça vous parlera peut-être plus comme ça :



2. Création du "updater-script"
Pour rappel, le fichier se trouve dans /META-INF/com/google/android/updater-script.

C'est ce fichier qui dit au recovery ce qu'il doit faire. En gros, il faut lui demander d'injecter les applications dans le bon répertoire et de définir les permissions. Comme vous le savez probablement, les dossiers et fichiers système doivent avoir les bonnes permissions. Donner trop de permissions peut être dangereux, ne pas en donner assez peut provoquer des redémarrages en boucle ou des dysfonctionnements.



Enregistrez le fichier, qui se trouve dans /META-INF/com/google/android/updater-script.
Compressez les dossiers META-INF et system au format .zip et signez-le avec ZipSigner.

Exemple 2 BIS - Autres installations système

Le principe est exactement le même pour l'ajout de nouveaux fichiers, ou pour écraser un fichier existant.

Prenons l'exemple de mon fichier /system/addon.d/81-Xposed.sh :
1. Je mets le fichier dans le bon répertoire
2. Vous pouvez reprendre updater-script. Il suffit de mettre un set_perm sur le fichier :

Tout le reste est identique (supprimez les autres set_perm si vous n'avez d'applications à installer).

Si on prend le cas du fichier /data/local/afscript.sh, le principe est le même que pour /system/addon.d/81-Xposed.sh. Il suffit de faire ces quelques changements :
→ set_perm : il est possible que les permissions soient différentes
→ La partition /system que l'on on monte ("mount") et que l'on démonte ("umount") doit être remplacée par /data.

- Note -

Si vous ajoutez des fichiers/applications à la fois dans la partition /system et dans la partition /data, alors il faut monter ("mount") et démonter ("umount") les deux partitions dans votre updater-script. (cf mon fichier "primokorn-signed.zip" pour exemple).

Exemple 3 : Modifier le contenu d'un fichier système existant

Il est aussi possible de seulement modifier une partie du contenu d'un fichier système. Le cas le plus classique, c'est le build.prop. Vous pourriez tout aussi bien modifier votre fichier hosts, le fichier de config du gps, etc...
Dans cette exemple, on va modifier la densité de l'écran. Passer de 480dpi à 400dpi, ça permet d'avoir un affichage plus petit sur son téléphone.

- Création du fichier -

1. Créez un nouveau fichier .sh, exemple modif.sh et mettez ceci sur votre 1ère ligne :


2. Pour modifier une ligne existante, on utilise la commande sed :

sed -i 's/valeur_originale/nouvelle_valeur/g' /emplacement_du_fichier;

Si on reprend notre exemple, on veut changer la densité de l'écran de 480 à 400. C'est la ligne ro.sf.lcd_density du fichier build.prop qui permet de la définir :

sed -i 's/ro.sf.lcd_density=480/ro.sf.lcd_density=400/g' /system/build.prop;

3. Pour ajouter une nouvelle ligne, on utilise la commande echo :

echo "nouvelle_valeur" >> /emplacement_du_fichier;

Exemple a écrit:

echo "IPA.decode=false" >> /system/build.prop;
echo "tunnel.decode=false" >> /system/build.prop;
echo "lpa.use-stagefright=false" >> /system/build.prop;

4. Une fois que vous avez défini vos lignes sed et echo, ajoutez-les dans votre fichier, à la 2e ligne (en dessous de #!/sbin/sh).

Exemple a écrit:

#!/sbin/sh
sed -i 's/ro.sf.lcd_density=480/ro.sf.lcd_density=400/g' /system/build.prop;
echo "IPA.decode=false" >> /system/build.prop;
echo "tunnel.decode=false" >> /system/build.prop;
echo "lpa.use-stagefright=false" >> /system/build.prop;

5. Placez votre fichier modif.sh dans le bon dossier (la même structure que le "vrai" fichier qui se trouve sur votre téléphone). Dans notre exemple, on le met à la racine du dossier system.

- Création du script -

6. On passe au updater-script


Enregistrez le fichier, qui se trouve dans /META-INF/com/google/android/updater-script.
Compressez les dossiers META-INF et system au format .zip et signez-le avec ZipSigner.

Dernière édition par Primokorn le Lun 12 Sep 2016 - 10:07, édité 30 fois

Script de sauvegarde / restauration pour dirty flash

Toutes les modifications ci-dessus sont bien sympa mais certaines seront supprimées dès lors qu'on flashe à nouveau la rom (lors d'une mise à jour par exemple).
Pour gagner du temps, on peut gérer un script de sauvegarde/restauration. Ce dernier va automatiser tout le processus. C'est le même principe que les GApps qui sont conservées.

Comme vous pouvez le voir dans mon schéma bleu du début, j'ai créé un fichier dans /system/addond.d/keepsupapks.sh (vous pouvez lui donner le nom que vous voulez).
Bien entendu, votre ROM doit supporter ce type de script (c'est le cas pour 99% des ROMs Custom je pense).

Voilà à quoi ressemble le mien :

On va regarder ça étape par étape.

- Conservation de fichiers -

list_files() {
cat <addon.d/keepsupapks.sh
priv-app/Viper4Android/V4A.apk
priv-app/BetterBatteryStats.apk
su.d/vib.sh
etc/gps.conf
etc/init.d/v4a
etc/hosts
EOF
}

Ici, je place tous les répertoires de fichiers que je souhaite conserver après la mise à jour. On met uniquement les fichiers personnalisés, ceux qu'on a ajouté après avoir flashé la ROM.
Je vous déconseille de conserver des fichiers qui sont susceptibles de beaucoup changer après une mise à jour. Un bon exemple à éviter, c'est le build.prop.

Dans mon cas, je conserve :
→ le script de sauvegarde (normal si on veut qu'il fonctionne pour la prochaine fois )
→ V4A.apk et BetterBatteryStats.apk : des applications perso (non fournies avec la ROM)
→ vib.sh : modification de l'intensité du vibreur
→ gps.conf : réglages perso du gps
→ v4a : commande root pour faire fonctionner V4A en mode Enforcing
→ hosts : fichier hosts selon source AdAway

- Maintien de suppression de fichiers et nouvelles suppressions -

rm -rf /system/priv-app/AudioFX
rm -rf /system/priv-app/CMLogger
rm -rf /system/priv-app/CyanogenStats
rm -rf /system/priv-app/DeviceManager
rm -rf /system/priv-app/KernelAdiutor
rm -rf /system/priv-app/OmniSwitch
rm -rf /system/priv-app/MusicFX
rm -rf /system/priv-app/Mms
rm -rf /system/priv-app/Trebuchet
rm -rf /system/priv-app/Tag
rm -rf /system/priv-app/Velvet
rm -rf /system/etc/hosts.og
rm -rf /system/etc/hosts.alt
rm -rf /system/app/Apollo
rm -rf /system/app/BasicDreams
rm -rf /system/app/BoxerCM
rm -rf /system/app/Browser
rm -rf /system/app/Calendar
rm -rf /system/app/Camera2
rm -rf /system/app/Chromium
rm -rf /system/app/CMFileManager
rm -rf /system/app/CMWallpapers
rm -rf /system/app/DeskClock
rm -rf /system/app/DocumentsUI
rm -rf /system/app/DSPManager
rm -rf /system/app/Eleven
rm -rf /system/app/Email
rm -rf /system/app/Exchange2
rm -rf /system/app/ExchangeServices
rm -rf /system/app/Galaxy4
rm -rf /system/app/Gallery2
rm -rf /system/app/Gmail
rm -rf /system/app/KernelAdiutor
rm -rf /system/app/HoloSpiralWallpaper
rm -rf /system/app/LatinIME
rm -rf /system/app/LiveWallpapers
rm -rf /system/app/LiveWallpapersPicker
rm -rf /system/app/LockClock
rm -rf /system/app/messaging
rm -rf /system/app/NfcNci
rm -rf /system/app/NoiseField
rm -rf /system/app/PhaseBeam
rm -rf /system/app/PhotoPhase
rm -rf /system/app/PhotoTable
rm -rf /system/app/QuickSearchBox
rm -rf /system/app/Snap
rm -rf /system/app/SoundRecorder
rm -rf /system/app/VideoEditor
rm -rf /system/app/YouTube
rm -rf /system/app/WhisperPush

On a vu que le updater-script permet de supprimer des applications système, mais celle-ci seront réinstallées après un dirty flash, d'où l'utilisation de ce script.
On peut aussi ajouter des applications en plus. Un bon exemple, c'est le launcher. Mieux vaut ne pas supprimer le seul et unique launcher quand on lance une ROM Custom pour la première fois. En revanche, une fois qu'on a mis un launcher alternatif, le launcher de la ROM peut être supprimé lors du premier dirty flash.

- Cas particulier Viper4Android -

# audio_policy.conf edits for V4A compatibility
sed -i '/deep_buffer {/,/}/s/^/#/' /system/etc/audio_policy.conf

C'est un bout de script qui permet de maintenir la modification du fichier audio_policy.conf. Je m'en sers pour faire fonctionner V4A sur mon téléphone.

Si ça ne vous parle pas, ne mettez rien. À la fin du fichier, remplacez

par

Ce script de sauvegarde doit être placé dans votre dossier (celui du futur zip et pas la partition /system réelle) /system/addond.d/
Pour le updater-script, il faut vous faut ces commandes :

run_program("/sbin/busybox", "umount", "/system");
run_program("/sbin/busybox", "mount", "/system");
package_extract_dir("system", "/system/");
set_perm(0, 0, 0755, "/system/addon.d/keepsupapks.sh");
show_progress(8.800000, 5);
run_program("/sbin/busybox", "umount", "/system");

Dans mon updater-script, seule la ligne set_perm était nécessaire car tout le reste était déjà présent.

Les logiques du "updater-script"

Je n'en ai pas parlé au début pour éviter de compliquer les choses mais si vous lisez encore ces lignes, vous vous êtes sans doute habitué aux scripts.

Dans un updater-script, il y a des phases logiques à respecter. Quand on crée un zip regroupant différents cas (suppression, ajout, modif...), il faut un minimum savoir où placer les lignes.
Avant de toucher à la partition system :
1. Il faut démonter la partition

2. Puis monter la partition

3. On supprime des applications
4. Pour installer de nouveaux fichiers, on extrait le contenu de notre zip

5. On définit les permissions

6. On démonte la partition

---

Voilà pour les bases, c'est plutôt complet je trouve. N'hésitez pas à tester, à regarder mon fichier d'exemple "primokorn-signed.zip" et à poser vos questions

Au boulot !

Dernière édition par Primokorn le Mer 4 Mai 2016 - 16:57, édité 14 fois

très inintéressant,

pas le temps en ce moment (gros week-end en vue) mais je ferai l'essai.

Peut-être faut-il expliquer la différence de droits en écriture/exécution entre 644 et 755...

En tout cas merci cela m'a semblé clair.

Faudrait faire un sujet à part pour les permissions. D'ici là, on peut jeter un oeil aux permissions Unix sur Wikipedia.
Sinon, on reprend les permissions existantes des autres apks pour savoir quoi mettre.

Exemple :
► tous les dossiers dans /system/priv-app sont en 755
► tous les .apk dans /system/priv-app ou /system/app sont en 644

C'est encore très clair

Super intéressant, merci pour cette information

Pas de quoi

Si quelqu'un a essayé avec succès le addon.d script, qu'il se montre lol
J'ai un petit soucis à régler donc de l'aide serait la bienvenue. Merci.

Problème réglé. Post 1 mis à jour.

Merci,
je regarde cela la semaine prochaine (qui devrait être plus cool)...

Ça marche, tiens moi au courant
Au passage, j'ai complété mon script addon.d pour sauvegarder/restaurer mon fichier hosts. Trop facile les dirty flashs

C'est que je pense travailler pour gagner sur les clean installs
d'autant plus que, vu le temps d'optimisation des applis au premier reboot (sur le M9 en tout cas)

Post 2 complété pour donner les explications de diverses commandes utilisées dans un updater-script.

Je vais essayer de faire quelque chose de plus "clé en main", même s'il y a forcément une phase de personnalisation pour chacun.
Les deux premiers posts seront refaits à 100% d'ici demain (sauf si empêchement).
Si vous avez des demandes particulières d'ici là, allez-y.

J'ai commencé la refonte du sujet. J'espère qu'il sera plus compréhensible.
J'ajouterai d'autres exemples sous peu mais il y a déjà les informations principales et des exemples.

Je t'en remercie, car justement j'ai commencé à le lire hier, mais j'étais trop fatigué pour le faire...Je vais relire tout çà et je reviendrai te dire si je ne comprends pas quelque chose

Pas de soucis, autant améliorer l'existant avant d'ajouter d'autres éléments plus complexes.

Hello,

J'ai beau lire et relire, je ne pige pas vraiment comment m'y prendre

Primokorn a écrit:

Pour vous mettre dans l'ambiance, voilà en résumé ce que fait le mien :

1. Installation script AFWall+, Viper4Android, de sauvegarde et configuration
2. Installation/Suppression d'applications système : Viper4Android, BBS, Blankstore
3. Installation/Suppression de fichiers : gps.cong, hosts.og, hosts.alt
4. Modification de fichiers : audio_policy, build_prop
5. Tout ça est automatiquement maintenu lors d'un dirty flash (mise à jour ROM sans effacer les données utilisateur)

Par exemple, où trouver le script AFWall+, etc...?
Installation d'applications système, là j'imagine que ce sont celles qui sont incorporées dans la rom custom...Mais où va t'il aller chercher les autres applications que je veux qu'il m'installe ? Faut-il créer un fichier "mes_apks" où je glisse toutes les applications qui m'intéressent ? Pour les fichiers hosts, il va les chercher où exactement ? Et en ce qui concerne audio_policy et build_prop, franchement, moi je suis perdu.
Ensuite, concernant mes propres configurations, mail, comptes, etc...Je ne comprends pas comment faire pour les ajouter, à part si j'utilise TB...
Sinon, franchement ce sujet m'intéresse vraiment, mais ce qui semble très simple pour toi devient très compliqué pour moi...D'ailleurs, moi je ne sais pas configurer mon AFWall+...


Edit: Bah...J'ai enfin compris où mettre tous mes apks perso...Il fallait que j'épluche ton dossier exemple "primokorn-signed.zip", à force de chercher, on fini par trouver Mais il me reste encore plein de choses à comprendre avant de pouvoir finaliser mon script

Les choses s'éclairciront une fois que j'aurais mis les autres exemples.

Primokorn-signed.zip est le cas le plus complexe que je connaisse, ça regroupe tout ce que j'ai découvert et que j'utilise. C'est donc normal que ça soit difficile à comprendre au début.

Ajout Exemple 2 (tuto + zip dans Dropbox) pour installer de nouvelles applications.
Ajout d'une mention pour les utilisateurs ARM64 et x86.

Merci beaucoup l'expert

Nexus5 c'est bien ARM ?

Je finalise l'exemple 3 sous peu.
Oui, c'est bien ARM.

EDIT : Exemple 3 terminé

Et voilà, tout est terminé.

Si quelque chose n'est pas clair, n'hésitez pas à le signaler. C'est pas facile de tout expliquer... Ça mélange logique, rigueur et détails. Heureusement que c'est pratique lol

Merci, je regarderai ça dès que j'aurais un bon moment de libre