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.
Related
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.
I've written an app that uses Firebase (if that's relevant) and is targeted to users residing within a certain city (Strasbourg, France, in my case). Also, users will log into the app using an email address (Gmail or other). How can I make sure only people residing in Strasbourg install the app? I can't use private distribution, since I don't have a list of user email addresses and anyway they are not part of my organization. Ideally, I'd like to be able to offer the app on Google Play, rather than, say, uploading the app to Google Drive and then sending them a link when they request it.
I decided to abandon this idea because it would prevent people who are temporarily away from their home in Strasbourg from being able to download the app and that disadvantage would outweigh the benefit of keeping "outsiders" out of the app community.
I have an app that has in-app purchases where users can purchase set of videos and there are ten of these sets. Now, before they do this they have to sign up for this app using their personal e-mail (not necessarily their phone's primary e-mail).
Since they have to log in this app, I was planning that they get the right to open the app and the set of videos they purchased from whatever device they use.
Problem:
After thinking about this and since this app is only directed towards local audience, I am afraid that users will pass their accounts to each other and my customer number will decrease.
Solution I thought about:
I will put a message when the users buy the set of videos that says: "These videos will only be viewed from the device you download it on". Which means I will use certain flags to ensure that an account will download them once. So that if someone is to share an account s/he won't be able to download because they where already downloaded.
Question:
If I do like this then if the user uninstalls this app, s/he will lose all the videos they purchased. Thus, if they install it again, they will have to buy the set of videos again. I am not sure if professional apps let the users have what they purchased back if they reinstalled the app or not.
So, is there a way that I can still use the solution that I thought about and still have my users regain what they bought before they uninstalled the app? Or do you have a completely different suggestion that can solve my problem.
Account sharing is a big topic. Daily business for Netflix and Amazon.
I'm not a big fan of your solution because of all the restrictions. I would suggest following approach:
User signs up in your App
You create a unique ID on the device (GUID - https://developer.android.com/training/articles/user-data-ids)
You store this data on the database plus the GUID on the device
You can now verify that the user has valid access.
I would suggest adding another field like max_guids=2. So that if the user looses the device he can still access his data (yes, this also means 1 single device sharing is possible, therefore you can detect irregularity with login sessions and ban the user).
Sounds better?
I have an Android application I am working on in which the client wants a promotional page in which the first 100 people who download the app get a 10% discount on their order. From what I researched I understand that Google Play doesn't have a very user-friendly way to do this, but for my work-around I wanted to have a "not used coupon" and a "used coupon" image that the waitress could see and type in a short verification code to permanently change the coupon on the app to "used."
From what I read I can use the SharedPreferences to make this happen, but what if the person uninstalls the application and then reinstalls it to get a fresh coupon? Is there anyway in Android to prevent this from happening?
There's actually a very simple API for backing up and a specific helper for SharedPreferences. You don't need to have your own server for this.
http://developer.android.com/training/cloudsync/backupapi.html
footnote:
Never use device ID. Use the account ID to identify the user and the ANDROID_ID to identify the device. If you use IMEI, MAC, serial number or anything that stays the same when device ownership changes, you're gonna have a bad time.
I would like to use in-app billing in my android application (instead of creation 2 versions of application - free and pro). If user paid, then additional options in Preferences should be available.
My application synchronizes data with website (not my).
Each time synchronization happens, I would like to check if user paid or not.
How should I do it?
I think the easiest means for you would be to use Managed purchase. More on it is at http://developer.android.com/guide/market/billing/billing_admin.html#billing-purchase-type
The "manage by user account" purchase
type is useful if you are selling
items such as game levels or
application features. These items are
not transient and usually need to be
restored whenever a user reinstalls
your application, wipes the data on
their device, or installs your
application on a new device.
Update: website and API updated refer this now https://developer.android.com/google/play/billing/api.html
There are to many ways to do that, i will try and give you some of the most used
what about user accounts? can your application support users? if it does, its practically solved with 1 user per 1 account. just add a flag to your DB for each user. this is the most secure way, its very easy to know if someone is stealing from you thats why all MMO's (like WOW) use this type of check. you can easily know if theres more then one user on an account as well
the downside is that it requires more processing and some support is case someone's account gets stolen or other user support of that kind.
you can save a sort of key inside your application. and some other key on the server. if the key matches (either 1 to 1 or after some manipulation) then you have yourself a paid user, other you dont.when someone buys the application then change the key on the device.
just do what you dont want to do and have 2 applications for free and paid it will probably be less work then the other 2 list above.
there are many ways of doing what you want. but i'll tell you this:
most applications use method 2 but on the opposite direction, meaning serial key.
i dont think your gonna create an mmo so theres no need for option 1 unless you really dont want anyone hacking your application (which i assume no matter what you do it will be hacked in todays world. i'll advice you to trust those who pay and accept those who dont)
method 3 is just easy in my opinion especialy when you want to just remove menu options, but it also creates duplicate repositories for code.
good luck. what ever you decide is good, make a theft protection, if someone wants to steal it, they will, dont fight it (even PS3 got hacked in the end)