How to Check an APK or AAB Before It Goes Live Under Your Name
Never publish an app file you haven't inspected. A practical checklist to verify an APK or AAB — permissions, signing, SDKs — before it ships under your account.
Whether you're renting a console, using a publisher, or just shipping a build someone else compiled, one rule protects you above all: never publish an app file you haven't inspected. Your account, and often your verified identity, is attached to whatever goes live. Here's a practical, no-jargon checklist to verify an APK or AAB first.
Why this matters
The moment an app is published under an account, that account is responsible for it. If the build quietly contains spyware, ad fraud, or permissions it doesn't need, the consequences — suspension, removal, worse — land on the publisher of record. Inspecting the file is how you make sure the thing carrying your name is the thing you agreed to.
The verification checklist
- Install it on a real device first. Sideload the APK on a spare or test phone. Does it do what it claims? Watch for surprise redirects, pop-ups, or requests that don't fit.
- Read the permissions. A wallpaper app asking for SMS, contacts and accessibility access is a red flag. Permissions should match the app's actual job.
- Decode the manifest. Use
aapt dump badging app.apkorapkanalyzerto read the package name, version, and declared permissions without guessing. - Look at the code. Tools like
apktoolandjadxunpack an APK (it's just a zip) so you can scan for hidden network calls, hard-coded URLs, and unexpected SDKs. - Verify the signature. Run
apksigner verify --print-certs app.apkand confirm the signing certificate is the one you expect — not a stranger's. - Scan it. Upload to a reputable multi-engine scanner to catch known-malicious patterns. Treat it like checking whether a link is safe before you click.
An APK is a sealed box with your name about to go on the label. Open it, look inside, and only then sign for it.
AAB vs APK
Google Play now takes the Android App Bundle (AAB) for publishing, while the APK is the installable file you can test directly. Ask for both: the AAB is what ships, and the APK is what you can sideload and inspect today. They should correspond to the same app and version.
If someone else is publishing for you
A reputable publisher expects this and will hand you the exact build on request — that transparency is part of how the live-and-transfer model stays trustworthy. If a provider refuses to show you the build that goes out under your account, that refusal is all the information you need. The same instinct that helps you avoid malware applies here: don't run — or publish — what you can't see.
Key takeaways
- Your account owns whatever you publish — inspect every build first.
- Install on a test device and read the permissions against what the app claims to do.
- Decode the manifest and code with aapt, apktool or jadx; verify the signature with apksigner.
- Ask for both the AAB (what ships) and the APK (what you can test).
- Any publisher worth using will show you the exact build on request.
Frequently asked questions
Can I open an APK to see what's inside?
Yes. An APK is a zip archive. Tools like apktool or jadx can decode the manifest and code so you can review permissions, the package name and bundled libraries before you trust it.
What should make me reject a build?
Permissions that don't match what the app does, a package name you don't recognise, a signing certificate that wasn't agreed, hidden network calls, or sketchy ad and analytics SDKs. When the build doesn't match the description, walk away.
Do I need to be a developer to check an app?
Basic checks are easy: install it on a spare device, read the permissions, and run the file through a reputable online scanner. Deeper decoding helps, but even the simple steps catch most obvious problems.