Develop Reference

Removing items from string set in shared preferences not persisting across app restarts [duplicate]

I'm trying to store a set of strings using the SharedPreferences API.
Set<String> stringSet = sharedPrefs.getStringSet("key", new HashSet<String>());
stringSet.add(new_element);
SharedPreferences.Editor editor = sharedPrefs.edit();
editor.putStringSet(stringSet);
editor.commit()
The first time I execute the code above, stringSet is set to the default value (the just created and empty HashSet) and it is stored without problems.
The second and subsequent times I execute this code, a stringSet object is returned with the first element added. I can add the element and, during the program execution, it is apparently stored in the SharedPreferences. However, when the program is killed and the SharedPreferences is loaded again from persistent storage, the newer values are lost.
How can the second and subsequent elements be stored so that they don't get lost?

This "problem" is documented on SharedPreferences.getStringSet.
The SharedPreferences.getStringSet returns a reference of the stored HashSet object
inside the SharedPreferences. When you add elements to this object, they are added in fact inside the SharedPreferences.
That is ok, but the problem comes when you try to store it: Android compares the modified HashSet that you are trying to save using SharedPreferences.Editor.putStringSet with the current one stored on the SharedPreference, and both are the same object!!!
A possible solution is to make a copy of the Set<String> returned by the SharedPreferences object:
Set<String> s = new HashSet<String>(sharedPrefs.getStringSet("key", new HashSet<String>()));
That makes s a different object, and the strings added to s will not be added to the set stored inside the SharedPreferences.
Other workaround that will work is to use the same SharedPreferences.Editor transaction to store another simpler preference (like an integer or boolean), the only thing you need is to force that the stored value are different on each transaction (for example, you could store the string set size).

This behaviour is documented so it is by design:
from getStringSet:
"Note that you must not modify the set instance returned by this call. The consistency of the stored data is not guaranteed if you do, nor is your ability to modify the instance at all."
And it seems quite reasonable especially if it is documented in the API, otherwise this API would have to make copy on each access. So the reason for this design was probably performance. I suppose they should make this function return result wrapped in unmodifiable class instance, but this once again requires allocation.

Was searching for a solution for the same issue, resolved it by:
1) Retrieve the existing set from the shared preferences
2) Make a copy of it
3) Update the copy
4) Save the copy
SharedPreferences.Editor editor = sharedPrefs.edit();
Set<String> oldSet = sharedPrefs.getStringSet("key", new HashSet<String>());
//make a copy, update it and save it
Set<String> newStrSet = new HashSet<String>();
newStrSet.add(new_element);
newStrSet.addAll(oldSet);
editor.putStringSet("key",newStrSet); edit.commit();
Why

Source Code Explanation
While the other good answers on here have correctly pointed out that this potential issue is documented in SharedPreferences.getStringSet(), basically "Don't modify the returned Set because the behavior isn't guaranteed", I'd like to actually contribute the source code that causes this problem/behavior for anyone that wants to dive deeper.
Taking a look at SharedPreferencesImpl (source code as of Android Pie) we can see that in SharedPreferencesImpl.commitToMemory() there is a comparison that occurs between the original value (a Set<String> in our case) and the newly modified value:
private MemoryCommitResult commitToMemory() {
// ... other code
// mModified is a Map of all the key/values added through the various put*() methods.
for (Map.Entry<String, Object> e : mModified.entrySet()) {
String k = e.getKey();
Object v = e.getValue();
// ... other code
// mapToWriteToDisk is a copy of the in-memory Map of our SharedPreference file's
// key/value pairs.
if (mapToWriteToDisk.containsKey(k)) {
Object existingValue = mapToWriteToDisk.get(k);
if (existingValue != null && existingValue.equals(v)) {
continue;
}
}
mapToWriteToDisk.put(k, v);
}
So basically what's happening here is that when you try to write your changes to file this code will loop through your modified/added key/value pairs and check if they already exist, and will only write them to file if they don't or are different from the existing value that was read into memory.
The key line to pay attention to here is if (existingValue != null && existingValue.equals(v)). You're new value will only be written to disk if existingValue is null (doesn't already exist) or if existingValue's contents are different from the new value's contents.
This the the crux of the issue. existingValue is read from memory. The SharedPreferences file that you are trying to modify is read into memory and stored as Map<String, Object> mMap; (later copied into mapToWriteToDisk each time you try to write to file). When you call getStringSet() you get back a Set from this in-memory Map. If you then add a value to this same Set instance, you are modifying the in-memory Map. Then when you call editor.putStringSet() and try to commit, commitToMemory() gets executed, and the comparison line tries to compare your newly modified value, v, to existingValue which is basically the same in-memory Set as the one you've just modified. The object instances are different, because the Sets have been copied in various places, but the contents are identical.
So you're trying to compare your new data to your old data, but you've already unintentionally updated your old data by directly modifying that Set instance. Thus your new data will not be written to file.
But why are the values stored initially but disappear after the app is killed?
As the OP stated, it seems as if the values are stored while you're testing the app, but then the new values disappear after you kill the app process and restart it. This is because while the app is running and you're adding values, you're still adding the values to the in-memory Set structure, and when you call getStringSet() you're getting back this same in-memory Set. All your values are there and it looks like it's working. But after you kill the app, this in-memory structure is destroyed along with all the new values since they were never written to file.
Solution
As others have stated, just avoid modifying the in-memory structure, because you're basically causing a side-effect. So when you call getStringSet() and want to reuse the contents as a starting point, just copy the contents into a different Set instance instead of directly modifying it: new HashSet<>(getPrefs().getStringSet()). Now when the comparison happens, the in-memory existingValue will actually be different from your modified value v.

I tried all the above answers none worked for me.
So I did the following steps
before adding new element to the list of old shared pref, make a copy of it
call a method with the above copy as a param to that method.
inside that method clear the shared pref which are holding that values.
add the values present in copy to the cleared shared preference it will treat it as new.
public static void addCalcsToSharedPrefSet(Context ctx,Set<String> favoriteCalcList) {
ctx.getSharedPreferences(FAV_PREFERENCES, 0).edit().clear().commit();
SharedPreferences sharedpreferences = ctx.getSharedPreferences(FAV_PREFERENCES, Context.MODE_PRIVATE);
SharedPreferences.Editor editor = sharedpreferences.edit();
editor.putStringSet(FAV_CALC_NAME, favoriteCalcList);
editor.apply(); }
I was facing issue with the values not being persistent, if i reopen the app after cleaning the app from background only first element added to the list was shown.

Just as a note, Shared Preferences can't just be overwritten.
If you have assigned a value to it, you have to remove it first by the method remove(KEY) and then commit() to destroy the key.
Then you can assign a new value to it.
https://developer.android.com/reference/android/content/SharedPreferences.html#getStringSet(java.lang.String,%20java.util.Set%3Cjava.lang.String%3E)

SharedPreferences sent by ACRA are all empty

I followed the manual for implementing SharePreferences capture inside ACRA. What I basically did was including the following line in the configuration (is one of the lines of the complete configuration:
customReportContent = { APP_VERSION,
ANDROID_VERSION,
SHARED_PREFERENCES }
additionalSharedPreferences={"EXTRA_MESSAGE","NOTIF_ACTIVATED"}
I followed the information from this manual and the details on this one .
However, all the preferences I received in my Cloudant database appear as empty. I made sure that ALL variables are not the default variables, specially on this 2 ones, which are changed earlier in the configuration, I tricked my code just before the message changing intentionally those variables. But, I am still receiving empty values.
I order to double check I included the email option to check what data was written by ACRA, also filling the field empty. The evidences I have:
- Report at Clound Ant with SharedPreferences are empty.
- The email text introduced by ACRA and offered to the user is also having the field as "empty".
- No error output from ACRA in any operation
After investigating during the morning I am blocked and I don't know what else to do.
SDK21 and ACRA4.5.0 using a 2.3 android mobile.

This was actually a wrong usage of SharePreferences in ACRA and not actually a bug in ACRA.
When the SharedPreferences is instantiated is a good practice to create a dedicated file using a code line like this one:
String MyPREFERENCES = "MYPREFS";
sharedpreferences = getSharedPreferences(MyPREFERENCES, Context.MODE_PRIVATE);
In this case "MyPREFENCES" will be the new preferences name. In order to properly use ACRA this new file needs to be explicitly added in the ACRA configuration using the following:
additionalSharedPreferences={"MYPREFS"}
The problem I was having was that I included the fields that I included in my shared preferences and NOT the preferences file that I created. Just adding the proper filename everything was working ok.

Writing to shared preferences too slow?

I have created a service that writes some information about a widget once a user places it on home screen(the info is picked up from the confutation activity)..i also write down the number of widgets the user has set up.
Once the user removes the widget i delete that info in the shared preferences.
What i have experienced is that if user places for example 2 widgets, then removes one, then places one again, doing all those actions fast, the shared preferences file gets inconsistent values in it. Sometimes it works ok but most of the time i get stuck with wrong values in it.
I am using apply(), i've tried with commit but same thing happens.
The values i store in the shared preferences are crucial for the system to work, without it the widgets are useless since they are backed up by info from internet based on the user configuration which is written in preferences.
Is switching to a database solution more reliable or any other viable solution which will fix this "race condition"? (maybe forcing my own mechanism of synchronization, but as far as i've understood from docs, apply() is already synchronized, and the read/write should first go to RAM which should make it fast and i shouldnt be experiencing any problems like this since the user cant physically manage to delete a widget and place a new one faster then 2-3 seconds top!)

Try using the synchronized keyword in working with the SharedPreferences itself. For example, here is a method that could be used when setting an application String in the SharedPreferences of an Android app:
public synchronized static void setAppString(Context context, String pref,
String val) {
SharedPreferences sp = context.getSharedPreferences(
APP_PREFS_UNIQUE_ID, Context.MODE_PRIVATE);
Editor editor = sp.edit();
editor.putString(pref, val);
editor.commit();
}
For few/simple key-value pairs, you might not need the overhead of a database paradigm.

How can I share a SharedPreferences file across two different android apps?

I've been struggling with this for a while. Basically, I want to have two applications (which will always be installed together) share preferences, with one of them being just a service which runs in the background and needs to use the preferences (should own the preferences but only really needs to read them) and the other app being a front-end UI app which needs to be able to write to the preferences file owned by the other app. The service will be doing things in the background (which may be determined by the preferences) and the UI will allow the user to edit the preferences and view some information from the service. However, they will be different packages/apps.
I tried following this tutorial which gave me a pretty good idea of how to have preferences in one app which can be read by another. Essentially, I create a new context through myContext = createPackageContext("com.example.package",Context.MODE_WORLD_READABLE + Context.MODE_WORLD_WRITEABLE); and then call myContext.getSharedPreferences("pref_name", Context.MODE_WORLD_READABLE + Context.MODE_WORLD_WRITEABLE); However, I can't write to the preferences successfully from the outside app - (SharedPreferences.Editor).commit() returns false and I get a warning in logcat about being unable to edit pref_name.xml.bak.
How can I successfully set up my applications so both of them can read and write to the same preferences file (which is stored in the data folder of one of them)?

It is better to set private mode for the file. App needs to be signed with same set of certificates to share this file.
Set sharedUserId in both apps to be same.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.hello"
android:versionCode="1"
android:versionName="1.0"
android:sharedUserId="com.example">
....
Get Context from other package:
mContext = context.createPackageContext(
"com.example.otherapp",
Context.MODE_PRIVATE);
mPrefs = mContext.getSharedPreferences("sameFileNameHere", Activity.MODE_PRIVATE);
Get items as usual from SharedPreference. You can access it now.

First, I should note that this is not officially supported, although there may be a supported way to do this (i.e. it would NOT be this method) added to Android in the future (source for both claims: see second paragraph of this link).
Again, this is unsupported and is very possibly unstable. I primarily did this as an experiment to see if it was possible; take extreme caution if you are planning to actually incorporate this method into an application.
However, it appears to be possible to share preferences between applications if a few requirements are met. First, if you want App B to be able to access App A's preferences the package name of App B must be a child of App A's package name (e.g. App A: com.example.pkg App B: com.example.pkg.stuff). Additionally, they can't be wanting to access the file at the same time (I assume the same rules apply as for accessing them between activities, if you want to ensure atomic access you'll have to use additional safeguards such as .wait() and .notify(), but I won't go into that here).
Note: all of this works on the emulator on 2.2 and 2.3.3- I haven't extensively tested across devices or android versions.
Things to do in the app which is going to own the preferences (App A from above):
1.) Declare the SharedPreferences file
This is fairly simple. Simply declare a couple variables for your sharedpreferences file and the editor in your class and instantiate them in your onCreate method. You can put a string in the preferences now that you will use to make sure the other app can read it properly.
public class stuff extends Activity {
SharedPreferences mPrefs = null;
SharedPreferences.Editor mEd= null;
#Override
public void onCreate(Bundle savedInstanceState){
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
mPrefs = (getApplicationContext()).getSharedPreferences("svcprefs", Context.MODE_WORLD_READABLE + Context.MODE_WORLD_WRITEABLE);
mEd = mPrefs.edit();
mEd.putString("test", "original send from prefs owner");
mEd.commit();
2.) Set up the backup file
The getSharedPreferences method appears to check for a .bak file to load the preferences from. This is why it says in the documentation that it will not work across multiple processes; to minimize I/O, it loads the prefs ONCE when you grab them and only backs them up when you close your application/activity. However, if you call this from an outside application you will get a warning about not having the right file permissions for the folder (which is the first app's data folder). To fix this we are going to create the .bak file ourselves and make it publicly readable/writable. The way I chose to do this was to define three variables in my overall class.
final String[] copyToBackup = { "dd", "if=/data/data/com.example.pkg/shared_prefs/prefs.xml", "of=/data/data/com.example.pkg/shared_prefs/prefs.xml.bak", "bs=1024" };
final String[] mainFixPerm = {"chmod", "666", "/data/data/com.example.pkg/shared_prefs/prefs.xml"};
final String[] bakFixPerm = {"chmod", "666", "/data/data/com.example.pkg/shared_prefs/prefs.xml.bak"};
and make a function in my main class which would take these as arguments and execute them
public void execCommand(String[] arg0){
try {
final Process pr = Runtime.getRuntime().exec(arg0);
final int retval = pr.waitFor();
if ( retval != 0 ) {
System.err.println("Error:" + retval);
}
}
catch (Exception e) {}
}
It's not terribly pretty or good but it works.
Now, in your onCreate method (right after editor.commit())you will call this function with each of the three strings.
execCommand(copyToBackup);
execCommand(mainFixPerm);
execCommand(bakFixPerm);
This will copy the file and make both the main .xml and the .xml.bak files accessible to outside programs. You should also call these three methods in your onDestroy() to make sure the database is backed up properly when your app exits, and additionally call them right before you call getSharedPreferences elsewhere in your application (as otherwise it will load the .bak file which is likely out of date if another process has been editing the main .xml file). That's all you need to do in this application though, though. You can call getSharedPreferences elsewhere in this activity and it will grab all the data from the .xml file, allowing you to then call the getdatatype("key") methods and retrieve it.
Things to do in the accessing file(s) (App B from above)
1.) Write to the file
This is even simpler. I made a button on this activity and set up code in it's onClick method which would save something to the shared preferences file. Remember that App B's package must be a child of App A's package. We will be creating a context based on App A's context and then calling getSharedPreferences on that context.
prefsbutton.setOnClickListener(new View.OnClickListener() {
public void onClick(View v) {
Context myContext = null;
try {
// App A's context
myContext = createPackageContext("com.example.pkg", Context.MODE_WORLD_READABLE + Context.MODE_WORLD_WRITEABLE);
} catch (NameNotFoundException e) {e.printStackTrace();}
testPrefs = myContext.getSharedPreferences("svcprefs", Context.MODE_WORLD_READABLE + Context.MODE_WORLD_WRITEABLE);
testEd = testPrefs.edit();
String valueFromPrefs = testPrefs.getString("test", "read failure");
TextView test1 = (TextView)findViewById(R.id.tvprefs);
test1.setText(valueFromPrefs);
testEd.putString("test2", "testback");
boolean edit_success = testEd.commit();
This grabs the string I set in the other application and displays it (or an error message) in a textview in this application. Additionally it sets a new string in the preferences file and commits the changes. After this runs, if your other application calls getSharedPreferences it will retrieve the file including the changes from this app.

SharedPreferences will not save/load in PreferenceActivity

EDIT: The problem described below was due to a very peculiar device issue not caused by any coding-related problem.
I have a preferenceActivity in which I have many checkBoxPreferences.
The checkBoxPreference is suppose to save the the default shared preferences file, and then be called again when I open the app in order to update the UI.
This does not happen like it's suppose to.
If I close the app and open it back up, my values remain like they are suppose to, but if I use task manager to end the app or if I power cycle the phone (when the app is not running) then the defaultValues are called again.
So, I created a SharedPreference in my onResume() to test it.
SharedPreferences pref = PreferenceManager.getDefaultSharedPreferences(getApplicationContext());
I then check to see if there is a key in that sharedpreference.
pref.contains("myCheckBoxPreference");
When I close out and open it back up, it returns true. if I close with the task manager or power cycle the phone off and on, then that returns false.
So, I tried manually setting the SharedPreference
SharedPreferences.Editor editor = pref.edit();
editor.putBoolean("myCheckBoxPreference", myCheckBoxPreference.isChecked());
editor.commit();
and then I called that when the checkboxpreference value changed. I also tried calling it in onStop and onPause. Still, if I close the app and open it back up, pref.contains returns true, but if I power cycle the phone off and back on, it returns false.
So I then tried using a SharedPreferences file.
In the class declaration:
public static final String PREFS = "prefs";
And in the onResume():
SharedPreferences pref = this.getSharedPreferences(PREFS, 0);
Same behavior, pref.contains still returns true if I just close the app and open it back up, but it returns false if I power the phone off and back on.
I then tried changing the key value of myCheckBoxPreference to something that did NOT match the xml key for the CheckBoxPreference, and it still had the same effect.
And I uninstalled the application from the phone, then powered the phone off and back on, and then re-installed, and it still has the same effect.

I just solved it, I'm pretty sure. There's no code error on my part, and there is no issue with my app whatsoever (I don't believe, anyway.)
I created a new project called "testproj", then I copied ALL the code from my settings PreferenceActivity, pasted it into the TestprojActivity, and I copied the code from the xml it relied on, then pasted that into the main.xml of TestProj.
I then installed TestProj on the Samsung Captivate, changed the settings around, cleared the ram through RAM management (a function of the custom ROM I have), and the settings stuck. I then power cycled the phone and the settings were still there like I'd configured them.
They stayed both when I manually set them using:
PreferenceManager.getDefaultSharedPreferences();
and without manually saving them to the SharedPreferences.
Since it is not my phone, I haven't tried it yet, but I assume a Factory Data reset would fix it completely
EDIT: I was able to test on both a new Samsung Captivate and a Samsung infuse, and it worked.
I wasted a lot of my time trying to figure this out, and I hope it helps someone else. :)

I encountered a possibly similar problem on a Samsung Galaxy S, where the permissions for the preferences XML file had somehow changed/corrupted.
The log revealed some host process was failing to read the file, causing all the settings to reset to their defaults. I don't recall the exact error message, but it was along the lines of "permission denied for /path/to/preferences/file.xml".
The resolution for me was to delete the application data through Settings, Applications, Manage Applications, MyApp, Delete data. This deletes the preference file associated with the app and the problem instantly disappeared.
I assumed it was an isolated event, as I've not run into it again on a variety of Android devices (including the Galaxy S II).

On the client's main test device I came across the very same issue. The Device used is a Samsung Galaxy S with SDK level 8 (2.2.1).
The strange behavior is that either SharedPreferences are not saved, or, as after a factory reset, they're too persistent, that is to say they are not deleted after having reinstalled the application.
Due to the current distribution of 2.2.x, and the number of Samsung Galaxy S devices sold being several millions, the probability of an occurrence of this issue is significant.
So it can be considered as crucial to implement a workaround for saving preferences.
For collecting detailed characteristics to isolate this workaround in a sharp-edged way, could everyone who is also facing that issue please provide the corresponding kernel version (System.getProperty("os.version") here?
I was thinking of something like this:
// !! I know that 2.6.32.9 is not yet correct. This would be a false positive !!
if ((System.getProperty("os.version").startsWith("2.6.32.9"))
&& (android.os.Build.DEVICE.contains("GT-I9000")))
useInternalStorage();
else
useSharedPreferences();
I can post the real code here also once it's ready and someone is interested.
EDIT: some additional information:
Devices facing that issue:
Property | Values
---------------------------------+------------------------------------
Build.DEVICE | "GT-I9000T"
Build.VERSION.INCREMENTAL | "UBJP9"
Build.VERSION.RELEASE | "2.2.1"
Build.VERSION.SDK | 8
System.getProperty("os.version") | "2.6.32.9"
Similar devices NOT facing that issue:
Property | Values
---------------------------------+------------------------------------
Build.DEVICE | "GT-I9000"
Build.VERSION.INCREMENTAL | "AOJP4"
Build.VERSION.RELEASE | "2.2"
Build.VERSION.SDK | 8
System.getProperty("os.version") | "2.6.32.9"

Try clearing the editor before you set your values. I had the same problem and it worked for me.
Example:
Editor e = PreferenceManager.getDefaultSharedPreferences(getParent()).edit();
e.clear();
e.putStringSet(key, value);

It is possible to work around the issue of permissions by using sharedUserId which should be the same for any of your signed apps.
http://developer.android.com/reference/android/R.attr.html#sharedUserId

I too had a problem with saving and then retrieving data. I had my Save and Load code in a class that extends Application because I wanted a single instance of my data. I could see the String being saved, no errors in LogCat and yet when I try to load it, again with no error, my String is empty. I never checked whether the data actually went into the file so I have no idea whether there was a failure on Save or Load or both.
My code was more or less as follows: (comboToSave is simply a string generated by Gson from a simple data class)
in one method to save:
SharedPreferences sharedPref = activity.getPreferences(Context.MODE_PRIVATE);
SharedPreferences.Editor editor = sharedPref.edit();
editor.putString(getString(R.string.prefCombos), comboToSave);
editor.commit();
in another method to load:
SharedPreferences sharedPref = activity.getPreferences(Context.MODE_PRIVATE);
String loadedComboText = sharedPref.getString(getString(R.string.prefCombos), "");
After lots of head scratching and not knowing what to do I changed the code that retrieves the sharedPref value from
SharedPreferences sharedPref = activity.getPreferences(Context.MODE_PRIVATE);
to
SharedPreferences sharedPref = PreferenceManager.getDefaultSharedPreferences(getApplicationContext());
There is some more here on the difference between the two (although in my case it seems exactly the same)
Still the result on my Galaxy S3 was the same. However, testing both versions on other devices, including VDs (virtual devices) worked.
In the first version of the code I passed the Activity from the calling activity; for save from the activity where the final bit of data is collected from the user, and for loading from my main activity so that I had it ready when the app is started.
I played with uninsalling the app and re-intalling, turning the device off and on again last night to no avail.
I have now moved the save and load methods from the application class to the activity where I complete the input i.e. both load and save code is now in the same activity. I have tested this with both variations of the code and they both work. I get back what I save. I then moved all the code back to the Application class and it works; this leads me to believe that somehow with all the installing/uninstalling I somehow managed to get it working. Point is: the code is correct - if it does not work the device and/or settings are probably to blame

I have the same problem, and i suffered from it for a while , finally i found the solution ,
and it is so easy , just pass the direct reference of the activity , and do not use any general context
public SessionManagment(Activity mContextActivity){
// this.contextActivity = mContext;
sharedPrefSession = mContextActivity.getSharedPreferences(
Constants.SHARED_PREFERANCES_LIGHT_TIGER_SESSION_FILE_NAME,
Context.MODE_PRIVATE);
}//enden constructor
the code above is the constructor of the class that i have written for session management , and
and when i call it in the code in the main ActivityFramgment in a AsyncTask i call it like this
SessionManagment sessionManagment = new SessionManagment(referanct2thisActivity);
where referanct2thisActivity is defined in "onCreate" function of fragment activity like this
referanct2thisActivity = this;
hope that will help others in the future