Dave,
Would you be interested in working with us at AndAppStore to offer an
alternative purchase location?
From your code I can see that we could create a LicenseManagerImpl
which interfaces into our purchase checking system to cover the
license management aspect, and we accept payments via
I would be interested in discussing this, Al. Assuming that our use
cases align and that your APIs provide necessary functionality, it
should work quite nicely.
As for the code base, I split LicenseManager and LicenseManagerImpl
primarily to facilitate obfuscation (I don't obfuscate
AAL has now been open-sourced. Find details here: http://bit.ly/coz0yB.
On May 10, 4:24 pm, niko20 nikolatesl...@yahoo.com wrote:
Well I will say one thing, if it was opened up, that would allow each
dev to make small code changes, so it would never be cookie cutter
then...however, I am not
On Jun 17, 8:05 pm, keyeslabs keyes...@gmail.com wrote:
AAL has now been open-sourced. Find details here: http://bit.ly/coz0yB.
Cool. Thanks for sharing it.
Are you still having good luck using AAL with your own app(s)? Any
downsides you've found?
String
--
You received this message
Biggest issues that I've seen for my own apps (and those other brave
souls who use AAL) have been related to legitimate users that somehow
can't validate their purchase. For example:
1. user buys app on marke using a 2.0-based phone. validation happens
just fine.
2. user backs up app, flashes
for me, I am developing an app that I think will be heavily pirated.
my idea to stop that is to require the user to update with each update
I make (maybe once every 2 weeks or so), which would require them to
buy it.
the app needs to connect to my server anyway, so if it connects with
an older
I think that this is also way. But some users hate updates (I got feedback
that my app has too often updates ;-) ).
I still think that Google should provide API for programmatical verification
whether user bought given copy or not.
Tom
On Fri, May 21, 2010 at 8:14 AM, Ivan Greene
On Fri, May 21, 2010 at 1:14 AM, Ivan Greene ivant...@gmail.com wrote:
I make (maybe once every 2 weeks or so), which would require them to buy
it.
This wouldn't require them to buy it if they pirated it to begin with - it
would just require them to pirate it again.
Might be enough of
Pardon the direct contact.
I was at Google IO these past two days and during one of the sessions,
a Fireside chat (http://code.google.com/events/io/2010/sessions/
fireside-chat-android-team.html), I asked the Android team if the
market API was going to be opened up, on the web side and the device
Excellent points. This is why in my requirements for AAL, I started
with the assumption that PAYING customers should:
- never have to type in a password
- never have to type in a license key
- only have to generate a valid license once (well, actually twice --
initially and then again after the
On Mon, May 10, 2010 at 11:06 AM, dadical keyes...@gmail.com wrote:
The point here
is to get this past the pain threshold where it won't be worth the
trouble for an app that is only a few bucks.
It's not clear that piracy translates into lost sales:
It took several days (almost a week) for crackers
to decompile Screebl Pro and find a way to circumvent AAL. Typically
it takes about 90 secs from the time that we publish to the market for
the various warez sites to start tweeting the location of the
download.
I was wondering, after the first
That argument assumes that I don't respond to those cracks with
improvements to AAL that will make it more difficult! :) Also, each
app will need to be cracked individually, and I'm trying to work out
some ways to make that a job that isn't cookie-cutter. The point here
is to get this past the
Well I will say one thing, if it was opened up, that would allow each
dev to make small code changes, so it would never be cookie cutter
then...however, I am not against that you are trying to make some
income from it, I mean you still did have to do the work.
-niko
On May 10, 10:06 am, dadical
Actually I think another pretty good solution is to simply put a date
lock on the app, sort of how Astro works.
What you do is make the app expire at a certain date. Before that date
you release the next version with another lock moving forward. Maybe
try a 2 or 3 month lock. Then when it does it
That works in most cases but not in a significant number of other
cases.
Consider users who go on an extended holiday to a non-paid app
country. Astro works partly because its free.
But then there is also the situation where you go on holiday and are
using your phone offline. Then all of a
Without introducing any new content - it makes it a very desirable
target for patching. A simple patch will make sure the date check
doesn't matter, and if you aren't introducing any new functionality,
then there isn't a real reason for the user to upgrade.
IMHO your just asking people to get fed
I'm wondering how you know the piracy rate of your app. Is there a
way to track that? I'd love to know if my apps are being pirated or
not.
On May 5, 9:20 am, dadical keyes...@gmail.com wrote:
I've spent the last few weeks developing a new tool to stoppiracyof
my paid apps on the Android
That's easy. Install flurry or the likes, compare reported daily new
installs to what you see reported by Google checkout.
On May 9, 4:28 pm, Stephen Lebed srle...@gmail.com wrote:
I'm wondering how you know the piracy rate of your app. Is there a
way to track that? I'd love to know if my
On Wed, May 5, 2010 at 2:49 PM, Marcut Andrei andreimar...@gmail.comwrote:
Shane,
You must be using your signature for the same? Looks like you are
just trying to cast some vague doubts on SlideLock and SlideME [...]
I prefer to stop here.
I didn't say a word about SlideLock, so your point
On Sun, May 9, 2010 at 5:23 PM, Shane Isbell shane.isb...@gmail.com wrote:
On Wed, May 5, 2010 at 2:49 PM, Marcut Andrei andreimar...@gmail.comwrote:
Shane,
You must be using your signature for the same? Looks like you are
just trying to cast some vague doubts on SlideLock and SlideME
As an aside, why don't google provide their own official API to allow
apps to check with the market whether they've been purchased or not ?
Perhaps it's the 'any security which can be conceivably broken is
useless' line ?
I would be happy with any protection mechanism which forced my apk to
be
I most certainly did NOT use code from that project. I rolled my own,
thank you very much. Take a look at that project. It's over 600k.
AAL is 36k. I wrote my own implementation of ProtoBuf to pull this
off, and that is no small undertaking. I did initially consider using
that project, but
Hello Lee.
Regardless of whether anyone purchases AAL, it has been a worthwhile
investment for us. It took several days (almost a week) for crackers
to decompile Screebl Pro and find a way to circumvent AAL. Typically
it takes about 90 secs from the time that we publish to the market for
the
You've pretty much got the major parts down. We validate with Google
market servers using a hand-rolled and highly-efficient implementation
of Google's binary protobuf protocol. Once the hard part (validation
of purchase) is done, a unique key that is tied to user, phone, and
app is generated,
Shane,
You must be using your signature for the same? Looks like you are
just trying to cast some vague doubts on SlideLock and SlideME [...]
I prefer to stop here.
The feedback from SlideME is valid, and the author welcomes it,
otherwise why would he open such a thread?
Is spreading a word
I like the idea. And the licensing price isn't bad if it meets ones
needs.
I'm looking myself for a solution that will unlock a time limited
version. It's been discussed how some are using a license key app to
unlock a demo app. I suppose this scheme could work if you put the
purchase
Intriguing. I was wondering if maybe you could add a blurb to your
web site explaining in simple terms how it works. E.g. when the API
is called, it communicates with the Android Market to verify your key;
once verified, the verification code is remembered so that no further
calls to the market
How about users who go from using a paid-app-country sim card to a non-
paid-app-country sim card? In such a case, the app is no longer
visible on the Market?
I guess your answer to this would be its up to the developer to decide
how to handle such a license check failure but in reality the user
On May 5, 8:09 pm, dadical keyes...@gmail.com wrote:
Hey Tim.
You're correct that validating purchase with the market is a key piece
of our solution. Figuring out how exactly to do that using Google's
binary market protocol in an efficient way (try doing everything that
AAL does in a 35
I believe that every DRM is something that IMHO Google HAVE to SOLVE. Every
independent solution is just a hack that may stop working anytime Google
wants. Sorry.
Tom
On Thu, May 6, 2010 at 9:22 AM, westmeadboy westmead...@yahoo.co.uk wrote:
How about users who go from using a paid-app-country
It uses this project: http://code.google.com/p/android-market-api/,
you can do same, just note that in proto purchased field is missing,
but you can simply extend App message in market.proto, purchased field
has id 34.
--
Regards,
Bart Janusz (Beepstreet)
On May 6, 8:22 am, Edward Falk
As you could also note - there is nothing in Android-Market-Api's
license against this type of use.
Whether he used their code or not - I'm not sure, but basing it off of
the User Agent is sort of a big leap of conclusions. That user agent
is pretty common on the android devices ;)
It's not as
On May 6, 9:18 pm, strazzere str...@gmail.com wrote:
As you could also note - there is nothing in Android-Market-Api's
license against this type of use.
Yes there is, google APIs services in point 5.3 states that you are
not allowed to use undocumented APIs:
5.3 You agree not to access (or
Yes there is, google APIs services in point 5.3 states that you are
not allowed to use undocumented APIs:
Ah, I'm talking specifically about the google code project android-
market-api.
No, each device uses different UA string when executing market request
(it contains device name and build
I don't think it's overcharge, BUT I think excusing for 'high' cost
with high piracy doesn't sound fair. It sounds like piracy would help
the sales of your product.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send
On Thu, May 6, 2010 at 4:12 PM, appforce.org ogi.andr...@gmail.com wrote:
It sounds like piracy would help the sales of your product.
Care to elaborate on this golden nugget?
-
TreKing - Chicago
I imagine he means: Without any piracy, dadical wouldn't have anyone to sell
his anti-piracy solution to. With more rampant piracy, he'll have a larger
potential customer base
- Dan
On Thu, May 6, 2010 at 5:26 PM, TreKing treking...@gmail.com wrote:
On Thu, May 6, 2010 at 4:12 PM,
On Thu, May 6, 2010 at 4:29 PM, Dan Sherman impact...@gmail.com wrote:
I imagine he means: Without any piracy, dadical wouldn't have anyone to
sell his anti-piracy solution to. With more rampant piracy, he'll have a
larger potential customer base
Ah, that makes much more sense than
I suggest that before anyone implements this licensing scheme, they
consider carefully that it does in fact break the terms agreement in
that it uses an unpublished and private API to access the Android
market servers.
With that said, I would also say that it's highly likely that Google
will make
Non-Android Market solutions would be more interesting to me.
I'd like some way to stick an apk on my website and allow users to pay
using paypal. Everything else would work seamlessly...
On May 4, 11:20 pm, dadical keyes...@gmail.com wrote:
I've spent the last few weeks developing a new tool
That's a cool use case, but I'm curious about how commonly people sell
apps that way. Are you doing this because of the limitations of where
Android offers paid apps? Is it because of the costs involved in
doing transactions on Android Market?
I think that the value offered by Android Market
My apps haven't reached piracy rates that high (yet). But i'll keep an
eye on your solution :-)
Keep us updated.
On May 4, 5:20 pm, dadical keyes...@gmail.com wrote:
I've spent the last few weeks developing a new tool to stop piracy of
my paid apps on the Android Market. In a nutshell,
Looking at your documentation, I'm assuming your making a call to the
market requesting the state of the application -- if I'm wrong, then
just disregard this information. If I'm right, I guess my only
question is why are you charging so much information for such a
simplistic method?
Don't get me
Hey Tim.
You're correct that validating purchase with the market is a key piece
of our solution. Figuring out how exactly to do that using Google's
binary market protocol in an efficient way (try doing everything that
AAL does in a 35 KB library) was a fairly significant dev effort.
What's more,
Dave,
Glad to hear it's paying for itself already! It's definitely a cleaver
use for the market api - wish I'd thought of it myself. This should
definitely slow down pirates - as it would require direct patching of
the apk file as an intervention.
Using the market api should also alleviate any
On May 5, 4:21 pm, dadical keyes...@gmail.com wrote:
That's a cool use case, but I'm curious about how commonly people sell
apps that way. Are you doing this because of the limitations of where
Android offers paid apps? Is it because of the costs involved in
doing transactions on Android
I'm not sure how many developers will like your licensing terms,
especially the bit which prevents them from creating any form of
licensing solution of their own if they download your app. It's also
worth noting that you're statement preventing reverse-engineer doesn't
hold water in many
Thanks for the feedback Al.
My intent wasn't to forbid anyone from creating their own licensing
options after downloading AAL, just that they can't reverse engineer
it, copy it, change the name, etc. I'll look into improving the
wording...
Dave
On May 5, 2:32 pm, Al Sutton
Dear dadical,
*
*I salute your initiative and congratulate your efforts in the anti-piracy
conflict. Digital Rights Management was never an easy adventure. Nowadays,
everything can be broken by using different methods. Some fall easier, some
do harder. However, I do not intend to highlight this in
Hey George.
I have looked at SlideMe and SlideLock. It's great but doesn't fit my
use cases for my apps, nor, I would suspect many others looking for
simple licensing solutions that mesh well with Android Market.
Permissions are a pain, aren't they? It is what it is, and devs will
have to
On Wed, May 5, 2010 at 1:35 PM, dadical keyes...@gmail.com wrote:
Hey George.
I have looked at SlideMe and SlideLock. It's great but doesn't fit my
use cases for my apps, nor, I would suspect many others looking for
simple licensing solutions that mesh well with Android Market.
52 matches
Mail list logo
