ΑΞΙΖΕΙ ΝΑ ΓΙΝΕΙ UPDATE

The original developed behind the Xposed Framework, XDA Senior Recognized Developer rovo89, has been responding on Github with his thoughts on these recent developments.

From my experience, I can tell you that it’s indeed not that hard to get the basics done, but it takes a hell lot of time for the details. It’s like the 80-20 rule, except that it’s more like 95-5 or so.
The hooking approach I have designed for the previous releases is rather stable and can be applied for newer releases as well. I assume you needed most of the time to check all the places where IsProxyMethod() and IsDirect() is called and decide whether they should consider the new method modifier or not (i.e. use parameter true or not). If you didn’t do that, you might have missed some places where they have newly introduced such calls. Same for methods like InstallStubsForMethod(), which needs to operate on the original original method even when they’re called for a hooked method. You’d need to check for more places where this could be relevant. That’s still in the range of days, but if you miss to do it, you might see obscure crashes or misbehavior that are very hard to debug.
Besides that, you took an approach where hooks would only work properly for ROMs which are entirely compiled from scratch. On stock ROMs and even most custom ROMs (that didn’t include your port while building) as well as for any apps the device might have compiled before. So you’d have to start all over again with a wiped device running a special ROM. If not, then optimizations (e.g. inlining) might prevent a method from being called at all, and hence hooks wouldn’t work. The worst thing about this is that the exact behavior would depend on the ROM, or even how the user uses the device (now that apps are compiled based on profiles). Modules would fail randomly and the module developers would be wondering what they did wrong (answer: nothing). If not all of the prerequisites are fulfilled, it’s a pretty unreliable API. Imagine Google published an update where the OnClickListener of a button wasn’t called sometimes, unless you compiled your ROM from scratch… For me personally, this is a big limitation.

He goes on:

It doesn’t make sense at all to publish flashable ZIPs with this, as the port is only intended for recompiling a ROM from scratch.
And as I feared, there is not a single warning that this is an incomplete port that will often fail to fulfill the API contract. That’s bad for developers and users, they should at least know it’s incomplete so they can decide whether they want to support/use it. I would never dare to do something like that without a big fat warning. Actually, as I’m rather perfectionist, I wouldn’t publish an incomplete version at all, reliablity is very important for me.

I just checked my Git log and I had the basic hooking (as in this port) ready in October. Since then, I have worked on removing the limitations. To make it more reliable on pre-compiled ROMs, I could have ported the recompiling part as well, however that’s still not ideal. As explained somewhere above, we have JIT now, which allows us to keep all the optimizations, only invalidating (and possibly recompiling) the methods which are directly affected by hooking. This is quite challenging, as it’s more than just copy & paste. And until this isn’t done, I won’t publish anything. 9 months for that (until now) is really a long time, I know, but hey, it’s my spare time and e.g. due to moving to a new apartment, I couldn’t work on Xposed for several months (!) at all, and had only very limited time otherwise.