How to Test Image Upload on Android (Complete Guide)

Image upload is a feature that touches many layers of an Android app: UI, storage, networking, permissions, and backend services. When it fails, users cannot share photos, profile pictures, or documen

Why Image Upload Testing Is Critical

Image upload is a feature that touches many layers of an Android app: UI, storage, networking, permissions, and backend services. When it fails, users cannot share photos, profile pictures, or documents, which often blocks core flows such as account creation, messaging, or e‑commerce checkout. A broken upload can also expose security holes—malicious files may be accepted, or sensitive data may be leaked through improper handling of EXIF metadata. Because the feature relies on external factors (device camera quality, available storage, network latency, MIME type detection), defects frequently appear only after release, under real‑world conditions that unit tests never see. Therefore a disciplined testing strategy that combines manual exploration, automated scripts, and autonomous persona‑driven analysis is essential to catch regressions before they impact users.

Common Ways Image Upload Breaks in Production

Understanding typical failure modes helps focus test effort. The list below aggregates issues observed across multiple Android apps in the wild.

Each of these categories can be exercised with a combination of manual checks, automated assertions, and exploratory runs that simulate varied user behaviors.

Comprehensive Test Matrix for Image Upload

The matrix below organizes test scenarios by dimension (happy path, error paths, edge cases, accessibility, security) and indicates the recommended verification method (M = manual, A = automated, P = persona‑driven autonomous). Use it as a baseline; add project‑specific rows as needed.

How to read the matrix

• Happy path (H) verifies core functionality.
• Error paths (E) cover client‑side validation and graceful degradation.
• Accessibility (A) ensures compliance with WCAG 2.1 AA as interpreted for Android.
• Security/Privacy (S) targets malicious input and data leakage.
• Locale/Runtime (L/R) capture configuration changes that often escape unit tests.

You can prioritize rows based on risk: H1/H2, E1/E2/E5/E6, A1‑A3, S1‑S2 are usually high‑impact.

Manual Testing Step‑by‑Step Guide

Manual exploration remains valuable for discovering UX friction, permission flows, and device‑specific quirks. Follow this procedure on a physical device or emulator with Google Play services installed.

1. Prepare the test environment

• Install the app under test (APK) via adb install -r app.apk.
• Grant android.permission.READ_EXTERNAL_STORAGE and android.permission.CAMERA manually via Settings → Apps → [YourApp] → Permissions, then revoke them to test the denial flow.
• Clear app data (adb shell pm clear com.example.app) to start from a clean state.
• Connect to a Wi‑Fi network; optionally enable network throttling via Android Studio’s Profiler → Network → Advanced → Set latency 150 ms, bandwidth 1 Mbps to simulate 3G.

1. Happy path via gallery

• Launch the app, navigate to the screen containing the image upload button.
• Tap the button; the system picker should appear.
• Choose a JPEG image (≥2 MB) from the gallery.
• Confirm any cropping or rotation dialogs.
• Observe a progress indicator, then verify that the uploaded image appears in the UI (e.g., as a profile picture).
• Check Logcat for network calls: adb logcat | grep -i "upload" and confirm a 200 response.

1. Happy path via camera

• Repeat step 2 but select “Take photo” in the picker.
• Frame a scene, capture, accept the photo.
• Verify that the image orientation matches the device’s native orientation (use an EXIF viewer on the pulled file: adb pull /sdcard/Pictures/... . && exiftool image.jpg).

1. Permission denial flow

• Before launching the picker, go to Settings → Apps → [YourApp] → Permissions and set both storage and camera to Deny.
• Return to the app and tap the upload button.
• Expect a rationale dialog (if you implemented one) or a toast explaining why the picker cannot open.
• The button should remain disabled or show an error; the app must not crash.

1. Permission revocation at runtime

• Grant both permissions, then start an upload (pick an image).
• While the picker is open, quickly navigate to Settings → Apps → [YourApp] → Permissions and toggle storage to Deny.
• Return to the app; the picker should close, and the app should display an error or allow the user to retry after re‑granting permission.

1. Size limit enforcement

• Use a file manager to create a dummy 12 MB file: dd if=/dev/zero of=/sdcard/large.jpg bs=1M count=12.
• Attempt to upload this file.
• The app should show a client‑side size‑exceeded toast before any network request appears in Logcat.

1. Network failure simulation

• Start an upload with a medium‑sized image (~3 MB).
• After a few seconds, enable Airplane mode or disable Wi‑Fi via quick settings.
• Observe that the upload stops, a retry button appears, and no partial file remains in /cache or /files.

1. Accessibility checks

• Enable TalkBack (Settings → Accessibility → TalkBack).
• Swipe to reach the upload button; listen for the announcement.
• Double‑tap to activate; ensure the picker opens and that focus moves appropriately inside the picker.
• Disable TalkBack and verify that color contrast meets 4.5:1 using the Android Studio Layout Inspector’s “Contrast” tool.

1. Security probing

• Rename a harmless APK to test.jpg and try to upload it via the picker (some file managers allow extension change).
• The backend should reject it; the app should show an error like “Invalid file type”.
• Use exiftool to embed a GPS tag in a JPEG and verify that the uploaded copy does not contain the tag (if your policy strips location).

1. Cleanup

• After each test cycle, clear app data to avoid state leakage: adb shell pm clear com.example.app.
• Remove any test files you created on external storage: adb shell rm /sdcard/large.jpg.

Manual testing shines when you need to observe subtle UI glitches, verify that error messages are user‑friendly, or confirm that the app behaves correctly under interruptions (incoming call, screen rotation). Combine it with automated checks for regression safety.

Automated Testing on Android: Tools and Techniques

Automated tests give fast feedback on regressions and can be run on every commit. For image upload, you need to interact with the system picker, handle permissions, and assert network behavior. Below are the most effective Android‑specific approaches, each with a ready‑to‑run snippet.

1. Espresso with IdlingResource for Network Calls

Espresso runs in‑process UI tests and is ideal for validating UI state and simple permission flows. Use an IdlingResource that monitors OkHttp or Volley callbacks to know when an upload finishes.

// UploadIdlingResource.kt
class UploadIdlingResource(
    private val callback: () -> Unit
) : IdlingResource {
    private var resourceCallback: IdlingResource.ResourceCallback? = null
    private var idle = true

    init {
        // Assume you have a singleton UploadManager exposing a LiveData<UploadState>
        UploadManager.getInstance().uploadState.observeForever { state ->
            if (state == UploadState.IN_PROGRESS) {
                idle = false
            } else if (state == UploadState.COMPLETED || state == UploadState.FAILED) {
                idle = true
                resourceCallback?.onTransitionToIdle()
            }
        }
    }

    override fun getName() = "UploadIdlingResource"
    override fun isIdleNow() = idle
    override fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback) {
        this.resourceCallback = callback
    }
}

// ImageUploadTest.kt
@RunWith(AndroidJUnit4::class)
class ImageUploadTest {

    @get:Rule
    val grantPermissionRule = GrantPermissionRule(
        Manifest.permission.READ_EXTERNAL_STORAGE,
        Manifest.permission.CAMERA
    )

    private lateinit var idlingResource: UploadIdlingResource

    @Before
    fun registerIdling() {
        idlingResource = UploadIdlingResource { }
        IdlingRegistry.getInstance().register(idlingResource)
    }

    @After
    fun unregisterIdling() {
        IdlingRegistry.getInstance().unregister(idlingResource)
    }

    @Test
    fun happyPath_galleryUpload_showsImage() {
        // Launch the activity
        val activityScenario = ActivityScenario.launch(MainActivity::class.java)

        // Click upload button
        onView(withId(R.id.btn_upload_image)).perform(click())

        // System picker appears – use UiDevice to interact because Espresso cannot
        // access system dialogs directly
        val uiDevice = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())
        uiDevice.wait(Until.hasObject(By.text("Gallery")), 5000)
        uiDevice.findObject(By.text("Gallery")).click()

        // Choose first image in grid
        uiDevice.wait(Until.hasObject(By.className("android.widget.ImageView")), 5000)
        uiDevice.findObject(By.className("android.widget.ImageView")).click()

        // Confirm crop if needed
        uiDevice.wait(Until.hasObject(By.text("Save")), 5000)
        uiDevice.findObject(By.text("Save")).click()

        // Wait for upload to complete via IdlingResource (implicitly handled)
        onView(withId(R.id.image_preview)).check(matches(isDisplayed()))
        onView(withId(R.id.image_preview)).check(matches(withDrawable(R.drawable.expected_image))) // custom matcher
    }
}

Why this works

• The GrantPermissionRule automatically grants runtime permissions before each test.
• UiDevice is needed to interact with the system picker, which runs outside your app’s process.
• The UploadIdlingResource ensures Espresso waits for the network call to finish before asserting UI changes.

2. UIAutomator for Robust System Dialog Interaction

UIAutomator can launch arbitrary activities and is better suited for cross‑app flows like picking images from DocumentsUI or handling the camera intent.

// ImageUploadUiAutomatorTest.java
@RunWith(AndroidJUnit4.class)
public class ImageUploadUiAutomatorTest {

    private UiDevice device;

    @Before
    public void setUp() {
        device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation());
        // Clear app data to start fresh
        Context ctx = InstrumentationRegistry.getTargetContext();
        ctx.deleteDatabase("app.db");
        ShellUtils.runCommand("pm clear com.example.app");
    }

    @Test
    public void testCameraUpload_orientationCorrect() throws Exception {
        // Launch main activity
        Intent intent = new Intent();
        intent.setClassName("com.example.app", "com.example.app.MainActivity");
        device.executeShellCommand("am start -n " + intent.getComponent().flattenToString());

        // Click upload button
        device.findObject(new UiSelector().resourceId("com.example.app:id/btn_upload_image"))
                .click()
                .waitForExists(2000);

        // Choose "Take photo"
        device.findObject(new UiSelector().text("Take photo")).click();

        // Handle camera app – set a simple scene (e.g., rotate device to landscape)
        device.setOrientationLeft(); // simulate landscape
        Thread.sleep(1500); // give camera time to adjust
        device.pressKeyCode(KeyEvent.KEYCODE_CAMERA); // capture

        // Confirm
        device.findObject(new UiSelector().text("OK")).click();

        // Wait for upload completion (poll a TextView that shows "Uploaded")
        UiObject2 status = device.wait(Until.findObject(
                new UiSelector().resourceId("com.example.app:id/tv_upload_status")), 10000);
        assertEquals("Uploaded", status.getText());

        // Verify orientation: pull the uploaded file and check EXIF
        String path = "/sdcard/Pictures/SusaTest/uploaded.jpg";
        device.executeShellCommand("cp " + path + " /data/local/tmp/");
        PullFile pull = new PullFile("/data/local/tmp/uploaded.jpg", new File(Environment.getExternalStorageDirectory(),
                "uploaded_check.jpg"));
        pull.start();
        pull.join(5000);
        ExifInterface exif = new ExifInterface(new File(Environment.getExternalStorageDirectory(),
                "uploaded_check.jpg").getAbsolutePath());
        int orientation = exif.getAttributeInt(
                ExifInterface.TAG_ORIENTATION,
                ExifInterface.ORIENTATION_NORMAL);
        assertTrue(orientation == ExifInterface.ORIENTATION_ROTATE_90 ||
                orientation == ExifInterface.ORIENTATION_ROTATE_270);
    }
}

Key points

• UiDevice.setOrientationLeft() simulates a device rotation to test how the camera handles orientation metadata.
• Pulling the uploaded file lets you inspect EXIF or verify that the file is not corrupted.
• UIAutomator works well for testing inter‑app interactions (camera, file picker) that Espresso cannot reach.

3. Appium for Cross‑Platform Scripts (Optional)

If you maintain both Android and iOS test suites, Appium provides a unified JSON Wire Protocol. The same test can be written in JavaScript, Python, or Java.

# test_image_upload_appium.py
import time
from appium import webdriver
from appium.webdriver.common.mobileby import MobileBy
from appium.webdriver.common.touch_action import TouchAction

desired_caps = {
    "platformName": "Android",
    "deviceName": "Pixel_4_API_33",
    "appPackage": "com.example.app",
    "appActivity": ".MainActivity",
    "automationName": "UiAutomator2",
    "noReset": True,
}

driver = webdriver.Remote("http://localhost:4723/wd/hub", desired_caps)

def test_upload_from_gallery():
    driver.find_element(MobileBy.ID, "btn_upload_image").click()
    time.sleep(1)

    # Switch to native picker context
    driver.start_activity("com.android.documentsui", ".FilesActivity")
    time.sleep(1)

    # Navigate to Pictures folder and select first image
    driver.find_element(MobileBy.ANDROID_UIAUTOMATOR,
        'new UiSelector().resourceId("com.android.documentsui:id/icon_thumb")').click()
    time.sleep(1)

    driver.find_element(MobileBy.ANDROID_UIAUTOMATOR,
        'new UiSelector().description("Done")').click()

    # Wait for upload completion
    WebDriverWait(driver, 20).until(
        EC.visibility_of_element_located((MobileBy.ID, "tv_upload_status"))
    )
    assert driver.find_element(MobileBy.ID, "tv_upload_status").text == "Uploaded"

    driver.quit()

Appium shines when you need to run the same script on multiple device farms or integrate with CI pipelines that already host an Appium server.

4. Backend Contract Tests with MockWebServer

To avoid flaky reliance on a real server, enqueue expected responses and verify request bodies (including multipart boundaries). This also lets you assert that the client sends correct MIME types and headers.

// UploadContractTest.kt
@MediumTest
@RunWith(AndroidJUnit4::class)
class UploadContractTest {

    private lateinit var mockWebServer: MockWebServer
    private lateinit var uploadRepository: UploadRepository

    @Before
    fun setUp() {
        mockWebServer = MockWebServer()
        mockWebServer.start()
        val okHttpClient = OkHttpClient.Builder()
            .url(mockWebServer.url("/upload"))
            .build()
        uploadRepository = UploadRepository(okHttpClient)
    }

    @After
    fun tearDown() = mockWebServer.shutdown()

    @Test
    fun `upload sends correct multipart with image/jpeg`() {
        // Enqueue 200 OK with empty body
        mockWebServer.enqueue(MockResponse().setResponseCode(200).setBody("{}"))

        // Create a temporary JPEG file
        val jpegFile = File.createTempFile("test", ".jpg")
        jpegFile.writeBytes(byteArrayOf(0xFF.toByte(), 0xD8.toByte(), 0xFF.toByte(), 0xE0.toByte()))

        // Trigger upload
        uploadRepository.uploadImage(jpegFile).await()

        // Take the recorded request
        val recorded = mockWebServer.takeRequest()
        assertEquals("POST", recorded.method)
        assertTrue(recorded.getHeader("Content-Type").startsWith("multipart/form-data; boundary="))

        val body = recorded.body.readUtf8()
        assertTrue(body.contains("Content-Disposition: form-data; name=\"file\"; filename=\"test.jpg\""))
        assertTrue(body.contains("Content-Type: image/jpeg"))
        assertTrue(body.contains("\r\n\r\n")) // ensure file data present
    }
}

These contract tests guarantee that the client never drifts from the expected API contract, catching bugs like wrong MIME type or missing authorization header before they reach production.

Autonomous Persona‑Driven Exploration with SUSA

While scripted tests cover anticipated flows, real users exhibit unpredictable behavior—rapid tapping, unusual navigation patterns, or deliberate attempts to misuse features. SUSA (SUSATest) autonomously explores an app using a set of defined personas, each with a distinct behavior model. It can surface image‑upload bugs that scripted tests never consider because they fall outside the pre‑defined action sequences.

How SUSA Works in a Nutshell

1. Ingestion – You provide an APK or a URL. SUSA installs the app on a cloud‑hosted Android emulator or a real device lab.
2. Persona Engine – Eight built‑in personas (curious, impatient, novice, adversarial, elderly, accessibility, power user, and security tester) each possess a probability distribution over actions such as tap, long‑press, swipe, voice input, permission toggling, and app backgrounding.
3. Exploration Loop – SUSA maintains a visited‑state graph (screen + UI hierarchy). From each state it selects an action weighted by the current persona’s profile, executes it, observes the result (new screen, crash, ANR, toast, logcat error), and updates the graph.
4. Issue Detection – Built‑in detectors watch for:

• Crash or ANR (via tombstone logs)
• Dead buttons (no state change after interaction)
• Accessibility violations (missing content‑description, contrast failures)
• Security red flags (file URI scheme usage, clear‑text HTTP, excessive permissions)
• UX friction (repeated error dialogs, endless loading spinners)

1. Learning – After each run, SUSA records dead ends and successfully completed flows. Subsequent runs bias exploration toward under‑tested areas, increasing coverage over time.
2. Artifact Generation – From the explored graph, SUSA auto‑generates regression scripts: Appium for Android UI and Playwright for web views, enabling you to lock‑in the discovered paths.

Applying SUSA to Image Upload

When you point SUSA at an app that contains an image upload button, the following persona‑driven scenarios often emerge automatically:

SUSA’s output includes a detailed report with screenshots, logcat excerpts, and the exact sequence of actions that led to each finding. You can then convert those sequences into automated regression tests (Espresso/UIAutomator) or address the root cause directly.

Integrating SUSA into CI

Add a step that runs the CLI agent against your latest APK:

pip install susatest-agent
susatest run \
    --apk path/to/app-release.apk \
    --personas curious,impatient,adversarial \
    --max-depth 6 \
    --output-dir ./susareport

The agent exits with a non‑zero status if any high‑severity issue (crash, ANR, security leak) is detected, causing the build to fail. Over time, you’ll notice the “explored screens” count rise, indicating growing coverage without writing additional test code.

Edge Cases That Only Appear in Production

Even the most thorough test matrix can miss issues that arise from the interplay of device fragmentation, carrier‑specific behavior, or user‑generated content. Below are production‑only edge cases that have caused outages in real apps, together with concrete detection strategies.

Detecting these issues requires a combination of device‑farm testing, simulated network conditions, and intentional system state changes (time zone, permissions, kill signals). Incorporate them into your nightly test suite or into a periodic exploratory run with SUSA, which already varies device models, OS versions, and network profiles.

Accessibility and Security Considerations

Image upload touches two critical non‑functional areas: accessibility (ensuring all users can interact) and security/privacy (preventing data leakage or malicious file acceptance). Below are focused checklists you can embed in your test plans.