Develop Reference

Sharing keystore between multiple apps

I am developing an SDK/API that will be used by apps not written by me.
I want my code to generate a private key once and store it on the device.
This key should be unique per device, I don't mind it being erased on factory reset, and I don't need to extract it from the device.
Sounds an ideal case for the KeyStore (preferably with a StrongBox).
I do want, though, different apps to use the same key to sign (or ask my API to do so)
I could not answer two concerns:
If my API is a library linked (statically) into the app, different apps using my code wouldn't be able to use the key, because the keystore requires
If I package my API as a separate android app, and have the other apps use it using Intents, I'll have to have the user install it manually, because as far as I could tell, Android/Play does not allow for dependencies between apps.
What is the most graceful way to resolve this situation?

Shared Content Provider

My application has two versions, a free and pro version and the Content Provider for the app data needs to be shared between the two.
It should be designed keeping the following in mind
Data created by any version should be visible in the other version instantly
as I understand, both the pro and free versions cannot declare the same content provider in the manifest file
Keeping the last point in mind, I need to create separate providers for the free and pro versions
Possible solutions:
Create two content providers, one created by the free version, the other by the pro version
When the pro version is first launched, if there is any data in the free version, copy that to the pro version
Whenever any data is written in the free or pro version, I should check if the other version of Content Provider exists or not, and write to both the Content Providers if they exist
Set the android:protectionLevel attribute to "signature" so that both the versions can access both Content Providers
Please let me know if this makes sense and follows best practices with respect to shared content providers. Do share any other ways of doing this.

So here is what i ended up doing:
I created two separate content providers for each version (each with a separate authority) and declared them uniquely
set their "android:exported" to "true" to enable sharing the content provider data across apps
defined a custom permission to each of the content providers (with read+write access) to restrict access to the data
for each of the permission definitions, I defined the "android:protectionLevel" attribute to "signature" so that my applications can implicitly and securely communicate with each other
in any given version, i then explicitly ask to access the content provider in the other version using the uses-permission android:name="MY_CUSTOM_PERMISSION element
Results:
Both the versions can now securely and implicitly access each others content-providers
When the paid version is fired up, it silently copies all the data from the free version to the paid one to prepare for seamless use

I have 3 apps in the market each having a free and a paid version.
For a given app, I have 100% code in a Android Shared lib project which is referenced from both the Free and Paid projects. These Free and Paid Android projects are just dummy projects and are only useful for its AndroidManifest.xml.
If you wish to enable/disable some functionality, you can always add the relevant check in the Shared lib based on the package name.
In your code (in the shared lib), you can distinguish between Free or Paid and enable/disable features based on the calling package.
if ("com.example.paid".equals(context.getPackageName()) {
//enable pro version features
}
Can you not do something similar? This will save you a lot of maintenance overhead.

Just my thoughts.
Is there really a need to have both the free and the paid version installed in a device? If not, you can simply provide a copy feature from free to paid when a user first launches the paid version. Then user can remove the free version and use the paid version exclusively.
The approach is fine. But I see one problem with it.
What happens when the content providers change over time? Lets say you decide to enhance the content provider with a few more fields. Then user should upgrade both the versions so that data is properly written.
Will both the content providers stay the same over time? What if you decide paid version will have more features, and hence more data is captured.

How to share the google android backup between applications?

I've implemented Android backup for my paid-application. I want to build an ad-supported version of the same app, and since they are using the same data I'd prefer to share the android backup between these two apps. How should I do?

EDIT
The refined question is whether it is possible to share the application backups on Google's servers.
My Answer: AFAIK it is not possible because Google will store the backups per package name, which must be unique per application.
Original Answer
I'm still not sure why you want to access the same data from both apps. Yes I understanding the upgrade path, but why not just copy the data over when the user gets the ad free one?
Anyway, your implementation of the BackupProvider will have to be responsible for managing the shared data. Now since you will have 2 versions of the provider (free + paid) they need to ensure they don't overwrite each other in the shared location (like the sdcard).
But even if you follow this approach Google is still going to maintain 2 separate copies of your users data, one per application (AFAIK this is determined by the package name of the app which must be unique)

Demo and paid application - how to implement?

I have nearly completed my application and about to upload it into Android Appstore. I need to divide demo and paid versions - one is free with limited capabilities, another one - paid with full functionality. The question is: how to implement it - the only idea which I have in my mind is following:
Upload 2 independent applications placed on different packages. But in this case there's one obstacle: let say user installed demo application packaged as my.foo.demo then user decided to buy full version which will be installed in package my.foo.paid. In this case I need to provide user with ability to transfer user files/data/preferences from package my.foo.demo to my.foo.paid. Wow, but it's not very simple task (keeping in mind Android's security model)
Probably there's another approach? Any ideas?

The easiest way would be to upload two independent APKs. There is a way to have a user download a free version, and then download a "key" application that unlocks the paid functionality. That can lead to lots of user confusion since sometimes they will download the "key" application and not the base application. So if you can upload two different versions, that will eliminate that hassle (but means you have to maintain two versions).
So now to answer your question about sharing the data. The simplest way would be to have a content provider for your data and just export that to the paid version. Alternatively, you can look into the sharedUserId attribute in the application's manifest. This will allow you to run in the same process and access the same files.

Upload two similar applications to Android Market

I want to upload the same application twice to the Android Market. One version will have AdMob messages and the other version of the same app will cost a pair of bucks.
Should I make two applications with differents packages names in order to upload them or is there any trick to do it with the same project.
Thanks in advance.

Every application at Android Market must have unique package name, so you have to place your apps into different packages (one be a subpackage of another though, i.e. com.app and com.app.ads). You can share common code in a library project.

You will need two different package names. You might also consider to exclude certain parts of your code in your free version, because Android Market is known for not being the most secure distribution channel. But if the only difference is the additional ads in your free version, it is not worth the effort.

There is another possibility, which unfortunately, I don't know how to do, but I'd like to find out. You can put all the functionality into one app and then create a second app which acts as a "key". Users download your first app for free, but it has limited functionality unless the "key" app is also present. You would charge users to download the "key" app.
This solution has the advantage of not having to maintain two code bases for every app, which is what I do and it drives me nuts.