Bootloop on MT6592 SoC [JiaYu G4S Advanced]

[Drugoy]

The thing is that Xposed generally works, and works fine with some modules, but there are also the modules that can cause the phone to start lagging badly, crashing apps, heating up, then hanging and rebooting (and so a bootloop may be started).

I experience the above described problems with 2 modules: GravityBox and XPrivacy.
I've also already opened issues in their repos: 1 and 2, but M66B (the author of XPrivacy) after reading my logcat.log suggested that the issue might be in the Xposed fw itself, so I'm opening this issue here.

logcat.log with Xprivacy causing bootloop.
logcat.log with GravityBox causing bootloop.

[rovo89]

It looks similar to a known issue: http://forum.xda-developers.com/showpost.php?p=52289793&postcount=5
If you use the latest Xposed version, you should have received a warning about this. Could you please check if there are any *.jex files in /system/framework?

[Drugoy]

Could you please check if there are any *.jex files in /system/framework?

There were 15 of them and I had deleted all of them before installed Xposed, as it was said in a manual on a local forum.

[rovo89]

There were 15 of them and I had deleted all of them before installed Xposed, as it was said in a manual on a local forum.

I remember that someone mentioned that he had deodexed the ROM and then deleted these files. Unfortunately, I can't help with the procedure. Mediatek has built their own compiler, and I don't think the source code is available. That makes it pretty much impossible for me to find out whether Xposed could be made compatible with it.

[Drugoy]

But why do some modules work fine (and Xposed itself, in general, too)? How to distinguish (without testing) which modules will most likely run fine and which ones will most likely cause a bootloop?
XPrivacy is a privacy manager, while GravityBox mostly (or only?) works with changing UI, from my point - they don't have much in common, yet they both cause the bootloop.

[rovo89]

Well, I don't know, maybe it's because they both hook many methods, so you have a higher probability that the compiler runs into a strange situation. But I can't find out more, it simply crashes while reading an instruction (ScanInsn_IGet) and no source code of the compiler is available.

What you could try is disabling JIT, as this should disable the compiler completely. To do this temporarily (until the next full reboot), execute this in an adb shell:

su
setprop dalvik.vm.execution-mode int:fast
stop
start

If this doesn't work, try "portable" instead of "fast".

[Drugoy]

if the bug happens, I usually don't have much time: most of the times I couldn't even manage to reach xposed to turn off the buggy modules, so I'm not sure I'll be able to execute this code when the module is active :(

Can it be saved as a script so I could call it fast?

[rovo89]

I would suggest you execute this first, then you activate the module(s) and use "soft reboot". This property will stay set until you do a full reboot.

[Drugoy]

woah, huge news: seems like this trick (I used "fast") worked just fine!
is there a way to save those commands as a phone startup script, so the user wouldn't have to manually execute those lines every time?

[rovo89]

You could try to but this line into /data/local.prop (or /system/build.prop):

dalvik.vm.execution-mode=int:fast

But please make sure that you could revert this change via recovery in the worst case!

[danielmmmm]

Editing the build.prop didn't work in my case.

[danielmmmm]

I just downgraded to the M6 snapshot and it also got stuck while booting up. Looks like something else is wrong that is probably specific to my phone/installation. Unfortunately I cannot get adb to work and therefore all I get to see is the angry looking CM Android from the boot animation :-(

[rovo89]

@Drugoy Did you have the chance to test the build.prop change? After rebooting, check the output of getprop dalvik.vm.execution-mode after rebooting to make sure that the value is set properly (similar to setting it manually via setprop).

[Drugoy]

@rovo89
That method seems to work as well.

[Drugoy]

@rovo89
what are the possible negative effects of that change? As far as I understand, you say this command turns off JIT-compilator, right?
So how will programs requiring JIT-compilation work?

[rovo89]

As far as I understand, you say this command turns off JIT-compilator, right?

Yes.

So how will programs requiring JIT-compilation work?

No apps require JIT. It's simply for performance optimization. Usually the dex commands are interpreted. JIT compiles them into native code when a particular part of the code is executed often.
So if your phone get's slower, that might be do to the missing JIT compiler. If it just got slower after reading this, it might be a placebo. ;)

[rovo89]

I have added a link to this issue to the FAQ item about these .jex files now: http://forum.xda-developers.com/showpost.php?p=52289793&postcount=5

[Kahan]

I have experienced. Aliyun OS problem on xposed installer aftr updating d framework on redmi note 3g..... Any solutions???