Database Develop

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

[Q] Good for Enterprise crashes when Xposed is enabled

Hi folks...
I am using a T-Mo Galaxy Note 3 with 4.3 (jellybean) and the latest Xposed Framework 2.7.1 (for reference, I did also try 2.4 through 2.5.1, with the same results).
I have installed the "Good for Enterprise" application to access my organization's email system. Our policy does NOT restrict use of root, so my issue is NOT with the fact that I am rooted.
However, whenever I enable the framework, even with NO modules enabled, launching Good crashes the app right after I enter my password into it. This is 100% repeatable. If I disable Xposed and reboot, Good works perfectly. This is also 100% repeatable.
I have looked through the logcat output and don't know what to look for, as I see a good amount of recurring debug messages. Any suggestions for how to proceed? Also, is it possible to blacklist an application so Xposed does not try to hook only that app?
Any suggestions are appreciated, and please remember that my organization does NOT restrict root via Good policy, so I don't have to worry about RootCloak, etc.
Thanks folks!
- SG

Xposed Framework Causes Good Mobile Messaging to not function
Hey there, not sure if there is anything that you can do about this but I wanted your input:
For some reason when I activate the xposed installer framework (my Verizon HTC One Max is running the most recent version of the NuSenseSix rom), it causes an app I have installed called "Good for Enterprise" to stop functioning. (Good for Enterprise is used for corporate email). if I disable the framework, then the app functions normally. Is there any way you can give me some advice or a resolution regarding this? the framework version I am running is 2.6.1
Thanks,

Slappy_G said:
Hi folks...
I am using a T-Mo Galaxy Note 3 with 4.3 (jellybean) and the latest Xposed Framework 2.7.1 (for reference, I did also try 2.4 through 2.5.1, with the same results).
I have installed the "Good for Enterprise" application to access my organization's email system. Our policy does NOT restrict use of root, so my issue is NOT with the fact that I am rooted.
However, whenever I enable the framework, even with NO modules enabled, launching Good crashes the app right after I enter my password into it. This is 100% repeatable. If I disable Xposed and reboot, Good works perfectly. This is also 100% repeatable.
I have looked through the logcat output and don't know what to look for, as I see a good amount of recurring debug messages. Any suggestions for how to proceed? Also, is it possible to blacklist an application so Xposed does not try to hook only that app?
Any suggestions are appreciated, and please remember that my organization does NOT restrict root via Good policy, so I don't have to worry about RootCloak, etc.
Thanks folks!
- SG
Click to expand...
Click to collapse
I am experiencing the exact same issue with good and my device. If I keep the framework disabled, good for enterprise works perfectly. As soon as I enable the framework and reboot, good hangs every time when attempting to connect after putting in my password and then just force quits back to the home screen.
I opened a seperate thread regarding the issue not seeing this thread until after I had already posted. I am hopeful that a resolution can be found. I have a Verizon HTC One Max, rooted with NuSenseSix Rom. I have also verified that they do not block access to good when it detects a rooted device. And as stated before, it functions normally on my rooted device as long as I keep the framework disabled.

Please describe in detail what you mean with "stop functioning". Does it crash? Please provide a logcat of the error.

I have merged these two threads. As mentioned, please post a logcat. A blacklist to avoid "loading" Xposed is not possible, because Xposed is initialized at system start and "inherited" by all apps.

rovo89 said:
I have merged these two threads. As mentioned, please post a logcat. A blacklist to avoid "loading" Xposed is not possible, because Xposed is initialized at system start and "inherited" by all apps.
Click to expand...
Click to collapse
Understood. I'll post a logcat this evening of both a positive and a negative case.

I am experiencing the excact same behaviour as stated in the OP, and are working under the same conditions (rooted rom with latest xposed and NO anti-root policy). I would LOVE to help providing logcats, and i happen to be part of the IT department enforcing Good, so i can really test this (they wont blacklist me).
I will produce som logcat for you, any advice on how to best do this? Otherwise i will just throw something at best effort :good: :laugh:
Update: Back with a log, see attatched.
I started Catlog (app), pressed home and launched GFE. I then entered my password, and the app crashed. After this i clicked the shortcut on my launcher to start (resume) catlog, and paused the logging. I then exported the whole thing to the attatched textfile. The loglevel is Verbose.
If any system information is needed, other than those in the log file, please ask.
Kind Regards
TwinAdk

Thanks. I don't see any crash/exception of the application there. Is it a normal crash ("<app> has stopped working" or whatever that message says)? If so, can you get the stack trace from it?
But what I noticed is that you have at least one module with quite verbose output (all those lines with "Xposed" tag, they don't come from the framework). Could you please make sure that it crashes even without any active modules?

rovo89 said:
Thanks. I don't see any crash/exception of the application there. Is it a normal crash ("<app> has stopped working" or whatever that message says)? If so, can you get the stack trace from it?
But what I noticed is that you have at least one module with quite verbose output (all those lines with "Xposed" tag, they don't come from the framework). Could you please make sure that it crashes even without any active modules?
Click to expand...
Click to collapse
I will deactivate all modules and re-take the log. It still crashes, that's for sure. When i will screen record the crash, it's not a stopped working crash, the app just closes with it's 'switch to launcher animation'. Once reopened it loads from scratch.
---------- Post added at 11:23 PM ---------- Previous post was at 10:32 PM ----------
Back with log of crash two times in a row, and screen record of working and failing good app. Notice that good cannot he screen recorded, hence the black screen when I'm inside the app. After the working recording I enabled xposed framework and rebooted.
Video and log here:
https://www.dropbox.com/sh/zrkivu9u0k4u2od/AAA5io6UfphGumblJCduRp8da
When you got the files, tell me, I'll remove them from dropbox then.
Kind Regards
TwinAdk

Twin, thanks for uploading the log files and the sharing the videos. i've been super busy and haven't had a chance to do this. what you are showing in your videos is exactly what is happening on my device when the framework is enabled (with no modules enabled/loaded). good prompts for my password and then force quits back to the home screen. it does this over and over again until I disable the framework and restart my device. then good functions normally.
Rovo, let me know if you need me to also supply logs from my device, or if what twin provided is enough to troubleshoot this.
thanks,

No problem, i know that far too well The phone having the problem is a HTC One, m7_ul, running the AICP project rom from here: http://forum.xda-developers.com/showthread.php?t=2632667
I also have an Samsung xCover 2 i can test it on (the wifes) and the former phone, the HTC One X, running a similair AICP rom, in a slightly older version. If this has any intereset, let me know. It would
Also, it occured to me, the Good app also hangs during the initial setup of Good (you have to pair the Good app with your company, by entereing your email address and a one-time key. This is done upon starting the app for the first time).. It has a process where it, after the email and onetime key is submitted, will "log in" - "check stuff" [NOT root policies etc i believe] - "preforms the secure connection" [between phone and company] - "fetches corporate settings" (this is the step where it freezes with XPosed enabled, hence never allowing the initial setup to complete) - "saving settings" [initial setup done, the app loads, if no xposed is present].
Are you interested in a logcat of that process aswell? I am quite sure its the same thing stopping the app from working.
Kind Regards
TwinAdk
EDIT: I just realised the video of the Good app working, was unable to play anywhere else than on my phone, so i screenrecorded it playing on my phone, and posted the screenrecord of a screenrecord to dropbox

you are correct, if i uninstall good and attempt to reinstall while the framework is enabled, it hangs on "retrieving corporate settings". If i disable the framework and reinstall, installation completes with no issues and functions normally. Again this is just enabling the framework on my device, not loading or enabling any modules. I am using a verizon htc one max running rooted nusensesix rom

TwinAdk said:
Video and log here:
https://www.dropbox.com/sh/zrkivu9u0k4u2od/AAA5io6UfphGumblJCduRp8da
When you got the files, tell me, I'll remove them from dropbox then.
Click to expand...
Click to collapse
Thanks, you can remove them.
This isn't a crash - the app deliberatly goes back to the launcher:
Code:
07-16 22:53:08.172 I/ActivityManager(585): START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.good.android.gfe/com.good.android.ui.LaunchHomeActivity bnds=[540,960][540,960]} from pid 1068
07-16 22:53:08.312 I/ActivityManager(585): Start proc com.good.android.gfe for activity com.good.android.gfe/com.good.android.ui.LaunchHomeActivity: pid=4604 uid=10161 gids={50161, 3003, 1028, 1015, 1023, 1006}
07-16 22:53:08.943 W/ActivityManager(585): Unable to start service Intent { cmp=com.dell.enterpriseservices/.EnterpriseService } U=0: not found
07-16 22:53:09.633 I/WindowManager(585): Screenshot max retries 4 of Token{41ca04d8 ActivityRecord{41ab9a78 u0 com.good.android.gfe/com.good.android.ui.LaunchHomeActivity t5 f}} appWin=Window{41d18a68 u0 Starting com.good.android.gfe} drawState=4
07-16 22:53:09.643 W/WindowManager(585): Screenshot failure taking screenshot for (1080x1920) to layer 21015
07-16 22:53:09.653 I/ActivityManager(585): START u0 {cmp=com.good.android.gfe/com.good.android.ui.activities.AppLockActivity (has extras)} from pid 4604
07-16 22:53:09.663 W/ActivityManager(585): startActivity called from finishing ActivityRecord{41ab9a78 u0 com.good.android.gfe/com.good.android.ui.LaunchHomeActivity t5 f}; forcing Intent.FLAG_ACTIVITY_NEW_TASK for: Intent { cmp=com.good.android.gfe/com.good.android.ui.activities.AppLockActivity (has extras) }
...
[B][COLOR="Red"]07-16 22:53:22.687 I/ActivityManager(585): START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10000000 cmp=com.teslacoilsw.launcher/com.android.launcher2.Launcher} from pid 4604[/COLOR][/B]
...
07-16 22:53:23.208 I/ActivityManager(585): Process com.good.android.gfe (pid 4604) has died.
07-16 22:53:23.208 I/WindowState(585): WIN DEATH: Window{41f2c360 u0 com.good.android.gfe/com.good.android.ui.activities.AppLockActivity}
I have decompiled the app and it indeed has code for that. Unfortunately, they have used Proguard to obfuscate the code, so it's very hard to understand why exactly they show the launcher. Maybe they have detected Xposed or something done by it, or it caused an unexpected situation.
You could try one more thing - disable the Xposed resources APIs in the installer settings and reboot. That disables a good part of Xposed. If that doesn't help, someone would need to analyse the app in detail. I'm saying "someone" because I don't have enough free time for that.

rovo89 said:
Thanks, you can remove them.
This isn't a crash - the app deliberatly goes back to the launcher:
Code:
07-16 22:53:08.172 I/ActivityManager(585): START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.good.android.gfe/com.good.android.ui.LaunchHomeActivity bnds=[540,960][540,960]} from pid 1068
07-16 22:53:08.312 I/ActivityManager(585): Start proc com.good.android.gfe for activity com.good.android.gfe/com.good.android.ui.LaunchHomeActivity: pid=4604 uid=10161 gids={50161, 3003, 1028, 1015, 1023, 1006}
07-16 22:53:08.943 W/ActivityManager(585): Unable to start service Intent { cmp=com.dell.enterpriseservices/.EnterpriseService } U=0: not found
07-16 22:53:09.633 I/WindowManager(585): Screenshot max retries 4 of Token{41ca04d8 ActivityRecord{41ab9a78 u0 com.good.android.gfe/com.good.android.ui.LaunchHomeActivity t5 f}} appWin=Window{41d18a68 u0 Starting com.good.android.gfe} drawState=4
07-16 22:53:09.643 W/WindowManager(585): Screenshot failure taking screenshot for (1080x1920) to layer 21015
07-16 22:53:09.653 I/ActivityManager(585): START u0 {cmp=com.good.android.gfe/com.good.android.ui.activities.AppLockActivity (has extras)} from pid 4604
07-16 22:53:09.663 W/ActivityManager(585): startActivity called from finishing ActivityRecord{41ab9a78 u0 com.good.android.gfe/com.good.android.ui.LaunchHomeActivity t5 f}; forcing Intent.FLAG_ACTIVITY_NEW_TASK for: Intent { cmp=com.good.android.gfe/com.good.android.ui.activities.AppLockActivity (has extras) }
...
[B][COLOR="Red"]07-16 22:53:22.687 I/ActivityManager(585): START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10000000 cmp=com.teslacoilsw.launcher/com.android.launcher2.Launcher} from pid 4604[/COLOR][/B]
...
07-16 22:53:23.208 I/ActivityManager(585): Process com.good.android.gfe (pid 4604) has died.
07-16 22:53:23.208 I/WindowState(585): WIN DEATH: Window{41f2c360 u0 com.good.android.gfe/com.good.android.ui.activities.AppLockActivity}
I have decompiled the app and it indeed has code for that. Unfortunately, they have used Proguard to obfuscate the code, so it's very hard to understand why exactly they show the launcher. Maybe they have detected Xposed or something done by it, or it caused an unexpected situation.
You could try one more thing - disable the Xposed resources APIs in the installer settings and reboot. That disables a good part of Xposed. If that doesn't help, someone would need to analyse the app in detail. I'm saying "someone" because I don't have enough free time for that.
Click to expand...
Click to collapse
See the dropbox folder. I ticked the option and rebooted, then I had same experience and found the shown in the logcat....

Mornig,
I just noticed that i get a notification from Good, saying that "GFE does not have connection [to the corporate network]. Unlock GFE to initiate the connection". See the screenshot (_20140718_072316.JPG) posted in the dropbox folder. I received this while GFE was unable to open, and it confirms that GFE is indeed running in the background..
I tried to rename the Xposed app in the phone, to test, using xSuite (weak attempt, but you never know). Also, i stripped GFE of some permissions using the App Settings module:
- Read External storage
- Read Logs
- com.dell.enterpriseservices.SET_PROPERTY_THIRDPARTY_APPINSTALL (custom GFE permission added to the manifest i belive). Possibly a permission used for corporate inforced rules (that do not apply here yet, but i still nuked it)
I will try stripping permissions to see where it gets me.
Also, there is this module, - http://repo.xposed.info/module/com.phantasm.xposed.gfesecuritypatcher - but it does not work for me at least.
Then there is this thread - http://forum.xda-developers.com/showthread.php?t=2040163 - but the "4.3+ xposed way" mentioned in the very first post, is also no good...
I also tested the rootcloak app, where the developer says it may work with GFE, but he needs more testing. It does not.
I fear however, that all these past efforts have been nullified by some recent GFE update, because the case here is that we dont even get to start the program.
Kind Regards
TwinAdk
EDIT: Okay, that was quick.. I stripped GFE of EVERY SINGLE permission. This caused it to FC on me the first time. The dump report revealed it needed the WAKE_LOCK permission, so i granted it that and retried.. On the second launch, it returned to my launcher as we have seen before...
In fact, i find this behaviour unacceptable, as my company has NOT decided against Xposed, rooting, etc, and a company could for all we know depend on both GFE and Xposed (unlikely, yes, impossible, no). But GFE seems to be dead set against opening up when Xposed is active.
Would it be possible to intercept and block the return to launcher call to android? Just to see where it gets us? This would require a module, i know.
---------- Post added at 08:32 AM ---------- Previous post was at 07:36 AM ----------
Okay, i read up on another thread, and found this post here: http://forum.xda-developers.com/showpost.php?p=53198439&postcount=833
It states the following:
Information Notification: Good for Enterprise (GFE) Good Mobile Messaging Client (GMMC) for Android v2.5 running Android OS v4.4.2 May Encounter Application Restarts After Entering the Password on the Nexus 4 and Nexus 5 Device
Date: June 3, 2014
Problem:
Good for Enterprise (GFE) Good Mobile Messaging Client (GMMC) for Android version 2.5 running Android OS 4.4.2 may encounter application restarts after entering the password on the Nexus 4 and Nexus 5 Device. This problem has occurred after upgrading from GMMC for Android version 2.4 to GMMC for Android version 2.5 and with doing a fresh installation of GMMC for Android version 2.5.
Environment:
· Good for Enterprise (GFE) Good Mobile Messaging Client (GMMC) for Android version 2.5
· Nexus 4 and Nexus 5 devices with Android OS 4.4.2
Please Note:
A re-install of the GFE GMMC Android version 2.5 will not resolve the problem.
Workaround:
Please install the older version of Good for Enterprise (GFE) Good Mobile Messaging Client (GMMC) for Android version 2.4 on your device and disable the auto update setting for this application.
· Here is the link to get the GFE for Android 2.4 release - https://get.good.com/ea/android/
· It's very important to disable the auto update for the application, so it does not auto update to GFE version 2.5.
o Open the Google Play Store
o Hit Menu (3 dots in the upper right)
o Select Settings
o Uncheck 'Auto-update' apps
FIX:
Good Engineering is currently working on a permanent fix for this issue. We will keep you updated on the availability of the new software version.
If you have questions, please contact our technical support team at 1-408-352-7100, 1-866-448-8458 or submit an online support ticket at www.good.com/gmp.
Thank you,
Click to expand...
Click to collapse
Provided this information, i downloaded the 2.4 release of GFE, instead of the 2.5 from Google Play Store - and it just works.
After uninstalling 2.5, rebooting and installing 2.4, i can open up GFE with Xposed fully enabled. I also have the GFE Patcher module (http://repo.xposed.info/module/com.phantasm.xposed.gfesecuritypatcher) installed, just in case.. even though my company does not block root.
Summa summarum - It seems we can call off the witch hunt, and conclude that its a bug in 2.5 of GFE causing the issues.
Also, the GFE Patch module seems to work for people with root, and in the thread where i found the bug-info, people are reporting that 2.5 of GFE works, when installed on top of 2.4, via playstore. This is however not the case for me, 2.5 still returns to launcher.
@revo89, thank you for all your time and effort in this matter, and once again, thank you for the xposed framework as a whole, its is a truly amazing piece of art, and my phone is not my phone without it! :good::good:

@twin
You are absolutely correct buddy. After reading your recent update to this thread, I removed and reinstalled w/ GFE 2.4 via the link you provided. that took care of my issue. I can use GFE 2.4 with the framework & modules enabled with no issues. as soon as I upgrade again to 2.5, I start experiencing the same issue as before where it force quits back to the home screen. for now I will use 2.4 until a newer version of GFE is released and will test again with that version. but at least now I have a working solution to the issue.
thanks again for all your time and assistance in troubleshooting this problem.

Thanks so much everyone for working on this thread. I run xposed on a Verizon note2 and I have been having this same issue described here. Its been driving me crazy and I've had to live without xposed since this 'bug' arrived. I'll try 2.4 as well and then wait for GFE to fix the newer versions. Thanks again.

I had this issue.. It's rom dependant.
I had one rom on my Note2 that had this issue. But a rooted stock rom does not have this issue.
I'm running a HTC One M8 as of today. It's got rooted stock, it also does not have this issue.
Hope that helps (but yeah 2.4 works, I kept a backup in titanium)

Indeed, it seems that the rom makes a difference, because some people say it works (2.5), and some doesnt.. Must be parts of the rom that is the issue, and that part is used only in some roms
Kind Regards
TwinAdk

Awesome, this thread was a lifesaver! I couldn't figure out why and kept reinstalling and on the phone with tech support at my company who basically told me to do a hard reset (right....). The older version 2.4 works fine. Thanks TwinAdk!

[Q] XSharedPreferences NoClassDefFoundError

I'm trying to load in a static XSharedPreferences instance in a separate class via
Code:
private static XSharedPreferences prefs = new XSharedPreferences(BuildConfig.PACKAGE_NAME);
Everything compiles, but at runtime I'm given:
Code:
09-27 08:59:26.929 24976-24976/com.versobit.kmark.xhangouts E/AndroidRuntime﹕ FATAL EXCEPTION: main
Process: com.versobit.kmark.xhangouts, PID: 24976
java.lang.NoClassDefFoundError: de.robv.android.xposed.XSharedPreferences
at com.versobit.kmark.xhangouts.XApp.<clinit>(XApp.java:33)
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1208)
at android.app.Instrumentation.newApplication(Instrumentation.java:990)
at android.app.Instrumentation.newApplication(Instrumentation.java:975)
at android.app.LoadedApk.makeApplication(LoadedApk.java:509)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4446)
at de.robv.android.xposed.XposedBridge.invokeOriginalMethodNative(Native Method)
at de.robv.android.xposed.XposedBridge.handleHookedMethod(XposedBridge.java:631)
at android.app.ActivityThread.handleBindApplication(Native Method)
at android.app.ActivityThread.access$1500(ActivityThread.java:144)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1265)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5146)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:732)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:566)
at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
at dalvik.system.NativeStart.main(Native Method)
Been at this for four or five hours and I'm out of ideas. I'm correctly providing the BridgeApi file in my gradle build. I've even tried loading in the jar manually and using reflection, but that doesn't seem to work properly. The class will load but nothing is read.

Are you trying to import that in a non Xposed class? AFAIK, it'll only work for classes loaded by Xposed.

GermainZ said:
Are you trying to import that in a non Xposed class? AFAIK, it'll only work for classes loaded by Xposed.
Click to expand...
Click to collapse
Yep. That's unfortunate. I was under the false impression that Xposed injected itself into every class loader context. It does modify the system classpath but that doesn't seem to have any effect on Dalvik apps. Here's my long-winded solution.
Thanks for the help.

Kevin M said:
Yep. That's unfortunate. I was under the false impression that Xposed injected itself into every class loader context. It does modify the system classpath but that doesn't seem to have any effect on Dalvik apps. Here's my long-winded solution.
Thanks for the help.
Click to expand...
Click to collapse
For what's it's worth, pretty much all modules use MAKE_WORLD_READABLE. IIRC, XSharedPreferences also has a helper to set that if it isn't already.
Edit: also, XSharedPreferences isn't very different from SharedPreferences. From memory, the only differences are a few extra helpers and read only support.

GermainZ said:
For what's it's worth, pretty much all modules use MAKE_WORLD_READABLE. IIRC, XSharedPreferences also has a helper to set that if it isn't already.
Click to expand...
Click to collapse
I found the usage of WORLD_READABLE common while looking around for ideas, but didn't notice the helper function somehow, after pouring over the source. Now that I'm looking at it again my concern is that the XSharedPreferences instance is running with the same permissions as my module, which certainly doesn't have the permissions required to chmod files owned by other users when running in the hooked process.

Kevin M said:
I found the usage of WORLD_READABLE common while looking around for ideas, but didn't notice the helper function somehow, after pouring over the source. Now that I'm looking at it again my concern is that the XSharedPreferences instance is running with the same permissions as my module, which certainly doesn't have the permissions required to chmod files owned by other users when running in the hooked process.
Click to expand...
Click to collapse
Wouldn't you be able to get (or create) an instance of SharedPreferences and edit what you want in that case, though?
Or get a Context and use that if it's not a preference file you're interested in.

GermainZ said:
Wouldn't you be able to get (or create) an instance of SharedPreferences and edit what you want in that case, though?
Or get a Context and use that if it's not a preference file you're interested in.
Click to expand...
Click to collapse
Unless I have a Context to my own application when my hook is running I don't see that working. The only time a Context to my app would even be alive would be when the PreferenceActivity was loaded. When my hook is running it's running inside the other application's process so I can't just spawn a SharedPreference to what is now a foreign resource.

Kevin M said:
Unless I have a Context to my own application when my hook is running I don't see that working. The only time a Context to my app would even be alive would be when the PreferenceActivity was loaded. When my hook is running it's running inside the other application's process so I can't just spawn a SharedPreference to what is now a foreign resource.
Click to expand...
Click to collapse
Ah, I misunderstood what you wanted. Basically I'd do something like this:
If I'm trying to access the hooked app's files, get a Context from the hooked app.
If I'm trying to access my own app's files, get a Context from the hooked app then use IPC (e.g. a BroadcastReceiver for my app, and use Context.sendBroadcast() from the hooked app).
I think you want the second but that's what you're doing currently if I'm not mistaken.

GermainZ said:
Ah, I misunderstood what you wanted. Basically I'd do something like this:
If I'm trying to access the hooked app's files, get a Context from the hooked app.
If I'm trying to access my own app's files, get a Context from the hooked app then use IPC (e.g. a BroadcastReceiver for my app, and use Context.sendBroadcast() from the hooked app).
I think you want the second but that's what you're doing currently if I'm not mistaken.
Click to expand...
Click to collapse
Yep, just used a ContentProvider/Resolver instead. :good:

Put Settings from hook

Hook is in PhoneWindowManager class, I need to put a value to Settings.System. ContentResolver from the available mContext variable is used.
I get the following:
Code:
InvocationTargetError: java.lang.SecurityException: Package android does not belong to 10036
10036 is UID of my module.

- Which context did you use to get content resolver?
- Depends on where your hook is.
Although your hook is in phone window manager, it still depends from where method you are hooking was called from. If it was called from different package that has different permissions (such as your module app), you will have to clear an identity of calling package while using system settings.
Something like:
Code:
long ident = Binder.clearCallingIdentity();
try {
// store to system settings or whatever
} finally {
Binder.restoreCallingIdentity(ident);
}
- Another option is to add necessary permission to your module's manifest

My module already has WRITE_SETTINGS permission. I use mContext variable that is available in PhoneWindowManager, never had a problem with it. Calling from a separate thread that is created in screenTurnedOff() method.
PhoneWindowManager has a lot of similar code involving Settings.System:
Code:
android.provider.Settings.System.putIntForUser(mContext.getContentResolver(), "screen_brightness_mode", 0, -3);
I tried ...ForUser methods with -2, -3 and 1000 UIDs - still the same error. Regular methods should use current process UID, so it's 1000 anyway.
No idea how it still knows that Xposed module is involved, code is supposed to be executed as if it's a part of a hooked app.
But I guess it knows) so clearing calling identity works perfectly, thanks.

I assume thread in screenTurnedOff you mentioned is your own you created? If yes, then for some reason thread in which runs phone window manager is thinking it's some kind of a foreign thread although created within phone window manager. Question is where screenTurnedOff was called from. If it's an IPC call then it's clear it has different identity. If it's not that case then it's definitely strange.

C3C076 said:
Question is where screenTurnedOff was called from. If it's an IPC call then it's clear it has different identity. If it's not that case then it's definitely strange.
Click to expand...
Click to collapse
screenTurnedOff is a stock method, it's called whenever it's called Definitely not from my module. I bet there is an explanation, something complicated)

[MODULE][MFW] - Android Messages For Web (Enabler)

Inspired by the recent post on the headlines describing how to enable Android Messages For Web by fiddling with some settings, I took and consolidated what I learned there, plus some other testing, into a handy-dandy Magisk Module that *should* work to enable MFW.
*HOWEVER*, I'm doing something wrong, and need a bit of help.
Repo is here:
https://github.com/d8ahazard/Magisk_Messages_For_Web
Basically, I'm just copying the sqlite binary to system, and then firing the commands to update some bools in a preference DB, then force-closing the messaging app so they take effect.
But for some reason, the script doesn't appear to be running. I'm trying to fire it in the services section. I can see that the bit where I'm setting permissions on sqlite3 is working, but I don't know why the sql commands aren't being executed.
Is there some way to output directly to the Magisk log from a module/script? I think if I can see what's happening there, I'd be set.
If I execute the service script manually in shell, it works:
Code:
marlin:/magisk/AMW # ./service.sh
Enabling Android Messages for Web (Hopefully)
Executing command '"UPDATE Flags SET boolVal=1 WHERE packageName LIKE '%messaging%' AND name LIKE '%PhenotypeOverrideRollout%'"'
Command status is 0
Executing command 'UPDATE Flags SET boolVal=1 WHERE packageName LIKE '%messaging%' AND name LIKE '%bugle_phenotype__enable_multi_device%';'
Command status is 0
Executing command 'UPDATE Flags SET boolVal=1 WHERE packageName LIKE '%com.google.android.apps.messaging%' AND name LIKE '%MultiQueueRollout__launched__%';'
Command status is 0
Executing command 'UPDATE Flags SET boolVal=1 WHERE packageName LIKE '%com.google.android.apps.messaging%' AND name LIKE '%MultiDeviceRollout__launched__%';'
Command status is 0
Records updated successfully!
Restarting messaging app
I know I'm close...I just don't know what's missing!

Interested by the purpose.
It would be great if you had material redesign :
https://www.xda-developers.com/android-messages-enable-material-redesign/
... When it will work !

julienbdx said:
Interested by the purpose.
It would be great if you had material redesign :
https://www.xda-developers.com/android-messages-enable-material-redesign/
... When it will work !
Click to expand...
Click to collapse
Yeah, that is literally just adding one more line to my script, and would more than likely make the material redesign permanent.
At least, modifying the settings needed for MFW in db versus the phenotype.xml preferent makes MFW permanent. I'd assume the issue described in the theme thread is the exact same thing.
All I need is for someone to explain to me why the damned services.sh script isn't executing. I've even tried putting the commands in post-fs script instead...same thing. I add a line at the very end to 'touch /sdcard/hasMFW' so I know the script ran, but no 'hasMFW' file every shows up in /sdcard.
Someone...anybody...help?
@topjohnwu

julienbdx said:
Interested by the purpose.
It would be great if you had material redesign :
https://www.xda-developers.com/android-messages-enable-material-redesign/
... When it will work !
Click to expand...
Click to collapse
There, I've pushed to git a version that has the commands that *should* enable material design as well.
Also, tried moving to post-fs.sh, still nothing works...
https://github.com/d8ahazard/Magisk_Messages_For_Web/commit/10319c338943d8b77b8c8523f31cc276bc4e5d23

Just FYI,
Modifying the flags table in PhenoType.db under GMS isn't permanent either (certainly better than a Shared_Prefs edit). It gets reset still. We're still trying to understand what causes it to reset.

MishaalRahman said:
Just FYI,
Modifying the flags table in PhenoType.db under GMS isn't permanent either (certainly better than a Shared_Prefs edit). It gets reset still. We're still trying to understand what causes it to reset.
Click to expand...
Click to collapse
That's good to know.
Ideally, if this would fire properly as a service, functionality would then be restored on reboot.
However, from what I'm seeing in my tests on my Pixel XL, with the values set the way I've done - I've not seen any breakage in functionality - even over numerous reboots.

digitalhigh said:
That's good to know.
Ideally, if this would fire properly as a service, functionality would then be restored on reboot.
However, from what I'm seeing in my tests on my Pixel XL, with the values set the way I've done - I've not seen any breakage in functionality - even over numerous reboots.
Click to expand...
Click to collapse
Yes, we've tested it too. It'll survive multiple reboots and FCs but eventually it reverts. We've narrowed it down to a service in GMS that checks every 24 hours.

MishaalRahman said:
Yes, we've tested it too. It'll survive multiple reboots and FCs but eventually it reverts. We've narrowed it down to a service in GMS that checks every 24 hours.
Click to expand...
Click to collapse
Interesting. What's the service name called? I've been poking around in the APK itself...
What I'm noticing is that my wife and a friend of mine both have Pixel 2 devices, and they "just have" the feature...which isn't all that surprising.
So, I'm wondering if the service is checking device props and enabling the feature that way. If so, then Magisk would again be an ideal candidate for fixing that issue.
LMK the service name, I'm no stranger to reversing smali.