Test an APK on a Real Android Device Without Android Studio
Install and test an APK on a real Android device without Android Studio. Phone setup, adb install or the browser, a 10-minute smoke test, evidence capture and cleanup.
You can test an APK on a real Android device without Android Studio: enable USB debugging once, then install the build with adb install -r app.apk from the platform-tools, or drop the file into the Install APK panel of ADBKit in Chrome or Edge with nothing installed at all. This guide is for people who receive builds rather than make them: QA testers, product managers and designers reviewing a build from CI, Firebase App Distribution or a shared drive. It covers the right file, phone setup, a 10-minute smoke test, evidence and cleanup.
Why test on a real device at all
Emulators are convenient for developers, but they hide the problems a release meets in the wild:
- Performance. A laptop emulates a phone with far more CPU and memory than a mid-range device. Jank, slow cold starts and stuttering animations only show on real hardware.
- Sensors and hardware. Camera, GPS, fingerprint, NFC, Bluetooth, haptics and the display cut-out behave differently or not at all in an emulator.
- OEM skins. Samsung One UI, Xiaomi HyperOS and others change permission dialogs, battery optimisation, notifications and the back gesture. A build that passes on a Pixel can still fail on your users' phones.
- Real networks. Mobile data, flaky Wi-Fi and switching between them are where network error handling is actually exercised. Keep a cheap, old "worst" device on the team; it tells you more than a flagship.
Getting the right build
Ask the developer or the CI pipeline for an .apk file, not an .aab. An App Bundle is a Google Play publishing format and cannot be installed with ADB; the developer can export a universal APK with bundletool.
Then check how it is signed, because signing decides whether you can update what is already on the phone:
| Build | Signed with | Updates the Play Store version? | Updates a previous test build? |
|---|---|---|---|
| Debug | Developer's debug key | No | Yes, if the earlier build used the same debug key |
| Release / internal | Release or upload key | Yes, if the keys match | Yes, if the earlier build used the same key |
Android refuses to install over an app signed with a different key (INSTALL_FAILED_UPDATE_INCOMPATIBLE); uninstall the old copy first and accept that its data is gone. An older versionCode over a newer one fails with INSTALL_FAILED_VERSION_DOWNGRADE unless the app is debuggable and you pass -d. Both are explained in how to install an APK with ADB.
Note: Distribution services usually download builds through the phone's browser. For a lab phone, downloading to your computer and installing over USB is more repeatable: you know exactly which file went on.
One-time phone setup
- Open Settings → About phone and tap Build number seven times to unlock Developer options.
- In Settings → System → Developer options, turn on USB debugging.
- Connect the phone with a USB data cable (some charging cables carry no data). If the phone asks what the connection is for, choose File transfer.
- The first time a computer connects, the phone shows Allow USB debugging?. Tick Always allow and tap Allow.
Manufacturer-specific steps are in how to enable USB debugging on Android. Show taps in the same menu makes touches visible in recordings.
Install the build
With adb
Download the platform-tools, unzip them, and run from that folder:
adb devices # phone should appear as "device"
adb install -r app.apk # -r keeps data when replacing an existing installAdd -g to grant all runtime permissions up front, and leave it off when the permission flow is part of what you are testing.
With ADBKit in the browser
If you would rather not keep command-line tools around, ADBKit does the same job in Chrome or Edge.
- Open the workspace, click Connect device, pick the phone in the browser's USB dialog and tap Allow on the phone.
- Choose the Install APK tool and select the
.apkfile. - If a previous build is on the phone, tick Replace existing app. ADBKit asks you to confirm before it overwrites anything.
- Wait for the success message; the panel reports the failure code if the install is refused.
The APK goes straight from the browser to the phone. Only one program can hold the USB connection, so if connecting fails, close Android Studio, scrcpy or other ADBKit tabs, or run adb kill-server.
The 10-minute smoke test
Run this checklist on every build before digging into the feature under review.
| # | Check | What to look for |
|---|---|---|
| 1 | Cold launch | Force-stop, then open from the launcher. No ANR dialog, first screen within seconds. |
| 2 | Permissions | Deny a permission on first ask, then grant it from Settings. The app explains, never crashes or loops. |
| 3 | Rotation | Rotate on every main screen. Typed text and scroll position survive, nothing is clipped. |
| 4 | Background and resume | Press Home, open two other apps, come back, then lock and unlock. State and login survive. |
| 5 | Low network | Enable aeroplane mode mid-request, then disable it. A readable error and a retry, not an endless spinner. |
| 6 | Text input | Type in every field with the real keyboard: emoji, a very long string, paste. The keyboard must not cover the field. |
| 7 | Dark mode | Toggle the system dark theme. Check contrast, icons and hard-coded white backgrounds. |
| 8 | Back navigation | Use the back gesture and button from every screen. Dialogs close, the app never exits unexpectedly. |
| 9 | Upgrade path | On a phone with the previous build, install the new one in replace mode. Login and data stay intact. |
Rotation, background/resume and the upgrade path break most often.
Capture evidence while you test
A bug that cannot be seen gets closed as "cannot reproduce". Capture as you go:
- Screenshots of every unexpected state:
adb exec-out screencap -p > bug.png, or the Screenshot tool in ADBKit, which keeps a session history. - A screen recording, started before the step you expect to fail:
adb shell screenrecord /sdcard/bug.mp4(stop with Ctrl+C, thenadb pull /sdcard/bug.mp4), or the Screen Record button in ADBKit, which saves a WebM file to your computer. - Logcat from the moment of failure. In ADBKit, set the level to Error, filter by the app, pause when it crashes and click Export logs. The CLI equivalent is in finding an app crash in logcat.
Push test files to the device
Many test cases need a file on the phone: a sample PDF, a corrupt image, a CSV to import. Put them in Downloads, which every app can reach through the file picker:
adb push sample.pdf /sdcard/Download/
adb pull /sdcard/Download/export.csv .In ADBKit, open the Files tool, go to Downloads, and use Upload file to send a file from your computer or Download to retrieve something the app produced; the panel asks before overwriting. More in browsing and transferring files with ADB.
Reset and clean up between builds
Start each session from a known state:
adb shell pm clear com.example.app # wipe app data, keep the app (like a fresh install)
adb uninstall com.example.app # remove the app and its data
adb shell pm list packages | grep example # find the package namepm clear is the fastest way to re-test onboarding and first-run permission prompts. Also delete the test files you pushed to Downloads.
Warning:
pm clearanduninstalldelete the app's local data with no confirmation. Export anything you still need first.
Report bugs with device details
Every bug report should name the phone and Android version. Collect it once per device:
adb shell getprop ro.product.model # SM-S911B
adb shell getprop ro.build.version.release # 14
adb shell dumpsys package com.example.app | grep versionNameIn ADBKit, the Shell tool opens a terminal on the connected device where the same getprop commands work. Put the model, Android version and app version at the top of the report, then the numbered steps, expected and actual result, and the screenshot, recording and log you captured. A report with those parts usually gets fixed in one round trip.