What is Android app testing?

Android app testing checks that your app installs, works and performs well on the Android phones, tablets and other devices your users own, across the Android versions you support, and that it is ready for Google Play.

Why is Android testing harder than iOS testing?

Because of fragmentation. Android runs on thousands of models from many makers, each with its own screen sizes, hardware and software changes, and users update Android more slowly. That makes the choice of devices and versions far more important.

Which Android devices do you test on?

The ones your users own. We build the device matrix from your analytics and target markets, usually covering Samsung, Google Pixel, Xiaomi, Oppo, Vivo, OnePlus and Motorola, across low, mid and high-end models. The device matrix wizard on this page gives you a first view.

Do you test on real devices or emulators?

Both. Emulators give fast feedback during development. Before release we test on real devices, our own and on device clouds such as BrowserStack, Sauce Labs and Firebase Test Lab, because real hardware and maker software behave differently.

How many Android versions should we test?

Usually your minimum supported version, the latest release and the versions in between that most of your users run, plus the next Android beta before it launches. Your Play Console and analytics data tell us where to focus.

Can you help us pass Google Play review?

Yes. We check the data safety form, target API level, permissions, content rating and listing, test the signed release build and review the pre-launch report before you submit, so you avoid avoidable rejections.

Do you test Samsung and other makers’ custom versions of Android?

Yes. Samsung One UI, Xiaomi HyperOS, ColorOS and others change notifications, battery savers and background behaviour. We test on those devices because these changes cause many real-world bugs.

Do you test foldables and tablets?

Yes. We test folded, unfolded and tabletop states, layout continuity when the screen changes, multi-window, and keyboard, mouse and stylus input on tablets.

Do you test Wear OS, Android TV and Android Auto apps?

Yes. We test watch tiles, complications and phone sync on Wear OS, remote and D-pad navigation on Android TV, and template and driver safety rules on Android Auto.

Do you test Flutter and React Native apps on Android?

Yes. We test the app on real Android devices whatever it is built with, and pay extra attention to plugins, native modules and platform channels, where cross-platform apps most often fail.

How do you test Android app security?

We test against OWASP MASVS and MASTG: how data is stored, how the app talks to its APIs, exported components and deep links, and how well it resists rooting, tampering and reverse engineering.

How do you test Android app performance?

We measure start-up time, ANRs, frozen frames, battery, memory and data use on real mid-range and budget phones, on slow networks, and compare the results with your Android vitals in Play Console.

Can Android testing be automated?

Much of it can. We use Espresso and UI Automator for native tests and Appium when you want one suite for Android and iOS, running on device clouds in your CI. New features and device-specific issues are still best checked by people.

How do we get started?

Book a call or send the form on this page. We start with a free one-week proof of concept on your most important Android journeys, so you can see our bug reports before you commit.

Android App Testing Services

Your app will run on thousands of different Android phones and tablets, each made a little differently. Your users expect it to work on theirs.

We test on the devices and Android versions your users actually have, check the behaviour that only Android has, and get every release ready for Google Play, from first install to staged rollout.

Get in touch Build your device matrix

Real devices and device clouds
Every Android version you support
Google Play ready
Free one-week POC

What we test

01Device fragmentationReal devices 02Android-specific behaviourBack button, permissions 03Android versions & updatesOS releases 04Foldables & tabletsLarge screens 05Wear OS, Android TV & AutoBeyond the phone 06Kotlin, Java, Flutter & React NativeAny stack 07Android securityData & privacy 08Android performanceSpeed & battery

[ Why Android testing ]

One app, thousands of different phones

Most of the world’s smartphones run Android, but no two makers ship it quite the same way. Samsung, Xiaomi and Oppo change how notifications, battery saving and background work behave. People keep their phones for years and update slowly. An app that runs perfectly on a developer’s Pixel can freeze on a three-year-old mid-range phone. Android testing is about finding those gaps before your users and your Play Store rating do.

Building for iPhone too? See iOS app testing →

The devices your users own

A matrix built from your analytics and markets, not a generic top-ten list.

Every version you support

From your minimum Android version to the next beta, tested before your users get it.

Smooth Google Play releases

Policy, data safety and pre-launch checks done before you submit.

Stable on budget phones too

Performance, battery and ANRs measured on the mid-range phones most people use.

[ What we test ]

Eight areas where Android apps break

From the device in your user’s hand to the security of the data on it. Each area lists what we check, when you need it and the risk we look at first.

Device fragmentation & the device matrix

Real devices

There are thousands of Android models from dozens of makers, each with its own screen, chipset and software changes. We build a device matrix from your analytics and markets, so you test the phones your users really own.

What we check

Top devices by your real user share, not a generic list
Samsung, Pixel, Xiaomi, Oppo, Vivo, OnePlus and Motorola
Low, mid and high-end hardware, including Android Go phones
Screen sizes, densities, notches and cut-outs

When you need it

Before your first release, and each quarter as your user mix changes.

Top risk we test firstCrashes and layout bugs that only appear on one maker’s phones

Android-specific behaviour

Back button, permissions

Android gives users and the system more control than iOS. Apps need to cope with the back button, runtime permissions and a system that stops background work to save battery.

What we check

Back button and gesture navigation on every screen
Runtime permissions: allow, deny, “only this time” and revoke
Background limits, Doze mode and maker battery savers
Rotation, split screen, process death and state restore

When you need it

For every release, especially after navigation or permission changes.

Top risk we test firstLost data and stuck screens after the system kills your app

Android versions & updates

OS releases

Each Android release changes permissions, notifications, storage or background rules. We test the versions you support and the next one before it reaches your users.

What we check

Your minimum supported version up to the latest release
The new Android beta before public launch
Target API level changes Google Play requires each year
App updates over older versions with real user data

When you need it

Each time Google ships a new Android beta, and before raising your target API level.

Top risk we test firstFeatures that stop working after an Android update

Foldables & tablets

Large screens

Large screens are a growing share of Android use. We check that your layouts adapt and nothing is lost when the screen changes shape.

What we check

Folded, unfolded and half-open (tabletop) states
Continuity when the app moves between screens
Tablet layouts, multi-window and drag and drop
Keyboard, mouse and stylus input

When you need it

When you add tablet support or see foldables in your analytics.

Top risk we test firstLayouts that stretch, crop or reset when the device unfolds

Wear OS, Android TV & Auto

Beyond the phone

Companion and standalone apps on watches, TVs and cars have their own rules and their own review checks from Google.

What we check

Wear OS tiles, complications, notifications and phone sync
Android TV remote and D-pad navigation and the leanback layout
Android Auto media and messaging templates and driver safety rules
Pairing, disconnects and reconnects between devices

When you need it

Before you launch on a new form factor, and with every companion app update.

Top risk we test firstSync failures between the phone and the watch, TV or car

Kotlin, Java, Flutter & React Native

Any stack

However your app is built, we test the result on real devices, and we know where each framework tends to fail.

What we check

Native Kotlin and Java apps, including Jetpack Compose
Flutter apps: platform channels, plugins and rendering
React Native apps: native modules, bridges and updates
Hybrid and WebView-based apps

When you need it

Whenever you change framework versions or major plugins.

Top risk we test firstBugs in the native layer under a cross-platform framework

Android security (OWASP MASVS)

Data & privacy

View service

Android apps are easy to unpack and inspect. We test yours against the OWASP Mobile Application Security Verification Standard (MASVS) and its testing guide (MASTG).

What we check

Data storage, logs, backups and the clipboard
Network security, certificate pinning and APIs
Exported components, intents and deep links
Root detection, tampering and reverse engineering

When you need it

Before launch, after major changes, and when handling payments or personal data.

Top risk we test firstSensitive data left readable on the device

Android performance

Speed & battery

View service

A slow or battery-hungry app gets uninstalled, and Google Play shows high crash and ANR rates to users. We measure what users feel on real mid-range phones.

What we check

Cold and warm start-up time
ANRs, frozen frames and dropped frames
Battery, memory, storage and data use
Behaviour on slow networks and low-end devices

When you need it

Before launch, and whenever Android vitals in Play Console get worse.

Top risk we test firstANRs and slow start-up on mid-range and budget phones

[ Google Play release checklist ]

Ten checks before you press “Send for review”

Most rejections and bad launches come from a short list of misses. We run through all of them on every release.

PolicyData safety form complete and matching what the app really collects
PolicyTarget API level meets the current Google Play requirement
PolicyContent rating questionnaire and target audience set
PolicyPermissions justified, including sensitive ones such as location and SMS
BuildRelease build signed, minified and tested, not just the debug build
BuildApp Bundle tested on the device types it splits for
ListingScreenshots, description and release notes match the app
TestingInternal and closed testing tracks used before production
TestingPre-launch report reviewed and issues fixed
ReleaseStaged rollout planned, with Android vitals and crash reports watched

[ How we work ]

Six steps from device matrix to Play release

You always know which devices and versions are covered and what is ready to ship. Every matrix, plan and report belongs to you.

Step 1 of 6
Review your app & users

Your app, analytics, markets and Play Console data reviewed with your team.

You getRisk and user review
Step 2 of 6
Build the device matrix

Devices, Android versions and screen sizes chosen from real user share.

You getAndroid device matrix
Step 3 of 6
Plan the tests

Journeys and Android-specific checks written for your app and its stack.

You getAndroid test plan
Step 4 of 6
Test on real devices

Real phones and tablets, plus device clouds and emulators for breadth.

You getBug reports with device, OS and logs
Step 5 of 6
Check Play readiness

Policy, data safety, pre-launch report and release build reviewed.

You getPlay release checklist
Step 6 of 6
Release & monitor

Staged rollout watched, then regression on every release.

You getRelease sign-offUpdated matrix

Free one-week POCWe test your most important Android journeys for a week, so you can judge our work first.
Real devices firstCore journeys on real phones in our team’s hands, with BrowserStack, Sauce Labs and Firebase Test Lab for breadth.
Bug reports you can act onDevice, Android version, steps, video and logcat output on every issue.

[ Tools ]