Hi, I've been gone for a long long time and just came back with a new module.
I have seen that some other modules can actually apply the changes immediately without the need of doing a soft-reboot or full reboot. That is new to me. Maybe I missed it during those times when I'm not around.
So I want to ask the masters about this technique. How do you implement it. Or is there a xposed method which is reponsible for this?
I'm trying to apply changes to resources of a package.
I hope someone can explain to me how to implement it.
Thanks in advance!
Usual scenario:
Code:
<load preferences>
<hook method>
<do something inside the method using the loaded preferences>
Dynamically:
Code:
<initialize XSharedPreferences>
<hook method>
<reload preferences using XSharedPreferences.reload() and getting the preferences directly>
<do something inside the method using the loaded preferences>
You can also use broadcasts, if possible.
GermainZ said:
Usual scenario:
Code:
<load preferences>
<hook method>
<do something inside the method using the loaded preferences>
Dynamically:
Code:
<initialize XSharedPreferences>
<hook method>
<reload preferences using XSharedPreferences.reload() and getting the preferences directly>
<do something inside the method using the loaded preferences>
You can also use broadcasts, if possible.
Click to expand...
Click to collapse
sorry but the idea really can't sink into my mind... maybe I need some actual code... but anyway sir, by using XSharedPreferences, does it mean that all inputs must be saved in a prefs file?
This module I've made does not actually utilize SharedPrreferences, but store them inside the files dir using getFilesDir() for some reason...
WisdomSky said:
sorry but the idea really can't sink into my mind... maybe I need some actual code... but anyway sir, by using XSharedPreferences, does it mean that all inputs must be saved in a prefs file?
This module I've made does not actually utilize SharedPrreferences, but store them inside the files dir using getFilesDir() for some reason...
Click to expand...
Click to collapse
Well in that case you'd just read the preferences before applying them. In some cases (resources replacements), I don't think it's possible, but if you're hooking a module to change a TextView's color for example:
Code:
beforeHookedMethod:
int textColor = getTextColor(); // load the preference inside the method
TextView textView = …;
textView.setTextColor(textColor); // apply the preference
I might be able to give you an actual example if you explain what you're doing exactly, but as I said I don't think it's possible for resource replacements (which I guess is what you're doing).
GermainZ said:
Well in that case you'd just read the preferences before applying them. In some cases (resources replacements), I don't think it's possible, but if you're hooking a module to change a TextView's color for example:
Code:
beforeHookedMethod:
int textColor = getTextColor(); // load the preference inside the method
TextView textView = …;
textView.setTextColor(textColor); // apply the preference
I might be able to give you an actual example if you explain what you're doing exactly, but as I said I don't think it's possible for resource replacements (which I guess is what you're doing).
Click to expand...
Click to collapse
When a user has selected a package, a new directory under its package name will be created inside the files dir of my app, and when the user has applied a replacement to a certain resource a new directory will be created inside the directory created a while ago. and then inside this directory is where a new file is created and the filename will be the resource name and the content of the file is just a single line plain text which is the replacement value.
so if you can see it, there is a heirarchy of directories...
under the files dir... it could look like this...
[dir]files
-----[dir]com.package.name
----------[dir]string
---------------[file]app_name
----------[dir]drawable
---------------[file]ic_launcher
by using this pattern, I can write something that will loop through the files dir... get the package name, then get the resource type, then get the resource name and finally get its value by reading the content. And now we all have the needed arguments to pass to the setReplacement method...
but since you said that it is not applicable to resource replacements, then there's really no hope.
WisdomSky said:
but since you said that it is not applicable to resource replacements, then there's really no hope.
Click to expand...
Click to collapse
I might be wrong as I'm not too familiar with replacing resources. Where are you replacing the resources? Also, can wee see a (simplified/pseudo-code, maybe) code snippet of you doing so?
The problem with resources is that the app/system will usually load resources just once, or at least only at certain spots of the code. So even if you set a new replacement, it won't come into effect immediately, but only when the app/system decides loads it again. Same for removed replacements.
WisdomSky said:
I hope someone can explain to me how to implement it.
Thanks in advance!
Click to expand...
Click to collapse
If you module hooks Activity, Service or any other context application, you can store settings not with Shared Preferences, but in system settings database and use ContextResolver to get information from database.
and of course use <uses-permission android:name="android.permission.WRITE_SETTINGS" />
Here is an example:
Code:
findAndHookMethod("com.android.phone.PhoneApp", paramLoadPackageParam.classLoader, "onCreate", new XC_MethodHook()
{
protected void beforeHookedMethod(MethodHookParam param) throws Throwable
{
ContentResolver cr = (ContentResolver) XposedHelpers.callMethod(param.thisObject, "getContentResolver");
Class <?> Features = XposedHelpers.findClass("com.android.phone.HtcFeatureList", paramLoadPackageParam.classLoader);
boolean CallRecording = Misc.toBoolean(Settings.System.getInt(cr, Const.TWEAK_CALL_REC, 0));
if (CallRecording)
{
XposedHelpers.setStaticBooleanField(Features, "FEATURE_SUPPORT_VOICE_RECORDING", true);
}
}
});
More look here https://github.com/Falseclock/HtcOneTweaker/blob/master/src/kz/virtex/htc/tweaker/mods/Recorder.java
It is possible also to implement for resources, but you have always lookup views by identifier, load your application resources, redraw drawables, strings, etc. AND THIS IS BATTERY COST EFFICIENT method.
Other way - store replaced drawables for example in static variables and do not redraw every time. But there will be a huge code if you are replacing a lot of resources.
here is another example
Code:
public static Drawable Background;
findAndHookMethod(packageName + ".ui.ConversationListBaseAdapter", paramLoadPackageParam.classLoader, "bind", "android.view.View", "android.content.Context", packageName + ".ui.ConversationHeader", new XC_MethodHook()
{
protected void afterHookedMethod(MethodHookParam param) throws Throwable
{
boolean isRead = (Boolean) XposedHelpers.callMethod(param.args[2], "isRead");
View row = (View) param.args[0];
if (Background == null)
{
Background = row.getBackground();
if (Background == null)
{
Background = new ColorDrawable(row.getContext().getResources().getColor(android.R.color.transparent));
}
}
if (isRead == false)
{
XModuleResources modRes = XModuleResources.createInstance(XMain.MODULE_PATH, null);
row.setBackgroundDrawable(modRes.getDrawable(R.drawable.list_background_unread));
} else
{
row.setBackgroundDrawable(Background);
}
}
});
Falseclock said:
If you module hooks Activity, Service or any other context application, you can store settings not with Shared Preferences, but in system settings database and use ContextResolver to get information from database.
and of course use <uses-permission android:name="android.permission.WRITE_SETTINGS" />
Here is an example:
Click to expand...
Click to collapse
Ideally, all traces of an Xposed module should be removed when it's uninstalled, IMO. This goes against that.
GermainZ said:
Ideally, all traces of an Xposed module should be removed when it's uninstalled, IMO. This goes against that.
Click to expand...
Click to collapse
Ideally yes, but there are some tweak/mods requires fast settings change and immediate apply without restart. Otherwise such mods are not usable.
I do such only for special mods. All other mods are stored in shared preferences.
Falseclock said:
Ideally yes, but there are some tweak/mods requires fast settings change and immediate apply without restart. Otherwise such mods are not usable.
I do such only for special mods. All other mods are stored in shared preferences.
Click to expand...
Click to collapse
Then get the app's context/system context and use your own settings, or register and use a BroadcastReceiver.
GermainZ said:
Then get the app's context/system context and use your own settings, or register and use a BroadcastReceiver.
Click to expand...
Click to collapse
you are completely right. I just took ready code from my old custom ROM and used as it is in Xposed mode.
time to refactor my code )))
Hi I want to blend in too so: I have charged the preferences in the initzigote and after I have method like this:
Code:
beforhookedmethod{
Pref.reload();
String[] A new string[2000];
Map<string,?> B = Pref.getall();
i=0;
for(Map.Entry<String,?> entry : a.entrySet()){
B[i] = entry.getValue().toString();
Xposedbridge.log(entry.getvalue());
i++;
}
//some code that set this array into a hooked field
}
Now the problem is:if I remove the reload pref,after a reboot all work but if I leave the reload nothing work;the method is still hooked because I see that doesn't do what it normally do,but doesn't do what I say in the hook and even no log.What could be the problem?
Thanks.
Massi-X said:
Hi I want to blend in too so: I have charged the preferences in the initzigote and after I have method like this:
Code:
beforhookedmethod{
Pref.reload();
String[] A new string[2000];
Map<string,?> B = Pref.getall();
i=0;
for(Map.Entry<String,?> entry : a.entrySet()){
B[i] = entry.getValue().toString();
Xposedbridge.log(entry.getvalue());
i++;
}
//some code that set this array into a hooked field
}
Now the problem is:if I remove the reload pref,after a reboot all work but if I leave the reload nothing work;the method is still hooked because I see that doesn't do what it normally do,but doesn't do what I say in the hook and even no log.What could be the problem?
Thanks.
Click to expand...
Click to collapse
Full code? what's Pref? How are you initializing it?
GermainZ said:
Full code? what's Pref? How are you initializing it?
Click to expand...
Click to collapse
This is the full code:
Code:
public String[] A = new String[2000];
Field B = null;
public XSharedPreferences Pref;
@Override
public void initZygote(StartupParam startupParam) throws Throwable {
Pref = new XSharedPreferences("com.android.xposed...", "Preferences");
}
public void handleLoadPackage(final LoadPackageParam lpparam) throws Throwable {
if (lpparam.packageName.equals("com.android...")) {
de.robv.android.xposed.XposedHelpers.findAndHookMethod
("com.android...", lpparam.classLoader, "....", Operation.class,
new XC_MethodHook() {
@Override
protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
final Class<?> Constants = de.robv.android.xposed.XposedHelpers.findClass
("....", lpparam.classLoader);
Pref.reload();
Map<String,?> D = xPreferences.getAll();
int i=0;
for (Map.Entry<String, ?> entry: D.entrySet()) {
A[i] = entry.getKey();
de.robv.android.xposed.XposedBridge.log(entry.getKey());
i++;
}
B = de.robv.android.xposed.XposedHelpers.findField
(Constants, "ACCEPTABLE...");
final Object oldFieldAcc = B.get(Constants);
B.set
(oldFieldAcc, A);
});
}
}
}
I want to keep the secret so I obscured the name of variables and some string but all the code is exactly that!
Thanks!
Massi-X said:
This is the full code:
Click to expand...
Click to collapse
And it works fine when you remove .reload()? I'm not sure what's wrong, but if I had to guess, I'd say it's a permission issue. Do this when defining Pref instead:
Code:
Pref = new XSharedPreferences(…, …);
[COLOR="Red"]Pref.makeWorldReadable();[/COLOR]
GermainZ said:
And it works fine when you remove .reload()? I'm not sure what's wrong, but if I had to guess, I'd say it's a permission issue. Do this when defining Pref instead:
Code:
Pref = new XSharedPreferences(…, …);
[COLOR="Red"]Pref.makeWorldReadable();[/COLOR]
Click to expand...
Click to collapse
Yes works perfect when I remove to reload.I have yet tried this solution but not work.
I try to explain you what happens when I use the version with pref.reload:I select the option in my app and reboot and all work,also the log;when I change things on the go old preferences continue to work and the hook also but all new things aren't considered and the log stop to work.
I'm going crazy....
That's easy to explain: You write the settings from your own app, but read them from a different app. It doesn't matter that your code tries to read the settings, it's executed in the hooked app's process with the hooked app's UID. Android's security concept doesn't allow this by default, preferences are usually only readable for the app that created it. Pref.makeWorldReadable() will change this (as the name says), but Android automatically resets the permissions when you store the settings again. To fix this, try:
Code:
[B]getPreferenceManager().setSharedPreferencesMode(MODE_WORLD_READABLE);[/B]
addPreferencesFromResource(R.xml.preferences);
https://github.com/rovo89/PlayStore...d/mods/playstorefix/SettingsActivity.java#L29
rovo89 said:
That's easy to explain: You write the settings from your own app, but read them from a different app. It doesn't matter that your code tries to read the settings, it's executed in the hooked app's process with the hooked app's UID. Android's security concept doesn't allow this by default, preferences are usually only readable for the app that created it. Pref.makeWorldReadable() will change this (as the name says), but Android automatically resets the permissions when you store the settings again. To fix this, try:
Code:
[B]getPreferenceManager().setSharedPreferencesMode(MODE_WORLD_READABLE);[/B]
addPreferencesFromResource(R.xml.preferences);
https://github.com/rovo89/PlayStore...d/mods/playstorefix/SettingsActivity.java#L29
Click to expand...
Click to collapse
You won't believe it but i think this last night .And yes,this was the problem!Thanks to everyone have help me.I think that my module will online today or tomorrow. :good:
Okay, so I have some resources in my module/app. Say, a Drawable. Unfortunately, when I try to use them (to create a UI, say) from within handleLoadPackage, well, I can't. I can access R.drawable.abc just fine; but for some reason, all I get is a strange white rectangle instead of the actual Drawable.
How do I work around this issue? Thank you!
This is because your hook is not really part of your app - it runs in the hooked app. To access your own resources, you need to create a context for your app first.
You're going to need a general context first. If you can't get any from the class you're hooking, you can try AndroidAppHelper.currentApplication(). Then, use that context to create a context for your own app (see Context.createContext(...)). You can then access your resources using that context.
GermainZ said:
This is because your hook is not really part of your app - it runs in the hooked app. To access your own resources, you need to create a context for your app first.
You're going to need a general context first. If you can't get any from the class you're hooking, you can try AndroidAppHelper.currentApplication(). Then, use that context to create a context for your own app (see Context.createContext(...)). You can then access your resources using that context.
Click to expand...
Click to collapse
I tried this:
Code:
Context c = tv.getContext().createPackageContext("package.name", Context.CONTEXT_IGNORE_SECURITY);
int resId = c.getResources().getIdentifier("ic_launcher", "drawable", "package.name");
dialog.setFeatureDrawableResource(Window.FEATURE_LEFT_ICON, resId);
No dice. I'm sure using c.getResources.getDrawable would work, but my dialog method requires the ID, not the Drawable itself.
perseus0807 said:
I tried this:
Code:
Context c = tv.getContext().createPackageContext("package.name", Context.CONTEXT_IGNORE_SECURITY);
int resId = c.getResources().getIdentifier("ic_launcher", "drawable", "package.name");
dialog.setFeatureDrawableResource(Window.FEATURE_LEFT_ICON, resId);
No dice. I'm sure using c.getResources.getDrawable would work, but my dialog method requires the ID, not the Drawable itself.
Click to expand...
Click to collapse
Yeah, but that resource ID will always be resolved using the target app's resources. If you can't use the the drawable directly, you can try this:
Code:
private static String MODULE_PATH = null;
private int mFakeId = 0;
public void initZygote(StartupParam startupParam) throws Throwable {
MODULE_PATH = startupParam.modulePath;
}
public void handleInitPackageResources(InitPackageResourcesParam resparam) throws Throwable {
if (!resparam.packageName.equals("your.target.app"))
return;
XModuleResources modRes = XModuleResources.createInstance(MODULE_PATH, resparam.res);
mFakeId = resparam.res.addResource(modRes, R.drawable.ic_launcher);
}
Then use mFakeId in your callback, which should run after the resources have been initialized. addResource() generates an ID for you an sets up a resource replacement for that non-existent ID to the item in your own resources.
rovo89 said:
Yeah, but that resource ID will always be resolved using the target app's resources. If you can't use the the drawable directly, you can try this:
Code:
private static String MODULE_PATH = null;
private int mFakeId = 0;
public void initZygote(StartupParam startupParam) throws Throwable {
MODULE_PATH = startupParam.modulePath;
}
public void handleInitPackageResources(InitPackageResourcesParam resparam) throws Throwable {
if (!resparam.packageName.equals("your.target.app"))
return;
XModuleResources modRes = XModuleResources.createInstance(MODULE_PATH, resparam.res);
mFakeId = resparam.res.addResource(modRes, R.drawable.ic_launcher);
}
Then use mFakeId in your callback, which should run after the resources have been initialized. addResource() generates an ID for you an sets up a resource replacement for that non-existent ID to the item in your own resources.
Click to expand...
Click to collapse
This works, thank you so much! Bit stupid of me, I should have inferred this from the tutorial.
perseus0807 said:
I tried this:
Code:
Context c = tv.getContext().createPackageContext("package.name", Context.CONTEXT_IGNORE_SECURITY);
int resId = c.getResources().getIdentifier("ic_launcher", "drawable", "package.name");
dialog.setFeatureDrawableResource(Window.FEATURE_LEFT_ICON, resId);
No dice. I'm sure using c.getResources.getDrawable would work, but my dialog method requires the ID, not the Drawable itself.
Click to expand...
Click to collapse
To add to what rovo said, you could've use getDrawable(…) instead of getIdentifier(…) here, which would've given you Drawable (that you can then use) instead of a resource ID that won't work in the hooked app.
Thank you, it works!!
I'm a newbee to xposed module development. I searched sometimes in this forum and viewed some open-source mudules on github, but I still don't know how to reload prefs in my module.
I try to change the setting repeatedly, but logcat always displays that prefs returned a false. My code is here below:
This is the main class loaded by xposed:
Code:
public class Main implements IXposedHookLoadPackage, IXposedHookZygoteInit, IXposedHookInitPackageResources{
private static XSharedPreferences prefs = new XSharedPreferences(Main.class.getPackage().getName());
....
SOME HACKS
....
private BroadcastReceiver xReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
context = mContext;
if (intent.getAction().equals("xxx.xxx.SETTING_CHANGED")){
prefs.makeWorldReadable(); // Wether this line is added or not, the result is same.
prefs.reload();
Log.d(TAG, String.valueOf(prefs.getBoolean("key", false)));
}
}
};
}
This is the setting screen class:
Code:
public class Setting extends PreferenceActivity implements OnSharedPreferenceChangeListener{
ListPreference lp;
ListPreference _lp;
EditTextPreference etp;
CheckBoxPreference cbp;
@SuppressWarnings("deprecation")
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
addPreferencesFromResource(R.xml.setting);
getPreferenceManager().setSharedPreferencesMode(MODE_WORLD_READABLE);
SharedPreferences prefs = PreferenceManager.getDefaultSharedPreferences(this);
prefs.registerOnSharedPreferenceChangeListener(this);
}
@SuppressWarnings("deprecation")
@Override
public void onSharedPreferenceChanged(SharedPreferences sharedPreferences, String key) {
Intent intent = new Intent();
intent.setAction("xxx.xxx.SETTING_CHANGED");
Setting.this,sendBroadcast(intent);
}
From memory, I believe the XSharedPreferences constructor takes the preferences' file name, which is usually something like "com.mypackage_preferences" and not only "com.mypackage".
Note that you don't need to use makeWorldReadable in your module since you're doing that in your preferences activity.
GermainZ said:
From memory, I believe the XSharedPreferences constructor takes the preferences' file name, which is usually something like "com.mypackage_preferences" and not only "com.mypackage".
Note that you don't need to use makeWorldReadable in your module since you're doing that in your preferences activity.
Click to expand...
Click to collapse
Thanks for your reply. But I can't understand clearly and I'm even more confused.
Code:
XSharedPreferences prefs = new XSharedPreferences(Main.class.getPackage().getName());
This works well. Read preferences correctly.
In the source code of XSharedPreference class. The function "XSharedPreferences(String packageName)" will call "XSharedPreferences(String packageName, String prefFileName)" and complete the default preferences file name. I don't think I need to use full path and file name?
I still don't know how to reload settings correctly. Could you give me a copy of detailed code to work perfectly?
Awating your reply.
neverweep said:
Thanks for your reply. But I can't understand clearly and I'm even more confused.
Code:
XSharedPreferences prefs = new XSharedPreferences(Main.class.getPackage().getName());
This works well. Read preferences correctly.
In the source code of XSharedPreference class. The function "XSharedPreferences(String packageName)" will call "XSharedPreferences(String packageName, String prefFileName)" and complete the default preferences file name. I don't think I need to use full path and file name?
I still don't know how to reload settings correctly. Could you give me a copy of detailed code to work perfectly?
Awating your reply.
Click to expand...
Click to collapse
If I'm not mistaken, this:
Code:
XSharedPreferences prefs = new XSharedPreferences(Main.class.getPackage().getName());
… will load an "empty" preferences file (because it won't exist) so everything will have the default value. Try something like this instead:
Code:
XSharedPreferences prefs = new XSharedPreferences(Main.class.getPackage().getName() + "_preferences");
As for reloading preferences, you seem to be doing it correctly (XSharedPreferences.reload method), it's just that it's not working as intended for the reason explained above.
No, neverweep's code:
Code:
XSharedPreferences prefs = new XSharedPreferences(Main.class.getPackage().getName());
is good. I also use such code in my modules and everything works.
Rovo89 has code to add "_preferences" automatically (link: https://github.com/rovo89/XposedBri...bv/android/xposed/XSharedPreferences.java#L37)
I also had some trouble figuring out how to reload prefs in realtime, but thank's to this thread and to some attempts, I could finally figure it out.
Here's the code if this can help someone (plus the preference management is very simple so it should be a very easy example to follow):
on github (cannot post links yet):
Code:
lrq3000/XposedJitteryGyroFix/blob/14d7e93949bbfd5cfc31ce30482eff9860c35a49/GyroscopeNoiseFilter/src/net/kajos/gyronoisefilter/GyroscopeNoiseFilter.java#L50
hi all.
i created an xposed module but, inside my app, i also have what a standard android app has, like res/strings.xml.
now, even if the entry point is IXposedHookLoadPackage.handleLoadPackage() and then i don't have an android app context, i sometimes need to access my app package name and to my app strings but context.getPackageName() and context.getResources() don't return what i want.
what's the proper way to do it?
thanks a lot.
Do you already have a context? If not, you can use AndroidAppHelper.currentApplication().
To create a context for your application from an existing context, use Context.createPackageContext.
GermainZ said:
Do you already have a context? If not, you can use AndroidAppHelper.currentApplication().
To create a context for your application from an existing context, use Context.createPackageContext.
Click to expand...
Click to collapse
hi and thanks for your reply.
i tried this code but it returns "android" as the package name:
Code:
Context context = AndroidAppHelper.currentApplication();
String packageName = context.getPackageName();
am i missing something?
This is my way of accessing my app context:
Java:
XposedBridge.hookAllConstructors(<the class you want to hook>, new XC_MethodHook() {
[user=439709]@override[/user]
protected void afterHookedMethod(MethodHookParam param) throws Throwable {
log("initializing");
//The context that you mod (usually android)
//It happens that the constructor of the constructor to be hooked has the context as the first argument
//I think AndroidAppHelper.currentApplication() is a more general way to do it
Context modContext = (Context) param.args[0];
//Context of your app
Context appContext = modContext.createPackageContext(
PACKAGE_NAME, Context.CONTEXT_IGNORE_SECURITY);
Resources modRes = modContext.getResources();
Resources appRes = appContext.getResources();
...
}
});
where PACKAGE_NAME is a static field like this
Java:
public static final String PACKAGE_NAME = <Your class>.class.getPackage().getName();
Not sure if there are other alternatives. This is just my way to doing it in my modules
This helped a lot! Thanks!
Hello!
I've decided to change Smooth System Progress Bars module to use a navigation drawer and use fragments inside a "container". In order to do that, I had to "convert" my previously "Main activity" into a fragment. I've followed these instructions in order to achieve that.
But now I'm forced to reboot the phone to see the changes take effect. If I don't reboot, the values applied are the ones defined by default on the module's code.
More than that, every time I change anything on a PreferenceFragment (which has another options but nothing related to user's progress bars customization), the behavior is the same.
After rebooting, everything becomes as it should be. That's odd.
Since I'm fairly new to android programming, I really could use some help in order to understand this.
Can anyone help me?
I'm sorry for double posting.
I've just realized that this issue has nothing to do with fragments.
The problem exists even if I convert everything back to activities.
So this means that this started to happen immediately after I've implemented a navigation drawer. What could be wrong?
Any ideas?
Sorry once again.
I've solved my issue.
Discovered that the problem resided on NavigationDrawerFragment.java.
Somewhere along the code this happens:
Code:
/**
* Per the design guidelines, you should show the drawer on launch until the user manually
* expands it. This shared preference tracks this.
*/
private static final String PREF_USER_LEARNED_DRAWER = "navigation_drawer_learned";
--- some more code ---
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Read in the flag indicating whether or not the user has demonstrated awareness of the
// drawer. See PREF_USER_LEARNED_DRAWER for details.
SharedPreferences sp = PreferenceManager.getDefaultSharedPreferences(getActivity());
mUserLearnedDrawer = sp.getBoolean(PREF_USER_LEARNED_DRAWER, false);
if (savedInstanceState != null) {
mCurrentSelectedPosition = savedInstanceState.getInt(STATE_SELECTED_POSITION);
mFromSavedInstanceState = true;
}
// Select either the default item (0) or the last selected item.
selectItem(mCurrentSelectedPosition);
}
So, the problem is, in order to use that small feature (make the user aware of the drawer) the default AOSP code uses this:
Code:
SharedPreferences sp = PreferenceManager.getDefaultSharedPreferences(getActivity());
And that, my friends, compromises any of your SharedPreferences and/or XSharedPreferences.
I can live well without that small feature...deleted it from my module.
Everything is ok now.
:victory: