[Support] échecs de mise à jour

Avec tous les changements majeurs à SuperSU, il ya des mises à jour de l'interface utilisateur graphique et binaire. L'interface graphique est la partie que vous voyez à l'écran, le binaire est ce qui permet à d'autres applications d'acquérir effectivement accès root. La première fois que vous ouvrez SuperSU après une telle mise à jour, il va tenter de mettre à jour le fichier binaire à la dernière version.

Il ya beaucoup de composants pour le binaire et il doit être mis en place juste pour que tout fonctionne. Ceci est une opération complexe, et parfois il échoue. SuperSU est utilisée par des dizaines de millions d'utilisateurs à travers des centaines de différents dispositifs, la course encore plus différentes révisions de firmware - tout changement a toujours le potentiel de briser quelque chose quelque part.

SuperSU offre de multiples façons de l'installation: in-app «normal», in-app TWRP / MCG, et ZIP via TWRP / MCG. Ceux-ci ont tous leurs propres forces et faiblesses, donc si on ne travaille pas, essayez les autres si disponible.

Si vous déclarez un échec de mise à jour, vous devez inclure au moins les informations suivantes. Certaines informations exige une certaine habileté avec la BAD pour récupérer.

- Modèle exact de dispositif

Cela comprend la marque, le modèle, et la variante de support (le cas échéant: la plupart du temps Etats-Unis, Corée, Chine)

- La version exacte du firmware

Quels firmware exacte utilisez-vous? Si vous utilisez un custom firmware, s'il vous plaît inclure un lien vers le téléchargement de ce firmware. Si en plus de cela, vous utilisez également un noyau personnalisé, s'il vous plaît inclure un lien vers le téléchargement pour cela aussi.

- Version Android exacte

X.y Android

- La version exacte SuperSU

Quelle version avez-vous été en cours d'exécution, et de quelle version vous sont à jour? Si vous utilisez Pro, avez-vous un mode de survie OTA permis?

- applications interférentes

Il ya quelques applications qui peuvent interférer avec l'installation SuperSU, principalement:

- d'autres applications Superusery

- Xposed

- BusyBox (lien symbolique ou non un lien symbolique)

Inclure dans votre rapport si vous avez un ou plusieurs de ces installé.

- Les méthodes de mise à jour ont essayé

In-app «normale», en application via la récupération, et ZIP via la récupération. Si vous avez utilisé l'une des options de récupération, s'il vous plaît inclure la version exacte dont le recouvrement que vous utilisez, et si elle est pas une accumulation officielle (donc un TWRP pas à partir du site TeamWin, un MCG pas à partir du site de MCG, etc) un lien vers où vous l'avez obtenu.

Notez que si vous laissez TWRP ou MCG root "fix" pour vous, ou laissez-les désactiver le firmware de clignoter une nouvelle récupération (parfois, vous êtes invité), vous avez cassé la root, et la seule façon de récupérer il clignote la pleine postal grâce à la récupération.

- Quel genre de root sont partis avec vous?

Après une mise à jour binaire échoué, plusieurs résultats sont possibles:

- Root est perdu. Les applications ne peuvent plus obtenir root, vous ne pouvez pas obtenir l'aide de le root "su" à partir d'un shell adb, etc.

- Root semble fonctionner pour la plupart encore. La plupart des applications fonctionnent encore, et / ou "su" fonctionne toujours à partir d'un shell adb

- Rien ne semble avoir changé du tout, même l'interface graphique montre encore l'ancien numéro de version

Signaler quel état votre appareil est maintenant. Notez que vous pouvez obtenir la version de la principale binaire "su" en exécutant "su -v" à partir d'un émulateur de terminal ou adb shell.

- Grumes de TWRP, lors de l'actualisation du binaire en utilisant la TWRP / bouton MCG à l'intérieur du SuperSU app

Après avoir appuyé sur le bouton Marche / TWRP MCG, l'appareil devrait redémarrer en TWRP, faire est chose pendant quelques secondes, puis redémarrez en Android. Si SuperSU se plaint encore de la binaire, s'il vous plaît récupérer le fichier journal de TWRP. Vous pouvez le récupérer via adb traction / cache / récupération / last_log, qui devrait produire le fichier last_log dans votre répertoire courant. Vous avez encore besoin d'au moins partielle de le root démarré Android pour récupérer ce journal. Malheureusement, il est effacé et remplacé par un nouveau fichier lorsque vous démarrez dans la récupération d'un second temps, de sorte que vous ne peut pas récupérer de cette façon. Notez que ce journal contiendra toujours un certain nombre d'erreurs, comme l'installateur essaie plusieurs choses de plusieurs façons, qui fonctionnent différemment sur les différents firmwares. Fixez ce fichier journal.

- Grumes de TWRP, lorsque la mise à jour via SuperSU complètement postal

Si après le démarrage de retour dans Android, SuperSU ne fonctionne pas correctement ou encore demande pour les fichiers binaires mis à jour, redémarrez de nouveau dans TWRP, installer le nouveau postal. Après la ZIP est installé, vous pouvez récupérer le fichier journal via adb /tmp/recovery.log de traction, qui devrait produire le fichier recovery.log dans votre répertoire courant. Fixez ce fichier journal.

- Grumes de SuperSU (très important)

Si SuperSU garde vous demandant de mettre à jour les fichiers binaires après avoir essayé tout de quelle manière et à défaut, s'il vous plaît poster le journal de détection. Après la mise à jour a échoué, ne redémarrez pas, mais produire des informations de détection via adb logcat -d | find / i "installateur"> logcat.txt (Windows, l'utilisation de grep -i 'au lieu de' find / i »sur Linux ou OSX ), qui devrait produire un fichier logcat.txt dans votre répertoire courant avec plusieurs lignes citant SuperSU. Fixez ce fichier journal.

- Divers journaux (très important)

Quelques informations à portée de main supplémentaire peut être obtenu par l'intermédiaire des appels adb shell. Si vous que le travail, copier / coller les commandes suivantes devraient produire un fichier sulog.txt belle dans votre répertoire courant, que vous devez joindre à votre message:

(Comme toujours avec le copier / coller, assurez-vous que vous appuyez sur entrer quelques fois par la suite pour vous assurer que la dernière ligne a été purgée)

Code:

adb shell getprop > sulog.txt
adb shell toolbox id >> sulog.txt
adb shell busybox >> sulog.txt
adb shell su -v >> sulog.txt
adb shell su -V >> sulog.txt
adb shell su -h >> sulog.txt
adb shell su --self-test >> sulog.txt
adb shell ls -l /system/xbin/*su* >> sulog.txt
adb shell ls -lZ /system/xbin/*su* >> sulog.txt
adb shell ls -lZ /system/bin/toolbox >> sulog.txt
adb shell ls -l /system/bin >> sulog.txt
adb shell ls -l /system/xbin >> sulog.txt
adb shell ps >> sulog.txt

en terminant

Toute cette information vous aidera à diagnostiquer le problème, et potentiellement aider à résoudre le problème si il ya quelque chose de mal avec SuperSU lui-même (qui est pas inconnue). Le plus d'informations que vous fournissez, le mieux que vous peut être aidé. Pourtant, être conscient que souvent, il faut un certain temps pour obtenir un problème triée. Même quand beaucoup de gens ont le même problème (et de nombreux problèmes peut sembler le même mais au fond sont des questions distinctes), il est rare de trouver un utilisateur qui veut activement pour aider à résoudre la question. La plupart des utilisateurs ne se plaignent mais alors ne pas vraiment aider à résoudre le problème. Si vous pouvez être quelqu'un qui peut aider activement, et par là je veux dire répondant à des questions, être disponible pour une session de débogage, etc, vous êtes une perle rare en effet, et votre aide sera grandement appréciée.

Si vous écrivez plusieurs postes, il est toujours utile si vous gardez créant un lien vers votre message original avec le rapport. Me fait gagner du temps.