1.3The Android Fragmentation Challenge

Android fragmentation is the dominant challenge in mobile testing. Unlike iOS, where Apple controls both hardware and software, Android runs on thousands of devices from hundreds of manufacturers, each with their own customizations.

Android Version Distribution (2026)

Android Version	API Level	Approximate Market Share	Notable Differences
Android 15	35	~20%	Predictive back, per-app language
Android 14	34	~30%	Foreground service types, photo picker
Android 13	33	~20%	Notification permission, themed icons
Android 12	31-32	~15%	Material You, approximate location
Android 11	30	~10%	Scoped storage enforcement, one-time permissions
Android 10	29	~5%	Dark theme, gesture navigation

Notice that the latest version (Android 15) has only about 20% market share. Unlike iOS, where Apple can push updates to most devices simultaneously, Android updates must pass through device manufacturers and carriers, creating long delays. Samsung, Xiaomi, and others must adapt each Android update to their custom UIs, test it on hundreds of device models, and then push it out -- often months after Google's initial release.

The practical implication: You must support at least three major Android versions to cover 70% of Android users. Supporting five versions covers roughly 95%.

Manufacturer Customizations

The stock Android experience that Google designs is not what most users see. Manufacturers layer custom UIs on top of Android, and these customizations can affect your app's behavior in ways that are difficult to predict.

Manufacturer	Custom UI	Global Market Share	Testing Consideration
Samsung (One UI)	~30% of Android devices	Custom gestures, split-screen, edge panels -- test multi-window and edge panel interactions
Xiaomi (MIUI/HyperOS)	~15% global	Aggressive battery optimization kills background apps -- test background task survival
Huawei (EMUI/HarmonyOS)	~5% global (growing in China)	No Google Play Services in newer models -- test without Google APIs, use HMS
Oppo/OnePlus (ColorOS/OxygenOS)	~10% global	Custom notification handling -- test notification delivery edge cases
Google (Pixel)	~3% global	Stock Android, fastest updates -- good baseline reference device

Samsung One UI Deep Dive

Samsung is the single most important Android manufacturer for most apps, with roughly 30% of the global Android market. One UI introduces several features that can break apps that were only tested on stock Android:

• Multi-window mode: Samsung devices support split-screen and pop-up window modes. Your app may be rendered at half the screen width or in a floating window. If your responsive layout only handles full-screen widths, it may break.
• Edge panels: Users can access quick-launch panels from the screen edge. If your app uses edge swipe gestures, they may conflict with Samsung's edge panel gesture.
• Bixby integration: Samsung's voice assistant can interact with your app in ways you may not have anticipated.
• DeX mode: Samsung devices can connect to monitors and run apps in a desktop-like environment. Your app's layout may need to adapt to desktop-class screen sizes.

Xiaomi Battery Optimization

Xiaomi's MIUI and HyperOS are notorious for aggressive battery optimization. They will kill background apps, prevent apps from auto-starting, and block background network requests. If your app relies on:

• Background location tracking
• Background sync or data fetch
• Push notification delivery when the app is not in the foreground
• Scheduled background tasks (WorkManager, AlarmManager)

...you must test on Xiaomi devices specifically, because these features may silently fail on Xiaomi even if they work perfectly on every other Android device.

Huawei and the Google Services Gap

Newer Huawei devices (post-2019) do not include Google Play Services. This means:

• No Google Maps API -- you need to use Huawei Map Kit or another mapping service
• No Firebase Cloud Messaging -- you need to use Huawei Push Kit
• No Google Sign-In -- you need to use Huawei Account Kit
• No Google Play for app distribution -- you need to publish on Huawei AppGallery

If your app has any users in China or if Huawei devices appear in your analytics, you need a dedicated test plan for HMS (Huawei Mobile Services) compatibility.

The WebView Problem

On Android, web content in native apps renders through a WebView component. This WebView is tied to the system Chrome version, which varies by device, Android version, and how recently the user updated Chrome. Different Chrome versions produce different rendering results.

This means a web page that looks perfect in Chrome on your development machine may render differently inside a WebView on a Samsung Galaxy A54 running Android 12 with an older Chrome version.

# Check WebView version programmatically
def get_webview_version(driver):
    """Get the WebView engine version on the current device."""
    info = driver.execute_script("return navigator.userAgent")
    # Parse Chrome version from user agent
    # Example: "Chrome/120.0.6099.230"
    import re
    match = re.search(r'Chrome/(\d+\.\d+\.\d+\.\d+)', info)
    return match.group(1) if match else "unknown"

# In your test setup, log the WebView version
def log_webview_info(driver):
    """Log WebView version for debugging rendering differences."""
    version = get_webview_version(driver)
    device = driver.capabilities.get("deviceName", "unknown")
    os_version = driver.capabilities.get("platformVersion", "unknown")
    print(f"Device: {device}, OS: Android {os_version}, WebView: Chrome/{version}")

Pro Tip: When a bug is reported only on specific Android devices, always check the WebView version first. Many "device-specific" rendering bugs are actually WebView version bugs. You can reproduce them by testing in the same Chrome version on desktop.

Understanding API Level Differences

Each Android version introduces new APIs and changes existing behavior. Here are the changes most likely to affect your testing:

Android 15 (API 35):

• Predictive back gesture: The system shows a preview of the destination when the user starts a back gesture. Your app must handle the onBackPressedDispatcher correctly or the back gesture may show incorrect previews.
• Per-app language preferences: Users can set different languages for different apps. Your app must handle locale changes without restarting.

Android 14 (API 34):

• Foreground service types: Apps must declare the type of each foreground service (location, camera, microphone, etc.). If your app uses foreground services without declaring types, it will crash on Android 14+.
• Photo picker: Android 14 provides a system photo picker that gives apps access to selected photos without requiring full storage permission. Your app should use this instead of requesting broad storage access.

Android 13 (API 33):

• Notification permission: Apps must explicitly request POST_NOTIFICATIONS permission. If your app sends notifications without requesting this permission on Android 13+, the notifications will be silently dropped.

Android 12 (API 31-32):

• Approximate location: Users can grant approximate (city-level) location instead of precise (GPS) location. Your app must handle approximate location gracefully.
• Splash screen API: Android 12 enforces a system splash screen. If your app had a custom splash screen, it may show a double splash screen on Android 12+.

Android 11 (API 30):

• Scoped storage enforcement: Apps can no longer access arbitrary files on the device. If your app reads or writes files outside its own directory, it will fail on Android 11+.
• One-time permissions: Users can grant camera, microphone, and location permissions for a single use. Your app must re-request permission each time.