--- title: "Why I stopped trusting device_class to tell me what a device can do ." url: https://daily.dev/posts/why-i-stopped-trusting-device-class-to-tell-me-what-a-device-can-do--mogqnkukf source_url: https://daily.dev/posts/why-i-stopped-trusting-device-class-to-tell-me-what-a-device-can-do--mogqnkukf type: freeform source: "Soumyajit Bhattacharya" author: "Soumyajit Bhattacharya" published: 2026-06-30T19:28:04.868Z updated: 2026-06-30T19:28:28.805Z tags: ["android", "rust", "embedded"] reading_time: 4 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why I stopped trusting device_class to tell me what a device can do . **[Soumyajit Bhattacharya](https://daily.dev/sources/2mzsovrk4b2apltdupzju)** · [@soumyajitbhattacharya](https://daily.dev/soumyajitbhattacharya) · 4 min read · 0 upvotes · 0 comments ## Summary A developer building Gunam, a Rust-based on-premises device management agent, shares how they nearly shipped a silent bug by relying on OS family detection (DeviceClass) to determine OTA update capabilities. The core insight: knowing the OS type doesn't tell you what bootloader or system-level access you actually have. On Android, HAL-level A/B slot switching is only available to OEMs who built the image — a stock app has zero access. The fix was introducing an AccessTier enum (ImageLevel, PrivilegedSystem, AppLevel, ReadOnly) that explicitly models actual permission levels, forcing every OTA function to handle all four tiers at compile time via the type system. ## Content I almost shipped a bug unknowingly. Probably this bug would have shown up on someone else's hardware without them knowing. I'm building [Gunam](https://github.com/IAmInYourKernel/Gunam), a cloud-free, FFI-first Rust agent for on-premises device management — OTA updates, telemetry, panic-safe operation, for environments where you can't assume a server is even reachable. Early on, the design seemed obvious: detect what OS you're running on, then run the OTA strategy that matches that OS. Previously, when I was creating the device class to get the access control of the system, I accidentally never asked the correct question to myself: Is the device class enough to give you complete access? enum DeviceClass { Linux, Android, Windows, Mac, } Detect Linux → use GRUB-style A/B slot switching. Detect Android → use Android's update mechanisms. Simple dispatch table. I was ready to build the OTA logic directly on top of this. The actual question comes, "WHO CONTROLLS THE BOOT LOADER ?" ### The assumption that almost created a **catastrophe** Here's the part I'd glossed over: **that HAL is only reachable if you're the one who built the OS image.** If you're an OEM flashing your own AOSP build, you can talk to it. If you're a regular app — or a `.so` library sitting inside a regular app, which is exactly what Gunam is — you have _zero_ access to it. Not "restricted access." Zero. No permission grants it. It's locked away from userspace apps by design, for the same reason you don't want any random app able to flip your boot partition. So device class doesn't actually tell you whether bootloader-level A/B is available. It tells you the OS family. Whether you can _do_ anything with that OS's update mechanism depends entirely on how the device was deployed — whether you're the OEM or just an app running on stock hardware. If I'd built the OTA dispatch logic directly on `DeviceClass`, the code would have compiled fine, looked correct, and then silently attempted bootloader operations it had no permission to perform — on whichever Android device someone actually deployed Gunam to. That's the worst kind of bug: invisible until a real user hits it. Cost created the catastrophe . ### The solution I got Device classes answer what OS I am, which was not enough to understand how much write and read access I actually have. Here at this point, the introduction of access tiers comes. enum AccessTier { ImageLevel, PrivilegedSystem, AppLevel, ReadOnly }. The same OS can give you different access. As Gunam does telemetry and OTA. Without proper access, the system will give us a permission error, which will block the outcome we want . A Linux kiosk box you flash yourself is Image level. A rooted Android device is Privilege level. A stock Android app — which is most real-world Android deployments — is App level. And critically, there's a tier for "I don't actually know, or I have no access"—read—only— which exists specifically so the agent can say "I can't safely act here" instead of guessing and failing silently later. ### What this actually bought me Beyond avoiding the bug: every OTA-related function in Gunam now has to explicitly handle all four tiers, because the type system makes it impossible to forget one. It goes deep into every layer and asks for permission before it returns the final access control. The main goal of building Gunam was not only to provide telemetry but to build a system that is fault-tolerant. Managing On-premises devices is hard when the system is not ready to handle errors. This blog is not just about sharing the experience but to remind myself that when you have all the answers in the world... Asking the right question at the right time matters. If you'd like to follow the project's progress or contribute, you can find Gunam on GitHub: **GitHub:** [**https://github.com/IAmInYourKernel/gunam**](https://github.com/IAmInYourKernel/gunam) ## Similar posts on daily.dev - [Analyzing the Security Implications of Unlocked Bootloaders](https://daily.dev/posts/analyzing-the-security-implications-of-unlocked-bootloaders-hn4zqpgtq) · droidcon · 0 upvotes · 0 comments - [Android Architecture & Security Model: TEE, Verified Boot, and SELinux](https://daily.dev/posts/android-architecture-security-model-tee-verified-boot-and-selinux-bytgusgtd) · Medium · 0 upvotes · 0 comments - [Who Really Owns Your Smartphone? \(And How to Take Back Control\)](https://daily.dev/posts/who-really-owns-your-smartphone-and-how-to-take-back-control--bc619dw9m) · Medium · 0 upvotes · 0 comments --- Tags: [#android](https://daily.dev/tags/android), [#rust](https://daily.dev/tags/rust), [#embedded](https://daily.dev/tags/embedded) [View this post on daily.dev](https://daily.dev/posts/why-i-stopped-trusting-device-class-to-tell-me-what-a-device-can-do--mogqnkukf)