Android Penetration Testing: Tools, Checklist and Scope

Android penetration testing is a manual security assessment of an Android app, the data it leaves on the device, and the backend API it talks to, measured against the OWASP Mobile Application Security Verification Standard (MASVS). The tester decompiles the APK, runs the app on a rooted device, strips protections such as certificate pinning and root detection the way an attacker would, and proves which weaknesses expose user data or let one user act as another.

For what differs from iOS, see iOS vs Android security testing. Invadel tests Android alongside iOS and the backend API in one fixed-price mobile application penetration testing engagement from $6,000 with a free retest; mobile app penetration testing cost shows each tier.

At a glance:

• What is tested: the APK, the running app on a rooted device, its network traffic and the backend API.
• Measured against: OWASP MASVS, using the MASTG v2 tests.
• How long: about a week of testing plus reporting for a small app.
• Price: from $6,000, fixed in writing, with iOS included and a free retest.

What an Android penetration test covers

Layer	What the tester examines	Typical findings
Package (static)	Manifest, decompiled code, resources, native libraries, bundled SDKs	Hardcoded secrets, exported components, debug flags, outdated libraries
Running app (dynamic)	The app on a rooted device, instrumented at runtime	Plaintext tokens, data in logs and backups, components other apps can call
Traffic	Every request, through an intercepting proxy	Cleartext endpoints, trusted user certificates, pinning that is not enforced
Backend API	The endpoints the app calls, replayed and modified by hand	Broken object-level authorization, checks enforced only in the app

The last row matters most: the app ships to the attacker’s phone, but the data lives on the server, so the API is in scope on every engagement (bought on its own, that work is API penetration testing). Our API penetration testing guide covers that half, and the IDOR vulnerability explainer covers the authorization flaw it finds most often.

The standard: MASVS, MASTG and what changed in 2026

The OWASP MASVS defines a secure mobile app in eight control groups: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and PRIVACY. Version 2.1.0, released in January 2024, is current and added PRIVACY. The old L1, L2 and R levels became MAS testing profiles: MAS-L1 is the baseline, MAS-L2 adds defense in depth for sensitive data such as payments or health records, MAS-R covers resistance to reverse engineering and tampering, and a fourth, MAS-P, covers baseline privacy.

MASVS is the mobile counterpart to OWASP ASVS, the verification standard for web applications and APIs. Beside it sits the OWASP MAS Weakness Enumeration (MASWE), a catalog of specific mobile weaknesses grouped under the same MASVS categories, so a finding can carry a MASWE ID next to its MASVS control.

MASTG v2.0.0, released at the end of June 2026, is the first stable release of the rebuilt testing guide, with 193 tests, and the v1 tests are no longer maintained. If a vendor’s report cites only deprecated v1 test IDs, ask whether its methodology has moved to MASTG v2. Google files its own Android security risk guidance under the same MASVS categories, so a MASVS-mapped report matches the fixes your developers look up. The OWASP Mobile Top 10 2024 is the awareness list that sits above both.

Android penetration testing checklist

We test against this checklist; use it to prepare a release or check a vendor’s report.

MASVS group	What gets checked	What a failure looks like	The fix
STORAGE	SharedPreferences, databases, files, caches	A session token in plain text in the app’s private directory	Store less; encrypt the rest with Keystore-held keys
STORAGE	Logs, shared storage, clipboard	Account numbers in logcat, or exports other apps can read	Strip sensitive logging; keep data in internal storage
STORAGE	Backups and device transfer	Auto Backup, on by default, copies the token database to the cloud or a new phone	Exclusion rules in dataExtractionRules (Android 12+) and fullBackupContent (Android 11 and lower)
CRYPTO	Keys, algorithms, randomness	An AES key hardcoded in the APK, ECB mode, predictable random tokens	Non-exportable Keystore keys, hardware-backed where supported; authenticated modes; SecureRandom
AUTH	Server-side enforcement	Admin features unlocked by flipping a client-side flag	Every authorization decision made on the server
AUTH	Biometrics	A fingerprint check that returns a yes or no the app simply trusts	Bind it to a Keystore key through BiometricPrompt with a CryptoObject
NETWORK	Cleartext, trust anchors, custom TLS	Cleartext for a production domain, user CAs trusted, or a TrustManager that accepts anything	System CAs only; no custom certificate validation
NETWORK	Certificate pinning	No backup pin, expired pins, or one host pinned while others are open	Pin public keys with a backup; never treat pinning as authorization
PLATFORM	Exported components and content providers	An exported activity that opens an authenticated screen; a provider that returns other users’ records	android:exported="false" by default; signature permissions for the rest
PLATFORM	Intents, PendingIntents, deep links	Intent redirection into private components; a deep link that starts a payment without re-authentication	Explicit intents, immutable PendingIntents, verified App Links, re-authentication
PLATFORM	WebViews	A JavaScript bridge (addJavascriptInterface) reachable by content an attacker can influence	Load only your own HTTPS content; remove bridges before loading anything untrusted
PLATFORM	Overlays and task hijacking	Tapjacking, or StrandHogg-style hijacking of a login screen	Filter obscured touches on sensitive views; Google advises a minSdkVersion of 30 against task hijacking
CODE	Build hygiene, SDKs, native code	Debug flags or test endpoints in a shipped build; a vulnerable SDK version; unsafe parsing in a JNI library	Release-only configuration; an SDK inventory with versions; updates; fuzzing
CODE	Dynamic code, archives, deserialization	Downloaded code in a writable path; archive entries containing ../	Avoid loading code at runtime; validate extraction paths
RESILIENCE	Root, hook and tamper detection	Detection removed at runtime and the server never notices	Integrity verdicts verified on the server; R8 shrinking and obfuscation
PRIVACY	SDK data flows	An SDK sending location that the Play Data safety form does not declare	Inventory SDK traffic; collect less; keep the declaration accurate

Google Play rejects uploads marked debuggable, but test endpoints, verbose logging and vulnerable SDKs still reach store builds; MDM and pre-release builds skip even that check.

Android security defaults by API level

Many Android protections apply only when the app targets a given API level (targetSdkVersion) and runs on that version or later. minSdkVersion sets the oldest, weakest platform the app still supports.

Version	What changed	What we check
Android 7.0 (API 24)	User-added CAs no longer trusted by default (network security config)	Configs that add the user store back in release builds
Android 9 (API 28)	Cleartext HTTP disabled by default	Every cleartext opt-in, especially for production domains
Android 12 (API 31)	Explicit android:exported for components with intent filters; PendingIntent mutability required; adb backup excludes app data (Android 12 changes)	Which components are exported on purpose; backup rules for device transfer
Android 14 (API 34)	Implicit intents reach only exported components; dynamically loaded code must be read-only; zip entries containing .. are rejected (Android 14 changes)	The same flaws on supported devices older than Android 14
Android 16 (API 36)	Opt-in strict intent matching through intentMatchingFlags, not a new default (Android 16 changes)	Whether the app opts in
Android 17 (API 37)	For apps targeting API 37: Certificate Transparency, opt-in only on Android 16, is on by default; natively loaded libraries must be read-only; local network access needs the new ACCESS_LOCAL_NETWORK runtime permission (Android 17 changes)	Any CT opt-outs, and whether they are justified

From August 31, 2026, Google Play requires new apps and updates to target Android 16 (API level 36); extensions ended on November 1, 2026, so a current Play build carries the newer defaults. Two gaps remain: apps permanently private to one organization are exempt, and an app with a minSdkVersion of 26 still installs on Android 8, where none of the Android 12 or 14 protections exist. We judge platform-dependent findings against the oldest version you support.

How an Android app penetration test runs

1. Scope. Targets, accounts, environments, rules of engagement and the testing profile are agreed in writing.
2. Static analysis. The manifest comes first (exported components, permissions, backup and debug flags, the network security config, SDK levels), then the decompiled code and resources for secrets, endpoints, cryptography and third-party SDKs.
3. Dynamic analysis. Every feature is exercised on a rooted device while the tester inspects disk, logs, backups and clipboard, and calls exported components and deep links from a second app, as malware on the same phone would.
4. Traffic and resilience. Traffic runs through an intercepting proxy, with pinning and root detection removed at runtime; the report states whether each control slowed testing and whether anything relied on it holding. For banking, payments and gaming apps, repackaging and hooking resistance are tested too.
5. Backend API. Two accounts per role: object-level and function-level authorization, token revocation, rate limits, and fields the server should never accept from a client.
6. Report and retest. Each finding carries its MASVS mapping, a CVSS rating, reproduction steps and the fix. Criticals are shared the moment they are confirmed, and the free retest verifies each fix.

Android application security testing: scanner, pentest, or both?

An automated APK scan inventories manifest flags, embedded strings and SDK versions, and static analysis in CI catches insecure code before release. Neither proves a finding is reachable, logs in as two users, or tests backend authorization. Scan every build, and put a person on the app at least annually and after major changes to authentication, payments or data handling. SAST vs DAST vs IAST compares the automated options, and a source code review adds the code-level view.

Android pentesting tools, and what their use reveals

Tool	What it is	If it produced a finding, it means
adb	Android Debug Bridge, the standard command-line link between a computer and a device	Data was readable from logs, backups or app storage with stock developer tooling, no exploit needed
jadx	Decompiler that turns Android bytecode back into readable source	Kotlin and Java logic, endpoints and embedded secrets are readable by anyone holding the APK
apktool	Decodes the manifest and resources, and rebuilds packages	The app can be modified and re-signed, so the server should check app integrity
MobSF	Automated static and dynamic analysis framework	Pattern-level issues a tester then confirms or discards by hand
Frida and objection	Runtime instrumentation; objection packages common Frida tasks	A client-side check was switched off at runtime, so anything relying on it alone is exposed
drozer	Framework for testing Android inter-process communication	Exported components or content providers that another app can call
Burp Suite	Intercepting proxy	The API accepts modified or replayed requests and trusts the client
Ghidra	Reverse engineering framework for native code	Secrets or logic moved into native libraries are still recoverable

None of these is exotic: an attacker has the same toolkit and unlimited time with your APK.

Cross-platform apps shift the work: Flutter compiles app logic into a native library and ignores the device proxy, and React Native ships it as a JavaScript or Hermes bundle, so the tester reads those instead of decompiled Java.

How your backend can detect a tampered client

Root detection and pinning run on a device the attacker controls, so assume they will be bypassed. The durable control is on the server: the app requests a signed integrity verdict, and your backend has Google Play’s server decrypt and verify it before trusting a sensitive request. For Play-distributed apps, the Play Integrity API verdicts are the main signal.

Verdict field	Value to watch	What it means	Server response
requestDetails	Hash or nonce mismatch, stale timestamp	The token was replayed or minted for another request	Reject
appRecognitionVerdict	UNRECOGNIZED_VERSION	Certificate or package name does not match Play’s records: a repackaged or re-signed build	Block sensitive actions
deviceRecognitionVerdict	Empty	Signs of attack such as API hooking, a rooted device, or an emulator that fails integrity checks	Step up verification or limit features
deviceRecognitionVerdict (optional label)	No MEETS_STRONG_INTEGRITY on Android 13+	A partition lacks a security update from the past year, or device integrity fails; also omitted for unlicensed apps	Lower trust for high-value actions
appLicensingVerdict	UNLICENSED	Not installed or updated from Google Play, for example sideloaded	Prompt a reinstall; limit access
appAccessRiskVerdict	UNKNOWN_CAPTURING, UNKNOWN_CONTROLLING, UNKNOWN_OVERLAYS	Non-Play apps are running that could read the screen, control input or draw overlays	Challenge before payments or credential entry
recentDeviceActivity	LEVEL_4	More than 50 standard token requests from your app on one device in the past hour	Rate-limit; investigate automation

We test the server side: whether sensitive actions require a verdict, whether the server rather than the app evaluates it, whether verdicts can be replayed, and what the API does with a bad one. An app an MDM installs outside managed Google Play cannot rely on Play’s app recognition or licensing verdicts (the device verdict still works), so hardware-backed key attestation and API telemetry fill the gap.

Scoping an Android penetration test

• Builds. A staging or debug build speeds testing; also send the release-configured build, because debug flags and network overrides differ. For an App Bundle, send the bundle or a universal APK so no module or native library is missed.
• Accounts. Two test accounts per role, so cross-user access is proven rather than assumed.
• Backend. A staging environment and API documentation or a Postman collection.
• Assumptions. The controls you believe are in place (pinning, root detection, Play Integrity, biometric binding), so the report confirms or contradicts each.
• Third parties. Payment, identity and analytics providers are out of scope unless they authorize testing; the report covers how your app uses them.

Planning an App Defense Alliance MASA assessment (a baseline check against MASVS, run by Google-authorized labs)? A penetration test beforehand finds issues first and goes deeper into the backend.

What an Android penetration test costs

Both platforms are included at the same starting price; if you only ship on Android, we scope the test to it.

Tier	Typical scope	From
Small	A handful of screens, one user role, a simple backend	$6,000
Medium	Several roles, offline storage, payments or messaging, a larger API	$8,500
Large	Many screens and roles, SDK integrations, anti-tampering, an extensive backend	$14,000+

Your fixed price comes back in writing from your scope details, with no sales call. The free retest runs against your fixed build and the API behind it, so a fix made only in the app, with the endpoint still open, does not pass. An attestation letter, executive and technical reports and the findings platform are included, and we onboard you within 24 hours of the signed proposal. Findings map to the controls your auditor examines for PCI DSS, HIPAA or SOC 2. See the sample report, or price several tests in the cost calculator.

Frequently asked questions

Do you need a rooted device for Android penetration testing? For full coverage, yes. Static analysis and API testing work without one, but inspecting private storage and removing runtime checks need root access. We test on real, rooted devices that we provide.

Is it legal to pentest an Android app? Only with written authorization from whoever owns the app and its backend. Testing without permission can violate laws such as the federal Computer Fraud and Abuse Act. Engagements start with signed rules of engagement naming what is in scope.

Is an automated APK scan enough? Not for an audit or a customer security review. A scan is a useful inventory on every build, but cross-user access and server-side checks only show up when a person tests the running app and its API.

How long does an Android penetration test take? About a week of testing plus reporting for a small app, longer for feature-rich apps with large backends. Testing usually starts within a week of scoping.

Can you test an Android app that is not on Google Play? Yes. MDM-distributed, sideloaded and pre-release builds are tested the same way from the build you send, and the report notes which Play-only protections do not apply.

Does an Android penetration test satisfy PCI DSS or SOC 2 for a mobile app? It supplies the testing evidence; neither framework certifies an app by itself. Where the app is inside your PCI DSS scope, the test counts toward the application-layer testing in Requirement 11.4, and your assessor decides the scope. SOC 2 names no specific test, and auditors accept a penetration test of the in-scope system as evidence. The report maps each finding to the relevant controls and comes with an attestation letter.

Do you test Flutter and React Native Android apps? Yes. The scope is the same and the method changes: Flutter logic sits in a native library and its traffic ignores the device proxy, and React Native ships a JavaScript or Hermes bundle, so the tester reads and instruments those instead of decompiled Java. Storage, platform and backend API checks are unchanged.

How much does Android app penetration testing cost? From $6,000 at Invadel, with iOS included at no surcharge and the backend API in scope, fixed in writing with a free retest.

The short version

Android penetration testing reads the APK, runs the app on a rooted device, intercepts its traffic and attacks the API behind it, measured against OWASP MASVS and the MASTG v2 tests. The worst findings sit in backend authorization and in what the app exposes to other apps, and the defenses that hold live on the server. See how our mobile application penetration testing works and what it costs, or scope your Android test for a written fixed price the same day.