Cheffusion Technologies
Mobile

Android Applications

Built for the devices your users own, not the one on the demo stand

How this is usually engaged

Ten to sixteen weeks for a first release, then maintenance covering the yearly Android release and the Play Store target-API deadline, which Google enforces by removing non-compliant apps from search. Publishing requires a Play Console account under your organisation, with the app signing key held by you.

Start a project brief
Practice
Mobile Engineering
Sectors
4 served
Process
5 stages
Standard
Built and tested to WCAG 2.2 AA

Kotlin applications for Android phones and tablets, tested across the screen sizes, OS versions and manufacturer behaviours your users actually have.

01What this solves

The problem this addresses

Android goes wrong through variety. An app is built and demonstrated on one recent handset, then arrives on a three-year-old device with half the memory, a manufacturer battery manager that kills background work, a screen a different shape, and an OS version two releases behind. The reviews that follow are about crashes and drained batteries, not about features.

02Capabilities

What is included

01

Kotlin and Jetpack Compose

Current Android tooling with a single-activity structure and Compose interfaces, following Material conventions so navigation, back behaviour and system gestures match what users already do on their phones.

02

Device and version coverage

A support matrix agreed from your analytics — which OS versions, which screen sizes, which manufacturers — and physical testing against the lower end of it rather than an emulator on a fast laptop.

03

Background work that survives

Sync, uploads and scheduled tasks built with WorkManager and tested against the battery restrictions that several manufacturers apply on top of stock Android, which are the usual cause of "it stops working overnight".

04

Offline storage and sync

A local database with a change queue, defined conflict resolution and a retry policy that does not flatten the battery when the network is intermittent.

05

Play Console release management

Internal and closed testing tracks, staged production rollouts, data safety declarations, and target-API upgrades kept ahead of Google's annual deadline rather than after it.

06

Accessibility on Android

TalkBack labels and traversal order, content scaling that holds at large font settings, contrast, and touch targets at the recommended minimum. Verified with TalkBack on a device, alongside automated checks.

03Use cases

Where this work usually starts

01

Rugged and shared-device deployments

Warehouse, depot and delivery handsets shared across shifts, often with barcode scanning and no reliable signal inside the building.

Logistics & Transport

02

Reaching a majority-Android customer base

Markets and demographics where Android is most of your traffic, and where an iOS-first plan would postpone most of your users indefinitely.

Retail

03

Staff apps for a distributed workforce

Rotas, timesheets, checklists and internal notices for people who do not have a company laptop and will not read an intranet.

Hospitality

04Approach

How we approach it

We set a minimum supported OS version from your own analytics rather than from a default, and keep a small set of older and lower-specification devices to test on. Applications are written in Kotlin with Jetpack Compose, background work is scheduled through WorkManager so it survives aggressive power management, and the local database is treated as the source of truth so the app remains usable on a weak connection. Play Console tracks are used properly: internal, then closed, then a staged production rollout.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

  1. 01

    Support matrix

    Minimum OS version, screen sizes and device classes decided from your data, with the cost of each extension made visible.

  2. 02

    Flows and offline model

    The tasks the app must complete with no signal, and what syncs when the device returns to coverage.

  3. 03

    Interface design for the range

    Layouts checked on a small low-resolution screen and a tablet, not only on the design reference device.

  4. 04

    Build and internal testing

    Regular builds to your internal track, with crash and performance reporting switched on from the first release.

  5. 05

    Staged rollout

    A small production percentage first, watching crash-free rates before widening.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

  • Android application source and build configuration
  • Supported device and OS matrixAgreed from your analytics, with the testing evidence against it.
  • Play Console tracks, listing assets and data safety declarations
  • Offline and background work specification
  • Accessibility and performance test results
  • Signing key handover and release runbook
07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

  • Node.js

Mobile

  • Kotlin

Data & Storage

  • PostgreSQL
  • Redis

Cloud Platforms

  • Google Cloud

DevOps & Operations

  • GitHub Actions
  • Sentry
The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Tokens are held in encrypted storage backed by the Android keystore, with a biometric or device-credential check where the data warrants it. The app talks only to your backend, so third-party keys never ship inside an APK that anyone can decompile. Release builds are obfuscated and stripped of logging, backup of sensitive data to the cloud is switched off explicitly, and exported components are limited to those that genuinely need to be reachable by other applications.

Our full security and quality approach
09Questions

Asked before we start

How far back should we support old Android versions?

That should come from your own analytics, not from a rule of thumb. Each additional older version adds testing effort and constrains which platform features you can use, so we present the coverage against the cost and let you choose. If you have no analytics yet, we start at a version that covers the large majority of active devices and revisit it after launch.

Why does background sync stop on some phones?

Several manufacturers add battery managers that are more aggressive than stock Android and will suspend an app they consider idle. We schedule background work through WorkManager, which handles this as well as anything can, and test against the common offenders. On some devices the only complete fix is asking the user to exempt the app, and we design that prompt to be understandable.

Do you build for tablets and foldables as well?

We can, but it is a scope decision rather than a free extra. Supporting larger screens properly means designing different layouts, not stretching phone screens, and testing on that hardware. If your users are on phones, we would rather spend the budget on the phone experience and say so.

Who holds the app signing key?

You do, in your own Play Console account, with Play App Signing enabled so a lost upload key can be reset. This matters more than it sounds: an app signing key held by a supplier means you cannot publish an update without them, and there is no way to recover from that other than shipping a new app under a new listing.

START HERE

Talk to us about Android Applications

The project brief takes about five minutes and gives us enough to have a useful first conversation about Android Applications rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a projectSend a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.