Developer Verification: A Signed APK Stopped Being Enough to Install

We maintain fourteen Android apps across nine clients. In August we sat down to answer one question that should have taken an afternoon: for each app, which legal entity owns the developer account that publishes it? We had a confident answer for six. The remaining eight took nine days. Two are still open. One of the two is a white-label build that ships to a client's own customers under their brand, from an account opened by a contractor who left in 2024, signed with a key that lives in our CI.

Nothing was broken. That is worth saying first, because it is the whole reason this sat in a backlog for a year — every one of those apps installs today, passes review, and has a green pipeline.

What changed is the rule about who is allowed to install an app at all. From 30 September, in the first enforcement markets, an Android app has to trace back to a verified developer identity before a certified device will install it. Not before a store will list it. Before a device will install it. That moves verification out of the account-admin drawer and onto the release path, next to the signing key, and it is the first time in years that a gap in your company's paperwork can make a correctly signed binary refuse to run.

The account that publishes the app is rarely the company that owns it

Nobody sets out to lose track of this. It happens because a developer account is the cheapest thing to create at the start of a project and the most expensive thing to move at the end of one. On day three of an engagement somebody needs a console to upload a build to, so they open one, with whatever email is convenient, on whatever card is nearest, and the project ships. Four years later that account is holding a live app, a signing key, ten thousand installs and no owner anybody can name in one sentence.

Across fourteen apps we found four distinct shapes, and only the first one is boring.

• Client account, client key, client billing— the clean case. Verification is entirely the client’s to complete and our job is a two-line email telling them it is due. Six of fourteen.
• Our account, client’s app — we opened the console during the build phase and never migrated it. The app is theirs commercially, the publishing identity is ours legally, and the two facts have never been written down in the same document. Four of fourteen.
• White-label, one codebase, many package names— a single build pipeline producing per-tenant apps under the tenant’s brand. Each package name may need to sit under a different verified identity, and the flavour matrix in Gradle is the only place that relationship is currently expressed. Three of fourteen.
• Enterprise internal, never on a store— the field app distributed by MDM to a client’s own drivers. It has no store listing, so it was never on anyone’s compliance list, and it is the one we are most worried about. One of fourteen.

This fails at install, which is the worst place for anything to fail

We have run plenty of Android platform migrations, and the target-SDK ones are, in hindsight, pleasant. They fail at submission. The console rejects the upload, a pipeline goes red, somebody fixes it inside a day, and the worst case is a delayed release. The feedback loop is short and it points at you.

This one fails on a stranger's phone, in one country, on a Tuesday, silently. There is no crash because the process never started. There is no stack trace, no Crashlytics event, no ANR, no review, no support ticket from a user who has already moved on to a competitor's app. Your dashboards measure sessions, and this failure is defined by the absence of one. The first signal most teams will get is a monthly install-count line that bends down in exactly four countries.

“Every metric we own is computed from devices that successfully ran our code. A rule that stops the code running is invisible to all of them.”

Google has said that over 99% of Play apps were registered automatically, and that number is both true and useless to an agency. You do not operate the 99%. You operate a portfolio, and a portfolio is made of exceptions: the app under a dormant account, the one whose billing card expired, the tenant build nobody has touched since launch, the internal tool that was never on a store and therefore never on a list. The 99% figure describes apps. Your risk is distributed across accounts, and one unverified account can take several apps with it.

What we changed in the release checklist

The fix is not technical, which is precisely why it kept losing to technical work. We gave it a slot anyway, and made it something a pipeline can assert rather than something a project manager has to remember. Five changes, in the order we made them.

• 1One row per app, not one row per client. Package name, signing key fingerprint, publishing account, legal entity, distribution channels, named human at the client who can act on it. Fourteen rows took nine days to fill because three of the columns required somebody to log into something they had forgotten existed.
• 2Registration status became a CI check. The verification APIs that landed in August are the reason this is worth automating at all — status can be queried rather than screenshotted. Ours runs nightly per app and posts to the same channel as the build, so it is noticed by the same people.
• 3Off-store distribution gets audited first. MDM builds, direct APK downloads, partner sideloads. They have no store to warn them, no review to fail, and nobody whose job description includes watching for this.
• 4Ownership transfer is a deliverable now, with a date. If the account is ours and the app is theirs, that is a migration with a scheduled end, written into the statement of work. It is the only item on this list that is genuinely awkward to raise, and it is the one that matters in three years.
• 5Handover includes the identity, not just the artefacts. Repository, keystore, console, and now the verified developer record and who is responsible for renewing it. A handover that transfers a keystore without transferring the identity it is registered against hands over half an app.

The thing that surprised us was the tone of the client conversations. We expected to be explaining a Google policy. What actually happened, in five of nine calls, was that somebody on the client side discovered they could not name the owner of their own app either, and that the awkwardness was mutual. Two of those calls turned into paid work to consolidate accounts that had drifted across three internal departments. A compliance deadline is a bad reason to fix ownership, but it is a working one.

If you only change one thing

Build the row-per-app table this week, before the deadline makes it urgent for the four countries in the first wave and before 2027 makes it urgent everywhere. Not a policy document, not a slide — one table, one row per package name, filled in by somebody who is allowed to log into things. The table will tell you within two days whether you have a paperwork task or a migration, and those are very different amounts of work to discover in the last week of September.

The broader shift is worth internalising beyond this one deadline. For fifteen years the signing key was the only identity an Android app needed, and it was an artefact you could put in a vault and forget. It now has a second half that lives in a company registry, expires, belongs to a legal entity, and can be invalidated by events that have nothing to do with your code — an acquisition, a dissolved subsidiary, a contractor who left. That half cannot go in the vault. It has to go in the release checklist, because it is now on the install path, and everything on the install path eventually breaks something.