Hi people,
I was wondering which parts of ART and what optimizations does Xposed disable. I read from one of @rovo89 GitHub that he needed to disable a couple of optimizations. Do these changes affect performance? If so, how can I make performance better?
Cheers!
-LLJY
It mostly disables method inlining and call sharpening. The latter would usually detect that a call to "myObject.toString()" will always resolve to one particular implementation, so ART would create a call directly to the native address of the compiled method. Both of these make it impossible to hook a method, as ART simply wouldn't look up the method anymore. I don't see a way to avoid this.
Little insight to demonstrate this. Consider this Java code:
Code:
package de.robv.android.xposed.smallapp;
public class MyClass {
private static int sMyField = 999;
public static int returnConstant() {
return 1234;
}
public static void main() {
sMyField = returnConstant();
}
}
This is the Dex code for the main() method:
Code:
0x0000: 7100 0700 0000 | invoke-static {}, int de.robv.android.xposed.smallapp.MyClass.returnConstant() // [email protected]
0x0003: 0a00 | move-result v0
0x0004: 6700 0600 | sput v0, I de.robv.android.xposed.smallapp.MyClass.sMyField // [email protected]
0x0006: 0e00 | return-void
And here is what ART (on Nougat / x86) compiles it to:
Code:
0x00001054: 83EC0C sub esp, 12
0x00001057: 890424 mov [esp], eax
0x0000105a: 8B08 mov ecx, [eax]
0x0000105c: C781B0010000D2040000 mov [ecx + 432], 1234
0x00001066: 83C40C add esp, 12
0x00001069: C3 ret
As you can see, the call to returnConstant() is gone. The value it would always return has been inlined. Granted, this is a very simple example, but this can happen for more complex methods as well. It's incremental, so if returnConstant() returned the result of "square(9)" and that square() function returned "x*x", then it would remove all of those calls and insert the precalculated value 81 in the native code.
Now if a module hooks returnConstant(), that hook would never be called, because, well, the method isn't called either. This behavior would depend on many factors (e.g. compiler filter settings in the ROM), so module developers couldn't even rely on the assumption that the hook isn't called. It would be virtually random.
To avoid this (and also a few similar simplifications), the Xposed fork of ART disables these optimizations and recompiles all the odex/oat files. I actually have no idea how big the performance impact is, but it's necessary. It can't even be selective, as it's not known at compile time which methods will be hooked. This optimization can't be reverted when a method is hooked (e.g. by recompiling that method), because it would mean that all the calling methods would have to be recompiled, which would require a list of all callers of that method (or at least those that have inlined it).
I'm not sure about Nougat yet. It has a JIT compiler (Marshmallow had one, too, but it was disabled because it wasn't stable yet), maybe that brings some new opportunities. But that's still a long way, first hooking has to work at all.
rovo89 said:
Little insight to demonstrate this. Consider this Java code:
This is the Dex code for the main() method:
And here is what ART (on Nougat / x86) compiles it to:
As you can see, the call to returnConstant() is gone. The value it would always return has been inlined.
some new opportunities. But that's still a long way, first hooking has to work at all.
Click to expand...
Click to collapse
Thank you for the response, I would just like to report that xposed adds a substantial amount of overhead compared to normal ART. Especially noticeable when ART is set to optimize everything.
Before flashing xposed, my phone running my own custom rom is noticeably faster compared to the iPhone 7. After flashing xposed, it lags behind quite abit.
I did loads of testing to come to this conclusion.
Just some feedback for you
_LLJY said:
I did loads of testing to come to this conclusion.
Click to expand...
Click to collapse
Did you also do real benchmarks? Most of the time when people talk about performance, they say it "feels" slower, but that's hard to investigate...
Also, modules might of course add overhead as well. What I mentioned above just refers to the framework itself.
rovo89 said:
Did you also do real benchmarks? Most of the time when people talk about performance, they say it "feels" slower, but that's hard to investigate...
Also, modules might of course add overhead as well. What I mentioned above just refers to the framework itself.
Click to expand...
Click to collapse
I tested Xposed on 3 devices, 2 ARMV7 and one ARM64. The Redmi note 4g(snapdragon 400) doesn't seem to be affected much at all. The Xperia Z5 (810) seems to slow down noticeably(I tested against a brand new Z5 with the same Rom) the Xiaomi mi3(800) does also get affected slightly although i haven't compared it against another new device. I will conduct a more scientific test where I actually time the devices using discomark to see how they do and put the results in a spreadsheet.
rovo89 said:
Did you also do real benchmarks? Most of the time when people talk about performance, they say it "feels" slower, but that's hard to investigate...
Also, modules might of course add overhead as well. What I mentioned above just refers to the framework itself.
Click to expand...
Click to collapse
on 6.0.1(nexus 5x) i don`t see any diference with or without xposed but seems on nougat will be a little complicate with the art modifications ! btw @rovo89 the xposed can be your phD theme (this is research)
Xposed sdk 23 v 86 does not work with cm 13 for i 9515 with newest kernel 3.4.113 anymore. Hope there will still be updates for xposed sdk 23????
Quote:
Originally Posted by friscoboi @sombree 20161115 got me stuck in a bootloop so far. I did everything as always with updates? Or does it take more than 30 minutes to reboot with the new kernel the first time?
It's because you're using xposed. And no, I'm not going to rebuild ROM with one of those unofficial fixes - you'll have to wait for fixed xposed
(Sorry to post here, but the older xposed thread is closed...)
rovo89 said:
Little insight to demonstrate this. Consider this Java code:
Code:
package de.robv.android.xposed.smallapp;
public class MyClass {
private static int sMyField = 999;
public static int returnConstant() {
return 1234;
}
public static void main() {
sMyField = returnConstant();
}
}
This is the Dex code for the main() method:
Code:
0x0000: 7100 0700 0000 | invoke-static {}, int de.robv.android.xposed.smallapp.MyClass.returnConstant() // [email protected]
0x0003: 0a00 | move-result v0
0x0004: 6700 0600 | sput v0, I de.robv.android.xposed.smallapp.MyClass.sMyField // [email protected]
0x0006: 0e00 | return-void
And here is what ART (on Nougat / x86) compiles it to:
Code:
0x00001054: 83EC0C sub esp, 12
0x00001057: 890424 mov [esp], eax
0x0000105a: 8B08 mov ecx, [eax]
0x0000105c: C781B0010000D2040000 mov [ecx + 432], 1234
0x00001066: 83C40C add esp, 12
0x00001069: C3 ret
As you can see, the call to returnConstant() is gone. The value it would always return has been inlined. Granted, this is a very simple example, but this can happen for more complex methods as well. It's incremental, so if returnConstant() returned the result of "square(9)" and that square() function returned "x*x", then it would remove all of those calls and insert the precalculated value 81 in the native code.
Now if a module hooks returnConstant(), that hook would never be called, because, well, the method isn't called either. This behavior would depend on many factors (e.g. compiler filter settings in the ROM), so module developers couldn't even rely on the assumption that the hook isn't called. It would be virtually random.
To avoid this (and also a few similar simplifications), the Xposed fork of ART disables these optimizations and recompiles all the odex/oat files. I actually have no idea how big the performance impact is, but it's necessary. It can't even be selective, as it's not known at compile time which methods will be hooked. This optimization can't be reverted when a method is hooked (e.g. by recompiling that method), because it would mean that all the calling methods would have to be recompiled, which would require a list of all callers of that method (or at least those that have inlined it).
I'm not sure about Nougat yet. It has a JIT compiler (Marshmallow had one, too, but it was disabled because it wasn't stable yet), maybe that brings some new opportunities. But that's still a long way, first hooking has to work at all.
Click to expand...
Click to collapse
Dalvik VM also uses JIT compiler
Sent from my GT-S7580 using Tapatalk
DodoGTA said:
This is the Dex code for the main() method:
And here is what ART (on Nougat / x86) compiles it to:
As you can see, the call to returnConstant() is gone. The value it would always return has been inlined. Granted, this is a very simple example, but this can happen for more complex methods as well. It's incremental, so if returnConstant() returned the result of "square(9)" and that square() function returned "x*x", then it would remove all of those calls and insert the precalculated value 81 in the native code.
Now if a module hooks returnConstant(), that hook would never be called, because, well, the method isn't called either. This behavior would depend on many factors (e.g. compiler filter settings in the ROM), so module developers couldn't even rely on the assumption that the hook isn't called. It would be virtually random.
To avoid this (and also a few similar simplifications), the Xposed fork of ART disables these optimizations and recompiles all the odex/oat files. I actually have no idea how big the performance impact is, but it's necessary. It can't even be selective, as it's not known at compile time which methods will be hooked. This optimization can't be reverted when a method is hooked (e.g. by recompiling that method), because it would mean that all the calling methods would have to be recompiled, which would require a list of all callers of that method (or at least those that have inlined it).
I'm not sure about Nougat yet. It has a JIT compiler (Marshmallow had one, too, but it was disabled because it wasn't stable yet), maybe that brings some new opportunities. But that's still a long way, first hooking has to work at all.
Dalvik VM also uses JIT compiler
Click to expand...
Click to collapse
You don't say
rovo89 said:
Did you also do real benchmarks? Most of the time when people talk about performance, they say it "feels" slower, but that's hard to investigate...
Also, modules might of course add overhead as well. What I mentioned above just refers to the framework itself.
Click to expand...
Click to collapse
I still haven't done actual tests due to time constraints but an interesting thing is that XDA labs does indeed take a fraction of a second longer to launch with Xposed. But it's barely noticeable, I had to time it.
_LLJY said:
I still haven't done actual tests due to time constraints but an interesting thing is that XDA labs does indeed take a fraction of a second longer to launch with Xposed. But it's barely noticeable, I had to time it.
Click to expand...
Click to collapse
if it helps, with xposed activated and deactivated (typically after a new rom install), activated it's perfectly fine, performance is a bit hindered but not so much that you notice it right away. Skip ahead a couple hours and it's laggy and slow, stuttering, apps don't open quite as fast, nor do they stay open (that's to do with another issue regarding xposed v87). But before that v87 update, that issue persisted.
But when i have xposed disabled (after flashing the new build), it's perfectly fine, performance is as snappy as a GS4 (SD600) would get you and apps open faster, don't lag or get bogged down. And they generally perform much better over time.
I can at least for me, confirm this since I've started using xposed (v70-76 i believe).
(Sprint Galaxy S4 SD600 16gb model, cm13 (12/4/2016 nightly) with ten modules installed.)
Do let me know if this helps at all with determining the performance hit with xposed enabled and with a decent amount of modules installed.
I'm gonna guess there's no new news about xposed for nougat
Shiftydogit said:
I'm gonna guess there's no new news about xposed for nougat
Click to expand...
Click to collapse
Correct. @rovo89 has not quite cracked the code on making it work with N just yet. He's working on it though so patience is required.
sjamie said:
Correct. @rovo89 has not quite cracked the code on making it work with N just yet. He's working on it though so patience is required.
Click to expand...
Click to collapse
Hopefully he gets it N seems like a pain in the grass for a lot of things we power users enjoy
Shiftydogit said:
Hopefully he gets it N seems like a pain in the grass for a lot of things we power users enjoy
Click to expand...
Click to collapse
Amen.
Wonder what's happening, I heard that Nougat xposed is unreliable with JIT?
I hope it gets fixed soon and gets out to the public.
Anyways, great job devs<3
Rotated Quickbits said:
Wonder what's happening, I heard that Nougat xposed is unreliable with JIT?
I hope it gets fixed soon and gets out to the public.
Anyways, great job devs<3
Click to expand...
Click to collapse
Maybe a new year present????
mitas35 said:
Maybe a new year present????
Click to expand...
Click to collapse
I'm going to like and respond to this post as it was only minutes away from the new years
All I'm hoping for, is that Android O doesn't mess with the compiler any more than N did, Android O Developer Previews are going to come before the official announcement on the 17 - 19 May 2017, and first betas are set to come in the summer, which aren't that far away...
If it does, then its going to be a long catch up game for @rovo89
Related
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
For my Xposed Module Play Store Chagenlog an update was released yesterday, this added a GUI as wel as some options. There have been quite a few reports about settings preferences not being applied. After some debugging, I found out that this XSharedPreferences simply doesn't have any entries and thus always returns the default values. I'm 100% sure the options are set (the preferences screen shows them correct and you can see them in the .xml) and the right file is being loaded. There are no errors in the Xposed Log or in the logcat.
I've found a workaround (only tested by me), unchecking and re-checking an option and then the preferences are read correctly. All my modules (actually most of all Xposed Modules) use this way to load an user's preferences, I have absolutely no clue what's causing this behaviour.
The source code is on GitHub, links to relevant files:
PlayStoreChangelog.java
SettingsActivity.java
SettingsFragment.java
settings.xml
For debugging purposes, I've added a snippet to dump the preferences beneath initializing XSharedPreferences. This says it loads the right file, the file exists but it contains no entries (size 0). So when trying to get values (getString, getBoolean etc), it only returns the default values.
Java:
sharedPreferences = new XSharedPreferences(BuildConfig.APPLICATION_ID);
XposedBridge.log(LOG_TAG + sharedPreferences.getFile().getAbsolutePath() + " exists: " + sharedPreferences.getFile().exists());
XposedBridge.log(LOG_TAG + " ---PREFS: " + sharedPreferences.getAll().size() + "---");
Map<String, ?> sortedKeys = new TreeMap<String, Object>(sharedPreferences.getAll());
for (Map.Entry<String, ?> entry : sortedKeys.entrySet()) {
XposedBridge.log(LOG_TAG + entry.getKey() + "=" + entry.getValue().toString());
}
Summary
The app uses a PreferenceFragment to set the preferences and XSharedPreferences to load them. The changes are written to the .xml file and shown in the GUI. The XSharedPreferences instance remains empty and does not contain any entries, thus it always returns the default value. I don't get why it doesn't work, I don't even get why the 'workaround' does work.
I'd really appreciate any help, I'm stuck on this one. No idea what causes it and whether it's a but in my code or something else.
I hope I gave enough information. Thanks in advance.
I'm really stuck on this one, I haven't got a clue what causes this. Maybe @rovo89, @MohammadAG, @GermainZ or @defim, you guys are the most experienced Xposed developers out here. Thanks in advance!
Could something like `sharedPreferences.makeWorldReadable();` (probably needs to be in initZygote) solve your issue? I can't personally think of any reason this might happen except a permission issue.
(Also make sure you're using the latest Xposed Bridge API. I remember there were some commits related to XSharedPreferences, although I can't remember what they were exactly and can't check right now.)
Permission problem sounds reasonable. PSC has for its xml file only set 660, so world readable is mission. After changing it by command line Play Store starts as expected. But i've to say that i use in no app the makeWorldReadable(), Xposed should do it by itself: http://forum.xda-developers.com/showpost.php?p=41976845&postcount=1586 But I also dont use settings fragment, which could cause it...
GermainZ said:
Could something like `sharedPreferences.makeWorldReadable();` (probably needs to be in initZygote) solve your issue? I can't personally think of any reason this might happen except a permission issue.
(Also make sure you're using the latest Xposed Bridge API. I remember there were some commits related to XSharedPreferences, although I can't remember what they were exactly and can't check right now.)
Click to expand...
Click to collapse
defim said:
Permission problem sounds reasonable. PSC has for its xml file only set 660, so world readable is mission. After changing it by command line Play Store starts as expected. But i've to say that i use in no app the makeWorldReadable(), Xposed should do it by itself: http://forum.xda-developers.com/showpost.php?p=41976845&postcount=1586 But I also dont use settings fragment, which could cause it...
Click to expand...
Click to collapse
First of al, both thanks you for your response, it's highly appreciated.
I've been testing with permissions, it indeed looks like a permission problem, because makeWorldReadable() solved it. I use the following line the SettingsFragment to make it World Readable, which has always worked, even though Context.MODE_WORLD_READABLE is officially deprecated because if security reasons:
Java:
getPreferenceManager().setSharedPreferencesMode(Context.MODE_WORLD_READABLE);
It creates a file with 660 permissions, with makeWorldReadable in initZygote it sets it to 664. This is my initZygote:
Java:
@Override
public void initZygote(StartupParam startupParam) throws Throwable {
sharedPreferences = new XSharedPreferences(BuildConfig.APPLICATION_ID);
XposedBridge.log(LOG_TAG + "Readable before: " + sharedPreferences.getFile().canRead());
sharedPreferences.makeWorldReadable();
XposedBridge.log(LOG_TAG + "Readable after: " + sharedPreferences.getFile().canRead());
}
The weird thing is, both readable before and after return true, which indicates it has the permission to read the file before makeWorldReadable(). But... it doesn't work without it
In the end, I created a snippet in SettingsFragment to solve it where the problem arises, instead of makeWorldReadable():
Code:
File sharedPrefsDir = new File(getActivity().getFilesDir(), "../shared_prefs");
File sharedPrefsFile = new File(sharedPrefsDir, getPreferenceManager().getSharedPreferencesName() + ".xml");
if (sharedPrefsFile.exists()) {
sharedPrefsFile.setReadable(true, false);
}
This still needs setSharedPreferencesMode(Context.MODE_WORLD_READABLE), otherwise the permissions will be reset to 660 when a preference changes, now they stay 664. So basically al it does it make it readable for others in addition to the setSharedPreferenceMode().
Thanks again for your replies, it really helped. I still think it's weird, especially since File.canRead() returns true, while it obviously can't read it. I hope it'll help others in the future.
I think I use the deprecated SettingsActivity for this reason. I can override getSharedPreferences so it always returns a world readable file, this avoids the permissions resetting when a preference changes.
Sent from my HTC One_M8 using Tapatalk
MohammadAG said:
I think I use the deprecated SettingsActivity for this reason. I can override getSharedPreferences so it always returns a world readable file, this avoids the permissions resetting when a preference changes.
Sent from my HTC One_M8 using Tapatalk
Click to expand...
Click to collapse
Thanks for your response, just checked out one of your modules, saw you were using getPreferenceManager().setSharedPreferencesMode(MODE_WORLD_READABLE); too. (and indeed SettingsActivity). This has always been sufficient for me using PreferenceFragment. To be sure it's world readable I now manually set the permissions on onPause as a workaround. Still weird because it has always worked flawless for me.
P1nGu1n_ said:
Thanks for your response, just checked out one of your modules, saw you were using getPreferenceManager().setSharedPreferencesMode(MODE_WORLD_READABLE); too. (and indeed SettingsActivity). This has always been sufficient for me using PreferenceFragment. To be sure it's world readable I now manually set the permissions on onPause as a workaround. Still weird because it has always worked flawless for me.
Click to expand...
Click to collapse
Yeah, I also override getSharedPreferences in PreferenceActivity, that allows it to stay world readable.
Sent from my HTC One_M8 using Tapatalk
Sam code works for me in XInstaller. Try check it out, it is open source.
Be aware that using XSharedPreferences will probably lead to problems on Lollipop caused by more stringent SELinux rules.
M66B said:
Be aware that using XSharedPreferences will probably lead to problems on Lollipop caused by more stringent SELinux rules.
Click to expand...
Click to collapse
Good point, but it's too early to say. I'll wait for Xposed to be compatible (hope it will), than I'll look into what changes it'll require. That's something almost every Xposed developer will face ;p
Sent from my phone, please forgive any tpyos.
Yes, I think also Xposed should then handle with LOL XResources properly
Breaking XSharedPreferences means that *almost* every module is not going to work on Lollipop.
I also migrated my project to use PreferenceFragment and getPreferenceManager().setSharedPreferencesMode(Context.MODE_WORLD_READABLE) pretty much does nothing. After I change any setting, prefs file lose "world available" mode.
I checked out P1ngu1n_'s implementation using PreferenceFragment, but it still doesn't work for me. Do any of you have an idea why?
Here is my source
The only difference I can see is that I don't have an xml file for the preferences and that I'm adding the keys in the fragment.
I even checked the permissions and they seem to be fine.
asdfasdfvful said:
I checked out P1ngu1n_'s implementation using PreferenceFragment, but it still doesn't work for me. Do any of you have an idea why?
Here is my source
The only difference I can see is that I don't have an xml file for the preferences and that I'm adding the keys in the fragment.
I even checked the permissions and they seem to be fine.
Click to expand...
Click to collapse
If the permissions seem to be fine, than what doesn't work?
P1nGu1n_ said:
If the permissions seem to be fine, than what doesn't work?
Click to expand...
Click to collapse
That's what confuses me. I have the xml file under shared_prefs and it definitely has values. However, xposed won't read it unless I open the app itself.
Sent from my Nexus 5 using Tapatalk
EDIT: Solution was posted to bypassing root-detection in the Amazon Flex App using a recently added feature to Security Bypasser 1.0.9.
****************
I have an Amazon app for doing contract deliveries for them, I need it to work on my rooted device. I'm pretty sure I've exhausted all other means of hiding root, as they are using native code (I think) to make one of their root checks.
They are implementing RootBeer to do their root-check. I have used APKTools to inspect the Amazon apk, coupled with reading through the source code for RootBeer I feel like I am just around the corner from getting this thing cracked.
UserAlertManager.smali has this line in it:
Code:
invoke-static {}, Lcom/scottyab/rootbeer/RootBeer;->checkForRootNative()Z
RootBeer.java has this:
Code:
/**
* Native checks are often harder to cloak/trick so here we call through to our native root checker
* @return true if we found su | false if not
*/
public boolean checkForRootNative() {
String binaryName = "su";
String[] paths = new String[Const.suPaths.length];
for (int i = 0; i < paths.length; i++) {
paths[i] = Const.suPaths[i]+binaryName;
}
RootBeerNative rootBeerNative = new RootBeerNative();
rootBeerNative.setLogDebugMessages(true);
return rootBeerNative.checkForRoot(paths) > 0;
}
And rootBeerNative is:
Code:
package com.scottyab.rootbeer;
/**
* Created by mat on 19/06/15.
*/
public class RootBeerNative {
/**
* Loads the C/C++ libraries statically
*/
static {
System.loadLibrary("tool-checker");
}
public native int checkForRoot(Object[] pathArray);
public native int setLogDebugMessages(boolean logDebugMessages);
}
And below is about where I am at:
Code:
package com.deleonemail.fixdet;
import android.util.Log;
import de.robv.android.xposed.XC_MethodReplacement;
import de.robv.android.xposed.XC_MethodHook;
import static de.robv.android.xposed.XposedHelpers.findAndHookMethod;
import de.robv.android.xposed.IXposedHookLoadPackage;
import de.robv.android.xposed.XposedBridge;
import de.robv.android.xposed.callbacks.XC_LoadPackage.LoadPackageParam;
public class stopdet implements IXposedHookLoadPackage {
public void handleLoadPackage(final LoadPackageParam lpparam) throws Throwable {
if (!lpparam.packageName.equals("com.amazon.rabbit"))
return;
findAndHookMethod("com.amazon.rabbit.android.presentation.alert.useralert.UserAlertManager", lpparam.classLoader, "checkForRootNative", new XC_MethodHook() {
@Override
protected void afterHookedMethod(MethodHookParam param) throws Throwable {
Log.v("rootbeer","grabbed UAM");
param.setResult(false);
}
});
//XposedBridge.log("we are in RootBeer!");
//param.setResult(false);
}
}
Any help getting this thing working right would be amazing!
nightauthor said:
Any help getting this thing working right would be amazing!
Click to expand...
Click to collapse
I was asked to add Amazon Flex support to my Xposed module and I just released it a few minutes ago. Check out Security Bypasser 1.0.9. You can check the source code. Your code is actually correct, but RootBeer has 5 more root checking functions active in Amazon Flex, that's why it still failed for you.
Amazon Flex' native library is "just" calling Java code, thus Xposed can easily override the functions. Other apps do stuff directly from native code, and that's much harder.
Setialpha said:
I was asked to add Amazon Flex support to my Xposed module and I just released it a few minutes ago. Check out Security Bypasser 1.0.9. You can check the source code. Your code is actually correct, but RootBeer has 5 more root checking functions active in Amazon Flex, that's why it still failed for you.
Amazon Flex' native library is "just" calling Java code, thus Xposed can easily override the functions. Other apps do stuff directly from native code, and that's much harder.
Click to expand...
Click to collapse
Thank you so much, this works perfectly. I'll definitely give the source a look. I didnt think to get into the other stuff because looking at the LogCat I only saw the xbin/su being detected, so I figured I needed to stop that and maybe move on from there.
I guess I was doing something wrong with the log command, because I never saw anything come up in my Logcat when trying to hook anything other than rabbit. I also wasnt sure about the "com.scottyab.rootbeer.RootBeer.isAnyPackageFromListInstalled())", didnt know if I needed rootbeer.RootBeer or just rootbeer.METHOD(). Thanks for your work and the great reference material.
I was concerned that this process might be harder than it was, because I thought surely someone would have done it already. And it seems you beet me to it, it was a learning experience, spent countless hours the past 1.5 days reading about Xposed, trying to make a module, figuring out that Instant Run in Android Studio sucks. And a bunch of other little things that took way too long to figure out. But here I am, pretty damn close to actually knowing how to hook and override a method.
how did it go?
Root-detection is no-longer bypassed
Amazon turned on some kind of new root-checking functionality in Amazon Flex today. No method of root-hiding seems to work at this moment. Not hiding the binary, not Security Bypasser, etc.
Can anything be done about this? It's kind of a big deal.
_kauffy_ said:
Amazon turned on some kind of new root-checking functionality in Amazon Flex today. No method of root-hiding seems to work at this moment. Not hiding the binary, not Security Bypasser, etc.
Can anything be done about this? It's kind of a big deal.
Click to expand...
Click to collapse
I updated just an hour ago, and while something had changed as far as the functionality of my script, the app did not seem to notice my phone being rooted at all.
Due to the changes on the offers page causing issues with my script, I reverted (I had created a backup on titanium backup). I will need to do some more testing later, but for now, I am going to keep using this version of the app for as long as I possibly can.
Still a problem with mine..
nightauthor said:
I updated just an hour ago, and while something had changed as far as the functionality of my script, the app did not seem to notice my phone being rooted at all.
Due to the changes on the offers page causing issues with my script, I reverted (I had created a backup on titanium backup). I will need to do some more testing later, but for now, I am going to keep using this version of the app for as long as I possibly can.
Click to expand...
Click to collapse
What market are you in? It may be they haven't pushed this to all the markets yet.
Also, what are you using root for in this case? I think it may be the same as I am. Curious how you did it, though we might want to take this conversation out of public view.
nightauthor said:
I updated just an hour ago, and while something had changed as far as the functionality of my script, the app did not seem to notice my phone being rooted at all.
Due to the changes on the offers page causing issues with my script, I reverted (I had created a backup on titanium backup). I will need to do some more testing later, but for now, I am going to keep using this version of the app for as long as I possibly can.
Click to expand...
Click to collapse
Im using the module on the amazon version 3.0.5947.2 and is working fine. Thanks for the module. :good:
Anonymus1725 said:
Im using the module on the amazon version 3.0.5947.2 and is working fine. Thanks for the module. :good:
Click to expand...
Click to collapse
Do you have the apk for your version, and can you get it to me? Thanks!
CommanderZurek said:
Do you have the apk for your version, and can you get it to me? Thanks!
Click to expand...
Click to collapse
I dont have the phone now its in a repair shop, and I have a SD but I dont have a SD card reader. when I have Back I can check if I have the APK.
Bypass root detection
Hopefully this will help someone... I had a Verizon S6 that i rolled back to OK7, then rooted by using the tar file in this folder and kingroot G920V Root By RubenTomala files. Then installed Amazon flex and it detected root. I used Xposed Installer by dvdandroid to install Xposed and then installed Wanam.
I installed the bypass module and tried it no go. Then i tried it with Bypasser module and rootcloak and it worked fine.
how do you bypass this root-check on Android 7.x / Lineage OS 14.1 without Xposed ?
Bypass for maadhaar app
I also find the rootbeer native detection in the maadhaar app. Can you please bypass the rootdetection for this https://play.google.com/store/apps/details?id=in.gov.uidai.mAadhaarPlus also.
I will be very thankful.
It is not working no more.
May you help me to bypass root-checker library, please?
Thank you very much
Hi,
I'm acually working on LineageOS 15.1 and I'm running into a problem:
In frameworks/base/core/java/android/content/BroadcastReceiver.java (in the method PendingResult beginning with line 86) the resultCode is set to 4!
This is
Code:
RESULT_SMS_UNSUPPORTED
added in API level 19
public static final int RESULT_SMS_UNSUPPORTED
Set by BroadcastReceiver to indicate that the message, while possibly valid, is of a format or encoding that is not supported.
Constant Value: 4 (0x00000004)
My problem is, I can't figure out, where and why this is set!
So, it's not possible to send a message via SMS...
Any help is welcome!
These two main problems are left in LineageOS 15.1:
Camera not working
Sending SMS not working
There are a few minor problems, but they are not important.
If there is no further help, this finally will be the end of developing this ROM! :crying:
thanks for the work
im just want stable rom.
my stock ROM reboot too much everday after rooting.
so now im using 14.1 no reboot here, you already lose lots good options in the LA14 camera like slow motion(high fps rate) and EIS \ OIS
this phone slowly dying
even my old sony(LWW) was develop from android 2.3 upto 7.1 (through CM to lineage) about 7 years (include custom roms)
Superrman said:
thanks for the work
im just want stable rom.
my stock ROM reboot too much everday after rooting.
so now im using 14.1 no reboot here, you already lose lots good options in the LA14 camera like slow motion(high fps rate) and EIS \ OIS
this phone slowly dying
even my old sony(LWW) was develop from android 2.3 upto 7.1 (through CM to lineage) about 7 years (include custom roms)
Click to expand...
Click to collapse
I understand what you are saying but I think the users enjoying Bernie's ROM are practical users who do not care about latest (crap) features like live emoji or animojis or whatever teenage functions they implement. Real innovations are not to be found. Currenty i switch between my iPhone 7 and Z5c every other week. I still think my Z5c rocks!
I would love to try L15 so I sincerely hope Bernie will find support for his development.
Berni-0815 said:
Hi,
My problem is, I can't figure out, where and why this is set!
Click to expand...
Click to collapse
I've been skimming through LOS repos. AFAICT, the only place in which that constant is used is here.
Antonio
antonio.galea said:
I've been skimming through LOS repos. AFAICT, the only place in which that constant is used is here.
Click to expand...
Click to collapse
Yes; I know. But I've set a logging command at this point and the code is never reached.
So, it ("4") must be set somewhere else...
I've set so much logging commands in some suspicious sourcecode-files but I can't figure out, where this could happen.
The logging commands are showing this chronological order:
Code:
packages/apps/Messaging/src/com/android/messaging/util/PhoneUtils.java #getCanonicalByCountry()
- MessagingApp: (bt): Number valid at this point! getCanonicalByCountry(): canonicalNumber: +nnnnnnnnnnn
>>> It must happen [B]after[/B] the above sourcecode-file and [B]before[/B] the next ones: <<<
frameworks/base/core/java/android/app/LoadedApk.java (Don't find anything)
frameworks/base/core/java/android/content/BroadcastReceiver.java #getResultCode() #PendingResult() #getPendingResult() and #setPendingResult()
- BroadcastReceiver: (bt): PendingResult(Line 86): resultCode: 4
We are now working on the new Xposed API, which allows modules to get / set scope, to get framework info, and to store configs across apps without the embarrassing New-XSharedPreferences interface. The API library will be released to GitHub/libxposed and maven central after it is ready.
Now we are considering removal of resources hook in the incoming new API, so we need to know whether it is still needed or unreplaceable for some modules.
About why we want to remove this API: Resources hook is very hard to maintain and is even not fully supported now under some frameworks (e.g. Taichi). So even if we keep it, it will be maintain-only.
Old modules can still use this feature. We are just considering remove it in the new API.
You can vote at the LSPosed Telegram group or write your opinion here. Also we are glad to hear your suggestions about the new API.
@AndroidX @siavash79 @Dark_Eyes_ @firefds @David B. @Quinny899 @wanam
Just mentioning you guys since you're all active here on XDA. Please see the first post.
Regards,
shadowstep
Senior Moderator
Dr-TSNG said:
We are now working on the new Xposed API, which allows modules to get / set scope, to get framework info, and to store configs across apps without the embarrassing New-XSharedPreferences interface. The API library will be released to GitHub/libxposed and maven central after it is ready.
Now we are considering removal of resources hook in the incoming new API, so we need to know whether it is still needed or unreplaceable for some modules.
About why we want to remove this API: Resources hook is very hard to maintain and is even not fully supported now under some frameworks (e.g. Taichi). So even if we keep it, it will be maintain-only.
Old modules can still use this feature. We are just considering remove it in the new API.
You can vote at the LSPosed Telegram group or write your opinion here. Also we are glad to hear your suggestions about the new API.
Click to expand...
Click to collapse
Thanks for getting opinions
1. Xshared preferences interface overhaul is good news since it was always unstable for me. I personally switched to remote preferences API for AOSPMods
2. When going to systemUI and framework, it's sometimes very difficult and complicated to change some variable values through Xposed, specially with R8 code optimizations which dramatically limit the points we can hook into code.
There are two workarounds I know of, being Xposed resource hooking that can be also dynamic in runtime, or overlays, which being static, still limit the way we can change resources dramatically.
So, I'd really suggest keeping it in the API
siavash79 said:
2. When going to systemUI and framework, it's sometimes very difficult and complicated to change some variable values through Xposed, specially with R8 code optimizations which dramatically limit the points we can hook into code.
Click to expand...
Click to collapse
For R8 code optimizations, we introduced a new API to parse dex file, which allows modules to find methods/fields more accurately.
Anyway if we finally decide to keep resources hook API, do you have any suggestions on keeping/adding/removing specific methods of it or refine it to a more modern interface?
Perfect news.
About resource hooking, few things to note are that: it can't differentiate between different resource files, for example normal values vs landscape or dark/light values. It would be great if there's a way to push different values to different resource files.
Also, there are more limitations when talking about special resources such as themes. As an example, in AOSPMods, one of the reasons it's a magisk module instead of being a normal APK is that overlay files have to be used in cases that need modification of theme resources and that can't be done via resource hooking.
I personally love to get a more complete/flexible resource hooking API, but I completely understand if that's too much to ask. So even keeping it as currently is would be good enough
Thank you @shadowstep for bringing this to my attention!
Dr-TSNG said:
We are now working on the new Xposed API, which allows modules to get / set scope, to get framework info, and to store configs across apps without the embarrassing New-XSharedPreferences interface. The API library will be released to GitHub/libxposed and maven central after it is ready.
Click to expand...
Click to collapse
That's wonderful news, although I do not quite understand what you have against the new XSharedPreferences interface. I use it in my modules, and I've never had any issues with it.
Dr-TSNG said:
Now we are considering removal of resources hook in the incoming new API, so we need to know whether it is still needed or unreplaceable for some modules.
About why we want to remove this API: Resources hook is very hard to maintain and is even not fully supported now under some frameworks (e.g. Taichi). So even if we keep it, it will be maintain-only.
Old modules can still use this feature. We are just considering remove it in the new API.
Click to expand...
Click to collapse
I am not currently using the resources hook in any of my modules, so removing it would not impact me, but even so, I'm not a fan of the suggestion to get rid of it completely. I think that at the very least, it should be kept as maintain-only. It is unfortunate that it does not work with Taichi, but given that Taichi isn't a true Xposed implementation, I'm not sure that it's worth worrying about.
This looks great, I've been waiting for it since the initial issue talking about it. Prefs are always a pain to handle, and while the "new" method worked, I always preferred to use a Content Provider, which was nerfed in Android 12.
Really like the idea of setting the scope, it would be beneficial to the Xposed part of DarQ, the only suggestion I have is to make sure it includes some sort of "am I enabled?" check - currently I use self hooks (literally the module hooking itself and changing a method returning false to true) to verify it's enabled, but it doesn't seem to be foolproof as people sometimes still complain it doesn't work.
Quinny899 said:
the only suggestion I have is to make sure it includes some sort of "am I enabled?" check
Click to expand...
Click to collapse
Of course does, and the module app can get more info about the the Xposed state like it's under which framework and which version, and whether it is rootless or not without self-hooking.
You can view the detail here.
@shadowstep Thanks for the head up.
Glad to see a new api to manage configs across apps, shared prefs has been always painful to handle even with the new-xshared prefs.
I would suggest having an api to get the version name of scope's package, I'm aware of some workarounds that help get the version name, but it's not a reliable solution on the latest Android versions, this information is needed for logging/debugging purposes.
@Dr-TSNG thanks and keep up the good work.
@Dr-TSNG Thanks for new api I was wating for this api from more then 1 year coz when I build my first module (Android Faker) its was really pain in ass coz of Xsharedpreference after some research I found better solution which was remote preference but Quinny899 mention in Github issue that its not work in android 11 so after that I move to new Xsharedpreference which was introduce by lsposed team and its working great but its still create issue in some devices so I think it will be a better solution if we get it soon and I am not sure about resources hook coz I don't use it before .
The problem with xshared preferences is that if the apk is a system app it won't work for some reason. Only works on user apps
siavash79 said:
The problem with xshared preferences is that if the apk is a system app it won't work for some reason. Only works on user apps
Click to expand...
Click to collapse
Interesting. I use XSharedPreferences in a System Framework hook and haven't had any issues with it.
David B. said:
Interesting. I use XSharedPreferences in a System Framework hook and haven't had any issues with it.
Click to expand...
Click to collapse
Is your module installed as APK or as magisk module?
Try mounting it to system through magisk and preferences will stop working
siavash79 said:
Is your module installed as APK or as magisk module?
Try mounting it to system through magisk and preferences will stop working
Click to expand...
Click to collapse
It's installed as an APK. I misunderstood what you had said earlier. I thought you meant that the hook doesn't work when you try to use it on system APKs. I didn't realize that you meant that it doesn't work when the module is itself a system APK.
siavash79Yeah I agree with this and in my testing if you set target sdk 23 its doesn't matter if its as system app or user its work without any issues but its not worth coz it have some other issues
Thank you for accepting the API invokeSpecial() !
Add invokeSpecial · libxposed/[email protected]
Fix #2
github.com
Implement invoke special and new instance special · LSPosed/[email protected]
LSPosed Framework. Contribute to LSPosed/LSPosed development by creating an account on GitHub.
github.com
Looking forward to the new API release.
Happy Chinese New Year!
I just want to see @M66B happy again
Somewhat unrelated, but is there any chance of seeing original Xprivacy return or compatibility? I think it's a lot better than Lua
lawrencee said:
Somewhat unrelated, but is there any chance of seeing original Xprivacy return or compatibility? I think it's a lot better than Lua
Click to expand...
Click to collapse
No. Xprivacy will never "return".
XPrivacyLua is the best ever