Android Internals & Custom ROM: When You Need to Go Deeper Than the App Layer
May 22, 2026
99% of projects that use the phrase "Android app" actually need a regular user-space application running on standard Android. The other 1% — secure systems for enterprises, dedicated industrial devices, branded OEM products, defense-grade communications, and cybersecurity platforms — needs something entirely different: Custom ROM development and Android Internals work. This article covers when you actually need to go deeper than the app layer, and what it really takes. iGates has worked in this discipline for over 15 years, and was the R&D partner behind Consensio Cyber Security's platform — one of the cleanest examples in the Israeli market of a security product built on a customized AOSP.
What Android Internals and Custom ROM mean
"Android Internals" is the general name for work at the operating-system level of Android — as opposed to developing an application that runs on top of it. When you build an app with Kotlin or Java, you use the Android SDK and operate above the framework. When you work on Android Internals you write the framework itself, the HAL, the kernel layer, or the system services that provide the APIs ordinary applications consume.
A "Custom ROM" is the output of Android Internals work: a customized build of AOSP (Android Open Source Project) that includes system-level changes — a dedicated kernel, modified framework, HAL for specific hardware, hardened SELinux policy, pre-installed packages, removal of unwanted components, and security logic built into the operating system rather than layered on top of it. LineageOS and GrapheneOS are open examples, but the serious enterprise model is a hardware-specific Custom ROM with a long-term security-update process.
When does a product actually need Custom ROM?
This is one of the most important questions to clarify before starting an expensive and long-running project. Six cases where Custom ROM is the right answer:
1. Cybersecurity systems built on Android. When the product itself is a security solution — secure communications, integrated MDM, forensics-resistant devices, secure containers — it can't be based on stock Android. You need control over every layer: kernel, SELinux, framework, identification mechanisms, app installation. Example: the Consensio platform that came out of iGates' R&D lab.
2. Dedicated industrial devices. POS terminals, outdoor field devices, scanners, kiosks. The need: remove all of Android's standard UX, install a single app as the only interface, prevent end users from exiting it, and guarantee kiosk mode. Single-app mode requires framework-level changes.
3. OEM customization. Hardware manufacturers need Android with branding, unique features, and sometimes integration with hardware components that don't exist in typical Android devices.
4. Device hardening for healthcare, finance, and defense organizations. Compliance requirements that exceed what MDM can enforce — meaning security built into the firmware itself.
5. Defense-grade systems. Field devices for soldiers, secure handhelds, radio products with an Android UI — classification requirements that can't be addressed with MDM alone.
6. IoT with an Android interface. Industrial controllers with touchscreens, smart-home platforms, medical equipment with UI — when the need is "Android for one device, not for a phone."
The flip side: when you don't need Custom ROM. When the solution is reachable through MDM, Android Work Profile, or Managed Google Play. These are cheaper, faster, and don't require ROM maintenance. At iGates we honestly recommend MDM when it's enough — Custom ROM is right only when something about the device fundamentally must be different at a level you can't reach through policies.
The technical stack — what's in Android Internals
AOSP base (Android Open Source Project — Google's source tree) Linux kernel with Android-specific patches like binder, ashmem, low memory killer and wakelocks Bootloader such as U-Boot, Little Kernel, or Tianocore for ARM Hardware Abstraction Layer (HAL), including Camera HAL, Audio HAL, GPS HAL, Sensors HAL and Treble Native daemons such as init, ueventd, vold, surfaceflinger and mediaserver System Server — the heart of Android: Activity, Window, Power and more Android Framework — the Java/Kotlin APIs apps consume System apps — launcher, settings, dialer, contacts SELinux policy — mandatory access control across the system
Android Internals work can touch any of these layers. Examples from real projects:
- Kernel customization: developing a new driver for dedicated hardware, tuning real-time performance, or integrating kernel-level security mechanisms.
- HAL development: when a hardware-component vendor didn't provide a HAL, or the existing HAL doesn't fit. Work in AIDL/HIDL depending on Android version.
- Framework modifications: changes in the System Server to add custom permissions, behavior changes based on organizational policy, or different UI on system surfaces.
- SELinux policy: writing custom policy that enforces the product's security model. One of the critical layers in security products.
- System apps: replacing the launcher, blocking app installation from stores, internal management features.
- OTA system: building a long-term signed-update mechanism with rollback.
iGates' experience in Android Internals — Consensio and beyond
iGates has been working on Android Internals for over 15 years — from the days of Android 2.x to today. Our services in the area include Custom ROM development from scratch, AOSP adaptation to new hardware, HAL development for unsupported peripherals, SELinux hardening to defense-grade, and building long-term security-update infrastructure.
The flagship example from recent years is the Consensio Cyber Security platform. iGates was the R&D partner behind the solution — a combination of Android Internals, custom kernel work, SELinux hardening, and framework modifications inside a complete security product. This experience is far from trivial at Israeli market scale: most Israeli cybersecurity companies build Android apps that sit on top of the system. Building a security product that intervenes inside the system is a different game entirely — one that requires combined expertise in AOSP, kernel, cryptography, and policy engineering.
iGates' Custom ROM development process
A typical engagement starts with a 3-4 week feasibility study summarizing: which chipset/SoC the product runs on, which kernel base is available, what the vendor BSP looks like, how long the Android version will be supportable, and what the security and compliance constraints are. The feasibility sometimes yields a non-trivial conclusion: "what you're planning is better done in MDM, and here's why."
After feasibility:
- AOSP base selection — which version (Android 14, 15, 16), which branch, and which vendor base.
- Hardware bring-up — if this is a new board, or if we've replaced the OS entirely. Includes drivers, HAL, and Device Tree.
- Customization layer — what changes in the system server, framework, and system apps. Includes UI, behavior, permissions.
- Security hardening — SELinux policy, verified boot setup, signature chain, key management.
- OTA infrastructure — building a signed-update mechanism with verification, rollback, and a long-term security-update process.
- CI/CD for ROM — automation of AOSP builds, tests, and deployment.
- Long-term maintenance — monthly Android security bulletins from Google, kernel CVE patches, vendor updates. A system without this process ages quickly.
What does this look like in cost and timeline?
For order-of-magnitude only:
- POC ROM on reference hardware: 3-4 months, $75K-$150K
- Full production ROM with OTA and 3-5 significant changes from stock: 8-14 months, $250K-$700K
- Full security platform with defense-grade hardening, custom kernel work, and a multi-year support contract: 18+ months, growing from $700K+ depending on scope
This is an expensive game. The reason: AOSP builds themselves consume thousands of compute hours, every kernel change requires thorough validation, and every new Android version requires a complex merge.
Summary
Custom ROM and Android Internals are relatively rare disciplines in the Israeli market. They're relevant only when a product genuinely cannot run on standard Android + MDM — that is, when the product itself intervenes inside the operating system. iGates, with 15 years of experience in the field, is one of the few addresses in Israel that can take a project like this from feasibility through shipped product and long-term post-launch support. If you're considering a platform that sits inside Android rather than on top of it, a 30-minute initial conversation with our team will save you months of trial and error.
Related articles and services
FAQ
What's the difference between Android app development and Android Internals?
App development runs on top of the operating system — Kotlin or Java using the Android SDK and operating against APIs the framework provides. Android Internals is work at the system level itself: kernel customization, HAL development, modifications to the framework and System Server, SELinux policy. It is a much rarer discipline requiring understanding of AOSP, the Linux kernel, and Android Treble.
When should you choose Custom ROM vs MDM?
MDM solves most enterprise management needs: device policies, application control, encryption enforcement, and remote wipe. Custom ROM is required when the need extends to the system level — a security product that intervenes in the OS, full single-app kiosk mode, OEM customization, or defense-grade hardening that requires kernel and SELinux changes.
What is Treble and why did it change the game?
Treble, introduced in Android 8 in 2017, separates the system partition from the vendor partition. The vendor partition holds the HAL and hardware-specific drivers; the system partition holds generic AOSP. This separation lets you update the system without touching vendor components, dramatically simplifying long-term security updates.
Can you build a Custom ROM on commercial devices?
Pixel is the most Custom-ROM-friendly device because Google publishes AOSP sources and documentation for every Pixel. Samsung, OnePlus, and others are sometimes possible but more complex because of bootloader unlock policies and Knox. In most serious security projects, clients choose dedicated hardware or an OEM partnership.
How long does Custom ROM development take?
A POC on reference hardware usually takes 3-4 months. A production ROM with OTA and 3-5 significant changes takes 8-14 months. A full security platform with defense-grade hardening can take 18+ months. We always start with a 3-4 week feasibility study that summarizes timeline and cost.
What is SELinux and why does it matter in Custom ROM?
SELinux is the Mandatory Access Control system built into every Android device since Android 5. It controls which process can read which file, which syscalls each process may make, and the blast radius of a security breach. In Custom ROM, custom SELinux policy is essential to enforce the product's security model.
More articles
