Android Security Testing Checklist: Network Communication, Data Storage, and Packaging

As user privacy concerns grow and more transaction scenarios emerge, security testing has become an indispensable part of the mobile testing process; any exploited security risk can cause significant user loss and damage a developer's brand. This article introduces key automated security scanning checkpoints used in project testing.

Android Network Communication Security

1. Plaintext transmission: Capture HTTP requests (especially during login) to ensure usernames and passwords are not sent in clear text; sensitive data must be encrypted.

2. Weak encryption algorithms: Verify that communication does not rely on weak algorithms such as DES or vulnerable HTTPS implementations, and ensure private keys are not hard‑coded.

3. Random number logic: Avoid predictable random numbers; for example, using SecureRandom(byte[] seed) can be predictable—prefer /dev/urandom or /dev/random as seed sources.

4. HTTP request encryption: Ensure all HTTP interactions include proper encryption and that captured request URLs cannot be replayed in a browser.

Android Application Data Storage Security

1. SharedPreference and database permissions: Do not set global read/write permissions; use MODE_PRIVATE instead of MODE_WORLD_READABLE or MODE_WORLD_WRITEABLE.

2. Clipboard usage: Check that clipboard operations do not expose usernames, passwords, or other sensitive data.

3. Log inspection: Ensure logs are disabled for release builds and that no sensitive information is printed.

4. Screenshot checks: Verify that screens containing credentials cannot be captured via screenshots.

5. Payment‑type keyboards: Confirm that payment keyboards are custom‑drawn and operate in a no‑trace mode.

Android Packaging Checks

1. Packaging process: Use ProGuard (or similar) to obfuscate code, then decompile the APK to confirm obfuscation effectiveness.

2. Anti‑tampering: Apply shell protection or third‑party hardening platforms (e.g., Baidu App Protection) to prevent easy cracking and modification.

3. Native library inspection: Review .so libraries—though implemented in C/C++ for higher security, they can still be reverse‑engineered.

For further reading, see the series on Android component communication security and related articles linked in the original source.