Hardware lifespan vs software support lifespan

Consumer Android phones are designed around a two-to-three year replacement cycle. Rugged industrial devices are not. A device built for a warehouse, a hospital, or a field survey kit is expected to run for five to seven years — sometimes longer. The hardware is overspecified precisely so it doesn't need replacing.

But Android software support doesn't work on that timeline. It works on the chip manufacturer's timeline.

The BSP lifecycle

Every Android device runs on a chip. Every chip manufacturer — Qualcomm, MediaTek, Samsung Exynos — provides a Board Support Package: the proprietary drivers, firmware, and binary blobs that make Android talk to the hardware. When the chip manufacturer stops updating the BSP, the Android version is frozen. Not because the hardware is incapable. Because the proprietary layer underneath it has been abandoned.

For Qualcomm's Snapdragon 630 — used in the CAT S61 — the BSP was frozen at Android 9. The chip can run Android 9. It will always be able to run Android 9. It will never officially run Android 10, not because of anything the user did or anything wrong with the device, but because Qualcomm's support contract for that silicon ended.

The hardware manufacturer cannot ship a newer Android version without a BSP update. Paying Qualcomm to produce one for an end-of-line device is not commercially viable. So the device stays on Android 9, indefinitely, in perfect working order.

What EOL actually means

End of life does not mean broken. It means:

• No further Android OS version updates
• No further security patches from the manufacturer
• No further guaranteed compatibility with new apps

It does not mean the device stops working. It does not mean its specialist hardware — thermal cameras, barcode scanners, depth sensors — stops functioning. It does not mean the user should throw it away.

The device a building inspector uses to find heat leaks in a wall cavity does not need Android 14. It needs Android 9 to keep running stably, the FLIR sensor to keep reporting accurate data, and apps installed on it to stop breaking things they have no business touching.

Why apps destabilise these devices

API level mismatches

Apps targeting Android 12+ use permission models, background process restrictions, and camera access patterns that behave differently or are absent on Android 9. The app assumes behaviour that doesn't exist.

Speculative hardware access

Some apps probe the camera, microphone, or sensor stack on startup regardless of whether their features need it. On standard devices this is wasteful but harmless. On devices with dual-HAL configurations or proprietary sensor drivers, it can destabilise the system service that manages that hardware for every other app on the device.

No compatibility gate

The app never checks whether it can run correctly before initialising. It installs, starts, probes, conflicts, and crashes — leaving the device in a degraded state that can persist for hours while Android's exponential backoff recovery runs.

Why the user never knows

Android's crash recovery is silent. When a system service like cameraserver or mediaserver fails, Android tries to restart it automatically. If it keeps failing, the retry interval doubles each time:

The device appears sluggish or partially unresponsive. Apps that depend on the affected service stop working. The user sees a slow device. They don't see "the Sonos app destabilised your camera HAL." They assume the device is failing. They may assume it's time to replace it.

The fix

App publishers can prevent this entirely without ever testing on the affected device. Declaring hardware requirements accurately in the app manifest causes Google Play to filter incompatible devices before the install button is shown. A runtime compatibility check on first launch catches anything the manifest filtering misses.

Neither requires testing on exotic hardware. Both require honesty about what the app actually needs to run correctly.

Implementation details for publishers →