Can someone create an application A for Android devices that contains functionality to unlock applications B and C in the marketplace?
Keep in mind that applications B and C should be purchasable by alternative means (aka actually buying them in them market place) but ALSO available in the secondary method inside application A.
This would create a system where users could unlock content via spending time in the application A (perhaps working towards some form of currency) that they could spend on real applications. Application A would also serve to advertise those applications B and C possibly getting players to choose to buy them rather than earn them, or get friends of players to buy said games.
It would not be possible. And if it were through some back door method, I doubt the downloads would show, so it wouldn't likely help the apps rating.
If you were a skilled hacker, you might be able to figure it out, but of course that would not be recommended.
I guess a more indirect way of doing it, although not nearly as
enticing, would be to distribute apps B and C for free, but require a
registration code that is unlockable via an inapp purchase, or via in
app purchase from app A ???
That would be a good way to do it, but you would need a good way to manage the code, so the user won't easily loose it. For example, back up data on google servers: http://developer.android.com/guide/topics/data/backup.html
And/or send the user an email that has their activation code, I guess.
Also, you could distribute a paid app that would just act as a key for apps B and C on the market and then the key could be purchased instead of using the in-app purchase.: http://developer.android.com/guide/publishing/licensing.html
Or, you could make apps B and C both have paid versions that are the full app and free versions that are the lite version, and then use in-app purchases or your code idea to upgrade from the lite version to the pro version.
Related
I have a paid app in the Google Play Store. I'm considering reducing the price of that app (somewhat; not all the way to free) and offering one of the features as a separate in-app purchase.
If I did that, I wouldn't want to yank the feature away from anybody who's already bought it.
Is there any way to figure out either the date that the user bought my app, or the original version of the app that they bought, or something like that? I'd like to say something like, "If the app was before the price change (either by date or by version), they should have the feature for free; otherwise, require IAP to unlock the feature."
For example, iOS does have a feature like this; the app receipt includes an "originalVersion" field which can be used to control access to features.
Unfortunately for your customers, this is impossible. There is no API call or anything else to Google Play where you can get the time on which the app was bought.
I know there is an android-publisher API in existance, however it doesn't offer any feature to check that.
The functions you want to use are not public availible and only used by the Playstore internally!
Workarounds which you could do:
1. Get the time the app was installed
On the first start you could check that and unlock the features.
Warning: This system could be abused by changing the time on the device
long installed = context
.getPackageManager()
.getPackageInfo(context.getPackageName(), 0)
.firstInstallTime;
2. Give users free keys
You could give every user who's using the app atm a free key via mail or push notification
3. Unlock the inapp purchase now
Publish an app update which unlocks the inapp purchase for free. After a few weeks you could pusblish your new version with the lower price and just unlock the features as if your current customers had bought your extension.
You might be able to hack your way around this if you're using some sort of persistent storage.
For SharedPreferences, on the first run, do a check for one of your preferences using SharedPreferences.contains(). If it contains it, the app must have already been installed. If not, set another preference that marks the user as new, and set yet one more so it doesn't do the check every time.
That might only work if the preference doesn't have a "default" value, I'm not entirely sure if setting a default in xml will mark it as contained.
You could do something similar if you have any assets that get transferred to SD, or any similar one-time setup. Just check to see if it's already done before doing it the first time.
If you're using an SQLite DB, you could increment the DB version and mark as "paid" in onUpgrade() if coming from the current version(or earlier).
There are some pitfalls here, though. For instance, if a previous paid customer completely uninstalls before installing the new version, or if it's on a new device. For that reason you should:
4. Provide Support
In the about or FAQ section of your app and on first run of your new version set a support mail adress which customers can use if they have any problems because the new features were not unlocked for them.
They could provide any proof (bill) for their purchase.
Like I said, those ideas are workarounds, but I don't know of any "official" way to check to see an app install is an upgrade or an initial install.
Your best option may be a combination of those four.
FYI: I've opened a feature request/idea in Google Cloud Connect for work which you could vote: https://connect.googleforwork.com/ideas/9392 (You can only vote if you have a paid Google Buisiness Account)
I hope this helps you at least a bit.
As far as i know, the best you can do is find the date it was installed. http://developer.android.com/reference/android/content/pm/PackageInfo.html#firstInstallTime
I have a "Base", "Normal" and a "Deluxe" App. "Base" is free, "Normal" costs 1$ and "Deluxe" costs 2$.
The "Base" app holds the entire logic for all content and shows the trial content at the same time. The "Normal" and "Deluxe" are only unlocker apps without any logic.
The "Base" app simple checks if the "normal" or "deluxe" apps are installed as well and shows the corresponding content. ( This is no security question, I am doing this with certs compare ... )
I am looking for a way to allow the Users, who already payed the "Normal" App to only pay another 1$ to unlock the Deluxe content.
What I evaluated so far, which I don't like :
I don't like to use inapp payment for several reasons, which I do not want to discuss here please :-)
I could create a "upgrade2Deluxe" and in the "Base"-App I could check if "Normal" and "upgrade2Deluxe" is installed and show the Deluxe Content. But I also don't like that, because the User will see 3 Apps on his device.
Do anyone have a idea howto do this in another way ?
I'm faced with a similar choice, and I'm still exploring a number of ideas:
although I also don't want to have in-app purchases in my Base app (which currently needs no permissions at all), I'm thinking that having in-app purchases in the Normal app will be acceptable, so the user installs the Base app (which holds all the Base + Normal code), and the first upgrade is to install the Normal app, then future upgrades are achieved by running the very limited upgrade code from the Normal app.
I intend that the user does not see multiple apps on their device - the Normal app will not declare any launcher intent, so will be hidden from the user
I'm looking to have the Base app change it's declared launcher activity so that the icon changes from Base to Normal (or beyond)
By keeping in-app billing out of the Base app, I keep the ability of that app to work on Kindle Fire and other devices outside the Google Play ecosystem.
Refund users $1 if they buy both normal and deluxe.
You cannot manipulate prices on a per-user basis. There also isn't anything stopping users from buying both normal and deluxe versions from the play store.
If your problem with IAP is having a server side component, you could use something like http://doc.applicasa.com/docs/content/android/#monetization to help.
You can make two versions of the app - Free(Base) & Premium(Deluxe).
Although I understand you do not want to implement IAP, however you could provide them some of the additional features(after the trial) via the In-app purchases that would transform your app to the Normal version as it seems the only viable option.
Now for the Deluxe app you have to make another app with all the features you want to provide & provide the link in your app for the user to download. After the download of the Deluxe app the user can delete the Free app!
This is the norm that developers follow for trial & full version apps ( Example: The Dictionary.com app in iOS)
my music theory app is free and has no ads. I made this for a school project, the goal is to make some money. My idea is that some functions are only available if you have purchased the "unlocker" version of my app.
Can I tell my app to check for the "unlocker" at first launch? I don't want the "unlocker" app to act as the real app, just a "file" that unlocks the free version.
If the user has purchased the "unlocker" I want it to activate some locked buttons.
I would prefer it to work like for example Solid Explorer.
Solide Explorer (Trial) - Google Play
Solide Explorer Unlocker - Google Play
You can use PackageManager.getPackageInfo() and request PakageInfo for your unlocker app. The app must be there. Second step would be to validate your app's signature. To make it even more difficult to hack, your main app can send some intents to unlock app, and then receive and check responses for correctness.
Although this will technically work, it is not as safe as In App Billing, which is advised way to go. Moreover in your case users will have to install two apps, which is not as convenient.
I would like to make my application free to install and upgrade for some users only (for example translators, developers and friends, to which else I would have to send the package at every release).
I thought the new licensing would allow that, but it seems not. Since I can't find the answer to whether it is even possible, I am asking right away:
Is it possible to put a paid application on the market and have it either freely istallable or paid, let's say based on the user id (account)?
The easiest thing to do would be to just send them an apk that they can install. They won't get auto updates, but should be able to use it.
I think I saw somewhere in the documentation for in-app billing that it is possible to have "unmanaged" purchases, where it is up to you to manage which user purchased what, either on the device or on a separate server. Maybe it's possible to implement your own purchase server to run in the "Google cloud" using AppEngine?
Anyway, in-app billing is, AFAIK, not available yet, and it seems a tad complicated just to let your friends try your application for free. I've been considering an alternative approach to implementing a try-before you buy scheme:
a) Implement a free App with basic functionality
b) Implement a paid but otherwise empty "unlock" App
c) When users activate "paid" functionality, use the PackageManager to look for the "unlock" app. If it is installed then activate the requested feature, otherwise show a dialog asking the user to go to the market and buy the unlock app.
If you did something similar, you could tell your friends and your testers to download and/or upgrade the unlocked version, and just send them the .apk for the "unlock" app. Furthermore, you would only need to send them the unlock app once.
I think I've seen such "unlock" apps on the market, but I haven't actually tried the approach myself (yet), so I can't guarantee that it will work. Can't see why it shouldn't, though.
For this, if it's possible, you need to have a database for the userId (if you want to manage that)
Or if you want a freely application.. it will need to be a Freeware (a beta version) from the complete application
Else, i don't think it's possible
There are a few apps on the market that are set up to have a free main component(which is a trial limited to 7 days lets say) then "recharge" apps that will add a certain amount of subscription time to an account for the user that allows them to keep using the main app. These "recharge" apps are available in the market as well. What I would like to know is how to make it so that once the user has paid for one of these "recharge" apps and used it to add time to their subscription, they are unable to uninstall it and re-download it(for free since they paid for it once). Basically how do I set my application up so that you only get 1 successful download of the app from the market per payment. Once the time has been added to the users account I would like the market to behave as though the "recharge" app has never been purchased.
What I would like to know is how to
make it so that once the user has paid
for one of these "recharge" apps and
used it to add time to their
subscription, they are unable to
uninstall it and re-download it(for
free since they paid for it once).
You cannot prevent them from uninstalling and re-downloading it. At most, you might work out your own mechanism to prevent the app from applying a new "recharge".
Once the time has been added to the
users account I would like the market
to behave as though the "recharge" app
has never been purchased.
This is not possible. In fact, it works in the reverse -- the user will forevermore be able to download it, on as many devices as they want, so long as they are using the same Google account for each device. Purchases of apps are for the lifetime of the Android Market, not for a developer-selected lifetime.
Check out the new in app billing functionality, you may be able to leverage some of it's functionality to sell additional functionality/subscription time.
Setup a server and once the user downloads the app, on the first start the app shall connect to your webserver and send the IMEI oder device serial number to the server and the server will send a code which enables all the features.
Since the date of the first activation is stored on your database on your server, the user won't be able to change it until he puts in a new SIM Card (hence changing his IMEI number) even if he redownloads the application several time, the IMEI basically never change unless you change the SIM.