I'm trying to understand how applications are storing data without the use of a login system. Example, an android app starts you with 500 coins and you use some of them. You have not logged in at all and you delete the 'app data' in settings and uninstall and reinstall. The app still knows you only have 450 coins left for example. The app requires internet connection so I'm assuming they are storing the info on their server. If so, how are they uniquely identifying your device? In my reading so far it seems there is no full-proof way to uniquely identify a device every time.
I'm asking because I'm going to be working on an app where I don't want to require a login but I also don't want the player to simply reinstall and get to start over. So, my question is how does everyone handle this situation to work for both iOS and android?
Google offers Firebase, which is used for notifications, but makes use of a unique identifier for an application instance on a device (both on iOS and Android), they could be using this.
There are some more providers that offer a similar service (for example OneSignal).
Reference: https://firebase.google.com/
Related
I do not want the data that is fed into the android app by the user to go away when the app is uninstalled or the device is lost/disposed. What I necessarily want is - data has to be tied to a user account rather than a device where the user can install the app from any other android device by logging into his account using his login credentials and see all the data that was entered in the past from an old/other device. Please suggest a storage option that would best fit for this scenario.
This is a very generic question and I think someone might vote to close it but I will still attempt a generic answer.
Essentially you want the data saved on some external data storage (not on device). So the obvious thing is a server. You will need to set up a machine and run a server on it which can communicate with your app. Also you will need to have unique id for each user (authentication?) which will link user-data with the user, so that if user uninstalls and reinstalls your app, the app can then download the user's data from the server to the mobile device on which the app is running.
For the server you can look at Amazon AWS, Google App Engine, Heroku etc. You can set up a minimal server at one of these places, maybe set a DB there (SQL/ NoSQL) and get a unique URL so that the app can ping the server (so static IP obviously). Then your app can send network requests to your server fetch data for a user and save it to the app whenever the user wants it (say on reinstall, device change, monthly etc).
Hope this helps!
Google is working on Google Cloud Save as a simple way to save data to the cloud on an Android app. There is no backend programming needed.
It's in closed beta now, so that's not super helpful right away, but it might open up to the public soon.
i need to know how can i secure my app to make a close beta?
i want to send my app to some people so that they can test it. but i dont want them to share the .apk with other people and just use it some days. so i need to implement some kind of trial/beta mode.
i need something, that the app e.g. only runs 7 days or so. how to do this?
There are a few ways to ensure security:
Get a server, and have a server side authentication based on a unique device ID, like an IMEI or MAC address. Any device which does not belong to your testers will not be listed on your server, and you can stop the app from running.
If possible, have each person come to you and install the apk yourself, instead of mailing it to them
Create a trial system. Store the date on which the person first accessed your app from the device, and stop letting him use it n days later. If you store this on a server along with the unique ID, it'll be safer, as if it is stored in the shared preferences or something, the user could get around it by clearing the data or uninstalling and reinstalling the app.
Obfuscate your code using a tool like ProGuard. This will add an extra layer of security incase someone decompiles your app
Note that these are only a few suggestions, and none of them are 100% secure. AFAIK, there is no way to ensure 100% security, short having having the devices locked in a lead room, and letting in the testers one at a time. And there is a way to get around that too, I bet.
Use hockeyapp, there's nothing easier to distribute your app to a closed group of people.
The problem:
In one of my Android apps, users should be allowed to make changes to text data on my server (via HTTP request) without being required to login or sign up.
In order to prevent spam and abuse of this function, I would like to identify a single installation of my app so that I can "ban" this installation. Of course, the user who is abusing my service could uninstall the app and download it again or something like that. But this is truly an obstacle and makes abusing the app more difficult.
So I have to find a way to identify an Android device or at least a single installation.
As one can read here or here the physical device ID of an Android phone is not a good solution. So what else could I do to achieve this?
My idea:
When the app is started for the first time, create an (almost) unique hash (maybe SHA-512) of the current timestamp and a huge random number. Then save this value on internal storage and always use it to identify this device or installation later (on HTTP requests).
What do you think of that solution? Are there any better approaches?
This is almost what the Android Developers Blog suggest, right? But are they really writing to the internal storage? They don't use openFileOutput() as suggested here.
And, at last, a question that is probably a bit stupid:
How can I use the code shown on the Android Developers Blog? Can I add that public class to my main activity .java file?
Thank you very much in advance! :)
In my current Android project, I use the Bluetooth mac id as the identifier because of what I read about the physical device ID not being reliable. Of course, my app is very specialized and REQUIRES bluetooth AND internet anyway, so this works.
Specifically I have a way of calling my web server from the phone, passing in the Bluetooth mac ID. I can check license status (for trials/expirations), where you might check against a ban method to see if that id is banned.
Since my application requires bluetooth, this worked perfectly for me since [mostly] all bluetooth mac id's should be unique.
Just an idea.
I am creating an app where the user does some things during a game, and these actions are logged in a SQLite-database. At the end of the game the app presents these logs through a screen, which are read by the game administrators (like, physically read by the game administrators watching the screen). Is there some ways for the contestants to manipulate the database, and if not, what security measures prevent them from doing this?
The database is stored under /data/data/your.applications.package/databases. Normally this location could only be access by the user the Android OS created for the app. No other user is able to access this location unless the device is rooted. Then any user can access any location on the phone and manipulate the data.
So if you want to prevent users from cheating you need some way to check if the values in the database are untouched. Perhaps you can store some kind of fingerprint on a server to check this.
Yes, you can do it programatically, as long as you are the developer. Here is the Android docs for SQLiteDatabase.
Here are some links for working with SQLiteDatabases programatically:
From Android docs
From a blog
From another blog
The SQLiteDatabase in an application should be 'sandboxed' to that specific application, meaning that no other application should be able to get to that data, as long as the developer didn't provide access to it with a ContentProvider. So to answer your final question, no, there should not be a way for contestants to manipulate the database, except in ways that the developer has already allowed.
Yes, users can examine and change the database when connected over USB via ADB: http://developer.android.com/guide/developing/tools/adb.html#shellcommands
Update:
This only works on rooted devices or official Google Dev devices: Why do I get access denied to data folder when using adb?
Still, this would allow users to access database and change game results. So you can not rely on databse not being accessible..
Unless you issue the devices to users and you carefully watch what they do with them, to be secure against anyone determined, you need to digitally sign the entries in the database using a mechanism hidden in strongly obfuscated application code. And even that only makes it harder.
Note that using a server does not help unless a key part of the game logic itself is implemented in the server; if the user knows how to fake your signing mechanism to write fake database entries, they can also send fake reports to your server.
You can use Proguard to obfuscate your code.
Also have the database be unique with a particular id according to the device id with some sort of server callback, to validate the database.
I am just starting on Android development. To my nascent knowledge, it seems that anybody can grab any personal info and modify it or phone it home. Like with ContactContentProvider. I know these(permissions) have to be specifically declared in application manifest and the user would be presented with this info during installation. But still how would you you know the application handling your private data is not going to go rouge on it?
Example:
Suppose I create an app with internet
and contact-reading permissions. It
claims that it will backup contacts on
a server specified by user. While
secretly it also copies them to your
own server.
It's no different than you developing an app that does it that runs on a PC, or something that uses your gmail login to see if there's others you know on the same site.
It's all about trust. Also the Apple approval process doesn't safeguard against any of this if you hide it and when found out malicious apps can be killed & uninstalled instantly.