DEV Community: Artem Garazha

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.