Hi all: I need to know if there is any way to make Android persistent data that the user can not delete, because if I use SharedPreferences or databases, it is possible that the user can delete all data from the Android menu, Settings - > applications -> Manage Applications -> "application name" -> Clear Data.
If I keep in the external memory also exist the possibility that the user delete or change memory device.
As always, thank you very much and sorry for my English.
Please check out Swarm's Cloud Data system. It provides a system extremely simple API (very similar to SharedPreferences) for set/get operations. Everything is saved to the cloud, and persists per user account.
This is not possible, your application does not have access to such kind of functionality. The only option you have... is storing data into a remote server.
Store it on your cloud app server.
I agree, If you do not want your users to be able to erase your data, you need to store it outside of the device, and access it via the internet.
You can use your own server for this, alternatively, I have used the Skiller SDK for my multiplayer game and noticed that they provide a simple data storage functionality (which frankly, i didn't use) but it seems like it would answers your needs.
Good luck.
Related
I use the ObjectBox in my kotlin project. Users can erase the database by clearing the application Data from the Android settings.
I want to prevent database removal or change ObjectBox Store mode to SQLite!
thanks
In case you want to make user data persistent you definitely should save and check DB copy on your server.
First of all, as you probably know, this is "normal" behavior on Android. When you delete an app's data, you have to start from scratch. E.g. all local data lost and log-in again etc. I'd guess that 0.01% of users would actually know about it and actually do that.
Anyway, yes, the question is if you want to extend data scope to cloud/server... That's a different topic though. ObjectBox will offer data synchronization later this year.
Alternatively, there's also Android's backup function: https://developer.android.com/guide/topics/data/autobackup.html
I'm trying understand which is the best way to store sensitive data in Android. In my app i want to insert a classic in-app-purchase model with some coins. My problem is that i'm not sure how to implement this correctly.
The initial idea was to simply use my firebase database, store the number of coins for every user and fetch the data every time the app is launched. This way I can easily detect some inappropriate usage but my users are forced to use the internet to play.
Looking at the documentations, I found this. Can this be a solution? Can I save in the internal storage the number of coins, maybe with some type of encryption, to avoid root user to modify the file? Then when the internet is on I can double-check the local stored variable with the the one in the database.
Thanks
Not an "easy" task.
Technically, you can create a SecretKey and encrypt data, so no normal user will be able to reproduce. If your concern are root users, You are kind of out of luck, as he can hook into your app while it is reading/writing that value.
But to store it online is not a solution in itself. You have to answer questions like: "Do you trust any server input"?
"How to make sure just paid coins are added"?
Have you had a look at Google Play billing?
it provides safe way's to determine if somebody paid or not.
This will require to be online.
If you have a sensitive data to save you can use sqlcipher database .. the good with it that it encrypt the database file itself so even the root user be able to get the database file he will not be able to decrypt it if you use a secured encryption algorithm.
you can find more about sqlcipher here
https://www.zetetic.net/sqlcipher/sqlcipher-for-android/
Since I assume you will grant your app a reading permission of your sensitive data and all writing processes should be reserved server-side, I would not recommend storing the data in a file on a phone, though every encryption can potentially be passed.
Maybe you already have heard about SharedPreferences, which is a good solution for let's say Preferences the user selects and that only shall affect his particular installation of your app. The difference is, that values are not stored in an external file, so not that easy accessible, BUT your app needs to write them, due only the app can access them directly (also your server can't). I am not aware of how your sensitive data is used at all but I would also not use SharedPreferences since it's injective-prone.
Official docs about SharedPreferences.
If security of your data (speaking of Confidentiality, Integrity, Authentication) is your No. 1 priority, simply don't store your sensitive data on the users device. Focus more on creating an API that ensures secure and performant passing of the relevant bits of your sensitive data. Hope this helps to give you a view of which way to go and which to walk around.
I know about asyncStorage. That's not what i need. I want to save some data locally, so if app will be completely deleted and installed again, it should gain access to the stored data. AsyncStorage data being removed along with app itself.
I think you must use a FileSystem to save files in phone storage. Take a look at this library to handle files: https://github.com/johanneslumpe/react-native-fs. Hope it helps.
I dont think anything an app creates can exist after app deletion. If you think about it, why would you want disk space being used up by an app you deleted. Only option I can think of is storing in the cloud: Google Drive, DropBox, etc. or a server you run and user data connected to an account system.
My experience is with iOS, maybe Android has some option for what you want.
Is is possible to restrict user, from accessing any application data, like SQLite db file, shared pref. file..etc. I have restricted it to certain level. But still, user can access these file, if he boots the device as root user, or super user.
What needs to be done, to restrict the user from accessing my secure application data?
I saw a blog on this somewhere (I'll get the link if I can find it), but basically, there's nothing you can do. The blog author says that whatever data you put on a user's device is now theirs, and if they want at it bad enough, they're going to get it. A root user has access to everything on the device. That's what rooting is supposed to do.
The only way to really protect your data is to pull it from a secured server and not cache it, which is the only way you should be doing it, if you want to keep something from your user.
Found the blog post, suitably titled, "It's the User's Data, Dammit."
http://commonsware.com/blog/2012/05/01/its-the-users-data-dammit.html
You should really subscribe to this guy's blog. He's got some good stuff on there. (No, I'm not plugging. I wish I could be this guy.)
If the phone is rooted there is little you can do to stop access to files stored on the device.
The best you can do is encrypt the data written to the file or the fields in the database using a key that the user has to enter every time they start the app.
So I have an application that logs medical data entered by user. I need to add functionality for backing up and restoring that data in case user changes their Android phone OR switches to and iPhone (there is an iPhone version of this app, which I have limited visibility into).
The data is currently stored inside a SQLite DB on the device.
I need help figuring out cleanest/easiest way to do this. So far I am thinking about these options:
add UI to email DB file to + UI to accept a DB file and copy it over current DB. Seems hacky.
create a web service which will store user data and sync on the background. I would need to build sync process and introduce some kind of account system. This seems like quite a bit of work, though likely the most flexible solution in the long run.
switch to Google Calendar as my data storage (data is essentially a set of event entries anyway). This would probably be most seamless, but iPhone option is out of the window.
Are there other pros/cons to these options that I am missing? Or perhaps there are some standard solutions to this?
Option #1 is filled with a lot of problems. Sideloading databases from files coming from external sources is no easy task. I wouldn't recommend it.
Option #3 should be a possibility - but it require the user to set up a Google account which (imho) shouldn't be required. Furthermore the addition of a new calendar and/or a lot of events wouldn't be many users favorite feature. Personally I would hate it.
The second option seems like to most promising. You can build it as simple as you like. You could even make it require only a simple identification code for backing up - or only provide "live" synchronization. It is true that you need some sort of server and accounting system - but these things come as standards and servers are cheap. This option would be the one of my choice.