Google dropped the October 2026 Google System Update a few days ago. Buried inside Google Play Services v26.39 is something that actually matters if you care about Android Automotive: OEM Design Tokens. Finally. Car manufacturers can consistently customize the color themes of Google apps running on their infotainment systems without having to hack together janky resource overrides that break on the next Play Services update.
I'm Artem Garazha. I'm a solo Android developer, I ship apps on Google Play, and I run the YouTube channel Pin Up Retro Manner where I walk through my builds. I pay attention to this stuff because it directly affects how apps look and behave across Android surfaces. When Google changes how theming works on a platform like Android Automotive, it ripples out to every developer who has to test against it. You don't get to ignore it.
OEM Design Tokens, Without the Fluff
OEM Design Tokens are Google giving car manufacturers a structured theming system for Google apps on Android Automotive OS. Before this, manufacturers either lived with Google's default Material You colors looking completely wrong against their custom dashboard UI, or they hacked together their own color overrides. Now they get a proper token library.
Three components. A static library that provides APIs to access OEM token values and lets apps opt into overriding token references with OEM values. A shared library that defines the library name, a boolean called enable_oem_tokens, and an OemStyle that carries the actual color values. And then manufacturers can create their own override of the shared library with their own package name and signing certificate. BMW gets com.bmw.sharedlib. Mercedes gets com.mercedes.sharedlib. Nobody steps on anybody else.
The token values themselves live in a style called OemStyle. It's standard Android resource XML:
<style name="OemStyle">
<item name="colorPrimary">#B0C5FF</item>
<item name="colorOnPrimary">#002B76</item>
<item name="colorPrimaryContainer">#003FA4</item>
<item name="colorOnPrimaryContainer">#D9E2FF</item>
</style>
The clever bit: manufacturers can layer Runtime Resource Overlays (RROs) on top of this to change token values dynamically. A car could switch color schemes based on driving mode. Sport mode, aggressive reds. Eco mode, calming greens. Whether any OEM actually does this instead of shipping one palette and calling it a day, I don't know. But the mechanism is there.
If you're working at the AOSP level with Google Automotive Services, there's a compliance requirement: the shared library com.android.oem.tokens has to be listed in config_sharedLibrariesLoadedAfterApp so it loads after app classes. Google's docs also mention a stub implementation trick. Ship a stub on the system image, push the full implementation later without a full OTA. Smart, assuming you have the infrastructure for that kind of staged rollout.
The Part Nobody's Talking About
OEM Design Tokens solve a real problem. Google apps on automotive screens shouldn't look like alien transplants. But they also represent Google quietly admitting something obvious: Material You's algorithmic theming does not work everywhere.
On phones, Material You pulls colors from your wallpaper and generates a palette. It's clever and it mostly works. On a car dashboard there is no wallpaper. The screen is dark, ambient light changes constantly, and the design language has to match physical knobs, dashboard materials, and whatever the manufacturer's brand guidelines say. You can't algorithmically theme your way out of that. Google is effectively saying "fine, here's a structured way to override everything."
The part that gets me: this is the opposite of how Google normally operates. Usually they want control. Consistency across devices. The Google experience has to feel like Google, whether you're on a Pixel, a Samsung, or a OnePlus. But inside a car they're handing the keys to the OEMs. That's either pragmatism or surrender. Depends how cynical you are that morning.
I've been on both sides of this. I've built apps that had to look native on Samsung's One UI while also working on stock Android, and the invisible tax of per-OEM theming is real. Every new device skin means another round of testing, another set of edge cases, another thing that looks fine on a Pixel and broken on a Galaxy. Google knows this. They've spent years trying to rein in OEM customization. And yet here they are, building a formal system for OEMs to override Google's own app colors in the car. The hypocrisy is almost impressive.
But automotive is different from mobile and Google knows that too. A car buyer doesn't care whether Google Maps matches Google's brand guidelines. They care whether the screen in their $50,000 vehicle looks coherent with the rest of the interior. If that means Google Maps has to wear BMW orange or Mercedes silver, then Google Maps wears BMW orange. The alternative is OEMs just not shipping Google apps, and Google definitely doesn't want that.
October Update: The Stuff That's Not Headlines
Find Hub tags finally have NFC support. Tap a tag with your phone and you instantly see details, settings, or identify a lost tag. No app, no menus, just tap. The registration flow also improved: you can set categories, rename tags, and configure Left-Behind Reminders during initial setup instead of manually later. Small change, but it removes the exact kind of friction that makes people not bother configuring tags at all.
Google Wallet notifications now show card art and payment network logos in the card tokenization prompt. Visual polish, sure. But for payment authorization, clear visual cues actually matter. You want to know at a glance which card you're about to approve.
Play Store v53.5 adds AI labels for AI-generated images in India, with exceptions because there are always exceptions. You can also now see your "global influence": total views and helpfulness votes on your reviews. I can't tell if that's nice or just another number to feel bad about.
Maps-related developer features for third-party apps. Bug fixes across Developer Services and Android System Intelligence. The usual.
What This Actually Means If You're Building Apps
If you target Android Automotive, you now need to test against OEM-themed environments. Your app can look perfect on a stock emulator and completely fall apart on a Volvo where the OEM tokens make every Google surface dark blue and your hardcoded white backgrounds suddenly scream for attention.
The token system rides on standard Android resource mechanisms. If you're already using theme attributes instead of hardcoded colors, you should be mostly fine. "Should be mostly fine" is the kind of sentence that has burned me exactly as many times as I've said it, and I've said it a lot.
Here's a concrete example. Say you've got a navigation overlay that draws a semi-transparent panel. You tested it on the stock AAOS emulator where the default background is a neutral gray. It looks fine. Then someone runs it on a Polestar where the OEM tokens set colorSurface to near-black and your 30% opacity panel becomes invisible against the dark background. Did you test with ?attr/colorSurface or did you hardcode #EFEFEF? If you don't know the answer to that question without checking your code, you have a bug waiting to happen.
The thing is, most Android developers targeting phones never think about this. Material You handles it or the OEM skin handles it or whatever. But Automotive is a different beast. Fewer apps, but the ones that exist run in a highly controlled environment where the OEM has strong opinions about visuals. You can't just ship and hope.
What I actually want, and what I think we'll see in the next year or two, is OEMs exposing these token values so third-party apps can read them. Right now the system is Google-apps-only. But if Toyota's OemStyle defines colorPrimary as something specific, there's no reason a mapping app or a music player can't read that and theme itself to match. That's the actual win: a cohesive in-car experience across every app, not just Google's.
I'm also watching whether this pattern leaks back to phones. Samsung already runs One UI with its own design language on top of Android. If Google formalized OEM design tokens on mobile too, Samsung ships their palette as tokens, Xiaomi ships theirs, and apps adapt without device-specific hacks. Probably wishful thinking. The phone ecosystem is way more fragmented and competitive than automotive. But the architecture exists now. Some product manager at Google has definitely had the meeting.
The Take
The October 2026 update isn't flashy. No big AI feature, no dramatic redesign. OEM Design Tokens are the kind of infrastructure change that quietly makes the platform better for anyone who actually has to ship software on it. Car manufacturers get control over their brand experience. Google apps stop looking wrong on automotive screens. Developers get a cleaner abstraction than whatever hacky override system came before.
It's a win. I'll still complain about the edge cases when they bite me. That's the job.
Top comments (0)