How to test an Android app online: the full guide
Testing an Android app online means the device lives in the cloud and your browser is the window: upload the APK, a real Android device boots with your app installed, and you test it by tapping, swiping, and typing — no emulator setup, no desk full of phones, and a link you can hand to anyone. This guide is the complete workflow, from preparing the right APK to the checklist that catches real bugs.
Step 1: Prepare the APK — debug vs. release
Start with the build itself, because which APK you upload decides what your testing proves.
- Debug builds are your iteration loop: quick to produce from Android Studio or Gradle (
assembleDebug), debuggable, signed with the debug key. Use them for daily functional checks while features are moving. - Release builds (
assembleRelease) are the truth build: signed with your release key, code-shrunk and optimized. A whole class of bugs lives only here — R8/ProGuard stripping something reflective, a resource that only the shrinker removes, a manifest merger difference. Rule of thumb: anything a stakeholder, tester, or user will see gets tested as a release build first. - APK vs. AAB: Google Play requires the Android App Bundle (AAB) for publishing, and Play generates per-device APKs from it. But an AAB isn't installable or shareable directly — for testing, you need the APK. Export one from the same code (Android Studio's "Build APK(s)", or generate a universal APK from the bundle with bundletool) so the build you test is the build Play will serve.
Step 2: Choose the Android version and device profile
Online testing earns its keep here: the same APK, many environments, minutes apart. On PreviewAPK your device runs Android 10–15 with a Pixel 9 Pro or Galaxy S24 profile. Choose deliberately:
- Oldest supported version — where compatibility goes to die. Permission models, background execution limits, and storage rules all changed across 10–15; a flow that works on 15 can silently fail on 11.
- Latest version — what new phones ship with, and where Play's target-API requirements push you anyway.
- Pixel vs. Galaxy profiles — different screen sizes and densities expose different layout bugs: text truncation, touch targets, fold-adjacent widths. Samsung's One UI also handles some dialogs and defaults differently from stock Android, and Galaxy devices are a huge share of real users.
- Stock profile — a clean baseline when you need to know whether a bug is yours or the OEM skin's.
A realistic minimum matrix for a release candidate: oldest + latest version, both profiles. Four runs, under an hour, and it covers the combinations your first angry review would have found.
Step 3: Run the functional checklist
Work this list on each environment in your matrix. It's ordered the way a user meets your app:
| Check | What to do | What it catches |
|---|---|---|
| Fresh install | Launch the app cold, first run | Crashes on empty state, broken first-run setup |
| Onboarding | Complete it; also try skipping/backing out mid-flow | Dead ends, state loss, resume bugs |
| Sign-up & login | New account, wrong password, existing account, logout | Validation gaps, session handling, error copy |
| Permissions | Grant each permission; then deny each one and keep using the app | Crashes and locked features on the deny path |
| Core flows | The 2–3 tasks the app exists for, end to end | The bugs your users will actually meet |
| Forms & input | Empty submits, long text, special characters, keyboard types | Validation, layout under the keyboard |
| Rotation & resize | Rotate mid-flow, mid-form, mid-video | State loss, layout breakage on the other aspect ratio |
| Background & return | Home button, switch apps, come back after a minute | State restoration, timer/media bugs |
| Offline behavior | Airplane mode: launch, use, reconnect | Infinite spinners, lost data, missing error states |
| Deep links | Open the app from a link in the browser/messages | Intent filters, cold-start routing |
Note results per build and environment as you go — "login fails on Android 11/Galaxy only" is a fixable bug report; "login is broken" is a meeting.
Step 4: Share the session, not screenshots
When a check fails — or a stakeholder needs to see a flow — send the build's link instead of describing the problem. On test APK online sessions, one person drives and everyone else watches the same live screen, so a teammate can watch you reproduce a bug, or a client can approve the exact flow you tested. Because each session's link is its own, the discussion stays attached to the build it was about — newer builds get newer links.
Step 5: Compare across versions when something smells
Version-comparison testing is where online devices beat a physical desk outright. Upload the same APK on two versions (or open two builds side by side across days) and diff the behavior: Does the notification arrive the same way on Android 13+, where notifications became opt-in? Does the permission dialog wording change the user's likely answer? Does the Galaxy profile's density clip the layout that fits the Pixel? Bugs that appear in exactly one cell of the matrix are configuration bugs — and they're invisible if you only ever test on your own phone.
Step 6: Know when to escalate to a real device
Online testing covers functional QA thoroughly, but sign-off for release should include one pass on physical hardware for anything involving: Bluetooth, NFC, or USB accessories; camera and microphone quality (not just whether they open); biometrics; GPS in motion; push notifications delivered to a locked, sleeping phone; and performance feel — scroll smoothness, frame rates under load, heat. PreviewAPK bridges the gap: enable the build's QR code and the same APK installs on a real phone (with Android's standard "install unknown apps" permission and possibly a Play Protect notice — normal for test builds), so your hardware pass tests the identical build you already cleared online.
Step 7: Keep a testing log per build
Five lines per build, kept anywhere your team actually looks:
- Build: version name + code, date, debug/release
- Matrix: versions × profiles run
- Checklist: pass, or the cell where it failed
- Issues: one line each, with environment
- Link: the session's share link, so anyone can watch the run live
That log is what turns "we tested it" into evidence — for clients, for your future self, and for the day a store review asks questions.
Try it with a live device
PreviewAPK is in private beta. Get early access to test your own builds.
Step 8: Put the preview in the pipeline
Manual uploads are for the first week. After that, wire the preview into where builds already happen: your CI pushes each build with the CLI or API, and the pull request carries the session's share link — posted once the run is live, always that run's build. If an AI agent writes your code, it can push its own builds the same way, run a screenshot pass over the flows it changed, and hand you a session it has already verified.
FAQ
Can I automate APK previews from CI or an AI agent?
Yes. The PreviewAPK CLI (`previewapk push app.apk --run`), REST API, and MCP server attach builds and start sessions without the portal. Agents can additionally drive the app — taps, typing, screenshots — in agent-driven sessions, then hand control to a human. The session's share link is how the human watches any of it.
Should I test a debug or a release APK?
Both, at different moments. Debug builds are for iteration — fast to produce, with debugging enabled. Before anything ships or goes to stakeholders, test the release build: it's signed, shrunk, and optimized the way users will receive it, and it's the build where release-only bugs (ProGuard/R8 issues, missing resources) appear.
Which Android versions should I test on?
At minimum: the oldest version your app supports and the newest available — behavior differences cluster at the extremes (permission models, background limits, notification rules). Add a middle version if time allows. On PreviewAPK you can run the same APK on Android 10 through 15, on Pixel 9 Pro and Galaxy S24 profiles.
My release is an AAB. Can I test it online?
You test the APK, not the bundle. The AAB is the publishing format Google Play requires; Play generates device-specific APKs from it. For testing, export an APK from the same build (Android Studio can build one directly, or bundletool can generate a universal APK from the AAB) and upload that.
How long does an online test session last, and what does it cost?
Sessions run while you're active and stop automatically after 15 minutes idle — start the device again any time from the portal or the API. PreviewAPK is $19/month per device with unlimited testing; it's in private beta, and the waitlist locks in the launch price.
Keep going
- Test APK online — run this workflow on your own build.
- Test an APK without a device — the same approach when there's no Android phone at all.
- Install an APK from a QR code — the real-hardware pass, with the same build.