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.
Related
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.
My Google developer account holds now 5 different apps in it, 4 of them were created before the new Google App Signing was released, and they all 4 share the same certificate. When I created the last app I followed the steps to create a new key and now that one works "separatedly" from the rest of apps, with its own release key.
I'm wondering if I could use the same recently created release-key.jks that I'm using to sign the last app for the rest of applications.
Also in case I could, which of the three options that the App Signing page of the Google Play Console offers me should I choose to upload it?
"You've exported your app signing key"
"You haven't exported your app signing key"
"You don't store your app signing key in a Java Keystore"
I'm a bit lost here and I don't want to mess things up by not being able to release more updates in a future.
Thanks beforehand!
You should use the same key you signed it with for the first time
According to https://developer.android.com/studio/publish/app-signing#considerations
You should sign all of your APKs with the same certificate throughout
the expected lifespan of your apps. 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 those APKs 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. If you use
Google Play App Signing, Google ensures your apps are correctly signed
and able to receive updates throughout their lifespans.
I developed an android application using Flash Builder.
Version 1.0 has been created with an old certificate (.PFX file).
That certificate is expired.
So I create new Version 1.1 with a new certificate.
But when I try to install the new version, the following message has been displayed.
Application not installed: an existing package by the same name with a
conflicting signature is already installed.
There is a simple solution: Uninstall first version (1.0) and install the new version (1.1).
But I don't want to lose my application data which is created by 1.0 (old version).
Could anyone please suggest a better solution?
Unfortunately, As of now there is no better solution for this situation.
Quoting the official documentation on Android Developers,
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.
So as per suggested by the documentation, You should create a key with maximum validity and use it for signing the application in future.
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.
So to conclude, You have to uninstall the old version and install the new one which is singed with the new certificate.
Hope this helps.
You can renew your old certificate with your Certificate Authority (CA) so that you will not face this conflict.
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.
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.