Develop Reference

How to detect a user after reinstalling the app

I am creating an iOS and Android App and I want to create a screen where the player can start with a guest account or can connect his account with our own accountsystem.
But my question is: Can I detect a user after the app was uninstalled and installed again?
I know that there is something like the vendor. But this will change.
I know that other apps also can do this.

With the user's permission- have them log into an account. Or provide you with their google of facebook account info. So far as hardware ids, those are discouraged and actively being removed to prevent people from the API to prevent this.
Also remember- that unless the user logs in with an account, you don't really know whether it is the same person. You could know its the same phone, but you don't know if he gave it to his kid sister to play on. Or sold it when he got a new one, and now you've given the new owner access to someone else's account. Also, if you rely on hardware ids you won't know its me when I buy a new phone and download it on that.
So yeah- either have him log in with a username and password, or use a 3rd party signon mechanism like Google or Facebook.

For iOS, there is a recommended approach to do that: by using the DeviceCheck framework. The idea here is that it allows you to persist 2 bits of data across app installations on each device. You can set the first bit to 1 if the user has already installed the app or 0 otherwise. And use the second bit, for example, to check if the user has signed in or not.
The official documentation is pretty good, please check it out.
The downside of this approach is that you will also have to do some work on the backend side.
UPDATE:
If you specifically want to detect the account, there is no reliable approach. One of the options is to use identifierForVendor or generate some kind of device fingerprint (for example, by combining the device model, timezone, locale, etc.), but of course, this will not work every time.
Uniquely identifying a device is a security leak, and all platforms are putting serious restrictions on unique persistent identifiers because of privacy concerns.

recovering app data after reinstalling app

I have a Nexus 5x. I mistakenly removed Google Authenticator, and then re-installed it. all passwords are gone. Is there a way to restore it? from my understanding, they are not backed by Google. I would like to know if there is a way to restore the data from the phone itself. Thank you!
edit:
I found this tool:
https://github.com/dchapkine/extract-google-authenticator-credentials
which allows to withdraw the passwords, unfortunately, it requires the device to be rooted, a process that wipes the data. Is there a way to circumvent this?

By passwords I'm assuming you mean the shortly generated 6 digit codes?
No, you can't restore those. This is where having those 2FA backup keys would come handy. You would need to login using those, turn off 2FA, and turn it back on again.
It's also possible to contact support of those specific websites and provide info of accounts to prove ownership.

Strategy for selectively enabling features in a mobile application

Assuming an application that has no login, how can one go about allowing some of its user access to activate 'hidden' features.
An example I recently came across is the need for some users to see a different version of the data feed the app is using (official feed vs editor feed which is being modified/approved)
In android, I assume that we could just point those user to downloading a specific file and test for that file presence in the app but I dont believe this approach can be used on iOS (sandbox).
The approaches I came up with:
Hide an activator in the UI: specific touches/gestures, invisible button and the like
Make the user visit a site which sets a cookie when on a specific page and test for that cookie's value in the app to enable features.
Did someone came up with a more elegant solution?

You can try any AB testing tool like Optimizely , Apptimize, Taplytics or MixPanel
They will help you to try new features by enabling them to only a group of users. Also you can set goals to each variant so you can compare how they perform.

Create a settings bundle. Then the user can just go into the Settings app to switch your 'hidden' behaviour on and off.

In iOS you can register an association between your app and a file extension. Then if you send an iOS user an email containing an attachment with this file extension, iOS will open your app and you'll have access to the file. You could save to the sandbox from there.

Just Like In-app purchases, when user completes a purchase some of the features in application gets unlocked.
I think best approach would be to have data maintained on your server end, the users vs features and in splash screen you get the response from server which of the application's feature are enabled for this user using a service call.
Obviously you must be needing some kind of business logic to implement the flow of enabled features in the application and that is totally up to you whether you use SharedPreferences of keep the information in txt or some other files.

How to restrict an application to only one user

I'm creating an Android application for a fantasy league as part of a college project. It's a paid application, and requires each download to be associated with only one team.
I'm confused as to how best go about it. If a user goes to settings and clears the data from there, all files, settings and databases would be deleted rendering a locally stored indicator for "The app has already run before and hence user is registered" as pointless.
Another option that had come to my mind was to store the IMEI no on a remote database (with SHA1 encryption to protect the data) but the problem with this is that, if a user loses or changes his phone, his further participation would be impossible. Additionally, users understandably don't like to share IMEI numbers and it's acceptable.
The best solution in my mind was to restrict usage of the app to the Google account that was used to download the application. With this, even a change of handsets would allow further participation of the user. However, I've not been able to find a way to obtain the Android Market account (only require E-mail) which resulted in the download.
So, my question is, how do I best go about with the problem that I face? Is there a way to get the Android Market username? Or is there a worthy alternative?

The server-side option is what you want, you can get a unique id from each phone and use that as your identifier.

Android - restrict access with password

I'm doing an android app and a want to restrict specific part of the app to a kind of administrator (that is only for this app).
The admin will push a button to access the admin part, and a password is required.
My question is about the way to store the password.
Do I have to store the password on like res/string or something?
do you have a better idea?
Thanks
I know that maybe some leaks are easy to do but my app is not something i'll spread, just for a signing app on an android smartphone, so no need to have big security, the password is just here to prevent from errors on the use of the app.

You need to create a hash function, which there is a great article about it at http://phpsec.org/articles/2005/password-hashing.html. Then you need to make sure that you store the password in the private data storage, for further protection. This should be sufficient for most purposes.

Considering that you are hardcoding the password in your app you might as well put it as plain text, since all it takes to lose all security is for one person to leak the password. Much easier then cracking a android .apk
If you want to be secure you need to confirm against a online account, and you need to be comparing hashes.

I think a more elegant way of doing this would be to use a AccountManager

Hold an encrypted version in the apps private directory.
When you come to enter the password the app can encrypt it and see if it matches the one in the file.
I think that's similar to how pin numbers work on credit cards.