Android Testing Specifics

Android Testing Fundamentals #

Android’s open ecosystem creates both opportunities and challenges for testers. The freedom that allows thousands of device manufacturers to customize Android also creates the fragmentation challenge that defines Android QA.

Android Activity Lifecycle #

The Activity lifecycle is the most important concept for Android testers. Activities (screens) go through specific state transitions that frequently cause bugs.

Activity States #

Created → Started → Resumed → Paused → Stopped → Destroyed

Configuration Changes #

When the device configuration changes, Android destroys and recreates the Activity:

• Screen rotation (portrait ↔ landscape)
• Language change
• Font size change
• Dark mode toggle
• Keyboard availability (physical keyboard connected/disconnected)
• Multi-window mode enter/exit

This is the #1 source of Android-specific bugs. Test every screen after:

1. Rotating the device mid-operation (e.g., during form input)
2. Changing font size in system settings
3. Toggling dark mode
4. Entering and exiting split-screen mode

Android Testing Tools #

ADB (Android Debug Bridge) #

ADB is the command-line tool for communicating with Android devices. Essential commands for testers:

# Device management
adb devices                    # List connected devices
adb install app.apk           # Install APK
adb install -r app.apk        # Reinstall (keep data)
adb uninstall com.example.app # Uninstall app

# Screenshots and recording
adb shell screencap /sdcard/screen.png    # Take screenshot
adb pull /sdcard/screen.png ./            # Pull to computer
adb shell screenrecord /sdcard/video.mp4  # Record screen

# App management
adb shell am start -n com.example/.MainActivity  # Launch app
adb shell am force-stop com.example               # Force stop
adb shell pm clear com.example                     # Clear app data

# Debugging
adb logcat                     # View device logs
adb logcat *:E                 # Errors only
adb logcat | grep "MyApp"     # Filter by tag

# Network simulation
adb shell svc wifi disable     # Disable WiFi
adb shell svc data disable     # Disable mobile data

Espresso #

Espresso is Google’s in-process UI testing framework:

// Example Espresso test
@Test
fun testLoginFlow() {
    // Type email
    onView(withId(R.id.emailInput))
        .perform(typeText("user@example.com"), closeSoftKeyboard())

    // Type password
    onView(withId(R.id.passwordInput))
        .perform(typeText("password123"), closeSoftKeyboard())

    // Click sign in
    onView(withId(R.id.signInButton))
        .perform(click())

    // Verify welcome message
    onView(withText("Welcome"))
        .check(matches(isDisplayed()))
}

Advantages: Fast, reliable, synchronizes with UI thread automatically. Limitations: Cannot interact with system UI or other apps.

UI Automator #

UI Automator works outside the app process, enabling system-level interaction:

// Example UI Automator test
@Test
fun testNotificationInteraction() {
    val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())

    // Open notification shade
    device.openNotification()

    // Find and click notification
    val notification = device.findObject(UiSelector().text("New message"))
    notification.click()

    // Verify app opened to correct screen
    onView(withId(R.id.messageView))
        .check(matches(isDisplayed()))
}

Android Profiler #

Android Studio includes profiling tools:

Manufacturer-Specific Testing #

Android manufacturers add custom behaviors that can break apps:

Samsung (One UI) #

• Aggressive battery optimization kills background apps
• Custom notification handling
• Edge panel interactions
• Secure Folder creates a separate app instance

Xiaomi (MIUI) #

• “Autostart” permission required for background processes
• Custom permission manager
• Aggressive RAM management (kills apps faster)
• Custom notification shade behavior

Huawei (EMUI/HarmonyOS) #

• No Google Play Services (uses HMS instead)
• Custom push notification system
• Aggressive power management
• Protected apps list

Android-Specific Test Scenarios #

Back Button and Navigation #

Android’s back button (gesture or hardware) must be tested on every screen:

Test checklist:
□ Back from each screen navigates to expected previous screen
□ Back from first screen exits the app (or shows confirmation)
□ Back during an operation (loading, saving) handles correctly
□ Back after deep link opens correct parent screen
□ Gesture navigation (swipe from edge) works identically to button

Multi-Window and Foldable Testing #

Test scenarios:
□ App in split-screen mode renders correctly
□ App handles window resize smoothly
□ Data is preserved when entering/exiting split-screen
□ App on foldable: folded vs unfolded layout
□ Drag and drop between app and another app in split-screen

Intent and Deep Link Testing #

Test deep links using ADB:

# Test deep link
adb shell am start -a android.intent.action.VIEW   -d "myapp://product/12345" com.example.app

# Test share intent
adb shell am start -a android.intent.action.SEND   --es android.intent.extra.TEXT "Shared content"   -t text/plain com.example.app

Exercise: Android Fragmentation Hunt #

Scenario: Your Android app works perfectly on a Google Pixel 8 (stock Android 14) but users report issues on Samsung and Xiaomi devices.

For each reported issue, identify the likely cause and testing approach:

1. Push notifications do not appear on Xiaomi devices
2. Background music playback stops after 10 minutes on Samsung devices
3. App crashes on rotation while filling out a multi-step form

Pro Tips from Production Experience #

Tip 1: Keep ADB in your PATH and use it daily. Clearing app data, simulating network conditions, and capturing logs through ADB is faster than any GUI tool. Learn 10 essential commands and you will save hours per week.

Tip 2: Test on Samsung first for Android. Samsung represents 30-40% of the Android market in most regions. If it works on Samsung, you have covered your largest Android user segment. Samsung’s One UI modifications are also the most impactful.

Tip 3: Always test rotation with data on screen. Rotate while: filling a form, watching a video, in a chat conversation, during a payment flow. Configuration change bugs are the most common Android-specific defects.

Key Takeaways #

• Android Activity lifecycle and configuration changes are the #1 source of platform-specific bugs
• ADB is an essential tool for Android testers — learn the key commands
• Espresso tests in-process for speed; UI Automator crosses process boundaries for system interaction
• Manufacturer customizations (Samsung, Xiaomi, Huawei) create device-specific bugs that stock Android does not exhibit
• Always test screen rotation, back navigation, and multi-window mode on every screen