Android Code Signing: Why There Is No Certificate to Buy, and What Developer Verification Changes

Do you need a code signing certificate for an Android app?

You need a signing key, and you do not need to buy a certificate. Android refuses to install an unsigned app, so signing is not optional, but it accepts a certificate you issued to yourself. Android Studio generates one for you through its signing wizard, or you can create the keystore directly with keytool from the JDK. No certificate authority is involved at any point, and none can be.

This surprises people who have shipped desktop software, and it shows up in a predictable way: a team gets ready to publish its first Android build, remembers the unsigned-publisher warnings they fought on Windows, and starts shopping for the Android equivalent. There isn't one. The two platforms solve the same problem — proving that an update came from whoever shipped the original — by opposite methods, and only one of those methods has a product attached to it.

The first row is the odd one out, and the reason is in the second column rather than the third. Every other row describes a signature that a machine has to evaluate cold, with no history of the publisher. Android never does that.

Why there is no Android code signing certificate to buy

Two rules collide. Google Play requires that the certificate signing an app has a validity period ending after October 22, 2033, and Google's own guidance is that the key should be valid for at least 25 years. Since March 1, 2026, a publicly trusted code signing certificate cannot be issued for more than 460 days, under CA/Browser Forum Ballot CSC-31. A CA physically cannot issue what Play asks for without leaving the rules that keep it publicly trusted.

It was never possible even before the cut. The old ceiling was about 39 months, so the longest publicly trusted code signing certificate ever available fell more than two decades short of 25 years. The gap widened in 2026 rather than opening then, which is why the answer has been stable for as long as Android has existed while the reasoning behind it keeps getting sharper.

The direction of travel matters here too. Publicly trusted certificate lifetimes are getting shorter across every product line, for reasons that have nothing to do with mobile: shorter validity limits the damage a stolen key can do and forces automation into renewal. That trend is a good thing for TLS and Authenticode, and it moves the industry further away from being able to serve a platform that wants one key to last a quarter of a century. If you want the detail on that, the 460-day validity limit and how it reshapes renewals covers the change itself.

How Android decides to trust an app

Android records the signing certificate when an app is first installed, then compares it against the certificate on every later update. In Google's words, the system "allows the update if the certificates match," and if you sign a new version with a different certificate you have to give the app a different package name, at which point users install it as a completely new app. The certificate is an identity anchor, not a credential to be validated against anything external.

Anyone who has configured certificate pinning will recognise the shape of this. Android pins your app to your key on first contact, permanently, with no CA in the loop and no way to appeal. The same mechanism drives signature-based permissions: one app can expose functionality only to apps signed with a specified certificate, which works precisely because the certificate is a stable identifier rather than a rotating credential.

Reading the two models side by side also explains why the self-signed certificate isn't a weakness. A CA exists to answer a question Android never asks. What Android needs is a key that stays the same and stays secret, and a CA contributes nothing to either property. Where the risk actually sits is key storage, which is why the custody question further down deserves more attention than the certificate question people usually start with.

Creating the key Android actually wants

Generate an RSA or EC key in a Java keystore with a validity period long enough to outlive the app. Google's guidance is at least 25 years, and Play enforces an expiry after October 22, 2033, so -validity 10000 (roughly 27 years) is the conventional choice. Android Studio's Generate Signed Bundle / APK wizard produces the same thing if you would rather not touch the command line.

keytool -genkeypair -v \
  -keystore release.jks \
  -alias upload \
  -keyalg RSA -keysize 4096 \
  -validity 10000

The -validity flag is counted in days, and this is the one value worth getting right first time. A key generated with the default validity expires in 90 days, Play rejects the upload, and the fix is a new key — cheap on day one and impossible after your first public release, because the key that signed the installed version is the only key that can sign its updates.

Treat the keystore file and its passwords the way you would treat a production database credential. Committing release.jks to the repository is the single most common mistake in this area, and it is worse than it looks: unlike a TLS certificate you can revoke and reissue within the hour, an Android signing key that leaks cannot be revoked at all. There is no CRL, no OCSP responder, no root program to appeal to. Rotation, covered below, is the only remedy and it is partial.

Who holds the key under Play App Signing

With Play App Signing there are two keys. You keep the upload key and use it to sign the bundle you send to Google; Google holds the app signing key and uses it to sign the APKs that reach users. Google describes the app signing key as one that "never changes during the lifetime of your app," stores it under its own key management service, and does not let you retrieve a copy once Play App Signing is configured.

This is not really optional for new apps any more. New apps have been required to publish as Android App Bundles since August 2021, and the bundle format, by design, "defers APK generation and signing to Google Play." If you are starting an app today and distributing through Play, Google signs what users install.

The trade is worth naming plainly, because it cuts both ways. Handing custody to Google removes the failure mode that ends apps: lose your upload key and you request a reset through the Play Console, and your users never notice. In exchange you accept that Google's infrastructure signs your software and that you cannot take the key with you. Teams shipping through alternative stores or direct download alongside Play feel this most, since those channels need a key you actually hold.

Anyone coming from the Windows side will notice the structural echo. Cloud code signing services put the signing key in a certified HSM you reach remotely rather than on a token in a drawer, for much the same operational reasons — how cloud signing compares with a physical token walks through that decision. The difference is who ends up holding the key: with Play App Signing it is the distribution platform, which is a materially different bet from a CA-operated HSM you rent.

Can you change an Android signing key?

Up to a point, and only through Play. An app published on Google Play can have its app signing key upgraded from the Play Console, using APK Signature Scheme v3 to record a signing certificate lineage that links the new key to the old one. The new key signs installs and updates for users on Android 13 and higher; the original key keeps signing updates for everyone on earlier releases.

So rotation adds a key rather than replacing one. The old key stays operationally live for as long as you support older Android versions, which means a compromised key is not neutralised by rotating away from it — every device that has not reached Android 13 still accepts updates signed with the key you were trying to retire. Plan for rotation as a slow migration measured in years of device turnover, not as an incident response tool.

Compare that with the publicly trusted world, where a compromised code signing key is revoked, the revocation propagates, and a replacement certificate is issued the same week. Revocation is the facility Android trades away when it drops the CA, and it is the strongest argument for treating the keystore as the most sensitive artefact your build system touches.

Does developer verification need a certificate?

No. Android developer verification checks who you are, and it reads the signing certificate you already made. Registering a package name in the Android Developer Console asks for the package name plus the SHA-256 certificate fingerprint from your app signing key pair; to claim an existing package name you sign an APK with your private key and upload it as proof of ownership. Nothing in the flow accepts, requires, or benefits from a CA-issued certificate.

As of September 2026 the enforcement dates are staged. Google places the regional deadline at September 30, 2026 for participating app stores in Brazil, Indonesia, Singapore and Thailand, on certified devices running Android 7 and above, with the global rollout in 2027 and beyond. The participating stores Google lists are Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore and GetApps. The ADB workflow is unchanged, and an advanced flow is planned for users who want to install unverified apps.

One detail catches teams with a long-lived package name: you may not automatically be the party eligible to register it. Google resolves contested package names by install share — a developer whose keys account for more than 50% of installs has priority, a developer with a sizeable cluster of 50 or more installs can register when no key holds a majority, and otherwise it is first-come, first-served among developers with a known key. Anyone who has shipped the same package through several signing keys over the years should check this well before the date that applies to them.

When you do need a CA-issued certificate

The moment your product ships anything that runs outside Android. A cross-platform codebase is where this bites: Electron, Flutter, .NET MAUI, React Native for Windows and Unity all produce a Windows build alongside the Android one, and that Windows build lands on a machine with no prior record of you. Unsigned, it triggers the unknown-publisher warning at install, and the self-signed key that satisfies Android does nothing for it.

That is the one genuine purchase decision in this whole area, and it is narrower than it looks. You need an OV or EV code signing certificate for the desktop artefacts, from a CA whose roots ship in the operating system trust stores, with the private key held on certified hardware — a requirement since June 1, 2023, which is why these certificates arrive on a token or through a cloud signing service rather than as a file. My-SSL issues through Certum, and the OV and EV code signing options set out which validation level suits which situation.

If you are working out which of those rows you are in, the wider version of the question is answered in our walkthrough of when a code signing certificate is actually required, which covers the same decision across every platform rather than just Android.

FAQ