subject:"Re\: \[android\-developers\] Re\: In\-App Purchasing and the Market Agreement"

I am sure they will but I wouldn't hold my breath on WHEN. There was a
lengthy thread going about two weeks ago on here about improving the market.
I just skimmed it to follow along but they wanted to do a petition and
everything. I am not sure what happened to that. I would bet money that
google IS working on it. How could they not? Android is googles big thing
right now. But my thoughts are watching how long it's taken for Eclair 2.1
to come out I wouldn't count on  the Market being improved anytime quickly
which is why when a few people suggested that I hold off on doing my app
installs idea until they improve the market well... I don't really want to
wait til 2012 to put my app out.

;-)
-Chris

On Fri, Mar 26, 2010 at 11:10 PM, Kevin Duffey andjar...@gmail.com wrote:

 I believe most apps are available within a few hours to a day at most..
 from what I've read anyway. Not 100% sure tho. I am a little bummed that
 google hasn't made any attempt to better the market app. There is sooo much
 I would do to improve it. It could be far better than the iPhone market app.
 I wonder if they have a forum to post on things like the built-in apps... or
 if we can gain source code to it and mess with it, test it and offer changes
 to them.


 On Fri, Mar 26, 2010 at 8:40 PM, chris harper ch393...@gmail.com wrote:

 That is a great idea and out of the box (which is good) building a .apk
 dynamically.

 The Market place does not yet have the ability to search per app (which I
 agree if add on's start to come more common that will be needed). The way I
 am planning on getting around that (hopefully temporarily) is that within my
 app I still plan to open a page to my website where all my characters are
 and they can select them from there.  Once they select a character it then
 links to the .apk within the market place for that character.

 I admit the downside is they can't select multiple characters for one
 check out which is where you idea would be ideal. But I think its the best I
 can currently do until the Market place changes.

 One question I do have though. I have yet to publish an app on the Market
 (this will be my first one).
 How long is the process take when you submit an app to when it is
 available on the market?
 I really don't know. For your idea that would probably be my first
 question and its not an issue with your idea but more an issue of the Market
 place. Is it immediately? Or does it take a few days?

 If it takes a few days you can see how it would make a user upset if they
 ordered something and they have to wait days to get it.

 If it is immediately than you might have given me an idea for version two
 of my app (if people like version one that is).

 I hope to get my first install app working with my main app by the end of
 the weekend to add/remove my characters.

 -Chris



 On Fri, Mar 26, 2010 at 7:33 PM, Kevin Duffey andjar...@gmail.comwrote:

 I have a sort of twist idea to the market problem... not sure this can be
 done, but I think it could be possible.

 Imagine you have an app that allows for virtual goods. You have dozens of
 goods for sale. Even better, you have an open-ended API that allows OTHER
 developers/users to create goods for your game/app and sell them. Yay..
 revenue streams are good.

 Now, many users will probably buy one good here, one good there... but
 often times, you'll have a lot of users who want to purchase several goods.
 We surely don't want to deter the multi-goods buyer. That's more money in
 our pocket. The problem with the way you're doing it Chris (not a problem as
 in bad..just for this example), is that they would have to search/find/buy
 individual downloads for each good they wanted.

 What if your users could build up a cart full of items they want, check
 out just once, and behind the scenes, your server side builds up a single
 .apk with those goods, put's it out on the market, then sends them an email
 link for them to access from their android device when its deployed to
 market. At that time, they can then purchase the whole pack at once, through
 the market, and then utilize what you are doing Chris, where your main app
 can make use of all the goods from that install, and if not refunded in 48
 hours... uninstall/delete the .apk off the device to avoid taking up room.

 Ok, I don't know that I would implement this, but I imagine it's got to
 be possible.

 On Fri, Mar 26, 2010 at 8:43 AM, chris harper ch393...@gmail.comwrote:

 We are probably in the running for the most active thread now but that’s
 great because

 this is an important issue that needs to be addressed.



 Bob – Thank you. Your solution is a pretty thought out solution. I admit
 I had to print it out and re-read it a few times. I might have a few
 questions coming your way because I think I like what you are doing. Give 
 me
 a little more time to make sure I understand what you are doing.



 String – Congrats on doing what many have failed to do. Get an answer

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Yes I know. Warren brought that up. But the game changer was when I found
out that I can remove:

category android:name=android.intent.category.LAUNCHER /

from the manifet.xml which hides the new app's from the user (hides the
clutter) and also doesn't allow the user to start it them on their own.

So then I can just keep the new install apps behind the scenes and they
don't clutter the users drawer. So there is not as much of an importance to
delete them right away.

What I might do is run checks for the install apps after a safe time (like a
week). Then prompt the user and ask them if they want to clean them up (i.e
remove them) letting them know that removing them DOES NOT remove the
character. This way in the long run they don't have a bunch stacked up
behind the scenes that they don't know about.

I do plan to make the character apps as small as I can and put as much of
the logic in the main app as I can.

So many little details we have to deal with...
-Chris

On Sat, Mar 27, 2010 at 2:29 AM, Bob Kerns r...@acm.org wrote:

Thanks. But it slipped my mind as I was writing it that immediately
deleting the new app is going to be a loser, because it'll refund your
payment.

You'll have to arrange to do that at another time. Or not, and live
with the clutter. Or simply use your .apk as the storage for your
characters. That may actually be reasonably space-efficient, unless
the character data is pretty small.

It's not an issue for free/paid, because it's the older, free one
that's being deleted in that case.

But perhaps some components of my idea may be useful, or the code
snippets.

A really BAD idea would be to use the AlarmManager to initiate the
deletion sequence. In fact, MOST uses of the AlarmManager to launch UI
are bad, but this would be particularly evil.

I'd do well as a prank app author, if I didn't have a conscience!

On Mar 26, 8:43 am, chris harper ch393...@gmail.com wrote:
We are probably in the running for the most active thread now but that’s
great because

this is an important issue that needs to be addressed.

Bob – Thank you. Your solution is a pretty thought out solution. I admit
I
had to print it out and re-read it a few times. I might have a few
questions
coming your way because I think I like what you are doing. Give me a
little
more time to make sure I understand what you are doing.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

2010-03-27 Thread Kevin Duffey

Got an idea for the deletion of add-on toons for you. Use a simple sqllite
db on the device... when your main app finds/installs a toon, log a little
date in the db (or some other way). Every time your main app starts up, just
scan for any rows.. if any are there, check the timestamps... if it's after
2 days (maybe 3 or 4 to be safe), uninstall the .apks at that time.

HOWEVER, something occurred to me. Programmatically uninstalling .apks
without the user knowing may not be advisable. Even tho the toon still works
in the app for them, I would suspect most users, if they wanted to delete it
(or otherwise look at stats on it), they would go thru the settings/manage
applications route, and if they can't find it they may wonder what happened.
Trying to explain to your end users that after a few days the .apk they
bought/downloaded/installed will be uninstalled to free up room, may be
too much text for a simple toon purchase/install. Maybe not.

Another thought..doubt it's possible.. and I still haven't paid for an app
on android yet so not entirely sure how this works. I thought you'd set up a
google checkout account.. being android and google and all. If that is the
case, then like you said, it's likely that a user will have an account
already.. or at least is more willing to submit their personal info setting
up a gogle checkout account over some in-game form you provide. Now, I don't
know how viable this is, but if the user already has a google checkout, is
there a way to obtain their checkout info... in-app/game, without requiring
them to fill anything out? This way, you could avoid the .apk market route,
you earn the extra .30 per toon, you host it, you keep stats on downloads,
which toons are more popular than others, etc. Tons of stuff you can control
from this aspect of it. If a user already set up a google checkout account,
how hard is it to utilize this in-app/game so that you can use it to charge
and then download in-app/game right away? If they haven't set up an account
to buy anything on market, they are going to have to fill in that info
anyway to buy anything. Actually.. come to think of it.. if you charge for
your main app..they already set it up. I would have thought the info would
be in some way available..not their private stuff, but the google checkout
info, so that you could utilize it somehow? I'll have to look into it more
as this is how I would do it.

Another thought..perhaps to get more virtual toon sales, give your game away
(if you aren't already), with 1 toon, and put your own little splash-screen
ads for other toons as the app loads up. This may interest users in
supporting your app and buying even more toons than if they already paid for
the app. Also, look at custom creation of toons/avatars.. for perhaps a $2
charge for example. Again, not at all clear on your app and it's ideas, but
just some food for thought on how you might make a little more from it.



On Sat, Mar 27, 2010 at 7:46 AM, chris harper ch393...@gmail.com wrote:

 Yes I know. Warren brought that up. But the game changer was when I found
 out that I can remove:

 category android:name=android.intent.category.LAUNCHER /

 from the manifet.xml which hides the new app's from the user (hides the
 clutter) and also doesn't allow the user to start it them on their own.

 So then I can just keep the new install apps behind the scenes and they
 don't clutter the users drawer. So there is not as much of an importance to
 delete them right away.

 What I might do is run checks for the install apps after a safe time (like
 a week). Then prompt the user and ask them if they want to clean them up
 (i.e remove them) letting them know that removing them DOES NOT remove the
 character. This way in the long run they don't have a bunch stacked up
 behind the scenes that they don't know about.

 I do plan to make the character apps as small as I can and put as much of
 the logic in the main app as I can.

 So many little details we have to deal with...
 -Chris


 On Sat, Mar 27, 2010 at 2:29 AM, Bob Kerns r...@acm.org wrote:

 Thanks. But it slipped my mind as I was writing it that immediately
 deleting the new app is going to be a loser, because it'll refund your
 payment.

 You'll have to arrange to do that at another time. Or not, and live
 with the clutter. Or simply use your .apk as the storage for your
 characters. That may actually be reasonably space-efficient, unless
 the character data is pretty small.

 It's not an issue for free/paid, because it's the older, free one
 that's being deleted in that case.

 But perhaps some components of my idea may be useful, or the code
 snippets.

 A really BAD idea would be to use the AlarmManager to initiate the
 deletion sequence. In fact, MOST uses of the AlarmManager to launch UI
 are bad, but this would be particularly evil.

 I'd do well as a prank app author, if I didn't have a conscience!

 On Mar 26, 8:43 am, chris harper ch393...@gmail.com wrote:
  We are probably in the

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

2010-03-27 Thread Kevin Duffey

Hmm.. just looked up google checkout.. turns out paypal and google checkout
charge .30 + 2.9%.. so you're still stuck losing 30% for a $1 fee.. actually
2.9% more. So what, .33 per toon. Still.. not a big deal if it's utilized..
making 67% or so is great, especially if more and more people buy virtual
goods.

On Sat, Mar 27, 2010 at 7:46 AM, chris harper ch393...@gmail.com wrote:

Yes I know. Warren brought that up. But the game changer was when I found
out that I can remove:

category android:name=android.intent.category.LAUNCHER /

from the manifet.xml which hides the new app's from the user (hides the
clutter) and also doesn't allow the user to start it them on their own.

So then I can just keep the new install apps behind the scenes and they
don't clutter the users drawer. So there is not as much of an importance to
delete them right away.

What I might do is run checks for the install apps after a safe time (like
a week). Then prompt the user and ask them if they want to clean them up
(i.e remove them) letting them know that removing them DOES NOT remove the
character. This way in the long run they don't have a bunch stacked up
behind the scenes that they don't know about.

I do plan to make the character apps as small as I can and put as much of
the logic in the main app as I can.

So many little details we have to deal with...
-Chris

On Sat, Mar 27, 2010 at 2:29 AM, Bob Kerns r...@acm.org wrote:

Thanks. But it slipped my mind as I was writing it that immediately
deleting the new app is going to be a loser, because it'll refund your
payment.

It's not an issue for free/paid, because it's the older, free one
that's being deleted in that case.

But perhaps some components of my idea may be useful, or the code
snippets.

A really BAD idea would be to use the AlarmManager to initiate the
deletion sequence. In fact, MOST uses of the AlarmManager to launch UI
are bad, but this would be particularly evil.

I'd do well as a prank app author, if I didn't have a conscience!

On Mar 26, 8:43 am, chris harper ch393...@gmail.com wrote:
We are probably in the running for the most active thread now but that’s
great because

this is an important issue that needs to be addressed.

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

We must be on the same wave length because I am ready doing what you just
explained. :-)

When in install app (I started calling them modules in my code) is download
I check the db, if that character is there then it updates that character
in the DB if it is not then inserts the character info. It also inserts it's
time stamp and its package name. On start up for the MAIN app it will cycle
though the package names of the installed modules and if one is over a
week old from install it will ask the user if they wish to remove it (but
make it clear this will NOT uninstall the character if they do). If they
decline it will state that no more notifications will ask to remove it and
it will remain installed until the user deletes the character (which also
removes the module for that character at the same time). I will NEVER
uninstall a module without checking with the user.

Yep the main app is free and it will come with TWO characters because two
characters can be loaded at the same time and interact with each other which
I want the user to experience this to make getting additional characters
more appealing. In the app itself where the installed characters are I have
a little mini webview set up which I links to one of my webpages where I
plan to post new characters. So when they use the app even without going
to search for new ones they will know of any new characters that I just put.
If you want my code snippet I can send it to you.
i.e. my own banner I guess.

I agree the main thing about going though Market place is that it has the
highest chance that the user probably has an account (compared to maybe a
paypal etc). Which is what we developers want.

It would be great if we could get their checkout info but I would say that
is a HUGE security risk and I don't see that happening. Besides why would
Google do that? They get 30% if people go though them? They have no
incentive. What could be done is what was suggested is that they provide an
API so people can use to check out THOUGH Market Place. But honestly I don't
see that happening either at least not for awhile.
Heck 2.1 took forever to come out. So going the route I am is the only way
I see how me (or someone) else can go through Market place, for awhile at
least.

I think I can get my character stats. I can keep track from my site where
they browse the characters, when they click the link to buy one (which links
to Market Place) I can track that I am thinking. Also Flurry can probably
help. I just started learning it.
www.flurry.com

If (big IF) mine is a success then maybe you can gain from my experience?
Although I probably have about another month to two before I can finish code
and test.

Speaking of which, I need to do serious testing in starting in about two
weeks. Has anyone used Device Anywhere? They seem to have a special setup
for independent developers.

https://www.deviceanywhere.com/Independent%20Developer/Independent%20Developer_virtual_developer_lab.html

I watched the video and seems like a great idea for testing:
https://www.deviceanywhere.com/onlinedemos/

I just wanted to get some feedback on anyone that tired it?

Thank you
-Chris

On Sat, Mar 27, 2010 at 12:20 PM, Kevin Duffey andjar...@gmail.com wrote:

Got an idea for the deletion of add-on toons for you. Use a simple sqllite
db on the device... when your main app finds/installs a toon, log a little
date in the db (or some other way). Every time your main app starts up, just
scan for any rows.. if any are there, check the timestamps... if it's after
2 days (maybe 3 or 4 to be safe), uninstall the .apks at that time.

HOWEVER, something occurred to me. Programmatically uninstalling .apks
without the user knowing may not be advisable. Even tho the toon still works
in the app for them, I would suspect most users, if they wanted to delete it
(or otherwise look at stats on it), they would go thru the settings/manage
applications route, and if they can't find it they may wonder what happened.
Trying to explain to your end users that after a few days the .apk they
bought/downloaded/installed will be uninstalled to free up room, may be
too much text for a simple toon purchase/install. Maybe not.

Another thought..doubt it's possible.. and I still haven't paid for an app
on android yet so not entirely sure how this works. I thought you'd set up a
google checkout account.. being android and google and all. If that is the
case, then like you said, it's likely that a user will have an account
already.. or at least is more willing to submit their personal info setting
up a gogle checkout account over some in-game form you provide. Now, I don't
know how viable this is, but if the user already has a google checkout, is
there a way to obtain their checkout info... in-app/game, without requiring
them to fill anything out? This way, you could avoid the .apk market route,
you earn the extra .30 per toon, you host it, you keep stats on downloads,
which toons are more

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Good point Kevin

Although we can't just look at this from the coder implementation point of
view (my website, using paypal, market place etc). We have to think how
people buy crap.
If the highest chance that they will have an account with Market place then
that will makes a big difference for how many people buy additional content
for your game. For the simple fact of impulse buying.

If all they have to do is click ok, there is a lot lower chance that they
actually think much about it (especially if you charge like .99). They are
caught up in your game its a two second click. Trasaction done.

If they have to stop to pull out their cc or look up a paypal account then
they actually start to think about that transaction. Do I REALLY want to
pay .99 for this? Eh...maybe not.

Its not being sneaky, it's just how people shop.

I know. I have done it.

;-)

On Sat, Mar 27, 2010 at 12:23 PM, Kevin Duffey andjar...@gmail.com wrote:

On Sat, Mar 27, 2010 at 7:46 AM, chris harper ch393...@gmail.com wrote:

Yes I know. Warren brought that up. But the game changer was when I
found out that I can remove:

category android:name=android.intent.category.LAUNCHER /

from the manifet.xml which hides the new app's from the user (hides the
clutter) and also doesn't allow the user to start it them on their own.

So then I can just keep the new install apps behind the scenes and they
don't clutter the users drawer. So there is not as much of an importance to
delete them right away.

What I might do is run checks for the install apps after a safe time (like
a week). Then prompt the user and ask them if they want to clean them up
(i.e remove them) letting them know that removing them DOES NOT remove the
character. This way in the long run they don't have a bunch stacked up
behind the scenes that they don't know about.

I do plan to make the character apps as small as I can and put as much of
the logic in the main app as I can.

So many little details we have to deal with...
-Chris

On Sat, Mar 27, 2010 at 2:29 AM, Bob Kerns r...@acm.org wrote:

Thanks. But it slipped my mind as I was writing it that immediately
deleting the new app is going to be a loser, because it'll refund your
payment.

It's not an issue for free/paid, because it's the older, free one
that's being deleted in that case.

But perhaps some components of my idea may be useful, or the code
snippets.

A really BAD idea would be to use the AlarmManager to initiate the
deletion sequence. In fact, MOST uses of the AlarmManager to launch UI
are bad, but this would be particularly evil.

I'd do well as a prank app author, if I didn't have a conscience!

On Mar 26, 8:43 am, chris harper ch393...@gmail.com wrote:
We are probably in the running for the most active thread now but
that’s
great because

this is an important issue that needs to be addressed.

Bob – Thank you. Your solution is a pretty thought out solution. I
admit I
had to print it out and re-read it a few times. I might have a few
questions
coming your way because I think I like what you are doing. Give me a
little
more time to make sure I understand what you are doing.

You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words
REMOVE ME as the subject.

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

2010-03-26 Thread chris harper

We are probably in the running for the most active thread now but that’s
great because

this is an important issue that needs to be addressed.

Bob – Thank you. Your solution is a pretty thought out solution. I admit I
had to print it out and re-read it a few times. I might have a few questions
coming your way because I think I like what you are doing. Give me a little
more time to make sure I understand what you are doing.

String – Congrats on doing what many have failed to do. Get an answer from
someone at google about app’s doing their own in-app purchasing. We need to
post that in bold someplace. I hope you bought his dessert for him. That
closes the can on a big question we have all be wanting a simple answer to
(right Kevin, Warren?). The idea of Google user creds is very good. I still
REALLY like that fact since the user is already using android then they
probably already have an account though Market place and REALLY want to tap
into that. As far as account setup it’s pretty much a given in my opinion.
They just have to “ok” a transaction though my app and download the install
app for the character. We are talking mobile here so people are messing with
their phone while doing something else a lot of the time. If you can set it
up so they just click “ok” and not have to mess with setting anything up
then that has to make a difference in the amount of people you get
purchasing extras.

Westmeadboy – I agree with you. Last night knowing that I can hide my
install app’s from the user and access them though the main app, well I can
just modify my design so all the resources for each character are contained
in their own install app’s (images, sounds etc..) and the main app can just
access them via the assetManager. This will allow the install app’s very
“lean” and in turn make downloading them quick for the user.

That way my virtual content (i.e. my characters) truly are just “modules”
that my main uses. Then my main app just accesses the “modules” for each
character when a user wants to add/remove or update a character.

Flooding the market. Maybe. But on a separate point many other threads have
been asking (even pleading) Google to upgrade the market. I don’t want to
wait because they have been very slow to respond in doing that. Maybe
flooding the market will actually SHOW them that the market NEEDS to be
changed. They need to maybe create an “addon” category so developers can do
what we are taking about and app users can then search for add-on’s for
specific apps? In your last post “LAUNCHER intent, the system won't give the
user the option to open it, from anywhere.” That is want I seen when I
played with it last night, but that is perfect for my design because A. The
install app’s are hidden and B. They can only access them via the main app.

Bob – I am re-reading. I like what you are doing.

-Chris

On Fri, Mar 26, 2010 at 6:34 AM, westmeadboy westmead...@yahoo.co.ukwrote:

On Mar 26, 11:54 am, String sterling.ud...@googlemail.com wrote:
If your add-on app doesn't have a LAUNCHER intent, the system won't
give the user the option to open it, from anywhere.

I thought using category INFO also allows the user to click Open in
the Market app once the downloaded app has installed?

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

I have a sort of twist idea to the market problem... not sure this can be
done, but I think it could be possible.

Imagine you have an app that allows for virtual goods. You have dozens of
goods for sale. Even better, you have an open-ended API that allows OTHER
developers/users to create goods for your game/app and sell them. Yay..
revenue streams are good.

Now, many users will probably buy one good here, one good there... but often
times, you'll have a lot of users who want to purchase several goods. We
surely don't want to deter the multi-goods buyer. That's more money in our
pocket. The problem with the way you're doing it Chris (not a problem as in
bad..just for this example), is that they would have to search/find/buy
individual downloads for each good they wanted.

What if your users could build up a cart full of items they want, check out
just once, and behind the scenes, your server side builds up a single .apk
with those goods, put's it out on the market, then sends them an email link
for them to access from their android device when its deployed to market. At
that time, they can then purchase the whole pack at once, through the
market, and then utilize what you are doing Chris, where your main app can
make use of all the goods from that install, and if not refunded in 48
hours... uninstall/delete the .apk off the device to avoid taking up room.

Ok, I don't know that I would implement this, but I imagine it's got to be
possible.

On Fri, Mar 26, 2010 at 8:43 AM, chris harper ch393...@gmail.com wrote:

 We are probably in the running for the most active thread now but that’s
 great because

 this is an important issue that needs to be addressed.



 Bob – Thank you. Your solution is a pretty thought out solution. I admit I
 had to print it out and re-read it a few times. I might have a few questions
 coming your way because I think I like what you are doing. Give me a little
 more time to make sure I understand what you are doing.



 String – Congrats on doing what many have failed to do. Get an answer from
 someone at google about app’s doing their own in-app purchasing. We need to
 post that in bold someplace.  I hope you bought his dessert for him. That
 closes the can on a big question we have all be wanting a simple answer to
 (right Kevin, Warren?). The idea of  Google user creds is very good. I
 still REALLY like that fact since the user is already using android then
 they probably already have an account though Market place and REALLY want to
 tap into that. As far as account setup it’s pretty much a given in my
 opinion. They just have to “ok” a transaction though my app and download the
 install app for the character. We are talking mobile here so people are
 messing with their phone while doing something else a lot of the time. If
 you can set it up so they just click “ok” and not have to mess with setting
 anything up then that has to make a difference in the amount of people you
 get purchasing extras.



 Westmeadboy – I agree with you. Last night knowing that I can hide my
 install app’s from the user and access them though the main app, well I can
 just modify my design so all the resources for each character are contained
 in their own install app’s (images, sounds etc..) and the main app can just
 access them via the assetManager. This will allow the install app’s very
 “lean” and in turn make downloading them quick for the user.

 That way my virtual content (i.e. my characters) truly are just “modules”
 that my main uses. Then my main app just accesses the “modules” for each
 character when a user wants to add/remove or update a character.

 Flooding the market. Maybe. But on a separate point many other threads have
 been asking (even pleading) Google to upgrade the market. I don’t want to
 wait because they have been very slow to respond in doing that. Maybe
 flooding the market will actually SHOW them that the market NEEDS to be
 changed. They need to maybe create an “addon” category so developers can do
 what we are taking about and app users can then search for add-on’s for
 specific apps? In your last post “LAUNCHER intent, the system won't give the
 user the option to open it, from anywhere.” That is want I seen when I
 played with it last night, but that is perfect for my design because A. The
 install app’s are hidden and  B. They can only access them via the main
 app.



 Bob – I am re-reading. I like what you are doing.

 -Chris


 On Fri, Mar 26, 2010 at 6:34 AM, westmeadboy westmead...@yahoo.co.ukwrote:

 On Mar 26, 11:54 am, String sterling.ud...@googlemail.com wrote:
  If your add-on app doesn't have a LAUNCHER intent, the system won't
  give the user the option to open it, from anywhere.

 I thought using category INFO also allows the user to click Open in
 the Market app once the downloaded app has installed?

 --
 You received this message because you are subscribed to the Google
 Groups Android Developers group.
 To post to this group, send email to

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

2010-03-26 Thread chris harper

That is a great idea and out of the box (which is good) building a .apk
dynamically.

The Market place does not yet have the ability to search per app (which I
agree if add on's start to come more common that will be needed). The way I
am planning on getting around that (hopefully temporarily) is that within my
app I still plan to open a page to my website where all my characters are
and they can select them from there.  Once they select a character it then
links to the .apk within the market place for that character.

I admit the downside is they can't select multiple characters for one check
out which is where you idea would be ideal. But I think its the best I can
currently do until the Market place changes.

One question I do have though. I have yet to publish an app on the Market
(this will be my first one).
How long is the process take when you submit an app to when it is available
on the market?
I really don't know. For your idea that would probably be my first question
and its not an issue with your idea but more an issue of the Market place.
Is it immediately? Or does it take a few days?

If it takes a few days you can see how it would make a user upset if they
ordered something and they have to wait days to get it.

If it is immediately than you might have given me an idea for version two of
my app (if people like version one that is).

I hope to get my first install app working with my main app by the end of
the weekend to add/remove my characters.

-Chris



On Fri, Mar 26, 2010 at 7:33 PM, Kevin Duffey andjar...@gmail.com wrote:

 I have a sort of twist idea to the market problem... not sure this can be
 done, but I think it could be possible.

 Imagine you have an app that allows for virtual goods. You have dozens of
 goods for sale. Even better, you have an open-ended API that allows OTHER
 developers/users to create goods for your game/app and sell them. Yay..
 revenue streams are good.

 Now, many users will probably buy one good here, one good there... but
 often times, you'll have a lot of users who want to purchase several goods.
 We surely don't want to deter the multi-goods buyer. That's more money in
 our pocket. The problem with the way you're doing it Chris (not a problem as
 in bad..just for this example), is that they would have to search/find/buy
 individual downloads for each good they wanted.

 What if your users could build up a cart full of items they want, check out
 just once, and behind the scenes, your server side builds up a single .apk
 with those goods, put's it out on the market, then sends them an email link
 for them to access from their android device when its deployed to market. At
 that time, they can then purchase the whole pack at once, through the
 market, and then utilize what you are doing Chris, where your main app can
 make use of all the goods from that install, and if not refunded in 48
 hours... uninstall/delete the .apk off the device to avoid taking up room.

 Ok, I don't know that I would implement this, but I imagine it's got to be
 possible.

 On Fri, Mar 26, 2010 at 8:43 AM, chris harper ch393...@gmail.com wrote:

 We are probably in the running for the most active thread now but that’s
 great because

 this is an important issue that needs to be addressed.



 Bob – Thank you. Your solution is a pretty thought out solution. I admit I
 had to print it out and re-read it a few times. I might have a few questions
 coming your way because I think I like what you are doing. Give me a little
 more time to make sure I understand what you are doing.



 String – Congrats on doing what many have failed to do. Get an answer from
 someone at google about app’s doing their own in-app purchasing. We need to
 post that in bold someplace.  I hope you bought his dessert for him. That
 closes the can on a big question we have all be wanting a simple answer to
 (right Kevin, Warren?). The idea of  Google user creds is very good. I
 still REALLY like that fact since the user is already using android then
 they probably already have an account though Market place and REALLY want to
 tap into that. As far as account setup it’s pretty much a given in my
 opinion. They just have to “ok” a transaction though my app and download the
 install app for the character. We are talking mobile here so people are
 messing with their phone while doing something else a lot of the time. If
 you can set it up so they just click “ok” and not have to mess with setting
 anything up then that has to make a difference in the amount of people you
 get purchasing extras.



 Westmeadboy – I agree with you. Last night knowing that I can hide my
 install app’s from the user and access them though the main app, well I can
 just modify my design so all the resources for each character are contained
 in their own install app’s (images, sounds etc..) and the main app can just
 access them via the assetManager. This will allow the install app’s very
 “lean” and in turn make downloading them

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Its within a day usually faster most of the time from what I have read

chris harper ch393...@gmail.com wrote:

That is a great idea and out of the box (which is good) building a .apk
dynamically.

The Market place does not yet have the ability to search per app (which I
agree if add on's start to come more common that will be needed). The way I
am planning on getting around that (hopefully temporarily) is that within my
app I still plan to open a page to my website where all my characters are
and they can select them from there.  Once they select a character it then
links to the .apk within the market place for that character.

I admit the downside is they can't select multiple characters for one check
out which is where you idea would be ideal. But I think its the best I can
currently do until the Market place changes.

One question I do have though. I have yet to publish an app on the Market
(this will be my first one).
How long is the process take when you submit an app to when it is available
on the market?
I really don't know. For your idea that would probably be my first question
and its not an issue with your idea but more an issue of the Market place.
Is it immediately? Or does it take a few days?

If it takes a few days you can see how it would make a user upset if they
ordered something and they have to wait days to get it.

If it is immediately than you might have given me an idea for version two of
my app (if people like version one that is).

I hope to get my first install app working with my main app by the end of
the weekend to add/remove my characters.

-Chris



On Fri, Mar 26, 2010 at 7:33 PM, Kevin Duffey andjar...@gmail.com wrote:

 I have a sort of twist idea to the market problem... not sure this can be
 done, but I think it could be possible.

 Imagine you have an app that allows for virtual goods. You have dozens of
 goods for sale. Even better, you have an open-ended API that allows OTHER
 developers/users to create goods for your game/app and sell them. Yay..
 revenue streams are good.

 Now, many users will probably buy one good here, one good there... but
 often times, you'll have a lot of users who want to purchase several goods.
 We surely don't want to deter the multi-goods buyer. That's more money in
 our pocket. The problem with the way you're doing it Chris (not a problem as
 in bad..just for this example), is that they would have to search/find/buy
 individual downloads for each good they wanted.

 What if your users could build up a cart full of items they want, check out
 just once, and behind the scenes, your server side builds up a single .apk
 with those goods, put's it out on the market, then sends them an email link
 for them to access from their android device when its deployed to market. At
 that time, they can then purchase the whole pack at once, through the
 market, and then utilize what you are doing Chris, where your main app can
 make use of all the goods from that install, and if not refunded in 48
 hours... uninstall/delete the .apk off the device to avoid taking up room.

 Ok, I don't know that I would implement this, but I imagine it's got to be
 possible.

 On Fri, Mar 26, 2010 at 8:43 AM, chris harper ch393...@gmail.com wrote:

 We are probably in the running for the most active thread now but that’s
 great because

 this is an important issue that needs to be addressed.



 Bob – Thank you. Your solution is a pretty thought out solution. I admit I
 had to print it out and re-read it a few times. I might have a few questions
 coming your way because I think I like what you are doing. Give me a little
 more time to make sure I understand what you are doing.



 String – Congrats on doing what many have failed to do. Get an answer from
 someone at google about app’s doing their own in-app purchasing. We need to
 post that in bold someplace.  I hope you bought his dessert for him. That
 closes the can on a big question we have all be wanting a simple answer to
 (right Kevin, Warren?). The idea of  Google user creds is very good. I
 still REALLY like that fact since the user is already using android then
 they probably already have an account though Market place and REALLY want to
 tap into that. As far as account setup it’s pretty much a given in my
 opinion. They just have to “ok” a transaction though my app and download the
 install app for the character. We are talking mobile here so people are
 messing with their phone while doing something else a lot of the time. If
 you can set it up so they just click “ok” and not have to mess with setting
 anything up then that has to make a difference in the amount of people you
 get purchasing extras.



 Westmeadboy – I agree with you. Last night knowing that I can hide my
 install app’s from the user and access them though the main app, well I can
 just modify my design so all the resources for each character are contained
 in their own install app’s (images, sounds etc..) and the main app can just
 access

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

I believe most apps are available within a few hours to a day at most.. from
what I've read anyway. Not 100% sure tho. I am a little bummed that google
hasn't made any attempt to better the market app. There is sooo much I would
do to improve it. It could be far better than the iPhone market app. I
wonder if they have a forum to post on things like the built-in apps... or
if we can gain source code to it and mess with it, test it and offer changes
to them.


On Fri, Mar 26, 2010 at 8:40 PM, chris harper ch393...@gmail.com wrote:

 That is a great idea and out of the box (which is good) building a .apk
 dynamically.

 The Market place does not yet have the ability to search per app (which I
 agree if add on's start to come more common that will be needed). The way I
 am planning on getting around that (hopefully temporarily) is that within my
 app I still plan to open a page to my website where all my characters are
 and they can select them from there.  Once they select a character it then
 links to the .apk within the market place for that character.

 I admit the downside is they can't select multiple characters for one check
 out which is where you idea would be ideal. But I think its the best I can
 currently do until the Market place changes.

 One question I do have though. I have yet to publish an app on the Market
 (this will be my first one).
 How long is the process take when you submit an app to when it is available
 on the market?
 I really don't know. For your idea that would probably be my first question
 and its not an issue with your idea but more an issue of the Market place.
 Is it immediately? Or does it take a few days?

 If it takes a few days you can see how it would make a user upset if they
 ordered something and they have to wait days to get it.

 If it is immediately than you might have given me an idea for version two
 of my app (if people like version one that is).

 I hope to get my first install app working with my main app by the end of
 the weekend to add/remove my characters.

 -Chris



 On Fri, Mar 26, 2010 at 7:33 PM, Kevin Duffey andjar...@gmail.com wrote:

 I have a sort of twist idea to the market problem... not sure this can be
 done, but I think it could be possible.

 Imagine you have an app that allows for virtual goods. You have dozens of
 goods for sale. Even better, you have an open-ended API that allows OTHER
 developers/users to create goods for your game/app and sell them. Yay..
 revenue streams are good.

 Now, many users will probably buy one good here, one good there... but
 often times, you'll have a lot of users who want to purchase several goods.
 We surely don't want to deter the multi-goods buyer. That's more money in
 our pocket. The problem with the way you're doing it Chris (not a problem as
 in bad..just for this example), is that they would have to search/find/buy
 individual downloads for each good they wanted.

 What if your users could build up a cart full of items they want, check
 out just once, and behind the scenes, your server side builds up a single
 .apk with those goods, put's it out on the market, then sends them an email
 link for them to access from their android device when its deployed to
 market. At that time, they can then purchase the whole pack at once, through
 the market, and then utilize what you are doing Chris, where your main app
 can make use of all the goods from that install, and if not refunded in 48
 hours... uninstall/delete the .apk off the device to avoid taking up room.

 Ok, I don't know that I would implement this, but I imagine it's got to be
 possible.

 On Fri, Mar 26, 2010 at 8:43 AM, chris harper ch393...@gmail.com wrote:

 We are probably in the running for the most active thread now but that’s
 great because

 this is an important issue that needs to be addressed.



 Bob – Thank you. Your solution is a pretty thought out solution. I admit
 I had to print it out and re-read it a few times. I might have a few
 questions coming your way because I think I like what you are doing. Give me
 a little more time to make sure I understand what you are doing.



 String – Congrats on doing what many have failed to do. Get an answer
 from someone at google about app’s doing their own in-app purchasing. We
 need to post that in bold someplace.  I hope you bought his dessert for
 him. That closes the can on a big question we have all be wanting a simple
 answer to (right Kevin, Warren?). The idea of  Google user creds is very
 good. I still REALLY like that fact since the user is already using android
 then they probably already have an account though Market place and REALLY
 want to tap into that. As far as account setup it’s pretty much a given in
 my opinion. They just have to “ok” a transaction though my app and download
 the install app for the character. We are talking mobile here so people are
 messing with their phone while doing something else a lot of the time. If
 you can set it up so they just click

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Good stuff Bob.. hurry up with your blog.. its empty right now. ;)

I am happy to hear that at lest someone from google has acknowledged that it
is perfectly fine to do in-app virtual goods, etc. I plan to roll that
ability into my service soon as I figure out how to handle paypal, credit
cards and google checkout.

On Fri, Mar 26, 2010 at 10:10 PM, Bob Kerns r...@acm.org wrote:

My experience was, I published it, went to my device, located it, and
downloaded it.

But I don't know if they have a distributed infrastructure that may
impose delays before it reaches everyone. I've noticed that it can
take a while for comments I posted from the Market app to actually
appear.

I maintain a comment to (1) try to direct people to contact me for
assistance rather than post problems -- HAH! and (2) mark in the
comments where any earlier comments are for earlier versions. So I was
a bit concerned at first, but my updated comment did show up in the
right place after a while.

My comment says:
Please send any support reuests or problem reports to us at android-
supp...@sfsmart.com. We aim to give fast, quality support. NEWLY
UPDATED! 1.0.296
(And I'll increment the version number every time I repost the
comment).

I'm hoping this will help.

Of course, this means I absolutely cannot reply via the comments, at
least not without another phone or account and a lot of hassle.

More on my thoughts and impressions at
http://bobkerns.typepad.com/bob_kerns_thinking/2010/03/meet-the-users.html
in a few minutes (I'm having a bad case of Chrome vs TypePad...)

On Mar 26, 9:26 pm, Kevin Duffey andjar...@gmail.com wrote:
Its within a day usually faster most of the time from what I have read

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

So has anyone found or used google checkout, or paypal, directly within your
app, as opposed to sending a user to a web page to log in to paypal and so
forth? I am curious how anyone has integrated checkout right into their app
without the user being taken away from the app itself. I haven't checked for
a while..but I thought google checkout had a REST api you could use once you
got an API key, or something like it. It would be nice if google checkout
and paypal were options, and could utilize a users account they may already
have without them having to fill out credit card info in your app. I think a
lot more people will be weary of filling out credit card info in your app,
then say a familiar paypal or google checkout page. If you do send them to a
web page, perhaps to sign up for an account and set up a credit card or
whatever, has anyone been receiving feedback that it's annoying, users
decide not to buy because of that extra process, etc?



On Wed, Mar 24, 2010 at 4:08 PM, Kevin Duffey andjar...@gmail.com wrote:

 Kewl. I agree with you.. same thoughts.. if they are going to say don't do
 it.. then they need to provide some clear cut examples and info on how to
 provide such functionality. If it's thru the market, then for God's sake
 please let's clean up the Market app so that virtual goods, addons etc are
 NOT displayed with the market apps/games. Add more filters on the market
 app. I am surprised there hasn't been any update at least since I got my
 droid, for the market app.




 On Wed, Mar 24, 2010 at 3:09 PM, chris harper ch393...@gmail.com wrote:

 I will post my response on both threads and I Kevin you are right we had
 two threads going on this with no answer.

 Thanks for the input TreKing

 I agree I don't WANT to violate anything but when I can't get an answer I
 am not sure what do to?

 I have the basic skeleton structure for implementing the APK's for the
 characters though the Market. I will keep that on the side and I will start
 by publishing my characters via my own website and if they say I can't then
 you are right as least I forced a hand and got an answer.

 If I do get that answer then again, the question is only PART of it
 because if they tell developers that they HAVE to go though  Market Place to
 provide virtual content which people can buy via their app (NOT AN UPGRADE
 FOR THE APP vey important difference) then well

 ...where is the infrastructure to support it?

 They have either to provide the infrastructure though Market Place for
 virtual content OR by provide the API's that developers can use in their
 apps to use Market Place to complete transactions of virtual items purchased
 within apps.

 They can't just say don't do that and not provide an alternative way.
 Well they could but it would make me rethink about developing for Android.

 At least that's how I see it.

 I'll go with my original idea and if they make me change to use market
 place then I will make sure all the other developers know about it and at
 least we have a future direction.

 Although I estimate that I have about another two months of code and test
 work before I distribute my app.

 ToonTalks!

 Watch for it.

 :-)

 Thank you
 On Wed, Mar 24, 2010 at 4:00 PM, Kevin Duffey andjar...@gmail.comwrote:

 Hey all,

 read that thread and the rest of this one. I agree with TreKing. Just do
 it Chris. The language to me, and everyone else here is quite clear. All
 apps distributed thru the market MUST pay the market. Cool.. fair enough..
 but there is nothing at all that describes in-game transactions that you
 code yourself. Nothing at all. There is no place short of this thread and
 another that tries to identify this issue and I am rather shocked as long as
 this thread has been around nobody from google has responded. As TreKing
 said, it's ambiguous, it's not nearly clear enough to say you can't do it.
 More so, I can't help but wonder, how would google ever know anyway... short
 of someone calling them up and saying that an app sold on the market is
 doing in-game payments thru paypal or something.. and if that person can do
 that, why can't we find some way to contact them to find this out.

 Frankly, as I've said a few times, google would be out of their minds to
 try to prevent this and if anything should really step up and provide a
 solid built-in android payment capability that they can profit from. I said
 it several times, I am ALL for giving google some of my in-game profits.
 They deserve it if they are willing to support it by supplying the API that
 handles the transactions. There has been plenty of articles about how long
 can google sustain their financial status on ads only... this is clearly one
 way they can make a crap load of money doing almost nothing (after all they
 already have google checkout working and supported), and from the various
 articles talking about how big micro transactions are going to be, and
 already are, if Android itself balloons and

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

2010-03-25 Thread Shane Isbell

I thought I'd briefly jump in on this discussion. I'm looking into providing
a virtual currency/in-app billing solution for ZappMarket. ZappMarket is
focused on paid app developers.

I'd like to talk with developers (either on-list or you can send me an
e-mail) about what your specific needs are for virtual currency and in-app
billing. Largely at a technical level in terms of APIs you would find useful
and whether you are looking for a basic set of interactions like
check_balance, pay or for something more sophisticated that would also
manage codes and virtual goods themselves.

Based on your feedback, I can put up a trial solution that we can test and
then go from there.

Thanks,
Shane Isbell (Founder of ZappMarket)
http://twitter.com/sisbell
http://twitter.com/zappstore
http://zappmarket.com

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Shane

Kevin and I have been heavily involved in this because we both require
in-app billing for virtual items within our apps.

Actually this morning (as Kevin knows) I am trying to decide which way to
go.

I can either have my app access my website, require my users to enter
account information on my site and then download my virtual content from my
website within my app (which it will install it for them).

Or I can find a way to make my virtual content available though Market place
and have my virtual content available via apk downloads. For me (and Kevin
probably agrees) the biggest advantage of using Market place is that users
are fimular with it and if they don't have to re-enter their account
information a second time from a source they don't know much about (i.e my
site) and instead use market place so all they have to do is hit ok to
confirm that will make a HUGE difference in the amount of users that will
pay for virtual content because its a two second click VS re-entering all
their account info again from an unknown source.

As a developer of an app that is a HUGE incentive for me to use Market place
and worth the extra time for me to think of a way to make it work.

I am just trying to design a way to make the virtual content available so
they don' t end up with dosens of apk files downloaded (one for each virtual
content they purchase). I am currently thinking of an install apk app
(different than my main app to make it small and lean for downloads) that
can maybe get updates depending on which virtual content is purchased.
Then that app talks to my main app to install my virtual content that my
main app uses.

I am currently researching what is involved when you do an update to a
current apk.

That's where I currently am right now.

-Chris

On Thu, Mar 25, 2010 at 9:02 AM, Shane Isbell shane.isb...@gmail.comwrote:

I thought I'd briefly jump in on this discussion. I'm looking into
providing a virtual currency/in-app billing solution for ZappMarket.
ZappMarket is focused on paid app developers.

I'd like to talk with developers (either on-list or you can send me an
e-mail) about what your specific needs are for virtual currency and in-app
billing. Largely at a technical level in terms of APIs you would find useful
and whether you are looking for a basic set of interactions like
check_balance, pay or for something more sophisticated that would also
manage codes and virtual goods themselves.

Based on your feedback, I can put up a trial solution that we can test and
then go from there.

Thanks,
Shane Isbell (Founder of ZappMarket)
http://twitter.com/sisbell
http://twitter.com/zappstore
http://zappmarket.com

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Like Chris said, the main thing is the user experience. We all know a user
after 3 seconds of waiting for a page to show up, often goes somewhere else.
Most people are impatient. Having them fill in all that info they've already
filled out for their google checkout or paypal account, in a game or other
app, in my opinion is asking for too much. You don't want to have a game or
app require personal info to be entered. It's just not going to go over
well. I honestly don't trust any app out there that asks for my info and
uninstall it. There is just WAY too much identity theft, stolen cards being
charged, etc. Most users, I am pretty sure will think along these lines.

What we need is some sort of Paypal, google checkout or other known vendor
(not sure how many others are out there) that people are familiar with, and
are asked for basically a pin or login or something that allows them to pay
for something without the game/app knowing any of that info. There should be
no way for any game/app to store their info they enter to access the
account.

Games like World of Warcraft, or Xbox 360 where you enter your info already
when you sign up for something like xbox live, or in WOW you sign up to get
charged monthly/quarterly.. they have that info already and to play a mega
game like wow, you must do this, or to access xbox live, you must do this.
Because that info is already there, in-game purchases, like upgrading xbox
live, buying xbox money to buy expansion packs to games, etc.. is all done
very easily.

To me, there are really only two good ways to do this. One is google
provides every android device an SDK they can use to do in-app charging,
that ties to their google account. To use it, a user of an android device
would do a one time setup of google checkout. Once done, the android device
can log in automatically and allow one click charging/approval in any app
on the device that uses the SDK. However, I don't see this being something
very viable anytime soon.

The other way that makes the most sense to me and is available sort of
right now, is using a service like ScoreLoop, OpenFeint, etc, that provide a
user profile setup..where the user can fill in info including credit
card/pay pal info at the service site when setting up their profile. Once
set up, any game/app using that service allows the user to log in to their
profile. It adds the advantage of storing high scores, achievements, levels,
etc and you gain the social aspect of things like being able to publish your
new high score on some game you play to twitter/facebook, and possibly draw
in other players, etc. The main benefit tho is that the end user signs up
just once and any game/app using the service is able to allow for micro
transactions like in-game purchases with one-click approvals.

Short of those, I don't see any good alternative that will make end users of
games feel comfortable. I forget Chris if it was you that embedded a
payment web page into your app... but I don't know how else you'll get
people to fill in private info like that to buy stuff in game. If the game
is really good, I can see some players willing to go to a web site, buy
stuff, then reload the game. When they buy stuff on the site, it updates
some game DB that they now own an item, and then when they reload the game,
it hits the server and downloads any purchases they made, so that its on the
device. That still requires them to go to a website out of the game (or app)
to do this, but its a much more common/secure way that more users would be
familiar with.

I was saying earlier, being able to call the API/SDK of a checkout program
in-game would be nice because you don't take the user out of your game. But
the more I think about it, the more I feel most users would not feel safe
doing stuff in-game that allows the game to have any of their personal info.
There will be some, for sure. But I just don't think that will go over well.
That is why this profile/service thing looks promising. Sign up with
openFeint, fill in the info once, the game can use the SDK to allow in-game
purchases.

On Thu, Mar 25, 2010 at 8:50 AM, chris harper ch393...@gmail.com wrote:

 Shane

 Kevin and I have been heavily involved in this because we both require
 in-app billing for virtual items within our apps.

 Actually this morning (as Kevin knows) I am trying to decide which way to
 go.

 I can either have my app access my website, require my users to enter
 account information on my site and then download my virtual content from my
 website within my app (which it will install it for them).

 Or I can find a way to make my virtual content available though Market
 place and have my virtual content available via apk downloads.  For me (and
 Kevin probably agrees) the biggest advantage of using Market place is that
 users are fimular with it and if they don't have to re-enter their account
 information a second time from a source they don't know much about (i.e my
 site) and instead use market place

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Frank

Yes it was me that had the payment web page into your app but I am about
90% sure I am going to change to somehow use Market place.
For the main reason that I don't think I will get near as many people buying
my characters for my app if they have to enter their payment info into my
app at my website.

I think I need to find a way to make my characters available via market
place so I can use the market place payment. Like I said I am trying to
design an install app to work with my main app.

Maybe they buy the install app, download it and the install app knows how to
download and install my characters from my site based on what the user
picked within the main app?

There has to be a way to do this.

I am good at digging until I find it.

-Chris


On Thu, Mar 25, 2010 at 10:59 AM, Kevin Duffey andjar...@gmail.com wrote:

 Like Chris said, the main thing is the user experience. We all know a user
 after 3 seconds of waiting for a page to show up, often goes somewhere else.
 Most people are impatient. Having them fill in all that info they've already
 filled out for their google checkout or paypal account, in a game or other
 app, in my opinion is asking for too much. You don't want to have a game or
 app require personal info to be entered. It's just not going to go over
 well. I honestly don't trust any app out there that asks for my info and
 uninstall it. There is just WAY too much identity theft, stolen cards being
 charged, etc. Most users, I am pretty sure will think along these lines.

 What we need is some sort of Paypal, google checkout or other known vendor
 (not sure how many others are out there) that people are familiar with, and
 are asked for basically a pin or login or something that allows them to pay
 for something without the game/app knowing any of that info. There should be
 no way for any game/app to store their info they enter to access the
 account.

 Games like World of Warcraft, or Xbox 360 where you enter your info already
 when you sign up for something like xbox live, or in WOW you sign up to get
 charged monthly/quarterly.. they have that info already and to play a mega
 game like wow, you must do this, or to access xbox live, you must do this.
 Because that info is already there, in-game purchases, like upgrading xbox
 live, buying xbox money to buy expansion packs to games, etc.. is all done
 very easily.

 To me, there are really only two good ways to do this. One is google
 provides every android device an SDK they can use to do in-app charging,
 that ties to their google account. To use it, a user of an android device
 would do a one time setup of google checkout. Once done, the android device
 can log in automatically and allow one click charging/approval in any app
 on the device that uses the SDK. However, I don't see this being something
 very viable anytime soon.

 The other way that makes the most sense to me and is available sort of
 right now, is using a service like ScoreLoop, OpenFeint, etc, that provide a
 user profile setup..where the user can fill in info including credit
 card/pay pal info at the service site when setting up their profile. Once
 set up, any game/app using that service allows the user to log in to their
 profile. It adds the advantage of storing high scores, achievements, levels,
 etc and you gain the social aspect of things like being able to publish your
 new high score on some game you play to twitter/facebook, and possibly draw
 in other players, etc. The main benefit tho is that the end user signs up
 just once and any game/app using the service is able to allow for micro
 transactions like in-game purchases with one-click approvals.

 Short of those, I don't see any good alternative that will make end users
 of games feel comfortable. I forget Chris if it was you that embedded a
 payment web page into your app... but I don't know how else you'll get
 people to fill in private info like that to buy stuff in game. If the game
 is really good, I can see some players willing to go to a web site, buy
 stuff, then reload the game. When they buy stuff on the site, it updates
 some game DB that they now own an item, and then when they reload the game,
 it hits the server and downloads any purchases they made, so that its on the
 device. That still requires them to go to a website out of the game (or app)
 to do this, but its a much more common/secure way that more users would be
 familiar with.

 I was saying earlier, being able to call the API/SDK of a checkout program
 in-game would be nice because you don't take the user out of your game. But
 the more I think about it, the more I feel most users would not feel safe
 doing stuff in-game that allows the game to have any of their personal info.
 There will be some, for sure. But I just don't think that will go over well.
 That is why this profile/service thing looks promising. Sign up with
 openFeint, fill in the info once, the game can use the SDK to allow in-game
 purchases.

 On Thu,

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

2010-03-25 Thread Shane Isbell

Hi Chris,

One other problem that may occur is that users purchase additional APKs (or
virtual goods) and then after receiving them, simply ask for a refund on the
APK. This allows them to keep your installer and main app and get as many
add-ons and additional content as they want for free. There is no way to
revoke the content once a refund has been issued.

Shane

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

2010-03-25 Thread Disconnect

Sure there is - when you load the saved game (or the app, or whatever) check
the content (characters, etc) against the installed applications.

On Thu, Mar 25, 2010 at 2:14 PM, Shane Isbell shane.isb...@gmail.comwrote:

 Hi Chris,

 One other problem that may occur is that users purchase additional APKs (or
 virtual goods) and then after receiving them, simply ask for a refund on the
 APK. This allows them to keep your installer and main app and get as many
 add-ons and additional content as they want for free. There is no way to
 revoke the content once a refund has been issued.

 Shane

  --
 You received this message because you are subscribed to the Google
 Groups Android Developers group.
 To post to this group, send email to android-developers@googlegroups.com
 To unsubscribe from this group, send email to
 android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

 To unsubscribe from this group, send email to android-developers+
 unsubscribegooglegroups.com or reply to this email with the words REMOVE
 ME as the subject.


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

So.. would a gamer service that provides microtransaction support where a
user sets up a profile + credit/card/googlecheckout/paypal info.. once.. be
a better choice?

On Thu, Mar 25, 2010 at 11:29 AM, Disconnect dc.disconn...@gmail.comwrote:

Sure there is - when you load the saved game (or the app, or whatever)
check the content (characters, etc) against the installed applications.

On Thu, Mar 25, 2010 at 2:14 PM, Shane Isbell shane.isb...@gmail.comwrote:

Hi Chris,

One other problem that may occur is that users purchase additional APKs
(or virtual goods) and then after receiving them, simply ask for a refund on
the APK. This allows them to keep your installer and main app and get as
many add-ons and additional content as they want for free. There is no way
to revoke the content once a refund has been issued.

Shane

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

2010-03-25 Thread Shane Isbell

On Thu, Mar 25, 2010 at 11:29 AM, Disconnect dc.disconn...@gmail.comwrote:

 Sure there is - when you load the saved game (or the app, or whatever)
 check the content (characters, etc) against the installed applications.

Then you are back to the case of having a bunch of apks installed on the
user's device, which I believe was the issue Chris was trying to avoid. In
any case, it looks like a tricky problem to get this to work in Android
Market without Google's blessing.


 On Thu, Mar 25, 2010 at 2:14 PM, Shane Isbell shane.isb...@gmail.comwrote:

 Hi Chris,

 One other problem that may occur is that users purchase additional APKs
 (or virtual goods) and then after receiving them, simply ask for a refund on
 the APK. This allows them to keep your installer and main app and get as
 many add-ons and additional content as they want for free. There is no way
 to revoke the content once a refund has been issued.

 Shane

  --
 You received this message because you are subscribed to the Google
 Groups Android Developers group.
 To post to this group, send email to android-developers@googlegroups.com
 To unsubscribe from this group, send email to
 android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

 To unsubscribe from this group, send email to android-developers+
 unsubscribegooglegroups.com or reply to this email with the words REMOVE
 ME as the subject.


  --
 You received this message because you are subscribed to the Google
 Groups Android Developers group.
 To post to this group, send email to android-developers@googlegroups.com
 To unsubscribe from this group, send email to
 android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

 To unsubscribe from this group, send email to android-developers+
 unsubscribegooglegroups.com or reply to this email with the words REMOVE
 ME as the subject.




-- 
Shane Isbell (Founder of ZappMarket)
http://twitter.com/sisbell
http://twitter.com/zappstore
http://zappmarket.com

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Thank you for all the interest guys. Really it helps and it can help feature
developers down the road.

Shane it is tricky and I don't want to do against Googles blessing but their
lack of direction (or more like NO direction) on what developers should do
for virtual content has kind of backed us into this corner of how can I
provide virtual content for my app?.

I THINK I am close.

The instructions for the characters are stored in the sqlite database. Where
the instructions for each character contain how to move, what images to use,
what sounds to play, different animation characteristics for each etc... but
the logic to RUN the instructions are in the main app. Hince the characters
are modules that my app uses.

Now to do this via Market place I am thinking that I have to create a
different apk intall file for each character.

Where in my main app I am using webview to go to my site to view additoinal
characters but once they select a character from my website then actual
checkout can be linked to the Market and to the .apk “installer” for just
that character.
They select the ok, they download the .apk for that character. Then the
user (or maybe my main app can run the .apk installer pragmatically) runs the
install .apk. That runs which populates the database (which is used buy
the main app) with the character instructions and the installer places the
images and sounds on the phone for the main program to access for that
character. Now the character is installed.

Now that would create a ton of .apk install app's on the phone (one for
each character). But I did find where a .apk can uninstall itself via:

*Uri packageURI = Uri.parse(package:com.android.myapp);
Intent uninstallIntent = new Intent(Intent.ACTION_DELETE, packageURI);* *
* *startActivity(uninstallIntent);*

* *

*So after each install runs and installs the character then the installer
for that character can then remove itself. *

*Where I don’t need the installer to uninstall the character. The Main App
has that functionality.*

* *

*The problem I have is when the install app uninstall’s itself it asks for
permission (which it should), but that can be confusing for the user who
JUST download it (and now it’s asking to be uninstalled??)*

* *

*So I think I am in the ballpark, unless anyone sees anything I have
overlooked?*

*-Chris
*

On Thu, Mar 25, 2010 at 12:56 PM, Shane Isbell shane.isb...@gmail.comwrote:

On Thu, Mar 25, 2010 at 11:29 AM, Disconnect dc.disconn...@gmail.comwrote:

Sure there is - when you load the saved game (or the app, or whatever)
check the content (characters, etc) against the installed applications.

Then you are back to the case of having a bunch of apks installed on the
user's device, which I believe was the issue Chris was trying to avoid. In
any case, it looks like a tricky problem to get this to work in Android
Market without Google's blessing.

On Thu, Mar 25, 2010 at 2:14 PM, Shane Isbell shane.isb...@gmail.comwrote:

Hi Chris,

Shane

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words
REMOVE ME as the subject.

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
Shane Isbell (Founder of ZappMarket)
http://twitter.com/sisbell
http://twitter.com/zappstore
http://zappmarket.com

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Will an uninstall trigger a refund? If so maybe I just don't do a refund? I
don't deal with it?

Is that an option? Can we do that?

I plan on only charging .99 for a character.

My main free app will contain two default characters (to get the user
hooked).

So if they really likes the app and they think the characters are funny (I
have spent a lot of time on them) then they are more likely to still buy
another one if there is no refund...because it's ONLY  .99 after all??

What do you think? Great point though. Thank you.






On Thu, Mar 25, 2010 at 2:22 PM, Warren warrenba...@gmail.com wrote:

 *So I think I am in the ballpark, unless anyone sees anything I have
 overlooked?*


 I think you overlooked something big. You plan to leave the data on
 the phone and uninstall the app. That works. But suppose I download
 the a character app, install the character, then immediately refund?
 Wouldn't I keep the character data?

 Also, if you auto-uninstall within the refund period, will that
 trigger a refund?

 If so, you guarantee 0 revenue.



 On Mar 25, 3:14 pm, chris harper ch393...@gmail.com wrote:
  Thank you for all the interest guys. Really it helps and it can help
 feature
  developers down the road.
 
  Shane it is tricky and I don't want to do against Googles blessing but
 their
  lack of direction (or more like NO direction) on what developers should
 do
  for virtual content has kind of backed us into this corner of how can I
  provide virtual content for my app?.
 
  I THINK I am close.
 
  The instructions for the characters are stored in the sqlite database.
 Where
  the instructions for each character contain how to move, what images to
 use,
  what sounds to play, different animation characteristics for each etc...
 but
  the logic to RUN the instructions are in the main app. Hince the
 characters
  are modules that my app uses.
 
  Now to do this via Market place I am thinking that I have to create a
  different apk intall file for each character.
 
  Where in my main app I am using webview to go to my site to view
 additoinal
  characters but once they select a character from my website then actual
  checkout can be linked to  the Market and to the .apk “installer” for
 just
  that character.
  They select the ok, they download the .apk for that character. Then the
  user (or maybe my main app can run the .apk  installer pragmatically)
 runs  the
  install .apk. That  runs which populates the database (which is used
 buy
  the main app) with the character instructions and the installer places
 the
  images and sounds on the phone for the main program to access for that
  character. Now the character is installed.
 
  Now that would create a ton of .apk install app's on the phone (one for
  each character). But  I did find where a .apk can uninstall itself via:
 
  *Uri packageURI = Uri.parse(package:com.android.myapp);
  Intent uninstallIntent = new Intent(Intent.ACTION_DELETE, packageURI);* *
  * *startActivity(uninstallIntent);*
 
  * *
 
  *So after each install runs and installs the character then the installer
  for that character can then remove itself. *
 
  *Where I don’t need the installer to uninstall the character. The Main
 App
  has that functionality.*
 
  * *
 
  *The problem I have is when the install app uninstall’s itself  it asks
 for
  permission (which it should), but that can be confusing for the user who
  JUST download it (and now it’s asking to be uninstalled??)*
 
  * *
 
  *So I think I am in the ballpark, unless anyone sees anything I have
  overlooked?*
 
  **
 
  **
 
  *-Chris
  *
 
  On Thu, Mar 25, 2010 at 12:56 PM, Shane Isbell shane.isb...@gmail.com
 wrote:
 
 
 
   On Thu, Mar 25, 2010 at 11:29 AM, Disconnect dc.disconn...@gmail.com
 wrote:
 
   Sure there is - when you load the saved game (or the app, or whatever)
   check the content (characters, etc) against the installed
 applications.
 
   Then you are back to the case of having a bunch of apks installed on
 the
   user's device, which I believe was the issue Chris was trying to avoid.
 In
   any case, it looks like a tricky problem to get this to work in Android
   Market without Google's blessing.
 
   On Thu, Mar 25, 2010 at 2:14 PM, Shane Isbell shane.isb...@gmail.com
 wrote:
 
   Hi Chris,
 
   One other problem that may occur is that users purchase additional
 APKs
   (or virtual goods) and then after receiving them, simply ask for a
 refund on
   the APK. This allows them to keep your installer and main app and get
 as
   many add-ons and additional content as they want for free. There is
 no way
   to revoke the content once a refund has been issued.
 
   Shane
 
--
   You received this message because you are subscribed to the Google
   Groups Android Developers group.
   To post to this group, send email to
 android-developers@googlegroups.com
   To unsubscribe from this group, send email to

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Warren

I think you are right. I think if I do an uninstall on the app before the 24
hour period then it refunds. Thanks for catching that.

Which leaves only one option.

The install app can have two buttons on it.
One to: Remove just the Install app
and another to: Remove the install app AND the Character

So the USER has the option of removing either just the install app (so the
phone doesn't get cluttered with apk install files) OR removing the install
app AND the character.

If they select EITHER button before the the 24 hour period for a refund then
both the install app and the character are removed.

Which this can all be explained to the user within the install app.

That should work. I would think?

Rob
I just took a look at them. The MAIN thing I am trying to accomplish is to
make my characters available without requiring the user to enter finical
information again.

 I really believe if they don't have to do that and instead they just click
on submit to buy another character that will make a HUGE difference in the
amount of people that will buy my characters because its a two second thing
for them.

They are at the DMV for example and board and like the characters in my app
(which they downloaded because it was free), so why not try another
character for .99 if they just have to click ok??

If I can just make it as seem-less as possible for an install apk to work
with my main app this would be a great thing (as well as other developers
like Warren).

-Chris

On Thu, Mar 25, 2010 at 2:58 PM, Rob Mazur r...@mobalyze.net wrote:

 Chris, have you tried creating an account on ScoreLoop? Once logged in
 they have a note at the bottom about their Android SDK. They are
 making it available to a few developers and you can email them if you
 are interested.

 IMO, until Google builds an in-app payment system, the best bet is to
 go with a company like ScoreLoop. I did read somewhere that they take
 a pretty hefty cut, but I don't know of any other options out there. I
 checked out OpenFeint but didn't see anything about Android. Plus this
 should only be temporary cuz it just wouldn't make sense for Google to
 miss out on the potential revenue available.


 On Mar 25, 4:36 pm, chris harper ch393...@gmail.com wrote:
  Will an uninstall trigger a refund? If so maybe I just don't do a refund?
 I
  don't deal with it?
 
  Is that an option? Can we do that?
 
  I plan on only charging .99 for a character.
 
  My main free app will contain two default characters (to get the user
  hooked).
 
  So if they really likes the app and they think the characters are funny
 (I
  have spent a lot of time on them) then they are more likely to still buy
  another one if there is no refund...because it's ONLY  .99 after all??
 
  What do you think? Great point though. Thank you.
 
 
 
  On Thu, Mar 25, 2010 at 2:22 PM, Warren warrenba...@gmail.com wrote:
   *So I think I am in the ballpark, unless anyone sees anything I have
   overlooked?*
 
   I think you overlooked something big. You plan to leave the data on
   the phone and uninstall the app. That works. But suppose I download
   the a character app, install the character, then immediately refund?
   Wouldn't I keep the character data?
 
   Also, if you auto-uninstall within the refund period, will that
   trigger a refund?
 
   If so, you guarantee 0 revenue.
 
   On Mar 25, 3:14 pm, chris harper ch393...@gmail.com wrote:
Thank you for all the interest guys. Really it helps and it can help
   feature
developers down the road.
 
Shane it is tricky and I don't want to do against Googles blessing
 but
   their
lack of direction (or more like NO direction) on what developers
 should
   do
for virtual content has kind of backed us into this corner of how
 can I
provide virtual content for my app?.
 
I THINK I am close.
 
The instructions for the characters are stored in the sqlite
 database.
   Where
the instructions for each character contain how to move, what images
 to
   use,
what sounds to play, different animation characteristics for each
 etc...
   but
the logic to RUN the instructions are in the main app. Hince the
   characters
are modules that my app uses.
 
Now to do this via Market place I am thinking that I have to create a
different apk intall file for each character.
 
Where in my main app I am using webview to go to my site to view
   additoinal
characters but once they select a character from my website then
 actual
checkout can be linked to  the Market and to the .apk “installer” for
   just
that character.
They select the ok, they download the .apk for that character. Then
 the
user (or maybe my main app can run the .apk  installer pragmatically)
   runs  the
install .apk. That  runs which populates the database (which is
 used
   buy
the main app) with the character instructions and the installer
 places
   the
images and sounds on the phone for the main program

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Uninstall time is 48 hours for refund. I think it might have been 24 and
moved to 48.. not sure about that.

Chris, while I agree making it as seamless as possible is the goal, I think
we're up against a corner right now on Android. I think what you are doing
is admirable, but may be overly complex for end users as opposed to them
setting up on ScoreLoop for example. I only say that because it will only be
a matter of time before more games use ScoreLoop or another serivce, and
once a user is set up on ScoreLoop, other games will only require them to
log in and reap all the benefits of ScoreLoop or other similar services.
Of course, if the end user has games that all use different services, they
would have to set up the info for each service... but that's far better than
them having to do it for every game they ever buy.


On Thu, Mar 25, 2010 at 2:11 PM, chris harper ch393...@gmail.com wrote:

 Warren

 I think you are right. I think if I do an uninstall on the app before the
 24 hour period then it refunds. Thanks for catching that.

 Which leaves only one option.

 The install app can have two buttons on it.
 One to: Remove just the Install app
 and another to: Remove the install app AND the Character

 So the USER has the option of removing either just the install app (so the
 phone doesn't get cluttered with apk install files) OR removing the install
 app AND the character.

 If they select EITHER button before the the 24 hour period for a refund
 then both the install app and the character are removed.

 Which this can all be explained to the user within the install app.

 That should work. I would think?

 Rob
 I just took a look at them. The MAIN thing I am trying to accomplish is to
 make my characters available without requiring the user to enter finical
 information again.

  I really believe if they don't have to do that and instead they just click
 on submit to buy another character that will make a HUGE difference in the
 amount of people that will buy my characters because its a two second thing
 for them.

 They are at the DMV for example and board and like the characters in my app
 (which they downloaded because it was free), so why not try another
 character for .99 if they just have to click ok??

 If I can just make it as seem-less as possible for an install apk to work
 with my main app this would be a great thing (as well as other developers
 like Warren).

 -Chris


 On Thu, Mar 25, 2010 at 2:58 PM, Rob Mazur r...@mobalyze.net wrote:

 Chris, have you tried creating an account on ScoreLoop? Once logged in
 they have a note at the bottom about their Android SDK. They are
 making it available to a few developers and you can email them if you
 are interested.

 IMO, until Google builds an in-app payment system, the best bet is to
 go with a company like ScoreLoop. I did read somewhere that they take
 a pretty hefty cut, but I don't know of any other options out there. I
 checked out OpenFeint but didn't see anything about Android. Plus this
 should only be temporary cuz it just wouldn't make sense for Google to
 miss out on the potential revenue available.


 On Mar 25, 4:36 pm, chris harper ch393...@gmail.com wrote:
  Will an uninstall trigger a refund? If so maybe I just don't do a
 refund? I
  don't deal with it?
 
  Is that an option? Can we do that?
 
  I plan on only charging .99 for a character.
 
  My main free app will contain two default characters (to get the user
  hooked).
 
  So if they really likes the app and they think the characters are funny
 (I
  have spent a lot of time on them) then they are more likely to still buy
  another one if there is no refund...because it's ONLY  .99 after all??
 
  What do you think? Great point though. Thank you.
 
 
 
  On Thu, Mar 25, 2010 at 2:22 PM, Warren warrenba...@gmail.com wrote:
   *So I think I am in the ballpark, unless anyone sees anything I have
   overlooked?*
 
   I think you overlooked something big. You plan to leave the data on
   the phone and uninstall the app. That works. But suppose I download
   the a character app, install the character, then immediately refund?
   Wouldn't I keep the character data?
 
   Also, if you auto-uninstall within the refund period, will that
   trigger a refund?
 
   If so, you guarantee 0 revenue.
 
   On Mar 25, 3:14 pm, chris harper ch393...@gmail.com wrote:
Thank you for all the interest guys. Really it helps and it can help
   feature
developers down the road.
 
Shane it is tricky and I don't want to do against Googles blessing
 but
   their
lack of direction (or more like NO direction) on what developers
 should
   do
for virtual content has kind of backed us into this corner of how
 can I
provide virtual content for my app?.
 
I THINK I am close.
 
The instructions for the characters are stored in the sqlite
 database.
   Where
the instructions for each character contain how to move, what images
 to
   use,
what sounds to play, different

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

I wonder if removing the .apks will bring up other issues, like updates? For
example, maybe not for your specific app, but what if a character .apk has a
bug in it.. you fix it.. but end users have uninstalled. Now they will have
to pay/reinstall again to get the updated toon even if they already
paid/installed before.

Honestly Chris I don't think this is a viable solution. It's close, but
not quite there due to the variations of issue that may arise from removing
the .apk.

Here's a thought.. do you have a server side at all? If not, do you know
enough server side to do a quick appengine or, I found a host that charges I
think $15 a month to host a web app on a tomcat 6 server (I'll have to dig
it up again)... the idea is.. make a simple server side app that stores a
user's paid-for characters in a DB. That is.. the user goes to your site,
pays for a toon. You then update (in some secure/encrypted manner) the DB
for that user that they own that character. The next time they launch the
game, some how it pulls the server and down comes any new toons they paid
for. You can even allow for an SMS push notification that if they don't have
a wifi/3G connection, but do have cell.. your game could listen for SMS
messages (or a separate service piece to your game) and your server piece
can send an SMS message (not sure what API/service allows for this to work
tho) that when received updates the game for that user. Worse case, they
don't have SMS enabled services.. and no internet.. then they have to wait
till they do to get the character toons. Heck, they cant use the market to
buy them either without network.. so no loss there.


On Thu, Mar 25, 2010 at 2:31 PM, Rob Mazur r...@mobalyze.net wrote:

 Maybe you could store the date you detected the new apk in the prefs
 and say after refund period has expired you throw a dialog that tells
 the user they can now uninstall the addon pack.

 So for a few days (2 or 3 to be safe) your code checks that the apk is
 still there, if not then remove the character. Once the refund period
 has expired you throw up the dialog and can even kickoff the uninstall
 nicely with an intent. In your app description just make sure to
 inform them that they should not uninstall until directed, otherwise
 they will lose the character. But that the app will notify them when
 they can safely uninstall.

 On Mar 25, 5:11 pm, chris harper ch393...@gmail.com wrote:
  Warren
 
  I think you are right. I think if I do an uninstall on the app before the
 24
  hour period then it refunds. Thanks for catching that.
 
  Which leaves only one option.
 
  The install app can have two buttons on it.
  One to: Remove just the Install app
  and another to: Remove the install app AND the Character
 
  So the USER has the option of removing either just the install app (so
 the
  phone doesn't get cluttered with apk install files) OR removing the
 install
  app AND the character.
 
  If they select EITHER button before the the 24 hour period for a refund
 then
  both the install app and the character are removed.
 
  Which this can all be explained to the user within the install app.
 
  That should work. I would think?
 
  Rob
  I just took a look at them. The MAIN thing I am trying to accomplish is
 to
  make my characters available without requiring the user to enter finical
  information again.
 
   I really believe if they don't have to do that and instead they just
 click
  on submit to buy another character that will make a HUGE difference in
 the
  amount of people that will buy my characters because its a two second
 thing
  for them.
 
  They are at the DMV for example and board and like the characters in my
 app
  (which they downloaded because it was free), so why not try another
  character for .99 if they just have to click ok??
 
  If I can just make it as seem-less as possible for an install apk to
 work
  with my main app this would be a great thing (as well as other developers
  like Warren).
 
  -Chris
 
 
 
  On Thu, Mar 25, 2010 at 2:58 PM, Rob Mazur r...@mobalyze.net wrote:
   Chris, have you tried creating an account on ScoreLoop? Once logged in
   they have a note at the bottom about their Android SDK. They are
   making it available to a few developers and you can email them if you
   are interested.
 
   IMO, until Google builds an in-app payment system, the best bet is to
   go with a company like ScoreLoop. I did read somewhere that they take
   a pretty hefty cut, but I don't know of any other options out there. I
   checked out OpenFeint but didn't see anything about Android. Plus this
   should only be temporary cuz it just wouldn't make sense for Google to
   miss out on the potential revenue available.
 
   On Mar 25, 4:36 pm, chris harper ch393...@gmail.com wrote:
Will an uninstall trigger a refund? If so maybe I just don't do a
 refund?
   I
don't deal with it?
 
Is that an option? Can we do that?
 
I plan on only charging .99 for a character.
 
My

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Thanks guys



Rob/Kevin



You guys are really give me some ideas here.



Thank you for the advice on score loop but I don’t think I can user it
because my app doesn’t keep scores or interact with my app on other phones.
It’s not really a game.

So I am not sure if that will benefit me? I looked though scoreloop but it
looks like it is for comparing scores with other users within a social
network. Am I right?



Rob – I was actually thinking right along that same track. Each install app
keeps a timer of itself when it was installed and asks to be uninstalled
after 48 hours, BUT makes it clear to the user that uninstalling the install
app does NOT remove the character from the main app.



Kevin -  you gave me a great idea very close to what you suggested. I do
have a server side set up. Like I said I have a website set up with a
shopping cart and everything where I WAS going to make people buy/download
my characters from there.



What if the install .apk not only installs the character like I stated but
also takes the user ID from the database on the phone (which both the
install .apk and the main program share the same sqlite DB) and it sends the
information to the sever like you suggested that this user ID OWNS this
character. So any updates to this character get sent to this user.  If they
uninstall the install app before the 48 hours (for the refund) then before
it uninstalls it updates the server they do not own this character anymore
and this character was removed.



If they remove the .apk install app after the 48 hours (via the prompt like
Rob suggested) they still own the character and get any updates. The
character is not tied with the .apk after the initial install.



They can still remove the character from the main app at any time and that
will also tell the server that they do not own the character anymore.



What do you guys think?


On Thu, Mar 25, 2010 at 3:38 PM, Kevin Duffey andjar...@gmail.com wrote:

 I wonder if removing the .apks will bring up other issues, like updates?
 For example, maybe not for your specific app, but what if a character .apk
 has a bug in it.. you fix it.. but end users have uninstalled. Now they will
 have to pay/reinstall again to get the updated toon even if they already
 paid/installed before.

 Honestly Chris I don't think this is a viable solution. It's close, but
 not quite there due to the variations of issue that may arise from removing
 the .apk.

 Here's a thought.. do you have a server side at all? If not, do you know
 enough server side to do a quick appengine or, I found a host that charges I
 think $15 a month to host a web app on a tomcat 6 server (I'll have to dig
 it up again)... the idea is.. make a simple server side app that stores a
 user's paid-for characters in a DB. That is.. the user goes to your site,
 pays for a toon. You then update (in some secure/encrypted manner) the DB
 for that user that they own that character. The next time they launch the
 game, some how it pulls the server and down comes any new toons they paid
 for. You can even allow for an SMS push notification that if they don't have
 a wifi/3G connection, but do have cell.. your game could listen for SMS
 messages (or a separate service piece to your game) and your server piece
 can send an SMS message (not sure what API/service allows for this to work
 tho) that when received updates the game for that user. Worse case, they
 don't have SMS enabled services.. and no internet.. then they have to wait
 till they do to get the character toons. Heck, they cant use the market to
 buy them either without network.. so no loss there.



 On Thu, Mar 25, 2010 at 2:31 PM, Rob Mazur r...@mobalyze.net wrote:

 Maybe you could store the date you detected the new apk in the prefs
 and say after refund period has expired you throw a dialog that tells
 the user they can now uninstall the addon pack.

 So for a few days (2 or 3 to be safe) your code checks that the apk is
 still there, if not then remove the character. Once the refund period
 has expired you throw up the dialog and can even kickoff the uninstall
 nicely with an intent. In your app description just make sure to
 inform them that they should not uninstall until directed, otherwise
 they will lose the character. But that the app will notify them when
 they can safely uninstall.

 On Mar 25, 5:11 pm, chris harper ch393...@gmail.com wrote:
  Warren
 
  I think you are right. I think if I do an uninstall on the app before
 the 24
  hour period then it refunds. Thanks for catching that.
 
  Which leaves only one option.
 
  The install app can have two buttons on it.
  One to: Remove just the Install app
  and another to: Remove the install app AND the Character
 
  So the USER has the option of removing either just the install app (so
 the
  phone doesn't get cluttered with apk install files) OR removing the
 install
  app AND the character.
 
  If they select EITHER button before the the 24 hour period for a refund

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Is there a way to be notified of uninstalls? I thought there wasnt?

On Thu, Mar 25, 2010 at 3:51 PM, westmeadboy westmead...@yahoo.co.ukwrote:

 What is your specific reason for wanting to uninstall the character
 apps?

 You can make sure that they do not appear in the app drawer by using
 the relevant intent filter. That would only leave them visible to the
 user when they do something like Settings - Applications or look in
 the Downloads of the Market app.

 On Mar 25, 11:09 pm, chris harper ch393...@gmail.com wrote:
  Thanks guys
 
  Rob/Kevin
 
  You guys are really give me some ideas here.
 
  Thank you for the advice on score loop but I don’t think I can user it
  because my app doesn’t keep scores or interact with my app on other
 phones.
  It’s not really a game.
 
  So I am not sure if that will benefit me? I looked though scoreloop but
 it
  looks like it is for comparing scores with other users within a social
  network. Am I right?
 
  Rob – I was actually thinking right along that same track. Each install
 app
  keeps a timer of itself when it was installed and asks to be uninstalled
  after 48 hours, BUT makes it clear to the user that uninstalling the
 install
  app does NOT remove the character from the main app.
 
  Kevin -  you gave me a great idea very close to what you suggested. I do
  have a server side set up. Like I said I have a website set up with a
  shopping cart and everything where I WAS going to make people
 buy/download
  my characters from there.
 
  What if the install .apk not only installs the character like I stated
 but
  also takes the user ID from the database on the phone (which both the
  install .apk and the main program share the same sqlite DB) and it sends
 the
  information to the sever like you suggested that this user ID OWNS this
  character. So any updates to this character get sent to this user.  If
 they
  uninstall the install app before the 48 hours (for the refund) then
 before
  it uninstalls it updates the server they do not own this character
 anymore
  and this character was removed.
 
  If they remove the .apk install app after the 48 hours (via the prompt
 like
  Rob suggested) they still own the character and get any updates. The
  character is not tied with the .apk after the initial install.
 
  They can still remove the character from the main app at any time and
 that
  will also tell the server that they do not own the character anymore.
 
  What do you guys think?
 
 
 
  On Thu, Mar 25, 2010 at 3:38 PM, Kevin Duffey andjar...@gmail.com
 wrote:
   I wonder if removing the .apks will bring up other issues, like
 updates?
   For example, maybe not for your specific app, but what if a character
 .apk
   has a bug in it.. you fix it.. but end users have uninstalled. Now they
 will
   have to pay/reinstall again to get the updated toon even if they
 already
   paid/installed before.
 
   Honestly Chris I don't think this is a viable solution. It's close,
 but
   not quite there due to the variations of issue that may arise from
 removing
   the .apk.
 
   Here's a thought.. do you have a server side at all? If not, do you
 know
   enough server side to do a quick appengine or, I found a host that
 charges I
   think $15 a month to host a web app on a tomcat 6 server (I'll have to
 dig
   it up again)... the idea is.. make a simple server side app that stores
 a
   user's paid-for characters in a DB. That is.. the user goes to your
 site,
   pays for a toon. You then update (in some secure/encrypted manner) the
 DB
   for that user that they own that character. The next time they launch
 the
   game, some how it pulls the server and down comes any new toons they
 paid
   for. You can even allow for an SMS push notification that if they don't
 have
   a wifi/3G connection, but do have cell.. your game could listen for SMS
   messages (or a separate service piece to your game) and your server
 piece
   can send an SMS message (not sure what API/service allows for this to
 work
   tho) that when received updates the game for that user. Worse case,
 they
   don't have SMS enabled services.. and no internet.. then they have to
 wait
   till they do to get the character toons. Heck, they cant use the market
 to
   buy them either without network.. so no loss there.
 
   On Thu, Mar 25, 2010 at 2:31 PM, Rob Mazur r...@mobalyze.net wrote:
 
   Maybe you could store the date you detected the new apk in the prefs
   and say after refund period has expired you throw a dialog that tells
   the user they can now uninstall the addon pack.
 
   So for a few days (2 or 3 to be safe) your code checks that the apk is
   still there, if not then remove the character. Once the refund period
   has expired you throw up the dialog and can even kickoff the uninstall
   nicely with an intent. In your app description just make sure to
   inform them that they should not uninstall until directed, otherwise
   they will lose the character. But that the app will

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Warren you comments are always welcome. Thank you

The way I am thinking of it is different.

If the user uninstalls the Install app within 48 it removes BOTH the install
app and the character and lets the server know that this user does not own
this character anymore.

So in your example the character will be uninstalled.

After 48 hours they can just remove the Install App which will NOT update
the server, so the user still owns the character and it is still installed.

So when the main app starts up again (48 hours or a week later) it reads the
database to reads in the installed characters.

I think that will work. Actually. Right?

I'll check and try the uninstall intent thank you.

On Thu, Mar 25, 2010 at 4:39 PM, Warren warrenba...@gmail.com wrote:

 I think there's an uninstall intent that you can hook into. If you go
 this route, you should check into that, because there are other ways
 to uninstall your app than through the interface you set up.

 Here's an example of how this could go wrong (not trying to be overly
 negative, just trying to help)

 user installs character app which creates timestamp and installs data
 user uninstalls character app manually within 48 hours
 user does not use main app for 48 hours
 the main app checks the timestamp and sees that 48 hours have elapsed,
 so the data can be kept and used



 On Mar 25, 5:09 pm, chris harper ch393...@gmail.com wrote:
  Thanks guys
 
  Rob/Kevin
 
  You guys are really give me some ideas here.
 
  Thank you for the advice on score loop but I don’t think I can user it
  because my app doesn’t keep scores or interact with my app on other
 phones.
  It’s not really a game.
 
  So I am not sure if that will benefit me? I looked though scoreloop but
 it
  looks like it is for comparing scores with other users within a social
  network. Am I right?
 
  Rob – I was actually thinking right along that same track. Each install
 app
  keeps a timer of itself when it was installed and asks to be uninstalled
  after 48 hours, BUT makes it clear to the user that uninstalling the
 install
  app does NOT remove the character from the main app.
 
  Kevin -  you gave me a great idea very close to what you suggested. I do
  have a server side set up. Like I said I have a website set up with a
  shopping cart and everything where I WAS going to make people
 buy/download
  my characters from there.
 
  What if the install .apk not only installs the character like I stated
 but
  also takes the user ID from the database on the phone (which both the
  install .apk and the main program share the same sqlite DB) and it sends
 the
  information to the sever like you suggested that this user ID OWNS this
  character. So any updates to this character get sent to this user.  If
 they
  uninstall the install app before the 48 hours (for the refund) then
 before
  it uninstalls it updates the server they do not own this character
 anymore
  and this character was removed.
 
  If they remove the .apk install app after the 48 hours (via the prompt
 like
  Rob suggested) they still own the character and get any updates. The
  character is not tied with the .apk after the initial install.
 
  They can still remove the character from the main app at any time and
 that
  will also tell the server that they do not own the character anymore.
 
  What do you guys think?
 
  On Thu, Mar 25, 2010 at 3:38 PM, Kevin Duffey andjar...@gmail.com
 wrote:
   I wonder if removing the .apks will bring up other issues, like
 updates?
   For example, maybe not for your specific app, but what if a character
 .apk
   has a bug in it.. you fix it.. but end users have uninstalled. Now they
 will
   have to pay/reinstall again to get the updated toon even if they
 already
   paid/installed before.
 
   Honestly Chris I don't think this is a viable solution. It's close,
 but
   not quite there due to the variations of issue that may arise from
 removing
   the .apk.
 
   Here's a thought.. do you have a server side at all? If not, do you
 know
   enough server side to do a quick appengine or, I found a host that
 charges I
   think $15 a month to host a web app on a tomcat 6 server (I'll have to
 dig
   it up again)... the idea is.. make a simple server side app that stores
 a
   user's paid-for characters in a DB. That is.. the user goes to your
 site,
   pays for a toon. You then update (in some secure/encrypted manner) the
 DB
   for that user that they own that character. The next time they launch
 the
   game, some how it pulls the server and down comes any new toons they
 paid
   for. You can even allow for an SMS push notification that if they don't
 have
   a wifi/3G connection, but do have cell.. your game could listen for SMS
   messages (or a separate service piece to your game) and your server
 piece
   can send an SMS message (not sure what API/service allows for this to
 work
   tho) that when received updates the game for that user. Worse case,
 they
   don't have SMS enabled

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

westmeadboy
We are trying to find a way to make app's install virtual content via the
market. virtual content being movies, mp3 etc..

I didn't know that bout intent filter that is a big help thank you.

On Thu, Mar 25, 2010 at 4:51 PM, westmeadboy westmead...@yahoo.co.ukwrote:

 What is your specific reason for wanting to uninstall the character
 apps?

 You can make sure that they do not appear in the app drawer by using
 the relevant intent filter. That would only leave them visible to the
 user when they do something like Settings - Applications or look in
 the Downloads of the Market app.

 On Mar 25, 11:09 pm, chris harper ch393...@gmail.com wrote:
  Thanks guys
 
  Rob/Kevin
 
  You guys are really give me some ideas here.
 
  Thank you for the advice on score loop but I don’t think I can user it
  because my app doesn’t keep scores or interact with my app on other
 phones.
  It’s not really a game.
 
  So I am not sure if that will benefit me? I looked though scoreloop but
 it
  looks like it is for comparing scores with other users within a social
  network. Am I right?
 
  Rob – I was actually thinking right along that same track. Each install
 app
  keeps a timer of itself when it was installed and asks to be uninstalled
  after 48 hours, BUT makes it clear to the user that uninstalling the
 install
  app does NOT remove the character from the main app.
 
  Kevin -  you gave me a great idea very close to what you suggested. I do
  have a server side set up. Like I said I have a website set up with a
  shopping cart and everything where I WAS going to make people
 buy/download
  my characters from there.
 
  What if the install .apk not only installs the character like I stated
 but
  also takes the user ID from the database on the phone (which both the
  install .apk and the main program share the same sqlite DB) and it sends
 the
  information to the sever like you suggested that this user ID OWNS this
  character. So any updates to this character get sent to this user.  If
 they
  uninstall the install app before the 48 hours (for the refund) then
 before
  it uninstalls it updates the server they do not own this character
 anymore
  and this character was removed.
 
  If they remove the .apk install app after the 48 hours (via the prompt
 like
  Rob suggested) they still own the character and get any updates. The
  character is not tied with the .apk after the initial install.
 
  They can still remove the character from the main app at any time and
 that
  will also tell the server that they do not own the character anymore.
 
  What do you guys think?
 
 
 
  On Thu, Mar 25, 2010 at 3:38 PM, Kevin Duffey andjar...@gmail.com
 wrote:
   I wonder if removing the .apks will bring up other issues, like
 updates?
   For example, maybe not for your specific app, but what if a character
 .apk
   has a bug in it.. you fix it.. but end users have uninstalled. Now they
 will
   have to pay/reinstall again to get the updated toon even if they
 already
   paid/installed before.
 
   Honestly Chris I don't think this is a viable solution. It's close,
 but
   not quite there due to the variations of issue that may arise from
 removing
   the .apk.
 
   Here's a thought.. do you have a server side at all? If not, do you
 know
   enough server side to do a quick appengine or, I found a host that
 charges I
   think $15 a month to host a web app on a tomcat 6 server (I'll have to
 dig
   it up again)... the idea is.. make a simple server side app that stores
 a
   user's paid-for characters in a DB. That is.. the user goes to your
 site,
   pays for a toon. You then update (in some secure/encrypted manner) the
 DB
   for that user that they own that character. The next time they launch
 the
   game, some how it pulls the server and down comes any new toons they
 paid
   for. You can even allow for an SMS push notification that if they don't
 have
   a wifi/3G connection, but do have cell.. your game could listen for SMS
   messages (or a separate service piece to your game) and your server
 piece
   can send an SMS message (not sure what API/service allows for this to
 work
   tho) that when received updates the game for that user. Worse case,
 they
   don't have SMS enabled services.. and no internet.. then they have to
 wait
   till they do to get the character toons. Heck, they cant use the market
 to
   buy them either without network.. so no loss there.
 
   On Thu, Mar 25, 2010 at 2:31 PM, Rob Mazur r...@mobalyze.net wrote:
 
   Maybe you could store the date you detected the new apk in the prefs
   and say after refund period has expired you throw a dialog that tells
   the user they can now uninstall the addon pack.
 
   So for a few days (2 or 3 to be safe) your code checks that the apk is
   still there, if not then remove the character. Once the refund period
   has expired you throw up the dialog and can even kickoff the uninstall
   nicely with an intent. In your app description just make sure

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

So what we need is a faster process. :D I did forget that services, I think
paypal does this.. takes up to 5 days to clear for things like bank
transfers. I wonder how that will work outside of the market process.. if
you can't buy it immediately, you need some way to assure the user that the
process is going through and will take a few days.


On Thu, Mar 25, 2010 at 4:47 PM, westmeadboy westmead...@yahoo.co.ukwrote:

 To exclude from the app drawer, I think this explains it:
 http://groups.google.com/group/android-developers/msg/c4ca26a240d7120b

 BTW, looking at the payments (received) in Google Checkout the actual
 payment goes through always between 24 and 36 hours after
 authorisation. Most of the time its between 26 and 27 hours.

 Authorisation normally happens within a minute of receipt of the
 order, but sometimes takes several hours.

 (Of course, its possible that some payment systems within Google
 Checkout behave differently.)

 Because of the potential authorisation delay, its very difficult to be
 sure when the actual payment has cleared. I suppose 48 hours is safe
 enough...

 On Mar 26, 12:32 am, Rob Mazur r...@mobalyze.net wrote:
  I didn't know you could hide it from the app drawer. If that's the
  case then loading additional apks from a master apk may be a nice
  solution. Then you don't really need anything server-side either.
 
  Do you happen to know which filter does it?
 
  On Mar 25, 6:51 pm, westmeadboy westmead...@yahoo.co.uk wrote:
 
 
 
   What is your specific reason for wanting to uninstall the character
   apps?
 
   You can make sure that they do not appear in the app drawer by using
   the relevant intent filter. That would only leave them visible to the
   user when they do something like Settings - Applications or look in
   the Downloads of the Market app.
 
   On Mar 25, 11:09 pm, chris harper ch393...@gmail.com wrote:
 
Thanks guys
 
Rob/Kevin
 
You guys are really give me some ideas here.
 
Thank you for the advice on score loop but I don’t think I can user
 it
because my app doesn’t keep scores or interact with my app on other
 phones.
It’s not really a game.
 
So I am not sure if that will benefit me? I looked though scoreloop
 but it
looks like it is for comparing scores with other users within a
 social
network. Am I right?
 
Rob – I was actually thinking right along that same track. Each
 install app
keeps a timer of itself when it was installed and asks to be
 uninstalled
after 48 hours, BUT makes it clear to the user that uninstalling the
 install
app does NOT remove the character from the main app.
 
Kevin -  you gave me a great idea very close to what you suggested. I
 do
have a server side set up. Like I said I have a website set up with a
shopping cart and everything where I WAS going to make people
 buy/download
my characters from there.
 
What if the install .apk not only installs the character like I
 stated but
also takes the user ID from the database on the phone (which both the
install .apk and the main program share the same sqlite DB) and it
 sends the
information to the sever like you suggested that this user ID OWNS
 this
character. So any updates to this character get sent to this user.
  If they
uninstall the install app before the 48 hours (for the refund) then
 before
it uninstalls it updates the server they do not own this character
 anymore
and this character was removed.
 
If they remove the .apk install app after the 48 hours (via the
 prompt like
Rob suggested) they still own the character and get any updates. The
character is not tied with the .apk after the initial install.
 
They can still remove the character from the main app at any time and
 that
will also tell the server that they do not own the character anymore.
 
What do you guys think?
 
On Thu, Mar 25, 2010 at 3:38 PM, Kevin Duffey andjar...@gmail.com
 wrote:
 I wonder if removing the .apks will bring up other issues, like
 updates?
 For example, maybe not for your specific app, but what if a
 character .apk
 has a bug in it.. you fix it.. but end users have uninstalled. Now
 they will
 have to pay/reinstall again to get the updated toon even if they
 already
 paid/installed before.
 
 Honestly Chris I don't think this is a viable solution. It's
 close, but
 not quite there due to the variations of issue that may arise from
 removing
 the .apk.
 
 Here's a thought.. do you have a server side at all? If not, do you
 know
 enough server side to do a quick appengine or, I found a host that
 charges I
 think $15 a month to host a web app on a tomcat 6 server (I'll have
 to dig
 it up again)... the idea is.. make a simple server side app that
 stores a
 user's paid-for characters in a DB. That is.. the user goes to your
 site,
 pays for a toon. You then update (in some secure/encrypted manner)

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

westmeadboy

Thank you!
I think you sent me down the right track.

After much discussion on this I believe I found the best way to do this and
I think it will actually work and be transparent to the user. Meaning it
will be seen as one app and not a main and and a bunch of installer
app's.

Here is what I came up with.

I been playing around tonight and westmeadboy is correct in your manifest
file if you take out:

 category android:name=android.intent.category.LAUNCHER /

The app does NOT show up in your drawer.  So this is done for the installer
apk's (not the main program). That is great because then the installer
.apk's won't clutter up the apps for the user. They won't see them.

When  each install .apk for each character is downloaded the installer then
updates the database (which is shared with the main app) with the installer
package and installer app name. So the main app KNOWS what .apk installers
are on the phone for each character which it gets from the database each
time it starts up.

If it knows that and keeps track of them, then dynamically the main app can
call them via:
final Intent intent = new Intent();
String PACKAGENAME = value from database for installer PACKAGE NAME;
String APP_NAME = value from database for installer APP NAME;
 intent.setClassName(PACKAGENAME, APP_NAME);
 startActivity(intent);

I already did it. The installer .apk is hidden and the main app calls them
and to the user it will APPEAR to be the SAME app.

The main app is just calling each installer .apk behind the scenes which the
user can then control the install or removal of each character though it's
individual installer.

When a character is removed then the installer for that character is also
removed.
If they don't like a character and want to remove it for a refund within
the 48 or whatever period then they are refunded for that character and the
installer for that character is gone (it updates the database upon its
removal).

If I need to update a character then I just update the installer app for
that character. The user can then re-download the installer app for that
character whenever they want or get an alert for an update for a character
just like any other program.

I actually think this will work. Anyone see anything I am missing?

-Chris




On Thu, Mar 25, 2010 at 5:47 PM, westmeadboy westmead...@yahoo.co.ukwrote:

 To exclude from the app drawer, I think this explains it:
 http://groups.google.com/group/android-developers/msg/c4ca26a240d7120b

 BTW, looking at the payments (received) in Google Checkout the actual
 payment goes through always between 24 and 36 hours after
 authorisation. Most of the time its between 26 and 27 hours.

 Authorisation normally happens within a minute of receipt of the
 order, but sometimes takes several hours.

 (Of course, its possible that some payment systems within Google
 Checkout behave differently.)

 Because of the potential authorisation delay, its very difficult to be
 sure when the actual payment has cleared. I suppose 48 hours is safe
 enough...

 On Mar 26, 12:32 am, Rob Mazur r...@mobalyze.net wrote:
  I didn't know you could hide it from the app drawer. If that's the
  case then loading additional apks from a master apk may be a nice
  solution. Then you don't really need anything server-side either.
 
  Do you happen to know which filter does it?
 
  On Mar 25, 6:51 pm, westmeadboy westmead...@yahoo.co.uk wrote:
 
 
 
   What is your specific reason for wanting to uninstall the character
   apps?
 
   You can make sure that they do not appear in the app drawer by using
   the relevant intent filter. That would only leave them visible to the
   user when they do something like Settings - Applications or look in
   the Downloads of the Market app.
 
   On Mar 25, 11:09 pm, chris harper ch393...@gmail.com wrote:
 
Thanks guys
 
Rob/Kevin
 
You guys are really give me some ideas here.
 
Thank you for the advice on score loop but I don’t think I can user
 it
because my app doesn’t keep scores or interact with my app on other
 phones.
It’s not really a game.
 
So I am not sure if that will benefit me? I looked though scoreloop
 but it
looks like it is for comparing scores with other users within a
 social
network. Am I right?
 
Rob – I was actually thinking right along that same track. Each
 install app
keeps a timer of itself when it was installed and asks to be
 uninstalled
after 48 hours, BUT makes it clear to the user that uninstalling the
 install
app does NOT remove the character from the main app.
 
Kevin -  you gave me a great idea very close to what you suggested. I
 do
have a server side set up. Like I said I have a website set up with a
shopping cart and everything where I WAS going to make people
 buy/download
my characters from there.
 
What if the install .apk not only installs the character like I
 stated but
also takes the user ID from the database on the phone (which

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

For your particular app.. that sounds pretty good. I don't know that I would
take this approach for say a game that had hundreds of different items you
could purchase.. that would flood the market with 100's of .apks.

Honestly, I would say your BIGGEST worry is flooding the market with tons of
.apks. Let me ask you something... is there a reason you don't host them
yourself? Keep in mind, if your game can download the .apks from your own
site, you can install them. At least, I was lead to believe from another
post a while back that there is a way to install .apks outside of the
market. I am not sure exactly how, but you may want to look into it. To your
end user, rather than search the market for extra toons, you can provide an
in-game option that calls out to your server to get a list of any toons..
you can look at your server side DB for the user making the request, and
return enough info so you can highlight the toons they already own in the
list of all toons. Now, you host the .apks, your in-app website page where
they buy them is from your site. When they buy it, rather than give 30% to
google market, and inundate the market with tons of .apks that mean nothing
to anyone except those buying your app, host them on your own server, have
your app download them and install them directly, and keep the extra .30 for
yourself.

My guess is that you may not have known (or I could be wrong) that you can
download/install .apks from your own hosted site. But I believe hit is how
other market sites works.. you can buy the app and download it to your
computer, then drag/drop it and run it using a file browser on the android
device and it being a .apk will install. If there is no way to do that
within code tho, then it may not work, but that would seem odd to me that
you can't reach in to a downloaded .apk and launch it.

Then again, why even use .apk at this point. If you host the toons, you can
just download the toon directly with no .apk at all, and handle it that way.
The only purpose in my mind to do what you are doing is to avoid a potential
back-lash from google at some point that you can't provide in-game
purchases. But shoot, as we've been saying, nobody is saying anything, their
info isn't nearly clear on the subject, I say rather than worry about .apks,
installs, etc.. just host the toon packs yourself, and download it directly
and allow your app to directly add them rather than deal with .apk mess.
Personally, this is what I would do in your shoes, and will do for my own
stuff one day.



On Thu, Mar 25, 2010 at 8:47 PM, chris harper ch393...@gmail.com wrote:

 westmeadboy

 Thank you!
 I think you sent me down the right track.

 After much discussion on this I believe I found the best way to do this and
 I think it will actually work and be transparent to the user. Meaning it
 will be seen as one app and not a main and and a bunch of installer
 app's.

 Here is what I came up with.

 I been playing around tonight and westmeadboy is correct in your manifest
 file if you take out:

  category android:name=android.intent.category.LAUNCHER /

 The app does NOT show up in your drawer.  So this is done for the installer
 apk's (not the main program). That is great because then the installer
 .apk's won't clutter up the apps for the user. They won't see them.

 When  each install .apk for each character is downloaded the installer then
 updates the database (which is shared with the main app) with the installer
 package and installer app name. So the main app KNOWS what .apk installers
 are on the phone for each character which it gets from the database each
 time it starts up.

 If it knows that and keeps track of them, then dynamically the main app can
 call them via:
 final Intent intent = new Intent();
 String PACKAGENAME = value from database for installer PACKAGE NAME;
 String APP_NAME = value from database for installer APP NAME;
  intent.setClassName(PACKAGENAME, APP_NAME);
  startActivity(intent);

 I already did it. The installer .apk is hidden and the main app calls them
 and to the user it will APPEAR to be the SAME app.

 The main app is just calling each installer .apk behind the scenes which
 the user can then control the install or removal of each character though
 it's individual installer.

 When a character is removed then the installer for that character is also
 removed.
 If they don't like a character and want to remove it for a refund within
 the 48 or whatever period then they are refunded for that character and the
 installer for that character is gone (it updates the database upon its
 removal).

 If I need to update a character then I just update the installer app for
 that character. The user can then re-download the installer app for that
 character whenever they want or get an alert for an update for a character
 just like any other program.

 I actually think this will work. Anyone see anything I am missing?

 -Chris




 On Thu, Mar 25, 2010 at 5:47 PM, westmeadboy

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

I should add Chris, that if the .apk thing works now.. I would totally shelf
it for now.. knowing that it works, and do what I said above. If/when google
ever says anything, clarify with them your .apk route, and then reply to
this forum (and me via email if you wouldn't mind) and let us know the
status. I still can't imagine there is anything wrong with the in-game
purchase issue, like you have it or otherwise.

If you need a tester for your app, please let me know.. I'd be happy to try
it out, and interested in how you did the server side.. and embeded it in
your app.



On Thu, Mar 25, 2010 at 9:05 PM, Kevin Duffey andjar...@gmail.com wrote:

 For your particular app.. that sounds pretty good. I don't know that I
 would take this approach for say a game that had hundreds of different items
 you could purchase.. that would flood the market with 100's of .apks.

 Honestly, I would say your BIGGEST worry is flooding the market with tons
 of .apks. Let me ask you something... is there a reason you don't host them
 yourself? Keep in mind, if your game can download the .apks from your own
 site, you can install them. At least, I was lead to believe from another
 post a while back that there is a way to install .apks outside of the
 market. I am not sure exactly how, but you may want to look into it. To your
 end user, rather than search the market for extra toons, you can provide an
 in-game option that calls out to your server to get a list of any toons..
 you can look at your server side DB for the user making the request, and
 return enough info so you can highlight the toons they already own in the
 list of all toons. Now, you host the .apks, your in-app website page where
 they buy them is from your site. When they buy it, rather than give 30% to
 google market, and inundate the market with tons of .apks that mean nothing
 to anyone except those buying your app, host them on your own server, have
 your app download them and install them directly, and keep the extra .30 for
 yourself.

 My guess is that you may not have known (or I could be wrong) that you can
 download/install .apks from your own hosted site. But I believe hit is how
 other market sites works.. you can buy the app and download it to your
 computer, then drag/drop it and run it using a file browser on the android
 device and it being a .apk will install. If there is no way to do that
 within code tho, then it may not work, but that would seem odd to me that
 you can't reach in to a downloaded .apk and launch it.

 Then again, why even use .apk at this point. If you host the toons, you can
 just download the toon directly with no .apk at all, and handle it that way.
 The only purpose in my mind to do what you are doing is to avoid a potential
 back-lash from google at some point that you can't provide in-game
 purchases. But shoot, as we've been saying, nobody is saying anything, their
 info isn't nearly clear on the subject, I say rather than worry about .apks,
 installs, etc.. just host the toon packs yourself, and download it directly
 and allow your app to directly add them rather than deal with .apk mess.
 Personally, this is what I would do in your shoes, and will do for my own
 stuff one day.




 On Thu, Mar 25, 2010 at 8:47 PM, chris harper ch393...@gmail.com wrote:

 westmeadboy

 Thank you!
 I think you sent me down the right track.

 After much discussion on this I believe I found the best way to do this
 and I think it will actually work and be transparent to the user. Meaning it
 will be seen as one app and not a main and and a bunch of installer
 app's.

 Here is what I came up with.

 I been playing around tonight and westmeadboy is correct in your manifest
 file if you take out:

  category android:name=android.intent.category.LAUNCHER /

 The app does NOT show up in your drawer.  So this is done for the
 installer apk's (not the main program). That is great because then the
 installer .apk's won't clutter up the apps for the user. They won't see
 them.

 When  each install .apk for each character is downloaded the installer
 then updates the database (which is shared with the main app) with the
 installer package and installer app name. So the main app KNOWS what .apk
 installers are on the phone for each character which it gets from the
 database each time it starts up.

 If it knows that and keeps track of them, then dynamically the main app
 can call them via:
 final Intent intent = new Intent();
 String PACKAGENAME = value from database for installer PACKAGE NAME;
 String APP_NAME = value from database for installer APP NAME;
  intent.setClassName(PACKAGENAME, APP_NAME);
  startActivity(intent);

 I already did it. The installer .apk is hidden and the main app calls them
 and to the user it will APPEAR to be the SAME app.

 The main app is just calling each installer .apk behind the scenes which
 the user can then control the install or removal of each character though
 it's individual installer.

 When a character

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Kevin

The main advantage like I stated before (and a BIG advantage in my mind) is
if I do the .apk route
 1. Yes it complies with Google agreement.
but
2 and more importantly the user does not have to enter their finical info
again and if I state where they are browsing my characters that all
payments go though Android Market place they are immediately more at ease
because they are already using it and trust it.

If they have to
A. Go to a site they know nothing about
B. Have to renter their credit card info

I am not a statistic but I am willing to bet that cuts a HUGE portion out
which might have bought a character for just .99 for of the ease of clicking
OK  from a site they trust.

To me that IS worth the 30% cut though the market.

Do you not agree?

Others could use the same model. But I would say to not do an apk installer
for EVERY item if you have a lot for a game. I would say you could purchase
packages of weapons or coins or whatever that your game uses for different
rates? And package them up in installer .apk's.

As far as flooding the market. Well Google needs to kick it in gear and
improve the market and this would be an addition they need to do. Add a
separate section for Virtual Install app's or something.

I would be happy to tell you how I did my server side. I basically have an
activity in my app that uses webview. Which when that starts it opens to my
site where my characters are. You can format the website to fit better on
the phone screen. I use zencart. They browsers and place items in a basket
just like usual. They checkout and zencart has a feature to say that the
times are virtual so when checkout is complete the item can then be
download. Which is download to your phone. I packages my character info up
in a zip file. Then the zip file is download the app takes it opens it up
and installs the character.

I have the address of my zencart site. If you give me another email you can
take a look. I don't really want to post it out in the open because its my
own trial for my app.

-Chris

On Thu, Mar 25, 2010 at 10:07 PM, Kevin Duffey andjar...@gmail.com wrote:

 I should add Chris, that if the .apk thing works now.. I would totally
 shelf it for now.. knowing that it works, and do what I said above. If/when
 google ever says anything, clarify with them your .apk route, and then reply
 to this forum (and me via email if you wouldn't mind) and let us know the
 status. I still can't imagine there is anything wrong with the in-game
 purchase issue, like you have it or otherwise.

 If you need a tester for your app, please let me know.. I'd be happy to try
 it out, and interested in how you did the server side.. and embeded it in
 your app.




 On Thu, Mar 25, 2010 at 9:05 PM, Kevin Duffey andjar...@gmail.com wrote:

 For your particular app.. that sounds pretty good. I don't know that I
 would take this approach for say a game that had hundreds of different items
 you could purchase.. that would flood the market with 100's of .apks.

 Honestly, I would say your BIGGEST worry is flooding the market with tons
 of .apks. Let me ask you something... is there a reason you don't host them
 yourself? Keep in mind, if your game can download the .apks from your own
 site, you can install them. At least, I was lead to believe from another
 post a while back that there is a way to install .apks outside of the
 market. I am not sure exactly how, but you may want to look into it. To your
 end user, rather than search the market for extra toons, you can provide an
 in-game option that calls out to your server to get a list of any toons..
 you can look at your server side DB for the user making the request, and
 return enough info so you can highlight the toons they already own in the
 list of all toons. Now, you host the .apks, your in-app website page where
 they buy them is from your site. When they buy it, rather than give 30% to
 google market, and inundate the market with tons of .apks that mean nothing
 to anyone except those buying your app, host them on your own server, have
 your app download them and install them directly, and keep the extra .30 for
 yourself.

 My guess is that you may not have known (or I could be wrong) that you can
 download/install .apks from your own hosted site. But I believe hit is how
 other market sites works.. you can buy the app and download it to your
 computer, then drag/drop it and run it using a file browser on the android
 device and it being a .apk will install. If there is no way to do that
 within code tho, then it may not work, but that would seem odd to me that
 you can't reach in to a downloaded .apk and launch it.

 Then again, why even use .apk at this point. If you host the toons, you
 can just download the toon directly with no .apk at all, and handle it that
 way. The only purpose in my mind to do what you are doing is to avoid a
 potential back-lash from google at some point that you can't provide in-game
 purchases. But shoot, as we've been

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

I hate to say it but I have to agree with Disconnect. I re-read the
agreement and it does say:

3.3 *All fees received* by Developers for Products *distributed* via the
Market must be processed by the Market’s Payment Processor.

To me that means any additional money that you make from any product (i.e.
app) that you distribute from the Market must go though the Market's Payment
Processor.
Or another way to put it from Google side. We distributed your app so any
money you make off it then we want our cut.
I don't like it but that is how I read it.
But want is pretty lame is that they are making developers abide to this but
they have not set up the infrastructure to support it.
Meaning the the market does not provide a way to distribute virtual
products one might want a user to buy and upload within their app like a
movie or music or in my case extra characters that my app uses.
There are no Market Libraries that you can use within your app to use to
process a payment though the Market. The Google guys have been silent to
answer this because there is no way to support it.

So *unless anyone that reads this knows of any another way*. The only way I
can see to abide by goggles legal request is to bundle up every single
character I want to sell and upload within my app as as a separate apk and
put it on the market as a separate download.
I don't want to do that but to stay legal then that is the road I am going
to have to take.

Thank you
-Chris

On Wed, Mar 24, 2010 at 1:36 AM, Jeremy Slade jeremy.g.sl...@gmail.comwrote:

My interpretation, not to be confused with legal advice: Add-on
products purchased via an app do not qualify as products distributed
via the Market. However, something like a pro version of an app,
purchased via a lite version that was distributed via the Market,
would be subject to this part of the agreement. Similarly, ad revenue
earned from a Market app is not subject to this clause, because the
product (for which you are being paid) is ad impressions / clicks,
which are not distributed via the Market.

I don't think I want to be first to prove that interpretation,
however...

On Mar 23, 8:53 am, TreKing treking...@gmail.com wrote:
Interesting discussion.

3.3 - All fees received by Developers for Products distributed via the
Market must be processed by the Market’s Payment Processor.

One could argue that fees received by Developers for Products
distributed
via the Market only applies to apps sold through the market. If you then
used your app to allow the user to buy stuff from your website, those
fees
would not be for products distributed via the Market, they would be for
products distributed via your website and would not be subject to being
processed by the Payment Processor.

Thoughts?

-
TreKing - Chicago transit tracking app for Android-powered deviceshttp://
sites.google.com/site/rezmobileapps/treking

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

I see your point. I can be read either way. The android tech guys on here
won't comment because it is a legal matter but it would be really really
great if they could at least point us in the direction of WHERE to ask this
question???

There is not a legal discussion forum to ask these things.
*
Please. To the Google engineers reading this. *

You guys really might want to bring up at your next weekly working meeting
(if you have those) that with all these developers creating everything from
X to Z for applications there WILL be many legal questions like this one
that will need to be answered.
So the developers will know what direction to go in on different issues.

We don't want to skirt around anything legal, we just need a place to go for
direction.

So you guys REALLY might want to set up a place where we can go to get these
legal questions answered.

Instead of waiting until they do all the work of developing their app and
getting it out there and THEN telling them oh you can't do this for legal
reason ..whatever.

Just trying to help. I guess I will just send search around to see if I can
find a general android support email and I will send the question there.

For anyone wondering what the question is go up to my last email on this
post about how to do in-app purchasing and the Market Agreement.

-Chris

On Wed, Mar 24, 2010 at 10:44 AM, Yahel kaye...@gmail.com wrote:

3.3 *All fees received* by Developers for Products *distributed* via the
Market must be processed by the Market’s Payment Processor.

To me that means any additional money that you make from any product
(i.e.
app) that you distribute from the Market must go though the Market's
Payment
Processor.

Say I sell gold point, or tickets through my app, then it doesn't fit
into *distributed* via the Market , since it is not distributed
through the Market at all, but through my app.
Intrepretation is in the eye of the beholder...Whatever that means :D

Anyway, there is no need to argue. We need Google's take on it.
Because only them know what they want and don't want.

Yahel

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

jfarringdon has posted an answer to the question In-App Purchasing for
Applications:

No you should not currently offer in app features that you charge for. It is
against the distribution agreement.

You could offer separate paid apps, and have your main app share these
resources (if you take good care to share, normally apps do not share).
Post back with your solution, it is an interesting question for a number of
people. Good luck, J.

http://www.android.com/us/developer-distribution-agreement.html

View this question at the Google Help Forum
Unsubscribe from answers to this question

jfarringdon

Thank you for the response and exactly what I am designing.

My main app uses Characters where the information about each character are
stored via the sqlite database and the images that make up the character are
stored on phone which my main app uses to load a character when needed.

I will create an installer app for EACH character. The installer app will
contain the information for each new character and the images (which are
under /assets in the apk) and when the user buys an installer app for a
character it will download, run, read in the images from /assets, write them
to the phone and populate the sqlite database with the the character
information. The installer for each character will also uninstall a
character by reversing the process.

So when an installer for character is purchased (though marketplace) and run
to install the character, then my main app can read the database, read the
images and run the character.

I downside is a user can then have accumulate installer apps for each
character on their phone. So I am applying an option to remove the installer
app for each character once the character is installed or they can either
remove it or leave it on their phone.

The characters can be uninstalled from the installer OR from the main
program.
So they don't need the installer app to remove a character.

That is the ONLY way I can think to abide by the Market rules as they stand.

-Chris

On Wed, Mar 24, 2010 at 11:34 AM, chris harper ch393...@gmail.com wrote:

There is not a legal discussion forum to ask these things.
*
Please. To the Google engineers reading this. *

We don't want to skirt around anything legal, we just need a place to go
for direction.

So you guys REALLY might want to set up a place where we can go to get
these legal questions answered.

Instead of waiting until they do all the work of developing their app and
getting it out there and THEN telling them oh you can't do this for legal
reason ..whatever.

Just trying to help. I guess I will just send search around to see if I can
find a general android support email and I will send the question there.

For anyone wondering what the question is go up to my last email on this
post about how to do in-app purchasing and the Market Agreement.

-Chris

On Wed, Mar 24, 2010 at 10:44 AM, Yahel kaye...@gmail.com wrote:

3.3 *All fees received* by Developers for Products *distributed* via the
Market must be processed by the Market’s Payment Processor.

To me that means any additional money that you make from any product
(i.e.
app) that you distribute from the Market must go though the Market's
Payment
Processor.

Anyway, there is no need to argue. We need Google's take on it.
Because only them know what they want and don't want.

Yahel

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Warren

That is correct. All the features for my app are always there, they never
change.

My app is just USED to load and run the characters (which are little modules
that my app uses that I want to charge for).

This is completely different than charging for an upgrade.

The same way you can put itunes on your PC but itunes is USED to load and
run mp3's (which you buy).

Or using VLC media player (which is free) which is USED to load and run
movies.

But the way I read the agreement Google still wants to any revenue made from
the app to go though market place.
Which to me means that I have make it so all my characters as separate
downloads in market place via a separate installer for each character which
I CAN charge for.

Unless I am am understanding that wrong which would be nice.

-Chris


On Wed, Mar 24, 2010 at 12:41 PM, Warren warrenba...@gmail.com wrote:

 I want to point out, because this has been part of the confusion the
 whole time, that he says, No you should not currently offer in app
 features that you charge for.

 Did you get that? The you should not charge for features.

 So suppose, as in Chris' case, you want to load extra character
 models. Well, one of the features of your app is the ability to load
 external models. They could be from the original developer, or I
 suppose someone else could design one and send it to you as well. Even
 if you don't have any characters installed/loaded, the feature to load
 them is still there and it is free.

 This is not that different from the mp3 comparison made earlier. The
 application offers a feature, the ability to play songs, no matter
 where the song files came from. Adding or removing mp3 files does not
 change the features of the music app.






 On Mar 24, 1:02 pm, chris harper ch393...@gmail.com wrote:
  jfarringdon has posted an answer to the question In-App Purchasing for
  Applications:
 
  No you should not currently offer in app features that you charge for. It
 is
  against the distribution agreement.
 
  You could offer separate paid apps, and have your main app share these
  resources (if you take good care to share, normally apps do not share).
  Post back with your solution, it is an interesting question for a number
 of
  people. Good luck, J.
 
  http://www.android.com/us/developer-distribution-agreement.html
 
  View this question at the Google Help Forum
  Unsubscribe from answers to this question
 
  jfarringdon
 
  Thank you for the response and exactly what I am designing.
 
  My main app uses Characters where the information about each character
 are
  stored via the sqlite database and the images that make up the character
 are
  stored on phone which my main app uses to load a character when needed.
 
  I will create an installer app for EACH character. The installer app
 will
  contain the information for each new character and the images (which are
  under /assets in the apk) and when the user buys an installer app for a
  character it will download, run, read in the images from /assets, write
 them
  to the phone and populate the sqlite database with the the character
  information.  The installer for each character will also uninstall a
  character by reversing the process.
 
  So when an installer for character is purchased (though marketplace) and
 run
  to install the character, then my main app can read the database, read
 the
  images and run the character.
 
  I downside is a user can then have accumulate installer apps for each
  character on their phone. So I am applying an option to remove the
 installer
  app for each character once the character is installed or they can either
  remove it or leave it on their phone.
 
  The characters can be uninstalled from the installer OR from the main
  program.
  So they don't need the installer app to remove a character.
 
  That is the ONLY way I can think to abide by the Market rules as they
 stand.
 
  -Chris
 
  On Wed, Mar 24, 2010 at 11:34 AM, chris harper ch393...@gmail.com
 wrote:
   I see your point. I can be read either way. The android tech guys on
 here
   won't comment because it is a legal matter but it would be really
 really
   great if they could at least point us in the direction of WHERE to ask
 this
   question???
 
   There is not a legal discussion forum to ask these things.
   *
   Please.  To the Google engineers reading this. *
 
   You guys really might want to bring up at your next weekly working
 meeting
   (if you have those) that with all these developers creating everything
 from
   X to Z for applications there WILL be many legal questions like this
 one
   that will need to be answered.
   So the developers will know what direction to go in on different
 issues.
 
   We don't want to skirt around anything legal, we just need a place to
 go
   for direction.
 
   So you guys REALLY might want to set up a place where we can go to get
   these legal questions answered.
 
   Instead of waiting until they do all the work of

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Sorry Warren I didn't check over there. I will post the same response.

-Chris

On Wed, Mar 24, 2010 at 12:50 PM, Warren warrenba...@gmail.com wrote:

 Here is where the discussion landed on the Market support forum.


 http://www.google.com/support/forum/p/Android+Market/thread?tid=3c47284987b99696hl=en


 On Mar 24, 1:41 pm, Warren warrenba...@gmail.com wrote:
  I want to point out, because this has been part of the confusion the
  whole time, that he says, No you should not currently offer in app
  features that you charge for.
 
  Did you get that? The you should not charge for features.
 
  So suppose, as in Chris' case, you want to load extra character
  models. Well, one of the features of your app is the ability to load
  external models. They could be from the original developer, or I
  suppose someone else could design one and send it to you as well. Even
  if you don't have any characters installed/loaded, the feature to load
  them is still there and it is free.
 
  This is not that different from the mp3 comparison made earlier. The
  application offers a feature, the ability to play songs, no matter
  where the song files came from. Adding or removing mp3 files does not
  change the features of the music app.
 
  On Mar 24, 1:02 pm, chris harper ch393...@gmail.com wrote:
 
   jfarringdon has posted an answer to the question In-App Purchasing for
   Applications:
 
   No you should not currently offer in app features that you charge for.
 It is
   against the distribution agreement.
 
   You could offer separate paid apps, and have your main app share these
   resources (if you take good care to share, normally apps do not share).
   Post back with your solution, it is an interesting question for a
 number of
   people. Good luck, J.
 
  http://www.android.com/us/developer-distribution-agreement.html
 
   View this question at the Google Help Forum
   Unsubscribe from answers to this question
 
   jfarringdon
 
   Thank you for the response and exactly what I am designing.
 
   My main app uses Characters where the information about each character
 are
   stored via the sqlite database and the images that make up the
 character are
   stored on phone which my main app uses to load a character when needed.
 
   I will create an installer app for EACH character. The installer app
 will
   contain the information for each new character and the images (which
 are
   under /assets in the apk) and when the user buys an installer app for a
   character it will download, run, read in the images from /assets, write
 them
   to the phone and populate the sqlite database with the the character
   information.  The installer for each character will also uninstall a
   character by reversing the process.
 
   So when an installer for character is purchased (though marketplace)
 and run
   to install the character, then my main app can read the database, read
 the
   images and run the character.
 
   I downside is a user can then have accumulate installer apps for each
   character on their phone. So I am applying an option to remove the
 installer
   app for each character once the character is installed or they can
 either
   remove it or leave it on their phone.
 
   The characters can be uninstalled from the installer OR from the main
   program.
   So they don't need the installer app to remove a character.
 
   That is the ONLY way I can think to abide by the Market rules as they
 stand.
 
   -Chris
 
   On Wed, Mar 24, 2010 at 11:34 AM, chris harper ch393...@gmail.com
 wrote:
I see your point. I can be read either way. The android tech guys on
 here
won't comment because it is a legal matter but it would be really
 really
great if they could at least point us in the direction of WHERE to
 ask this
question???
 
There is not a legal discussion forum to ask these things.
*
Please.  To the Google engineers reading this. *
 
You guys really might want to bring up at your next weekly working
 meeting
(if you have those) that with all these developers creating
 everything from
X to Z for applications there WILL be many legal questions like this
 one
that will need to be answered.
So the developers will know what direction to go in on different
 issues.
 
We don't want to skirt around anything legal, we just need a place to
 go
for direction.
 
So you guys REALLY might want to set up a place where we can go to
 get
these legal questions answered.
 
Instead of waiting until they do all the work of developing their app
 and
getting it out there and THEN telling them oh you can't do this for
 legal
reason ..whatever.
 
Just trying to help. I guess I will just send search around to see if
 I can
find a general android support email and I will send the question
 there.
 
For anyone wondering what the question is go up to my last email on
 this
post about how to do in-app purchasing and the Market Agreement.
 
-Chris

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

2010-03-24 Thread Kevin Duffey

Hey all,

read that thread and the rest of this one. I agree with TreKing. Just do it
Chris. The language to me, and everyone else here is quite clear. All apps
distributed thru the market MUST pay the market. Cool.. fair enough.. but
there is nothing at all that describes in-game transactions that you code
yourself. Nothing at all. There is no place short of this thread and another
that tries to identify this issue and I am rather shocked as long as this
thread has been around nobody from google has responded. As TreKing said,
it's ambiguous, it's not nearly clear enough to say you can't do it. More
so, I can't help but wonder, how would google ever know anyway... short of
someone calling them up and saying that an app sold on the market is doing
in-game payments thru paypal or something.. and if that person can do that,
why can't we find some way to contact them to find this out.

Frankly, as I've said a few times, google would be out of their minds to try
to prevent this and if anything should really step up and provide a solid
built-in android payment capability that they can profit from. I said it
several times, I am ALL for giving google some of my in-game profits. They
deserve it if they are willing to support it by supplying the API that
handles the transactions. There has been plenty of articles about how long
can google sustain their financial status on ads only... this is clearly one
way they can make a crap load of money doing almost nothing (after all they
already have google checkout working and supported), and from the various
articles talking about how big micro transactions are going to be, and
already are, if Android itself balloons and catches up or surpasses iPhone
like various reports indicate, google could stand to make huge money off of
something like this. As well, it will provide a more stable income source
for developers utilizing it.

I liken this to themes. I have yet to get my 2.1 update on my droid..
supposedly sometime in 2012 or so we'll get it being 2+ months late
already... but, the theme market.. or live home screen market is sure to
explode as people create their own themes and sell them for .99 on the
market. I still don't get why google doesn't take a cut of all the apps sold
on the market while apple does.. I dont get it. But whatever.

Anyway, I plan on supporting this in my apps.. until I am told otherwise.

On Wed, Mar 24, 2010 at 12:26 PM, chris harper ch393...@gmail.com wrote:

 Sorry Warren I didn't check over there. I will post the same response.

 -Chris


 On Wed, Mar 24, 2010 at 12:50 PM, Warren warrenba...@gmail.com wrote:

 Here is where the discussion landed on the Market support forum.


 http://www.google.com/support/forum/p/Android+Market/thread?tid=3c47284987b99696hl=en


 On Mar 24, 1:41 pm, Warren warrenba...@gmail.com wrote:
  I want to point out, because this has been part of the confusion the
  whole time, that he says, No you should not currently offer in app
  features that you charge for.
 
  Did you get that? The you should not charge for features.
 
  So suppose, as in Chris' case, you want to load extra character
  models. Well, one of the features of your app is the ability to load
  external models. They could be from the original developer, or I
  suppose someone else could design one and send it to you as well. Even
  if you don't have any characters installed/loaded, the feature to load
  them is still there and it is free.
 
  This is not that different from the mp3 comparison made earlier. The
  application offers a feature, the ability to play songs, no matter
  where the song files came from. Adding or removing mp3 files does not
  change the features of the music app.
 
  On Mar 24, 1:02 pm, chris harper ch393...@gmail.com wrote:
 
   jfarringdon has posted an answer to the question In-App Purchasing
 for
   Applications:
 
   No you should not currently offer in app features that you charge for.
 It is
   against the distribution agreement.
 
   You could offer separate paid apps, and have your main app share these
   resources (if you take good care to share, normally apps do not
 share).
   Post back with your solution, it is an interesting question for a
 number of
   people. Good luck, J.
 
  http://www.android.com/us/developer-distribution-agreement.html
 
   View this question at the Google Help Forum
   Unsubscribe from answers to this question
 
   jfarringdon
 
   Thank you for the response and exactly what I am designing.
 
   My main app uses Characters where the information about each character
 are
   stored via the sqlite database and the images that make up the
 character are
   stored on phone which my main app uses to load a character when
 needed.
 
   I will create an installer app for EACH character. The installer app
 will
   contain the information for each new character and the images (which
 are
   under /assets in the apk) and when the user buys an installer app for
 a
   character it will download, run,

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

I will post my response on both threads and I Kevin you are right we had two
threads going on this with no answer.

Thanks for the input TreKing

I agree I don't WANT to violate anything but when I can't get an answer I am
not sure what do to?

I have the basic skeleton structure for implementing the APK's for the
characters though the Market. I will keep that on the side and I will start
by publishing my characters via my own website and if they say I can't then
you are right as least I forced a hand and got an answer.

If I do get that answer then again, the question is only PART of it because
if they tell developers that they HAVE to go though  Market Place to provide
virtual content which people can buy via their app (NOT AN UPGRADE FOR THE
APP vey important difference) then well

...where is the infrastructure to support it?

They have either to provide the infrastructure though Market Place for
virtual content OR by provide the API's that developers can use in their
apps to use Market Place to complete transactions of virtual items purchased
within apps.

They can't just say don't do that and not provide an alternative way.
Well they could but it would make me rethink about developing for Android.

At least that's how I see it.

I'll go with my original idea and if they make me change to use market place
then I will make sure all the other developers know about it and at least we
have a future direction.

Although I estimate that I have about another two months of code and test
work before I distribute my app.

ToonTalks!

Watch for it.

:-)

Thank you
On Wed, Mar 24, 2010 at 4:00 PM, Kevin Duffey andjar...@gmail.com wrote:

 Hey all,

 read that thread and the rest of this one. I agree with TreKing. Just do it
 Chris. The language to me, and everyone else here is quite clear. All apps
 distributed thru the market MUST pay the market. Cool.. fair enough.. but
 there is nothing at all that describes in-game transactions that you code
 yourself. Nothing at all. There is no place short of this thread and another
 that tries to identify this issue and I am rather shocked as long as this
 thread has been around nobody from google has responded. As TreKing said,
 it's ambiguous, it's not nearly clear enough to say you can't do it. More
 so, I can't help but wonder, how would google ever know anyway... short of
 someone calling them up and saying that an app sold on the market is doing
 in-game payments thru paypal or something.. and if that person can do that,
 why can't we find some way to contact them to find this out.

 Frankly, as I've said a few times, google would be out of their minds to
 try to prevent this and if anything should really step up and provide a
 solid built-in android payment capability that they can profit from. I said
 it several times, I am ALL for giving google some of my in-game profits.
 They deserve it if they are willing to support it by supplying the API that
 handles the transactions. There has been plenty of articles about how long
 can google sustain their financial status on ads only... this is clearly one
 way they can make a crap load of money doing almost nothing (after all they
 already have google checkout working and supported), and from the various
 articles talking about how big micro transactions are going to be, and
 already are, if Android itself balloons and catches up or surpasses iPhone
 like various reports indicate, google could stand to make huge money off of
 something like this. As well, it will provide a more stable income source
 for developers utilizing it.

 I liken this to themes. I have yet to get my 2.1 update on my droid..
 supposedly sometime in 2012 or so we'll get it being 2+ months late
 already... but, the theme market.. or live home screen market is sure to
 explode as people create their own themes and sell them for .99 on the
 market. I still don't get why google doesn't take a cut of all the apps sold
 on the market while apple does.. I dont get it. But whatever.

 Anyway, I plan on supporting this in my apps.. until I am told otherwise.

 On Wed, Mar 24, 2010 at 12:26 PM, chris harper ch393...@gmail.com wrote:

 Sorry Warren I didn't check over there. I will post the same response.

 -Chris


 On Wed, Mar 24, 2010 at 12:50 PM, Warren warrenba...@gmail.com wrote:

 Here is where the discussion landed on the Market support forum.


 http://www.google.com/support/forum/p/Android+Market/thread?tid=3c47284987b99696hl=en


 On Mar 24, 1:41 pm, Warren warrenba...@gmail.com wrote:
  I want to point out, because this has been part of the confusion the
  whole time, that he says, No you should not currently offer in app
  features that you charge for.
 
  Did you get that? The you should not charge for features.
 
  So suppose, as in Chris' case, you want to load extra character
  models. Well, one of the features of your app is the ability to load
  external models. They could be from the original developer, or I
  suppose someone else

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

2010-03-24 Thread Kevin Duffey

Kewl. I agree with you.. same thoughts.. if they are going to say don't do
it.. then they need to provide some clear cut examples and info on how to
provide such functionality. If it's thru the market, then for God's sake
please let's clean up the Market app so that virtual goods, addons etc are
NOT displayed with the market apps/games. Add more filters on the market
app. I am surprised there hasn't been any update at least since I got my
droid, for the market app.



On Wed, Mar 24, 2010 at 3:09 PM, chris harper ch393...@gmail.com wrote:

 I will post my response on both threads and I Kevin you are right we had
 two threads going on this with no answer.

 Thanks for the input TreKing

 I agree I don't WANT to violate anything but when I can't get an answer I
 am not sure what do to?

 I have the basic skeleton structure for implementing the APK's for the
 characters though the Market. I will keep that on the side and I will start
 by publishing my characters via my own website and if they say I can't then
 you are right as least I forced a hand and got an answer.

 If I do get that answer then again, the question is only PART of it because
 if they tell developers that they HAVE to go though  Market Place to provide
 virtual content which people can buy via their app (NOT AN UPGRADE FOR THE
 APP vey important difference) then well

 ...where is the infrastructure to support it?

 They have either to provide the infrastructure though Market Place for
 virtual content OR by provide the API's that developers can use in their
 apps to use Market Place to complete transactions of virtual items purchased
 within apps.

 They can't just say don't do that and not provide an alternative way.
 Well they could but it would make me rethink about developing for Android.

 At least that's how I see it.

 I'll go with my original idea and if they make me change to use market
 place then I will make sure all the other developers know about it and at
 least we have a future direction.

 Although I estimate that I have about another two months of code and test
 work before I distribute my app.

 ToonTalks!

 Watch for it.

 :-)

 Thank you
 On Wed, Mar 24, 2010 at 4:00 PM, Kevin Duffey andjar...@gmail.com wrote:

 Hey all,

 read that thread and the rest of this one. I agree with TreKing. Just do
 it Chris. The language to me, and everyone else here is quite clear. All
 apps distributed thru the market MUST pay the market. Cool.. fair enough..
 but there is nothing at all that describes in-game transactions that you
 code yourself. Nothing at all. There is no place short of this thread and
 another that tries to identify this issue and I am rather shocked as long as
 this thread has been around nobody from google has responded. As TreKing
 said, it's ambiguous, it's not nearly clear enough to say you can't do it.
 More so, I can't help but wonder, how would google ever know anyway... short
 of someone calling them up and saying that an app sold on the market is
 doing in-game payments thru paypal or something.. and if that person can do
 that, why can't we find some way to contact them to find this out.

 Frankly, as I've said a few times, google would be out of their minds to
 try to prevent this and if anything should really step up and provide a
 solid built-in android payment capability that they can profit from. I said
 it several times, I am ALL for giving google some of my in-game profits.
 They deserve it if they are willing to support it by supplying the API that
 handles the transactions. There has been plenty of articles about how long
 can google sustain their financial status on ads only... this is clearly one
 way they can make a crap load of money doing almost nothing (after all they
 already have google checkout working and supported), and from the various
 articles talking about how big micro transactions are going to be, and
 already are, if Android itself balloons and catches up or surpasses iPhone
 like various reports indicate, google could stand to make huge money off of
 something like this. As well, it will provide a more stable income source
 for developers utilizing it.

 I liken this to themes. I have yet to get my 2.1 update on my droid..
 supposedly sometime in 2012 or so we'll get it being 2+ months late
 already... but, the theme market.. or live home screen market is sure to
 explode as people create their own themes and sell them for .99 on the
 market. I still don't get why google doesn't take a cut of all the apps sold
 on the market while apple does.. I dont get it. But whatever.

 Anyway, I plan on supporting this in my apps.. until I am told otherwise.

 On Wed, Mar 24, 2010 at 12:26 PM, chris harper ch393...@gmail.comwrote:

 Sorry Warren I didn't check over there. I will post the same response.

 -Chris


 On Wed, Mar 24, 2010 at 12:50 PM, Warren warrenba...@gmail.com wrote:

 Here is where the discussion landed on the Market support forum.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Too bad for you that the market agreement is -very- clear about it and
you've just publicly admitted any violation is willful and intentional. ISTR
the agreement says they can pull every dime you made from market if you do
that sort of thing...

Good luck though.

On Tue, Mar 23, 2010 at 9:25 AM, Yahel kaye...@gmail.com wrote:

Hi,

I'm actually very interested as well.
I think if the Android Team doesn't answer it's just that it's not an
issue for them.

And as we say in France Qui ne dit mot, consent :D

I'm going to implement an in-app purchase in my next game.
I'm going to try to make it use Google checkout, this way if this is
infringing enough to get a cease an desist letter, at least, I will
always be able to claim they made money too ;D

I'll publish my cease and desist letter here if I get one :D

Yahel

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Warren wrote:
 I just want to get Google's take.

You're not likely to get Google's take on this list. The Googlers on
this list are engineers and are not in position to provide legal or
business advice.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

Android Online Training: 26-30 April 2010: http://onlc.com

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

It comes up all the time, and every time it comes back to no, they
specifically said not to do that.

At first glance, section 3.3:
All fees received by Developers for Products distributed via the Market must
be processed by the Market’s Payment Processor.

All fees. (And unless you have a weird contract with google checkout, your
standard account is unlikely to do that 70/30 split, pay the carriers, etc -
so its not the -market- payment processor.)

On Tue, Mar 23, 2010 at 9:50 AM, Warren warrenba...@gmail.com wrote:

Disconnect, I don't think the market agreement is clear on this.

It is clear that if you charge for apps, the payment has to go through
the Market processor.

I'm talking about something different. In this scenario, the app
doesn't change and all functionality is still available to all users.
However, users can purchase virtual goods for use in the game (which
may also be attainable without purchase).

The reason I am asking is not to skirt the rules without being caught.
Just the opposite, I'm seeking clarification up front to avoid
misunderstanding. That is why I'm looking for Google's input on how to
proceed. This has got to be a very common issue. And clearing this up
would help a lot of developers.

I believe that selling virtual goods that can be used in an online
game app does not violate the agreement. I just want to get Google's
take.

On Mar 23, 8:37 am, Disconnect dc.disconn...@gmail.com wrote:
Too bad for you that the market agreement is -very- clear about it and
you've just publicly admitted any violation is willful and intentional.
ISTR
the agreement says they can pull every dime you made from market if you
do
that sort of thing...

Good luck though.

On Tue, Mar 23, 2010 at 9:25 AM, Yahel kaye...@gmail.com wrote:
Hi,

I'm actually very interested as well.
I think if the Android Team doesn't answer it's just that it's not an
issue for them.

And as we say in France Qui ne dit mot, consent :D

I'll publish my cease and desist letter here if I get one :D

Yahel

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
android-developers%2bunsubscr...@googlegroups.comandroid-developers%252bunsubscr...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words
REMOVE
ME as the subject.

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

He is asking for someone to interpret a contract - that is legal advice.
Just like what router would you buy is technical advice - would you ask a
random lawyer that question?

On Tue, Mar 23, 2010 at 10:36 AM, polyclefsoftware dja...@gmail.com wrote:

 He doesn't want legal or business advice. He wants a clarification
 of Google's policy regarding the implementation of a specific
 feature.

 That is not an unreasonable request, and if this is not the venue in
 which to ask for such a clarification, then how exactly are developers
 supposed to go about getting such clarification?

 Just implementing a feature and seeing what happens is a risky and
 less-than-ideal course of action.

 On Mar 23, 9:07 am, Mark Murphy mmur...@commonsware.com wrote:
  Warren wrote:
   I just want to get Google's take.
 
  You're not likely to get Google's take on this list. The Googlers on
  this list are engineers and are not in position to provide legal or
  business advice.
 
  --
  Mark Murphy (a Commons Guy)http://commonsware.com|
 http://twitter.com/commonsguy
 
  Android Online Training: 26-30 April 2010:http://onlc.com

 --
 You received this message because you are subscribed to the Google
 Groups Android Developers group.
 To post to this group, send email to android-developers@googlegroups.com
 To unsubscribe from this group, send email to
 android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

 To unsubscribe from this group, send email to android-developers+
 unsubscribegooglegroups.com or reply to this email with the words REMOVE
 ME as the subject.


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

polyclefsoftware wrote:
 He doesn't want legal or business advice. He wants a clarification
 of Google's policy regarding the implementation of a specific
 feature.

That is legal or business advice compared to technical QA, which is
the purpose of this list and the role of the Googlers on it.

 That is not an unreasonable request, and if this is not the venue in
 which to ask for such a clarification, then how exactly are developers
 supposed to go about getting such clarification?

The only people in position to answer that sort of policy question will
be the executives in charge of Android.

Hence, either you have the personal connections to ask the question of
an executive at a multi-billion-dollar firm, or you don't. If you do,
use them. If you don't, you either live without the answer or you find
some way to get those connections (e.g., form a cooperative with a
thousand other leading Android developers and get negotiating clout that
way).

The most you will get from asking the question here is that a Googler
*may* mention to an executive that people are asking this sort of
question. This *may* trigger some sort of blog post or similar
announcement on the topic *eventually*. However, that will not be quick,
and I don't get the impression that the OP was expecting that sort of
delay. You're not going to get a conversational response on questions
like that here the way you might get a response regarding questions on
garbage collection.

 Just implementing a feature and seeing what happens is a risky and
 less-than-ideal course of action.

Indubitably. And I'm not dismissing the question, or the interest in
in-app payments.

Asking the question here, though, is akin to asking a Toyota automotive
engineer how their firm intends to respond to the various lawsuits and
government inquiries surrounding the recent spate of security defects in
their cars. That's not the engineer's area of expertise or authority.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

Android App Developer Training: http://commonsware.com/training

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

On Tue, Mar 23, 2010 at 11:24 AM, polyclefsoftware dja...@gmail.com wrote:

 Disconnect wrote:
 At first glance, section 3.3:
 All fees received by Developers for Products distributed via the
 Market must
 be processed by the Market’s Payment Processor.
 All fees. (And unless you have a weird contract with google
 checkout, your
 standard account is unlikely to do that 70/30 split, pay the carriers,
 etc -
 so its not the -market- payment processor.)

 So all those fees I and other developers receive for in-app ads from
 various providers are in violation of the Market Agreement?
 Free, ad-supported apps are *products distributed via the Market*. And
 all fees from ads do not flow through Google Checkout. You saying
 all apps with ads need to be yanked?


Nice try, but you need to read the -whole- agreement:

Payment Processor(s): Any party authorized by Google to provide payment
processing services that enable Developers with optional Payment Accounts to
charge Device users for Products distributed via the Market.
Ad revenue isn't a fee. If nobody clicks your ads, the app doesn't
disappear. You aren't charging the users -a fee- for the app any more than
gmail is when they show ads there..

Mark Murphy wrote:
 That is legal or business advice compared to technical QA, which
 is
 the purpose of this list and the role of the Googlers on it.

 The very fact that he has to resort to asking here should demonstrate
 the need for a business contact to handle non-technical issues related
 to the development and distribution of apps via the Android Market. I
 have a contact I work with at Google on the AdSense team that I can
 ask about questions related to whether or not specific implementations
 are acceptable or whether they violate terms of service.

 Check the group charter:
*Discuss developing Android applications using the Android framework. Get
help with troubleshooting apps, advice on implementation, and strategies for
improving your app's speed and user experience.*

Sorry, nothing there about getting legal advice from google..

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Yahel wrote:
 standard account is unlikely to do that 70/30 split, pay the carriers,
 
 AGAIN !! This is driving me crazy !!!
 Where did everybody get this info that the 30% goes to the carriers
 and why would that be ?
 I want, I demand, I beg for a link or something and an explanation as
 to why a carrier would get money over a web service ?

http://android-developers.blogspot.com/2008/10/android-market-now-available-for-users.html

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

Android Development Wiki: http://wiki.andmob.org

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Ok.

I am REALLY trying to play ball here.

I will then ask a technical question on this issue.

If we have to go though the Android Market for people to purchase virtual
items though our app's (like a movie, or music) from a site then how do we
do that within our application technically - using the Android Market?

We want a user to go to a site using our app's and buy something and
download it and us it within our app.
If we have to go though the Android Market to do that then...how???
If the items can be anything from a movie to music to additional characters
for a game? How do we technically do that using the Android market within
our application if that is the ONLY choice we have for our users to purchase
a virtual item?

That is a technical question.

:-)

Thank you
-Chris

On Tue, Mar 23, 2010 at 9:32 AM, Disconnect dc.disconn...@gmail.com wrote:

On Tue, Mar 23, 2010 at 11:24 AM, polyclefsoftware dja...@gmail.comwrote:

Disconnect wrote:
At first glance, section 3.3:
All fees received by Developers for Products distributed via the
Market must
be processed by the Market’s Payment Processor.
All fees. (And unless you have a weird contract with google
checkout, your
standard account is unlikely to do that 70/30 split, pay the carriers,
etc -
so its not the -market- payment processor.)

So all those fees I and other developers receive for in-app ads from
various providers are in violation of the Market Agreement?
Free, ad-supported apps are *products distributed via the Market*. And
all fees from ads do not flow through Google Checkout. You saying
all apps with ads need to be yanked?

Nice try, but you need to read the -whole- agreement:

Payment Processor(s): Any party authorized by Google to provide payment
processing services that enable Developers with optional Payment Accounts to
charge Device users for Products distributed via the Market.
Ad revenue isn't a fee. If nobody clicks your ads, the app doesn't
disappear. You aren't charging the users -a fee- for the app any more than
gmail is when they show ads there..

Mark Murphy wrote:
That is legal or business advice compared to technical QA, which
is
the purpose of this list and the role of the Googlers on it.

The very fact that he has to resort to asking here should demonstrate
the need for a business contact to handle non-technical issues related
to the development and distribution of apps via the Android Market. I
have a contact I work with at Google on the AdSense team that I can
ask about questions related to whether or not specific implementations
are acceptable or whether they violate terms of service.

Check the group charter:
*Discuss developing Android applications using the Android framework. Get
help with troubleshooting apps, advice on implementation, and strategies for
improving your app's speed and user experience.*

Sorry, nothing there about getting legal advice from google..

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

With one update: If the carrier doesn't get a cut (eg nexus one on
unsupported carrier) then that 30% goes to google. (Or at least, it goes
-somewhere- other than the developer - I'm not sure that they've ever
actually addressed that, so I could be wrong.)

On Tue, Mar 23, 2010 at 11:40 AM, Mark Murphy mmur...@commonsware.comwrote:

 Yahel wrote:
  standard account is unlikely to do that 70/30 split, pay the carriers,
 
  AGAIN !! This is driving me crazy !!!
  Where did everybody get this info that the 30% goes to the carriers
  and why would that be ?
  I want, I demand, I beg for a link or something and an explanation as
  to why a carrier would get money over a web service ?


 http://android-developers.blogspot.com/2008/10/android-market-now-available-for-users.html

 --
 Mark Murphy (a Commons Guy)
 http://commonsware.com | http://twitter.com/commonsguy

 Android Development Wiki: http://wiki.andmob.org

 --
 You received this message because you are subscribed to the Google
 Groups Android Developers group.
 To post to this group, send email to android-developers@googlegroups.com
 To unsubscribe from this group, send email to
 android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

 To unsubscribe from this group, send email to android-developers+
 unsubscribegooglegroups.com or reply to this email with the words REMOVE
 ME as the subject.


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

2010-03-23 Thread TreKing

Interesting discussion.

3.3 - All fees received by Developers for Products distributed via the
Market must be processed by the Market’s Payment Processor.

One could argue that fees received by Developers for Products distributed
via the Market only applies to apps sold through the market. If you then
used your app to allow the user to buy stuff from your website, those fees
would not be for products distributed via the Market, they would be for
products distributed via your website and would not be subject to being
processed by the Payment Processor.

Thoughts?

-
TreKing - Chicago transit tracking app for Android-powered devices
http://sites.google.com/site/rezmobileapps/treking

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

On Tue, Mar 23, 2010 at 11:56 AM, polyclefsoftware dja...@gmail.com wrote:

Disconnect wrote:
Nice try, but you need to read the -whole- agreement:

Payment Processor(s): Any party authorized by Google to provide payment
processing services that enable Developers with optional Payment Accounts
to
charge Device users for Products distributed via the Market.
Ad revenue isn't a fee. If nobody clicks your ads, the app doesn't
disappear. You aren't charging the users -a fee- for the app any more
than
gmail is when they show ads there..

What fills you with certainty that ad revenue is clearly not a fee,
while an in-app purchase is?

Seriously, go read the whole thing. Then get legal advice. In most
countries a simple initial consultation such as this would be free. (And
they specifically say in-app purchases are banned. We covered that part
earlier.)

4.4 Prohibited Actions. [..] You may not use customer information obtained
from the Market to sell or distribute Products outside of the Market.

4.5 Non-Compete. You may not use the Market to distribute or make available
any Product whose primary purpose is to facilitate the distribution of
Products outside of the Market.
(Technically this might apply to brickmorter distribution as well - eg the
non-mp3 amazon app. Get legal advice.)

Ad revenue is a fee charged to the user fails the 'reasonable
person/common man' test.

Check the group charter:

*Discuss developing Android applications using the Android framework. Get
help with troubleshooting apps, advice on implementation, and strategies
for
improving your app's speed and user experience.*

Sorry, nothing there about getting legal advice from google..

Wow, you know what? You're absolutely right, and you completely
ignored the point that this is not a question for a third-party legal
advisor to answer, but for *Google* to answer.

..and it STILL doesn't say ask us about our contracts. (For that matter,
there is a market support forum. Try there.)

The question stands, if this is not the proper venue, then how exactly
are developers supposed to find out whether or not specific decisions
are acceptable to Google? Mark Murphy seems to think that this
requires executive-level contacts. I don't think that is the case.
I've interacted with representatives from other Google services that
were able to clarify whether or not implementation issues violated
Google's terms of service. Is this really too much to ask for Android?

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

These guys seems to find a way to make it work.

Looks like they just add updates to their app though the market.

http://phandroid.com/2009/11/23/android-in-app-purchases-breached-by-ringz/

-Chris

On Tue, Mar 23, 2010 at 10:12 AM, Warren warrenba...@gmail.com wrote:

If you then
used your app to allow the user to buy stuff from your website, those
fees
would not be for products distributed via the Market, they would be for
products distributed via your website and would not be subject to being
processed by the Payment Processor.

Thoughts?

This is exactly what I'm thinking. And I think this would be allowable
under the agreement.

On Mar 23, 10:53 am, TreKing treking...@gmail.com wrote:
Interesting discussion.

3.3 - All fees received by Developers for Products distributed via the
Market must be processed by the Market’s Payment Processor.

Thoughts?

-
TreKing - Chicago transit tracking app for Android-powered deviceshttp://
sites.google.com/site/rezmobileapps/treking

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Not sure about any digital-downloads side of the amazon store, but mp3 store
has been an exception from the very beginning, back when there were -no-
paid downloads for android.

Movie tickets are physical items, the agreement seems focused on digital
items. (And fandango movie tickets don't alter/enhance the fandango app in
any way, any more than buying a grill off amazon does :) ..)

I'm failing the search test (because the question comes up -way- more than
the answer) but IIRC a google/android employee was the first to suggest the
unlockable-apps method.

(As an aside, there are even examples that -directly- violate it, without
any sort of special agreements. Take a look at pixelpipe - the free, working
app was initially outright replaced with a paid app, then they undid that
and released an app that just says buy the full version. Both moves are
directly against that agreement, but google didn't care..)

On Tue, Mar 23, 2010 at 12:03 PM, Streets Of Boston flyingdutc...@gmail.com
wrote:

I wonder how Amazon.com (Music Store/MP3 Store) interprets these rules/
contract...?

You can download music from Amazon.com on your Android phone without
going through Android Market for each song/album purchase.

You can buy movie tickeds from the Fandango application. Movie tickets
are not charged through Android Market.

And there are more of such examples.

I think it's more of a protection for users of Android phones who
download apps from the Market.
E.g. what a developer can't do is putting up an application for free
and then charge the user some other way so that he/she can actually
use the application.

It looks like store fronts are fine (like Amazon, Fandango).
Putting up a (free) app then charging an (additional) fee just to be
able to use the app at all is not OK.

Note, this is just my interpretation of it all. I'm NOT a lawyer.

On Mar 17, 3:06 pm, Warren warrenba...@gmail.com wrote:
I have still not seen an acceptable solution for in-app purchasing,
and I was hoping for an official response from Google.

This has been discussed in other threads, but there is still no good
solution.
http://groups.google.com/group/android-developers/browse_thread/threa...

Collecting a fee to unlock functionality or to buy virtual items is
not a technical problem. It is straightforward.

However, the Market Agreement severely limits developers' ability to
collect such a fee. It says all fees collected for the app must go
through the Market payment processor.

http://www.android.com/us/developer-distribution-agreement.html

Buying another app from the Market seems the only clearly acceptable
solution. But that is not ideal. It perverts the definition of an
app and causes problems because of the refund policy.

Google, how are developers supposed to handle this situation? Or is
your intention that we simply not do this?

While lawyers may quarrel over the actual document, what is your
intent as it pertains to buying virtual items? For example, charging
$1 real money for 10 in-game gold?

What if only the front end of the game is distributed on the market,
and the features of the front end (the app) do not change with
additional fees? This may be splitting hairs but that's what happens
with legal documents, I suppose.

So what is the intention of the Market Agreement here? Did you intend
to prevent buying virtual items or not?

I would appreciate some clarification so I can proceed knowing the
spirit of the law, so to speak.

Thank you

To unsubscribe from this group, send email to android-developers+
unsubscribegooglegroups.com or reply to this email with the words REMOVE
ME as the subject.

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to
android-developers+unsubscribegooglegroups.com or reply to this email with the
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

So, I am curious how a service like ScoreLoop is going to work? They provide
in-game tokens you buy with real many, or something like that. I apologize,
I haven't read up on it entirely. But a lot of android game developers are
looking to use ScoreLoop. ScoreLoop is already used a bit on iPhone, which I
thought in-game purchases were not allowed on? I could be wrong.. I gave up
on iPhone a while ago with all their ridiculous changing rules. But if
ScoreLoop can provide a way to spend real money on in-game tokens, of which
they benefit from financially, I can't see why any other game/app can't do
it.

Here is my interpretation of the google contract, just from reading it and
bits and pieces of other posts of the past few months. From what I gather,
you can NOT sell updates (or offer updates) thru an in-game service. They
all must go thru the android market. I don't know if that is clear enough to
insinuate that game add-ons, such as new levels, can't be downloaded. If
they do mean that, then any game developer that wanted to offer say an open
game editor to make new maps for their cool game, just got shut down. I
think that stinks, and if android is so open, I can't imagine why that is a
big deal.

I really do NOT interpret anything they say as a no, you can't provide
in-game items for sale. In the World-of-Warcraft sense, you should be able
to sell gold for real money if you want. Or allow gamers to trade items
with each other, perhaps for money... for example, some player found a rare
item in your game.. you only provide maybe 3 total, that player can sell the
item to another player (somehow) for real money. If your game has in-game
payment/processing, then the game developer takes a cut, and everybody is
happy. Hell, I would be fine if google provided all the payment processing
API and required a cut. If I could sell items at .25 each for example, I am
fine with giving .10 or .20 even of that to google. Hell, google should be
doing this! If they make no money on app purchases.. as someone else said,
what's the money maker benefit of Android for them. I don't know why they
would NOT offer something like this from the start. Simply say If you build
in your own payment processing.. money is all yours. If you wish to avoid
the headaches of state taxes, IRS issues, different country/currencies,
etc.. use our built in API and we'll take a 25% cut of the transaction..
BOOM! Google, like apple, would be making big money! Coming out and saying
that, and even better providing the payment processing API (I would say
google checkout AND paypal required tho).



On Tue, Mar 23, 2010 at 9:25 AM, Disconnect dc.disconn...@gmail.com wrote:

 Not sure about any digital-downloads side of the amazon store, but mp3
 store has been an exception from the very beginning, back when there were
 -no- paid downloads for android.

 Movie tickets are physical items, the agreement seems focused on digital
 items. (And fandango movie tickets don't alter/enhance the fandango app in
 any way, any more than buying a grill off amazon does :) ..)

 I'm failing the search test (because the question comes up -way- more than
 the answer) but IIRC a google/android employee was the first to suggest the
 unlockable-apps method.

 (As an aside, there are even examples that -directly- violate it, without
 any sort of special agreements. Take a look at pixelpipe - the free, working
 app was initially outright replaced with a paid app, then they undid that
 and released an app that just says buy the full version. Both moves are
 directly against that agreement, but google didn't care..)


 On Tue, Mar 23, 2010 at 12:03 PM, Streets Of Boston 
 flyingdutc...@gmail.com wrote:

 I wonder how Amazon.com (Music Store/MP3 Store) interprets these rules/
 contract...?

 You can download music from Amazon.com on your Android phone without
 going through Android Market for each song/album purchase.

 You can buy movie tickeds from the Fandango application. Movie tickets
 are not charged through Android Market.

 And there are more of such examples.

 I think it's more of a protection for users of Android phones who
 download apps from the Market.
 E.g. what a developer can't do is putting up an application for free
 and then charge the user some other way so that he/she can actually
 use the application.

 It looks like store fronts are fine (like Amazon, Fandango).
 Putting up a (free) app then charging an (additional) fee just to be
 able to use the app at all is not OK.

 Note, this is just my interpretation of it all. I'm NOT a lawyer.



 On Mar 17, 3:06 pm, Warren warrenba...@gmail.com wrote:
  I have still not seen an acceptable solution for in-app purchasing,
  and I was hoping for an official response from Google.
 
  This has been discussed in other threads, but there is still no good
  solution.
 http://groups.google.com/group/android-developers/browse_thread/threa...
 
  Collecting a fee to unlock functionality or to buy virtual items is
  not a

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

On a different note... technically.. if Google does not provide the api to
handle this.. how are some of you thinking of actually implementing this?
Will you require the game player to enter credit card or paypal/google
checkout info into your game in order to charge them? I fear that if every
game has some different way of doing this, it's going to deter players..
they will get tired of entering this info over and over, and more so
probably fearful that the game developer has their private info. Having
google provide an API is probably safer and more likely to get people to use
it, not to mention only having to enter the info once for their device, then
game developers can use some API to see if they filled it out, if not, ask
for it, if so, use it.

I personally don't want to have to deal with requiring credt card info,
billing/shipping address info to verify the credit card, etc. Nor would I
want my app to be responsible for that private info if I could avoid it.

So what are some ways to actually implement this feature?


On Tue, Mar 23, 2010 at 9:54 AM, Kevin Duffey andjar...@gmail.com wrote:

 So, I am curious how a service like ScoreLoop is going to work? They
 provide in-game tokens you buy with real many, or something like that. I
 apologize, I haven't read up on it entirely. But a lot of android game
 developers are looking to use ScoreLoop. ScoreLoop is already used a bit on
 iPhone, which I thought in-game purchases were not allowed on? I could be
 wrong.. I gave up on iPhone a while ago with all their ridiculous changing
 rules. But if ScoreLoop can provide a way to spend real money on in-game
 tokens, of which they benefit from financially, I can't see why any other
 game/app can't do it.

 Here is my interpretation of the google contract, just from reading it and
 bits and pieces of other posts of the past few months. From what I gather,
 you can NOT sell updates (or offer updates) thru an in-game service. They
 all must go thru the android market. I don't know if that is clear enough to
 insinuate that game add-ons, such as new levels, can't be downloaded. If
 they do mean that, then any game developer that wanted to offer say an open
 game editor to make new maps for their cool game, just got shut down. I
 think that stinks, and if android is so open, I can't imagine why that is a
 big deal.

 I really do NOT interpret anything they say as a no, you can't provide
 in-game items for sale. In the World-of-Warcraft sense, you should be able
 to sell gold for real money if you want. Or allow gamers to trade items
 with each other, perhaps for money... for example, some player found a rare
 item in your game.. you only provide maybe 3 total, that player can sell the
 item to another player (somehow) for real money. If your game has in-game
 payment/processing, then the game developer takes a cut, and everybody is
 happy. Hell, I would be fine if google provided all the payment processing
 API and required a cut. If I could sell items at .25 each for example, I am
 fine with giving .10 or .20 even of that to google. Hell, google should be
 doing this! If they make no money on app purchases.. as someone else said,
 what's the money maker benefit of Android for them. I don't know why they
 would NOT offer something like this from the start. Simply say If you build
 in your own payment processing.. money is all yours. If you wish to avoid
 the headaches of state taxes, IRS issues, different country/currencies,
 etc.. use our built in API and we'll take a 25% cut of the transaction..
 BOOM! Google, like apple, would be making big money! Coming out and saying
 that, and even better providing the payment processing API (I would say
 google checkout AND paypal required tho).




 On Tue, Mar 23, 2010 at 9:25 AM, Disconnect dc.disconn...@gmail.comwrote:

 Not sure about any digital-downloads side of the amazon store, but mp3
 store has been an exception from the very beginning, back when there were
 -no- paid downloads for android.

 Movie tickets are physical items, the agreement seems focused on digital
 items. (And fandango movie tickets don't alter/enhance the fandango app in
 any way, any more than buying a grill off amazon does :) ..)

 I'm failing the search test (because the question comes up -way- more than
 the answer) but IIRC a google/android employee was the first to suggest the
 unlockable-apps method.

 (As an aside, there are even examples that -directly- violate it, without
 any sort of special agreements. Take a look at pixelpipe - the free, working
 app was initially outright replaced with a paid app, then they undid that
 and released an app that just says buy the full version. Both moves are
 directly against that agreement, but google didn't care..)


 On Tue, Mar 23, 2010 at 12:03 PM, Streets Of Boston 
 flyingdutc...@gmail.com wrote:

 I wonder how Amazon.com (Music Store/MP3 Store) interprets these rules/
 contract...?

 You can download music from Amazon.com on your Android

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

polyclefsoftware wrote:
 Some other Google services provide this type of business contact.
 Android does not. It should.

Agreed.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

Android App Developer Training: http://commonsware.com/training

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

To unsubscribe from this group, send email to 
android-developers+unsubscribegooglegroups.com or reply to this email with the 
words REMOVE ME as the subject.

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

I dont know that I agree Chris.. this issue is not resolved in my opinion.
There needs to be a definitive response from google, maybe not here, but
perhaps from a developer that has dealt with this issue.

The problem with using the market for updates.. is that it's going to flood
the market with items that end users have to scroll thru to find other apps,
and they are updates. How the heck is that any good? What google should do
is provide an update section to the market, so that developers can put
game expansions, in-game items, etc in that section and NOT pollute the main
apps/games section of the market. A user will stay on a web page for about 3
seconds on average before they get bored and leave if it takes too long to
load. How long will end users scroll through a list of mostly
add-ons/in-game updates if they are intermixed with all the other apps. I
know I don't spend that much time, at most I load more a couple of times.
If the market doesn't get cleaned up, it's going to deter more and more
users and degrade the overall android experience. I am baffled as to why the
market doesn't get some sort of regular updates that make it better. As far
as I can tell, it's a locked app on our devices, but it's an app. Is there
nobody at google hearing all the negative feedback on how it works and
looking to better it?

Like I said above, this is a VERY good opportunity for Google to offer a
built-in API (or an add-on SDK api so that 1.5+ android apps can take
advantage of it, not just 2.2+ when it could come out) that provides a
single sign-on device form.. the device owner only has to fill in their
paypal/google checkout info once, and all apps can make use of it for
in-game purchases. Google takes a cut, and makes money. Apple is freaking
huge due to iTunes.. this would be the same thing for google. Provide us
with the checkout/purchase API, and take a cut, 25%, 30%, whatever.

It's evident a LOT of game developers, and even app developers, want to have
a way to make some money. Microtransactions has been reported on as being
one of the biggest things coming up for making money. Developers may not
make much on their games alone, but if their game offers simple in-game
purchases of some sort, the developer has another avenue of making some
money. The end result is more developers work this in to their apps/games,
providing more/longer lasting games, and Android benefits, and google
benefits too by actually making some money. I see nothing wrong with this at
all, I think it's fair if google put the leg work into the purchasing api
that we can all use, they get a cut.

On Tue, Mar 23, 2010 at 10:20 AM, chris harper ch393...@gmail.com wrote:

 Ok... Ok.

 Guys.

 I didn't realize that Google does not allow In-App Purchasing.
 After searching around the internet I see that Apple just allowed their
 developers this option but we do not have the same ability.

 That kind of sucks but that's how it is. I currently have a little rain
 cloud above me and my PC as I write this.

 I am ready to move on now.

 I have to do some redesign on my app. I see am now going to go the same
 route that this application is doing:
 http://phandroid.com/2009/11/23/android-in-app-purchases-breached-by-ringz/

 Where they just make updates to there app available on the Market for
 additional features that they want their users to buy.

 So my simple question is does anyone have any examples (or threads) that
 show or talk about how to update your app with another updated apk WITHOUT
 reinstalling the whole app again?
 So just to add updated features?
 This way I can put my app out there and put my updates in additional apk
 files on the market which users can buy.

 Does anyone have any examples how the best practice is to do this?
 It involves app keys and all that I presume.

 Thank you


 On Tue, Mar 23, 2010 at 11:14 AM, polyclefsoftware dja...@gmail.comwrote:

 Disconnect wrote:
  Ad revenue is a fee charged to the user fails the 'reasonable
  person/common man' test.

 And what about the other part of my question? What makes you
 absolutely certain that in-app purchases are forbidden under the
 Market Agreement?

 I think as others in this discussion have demonstrated, the policy is
 far from crystal clear.

  ..and it STILL doesn't say ask us about our contracts. (For that
 matter,
  there is a market support forum. Try there.)

 Hah...good one. You'd have better luck putting a written note in a
 bottle and throwing it in your swimming pool.

 Look, this and other policies that directly impact what and how we
 develop apps are not always clear (another example is tethering).
 Third-party legal advice will not resolve these ambiguities. The
 clarification must come from Google.

 Some other Google services provide this type of business contact.
 Android does not. It should.

 --
 You received this message because you are subscribed to the Google
 Groups Android Developers group.
 To post to this group, send email to

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

KevinYou just hit the nail on the head. Most of us are making applications
to make some extra money and if google is not going to allow developers to
do In-App Purchasing then we need a good alternate solution.

*PLEASE FOR THE ANDROID ENGINEERS ON HERE! *- If we can't do in-app
purchasing then ok. That's now it is. That what do we do for extra
functionality or virtual items for our app's that we want our users to buy
and download?
Is the only solution for us developers to add a new apk file on the Market
for any and all items that we want our app to download and use?
In my case my app is based on little characters. It comes with so many but I
want the users to buy and download new ones. I was going to do this via a
website but I am seeing now that I can't do that?
Now I am thinking that I need to bundle them up in an apk update and put
them on the market but as Kevin eluded to this will lead to many apk
versions on the market.

Is this want we need to do though?

I am wanting to fight one way or another but I need to know how to design my
application to provide this ability.

Thank you
-Chris



On Tue, Mar 23, 2010 at 11:29 AM, Kevin Duffey andjar...@gmail.com wrote:

 I dont know that I agree Chris.. this issue is not resolved in my opinion.
 There needs to be a definitive response from google, maybe not here, but
 perhaps from a developer that has dealt with this issue.

 The problem with using the market for updates.. is that it's going to flood
 the market with items that end users have to scroll thru to find other apps,
 and they are updates. How the heck is that any good? What google should do
 is provide an update section to the market, so that developers can put
 game expansions, in-game items, etc in that section and NOT pollute the main
 apps/games section of the market. A user will stay on a web page for about 3
 seconds on average before they get bored and leave if it takes too long to
 load. How long will end users scroll through a list of mostly
 add-ons/in-game updates if they are intermixed with all the other apps. I
 know I don't spend that much time, at most I load more a couple of times.
 If the market doesn't get cleaned up, it's going to deter more and more
 users and degrade the overall android experience. I am baffled as to why the
 market doesn't get some sort of regular updates that make it better. As far
 as I can tell, it's a locked app on our devices, but it's an app. Is there
 nobody at google hearing all the negative feedback on how it works and
 looking to better it?

 Like I said above, this is a VERY good opportunity for Google to offer a
 built-in API (or an add-on SDK api so that 1.5+ android apps can take
 advantage of it, not just 2.2+ when it could come out) that provides a
 single sign-on device form.. the device owner only has to fill in their
 paypal/google checkout info once, and all apps can make use of it for
 in-game purchases. Google takes a cut, and makes money. Apple is freaking
 huge due to iTunes.. this would be the same thing for google. Provide us
 with the checkout/purchase API, and take a cut, 25%, 30%, whatever.

 It's evident a LOT of game developers, and even app developers, want to
 have a way to make some money. Microtransactions has been reported on as
 being one of the biggest things coming up for making money. Developers may
 not make much on their games alone, but if their game offers simple in-game
 purchases of some sort, the developer has another avenue of making some
 money. The end result is more developers work this in to their apps/games,
 providing more/longer lasting games, and Android benefits, and google
 benefits too by actually making some money. I see nothing wrong with this at
 all, I think it's fair if google put the leg work into the purchasing api
 that we can all use, they get a cut.

 On Tue, Mar 23, 2010 at 10:20 AM, chris harper ch393...@gmail.com wrote:

 Ok... Ok.

 Guys.

 I didn't realize that Google does not allow In-App Purchasing.
 After searching around the internet I see that Apple just allowed their
 developers this option but we do not have the same ability.

 That kind of sucks but that's how it is. I currently have a little rain
 cloud above me and my PC as I write this.

 I am ready to move on now.

 I have to do some redesign on my app. I see am now going to go the same
 route that this application is doing:

 http://phandroid.com/2009/11/23/android-in-app-purchases-breached-by-ringz/

 Where they just make updates to there app available on the Market for
 additional features that they want their users to buy.

 So my simple question is does anyone have any examples (or threads) that
 show or talk about how to update your app with another updated apk WITHOUT
 reinstalling the whole app again?
 So just to add updated features?
 This way I can put my app out there and put my updates in additional apk
 files on the market which users can buy.

 Does anyone have any examples how the best practice is to do

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Warren

My app is still in development but this is what I am doing. Within my app I
open a web browser to my site where I am using ZenCart.
http://www.zen-cart.com/

ZenCart handles all my store process and credit card processing. Once a user
selects an item and makes a payment (which are characters that my app uses
in my case) they can then download the new character (in a .zip file) which
my app takes and installs.

What WAS the way I was going to do it but from what I am reading I am not
sure that Google will allow that.

If I can't do that within my app then I am asking the Google Development
guys want my alternative solution is?

(queue tumble weed blowing by and cricket chirping in background)

;-)

-Chris

On Tue, Mar 23, 2010 at 12:28 PM, Warren warrenba...@gmail.com wrote:

 An in-app purchase API would be ideal for many reasons. It would spare
 users from having to enter credit card information repeatedly. It
 could also take advantage of carrier billing where it is available. It
 could also provide more revenue for Google.

 The question was asked about how else to do credit card charges.

 Without an API option, I would likely send the user to a payment
 processor like Amazon or PayPal. That way the user deals directly with
 a proven system and I don't have the liability of handling credit card
 data. Then the processor sends my server a notification of successful
 payment. I checked and both of Amazon and PayPal have micro
 transaction rates that are far better than the standard $.30 + 3% for
 small values.

 This is just on the technical end, assuming you have met the Market
 Agreement details.


 On Mar 23, 12:29 pm, Kevin Duffey andjar...@gmail.com wrote:
  I dont know that I agree Chris.. this issue is not resolved in my
 opinion.
  There needs to be a definitive response from google, maybe not here, but
  perhaps from a developer that has dealt with this issue.
 
  The problem with using the market for updates.. is that it's going to
 flood
  the market with items that end users have to scroll thru to find other
 apps,
  and they are updates. How the heck is that any good? What google should
 do
  is provide an update section to the market, so that developers can put
  game expansions, in-game items, etc in that section and NOT pollute the
 main
  apps/games section of the market. A user will stay on a web page for
 about 3
  seconds on average before they get bored and leave if it takes too long
 to
  load. How long will end users scroll through a list of mostly
  add-ons/in-game updates if they are intermixed with all the other apps. I
  know I don't spend that much time, at most I load more a couple of
 times.
  If the market doesn't get cleaned up, it's going to deter more and more
  users and degrade the overall android experience. I am baffled as to why
 the
  market doesn't get some sort of regular updates that make it better. As
 far
  as I can tell, it's a locked app on our devices, but it's an app. Is
 there
  nobody at google hearing all the negative feedback on how it works and
  looking to better it?
 
  Like I said above, this is a VERY good opportunity for Google to offer a
  built-in API (or an add-on SDK api so that 1.5+ android apps can take
  advantage of it, not just 2.2+ when it could come out) that provides a
  single sign-on device form.. the device owner only has to fill in their
  paypal/google checkout info once, and all apps can make use of it for
  in-game purchases. Google takes a cut, and makes money. Apple is freaking
  huge due to iTunes.. this would be the same thing for google. Provide us
  with the checkout/purchase API, and take a cut, 25%, 30%, whatever.
 
  It's evident a LOT of game developers, and even app developers, want to
 have
  a way to make some money. Microtransactions has been reported on as being
  one of the biggest things coming up for making money. Developers may not
  make much on their games alone, but if their game offers simple in-game
  purchases of some sort, the developer has another avenue of making some
  money. The end result is more developers work this in to their
 apps/games,
  providing more/longer lasting games, and Android benefits, and google
  benefits too by actually making some money. I see nothing wrong with this
 at
  all, I think it's fair if google put the leg work into the purchasing api
  that we can all use, they get a cut.
 
  On Tue, Mar 23, 2010 at 10:20 AM, chris harper ch393...@gmail.com
 wrote:
   Ok... Ok.
 
   Guys.
 
   I didn't realize that Google does not allow In-App Purchasing.
   After searching around the internet I see that Apple just allowed their
   developers this option but we do not have the same ability.
 
   That kind of sucks but that's how it is. I currently have a little rain
   cloud above me and my PC as I write this.
 
   I am ready to move on now.
 
   I have to do some redesign on my app. I see am now going to go the same
   route that this application is doing:

Re: [android-developers] Re: In-App Purchasing and the Market Agreement

Chris, as I said to Warren.. how many end users of your game are willing to
go through that extra long process to buy things? Why google/android would
NOT want to make almost free money by providing their google checkout as a
built in API and allow games/apps to use it in-game/app to offer goods, and
NOT leave the game.. either charge it to some sort of paypal like account
(can't remember if google checkout ties to credit cards, or paypal, or has a
paypal like thing where you transfer money to it for use)... but really the
best solution all around is for google to provide an API that they make
money off of, the carrier (when applicable) can make some money off of, and
the game developer makes at least 50% of the purchase price. Everyone wins.
I don't see a thing wrong with it. I am no lawyer, so maybe there are legal
ramifications I just can't see.. but I believe not only would everyone win,
more developers would use it, more developers would want to write for
Android knowing they have another avenue of making money, and the Android
platform as a whole would benefit and grow larger.

I am curious tho.. with google pulling out of China.. is Android on phones
in China going to be out of the question for us now? That would suck.. with
500 million potential end users!! Get a friend to translate to Chinese, and
you got a HUGE market of potential buyers for games.. especially puzzle
games that get snapped up all the time.


On Tue, Mar 23, 2010 at 11:38 AM, chris harper ch393...@gmail.com wrote:

 Warren

 My app is still in development but this is what I am doing. Within my app I
 open a web browser to my site where I am using ZenCart.
 http://www.zen-cart.com/

 ZenCart handles all my store process and credit card processing. Once a
 user selects an item and makes a payment (which are characters that my app
 uses in my case) they can then download the new character (in a .zip file)
 which my app takes and installs.

 What WAS the way I was going to do it but from what I am reading I am not
 sure that Google will allow that.

 If I can't do that within my app then I am asking the Google Development
 guys want my alternative solution is?

 (queue tumble weed blowing by and cricket chirping in background)

 ;-)

 -Chris


 On Tue, Mar 23, 2010 at 12:28 PM, Warren warrenba...@gmail.com wrote:

 An in-app purchase API would be ideal for many reasons. It would spare
 users from having to enter credit card information repeatedly. It
 could also take advantage of carrier billing where it is available. It
 could also provide more revenue for Google.

 The question was asked about how else to do credit card charges.

 Without an API option, I would likely send the user to a payment
 processor like Amazon or PayPal. That way the user deals directly with
 a proven system and I don't have the liability of handling credit card
 data. Then the processor sends my server a notification of successful
 payment. I checked and both of Amazon and PayPal have micro
 transaction rates that are far better than the standard $.30 + 3% for
 small values.

 This is just on the technical end, assuming you have met the Market
 Agreement details.


 On Mar 23, 12:29 pm, Kevin Duffey andjar...@gmail.com wrote:
  I dont know that I agree Chris.. this issue is not resolved in my
 opinion.
  There needs to be a definitive response from google, maybe not here, but
  perhaps from a developer that has dealt with this issue.
 
  The problem with using the market for updates.. is that it's going to
 flood
  the market with items that end users have to scroll thru to find other
 apps,
  and they are updates. How the heck is that any good? What google should
 do
  is provide an update section to the market, so that developers can put
  game expansions, in-game items, etc in that section and NOT pollute the
 main
  apps/games section of the market. A user will stay on a web page for
 about 3
  seconds on average before they get bored and leave if it takes too long
 to
  load. How long will end users scroll through a list of mostly
  add-ons/in-game updates if they are intermixed with all the other apps.
 I
  know I don't spend that much time, at most I load more a couple of
 times.
  If the market doesn't get cleaned up, it's going to deter more and more
  users and degrade the overall android experience. I am baffled as to why
 the
  market doesn't get some sort of regular updates that make it better. As
 far
  as I can tell, it's a locked app on our devices, but it's an app. Is
 there
  nobody at google hearing all the negative feedback on how it works and
  looking to better it?
 
  Like I said above, this is a VERY good opportunity for Google to offer a
  built-in API (or an add-on SDK api so that 1.5+ android apps can take
  advantage of it, not just 2.2+ when it could come out) that provides a
  single sign-on device form.. the device owner only has to fill in their
  paypal/google checkout info once, and all apps can make use of it for
  in-game

Re: [android-developers] Re: In-App Purchasing and the Market Agreement