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.
Related
The company I work for wants me to publish their app as hidden in the Google play store and from what I have found that is not really the case unless a) you create a Google apps work account and invite all clients/staff to join and b) keep it as a beta and use clients/staff as testers. Is it really any other way of publishing an application as hidden (not searchable) and accessible only by link lets say?
You can use private channel for distribution or check alternative solutions like crashlytics
Only people who joined the beta test program can download your app. I don't know if you can really hide it from other people because in that case it would be still accessible in other ways such as the package name.
If there is no option for that, then probably that is not possible
But you might be searching for this: https://support.google.com/googleplay/android-developer/answer/2623322?hl=en
Edit:
If it is not a requirement to publish the app explicitly on Google Play, then you could upload it to your own web server and only let staff/clients have access to it.
You could then also implement a little updater in the app itself so it is kept updated.
Think about it. I have already made such an updater and it is not difficult to implement it.
Btw, if you don't mind, you may take a look at aptoide.com where you can publish apps but without being visible to other people.
I sell a game on Google Play called Quantum-X. Not many people have bought it so I want to move to an ad-supported model and make it a free download.
But I want to reward the people who did buy the game by disabling advertising. So existing users see no ads, new users see ads. I can store a flag in some obfuscated, device specific way which makes this determination.
But in order to this I need to tell the difference between paying and non paying users.
So how do I do this? I have a few ideas but I don't know if any of them are viable:
The old app wrote some preferences out. I could look for an old preference and set the flag. But this will not work if someone installs the app on a clean device since they won't have that preference. It is also an exploit since anybody could put the old key in to fool my app into disabling advertising.
My pay app currently uses LVL to validate a person's licence. If I make my app free, what happens when I call LVL? Does it respond LICENCED even if a user downloaded it for nothing? If I could tell paid from non-paying users from the response then I know how to set the flag. But LVL is a pain to test since I would have to upload the app, set it to free and then see what difference there is in the result and there may be none.
I could produce one final update of my pay app which sets the flag and asks users to upgrade. Then I could roll out the app free in a month from now. The same problem exists as with 1. that some users may not update or may install onto clean devices.
I could produce two apps on the store. The pay app could be renamed to "Quantum-X legacy" and a new Quantum-X goes in its place which is free. I would update the legacy version to install the flag, but people would have to switch to the new version for continued support. This would work but it's a lot more effort.
None of these are pretty although 2. would be the least amount of work. Has anyone experience of a working solution, or know a some better way of doing this?
EDIT: My intention is now a hybrid and I've begun to do this:
Rename the old app as Quantum-X Legacy and update the description.
The new free version is called Quantum-X. The only fly in the ointment here is that I must update the app package in the manifest to make the two apps distinct.
I intend to put a test into the free version that calls LVL using the old app's key. If this works the way I think it will, it will tell me when a user has bought the old app (since the licence server is being asked about the old app), and I can write out an obfuscated flag somewhere so I don't have to call LVL any more.
Free users carry on but with ads.
I'm up to 3. and this is my intention. If LVL doesn't work, then I might have to put out an update to the legacy version which writes the flag or puts a code out on screen that someone must use to enable adfree when they install the other version.
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.
Can Andorid Apps have same name - public name.. or they need to have different names..
i want to ensure that if i create an app and post on google play... someone else sld not copy the app and host it elsewhere with the same name..
please advise if apps can or cannot have same public name..
Your question is about apps having the same name, but your actual concern is about the theft of your application. These are two separate issues.
If someone did a straight copy of your APK and attempted to post it to Google Play, then they would be unable to do so if you had already posted that same APK to Google Play yourself. The reason they would be prevented from posting it, however, would be due to its package name being the same as an existing app, not because of its name.
A more sophisticated thief might be able to change your package name, and if they could do that, then they could also probably (even more easily) change your app's name. In that case, they might be able to post the resulting app to Google Play. You then would might decide to complain about this to Google and ask that the infringing app be taken down. There is a form for this kind of complaint here:
http://support.google.com/googleplay/bin/request.py?contact_type=takedown
I don't know what kind of results you might obtain from such a complaint, but Google has recently become much more focused on preventing infringing apps of this kind, so you might get a good response.
If you're talking about other app stores, outside of Google Play, then you have to look at the policies of those stores. But certainly there is nothing preventing an app that has been posted on Google Play from being posted on these other stores, provided that it meets the policies of the other store. Developers do this themselves (post on multiple app stores) all the time. And of course it can have the same name and the same package.
Regarding the more general question of whether two apps on Google Play can have the same name:
In the past it has been the case that two apps could have the same name on Google Play.
However, in August, 2012 (since you posted your question) Google announced new Developer Program Policies that state that
"Apps must not have names or icons that appear confusingly similar to existing products, or to apps supplied with the device (such as Camera, Gallery or Messaging)."
The full policies can be found here:
http://play.google.com/about/developer-content-policy.html
It may still be possible to post an app that has the same name as an existing app, but if someone did that, there is at least some chance that Google's (somewhat inscrutable by design) automated detection process will flag that app for the above reason. This could lead to a letter from Google and, if the app's name were not changed, an eventual takedown.
These policies are relatively new, and probably nobody, even Google, knows exactly how they are going to play out. How, for example, will Google resolve apps that are already similarly named? Will it go with the first app to use the name, or will it go with the most popular app having the name, or will it ask app owners to negotiate a settlement, or will it just allow the ambiguous names to be grandfathered in? I certainly do not know the answer, but for new apps, for sure, honest developers will avoid naming their apps in a manner that is similar to your app, and malfeasants who use the same name are likely to hear from Google.
Your package name must be unique (ex. com.example.mail.free) to publish an app on Google Play.
I nearly sure that the name is not important. You can have different names on different languages.
Is there an elegant way to handle end-of-life scenarios for an app on Google Play?
Suppose I have an app ("A"), and this app is being superseded by a suite ("S") that has all the functionality of that old app. In other words, S will absorb A. I think it makes sense, from a business point of view, to:
Prevent new sales of A, directing all new sales to S.
Keep supporting A with updates and fixes.
I want to know if it's technically possible. Please disregard SDK requirements and user experience and other OT issues, as I'm not considering with that yet (besides, with this I can always gift old customers in case I want to).
Right now, the only way I see to achieve this is to set the price of A so high that users won't buy it. That way I can keep providing updates without increasing its user base (and thus time spent on support etc.).
One very simple approach would be to simply upgrade your old app to have the new functionality of your suite app, and then rename and re-price the "old" app (which is now your suite) to reflect its new status (e.g., add the word "suite" onto the name). So far as Google Play is concerned, it will still be the same app, only "better." You will keep all the credibility gained from installs of the old app (by essentially upgrading the old app). Your old users will be happy because (as you've described it) they will have all of the old app's functionality, plus some additional functionality.
When I say "upgrade," that doesn't mean that you have to start with the old app's code base; you can just create an entirely new project and APK, so long as you use the same package name and upload it to the old app's location on the Google Play store, and so long as functionally it covers all of the bases expected by your existing user base.
Based on your description, I really can't see the down side of this. It may be that by conceiving of this feature superset as a new product rather than as an update you've created a problem that need not exist.
Currently, Google provides no such functionality. Your best route would be to add functionality to app A that allows it to update using your own private servers, then unpublish the app from the market. It really is quite that Google provides extremely limited functionality in the Dev Console. Instead of taxes, they should've added app coupons and private app listings. Oh Google, "driving sales" as always.