Working document · Free, and free to forward

The Android Build
Handover Sheet

Five groups of questions about the artefact, answered once and sent with it — and then the section that makes the rest worth filling in: what each answer changes about the findings.

Groups of questions, all Android

Answers, and what each changes

Deadlines printed in it

A scope document says how many. It does not say which

Our own request-for-proposal template carries two rows for Android and iOS, and each offers the reader exactly two things to fill in: how many, and who owns them. Counted in that file on 3 September 2026, it contains the words obfuscation, variant, debuggable, mapping file, APK, SDK and target API exactly zero times between them.

That is not a fault in it. An RFP goes out before a supplier is chosen and before the artefact exists, and a question about a mapping file has nobody to answer it yet. It is the reason a second document is needed rather than a longer first one — and the gap between the two is where an Android engagement quietly opens on a call that establishes which build this actually is, rather than on testing it.

These questions are not new. They are step one of any competent methodology, asked at kickoff by a tester who then writes the answers into a ticket. This is them, in writing, before the engagement starts — which costs the person who already knows the answers a few minutes and removes an entire category of late surprise.

What it asks

Which build this is The variant and product flavour. The Play track it came from. The target API level the artefact declares — not the one in your source.

What can be read from it Whether android:debuggable is set in the artefact supplied. Whether shrinking ran. Whether the mapping file exists for this exact build, and who holds it.

What is defending it Root detection, shielding, emulator and debugger checks, pinning, attestation — and whether a build with them disabled can be supplied.

What it talks to Which environment this variant compiles in, whether it ships a different network configuration from production, and every third-party SDK inside it.

Whose app it is Upload key or app signing key, rotation, how many keys the organisation holds, and where the package name came from.

Then the section that is the actual reason to fill it in. What each answer changes takes fourteen answers and says what each one does to the assessment: a debuggable artefact produces findings about a build no user installs; a missing mapping file produces findings your developers cannot map back to their own source; shielding that cannot be lifted produces a report about what the shielding prevented from being examined. None of those is a reason to delay testing. They are reasons to know what the report will be able to say before it is written.

Nothing in it is scored and there is no right column of answers. An application with no shielding, no mapping file and one signing key is a perfectly ordinary application. And the obligations it names — the target API level Play enforces, package-name registration — carry no dates: a deadline printed in a downloaded file is wrong the moment it moves and nothing recalls a file from an inbox, so the dates live on this site, where they are corrected in one push.

The Android Build Handover Sheet

Thirty-four things to write down about an Android artefact, fillable, plus what each answer changes about the assessment.

A completed copy of this sheet evidences nothing to Google or to a regulator. It is a record of what was handed over and which build the findings describe — which is the question that gets asked six months later and is almost never answerable. Keep it with the report.

Filling it in for an assessment you have not booked yet?

Tell us the app, the form factors it ships on, and whether it is a bank's. Security Brigade has been CERT-In empanelled since 2008, with 693+ mobile application scopes assessed.

Describe the app