I would like to know if it is possible to for some application other my own to change a preference value of my application. Also are the preferences been kept by android when the phone is turned off?
Is it safe to store some data(flags) on sharedpreferences in order to notify an activity for something?
When user clears the application data what exactly is erased, shared preferences data?
Is it preferred to use an internal private file to store secure data? Such as passwords?
Also I would like to be able to show a dialog when I detect a certain behavior, for this I have a monitoring service that has to notify the main activity about that. currently this is done through a callback method but I would like to maintain that state even if the application is killed or the phone reboots.
So I thought of setting a sharedpreference value (flag) and then on the oncreate method check if that flag exists. Also should I also check on the resume method?
Preferences (including SharedPreferences) are stored in files under your application's private data directory. No other application can read or write there, unless the phone has been rooted. This internal storage is flash-based and survives the phone being turned off... not much would work if it didn't. :)
As a general security principle you should never store a password. Secure systems store and compare password hashes, not the passwords themselves.
It's fine to store application state in preference data... personally I'd read it in onCreate() and thereafter write the value back to preferences either at the point it changes or in onPause().
Related
I tried to find an explanation about this issue but I couldn't find anything.
I have a remote service that is working in the background. This service reads some preferences from a SharedPreference.
The problem I have happens when I change a preference from a PreferenceActivity (the activity and the service belong to the same application and the same package). I change the preference and it is saved correctly, but as soon as the service reads that preference (the service never modifies the preferences, it only modifies some internal preferences that cannot be modified from the PreferenceActivity) the preference is 'resetted' and the service gets the resetted value.
This is happening with CheckBoxPreference. I don't know if this would happen with other kind of preferences as I don't have any of them.
After I change the preference I should restart the service? Or I need to 'refresh' the preferences in the service? Maybe this is a problem related with using HoloEverywhere?
To get the SharedPreference object I use the following code:
PreferenceManager.wrap(context, getSharedPreferencesName(context), Context.MODE_MULTI_PROCESS);
This code is specific for HoloEverywhere and it equals this:
context.getSharedPreferences(getSharedPreferencesName(context), Context.MODE_MULTI_PROCESS);
'getSharedPreferencesName()' just returns a string composed by "package.name_preferences".
Thank you.
I have a remote service that is working in the background.
Why did you make your service be remote?
I change the preference and it is saved correctly, but as soon as the service reads that preference (the service never modifies the preferences, it only modifies some internal preferences that cannot be modified from the PreferenceActivity) the preference is 'resetted' and the service gets the resetted value.
That's because you made your service remote. Simply remove the android:process attribute from your manifest, to have all your components run in the same process, and this problem will go away. Along the way, you will make the user happier, because you won't be consuming as much RAM and battery.
After I change the preference I should restart the service? Or I need to 'refresh' the preferences in the service?
If you truly have a legitimate reason for having a remote service -- and IMHO there's a greater chance that I will spontaneously regrow my hair -- you will need to restart the service's process, AFAIK. SharedPreferences are cached per process, and I don't know of a way to force Android to reload SharedPreferences from disk except by restarting the process.
Or, you could not have a remote service. The choice is yours.
I was wondering about how saving variables work by using SharedPreferences inside onStop() function. I already managed to save and retrieve variables from a "file".
My question is: lets say i have x layouts in my app, and need to use different file names in my SharedPreferences. What happens with all these files when the app is uninstalled? Do we waste our memory all the time? Is there a point where all these files are getting deleted?
SharedPreferences are deleted when the application is uninstalled.
Edit: For completeness, they'd also be deleted when one performs a "Clear data" operation from the Application Manager.
I would like to know where the bundle "outState" of the method onSaveInstanceState(Bundle outState) is stored.
Is it stored in memory or in the device storage?
I am concerned about the security of the data which is stored in the bundle.
To store data only for application lifetime (ie temporarily), use the onSaveInstanceState(Bundle) activity event
This data will only be held in memory until the application is closed, the data will be available any time that this activity starts within the current lifetime of the application.
Explanation: if data is stored here by activity A then the application shows a different activity or rotates the screen (hence closing A) and then returns to A the data can be retrieved to populate the controls. However if the application is closed and opened again the data will be gone and the controls will revert to their default values.
Example of use: storing text typed in by user and selections making up an order, blog entry, message, etc...
Note:
It’s important to notice that only the Activity is destroyed and recreated, not your whole application! An Android application can consist of many Activities, Services and ContentProviders! If the application is closed (for example by pressing the “Back” Button, then all values will be gone. savedInstaceState is only there to preserve data temporary when an Activity is destroyed/recreated, not the application itself.
If you want to preserve data permanently, you need to save it either as Preferences or in a ContentProvider/database.
Here is a detailed answer for where the outState Bundle data is saved:
...Bundles are an IPC mechanism, so it's not going to the filesystem. But now there's a P involved – which process is it? And what is that process doing with this data? And do I need to be worried about it? It turns out that these instance state bundles are stored in the Activity Manager service. This service is implemented under the package com.android.server.am in the Android source code. Recall that Activities are stacked one on top of another and that Android calls these stacks “Tasks”... Each of these tasks is represented internally with an object of class TaskRecord. This class contains an array of ActivityRecord objects, each of which manages the state of an Activity. ActivityRecord contains a member of type Bundle named icicle. This icicle-bundle is the saved instance state and it is actually stored in the memory space of the Activity Manager service.
Source: https://www.linkedin.com/pulse/android-onsaveinstancestate-bundle-secret-safe-daniel-pietsch/
The documentation has been updated and indicates precisely that the state is serialized to disk:
Saved instance state bundles persist both configuration changes and process death, but are limited by amount of storage and speed because onSavedInstanceState() serializes data to disk.
You can also found a table comparing the differents approches to preserving UI state
Source: https://developer.android.com/topic/libraries/architecture/saving-states
I don't think there's any way that any malicious background process can get at the bundle data of your application. It is not documented how Android treats the Bundle data. It may or may not be written to disk in the event that your app is cleaned, while backgrounded. However, given that we don't know whether or not this data is saved to disk, and if it is, given that we have no clue where, and almost certainly don't have read access to that part of the disk, I wouldn't worry about some third party process being able to recover that data.
Consequently I'm not clear what you might think the exposure is. Though I may be missing something.
However, in answer to your question, it is absolutely in memory while your app is alive, and if your app is backgrounded it may or may not be written somewhere hidden, but we dont' know because Google hasn't told us.
It's destroyed along with the application when the memory is collected.
My guess would be in memory, but the best way to protect your data would be not to trust the system and encrypt it. Never trust the client (in this case the client being the OS).
EDIT:
To be clear, I'm not saying encrypt the bundle. Rather I'm saying that any sensitive data should not be put into the bundle. If you must put custom data in the bundle, then encrypt it.
But ultimately you should keep as little sensitive data on the client as possible. This is the same reason a e-commerce site would only show the last 4 digits of a credit card.
My app uses SharedPreferences (with the help of a PreferenceActivity) to store all settings. But sometimes all settings are deleted and all values are set back to default. Mostly on Android 3.x tabs.
On normal smartphones there are no problems.
I have observed that all settings are deleted when the application process is killed by Android.
I noticed this because the notification icon is no longer displayed.
I also wonder why the process is killed on tablets and not on smartphones. On my smartphone the notification icon never disappears.
My app also has a service, the main process and the service both read and write settings to the SharedPreferences.
I've sometimes noticed that all settings are cleared once the service writes to the SharedPreferences. But it does not happen every time.
Any ideas?
I realize that the SharedPreferences should not be used by different processes, but it works on all smartphones without problems!
I found out the reason why the settings disappear:
If two processes write data to SharedPreferences, it can happen that all SharedPreferences are reset to default values.
In my case all settings are cleared when the service write the first data to SharedPreferences.
Now, the service provides only read access to the SharedPreferences. The settings that are accessed by both processes writing are stored in a database.
SharedPreferences usually work great and as you mentioned without any problem on smartphones. It should also work on tablets. However it would be best to use sqlite or backing your shared prefs on a server for each users id data loss is a problem.
I have had the same issue.
All values from shared preferences become default if one value occasionally written with key = null. This is possible when you creating new constants using Eclipse, which inits them with null by default, and then you forgot to go to the beginning of the class and change constant to some meaningful value.
If you continue using the app, read operation of shared preferences will return valid values.
But when context is changed(for example, when activity killed by android and recreated) all values from shared preferences will return default values(zeroes).
So check your shared preferences's keys!
I hope this answer will help someone.
I'm looking for storing some data in my app that needs to be wiped off when Factory reset is performed. Is SharedPreferences the right storage to use for this purpose?
Yes, they will be wiped off. Database will be wiped off as well. The only data that will persist is whatever you store on SD card
Android's backup service
allows you to copy your persistent application data to remote "cloud" storage, in order to provide a restore point for the application data and settings. If a user performs a factory reset or converts to a new Android-powered device, the system automatically restores your backup data when the application is re-installed. This way, your users don't need to reproduce their previous data or application settings.
Refer Data Backup, you will get the complete details