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. Then comes 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

Where the scope document stops

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.

An RFP goes out before a supplier is chosen and before the artefact exists, so a question about a mapping file has nobody to answer it yet. That is why a second document is needed instead of a longer first one. The gap between the two is where an Android engagement quietly opens on a call to establish which build this actually is, before any testing starts.

The questions are step one of any competent methodology, asked at kickoff by a tester who then writes the answers into a ticket. This sheet asks them in writing, before the engagement starts. It 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 and attestation. Also 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. Knowing which of them applies tells you 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. 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 is a record of what was handed over and which build the findings describe. That 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