I want to upload my application on playstore. I already have another application published. Is it necessary that I use the same keystore that my first application so the same package name, or can I use another keyStore? In fact I tried with a new keystore and I'm still stuck at Price and availability of the application (error)
In general, the recommended strategy for all developers is to sign all of your applications with the same certificate, throughout the expected lifespan of your applications. There are several reasons why you should do so:
Application upgrade – As you release updates to your application, you must continue to sign the updates with the same certificate or set of certificates, if you want users to be able to upgrade seamlessly to the new version. When the system is installing an update to an application, it compares the certificate(s) in the new version with those in the existing version. If the certificates match exactly, including both the certificate data and order, then the system allows the update. If you sign the new version without using matching certificates, you must also assign a different package name to the application — in this case, the user installs the new version as a completely new application.
Application modularity – The Android system allows applications that are signed by the same certificate to run in the same process, if the applications so requests, so that the system treats them as a single application. In this way you can deploy your application in modules, and users can update each of the modules independently if needed.
Code/data sharing through permissions – The Android system provides signature-based permissions enforcement, so that an application can expose functionality to another application that is signed with a specified certificate. By signing multiple applications with the same certificate and using signature-based permissions checks, your applications can share code and data in a secure manner.
For more see Signing Your Applications
you can use different keystore for different apps. But to update an existing app you must use the same keystore. For details about publishing see the doc here
You must use the same keystore because all the information will be lost if you use another keystore like No. of Downloads etc.
Also with the existing app if you upload same app with another keystore then it will give error for having same package name.
Try to use same keystore and change the version of app. That will be beneficial for you.
Related
I knew it's only for managing application in google play store.
But are there also other reasons to protect code from the decompiler?
I wonder what is the right answer for this question in the interview.
Anyone, who let me know the reasons why we should sign the application?
if you're asking why would we sign an apk, well a digital signature is a method of demonstrating the authenticity of a digital file, such as a document, message or in this case an apk, which is really just a collection of files.
so by signing an apk, we are effectively creating a way of ensuring that whoever makes use of the apk gets a verifiable copy of the file they were expecting to receive. This has obvious advantages in terms of security, as others can't make changes to this file whilst maintaining the same signature.
From the docs :
There are several reasons why you should do so:
App upgrade: When the system is installing an update to an app, it compares the certificate(s) in the new version with those in the
existing version. The system allows the update if the certificates
match. If you sign the new version with a different certificate, you
must assign a different package name to the app—in this case, the user
installs the new version as a completely new app.
App modularity: Android allows APKs signed by the same certificate to run in the same process, if the apps so request, so that the system
treats them as a single app. In this way you can deploy your app in
modules, and users can update each of the modules independently.
Code/data sharing through permissions: Android provides signature-based permissions enforcement, so that an app can expose
functionality to another app that is signed with a specified
certificate. By signing multiple APKs with the same certificate and
using signature-based permissions checks, your apps can share code and
data in a secure manner.
If you plan to support upgrades for an app, ensure that your app
signing key has a validity period that exceeds the expected lifespan
of that app. A validity period of 25 years or more is recommended.
When your key's validity period expires, users will no longer be able
to seamlessly upgrade to new versions of your app.
If you plan to publish your apps on Google Play, the key you use to
sign your app must have a validity period ending after 22 October
2033. Google Play enforces this requirement to ensure that users can seamlessly upgrade apps when new versions are available.
I've just finished my second react native app and going to release its android version. Should I create a new signing key or I can use my previus project key?
There is nothing that stops you to use one keystore for all apps, but it's not good practice.
With one key, it's easier for you.
With different keys, you can transfer just one of your apps to someone else.
There is no need to create a new signing key. You could use one signing key for every app.
I recently heard a case where a company sold an app to another company, and was more than happy to find out its engineers used separate project keys for all apps; the company basically sold the specific key along with the code and the intellectual property without affecting the rest.
Switching to a new set of keys for an already deployed app is not possible, as it is seemingly tied to the identification of apps for updates, preventing updates from third parties; unfortunately, I do not have a link at hand that documents this.
Android developer site say:
You should sign all of your apps with the same certificate throughout
the expected lifespan of your applications. There are several reasons
why you should do so:
App upgrade: When the system is installing an update to an app, it
compares the certificate(s) in the new version with those in the
existing version. The system allows the update if the certificates
match. If you sign the new version with a different certificate, you
must assign a different package name to the application—in this case,
the user installs the new version as a completely new application.
App modularity: Android allows apps signed by the same certificate to
run in the same process, if the applications so requests, so that the
system treats them as a single application. In this way you can deploy
your app in modules, and users can update each of the modules
independently.
Code/data sharing through permissions: Android provides
signature-based permissions enforcement, so that an app can expose
functionality to another app that is signed with a specified
certificate. By signing multiple apps with the same certificate and
using signature-based permissions checks, your apps can share code and
data in a secure manner.
At these link is another opinion:
I'd recommend using different keystores if they are totally unrelated
apps. If you end up selling one of the apps, you can give away the
corresponding keystore without compromising the security of your other
apps.
What exactly is the importance of signing an apk before releasing to the market?
From the Android Documentation for Signing Applications:
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. The certificate is not used
to control which applications the user can install. The certificate
does not need to be signed by a certificate authority: it is perfectly
allowable, and typical, for Android applications to use self-signed
certificates.
The important points to understand about signing Android applications
are:
All applications must be signed. The system will not install an application on an emulator or a device if it is not signed.
To test and debug your application, the build tools sign your application with a special debug key that is created by the Android
SDK build tools.
When you are ready to release your application for end-users, you must sign it with a suitable private key. You cannot publish an
application that is signed with the debug key generated by the SDK
tools.
You can use self-signed certificates to sign your applications. No certificate authority is needed.
The system tests a signer certificate's expiration date only at install time. If an application's signer certificate expires after the
application is installed, the application will continue to function
normally.
You can use standard tools — Keytool and Jarsigner — to generate keys and sign your application .apk files.
After you sign your application for release, we recommend that you use the zipalign tool to optimize the final APK package.
The Android system will not install or run an application that is not
signed appropriately. This applies wherever the Android system is run,
whether on an actual device or on the emulator. For this reason, you
must set up signing for your application before you can run it or
debug it on an emulator or device
Why means:
Some aspects of application signing may affect how you approach the
development of your application, especially if you are planning to
release multiple applications.
In general, the recommended strategy for all developers is to sign all
of your applications with the same certificate, throughout the
expected lifespan of your applications. There are several reasons why
you should do so:
Application upgrade – As you release updates to your application, you must continue to sign the updates with the same
certificate or set of certificates, if you want users to be able to
upgrade seamlessly to the new version. When the system is installing
an update to an application, it compares the certificate(s) in the new
version with those in the existing version. If the certificates match
exactly, including both the certificate data and order, then the
system allows the update. If you sign the new version without using
matching certificates, you must also assign a different package name
to the application — in this case, the user installs the new version
as a completely new application.
Application modularity – The Android system allows applications that are signed by the same certificate to run in the same process, if
the applications so requests, so that the system treats them as a
single application. In this way you can deploy your application in
modules, and users can update each of the modules independently if
needed.
Code/data sharing through permissions – The Android system provides signature-based permissions enforcement, so that an
application can expose functionality to another application that is
signed with a specified certificate. By signing multiple applications
with the same certificate and using signature-based permissions
checks, your applications can share code and data in a secure manner.
Another important consideration in determining your signing strategy
is how to set the validity period of the key that you will use to sign
your applications.
If you plan to support upgrades for a single application, you should ensure that your key has a validity period that exceeds the expected
lifespan of that application. A validity period of 25 years or more is
recommended. When your key's validity period expires, users will no
longer be able to seamlessly upgrade to new versions of your
application.
If you will sign multiple distinct applications with the same key, you should ensure that your key's validity period exceeds the expected
lifespan of all versions of all of the applications, including
dependent applications that may be added to the suite in the future.
If you plan to publish your application(s) on Google Play, the key you use to sign the application(s) must have a validity period ending
after 22 October 2033. Google Play enforces this requirement to ensure
that users can seamlessly upgrade applications when new versions are
available.
Why?
Developers can prevent someone from tampering with their app.
Sign to protect your app!
This works in the public key cryptography. You are the only one who has the private key. You are the only one who can sign your apps. The user can trust the app being directly from you. It is mathematically proven to be unfeasible to tamper with the app if the private key is not available.
You know, in public key cryptography there are two keys like the sides of a coin. The private and the public key. You keep the private key secret. You lock it away and keep it secure. On the other hand you publish your public key.
These keys are like the sides of a coin because what you encrypt with one key you decrypt with the other key.
And how is this applied for app signing?
Signing is encrypting with the private key.
Because you publish the public key the app store and the users have your public key. They can decrypt your app and therefore know for sure that the app is really your own. Android and the app store does this for them.
The app store verifies the signature by decrypting with the public key.
That's all, folks.
Sign Apk:
Generating a signed apk means to encrypt your apk with a password or a key that is known only to you and you have to remember this apk forever as if for any further upgradation done on your app you have to access it with your app then.
Hy,
yesterday, I publish an app on play store. I have done a big mistake, I signed the app with debug.keystore so the map is not shown when the app is published.
to solve this, I resign the app with a new keystore and generate a new map key (with new sh1).
but the problem that i can't now publish the new apk, they said (The apk must be signed with the same certificates).
what I can do now ?
You have to use the same certificate when you update your apk or Google Play won't recognize it as the same app.
From Google documentation
Application upgrade – As you release updates to your application, you must continue to sign the updates with the same certificate or set of certificates, if you want users to be able to upgrade seamlessly to the new version. When the system is installing an update to an application, it compares the certificate(s) in the new version with those in the existing version. If the certificates match exactly, including both the certificate data and order, then the system allows the update. If you sign the new version without using matching certificates, you must also assign a different package name to the application — in this case, the user installs the new version as a completely new application.
Source: http://developer.android.com/tools/publishing/app-signing.html
Similar info also here in Android developer blog: http://android-developers.blogspot.com.au/2011/06/things-that-cannot-change.html
Just as important as the manifest package name is the certificate that application is signed with. The signing certificate represents the author of the application. If you change the certificate an application is signed with, it is now a different application because it comes from a different author. This different application can’t be uploaded to Market as an update to the original application, nor can it be installed onto a device as an update.
[...]
In conclusion: There are some parts of your application that can not change. Please be careful.
So I'm afraid you can't do much in this case.
I developed an android project for a customer which I signed with my own generated keystore.
Now I'd like to hand over the project to a different developer; (how) is it possible for him to sign the app and submit it to the market - without my keystore? Can I generate a file for him or how does that work?
Thanks a lot!
Signing Your Applications is detailed in the Android documentation:
Application upgrade – As you release updates to your application, you
will want to continue to sign the updates with the same certificate or
set of certificates, if you want users to upgrade seamlessly to the
new version. When the system is installing an update to an
application, it compares the certificate(s) in the new version with
those in the existing version. If the certificates match exactly,
including both the certificate data and order, then the system allows
the update. If you sign the new version without using matching
certificates, you will also need to assign a different package name to
the application — in this case, the user installs the new version as a
completely new application.
This basically means that any developer will need to sign updates with your keystore, or users won't be able to install the new version.
You can modify the passwords for your keystore but you generating a new keystore will cause problems for your users. If you generate a new keystore, you'll have to remove the app from the Market and submit a new version. Existing users will not be able to upgrade - they'll need to uninstall and install the new version.
if you can want to give your keystore it's possible for that you need to give their details like alias name, password etc.
Another developer can create there own keystore on his way
Application signing gives you the possibility to make updates to the application. If the application v1.0 is signed with one certificate and application v1.1 is signed with different certificate - your users won't see the update notification, it will appear like a new application. Who should own the keystore is not as important, as fact that every update must be signed with the same certificate. In fact, the owner of the certificate must be the publisher: if you're the publisher - sign it with your certificate, if the customer publishes the application - sign it with his certificate. Hope this helps.