Android Automotive OSTackling Android Automotive OS (AAOS): A Deep-Dive into Real-World App Integration by Silicon Signals

Silicon Signals Pvt. Ltd.

2 min read

·

May 16, 2025

--

Listen

Share

Recently, our Android team at Silicon Signals took on the challenge of integrating one of our legacy Android applications with Android Automotive OS (AAOS). While Google offers an integration guide for media apps, we faced a unique set of architectural and modular challenges that demanded custom solutions beyond the standard documentation.

Press enter or click to view image in full size

Legacy Code Meets Modern Requirements

• Platform Core (AAP): A modular structure with minimal interdependency, housing player integration, networking, and persistent storage logic.
• App Core (AAL): A tightly coupled structure responsible for the app’s front-end, business logic, and APK generation across multiple app stores.

Most new features lived in AAL, which was deeply dependent on AAP. As we evaluated the AAOS requirements, we realized a naive approach — building AAOS as a feature module on top of the existing base — would bloat the app size, introduce unnecessary dependencies, and increase the risk of breaking functionality due to updates meant for mobile or tablet versions.

Engineering the Right Solution

Rather than layering AAOS on top of our legacy architecture, we rethought the structure:

1. Extracted our MediaBrowserServiceCompat implementation into a new standalone module called mediabrowser.
2. mediabrowser was designed to depend only on what AAOS needed — like playback, library access, and media session handling.
3. Created a new top-level module, automotiveos, which handles AAOS-specific UI, settings, and authentication.
4. Reconfigured Dagger dependency injection to support this new architecture.

This refactor allowed us to decouple AAOS from the legacy mobile architecture, reduce app size, and future-proof the codebase.

The Real Work: Migration and Refactoring

Moving MediaBrowserServiceCompat out of the core base module revealed deep legacy dependencies. The refactor touched over 140 files. But the modular outcome was worth it.

Then came the Dagger challenge. Our new automotiveos module lacked over 150 bindings previously handled by other modules. We tackled this by:

• Creating custom or stub implementations where needed.
• Moving reusable logic to common modules.
• Abstracting app-specific logic into the appropriate module.

We categorized dependencies smartly and rebuilt the graph with minimal disruption.

Lessons Learned

• Creating an abstract MediaBrowserServiceCompat layer helped isolate AAOS and mobile behaviors.
• Testing across multiple AAOS devices is essential due to platform inconsistencies.
• Clear internal documentation and nomenclature (AAOS ≠ Android Auto) avoided confusion.

🚗 Building Android Automotive Solutions with Silicon Signals

At Silicon Signals, we don’t just follow the guide — we re-architect for performance, maintainability, and scale. Whether you’re modernizing a legacy Android app or launching your first AAOS product, we bring deep expertise in modular architecture, embedded systems, and real-time media integration.

📩 Ready to bring your AAOS product to life? Let’s talk!
📧 info@siliconsignals.io
🌐 www.siliconsignals.io