Android Apps Built for the Handsets Your Staff Are Actually Carrying
Not the flagship in the demo video. The three-year-old budget phone on a van dashboard, the rugged scanner in a warehouse, the shared handset at a depot with 8 per cent battery. Kotlin, Jetpack Compose, and a device list drawn from your asset register rather than from a global market share chart.
British Pockets Hold a Different Mix to the Global Average
Generic Android advice is written against a worldwide device distribution that does not describe this market. Two features of the UK and European mix change what you should build and what you should test on.
A Near-Even Consumer Split, With a Skew
Android and iOS divide the UK consumer market fairly evenly, which already differs sharply from most of the world. What matters more is where the Android share sits: heavily weighted towards mid-range and budget handsets, and towards company-issued devices. Building only for a recent flagship means your worst-performing users are systematically the ones on the cheapest phones, and you will not see it because your own team does not have one.
A European Manufacturer Mix, Not a Global One
Samsung dominates Android here and across Europe to a degree it does not everywhere, with Google, Motorola, Xiaomi, Honor and a long tail of smaller brands behind it. That matters because manufacturer software layers differ most in exactly the areas that break apps: battery management, notification handling, permissions screens and default keyboards. A test matrix assembled from worldwide share would over-weight brands you will barely encounter in Britain and under-weight the one most of your users hold.
We build the device matrix from your own analytics where you have them, and from your asset register where the handsets are issued. Market statistics are a fallback, not a starting point.
Field Service, Trades and Logistics Run on Android
This is the segment where the platform is not a preference but a default. Issued handsets are overwhelmingly Android because they are cheaper to replace, easier to manage centrally, and available in rugged form factors nobody else makes.
Scanning That Uses the Hardware
Rugged handsets from the usual industrial brands carry a dedicated barcode engine and a physical scan trigger, exposed to applications through a manufacturer service. Integrating with that is quicker, more reliable in poor light and far less irritating over a shift than aiming a camera at a label. It is also a specific piece of integration work rather than something you get for nothing.
Work That Survives No Signal
Basements, plant rooms, rural sites, lorry parks and the middle of a distribution shed all defeat a browser. The job list has to live on the device, photographs, meter readings and signatures have to be captured offline, and everything has to reconcile when a connection returns without producing duplicates. That sync layer is where a serious proportion of the budget goes, and it should be specified deliberately.
Managed Devices, Not Personal Ones
Android Enterprise and managed Google Play let you publish privately to your own staff, lock a handset to an approved set of applications, push updates without anybody tapping anything, and wipe a device left in a cab. Most operations teams already run a management platform; the app has to be built to cooperate with it rather than fight it.
Paperwork That Has to Be Provable
Proof of delivery, signed job sheets, timestamped photographs, customs documentation on European movements. What the operation needs is not a pretty form but a defensible record: who, when, where, and an audit trail that cannot be quietly edited later. That shapes the data model more than the interface.
A Battery That Lasts the Shift
Constant GPS, a screen on in a bright cab and a chatty sync loop will flatten a budget handset before the afternoon. Location sampled at a sensible interval, batched uploads, dark interfaces where they suit the setting, and measurement on the actual device rather than an emulator. Field teams judge an app almost entirely on whether it survives the day.
Designed for Gloves and Daylight
Larger targets than a consumer app would use, high contrast that holds up outdoors, and a layout that tolerates one-handed use while holding something else. Also fewer taps: every extra confirmation is repeated forty times a day by somebody who will eventually find a way around it.
Kotlin, Compose, and Libraries We Did Not Invent
The mainstream Google-supported toolkit, so any competent Android developer can pick the project up. That matters more on a workforce app that will be in service for five years than on anything else we build.
Kotlin, With No Java Left Behind
Google’s first language for Android, with coroutines and flows for asynchronous work. The practical benefit is the null safety: an entire species of crash that used to dominate Android crash reports simply stops occurring. No Java left lying around for somebody to maintain later.
Jetpack Compose for the Interface
Declarative, far less code than the old layout system, and it handles large text settings, dark themes and TalkBack far better by default. It also makes the accessibility work less painful, which matters when the app has to satisfy a public sector buyer.
Jetpack for the Rest
Room for the local database, the platform work scheduler for deferrable background jobs, DataStore for preferences, the navigation and lifecycle libraries. These are maintained by Google and documented publicly, which beats an in-house abstraction that only its author understood.
Material as a Baseline You Can Depart From Deliberately
Material Design is not a requirement and nobody at Google will reject you for ignoring it. It is simply the set of behaviours an Android user already understands: where navigation sits, what the back gesture does, how a sheet or a snackbar behaves, how a list reacts to a long press. Following it means the app feels ordinary in the way good tools feel ordinary, and it means the dynamic colour, large text and dark theme handling arrive largely for free.
The departures we make are deliberate and they are mostly about context. A warehouse app gets larger touch targets and higher contrast than Material specifies, because the user is wearing gloves in a cold store. A driver app puts the primary action where a thumb reaches while the handset is in a cradle. A consumer product with strong brand guidelines keeps its colour and typography but not its navigation model. What we avoid is porting an iOS interface across unchanged, which is immediately obvious to an Android user and reads as an afterthought — an impression worth avoiding when Android is the majority of your workforce.
Where the app will be sold to a council, an NHS trust or a university, WCAG 2.2 AA is the working expectation and it is far cheaper handled during design. Our design and prototyping page sets out how that is done as an input rather than an audit.
Play Console, and Shipping Without Holding Your Breath
The great advantage of Android releases is that they are reversible in practice. A rollout can be halted after it has reached a small fraction of users, which turns a bad release from an incident into an inconvenience.
A Verified Account in Your Name
A one-off registration fee and a verification step. Organisation accounts are expected to supply a D-U-N-S number and details matching your registered entity, and the verified developer name appears on your listing. We are added as team members with the access we need and nothing more.
App Bundles, Signed by Google
Store submissions are Android App Bundles rather than APKs, so Google generates an optimised install per device and the download is smaller. Play App Signing holds the key, which removes the single most catastrophic failure in Android history: losing the signing key and being unable to update your own app ever again.
Testing Tracks, Used in Order
Internal testing for your team and ours, with builds available within minutes. Closed testing for an invited pilot group. Open testing where a wider beta is useful. Newer personal developer accounts also face a testing requirement before production access, which is worth knowing before promising a launch date.
The Pre-Launch Report
Google runs your build automatically on a set of real devices in its own lab and reports crashes, accessibility problems and screens it could not get past. It is free, it runs before anybody sees the app, and it routinely catches something on a handset nobody in the project owns.
Staged Production Rollout
Release to a small percentage first, watch the crash-free rate and the support inbox, then increase. If something is wrong, halt the rollout and most of your users never receive the bad build. We treat the first percentage as a real checkpoint rather than a formality, which means somebody is actually watching it.
Private Distribution Where It Fits
For workforce apps, managed Google Play publishes to your organisation only. The app never appears in a public search, updates can be pushed silently to enrolled handsets, and the release process is considerably calmer because there is no store review of the ordinary kind standing between you and a fix.
Why the App Stops Doing Things Overnight, and What We Do About It
Almost every Android support ticket that begins with it worked yesterday ends here. The platform restricts what idle apps may do, and several manufacturers restrict considerably more on top.
Dozing, Buckets and Manufacturer Extras
Android defers background work for idle apps and groups them into usage buckets that determine how often they may run. Several manufacturers add their own layer, and a phone can effectively put an unused app to sleep. It is not a bug in your app; it is the platform behaving as designed, plus a vendor being more aggressive than the design.
Schedule It, Do Not Assume It
Deferrable jobs go through the platform work scheduler, which survives reboots, respects the battery rules and retries sensibly. Uploads batch rather than firing per record. Anything genuinely continuous — navigation, a live tracked delivery — runs as a foreground service with an honest notification, because that is the arrangement the platform actually supports.
Push Rather Than Poll
An app that wakes every ten minutes to ask whether anything changed will be throttled and will be blamed for the battery. Sending a push when something actually changes is cheaper, faster and far more reliable. The awkward part is designing the server side to know what changed and for whom, which is where the work sits.
Permissions Asked in Context
Background location, notifications, precise location and file access are all requested at runtime and are all easy to refuse. Asking at the moment the user is about to need it, with a sentence explaining why, changes acceptance rates dramatically compared with a wall of prompts on first launch.
Measured on the Real Device
Battery and performance claims are checked on the oldest handset in your fleet, not on a developer machine. Emulators tell you nothing useful about thermal behaviour, radio wake-ups or what happens when a phone has been on a windscreen mount in July.
One Honest Onboarding Screen
Where a manufacturer battery setting will genuinely break a critical feature, the app says so once, in plain terms, with a route to the right settings screen. This is not elegant and it is far better than a driver discovering at 6am that last night’s jobs never downloaded.
Play Requirements That Will Stop a Release
Google enforces these through automated checks and periodic reviews. None are difficult; all of them delay a launch if they are discovered late.
Data Safety in particular has a UK GDPR dimension: it is a public statement about your processing, so it needs to agree with your privacy notice and your records of processing as well as with the code.
How the Device Matrix Gets Decided
Written down before build starts, agreed with you, and revisited each year. Nobody can test everything, so the useful discipline is deciding in advance what is in and what is explicitly out.
| Tier | What it covers | How it is tested |
|---|---|---|
| Primary | The handsets most of your users actually hold — typically a current Samsung, a Pixel, and whatever your fleet standardises on | Physical devices, every sprint, by a person |
| Oldest supported | The slowest and smallest device still in service, which on a van fleet is often several years old | Physical device, every release, with performance measured rather than assumed |
| Rugged and specialist | Industrial scanners and reinforced handsets with vendor scanning services and hardware keys | Physical device supplied by you, tested against the real workflow |
| The long tail | Other manufacturers, other screen sizes, tablets where relevant | Cloud device farm plus the Play pre-launch report |
| Explicitly out of scope | Devices nobody in your user base has, and versions below the agreed minimum | Not tested, and stated in the scope so it is a decision rather than a surprise |
Crash reporting is installed from the first release regardless, so anything the matrix missed announces itself within hours rather than through a complaint three weeks later.
Android Questions From UK Operations Teams
Our engineers use rugged Zebra and Samsung XCover handsets. Will a normal Android app run on those?
Yes, because they are ordinary Android devices underneath, but the interesting parts are the extras. Rugged handsets typically add hardware scan triggers, an integrated barcode or RFID engine, programmable side keys and a manufacturer service that exposes them to applications. Using those properly means integrating with the vendor mechanism rather than pointing the camera at a label, which is slower and fails in poor light. We also design for the physical reality: gloved fingers, wet screens, bright sunlight, and a shift that runs longer than a consumer battery expects. It is a design and integration question more than a code one.
Half our drivers are on Android and half on iPhone. Do we need two apps?
Not necessarily two native ones. Where a workforce is genuinely split and the app is form-driven work such as job sheets, photographs, signatures and status updates, a single cross-platform codebase usually serves both fleets at materially lower cost, with native modules written only for the parts that need them. Where the work leans on manufacturer scanning hardware, device management or deep background behaviour, native Android earns its keep on that side. A common and sensible pattern is native Android for issued handsets and a responsive web application for the smaller group on personal iPhones.
Can we distribute an internal app to staff without publishing it publicly?
Yes, and for a workforce app it is usually the right answer. Google Play supports private distribution to your own organisation through managed Google Play, so the app appears only for your staff on enrolled devices and never shows up in a public search. Combined with a device management platform you can also lock handsets to a small set of approved applications, push updates without asking anybody to tap anything, and wipe a lost device. It changes how releases are scoped, so it is worth deciding early rather than after the first public listing has gone live.
Our app stops working overnight on Samsung and Xiaomi handsets. Why?
Because several manufacturers layer their own battery management on top of Android and it is more aggressive than the platform default. An app the system has decided is idle can have its background work deferred, its alarms delayed and its network access cut, and some manufacturers will effectively put an unused app to sleep entirely. The fix is partly engineering and partly onboarding: use the platform work scheduler so jobs survive being deferred, use push rather than polling, declare a foreground service honestly where work genuinely must continue, and tell the user once, in plain terms, how to exempt the app on their particular handset.
What minimum Android version should a UK workforce app support?
For a consumer app in the UK, supporting roughly the last four to five major releases covers the overwhelming majority of the active base without dragging ancient code along. For a workforce app the answer comes from your own asset register instead of market statistics, because issued handsets often stay in service far longer than consumer ones and a three or four year old budget device is entirely normal on a van fleet. We ask for a list of what your staff actually carry, set the minimum from that, and revisit it at each annual platform update. Separately, Google enforces a minimum target API level for anything that stays in the store, which is a different obligation and it is not optional.
Does the Play Console account have to be in our company name?
It should be, and we set it up that way. Google Play charges a one-off registration fee and now requires verified details for developer accounts, with organisation accounts expected to provide a D-U-N-S number and information that matches your registered entity. Having it in your own name means you hold the listing, the reviews, the release keys and the payouts, with us added as team members and removable at any point. Accounts opened in an agency name are one of the more painful things we untangle during a takeover, so it is worth twenty minutes in week one.
Read Next
iOS App Development
Swift, App Review and the Apple account paperwork your finance team has to sign off.
Learn moreCustom Business Software
The office half of most field apps: scheduling, dispatch, reporting and the system the handsets talk to.
Learn moreBackend & APIs
Offline sync, conflict resolution and the data design that decides whether a fleet app holds up.
Learn moreTell Us What the Handsets Have to Do
Send the workflow, the device list and how much of it happens without signal. You get a written scope, a delivery window and a sterling range excluding VAT within two working days.