An open-source, hardware-adaptive, security-first mobile operating system — built on AOSP, built in India, built for everyone.
One OS core. Many hardware profiles. The right amount of software for the hardware you actually own.
What we're building · Why it matters · Start contributing · Roadmap · Honest limitations
tandem (n.) — two things working as one, moving in step. The OS and the hardware, coordinated. That is the whole idea in one word.
Tandem is an AOSP-based mobile operating system that measures what a device can actually do — CPU, RAM, GPU, storage, and thermal headroom — and then configures itself to match. The same OS core runs lean on a ₹7,000 phone and unlocks advanced features on flagship hardware, without shipping two different products.
It is designed from the first commit around four properties most mobile operating systems bolt on later:
| Property | What it means in practice |
|---|---|
| 🧠 Adaptive | Hardware capability is measured, not guessed. Profile is re-evaluated live against thermal, battery, and memory pressure. |
| 🪶 Lean | Background services do not stay alive merely because they exist. Optional modules load on demand, not at boot. |
| 🛡️ Isolated | Five security zones. A compromise in one does not become control of the system. |
| ♻️ Recoverable | Every critical operation has a rollback path and a trusted restore. Bricking should not be permanent. |
The security promise: we do not claim malware can never exist. We claim a compromise will have limited blast radius, be isolated fast, and be recoverable through a trusted path.
Roughly 600 million smartphones in India run Android, and a large share of them are budget devices that ship the same heavyweight software stack as flagships. The result is familiar to anyone who has used one for a year: 3 GB of RAM fighting a launcher that assumes 8, background services nobody asked for, preinstalled bloat that cannot be removed, and a device that feels obsolete long before the hardware actually is.
Meanwhile the security model on those devices is thin. There is no realistic recovery path when something goes wrong, and no isolation model that limits the damage when an app misbehaves.
Tandem is an attempt to fix the software half of that problem. Not by building yet another skin, and not by writing a kernel from scratch — but by building a disciplined policy layer on AOSP that treats low-spec hardware as a first-class target instead of an afterthought, and treats recoverability as a feature instead of a support ticket.
We are building this in the open, from day one, because an operating system that claims to be trustworthy cannot be a black box.
This project is at Phase 0. That is the single best moment to join — the architecture is written but almost nothing is implemented, so early contributors shape the actual design rather than inherit it.
You do not need a test device, an AOSP build machine, or kernel experience to make your first meaningful contribution. Here is real, currently-unclaimed work, sorted by what it asks of you:
| # | Task | Skills | Why it matters |
|---|---|---|---|
| 1 | Build the Hardware Profile Engine simulator — our active milestone | Any language, unit testing | The core of the whole project. Pure logic, fully specified, zero hardware dependency. Full spec → |
| 2 | Design the capability combining rule | Systems thinking, benchmarking | How do 5 capability scores become 1 profile? A weighted average is wrong — it lets 8 GB of RAM hide a terrible thermal envelope. Open design problem. |
| 3 | Define hysteresis parameters | Control theory, systems | Stop the profile flip-flopping on every thermal sample. Needs entry/exit thresholds and dwell times. |
| 4 | Contribute real device benchmark fixtures | Any Android phone | Run benchmarks on the phone in your pocket, submit the numbers. Our test fixtures are synthetic and therefore encode our assumptions rather than reality. Easiest possible first contribution. |
| 5 | Write the threat model | Security research | Eight threat scenarios are scoped and unwritten. Scope → |
| 6 | Prototype the Windows Builder UI | C#/WPF, Tauri, Electron | Six screens are specified. Greenfield app, no OS knowledge needed. |
| # | Task | Skills |
|---|---|---|
| 7 | Launcher prototype | Android, Kotlin, Compose |
| 8 | Resource engine research — map which AOSP knobs already exist vs. what we must build | AOSP framework |
| 9 | Module system design — activation, dependencies, safe deactivation | Android system services |
| # | Task | Skills |
|---|---|---|
| 10 | Device selection analysis — AVB custom-key support across candidate devices | Bootloader, AVB, dm-verity |
| 11 | Verified boot chain design | Secure boot, hardware root of trust |
| 12 | Vendor blob / HAL bring-up strategy | AOSP device bring-up |
Interested in any of these? Comment on the issue to claim it, and say a little about your background. No formal process, no gatekeeping. See CONTRIBUTING.md.
TANDEM
│
┌────────────────────┼────────────────────┐
│ │ │
SECURITY ENGINE ADAPTIVE ENGINE SYSTEM UI
│ │ │
│ HARDWARE PROFILER │
│ │ │
└────────────────────┼────────────────────┘
│
SYSTEM SERVICES
│
ANDROID FRAMEWORK
│
AOSP BASE
│
LINUX KERNEL
│
HARDWARE
Raw hardware readings
↓
Capability model (CPU · RAM · GPU · Storage · Thermal → 5 scored axes)
↓
Static profile (Lite · Balanced · Performance)
↓
Runtime modifiers (battery · thermal · memory pressure · CPU load)
↓
Effective operating profile
↓
├── Feature configuration → System UI
├── Resource configuration → Resource Engine
└── Module configuration → Module System
Design rule: a runtime modifier may only make the profile more conservative than the static profile, never more aggressive. And profile is never decided by RAM alone — that is the shortcut every "lite" Android build takes, and it is why they still stutter.
| Profile | Target hardware | Behavior |
|---|---|---|
| Lite | Very low-spec | Lightweight UI, reduced effects, minimal background services, aggressive suspension, small caches |
| Balanced | Standard consumer devices | Standard UI and multitasking, moderate caching, advanced modules on demand |
| Performance | High-performance hardware | Advanced multitasking, higher resource limits, advanced graphics, desktop-style features |
┌─────────────────────────────────┐
│ ZONE 1 — TRUSTED CORE │ Protected system components
├─────────────────────────────────┤
│ ZONE 2 — VERIFIED SYSTEM │ Signed replaceable components
├─────────────────────────────────┤
│ ZONE 3 — APPLICATION SPACE │ Sandboxed applications
├─────────────────────────────────┤
│ ZONE 4 — USER DATA │ Protected user content
├─────────────────────────────────┤
│ ZONE 5 — QUARANTINE │ Suspicious content, no execution
└─────────────────────────────────┘
Security lifecycle: PREVENT → DETECT → ISOLATE → ROLLBACK → RESTORE
Architecturally distinctive subsystems carry codenames from the Mahabharata and Ramayana. Each was chosen because the mythological function matches the engineering function — not for decoration.
| Codename | Subsystem | Source | Why it fits |
|---|---|---|---|
| Netra | Hardware profiler | नेत्र — eye, vision | The component that sees the device |
| Kavach | Security controller | कवच — Karna's armor, fused to his skin at birth | Protection that is part of the body, not worn over it |
| Chakravyuha | The five security zones | चक्रव्यूह — the layered concentric battle formation | Concentric rings; breaching one is not breaching all |
| Vajra | Trusted core | वज्र — Indra's indestructible thunderbolt | Zone 1: the part that must not break |
| Sanjeevani | Recovery engine | संजीवनी — the herb that revived Lakshmana | Literally "that which brings back to life" |
| Sudarshan | Update & rollback | सुदर्शन — Vishnu's discus, which returns to the hand | The return is the point: rollback to known-good |
Code stays descriptive and greppable (hardware-engine/profiler/,
CapabilityModel). Codenames live in documentation and discussion, and never
replace an explanation. Convention →
We would rather lose your interest now than waste your months. Every one of these is a real, currently-unsolved constraint:
⚠️ Banking and UPI apps will not work on V1 — click to expand
An unlocked bootloader fails Google's Play Integrity API. Most Indian banking apps, GPay, PhonePe, and Paytm check it and refuse to run. Achieving GMS certification requires a CTS/CDD-passing build and a commercial agreement with Google — not realistically available to a pre-revenue project.
Honest V1 statement: a phone that runs most Android apps, but not banking or UPI. In India this is the difference between a daily driver and a secondary device. Solving it is a distribution and partnership problem, not a coding problem, and we have not solved it.
⚠️ Verified boot vs. market reach is a real fork — click to expand
Our verified boot chain requires re-locking the bootloader with a custom AVB key. Pixels support this. Most Xiaomi, Realme, and Samsung devices — the phones actually in Indian hands — do not.
- Pick a Pixel → the full security model works, but on a phone that is not the Indian mass market.
- Pick a cheap popular device → market reach, but hardware-enforced verified boot largely evaporates and the security zones become software conventions.
You cannot have both on device 1. This decision is open, and it is the single highest-leverage call in the project. Analysis →
⚠️ "Runs on old low-spec phones" is harder than it sounds — click to expand
Old budget devices are the worst targets for a custom OS: locked bootloaders, unpublished kernel source, unobtainable vendor blobs, kernels stuck on 3.18/4.9. The Lite profile is a software capability — it does not make an unsupportable device supportable. Adaptive profiles and device support are independent problems.
⚠️ Realistic timeline is years, not months — click to expand
The roadmap below sums to 12–24 months. For a genuinely daily-drivable OS — camera, modem, VoLTE, and battery all working properly — 2–4 years is the honest estimate at current team size. Camera HAL and modem/VoLTE bring-up are where experienced multi-person ROM teams stall.
This is exactly why we are recruiting. More contributors is the only variable that meaningfully changes this number.
⚠️ Much of the adaptive layer overlaps existing AOSP features — click to expand
Android already has lowmem thresholds, Go edition, thermal HAL 2.0, cached app freezing,
and App Standby buckets. A large part of our engine will be re-expressing knobs that exist,
in a coherent documented policy layer.
We think a unified, inspectable, user-visible policy layer is genuinely better than Android's scattered heuristics — but it is a tuning and integration product, not a new capability, and we are not going to pretend otherwise.
| Phase | Focus | Target | Status |
|---|---|---|---|
| 0 | Research & architecture | 2–4 weeks | 🟡 In progress |
| 1 | Windows Builder prototype | 2–4 weeks | ⚪ Not started |
| 2 | Hardware Adaptive Engine | 3–6 weeks | 🟡 Milestone 001 — active |
| 3 | Custom mobile experience | 1–3 months | ⚪ Not started |
| 4 | AOSP integration — first bootable image | 2–4 months | ⚪ Blocked on device selection |
| 5 | Module system | 2–4 months | ⚪ Not started |
| 6 | Security & recovery | 3–6 months | ⚪ Not started |
| 7 | Windows installer | 1–3 months | ⚪ Not started |
SUPPORTED DEVICE + BOOTABLE AOSP-BASED OS + CUSTOM MOBILE EXPERIENCE
+ HARDWARE PROFILING + ADAPTIVE PROFILE + RESOURCE MANAGEMENT
+ BASIC MODULE CONTROL + VERIFIED IMAGE + RECOVERY PATH + WINDOWS INSTALLER
We do not add anything else before reaching this milestone.
This is where the project is right now, and where you can help most.
Takes CPU / RAM / GPU / storage / thermal / device-feature inputs and emits an OS profile plus feature, resource, and module configuration. It runs as a standalone simulator first — no device, no AOSP build, no bootloader required.
Inputs Outputs
────── ───────
CPU OS Profile (Lite / Balanced / Performance)
RAM Feature Configuration
Storage Resource Configuration
GPU Module Configuration
Thermal Capability
Device Features
Open design problems — genuinely undecided, your input shapes them:
- The combining rule across the five capability axes
- Hysteresis thresholds and minimum dwell time
- Implementation language and runtime
- Where threshold values come from — measured benchmarks or judgment
📄 Read the full specification →
| Document | Purpose |
|---|---|
| docs/plan.md | Master plan — vision, architecture, roadmap, MVP |
| docs/architecture.md | Layer-by-layer technical architecture |
| docs/security-model.md | Zones, boot chain, isolation, recovery |
| docs/device-support.md | Device selection criteria and expansion |
| docs/hardware-profile-spec.md | Milestone 001 specification |
| docs/development-log.md | Dated decisions and progress |
| CONTRIBUTING.md | How to contribute |
docs/ Specifications and decision records
hardware-engine/ Hardware profiler, capability model, profile manager
resource-engine/ Memory, CPU, background, thermal policy
module-system/ Core / dynamic / optional module definitions
security/ Isolation, integrity, quarantine, recovery
system-ui/ Launcher, notifications, quick settings, settings
windows-builder/ Windows companion: detect, configure, validate, install, recover
tests/ Unit, integration, device, security
These are not aspirational. They are enforced in review.
- Build one working vertical slice at a time. No half-finished layers.
- Never modify boot or security components without a recovery path.
- Keep the first supported device extremely limited. Breadth kills OS projects.
- Do not invent cryptography. Established primitives and platform mechanisms only.
- Do not trust AI-generated code without testing. This project uses AI assistance heavily and reviews it adversarially.
- Every major system change must be reversible during development.
- Maintain reproducible builds and documented configuration.
Project principle: Build one secure core. Detect the hardware. Enable only what the device needs. Isolate what can fail. Recover what is compromised.
You will fit here if you are an AOSP / Android platform engineer, Linux kernel or embedded developer, mobile security researcher, Kotlin / Android UI developer, desktop app developer (C#/WPF, Tauri, Electron), technical writer, or a student or self-taught developer who wants to learn operating systems by building one.
You will fit here especially if you have ever looked at a budget Android phone and thought the software was the thing holding it back.
Not sure you're qualified? Task #4 — running a benchmark on the phone in your pocket and submitting the numbers — is a genuinely useful contribution that takes fifteen minutes. Our fixtures are synthetic right now, which means they encode our assumptions instead of reality. Real numbers from real devices fix that.
Read CONTRIBUTING.md, then:
- Pick a task from Where to start
- Comment on the issue to claim it
- Discuss the approach before writing large amounts of code — the design is still moving
- Submit a PR with tests and a note on what you verified
Every contribution needs: clear requirements, defined inputs and outputs, test cases, failure cases, and stated security constraints.
Other ways to help that are not code:
⭐ Star the repo — visibility is how we reach the systems engineers we need 📱 Submit device benchmark data 🔍 Review the architecture and tell us where it is wrong ✍️ Improve documentation 📣 Share with someone who does AOSP work
Is this a custom ROM or a new operating system?
Today, an AOSP derivative — a custom ROM with a serious architectural layer on top. Long term the plan allows progressively replacing deeper layers. We are not writing a kernel from scratch; that is a separate multi-year project with no user-facing payoff at the start.
Why not just use LineageOS / GrapheneOS / CalyxOS?
They are excellent and you should use them if they fit. They target privacy (GrapheneOS, CalyxOS) or device longevity and breadth (LineageOS). None of them treat hardware-adaptive resource policy as the core product, and none target low-spec hardware as a first-class case. That gap is what this project is about.
Will my banking / UPI app work?
Not on V1. See Honest limitations. This is the most important thing to understand before getting excited.
Which device will it run on?
Not yet decided — and it is the highest-leverage open decision in the project. Criteria and analysis →. Input from anyone with AVB and bootloader experience is extremely welcome.
Can I use this today?
No. Phase 0, planning stage, no bootable image yet. Star or watch the repo to follow progress.
Is this an "Indian OS" project like BharOS?
It shares the motivation but not the framing. We are being deliberate about separating three different goals:
| Goal | Solo/small-team viable? |
|---|---|
| A clean, fast, de-bloated Android OS people can flash | Yes |
| A hardware-adaptive, modular, recoverable OS | Yes, over years |
| A sovereign OS with app-ecosystem independence | No — needs OEM, NPCI, and regulatory partnerships |
We are attacking the first two. BharOS and IndusOS both showed the technical build was never the hard part — adoption was. That is a sequencing problem: build something genuinely excellent on one device, earn real users, and let scale follow.
Is this AI-generated slop?
The project uses AI assistance heavily and says so openly — Rule 5 exists precisely because AI-generated code is not trustworthy without testing. Every module requires tests, failure cases, and stated security constraints before merge. The architecture decisions, and the honest limitations section in particular, are human judgment calls.
Not yet selected. Candidates under consideration: Apache 2.0 (AOSP-compatible, permissive) or GPLv3 (copyleft). Input welcome — open an issue. Kernel modifications will be GPLv2 by requirement regardless of the choice for the rest of the project.
Open an issue for anything technical. For collaboration, partnership, or press, open a discussion thread.
If you have ever thought a budget phone deserved better software — this is the project.
⭐ Star this repo to follow progress · 🛠️ Pick a task to start building
Topics: tandem · tandem-os · android · aosp · mobile-os · operating-system · custom-rom · android-rom
· mobile-security · verified-boot · secure-boot · hardware-adaptive · resource-management
· low-end-devices · budget-smartphones · system-ui · launcher · kotlin · linux-kernel
· open-source-os · privacy · india · made-in-india · indian-os · digital-sovereignty
Tandem — open-source hardware-adaptive secure mobile operating system. Built on AOSP. Built in India. Built in the open.