Your phone app runs on top of the world. A car app runs on top of a world that also has wheels, brakes, a battery, and a driver who must not look at the screen for long. If you are an Android developer today, you already own about sixty percent of what you need to build for cars. This guide shows you the other forty percent, in the order you should learn it.

The cars on the road are changing fast. Carmakers no longer want a locked, closed infotainment system. They want Android running as the operating system of the vehicle itself, called Android Automotive OS, or AAOS. That is different from Android Auto, which only mirrors your phone on the car screen. With AAOS the car runs Android natively, and that creates a huge need for people who understand both Android and the car.

This article walks you through four roles. First the automotive app developer, then the framework developer, then the middleware developer, and finally the VHAL developer, who sits closest to the vehicle. You do not need to learn all four at once. Each step builds on the one before it, and by the end you will know exactly what to study and why.

The Big Picture, Android as a Building

Think of the Android system as a building with floors. As an app developer you live on the top floor and rarely visit the basement. In automotive you will take the lift down, floor by floor.

1. Apps, the top floor. Media, navigation, climate screens, launcher, settings. This is where you start.
2. Framework, the second floor. Java and Kotlin services inside the system. Car Service lives here. It decides what apps are allowed to know about the car.
3. Middleware and native services, the third floor down. C plus plus code that talks to audio, camera, display, power and communication.
4. HAL and VHAL, the ground floor. The Hardware Abstraction Layer is a clean doorway between Android and the hardware. VHAL, the Vehicle HAL, is the doorway for vehicle data such as speed, gear, fuel, door state and HVAC.
5. Kernel and the car network, the basement. Linux drivers, the CAN bus and the control units that sit in the car.

A simple example makes this real. When the driver changes gear to reverse, the gear sensor sends a message on the CAN bus. The kernel receives it, VHAL converts it into a vehicle property, Car Service passes it to apps that asked for it, and your app shows the rear camera. One tap of a lever travels through every floor. A good automotive developer understands the whole journey, even if they work on only one floor.

Step 1, Build Automotive Apps and Learn What Changes

Start where you are comfortable. Your Kotlin, Jetpack, coroutines and lifecycle knowledge all carry over. What changes is the rules of the road, literally.

First, learn the app categories the car supports. Media apps use MediaBrowserService and MediaSession, so you must know them well. Navigation, charging, parking and messaging apps use the Car App Library, which gives you ready made templates instead of free form screens. Free form layouts are mostly reserved for system apps built by the carmaker.

Second, learn driver distraction rules. When the car moves, the system restricts what your screen can show. Text input, long lists and video may be blocked. The Car UX Restrictions API tells your app when the car is parked or moving, and you must design for both. Buttons are bigger, text is shorter and every flow must work in two or three taps.

Third, learn the car specific APIs. The android.car package gives apps access to vehicle data through managers such as CarPropertyManager for speed, gear and fuel, CarAudioManager for audio zones, and CarUxRestrictionsManager for driving restrictions. Learn how permissions work here, because many car permissions are granted only to system or privileged apps.

Fourth, get used to the car environment. Screens are large and come in odd shapes. There can be several displays, such as a main screen, an instrument cluster and a passenger screen. Several users can share one car, and the system switches between them. Your app must survive all of this without crashing.

A good first project is a simple media player or a vehicle data viewer app that shows speed and gear from the emulator. When this feels easy, move down one floor.

Step 2, Learn to Build and Read AOSP

This is the biggest mindset change. An app developer downloads libraries. A platform developer downloads the entire operating system, which is the Android Open Source Project, or AOSP, and builds it from source.

Begin with the basics of the source tree. Learn how to sync the code using repo and git, how the folders are arranged, and where packages, frameworks, system, hardware and device folders live. Then learn the build system. Modern Android uses Soong, driven by Android.bp files, while older parts still use Android.mk. Learn the lunch command, which selects a target such as an automotive emulator build, and learn how to build only one module instead of the whole system, because a full build can take hours.

Next, learn to run what you built. Use the automotive emulator or Cuttlefish, a virtual device that runs full AOSP builds on a Linux machine. Learn adb deeply, including adb shell, adb push, adb remount, logcat, dumpsys and service list. Dumpsys is a superpower. It lets you ask any system service what it is thinking right now, including Car Service.

Finally, learn to read code more than you write it. Platform work is ninety percent reading and ten percent writing. Practice finding where a feature lives, following a call from an app down into the framework, and changing one small thing to see the effect. Your machine also matters. Plan for a strong Linux computer with plenty of memory and fast storage, because AOSP builds are heavy.

Step 3, Become a Framework Developer

The framework is the brain of the system. It is where Java and Kotlin system services run, and where Car Service lives. Car Service is a privileged service that manages everything car related, including vehicle properties, audio, power, user switching, occupant zones and driving restrictions. Apps never talk to hardware directly. They talk to Car Service, and Car Service talks down.

Here is what to learn, in order.

1. Binder and AIDL. Binder is how processes talk to each other in Android. AIDL is the language you use to describe those conversations. Almost every framework and HAL interface in modern Android is written in AIDL, so this is your most important tool.
2. How system services start. Learn SystemServer, how services register with ServiceManager, and how a manager class such as CarPropertyManager wraps a service for apps to use.
3. Android permissions and security. Learn signature permissions, privileged apps, and above all SELinux. When a change you made works on a developer build but fails on a real build, SELinux is usually the reason. Read denial messages in the log and learn how to write a policy rule that fixes them correctly.
4. Car Service internals. Study how it handles power states such as suspend, resume and garage mode, how it enforces driver distraction rules, how it manages users and displays, and how audio focus and audio zones work in a car with many speakers.
5. Customization. Carmakers rarely use AOSP untouched. Learn runtime resource overlays, which let you change values without editing the source, and learn how to add a new system service or a new manager API for your own feature.

A good practice project is adding a small custom service to Car Service, exposing it through AIDL, and calling it from a test app. If you can do that, you already think like a framework developer.

Step 4, Grow into Middleware

Middleware is the glue between the framework and the hardware. It is mostly native code written in C plus plus, running as separate processes, and it is where many automotive features are really built. Think of the rear camera, the audio engine, the instrument cluster data feed, voice services, and the gateway that connects Android with other computers in the car.

The first skill is C plus plus itself. You do not need to be a wizard, but you must be comfortable with pointers, memory ownership, smart pointers, threads, mutexes and the standard library. Most bugs in this layer come from memory and threading mistakes, and they crash the whole system instead of one app.

The second skill is how native services fit into Android. Learn how a native process is started by an init rc file, how it registers a Binder service using the NDK Binder library, how it calls up into Java through JNI when needed, and how its interface is declared in the VINTF manifest. Learn Treble too, the architecture that separates the vendor part of the system from the Android part so that each can be updated on its own.

The third skill is the car specific subsystems. Study the Exterior View System, called EVS, which shows camera feeds very early at boot so the driver can reverse even before Android is fully ready. Study the audio HAL and audio routing, since cars have many zones and many sound sources. Study the display and cluster path, and how a second screen is driven.

The fourth skill is talking to other vehicle computers. Learn the idea of service oriented communication in cars, protocols such as SOME IP, and how an Android head unit exchanges data with the rest of the vehicle. You will often write a small bridge service that listens on one side and publishes on the other.

Good habits for this layer are strong logging, careful startup order and clean error handling, because a middleware service that crashes in a moving car is a serious problem.

Step 5, Master VHAL, the Doorway to the Vehicle

VHAL is where Android finally meets the car, and it is the most automotive specific part of the whole stack. Everything the car knows, such as speed, gear, fuel level, door open, seat belt, outside temperature and air conditioning, is described as a vehicle property.

Each property has a few simple parts. A property ID says what it is. An area ID says where it applies, for example which seat or which door. A type says whether the value is an integer, a float, a string or a list. An access mode says whether it can be read, written or both. A change mode says how updates arrive. A static property never changes, an on change property reports when the value changes, and a continuous property reports at a steady rate. Properties come in two families. System properties are defined by Android, and vendor properties are defined by the carmaker for their own features.

Learn the VHAL interface itself, which is now written in AIDL. The main actions are getting a value, setting a value, and subscribing to changes. Understand how a request from CarPropertyManager reaches Car Service, then the VHAL service, and how the answer comes back. Study the reference implementation that comes with AOSP, including the fake hardware used for emulators, because it shows you a complete working example before you touch a real vehicle.

Then learn the connection to the real car. Most VHAL work is about mapping car messages to properties. That means understanding the CAN bus, how a message has an identifier and a payload, and how a DBC file describes which bits inside a message mean which signal, with scale and offset. A VHAL developer reads a DBC file and writes code that turns raw bits into clean properties, and does the reverse for writes. Be careful with units, timing and safety, because wrong values on a dashboard are not a small bug.

A wonderful practice project is building a simulated VHAL that feeds changing speed and gear values into the emulator, then watching your own app react. Once that works, you have touched every floor of the stack.

Skills Beyond Android That Make You Stand Out

Some of the most valuable skills are not Android at all.

1. Linux basics. Comfort with the shell, processes, permissions, file systems and scripting. Know how the kernel boots and what a device driver does, even if you never write one.
2. Hardware bring up awareness. Know what a BSP is, what a bootloader does, and how an Android image is flashed to a board.
3. Automotive basics. Know what an ECU is, why cars contain many of them, how CAN and Ethernet carry data, and what diagnostics are. Learn the language of ignition states, wake up, sleep and power modes.
4. Safety and quality awareness. Learn why automotive software follows strict processes, why driver distraction rules exist, and why testing is far heavier here than in phone apps.
5. Debugging like a detective. Master logcat filtering, dumpsys, bugreports, tombstones, trace tools and reading kernel logs. When a head unit fails to wake from sleep, the log is your only witness.
6. Git and code review habits. Platform changes are small, careful and reviewed by several people. Learn to write clean commit messages and to explain why a change is needed.

Your Six Month Roadmap

You can follow this plan with a few hours a day alongside a job.

1. Month one. Automotive apps. Build a media app and a vehicle data app on the emulator. Learn Car App Library basics, driver distraction rules and the android.car managers.
2. Month two. AOSP foundations. Sync, build and boot AOSP. Master adb, logcat and dumpsys. Make one tiny change in the system and see it run.
3. Month three. Framework. Learn Binder and AIDL properly, study Car Service, understand SELinux, and add a custom service.
4. Month four. C plus plus and native services. Refresh the language, write a native Binder service, start it from init, and call it from Java.
5. Month five. Middleware subsystems. Explore EVS, audio, power management and display paths. Read the code, trace one full feature from app to native.
6. Month six. VHAL. Study properties, the AIDL interface and the reference implementation. Learn CAN and DBC, then build a simulated VHAL and a small end to end demo.

Mistakes to Avoid

Do not try to learn the whole stack at once. Depth on one floor beats shallow knowledge of five. Do not skip C plus plus, because it is the price of entry below the framework. Do not ignore SELinux, because it will stop you at the worst moment. Do not only read theory. Build something every week, even if it is tiny, because platform knowledge only sticks when you break the system and fix it yourself. And do not fear the size of the code. Nobody understands all of AOSP. Strong engineers simply know how to find their way.

Final Words

Moving from phone apps to automotive is not starting over. It is going deeper. Every layer you learn makes you more valuable, because few engineers can follow a single signal from a car sensor all the way to a pixel on the screen. If you can, you will never be short of interesting work. Pick the first step tonight, open the emulator, and start.

Thanks for reading Cross Commit

Before you go:

👉 Clap and follow Mandapati Bhargava so their next story lands in your feed 👏

👉 Want their stories by email? After you follow, tap Following on their profile and choose Email notifications on 📩

👉 Follow Cross Commit for practical iOS, Android and mobile AI stories from engineers who ship real apps

👉 Writing about Swift, Kotlin or mobile AI? Cross Commit is open to writers worldwide. Leave a response below and we’ll get in touch ✍️

The Complete Guide to Moving from Android Apps to Android Automotive was originally published in Cross Commit on Medium, where people are continuing the conversation by highlighting and responding to this story.