For a long time, Android gave developers a quiet way out. If your app wasn’t ready for resizable windows or unexpected orientations, you could declare it in the manifest — lock to portrait, fix an aspect ratio, mark the activity as non-resizable — and the platform would mostly respect it. That arrangement is ending.

In February 2026, Google published a post explicitly framing the changes coming in Android 17 as the next phase of its adaptive roadmap. The headline is straightforward: Android 17 removes the developer opt-out for orientation and resizability restrictions on large screen devices. When you target API level 37, those manifest attributes and runtime APIs — screenOrientation, setRequestedOrientation(), resizeableActivity, minAspectRatio, maxAspectRatio — are simply ignored on any device whose smallest screen dimension is 600dp or larger. There’s no override, no flag to enable the old behavior. It’s gone.

The practical deadline that gives this teeth: Google Play will require apps to target API level 37 starting in August 2027. That’s not far off for teams with large codebases or complex UI work.

This Isn’t New — But Now It’s Mandatory

The groundwork was laid in Android 16, which introduced these changes while still allowing a temporary opt-out to ease the transition. Google says many developers have already made the move when targeting API level 36. Android 17 closes the door for those who haven’t. No new behaviors are being introduced; the opt-out is simply no longer available.

The scope of the change is worth being precise about: it applies to large screens, defined as devices where the smallest display dimension is at least 600dp. It does not apply to smaller phones, and it explicitly carves out apps flagged as games via the android:appCategory manifest attribute. So if your app is a game, you have more breathing room. If it’s anything else and it runs on tablets, foldables, or — as we covered recently — connected external displays, you are affected.

The Failure Modes Google Is Expecting

The February post doesn’t just describe what’s changing — it anticipates the problems teams will hit and names them directly. That specificity is worth paying attention to, because these aren’t edge cases. They’re the natural consequence of assumptions that seemed safe on a phone but break down the moment the window shape becomes unpredictable.

Camera previews that stretch or rotate. This is the first problem the post calls out, and it’s a common one on foldables and landscape tablets. Apps that assume fixed relationships between camera sensor orientation and device orientation produce previews that are cropped, rotated, or distorted when those assumptions no longer hold. In multi-window, desktop windowing, or connected display scenarios, the window the app occupies is only a portion of the screen — which means using screen size to determine camera viewfinder dimensions will produce a stretched preview. The recommended fix is Jetpack CameraX, which handles these transformations automatically. For Camera2 codebases, the CameraViewfinder library is the next best option.

Stretched layouts and unreachable buttons. If you’ve set buttons or form fields to fillMaxWidth or match_parent, they look fine on a phone. On a tablet in landscape, they stretch awkwardly across the full screen. More critically, action buttons — a Save or Login at the bottom of a screen — can end up offscreen entirely in landscape orientation if the container isn’t scrollable. The post offers specific Compose patterns for both: using widthIn to cap component width, and adding verticalScroll to containers so nothing gets pushed out of reach.

Lost state on configuration changes. Removing orientation and aspect ratio restrictions means window size changes will happen more often — when users rotate their device, fold or unfold it, or resize your app in split-screen or desktop windowing. By default, these configuration changes destroy and recreate the activity. If your app doesn’t manage this properly, users lose scroll position, partially filled forms get wiped, and navigation history disappears. The post recommends proper use of saved state APIs, and notes that with Jetpack Compose you can opt out of activity recreation entirely, letting window size changes trigger recomposition instead.

The Testing Tools You Should Know About

Two specific tools get highlighted in the post for verifying your app handles these scenarios correctly.

Compose UI Check is an automatic UI auditing tool built into Android Studio that scans your Compose UI for adaptive issues and surfaces suggestions. It can catch problems — like components that will stretch badly at wider widths — without you having to manually resize an emulator and look for them.

DeviceConfigurationOverride is a testing API that lets you simulate specific display characteristics in your tests — particular window sizes, density values, or font scale configurations — without needing physical hardware or a running emulator session. For teams writing UI tests, this makes it possible to build adaptive coverage into your standard test suite rather than treating it as a manual QA step.

For hands-on testing, Google recommends the Android 17 Beta with the Pixel Tablet and Pixel Fold emulators in Android Studio, targeting sdkPreview = "CinnamonBun". Teams not yet targeting API level 36 can use the app compatibility framework to enable the UNIVERSAL_RESIZABLE_BY_DEFAULT flag and test the behavior ahead of formally bumping the target SDK.

The Underlying Shift

It’s worth stepping back to see what this post represents in context. Android 16 introduced these API changes with an opt-out. The connected display support that reached general availability in Android 16 QPR3 created real-world scenarios where phones run windowed desktop sessions on external monitors. Android 17 removes the opt-out. The adaptive roadmap is progressing in a straight line, and each step makes the previous workarounds less viable.

The post is explicit that the goal is a consistent, high-quality experience across all Android form factors — phones, foldables, tablets, desktop windowing, car displays, XR. That’s a broad mandate. For development teams, the practical takeaway is the same one that keeps showing up across Google’s recent posts: “phone-first” is still a valid starting point, but “phone-only” is becoming an increasingly fragile assumption. The platform is systematically removing the mechanisms that allowed that assumption to survive.

August 2027 sounds distant. For large apps with deep UI debt, it isn’t.

For years, “desktop mode” on Android felt like a curiosity — a feature you could technically trigger by plugging a phone into a monitor, but one that nobody built for and few users relied on. That era is now officially over. In March 2026, Google announced that connected display support has reached general availability with the Android 16 QPR3 release — and the implications for app developers are real.

The feature, which was first shown at Google I/O 2025, allows users to connect their Android device to an external monitor and immediately access a desktop windowing environment. Apps run in free-form or maximized windows; users can multitask across multiple apps simultaneously, just as they would on a traditional desktop OS. A taskbar shows active apps, lets users pin favorites, and the whole experience is built on Google and Samsung’s joint effort to bring a coherent desktop experience across the Android ecosystem.

Crucially, this isn’t mirroring. When a supported phone or foldable connects to a display, a new desktop session starts on that display — while the phone maintains its own separate state. When a tablet like the Samsung Galaxy Tab S11 connects, the desktop session extends across both screens, letting windows, content, and the cursor move freely between them. That’s a meaningfully different architecture than simply projecting what’s on your screen to a bigger canvas.

At launch, connected displays are supported on Pixel 8, 9, and 10 series phones and a range of Samsung devices including the S26, Fold 7, Flip 7, and Tab S11.

What the App Experience Requires

Google’s announcement is clear about what apps need to do to show up well in this environment. If your app is already built with adaptive design principles, it should automatically adopt the desktop look and feel. If it’s locked to portrait orientation or assumes a touch-only interface, the post is equally direct: now is the time to modernize.

Three specific areas get called out in the official guidance:

Dynamic display handling. The Display object associated with your app’s context can change when a window moves to an external display or when display configuration changes. Apps need to handle configuration change events and query display metrics dynamically rather than caching them — a pattern that trips up a lot of existing code.

Density configuration changes. External monitors can have very different pixel densities from the device’s primary screen. Layouts and resources need to adapt correctly, which means using density-independent pixels for layouts, providing density-specific resources, and ensuring your UI scales without breaking.

External peripheral support. When users connect to a monitor, they typically add a keyboard and mouse too. Hover states, keyboard shortcuts, and proper mouse and trackpad handling all need deliberate attention that phone-only development never demanded.

New Breakpoints, New Layout Thinking

The desktop push also comes with a concrete tooling update. Jetpack WindowManager 1.5.0 adds two new width window size classes: Large (1200dp–1600dp) and Extra-large (1600dp and above). These extend the existing breakpoint guidance specifically for screens bigger than typical tablets.

The intent is practical: simply scaling up a tablet’s expanded layout doesn’t produce a good experience on a wide external monitor. An email app that comfortably shows two panes at tablet width could show three or four panes on a large display — a mailbox, message list, full message content, and a calendar panel, all at once. The new size classes give teams the official vocabulary to design for that.

To use the new breakpoints, switch from WindowSizeClass.BREAKPOINTS_V1 to WindowSizeClass.BREAKPOINTS_V2 in your project.

Navigation 3, Jetpack’s new Compose-compatible navigation library that just reached its first stable release, is also worth noting here. It supports displaying multiple destinations simultaneously and switching between layouts seamlessly — which makes it a useful tool for building the kind of adaptive, multi-pane experiences that desktop-scale screens invite.

The Larger Picture

Android’s desktop push is happening alongside a broader tension in the industry around what a “personal computer” even means anymore. Foldables have already complicated the phone-tablet line. External display support with proper windowing is the next step in blurring the phone-laptop boundary — and with the feature now generally available on current Pixel and Samsung hardware, it’s not a future consideration anymore.

The practical implication for development teams is straightforward even if the implementation work isn’t: “tablet support” and “desktop mode support” are converging into a single discipline. The sooner teams treat them that way — with shared guidelines, shared test coverage, and shared design vocabulary — the less scrambling there will be when desktop sessions start generating real user complaints.

Google has laid out the direction. The engineering work of getting there is, as usual, left to everyone else.

What changed from the previous version:

• The original framed this as a blog post describing a feature. It’s actually a general availability announcement tied to Android 16 QPR3 — significant difference in stakes.
• Removed the reference to a “second blog post” (the original notes were combining two separate posts). This article is based solely on the one official post.
• Added the correct supported device list (Pixel 8/9/10 series, S26, Fold 7, Flip 7, Tab S11).
• Added the Jetpack WindowManager 1.5.0 breakpoint details (Large/Extra-large size classes), which were missing entirely.
• Added Navigation 3 context, which the official post highlights.
• Corrected the framing around tablet vs. phone behavior — the official post makes a distinction between phone connections (separate desktop session) and tablet/foldable connections (extended session across both displays).
• The “Adaptive Design lab” mentioned in the original notes doesn’t appear in this post — removed to avoid inaccuracy.

I’ll be honest: when I first saw Google announce Experimental Gems inside Gemini, I assumed it was just a rebrand of their existing Gems feature. Give Gemini a persona, some instructions, call it a day. I nearly skipped right past it.

That was a mistake. Experimental Gems — powered by a Google Labs tool called Opal — are something meaningfully different. They’re not chatbot personas. They’re closer to interactive mini-apps: things with actual structured workflows, multiple steps, and interfaces you can share with your team. You build them entirely in plain English.

No code. No deployment. No infrastructure to manage. You describe what you want, and Opal generates a working app.

What actually changes here

Let me explain why this is different from just writing a very detailed system prompt.

When you create an Experimental Gem, Opal converts your description into a visible step graph — a structured list of stages that you can inspect, edit, reorder, or tweak individually. It’s not a black box. You can see the logic. You can change it without rewriting everything from scratch.

It’s the difference between having a smart assistant who just improvises every time, and having one who follows a documented process you can actually review and improve.

That distinction matters a lot for developers. We like inspectable systems. We like things we can version, adjust, and hand to teammates with confidence that they’ll get consistent results.

The developer use cases that actually make sense

The obvious question is: okay, but what would I actually build with this?

The sweet spot is tasks that are too complex for a one-liner prompt, but too narrow and repetitive to justify building a full app. Every development team has a pile of these.

Here are the ones I’d build first:

None of these are revolutionary tasks. They’re just things that eat time and benefit from consistency. The point of a Gem isn’t to do something impossible — it’s to take something you’d normally do manually, over and over, and package it so anyone on your team can run it in seconds.

The team angle is where it gets interesting

I’d actually argue the biggest benefit isn’t personal productivity. It’s what happens when you share a well-crafted Gem with your team.

A senior engineer who builds a solid “microservice design review” Gem has essentially packaged their architectural instincts into something a junior engineer can run independently. A DevOps person who builds a “post-incident log analyzer” Gem has turned a manual, expert-intensive task into a self-service workflow anyone on-call can use at 2am.

That’s knowledge transfer that actually sticks. Not a wiki page nobody reads. A tool people actually run.

Gems are also remixable. If your teammate built a documentation Gem tuned for REST APIs, you can copy it, tweak the output format for GraphQL, and save a new variant — all in plain English, all in minutes.

What you should know before diving in

A few honest caveats, because this is still experimental.

Right now, Experimental Gems only work in the Gemini web app, and only in English. Enterprise Workspace accounts and mobile aren’t supported yet. The feature lives in Google Labs, which means it can change, break, or disappear without notice.

Data you send through Opal-powered Gems isn’t governed by the same controls as standard Gemini. Before running anything sensitive — client code, proprietary systems, personal data — check the current data handling policy.

And the usual AI caveats apply: verify the outputs, especially for anything security-adjacent or architecturally significant. Treat it as a strong first draft, not a finished product.

Also worth saying: Gems live inside Gemini, not inside your stack. For anything customer-facing, SLA-bound, or needing real integration with your systems, you still want to build properly via the Gemini Developer API. Experimental Gems are a prototyping and team-enablement layer — not a production deployment.

Is it worth trying now?

Honestly, yes — especially if you’re already using Gemini regularly. The barrier to building a Gem is low enough that you can try one in the time it takes to write a good system prompt. If it works, you’ve got a reusable tool. If it doesn’t, you’ve spent twenty minutes.

The developers who figure out how to build good Gems — specific, well-structured, genuinely useful to their team — will have a real head start as this matures. Right now it’s experimental. It’ll graduate eventually, and when it does, the institutional knowledge your team has built through Gems will travel with it.

It’s not magic. It’s just a smarter way to stop doing the same thing over and over again.

The divide isn’t theoretical. Real musicians are using Lyria 3 in production, while hundreds of other artists are actively fighting against AI music generation. Understanding both perspectives reveals what’s actually at stake.

The Artists Using It

Three-time Grammy-winning rapper Wyclef Jean used Lyria 3 and Google’s Music AI Sandbox on his recent song “Back From Abu Dhabi.” His take on the technology is surprisingly nuanced.

“This is not just a machine where you’re clicking a button a hundred times, and then you’re done,” Wyclef explains. “What I want everybody to understand […] is you’re in the era where the human has to be the most creative. There’s one thing that you have over the AI: a soul. And there’s one thing that AI has over you: the infinite information.”

For Wyclef, the appeal is speed and exploration. He describes the tools as “capable of speeding up the process of what’s in my head, getting it out. You’re able to move at light speed with your creativity.” He compares it to “digging in the crates” – going through record stores to find sounds to sample. “So right now, we’re digging in the infinite crate. It’s endless.”

He’s not alone. Several musicians have tested these tools: Isabella Kensington found the “Extend” feature helpful for songwriting and trying new ideas. The Range described it as helping overcome writer’s block. Adrie expressed caution about AI generally but sees these tools opening up new experimental avenues. Sidecar Tommy noted the tools help “speeding up production and sparking complex orchestral ideas from simple beginnings.”

The pattern among these artists: they see Lyria as a collaborator that accelerates workflows and enables experimentation, not a replacement for human creativity.

The Artists Fighting It

The counterpoint is equally vocal and significantly larger. Hundreds of musicians, including stars like Billie Eilish, Katy Perry, and Jon Bon Jovi, signed an open letter in 2024 calling on tech companies not to undermine human creativity with AI music generation tools.

Their concerns center on training data and economic impact. AI music models learn from existing music, raising questions about whether artists consented to their work being used for training. More fundamentally, they worry that flooding the market with AI-generated music devalues human artistry and makes it harder for working musicians to earn a living.

Critics are calling the output “musical slop” and questioning the copyright implications of the training data. The criticism isn’t just about quality—it’s about the entire model of training AI on copyrighted work without explicit permission or compensation.

What Lyria 3 Actually Does

The technology behind the debate is now accessible to anyone. Lyria 3 is available to all Gemini users 18+ in 8 languages (English, German, Spanish, French, Hindi, Japanese, Korean, Portuguese). You can create 30-second tracks using text descriptions or by uploading photos/images.

It generates lyrics automatically based on your prompt and allows control over style, vocals, and tempo. All tracks include SynthID watermarking to identify AI-generated content.

For professionals, ProducerAI, backed by The Chainsmokers, just joined Google Labs, using Lyria 3 for professional-grade music creation with granular controls over tempo and time-aligned lyrics. This positions Lyria not just as a consumer toy but as a tool for serious music production.

The Real Question

The divide between artists like Wyclef who embrace these tools and artists like Billie Eilish who oppose them isn’t about technical capability—it’s about philosophy and economics.

Pro-AI musicians see infinite creative possibilities and accelerated workflows. Anti-AI musicians see their work being used without permission to train systems that could eventually replace them. Both perspectives are valid, and they’re not mutually exclusive.

Wyclef’s emphasis on humans bringing “soul” while AI brings “infinite information” suggests a potential middle ground: AI as a tool that amplifies human creativity rather than replaces it. But that only works if the economic model doesn’t destroy musicians’ livelihoods in the process.

What This Means Going Forward

Google’s decision to make Lyria 3 widely available through Gemini—not locked behind professional tools or expensive subscriptions—forces this debate into the mainstream. It’s no longer theoretical. Anyone can generate music with AI right now.

The watermarking through SynthID is Google’s attempt to maintain transparency, ensuring AI-generated music can be identified. But watermarking doesn’t address the fundamental concerns about training data or economic impact.

The music industry is facing a question that won’t be resolved through technology alone: can AI music generation coexist with human artistry in a way that’s economically viable for working musicians? Or will the “infinite crate” that Wyclef celebrates eventually replace the human diggers entirely?

Right now, both futures seem possible. Which one we get depends on decisions about copyright, compensation, and how we value human creativity—decisions that go far beyond what AI can do.

The Problem That Plagued Every Android Developer

If you’ve worked with Android Studio for any length of time, you’ve encountered the JDK nightmare. Import a colleague’s project, and suddenly you’re troubleshooting JDK version mismatches. Clone a repository, and spend twenty minutes figuring out which exact JDK version the project needs. Switch between projects, and watch multiple Gradle daemons spawn because each uses different JDK configurations.

The old approach to JDK management was manual and fragile. You had to have the right JDK installed locally, configure it correctly in Android Studio, and hope everyone on your team did the same. When something went wrong—and it frequently did—you were stuck googling error messages and adjusting settings until builds finally worked.

What Panda Changes

Android Studio Panda now uses Gradle Daemon JVM criteria by default for new projects, letting Gradle auto-detect compatible JDKs installed on your machine or auto-provision the required JDK by downloading it if it cannot be found locally.

In practical terms: you no longer need to manually install and configure specific JDKs before opening a project. Gradle figures out what it needs and either finds it on your system or downloads it automatically. The setup friction that consumed the first twenty minutes of working with any new Android project? Largely eliminated.

For existing projects using compatible Gradle versions, Android Studio offers automatic migration from the old Gradle JDK configuration to the new Daemon JVM criteria, maintaining your existing specifications while moving to the better system.

Why This Actually Matters

The benefits are immediate and tangible:

Fewer setup errors. New team members or collaborators can clone and build projects without JDK configuration headaches. The “invalid JDK selection” errors that plagued project imports? Mostly gone.

Consistent builds everywhere. JDK selection for Gradle builds is now consistent across different machines and between the IDE and command-line, preventing multiple Gradle daemons from spawning. Those mysterious build performance issues caused by daemon proliferation? Much less likely.

Less maintenance overhead. You’re not manually managing JDK installations and configurations across different projects anymore. Gradle handles it, using the same criteria whether you’re building in Android Studio or from the terminal.

The Technical Foundation

This feature leverages Gradle’s toolchain system, which was stabilized in Gradle 9.2.0. The toolchain mechanism provides reliable JDK detection and provisioning, making the entire system more robust than previous attempts at automatic JDK management.

You can still configure project Daemon JVM criteria manually if needed—it’s under File > Settings > Build, Execution, Deployment > Build Tools > Gradle on Windows/Linux, or Android Studio > Settings on macOS. But for most developers, the automatic detection and provisioning removes the need to touch these settings at all.

The Bigger Picture

Android Studio Panda isn’t packed with flashy new features. No revolutionary AI capabilities, no dramatic UI overhauls. Instead, it fixes a fundamental workflow problem that has frustrated Android developers for years.

That’s often how the most valuable improvements arrive—not through marketing announcements and demo videos, but through unglamorous infrastructure work that removes friction from daily development. JDK management is now one less thing to think about, configure, or troubleshoot.

For a tool you use every day, eliminating even small sources of friction compounds into significant productivity gains. Android Studio Panda delivers that, and every Android developer will benefit from it.

More on AI assistance in IDEs here

1. How an app adapts as its window changes shape and size
2. How it behaves in multitasking and multiwindow environments
3. How it stays usable across touch, keyboard, mouse/trackpad, and pen

The convergence isn’t accidental. It’s a response to the same hardware reality: foldables and tablets, laptops with touchscreens, desktop-class windowing on tablets, and “one app, many contexts” distribution (phone → tablet → desktop → large external display). The result is a shared design center of gravity: adaptive layouts + multiwindow + multi-input.

Adaptive layouts: the window is the unit, not the device

All three ecosystems have moved away from “design for devices” and toward “design for available space.”

Google’s Material 3 adaptive guidance is explicit: window size is dynamic and changes with user behavior—multi-window modes, resizing, and foldable postures—so layout should respond to window size classes rather than device labels. Material describes a set of window size classes (from compact through extra-large) and encourages layouts that reflow across these breakpoints. It also frames common UI structures in terms of 1–3 panes that can appear or collapse as space changes—an idea that maps cleanly to modern tablet and desktop UI.

Microsoft’s Windows app design guidance reaches a very similar place through different mechanics: responsive UI is commonly achieved with VisualStateManager and AdaptiveTrigger, so layouts rearrange automatically when a window hits a specified width/height threshold. Even Microsoft’s control guidance uses this approach for navigation patterns — switching, for example, between top navigation and a left/compact navigation model based on window width.

Apple’s Human Interface Guidelines speak the same “window-first” language: people can freely resize windows down to minimum sizes, and apps should account for that resizing behavior. Apple’s HIG also emphasizes that windows should adapt fluidly to different sizes to support multitasking and multiwindow workflows.

Similarity that matters: all three are teaching developers to treat UI as a responsive system driven by runtime constraints. Concretely, the design question is no longer “do we have a tablet layout?” but “what happens to our navigation, hierarchy, and content density when the window becomes medium, narrow, tall, split, or freeform?”

Multitasking: multiwindow is no longer optional behavior

The second convergence is that multitasking isn’t presented as a special mode; it’s treated as a default context that apps must survive.

Material’s layout guidance repeatedly anchors adaptation in scenarios like entering multi-window mode and resizing freeform windows, and it describes canonical patterns (like list-detail) that collapse from two panes to one when the window class shrinks. The framing is practical: layouts should keep working as the user changes the window, not only at app launch.

Apple’s platform guidance for multitasking similarly puts adaptation first: when supporting multitasking, your scenes should adapt to different window sizes, and Stage Manager/desktop-class features make resizable windows a core iPad experience rather than an edge case. Apple’s HIG sections on windows and multitasking reinforce that multiwindow workflows are expected and that window resizing is something the UI should handle gracefully.

On Windows, multitasking is essentially synonymous with windowing: users routinely resize, snap, and run multiple apps side by side. The Windows design hub explicitly frames guidance around consistent behavior across devices, input types, and form factors—meaning your app should still behave when it’s one window among many. The underlying adaptive UI model (states and triggers) exists precisely because multiwindow is normal, not exceptional.

Similarity that matters: across platforms, multitasking pushes the same engineering consequences: state restoration, layout performance during live resizing, and navigation that remains coherent when panes appear/disappear. The “design” problem is inseparable from lifecycle and state: a two-pane view that loses selection context when collapsing to one pane is a UX issue and a state-management issue at the same time.

Input methods: touch is table stakes; keyboard and pointer are first-class

The third convergence is input plurality. Touch-first assumptions are no longer safe, even on tablets.

On Windows, keyboard access and focusability are core accessibility and productivity concerns—Microsoft documents built-in support for access keys and keyboard interaction patterns that let users operate UI without a pointer.

Apple has spent years evolving iPad toward hybrid input. Official guidance and supporting material emphasize pointer/trackpad interaction and hardware keyboard workflows in iPad multitasking contexts (and, by extension, windowed environments). The HIG’s multiwindow push implicitly raises the importance of predictable focus, shortcuts, and pointer affordances, because windowed multitasking is strongly associated with keyboard/pointer usage.

Google’s adaptive layout framing is often paired with large-screen expectations that include keyboard, mouse/trackpad, and stylus across Android’s broader large-screen ecosystem—because the same layout needs to remain usable when interaction shifts from thumbs to cursor and keys. Material’s own multi-window framing underscores that layout must remain functional as the user changes context, which includes input context in real life.

Similarity that matters: the input problem is converging on the same checklist everywhere: reliable focus order, obvious hover/pressed states where relevant, keyboard accelerators/shortcuts, and controls that don’t depend on a single interaction model (e.g., swipe-only navigation with no keyboard alternative).

Why this convergence matters for app developers

This shared direction changes how teams should think about “platform support”:

• Adaptive layout becomes product work, not just UI polish. If your navigation model can’t collapse/expand cleanly (bottom bar side rail; single pane list-detail), you’ll feel it on iPad window resizing, Android multiwindow/foldables, and Windows snap layouts.
• State and navigation architecture are now design requirements. The better your app separates state from presentation and maintains meaningful selection/history across panes and window sizes, the more “native” it feels everywhere.
• Multi-input isn’t niche. The platforms are converging on the expectation that serious work happens with keyboards and pointers—even on devices that used to be touch-only.

The practical takeaway is simple: Apple, Google, and Microsoft aren’t asking developers to solve three different problems. They’re asking developers to solve the same problems—adaptive layout, multitasking resilience, and multi-input usability—through each platform’s idioms. If your app strategy treats those as a single design-and-architecture investment, you get leverage across ecosystems instead of re-litigating “tablet support” and “desktop support” as separate projects every year.

Agent Mode in Android Studio changes that relationship entirely. And if you haven’t tried it yet, the gap between what you’re reading about it and what it actually feels like to use is larger than you’d expect.

What Agent Mode Actually Is

The simplest way to describe it: you give Android Studio a goal, not instructions.

With Agent Mode, you can describe a complex goal in natural language — from generating unit tests to complex refactors – and the agent formulates an execution plan that can span multiple files in your project and executes under your direction.

This is fundamentally different from chat-based AI assistance. When you ask Gemini a question in the chat window, it responds with suggestions you then implement manually. When you give Agent Mode a task, the agent creates a plan, determines which tools are needed, executes those tools, evaluates the results, and keeps iterating until the task is complete.

It’s the difference between asking a colleague “how would you approach adding unit tests to this ViewModel?” and saying “add comprehensive unit tests to this ViewModel” and watching it actually happen.

What It Can Do Right Now

Agent Mode is designed to handle complex, multi-stage development tasks. You can describe a high-level goal, like adding a new feature, generating comprehensive unit tests, or fixing a nuanced bug.

In practice, the tasks it handles well include things that used to consume large portions of a developer’s day: generating test coverage for existing code, refactoring components to follow updated architecture patterns, fixing build errors that cascade across multiple files, and updating UI components to new Compose APIs.

Agent Mode uses a range of IDE tools for reading and modifying code, building the project, searching the codebase, and more to help Gemini complete complex tasks from start to finish with minimal oversight.

That last part matters. It’s not just reading your code — it’s building it, running it, seeing what breaks, and fixing those breaks. The loop that a developer manually runs dozens of times per day is now something the agent can run autonomously.

You’re Still in Control

Before this sounds like science fiction or a job threat, the implementation is deliberately conservative about developer control. You are firmly in control, with the ability to review, refine and guide the agent’s output at every step. When the agent proposes code changes, you can choose to accept or reject them.

Every proposed change waits for your approval before being applied. You can see exactly what the agent plans to do before it does anything. If a proposed change doesn’t look right, you reject it and redirect.

There’s also an “Auto-approve” option if you are feeling lucky — especially useful when you want to iterate on ideas as rapidly as possible. Most developers will keep auto-approve off initially and develop a sense of when the agent’s judgment can be trusted for specific task types.

This design reflects a realistic understanding of where AI assistance is today: capable enough to handle large, well-defined tasks autonomously, but still requiring human judgment for the decisions that actually matter.

The Context Window Is the Key Ingredient

What makes Agent Mode different from previous AI coding assistants isn’t just the agentic architecture — it’s the context window backing it.

You can add your own Gemini API key to expand Agent Mode’s context window to a massive 1 million tokens with Gemini 2.5 Pro. A larger context window lets you send more instructions, code, and attachments to Gemini, leading to even higher quality responses. This is especially useful when working with agents, as the larger context provides Gemini 2.5 Pro with the ability to reason about complex or long-running tasks.

For context: a million tokens can hold roughly 750,000 words of text. That means Agent Mode can hold your entire codebase in context simultaneously, not just the file you’re currently editing. It understands how your ViewModel connects to your Repository connects to your data layer — and that holistic understanding is what enables it to make changes across multiple files without breaking things.

Previous AI coding tools that worked on single files or small snippets were limited precisely because they couldn’t see the whole picture. Agent Mode can.

Journeys: AI-Powered UI Testing

Alongside Agent Mode, Android Studio introduced another agentic feature worth knowing about: Journeys.

Journeys for Android Studio leverages the reasoning and vision capabilities of Gemini to enable you to write and maintain end-to-end UI tests using natural language instructions. These natural language instructions are converted into interactions that Gemini performs directly on your app.

The practical impact: instead of writing detailed UI test code that breaks every time your layout changes, you write instructions like “navigate to the checkout screen and complete a purchase with the test card.” Gemini figures out how to execute that intent against your actual running app.

Because Gemini reasons about how to achieve your goals, these tests are more resilient to subtle changes in your app’s layout, significantly reducing flaky tests when running against different app versions or device configurations.

Flaky tests are one of the most persistent sources of wasted time in Android development. If Journeys delivers on this promise consistently, it addresses a problem that has frustrated Android developers for years.

Local Model Support for Privacy-Conscious Teams

One underreported addition: Android Studio now supports local models via providers like LM Studio or Ollama for developers with limited internet connectivity, strict data privacy requirements, or a desire to experiment with open-source research.

For teams working on sensitive codebases — banking, healthcare, enterprise software — this matters enormously. The concern about sending proprietary code to external AI services has been a real barrier to adoption. Local model support removes that barrier, even if the experience isn’t quite as powerful as cloud-backed Gemini.

Real-World Impact Is Already Showing Up

The numbers coming out of early adopters are hard to ignore. Developers like Pocket FM have seen an impressive development time savings of 50%. That’s not a marginal improvement — that’s a fundamental change in how much a developer can accomplish in a day.

And it’s not just raw speed. Kakao used the Prompt API to transform their parcel delivery service, replacing a slow, manual process where users had to copy and paste details into a form into just a simple message requesting a delivery — this single feature reduced order completion time by 24% and boosted new user conversion by 45%.

These outcomes suggest that the impact of agentic AI isn’t confined to developer productivity — it’s changing what’s feasible to build and how quickly products can improve.

What This Means for Android Developers Day-to-Day

The honest practical impact of Agent Mode isn’t that it replaces developers. It’s that it changes what developers spend their time on.

The tasks that consumed hours but didn’t require creative thinking — writing boilerplate, generating test coverage, fixing compilation errors after a library upgrade, refactoring components to new patterns — these are exactly the tasks Agent Mode handles well. Delegating them doesn’t make you a less capable developer; it makes you a more focused one.

What remains firmly in human territory: architecture decisions, user experience judgment, performance trade-offs, understanding what users actually need. The creative and strategic work that defines good software doesn’t get automated — it gets more time.

You can delegate routine, time-consuming work to the agent, freeing up your time for more creative, high-value work.

That sentence from Google’s own announcement is worth sitting with. The framing isn’t “AI will build your apps.” It’s “AI will handle the parts of building apps that you don’t want to be doing anyway.”

How to Get Started

Agent Mode is now available in the stable release of Android Studio Narwhal Feature Drop. To use it, click Gemini in the sidebar, then select the Agent tab, and describe a task you’d like the agent to perform.

For the best experience with complex tasks, adding a Gemini API key unlocks the full 1 million token context window with Gemini 2.5 Pro. The free tier provides a smaller context window that works well for contained tasks but will hit limits on larger, cross-file operations.

You can also organize your conversations with Gemini in Android Studio into multiple threads, creating a new chat or agent thread when you need to start with a clean slate, with conversation history saved to your account.

Start with something well-defined: ask it to generate unit tests for a specific class, or refactor a particular component. Build trust with smaller tasks before handing it larger, more consequential ones. The developers getting the most value from Agent Mode are those who’ve developed a sense of which task types the agent handles reliably and which ones still need close supervision.

The Bottom Line

Agent Mode represents a genuine inflection point in Android development tooling, not just an incremental improvement to what existed before. The shift from AI-as-autocomplete to AI-as-autonomous-agent changes the developer’s role in the development process — from manually executing every step to directing an agent that handles execution while you focus on judgment and creativity.

Android Studio is the best place for professional Android developers to use Gemini for superior performance in Agent Mode, streamlined development workflows, and advanced problem-solving capabilities.

Whether that’s marketing language or genuine truth is something every developer will have to evaluate for themselves. But the early evidence — the adoption numbers, the developer testimonials, the concrete productivity improvements — suggests this is one of those rare cases where the technology has actually caught up with the promise.

Try it. Then decide.

Google’s latest large-screen messaging shifts that definition in a more consequential direction. Tablet support is no longer a special layout for a special device category—it’s a baseline expectation that an Android app behaves well across variable windows, multiple concurrent apps, and multiple input types, including scenarios that look increasingly desktop-like.

You can see the new bar most clearly in Google’s Large screen app quality guidelines, which don’t treat “tablet” as a one-off target. Instead, they define a ladder of readiness for tablets, foldables, and ChromeOS devices, with “support” meaning: the app fills whatever window it’s given, survives resizing, and remains fully usable when the user is multitasking.

A new baseline: “runs properly in any window”

The quiet redefinition starts with Tier 3—“Large screen ready”—which reads less like a stretch goal and more like a compatibility promise users now assume. Google’s definition includes:

• running full screen in both orientations and full window in multi-window
• avoiding letterboxing and “compatibility mode” behavior
• retaining state through configuration changes like rotation, resize, and fold/unfold
• basic support for keyboard, mouse, trackpad, and stylus
• support for multi-resume, where your app may need to keep updating even when it’s not the focused window
• graceful handling of exclusive resources (camera, etc.) in a world where another app may be active beside yours

That’s a different framing than “it has a tablet UI.” It’s “your app is a good citizen in a system where the user controls the window.”

Google reinforces this shift in public-facing messaging. At Google I/O 2024, the blog explicitly defines “adaptive apps” as apps that adjust based on window size changes, device posture, and even font size—conditions that show up constantly once you accept resizable windows and foldables as normal.

Tablet support now includes desktop-like multitasking

The change becomes harder to ignore once you factor in Android’s push toward more PC-style workflows on tablets. In the 2024 developer preview of desktop windowing on Android tablets, Google calls out the need for “adaptive layouts,” “more robust multitasking,” and “adaptive inputs” so apps work across the large-screen ecosystem (including environments where apps run in freeform windows).

That matters because freeform windowing turns every brittle UI assumption into a bug:

• hard-coded aspect ratios break
• portrait-only flows look awkward in a narrow landscape window
• “this screen will always have space for a bottom sheet” stops being true
• lifecycle and state handling get tested continuously by resize and focus changes

Google’s large-screen guidance is effectively a warning: the OS is moving toward more window variability, so “tablet support” must mean “window support.”

From “big phone UI” to adaptive navigation and input

Beyond baseline readiness, Google’s higher tiers make the expectations explicit.

Tier 2 (“Large screen optimized”) calls for layout optimizations across configurations plus enhanced external input support. Tier 1 (“Large screen differentiated”) goes further: multitasking that feels intentional, foldable postures, drag-and-drop, stylus integration—features that treat large screens as their own interaction environment rather than a stretched phone.

This is where the implications for existing apps get real. Many apps “support tablets” in the old sense—layouts scale, nothing crashes—but still fail the newer definition in everyday use:

• Navigation that doesn’t reflow. A bottom navigation bar that works on phones can become a reach-and-clutter problem on tablets; Google’s own guidance nudges developers toward patterns like vertical navigation on large screens and list-detail layouts.
• State that’s fragile under resize. If a resize recreates activities/fragments without robust state restoration, users lose their place—especially painful in commerce, productivity, and media flows.
• Input that’s treated as optional. Keyboard focus, pointer hover affordances, trackpad scrolling behavior, stylus interactions—these aren’t “power user extras” on large screens. They’re part of the platform’s expectation of readiness.
• Multi-window resource conflicts. Google has repeatedly stressed not assuming exclusive access to hardware like the camera because large screens are commonly used side-by-side with other apps.

What developers may need to revisit

The practical takeaway isn’t “build a tablet layout.” It’s “audit the assumptions your app makes about screens and sessions.”

In Google’s own framing, teams should evaluate how their app behaves across tablets, foldables (different postures), Chromebooks, and desktop windowing—not only whether it looks fine, but whether core flows stay intact when resized, multitasked, or driven by keyboard and pointer.

And the bar is no longer theoretical. Recent case studies on the Android Developers Blog showcase apps aligning themselves to these tiers, using window size classes, adaptive media presentation, and accessibility-driven touch targets as part of “large screen quality,” not polish.

Google isn’t loudly declaring a new tablet era. Instead, it’s redefining tablet support by standardizing what “good” means—then steadily expanding Android into more windowed, multi-input environments where “it runs” won’t be enough.

What’s changing now is scope. The major IDE assistants are steadily moving from line-by-line suggestions toward workflows that treat your project as a system: multiple files, navigation edges, refactors that preserve behavior, and task-level planning that resembles how experienced developers actually work.

Three ecosystems show the direction clearly: Android Studio with Gemini, GitHub’s GitHub Copilot and Copilot Workspace, and JetBrains’ JetBrains AI Assistant.

What changed recently: from “suggest” to “act across files”

Android Studio is formalizing agentic, multi-step work inside the IDE. Google’s Gemini experience in Android Studio is no longer framed as “chat plus completions.” The documentation highlights an Agent Mode alongside code completion and a set of actions that touch more than the current line: code transformation, refactoring/renaming, UI transformation, unit test generation, documentation drafting, and commit message generation. [Android Studio]

This matters because it signals a design goal: AI as a tool operator embedded in the coding loop, not just a text predictor. The docs also emphasize that Gemini is “under active development” and updated frequently through Android Studio preview releases—an explicit indication that Google is iterating on capabilities beyond autocomplete as an IDE feature set, not a plugin novelty.

GitHub is pushing Copilot into planning, multi-file edits, and agent workflows. On GitHub’s own blog, “agent mode” is described as a multi-step collaborator that can iterate, recognize errors, and fix issues based on natural-language intent. [GitHub] Separate updates around Copilot “modes” (ask/edit/agent) reflect a product split between quick answers, targeted edits, and longer-running tasks—an explicit move beyond completion toward “do work across the project.”

Copilot Workspace, meanwhile, reads like an attempt to productize codebase reasoning: generating plans, operating on multiple files, improving file search, and adding IDE-like navigation primitives such as go to definition—features that only make sense if Copilot is expected to traverse and modify more than a single buffer. [GitBub Blog]

JetBrains is treating AI as an IDE-native layer, plus “agentic development” as the next step. JetBrains’ AI messaging leans heavily on integration: AI features “directly into JetBrains IDEs” across tasks like explaining code, answering questions about code fragments, generating commit messages, and more—i.e., IDE operations that sit above typing speed. Their 2025 updates also point toward agents (JetBrains references “Junie” and positions it alongside AI Assistant under one subscription), which reinforces the same direction: not just “suggest code,” but help execute development tasks with more autonomy and broader context.

Why it matters: practical wins for experienced developers

Autocomplete is most valuable when you already know what you’re building. Codebase-level assistance helps most when you don’t—or when the cost is in coordination, not keystrokes:

• Refactoring with less dread. Renames and structural refactors are easy to describe (“split this class,” “extract a use-case layer,” “migrate to Compose idioms”) but time-consuming to execute safely. Tools like Gemini’s code transformation/refactor actions aim to compress the mechanical part of that work.
• Navigation that’s closer to intent than grep. “Where is this value set?” “What calls this?” “What breaks if I change the contract?” Copilot Workspace’s file search improvements and “go to definition” hint at AI becoming a higher-level navigation surface over the code graph.
• Multi-file changes as a first-class workflow. When assistants can add files, propose a plan, and update multiple touchpoints, they start to resemble a junior dev who can take a scoped task—especially for migrations, repetitive patterns, and documentation/test scaffolding. Workspace’s multi-file generation focus and Gemini’s unit-test/documentation features both align to that.

Where the ceiling still is: limitations that haven’t gone away

Even as these tools expand scope, their failure modes expand too. The biggest constraints are predictable—and developers will recognize them immediately:

1. Context isn’t comprehension. “Knowing your codebase” often means selectively reading files, guessing intent, and stitching it together. That works for conventional architectures and well-named code. It degrades fast in monorepos, highly generic code, generated sources, or projects with heavy build-time wiring.
2. Refactors need invariants, not just syntax. A tool can rename symbols and rearrange code yet still break behavior (serialization formats, subtle lifecycle ordering, thread confinement, DI graphs). The more “agentic” the tool becomes, the more important it is that it runs tests, builds, and linters—and that developers review diffs like they would a real PR.
3. Project-specific rules are hard to infer. Style guides, architectural boundaries, and product constraints live in human agreements, not code. AI assistants can help enforce patterns once you tell them, but they still struggle to consistently honor implicit rules across a whole codebase.
4. Trust and governance are now part of IDE choice. When tools can traverse files, generate commit messages, and propose multi-file changes, questions about what gets sent to a model, how context is selected, and how changes are audited become practical engineering concerns—not abstract policy debates. (The platform docs emphasize IDE integration and workflows; they also implicitly raise the stakes of how that integration is managed.)

The near-term reality

The shift is real: IDE AI is evolving from “write code faster” to “change code more confidently.” But the value isn’t magic; it’s leverage. The best results come when developers treat these tools like powerful assistants that can draft, refactor, and navigate—while the team still owns correctness, architecture, and review discipline.

In other words: less typing, yes—but more importantly, less mechanical work standing between intent and a clean diff.