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.
Related
Before being able to publish an Android App on Google Play it needs to be signed with a release key. Its said to be for security. When generating the key one has to enter a password.
What is all the fuss about, here?
Let me ask, what would happen if my release key got stolen/copied. Assume somebody could even manage to use that key to sign apps of him/herself. What bad would that mean?
I would argue, little to none, correct? (considering that my developer account/console credentials were not stolen too)
Maybe the biggest/ only risk would arrise if somebody elses app signed with the stolen release key would become able to more directly access data of my app (on the users devices).
They can grab your APK (publicly readable on all Android devices), modify it (e.g., add malware), sign it, and distribute it. Assuming that they bump the versionCode, anyone who tries installing their hacked version of your app will succeed, as from Android's standpoint, it is a valid upgrade. If the hacker can obtain your credentials for your distribution channel (e.g., compromise your Google account for the Play Store), they can ship their update to all of your users.
Or, they can create their own separate APK and sign it with your signing key. Now, your app and theirs are signed by the same key. That opens up other attack avenues:
If you used android:sharedUserId, they can get at all of your app's files on internal storage, which are normally protected from other apps (outside of rooted devices)
If you used permissions with a signature protectionLevel, their app can hold those same permissions and perhaps interact with your app in ways that you were only expecting your own suite of apps to use
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.
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.
I have ready one application in Android that I am planning to sell to different clients. Each client will send me their own information to customize the layout of the application and maybe some functionality. The clients can decide if they want to give the application for free in the market or if it will be paid.
I know that it is not possible to upload the two applications with the same package name, so I will refactor the package name for each client.
According the Android documentation:
Android requires that all apps be digitally signed with a certificate
before they can be installed. Android uses this certificate to
identify the author of an app, and the certificate does not need to be
signed by a certificate authority. Android apps often use self-signed
certificates. The app developer holds the certificate's private key.
I would like to know what is the best way to handle the publishing and signing of my application:
Should I publish the customized version of my application for each client using my own google account or I should request/create one google account for each client?
Regarding the signing procedure, Should I use the same key for each customized version of my application or I should create multiple keys in one Keystore?
Thanks in advance
1- It is best that the client create their own Google play console and send you an invitation as admin, so that you can manage it for them (create new app, listing, publishing etc).
2- Sure you can use same key for all of them (i will recommend you that) as long as it is still valid (should be valid for at least 25 years)
There are many questions about signed and unsigned .apk files.for testing & debugging we can use unsigned .apk file that generated inside bin folder. This apk file generated using a dummy keystore file. My question is why we need to use signed apk. can't we publish a unsigned apk. what's wrong with that?
There's a number of reasons why you want to have a release signed application. There's even a great article about it. Here's a few reasons:
It's a method that the end user can verify that an app is in fact published by the same author.
The release process allows for Android to use additional features, like In App purchases. Without it, Google can't verify that in fact the app is yours.
It's a way of saying that someone trusted released the app.
It is a two step authentication process to verify your app is yours. That gives an added layer of security that can't be done via other means.
Applications signed with the same key are allowed to share resources. The debug certificate is shared by all, and you probably don't want to have that level of access with all of your apps.
Basically, it makes a hacker's life more difficult, which is always a good thing.
For instance, one might give access to the Google Play account to people to modify the description, but you don't want them to upload new apps. Without the key, they can't upload the app. Furthermore, if your google password is cracked, you still can't upload the app. It takes having your private key file and key to crack it.
As #Pearson covered almost all the things but one thing I like to cover.
In Android, you can not install the unsigned application in any how on your developer phone/emulator. You have to sign your application either by debug or your own certificate.
Upon installation, the Android SDK generates a “debug” signing certificate for you in a keystore called debug.keystore. A debug certificate is only valid for 365 days.
So When you install your application through any IDE Eclipse/Android Studio, IDE also sign the app using the debug certificate.
Update
My question is why we need to use signed apk. can't we publish a unsigned apk. what's wrong with that?
You need to sign your app with your own release keystore certificate because you can't publish app which are signed with debug certificate because
One reason is your debug certificate expire within a year so after that you can not release the update of your app Once your debug certificate has expired that why also reason Google does not allow and some more major security concern.
Second reason is android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications.
Only people who have enabled debugging in their developer options will be able to run it. And people will need to know how to enable developer options (by clicking on 'Build Number' in the phone settings seven times). Google will not let you publish a debug apk, so people will have to side-load it.
Apk with debug keystore is a signed apk. Unsigned apk can't be uploaded to a device. For production you must create a different keystore to sign with. Also, once published, future updates must be done using the same keystore. If the keystore is lost, the application can't be updated.
An unsigned APK is harder to trace to the original author. Although in principal there is nothing wrong with that, Google forces you to sign your APK before publishing in Google Play. Because of this Google has the power to revoke the certificate when a developer abuses Google Play to publish software, ie. malware.
Also, because you have to pay Google for a certificate, Google hopes that malicious devevelopers won't pay over and over again to publish there application.
From Android Developers:
"The Android system requires that all installed applications be digitally signed with a certificate whose private key is held by the application's developer. The Android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications"...
Read all about it here