Database Develop

Xposed - Legacy thread. Don't panic, Xposed is still here.

General information on Xposed has been moved to this thread: http://forum.xda-developers.com/xposed/xposed-installer-versions-changelog-t2714053
The FAQ has been moved to this thread: http://forum.xda-developers.com/xposed/-t2735540
Questions, suggestions, bug reports and so on can be posted in the Xposed General forum (for the installer/framework/development only) and in the Xposed Framework modules forum (for anything module-related).

Sounds interesting.I hope that you make a apk that simplifies things for simple user like rom control in AOKP
Keep up the good work my friend

That's great, decompiling/compiling apks is not really my cup of tea lol thanks rovo89

May be useful for my themes, keep working on it

Very interesting... Will try soon.

This looks like a really great idea and could help reduce the need for dev's being pestered by users for mod's every time a new rom is leaked/released, well done sir, hope to see this take off

I will definitely have a swing at this over the next few days. This looks like fun!
**This message will self-destruct**

Thanks for the "thanks" everyone. I decided to create an installer first before looking into the other things. This way, I hope a few people can test whether it works on their device (see first post for the APK).
Some notes about this:
The installer holds the app_process executable and the XposedBridge.jar as assets and can install it to the correct locations (root permissions required!).
It will automatically create a backup of /system/bin/app_process at /system/bin/app_process.orig, which can be restored either via the app or via shell (e.g. adb, works in recovery as well).
I have only tested it on ICS (LPQ Stock). Honestly, I do not have the time to test it with anything below that. If somebody wants to do this, I can help you to get started with the code. app_process was not changed very often, so chances are rather good that it will work with only few changes.
The installer requires SDK15 (4.0.3) for the same reason.
Improvements for any part of the code are welcome! It should be easy to use for both users and developers.
(Un-)Installing the installer app alone does not change anything (at least not now). Please use the buttons inside the app.
The next step should now really be to load modules dynamically, I hope I can use standard installable APKs for that (although the framework will probably request enabling confirmation for technical and security reasons).

siberian tiger said:
I hope that you make a apk that simplifies things for simple user like rom control in AOKP
Click to expand...
Click to collapse
From what I read, Rom Control seems to be something like the Settings app for ROM-specific stuff? I am not so sure yet whether I want to implement generic settings in the framework.
Having a standard interface for setting loading/saving (like or using Android's Shared Preferences) would probably make sense. But the settings themself can be very different from module to module, so I would rather let those bring their own settings menus.
What I did though was to implement an installer. My idea how it should ideally work for end users:
Install the Xposed Installer
Click the "Install/Update" button in the installer
Install one or more modules
Configure the modules (if necessary)
Have fun!
Where "install" would mean that you can download the app from the Play Store or a website and install it with the usual package manager. At least for steps 1 and 2, this is working already. For the others, I have to see.

Dynamic module loading is implemented now as well. Modules are normal apps with a special metadata tag and an asset describing which classes to load. You can look at my modifications for examples how this works. I think it is quite simple to develop and use.
I feel that Xposed is quite stable right now. It should be very easy to install both the framework and the modules without any knowledge about modding.
Also for developers, creating a new module is not too complicated. If anyone wants to give it a try, I'm happy to help you getting started. I'm convinced that Xposed is great alternative to APK modifying, but it will not work without developers creating modules for it.
Speaking of modules, I have published one for the famous CRT off effect: http://forum.xda-developers.com/showthread.php?t=1583963
The source code is also available at Github. See how it has less than 40 lines (and only about 10 LOC)? I think that this is awesome!

I was not able to install it as normal app hence pushed them to system/app using root explorer.
It works perfectly on XXLPS SENSATION ROM ICS V 3.2
Sent from my GT-I9100 using Tapatalk

OK you got me interested
What is currently holding me back is a lack of "documentation" about how to go about doing things...
Is there any reference info (even source code comments) that I should have a read of?
Or perhaps a little worked-through guide as to how you made the screen-off or red-clock one, complete with the "thinking" behind it all, just to learn the thought process.
This seems potentially hugely useful for me, just need to know what it can do!

Diliban said:
I was not able to install it as normal app hence pushed them to system/app using root explorer.
Click to expand...
Click to collapse
Really? Oh. Did you get any error message? I assume you have allowed installation of non-market apps?
@pulser_g2: Feedback taken! Until now, I focused on bringing Xposed to a level where it is actually doing something useful for end-users.
As there are some steps that can not be documented easily in the source code (e.g. how you mark an app as Xposed module), I will recreate a tutorial how you can create the clock example. I will try to give many details not only what to do, but also how you can know that you need to do this.

TUTORIAL - How to create an Xposed module
The tutorial has been moved to https://github.com/rovo89/XposedBridge/wiki/Development-tutorial

this is one of the most amazing projects made lately.
You are unleashed the best way to handle mods and possible some hacks.
very great work, robo89

Great concepts mate. Very powerful.
Wouldnt this also expose a device to malicious coders?
If a device has this implemented then is it possible that a simple theme could contain something nasty.
Not trying to stop progress of this project just throwing this out there for consideration.
----------------------
GTI9100 KK5

aceofclubs said:
Wouldnt this also expose a device to malicious coders?
If a device has this implemented then is it possible that a simple theme could contain something nasty.
Not trying to stop progress of this project just throwing this out there for consideration.
Click to expand...
Click to collapse
This is an absolutely valid thought.
In a way: Yes, it is easier to do something malicious with this. With great power comes great risk. The thing is: How would you prevent that? I couldn't think of any way once a module has been loaded, because a) how do you identify something malicious and b) how can you block it when it could just circumvent the security measure taken?
So what I did was to require that you enable a newly installed module in the installer. This at least avoids that you install any normal app and it contains a hidden Xposed module.
And not trying to play this question down, but you could insert malicous code in a theme also when you post a new framework.jar or SystemUI.apk. You could just change the smali code, compile it and you have similar power. For example, modifiying the constructor of the Activity class would also get you into any app and you could as well do whatever you want. You wouldn't even find these modifications because of the hundreds of classes in the Android framework. In this point, Xposed modules are easier to check, because they will usually contain just one class with very few and short methods.
Or take Superuser. Yes, it is asking you every time whether you want to execute this command. But the command can as well be a script that could replace files as the root user. Same for the kernel. In any case, when you modify anything in your phone, there is a risk that it is malicous.
As I said, I'm not denying that there could be a misuse of this project. But I do not see a chance to prevent it without blocking even simple real-life modifications. If anybody has ideas, please let me know.

rovo89 said:
This is an absolutely valid thought.
In a way: Yes, it is easier to do something malicious with this. With great power comes great risk. The thing is: How would you prevent that? I couldn't think of any way once a module has been loaded, because a) how do you identify something malicious and b) how can you block it when it could just circumvent the security measure taken?
So what I did was to require that you enable a newly installed module in the installer. This at least avoids that you install any normal app and it contains a hidden Xposed module.
And not trying to play this question down, but you could insert malicous code in a theme also when you post a new framework.jar or SystemUI.apk. You could just change the smali code, compile it and you have similar power. For example, modifiying the constructor of the Activity class would also get you into any app and you could as well do whatever you want. You wouldn't even find these modifications because of the hundreds of classes in the Android framework. In this point, Xposed modules are easier to check, because they will usually contain just one class with very few and short methods.
Or take Superuser. Yes, it is asking you every time whether you want to execute this command. But the command can as well be a script that could replace files as the root user. Same for the kernel. In any case, when you modify anything in your phone, there is a risk that it is malicous.
As I said, I'm not denying that there could be a misuse of this project. But I do not see a chance to prevent it without blocking even simple real-life modifications. If anybody has ideas, please let me know.
Click to expand...
Click to collapse
It is so refreshing to see someone take such a mature approach as this.
I greatly appreciate your time on that tutorial, and I will take a proper read through it while working it out myself later... (on vacation right now, this seems like a good thing to try if it rains )
Regarding security, I guess you could add a way to protect WHAT was being edited... Such that your package needed to declare edit access to package X and Y, and if it doesn't have permission, it can't do it... This way, if I want to interfere in Gmail, the user must agree, and he/she will say "well... Why is my no battery sound tweak touching gmail?" But this obviously doesn't help for frameworks and services where they are all in the one file... :/

pulser_g2 said:
Regarding security, I guess you could add a way to protect WHAT was being edited... Such that your package needed to declare edit access to package X and Y, and if it doesn't have permission, it can't do it... This way, if I want to interfere in Gmail, the user must agree, and he/she will say "well... Why is my no battery sound tweak touching gmail?" But this obviously doesn't help for frameworks and services where they are all in the one file... :/
Click to expand...
Click to collapse
Maybe.. I could rather easily implement something in hookMethod that checks the method to be hooked against a whitelist defined in an asset in the module (which could of course contain wildcards). Then when you enable a module, I could display this whitelist, with a warning if it includes some very central classes/packages/methods (but how to create such a list?).
However, this cannot control the following:
What you do inside the handling method. If you change anything in SystemUI (and that might be only the battery icon or the clock color), this method will be executed in the context of the SystemUI, which has a large set of Android standard permissions.
Calling any methods of the framework and modifying any available variables, as this can be done via standard reflection.
Basically anything that is not handled through XposedBridge, but using standard techniques.

Wanted to install the framework, but i am getting:
sh: /data/data/de.robv.android.xposed.installer/cache/install.sh: no such file or directory
What am i doing wrong ?

Xposed API changelog / developer news

This thread is intended for module developers. Make sure you follow it (i.e. subscribe) to be informed about any API changes and additions.
I will announce changes before the release if they might make existing modules incompatible.
If you're interested in more details, you can follow the GitHub repositories:
https://github.com/rovo89/XposedBridge/commits/master
https://github.com/rovo89/Xposed/commits/master
https://github.com/rovo89/XposedInstaller/commits/master
Here you can also download the API jar file that you need to reference from your project. Make sure you read the development tutorial to understand how it works. Especially make sure that the classes are not included in your APK, but only referenced.
Note that I will only post the latest API version here to drive the adoption of updates.

This is on pretty short notice, but I have removed the method AndroidAppHelper.getActivityThread_mPackages(): https://github.com/rovo89/XposedBridge/commit/892ba9195da5516dd79f175ac95be2b313c8f8ca
It had been used internally some time ago. I scanned the modules which have been uploaded to the repository and didn't find any which uses this method.
Apart from that, I'm planning to make Xposed for command line tools (e.g. am and pm), implemented via IXposedHookCmdInit/initCmdApp(), optional and disabled by default. It is currently used only by App Settings (but unnecessary and therefore removed in the next version) and NFC LockScreenOff Enabler (I will contact the authors).
As the low usage shows, this feature is hardly needed, so there is no need to load Xposed every time such an app is started. It also avoids the additional log entries, which could be confusing for some users. Actually it is so rarely used that I might not even offer a setting in the UI for it, just a command file for experts. I will not remove it completely as it's useful for low-level framework development (I can quickly test whether my native code changes work without having to reboot).

Xposed 2.6 will bring support for replacing dimensions defined in code (instead of merely forwarding to your own resources): https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
The new API will be published once that version is out. Until then, it would still be possible to make adjustments of the API. If you think anything should be changed, please let me know as soon as possible.

Ok devs, 2.6 beta1 is out, and so is the new API (version 52).
Here are the relevant XposedBridge changes to version 42 (internal changes/optimizations are not listed):
The resources API can be disabled via a debug setting in the UI. If your module implements IXposedHookInitPackageResources, it will not be loaded because it likely depends on this API. You can also check (but don't change) the status via XposedBridge.disableResources if you use the API in other ways.
Hooking abstract methods (including methods declared in interfaces) will throw an IllegalArgumentException now. The callback was never executed for them anyway. This change avoids debugging effort on your side because you will notice it immediately.
It's now possible to create a DimensionReplacement object and use it to replace "dimen" resources with values calculated at runtime. Previously it was only possible to forward such resources to your module. Example in the commit message: https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
Removed AndroidAppHelper.createResourcesKey() methods and AndroidAppHelper.getActivityThread_mPackages() - weren't used by any module in the repository.
Fix delayed configuration update for forwarded resources. That's only of interest if your replacement resource contains variants for different qualifiers that might change at runtime (e.g. drawable-land/drawable-port). https://github.com/rovo89/XposedBridge/commit/1c81954e295cdda191cf8a1cf33d21d7c5ea334d
New findConstructorExact() / findAndHookConstructor() methods, similar to the one for methods: https://github.com/rovo89/XposedBridge/commit/a233fa0bc9499eadbe2efc0b49fc3f4a46264614
IXposedHookCmdInit is deprecated now, initCmdApps() won't be called anymore unless an undocumented file has been created. Only two modules used it, both got rid of it without any loss of functionality. This also averts situations like this where logging for tools like am/pm masks errors for Zygote.
Due to some internal changes, the constructor of XResources isn't called anymore (a good thing!), which breaks some features in App Settings (a not so good thing). That's because it relied on updateConfiguration() being called twice, so it could retrieve the package name in the second call and do its changes. A fix for that is on the way, using a new method (getPackageNameDuringConstruction()) added in the last minute, which returns the package name for a very specific situation. You will probably not need it.
Apart from that, there is now an official way to open a certain section in the installer:
Code:
Intent intent = new Intent("de.robv.android.xposed.installer.OPEN_SECTION");
intent.setPackage("de.robv.android.xposed.installer");
intent.putExtra("section", "modules");
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
Possible values for "section" are currently: install, modules, download, logs, settings, about.
You can for example use this to send the user to the module section if you find out that your module isn't active yet. The best way to find out is something like that:
Code:
// in your Activity, call it to find out the activation status
private static boolean isModuleActive() {
return false;
}
// in handleLoadPackage()
if (lpparam.packageName.equals("your.package.name")) {
// don't use YourActivity.class here
findAndHookMethod("your.package.name.YourActivity", lpparam.classLoader,
"isModuleActive", XC_MethodReplacement.returnConstant(true));
}
Do NOT try to read - or even change - the internal files of the Xposed Installer to get this information or force your module to be activated. Not only can this break anytime, it will also be bad user experience and a security threat if your module is active without explicit selection in the app. You will probably see your app removed from the repository if you break the rules.
If you have any questions or remarks, please let me know. And if you haven't subscribed to this thread yet, make sure to do so now in order to stay up-to-date with new developments.

IllegalAccessException if you use reflection yourself
One additional change in the new version was the removal of a hack that nuked some access checks in Dalvik by making them return "true" every time. After some of the other internal changes, some of the processing that required this hack was no longer necessary. With some more refactoring, I was finally able get rid of this hack. That's good because it caused crashes on some badly built ROMs (incorrect smali hacks), but also in some rare cases in normal apps: https://github.com/rovo89/XposedInstaller/issues/89
However, some modules relied on the deactivation of these access checks. Now they get IllegalAccessExceptions when trying to access e.g. private fields or methods.
Does this mean that Xposed used to cause security issues on the whole system? After all, it meant that any app could access things that they couldn't access otherwise, right? So it destroyed Java's security system!
The answer is: No, that wasn't a security issue! The Java access check system is actually optional. When you get a field/method/class via reflection, you just need to call setAccessible(true) on it to disable the access check. Example in XPrivacy: https://github.com/M66B/XPrivacy/co...430849f#diff-a350382a0ec1158ad9769d07bd754a63
Note that this is only needed if you use reflection yourself, e.g. with getDeclaredMethod() / getDeclaredField(). The methods in XposedHelpers call setAccessible() on the result before returning it to you.

2.6 final comes with XposedBridge v54.
The only changes relevant for developers are the addition of XSharedPreferences.hasFileChanged() and XSharedPreferences.getFile(), and a fix for replaced animation/xml resources. If you're using the latter and want to avoid that someone with the buggy version 2.6 beta1 runs into issues with your module, consider bumping the minimum required Xposed version to 54.

In Lollipop, there were a few architectural changes in Android. I hinted one of them in the Q&A:
The most significant one is that the code for system services has been moved to a separate file. For most of the affected modules, this can be solved by a little refactoring (moving code to a different place).
Click to expand...
Click to collapse
In detail, this means: If you want to hook a system service like PackageManagerService, you can no longer do that in initZygote(). Instead, move your code to handleLoadPackage() and check for dummy package "android". Make sure you use lpparam.classLoaders when looking for classes and hooking methods. This way has worked in older Android versions as well, so you don't lose backwards-compatiblity.

I'll just repeat here what I wrote in the official announcement thread, as it'll be helpful for all module developers:
rovo89 said:
After a long time with mainly bug fixes, version 81 focuses on improvements for developers:
There is a proper API now. Previously, I basically published the sources of XposedBridge.jar, which included many internal classes/methods that modules shouldn't use. Hiding them makes it easier to find the correct methods to use and also makes it easier for me to change implementation details.
The API is published on Bintray/JCenter, so it's easy to use, especially with Gradle/Android Studio. Full explanations here: https://github.com/rovo89/XposedBridge/wiki/Using-the-Xposed-Framework-API
100% of the API are documented with Javadoc now: http://api.xposed.info/
Apart from that, downloads have moved to http://dl-xda.xposed.info/framework/ and are GPG-signed now. You can verify them against this key (fingerprint: 0DC8 2B3E B1C4 6D48 33B4 C434 E82F 0871 7235 F333). That's actually the master key, the files are signed with subkey 852109AA.
There are no real changes for end-users in this release, nevertheless I would recommend that at least developers test their modules with it.
Click to expand...
Click to collapse

tag organization system

let me start off by saying that the xposed framework is absolutely awesome but if you've noticed recently just the amount of modules have just gotten a bit unruly I suggest adding some sort of tag system to help organize all the modules
for example some the tags could be device specific modules, type of module, android version etc.
ie. I would disable any tags with sense or touchwiz because I do not on that device and those modules wouldn't work on my device

This is a frequently suggested feature and I think it's valid, but everytime I asked for someone to develop this idea further, replies stopped...
Before thinking about an implementation, it's necessary to find out which kind of categorization makes sense for most modules. There are more than 350 of them now and many of them have different requirements and purposes. Tags make only sense if they are understood and used consistently. Just giving developers the choice to create and assing tags won't work, there need to be clear guidelines, ideally even a predefined set of tags. These guidelines need to be drafted by someone, but I'm too busy to do the major work of it. If some people want to volunteer to analyse the existing modules, look for similarities (and differences) between modules, assign tags to them to get a feeling what's needed and propose guidelines, be my guest. You can use this thread for discussion and coordination.
Just to give you some examples which this isn't trivial:
- Some modules work for basically every ROM and devices.
- Others just work on certain ROMs on certain devices (the device alone is rarely a limiting factor).
- Others will work on a certain type of custom ROM (e.g. CyanogenMod-based) on different devices, but sometimes there might be a version limitation.
- Some modules can work on Sense and TouchWiz - so if you hide all TouchWiz modules, but want to see Sense modules, special filter logic is required.
- Some modules target a certain app.
That's just the works-or-not section, which I suggest to start with. Purposes of modules are even more segmented.

rovo89 said:
This is a frequently suggested feature and I think it's valid, but everytime I asked for someone to develop this idea further, replies stopped...
Before thinking about an implementation, it's necessary to find out which kind of categorization makes sense for most modules. There are more than 350 of them now and many of them have different requirements and purposes. Tags make only sense if they are understood and used consistently. Just giving developers the choice to create and assing tags won't work, there need to be clear guidelines, ideally even a predefined set of tags. These guidelines need to be drafted by someone, but I'm too busy to do the major work of it. If some people want to volunteer to analyse the existing modules, look for similarities (and differences) between modules, assign tags to them to get a feeling what's needed and propose guidelines, be my guest. You can use this thread for discussion and coordination.
Just to give you some examples which this isn't trivial:
- Some modules work for basically every ROM and devices.
- Others just work on certain ROMs on certain devices (the device alone is rarely a limiting factor).
- Others will work on a certain type of custom ROM (e.g. CyanogenMod-based) on different devices, but sometimes there might be a version limitation.
- Some modules can work on Sense and TouchWiz - so if you hide all TouchWiz modules, but want to see Sense modules, special filter logic is required.
- Some modules target a certain app.
That's just the works-or-not section, which I suggest to start with. Purposes of modules are even more segmented.
Click to expand...
Click to collapse
For the Xposed modules index thread, I'm using 9 categories to separate modules by their function, and additional tags for modules that are specific to an Android version or vendor.
If you find that that makes sense and if you'd like to use it, I can share a CSV file (which is easily usable with Python, which is why I picked it) that should have the necessary info to easily add it to your server's data "automatically" (by writing a hopefully short script) (fields include, among others: tags and package name for each module).
I realize this needs discussion and will take a good amount of time and effort, but I'm just offering the index right now should you want to take a look at it. Also, if you think I/the community can make your life easier by categorizing modules with additional tags, I'm sure many will step up to help.

That is so kind of you! Thats awesome
I will also say that I wasn't very clear. (What it became is way awesome)
I meant only like an automatic way to get ones that won't work with my device to be hidden
My scenario for this was I have an aosp gpe tablet. And when I'm brousing modules I don't want to scroll past 6 experia mods that don't apply to me.

Several suggestions

@rovo89: Some ideas & questions:
- For modules some sort of "priority" (maybe only "high") defined in the manifest.xml could be usefull. For HitchXposedLog I altered writing of modules.lst of Installer to load the moduel as first, to hook all other modules
- Some (user configurable?) depends on/loads before&after module xx. There are many modules for the right side of the status bar and the start order matters if you are using many of them
- Can you set writing XSharedPreferences to "deprecated" so it's better visible in Ssource code editor? I forget it again
- Just wondering: Why uses you API 15 hand have set targetSdkVersion to 15?
- Please enable FastScroll and add a indexer: https://github.com/rovo89/XposedInstaller/pull/220

@defim I have moved your post here because it was off-topic in the thread of the changes in the experimental version.
For modules some sort of "priority" (maybe only "high") defined in the manifest.xml could be usefull. For HitchXposedLog I altered writing of modules.lst of Installer to load the moduel as first, to hook all other modules
Click to expand...
Click to collapse
Ouch. I have to say I strongly dislike such modifications of the installer. The next one might just enforce their module to be activated or something. I'll have to think about whether I'm ok with having such a module in the repository... See also: https://github.com/rovo89/XposedBridge/issues/16
As for the priority: See https://github.com/rovo89/Xposed/issues/11. Your use-case is the first one which would really require this. In the way you request it (defined by the module author, not the user), it would be easier to realize, but what happens if multiple modules use this?
Some (user configurable?) depends on/loads before&after module xx.
Click to expand...
Click to collapse
See the issue I linked to. I don't believe that these modules would require a certain loading order if the were written with other modules in mind.
Can you set writing XSharedPreferences to "deprecated" so it's better visible in Ssource code editor? I forget it again
Click to expand...
Click to collapse
You mean the edit() method? I don't think it's usual to make unsupported methods deprecated (at least AOSP doesn't do it), but yeah, I could do that.
Just wondering: Why uses you API 15 hand have set targetSdkVersion to 15?
Click to expand...
Click to collapse
No big reasons, but when I started development, that was the latest version. I still have references to the hidden API functions, using the full set of framework classes for API15. I'm not sure about compatibility. And I don't see advantages of using the newer API, so I'll just keep 15.
Please enable FastScroll and add a indexer: https://github.com/rovo89/XposedInstaller/pull/220
Click to expand...
Click to collapse
See my comments over there. I don't think it makes sense.

rovo89 said:
I have moved your post here because it was off-topic in the thread of the changes in the experimental version.
Click to expand...
Click to collapse
I posted there, because i think the experimental release misses it.
rovo89 said:
Ouch. I have to say I strongly dislike such modifications of the installer. The next one might just enforce their module to be activated or something. I'll have to think about whether I'm ok with having such a module in the repository... See also: https://github.com/rovo89/XposedBridge/issues/16
Click to expand...
Click to collapse
As i wrote, it just changes the saving order, it does not enable itself.
But if the installed had such a priority fuinction it would not be needed.
And if Xposed had an option to enable timestamps in the log, the whole modules would be superfluous
rovo89 said:
As for the priority: See https://github.com/rovo89/Xposed/issues/11. Your use-case is the first one which would really require this. In the way you request it (defined by the module author, not the user), it would be easier to realize, but what happens if multiple modules use this?
Click to expand...
Click to collapse
It's the same question what would be if multiple notifications hav a "high" priority etc. Should only be used if really required
rovo89 said:
See the issue I linked to. I don't believe that these modules would require a certain loading order if the were written with other modules in mind.
Click to expand...
Click to collapse
As i wrote, multiple modules which changes the right side of the statusbar dont work in wrong order
rovo89 said:
You mean the edit() method? I don't think it's usual to make unsupported methods deprecated (at least AOSP doesn't do it), but yeah, I could do that.
Click to expand...
Click to collapse
Yes, i used it again, and wondered why the values was not written..
No big reasons, but when I started development, that was the latest version. I still have references to the hidden API functions, using the full set of framework classes for API15. I'm not sure about compatibility. And I don't see advantages of using the newer API, so I'll just keep 15.
[/QUOTE]
If i remember right, it uses newer themes if available, but only if the api was set. Set the api to 10 and try it, it's better visible...
rovo89 said:
See my comments over there. I don't think it makes sense.
Click to expand...
Click to collapse
Okay, i will delete it

Oh, and another request yet posted somewhere in the "experimental" thread:
"Dont remind for updates", per app.
Usefull if newer versions contain errors so the installer has not to remind me all the time
As all of my ideas are declided, I save time and dont create a push request

EdXposed vs Lsposed

I'm not clear on the differences between them, and it seems that there are even more alternatives.
Is one better than another?
I just got an Android 10 phone, was previously on 7 for a short time, but was otherwise still on 5 and 6.

AllanonMage said:
I'm not clear on the differences between them, and it seems that there are even more alternatives.
Is one better than another?
I just got an Android 10 phone, was previously on 7 for a short time, but was otherwise still on 5 and 6.
Click to expand...
Click to collapse
The main difference is that in LSPosed you have to whitelist apps to be hooked instead of blacklist. The second one is that EdXposed seems to break SafetyNet in latest version. And it seems that it's not that actively developed as LSPosed

They both have whitelist and on LSPosed it set in default. But only EdXposed have blacklist. I saw some comment like "have too much modules and too much apps to hook, how painful to check everything by manually".
Yes, Edxposed still break SafetyNet.
Yes, now Edxposed is not that actively update than LSPosed.
Something about LSPosed
If you can read Chinese, maybe you can read these below: https://www.bilibili.com/read/cv9603603/ https://www.bilibili.com/read/cv9603669/ https://www.zhihu.com/question/442534533 https://www.zhihu.com/question/442531709 I am very troubled by...
forum.xda-developers.com
I personally tried both. Not that much difference. Yeah, because basically LSPosed just forked Edxposed and did a little improvement.
In the end I choose Edxposed rather than LSPosed. Because I can't trust one dev who made a prank about "rm -rf" and the rest dev have no objection to this and even help him to hide it. And those personal attack with filthy language of course.

Arakawa. said:
They both have whitelist and on LSPosed it set in default. But only EdXposed have blacklist. I saw some comment like "have too much modules and too much apps to hook, how painful to check everything by manually".
Yes, Edxposed still break SafetyNet.
Yes, now Edxposed is not that actively update than LSPosed.
Something about LSPosed
If you can read Chinese, maybe you can read these below: https://www.bilibili.com/read/cv9603603/ https://www.bilibili.com/read/cv9603669/ https://www.zhihu.com/question/442534533 https://www.zhihu.com/question/442531709 I am very troubled by...
forum.xda-developers.com
I personally tried both. Not that much difference. Yeah, because basically LSPosed just forked Edxposed and did a little improvement.
In the end I choose Edxposed rather than LSPosed. Because I can't trust one dev who made a prank about "rm -rf" and the rest dev have no objection to this and even help him to hide it. And those personal attack with filthy language of course.
Click to expand...
Click to collapse
The developer you mentioned has left the development group long ago

All I wanna know is which one passes safetytest. Installed edxposed for the first time in 2 years only to discover that safetytest is completely fubar'd. And all the tutorials I've found are old and seemingly obsolete.

This moment, LSPosed is alot better than EdXposed.
Simple that.
I say many thanks to EdXposed, but LSPosed is the future.
We Love EdXposed
We Love LSPosed
We Love Better Future

More than 100 commits less than 20 days
Commits · LSPosed/LSPosed
LSPosed Framework. Contribute to LSPosed/LSPosed development by creating an account on GitHub.
github.com

Arakawa. said:
who made a prank about "rm -rf"
Click to expand...
Click to collapse
Which prank? Will you share the source of the prank? Plz let us know.
Edit: Sorry, haven't noticed the quoted post, got it.

cracky.ice said:
The developer you mentioned has left the development group long ago
Click to expand...
Click to collapse
The man left temporarily, but what he had done was still there. And the rest of the developers don't think rm -rf is wrong. The whole development team had problems, they even excused the malicious code. Communities should not forgive this.

LSPosed is not a good choice for Xposed: from the software itself, module scopes and Xposed Hide (White) were designed as advanced features for advanced users only, and forcing them to be enabled is abusive and will increase the learning cost for users, increase the cost for module developers, break the functionality of global modules, and make modules much less compatible. On the developer level, the LSPosed development team has been suppressing and abusing other Xposed implementations and their developers since the project's inception, attacking third-party ROM developers with web violence, and committing community divisive acts like this; one of the development team members submitted rm -rf /* malicious code to EdXposed, which was responsible for emptying CI user data. The culprit has no credibility.

mlgmxyysd said:
The man left temporarily, but what he had done was still there. And the rest of the developers don't think rm -rf is wrong. The whole development team had problems, they even excused the malicious code. Communities should not forgive this.
Click to expand...
Click to collapse
We will never forgive.
But it is past.
We just need MORE attention before to accept any commit.
We will have bad people everywhere.
Nothing more.

mlgmxyysd said:
LSPosed is not a good choice for Xposed: from the software itself, module scopes and Xposed Hide (White) were designed as advanced features for advanced users only, and forcing them to be enabled is abusive and will increase the learning cost for users, increase the cost for module developers, break the functionality of global modules, and make modules much less compatible. On the developer level, the LSPosed development team has been suppressing and abusing other Xposed implementations and their developers since the project's inception, attacking third-party ROM developers with web violence, and committing community divisive acts like this; one of the development team members submitted rm -rf /* malicious code to EdXposed, which was responsible for emptying CI user data. The culprit has no credibility.
Click to expand...
Click to collapse
YES.
Xposed is for ADVANCED USERS only !!!!
Xposed is not a play for kids.
I agree with you about the difficulty for developers, but well, the future is here.
And we will not accept to remain in the past.
Long Life to LSPosed
But, we love EdXposed too

VD171 said:
YES.
Xposed is for ADVANCED USERS only !!!!
Xposed is not a play for kids.
I agree with you about the difficulty for developers, but well, the future is here.
And we will not accept to remain in the past.
Long Life to LSPosed
But, we love EdXposed too
Click to expand...
Click to collapse
Put away your false future, Xposed (even ROMs) will die because of LSPosed Developers. You don't know what disgusting things LSPosed Developers are doing behind the scenes.

mlgmxyysd said:
Put away your false future, Xposed (even ROMs) will die because of LSPosed Developers. You don't know what disgusting things LSPosed Developers are doing behind the scenes.
Click to expand...
Click to collapse
The point is we need xposed for Android 9, Android 10, Android 11, Android 12, Android 13, Android 14...
We currently have no choices.
Or do you have any?

VD171 said:
The point is we need xposed for Android 9, Android 10, Android 11, Android 12, Android 13, Android 14...
We currently have no choices.
Or do you have any?
Click to expand...
Click to collapse
There will be, just need to wait.

mlgmxyysd said:
There will be, just need to wait.
Click to expand...
Click to collapse
I can't wait.
I have a solution, so I will use it.

But, I'm totally open for new XPOSED alternatives.
Let's keep watching

I did a test with the old original Xprivacy app. Oreo 8.1, Magisk v23, Riru v 25.4.4
With EdXposed: it works, but whole phone is slowed down. Every app is checked and Xprivacy popup asks you how to proceed (accept or deny internet/load/whatever request). It works how it should but sadly phone is slowed down and wallpaper doesn't load after phone bootup
With LSposed: it doesn't work, because: Every app just bypasses most Xprivacy functions, you only get a meaningless Binder Xprivacy popup. Xprivacy has no control over what apps do. Apps do what they want and don't ask for your permission
With Xposed Installer: it runs perfectly, flawlessly. Using the good old "Xposed Installer" with Xposed Framework version 90-beta3, the original. You know every url and request every app does, if they scan your nearby wifi, if or when they use record in cam or audio, scan your contacts, request some device identifiers, you can whitelist the urls, internet requests and loads you want. All app requests logged, apps can't do nothing without your permission. Very useful because you can use (whitelist) the functions in any app that you use and want, and dismiss the rest that's bundled within the app (ad networks, telemetry requests, proprietary functions. resource-hungry unnecessary actions). In the new XprivacyLua these features and logs and this sort of control is not possible. This is why the old original Xprivacy is superior.

jason382 said:
I did a test with the old original Xprivacy app. Oreo 8.1, Magisk v23, Riru v 25.4.4
With EdXposed: it works, but whole phone is slowed down. Every app is checked and Xprivacy popup asks you how to proceed (accept or deny internet/load/whatever request). It works how it should but sadly phone is slowed down and wallpaper doesn't load after phone bootup
With LSposed: it doesn't work, because: Every app just bypasses most Xprivacy functions, you only get a meaningless Binder Xprivacy popup. Xprivacy has no control over what apps do. Apps do what they want and don't ask for your permission
With Xposed Installer: it runs perfectly, flawlessly. Using the good old "Xposed Installer" with Xposed Framework version 90-beta3, the original. You know every url and request every app does, if they scan your nearby wifi, if or when they use record in cam or audio, scan your contacts, request some device identifiers, you can whitelist the urls, internet requests and loads you want. All app requests logged, apps can't do nothing without your permission. Very useful because you can use (whitelist) the functions in any app that you use and want, and dismiss the rest that's bundled within the app (ad networks, telemetry requests, proprietary functions. resource-hungry unnecessary actions). In the new XprivacyLua these features and logs and this sort of control is not possible. This is why the old original Xprivacy is superior.
Click to expand...
Click to collapse
No. Xprivacy is NOT superior.
Xprivacy is totally deprecated and uses old methods and old functions.
XPRIVACYLUA is totally better, superior and CUSTOMIZABLE.
XprivacyLua WORKS PERFECTLY WITH LSPOSED, because I am using it on my main phone.
I LOVE XPRIVACYLUA.
I CAN'T LIVE WITHOUT ROOT, XPOSED AND XPRIVACYLUA !!!!
I LOVE YOU @M66B

LSPosed is the future and as of this date clearly the winner as Edxposed development has halted, it's incompatible with the latest Riru and breaks Safetynet.