Android Question License per device

[Robert Valentino]

Hi:

I want my software to be a per device license (something that Google directly [I believe] does not support) so I can up with this Idea and what to see what some of you thing.

I have Yearly subscriptions that when you purchase them as Part of the DeveloperPayload I include the purchasing device Mac address.

When starting the APP I check the running device Mac Address against the DeveloperPayload subscriptions Mac Address and if it does not match they need to purchase a In-App Managed product which would then contain the New Mac Address of the device they are switching to [This would override the subscriptions Mac Address] (and the software would stop working on the old device)

If they need to switch a second time I can have the App consume the In-App Managed product and have them purchase it again - where once again I would save the new Mac address.

This process could go on forever if the user keeps changing devices.

Now the fee for changing devices would be small like $1 (I am not trying to make money for them changing devices) but I just want to stop my software from being run on more than one device at a time. The reason I am so concerned about this is that my APP makes the user money so to have it working on more than one device at a time and not paying for more than one copy is not fair to me.

I've purchased some APPs and they are on my old phone that I passed onto my wife and the APPs still work fine (in fact most of them still get updated).

Would anyone do this any differently?

NOTE: I do not want to store anything on a local server or database - this way everything is on Google

Any Thoughts

Thanks

BobVal

 

[JordiCP]

Just a thought, don't know if it is possible

Why not working with N subscription items (which would in fact do the same function)? The user would only see one "Subscribe", but your app could decide to which one go (based on Google information of which items have been purchased by that account). So, if the mac address is in the group of mac addresses of purchased items, that device will be already subscribed. If not, give it the possibility to do it. This would allow for multiple devices from the same account to be subscribed at the same time

 

[JonPM]

To implement something like this, which I'm not completely sure if it violates any of Google's policies, you would need to consume the purchase as soon as it's made. This does mean that you would still need to store the purchase information on your own external server and check for previous purchases.

 

[Robert Valentino]

JordiCP that is a interesting way to go. The only problem could be if the user transfers devices (say 5 times in a year - for whatever reason - that would be a lot of subscriptions to parse [subscriptions are not consumed but expire]) otherwise I would have the managed item and the subscriptions

JonPM: This Google Doc:
"If you are using the Version 3 API, you can also consume managed items within your application. You would typically implement consumption for items that can be purchased multiple times (such as in-game currency, fuel, or magic spells). Once purchased, a managed item cannot be purchased again until you consume the item, by sending a consumption request to Google Play."

To me this reads when they want to transfer I consume the item and have them purchase again


As for Violates Google's Policies - I have not (as of yet) found anything that says this is a No No - If you have found something please let me know

BobVal

 

[Ed Brown]

@Robert Valentino, Are you saying that if I were to use device A and then switch to device B and then back to device A that I would have to buy another subscription even though I have already bought a subscription for device A? That's how I'm reading your subscription methodology.

I agree with @JordiCP's approach in that a purchase of a block of licences that can be consumed. In this situation the initial purchase price of the app can be increased to include the cost of the first block of devices. ie. instead of charging $1 you could charge $5 and it could include 5 licences. By setting the initial buying price you might not need to have IAP in your app. How many devices is a user likely to install the app onto?

Just my 5 cents worth.

 

[JonPM]

JordiCP that is a interesting way to go. The only problem could be if the user transfers devices (say 5 times in a year - for whatever reason - that would be a lot of subscriptions to parse [subscriptions are not consumed but expire]) otherwise I would have the managed item and the subscriptions

JonPM: This Google Doc:
"If you are using the Version 3 API, you can also consume managed items within your application. You would typically implement consumption for items that can be purchased multiple times (such as in-game currency, fuel, or magic spells). Once purchased, a managed item cannot be purchased again until you consume the item, by sending a consumption request to Google Play."

To me this reads when they want to transfer I consume the item and have them purchase again


As for Violates Google's Policies - I have not (as of yet) found anything that says this is a No No - If you have found something please let me know

BobVal

When you say "when they want to transfer I consume the item...". I'm not sure how you plan to handle this, as you won't know when the user plans to use another device. If you are going to use a regular IAP then you would need to consume the purchase immediately (regardless if the user wants to transfer it or not), I believe.

 

[JonPM]

Here is another discussion

 

[Robert Valentino]

The subscriptions are for a year. If you change devices you would purchase a transfer consumable (something you would not consume unless you change devices). Now if I can make a consumable that cost nothing then there would be no charge at all - I just do not want the software running on more than one device at a time.

When the user starts my app I see the Mac address is different and I would ask them if they want to transfer. If they want to transfer I would consume the item.

JonPM - you seem to read the consumables different then I do. I believe when the purchase something they own it. I do not believe I have to consume it right away that I can consume it when I want to by sending a a consumption request. But I will look into this more.

But the Consumable would be your device license and the subscriptions would be your software options.

Thought it was pretty straight forward, but I will have to try it out and see.

BobVal

PS: THANKS for all the feedback.

PSS: Update - Just tried to create a consumable for $0.00 - Not possible has to be $0.99 or more (so it would be a dollar)

PSSS: Ed Brown - read your posting that won't work. My subscriptions are different amounts and because they are yearly's or monthly's they could be expiring at different times

 

[JonPM]

JonPM - you seem to read the consumables different then I do. I believe when the purchase something they own it. I do not believe I have to consume it right away that I can consume it when I want to by sending a a consumption request. But I will look into this more.

Here's what I'm getting at: You stated you want the user to be able to purchase additional licenses on other devices, correct? The problem then is if the user is signed into the Google Play Store with the same email address (which is 99.9% likely) on a second device, then he/she cannot purchase an item that has NOT been consumed. The Play Store will see that the user has previously purchased that item, and it doesn't care that it was on a different device, and will trigger the "Purchase" state automatically. So in order to have one user with two or more devices purchase the same IAP, the product must be consumed.

 

[Robert Valentino]

JonPM - Your missing it.

Think of it this way. My app is Verizon your cell phone works on it. My subscriptions are like (call waiting, call forwarding, etc) they will work on any cell phone but only the currently connected one. If you trade in cell phones your subscriptions keep working (call waiting, call forwarding, etc) but the OLD phone doesn't do calls anymore.

I will use the consumable to track what device you are using and the subscriptions to work on any device the consumable is registered to.
So if you change devices I only have to end the consumable and start a new one for the new device.

When I generate a consumable I will put the Mac address in the Developer Payload (which I can retrieve at any time) and if the Mac address doesn't match give you options to choose from

Give me a week or so to work on it and I will let you know how it works.

BobVal