24

I've defined an instance of SharedPreferences that used on multi-process mode.

public class Prefs {

    private static SharedPreferences prefs;
    private static SharedPreferences.Editor editor;

    private static void init(Context context) {

        prefs = context.getSharedPreferences("alaki",
                Context.MODE_MULTI_PROCESS);
        editor = prefs.edit();
    }

// static methods to set and get preferences
}

Now I'm using this class on a service with separate process and also in my main application process in static way.
Everything is going well, but sometimes all stored data on SharedPreferences instance removed!
How can I solve this problem?

Edit: Finally I've solved my problem using by IPC.

Mousa Jafari
  • 677
  • 1
  • 6
  • 21

8 Answers8

39

There is currently no way of safely accessing SharedPreferences on multiple processes, as described in its documentation.

Note: This class does not support use across multiple processes.

After testing a lot with MODE_MULTI_PROCESS, I've three trials to share:

1- Initialize the SharedPreferences once in each process and use it multiple times.

The problem: The values are not reflected in each process as expected. So each process has its own value of the SharedPreferences.

2- Initialize the SharedPreferences in each put or get.

This actually works and the value now is interchangeable between processes.

The problem: sometimes after aggressively accessing the sharedpref, the shared preferences file got deleted with all its content, as described in this issue, and I get this warning in the log:

W/FileUtils﹕ Failed to chmod(/data/data/com.hegazy.multiprocesssharedpref/shared_prefs/myprefs.xml): android.system.ErrnoException: chmod failed: ENOENT (No such file or directory)

You can find why this happens in the issue.

3- Use synchronization to lock the methods that put and get values in the SharedPreferences.

This is completely wrong; synchronization doesn't work across processes. The SharedPreferences is actually using synchronization in its implementation, but that only ensures thread safety, not process safety. This is described very well here.

Ahmed Hegazy
  • 12,395
  • 5
  • 41
  • 64
  • Thanks for this well-researched answer! I found it a bit confusing to read, so I edited it to tidy up the English so it's easier to follow. Hopefully I've preserved your original meaning. – Sam Jul 04 '15 at 00:58
  • @AhmedHegazy Your answer is quite risky, I think you should consider send the value or object to the service or wise every time that stored value or object change in the preference you send a message to the service with the updated value. That's what I do, I just read or store the values in the preference from one of the two process. – AXSM Aug 10 '16 at 22:51
  • @AlexSanchez Sorry, that what the answer is about. It says that you can't access the shared pref from multiple processes. – Ahmed Hegazy Aug 19 '16 at 15:35
  • The sentence "This will be added later" has now been removed. – mhsmith Jan 31 '18 at 13:43
  • @mhsmith oh! I was not waiting though :D – Ahmed Hegazy Jan 31 '18 at 17:55
  • initializing the sharedorefrences everytime does the job, but does this lead to any performance problems ? – Tamim Attafi Mar 13 '19 at 17:35
  • @TamimProduction yeah as written above it might produce an issue after heavily accessing the sharedpref – Ahmed Hegazy Mar 13 '19 at 21:55
  • @AhmedHegazy in my case i'm using it to store currently running and pending tasks and display a disabled button so the user doesn't duplicate tasks, i use it once on task added to queue , and once on task finish, do you think that's a dirty approach ? – Tamim Attafi Mar 14 '19 at 09:35
8

SharedPreferences itself is not process-safe. That's probably why SharedPreferences documentation says

Note: currently this class does not support use across multiple processes. This will be added later.

VikramV
  • 1,111
  • 2
  • 13
  • 31
3

I've worked around this by combining:

  • Providing each process mutually-exclusive access to the SharedPreferences file (such as by using a socket-based locking mechanism)
  • Re-initialising the SharedPreferences with the MODE_MULTI_PROCESS flag every time you want to use it to bypass in-memory caching

This seems to work OK, but it hasn't been thoroughly tested in the real world, so I don't know if it's perfectly reliable.

You can see a working example I wrote here.

Warning: Looks like MODE_MULTI_PROCESS has been deprecated in Android M. It might stop working in the future.

Community
  • 1
  • 1
Sam
  • 40,644
  • 36
  • 176
  • 219
2

Using the commit() method store the changes in persistent storage, hence it is slow and would make conflict across multiple call from other processes.

However there is an alternative to this method, you should call the apply() method, this method stores the changes in memory and then in disk storage asynchronously, so it is more reliable.

M. Reza Nasirloo
  • 16,434
  • 2
  • 29
  • 41
  • 4
    Why do you think asynchronously writing the preferences file will reduce clashes with other processes? I just double-checked the `SharedPreferencesImpl` source code, and they both use the same code (`enqueueDiskWrite`) to write the preferences file. – Sam Jul 09 '15 at 13:13
2

Use a Content Provider which uses SharedPreferences. Example see here: https://github.com/hamsterksu/MultiprocessPreferences

Highriser
  • 212
  • 2
  • 14
  • I've been using this technique in production for quite a while now. It generally works but also has various occasional issues that appear to be bugs in Android related to content providers. – Sam Oct 01 '17 at 11:33
  • It will work but will cause some ANRs. – Shubham AgaRwal May 03 '23 at 07:01
1

recalls that the use of context objects as static field, you have the risk of leakage of context because not declare the object in the application class

public class CustomApplication extends Application{
     private Prefs prefs;

     public void onCreate(){
          prefs = new Prefs(this);
     }

     public Prefs getPrefs(){
        return prefs;
     }
}

From any context you can get the prefs

   ((MyApplication)context.getApplicationContext()).getPrefs();
0
 public static int getValore(Context ctx, String contenitore,  String chiave, int valore){
    try {
        SharedPreferences sh = ctx.getApplicationContext()
                .getSharedPreferences(contenitore, Context.MODE_MULTI_PROCESS);
        //SharedPreferences.Editor editor = sh.edit();
        return sh.getInt(chiave, valore);
    }catch (Exception ex){
        return valore;
    }
}
Daniela
  • 1
  • 1
-2

If two processes write data to SharedPreferences, then it might possible all SharedPreferences are reset to default values.

Also you can try to call clear() on the editor before storing val

SharedPreferences.Editor sp = settings.edit();
sp.clear();
sp.putString("Name", "YourName");
sp.commit();
PPD
  • 5,660
  • 12
  • 52
  • 86