J'ai un OnePlus One avec bootloader déverrouillé, TWRP modifié v2.8.6, MultiROM non officiel v32k, Gestionnaire MultiROM v1.186, Cyanogen OS 12 comme primaire et plusieurs ROMs Android 5.1 secondaires. Je n'ai pas de ROM secondaire non-Android.
J'ai créé un script de sauvegarde Android dans mon PC qui nécessite que je démarre dans une ROM particulière de la mienne pour que la sauvegarde ait lieu. Ce n'est pas un problème XY et je n'ai donc pas besoin de discuter de la flexibilité de la sauvegarde. Je dois démarrer dans une ROM secondaire particulière (disons S1).
Actuellement, j'utilise automatisation qui, à l'aide d'un déclencheur temporel, lance le MultiROM et utilise la combinaison des éléments suivants input tap pour naviguer jusqu'à l'entrée de S1 et le toucher pour démarrer dans cette entrée. Comme vous l'avez peut-être deviné, cette approche est banale et est vouée à l'échec si l'utilisateur touche délibérément ou par inadvertance un bouton souple ou dur ou interagit avec l'interface utilisateur de l'application active pendant que la série de commandes d'entrée est utilisée.
Je suis absolument conscient de Entrée automatique , Xposed Additions Pro applications et épinglage d'une application à l'écran Les deux premières permettent de désactiver indépendamment les touches programmables et les touches dures d'une application active. AutoInput peut même simuler des touchers enregistrés. Cependant, aucun d'entre eux ne peut désactiver la saisie à partir de l'écran tactile, la saisie tactile étant la principale cause d'échec de la solution actuelle.
N'ayant pas trouvé de moyen de bloquer l'entrée tactile à la volée, j'ai décidé de comprendre comment l'application MultiROM Manager fait démarrer un appareil dans une ROM particulière. C'était un voyage sans espoir pour commencer, étant donné que les mots-clés à savoir. commande, multirom, adb, boot, secondary, primary ROM, se trouvent partout où MultiROM est mentionné. Puisque même une recherche avancée sur le web ne m'a pas été utile, j'ai décidé de jeter un coup d'oeil à la sortie de la commande logcat et voir si cela me donne quelque chose d'utile. Une fois de plus, rien d'utile.
Je me suis retrouvé devant le choix de contacter Vojtech Bocek ( Tassadar (le développeur original de MultiROM) pour trouver la solution ou consulter le code source de l'application. En décidant de faire ce dernier choix, je suis tombé sur ces lignes dans le code source de l'application. MultiROM.java
public void bootRom(Rom rom) {
String name = (rom.type == Rom.ROM\_PRIMARY) ? INTERNAL\_ROM : rom.name;
Shell.SU.run(**"%smultirom --boot-rom='%s'", m\_path, name**);
}En avoir fini avec libsuperuser déjà, j'ai supposé que Shell.SU.run("%s/multirom --boot-rom='%s'", m_path, name) correspond très probablement à la commande exécutée dans un shell avec les privilèges de superutilisateur.
Et, c'est la fin de l'histoire puisque j'ai vérifié tous les emplacements sous $PATH et aucun d'entre eux ne contient le binaire nommé multirom .
Donc, comment puis-je démarrer dans une ROM particulière maintenant ?
