Testing Different Devices, Android Versions, and Screen Sizes

Course: Android App Development

Topic: Testing Different Devices, Android Versions, and Screen Sizes

Course Link: Android App Development Course

Demo Link: Register for a Course Demo

Website: JustAcademy Official Website

1. Introduction to Android Compatibility Testing

Android applications run on a wide variety of smartphones, tablets, foldable devices, and other supported hardware. These devices differ in screen dimensions, pixel density, Android operating system versions, hardware capabilities, manufacturer customizations, and system settings.

An application that works perfectly on one smartphone may display incorrectly on another device, crash on an older Android version, or behave differently on a tablet. Therefore, developers must test applications across different device configurations before releasing them to users.

Android compatibility testing is the process of verifying that an application functions correctly, displays properly, and provides a consistent user experience across the devices and Android versions it intends to support.

Why Is Compatibility Testing Important?

• Ensures the application works on supported Android versions.
• Identifies layout problems on small and large screens.
• Detects crashes caused by device-specific behavior.
• Verifies that buttons, text fields, images, and navigation remain usable.
• Checks application behavior across different pixel densities.
• Helps identify performance issues on devices with limited memory or processing power.
• Improves accessibility and user experience.
• Reduces negative reviews and application failures after release.

2. Understanding Android Device Fragmentation

Android device fragmentation refers to the wide variety of devices, operating system versions, screen configurations, and hardware capabilities within the Android ecosystem.

Developers cannot assume that every user has the same device specifications. A budget smartphone may have limited memory, while a tablet may offer a large display and support multitasking. Both devices can run Android applications but may present different testing challenges.

Major Factors Contributing to Fragmentation

3. Testing Different Android Versions

Android versions introduce new APIs, security improvements, permission requirements, system behaviors, and interface changes. Applications should be tested against the Android versions they support.

For example, an application developed with a recent Android SDK may use APIs that are unavailable on older devices. Without appropriate compatibility handling, these operations may fail or cause runtime errors.

Important Android Version Concepts

• Minimum SDK version: The lowest Android API level on which the application is intended to install and run.
• Target SDK version: The API level against which the application is designed and tested to account for platform behavior and compatibility changes.
• Compile SDK version: The Android API level used to compile the application.
• API level: A numeric identifier representing a particular Android platform API level.

These settings serve different purposes. A higher compile SDK does not automatically mean that the application requires that same Android version to run.

Example of SDK Configuration

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 23
        targetSdk = 36
    }
}

This Kotlin DSL example illustrates how the settings are configured. The values are examples, not a recommendation for every project. Select SDK versions based on application requirements, supported devices, current platform guidance, and project configuration.

What Should Be Tested Across Android Versions?

• Application installation, launching, and updating.
• Runtime permissions and permission-denied scenarios.
• Notifications and notification permissions where applicable.
• Camera, location, Bluetooth, and other hardware or system APIs used by the app.
• Background work, alarms, and battery-related restrictions.
• File access and media permissions.
• Deep links, sharing, and navigation between applications.
• Application behavior after moving to the background and returning.
• Security and privacy behavior.

4. Backward Compatibility Testing

Backward compatibility testing verifies that an application continues to function on older Android versions that are included in its supported device range.

This is important when developers introduce new APIs or update existing functionality. An API available on a recent Android release may not exist on the minimum supported version.

Example: Checking an Android API Level

if (android.os.Build.VERSION.SDK_INT
        >= android.os.Build.VERSION_CODES.O) {

    // Use functionality supported from Android 8.0 onward.

} else {

    // Provide an alternative for older supported versions.

}

The example demonstrates conditional execution based on the Android API level. In a real application, use the appropriate API-level constant and provide a meaningful fallback when required.

Backward Compatibility Best Practices

• Test the application on its minimum supported Android version.
• Use API-level checks for platform features that are not available everywhere.
• Use AndroidX libraries when they provide appropriate compatibility support.
• Test permissions and storage access on relevant platform versions.
• Avoid assuming that every device supports the same sensors or hardware features.
• Verify that fallback behavior works correctly when a feature is unavailable.

5. Forward Compatibility Testing

Forward compatibility testing evaluates how an application behaves on newer Android versions, especially when platform behavior, privacy requirements, or system interfaces change.

An application may work on the version used during development but encounter problems after a major Android upgrade. Testing against newer platform versions helps developers identify issues before users experience them.

Important Forward Compatibility Checks

• Test the application on newer Android emulator system images.
• Review changes to permissions, background execution, and storage rules.
• Check edge-to-edge layouts and system bar behavior where applicable.
• Verify notifications, navigation, and application lifecycle behavior.
• Review compatibility warnings in Android Studio.
• Check deprecated APIs and update implementations when necessary.

Forward compatibility testing does not guarantee compatibility with every future Android release. It reduces risk by identifying known platform changes and unexpected behavior early.

6. Understanding Screen Sizes and Form Factors

Android applications must support different available display spaces. The usable area depends not only on the physical screen but also on system bars, display scaling, orientation, windowing mode, and other system features.

7. Understanding Screen Resolution and Pixel Density

Screen resolution refers to the number of physical pixels displayed horizontally and vertically. Pixel density describes how densely those pixels are packed into a physical display area.

Android layouts commonly use density-independent pixels (dp) for dimensions and scale-independent pixels (sp) for text sizing.

Important Units

Understanding dp Conversion

A simplified conversion between physical pixels and density-independent pixels is:

px = dp * (densityDpi / 160)

For example, if a layout dimension is 100 dp and the device density is 320 dpi:

px = 100 * (320 / 160)
px = 200 pixels

The same 100 dp layout dimension is intended to occupy a similar density-independent size across devices, even though the physical pixel count changes.

Why Density Testing Matters

• Images should remain sharp across supported densities.
• Buttons should maintain usable touch areas.
• Text should remain readable and correctly positioned.
• Icons should not appear stretched or distorted.
• Layouts should not depend on fixed physical-pixel measurements.

8. Responsive and Adaptive Layout Testing

Responsive and adaptive design techniques help an Android interface adjust to available screen space. Testing verifies that these layouts remain usable across different configurations.

A responsive layout adjusts its dimensions and spacing to available space. An adaptive layout may also change its structure to make better use of a larger display, such as showing a navigation panel beside the main content on a tablet.

Common Layout Problems

• Buttons extending beyond the visible screen.
• Text labels overlapping input fields.
• Images appearing stretched or cropped incorrectly.
• Forms requiring unnecessary horizontal scrolling.
• Large empty spaces on tablet displays.
• Dialogs extending beyond the available window.
• Controls hidden behind system bars or display cutouts.

Recommended Layout Practices

• Prefer flexible constraints and responsive layouts instead of hardcoded screen positions.
• Use dp for layout dimensions and sp for text sizes.
• Use appropriate layout containers for the interface framework.
• Provide alternative layouts when different screen sizes require a different structure.
• Check long text, localization, and larger font settings.
• Use scrolling containers for content that may exceed available height.
• Test split-screen and resized application windows.

9. Creating Android Virtual Devices for Testing

An Android Virtual Device (AVD) is a configuration that defines the characteristics of a virtual Android device running in the Android Emulator. It can represent a particular hardware profile, Android system image, and screen configuration.

AVDs allow developers to test on different device configurations without purchasing every physical device.

Steps to Create an AVD

1. Open Android Studio.
2. Open Device Manager from the available tools or device-management menu.
3. Select the option to create a virtual device.
4. Choose a suitable hardware profile, such as a phone or tablet.
5. Select an Android system image and API level.
6. Download the system image if it is not already installed.
7. Review the device configuration and finish creating the AVD.
8. Start the emulator and run the Android application.
9. Repeat the process for other relevant Android versions and form factors.

Choosing Useful Emulator Configurations

Official reference: Android Emulator documentation.

10. Testing on Real Android Devices

Emulators are useful for broad configuration coverage, but physical-device testing remains important. Real devices can expose differences involving manufacturer customizations, camera hardware, sensors, performance, network connectivity, battery management, and touch behavior.

Steps for Testing on a Physical Device

1. Enable Developer Options on the Android device.
2. Enable USB debugging if using a USB connection.
3. Connect the device to the development computer or configure a supported wireless debugging connection.
4. Accept the debugging authorization prompt when displayed.
5. Select the device in Android Studio.
6. Run the application and execute the planned test scenarios.
7. Inspect logs and investigate any crashes or unexpected behavior.

Test on devices representative of the intended audience. Include different screen sizes and performance levels where possible.

Official reference: Run apps on a hardware device.

11. Using Firebase Test Lab for Device Testing

Firebase Test Lab provides infrastructure for testing Android applications on a range of physical and virtual devices hosted by Google. It can help teams expand device coverage when they cannot access every required device locally.

Benefits

• Runs tests across selected device and Android version combinations.
• Helps identify device-specific crashes and failures.
• Supports automated test execution.
• Can provide logs, screenshots, and other test results depending on the test configuration.
• Supports broader compatibility testing without maintaining a large physical-device collection.

Before using a cloud testing service, review its available device catalog, supported test types, pricing, quotas, and configuration requirements.

Official resource: Firebase Test Lab documentation.

12. Testing Portrait and Landscape Orientations

Android devices can change orientation when users rotate them. Orientation changes may alter available width and height and can cause activity recreation or other configuration changes.

What Should Be Tested?

• Check whether all controls remain visible in portrait and landscape modes.
• Verify that forms and text fields remain usable.
• Confirm that entered data is preserved when appropriate.
• Ensure navigation does not unexpectedly reset.
• Check image and video presentation after rotation.
• Verify that scrolling remains functional.
• Check that the application does not crash during configuration changes.

Example: Testing State Restoration

Suppose a user enters information into a registration form and rotates the device. The test should verify that the entered information is preserved when that is the intended application behavior.

In automated UI tests, developers can use suitable testing APIs to recreate an activity or simulate configuration changes and then verify the resulting interface state.

13. Testing Foldable Devices and Multi-Window Layouts

Foldable devices introduce changing display dimensions and device postures. A user may switch between an outer display and a larger unfolded display. Android applications should respond appropriately to these changes.

Multi-window mode also changes the amount of space available to an application. The app may need to rearrange content when it is displayed beside another application.

Important Test Scenarios

• Open and close the foldable device while the app is active.
• Verify navigation state after display changes.
• Check that forms and lists remain usable after resizing.
• Test dialog placement and pop-up positioning.
• Verify that content is not unnecessarily letterboxed.
• Check whether application state is retained during configuration changes.
• Test transitions between compact and expanded layouts.

Use a compatible foldable emulator or physical device when testing behavior that depends on fold posture or display transitions.

14. Testing Font Scaling and Accessibility Settings

Users may increase font sizes, enable display scaling, use screen readers, or change other accessibility settings. Applications should remain usable under these conditions.

Accessibility Test Checklist

• Increase the system font size and inspect important screens.
• Verify that text does not overlap buttons or other elements.
• Check that important content is not cut off.
• Test touch targets and spacing.
• Verify accessibility labels and descriptions for important controls.
• Use TalkBack or other appropriate accessibility tools to inspect navigation.
• Check sufficient color contrast for text and interactive elements.
• Verify that forms and error messages remain understandable.

Use sp for text sizes and avoid assuming that every user has the default font scale. A visually correct layout at the default setting may become unusable when larger text is enabled.

15. Testing Different Hardware Capabilities

Android devices do not all contain the same hardware. Some devices may lack a particular sensor, camera feature, biometric capability, or other component required by an application feature.

Hardware Compatibility Scenarios

Test optional features gracefully when the relevant hardware is missing. If a feature is essential, make its requirements clear and handle unsupported configurations appropriately.

16. Testing Application Performance Across Devices

Performance testing evaluates how efficiently an application runs on devices with different processing capabilities, memory capacities, storage performance, and network conditions.

Important Performance Measurements

• Startup time: How long the application takes to become usable.
• Responsiveness: Whether interactions happen without noticeable delays.
• Memory usage: Whether the application consumes excessive memory.
• CPU usage: Whether processing tasks create unnecessary load.
• Battery usage: Whether background activity consumes excessive power.
• Network behavior: How the app handles slow connections and request failures.
• Stability: Whether the application crashes or becomes unresponsive.

Performance Testing Tips

• Test on at least one lower-performance device when relevant to the target audience.
• Measure startup and navigation behavior under realistic conditions.
• Test large lists, images, and other resource-intensive screens.
• Inspect memory usage and look for leaks.
• Test background and foreground transitions.
• Use Android Studio profiling tools to investigate bottlenecks.
• Test both normal and poor network conditions when the app uses online services.

17. Automated UI Testing Across Screen Sizes

Manual testing is valuable but can become time-consuming when an application supports many device configurations. Automated UI testing helps verify important interactions and detect regressions after code changes.

Android developers commonly use Espresso for Views-based interfaces and the Jetpack Compose testing APIs for Compose interfaces. Screenshot testing can also be used to detect unexpected visual changes.

Example Espresso Test

The following example assumes that the application's layout contains a button with the resource ID submitButton and a view with the ID successMessage.

import androidx.test.ext.junit.runners.AndroidJUnit4;
import androidx.test.espresso.Espresso.onView;
import androidx.test.espresso.action.ViewActions.click;
import androidx.test.espresso.assertion.ViewAssertions.matches;
import androidx.test.espresso.matcher.ViewMatchers.withId;
import androidx.test.espresso.matcher.ViewMatchers.isDisplayed;

import org.junit.Test;
import org.junit.runner.RunWith;

@RunWith(AndroidJUnit4.class)
public class FormScreenTest {

    @Test
    public void submitButton_displaysSuccessMessage() {
        onView(withId(R.id.submitButton))
            .perform(click());

        onView(withId(R.id.successMessage))
            .check(matches(isDisplayed()));
    }
}

This Java-style example illustrates the test logic. The imports should be written as ordinary Java import declarations without semicolons separating individual imports in any other format. The test also requires compatible AndroidX test dependencies and a configured instrumented test environment.

What Automated UI Tests Can Verify

• Important buttons and views are visible.
• Navigation actions open the expected screens.
• Forms respond correctly to user input.
• Dialogs and menus remain usable.
• Critical content remains available across selected configurations.
• State is restored correctly after supported configuration changes.

Official reference: Android testing documentation.

18. Building a Device Compatibility Test Matrix

A test matrix is a structured list of device configurations and scenarios selected for testing. It helps ensure that important combinations of Android versions, screen sizes, and hardware characteristics are covered.

The matrix should be adjusted according to the app's actual minimum SDK, intended audience, supported form factors, critical features, and known risks. Not every combination requires the same amount of testing.

19. Risk-Based Device Testing Strategy

Testing every possible combination of Android version, device model, screen size, density, and hardware feature may be impractical. Risk-based testing prioritizes the combinations most likely to affect users.

Recommended Testing Priorities

1. Core functionality: Test login, registration, navigation, and other essential workflows.
2. Minimum supported version: Verify that older supported devices can run the app.
3. Common configurations: Cover devices and screen sizes representative of the intended user base.
4. High-risk features: Test camera, location, payment, authentication, and other critical capabilities.
5. Layout extremes: Test compact screens, large displays, landscape orientation, and resizing.
6. Platform changes: Test Android versions with relevant permission or behavior changes.
7. Real-device confirmation: Run important scenarios on representative physical hardware.
8. Regression testing: Repeat critical tests after significant code or dependency changes.

20. Common Compatibility Problems and Solutions

21. Practical Project: Testing a Registration Application

Create a sample Android registration application and test its behavior across different Android versions and screen sizes.

Project Requirements

• Create a registration screen with name, email, and password fields.
• Add input validation and a submit button.
• Display appropriate validation errors for invalid input.
• Ensure the screen remains usable on small displays.
• Test portrait and landscape orientations.
• Verify that larger font settings do not hide important controls.
• Test on the minimum supported Android version and a recent version.
• Verify the expected behavior when the keyboard opens.
• Test navigation and state preservation after configuration changes.
• Record failures, screenshots, and corrective actions.

Expected Deliverables

• A working Android registration application.
• A device compatibility test matrix.
• A record of Android versions and screen configurations tested.
• Test results showing passed and failed scenarios.
• Screenshots of any layout issues discovered.
• A brief report describing fixes and remaining limitations.

22. Interview Questions and Answers

Q1. What is Android compatibility testing?

It is the process of verifying that an Android application works correctly across the Android versions, devices, hardware capabilities, and screen configurations it supports.

Q2. What is Android fragmentation?

Android fragmentation describes the diversity of Android devices, platform versions, screen configurations, and hardware characteristics.

Q3. What is the difference between minSdk and targetSdk?

minSdk defines the minimum Android API level required by the application. targetSdk indicates the API level for which the application is designed to account for platform behavior and compatibility changes.

Q4. Why should an app be tested on different screen sizes?

Different screens provide different amounts of usable space. Testing helps identify clipped content, overlapping controls, layout problems, and usability issues.

Q5. What is an Android Virtual Device?

An AVD is a virtual device configuration used by the Android Emulator to simulate a particular device profile and Android system image.

Q6. Why is physical-device testing necessary?

Physical devices can reveal hardware-specific behavior, manufacturer customizations, performance issues, and sensor or connectivity problems that may not be fully represented by an emulator.

Q7. What is pixel density?

Pixel density describes how many physical pixels fit into a given display area. It affects how physical pixels correspond to density-independent layout dimensions.

Q8. What is the difference between dp and sp?

dp is generally used for layout dimensions, while sp is used for text sizing and supports user font-scaling preferences.

Q9. What is backward compatibility testing?

It verifies that an application continues to work on older Android versions within its supported range.

Q10. What is forward compatibility testing?

It evaluates application behavior on newer platform versions and helps identify problems caused by updated APIs or system behavior.

Q11. What is a device compatibility test matrix?

It is a structured plan listing device configurations, test scenarios, expected results, and outcomes.

Q12. What is Firebase Test Lab?

Firebase Test Lab is a testing service that allows developers to run Android tests on selected physical and virtual devices hosted in Google's testing infrastructure.

Q13. Why is orientation testing important?

Rotation changes the available display dimensions and can trigger configuration changes. Testing ensures the interface remains usable and important state is preserved as intended.

Q14. What is adaptive UI design?

Adaptive UI design adjusts the interface structure to suit the available window size and device form factor.

Q15. How can developers reduce device testing effort?

They can prioritize high-risk scenarios, use emulators and automated tests, select representative devices, and use cloud testing services when appropriate.

23. Quick Revision Checklist

• Understand Android device fragmentation and compatibility.
• Know the difference between compile SDK, minimum SDK, and target SDK.
• Test the minimum supported and recent Android versions.
• Use emulators to test different device profiles.
• Test critical features on physical devices.
• Verify compact, standard, and large screen layouts.
• Check portrait, landscape, and multi-window behavior.
• Test font scaling and accessibility settings.
• Check device-specific hardware and permission behavior.
• Use automated UI and screenshot tests where appropriate.
• Maintain a test matrix and record failures.
• Run regression tests before releasing application updates.

24. Conclusion

Testing different devices, Android versions, and screen sizes is an essential part of developing reliable Android applications. Device fragmentation means that a successful test on one smartphone cannot guarantee correct behavior across all supported configurations.

Developers should combine Android emulators, representative physical devices, automated UI tests, compatibility checks, and performance profiling to identify problems early. Flexible layouts, correct use of dp and sp, careful API-level handling, and appropriate state restoration help applications remain usable across different displays and platform versions.

A structured, risk-based testing strategy makes it easier to maintain application quality while reducing the effort required to cover a diverse Android ecosystem.

25. Additional Learning Resources

• Android screen compatibility guidance
• Testing different screen and window sizes
• Android Emulator documentation
• Testing on physical Android devices
• Firebase Test Lab documentation

Learn Android App Development with JustAcademy

Explore Android development concepts, testing techniques, and practical programming skills through structured learning resources.

Course Link: Android App Development Course

Demo Registration: Register for a Course Demo

Official Website: Visit JustAcademy