What are all the conditions satisfied by the APK to upload in play store?
like debug release,signed apk,keystore generation.and please explain them how to do?
A release build. So you should ensure you are not polluting the logcat with your debugging statements. Usually this will automatically be flagged off for you but you may (as I often did) use different forms of debug logging (eg with the NDK) which will need explicit deactivation.
You will need to sign your APK also. You can generate a key and keystore offline with your development tools (i.e. Android Studio, can't remember about Eclipse but (How do I generate a "Keystore" for Google Play?) should work in that instance).
When you register an account on the playstore you need to upload your public key. You can associate about 20 (IIRC) keys with an app's GMS profile, although that is not strictly required to upload an app in general it is one of the great benefits of a Play Store account. See https://developers.google.com/android/guides/setup for more on that.
Then if you are seeking financial reward, either via advertisemnet or direct sales you will need to provide your address.
For this service and also, I suspect, for the purposes of identity verification, Google require a one off registration fee of a princely $25.
Related
We at my company work with outsource on our Android application. If the outsource provider has the full source code, is it safe to also provide him with the certificate and its credentials we signing the application's APK with?
There are 3 steps of security for Android apps:
Source code
.jks and credentials
Google console access
If you break all three, they can rework and reupload your app to Google Play Store.
Probably, it's bad idea to send them .jks and credentials.
And actually, why do they need that?
The release keystore you use to sign a APK will remain the same across its lifetime. If you are using the App Signing system, sharing the upload key is less risky, since your Developer console account credentials will remain with you, and you can reset that key.
Even if they have full access to source code, it is better to limit access to certificates and keys in order to avoid impersonation or misuse later, when they may not be working with you. You may also consider managing permissions for developer account users to ensure they can only modify what you allow them to.
Our project has multiple android developers that all have access to the Google Play Console, in order to be able to publish APK updates from their respective computers.
As mentioned in the docs and this post here :
The apk must be signed with the same certificates as the previous version
Question:
Is there a way where first developer can share his certificate with second developer, such that second developer is able to publish APK updates to Google Play console?
So far I didn't see any mention of this in the docs or discussion
The initial release of the app was published by the first developer. Now, the second developer would like to publish some updates as well. However this seems to be blocked, such that only APKs signed from first developer's computer will be permitted for Update upload.
Update
For a more established team, I can see the cloud solution from the accepted answer working - but in our case, sharing the certificate file proved to be the most practical solution. It was clean, fast, and solved the requirement without otherwise adding any additional layers to the stack.
One way to deal with this is to use the Google Play App Signing function of the Developer Console. Your signing key can be stored with Google and secondary upload keys are used to generate the build.
When you upload the build, Google will re-sign it with the actual signing key. If another developer comes along, the upload key can be revoked and a new one generated but the actual signing key remains secure in Google-land.
See:
https://developer.android.com/studio/publish/app-signing.html
and:
https://support.google.com/googleplay/android-developer/answer/7384423
Apple App Store allows publishing update to an application even when certificate lost and recreated but Google Play Store does not allow it.
Using same bundle id is fine for publishing an update of application to Apple App Store, so a new certificate could be used while publishing the update of the application.
So, why Google Play Store does not allow it? Is it a security weakness to allow it? Or Google Play Store is exaggerating about security and unnecessarily require same certificate?
Apple App Store allows it
But Google Play Store does not allow it
It has little to do with the Play Store. Android does not allow it, for security reasons. Malware authors would love the ability to replace an existing app with their malware-injected replacement. Requiring a matching signature is one of the ways that Android prevents this.
It's simple, Apple Certificate can be generated only by the owner of the account (or the hacker who got access to it). Also if the certificate is revoked the owner will get an email on this matter => not a big problem for security.
For Android, anybody who has a little knowledge about Android, can generate a keystore, find the app package name, and there you go, he/she could upload an update to your app => huge security problems.
On the other hand, as a developer is your responsibility to generate these keys/certificates and deliver them to your client and specifiy to your client that they are really important and they should be stored in a safe place. That's how I roll :D
There's a developer interested in purchasing one of my apps (the only one that actually have users), meaning I would need to send him the original source code, the keystore and request Google for a transfer following this link: https://support.google.com/googleplay/android-developer/answer/6230247?hl=en
The issue is: all my apps use the same certificate from the same keystore.
So my question is: Would it be possible for the new developer to hijack any of my other apps?
I believe that the answer is "No. A device would allow another apk signed with the same certificate and with the same package name to update on the device, but Google Play wouldn't allow the developer to upload another app with the same package name as any of my other apps".
But I'm not sure on that and I would like further tech details on it.
As I said, the other apps I have are not important and I could just as well unpublish them. But I rather not, and even if I do, the question is still valid.
ps.: yeah, now I've learned that I should have 1-certificate per app.
The package name of your application is unique in the Play Store. It is how devices (and the Play Store) identify your application, and thus must be unique and cannot be changed. Android will not allow your users to install two applications with the same package name.
However, giving your keystore to another developer is still risky. The Play Store employs two gates when updating an application:
First, you must have access to the account that owns the application.
Second, you must have an APK signed with the correct keystore
By giving someone access to your keystore, you remove one of the two security checks. If the new owner of the application where to gain access to your developer account, they could re-publish the other applications as well. There's also the risk of this new owner selling the keystore and application to someone else in the future who might do the same thing.
Theoretically if your account is secure, then your other applications are also safe from hijacking.
Whether this risk is acceptable is up to you.
They could sign an APK and encourage your existing users to sideload it. When sideloading, the app isn't going to be able to know if it came from you or them. But the Play store itself won't let them upload an app that you haven't transferred to them.
Normally, part of the agreement when the buyer buys and app that using a key used by other apps would include a small snippet that the buyer must protect the key. This agreement would be bilateral anyways, since you could in theory hijack their users by sideloading a signed APK.
Would it be possible for the new developer to hijack any of my other
apps?
No way in the world its possible for him to do anything to any other of your apps unless you give him your keystore.
Your keystore is the key to all your applications and you should never share it with anyone. Having an app signed with your keystore in my developer account would never ever let me do anything to your own apps.
Anybody can have apps publish in plays store with different keystores.
I am currently having an Android application developed by an outside third party. We are at the point where we are ready to implement/test In-App purchasing, but in order to proceed with that we must upload the application to the market first (so we can make the In-App Purchase ID's). In order to upload to the Market, you must sign the application with a non-debug key.
My questions are:
What is the best way to go about this and maintain the privacy of my keystore?
Can the keystore be changed later without affecting functionality of the app?
What is a good back-and-forth process that would make this work, assuming I will not be coding the In-App purchasing myself?
It seems the best way to test the app is to have the vendor upload it to Market under a different package name and using a certificate that you and this vendor share. This would be the debug version of the app, which would not be advertised.
After testing and debugging are complete and you're ready to release the production version, you'd have your vendor deliver you the unsigned APK to you with the final package name, and you would upload it to Android Market using your certificate, which you never share with the vendor.
The keypair used for signing must remain unchanged, otherwise you can't update existing application in Market. Consequently right approach is that the developer gives you an unsigned APK and you sign it locally, then submit to Market.
As Bruno Oliveira suggested in another answer, for debug purposes you can create an application and sign it with the key shared between you and developer. But in this case be ready to create and submit a brand new application for release for the reason I mentioned above.