Android App Handover: Signing Keys, Certificates and Update Access

An APK or AAB is a deliverable, not a complete Android app handover. The next maintainer also needs a clear record of source, build steps, package identity, signing arrangements, service configuration and the supported route for future updates. Establish that evidence before the original developer leaves.

This is a handover checklist for buyers and project owners. It does not ask you to publish private keys or take ownership credentials from another person. Use supported account and release controls and arrange secret transfer through an appropriate protected channel.

Separate the two signing roles

Android's documentation distinguishes an upload key used for an app bundle from the app-signing key used for distributed APKs under Play App Signing. Those roles can involve different certificates. A successful local build therefore is not enough to prove that an existing store release can be updated.

Release materials to identify during handover

Material	Record	Do not confuse it with
Source repository	Repository, branch and delivered commit	A compiled APK with no build source
Build instructions	Toolchain, commands and configuration inputs	A developer's unrecorded local setup
Upload signing material	Who controls it and the supported update process	The certificate used for distributed installs
Signing certificates	Relevant fingerprints and their uses	A private key or a password
Store and service access	Named accounts, scope and responsible owner	A shared personal login

Make a release identity record

Write down the application ID, current store URL, delivered source commit, version name and version code. Add the build environment and a reference to where protected configuration is managed. Keep the record useful without putting secrets directly into the document.

Application ID / package:
Store listing:
Source repository and commit:
Delivered version name / version code:
Build command and toolchain:
Play App Signing arrangement:
Upload key owner and protected location:
Certificate fingerprints required by services:
Maintainer and next review date:

A package name typed into a document is not a verification step. Compare it with the actual build and the selected store app. When there are staging and production variants, list them separately so a test build is not accidentally treated as a production artifact.

Check certificate-dependent services

Some connected services use a signing certificate fingerprint to identify an Android client. Google's Play signing guide explains why the distributed signing identity matters for those integrations. Ask the developer which services depend on it and how the released build was checked.

For example, a sign-in flow may work in a locally installed build but fail in a store-distributed one if the service configuration represents only the local signing identity. Treat that as a configuration hypothesis to test with the actual distribution path, not a reason to share private signing files publicly.

Use a rebuild and update acceptance check

1. Check out the agreed source commit in the documented environment.
2. Supply configuration through the agreed protected process.
3. Build the release candidate and record its package and version information.
4. Verify the artifact using the APK and AAB inspection checklist.
5. Have the authorized release owner check the supported update route for the existing app.
6. Exercise critical integrations in the resulting test distribution and record the outcomes.

Do not send an unreviewed update to production merely to prove a handover. Agree the test track, authorized actions and acceptance criteria first. The evidence should show that the next maintainer can follow the process without relying on an undocumented machine.

Plan loss and departure before they happen

Record who handles a lost or suspected-compromised upload key, and where the current official recovery instructions live. Google provides an upload-key reset process for applicable Play App Signing setups; that is not a claim that every self-managed signing arrangement can be recovered in the same way.

Offboarding also includes repository membership, build service access and other connected systems. Use the collaborator permissions checklist for the console portion. Update release notes and operational ownership after a maintainer changes.

Define the purchased handover scope

Ask whether the delivery includes source, licensed assets, build instructions, dependency information, configuration documentation, release help and a defined support period. Separate those deliverables from future feature work and ongoing maintenance. The phrase “full source included” does not answer every one of those questions.

For what comes after acceptance, read the published-app maintenance guide. A documented handover lowers avoidable uncertainty; it is not a guarantee that future platform or dependency changes will require no work.

Sources

Android Developers: sign your app and Google Play: Play App Signing, checked on publication. The handover record is an editorial project-management aid.