Moschip Technologies Ltd · NSE:MOSCHIP
Moschip Technologies — Technical Presentation (October 2026)
31 slides from Moschip Technologies's technical presentation, October 2026
Slide 1: Engineering The Tech Stack For Android Products
Engineering The Tech Stack For Android Products The stack stays. The constraint moves. www.moschip.com 1
Slide 2: Agenda
Agenda Parul FROM PLATFORM FOUNDATIONS TO PRODUCTION-READY PRODUCTS Aggarwal 01 Why the Android Stack Matters Director - Product Engineering Services From board bring-up to a production-ready product 02 Engineering the Android Stack Layers, budgets, contracts and upgradeability Vinod Kumar Galla 03
Slide 3: The demo takes weeks. The product ships in months.
The demo takes weeks. The product ships in months. Weeks Months Demo: AOSP + BSP on dev board Your board, peripherals and HALs Power and thermal Boot time and performance OTA and lifecycle Certification The demo day Product ships Today: everything to the right of the dashed line, and how to plan it
Slide 4: Android is beyond the phone now.
Wearables & XR Consumer Industrial Healthcare Automotive Android is beyond 2024 Google TV and Android TV OS pass 270 million monthly active devices. the phone now. 2025 Android XR ships on Samsung Galaxy XR. Wear OS 6 brings Android 16 to watches. 2026 AAOS SDV announced: Android beyond infotainment
Slide 5: AOSP: Six Layers And One Boundary That Matters.
AOSP: Six Layers And One System side Boundary That Matters. Apps / HMI you Not in AOSP Framework Java / Kotlin APIs Google Mobile Services Play Store and Play Services. Licensed; requires passing compatibility tests (CTS). System services system_server Google Automotive Services Native libs + runtim
Slide 6: AOSP Is Tuned For A Phone. Your Device Isn't One.
AOSP Is Tuned For A Phone. Your Device Isn’t One. A phone assumes Your device may need Where it lands All-day listening on a coin cell, or no fan A battery, charged nightly Kernel · HAL · power behind a dash One user, one display Three displays, two users, separate audio Framework · services Apps fr
Slide 7: Four questions decide where the engineering goes.
Four questions decide where the engineering goes. 1 2 3 4 Budget Layer Contract Upgrade What number must Which layer owns the Which interface must What does it cost at this product hold? requirement? stay stable? the next release? mW · ms · °C · seconds to App · framework · service · So layers can c
Slide 8: Budget
1 Budget Measure it as Typical tools Power mW at idle and in use Power rails · Battery Historian Latency ms at p95, under load Perfetto · timestamps Budget Memory Peak MB · behaviour under pressure meminfo · LMK events Start from a number, not a Thermal °C sustained, not at 30 seconds Thermal HAL ·
Slide 9: Layer
Requirement Owning layer From the engagements ahead 2 Change what the user sees Users, displays, boot, device Apps / HMI Framework · services Clinical interface on a bedside monitor Driving-mode themes across three Layer policy cockpit screens A media, graphics or audio Camera-to-display path in low
Slide 10: Contract
Framework side Vendor side 3 Stable AIDL interface System services Kernel driver Versioned: frozen, can only grow Declared in VINTF manifest Apps, via your SDK MCU · DSP Contract Timeout and fault semantics Power behaviour: wake, batching A HAL is a Test harness Firmware A test double for the framew
Slide 11: Upgrade
Q2 · Major release + AOSP source Q4 · Minor SDK + AOSP source 4 Android 17, June 2026 J F M A M J J A S O N D Upgrade High-risk security fixes, monthly Security bulk, quarterly Platform + AOSP source Every customisation is Carried through every release Cheap a line item at the Framework patches Chan
Slide 12: The stack stays. The constraint moves.
Engineering weight by layer, in a typical programme Consumer Wearables & XR Industrial Healthcare Automotive Standby power · A/V sync Milliwatts · camera-to- Peripheral I/O · uptime Data integrity · alarms All of it, plus a safety display boundary Apps / HMI Framework System services Native libs + r
Slide 13: Consumer
Consumer The budget is standby current. Standby current Wake latency False wakes mA while always listening ms from keyword to per day, in a real room response Use-case path Apps / HMI Wake-word Framework + Mic + codec ALSA driver Audio HAL Framework hotword path engine app System services audio poli
Slide 14: Always listening, almost asleep.
Always listening, almost asleep. Android software for a custom voice-processor SoC The ask Always-on voice wake-up on a custom TI OMAP voice SoC, at a very low standby-current target. Why it was hard Drivers, HAL, framework and firmware had to agree on when the system may wake. What we changed in th
Slide 15: Consumer appliances
Consumer appliances Here, the work moves up the stack: screen, connection, camera and AI. Smart refrigerator HMI Smart-home controller AR appliance placement Android HMI on a 10" touch screen. An internal Android tablet app that brings Matter and Android AR app that detects walls and floors, camera
Slide 16: Wearables & XR
Wearables & XR The budget is milliwatts, and milliseconds. Idle current Camera-to-display Sustained thermal across a full day ms, end to end °C, on the body Use-case path: wearable power Apps / HMI Wakelocks + Wi-Fi Doze + Deferred Sensors + radios suspend scanning Battery Saver app work Framework w
Slide 17: Asleep when it can be. Connected when it must be.
Asleep when it can be. Connected when it must be. Android wearable on NXP i.MX 8M, running in kiosk mode The ask Better standby power, while keeping continuous sensing, kiosk mode and normal app behaviour. Why it was hard Doze never kicked in. Wakelocks, Wi-Fi scans and background jobs kept the devi
Slide 18: Industrial
Industrial The budget is the operator’s shift. Peripheral I/O Uptime Recovery ms per scan, hundreds a weeks, not hours network loss, power loss shift Use-case path Apps / HMI workflow HMI Scanner · GPIO · Driver HAL System service Operator HMI Framework kiosk mode PLC System services device owners H
Slide 19: Light on the head, heavy on the workflow.
Light on the head, heavy on the workflow. AR-guided warehouse picking The ask Guide pickers hands-free to the right shelf, validate each scan, serve the next task. Why it was hard AR needs compute; a full shift needs light glasses; every step is a WMS transaction. What we changed in the stack Partit
Slide 20: Healthcare
Healthcare The budget is trust in the data path. Data integrity Alarm latency Uptime sensor → screen → remote bounded and known days at the bedside Use-case path Apps / HMI clinical HMI Device Medical sensor HAL State service Clinical HMI Framework lock-down interface System services alarm · state C
Slide 21: An alarm is a state machine, not a notification.
An alarm is a state machine, not a notification. Android bedside patient monitor on NXP i.MX The ask Continuous bedside monitoring of six vital signs, mirrored on care-team phones. Why it was hard Each value must mean the same thing on screen, in alarms, in history and remotely. What we changed in t
Slide 22: Automotive
Automotive Every layer at once, beside a safety domain. Time to usable Displays and zones Service life seconds from wake one SoC, several people fifteen years of updates Use-case path Apps / HMI SystemUI · launcher CAN · LIN · SystemUI + Driver · VHAL (AIDL) CarService Framework Car API Ethernet lau
Slide 23: "Android in the car" means three commitments.
Projection Built in Beyond infotainment Android Auto Android AAOS SDV Automotive OS The phone runs the experience; Android is the head unit. VHAL, Headless Android on VirtIO for the head unit displays it. Nothing CarService, boot, displays, audio body, cluster and telemetry to engineer, nothing to z
Slide 24: Draw the safety boundary first.
Android / AAOS domain Safety domain Engineered IVI · media · navigation · apps Cluster telltales · ADAS · real-time control boundary Draw the safety 1 Isolation 2 Communication ECU, hypervisor or partition: CPU, Defined interfaces, and defined boundary first. memory, interrupts, I/O behaviour when d
Slide 25: Three screens, one car.
Three screens, one car. Triple-display EV cockpit on NXP i.MX95 with Android Automotive OS The ask Centre IVI, cluster and passenger display with live EV data, voice, navigation, themes. Why it was hard Three screens are easy. Three sharing one vehicle state, with separate roles, are not. What we ch
Slide 26: Migrate, port or re-architect: three different plans.
Migrate, port Engineering scope rises → or re-architect: three different plans. Re-architect One system → domains Split into isolated domains. The path Port 1 Inventory every change towards SDV. One SoC → another 2 Decide: keep, adapt, replace or drop Re-map BSP, kernel, drivers and HALs; Migrate re
Slide 27: Design the update path before the first release.
Four updates cycle, one device Monthly Quarterly Q2 · Q4 Yours High-risk security fixes Security bulletin bulk Platform release + AOSP Product features source Sign Package Deploy Verify Recover Who owns the keys for A/B or virtual A/B slots; Staged: a hundred Boot, critical services Automatic rollba
Slide 28: On-device AI is the next budget.
On-device AI is the next budget. The same four questions, applied to a model on the device. In practice Time to first token · tokens per second · Budget peak memory · heat sustained at minute On-device LLM SDK ten One API across three model formats; NPU, GPU or CPU chosen at runtime; live Layer A pl
Slide 29: The stack stays. The constraint moves.
The stack stays. The constraint moves. Know your constraint and you know which layers your team will live in. Before you choose silicon, answer four questions Budget Layer Contract Upgrade What number must this Which layer owns each Which interfaces must stay What will each change cost at product ho
Slide 30: We work across the stack, from silicon to systems
We work across the stack, from silicon to systems 360° meeting camera Wear OS smartwatch platform Designing Intelligent Products We design chips, bring up boards and write the drivers under the platform. A late frame or a misbehaving HAL is one team AR glasses for entertainment Self-service kiosk, e
Slide 31: Thank you!
Thank you! www.moschip.com | contact@moschip.com Ahmedabad Bengaluru Hyderabad (HQ) Pune Santa Clara - USA Engineering The Tech Stack For Android Products www.moschip.com 31
MosChip Technologies — Technical Presentation (October 2026) on 6ix