Hire Android Developers

Native Android earns its place where the hardware matters — integrated barcode scanners, rugged handsets, vehicle mounts, kiosks locked into a single application, devices managed by an enterprise MDM. That world runs on older API levels and manufacturer-specific behaviour that a cross-platform layer will not shield you from.

Most Android defects that reach a field fleet are not code defects; they are platform-policy defects — something the operating system stopped allowing, or something Google Play now requires, that continued to work perfectly on the developer’s phone.

The manifest rules that changed under everybody

Since API 30, an app cannot see another app unless it declares what it is looking for. Miss the queries element and resolveActivity returns null for the dialer or for WhatsApp even though both are installed, and the button in your app is simply dead. It is not an error anyone will see in a log.

The same file is where two other classes of bug live. A notification’s small icon is rendered as a silhouette, so a colour launcher icon supplied there shows up as a blank white square on the handset. And a library declaring the same metadata key as your app makes the manifest merger fail outright rather than pick one, which is a build failure that arrives from a dependency bump.

There is a Play policy edge too: declaring broad media permissions when you are actually using the system photo picker gets the app treated as a broad-media-access app and flagged for policy review. Asking for a permission you do not need is not conservative; it is a review risk.

Background execution is where field apps quietly die

The single most common support ticket on a fleet app is “it stopped syncing”, and the cause is almost always background restrictions rather than the network.

Three specifics we work to. A foreground service on Android 12 and above can throw when it is not permitted to start, so every start needs a fallback path rather than a crash. A foreground service declared for data sync on Android 14 and above is not permitted background location access at all — we found this by having watermark coordinates come back empty, and the fix was to stamp photographs from a cached last-known fix with a maximum age rather than requesting a live one that could never succeed. And on several manufacturers, aggressive battery management will stop a service regardless of what the API documentation says, which is why an exemption request and a visible queue screen matter more than a clever scheduler.

Storage stopped being a filesystem

Writing to the public Downloads directory worked up to Android 9. After scoped storage it fails with a permission error on a permission the user cannot grant, and the app tells them to enable something that no longer exists. The correct path is to stage the file in the app’s own sandbox and hand it to MediaStore.

Related, and easy to miss: a URI handed back by a camera or picker intent can be cleared by the system, is not readable under scoped storage in every case, and may not survive an app restart. Any photograph that has to be uploaded later gets copied into the app’s own documents directory the moment it is taken, and the queue references that copy.

Two ways a release build differs from a debug build

Code shrinking is the first. R8 will strip or rename classes that are only reached through JNI or reflection, which produces a crash that exists exclusively in release builds and often only on certain devices — in our case watermarking and image compression failing on some Android 10 handsets and blocking every photo upload. The fix is explicit keep rules, and the lesson is that a release candidate has to be tested as a release build on real hardware.

The second is packaging. Android 15 devices can use a 16 KB memory page size, and native libraries have to be aligned for it — which means non-legacy JNI packaging, a recent build toolchain and, in practice, a verification step on the bundle rather than a hope. Two of our apps solved it differently: one dropped 32-bit architectures entirely, the other kept all four and pinned a dependency version that carried the alignment fix. Both wrote a script that checks the artefact.

Where native Android is the wrong choice

If the product must exist on both platforms with identical behaviour and there is one team, a cross-platform framework will get you there for less. If the app is a thin wrapper over content, a web app avoids store review entirely. And if nobody on the project has run a Play Console release before, the schedule should reflect that store review, target-API deadlines and staged rollout are work, not paperwork.

What we interview for

Ask what the oldest device they supported was and what broke on it. Ask how they got reliable background sync on handsets with aggressive battery management, and how they handled the Play Store target API deadline. Engineers who have deployed to a real fleet answer immediately. Engineers who have only built on an emulator do not.

Then one specific: describe a bug that only appeared in a release build. There is a right kind of answer — shrinking, signing, a different manifest merge — and an engineer who has never met one has not shipped to a store under pressure.