I'm using PreferenceActivity to let Android handle some persistent key/value pairs for my app.
According to the Android Preference docs :
Note that saved preferences are accessible only to the application that created them.
However, when further researching the security and permissions aspect of preferences, I come across questions like this one:
Android: Retrieving shared preferences of other application
where some users are saying that preferences may be made world readable and world writeable and that they are successfully able to access them across applications.
So my question is:
Are preferences inalienably inaccessible across applications or do I have to take precautions to make them so?
Note: I'm am not trying to use preferences to share data among apps. Quite the opposite - I want to know that any preferences my users set are secure from inspection/alteration by other apps.
From the above answers and comments, it looks to me like the android developer docs on this subject are a bit misleading.
I even found another place where the developer docs state explicitly that settings are not accessible across apps:
(Note that it is not possible to share settings data across application packages -- for that you will need a content provider.)
Reference to the above quote it here: http://developer.android.com/reference/android/app/Activity.html#SavingPersistentState
But the responses from #shruti and #raman-bhatia (thanks guys!) both support the fact that settings can be configured to be shareable across apps, as does the SO query I referenced in the question.
The clincher was finding this SO query: Difference between getDefaultSharedPreferences and getSharedPreferences which shows how it the default shared preferences file is initially configured as private.
Thanks to all. The answer is that the docs are misleading in that preferences can be coerced to being shareable across apps, but that PreferenceActivity will by default create a secure shared preferences file visible only to the components of the app from which originated.
There are modes associated with the shared preferences that you get to define when you create them.
For example, you can make them as "World Readable" or "World Writable" if you want the rest of the applications on your device to be aware of them.
You can thus use your own flags to adjust the transparency of the shared preferences that you create
Related
I'm developing a library which can be used in multiple applications. The library contains a PreferenceScreen to set certain settings, which often only need to be set once.
I want to make sure the settings are shared (and able to be edited) across applications using my library and for that, I think I should set the SharedPreferences to world writable.
However PreferenceScreen seems to use the default shared preferences and although the packagename will be the same across, the mode is set to private.
How can I set the share mode for PreferenceScreen to world writable?
Isn't strings.xml is supposed to be used as a text storage for easing the translation of text in the app to other languages?
For example - Facebook app id according to facebook manuals is advised to be stored in strings.xml.
It means that if I want to share this file with 3-th parties for translation - I will have to manually remove all ids by myself, or share those ids with 3-th parties.
Isn't strings.xml is supposed to be used as a text storage for easing the translation of text in the app to other languages?
No. It's string storage for any kind of strings. Majority of use is localization related but it is perfectly fine to have anything that is string there like API keys, tokens whatever.
Please be aware that you are not limited to just strings.xml file. You can have as many *.xml files holding string resources as you like (so it's quite common to split localization per class/functional module and keep it in separate xml file).
You can create more then one strings.xml you could name it appids.xml and store all your ids inside this file. It is common software design pardigm to seperate data from code, so you won't just use a String constant for your id.
For Android best practices, Google is the source to go, for example they propose the usage of an appids.xml file here: Getting started with Play Games
Facebook might be using this simpler form of storing your id to make the tutorial easier to follow.
Basically it may happen that the ids that you're going to use inside your app may occur in multiple java class files. So by mistake there may be a chance that you mistype the id or secret key which will result in failure of result that you are expecting. As a good practice you should store such things in strings.xml which will help you minimizing the possibility of error in your result. Also if you change your id or key because of any reason then you might have to change that in each file where you've mentioned it. Instead of that if you just change it in strings.xml then it will automatically reflect at every instance where you've used it.
Going further, Android is open source. Thus any app that you create can be reverse engineered and all the code can be read. This leads to leakage of your id's and may be some secret keys for any api that you've used inside your app.
Usage of Shared Preferences in android library projects is allowed?I am trying to work on rating bar but i am not sure whether i can use Shared preferences to write that.
If you have a Context, supplied to you by the app that is using your library, you can use SharedPreferences.
However, you need to be a bit careful to ensure that you do not accidentally try using the same keys as the app might use. You might consider using a unique SharedPreferences file, rather than getDefaultSharedPreferences().
I just have some basic questions about the way shared preferences work with Android:
1) Are the preference files part of the application itself, or are they stored elsewhere on the user's phone?
2) If I have created and modified preference files in the course of testing my app, will those preferences be the default settings for users, or do the users start with a clean slate?
1) The preferences are stored on the user's phone, of course.
2) If you want defaults, you need to program them yourself, just setting the preferences in your emulator is not going to affect anybody installing your application.
I have some configuration I want to save it in my Android application and read it whenever I need , for instance, the server URL that it should try to access like that.
Is there any similar mechanism like web.config in ASP.NET available in Android?
A central configuration file that can be set up manually and then read by the application? Any help would be appreciated!
We use a .properties file in assets folder. It works out very well for us as we support multiple carriers with this, write to it (in case some values, sent from server, need to change. This is done at app start time, thus making our code configurable from server).
You can throw things like that into your strings.xml file. But, since you can't actually modify these values in real-time (since it's a distributed application rather than running on a server), throwing it into a constants class is quite acceptable.
Use Shared Preferences.
Here's a link Shared Preferences
You can use sq lite database files for it. You have a native API to read and write those and on top of that a command line tool.
If you want to create an XML file instead, then it's no different than any other xml file (unless you are thinking about the Shared Preferences, which use an xml format to save the data, but I believe it's not the best API for your application).
I was stumped on this too, but came across Managed Configurations in the Android documentation.
Managed configurations, previously known as application restrictions, allow the enterprise administrator to remotely specify settings for apps. This capability is particularly useful for enterprise-approved apps deployed to a managed profile.
It allows you to set a default value in case you rather not getting into the enterprise admistration business but leaves that option open for the future.
There is a caveat. This only works if your app is registered for EMM. Otherwise you will retrieve an empty map of restrictions.