Originally Posted by WinSern1
It is not boot loop, It can boot to lockscreen but then reboot and go to lockscreen again. It keeps repeating reboot
Downloading Android SDK...
Can you use "adb" (contained in the SDK)? Then you can execute "adb logcat -d > logcat.txt". If you have that, you can also execute "adb shell" to get a command line on your phone. Type "id" to make sure you are root (and use "su" on the shell or "adb root" from your PC if you are not root) and then execute "touch /data/xposed/disabled".
Originally Posted by karol1981
Rovo89 can you tell me what is exactly problem in aokp roms that xposed not working correctly, I can't stand situation when after reboot i need to wait 2-3 hours for normal state my phone.
Here is the essential part of my mail to the author of this commit
(shows a unicorn for me right now, but should work again soon...):
I had several users reporting that with the latest AOKP nightlies and my Xposed framework, their SystemUI takes some minutes to show up. Even though I'm not using AOKP myself, I spent some hours investigation this issue. What I found was:
- The reason for the delay are ANRs, which cause a restart of the SystemUI
- I believe the root cause was introduced in this commit: https://github.com/AOKP/frameworks_b...5494a64ff1f96e
- AppWindow, which is initialized in the start() function of the SystemUI services, loads information about all installed packages
- There are two expensive things in this:
- getting the launch intent results in two queryIntentActivities() calls for each installed package
- retrieving the labels for all launchable packages requires their resources to be loaded
- I injected the package loading functions into the ROM I'm using and they took 10-15 seconds on my S2 at boot time (high load -> more runtime)
- With many installed packages, a slower device or other initializations going on in parallel, the 20 seconds limit for ANRs is easily reached
- Xposed seems be another factor in this, but I have also seen an ANR trace where Xposed was not installed. Even if it slowed down the whole thing by 3 seconds, it couldn't be called the main factor.
- I asked one of the affected users to try an Xposed module that nukes the sortApps() function, which is just one half of the expensive instructions. He reported back that this mostly solves it.
So, here are my suggestions:
- avoid loading the packages during service startup (or at boot time at all - later, the same code just takes about 4 seconds)
- load the information asynchronously if possible to avoid blocking
If you need more information, please let me know.
So in short: I believe that the root cause is that information about all installed packages is loaded at boot time, which is quite slow. It seems that Xposed has also a share in that (i.e. it seems to slow it down a bit further, pushing it over the 20 seconds limit), but I have also seen a trace where the SystemUI crashed in these functions even though Xposed was not installed.
Obviously I'll try to address the performance in the future. @exidler
has done some great and detailed analysis and suggested fixes (but as they touch the very core of Xposed, this has to be handled very carefully). Just to get the dimensions right: Execution times are far less than a millisecond in his test. On the other hand, when there are many hundreds and thousands of calls in a short time, this can add up. And during boot time the CPU load is high anyway, so the actual execution time is higher than the CPU time.
So far, I haven't received any reply. If you can address this somehow else, please do so, I honestly don't have the energy to follow up on this. When you talk to your ROM developer, can you ask him to add some logging (with System.currentTimeMillis and maybe a stack trace) at the beginning and end of AppWindow.setupWindow()? That would make it easier to see how much Xposed contributes in this particular case.
Meanwhile, you can try the workaround module from this post
. It nukes one of the long-running functions.