Database Develop

[Q] How to change carrier text on demand

Hello,
I'm trying to develop an Xposed module that will allow me to change the carrier text of the device on demand (in reality, this will happen when the music track is changed).
I'm already using a BroadcastReceiver to listen to track-changed events from various media players, but I want to change the carrier text of the device when I receive such an intent.
However, I wasn't able to find how to do it using Xposed, as it only allows me to hook methods before/after they execute (feel free to correct me if I'm wrong of course), which isn't exactly what I need.
I went through the source code of XBlastTools for changing the carrier text, but wasn't able to conclude much for my needs.
Please advise in setting up a method that will basically get a String and replace the carrier text with that given String (at any given time). Something like this:
Code:
public void setName(String name) {
// TODO implement
}

Normally, you'd put your BroadcastReceiver somewhere you can access the carrier TextView from. You'd then be able to edit it when you want normally. In this case it looks like there's an easier way, though.
Here's how I'd do it: register a BroadcastReceiver in CarrierText's constructor. In that receiver, get and save the text you want as a class variable. Then hook getCarrierTextForSimState and make it return that variable.
http://grepcode.com/file_/repositor...licy/impl/keyguard/CarrierText.java/?v=source

GermainZ said:
Normally, you'd put your BroadcastReceiver somewhere you can access the carrier TextView from. You'd then be able to edit it when you want normally. In this case it looks like there's an easier way, though.
Here's how I'd do it: register a BroadcastReceiver in CarrierText's constructor. In that receiver, get and save the text you want as a class variable. Then hook getCarrierTextForSimState and make it return that variable.
http://grepcode.com/file_/repositor...licy/impl/keyguard/CarrierText.java/?v=source
Click to expand...
Click to collapse
That's a good way of doing things if it weren't for the "on demand" requirement.
Basically, what I want to do is set the carrier text to a different one whenever the onReceive() of the BroadcastReceiver is called, so I can't just hook into getCarrierTextForSimState() and change that, because it probably won't be called whenever I need.

benthe said:
That's a good way of doing things if it weren't for the "on demand" requirement.
Basically, what I want to do is set the carrier text to a different one whenever the onReceive() of the BroadcastReceiver is called, so I can't just hook into getCarrierTextForSimState() and change that, because it probably won't be called whenever I need.
Click to expand...
Click to collapse
Then call the setText method from your receiver as well.

GermainZ said:
Then call the setText method from your receiver as well.
Click to expand...
Click to collapse
By the way, I think the class you linked to only affects the carrier name that appears on the lockscreen.
I'm not that interested in this carrier text to be honest, and basically want to set the carrier text whereever it may be the class you linked to is pulling it from.
The main idea behind my module is that I have a BT headset in my car that can only display the carrier name & bluetooth name of my phone, but I want it to display the currently playing track. So I want to change the bluetooth name of the phone to the artist of the currently playing song (almost works at this point, just have some crashes I need to deal with), and set the carrier name to the name of the song that's currently playing.
However, I didn't manage to do that later. I tried various methods, but no luck so far.
EDIT: I managed to get everything working for the most part (I didn't test it with the actual BT headset, but both the BT and carrier names change when changing tracks).
However, I'm getting 2 error messages constantly as soon as I start playback:
1. Unfortunately, the process android.process.acore has stopped.
2. Unfortunately, the process android.process.media has stopped.
Any ideas on how to fix those two? What's causing them seems to be the changing of the bluetooth name (although it does work, just shows me those two crash errors time after time). Here's the code for my bluetooth manager.
Disabling the "setName" call of the BluetoothAdapter fixes the crashes (but obviously doesn't change the BT name of the device, which defeats the purpose).
Also, replacing the said call with:
Code:
XposedHelpers.callMethod(mLocalAdapter, "setName", name);
fixes this, but I prefer to do things without using reflection and hooking if I can (which is possible in this case), so it seems like it's just a permission issue.
It might be because of a permission problem:
I put together a quick Android app to simulate changing the BT name in the same way, and it crashed without adding:
Code:
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
to the manifest file.
However, if I recall correctly, Xposed modules run in root mode, so they shouldn't need permissions to do whatever they please. Also, I tried adding the above permissions to my module, but it still crashes.
Any help on the matter would be most appreciated.

I just checked which class XBlastTools hooked and assumed that's it. If not, look for the right one or see the first part of post #2.
About the crashes: check your logcat.
Xposed modules do not run as root, they'll have the same permissions as the process they're in (the app you're hooking). You can hook anything, though (including Android system methods).

GermainZ said:
I just checked which class XBlastTools hooked and assumed that's it. If not, look for the right one or see the first part of post #2.
About the crashes: check your logcat.
Xposed modules do not run as root, they'll have the same permissions as the process they're in (the app you're hooking). You can hook anything, though (including Android system methods).
Click to expand...
Click to collapse
Thanks for the help.
I got the carrier name part working perfectly now (or so it seems at least, I'll have to check later in the actual car BT headset).
The only part that remains to make the module fully functional is the Bluetooth one. I checked my logcat, and like I said in my previous post - I think it's a permission issue, which is rather weird - as I set both permissions needed for Bluetooth for the module. Keep in mind that the part that's running the bluetooth code in the app isn't hooking anything, it runs on the module itself as far as I can tell. I'm calling it on the onReceive callback from the BroadcastReceiver (I don't think the app that send the broadcast has bluetooth permissions, but that shouldn't matter, should it?).

benthe said:
Thanks for the help.
I got the carrier name part working perfectly now (or so it seems at least, I'll have to check later in the actual car BT headset).
The only part that remains to make the module fully functional is the Bluetooth one. I checked my logcat, and like I said in my previous post - I think it's a permission issue, which is rather weird - as I set both permissions needed for Bluetooth for the module. Keep in mind that the part that's running the bluetooth code in the app isn't hooking anything, it runs on the module itself as far as I can tell. I'm calling it on the onReceive callback from the BroadcastReceiver (I don't think the app that send the broadcast has bluetooth permissions, but that shouldn't matter, should it?).
Click to expand...
Click to collapse
Remember that all hooked code does *not* run as your app so your app's permissions don't matter here. Hooked code runs as if it was in the hooked process.
Can't say much else without the actual error.

GermainZ said:
Remember that all hooked code does *not* run as your app so your app's permissions don't matter here. Hooked code runs as if it was in the hooked process.
Can't say much else without the actual error.
Click to expand...
Click to collapse
But this code does run on the module.
In my main class (that implements IXposedHookLoadPackage), I'm initializing a class (that derives from Object, and doesn't implement any interfaces), in which I register the BroadcastReceiver (on the context of the application, via AndroidAppHelper.currentApplication().getApplicationContext()), when the onReceive() method is called in the BroadcastReceiver I call the setName() method of the BluetoothAdapter.
If it doesn't run on the module application, on what application does it run on?
And here's the error:
E/AndroidRuntime( 5063): FATAL EXCEPTION: main
E/AndroidRuntime( 5063): Process: com.maxmpz.audioplayer, PID: 5063
E/AndroidRuntime( 5063): java.lang.RuntimeException: Error receiving broadcast Intent { act=com.maxmpz.audioplayer.TRACK_CHANGED flg=0x10 (has extras) } in com.bengr.MusicMetadataForLegacyDevices.Musi
[email protected]
E/AndroidRuntime( 5063): at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:785)
E/AndroidRuntime( 5063): at android.os.Handler.handleCallback(Handler.java:733)
E/AndroidRuntime( 5063): at android.os.Handler.dispatchMessage(Handler.java:95)
E/AndroidRuntime( 5063): at android.os.Looper.loop(Looper.java:136)
E/AndroidRuntime( 5063): at android.app.ActivityThread.main(ActivityThread.java:5144)
E/AndroidRuntime( 5063): at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime( 5063): at java.lang.reflect.Method.invoke(Method.java:515)
E/AndroidRuntime( 5063): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:795)
E/AndroidRuntime( 5063): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:611)
E/AndroidRuntime( 5063): at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
E/AndroidRuntime( 5063): at dalvik.system.NativeStart.main(Native Method)
E/AndroidRuntime( 5063): Caused by: java.lang.SecurityException: Need BLUETOOTH ADMIN permission: Neither user 10128 nor current process has android.permission.BLUETOOTH_ADMIN.
E/AndroidRuntime( 5063): at android.os.Parcel.readException(Parcel.java:1465)
E/AndroidRuntime( 5063): at android.os.Parcel.readException(Parcel.java:1419)
E/AndroidRuntime( 5063): at android.bluetooth.IBluetooth$Stub$Proxy.setName(IBluetooth.java:783)
E/AndroidRuntime( 5063): at android.bluetooth.BluetoothAdapter.setName(BluetoothAdapter.java:660)
E/AndroidRuntime( 5063): at com.bengr.MusicMetadataForLegacyDevices.BluetoothManager.setName(BluetoothManager.java:50)
E/AndroidRuntime( 5063): at com.bengr.MusicMetadataForLegacyDevices.MusicListener.updateRemoteFieldsFromLocalFields(MusicListener.java:150)
E/AndroidRuntime( 5063): at com.bengr.MusicMetadataForLegacyDevices.MusicListener.setTrackMetadata(MusicListener.java:144)
E/AndroidRuntime( 5063): at com.bengr.MusicMetadataForLegacyDevices.MusicListener.access$4(MusicListener.java:138)
E/AndroidRuntime( 5063): at com.bengr.MusicMetadataForLegacyDevices.MusicListener$1.onReceive(MusicListener.java:105)
E/AndroidRuntime( 5063): at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:775)
E/AndroidRuntime( 5063): ... 10 more
W/ActivityManager( 935): Force finishing activity com.maxmpz.audioplayer/.PlayerUIActivity
W/ActivityManager( 935): Force finishing activity com.maxmpz.audioplayer/.PlayListActivity
D/LogFetchServiceManager( 6618): Received entry added
W/ActivityManager( 935): Activity pause timeout for ActivityRecord{42d72640 u0 com.maxmpz.audioplayer/.PlayerUIActivity t4 f}
I/Timeline( 1490): Timeline: Activity_idle id: [email protected] time:183794
I/Timeline( 935): Timeline: Activity_windows_visible id: ActivityRecord{42ca81c8 u0 com.teslacoilsw.launcher/com.android.launcher2.Launcher t1} time:184001
W/System.err( 5009): LOG: Warning Unknown dock level ignored.
Click to expand...
Click to collapse
Also, here's the project (together with the PowerAMP API project, as it depends on it, and the Android tester application I made to simulate changing the bluetooth name on a "regular" project): link, if that's of any help.

I can't check the project right now, but just to make sure I understand correctly, you're doing something like this:
1- You're hooking the class in which the carrier text is set and registering a BroadcastReceiver there.
2- From your app, you're sending a broadcast whenever you want (possibly with the text you want in the extras).
3- In the BroadcastReceiver's onReceive method, you're setting the carrier text to the value you just received.
If that's what you're doing, it seems fine to me. For the permissions issue, I suppose adding the required permission to your manifest will fix that.

GermainZ said:
I can't check the project right now, but just to make sure I understand correctly, you're doing something like this:
1- You're hooking the class in which the carrier text is set and registering a BroadcastReceiver there.
2- From your app, you're sending a broadcast whenever you want (possibly with the text you want in the extras).
3- In the BroadcastReceiver's onReceive method, you're setting the carrier text to the value you just received.
If that's what you're doing, it seems fine to me. For the permissions issue, I suppose adding the required permission to your manifest will fix that.
Click to expand...
Click to collapse
Not really. The carrier text has nothing to do with the issue anymore. Even if I removed all the code that has to do with the carrier text, and left the bluetooth part alone - the issue would persist.
What I'm doing is this:
1- Have a regular class (meaning it derives from Object directly, and doesn't implement any interfaces).
2- In the said class I set up a BroadcastReceiver (using the application context, which I got via AndroidAppHelper.currentApplication().getApplicationContext(), which is static and can be called from anywhere).
3- When the BroadcastReceiver's onReceive() is called (again, in the previously mentioned class), I call BluetoothAdapter.getDefaultAdapter().setText with the text I want to set as the phone's BT name.
4- Error messages pop-up, and the error I attached in my previous reply shows up on the logcat. (this step occurs when the onReceive is called, which calls the setText).
When I comment out the setText() call, no errors occur (but the BT name doesn't change, obviously).
It's important to note that I did add the needed permissions to my manifest:
AndroidManifest.xml:
Code:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.bengr.musicmetadateforlegacydevices"
android:versionCode="1"
android:versionName="1.0" >
<uses-sdk
android:minSdkVersion="16"
android:targetSdkVersion="19" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<application
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
<meta-data android:name="xposedmodule" android:value="true"/>
<meta-data android:name="xposedminversion" android:value="50"/>
<meta-data android:name="xposeddescription" android:value="Changes the device's carrier and bluetooth names to display the currently playing track."/>
</application>
</manifest>

So you're not using Xposed for anything anymore? Sorry but I'm a bit confused now.

GermainZ said:
So you're not using Xposed for anything anymore? Sorry but I'm a bit confused now.
Click to expand...
Click to collapse
For what I'm doing right now? Not really.
My module is composed of two parts - one for changing the BT name (which doesn't require private calls, and can be done via Android's public API), and one for changing the carrier name (which does require Xposed, as I'm doing some private calls etc).
The carrier name part of the module works perfectly right now.
However, the Bluetooth one doesn't; and crashes as mentioned before, and throws a permission error. However, on a side-project that's just a regular Android app, that also changes the BT name this works (keep in mind that in both the side-project and the Xposed module project I added both Android bluetooth permissions).

[Q] Hook existing DialogInterface.OnDismiss

I have a dialog that I am trying to get when its closed. I am able to get the object of the dialog itself and add my own setOnDismissListener but that overwrites the default one causing problems.
What I'm doing now is re-copying the code from the original DialogInterface.OnDismissListener into my own OnDismissListener.
However, because I'm lazy, how, if possible, could I hook the existing OnDismissListener without hooking the DialogInterface class?

elesbb said:
I have a dialog that I am trying to get when its closed. I am able to get the object of the dialog itself and add my own setOnDismissListener but that overwrites the default one causing problems.
What I'm doing now is re-copying the code from the original DialogInterface.OnDismissListener into my own OnDismissListener.
However, because I'm lazy, how, if possible, could I hook the existing OnDismissListener without hooking the DialogInterface class?
Click to expand...
Click to collapse
Can't you hook the existing OnDismissListener? Or do you want to avoid that because it's in an anonymous class?
I think the closest to what you want to do is hook DialogInterface when that dialog is shown, and unhook it when it's hidden. You'll still need to check the package in your hook, but only when necessary.

GermainZ said:
Can't you hook the existing OnDismissListener? Or do you want to avoid that because it's in an anonymous class?
I think the closest to what you want to do is hook DialogInterface when that dialog is shown, and unhook it when it's hidden. You'll still need to check the package in your hook, but only when necessary.
Click to expand...
Click to collapse
Well, DIalogInterface.OnDismissListener is an interface which I believe xposed cannot hook.
I really think I am looking for something that doesn't exist because I am being lazy
What I think I can do though is hook the "Dialog" class then hook the "setOnDismissListener" and steal the parameter that was sent to it and store it as an object in my xposed class. Then register my own onDismissListener, and execute what I need, then call the original saved method.... I think. Lol.

elesbb said:
Well, DIalogInterface.OnDismissListener is an interface which I believe xposed cannot hook.
I really think I am looking for something that doesn't exist because I am being lazy
What I think I can do though is hook the "Dialog" class then hook the "setOnDismissListener" and steal the parameter that was sent to it and store it as an object in my xposed class. Then register my own onDismissListener, and execute what I need, then call the original saved method.... I think. Lol.
Click to expand...
Click to collapse
Well it'll be an anonymous class so you could try hooking that (e.g. ClassName$1.onDismissListener or ClassName$2.onDismissListener).

GermainZ said:
Well it'll be an anonymous class so you could try hooking that (e.g. ClassName$1.onDismissListener or ClassName$2.onDismissListener).
Click to expand...
Click to collapse
Ohhh I see what you mean. Yeah I could hook that, I thought you meant the general DialogInterface.OnDismissListener. Doh. I'm dumb

GermainZ said:
Well it'll be an anonymous class so you could try hooking that (e.g. ClassName$1.onDismissListener or ClassName$2.onDismissListener).
Click to expand...
Click to collapse
I remember now why this wouldn't work. The anonymous class is named differently in each device depending on OS version. (IE Sense, TouchWiz, AOSP)
So I think what I have now is to hooke each anonymous class then try to hook the "onDismiss" method and have a catch to catch any errors. Then if it catches an exception, go to the next anonymous class and try again then repeat until it hooks.

[Q][Development] XSharedPreferences issue, no entries

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

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)

[PROBLEM] Server classes and resource hooks

com.android.server.*
I know that these classes have to be hooked in handleLoadPackage for lpparam.packageName == "android", but sometimes there are several processes ("system:ui" for example) that contain this package and hooks fail even from handleLoadPackage.
Now I'm using this code, is it correct?
Code:
if (lpparam.packageName.equals("android") && lpparam.processName.equals("android")) { ... }
Resource hooks
They are just not working. Well, most of them. Using fwd or DrawableLoader doesn't matter. No errors shown in log. It's not just a problem with some packages. Status bar icons, action bar icons, etc, etc - I can't replace 90% of them, exact same hooks were working on Kit Kat.
For example, png drawable is used only in manifest and in actionbar ( actionbar.setIcon(iconResId) ). With a hook this icon is replaced in launcher, but not in actionbar.
Code:
Starting Xposed binary version 60, compiled for SDK 21
Phone: HTC One (HTC), Android version 5.0.2 (SDK 21)
ROM: LRX22G release-keys
Build fingerprint: htc/htc_europe/m7:5.0.2/LRX22G/482424.2:user/release-keys
Platform: armeabi-v7a, 32-bit binary, system server: yes
SELinux enabled: yes, enforcing: no

Mikanoshi said:
Resource hooks
They are just not working. Well, most of them. Using fwd or DrawableLoader doesn't matter. No errors shown in log. It's not just a problem with some packages. Status bar icons, action bar icons, etc, etc - I can't replace 90% of them, exact same hooks were working on Kit Kat.
For example, png drawable is used only in manifest and in actionbar ( actionbar.setIcon(iconResId) ). With a hook this icon is replaced in launcher, but not in actionbar.
Click to expand...
Click to collapse
Noticed that as well. Some resources can be replaced, others it's like they're just silently ignored. I'm guessing maybe the ART optimizations are the culprit?
There's a thread about it here. I'm sure @rovo89 will chime in when he's had time to take a look. As a workaround, you could always find the method that's setting the original drawable and replace it there; that seems to work for me in most cases.

Mikanoshi said:
com.android.server.*
I know that these classes have to be hooked in handleLoadPackage for lpparam.packageName == "android", but sometimes there are several processes ("system:ui" for example) that contain this package and hooks fail even from handleLoadPackage.
Now I'm using this code, is it correct?
Code:
if (lpparam.packageName.equals("android") && lpparam.processName.equals("android")) { ... }
Click to expand...
Click to collapse
So you're saying that there are situations with lpparam.packageName == "android" and lpparam.processName <> "android"? That would explain a couple of other issues. If you could find out a good way to reproduce this, it could be quite helpful.
Depending on the situation, I will have to see how to handle it. Checking for package name "android" is a pretty common pattern to ensure you're in the system server (which I even recommend myself!), so ideally it should stay correct even without the additional checks you suggested.

rovo89 said:
So you're saying that there are situations with lpparam.packageName == "android" and lpparam.processName <> "android"? That would explain a couple of other issues. If you could find out a good way to reproduce this, it could be quite helpful.
Depending on the situation, I will have to see how to handle it. Checking for package name "android" is a pretty common pattern to ensure you're in the system server (which I even recommend myself!), so ideally it should stay correct even without the additional checks you suggested.
Click to expand...
Click to collapse
I've seen only "system:ui" process name, it tries to search for classes in XposedBridge.jar only and of course fails.
Occurrences are very inconsistent, I install modules from Eclipse and then soft reboot like 50 times a day, and this bug happens 2 or 3 times. Not a big problem though, it just clutters Xposed log
I also have a lot of problems with installing apk via adb, it either throws an excpetion and doesn't install
Code:
ActivityManager: java.lang.UnsatisfiedLinkError: No implementation found for java.lang.String android.os.SystemProperties.native_get(java.lang.String) (tried Java_android_os_SystemProperties_native_1get and Java_android_os_SystemProperties_native_1get__Ljava_lang_String_2)
ActivityManager: at android.os.SystemProperties.native_get(Native Method)
ActivityManager: at android.os.SystemProperties.get(SystemProperties.java:52)
ActivityManager: at com.htc.customization.HtcCustomizationManager.<init>(HtcCustomizationManager.java:65)
ActivityManager: at com.htc.customization.HtcCustomizationManager.<clinit>(HtcCustomizationManager.java:60)
ActivityManager: at android.os.Environment$UserEnvironment.getCustomizationReader(Environment.java:523)
ActivityManager: at android.os.Environment$UserEnvironment.isDynamicSwitchSupported(Environment.java:534)
ActivityManager: at android.os.Environment$UserEnvironment.<init>(Environment.java:222)
ActivityManager: at android.os.Environment.initForCurrentUser(Environment.java:142)
ActivityManager: at android.os.Environment.<clinit>(Environment.java:136)
ActivityManager: at android.os.Environment.getLegacyExternalStorageDirectory(Environment.java:726)
ActivityManager: at android.os.Debug.<clinit>(Debug.java:96)
ActivityManager: at android.ddm.DdmHandleHello.handleHELO(DdmHandleHello.java:164)
ActivityManager: at android.ddm.DdmHandleHello.handleChunk(DdmHandleHello.java:91)
ActivityManager: at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)
ActivityManager: java.lang.UnsatisfiedLinkError: android.os.Debug
ActivityManager: at android.ddm.DdmHandleHello.handleFEAT(DdmHandleHello.java:176)
ActivityManager: at android.ddm.DdmHandleHello.handleChunk(DdmHandleHello.java:93)
ActivityManager: at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)
ActivityManager: java.lang.UnsatisfiedLinkError: android.os.Debug
ActivityManager: at android.ddm.DdmHandleProfiling.handleMPRQ(DdmHandleProfiling.java:215)
ActivityManager: at android.ddm.DdmHandleProfiling.handleChunk(DdmHandleProfiling.java:106)
ActivityManager: at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)
or installs but fails to launch until (soft) reboot:
Code:
I/ActivityManager(15637): Process name.mikanoshi.icecontrol (pid 27200) has died
I/ActivityManager(15637): Start proc name.mikanoshi.icecontrol for activity name.mikanoshi.icecontrol/.Settings: pid=27233 uid=10343 gids={50343, 9997} abi=armeabi-v7a
I/art(27233): Late-enabling -Xcheck:jni
W/art(27233): Failed to find OatDexFile for DexFile /data/app/name.mikanoshi.icecontrol-2/base.apk ( canonical path /data/app/name.mikanoshi.icecontrol-2/base.apk) with checksum 0x7991961b in OatFile /data/dalvik-cache/arm/[email protected]@[email protected]@classes.dex
D/Process(15637): killProcessQuiet, pid=27233
No idea if Lollipop or Xposed problem

rovo89 said:
So you're saying that there are situations with lpparam.packageName == "android" and lpparam.processName <> "android"? That would explain a couple of other issues. If you could find out a good way to reproduce this, it could be quite helpful.
Depending on the situation, I will have to see how to handle it. Checking for package name "android" is a pretty common pattern to ensure you're in the system server (which I even recommend myself!), so ideally it should stay correct even without the additional checks you suggested.
Click to expand...
Click to collapse
Yes, I can confirm this seems to be the case. Haven't got a chance to debug which process comes with packageName == "android" apart from "android" process itself, but when that happens, classLoader cannot find classes that are typically available within "android" package, which is logical. The other process that has packageName "android" is something else with no access to those classes.

Oh, and rarely soft reboot after module activation ends like this
Code:
E/Xposed(10834): Error -32 while adding app service user.xposed.app
E/Xposed(10822): Zygote service is not running, Xposed cannot work without it

I would like to concentrate on the bigger issues first. Yours can probably be solved by another reboot.
So after some research, grepping the AOSP code and so on, it seems that the "system:ui" process is only used by the PackageManagerService. Maybe more will follow in the future. For some reason, the process seems to be called "android:ui" though once it has been started. It's running with UID 1000, but in the system_app SELinux context.
I would like to understand some more things about this before making a decision. It seems that there can now indeed be processes with package name "android" that aren't the system_server. Without breaking existing modules, I think I could only block handleLoadPackage() for these. Maybe it would also make sense to add a new handleLoadSystemServer() method. That would avoid the need for checks, especially if only system services are hooked. For backward-compatiblity, handleLoadPackage() could still be called for package "android", but modules would produce error messaages if they don't check the process name. Or there could be a compatiblity break at this point, requiring all modules that hook system services to adopt the new API.

I don't mind checks Almost every module that hooks system classes requires an update for 5.0 anyway.
Huge issues for me now are broken resource hooks and problems with installing apks (sometimes it takes 3-5 tries to install and then soft reboot just to test interface changes).

Most likely, this is the reason why the ChooserActivity runs in the "android:ui" process now:
https://github.com/android/platform...40#diff-30afe08a44bf548c7cc9116a473f8bdfL2798
It used to declare multiprocess=true, which meant that the activity was started in the caller's process. Now it's started in a separate process, where ":ui" is relative to the package name, not the applications's default process name (that would be "system").
There are also other activities with similar attributes defined, even in KitKat. If someone has a bit of time at their hands, they could try to check whether handleLoadPackage() is also called for package == "android" and process != "android" on KitKat ROMs for those other activities. It wouldn't be as noticable as it is on Lollipop because the system services that most modules hook there were available with the boot class path.
Anyway, now we know that there are legitimate usages of the "android" package for other things than the system_server. These usages are very limited though. The activities use the boot classloader, so hooking methods from initZygote() would (still) work for them. What if I set the packageName for these apps to "system" instead? So modules checking for "android" as package name could be sure it's the system_server then. Modules which need to do something for the android:ui process could simply check for "system" as package name. Any complaints?

Good solution... Ship it
But I believe majority of actively developed modules are already fixed for this specific case.

rovo89 said:
Most likely, this is the reason why the ChooserActivity runs in the "android:ui" process now:
https://github.com/android/platform...40#diff-30afe08a44bf548c7cc9116a473f8bdfL2798
It used to declare multiprocess=true, which meant that the activity was started in the caller's process. Now it's started in a separate process, where ":ui" is relative to the package name, not the applications's default process name (that would be "system").
There are also other activities with similar attributes defined, even in KitKat. If someone has a bit of time at their hands, they could try to check whether handleLoadPackage() is also called for package == "android" and process != "android" on KitKat ROMs for those other activities. It wouldn't be as noticable as it is on Lollipop because the system services that most modules hook there were available with the boot class path.
Anyway, now we know that there are legitimate usages of the "android" package for other things than the system_server. These usages are very limited though. The activities use the boot classloader, so hooking methods from initZygote() would (still) work for them. What if I set the packageName for these apps to "system" instead? So modules checking for "android" as package name could be sure it's the system_server then. Modules which need to do something for the android:ui process could simply check for "system" as package name. Any complaints?
Click to expand...
Click to collapse
Great idea, no complaints here.

Whike fixing this, maybe you can try to look why appInfo is null for "android" package.

pyler said:
Whike fixing this, maybe you can try to look why appInfo is null for "android" package.
Click to expand...
Click to collapse
That's very simple to answer: https://github.com/rovo89/XposedBri...de/robv/android/xposed/XposedBridge.java#L245
There's simply no ApplicationInfo object (yet), it's constructed later when the PackageManagerService is running. I could construct a fake object, but there are hardly any fields that could be filled with proper values.

atleast flags field could be filled, or not? just do copy of real object for android, which any normal app can get.
since we talk about this, is this doable or Xposed starts too soon for these values?

rovo89 said:
What if I set the packageName for these apps to "system" instead?
Click to expand...
Click to collapse
Old modules which use "android" are incompatible...
To be compatible i have then to check "system" and "android" - this is not better than check for package& process name

system is for *:ui processes and we mostly care about android only.

pyler said:
system is for *:ui processes and we mostly care about android only.
Click to expand...
Click to collapse
Who is "we" and whats the source of "mostly"
I have to say that i'm using "android" for <21 and so it seems i have to use different package names depending on Xposed version

pyler said:
atleast flags field could be filled, or not? just do copy of real object for android, which any normal app can get.
since we talk about this, is this doable or Xposed starts too soon for these values?
Click to expand...
Click to collapse
"real object for android" => you mean the one that I said doesn't exist at the time the system_server is starting up, as the PackageManagerService is not running yet?
No idea about your other suggestion, I'm currently looking mainly into crashes etc., API extensions have to wait...
defim said:
I have to say that i'm using "android" for <21 and so it seems i have to use different package names depending on Xposed version
Click to expand...
Click to collapse
I was talking about "other things than the system_server", i.e. the process for ChooserActivity etc. This process is hardly used, I'm not even sure if it existed in previous versions. Only for this process, the package name is faked to be "system". The system_server, which is way more widely used, will keep package name "android". So I don't expect a single module to break.

If no update for older modules is needed its great :good:

can i use it on samsung device running cm 12
can i use it on samsung device running cm 12