My application will have a low cost for a basic version.
If the user need more features, heneed to buy plug-in.
Question is:
What is the best solution for this approach?
Better the use of in-app billing or publish packet that contain the plug-in as normal apps with a price ?
Thank you
In-app billing is the recommended means for providing extra features. There's very little to worry about with it, as it's all taken care of through google play functionality. Otherwise you're requiring your users to download a whole new apk file as a paid for thing.
This page on the Android Developer site gives a good set of instructions on how to achieve this.
Related
I would like to implement a license system in my Android application, have you any idea about this system?
I think a file crypted contains informations about licence?
Thank you.
I think, you should have a look at the Google Play Billing feature, which can give you the possibility to charge user for one time purchase, monthly subscription or yearly subscription. You can see exemplary usages in the official Google/Android repository here: https://github.com/android/play-billing-samples. As far as I know, this is the most common practice to unlock app features or charge users for the "full version" of your app and it's integrated with the Android OS.
I don't want use GooglePlay services, i share the apk by my personnal link.
I know Apple has this API I can hit:
http://itunes.apple.com/lookup?bundleId={id}
However, for the PlayStore, I'm looking for something similar, rather than parsing the app page
https://play.google.com/store/apps/details?id={id}
and then looking for the <div> that contains itemprop="softwareVersion"
There are a few questions about this here on SO and elsewhere on the web, but they are outdated, and make reference to unofficial APIs.
There is no Official API for grabbing the App version from the Play store.
I'd be curious exactly what you would use such an API for, if you wanted to add it in a comment. There may be a better way of achieving what you want.
Edit:
For forcing an update to your app there are other recommendations. We normally recommend that you don't have "always update to the latest version in the Play store" to developers. For example, the user might want to use your app, but be in a place where they don't have much battery or wifi. Forcing them to update in such a situation is rude, it's much better to give them a week or two until a more convenient time.
If you want to do "never have a version that is more than a couple of weeks old", can I recommend Firebase Remote Config. This would let you on the server update a configuration options for your app saying "the user should have at least this version" and change the behaviour of your app accordingly. It is much more flexible at robust than polling the Play store.
Another approach can be the Support In-app updates besides Firebase Remote config.
Google has released the Support In-app updates feature in which the apps can nudge the users to update their apps without even going to the play store. If an update is available, the users will see a dialog or a full blocking screen where the UI is generated and controlled by google play.
In-app updates works only with devices running Android 5.0 (API level 21) or higher, and requires you to use Play Core library 1.5.0 or higher. After meeting these requirements, your app can support the following UX for in-app updates!
references are here and this helpful blog. Check this out, hope it will help.
I have a app created in xamarin forms, I already know how to create the APK, the app is to be used internally, i dont want to publish to the appstore, how can the app be update when is available a new version ?
Depending on your resources at hand and requirements, you have a couple of options. These options include, but are certainly not limited to:
Visual Studio Mobile Center (link): probably the most obvious choice. Out of the box support for Xamarin, and 'just works'. You can set up different groups of users, add analytics and crash reporting, etc. In the future you might be able to take your configuration to its big brother: VSTS. But beware! The product is in preview right now. Preview in Microsoft-land means free for now, but doesn't have to be in the future. While I expect it not to cost much/anything for basic functionality, it is something to be aware of. Not sure on this, but I think you need to invite your users by hand, so you have to know who you want to invite.
Google Play Store (link): It's kind of a mis-use, but you could of course leverage the Google Play Stores capabilites for Alpha/Beta testing. Also here you have the ability to create groups and have some basic reporting options. In terms of delivering your app you have some nice options here like A/B testing and unlike Mobile Center (again, I didn't verify this) you can setup a link with which people can enroll themselves. Depending on your needs, this might be nice. In terms of costs, this will set you back 25 dollars once. And you could develop and distribute other apps if you'd like.
Manual: send the APK file manually or hosting it on a shared location. I would prefer this least of all. People are not notified of any updates and you don't have any insights apart from something you might have incorporated in your app. Also you don't have any control over who installs or sees the app, etc.
But of course the prefered way would be to do it through the Google Play enterprise program. See this website. This provides you and your end-users with a private app store basically. Or as they say:
A managed version of Google Play is used by enterprises and their employees to access a rich ecosystem of work and productivity apps.
You can have private apps, only available for your targeted audience and still leverage the power of the Google Play store. The experience for your end-users will be unified with the regular app store.
I couldn't find a straight answer, but it seems the private apps will also cost just 25 dollars once and is included in the regular Play Store developer license.
You have a good way to do that : Use Beta this a service provided by Fabric, you can upload your app with different versions and get access to different teams in your company. It's easy to use and quick to manage.
Hope it helps.
You have multiple options at your hand:
use Bitrise or Visual Studio Mobile Center (aka HockeyApp) to build and provide a downloadable version of you app
in addiont to Bitrise or VS Mobile Center you can set up your own store. Take a look at Relution for example
build locally on your machine and push it to:
a fileshare
an FTP-site
the user by mail.
Is it possible to list in Google's Android Market a single APK for both free and paid versions?
So far, I only found this tip to create a button in the free version that links to the paid versions, but IIUC these are still 2 separate APKs.
I also found a reference to creating free/paid versions from same code, but that still refers to 2 separate APKs.
What I am interested in is an (Google) Android Market way to provide functionality that is similar to PayPal's MPL (i.e. one app does it all). Is this possible?
EDIT: Based on the answer below, it seems that Google's In-App Billing facilitates this.
However, LVL's Requirements and limitations says:
Licensing is currently for paid apps
only, since free apps are considered
licensed for all users. If your
application is already published as
free, you won't be able to upload a
new version that uses licensing.
I know that LVL is not the same as In-App Billing but LVL is definitely required for In-App Billing to work (if only for using the key). So how does this reconcile?
It's possible to use something known as in app products. The min API is 1.6, which should work plenty well. Basically, anyone could download the code, but some unlocking of features could be done if desired to buy new functionality. They also have sample code which shows how it works.
Alternatively, you could use the licensing API, and simply check to see if your app is licensed. This would require a different package name, however, as all apps do.
You can rename the package before compile and release it as two apps.
i.e. com.example.yourproject and com.example.yourprojectpaid
You need to use the Key for both he LVL and the in app billing and its a good amount of effort to set up. If you want the easy way out use the example above, but know your paid app is not really protected from piracy if you don't use the LVL for your paid app or in app purchases if you keep the app free.
Good Luck.
Edit: Android now supports in-app billing!
Original question:
It looks like Android won't natively support in-app purchases for a while, and when it does there might be a huge user base with devices that don't support them.
What's the best way to implement iPhone-like (additional content or services) in-app purchases in Android using the Android Market if possible?
The solution should consider in particular:
For all kinds of in-app purchases: Android Market's 24-hour cancellation policy
For consumables/non-consumables: storage of additional content (ie: use precious application memory to avoid piracy, or use SD card to avoid bloating application memory)
Thanks!
This has changed as of today! There is now an example on the Android Developer site here: https://developer.android.com/google/play/billing/billing_overview
You can create a premium key application, that will have a key. How you expose that it's your deal ( or you can just check if PremiumKey activity exist ). From the main app you just check for your key and if it's exist enable premium option )
If you're talking about buying OTHER apps from yours - build your list with market url pointed to the other apps ( market:// )
It is against the Android Market Developer Distribution Agreement to take in-app payment:
3.3 ... All fees received by Developers for Products distributed via the Market must be processed by the Market’s Payment Processor.
Looks like Paypal has launched a library for accepting in-app payments. See here. Not sure if this system violates the T&C though.
You say that Android Market doesn't support in-app purchases, and then ask how you can implement in-app purchases using Android Market?(!)
Anyway, if and when they do support it, I imagine it could be distributed as an update to the Android Market application itself, so most users would be able to use the functionality. I believe the Market app updates itself automatically.
Possibly the Market would accept an Intent to trigger a payment via the usual on-device mechanism and return your app (or more likely your server) a callback.
There is also another in-app payment platform for Android applications called MoVend (www.movend.com). I have checked it out and there are several benefits using it compared to the other 2 mentioned earlier:
Many payment channels : Operator Billing for more than 38 countries, PayPal and virtual credits.
Many distribution channels: They work with developers to distribute their applications through the various distribution channels like Operator AppStores , OEMs and Android applications website. Marketing is something we all need. They are also invested by Singapore Telecommunications who has a strong presence in South East Asia.
They provide a sales analytics for you to track, trace and monitor the performance of your apps. Since they are available worldwide, you can always tailor your applications to the different geography area.
I am trying to build Android applications and monetizing is important.
Reply this thread so we can discuss how we can monetize our Android applications.
Here's another free licensing and payments system. The nice thing about this one is that it allows you to offer your app in any app store.
You can find more details # http://www.cloud4apps.com/
Check out http://mobpaynet.com, they are doing something like this. Not sure if it violates terms or not, but I will probably check it out.
For implementing in-app purchases in Air applications you may use third-party libs (Adobe AIR does not support In App Purchases for any platforms out of the box). For example, developed by Milkman Games (unfortunately, they are not free)