-- My 2 cents on hardening the process:
Blocking piracy by binding the license (email) to a single device
(serial no) seems indeed a good way to me.
Also:
- blocking "pay once, run everywhere": your server has to check license
+serial is actually used only by a *single* user (throttling/daily
limits).
SerialNo may be crafted and cannot be trusted. I.e, the app may be
used by many users that run a cracked version that always sends a
valid {license, serialNo} pair. (or use N valid pairs).
- a critical part of the app should be running on the server, so the
protection is enforced by non crackable code. This isn't easy nor
convenient, though.
Any additional ideas?
On 21 sep, 08:43, JonFHancock <[email protected]> wrote:
> I am currently storing the user's email and their license code, in
> preferences, and sending those plus an AES encrypted hash of some
> select strings + their deviceid back to the server. The first time
> they log in, their deviceid is recorded in the db. Subsequently, if
> they try to authenticate with the same email and license code, their
> deviceid must match. They can have their deviceid reset upon request,
> so they can use a new device, but they must invalidate their old
> device first.
>
> It may not be an ideal solution, but it is the best I could come up
> with for now. Everything is sent over ssl, so prying eyes aren't
> watching users email in plaintext, but I might start sending a hash of
> the email and license instead in the next update.
>
> I'm also delivering updates inside the app. While the app is checking
> the license, it is also checking the current version against the
> server's version. If it gets an update notification, the user is
> prompted to download the newest version, which is done in an asynctask
> again over ssl, and calls the following code after completion to go
> straight to the installer. I just realized that I need to be checking
> the md5 sum of the download before installing...
>
> Intent intent = new Intent();
> Uri uri = Uri.fromFile(file);
>
> intent.setAction(android.content.Intent.ACTION_VIEW);
>
> intent.setDataAndType(Uri.parse(uri.toString()),
> "application/vnd.android.package-archive");
> startActivity(intent);
> dialog.dismiss();
>
> I've had beta testers ask me to implement this in the market version
> too. In conjunction with preferences, it could be a nice way to do
> stable, beta and dev channels like Chrome.
>
> On Sep 20, 5:33 pm, GJTorikian <[email protected]> wrote:
>
> > The title more or less says it all.
>
> > Google Checkout, as you may be acutely aware, only supports ~9
> > countries. Some apps use PayPal to receive payment, then send out an
> > "activation code" to the user. How can this be done to ensure that a
> > single user receives a single activation code? Once the app verifies
> > the code, how could the app more or less "verify itself" that it's
> > been paid for? Storing such data in a preference file or a database on
> > the Android device can surely be easily extracted and exploited.
>
> > How are other developers handling app sales in other countries--or do
> > they just not care?
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
