Refactoring AAL to support multiple purchase verification sources
32 views
Skip to first unread message
dadical
Jun 18, 2010, 2:24:00 PM6/18/10
to Automatic Application Licensing
One of the biggest reasons for piracy from the Android Market is
actually the inability to purchase apps. This can be for a number of
reasons including:
- lack of market support for certain international markets
- lack of market support for certain builds of the Android O/S
- lack of market support for purchase mechanisms other than credit
cards
In these cases, it would be great if AAL could provide a hierarchical
purchase validation mechanism, and upon failure, offer users a range
of options for purchasing the pirated APK. Consider the following
workflow.
1. User downloads pirated APK from non-Android Market source and
installs on phone.
2. AAL attempts to validate purchase of app from Android Market first,
and then a sequence of other pluggable sources (e.g., AndAppStore,
Orange Market, etc.).
3. Once validation has failed some configurable number of times, the
user will be presented with an option to purchase the app from a list
of sources, which could be filtered based on detected ability of the
phone to see paid apps on that market.
Questions to answer:
- Is this approach compatible with the Android Market usage agreement?
- What will the remote validation API look like? It probably should
be compatible at some level with the Android Market API (same protobuf
signature?)...
- Should AAL be involved in the purchase transaction? My initial
reaction is "no", but it might would be nice to get some kind of
referral fee :)
actually the inability to purchase apps. This can be for a number of
reasons including:
- lack of market support for certain international markets
- lack of market support for certain builds of the Android O/S
- lack of market support for purchase mechanisms other than credit
cards
In these cases, it would be great if AAL could provide a hierarchical
purchase validation mechanism, and upon failure, offer users a range
of options for purchasing the pirated APK. Consider the following
workflow.
1. User downloads pirated APK from non-Android Market source and
installs on phone.
2. AAL attempts to validate purchase of app from Android Market first,
and then a sequence of other pluggable sources (e.g., AndAppStore,
Orange Market, etc.).
3. Once validation has failed some configurable number of times, the
user will be presented with an option to purchase the app from a list
of sources, which could be filtered based on detected ability of the
phone to see paid apps on that market.
Questions to answer:
- Is this approach compatible with the Android Market usage agreement?
- What will the remote validation API look like? It probably should
be compatible at some level with the Android Market API (same protobuf
signature?)...
- Should AAL be involved in the purchase transaction? My initial
reaction is "no", but it might would be nice to get some kind of
referral fee :)
Al Sutton
Jun 19, 2010, 3:39:08 AM6/19/10
to Automatic Application Licensing
[carried over from android-developers]
You could back off external purchases to AndAppStore if you'd like. We
have a public purchase checking API (details at
http://andappstore.com/AndroidApplications/purchase_checking.jsp ),
and payments are made via PayPal, which opens up several new countries
for developers to sell apps to and from.
Our revenue comes from on-site and in-client ads & customisation work
so we take nothing from app sale revenue. The money is paid directly
from the user to the developers PayPal account, so the only fees
involved are those imposed by PayPal and you can use PayPals tools for
tracking sales information.
As for issues with Market T&Cs and buying from other markets, well,
I'm no lawyer so I can't offer solid advice, but from what I remember
the restriction on only using Market as the payment processor only
applies to applications obtained via Market, so if the application has
been obtained from a pirated site then I wouldn't have thought they
could complain about it.
Al.
You could back off external purchases to AndAppStore if you'd like. We
have a public purchase checking API (details at
http://andappstore.com/AndroidApplications/purchase_checking.jsp ),
and payments are made via PayPal, which opens up several new countries
for developers to sell apps to and from.
Our revenue comes from on-site and in-client ads & customisation work
so we take nothing from app sale revenue. The money is paid directly
from the user to the developers PayPal account, so the only fees
involved are those imposed by PayPal and you can use PayPals tools for
tracking sales information.
As for issues with Market T&Cs and buying from other markets, well,
I'm no lawyer so I can't offer solid advice, but from what I remember
the restriction on only using Market as the payment processor only
applies to applications obtained via Market, so if the application has
been obtained from a pirated site then I wouldn't have thought they
could complain about it.
Al.
dadical
Jun 21, 2010, 3:56:06 PM6/21/10
to Automatic Application Licensing
Hello Al, I have a few questions.
First, looking at your architecture, my initial thought is that
AndAppStore purchase option will be available IF the AndAppStore
client is installed on the phone. I know that you probably want to
promote the installation of your market client on users' phones, but
if we go there I'll want to keep it really simple, such as a link to a
web page.
Second, I'm assuming that users would be performing the purchase via
your on-phone AndAppStore market app. What is the intent pattern for
invoking a purchase of a specific app using your market app?
Third, I see that you provide a ContentProvider for retrieving the
user id from the installed AndAppStore client. If that isn't
available, we would need to ask the user for manual input, or does
your client always require a username?.
Finally, I think it would be nice if you were to add an optional field
to your license check API that would allow you to determine where the
license checks are coming from. That way you can get a feel for how
much of your traffic is being driven from AAL.
Dave
First, looking at your architecture, my initial thought is that
AndAppStore purchase option will be available IF the AndAppStore
client is installed on the phone. I know that you probably want to
promote the installation of your market client on users' phones, but
if we go there I'll want to keep it really simple, such as a link to a
web page.
Second, I'm assuming that users would be performing the purchase via
your on-phone AndAppStore market app. What is the intent pattern for
invoking a purchase of a specific app using your market app?
Third, I see that you provide a ContentProvider for retrieving the
user id from the installed AndAppStore client. If that isn't
available, we would need to ask the user for manual input, or does
your client always require a username?.
Finally, I think it would be nice if you were to add an optional field
to your license check API that would allow you to determine where the
license checks are coming from. That way you can get a feel for how
much of your traffic is being driven from AAL.
Dave
Al Sutton
Jun 22, 2010, 2:41:08 AM6/22/10
to automatic-appli...@googlegroups.com
Hi Dave,
Al.
Apps can be purchased through the AndAppStore website from the applications page (e.g. you can see the buy link on http://andappstore.com/AndroidApplications/apps/Executive_Assistant_Plus ). The client does have to be installed for the user to claim their purchase, but this is to allow us to associate their purchase with their device (something we couldn't do via a web-only interface).
The client doesn't currently require a username so you would need to ask them for it if it isn't present. It would be a good idea to include this logic anyway in case the user only has the AndAppStore client installed to claim their purchase and un-installs the client before they run the app.
At the moment we use the user agent field for statistics gathering. We can add extra fields, or AAL could set its own user agent because the back end logic of the purchase checker isn't user agent based, it's purely a statistical tool.
We're developing a new client at the moment so if there are any intents you'd like added (such as one to fire off the purchasing process) please let me know and I'll make sure they're added in prior to release.
All the best,
Al.
--
--
* Looking for Android Apps? - Try http://andappstore.com/ *
======
Funky Android Limited is registered in England & Wales with the company number 6741909.
The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries.
--
* Looking for Android Apps? - Try http://andappstore.com/ *
======
Funky Android Limited is registered in England & Wales with the company number 6741909.
The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries.
Reply all
Reply to author
Forward
0 new messages