问题
Within my Android app that is available via Google Play, I want to offer additional items that can be bought via in-app billing.
The kind of items I want to offer is media content such as graphics and sounds, which would normally go into the res folder of the app.
The problem is that these resources must be protected, of course. In its documentation, Google suggests not to store the content inside of the application package but to obtain a key after the item was bought and then send the key to a remote server where the key is checked and, if successful, the graphics/sounds offered for download to the app.
This sounds good, from the security perspective. But if I do this, I can't use the content as easily as resources can be accessed normally. If the user can get additional background PNGs, for example, I can't use R.drawable.new_background but have to decode the bitmap programatically, right?
So are there any alternatives or best practices for downloading additional media content via in-app billing?
I would say, as everyone who is determined enough can reverse-engineer the code, anyway, why not just store the content inside of the app but do strong checks if the user might use that content at all.
回答1:
One of obvious reasons for not storing additional content in the app is your app's app download size. If you are offering audio as additional content it can drammatically increase the size of your application. And users care about it. Besides it makes it easier to publish additional content, since you can do it via your server side/developer console without the need to publish app update. Moreover, if you want to provide high quality graphics, you will be able to serve appropriate version of the image directly to the device without the need of storing all density/screen size versions.
If you are concerned about security you can always use encryption and signatures to access resources and make attackers life much harder by properly obfuscating your code (or even moving security/decryption related code to native side, which will make it faster as well).
Yes, that would create a drawback that you will have to decode them programmatically and there is nothing to do about it. I honestly don't see why it is so big of a deal, on contrary, I think it's quite convenient that you will have more data driven access to resources.
As a summary I dont really think there are any standards for doing this and it depends on your app and content type. If you offer a fixed amout of 5-10 images, then there it is perfectly fine to keep them locally, if it is richer content, more items, heavier resources, then client-server would suit you more.
回答2:
The answer depends somewhat on your specific concerns, which, from your question, might be either 1 or 2 below:
1) I'm concerned that someone will be able to use my resource within my app without paying, or
2) I'm concerned that a user (either one who has paid, or one who has not paid) will remove my resources and use them outside my app.
Another possibility, that does not seem to be indicated by your question (but which others have attempted to address) would be:
3) I'm concerned about my initial APK download being too large due to downloading a large number of resources, only some of which they user will decide to use.
If your only concern is item 1, then you can just store your resources as you normally would, but inside your app, refuse to load / use any resource for which you have not yet received an in-app payment. This is certainly the simplest approach.
If your concern is item 2, then you can just include with your APK an encrypted binary archive in the raw folder, and decode a specific resource from it whenever that resource is authorized (e.g., by payment) for use by the app. As others have noted, this is not really a big deal in terms of processor load, and it does provide some protection from casual theft. Of course, there is always copyright law if you're dealing with one of those "creative plagiarist" oxymorons who breaks your encryption and steals your resources anyway.
If your concern is item 3, then you'll need an external server from which your items can be retrieved. Google App Engine is a popular choice for hosting when implementing this kind of storage outside the app. You would want to just cache any purchased /downloaded resources in an encrypted archive in your app's own external files folder (as returned by getExternalFilesDir()), then read and decrypt it as in item 2, above. Such files will be automatically deleted when your app is uninstalled.
回答3:
One solution would definitely be the following approach featuring two apps that share the same user ID. But this is not as elegant as in-app purchases and a bit hacky, obviously.
- Create two apps with the same
android:sharedUserIdinAndroidManifest.xml - Store the paid content in the second app, that is a library app from now on and only contains those images (apart from necessary folders and manifest)
- Sign both APKs with the same key
- Offer the first app for free, as usual, and make the second app a paid one
- In the free app, use the
PackageManagerto check if the second APK is installed - If yes, use
createPackageContext()to create aContextfor the second app which is then used to access the second app's resources from the first app
回答4:
Google Play offers extension packs that can be purchased. These are large extensions that can be downloaded if purchased, and are separate from your app. This is one possibility.
http://developer.android.com/google/play/expansion-files.html
Depending on how secure you want it, and the size of the media, you can encrypt the media with a key, and store it with your app. It will be downloaded and installed with the app, but inaccessible. When the in-app purchase is complete, you can decrypt the contents and offer it to the user. You can either store the key in the source code with the app to decrypt it, or you can verify the purchase on your own server and retrieve the key from your server.
来源：https://stackoverflow.com/questions/14510165/offering-additional-media-resources-graphics-sounds-as-google-play-in-app-bill