How to Evaluate a Native Android Development Vendor: The Complete Scorecard for US Enterprise 2026

Most mobile vendor evaluation processes ask the wrong questions. "How many engineers do you have?" and "What frameworks do you use?" tell you nothing about what happens when your Android app crashes on a Samsung Galaxy A34 in the hands of a field worker. These eight questions do.

Why Android vendor evaluation is different

iOS vendor evaluation and Android vendor evaluation share some questions. Several questions are Android-specific, and they matter more than most buyers realize.

Android's device fragmentation means an app can behave correctly on every device a vendor tests and fail on devices your employees actually carry. An iOS app that passes quality review on six Apple devices will behave consistently on all iPhones those iOS versions support. An Android app that passes on six devices may have untested behaviors on the Samsung A-series hardware that represents a large fraction of your workforce.

Android's background service restrictions mean an app that syncs data reliably in testing — where devices are plugged in and actively used — may fail to sync in production, where devices sit idle overnight in a charging dock or in a pocket between uses.

Android Enterprise MDM deployment requires architecture decisions that do not apply to consumer Play Store apps. A vendor who has only built consumer Android apps will not know what they do not know about MDM deployment.

These are not edge cases. They are the most common categories of Android production failure that enterprise buyers face after signing with a vendor who passed a generic evaluation. The eight questions below are designed to surface these risks before you sign.

Question 1: the device test matrix

Ask: "What is your Android device test matrix? Can you share the specific devices and OS versions?"

The right answer is a list. Specific device names. Specific OS versions. The list should include:

• Flagship Samsung (Galaxy S22, S23, or S24 series)
• Mid-range Samsung (Galaxy A34 or A54 series)
• Entry-level Samsung or Motorola (Galaxy A14, Moto G-series)
• Google Pixel (any generation)
• At least Android 10, 11, 12, 13, and 14 coverage

A vendor who responds with "we test on a range of devices" or "we have access to a device farm" is not answering the question. The question is about the specific matrix, not about access to hardware.

Ask a follow-up: "Is this matrix run in CI on every build, or is it a manual test run before release?" Automated CI testing on every build is meaningfully different from manual testing once before a release. The first catches regressions as they are introduced. The second catches them when they are harder to fix.

Wednesday runs 16 device and OS configurations in CI. The device list is specific and documented.

Question 2: Jetpack Compose adoption

Ask: "What percentage of your current Android engagements use Jetpack Compose for new UI? What is your position on Compose vs XML for new projects starting in 2026?"

A current answer is: all new Android projects use Compose. XML is maintained for existing apps where migration is not cost-justified.

A concerning answer is: "We use a mix depending on client preference" — which often means the team defaults to XML because it is what they know, and uses Compose only when a client specifically requests it.

Compose has been production-stable for enterprise use since 2023. A vendor building new Android apps on XML in 2026 is not keeping pace with the platform. The practical consequence is lower development velocity and less testable UI code over the life of the engagement.

The follow-up question: "Can you show me a recent production app where you used Jetpack Compose extensively?" A yes with a specific app name is a real answer. A hedge is not.

Question 3: background service handling

Ask: "How do you handle Android background service limitations — specifically Doze mode and App Standby — for apps that require background sync?"

The right answer includes: WorkManager as the foundation for deferrable background tasks, specific WorkManager constraint configuration (NETWORK_CONNECTED, REQUIRES_NOT_LOW_BATTERY), awareness of manufacturer-specific battery optimization layers (Samsung Power Saving mode, Xiaomi's MIUI battery manager), and the use of ForegroundService for tasks requiring continuous execution.

A concerning answer describes WorkManager correctly but does not mention manufacturer-specific layers. The standard Doze mode behavior is documented. The Samsung and Xiaomi manufacturer layers are where background processing surprises happen in production.

Ask the follow-up: "Have you encountered background service failures caused by manufacturer battery optimization on mid-range devices, and how did you solve them?"

An experienced Android team has encountered this. They will have a specific story about a specific device and a specific fix. A team that has not encountered it has not shipped Android apps to a diverse fleet of mid-range devices.

Question 4: crash-free rate and measurement

Ask: "What crash-free rate do you target for Android apps, and how do you measure it? Can you share Crashlytics or Firebase data from a recent production app?"

The right answer: 99.5% crash-free on Android as a target. Measurement via Firebase Crashlytics or an equivalent tool (Sentry, Datadog). Willingness to share recent data.

A concerning answer: any target below 99.5% without a specific justification, or reliance on self-reported crash counts rather than a monitoring tool.

Google Play Console marks apps with crash rates above 1.09% as bad behavior. This affects Play Store visibility. Enterprise apps should be well above that threshold. A vendor who targets 98% crash-free is delivering a Play Store visibility risk and a user experience problem.

The Crashlytics data request is a filter. A vendor with strong Android quality will share it without hesitation. A vendor with weaker quality will hedge or say the data is confidential. The hedge itself is informative.

Question 5: Android Enterprise experience

Ask: "Have you deployed Android apps in Android Enterprise managed deployments — fully managed, work profile, or dedicated device mode? What MDM platform was used?"

The right answer names a specific MDM platform (Jamf, Intune, Workspace ONE, SOTI), a specific deployment mode, and can describe how managed app configuration was implemented.

A concerning answer references "enterprise MDM" generically without naming a platform or describing the deployment model.

Ask the follow-up: "How do you implement managed app configuration so IT administrators can push environment settings to the device fleet without requiring users to do anything?"

This is a specific Android Enterprise API question. A vendor with real MDM deployment experience knows the answer immediately. A vendor who has only built consumer apps will not recognize the question.

Question 6: Google Play review track record

Ask: "Can you share your Google Play review track record for the last 12 months, including any rejections? Have you submitted apps in sensitive categories — health data, financial services, apps requiring camera, location, or microphone permissions?"

The right answer: a documented review history, transparency about rejections and what they required, and specific experience with the Play Store policies for your industry category.

Google Play review has become more rigorous in the last two years, particularly for health-related apps, financial apps, and apps requesting sensitive permissions. Vendors who have not navigated these categories recently may underestimate review timelines and the policy compliance work required.

Rejection patterns are as revealing as approval rates. A vendor with a pattern of rejections for missing privacy policy disclosures, for permission over-requests, or for policy-noncompliant content has not internalized Google's current review standards.

Question 7: AI-augmented development workflow

Ask: "Do you use AI code review for Android? What does it catch that human review misses? What is your release cadence for active engagements?"

The right answer: yes to AI code review, with specific categories it catches (coroutine scope misuse, Compose recomposition inefficiencies, background service violations, security anti-patterns). Weekly release cadence for active engagements.

A concerning answer: "we evaluate AI tools" or "we use AI for documentation." These are not AI-augmented development workflows.

AI code review for Android catches Kotlin-specific patterns that human reviewers miss under time pressure: GlobalScope coroutine leaks, Compose recomposition triggers on high-frequency state changes, main thread I/O calls that cause ANRs. The catch rate matters because these patterns cause production ANRs — Android application not responding errors — that directly trigger Google's bad behavior thresholds.

Question 8: ongoing maintenance model

Ask: "What does an ongoing maintenance engagement look like after initial development? What is your response time SLA for a critical production bug — a crash affecting more than 1% of sessions?"

The right answer: a named delivery lead, a weekly release cadence that allows fixes to ship within the current week for critical issues, and a defined escalation path for production incidents during US business hours.

A concerning answer: "we review maintenance needs quarterly" or "we handle bugs in the next week." A critical Android production bug that is crashing the app for 1% of users needs a fix in days, not weeks.

Ask specifically about Google Play review turnaround for emergency fixes. Standard Play Store reviews complete in 1-3 days. Emergency expedited reviews are not guaranteed. A vendor who has managed production incident responses for enterprise Android apps knows this and will describe their process for managing the gap between fix completion and Play Store approval.

How Wednesday answers all eight

Device test matrix: 16 device and OS configurations in CI. The list is available on request. Includes Samsung flagship and mid-range, Motorola G-series, Google Pixel, Android 10-14.

Jetpack Compose: all new Android projects use Compose. XML maintained for existing apps where migration is not cost-justified. Engineers have Compose proficiency across the Android team.

Background service handling: WorkManager with platform-specific constraint configuration. Wednesday has encountered and solved manufacturer battery optimization failures on Samsung and other mid-range hardware. Case study: zero patient logs lost in the clinical health app's offline-first background sync.

Crash-free rate: 99.5% target on Android. Measurement via Firebase Crashlytics. Wednesday has maintained 99% crash-free at 20 million users in the fashion e-commerce engagement.

Android Enterprise: fully managed, work profile, and dedicated device deployments. Jamf and Intune experience. Managed app configuration implemented as standard for field device deployments.

Google Play review: active experience with health, financial services, and permissions-heavy app categories. No unexplained rejections in the last 12 months of enterprise submissions.

AI-augmented workflow: AI code review on every Android PR. Weekly release cadence across all active engagements. AI code review catches 23% more issues than human review alone.

Ongoing maintenance: named delivery lead, weekly release cycle, critical production bug response within 24-48 hours.