How to implement trialware model on Android? - android

Any tips on how to implement a trialware model for Android apps? I plan to release my app as a free app that expires after 30 days unless the user buys the license via an in-app purchase.
I can use the Android Market API to tell if they bought the license, so my main question is how to prevent the user from un-installing and re-installing my app every 30 days? Can I save something to their phone in a permanent and reliable way that will remain on the phone even if they uninstall? I know nothing will stop a determined hacker, I just want to stop the average user.
I am also open to different approaches to going trialware on Android.
Thanks in advance,
Barry

Have you read the documentation on Application Licensing? Specifically, have a look at Implementing a Policy
I also have found this resource very helpful in determining the best way to get a unique ID for any one device. Android - Identifying App Installations -- They discuss pros/cons to the different approaches -- Straight from the developer's mouths!

I would avoid leaving unwanted remains of the application on their phone.
Instead, you can take some unique identifier of the device, and send it to your server, if this ID was not registered before, send it activation code, if it was, don't send it.
Store this activation code in some shared preferences etc. and when the application starts, check if the activation code is there and if it is valid.

They don't even have to uninstall, just clean app data. You can save something to an obscure location on the SD card, but that's also fairly easy to circumvent, even easier if they read this forum :) Your best bet is to have the app call home to your server and check if licensed periodically. That of course comes with it's own problems: do you allow it to run if network connection is never available, etc.

Related

How to detect a user after reinstalling the app

I am creating an iOS and Android App and I want to create a screen where the player can start with a guest account or can connect his account with our own accountsystem.
But my question is: Can I detect a user after the app was uninstalled and installed again?
I know that there is something like the vendor. But this will change.
I know that other apps also can do this.
With the user's permission- have them log into an account. Or provide you with their google of facebook account info. So far as hardware ids, those are discouraged and actively being removed to prevent people from the API to prevent this.
Also remember- that unless the user logs in with an account, you don't really know whether it is the same person. You could know its the same phone, but you don't know if he gave it to his kid sister to play on. Or sold it when he got a new one, and now you've given the new owner access to someone else's account. Also, if you rely on hardware ids you won't know its me when I buy a new phone and download it on that.
So yeah- either have him log in with a username and password, or use a 3rd party signon mechanism like Google or Facebook.
For iOS, there is a recommended approach to do that: by using the DeviceCheck framework. The idea here is that it allows you to persist 2 bits of data across app installations on each device. You can set the first bit to 1 if the user has already installed the app or 0 otherwise. And use the second bit, for example, to check if the user has signed in or not.
The official documentation is pretty good, please check it out.
The downside of this approach is that you will also have to do some work on the backend side.
UPDATE:
If you specifically want to detect the account, there is no reliable approach. One of the options is to use identifierForVendor or generate some kind of device fingerprint (for example, by combining the device model, timezone, locale, etc.), but of course, this will not work every time.
Uniquely identifying a device is a security leak, and all platforms are putting serious restrictions on unique persistent identifiers because of privacy concerns.

Automatically sending sms from Android and IOS

As I understood, it is possible but such applications are not allowed in the official stores.
The app should get permissions in advance, from the user, and then, at random times, send an SMS to a random user from the phone contact-list, without further user interaction.
My questions are:
1) Is it possible at all?
2) If so, is it something that the official stores will approve?
1) In Android this is possible. If I recall correctly, there is no API for sending sms in iOS, without going through the stock sms application.
2) It's sketchy... Apple would probably not approve this kind of application, if it's even possible to make in iOS. Its never a good idea doing things behind the users back.
Apple will definitely NOT approve this kind of app!
I have tried this for over 2 years now, even contacted Apple - there is no approval for this!
There has been an App in iTunes at sometime (how that could have passed the review process - nobody knows) This has been removed as soon as Apple got to know about this.
Besides the approval issue, there is no OFFICIAL way to even accomplish this.
While there are/were some direct calls to private libraries, using these would immediately be identified (even automatically nowadays).
Just stick with Apple's rules if your App allows - give the user some background information, why they need to explicitly press "send" again - otherwise you might get some bad reviews, since this fact is certainly not known among all iPhone users.
In Android this is just a normal usage of SmsManager.getDefault();

How to identify an app user so he cannot pretend to be someone else

I'm developing an Android app which should be free to use for a certain period. When the phase of free use ends the user should register and pay to be able to use the app furthermore.
No I wondering how I could archive this, as the user might simply re-install the app to extend the period of free use. So I need a way to identify the user in such a way that he cannot pretend to be someone else or a new user. At the same time I want to avoid that the user has to do any registration if possible before the free use period ends.
At the moment I think about identify the user by his telephone number or SIM card id as he probably won't buy a new SIM card only to be able the use the app for free. The disadvantage of this is that this is limited to devices which are phones so any WIFI tablet won't be able to use the app as it doesn't have a SIM card.
Are there any other options to archive this behavior?
What you want to do is to track installations. This can be done by getting a unique id and then saving it using shared preferences. You could put this into a folder on the SD-card but I don't think I'm the only one getting annoyed by this kind of behaviour in apps. Rather than putting a file on the SD-card want to backup the file using BackupManger and uploading it to the cloud.
You can find info about the BackupManager here:
Data backup
and a short part of this video on tracking installations here, 16:30 min in:
Google I/O 2011: Pro tips
I really recommend you (all) to watch the video as it goes through many rookie and pro misstakes.
When reading about the BackupManager you'll find out that, just as all the other solutions, it wont work on all devices. I don't think this will be a big concern of yours, it will be a small group of people who can work around your trial period ending but there will always be. Spend time on developing your app and making it better instead.
You might want to read this post from the Android Developers blog.
They recommend the ANDROID-ID, though it has it's downsides.
You might want to try:
import android.provider.Settings.System;
..
String android_id = System.getString(this.getContentResolver(), System.ANDROID_ID);
Although some devices apparently return the same value for this, which I think is contradictory to what the API docs say. It's possibly useful to use this as a secondary check.
However do try to take caution in sending personal details such as IMEI or phone number etc back to your server as users rightfully get a little anxious about such things being broadcast. You could always do a hash of the IMEI (if accessible, can't remember off the top of my head) and add this to the ANDROID_ID, creating something that's going to more or less be unique. Maybe hash some other detail in addition to this to really guarantee uniqueness as hashes can and will clash.
Is there a unique Android device ID?
Most voted answer (Joe's) in above is the best approach I have found so far.

Android free app limit usage lock out

I want to release a trial version of my Android App that can only run for a fixed number of days before it disables itself. What techniques could be used that would provide reasonable protection and achieve this?
I am hoping to avoid the need for a licensing server. But if I do need one does anyone know of any open source license servers that they would recommend. If not open source then any that are reasonably priced?
Thank you for your kind response
Android makes it pretty hard to reliably resist pirating. You basically can't trust the device, pretty much need to have a call on startup to your server with the unique ID that authorizes or rejects the user. If most of the functionality relies on some server of yours, then you can make the app much more resistant to pirating by requiring a valid device ID on startup to get some sort of auth token, which your other RPCs can then use to authenticate the app.
I have a suggestion, although I do not know how effective it will be against someone who is very determined to get your app for free.
You could have a check that happens on startup of your app. If it is the first time the user has opened the app, then you take note of the time, and save it into a private preference of the app. If it is not the first time the user has opened the app, check to see if it is still within the valid data/time range from the initial time you saved to preferences. If valid, continue as normal, if not, display some message asking them to download the full version.
Again, I am not suggesting this is the best idea, or that it is even completely secure (as I do not know if anyone or any app could have access to those preferences). But I do think that it would be a cheap solution and easy to implement.
I had answered this question previously might be helpful Android: saving info for trial application

How can you make a review copy of an Android app?

I've been asked for some review copies of an Android app I've written, which is great, but I'm not willing to give out the full app to just anyone. I want to make a time-limited version (which works for about two weeks, then gives up the ghost).
What is the easiest way to do this? I haven't tested this myself, but I think that in theory if one built the app using a keystore which expires in two weeks might work. Is that correct, or do I have to put a line of code in the app which shuts it down if you attempt to boot it after a set date?
The keystore is not checked after the application is installed; only at installation time is the date verified.
You would have to put in your own time limit code, I imagine. Though if you want to be really paranoid, you could consider that the user could alter their device's clock.
Alternatively, you could do an online check (against time on your server), or make each APK that you hand out have an individual token embedded which gets validated against your server.
I have a simplest suggestion, what if the reviewer buys the application, and you refund the payment?
I just thought of a cool way to do this.
You make a Beta version of your app, and you can define the group of testers, you just need the email address of that person, or a G+ community they can request access to, and then you add them to the Beta program.
easiest way is to hardcode an end date and no longer run after that. it can be circumvented if users change their system time, but that is kind of a hassle to go through.
otherwise, you can have your app check the license periodically by connecting to your server over http, but that requires more work.
This sounds like a great idea. You'd probably want to make the app phone home and verify with a server that a certain amount of time has elapsed. Users can always delete your preferences file on the phone or uninstall and reinstall the app to get around on-phone restrictions.
I believe the keystore approach may also work, but I'm not sure exactly how they work in Android.
Please make this an open source project when you finish - I think this would be useful to a lot of people!
You could use TelephonyManager.getDeviceId() and create a build of your application that would only ever run on the reviewer's phone.
You could either hard code this into the application or have the phone check against your server where you'd store permissions for each Device ID. With the latter case you could have your application display the Device ID when it can't find a license; the reviewer tells you this and then you enter this in your DB.
As per Google: "If you plan to publish your application(s) on Android Market, the key you use to sign the application(s) must have a validity period ending after 22 October 2033. The Market server enforces this requirement to ensure that users can seamlessly upgrade Market applications when new versions are available"
What we did with our developer challenge II entry was when we hit the expiration date any new data we processed was replaced by an expiration warning. So the application functioned with existing data but not with any new data the user entered after the expiration. Since our app processed text messages, setting back the clock was an unrealistic long-term solution for the user to overcome the expiration.
Depending on the type of application your are giving to reviewers, you may have another options.
You code it like a lot of shareware and only let the application run so many times. The code for this would be very easy to implement. Sure the reviewer could delete the data, but not very easily. I don't think they would go through that much trouble for maybe a couple dollars.

Categories

Resources