Develop Reference

Android - Security On Saving Data

I wanna save a user's score that is retrieved from a server, locally, in order to reduce number of calls to the server.
However if I use SharedPreferences, it could be easily edited by the user. If I use a local database, it could also be changed if user has root access.
So is there any way to safely store data? Should I encode it?
Note that I can't check if local score equals server score, because it may be modified by the app.

A better way to enforce security while saving data in either to save it on your server and enforce security there. But, if you want it to be saved on local; then encrypt them and save them.
For sqlite encryption; https://guardianproject.info/code/sqlcipher/
is great. (link to project)
For saving files or blob data https://github.com/facebook/conceal may
help.
For saving simple key-value pairs in sharedprefs -
https://github.com/scottyab/AESCrypt-Android is useful
It is not good to save sensitive data such as user's personal information and/or passwords in shared preferences or raw sqlite database without encryption.

How to keep shared preference data after clearing the cache of application from settings

I have observed that when i click on clear cache in settings>apps>particular app,
Shared preference data get deleted.
how to keep shared preference data even if i clear the clear the cache? is it possible? if possible means give idea about that

It is worth noting that there are three types of data clearing in Android, of which your application has no control over:
Clear Data
Clear Cache
Clear Defaults
The only way to have persistent data is to use the SD card, but again, users won't like to have the data on their card after the app is uninstalled or users can un-mount the SD card.
Or you can consider:
Storing the data on a remote server with some kind of authentication to retrieve it
Using Data Backup service

Shared preferences is generally used to store temporary information on a user's device. So generally it holds temporary information/data.
To store data that will survive the 'Clear Cache' action, you can store information in an sqllite database.
To do this, you need to implement a content provider that will encapsulate access to the sqllite database, it will help you store and retrieve data that will not be deleted when the cache is cleared. find more information on how to create a content provider here : http://developer.android.com/training/basics/data-storage/databases.html

Sqlite Database deleted when I clear data from Application

I have created Sqlite database in app. when I clear data from settings->applications->manage applications the Sqlite db removed. any suggestions to keep sqlite database as it is.

When you press Clear Data from the Android application manager its supposed to remove everything related to the app such as preferences, databases, caches etc the only thing that gets left is the app so when you re-launch it behaves as if it was just installed.
If you want to allow the user to clear the data but keep the database then there should be an option in the menu that removes the shared preferences but doesn't do anything with the database.
Hope this helps.

Android's SQLite is intented for local app data storage. When you opt to wipe your app's data, this data is wiped (as expected).
If you want to persist DB data, look into external storage (eg. the late Parse.com, or MS's Azure). You'll be making network calls, your local data will still be wiped, and you'll need to have a way to link your app back up with the external data post-local-wipe (eg. logging in) but your external data will survive an app data clear.
The "linking up" part can be mitigated as well depending on your use case, eg. Google Play Games' data services is tied to your Google Play id and will resync after an app wipe.

Why would you want to keep the data when the user wants to clear everything.
It is not suggested you keep the db.
I would suggest you use the sd card to store images/text files with the adequate permission from the user.

Difference between shared preference and sqlite

I know this topic has been discussed before on Stack Overflow. But there are still some things that are not clear when I read previous posts about it. So here they are:
I know that we use shared preference for small datasets and sqlite for large data manipulation, so if we just want to save a username and password should we use shared preferences?
Won't shared preferences be lost when user uninstalls the app? For example I download an app called abc and save my username and password. Then I uninstall this app from one phone and try to access it from other phone using the same username and password. Will this be saved using shared preferences or the data be lost?
What are the main reason we use one over the other beside large and small datasets?

You can think of the difference between shared preferences and an SQLite database in terms of data size but that isn't entirely accurate. A better way to think of it is in terms of the structure of the data you want to store.
Shared preferences can only store key-value pairings whilst an SQLite database is much more flexible. So shared preferences are particularly useful for storing user preferences, e.g. should the app display notifications etc. Whilst an SQLite database is useful for just about anything.
Both data sources are local but something you should be aware of is the ability to backup your application data to cloud storage that is linked to the user's Google account. This makes it much easier for your users to change devices and for their applications to easily transfer to the new device. For more info take a look here.

In the situation you described about you will lose the user name and password in both situations. The data is stored on the phone, when you uninstall the application, the data that some with it will also be lost. The user will have to re-enter this information.
You can save the user name and pass in either the shared Preferences or a DB, that is personal preference. Just make sure you lock either down, i.e. don't share the DB or Shared Preferences that you keep this information in.
As for the difference... shared Preferences should hold well... shared Preferences... here is an example:
If I create an option to change the background color, I will store all available options in a DB that can be loaded into a adapter view for the user to choose from. But I will store the color that they have selected in the Shared Preferences. This way when the application load I can get the Shared Preference value of the background color that should be used.

SharedPreferences is used for just that, storing user preferences shared application-wide. You can use it, for example, to store a user's username, or perhaps some options he or she has configured in your app in which you want to remember.
SQLite is a relational database. It's used to store your application's data, not preferences or configuration information.
Both are stored locally on the device.

1.SharedPreferences stores only Boolean, int, float, long, String five kinds of simple data types, such as can not be conditional query. So, whether SharedPreferences data storage operation is how simple it can only be a supplement of storage, but can not completely replace other data such as the SQLite database is stored.
2.SharedPreferences based on the XML file to store key-value key used to store configuration information(mainly user preference for your application).
3.Sharedprefrece just like cookies in web which store some basic information at client side.

both store their data locally, so uninstalling the app will delete both. other than that, SharedPreferences is easier to program, and you're right about the data amounts.

In general, shared preferences should be used if you want to allow your user to directly manipulate certain data fields. Shared preferences are basically user preferences; if you would like the user to reconfigure the app to behave in different ways, you should expose that functionality as a shared preference. On the other hand, the SQLite database should be used if you want to limit the visibility of the data to just the application, if you want a stronger guarantee that the data be persistent, and if you want the application to behave independently of what is stored in the database. Of course, you can use both in one application.
Shared preferences and the database are part of local data that the application stores. If you uninstall the application, both of the data stores will be removed.

How to save data to internal storage in android app persistently between updates?

My android app saves user information as serialized objects in a ".ser" file that's saved to internal storage.
The data can be stored and retrieved and written just fine but whenever the user installs an update to the app, all the data is erased.
I assume the file is deleted upon installation of an update.
My question is: how do I save data to internal storage without it getting deleted when users install updates?
Do I have to use a different method, like SharedPreferences or SQLite?
or can my FileOutputStream save persistently through updates?

If you're worried about it getting deleted on internal memory, why not write to the ext?

Hello Boron I've been using SharedPreferences for the purpose you are explaining. I don't think SQLite would be preferable because you might want to save the images and large information like Bio of the user.
I store all my user data in shared preference and I am almost positive that the data persists even on updating the application. This should solve your problem.
When you have to store the images I would suggest you to convert the image to base 64 or some string and store in SharedPreferences this reduces the chances of deleting of the image from mobile by user accidentally.
Happy Coding