I know this topic has been discussed many times here.
It's the first time i'm uploading an app to Google Play. The app is free. I read google's licensing support webpages but i'm really confused. From my understanding, licensing should be used for paid application in order to prevent copying the app from one device to another.
My app will be free. Do i need to implement licensing? I guess it will only help me to prevent app copying from one device to anoter ( which probably won't be the case beceuase it's free) but still, i may track the right number of downloads if i use it. Would this help me in a different way?
I read that when you upload the app there should be some checkbox to "Copy protect" your app. Is it still there and usable?
In the future i'm planning to add some paid modules to the app. Is it possbile to add licensing in an upcoming release version?
Many thanks,
Dan
Do i need to implement licensing?
No. Your app will work just fine without it. It's only there to prevent pirating your app and since it's free, that's not going to be a major problem.
Is "Copy protect" still there and usable?
As of 2012-12-13: Yes, it's a simple switch in the old layout.
Is it possbile to add licensing in an upcoming release version?
Yes, but bear in mind that itmeans users will see a new "right" that is required by your app and many users do not like that. So if you're planning on implementing it, I'd put the uses-permission in the Manifest now.
However, if you are using in-app payments, you might not need to implement app licensing at all, since the paid content will be verified by googles in-app system, which uses other APIs.
Oh, and make sure you properly obfuscate your code before your first release.
Related
So, is there a realiable way to update enterprise/intern apps remotelly?
I work in a company that spreads across my state, including some areas that the access is dificult, so I can't send someone to locally update the app everytime there's a new release.
I'm working with Android/Java at the moment, and we also use Azure DevOps to store the repositories.
I tryied App Center from Microsoft but didn't understood if that could help me update my app or not.
Also, we don't want to publish the application to the PlayStore and make it public. Unless, of course, if that's the only way.
Thank you for your time reading this, I will keep searching something related to this and also share here any solution that I can find.
There's different ways to do so I'll say some but there's definitely more.
You can use Push-link, read about it it does more or less what you are looking for.
Perhaps could work uploading the .apk to Google Play and just publish it for beta testers, here's an old Google Play Private App Guide pdf and perhaps it doesn't work anymore but give it a try.
Also what you tried with App Center perhaps what you are looking for is Distribution In-App Updates
Note: This is not recommended to avoid by passing Google Play to distribute an app
Good day.
In my application I have paid items and for a long time I was accepting purchases through PayPal only. Recently I have added Google Inn App Purchases too. But the problem is, that when you add inn app purchases to the app your app disappears from the stores of lot of countries (about 60).
Google supports said that as they cannot support inn app billing in that countries they do not distribute apps with inn app billing to such countries.
But for my app it is really bad, because I loose a lot of users.
So the question is - how can I keep inn app billing in my app for the countries that are supported and also distribute my app in the other countries without inn app billing.
The first solution that came to my mind is to create a totally different app in app store, but keeping the name of the app. But as I understand this way I have to change the namespace of my app, and that will cause me a lot of problems (I will have to create another facebook app for new namespace and a lot of such problems).
So may be somebody has other ideas how can I solve this problem?
Any kind of ideas are welcomed - even if you are not sure that they will work...
It's not a beautiful solution, but I think it would work:
Keep your old package name, and remove the in-app purchases from it. We'll call this the "functional package".
Create a new package to handle only the in-app purchases (including the UI for it, I guess). We'll call this the "IAP package".
Unfortunately (and this is the not-so-beautiful part), this means that users who want to do the in-app purchases stuff will have to install both of these packages. I'm not sure if the install order matters.
Now, implement an interface between these two packages so that the functional package can ask the IAP package whether certain purchases have been done or not. An AIDL service is probably what you want here.
Important: Depending on your worry of piracy/cracking, you should make sure this interface is somewhat secure. At least put a permission limiting who can access it, and give that permission a protectionLevel of "signature". You may also want to add some logic to check that this permission is actually defined by the expected package, and not someone else.
You probably also want your two packages to have a shared userid, and maybe have the IAP package's components run in the functional package's process through the android:process attribute.
I am going to have a alpha release of my app, which is not yet on the market. I want to have the app APK link sent out to friends via email so they can download it from my site CDN.
One question here: if I want to give them updates, what will be a good way? Can I download the new APK within the app, and somehow install the APK to replace the old one without anything to do with the market? So my friends can have the app upgraded while it is still in alpha release?
When I did it, I used Zubhium -- they were a web service with a small API that you could install into your app, giving you a mini "app store"-style backend and handling distribution for you. It would host and distribute your APK, connect up to their server when the app launched, check for updates, invalidate old versions, gather crash logs for you, etc. It was very good.
Zubhium are now https://www.vessel.io -- I presume they still have the above features as part of their now-much-bigger service, but when I checked you had to give them a credit card number even to sign up for the free plan, so I've not played with it.
A friend of mine uses http://testflightapp.com for iOS, and it looks like they have an Android version now, so that's certainly worth checking out. A quick search also shows up http://applover.me. #Janusz recommends http://hockeyapp.net/features in his comment.
As #Nanne points out in his answer, the Play Store itself now lets you distribute to limited alpha- and beta-test groups. That looks like it has fairly minimal features compared to the third-party services (no A/B testing, etc.), but will be familiar and free. And it doesn't need an extra SDK rolled into your app.
So, my general answer is that there's more than one professional beta-testing API/service that you could use, that they're generally very useful, quite easy to roll into your app, solve all the problems you're anticipating and more, and often have a free plan to get started. I'd recommend picking one of them rather than trying to roll your own solution.
If you want this only to be able to release your app in Alpha, and maybe later in beta, take a look at the android market again.
Check out this link: https://support.google.com/googleplay/android-developer/answer/3131213?hl=en
It boils down to the fact that you can have an Alpha-test, and a beta test, each with selected users. You can upload your app as normal, so you'll have updates via the market, but not everyone can download your app.
For the beta at least, you can select a community that is the source of your users, so all that are in that community could be testers.
This is the best method for testing I believe.
Now I've nearly finished my first app and I wanted to have two versions of it, one free (with ads and a little less functionality) and one full/paid version.
I know that you can not completely prevent apps from being cracked/distributed, but anyway, I'm currenlty having some thoughts about what the best method would be to release the app.
1) Both full and light versions in the store with no additional checks
2) Full version with Google Market license check integrated... Does this really bring any "security"? I've read that this protection has been cracked and therefore is pretty useless?
3) Have the light version and convert it via InApp purchase to the full version? Currently I have no idea on how to implement InApp billing and how to check whether a user paid inApp to release the full functionality and... of course there are also ways around that, right?
How would you do it?
Do you try to prevent your app from being illegally shared, or do you think it's not worth the effort, as any protection can be removed (and then it's shared anyway)?
Just gathering some thoughts :)
I have been through the same thought process and settled on option 3 for new apps.
My reasoning is as follows;
With option 1 you have two apps to maintain, users have to do a uninstall of your trial version and you have the problem of migrating data between the two versions.
Option 2 has all the problems of option 1 plus the headache of implementation.
Option 3 you have the benefit of only one codebase to maintain, users can quickly and easily upgrade with all their data intact and you have higher download stats/ratings for the one app rather than two.
Implementing it has got a lot easier with the version 3 of the billing library. I followed the sample from Google here and got a simple remove the ad's with IAB within a couple of hours.
I personally think that an In app purchase is the most secure way to stop people from getting free paid versions of your app, because when someone inevitably (if your app is popular) release an apk file of your app on the internet, it is just the free version.
If I want to deploy to the Android Market it looks like I have two options:
Create my own keystore and upload. When I update my app use that keystore on my APK to ensure that users are given the option to update.
Do step 1, but also implement Application Licensing which will put controls on how the app is used.
Am I correct to assume that step 1 means that anyone could copy my APK once it is purchased from the Android Market and install it anywhere they wish?
How common is it for people to use Application Licensing and is it the defacto approach?
My app will be paid and I want to ensure I am taking the best approach.
Am I correct to assume that step 1 means that anyone could copy my APK once it is purchased from the Android Market and install it anywhere they wish?
Yes you are correct, it would be extremely easy to copy your application.
How common is it for people to use Application Licensing and is it the defacto approach?
I would say it's very common since it's the only way to verify the licence against the Android Market, though I don't have any stats on this. Otherwise you would need to implement your own "Market" and verify purchases in your own.
My app will be paid and I want to ensure I am taking the best approach.
Use LVL, DO NOT use the default implementation. Watch the LVL session from the 2011 IO for a how to.
Often times, people will not simply download an app and copy it anywhere they would like. However, it is possible through some apps and other software for users to copy off APKs from their phones (even though they aren't suppose to). In my opinion, if you app is paid, you should implement Applicant Licensing. It is a very useful tool to help in preventing people from stealing your APKs (in other words, downloading it and then trying to install it some where else) as it checks on start up to ensure that the app is on the phone that purchased it. Otherwise, for free apps, I don't really see the neccessity because it's free and anyone could have downloaded it.