1

I uninstalled this version of Xposed, because I wanted to try this one. Note: Thanks to this comment I was actually able to flash the latter too, but it gave me a bootloop. So I would caution others against that package.

So the procedure for the latter was adb, but it turns out adb doesn't work for flashing Xposed on my device. (Zenfone 2) I had only managed to install my previous version of Xposed using recovery flashing.

But when I tried the adb script, though, I got this output. However, the phone didn't reboot or anything. Just like last time. (Even though I waited a fair amount of time.)

Even though there is no evidence of it, I figured there may be a small chance that this failed adb script had done some sort of damage to my firmware. So I decided to flash the stock firmware again "just because". Why not? Anyway, that's already done.

  1. Is there any potential use to also wipe the data partition?
  2. Was there any potential benefit to restore the firmware like I did?

(I'm gonna root again and install the same Xposed Framework I initially had.)

  • @DeathMaskSalesman Is this the case for the adb scripts in both the XDA threads I linked to in OP? The same thing happened for both of them. (Which is why I've had to flash through recovery.) – Revetahw Jul 8 '16 at 16:00
  • @DeathMaskSalesman Yeah, it looks like both scripts lack such quotes. In the the scripts, the shell command is used twice. Should I add the quotes to both lines? – Revetahw Jul 8 '16 at 16:29
  • @DeathMaskSalesman I see. I will try. By the way, why would they have left such a weird error in the scripts? And why did the scripts, containing these errors, work for other people? – Revetahw Jul 8 '16 at 16:45
  • @DeathMaskSalesman I see. I will try. By the way, why would they have left such a weird error in the scripts? And why did the scripts, containing these errors, still work for other people? – Revetahw Jul 8 '16 at 16:47
  • @DeathMaskSalesman Alright, will test it when I get back to my laptop. – Revetahw Jul 8 '16 at 16:52
2

Analyzing the InstallXposedFramework.bat script tells us the reason behind the script failure. The content of the script follows:

@echo off

set adb=files\adb.exe

echo '
echo '
echo ' Connecting ZenFone ..
echo '
echo '
%adb% wait-for-devices

echo '
echo '
echo ' Pushing files ..
echo '
echo '
%adb% push assets\xposed-sdk21-x86\system /data/local/tmp/system
%adb% push files\installer /data/local/tmp
%adb% shell "su -c chmod 755 /data/local/tmp/installer"

echo '
echo '
echo ' Installing Xposed Framework ..
echo '
echo '
%adb% shell "su -c /data/local/tmp/installer"

echo '
echo '
echo ' Done, rebooting ..
echo '
echo '
%adb% reboot

Reason behind the failure

Above, the script proceeds flawlessly until it hits:

%adb% shell "su -c chmod 755 /data/local/tmp/installer"

, whose arguments haven't been formatted correctly. Specifically, chmod, 755 and /data/local/tmp/installer are intended as three separate arguments to be supplied to su -c, which accepts one mandatory argument (that is, the command to be executed), an optional login id and an optional and arbitrary number of arguments at the end.


Patch for the script

To make the script work, the line:

%adb% shell "su -c chmod 755 /data/local/tmp/installer"

has to be edited to resemble:

%adb% shell "su -c 'chmod 755 /data/local/tmp/installer'"

, since chmod 755 /data/local/tmp/installer is an unique command (chmod) with two arguments of its own (755 /data/tmp/installer). The whole of it will then be supplied as the only argument to su -c and be executed with root permissions, allowing the script to proceed its execution.


If the phone bootloops

Then the Xposed version supplied alongside the script is somehow incompatible. The bootloop is independent from the installer script.


Should I wipe the Data partition and reflash the firmware, if I execute the original InstallXposedFramework.bat?

Absolutely not, and there's why: the commands that push Xposed to your device are the following:

%adb% push assets\xposed-sdk21-x86\system /data/local/tmp/system
%adb% push files\installer /data/local/tmp

. Since, as explained before, the command:

%adb% shell "su -c chmod 755 /data/local/tmp/installer"

is buggy and therefore makes the script hang, nothing is in fact installed. The only thing to do, is to check if the folder /data/local/tmp is empty, and delete anything inside it if it's not.

  • Thanks! By the way, does this mean that the script would have hung for everyone who tried it? (I'm referring to the script itself, not the bootloop that happened due to the incompatible Xposed.) – Revetahw Jul 9 '16 at 7:32
  • @Fiksdal Unless one has a weird su binary, then yes, this script won't work for anyone. – Death Mask Salesman Jul 9 '16 at 7:34
  • That is so weird. Although I agree with your observation, since I have edited the script and experienced the difference first hand. What I don't understand is that I encountered exactly the same situation with this one (for which I ended up using the recovery option.) I'm just curious, how could they possibly both release this with such a serious bug? (I'm not disagreeing with your answer, I'm just dumbfounded.) Also, why is nobody in the XDA comments mentioning it? – Revetahw Jul 9 '16 at 8:11
  • @Fiksdal This cannot really be answered, since an eventual answer would be mere speculation. My guess is that most people uses the recovery method, than the adb one. As for the .bat scripts being the same, I reckon that the authors may have shared them with each other. – Death Mask Salesman Jul 9 '16 at 8:11
  • Yeah, that sounds plausible. Although the latter didn't supply any recovery option at all. – Revetahw Jul 9 '16 at 8:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.