Mastering Android Testing: Architecture, ADB Commands, and a Complete Test Checklist

1. Android System Overview

1.1 Android System Architecture

Application layer

Application framework layer

System runtime library layer

System kernel layer

Four major components and APIs

1.2 Android Permission System

Android is a multi‑user Linux OS; each app runs under a separate user in its own sandbox, with file permissions isolating apps and each app having its own virtual machine.

1.3 Understanding ADB and Android Communication

ADB (Android Debug Bridge) is a client‑server command‑line tool consisting of:

ADB client – runs on the developer’s computer

ADB server – daemon that manages communication with devices

ADB daemon – runs on the device or emulator

2. Android App Test Flowchart

3. Android App Test Items

3.1 UI Testing

Static UI elements such as buttons, dialogs, lists, windows

Dynamic UI elements such as content lists and prompts

UI related to system integration (status bar, lock‑screen prompts, app display in settings, etc.)

Interaction between the app and launcher, other system apps, or the system itself

3.2 Compatibility Testing

Different device brands

Various Android versions and OS releases

Screen resolutions and sizes (mainstream resolutions)

Network conditions (Wi‑Fi, mobile, weak network, no network, private networks)

Compatibility with local software

Hardware peripheral compatibility (headset, Bluetooth, NFC, camera, wearables, etc.)

3.3 Install/Uninstall & OTA Upgrade Testing

Normal installation, icon display, version number verification

Over‑install scenarios (same version, higher, lower)

Data retention after upgrade

Proper uninstallation and data removal

Abnormal conditions during install/uninstall (power loss, insufficient storage)

Support for canceling the operation

Installation methods: manual, adb command, third‑party tools

Effect of factory reset on app/data

Permission checks for install/uninstall, including root vs. non‑root

3.4 Online OTA Upgrade Testing (FOTA)

Update prompts when a new version is available

Optional upgrade flow for non‑forced updates

Forced upgrade behavior and app exit handling

In‑place update without deleting the existing app

Recovery from network or power interruption during download

Behavior after factory reset

Resume or re‑prompt after deleting the downloaded package

Full‑device FOTA vs. independent app FOTA strategies

3.5 Interaction Testing

Foreground/background switching

Process killing

Lock screen handling

Long‑term standby

Interrupt handling

Shake, flip gestures

Power on/off and reboot

3.6 Concurrency Testing

Simultaneous app usage with messaging apps (WeChat, QQ, video calls)

Impact on location accuracy while using the app

Incoming calls/SMS during app usage

Media playback (music, video) while the app runs

Network traffic concurrency without affecting app performance

Power consumption and data usage under concurrent scenarios

3.7 Client Database Testing

CRUD operations verification

Testing with empty data sets

Automatic data retrieval from client storage

Server‑client synchronization after data changes

Effect of missing root permissions on critical system files

3.8 Interface Testing

Business logic functional testing

Boundary value analysis

Parameter combination testing

Exception handling testing

3.9 Performance Testing

Power consumption per unit time (software tools, hardware meters, standby strategies)

Network traffic per unit time (mobile data, Wi‑Fi, throughput)

Resource utilization (CPU, memory impact)

Business response time

Frame rate (smoothness)

Stability and reliability/recoverability

Stress testing

3.10 Security Testing

Decompilation and code obfuscation checks

App signature, key, encryption validation

Integrity verification

Sensitive information exposure

Soft keyboard hijacking

Root permission checks

Component security (Activity, Service, ContentProvider, Broadcast)

Server‑side API testing

Attack simulations: SQL injection, XSS, CSRF, privilege escalation

Security scanning tools

Environment setup (public network, data storage)

Data transmission and account security

Code backdoor detection

Business‑level security

3.11 Other Tests

Authentication testing

Billing testing

App store release testing

Upload/download testing

Simulated user experience testing (internal staff)

Real user experience testing (external users)

4. Tool Techniques (Third‑Party)

4.1 Common ADB Monitoring Commands

1.4.1 View app launch time

adb -s <em>device_id</em> shell am start -W -n com.example.app/.MainActivity

1.4.2 Get battery level and temperature adb shell dumpsys battery 1.4.3 Find most resource‑intensive app

adb -s <em>device_id</em> shell top -m 6 -n l -s cpu

1.4.4 Get memory usage

adb -s <em>device_id</em> shell dumpsys meminfo com.example.app

1.4.5 Get CPU usage of a specific app

adb -s <em>device_id</em> shell dumpsys cpuinfo com.example.app

1.4.6 Get PID of a specific app

adb shell "ps | grep com.example.app"

4.2 Required Features

Real‑time CPU usage of the target app and overall CPU load

Current memory usage and percentage, plus remaining memory

Network traffic consumed from app start to now

Write test data to a CSV file stored on /storage/sdcard0 and optionally email it

Optional floating window to display live performance metrics

Floating window controls to quickly toggle Wi‑Fi

4.3 Implementation Principles

4.3.1 CPU monitoring reads /proc/stat for overall usage and /proc/cpuinfo for CPU details; per‑process data is obtained from /proc/ PID /stat via tools like Emmagee.

4.3.2 Memory monitoring obtains the target app’s PID and reads its memory info from /proc/meminfo.

4.3.3 Traffic monitoring uses /proc/net/dev for total traffic and /proc/uid_stat/ UID /tcp_rcv & tcp_send for per‑app download/upload, calculating differences over time.

4.3.4 Power monitoring listens to battery manager broadcast events to capture level, voltage, and temperature.

4.3.5 Launch time monitoring triggers a thread in onStartCommand() that posts a delayed task to collect data and extracts start time from logcat via ActivityManager.

4.3.6 Frame rate (FPS) is calculated by querying the SurfaceFlinger service for frame timestamps.