Develop Reference

Purpose of android app certificates

I want to clarify a confusion I have related to Android app certificates (used during installation).
In the web, certificates are used to map a public key with domain / identity (organization). The hash of the details is signed by CA, then verified by the browser.
An Android app ships with a public key. Based on my understanding, the developer could use his own private key, sign the hash of the app, then ship app with his public key. This information is used by installer.
My questions are:
Even if some CA was used, app would still be shipped with CA's public key - does it matter who owns the signing public key ? it could be anyone, as installer will just use it.
Is integrity checking the only thing android app certificate is used for ? App has a no public key like a website, so certificate is not being used to associate some public key with the app. Is there any other purpose for the certificate ?

does it matter who owns the signing public key ?
No. Usually, they are self-signed.
Is integrity checking the only thing android app certificate is used for ?
It is also used to answer two permission-related questions:
Is App A signed by the same signing key as App B? If yes, then those apps may be able to interoperate more closely than two arbitrary apps.
Is App A signed by the same signing key that signed the firwmare? If yes, then App A can hold certain permissions that are reserved for device manufacturers and custom ROM developers.
Also, developers can validate the signature of other apps, which can be useful for ensuring that you are talking to the proper app.

does it matter who owns the signing public key ? it could be anyone,
as installer will just use it.
Yes it will. Anyone can write an app, self-sign the certificate, and publish apps using it. The private key is still controlled by the owner, and he/she gets to control all the app's capabilities and any future updates to the app, as explained below.
Is integrity checking the only thing android app certificate is used
for ?
Nope, it serves more than that:
When installing Over-the-Air app updates, the device will confirm that the updated app's certificates match the existing one. If the developer were to sign the app with a new key, he/she should change the package name; without this, Google Play does not let the developer update the application. If the developer does want to change the signing keys, he/she will be forced to change the Application's package name, and hence this will show up as a new application altogether in the Play Store.
Two or more applications using the same public key can share data amongst each other. Permissions can be signature based for instance to allow this.
It is also possible for 2 or more applications signed using the same key to run in the same process group, and even share code and state.
More details available in the Android Developer page - https://developer.android.com/tools/publishing/app-signing.html#considerations

Android: Publishing and Signing same application for many customers

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)

Same keystore, but different keys for different apps?

Ok so I understand I can use the same keystore for multiple apps, but what about the same KEY or ALIAS? Should I use the same keystore AND same alias or key for all of my apps?

You dont have to use the same alias for your apps. But for the same app when publishing updates my understanding is that you have to use the same keystore/alias. Now, which approach is better? Depends, however signing apps with the same key establishes the trust among your applications in sharing data. From android developer's website:
The Android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications.

Why should I sign my apk before releasing to PlayStore?

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.

What does the term 'application signing' mean in Android?

Can anyone please elaborate what is app signing in android and why it is necessary to upload an app to android market? Also tell me what changes it make to the application package/apk file.
Thanks in Advance

You sign your application with your private key so that ownership and the integrity of the APK can be verified.
https://en.wikipedia.org/wiki/Public-key_cryptography
https://developer.android.com/tools/publishing/app-signing.html
You might've noticed that in some cases a download has an associated md5 hash, that's a similar sort of thing although intended exclusively for verifying the integrity of the download.
In the old days, you checksummed your downloads against the provided hash just because your connection was lossy and crappy and files could get corrupted.
These days it's that and security.
One among many security concerns would be a nefarious actor taking over your Android Market account and uploading a hacked/virus-infected APK. Signing with a private key ideally reduces the odds this could happen successfully unless they've made off with your keys as well. By identifying you, via the keys, they're also protecting your users from the aforementioned scenario.

App signing is required to identify the author.
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.