Skip Xposed API classes check if needed

[BetterXP]

There are still many modules, which are wrongly compiled, but still can work just fine on LP, MM or later. Many of them are as is, without chance to be updated for Android Studio, Grandle and new Xposed API.

This patch allows us to add option to Xposed Installer's Settings to enable running of modules, which are outdated and Xposed classes are compiled into module's APK.

[rovo89]

Many of them are as is, without chance to be updated for Android Studio, Grandle and new Xposed API.

There's no need to switch Android Studio/Gradle and you don't even have to use the "new" (rather "cleaned up") Xposed API, although that's obviously the preferred way. It works the same way for Eclipse and older API versions.
Everything developers need to know is explained in the link that's given in the error message: http://api.xposed.info/using.html

So only if the developer isn't willing to update (even after months) or has lost the source code, this could be an issue. The question is whether it's a good idea to use such a module... And even in that case, there would be a workaround: Decompile the APK, remove the Xposed classes, compile again, sign, publish´.

Keep in mind that I didn't add this check just for fun. Various very strange issues have occured because of such modules. If such a setting existed, lazy/unexperienced developers would just tell users to enable it instead of providing a fix.

Can you give more reasons why it should be possible to override this check? Are there any popular modules affected?

[wanam]

@rovo89 Is it possible that this check may introduce some false positive cases?
Someone reported an error loading my module "YouTube AdAway" few weeks ago, i always make sure to not include the api since my first xposed dev steps, the same version of the module had more than 400 000 dls and no one else reported this issue.

[rovo89]

@wanam Well, the fact that nobody else reported it kind of confirms that the implementation is generally working well. I did make some changes to it in v86 though: ffd8b80

Did you you ever hear back from the reporter? Would be good to know if this still happens with v86. If it does, it should of course be checked in more detail.

[wanam]

Actually the reporter was running v86, i didn't get any news since the first report and i didn't try to look at this issue because it was the only report for such error.

[BetterXP]

I was using Eclipse and exactly followed your rules to add lib, modules have been working well, on pre-Lollipop nad Lollipop and later, until I saw warning in Xposed log and users claimed that Xposed rejects such modules so I dont know. I updated my popular ones to Gradle, it is ok now, but I have still some more to port :D

It is not about "lazy/unexperienced developers" (every developer should matter imho), it is that sometimes there is no time (imagine you have older module project and now you have Android Studio, you need to convert it, resolve errors, etc) or access to source code to fix this issue.

"Are there any popular modules affected" (*) ... hm... Some modules may not have many downloads because are too specific, but still has userbase.

Option to skip this could be only in custom Xposed Installer fork by DVDAndroid, if you dont want to have it on official Xposed Installer.

• off topic: what about your AppSettings? I fixed it to work on MM, but since you blocked me (pyler) I cannot send you pull requests. Fixed APK is uploaded on XDA forum, somewhere in the module thread. Not very user-friendly.

[rovo89]

I was using Eclipse and exactly followed your rules to add lib, modules have been working well, on pre-Lollipop nad Lollipop and later, until I saw warning in Xposed log and users claimed that Xposed rejects such modules so I dont know.

Can you please upload/link to a module which is compiled according to the instructions, but fails the check anyway? I can't fix potential bugs that nobody bothers to report.

People love to go the "easy" way. If I added a switch which would turn this error into a warning again (completely ignoring is a no-go!), I'm pretty sure that the number of incorrectly compiled modules would increase again. Developer doesn't follow the instructions properly, gets the error message, finds out about the option, publishes the module as-is and recommends that all users check the option.

I checked the repository meanwhile. As far as I could tell, there are 29 out of 939 modules left which are not compiled correctly. Not sure how many of them would work anyway. I put lots of thoughts into backwards compatiblity (which is why I'm very careful when introducing new things, knowing that they should be supportable "forever"), but there are limits. I probably spent more time analyzing the consequences of the wrong compilation and discussing this here with you than it would take to fix those modules that are actually worth it.

[C3C0]

I'm still on Eclipse and don't have any problems building my modules without Xposed libs included. I simply have them in "ext" folder instead of "lib" folder which clearly indicates it's a lib that's external thus should not be compiled into resulting APK.

[davcec]

I'm still on Eclipse and don't have any problems building my modules without Xposed libs included. I simply have them in "ext" folder instead of "lib" folder which clearly indicates it's a lib that's external thus should not be compiled into resulting APK.

Another one still on Eclipse here... :-)
You can also create a User Library for the Xposed Framework API (named Xposed API Libraries, for instance) and then reference it on the project classpath:
<classpathentry kind="con" path="org.eclipse.jdt.USER_LIBRARY/Xposed API Libraries"/>
Simple and reusable... 👍
Cheers.