Building a business app for Android usually starts with a reasonable question: which versions do we support? Someone checks the distribution numbers, picks a floor, and the team moves on.
Then the app is deployed to two hundred devices in the field, and the real questions arrive. Why does the barcode scanner behave differently on the Zebra units? Why do the tablets in the trucks fall off the network overnight? Why did an update reach a hundred and eighty devices and stall on twenty. Why is one crew still on a build from March.
None of that is a coding problem. It is a fleet problem, and it belongs in the plan long before it becomes an emergency.
Consumer Android and fleet Android are different products
A consumer app is installed voluntarily, updated automatically, and used on a phone the owner chose and maintains. Almost none of that is true for a company deployment.
The devices are bought in batches and kept for years. They may be rugged handhelds from a manufacturer whose Android version froze at release. They are often locked down, sometimes without a Play Store at all. Users cannot install anything and would not know how. Updates arrive when an administrator pushes them, not when Google decides.
That changes the engineering. You are no longer supporting the current version of Android plus a couple behind. You are supporting whatever shipped on the hardware someone bought in 2022, for as long as that hardware stays in service.
The oldest device in the fleet sets the floor
The mistake is to set a minimum API level from global statistics rather than from an inventory.
Ask the operations team what is actually out there. The answer is usually more varied than anyone expects: three generations of the same handheld, a batch of tablets bought for a project that never ended, a dozen personal phones belonging to contractors, and one model that was discontinued and cannot be replaced with the same thing.
That inventory is the real support matrix. Write it down, keep it current, and get the finance side to agree on when devices leave the fleet, because “support everything forever” is a decision with a price and somebody should make it deliberately.
Manufacturer behaviour is the hidden variable
Stock Android and shipped Android are not the same thing. Manufacturers layer their own power management on top of the system, and several of them are far more aggressive than the platform defaults.
The practical result is that background work quietly stops. A sync that runs reliably on a Pixel may never run on certain devices unless the app is manually exempted from battery optimisation. Nothing crashes. Nothing logs an error. The data simply stops arriving.
Anyone who has debugged this once learns to test on the actual hardware in the fleet rather than on whatever the developers carry. It is also the single most common reason a deployment that passed testing fails in the field.
Distribution needs a plan of its own
If the app never goes through the Play Store, everything the store normally does becomes your responsibility.
Someone has to sign the builds and keep the keys safe. Someone has to decide how a device knows an update exists. Someone has to handle the device that has been in a drawer for six weeks and comes back four versions behind. Managed distribution, whether through a private Play channel or a device management platform, solves most of this, but only if it was chosen and configured before rollout rather than after.
Staged rollouts matter more here than in consumer work, not less. Send a new build to one crew, watch it for a few days, then widen. Recalling a bad update across a fleet is slow and visible.
Kiosk mode, permissions and the human factor
Locked-down devices bring their own catalogue of surprises. An app pinned to the screen has to handle everything itself, including the states a user would normally escape by leaving. Permissions granted by policy behave differently from permissions granted by a person tapping a dialog. A device shared across shifts needs a session model, because “logged in as whoever used it last” is how records get attributed to the wrong person.
These are ordinary requirements once they are named. They are painful when they surface during rollout, which is why teams that have done fleet work ask about them in the first meeting.
Ask the operational questions early
The gap between a consumer build and a fleet build is mostly a gap in questions asked at the start. What hardware, how old, who owns it, who updates it, what happens when it is offline for a week, who gets the call when a device stops reporting.
In Alberta, this comes up constantly because so much of the work happens on sites where the device is a tool rather than a phone. Companies looking for Calgary mobile app developers for field operations usually find the useful conversations are the ones that start with the hardware inventory rather than the feature list.
Plan the fleet, not just the app
A field application is only as good as the worst device it runs on and the slowest update it receives. Treat the device population as part of the product, decide who owns it, and budget for it the way you would budget for any other piece of infrastructure.
Do that, and Android is an excellent platform for this kind of work. Its openness is exactly what makes locked-down, purpose-built deployments possible. Ignore it, and that same openness becomes two hundred slightly different phones, each failing in its own way.
