Up until now we were using the in app purchaces api using the IabHelper classes that Google was giving in the form of raw code so that we could "rewrite" it and make it difficult for a hacker to reverse engineer it, trace the code and remove it and then upload the app in the black market with everything for free.
Now Google has released the Billing Library with very easy to trace methods and callbacks. Right away I'm wondering what that means for the safety of our apps because I think it's not that good. Can someone explain what Google is thinking with this and how we can still ensure that the app will not be easy to hack?
ΝΟΤΕ
I'm aware that it's impossible to make an app hackproof. We can just make it more difficult to hack so that the average person can't do it. My question is about whether using the BillingApi from a library makes it easier to hack than the previous approach.
You can't be sure what your app isn't hacked. It's only a matter of time.
I suppose all time that my app is hacked and I don't allow do any purchases if root was found.
I suggest you see the Google SafetyNet helper docs.
Good link from Dima!
The library mostly does integration with Play billing. There should be an additional logic in your app to protect it against hackers.
I also recommend checking Security Best Practices from Google Play billing team.
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
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 realise this is a loaded question but I'm hoping someone with a deeper understanding of obfuscation and public key security etc. will be able to help - and the issues are wider than just Apps with In App Purchases too, of course, but that's my personal interest at this point.
I once made the mistake of using ProGuard on one of my (free) Android Apps - I say mistake because tracing problems reported by users became and utter and total NIGHTMARE and I soon realised I was gaining nothing and so I dropped it.
I now have paid Apps and apps with In-App Purchases (using both Amazon and Google Billing Systems) ready for launch and it seems that using Proguard (or a similar alternative) is strongly recommended - but before I step back into that nightmare, is it REALLY essential?
If people want to reverse-engineer my code to remove ads or get Apps 'for free' then they'll do it somehow I'm sure - but I obviously don't want to make things like Billing Systems and people's personal credentials less secure!
The Google Play In-App Billing talks about obfuscating things like the In-App product Public Keys (by storing them in separate bits to make changing them harder) - I guess not Proguarding weakens that further - but is this just my Apps or does it have a wider effect on other people's Apps/customers own personal security?
Basically - I care not 1 jot about pirates because they will do what they do regardless, I certainly don't want to give myself work for just that purpose, but neither do I want to weaken security for other users either!
Anyone clued-up enough on this to comment??
ProGuard only helps prevent piracy; it does not affect the safety of personal information.
Well-designed payment processing systems (for the public) remain secure even if someone hacks their client (a.k.a. your app). The most someone could do is access paid content without paying, but there's no way for a hacker to compromise other people's apps through the Google or Amazon payment systems.
So, adding Google or Amazon payment processing to an app does not affect the security of the app.
However, if a hacker manages to hack someone else's phone through regular means, they might be able to access the payment information stored in your app. But ProGuard only protects code, not personal information, so it would not prevent this sort of hack either.
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.
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.