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.
Related
My org android app is signed with 2 Keystore files. So while doing app signing on Play Store, I am getting the following message
Your app cannot be enrolled into App Signing because of the following reasons:
We do not support enrolling apps signed with multiple keys
So, wants to know if there is any way to move from 2 certificate signings to 1 certificate keeping the same app in Play Store
Unfortunately it is not possible today.
For app updates to work, the Android framework requires that the app be signed by the same certificates, so it is not possible to change the certificates. The only option would be to create a new app (i.e. new package name).
Android has introduced key rotation, which could possibly help with this situation, but it is unfortunately not supported by Play to this day.
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.
We already have an android app deployed under Play.
Is it possible to change current keystore? Reason: currently we have a development team and this team will be discarded within 1 year.
I would like to know if it is possible to get 'current one' without asking them (we are owners of app - I have admin account in Play), replace this 'current one' and publish and new version of app, but using same package, same name.
We intend users not to download new version, but to have it automatically updated.
Yes it's possible.
If you are using App Signing by Google Play you are supposed to sign your bundle/apk with an Upload keystore which you can update by contacting developer support from your account owner. In the detailed guideline it says:
If you’ve lost your private upload key, or it’s been compromised, you can create a new one, and then ask your account owner to contact support to reset the key. When contacting support, make sure your account owner attaches the upload_certificate.pem file.
On the other hand, if you are not using App Signing by Google Play it means you are managing the Signing key yourself. In this case you still have the chance to upgrade the signing key only once in the whole lifetime of the app. Users with the previous key will be able to use and update the app with the legacy signing key and the new users will be enabled with the upgraded key. Here is what quoted in the reference:
In some circumstances, you can request an app signing key upgrade. Your new key is used to sign new installs and app updates. Your legacy app signing key is still used to sign updates for users who installed your app before the key upgrade.
Each app can only have its app signing key upgraded once in its lifetime. In the unlikely event that you have multiple apps using the same signing key specifically to run in the same process, you won’t be able to use key upgrade for those apps.
Details is explained here
I'm afraid that it's impossible. You should read more here: Google App Signing:
Instead of using Google Play App Signing, you can choose to manage your own app signing key and keystore. If you choose to manage your own app signing key and keystore, you are responsible for securing the key and the keystore. You should choose a strong password for your keystore, and a separate strong password for each private key stored in the keystore. You must keep your keystore in a safe and secure place. If you lose access to your app signing key or your key is compromised, Google cannot retrieve the app signing key for you, and you will not be able to release new versions of your app to users as updates to the original app.
To avoid losing your keystore, the best way is using Google Play App Signing:
If you lose your keystore or think it may be compromised, Google Play App Signing makes it possible to request a reset to your upload key. If you're not enrolled in Google Play App Signing and lose your keystore, you'll need to publish a new app with a new package name.
I'm sumbitting an android app to Google Play and am following the process to sign my app. However the documentation on the android development site seems unclear about whether or not every app I submit through my Google Play developer account should be signed with the same key or not.
From the android developer site:
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.
No the same app next version or its update should be signed with the same key. And if you want to upload new(different) app you have to generate new key and that key works for that app only and its updates.
Like i have uploaded two apps on the playstore proQuiz gilpix and wallpaper.
The keys for both are different and if i want to upload next version of any app, I have to use their respective keys.
The keys are ment to identify the original owner of the android application and allow them to update the older app on the playstore.
http://developer.android.com/tools/publishing/app-signing.html
No. You can use different signing certs for different applications.
Please read "Signing Your Applications" here: http://developer.android.com/tools/publishing/app-signing.html
Warning: Keep your keystore and private key in a safe and secure place, and ensure that you have secure backups of them. If you
publish an app to Google Play and then lose the key with which you
signed your app, you will not be able to publish any updates to your
app, since you must always sign all versions of your app with the same
key.
The important thing to note is that you:
"must always sign all versions of your app with the same key."
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.