I'm trying to use android subscription system.
And I think setting up 7days trial.
I would like to summarize trial users and paid users separately.
I assume that my android app gets subscription status(trial/paid) from google play, then send it to my aggregation server.
But I couldn't find the way to discriminate the status with my client app.
How can I get it?
A work around would be to make a database table with the confirmation numbers for trial or paid? this can be connected to your web service online, once activated, you can have the confirmation key and status in a table and that way you can track the user?
but then you will have to have a code, that calculates, the days..
I am also new to android development, but if I had to do it I would do it this way.
or if someone is aware of a better way, then I would love to know it aswell..
but I still do not know you are asking for code or Idea of how can it be implemented..
Related
I've been setting up in app billing the last couple of days and been trying to go the right way about it. The guides recommend using a secure back-end server to store the purchase token rather than storing the data locally. The documentation on verifying the purchases on a server is very thin and I'm not sure whether am going the right way about it.
I am using cloud fire store to store the purchase information mentioned in the title. I have a couple of questions:
Should I be reading my product id from a server rather than having it hard-coded in the apk?
How often should I/Do I need to read the device id in this case and search on the DB to make sure the user has a valid purchase? Just the once when making the purchase or intermittently?
If I am to do this, what happens when the buyer changes their phone? The device ID will be different and I wont have a record of their new device making a successful purchase. Or here do I query a skupurchase and it returns the item is already owned, write these new details to the DB?
and finally should I store a successful purchase flag in shared preferences or something so I am not constantly reading the DB and the user can use the device offline?
I was going to go down the route of getting users email using this answer here but there is a lot of comments saying this is very intrusive and I only need it for a simple thing. So I went the device ID route.
BTW I only have one product that unlocks full features and is non-consumable.
What is the correct way to go about this?
This was my approach to the same problems. It may not be relevant to your scenario. Hope it helps.
Should I be reading my product id from a server rather than having it
hard-coded in the apk?
You should store productIDs in the code as they will be used to provide features coded into the app.
How often should I/Do I need to read the device id?
You should not rely on the device id as you have raised the concern about the user changing the phone. You would want to implement the login system and make user login into the app before purchasing the product. This will make your subscription device independent.
The process should be:
User tries to use the locked feature.
App asks for login. Make user register and log in.
User clicks on the buy button again and completes the purchase.
Your server stores the user login information with the purchase information.
User changes the device.
User tries to use the locked feature.
App asks for login. User logs in.
The server returns purchase details with user info.
The app unlocks the feature.
How often should I check purchase details from the server?
You should check for purchase details intermittently.
Why? The user may ask for a refund after some time or the payment gateway would void the purchase for some reason.
IMO, there should be two types of sync methods silent and forced.
In my approach, silent sync would check for internet every 9 days. If the internet is not available, it would not do anything. While the forced sync would check for internet every 25 days from the last sync. If the internet is not available it would ask the user to turn it on otherwise, the user wouldn't be able to use the app.
I was using the subscription period of one month but as you have a non-consumable product you can afford 2-4 months forced sync period.
Should I store a successful purchase flag in shared preferences or
something so I am not constantly reading the DB and the user can use
the device offline?
The syncing process and the login would solve this problem.
I think you might be reluctant to implement a login system for such a small thing and think it would make fewer users buy your product. But by implementing Google authentication it would be fast and users would be less frustrated by it.
Implementing this approach involves a lot of server-side logic.
I've seen this question: Android - how to check if in app purchase has already been done?
It is not very clear to me however. I am using the AndroidBillingLibrary, mentioned in the answer, and I have a couple of questions.
When using restoreTransactions(), does that mean that at that point the purchases are stored on the device itself? Couldn't that be manipulated somehow?
And what if I buy an item on an other device, how does the first device know this? Do I need to restore again?
Thanks in advance
For the first question, every purchase is managed with an ID, thus only managed items work with restoreTransactions(). Also, restoreTransactions() does not work for reserved Product IDs. Thus it is still safe.
Ideally you should call restoreTransactions() every time the app runs. The Key thing is that all transactions are paired with the device/user ID (not sure how Google handles authentication on their server side but I assume it is using a combination of your Google account as well as the phones that the Google account is paired to).
So, if someone were to modify the transaction file, it will get invalidated when it is compared to the logfile on Google's side.
Hope this clarifies things :)
I'm searching for a tutorial or an explanation on how to remove advertisement in my application with in-app purchase?
I will put some ads with ad-mob in my app but I also want, that the user can disable the ads when he pays a little donation. Do you know a site or tutorial where I can find a step-by-step explanation how to do this?
Or do I need to publish 2 versions of my app? One with ads and one without ads for paying?
Don't use the SharedPreferences method because if the user flushes the app data or uninstalls/reinstalls your app their ad-free status will be lost.
A couple of ideas:
If your app has any kind of web based login or authorization, you can flag the user as having bought the ad free version by updating the web database's customer data and then disable ads in code following login and verification. This has the added benefit of following the user to new devices.
Use one of the several ways to get a unique device id, and store that in a web server database. On startup, query the DB to see if the device is ad-free. See Android Unique Device ID. This will only work for that particular device though.
The two apps approach is simple enough to get the job done too. :)
This presentation seems to explain an example and includes a link to source code at github:
http://gotocon.com/dl/2011/GeekNights/Tjen_penge_p%C3%A5_Android_ARH.pdf .
It stores the purchased upgrade at a sharedpreference.
However, I'm still looking for a more secure and robust solution that works out the use-case explained here:
http://vlingo-en.custhelp.com/app/answers/detail/a_id/1785/~/moving-in-app-purchase-(ad-removal)-to-new-android-phone/p/180
I want to release a trial version of my Android App that can only run for a fixed number of days before it disables itself. What techniques could be used that would provide reasonable protection and achieve this?
I am hoping to avoid the need for a licensing server. But if I do need one does anyone know of any open source license servers that they would recommend. If not open source then any that are reasonably priced?
Thank you for your kind response
Android makes it pretty hard to reliably resist pirating. You basically can't trust the device, pretty much need to have a call on startup to your server with the unique ID that authorizes or rejects the user. If most of the functionality relies on some server of yours, then you can make the app much more resistant to pirating by requiring a valid device ID on startup to get some sort of auth token, which your other RPCs can then use to authenticate the app.
I have a suggestion, although I do not know how effective it will be against someone who is very determined to get your app for free.
You could have a check that happens on startup of your app. If it is the first time the user has opened the app, then you take note of the time, and save it into a private preference of the app. If it is not the first time the user has opened the app, check to see if it is still within the valid data/time range from the initial time you saved to preferences. If valid, continue as normal, if not, display some message asking them to download the full version.
Again, I am not suggesting this is the best idea, or that it is even completely secure (as I do not know if anyone or any app could have access to those preferences). But I do think that it would be a cheap solution and easy to implement.
I had answered this question previously might be helpful Android: saving info for trial application
I am placing an app for free in the Market. I want to restrict the downloads (i.e only 1 download per account). If the person uninstalls my app and tries to download again and re-install it with same gmail account, I want to restrict it.
Is that possible? Please help. I am stuck here. Thanks in advance!
I strongly recommend to skip what ever you try in that direction for the given reason:
you will upset your user!
you will lose user when they had to reset their device or if they bought a new one
and finally: its not supported!
Guillaume Brunerie mentioned the Application Licensing, but that will only work after they have downloaded the app the second time and you will just piss off your user when they can't start the app after downloading it the second time.
Seriously: drop the idea!
You have to create a server.
When you app starts for first time after installation, it should make a request to your server and send some unique information about the user like gmail address, but it is highly recomended that you hash this information to protect user's privacy. The server should check the hash if exists in it`s database and return an appropriative response to the application.
The standard way to do this kind of things is to use Application Licensing, but this is only available for paid apps.
So I don’t think this is possible if you want your app to be free.