DEV Community: Artem Garazha

Compose 1.13 beta is out. Three things in it actually matter to a solo developer.

Artem Garazha — Thu, 15 Oct 2026 13:31:06 +0000

Jetpack Compose 1.13.0-beta01 shipped on October 7th. I read the release notes the way I always do: skim the commit log, click the issue tracker links, and try to figure out what's going to bite me when stable lands. I'm Artem Garazha, an Android developer from Ukraine, and I maintain a few side apps on my own. For me, "just bump the version" has never meant what it sounds like.

Most of the notes are noise. A few changes actually matter whether you adopt the beta or not. Here's what I'd want to know if I only had five minutes.

Kotlin 2.2 becomes a hard floor

The headline change: Compose 1.13 libraries now target Kotlin 2.2 and require kotlinc 2.2 as the minimum compiler.

If you track Kotlin releases anyway, this is nothing. If you're like me, though, you have an app sitting on Kotlin 2.0 or 2.1 because it compiles and shipping beats upgrading. This beta is the early warning. The moment 1.13 goes stable, that older Kotlin runtime stops being a valid setup.

There's also a build-file wrinkle. For a while now the recommended path has been the Compose Compiler Gradle plugin, which makes the Kotlin version explicit through your plugin version. If you never migrated away from the older composeOptions { kotlinCompilerExtensionVersion = "..." } block, you might need to restructure your build.gradle before you can even attempt the Kotlin 2.2 bump. Google's Compose-to-Kotlin compatibility map is worth a glance before you start editing.

I found this out the annoying way a few versions back when a "simple" Compose upgrade turned into an hour of Gradle archaeology. The symptom was cryptic: Gradle complaining about compiler versions in a language barely resembling a real error. Let me spare you that particular afternoon.

The practical advice: bump Kotlin first, on its own, and get a clean build. Then move the Compose dependency. Doing both in one shot makes it impossible to tell which one broke the build.

A recomposition bug that's been eating frames silently

This is the one I keep thinking about. The release notes describe it in one dry line:

Fixed a bug where passing Float.NaN or Double.NaN into a @Composable function would prevent that function from ever skipping recomposition, even when all arguments are unchanged.

The part that makes it land: Dp.Unspecified is backed by Float.NaN.

So if you ever passed Dp.Unspecified into a composable, directly or through something like Modifier.size(width = Dp.Unspecified, height = 24.dp), that composable would recompose on every single frame, forever. Compose decides whether to skip by comparing arguments. NaN never equals NaN, so the comparison always failed, and the recomposition always fired.

Here's why this would have wrecked my evenings: there's no spike to find. A profiler shows a constant, elevated recomposition count with no obvious culprit. No single frame jumps out. Your list scrolls a little worse than it should, battery drains a bit faster, and you can't point at anything. This is the kind of bug a team can carry for a year without knowing.

If you want to see it for yourself, a composable that takes an optional size works:

@Composable
fun Label(text: String, width: Dp = Dp.Unspecified) {
    Text(text, modifier = Modifier.width(width))
}

Call Label("x", width = 24.dp) and the arguments stay stable, so Compose skips. Call Label("x") and the default Dp.Unspecified (which is Float.NaN under the hood) fails the equality check, so it recomposes every frame. Before 1.13, that second case was permanent. You'd never see it in a layout inspector because nothing looks wrong.

The fix alone justifies running a debug build on the beta to see whether anything suddenly gets smoother.

computedStateOf now fails loudly instead of lying

This is a behavioral change that will break code, and I'm fine with it. The calculation block of computedStateOf is now enforced as read-only. Write to any state inside that block and it throws IllegalStateException.

Before, writing inside computedStateOf was wrong but it didn't crash. It produced those unpredictable invalidation cascades and subtle recomposition loops that are miserable to trace. Now the framework tells you, directly, where the bad code is.

If your app has been doing something weird after state updates and the profiler hasn't helped, there's a real chance this is it. The beta will point at the offender for you.

The rest, quickly

A handful of smaller changes round out the release:

CompositionObserver resolves once per pass now. Calling setObserver mid-composition defers to the next pass. Movable content insertion also reports onBeginComposition and onEndComposition.
A memory leak in LinkComposer got fixed. Movable content that moves around was keeping wrapper group slots alive. If you lean on movable content, this could give you back some memory.
lifecycle-runtime bumped to 2.10.0, which AGP 9.5.0-alpha04 and later need for their lint checks to run.
ComposeTracer supports off-main-thread use now.
An invalidation edge case in computedStateOf around SnapshotStateObserver was cleaned up.

None of these will make headlines. Collectively they're the kind of quiet hardening that keeps a framework shippable.

Should you jump on the beta?

If your project is small and you have an afternoon to spare, yes. Move to Kotlin 2.2, pull the beta, run your debug app, and watch for two signals. First, does anything recompose visibly less? Second, does anything throw IllegalStateException inside a computedStateOf? Both are good news, even the crash.

If your app is in production and you can't risk a beta compiler, you don't have to do anything yet. But read the notes so the Kotlin 2.2 requirement doesn't ambush you when stable drops.

The Compose team is moving fast. 1.12 stable was barely a month ago and we're at 1.13 beta already. I'm not complaining. The treadmill is just real for someone shipping alone.

I write about building and shipping Android apps solo. You can find my retro Android app demo on YouTube and follow me on Instagram.

Vibecoding: The Stages of Acceptance

Artem Garazha — Mon, 12 Oct 2026 13:56:35 +0000

The hype and the outrage around vibe coding have both cooled off enough that we can finally talk about it without shouting. It's a tool. It has sharp edges. Some people jumped in early, some are still watching from the sidelines. Almost everyone has an opinion and at least a little hands-on experience by now. Here's what the journey actually looked like for me.

How I fell into this

I got hooked on vibe coding in January 2026 after finding myself unexpectedly between jobs. When you work at a product company, the corporate mindset seeps into your bones, and it took me a while to shake it off. My first project was basically a continuation of work that no longer existed.

That first project mattered more than I realized at the time. Vibe coding gets described as magic: "I told it what I wanted and it works, no idea how." That wasn't my experience. I knew exactly what the system should do and how it should behave, and I understood the domain deeply. So I could open up whatever the agent produced, inspect it, and fix things by hand when needed. More importantly, I learned the tool actually works. And it is terrifyingly productive.

I could have coded the whole thing manually, but it would have taken two years. Cursor and I shipped it in about three months. The project wasn't small: 70 entities, 200 screens, roughly 1,000 Java classes.

Don't start vibe coding on unfamiliar ground. Begin in a domain you know well, with frameworks you've used before. That way the agent's output is legible to you and you build real trust in the tool. My stack was Java, Spring Boot, Jmix BPM, and Spring AI. A proper enterprise stack, not a toy Python script.

Stage 1: AI as a Stack Overflow replacement

Nobody becomes a vibe coder overnight. New habits build gradually. For me the whole path took over a year.

The zero phase, just asking a chatbot questions, is something everyone does now. It's a straight swap for searching Stack Overflow. And honestly, Stack Overflow was never that welcoming to beginners. Getting roasted for asking something the gurus found obvious was practically a rite of passage. The site's traffic has fallen off a cliff since ChatGPT arrived, and I doubt that's a coincidence. A chatbot is infinitely patient, even if you ask it the same thing a hundred times.

The danger at this stage is getting stuck. Models are absurdly verbose. You can pull useful code out of their walls of explanation, but it's slow. And by now, a tool that can only answer questions about code rather than write it is already obsolete.

In the next phase, still in chat mode, I learned to make the AI write whole classes and services. Whenever it veered into lecture mode, I'd cut it off and demand clean code. We built some genuinely complex things this way, several BPM processes talking to each other through RabbitMQ. But I stayed in this phase too long. I should have moved to agents sooner.

I was afraid to leave my IDE. Everyone around me raved about Claude in the terminal, and the idea left me cold. CLI and nothing else? What about browsing the code, checking dependencies, tweaking parameters? No thanks. That felt like a downgrade.

A wider view

Those early terminal-only agent coders left a bad first impression. "Vibe coder" became almost a slur. The early experiments looked like toys, and nobody believed you could build real systems on such shaky foundations. The hype would pass, managers would get bored with their new playthings, and production code would stay exactly as it was.

Tooling vendors slept through the shift. They didn't exactly miss AI, but they didn't take it seriously. They treated it like low-code: let the "citizens" play, we'll fix it later and charge more. That arrogance is going to cost them. Now they're scrambling to bolt AI features onto old products, but they're chasing, not leading.

Code production has become a commodity. The market will belong to the top AI vendors. You can't build better developer tools than Claude Code, OpenAI Codex, or Cursor. The numbers tell the story: Claude Code passed a $2.5 billion run rate by February 2026, Codex hit over 5 million weekly active developers by June, and Cursor sold to SpaceX in August for $60 billion. Subscriptions to traditional tools will collapse. No amount of AI duct tape will save legacy products.

What survives? Niche tools where domain expertise matters and the end user's job isn't coding. Designing warehouses. Building support bots. Whatever. Thousands of these opportunities exist, and building them just got a lot cheaper. But that's my hypothesis, not a guarantee.

Stage 2: Caution

Sick of copy-pasting code blocks between ChatGPT and my IDE, I finally graduated to a real agent. Let it write the code if it's so smart. By then the hype was deafening, and everyone on my feed was building entire apps in a single evening. I wanted in.

I picked Cursor for two reasons. It had a real IDE, not a stripped-down terminal. And it was the least painful option given current geopolitical realities. In the end, the IDE part was mostly psychological comfort. I kept IntelliJ IDEA open in parallel and reviewed code there, only using Cursor to hand instructions to the agents.

And then I just stared at it, not knowing where to begin. If you're used to a traditional IDE, your brain has no pattern for working with an agent. It's a completely different experience from chat. At first I gave it tiny tasks: write this method, add a controller. I did plenty of things manually in my IDE because it seemed too simple to bother the AI with, and I was stingy with tokens.

Looking back, that was inefficient. I could have trusted the agent more and moved faster. But the brain is both plastic and conservative. It takes time to learn to think differently.

But don't miss the moment when you should try building something genuinely unfamiliar. Something you've never done before. That's what forces you out of the habit of checking every line the agent writes and hunting for minor mistakes. You start thinking like an architect, hands completely off the code.

Stage 3: Unfamiliar ground

A random request broke me out of my BPM bubble. Someone asked me to write specs for a Telegram bot for family task management. I'm an analyst by trade, so spec-writing is familiar, comfortable work. I said yes.

A family bot isn't a document management system for a government agency. I finished the specs in a few days. Then the client asked if I'd code it too.

I nearly declined. After years in a dev-heavy company, I'd internalized the idea that engineers were the elite caste and analysts were second-class. An analyst writing code? Don't make me laugh.

But by then I had months of solid agent experience and one substantial project under my belt. I'd presented it at a webinar and the response was positive. Still, I'd never built anything like this before. I'd be negotiating with the agent the whole way, and I couldn't have done it manually at all.

The backend went smoothly. Familiar stack, same Jmix: entities, DTOs, services, REST APIs, nothing exotic. But something felt different. I no longer needed my old IDE. Everything happened in dialogue with the agent. I'd review the finished result and ask for a rewrite if something bothered me.

Then came the bot itself. The user scenarios turned out to be surprisingly complex despite how simple the product looked on the surface. Thirty-six use cases. I figured I'd give the agent detailed step-by-step descriptions, the Telegram Bot API docs, the specs, and off we'd go.

Not so fast. We'd build one scenario and it worked. Start the second and something broke in the first. The agent had changed code where it shouldn't have. This loop kept repeating, and I realized the project would never ship this way.

Agents lose context on long tasks. They optimize for the immediate problem and accidentally break something else. People told me I needed specs, that I needed to understand what I was doing. I had specs. Every major task was planned. But a truly detailed spec in a new domain requires deep domain understanding first. A detailed spec is almost code already, and it takes forever to write. On a solo project it's an extra layer of bureaucracy.

Stage 4: A framework for the agent

I was out of time. There was no decent Java framework for Telegram bots. Python? I didn't know it, and learning a new language on a paying project just to stroke my ego was too risky. It was clear that no matter how detailed the instructions, the agent would eventually get tangled if everything sat on raw API calls. I needed an intermediate layer to hold the scenarios.

Somewhere around 3 AM the idea hit: build a domain-specific language for user interaction scenarios. Not just for Telegram, for any platform. The roadmap already included a mobile app and other messengers, and I wasn't going to rewrite everything from scratch each time.

I prototyped it after Vaadin, which separates declarative screen descriptions from runtime logic. So I built a DSL, and then I needed an engine to interpret it. That engine briefly threw off my timeline. It wasn't in the original plan, and there was no budget for it. But without it I would have failed the project entirely. The complexity exceeded what raw vibe coding could handle.

How does a DSL solve the context-loss problem? A formal language narrows the agent's interpretation space when it translates my instructions into code. Raw Java, or any general-purpose language, gives the agent too much expressive freedom. Sometimes you can literally see it showing off. Swap in a restricted language and the agent has to express itself within those constraints. If it hallucinates, the engine validator catches it, and a previously hidden logical error becomes a dumb syntax error.

The second benefit was that I could actually see what the product was doing. A monolithic service with a few thousand lines of embedded logic is opaque. A set of YAML scenarios showing what's on screen, plus compact controllers with business logic, is transparent. When controllers started bloating or becoming incomprehensible to a human, that signaled the language was missing features and the agent was cramming everything into code. We'd step back, extend the language, and refactor.

This isn't about agent harnesses or super-prompts. I barely touched agent settings and used them as-is. This was about reshaping the problem domain itself so the agent could understand it better.

The process took off. Cursor knocked out scenarios one after another, and we had the core functionality done in about two weeks. The rest was standard fare: tests, bugs, fixes, new ideas, refinements. The bot is now poised for a production launch. That month of work with Cursor cost me around €400.

By this point the agent and I had fully clicked. Normal coding started feeling like pain. There were a few days when my subscription lapsed, and I felt completely helpless. I tried going back to the old chat copy-paste workflow, and it was brutal. Simple, even stupid work: add a few entities, make DTOs, REST endpoints, pure boilerplate. Writing that by hand in 2026 is embarrassing, but chat mode felt wrong now too.

I'd reached the phase where coding without an agent feels like translating text with a paper dictionary. It's not laziness. It's awareness of wasted time. I can do it. I just see no point.

Stage 5: The illusion of omnipotence

When you finally catch the vibe, the thing Andrej Karpathy described when he coined the term, you get hit with a wave of omnipotence. Ideas crowd your head, fighting each other: "Code me first. No, me." You want to start ten projects at once and you genuinely believe you can finish them all.

In theory you can. But slow down, or your brain will explode. The agent doesn't care about multitasking. It spawns sub-agents and waits. You, the human, have cognitive limits. I fell into this trap and scattered myself. Lots started, nothing finished. It's not even about budget, though costs can skyrocket fast. It's half a step from burnout.

Vibe coding evangelists don't talk about this. But I'm sure they feel it too; they just don't want to look uncool in public. I honestly think there's a huge gap between making YouTube videos about vibe coding and actually shipping something. Whenever I see someone bragging about thousands of closed tasks, I want to ask when they actually think.

Thinking is real work. It needs its own AI companion, but that's a different thing from coding. Counting tasks only makes sense if they're your personal tasks, not automated units of work that spawned and resolved themselves. That metric tells me nothing.

The next stage of AI acceptance in development is realizing your human limits. We're not robots. Don't chase hyper-efficiency into the ground.

Stage 6: Meeting a real agent

"Wait, the previous ones weren't real?" you might ask.

Based on my experience now, not quite. While I was buried in bot scenarios, I missed that Cursor had added a new option: GrokBot. A bot, whatever, I thought. Plenty of those around. I've got work to do.

By the way, there's a category of people who confuse me: the ones posting lengthy comparison reports every other day about which tool is better and why. That kind of analysis is real, difficult work if done properly. If you're just rehashing other people's takes, at least cite them. Sure, you can generate the text with AI, but you still have to try things yourself so you're not embarrassed when someone calls you out. Although maybe being embarrassed about mistakes isn't fashionable anymore.

Anyway. There's no industry-standard definition of an agent. Formally, any LLM with a couple of tools qualifies. Inside coding platforms, "agent" just means a new conversation. The terminology is a mess, and nobody agrees on what chat, agent, or bot actually mean. That's why I ignored the new feature. Bad move.

You probably heard that SpaceX acquired Cursor in the summer. As a result, Cursor got Grok 4.6 at a very reasonable price, none of that Opus-tier token gluttony. Grok isn't exactly a minor player, so having it available was a pleasant surprise.

But GrokBot is a different beast. It's Cursor's equivalent of Claude, an autonomous agent included in the base subscription, and it's a completely different experience. Now I partly understand the Claude fanatics, but only partly. This kind of agent is genuinely versatile: it handles email, writes articles, creates apps, analyzes and refactors repositories. I wish I'd had it earlier. Damn geopolitics.

Disclaimer: Not a single line of this article was written by AI. 100% human text. I didn't even let an agent read it. This is between us, humans.

The top AI players are close not just in model intelligence but in their total offering. I don't think it's worth switching between them hunting for nuances. I'm satisfied with my choice.

Wrapping up

Honestly, I'm stunned. I've never seen change at this speed. Development has shifted radically and permanently. People who talk about an AI bubble are just comforting themselves. The stock market might get shaken, but the technology isn't going anywhere.

I regret taking so long to fully accept AI in development. I should have moved faster. If you're still in the early stages, hurry up. If you've gone further and faster, share your story.

Adapted and expanded from the original article by Stanislav Makarov on Habr. This version adds context from 2026 industry data: JetBrains Developer Ecosystem Survey 2026, Stack Overflow Developer Survey 2025, GitHub Octoverse 2025, METR productivity trials, and Veracode security assessments.

Vibe Coding Is Not a Shortcut — It's a Minefield

Artem Garazha — Fri, 09 Oct 2026 20:22:15 +0000

Vibe Coding Is Not a Shortcut — It's a Minefield. Here Are the Mistakes That Will Actually Cost You

Vibe coding started as a joke. You describe what you want in plain English, an LLM spits out code, and you ship it without reading a single line. It felt like magic.

Six months in, the magic is wearing off. Developers are shipping apps that break in production, leak API keys, and run up cloud bills for features nobody asked for. The problem isn't the AI — it's the vibe.

I've been building Android apps for years, shipping to Google Play with a tiny team and an even tinier budget. When vibe coding tools showed up, I tried them. I broke things. I learned. Here are the mistakes that actually matter — and what to do instead.

1. You Trust the First Output

The biggest lie in vibe coding: "It just works." It doesn't. The first output from any LLM is a starting point — not a finished product. It will compile. It might even look correct. But it rarely handles edge cases, and it never understands your specific constraints.

I've seen generated code that works perfectly for API version 3 and silently corrupts data on version 4. I've seen "null checks" that check the wrong variable. The AI doesn't know your backend, your users, or your deployment pipeline. It guesses.

Fix: Treat every generation as a draft. Run it. Break it. Ask "what happens if the network is slow?" and "what happens if this value is empty?" The AI will answer confidently — you need to verify.

2. You Ship Code You Don't Understand

This one is seductive. The AI generates 200 lines of Kotlin. It compiles. The feature works. You merge it. Three weeks later, a crash report points to a function you've never read.

If you can't explain every line of code you ship, you're not developing — you're gambling. The AI might generate a regex that's 99.9% correct but fails on one specific character. It might use a deprecated API that works today and breaks tomorrow.

Fix: Read every line. If something looks clever, it's probably wrong. Rewrite it until you could explain it to a junior developer. If you can't, you shouldn't ship it.

3. You Let the AI Make Architecture Decisions

Vibe coding tools are great at generating functions. They are terrible at deciding how those functions should be organized. Ask an LLM to build a "scalable architecture" and you'll get a beautiful diagram with arrows going everywhere and a codebase that collapses under its own weight in two sprints.

Architecture decisions — dependency direction, module boundaries, data flow — require context the AI doesn't have. It doesn't know your team size, your release cadence, or which components change most often.

As the developer behind Pin Up Retro Manner, I've learned that architectural choices compound. A bad decision on day one costs ten times more to fix on day one hundred. The AI will happily make that bad decision for you if you let it.

Fix: Design the architecture yourself. Use the AI to fill in implementation details within boundaries you've already set. Never ask "how should I structure this project?" — ask "given this structure, implement this module."

4. You Skip Testing Because "The AI Got It Right"

LLMs generate plausible-looking code. Plausible is not correct. I've seen generated sorting algorithms that work for 10 items and shuffle everything above 100. I've seen database queries that return the right result in development and time out catastrophically in production with real data volumes.

Without tests, you're betting your users will find the bugs before you do.

Fix: Write tests before you trust the code. Not after. If the AI can generate the implementation, it can generate the tests too — but you need to verify both. A test the AI wrote that passes doesn't prove anything. Read the test. Break the code on purpose and confirm the test catches it.

5. You Burn Your Context Window

Every LLM has a context window. When you vibe-code a feature, you burn tokens on back-and-forth corrections, retries, and "no, what I meant was..." by the time you reach the important part, the AI has forgotten your project structure, your naming conventions, and that critical constraint you mentioned 20 messages ago.

The result: code that doesn't match the rest of your codebase. Inconsistent patterns. Duplicated logic. Bugs introduced by context amnesia.

Fix: Start fresh conversations for distinct features. Keep a project context document you paste at the start of each session. Be specific in the first message. The more focused your prompts, the less context you waste.

6. You Don't Version the Prompt History

Your code is in git. Your prompts? Probably lost in a chat history you'll never revisit. When a bug surfaces six months later and you need to understand why a particular implementation decision was made, the prompt that generated it is gone.

Fix: Save prompts alongside code changes. A one-line comment in the commit message or a prompts/ directory in the repo. It takes ten seconds and saves hours of forensic debugging later.

The Bottom Line

Vibe coding is a tool, not a replacement for engineering judgment. Use it to accelerate the boring parts — boilerplate, test stubs, documentation drafts. But when it comes to architecture, security, and correctness, the vibe stops. You make the call.

The developers who will thrive with AI are not the ones who type the fastest prompts. They're the ones who know when to trust the output and when to tear it apart and start over.

This article was written by Artem Garazha, an independent Android developer exploring the intersection of AI tools and mobile development. Follow the journey at Pin Up Retro Manner on YouTube.

Google's October Update Gives Car Makers a Paintbrush, and I Have Mixed Feelings About It

Artem Garazha — Thu, 08 Oct 2026 13:24:54 +0000

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.

Find me on YouTube and Instagram.

The Android I Knew Just Got Locked Behind Three Doors — All at Once

Artem Garazha — Wed, 07 Oct 2026 13:01:58 +0000

I've been writing Android code since the Jelly Bean days. Back then, the platform felt like an open field. You could build whatever you wanted, distribute it however you wanted, and run it on whatever device you could get your hands on. Over the years, Google has been putting up fences. Slowly. One at a time. But October 2026 is the first month where three of those fences turned into walls — simultaneously.

Developer verification landed for real

September 30 came and went, and if you're in Brazil, Thailand, Singapore, or Indonesia, your phone now blocks apps from unverified developers. Not warns you. Blocks.

Registering as a verified developer means handing Google a government ID, uploading your signing keys, and paying $25 — whether you're publishing on Google Play or distributing an APK from your own website. Same process either way.

Google's framing is "accountability." The rest of us are calling it what it looks like: a tollbooth at the entrance to an open platform. NewPipe's maintainers now need to register with Google so their users can install the app. F-Droid has banners up warning people. The Keep Android Open coalition published an open letter back in February laying out the consequences for independent developers, for open-source, for anyone distributing software outside the Play Store. Google read it. Then they shipped it anyway.

Four countries now. Global next year.

The 24-hour waiting room

If you want to install an unverified app after enforcement kicks in, there's an escape hatch — barely. Google calls it the "advanced flow." What it actually is: enable Developer Options, find the buried toggle, authenticate, confirm you're not being coerced, restart your phone, wait 24 hours, scroll past more warnings, then choose between a seven-day window or permanent access.

A full day. To install an APK.

Sameer Samat, Android's ecosystem president, told Ars Technica the delay is meant to break social engineering scams — the kind where a scammer coaches someone through installing malware in real time. The reasoning is that in 24 hours, the victim realizes their loved one isn't actually in jail. I get the logic. But the side effect is that anyone who wants to install software from outside the Play Store now has a mandatory cooling-off period baked into the OS.

The advanced flow started rolling out in August. ADB is exempt — so if you know your way around a terminal, you're fine. Everyone else waits.

Play Integrity went hardware-level

This one is harder to explain but its impact might be the biggest of the three. Last May, Google moved the Play Integrity API's "device" verdict to hardware-backed attestation. Before that, root users and custom ROMs could fake the checks. Magisk modules, SafetyNet workarounds, the usual cat-and-mouse routine.

Hardware attestation ends that game. The verdict now comes from the Trusted Execution Environment — a secure enclave in the chip itself. If your bootloader is unlocked, the TEE knows. LineageOS? The TEE knows. No Magisk module can spoof it, because the check doesn't happen at the OS level. The community has been fighting this for over a year now. Play Integrity Fix, Play Integrity Fork, KernelSU with SUSFS, Hide My Applist — every workaround is a temporary patch, and every patch has a shorter shelf life than the last.

Banking apps use Play Integrity. Payment apps use it. Games with anti-cheat use it. I've had users email me because their banking app stopped working the day they flashed a custom recovery. Not because they did anything wrong — just because the app checked and the hardware answered honestly. And increasingly, ordinary apps are checking too. Fail, and the app either refuses to launch or silently degrades. The community-run fingerprint trackers that tell you which signatures still work are drying up. Pixel Canary fingerprints die every six weeks.

Unlock your bootloader, and a growing slice of your apps stop working. Not hypothetically. Right now.

Why the timing matters

Each of these policies has a defense. Malware is real. Social engineering is real. I'm not pretending otherwise. But they don't exist in isolation. They stack.

Developer verification controls who gets to publish software. The 24-hour wait controls how software reaches users. And Play Integrity controls what devices are allowed to run it. Put them together and you have a platform where one company decides all three.

That's not the Android I signed up for.

I'm a solo developer. My apps run on five-year-old hardware, on custom ROMs, on phones whose owners install APKs because the Play Store isn't an option where they live. I've spent years telling people that Android's openness is the reason to choose it over the alternative. That argument is getting harder to make with a straight face. My YouTube and Instagram are full of people asking whether their phone still works after the next update. I used to have confident answers. Now I just have questions.

Google insists sideloading isn't going anywhere, and technically they're right. You can still install APKs. But they've turned an open door into a puzzle box — and when you finally solve it, Play Integrity might just tell you the app won't run anyway because your bootloader is unlocked.

This didn't start in October 2026. It's been building for years. But October is the first month where all three policies are active at once. If you care about Android staying open, this is the moment to look up and notice.

The doors are closing. I'm not convinced Google plans to open them again.

I'm Artem Garazha, an Android developer from Ukraine. I write about things that break in the Android ecosystem before most people notice they're broken. You can find me on YouTube and Instagram. Previously: The September 30 Deadline Just Passed. Here's What Developer Verification Actually Changed for Me.

Vibe coding on Android: problems nobody asked for

Artem Garazha — Sat, 03 Oct 2026 18:52:50 +0000

What the research actually says about AI-generated Android code, with numbers, studies, and production incidents.

Andrej Karpathy coined "vibe coding" in 2025. You describe an app in natural language, AI generates the code, you don't read every line, you iterate until it works.

For web prototypes, fine. For Android, it works right up until your first production deploy. Then the crash reports start rolling in and you're reading every line anyway, just at 3am with an incident channel pinging.

Android isn't a language plus a framework. It's Kotlin/Java, Gradle with multi-module configs, Activity/Fragment lifecycles, coroutines, Jetpack Compose recomposition, Hilt, Room, Navigation Component, WorkManager, and API versions that change faster than LLM training cycles. When an AI doesn't understand this stack, it generates code that looks right and behaves wrong. That's worse than code that won't compile. The compiler at least tells you something's broken.

1. API hallucinations: code from a parallel universe

The most obvious and most frequent problem. AI models train on data frozen at a cutoff date. The Android SDK, Jetpack libraries, and Kotlin update every few months. The model generates code using APIs that no longer exist, or never existed.

Real examples from dev.to and production:

AsyncTask — removed in Android API 33. AI keeps generating it.
TestCoroutineDispatcher — removed from coroutines-test 1.8+.
ContextualFlowRow — deprecated in Compose 1.8.
android:screenOrientation="portrait" — illegal on screens ≥600dp under Android 16.
Navigation 2 patterns in a Navigation 3 project.
LiveData instead of StateFlow in Compose projects.

Developer Vikas Sahani, creator of AndroJack MCP, documented this: "My AI assistants (Cursor, Claude, Windsurf) were exceptionally fast at generating code, but they were consistently generating the wrong code. They suggested Navigation 2 patterns for a Navigation 3 project, hallucinated Gradle coordinates that didn't exist on Maven, used APIs removed from Android years ago. This wasn't a failure of the models. It was a failure of grounding."

Scale of the problem, per USENIX Security 2025:

2.23 million generated code samples, 16 models analyzed.
Open-source models hallucinate package names in 21.7% of cases on average.
Commercial models: 5.2%. That's still roughly 1 in 20 dependencies.
20% of all AI-suggested packages are hallucinations (Snyk data).

2. Slopsquatting: when hallucination becomes an attack vector

This is the part that scares me. When AI hallucinates a package name that doesn't exist (aws-helper-sdk, express-rate-guard, huggingface-cli), someone can register that name with malicious code. And because AI hallucinates the same names consistently (43% of hallucinated names repeat across 10 separate queries, per USENIX Security 2025), the attacker knows exactly what to squat.

Researchers classified the hallucinations:

Pure fabrication (51%): plausible but invented. express-rate-guard.
Conflation of two real names (38%): react-codeshift (jscodeshift + react-codemod). Dangerous because they sound semantically correct.
Typo of a real package (13%): lodahs instead of lodash.

For Android this matters because Gradle pulls dependencies from Maven Central and Google Maven. An attacker can publish a malicious artifact under a hallucinated name and wait for an AI to suggest it. Developer Zhenya Sedoy built SafeDroid, a GitHub Action that validates Gradle dependencies before merge, specifically because "AI sometimes confidently suggests a package name that doesn't exist."

3. Coroutines and lifecycle: leaks that don't crash, but kill

This is the Android-specific stuff that vibe coding is worst at. Praveen Yadati, researching AI-generated Kotlin/Compose code, identified five major failure patterns.

Wrong coroutine scope

AI loves GlobalScope or forgets to cancel coroutines entirely. A leaked coroutine doesn't crash. It just runs in the background forever, draining battery and creating bugs you won't find until users report that their phones are hot and their battery is dead by lunch.

Force-unwrap (`!!`) operators

Kotlin is designed for null safety. AI responds by sprinkling !! everywhere to make the code compile. Every !! is a NullPointerException waiting for production. I've watched this happen: the PR looks clean, the build passes, and six hours later Crashlytics lights up.

Recomposition issues in Compose

AI rarely optimizes for Compose performance. It generates lambdas that trigger unnecessary recompositions. If your UI feels janky, check for unstable parameters being passed to composables. The AI won't flag this.

Missing loading, error, and empty states

AI builds the happy path. It almost never adds loaders, empty states, or error handling unless you explicitly ask. I now add "Include loading, empty, and error states in the UI" to every prompt. Learned that one the hard way.

Room migrations

AI generates @Database(version = 1) with no migration strategy. Add a column, crash. @AutoMigrations is almost never included.

4. What the numbers say

This isn't anecdotal. 2025–2026 produced a lot of research.

Columbia DAPLab (January 2026): Analyzed 15+ applications built through 5 top AI agents (Claude, Cline, Cursor, V0, Replit). Nine critical failure patterns:

UI Grounding Mismatch — agent doesn't understand spatial requests.
State Management Failures — state loss during refactoring.
Business Logic Mismatch — code runs without errors but produces wrong output.
Data Management Errors — ID confusion (firestore_id vs jira_id).
API & External Service Integration — hardcoded fake keys instead of requesting real ones.
Security Vulnerabilities — mixing admin and user roles.
Repeated Code — duplication instead of abstraction.
Codebase Awareness — more files means more errors.
Exception & Error Handling — suppressing errors instead of reporting them.

DAPLab's headline: agents prioritize runnable code over correct code and suppress errors instead of reporting them.

CodeRabbit (December 2025): 470 open-source PRs analyzed:

AI code has 1.7× more defects than human code.
Logic and correctness errors: 1.75× higher.
XSS vulnerabilities: 2.74× higher.
Password handling issues: 1.88× higher.
Performance issues: nearly 8× more frequent.

Lightrun Survey (2026): 43% of AI-generated code changes required additional debugging after deployment.

Google DORA Report (2025): AI adoption correlates with roughly a 10% increase in code instability.

CloudBees (2026): 81% of enterprises see rising production failures alongside AI code adoption.

Stack Overflow Developer Survey (2025, 49,000 developers):

84% use AI tools.
Only 29% trust AI output accuracy, down from 40% the year before.
35% of Stack Overflow visits are now triggered by debugging AI-generated code.

5. Context degradation: when AI forgets the project

This one is specific to Android's multi-file structure. Developer Prabhakaran Thota described the pattern: "I was spending the first 3-4 messages of every session just correcting the AI. When a teammate started using the same tools, same problem. Claude Code, Copilot, Gemini — didn't matter. No project-level context."

Dwayne Parkinson documented his Gemini experience in Android Studio: "I had to wipe our entire conversation history, losing all context. Starting fresh felt like onboarding a new teammate. I fed Gemini all my project files manually and continued the experiment."

An Android project is an AndroidManifest.xml, Gradle scripts, modules, resources, and a navigation graph. Dozens of files that have to agree with each other. An AI that drops context mid-session starts generating code incompatible with what's already there. I've watched it suggest a ViewModel that references a repository that was deleted three prompts ago.

6. Security: what AI doesn't understand

Veracode (testing 100+ AI models):

86% of AI-generated code samples fail XSS defense.
88% are vulnerable to log injection.
CWE pass rate stuck at roughly 55% from 2023 to 2025. Models got smarter. They didn't get more secure.

Hardcoded secrets: AI regularly embeds API keys, database passwords, and tokens directly in source code. Per Snyk, 80% of developers admitted to bypassing security policies when using AI tools, and only 10% scan most AI-generated code before shipping.

Read those numbers again. Eight out of ten devs skip their own security policies when an AI writes the code. That's not a tool problem. That's a process problem the tool makes worse.

7. Zero test coverage: a time bomb

Vibe-coded apps almost never include automated tests. AI generates the feature but not the safety net. Every subsequent change, by AI or human, has no guardrails. A fix in one area breaks three others, and nobody finds out until a user complains.

Praveen Yadati recommends adding to every prompt: "and write a unit test for the ViewModel using MockK and Turbine for Flow testing." When you actually do this, the AI-generated tests often reveal broken logic that the implementation was hiding. Funny how that works.

8. Real incidents

Amazon (December 2025 – March 2026): At least four Sev-1 production incidents followed the AI-assisted development mandate, including a 6-hour outage with an estimated 6.3 million lost orders.

Google AI Studio (March 2026): Google launched the ability to vibe code native Android apps directly from AI Studio. The New Stack reported: "You can now build native Kotlin/Compose apps from prompts, including emulator, device testing, and Play Console upload." The same article also warned about code quality, security, and long-term maintainability. Bold move from Google. We'll see how it ages.

9. What to actually do about it

Start with architecture, not code. Before you prompt, write three lines: what the feature does, what data it needs, how the user interacts with it. It takes thirty seconds and prevents the AI from wandering off in random directions.

Generate in layers. Data layer first (model, DAO, repository), then domain, then UI. Not everything at once. When you feed the entire feature to the AI in one prompt, it cuts corners you won't notice until later.

Be explicit about your stack. "Jetpack Compose, Material 3, MVVM, Hilt, Room, StateFlow, Kotlin 2.0." Without this, the AI mixes APIs from different Android eras. You get LiveData next to Compose, deprecated coroutine APIs next to modern ones.

Always request error states and tests. Every prompt should include: "Include loading, empty, and error states. Write unit tests with MockK and Turbine." This alone catches a surprising amount of broken logic.

Review the dangerous parts manually. You don't need to read every line, but you must check data transformations, error handling, and state management. These are where AI makes silent mistakes. A method called mapResponseToDomain is where your bugs are.

Validate every dependency. Before you install an AI-suggested package, check it exists: npm info, pip index versions, Maven Central search. Don't install blind. A hallucinated package name is an invitation for someone to register it with malware.

Use grounding tools. MCP servers like AndroJack connect AI to current Android documentation. Prompts like agents.md control how the AI responds, not what it knows. The models are frozen in time. Your tooling shouldn't be.

Treat AI like a very fast junior dev. Praveen Yadati put it well: "Think of it less as replacing your skills and more as hiring a very fast, very eager, slightly overconfident junior developer. You still need to be the tech lead." If you wouldn't merge a junior's PR without reading it, don't merge AI code without reading it either.

10. Where we actually are

I've shipped AI-generated Android code. Some of it is still running. Some of it caused incidents I'd rather not think about.

The tool is a multiplier. A developer who knows the platform uses it to move 3–4× faster on boilerplate. A developer who doesn't understand Android gets buried under code that compiles and ships incorrect behavior.

The numbers don't leave much room for debate: 43% of AI code needs post-deployment fixes. 81% of enterprises see rising incidents. AI code security hasn't improved in three years. The problem isn't the AI. It's developers shipping code they didn't read.

If you don't know what the model generated, you can't own what it deploys.

Sources: Columbia DAPLab (2026), CodeRabbit State of AI vs Human Code Generation Report (2025), USENIX Security (2025), Lightrun Developer Survey (2026), Google DORA Report (2025), CloudBees AI Code Production Failures Survey (2026), Veracode GenAI Code Security Report, Stack Overflow Developer Survey (2025), Snyk Secure Adoption in the GenAI Era, Praveen Yadati / Medium, Vikas Sahani / dev.to, Zhenya Sedoy / dev.to, Modall (2026).

Android 18 Is Turning Into an "Intelligence System." I'm Not Sure Whether to Be Excited or Worried.

Artem Garazha — Fri, 02 Oct 2026 14:25:39 +0000

I've been building Android apps for years. Kotlin, Jetpack Compose, the usual stack. For most of that time, "AI on Android" was a chatbot overlay or a cloud API charging by the token. That's changing fast.

Google just wrapped Android Dev Summit 2026, and the 2027 picture is sharp enough to sketch. Android 18 is being framed as an "Intelligence System." Not an operating system with AI features bolted on. An OS built around AI from the ground up.

After spending a few days reading through the sessions, the hardware specs, and the API previews, here's what I think is actually real and what it means for someone like me who builds apps alone.

12 GB of RAM. Not a suggestion.

If you want the full on-device AI suite (what Google calls "Gemini Intelligence"), your phone needs 12 GB RAM minimum. Add a flagship SoC with INT4/INT8 tensor hardware, enforced crash-rate SLOs, latency budgets for token generation, and thermal throttling requirements.

That is a big bet. Google is saying that by 2027, resident on-device models like Gemini Nano v3 will sit warm in memory right alongside your normal app. They're part of the OS, not an app you launch.

For developers, this splits the world in two: AI-capable devices and everything else. Your APK has to handle both. Feature flags, graceful degradation, the works.

The Android Context Engine: proactive, not reactive

Previous Android versions treated AI as something you summoned. You opened Gemini. You asked a question. You got an answer. Android 18 adds the Android Context Engine, a background service that tracks user intent, screen context, and app tasks so it can act before you ask.

Translation: your phone sees a grocery list in your notes app and offers to add items to your cart. It notices you text your partner every time you leave work and offers to automate it. This is not a chatbot responding to prompts. This is an OS-level agent watching and acting.

Google is also deprecating legacy Google Assistant components. Gemini is becoming the system service underneath, not an app on top. Fundamental rearchitecture.

AppFunctions: your app becomes an API for AI

This is the part that directly affects how I write code. Starting with Android 16 and maturing through Android 18, apps declare AppFunctions: structured capabilities that AI agents invoke without opening your UI.

You extend AppFunctionService, annotate callable methods with @AppFunction, mark parameters and return types as @AppFunctionSerializable, and the OS indexes everything into XML. An agent queries AppFunctionManager, discovers what your app can do, and does it.

It's Android's answer to MCP tool servers. The transport is the platform itself. The "server" is an app the user already installed.

What this looks like in practice: your calendar exposes createEvent. Your messages app exposes sendMessage. Your todo list exposes addTask. An AI agent orchestrates across all three: "book a dentist appointment, add it to my calendar, text my partner I'll be late."

The permission is EXECUTE_APP_FUNCTIONS. One blanket grant, not per-function. Google clarified in July that third-party AI integrations fall under existing User Data policy, which closes a loophole before it opened. Still open: whether an agent's invocation counts as a "highly compelling feature" that justifies broad data access under Play Store rules.

The EU just forced Google's hand: 11 features must open up

On July 16, 2026, the European Commission adopted binding specification decisions. Third-party AI agents must get access to 11 Android features, grouped into four buckets:

Invocation: long-press home button handle. Always-on hotword detection.

Context: centralized access to on-device app data. Context-aware intelligence. Ambient sensor streams.

Actions: AppFunctions for in-app tasks. Screen automation in separate virtual windows. System-level controls like brightness and do-not-disturb.

Resources: Gemini Nano models. Running your own on-device models. Background execution.

Deadline: Android 18, by August 1, 2027. Concurrent hotword detection (multiple assistants listening for different wake words simultaneously) is pushed to Android 19, August 1, 2028.

Why this matters: the agent landscape won't be Gemini-only. Third parties get equal access to the OS plumbing Google uses for its own assistant. For developers, that means building AppFunctions for a diverse set of agents, not just one.

Gemini Nano: what actually runs on-device

Gemini Nano v3 is the 2026 baseline. Multimodal transcription across 10+ languages offline. Contextual UI assistance. Magic Cue. No outbound network latency. It runs on Pixel 8+, Samsung S24+, Xiaomi, Motorola, and more.

Models are 1.8B to 3.25B parameters with 4-bit quantization. Context window is 4,096 tokens. Not huge by cloud standards, but targeted. ML Kit's GenAI Prompt API graduated from prototype to production, backed by Nano v4. There's a Structured Output API returning typed objects from on-device generation. Prefix caching reuses intermediate LLM state across recurring prompt sections (unglamorous latency and battery work that never makes a keynote).

Privacy: inference runs inside pKVM (protected Kernel-based Virtual Machines) via the Android Virtualization Framework. Sensitive UI and screen processing lives in isolated memory partitions the host OS kernel can't touch. Zero-knowledge inference. Cryptographic validation of outbound connections from AI core processes.

Android XR and the multimodal thing

Not all of this is about phones. Google is pushing Android XR: spatial computing with multimodal agent grounding. Gemini Nano 4 is built for audio-first, ultra-low-power devices (smart eyewear, headsets, glasses).

Near-zero latency audio feedback. Real-time environment translation. Your phone agent follows you across Pixel, Galaxy, foldable, desktop mode, and eventually glasses.

What I'm actually doing

I'm not waiting for Android 18. Here's my list:

Add AppFunctions now. If your app does anything an agent might want to invoke (calendar events, messaging, task management, media), wrap it in @AppFunction annotations. The schema costs almost nothing. Being agent-ready by 2027 will matter.

Test on-device inference. AICore and ML Kit GenAI APIs are production-ready. Stop designing UX around cloud latency. Figure out what runs localy and work from there.

Plan for the RAM gap. Your APK must degrade gracefully on sub-12 GB devices. Different code paths. Feature flags. Annoying extra work, but the alternative is crashes on older hardware.

Watch the EU timeline. August 1,2027 is the Android 18 compliance deadline. If you distribute in Europe, your AppFunctions may need to work with non-Gemini assistants.

Android is no longer an operating system in the traditional sense. It's becoming a runtime for AI agents that happen to also run apps. The phone is not a device you operate. It's a device that operates on your behalf. For developers, that means our job isn't just building UIs anymore. It's building capabilities that software (not just humans) can invoke. I'm not entirely sure how I feel about that. But I'm not betting against it.

I build Android apps as a solo developer. You can find my retro-style Android app demo on YouTube and follow my dev journey on Instagram.

Previous article: My retro app just learned to answer to an AI agent. What Android 17 actually means for me.

My retro app just learned to answer to an AI agent. What Android 17 actually means for me.

Artem Garazha — Thu, 01 Oct 2026 16:08:34 +0000

June 16. Google ships Android 17, and I read the announcement the way developers do: half skimming, half squinting for the part that breaks my weekend. I'm Artem Garazha, I build Android apps from Ukraine, and my current obsession is a little retro-styled app called PinUp, which I present on my YouTube channel and which I mostly ship to the Play Store by myself, without a team. So when Google said "mandatory resizability" and "an intelligence system" in the same breath, I was paying attention.

The part nobody can skip: your app has to resize now

If you target API level 37 on a device with sw > 600dp, Android 17 removes the opt-out. The system starts ignoring things we've all been hiding behind for years: screenOrientation, setRequestedOrientation(), resizeableActivity="false", aspect ratio constraints. Legacy manifest attributes. Gone. Games get an exemption based on Play category, but a "lifestyle" or "tools" app does not.

I had one of those legacy attributes. One. It was in a screen that honestly nobody uses on a tablet, which is exactly why it survived. The lesson is not about the attribute. It's that large screens are no longer a separate world you plan for in Q4. Google puts 580 million of them in the hands of users, and there's a new Googlebooks line (ChromeOS on the Android stack) coming, so the large-screen population keeps growing. Your app has to handle any window size, respect the user's posture, and support free-form windowing. If you're using Jetpack Compose, you're mostly in luck. That's the quiet win of the Compose era: declarative layouts don't care about orientation.

The new multitasking stuff is more fun. App Bubbles: long-press any app icon in the launcher and it becomes a floating bubble. On tablets there's a Bubble Bar in the taskbar to dock them. Desktop mode gets interactive PiP, where the pinned window is still fully clickable, not a read-only video tile. I already tested the long-press on a Pixel. It works. It's a bit much, honestly, but my app survived it, which is more than I can say for my old layout with a hard-coded 16:9 video block.

The part I actually care about: AppFunctions and Android MCP

Here's the headline for people who've been watching what happened in the web world. Android 17 expands AppFunctions, a platform API with a matching Jetpack library, that lets your app expose its capabilities as orchestratable "tools" for Android MCP, the on-device equivalent of the Model Context Protocol. An AI agent, in practice Gemini, can discover your app's functions and execute them with access to local state. No webview. No scraping. A real API call into your app.

The way you add it is almost insulting in how easy it is. You annotate a class and write KDoc:

class NoteFunctions(private val noteRepository: NoteRepository) {
    /**
     * Adds a new note to the app.
     *
     * @param title The title of the note.
     * @param content The note's content.
     */
    @AppFunction(isDescribedByKDoc = true)
    suspend fun createNote(
        appFunctionContext: AppFunctionContext,
        title: String,
        content: String
    ): Note = noteRepository.createNote(title, content)
}

That's it. The Jetpack library is in alpha, there's an "agent skill" that analyzes your app's workflows and generates the code for you, plus ADB commands and a test agent app to simulate the integration. Gemini hookup is in private preview right now, but you can start preparing. There's an early access program at goo.gle/eap-af if you want in.

Why does this matter to me specifically? My app is small, personal, aesthetic. The kind of app an agent could plausibly drive: "add this to my board", "show me the last thing I saved". Before AppFunctions, the only way for an assistant to touch my app was for the user to open it and tap through. Now the app can say "here is a verb" to the system. I've been prototyping one function against the test agent app, and the moment the simulated agent called it and my UI updated, it felt like the app got a door.

One caveat I'd take seriously: your KDoc becomes your API documentation for a machine reader. If your docs are garbage, your function is garbage. I rewrote a few comments that were written for human colleagues, and that's a weird new job description: documenting for LLMs.

What I did this weekend

Practical list, for the solo developer:

Bump targetSdk to 37 in a branch. Run the app on a tablet, rotate it, drag it to a corner in free-form mode. You'll find your layout sins fast.
Grep for the legacy orientation attributes. If you find them, ask whether the screen actually needs the lock.
Pick one or two user workflows in your app and write them down as functions with parameters. That's your AppFunctions shortlist.
If your app is public and has reviews, check Play Console: the resizability requirement is enforced per API level, so it's a deadline, not a suggestion.

I also took the chance to re-shoot the presentation video, because the new multitasking features make for better demo footage than my previous "here is my app on a phone" setup.

Where this leaves me

Android 17 is a big release, and Google's framing of it as an "intelligence system" is doing a lot of work in that sentence. What I can actually see is more modest and more useful: the platform is preparing a stable way for agents to call into apps, and it's forcing the large-screen question to the front of your backlog. Neither of those is a problem for an app built in Compose with a sane layout strategy. Both are problems for the app you keep telling yourself you'll refactor in the spring.

I'll write up the AppFunctions prototype when it's further along, probably with the demo video. If you want to see where the app is headed, my Instagram posts the build progress between releases.