We have developed several apps and published them on Android Market. We are now writing an app that another company will brand and sell through their own publisher account. The other company has no experience with Android Market or with Android development. I'd appreciate any insights from others who have faced similar situations. I'm specifically concerned about the following areas:

  1. Signing the app
    The alternatives we see are: sign with our usual key; create a signing key pair specific to the other company and sign with that; or help the other company install a development system, generate a key pair, and do the signing themselves. The latter would require us sending them the project sources, which presents its own problems. Other than our concern about sending the source, does the choice matter in any way?

  2. Licensing
    Since the license check will be done against their account, the code will need to embed their public key for decrypting the license response. Is there any reason they should be concerned about sharing that key with us? Are there any alternatives to them sharing the key with us?

  3. Publishing
    The other company is responsible for all marketing and sales; we are responsible for the app development. From what we can tell, Android Market is not set up to allow a clean separation of these roles. (It assumes that the developer will also be the publisher.) This makes it difficult to work out a division of responsibilities for the publication process. Our initial thought was to deliver the .apk file to them and let them handle it from there. The licensing issue was the first indication that we were being naive about this. The publishing process itself is rather technical, and we see two alternatives: walk them through all the steps or ask them to give us access to their publisher account and do it ourselves. What do others do?

2 Answers 2

  1. Signing the app I would generate a separate key for the company, and sign it yourself. The other company doesn't sound like it's at a technical level to appreciate the importance of a private. Also, I'm not sure what your agreement is, but they could at a later date ask for the keys used to sign the app they are selling. If you sign it with your own key, that means they could potentially sign other apps with your key and market them, something I'm not sure you want. If you're fine with sending the sources to the other company (with all the associated support costs of helping them set up a development system), it's a good option.

  2. Licensing See above. If you have their key, you can sign apps as the other company, something they might not be ok with. Having each company handle their own keys presents the least potential for conflict.

  3. Publishing This is the area where I'm least familiar with. I guess the answer would depend on your relationship - is this a one-off or the first of many? If it's a one-off, and you have a good relationship, you could ask for temporary access and do it yourselves; if you envision further work down the road, going through the pain of teaching them would make it much easier down the road.

Hope that helps!

  • We are now in the middle of the process and your suggestions were helpful. We generated a separate signing key solely for use in joint projects with this one company. After some prodding and us pointing to the Android docs, they agreed to send us their public key. We shipped them the .apk using their key with LVL. We've spent some time walking them through the upload process, but that's not complete yet. The biggest complaint I have so far is that both companies need to be involved in testing license responses. We're still in the middle of that. It's been slow, but we'll get there. Thanks!
    – Ted Hopp
    Jun 20, 2011 at 23:33

They probably don't want to do it themselves (unless they are a software company) nor do they want to be locked into you, so get a separate key and take care of everything.

If you can take out the technical elements of the publishing process, you may be on to something.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.