In, I havethat were reported on GitHub. It's hard to say which devices and ROMs profit from the changes. Affected devices mentioned in the issues were mainly HTC and LG, plus any devices which have activated the compiler filter "everything" for ART.The reason for these issues is in pretty much all cases that AOSP can't handle so called "quickened" instructions like "invoke-virtual-quick". They're the result of optimizations when the ROM was compiled, and usually just need to be executable by the runtime. However, as Xposed needs to recompile the whole ROM to disable a few optimizations that would prevent hooks from being called, these instructions need to be understood by the compiler as well, which isn't always the case. It did get better in Android 6.0 due to beginning JIT support, so I could port several changes to 5.0 and 5.1 (which isn't as easy as it sounds). But even on 6.0, several fixes were required. Unfortunately, debugging the issues to find those fixes often takes many hours or even days, hence the rather long time between v78 and v79.I hope that by now, most of these issues should be solved. If you still come across any bootloops - even without any active modules - please open an issue on GitHub . You must include a logcat of the failing boot attempt, otherwise I can't help you. My recommendation: Clear Dalvik cache, restart device, execute "adb logcat -v time > logcat.txt" as early as possible, wait a few minutes, press Ctrl+C.Additionally, I have merged the AOSP changes from 6.0.0 to 6.0.1. They're just a few fixes, so the SDK23 ZIP works on any 6.0.x ROM.The latest version of Genymotion emulator contains improved flashing scripts based on my GenyFlash project, allowing you to flash recovery ZIPs properly. Now you can simply drag & drop the Xposed Installer APK and then the x86 framework ZIPs from the first post onto the window, without the extra step of flashing GenyFlash. Due to the great boot speed and overall performance, module development becomes much more efficient (and no, they don't sponsor me, I really just like it).- Making Xposed "systemless" (i.e. work without modifying the /system partition) should be generally possible. However, it will certainly be much effort, especially due to the high diversity of devices. I follow the process of @ Chainfire 's systemless SuperSU experiment to see how feasible it is. Maybe once this approach has become more mature, it can be re-used by other projects such as Xposed. I'd want to avoid incorporating the whole kernel modification stuff though - if there was some kind of init.d-like interface that allows other projects to plug in and execute some commands at very early boot time (e.g. to mount a custom libart.so over the original one), that would be great. So much for wishful thinking - currently, I'm not working on this.- It seems that some vendors have ported a change that was originally made in 5.1 back to 4.4 (KitKat). Xposed currently doesn't work with such ROMs. Why isn't this fixed yet? Well, I have completely restructured the source code and installation procedures for ART on Lollipop. Even though I kept Dalvik in mind, it will still require much more work and testing. Therefore, I'm not able to release pre-Lollipop files at the moment and due to the focus on Lollipop/Marshmallow, I don't think this will change for the next weeks or maybe even months.