I ask this question expecting the answer to be 'not possible', as I have attempted to research this already and found no fruit! I thought that I would give the community a chance to weigh in however.
I have a working in-app billing system, but what I want is to be able to provide a little extra bit of infomation with the billing request. Something that would show up in my market place stats.
My users have the option of buying several different levels of product (sort of a Base, Premium and Gold-Star sort of thing). When they purchase the product they provide me with a string that represents the specific thing they want the product about (such as the house number and postcode if the product was about a house).
What I want is to be able to see that extra bit of information in my market place reports, so when I see someone who has requested a refund I can see on what exact item they purchased the product. I have looked at the DEVELOPER_PAYLOAD but I don't think that it will do what I want.
If I can't find a solution this way then I will end up performing a service call and storing the data myself, but I thought I would ask you guys first!
Sorry for being vague about my app and the products it returns but I don't want to expose my app yet (plus it holds no bearing on the question!).
EDIT
Now that I have added a bounty I would like to limit the answers. As I mentioned in my original question my backup plan will me a service call to my system registering the google reference and "data packet" for the purchase.
What I am most interested in is a way to do this where my information would end up in the my market place reports. For instance, if you were to offer a physical item with your in app purchase, how would a user record shipping instructions/etc. There is a place for this in the market reports, so surely there is a way to add the data?
You can certainly use DEVELOPER_PAYLOAD for this. However, Google doesn't process it in anyway and it won't show up in reports (not sure if they store it at all). So what you need to do is send transaction info (the JSON string you receive) to your own sever, parse it and store/process/whatever the developerPayload. You can combine this with signature verification and transaction reporting if you want to. One thing to beware of is that the size is limited to 512 bytes. If you send a request with a longer string, the whole transaction will fail, and the error message is not friendly at all ('IAB-DPTL' or some such).
Of course if you need more that this, you can simply build your own webservice and send whatever data you want. If it includes personal info, etc. make sure you let people know about it and/or they can turn it off.
In order to see this in the report, assuming you have a limited set of "dynamic" data, you would probably have to create a different set of in-app items per each "item" in your game.
Then, of course, you let the game handle which list the user sees according to the "dynamic" data.
That's the only way you would see it in the reports without your own web service handling it.
For those that may find this question via Google!
It seems that the easy answer to my question is NO. You can not add extra information to your market stats with regards to in app purchases.
As I mentioned in my question (and some answers said) the work around would be to upload the transaction string to your server and then compare it to market stats yourself (using the export function from the market perhaps).
I now intend to write a system to extract market stats (likely from the csv download feature) and match it up to the strings from the IAPs. If I ever get around to writing it I will share it with the community.
Related
I have a question regarding in-app purchases in Android. But first off, a little bit of information about what I am trying to do...
My app has a collection of "modules" that are arranged in a SQLite database arranged like this. These modules are differentiated simply by a column that designates what module that particular entry belongs to. What I want to do, is create an in-app purchase system where the user can download additional "modules" of content.
What is the best way to arrange and handle this data? Is it a good idea to keep the database setup and somehow implement a system where the in-app purchase adds to the database? Is it possible to keep track of this in the case that the user deletes the app or app data? I want to make this system as dynamic as possible, so that the user is not shown a message saying there is additional content available if they have already purchased and installed it.
The development on my app has not begun yet, so any other arrangement of data can easily be explored. For reference purposes, each "module" will have about 50-60 entries, and the plan is to have anywhere between 5-20 "modules" so there will be a good chunk of data.
Sorry for the plethora of questions all at once. If you need any screenshots to get a better idea of the data, or if I didn't do a good enough job in explaining what I am trying to do, please let me know!
For me it sounds like you need user accounts serverside. There you keep track of the necessary things about the user, like what he/she has bought, etc. In other words, the database is in a remote place, not in the app, so you can delete and reinstall as you wish and the data is still available.
In order to identify the users, this will help: http://developer.android.com/training/id-auth/identify.html
I'm thinking about putting an half-developed app idea up on Indie GoGo (worldwide variant of Kickstarter) but am considering how to handle delivery.
I need to make sure that just the right people can get the app they pledge for, do you know if there's a way to bind certain users to an app so only they can download it? I was thinking of using the e-mail of their Google account since they need one anyway.
I would then upload the same app publicly for a higher price for everybody else once it's done. If this way isn't supported, do you know how other people have solved this?
I guess it will be hard to do. But I have some ideas that you can use:
First of all if you have emails of your subscribers then you can directly send them your app.
If you want to place your application on Google Play then it's more difficult. I hope the following approach can be used. You can create a stub for your application. This stub during the run will check if a user possesses with some purchased item. If he possess then you simply start your application (inside your application you can also put this type of checks to be more difficult to crack your application). If the user does not have this item you propose him to buy it. During this you check if the user is in your list. If he is then you select one price if not then another.
These are just my thoughts. I've never implemented something similar.
I'm developing an Android app which should be free to use for a certain period. When the phase of free use ends the user should register and pay to be able to use the app furthermore.
No I wondering how I could archive this, as the user might simply re-install the app to extend the period of free use. So I need a way to identify the user in such a way that he cannot pretend to be someone else or a new user. At the same time I want to avoid that the user has to do any registration if possible before the free use period ends.
At the moment I think about identify the user by his telephone number or SIM card id as he probably won't buy a new SIM card only to be able the use the app for free. The disadvantage of this is that this is limited to devices which are phones so any WIFI tablet won't be able to use the app as it doesn't have a SIM card.
Are there any other options to archive this behavior?
What you want to do is to track installations. This can be done by getting a unique id and then saving it using shared preferences. You could put this into a folder on the SD-card but I don't think I'm the only one getting annoyed by this kind of behaviour in apps. Rather than putting a file on the SD-card want to backup the file using BackupManger and uploading it to the cloud.
You can find info about the BackupManager here:
Data backup
and a short part of this video on tracking installations here, 16:30 min in:
Google I/O 2011: Pro tips
I really recommend you (all) to watch the video as it goes through many rookie and pro misstakes.
When reading about the BackupManager you'll find out that, just as all the other solutions, it wont work on all devices. I don't think this will be a big concern of yours, it will be a small group of people who can work around your trial period ending but there will always be. Spend time on developing your app and making it better instead.
You might want to read this post from the Android Developers blog.
They recommend the ANDROID-ID, though it has it's downsides.
You might want to try:
import android.provider.Settings.System;
..
String android_id = System.getString(this.getContentResolver(), System.ANDROID_ID);
Although some devices apparently return the same value for this, which I think is contradictory to what the API docs say. It's possibly useful to use this as a secondary check.
However do try to take caution in sending personal details such as IMEI or phone number etc back to your server as users rightfully get a little anxious about such things being broadcast. You could always do a hash of the IMEI (if accessible, can't remember off the top of my head) and add this to the ANDROID_ID, creating something that's going to more or less be unique. Maybe hash some other detail in addition to this to really guarantee uniqueness as hashes can and will clash.
Is there a unique Android device ID?
Most voted answer (Joe's) in above is the best approach I have found so far.
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)
As Google stores your purchases of Android apps, I was wondering if they are somehow offering a webservice that can be used to check if a certain app has been purchased. To me this seems the most secure way of distinguishing free and paid users from within my app.
It would not only defeat piracy, but would also allow for managing a database of legally registered users, by a one-time check through this service.
What are your solutions to this matter?
Google provides a library for you. See here.
Note that this has been compromised in unprotected apps, so you should use something like ProGuard. The link above contains more information.
Finally, keep in mind that the Android Market is not the only app market for Android out there. Amazon has their own DRM.
At this particular moment there is one way to check.
The Android Market authenticates purchases through Google Checkout, but Google has not implemented the Checkout API to synchronize Market purchases. So calls like that check the status of an order do not work. Maybe Google doesn't want dev's to get a hold of customer emails? Either way, I do not know why it does not exist, it seems to me that if Google simply made this service available we could implement a far more superior security system that would better utilize the methods of obfuscation. As it is at the moment, a hacker can simply look for a specific class like the ILicenceService and hook it.
The only way at the current moment is to download a list of current purchases. You can do this using an authenticated http call. The drawbacks to doing this are pretty large though. First, the list it provides only extends back 31 days (so you've got to make sure you keep everything). Second, you would have to call and parse at least every ten minutes. Actually faster than that, most users want to play their games when they buy them. Third, if your service, or server goes down, that is precious information that is being requested almost instantly by your users.
I don't know how many dev's are currently utilizing this process, I considered it, but am just going to keep complaining to Google for a better method.
You could piggy back off of the LVL. I have just implemented a similar system.
Perform Check via LVL.
On success make a post to your own web server and store whatever details you need, i.e. DeviceID etc.
You could also perform checks to your own server even when the LVL check fails and allow things like trial periods etc.