There was a question on Google groups:
Our main app offers In-App Billing for different advanced features. Recently we've wrapped our code in an AAR file which offers some basic functionality for free, but we would like to offer In App Purchases for advances features. Since we will be used by other applications as an SDK, and those applications might have their own IAB implementations and their own SKUs, we aren't sure if there is a way to still use the same Application ID and SKUs defined for our main app when trying to purchase something related only to the SDK part of the code, or would that be against the rules and wouldn't work because of public key used to verify the signature wouldn't match the private key of our main app?
I have the same problem so the question remains and any suggestion is more than welcome.
Thanks!!
we aren't sure if there is a way to still use the same Application ID and SKUs defined for our main app when trying to purchase something related only to the SDK part of the code
If you by application ID mean package this cannot be done when the app is uploaded to google play. Every single app has to have its own package(app ID). Each app would then have a different base 64 key and making the In App Items unaccessible from the other app.
For possible solutions:
(this is based on that I have understood the question correctly)
Our main app offers In-App Billing for different advanced features.[...] Since we will be used by other applications as an SDK[...]
Wordpress and design example:
I use the stargazer theme(parent), and this has many sub-themes(children). Each of these designs have small-large changes that overrides the existing, but does not contain all the code in the original design and requires the parent installed to work. Without the parent it does not have the necessary master code(or SDK) to work.
As such, a user that would have the child app which uses the parent app with IAB(in app billing) as an SDK for something, will require to have the parent app installed for it to work. Without the parent app the child app will not work propperly. If it accesses features created and distributed by the parent app there are a lot of communication mechanics(for inter-app communication(parent to child with feature data, for purchased features)) but the child apps would then get data from the main app and unlock local features in the child app.
The parent app here would basically provide In App Purchases for improved features. I am not sure however as to how these features are. The child app would though override the master app's implementation of the features, considering the previous wordpress example:
There are things in the master app that one can use, but the children would change these features(overriding) the master app.