If you’re getting started with Android Automotive OS (AAOS), you’ll quickly run into something called Car Service in AOSP. It’s one of those essential components that makes Android work inside a car — not on your phone, but actually on the car’s infotainment system. In this guide, we’ll break down Car Service in AOSP step-by-step, explain how...
The automotive industry is going through a digital revolution. Cars are no longer just mechanical marvels; they are becoming smart, connected, and software-driven. At the heart of many modern infotainment and connected car systems is AOSP Architecture in Automotive — the Android Open Source Project adapted for in-vehicle environments.
In this blog, we’ll break down AOSP Architecture in Automotive, why it matters, and how developers can use it to build smarter infotainment systems.
AOSP (Android Open Source Project) is the open-source foundation of Android. In the automotive world, it serves as the base platform for Android Automotive OS (AAOS) — a full operating system built directly into vehicles, without the need for a connected smartphone.
Think of it as Android for your car’s dashboard, but with special layers and modules designed for safety, performance, and automotive-grade reliability.
The main advantages of AOSP Architecture in Automotive include:
Just like Android for phones, the automotive AOSP stack is divided into layers, each serving a different purpose.
Acts as a bridge between hardware components and Android services.
In automotive systems, specialized Automotive HALs exist for vehicle-specific functions like:
Vehicle HAL Interface
package android.hardware.automotive.vehicle.V2_0;
interface IVehicle {
/**
* Reads the property value from the vehicle.
*/
VehiclePropValue get(VehiclePropValue requestedProp);
}get() allows reading real-time car data (e.g., speed, fuel level).CarService, to control vehicle-related functions.Accessing Car Data via CarService
val car = Car.createCar(context)
val carInfoManager = car.getCarManager(Car.INFO_SERVICE) as CarInfoManager
val manufacturer = carInfoManager.manufacturer
val model = carInfoManager.modelCar.createCar() connects your app to the car’s system services.CarInfoManager retrieves details like manufacturer and model.While infotainment is the most visible part, AOSP Architecture in Automotive also enables:
With EVs, autonomous driving, and AI integration, the role of AOSP will grow. Manufacturers are already exploring:
The goal..? Turning the car into a truly connected digital companion.
AOSP Architecture in Automotive is not just a port of Android to cars — it’s a reimagined operating system that bridges consumer tech with automotive-grade safety and reliability. For developers, it opens up endless possibilities to create smarter infotainment systems and connected experiences that evolve with the vehicle.
By understanding its layers and best practices, you can be part of shaping the future of mobility.
If you’ve ever wondered what powers Android at its core, you’ve probably stumbled across the term AOSP — short for Android Open Source Project. It’s Android… but without Google. Sounds strange, right? Let’s unpack what that really means, why it exists, and how it works in practice. What is AOSP? At its simplest, AOSP is the open-source base of...
Android Automotive OS is powering a growing number of infotainment systems, and at the heart of its vehicle interaction lies a critical component: VHAL Interfaces (IVehicle). These interfaces are what allow Android to talk to your car’s hardware. From reading the speedometer to turning on climate control, everything hinges on this system.
In this post, we’ll break down how VHAL Interfaces (IVehicle) work, why they’re essential, and how developers can work with them to build automotive apps that actually connect with vehicle systems.
VHAL stands for Vehicle Hardware Abstraction Layer. Think of it as a translator between Android and the car’s underlying ECUs (Electronic Control Units). Cars have multiple ECUs controlling everything from brakes to lights, and Android Automotive needs a way to communicate with them.
That’s where VHAL Interfaces (IVehicle) come in. They define how Android gets and sets data to and from the vehicle hardware.
In Android Automotive, IVehicle is the AIDL (Android Interface Definition Language) interface that enables communication between the Vehicle HAL and the framework.
You can think of IVehicle as a contract. It defines methods the Android system can call to:
This interface must be implemented by car manufacturers or Tier-1 suppliers so that Android can access real-time vehicle data.
Here’s a simplified look at what an IVehicle interface might look like:
interface IVehicle {
VehiclePropValue get(in VehiclePropGetRequest request);
StatusCode set(in VehiclePropValue value);
void subscribe(in IVehicleCallback callback, in SubscribeOptions[] options);
void unsubscribe(in IVehicleCallback callback, in int[] propIds);
}Here,
These methods form the foundation of vehicle interaction in Android Automotive.
A vehicle property is any data point Android can interact with. Each has a unique ID, data type, and permission level. For example:
VehicleProperty::PERF_VEHICLE_SPEED: Car speedVehicleProperty::HVAC_TEMPERATURE_SET: Climate control temperatureVehicleProperty::FUEL_LEVEL: Fuel levelEach property is defined in the VehicleProperty.aidl file.
Let’s say you’re a car maker. You want Android to read your custom battery voltage data. You’d do something like this:
#define VEHICLE_PROPERTY_CUSTOM_BATTERY_VOLTAGE (0x12345678)VehiclePropConfig config = {
.prop = VEHICLE_PROPERTY_CUSTOM_BATTERY_VOLTAGE,
.access = VehiclePropertyAccess::READ,
.changeMode = VehiclePropertyChangeMode::ON_CHANGE,
.configArray = {},
.configString = "Custom Battery Voltage",
};VehiclePropValue get(const VehiclePropGetRequest& request) override {
VehiclePropValue value = {};
if (request.prop == VEHICLE_PROPERTY_CUSTOM_BATTERY_VOLTAGE) {
value.prop = request.prop;
value.value.floatValues = {12.6};
}
return value;
}And that’s it. Now Android can read your custom battery voltage.
Without VHAL, Android is blind to the vehicle. These interfaces power key services like:
By standardizing communication, VHAL Interfaces (IVehicle) make it possible for third-party developers to build real, vehicle-aware apps. That’s a game-changer.
Let’s look at a code snippet that reads the vehicle speed.
VehiclePropertyValue speed = vehicle.get(VehicleProperty.PERF_VEHICLE_SPEED);
float currentSpeed = speed.getValue().getFloatValue();Here,
get() method on the IVehicle AIDL interface.subscribe() instead of calling get() in a loop.If you want to build or integrate automotive systems with Android Automotive OS, you must understand how VHAL Interfaces (IVehicle) work. They’re the core pathway between Android and the car’s brain.
With the right implementation, you can create apps that do more than just run in the dashboard — they interact with the vehicle in real-time, improving safety, convenience, and experience.
VHAL Interfaces (IVehicle) are not just another Android abstraction. They’re what make Android truly automotive.
In today’s rapidly evolving automotive world, technology increasingly powers every aspect of your driving experience. One such advancement making a significant impact behind the scenes is Vehicle HAL. You might be wondering, what exactly is Vehicle HAL, and how does it affect the way you drive? Let’s break it down clearly and simply.
Vehicle HAL stands for Vehicle Hardware Abstraction Layer. Think of it as the translator between the car’s hardware (like sensors, cameras, control units) and the software apps that make your driving experience smarter and safer. It sits in the middle, handling the nitty‑gritty so app developers can focus on features — not on hardware quirks.
With Vehicle HAL, your car’s systems talk in a standard language. Whether it’s braking, lane‑keeping, infotainment, or diagnostics, everything works through that common interface. That consistency simplifies development, improves safety, and speeds up innovation.
Vehicle HAL gives developers a single, reliable interface to access diverse hardware. Instead of building custom code for each sensor or device, they write once and it works across models — much faster and safer.
Need to add voice commands, predictive cruise control, or advanced diagnostics? Vehicle HAL decouples hardware from apps. That means updates come quicker and you get new features without long delays.
By enforcing consistent behavior across hardware components, Vehicle HAL helps reduce bugs and improves reliability. Consistency boosts safety — especially in critical systems like braking or collision avoidance.
Automakers and suppliers can plug in different parts — cameras, sensors, processors — from various vendors. As long as they follow Vehicle HAL standards, everything integrates seamlessly. This encourages competition and innovation while keeping quality high.
Let’s look at a basic example in Android’s Vehicle HAL environment to understand how it controls a vehicle’s power state.
// Example: Controlling Vehicle Power State with Vehicle HAL
public class VehiclePowerController {
private VehicleHal vehicleHal;
public VehiclePowerController(VehicleHal hal) {
this.vehicleHal = hal;
}
// Method to turn vehicle power on or off
public void setPowerState(boolean on) {
try {
int powerState = on ? VehiclePropertyIds.POWER_STATE_ON : VehiclePropertyIds.POWER_STATE_OFF;
vehicleHal.setProperty(VehiclePropertyIds.POWER_STATE, powerState);
System.out.println("Vehicle power turned " + (on ? "ON" : "OFF"));
} catch (VehicleHalException e) {
System.err.println("Failed to set power state: " + e.getMessage());
}
}
}Here,
VehicleHal is an object representing the hardware abstraction layer interface.setPowerState takes a boolean to turn the vehicle power on or off.VehiclePropertyIds.POWER_STATE_ON and POWER_STATE_OFF are constants representing the hardware power states.setProperty method sends the command down to the hardware, abstracted away from the specific implementation.This simple code showcases how Vehicle HAL hides the hardware complexities and presents a clean way to control vehicle functions programmatically.
As connected and autonomous vehicles advance, the role of Vehicle HAL will grow even more crucial. It will support complex sensor networks, cloud integration, AI-driven decisions, and real-time data sharing between vehicles to make driving smarter, safer, and more enjoyable.
In conclusion, Vehicle HAL is revolutionizing the automotive space by breaking down the barriers between hardware and software. It’s making cars more adaptable, feature-rich, and user-friendly, changing the way you interact with your vehicle every day. Whether it’s through better safety, easier updates, or improved performance, Vehicle HAL is quietly refashioning the future of driving, one line of code at a time.
Drive smarter, safer, and connected — thanks to Vehicle HAL.
Android Automotive OS is Google’s in‑car operating system that runs directly on a vehicle’s hardware. Not to be confused with Android Auto (a phone projection platform), Android Automotive OS Architecture is a complete software stack, ready for infotainment, driver assistance apps, and full vehicle integration. Let’s dive into its main layers. Android Automotive Architecture A...
If you’re an OEM or Tier 1 developer integrating Google Automotive Services (GAS) into your Android Automotive OS (AAOS) stack, compliance isn’t just a formality — it’s a binding agreement with Google. Their guidelines are intentionally strict to preserve platform security, ensure a consistent user experience, and maintain API reliability across the ecosystem.
This article takes a deep dive into what GAS compliance actually entails — offering actionable insights for engineers, system architects, and product owners navigating the AAOS landscape.
Google Automotive Services (GAS) is a proprietary suite of applications running on Android Automotive OS (AAOS). It includes:
com.google.android.apps.maps (Google Maps)com.google.android.googlequicksearchbox (Google Assistant)com.android.vending (Play Store)com.google.android.gms (Play Services)Unlike Android Auto, which mirrors from a paired phone, GAS apps run natively on the IVI (In-Vehicle Infotainment) hardware. That requires full-stack integration — kernel to UI.
Before any technical work begins, your OEM must sign a GAS License Agreement with Google. This is model-specific, meaning:
As a developer, you’ll typically get access to the GAS Partner Portal after your OEM is approved — where SDKs, sample projects, and certification tools are hosted.
To be GAS-compliant, your hardware must meet strict thresholds.
| Component | Requirement |
|---|---|
| RAM | ≥ 2GB (realistically 4GB+ recommended) |
| Storage | ≥ 32GB eMMC or UFS |
| Connectivity | Wi-Fi, Bluetooth Classic + LE |
| GNSS / GPS | Required for Maps integration |
| Microphones | High SNR, beamforming preferred |
| Audio DSP | For voice recognition preprocessing |
To integrate Google Automotive Services, your IVI system must use a Google-certified build of Android Automotive OS. This typically involves:
Note: Google prohibits UI customizations that interfere with system-level navigation, Assistant triggers, or driving safety workflows. GAS will not support heavily skinned or fragmented UI shells that break these requirements.
Google requires your system to pass a set of test suites to ensure stability and UX consistency.
Tests Android APIs, permissions, and behavior.
$ run_cts --module CtsAppSecurityHostTestCases
$ run_cts --module CtsMediaTestCasesFailures often involve:
Validates hardware interface layers. You’ll need to flash your build and execute these over adb/fastboot.
$ run_vts --plan VtsKernelTestTypical failures:
Tests GAS apps in the context of AAOS.
Key checks include:
ACTION_NAVIGATE_TO)DTS evaluates runtime behavior during actual vehicle use. Google may perform this directly or via OEM-conducted telemetry logs.
CarApp API for Custom AppsIf you’re building companion apps, use the androidx.car.app APIs (Jetpack):
class MyCarScreen(carContext: CarContext) : Screen(carContext) {
override fun onGetTemplate(): Template {
return MessageTemplate.Builder("Welcome to MyCar App")
.setTitle("MyCar")
.setHeaderAction(Action.APP_ICON)
.build()
}
}MediaBrowserServiceCompat for Media AppsGAS expects media apps to use Android’s MediaBrowserServiceCompat so that Assistant can control them
class MyMediaService : MediaBrowserServiceCompat() {
override fun onCreate() {
super.onCreate()
// Setup your media session and player
}
override fun onLoadChildren(parentId: String, result: Result<List<MediaItem>>) {
// Populate UI content
}
}Make sure you support Google Assistant voice intents. This requires implementing App Actions schema or handling common Intents.
<intent-filter>
<action android:name="android.media.action.MEDIA_PLAY_FROM_SEARCH" />
</intent-filter>Handle queries like “Play Arijit Singh songs on MyCar App”.
As a developer, your GAS integration must comply with Google and regional privacy rules.
You must:
android-automotive GitHub.VehicleProp handling.TradeFederation to orchestrate builds and reports.GAS compliance is a high bar. But it’s not just bureaucracy — it’s about delivering a polished, secure, responsive infotainment system users can trust.
As a developer, your role is to make sure the AAOS stack:
Once certified, your GAS integration unlocks the full power of Google’s ecosystem — and keeps your vehicles competitive in a connected world.
As vehicles evolve into digital experiences, the need for glanceable, fast, and distraction-free interfaces becomes paramount. In Android Automotive OS (AAOS), this demand has led to the emergence of the Jetpack Glance framework — a powerful tool for creating UI surfaces that are lightweight, fast to load, and safe for drivers to interact with.
In this blog post, we’ll explore how Jetpack Glance can be used to build a media playback card for Android Automotive OS. From setting up dependencies to implementing a full-featured glanceable media widget with play/pause/skip functionality — we’ll walk through the full picture with code, context, and best practices.
Jetpack Glance is a declarative UI library designed for building remote user interfaces, including:
Think of Glance as the Compose-inspired sibling of RemoteViews, but tailored for rendering quickly, efficiently, and safely on surfaces with strict interaction rules — like a car’s infotainment screen.
Using Glance in AAOS allows developers to:
| Use Case | Description |
|---|---|
| Media Cards | Display now-playing info and basic playback controls |
| Navigation Previews | Show turn-by-turn summaries or route cards |
| Vehicle Status | Fuel, tire pressure, battery charge level |
| Contextual Alerts | Door open, low fuel, safety notifications |
Update your build.gradle with the latest Glance libraries:
dependencies {
implementation "androidx.glance:glance:1.0.0"
implementation "androidx.glance:glance-appwidget:1.0.0"
implementation "androidx.glance:glance-wear-tiles:1.0.0" // optional
implementation "androidx.core:core-ktx:1.12.0"
}Tip: Glance is backward-compatible with Android 12 and above, making it suitable for most AAOS setups.
Let’s walk through a full example where we build a media playback widget that can be shown in a center display or cluster (with OEM support).
class MediaGlanceWidget : GlanceAppWidget() {
@Composable
override fun Content() {
val title = "Song Title"
val artist = "Artist Name"
Column(
modifier = GlanceModifier
.fillMaxSize()
.padding(16.dp)
.background(Color.DarkGray),
verticalAlignment = Alignment.CenterVertically,
horizontalAlignment = Alignment.CenterHorizontally
) {
Text("Now Playing", style = TextStyle(fontWeight = FontWeight.Bold, color = Color.White))
Spacer(Modifier.height(8.dp))
Text(title, style = TextStyle(color = Color.White))
Text(artist, style = TextStyle(color = Color.LightGray))
Spacer(Modifier.height(16.dp))
Row(horizontalAlignment = Alignment.CenterHorizontally) {
Image(
provider = ImageProvider(R.drawable.ic_previous),
contentDescription = "Previous",
modifier = GlanceModifier.size(32.dp).clickable {
actionStartService<MediaControlService>("ACTION_PREVIOUS")
}
)
Spacer(Modifier.width(16.dp))
Image(
provider = ImageProvider(R.drawable.ic_play),
contentDescription = "Play",
modifier = GlanceModifier.size(32.dp).clickable {
actionStartService<MediaControlService>("ACTION_PLAY_PAUSE")
}
)
Spacer(Modifier.width(16.dp))
Image(
provider = ImageProvider(R.drawable.ic_next),
contentDescription = "Next",
modifier = GlanceModifier.size(32.dp).clickable {
actionStartService<MediaControlService>("ACTION_NEXT")
}
)
}
}
}
}Since Glance doesn’t support direct onClick behavior like Compose, we use a Service to act on UI interactions.
class MediaControlService : Service() {
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
when (intent?.action) {
"ACTION_PLAY_PAUSE" -> togglePlayPause()
"ACTION_NEXT" -> skipToNext()
"ACTION_PREVIOUS" -> skipToPrevious()
}
return START_NOT_STICKY
}
private fun togglePlayPause() {
// Hook into MediaSession or ExoPlayer
}
private fun skipToNext() {
// Forward playback command
}
private fun skipToPrevious() {
// Rewind playback
}
override fun onBind(intent: Intent?): IBinder? = null
}To register the widget and service:
<receiver
android:name=".MediaGlanceWidgetReceiver"
android:exported="true">
<intent-filter>
<action android:name="android.appwidget.action.APPWIDGET_UPDATE" />
</intent-filter>
<meta-data
android:name="android.appwidget.provider"
android:resource="@xml/media_widget_info" />
</receiver>
<service
android:name=".MediaControlService"
android:exported="false" />In res/xml/media_widget_info.xml:
<appwidget-provider
xmlns:android="http://schemas.android.com/apk/res/android"
android:minWidth="180dp"
android:minHeight="100dp"
android:updatePeriodMillis="60000"
android:widgetCategory="home_screen" />Jetpack Glance is quickly becoming a go-to tool for developers looking to build safe, fast, and flexible UI surfaces across Android form factors. In the automotive space, it shines by helping deliver minimalist, glanceable media controls that respect both performance and safety constraints.
As AAOS continues to evolve, expect more OEM support for Glance in clusters, dashboards, and center displays — especially with the push toward custom car launchers and immersive media experiences
Android has come a long way since powering our phones. Today, it’s in dashboards, infotainment systems, and even under the hood of cars. But how exactly did Android evolve from a smartphone OS to a critical player in the automotive world?
In this blog post, we’ll explore the fascinating journey of Android in the automotive industry, from its humble beginnings to the modern Android Automotive OS (AAOS). We’ll explain everything in a clear and easy-to-understand way, covering code examples, system architecture, and how this evolution affects developers, car manufacturers, and everyday drivers.
When Android was first introduced by Google in 2008, its open-source nature caught the attention of many industries — including automotive.
In 2015, Google officially launched Android Auto — a platform that allowed Android smartphones to project a simplified interface onto the car’s infotainment system. Drivers could use apps like Google Maps, Spotify, and WhatsApp with voice commands and touch input, enhancing safety and usability.
How It Works:
Android Auto runs on the phone, not the car. The car merely acts as a display and controller.
// Example: Launching a voice command with Google Assistant
val intent = Intent(Intent.ACTION_VOICE_COMMAND)
startActivity(intent)This architecture meant quick updates and a wide range of compatible vehicles. But it also had limitations — OEMs (Original Equipment Manufacturers) had little control over the UI or deep integration with car hardware.
Recognizing the limitations of projection-based systems, Google introduced Android Automotive OS — a full-fledged, car-ready version of Android that runs natively on the vehicle’s hardware.
Let’s break down how Android Automotive OS works under the hood.
This layer interacts directly with the vehicle’s hardware. OEMs implement Vehicle HALs to expose data like speed, fuel level, and climate control to Android.
Android Automotive uses AIDL (Android Interface Definition Language) to define communication between system services and vehicle HALs.
// AIDL example to access vehicle property
interface IVehicle {
int getProperty(int propertyId);
}These are system services provided by AAOS (like CarSensorManager, CarInfoManager, etc.) that expose car-related data to apps.
val car = Car.createCar(context)
val sensorManager = car.getCarManager(Car.SENSOR_SERVICE) as CarSensorManagerWith AAOS, developers now build apps that run directly on the car. These can be media, navigation, or communication apps.
Android Automotive media apps are built on the MediaBrowserService framework:
class CarMediaService : MediaBrowserServiceCompat() {
override fun onGetRoot(
clientPackageName: String,
clientUid: Int,
rootHints: Bundle?
): BrowserRoot? {
return BrowserRoot("root", null)
}
override fun onLoadChildren(
parentId: String,
result: Result<List<MediaItem>>
) {
result.sendResult(emptyList()) // Placeholder
}
}This setup allows your media app to appear natively within the car’s infotainment system.
More manufacturers are embracing Android in the automotive industry due to its flexibility and Google ecosystem support.
OEMs can add their own app stores, integrate voice assistants like Alexa, and modify the interface, all while running on a solid Android foundation.
One of the major concerns with embedded software in cars is security. Google addresses this with:
No waiting for your phone to connect. No dropped Bluetooth. Everything just works.
“Hey Google, take me to the nearest gas station.” Simple, natural, and hands-free.
Designed with safety in mind, the interface limits visual overload. You only see what you need, when you need it.
Since AAOS runs directly in the car, it can save preferences across profiles and adapt to whoever’s behind the wheel.
We’re only scratching the surface of what Android can do for mobility.
Google is also working on extending AI-powered user experiences using contextual data like location, calendar events, and habits to provide real-time driving recommendations and proactive assistance.
The journey of Android in the automotive industry showcases how adaptable and scalable the Android ecosystem truly is. From phone projection systems to embedded car platforms, it has revolutionized how drivers interact with their vehicles.
For developers, this is a golden era — you can now build apps not just for phones and tablets, but for the road itself. For OEMs, it’s an opportunity to build smarter, more connected vehicles. And for users, it means safer, more personalized, and enjoyable driving experiences.
As Android continues its journey on wheels, the road ahead looks smarter, safer, and more open than ever.
Q: What is Android Automotive OS?
A: Android Automotive OS (AAOS) is an operating system developed by Google that runs directly on a vehicle’s hardware, unlike Android Auto which runs on a smartphone.
Q: How is Android Auto different from Android Automotive OS?
A: Android Auto is a projection system that mirrors apps from your phone. AAOS is a standalone OS installed in the car, offering deeper integration with vehicle functions.
Q: Can I build apps for Android Automotive?
A: Yes! You can build navigation, media, and communication apps using standard Android tools and frameworks, with slight modifications for car compliance.
Q: Which cars use Android Automotive OS?
A: Cars like the Polestar 2, Volvo XC40, and some models by GM, Honda, and Renault run Android Automotive OS.
Glanceable UI is a key pillar of in-car user experiences, especially in vehicles powered by Android Automotive OS (AAOS). With safety at the core, designing for “at-a-glance” interaction ensures drivers get the information they need with minimal distraction.
In this blog post, we’ll explore:
Jetpack Glance is a lightweight UI toolkit by Google that allows developers to build glanceable app widgets using Jetpack Compose principles.
While it’s widely used for Android home screen widgets, it also plays a growing role in automotive contexts, where modular, safe, and context-aware UI components are essential.
Key Benefits:
An ideal in-car interface (for media, navigation, etc.) should be so intuitive, voice-driven, glanceable, and minimal that drivers can use it with little or no visual attention — keeping their eyes on the road and hands on the wheel.
Android Automotive is designed to operate under strict UX restrictions to reduce cognitive load and visual complexity while driving. Glanceable UI is about showing just enough information for a quick decision or action.
First, make sure to add the required dependencies:
dependencies {
implementation("androidx.glance:glance:1.1.1")
implementation("androidx.glance:glance-appwidget:1.1.1")
}Jetpack Glance is evolving, so make sure to check the latest versions here.
Let’s say you want to display a media card with the currently playing song, a thumbnail, and basic controls like play/pause.
class MediaPlaybackWidget : GlanceAppWidget() {
override suspend fun provideGlance(context: Context, id: GlanceId) {
provideContent {
MediaPlaybackContent()
}
}
}@Composable
fun MediaPlaybackContent() {
val mediaState = rememberMediaState()
Column(
modifier = GlanceModifier
.fillMaxWidth()
.padding(16.dp)
.background(ImageProvider(R.drawable.widget_bg))
) {
Text(
text = mediaState.title,
style = TextStyle(fontSize = 18.sp, fontWeight = FontWeight.Bold),
maxLines = 1
)
Text(
text = mediaState.artist,
style = TextStyle(fontSize = 14.sp, color = Color.Gray),
maxLines = 1
)
Row(
horizontalAlignment = Alignment.CenterHorizontally,
modifier = GlanceModifier.fillMaxWidth()
) {
Image(
provider = ImageProvider(R.drawable.ic_prev),
contentDescription = "Previous",
modifier = GlanceModifier.clickable { /* skipPrevious() */ }
)
Spacer(modifier = GlanceModifier.width(8.dp))
Image(
provider = if (mediaState.isPlaying)
ImageProvider(R.drawable.ic_pause)
else
ImageProvider(R.drawable.ic_play),
contentDescription = "Play/Pause",
modifier = GlanceModifier.clickable { togglePlayback() }
)
Spacer(modifier = GlanceModifier.width(8.dp))
Image(
provider = ImageProvider(R.drawable.ic_next),
contentDescription = "Next",
modifier = GlanceModifier.clickable { /* skipNext() */ }
)
}
}
}Pro Tips for Designing Glanceable UI in AAOS
| Principle | Glanceable Design Tip |
|---|---|
| Visibility | Large touch targets (min 48x48dp), no nested menus |
| Context Awareness | Surface-aware widgets (only show glance cards when relevant) |
| Minimized Screen Time | Display key actions only: Resume, Pause, Next |
| Distraction-Free UX | Avoid animations, complex visuals, or swipe gestures |
| Test While Driving Sim | Use Android Emulator’s automotive mode or in-car dev hardware if possible |
Google enforces strict glanceable design rules for AAOS:
If your app violates these, it may be rejected or hidden when driving.
Jetpack Glance enables a new era of modular, composable, and glance-friendly UI for Android Automotive OS. By respecting the driving context and focusing on essential, actionable information, developers can create interfaces that enhance the in-car experience—without compromising safety.
Remember: In the car, less is more. Show less, do more.