So yes, I’m still working on Nougat support, whenever my free time allows it, but I don’t have any idea when it will be done. Once it’s done, you’ll know.

It seems that more and more people get nervous about whether (and when) there will be Xposed for Nougat or not, so I felt I should say something.

Why does it take that long? Because with every release, I try to ensure that Xposed integrates nicely with the improvements in the new ART version. The step from Lollipop to Marshmallow wasn't huge. It was an evolution, some things even made it possible to integrate Xposed in a more elegant way. On the whole, it was mainly careful porting than rather innovating.

With Nougat, something fundamental has changed. If you're using Nougat already, you'll have noticed that installations are much faster now. That's because APKs aren't compiled immediately (AOT), but start in (slower) interpreting mode. Sounds bad, but they have enabled JIT, which will quickly compile those methods that are used very often. That will restore the well-known and constantly improving performance of native code. Besides that, ART keeps a list of these frequently used methods ("profiling&quot. When the device is idle, it finally does the AOT compilation, but based on the profiling data. After that, you get the great performance right after starting the app. JIT is still waiting in case the usage patterns change, and I think it will also adjust the profile and improve the AOT compilation.

That results in various different compilation states and more complexity. Besides that, there were many issues in the past caused by Xposed's need to recompile the whole ROM and all apps: It sometimes caused boot loops when the odex files were too heavily pre-optimized, it blocked quite some storage space to store the recompiled files, and I needed to disable some optimizations like inlining and direct pointer calls. I hope that I can make use of the JIT compiler to avoid that in Nougat. If Xposed knew from where a method is called, it could invalidate the callers' compiled code, so that they would temporarily use the interpreter. If they're important enough, JIT will recompile them.

I have already done a lot of research and experiments for this and I'm currently trying to implement this. But as you can imagine, all of that is much effort and can easily take hundreds of hours. That's net (working) time, not real time. If I worked on Xposed 24 hours a day, that might be done within a week or two. But, in the last year or so, my "time for Xposed stuff" was about 5 hours a week, sometimes more and sometimes less. You can do the math yourselves... There are just so many other (non-technical) things that I need or want to do. If you substract the time it took me to build the new installer version, move the repo to a new server and restore compatibility with the Nov 2016 security patches, that's even less time for new stuff.

So yes, I'm still working on Nougat support, whenever my free time allows it, but I don't have any idea when it will be done. Once it's done, you'll know.

Guys, it's done when it's done. Many people offer their help, but keep in mind that you'll need much in-depth knowledge about how compilers work in general and how ART works in particular. It's not just about the amount of work, it's mainly about the complexity. Yesterday, I worked maybe 3-4 hours on Xposed, and I've written just a few lines of code. The rest of the time was spent to do even more research on how certain things work internally and what edge cases could occur. I still believe it's worth it though, as only this way, I can integrate Xposed properly into ART.

You can have that opinion - but in the end, it's my own decision whether I want to publish my current WIP or not, and you'll have to respect that decision.

There are a couple of reasons why I won't do that. Working on Xposed isn't really straight-forward, it's an iterative process in which I hardly know what to do next until it's done. That makes it quite hard to work on it with someone else, unless there's some really close communication and common understanding how things should work. Given that my time for Xposed is pretty unreliable, I would not be able to fulfill my part in this. Besides that, I'm a perfectionist. I wouldn't accept any foreign code without very close review to make sure it's "the right way" to implement it. This would also be very time-consuming. It might work if that other person has thoroughly studied how ART works and did a lot of research to understand how Xposed can best be integrated into it. However, my experience shows that even for previous releases (for which the source code is published), there wasn't really anyone who digged into it deeply enough to help analyse and fix some of the issues.

If somebody contacted me saying "hey there, I checked out the ART source code and I think I understood in general how it works. here are some ideas how I would implement Xposed for Nougat it, can I help you somehow?", then I would consider giving it a try, but I believe that just pushing out the current state wouldn't help the project. We would maybe see "some" release really fast by people who compile the code, see that it appears to be working fine and publish it as "their port", despite the issues and things to do that they wouldn't be aware of. So call me selfish, but I wouldn't want to see such a half-finished release.

That said, I'm now at a point where I'm wrapping up some things, reviewing the big amount of changes I've done in the last months and clustering them into individual commits to keep the overview. I think I got some really nice technique working to ensure that the apps can still be compiled with all the optimizations enabled. When a method is hooked, its callers will be deoptimized, but can later be compiled again (with optimizations, but also knowing about the hook). That's possible in Nougat thanks to JIT, which wasn't enabled in previous versions. So it's not just a simple port of Xposed, important parts are actually re-invented. There are still many tasks though before this can work beyond my test cases, so you'll have to be patient and stay tuned!

Does it work on Nougat, yes it does. What does it mean for us? This Xposed hack is made deeply in the system, means it requires an AOSP pre-compiled rom just for this xposed feature (you could say like a special xposed rom is needed to make it work). Rovo (the author of xposed) has already found this "whole" back in october (!!!) but as he is a little perfectionist like me he want's to make a flashable zip for as many devices as possible. And this variants now floating around are just... yeah very limited and dirty and totally unusable for samsung touchwiz based roms. Just that you have an idea.

The core of Xposed is obviously its ability to hook Java methods, i.e. let modules execute code before, after or instead of these methods. Pretty much every other functionality is based in this, so it’s critical that it’s always working as expected. The general concept has been the same since I invented Xposed five years ago, it requires changing the entry point of the method. This starts to fail when the entry point isn’t checked during execution – which is actually the case with some of the optimizations in ART.

One example is when the entry point is already known at compile time, then callers can directly jump to this address without looking it up. Another example is inlining. Consider this example:



ART is smart enough to notice that the twice() method is very simple and therefore embeds the logic right into the doSomething() method, like this:



You can still hook the twice() method, but it won’t be called from doSomething() anymore at runtime, and so won’t your callback. ART is even more clever: It realizes that magic is always 42 and therefore the condition can never be fulfilled. So the whole doSomething() method is actually a no-op:



In previous versions, Xposed used to disable these optimizations completely and forced recompilation of everything. That came with several downsides. First of all, the ART developers are doing a fantastic job in maximizing the performance with their optimizations, and disabling them partly necessarily leads to less performance (I never measured how much though). Then, the recompilation itself isn’t always easy and caused me a lot of headaches, especially in the beginning. Finally, the recompiled files take up space, in addition to the precompiled files on /system.

The unofficial versions for Nougat also disable these optimizations, but they don’t force the recompilation (because the port was originally made to be integrated into the ROM). Therefore, hooks might not be executed sometimes.

With the official version, you’ll get to keep the optimized code and still have reliable hooks. How does that work? Well, Xposed records all the calls that are made. This happens while APKs are being compiled, or in a separate pass for preoptimized code. This additional data doesn’t take up much space, but it allows Xposed to find out where a certain method might have been inlined. So when a method is hooked, all its callers will be deoptimized, i.e. their code won’t be used anymore. This ensures that the hook callback will definitely be called. And if the caller is heavily used, it will simply be recompiled with JIT, this time with the knowledge that the method is hooked and therefore some of the optimizations don’t apply. This means that the effects of hooking methods are reduced to the bare minimum. Yay!

Now go ahead and try it out. Make sure to use Xposed Installer 3.1.2, as the config path had to be changed to support File Based Encryption.