Posted by Simona Milanovic, Developer Relations Engineer As Android developers, you have many choices when it comes to the agents, LLMs, tools, and command-line interfaces (CLI) you use for app development. Our goal is to help you build beautiful, high-quality Android apps, no matter how you choose to build. We’re announcing updates to our Android CLI command-line tooling, including the ability to access real devices through Android Device Streaming. We’re also sharing more Android skills, and giving you a deep dive into the Wear OS Compose Material 3 skill. ## Android CLI for command-line development Android CLI is our tool to make command-line interface Android development easier. It supports any AI agent or tool in building more efficiently for Android. Along with the `android-cli` skill, your agents use Android CLI to create, build, test, and manage Android projects, help you set up the development environment, create and run emulators, and execute test runs. ## Android Device Streaming now available in CLI It’s important to test your app on real devices to catch issues that are hardware- or OS-specific, but sometimes you don’t have access to the ones you need. Android Device Streaming gives you access to real physical devices, remotely. Your agent can now use Android Device Streaming anywhere, through Android CLI. _Connecting to a Pixel 10 Pro through Android Device Streaming_ The agent can interact with physical devices (as if they were plugged in over USB) over a secure ADB over SSL connection. This enables spinning up devices, deploying builds, collecting logs and traces, and even capturing screenshots headlessly—all through the terminal. To get started, link your project, instruct your agent to list available remote devices and decide which device you want next. Read the documentation to learn more, and see the Android CLI release notes. ## Grounding agents with Android skills To bridge the gap between LLMs’ default knowledge and platform-specific standards and updates, we keep growing our **Android skills repository**. Android skills are structured instructions (`SKILL.md` files) that ground AI agents with our official guidance from developer.android.com. Instead of relying on a model’s training cutoff, skills provide more precise and fresher data, API references and samples, and architectural patterns directly into your agent’s context. _Android skills_ With over 20 skills available, you can now equip your AI agents to handle more complex and specialized development tasks such as: * **Audit Play policy compliance:** Audit app manifests, runtime permissions, target SDK levels, and privacy disclosures before submitting your app for Play Policy review. * Implement Restore Credentials: Implement re-authentication across device setup and cloud restores using Jetpack Credential Manager. * **Android Intent security:** Detect and prevent implicit intent hijacking, secure broadcast receivers, and validate PendingIntent declarations. * **Use Android profilers:** Diagnose UI frame drops, interpret CPU/memory traces, and query trace data using natural language mapped to PerfettoSQL. * **CameraX:** Replace legacy Camera1/Camera2 code with lifecycle-aware CameraX. * **Migrate Leanback to Compose for TV:** Modernize Android TV experiences by transitioning from Leanback to Compose for TV. * **Integrate Media3 Cast:** Connect Jetpack Media3 media sessions with Google Cast receiver devices and sync playback states. * **Integrate Play Engage SDK:** Integrate the Google Play Engage SDK to publish user recommendations and cluster surfaces. * **Set up testing strategy:** Configure unit test suites, Compose UI testing rules, and screenshot testing infrastructure. * **Audit R8 configuration:** Optimize your app's performance by auditing your R8 configuration. Our Android skills are thoroughly evaluated. To understand the philosophy and methodology behind this project, as well as why all skills should come with evals, make sure to read Inside Android Skills - Built for deprecation. Managing skills across projects and individual agent directories is pretty straightforward with Android CLI: 1. Install Android CLI 2. Run `android init` to install the `android-cli` skill 3. To list all available official skills, run: `android skills list` 4. To install individual skills into a single project root: `android skills` add `wear-compose-m3 --project=`. 5. To update skills, use: 6. `android skills update --all` 7. `android skills update wear-compose-m3` (for an individual skills) Skills are designed to be **environment-agnostic**. From writing code in Android Studio and Antigravity, to pairing with third-party agents like Claude and Codex, our Android skills work across your entire setup. _Android skills work across your entire setup_ _ _ ## Skill spotlight: Wear Compose Material 3 Building for Wear OS means distinct design and development decisions: round viewports, rotary input, ambient display mode, minimizing power consumption, preferring `TransformingLazyColumn`, and using the `AppScaffold` and `ScreenScaffolds` containers. Without explicit guidance, LLMs lack the understanding and knowledge of these distinct patterns that make the Wear apps really stand out and shine. To help agents with this, we released the **Wear Compose Material 3 skill** (wear/wear-compose-m3). Check out this video for more information on how powerful this skill is: Early adopters are already seeing significant productivity impact with this skill. The **engineering team at** **FotMob** used it for tasks like modernizing their existing Wear M3-based app, migrating multiple lists to `TransformingLazyColumn` with `ScreenScaffold` content padding, `ListHeader` titles, `SurfaceTransformation` on cards and buttons, theme typography, and Wear previews. The result? The changes compiled successfully and were verified on the emulator for scrolling, rotary, edge morphing and RTL. This enabled the team to delete their legacy wrapper, and all rotary and focus boilerplate. The skill caught mistakes that the underlying model missed, such as forgetting to forward `ScreenScaffold`'s `contentPadding` into the list, and using theme typography over hardcoded sp. > _“One skill, one afternoon, eight lists migrated and a pile of custom rotary code gone!” - Roy Solberg, Android Tech Lead at FotMob._ _A Wear OS app built with the skill_ ## Get started today When you're ready to get started, install Android CLI with just one command. You can learn more about Android CLI by reading the developer documentation, and as well as checking out the latest updates in the Android CLI release notes. After installing Android CLI, run android init to configure your agent, then browse the latest Android skills available for use and install them with android skills add. Also check out the Android Device Streaming documentation to learn more about how this feature allows you to access real devices on the cloud inside both Android Studio and via your agents.

_Posted by Pavlo Stavytskyi, Software Engineer, Meta and Rebecca Franks, Developer Relations Engineer, Google_ This blog post is written in collaboration with the Meta team. Instagram Direct is one of the core surfaces on Instagram, handling billions of user messages every single day. Over years of iteration, the team squeezed every micro-optimization possible out of the legacy Android View system. However, maintaining and expanding a heavily optimized legacy surface creates significant technical debt and engineering overhead, especially as teams increasingly adopt declarative UI and AI coding assistants. Adopting Jetpack Compose for Instagram Direct went beyond a typical UI modernization. The team built an AI-native UI codebase that is **50% smaller** than the original implementation, while achieving a **35% reduction in AI agent execution time** , **32% fewer engineer-agent exchanges** , and a **33% reduction in token cost**. In close partnership with Google, the team adopted Jetpack Compose while maintaining a high performance bar. **Through the performance optimizations, Meta and Google improved Compose not only for Instagram, but for the broader Android developer ecosystem too.** ## Modernizing the codebase at massive scale AI has rapidly become a daily companion for engineers in the industry, and applying it to a large-scale codebase like Instagram already yields real productivity gains. The Instagram Direct team set a more ambitious goal. Rather than simply pointing AI tools at the existing code, the team redesigned the codebase and its architecture to be AI-native by design, multiplying the impact of AI far beyond what retrofitting alone can deliver. The Instagram Direct team chose Jetpack Compose as a key component for building an AI-native UI architecture. Its declarative nature ensures code is concise, predictable, and structurally easier for AI models to reason about, with fewer side effects, less implicit state, and clearer component boundaries. The migration to Jetpack Compose required careful planning. Hundreds of millions of people send messages on Instagram every day, so the migration had to be gradual, smooth, with zero disruption to the experience while the team re-architected the foundation underneath it. To illustrate the scale of the challenge: Individual UI components can render in **over 160 distinct state permutations** , and a single conversation screen alone handles **more than 200 distinct message types**. When migrating a codebase of this size to Compose, it's tempting to take the easy way out and embed Compose UI components inside the existing View hierarchy. As an incremental step during a gradual migration, that's perfectly valid. Over the long run, though, integrating Compose inside a View-based codebase poses a challenge. AI tools often take the path of least resistance. If you mix declarative and imperative UI code, AI is likely to blend them incorrectly, introducing subtle bugs, tech debt and performance regressions. ## Building an AI-native UI architecture At the scale of Instagram, a degree of architectural abstraction is unavoidable, and it is what keeps the app maintainable as it grows. Consider a common pattern, where every `RecyclerViewitem` type is modeled as a descendant of a custom `RecyclerViewItem` base class that exposes usual lifecycle hooks such as `onBind`. Example 1 class ChatItem(   val features: FeatureFlagProvider ) : RecyclerViewItem<ComposeViewHolder, ChatUiState> {   // Imperative context:   // AI could often take the path of least resistance and generate a mutable   // state here, dispatched outside the ChatUiState. This class survives   // re-bindings and is shared across multiple items, ultimately leading to   // unexpected, hard-to-reproduce bugs.   var isPinned: Boolean = false   override fun onBind(holder: ComposeViewHolder, uiState: ChatUiState) {       // Imperative context       val isPinnedChatsEnabled = features.isEnabled("pinned_chats_feature")       // Declarative context       holder.composeView.setContent {         // Blending imperative and declarative contexts         if (isPinnedChatsEnabled) {           Button(onClick = { isPinned = !isPinned }) {             Text(if (isPinned) "Unpin" else "Pin")           }         }                  ...       }   } } In the snippet above, two problems creep in. First, the `isPinnedChatsEnabled` flag is read in imperative code and then captured inside a Compose lambda, a subtle coupling across paradigms. Second, `isPinned` lives as a mutable field on the item itself rather than in `ChatUiState`, so it survives `RecyclerView` re-binding and recycling across rows, leaking and producing bugs that are painful to reproduce. Even when the code is cleaned up by giving the item a dedicated `@Composable` function, the same problems remain. Example 2 class ChatItem(   val features: FeatureFlagProvider ) : ComposeRecyclerViewItem<ChatUiState> {   // Imperative context   val isPinnedChatsEnabled = features.isEnabled("pinned_chats_feature")   var isPinned: Boolean = false   // Declarative context   @Composable   override fun Content(uiState: ChatUiState) {     // Blending imperative and declarative contexts     if (isPinnedChatsEnabled) {       Button(onClick = { isPinned = !isPinned }) {         Text(if (isPinned) "Unpin" else "Pin")       }     }     ...   } } This is deliberately a simple example, but it illustrates a broader issue— the fewer boundaries AI is given, the lower the quality of the code it produces over time. Guardrails and skills help, but they are not enough on their own, because when AI hits friction it will often route around them to unblock itself. To make the codebase AI-friendly, it needs to follow two practical rules: * **Minimize dependency on custom context.** The more bespoke, codebase-specific knowledge an AI agent needs to make a correct change, the lower the quality of its output. The closer the codebase is to known best practices, the better the AI results. * **An AI-first codebase must enforce its own boundaries.** Patching design gaps with AI skills doesn't scale, since every skill loaded into context costs tokens and can degrade the agent's performance. Instead, the architecture itself should carry that weight. AI agents naturally take the path of least resistance, so the design should make that path lead to correct, high-quality code, while making poor design decisions hard and expensive to express. A list item can still be represented by its own abstraction, but in this case all the Compose code lives in the constructor, so it has no access to class members or state, and its only source of arguments is the constructor. This makes it equivalent to a plain `@Composable` function, while conforming to the existing architecture. Example 3 class ChatItem(   val features: FeatureFlagProvider,   val onPin: (Boolean) -> Unit, ) : ComposeItem<ChatUiState>(   // Compose UI   content = { uiState: ChatUiState ->     val isPinnedChatsEnabled = features.isEnabled("pinned_chats_feature")     if (isPinnedChatsEnabled) {       Button(onClick = { onPin(!uiState.isPinned) }) {         Text(if (uiState.isPinned) "Unpin" else "Pin")       }     }          ...   }, ) Migrating a codebase of this size is a massive undertaking. For a long time, the hundreds of UI components that make up the majority of Direct UI had to coexist with their legacy counterparts, with both maintained in parallel. AI workflows helped make this parallel migration possible by speeding up the process of writing massive amounts of code. That approach is what let the Direct team perform the migration in record time, all without disrupting the rest of the team, who kept shipping the features that improve the experience of millions of people every day. Multiple engineers ran their own AI agents against a shared knowledge base of reusable skills and conventions built during the migration. That kept workflows and best practices in sync across the team, rather than having each engineer rediscover them. Within each surface, the team performed the migration in the following stages: * Write all the Compose code with AI. * Polish it, handling edge cases and closing performance gaps, until the UI was rolled out to real users in a public test. Splitting the work into two stages per screen lets one engineer move quickly through the entire surface, settling the architecture and the tricky edge cases up front. With that groundwork in place, others can focus on getting the UI production-ready without stopping to make those technical decisions themselves, keeping the overall migration fast. The results of the migration validated the approach. For migrated Instagram Direct surfaces, Jetpack Compose allowed the team to**reduce the total amount of UI code by 50%**. Less code for AI to generate is associated with higher-quality output and lower token cost per task. An internal data analysis of the Android codebase for Instagram Direct compared AI agent sessions working on Compose UI against the same tasks using Android Views. The efficiency gains were clear across two dimensions: * **Per character of landed code** : Compose required **32% fewer engineer-agent exchanges** and **35% less agent execution time** (the elapsed time from when an agent starts working on an engineer’s request until it returns a response). * **Per agent session:** The overall **token cost dropped by 33%** with Compose in comparison to Views. We report both output efficiency and typical session numbers because they are independently useful outcomes. The engineer-agent exchanges and execution time figures compare resource use per unit of landed output, while the token figure compares total cost for a typical agent session. The data also revealed a consistent difference in how the two frameworks handle complex or fragile code. Meta tracks this using a risk score of code changes, which evaluates overall code quality and the likelihood of a change causing production incidents. The analysis measured an agent’s **resource efficiency** using a composite of token consumption, agent’s execution time and the engineer to agent interactions. As files accumulate a higher risk score, AI agent sessions naturally become less **resource efficient**. **When a file’s accumulated risk score doubles** , the UI implemented with **Android Views reduces agent resource efficiency by 30%** (per landed character). In the same circumstances, the reduction by **Jetpack Compose UI is only 9%**. Through partnership between Google and Meta, the Instagram Direct team brought a fresh perspective to Compose adoption — approaching it through the lens of the codebase's AI-readiness, not just a UI rewrite. This work revealed Compose's strength in serving as a foundation for building AI-first codebases and architectures, especially when applied at the scale of apps like Instagram. ## Performance optimizations Instagram Direct is one of the most integral surfaces of the app, and people expect it to feel fast and responsive at all times. Adopting Jetpack Compose effectively meant a substantial UI rewrite, and the number-one goal was to preserve the **high-quality experience with no regressions**. Years of iteration had already pushed the legacy View-based implementation on Instagram to an exceptionally high performance bar, and the team needed to meet that same standard while moving to an entirely new UI framework. Instagram measures hundreds, if not thousands, of performance metrics. For Compose adoption, the following three were the most important: * **Time to interact** - the amount of time between opening the screen to being able to use it. * **Time to fully load** - the amount of time between opening the screen to when all the content is fully loaded (i.e. images). * **Scroll performance** - how smoothly the screen scrolls, without dropped frames. These metrics are tracked at runtime in production, making it possible to run A/B tests comparing the migrated Compose UI against the legacy UI and evaluate the performance impact of this effort. A common way to approach a migration like this is to start small, moving over a handful of UI components, gathering data, and studying how they behave. While helpful, these early results only paint a partial picture, providing false negatives against Compose adoption because: * **Not representative** — one migrated UI component can provide useful data about its overall performance on a particular screen. However, different components behave differently for reasons that don't generalize, so you can't always extrapolate from it. * **Interop cost** — a small Compose piece inside a big View codebase pays an unpredictable bridging cost between the two systems. That overhead distorts the measurement, so early small-scale results don't reflect what full migration would actually look like. The result is that small migrations, while useful, don't always reflect the full impact of Compose. **The more of a surface is migrated end-to-end without bridging interruptions, the clearer and better the picture becomes performance-wise.** The core screens in Instagram Direct are built around long lists of varied item types, originally implemented with `RecyclerView`. The architecture relies on custom abstractions for scalability, but it remains bound to the lifecycle of the View-based system. The team's primary undertaking was a gradual migration of several hundred individual list items to Compose within the existing `RecyclerView`-based architecture, rolling them out in production in small independent groups under A/B tests — all of it without visible changes to the user's messaging experience. The biggest downside of such a setup is a significant dependency on the legacy View system through a core `RecyclerView` architecture, even after the full migration of every list item to Compose. As a natural next step, the team decided to invest in replacing the `RecyclerView`-based core architecture with the Compose-native alternative — `LazyColumn`. This means Compose UI components should be abstracted away from the framework they are enclosed in while still being compatible with both `RecyclerView` and `LazyColumn` at the same time. Equally important is the ability to switch between the two at runtime via feature flags, to enable A/B testing. While the new Compose items are natively compatible with `LazyColumn` and can be plugged into an uninterrupted composition tree, an interop API was created to slot them into a `RecyclerView` as well. This made it possible to roll out the `LazyColumn` setup under an A/B test side-by-side with `RecyclerView` — reusing the same Compose items and polishing performance, without disrupting the rest of the team building and refining features. The scale, complexity and sensitivity of Instagram to even the smallest regressions posed a unique challenge for Jetpack Compose. Addressing these required an **iterative** , **hands-on partnership**. Working closely together, Google and Meta engineers analysed metrics to pinpoint and design new Compose capabilities to meet or exceed the View-based benchmarks. As a result of this partnership, the following additions to Jetpack Compose stand out: Pausable composition with `LazyLayoutCacheWindows` and visibility tracking. ## Pausable composition with LazyLayoutCacheWindows Pausable composition (enabled by default in Compose 1.10) allows expensive lazy-list items to be composed incrementally across frames to prevent jank. When paired with `LazyLayoutCacheWindow` (added in Compose 1.9), the combination significantly improves scroll smoothness. In recent internal testing at Meta, combining Pausable composition with a one-viewport `LazyLayoutCacheWindow` reduced large frame drops per minute (LFDs/m) by about 13% compared with vanilla Compose. Cache Window on its own reduced it by about 8% against the same baseline. LFDs/m is an internal metric Meta uses to track noticeable stutters while scrolling. Using a `LazyLayoutCacheWindow` in your app prepares and retains off-screen items within a pixel-based band around the viewport to enable fast flings. To take advantage of `LazyLayoutCacheWindows` in your app, you can use the latest Compose 1.13.0-alpha03 and set it up as shown in the example below: val cacheWindow = LazyLayoutCacheWindow(ahead = 150.dp, behind = 100.dp) // OR val cacheWindow = LazyLayoutCacheWindow(aheadFraction = 0.5f, behindFraction = 0.3f) LazyColumn(state = state, cacheWindow = cacheWindow) {     ... } There are two ways to configure the cache window. Both describe the same thing: how much off-screen content to keep composed, but in different units. * **Dp** : fixed absolute length. `ahead = 150.dp` keeps 150dp of content composed past the visible edge regardless of device. * **Float** : fraction of the viewport. `aheadFraction = 0.5f` keeps half a screen composed ahead, so the absolute amount scales with screen height supporting various form factors: more on a tablet or unfolded foldable, less on a compact phone. The Instagram team fine-tuned the cache window's **float fractions** specifically for Direct's content structure and item sizes. Since the ideal values vary depending on the specific UI parameters, finding the right balance requires some experimentation. ## Impression logging with onVisibilityChanged The `onVisibilityChanged` (added in Compose 1.9.0) API was another key result of the technical partnership between Google and Meta. It gives large-scale Jetpack Compose surfaces a consistent way to know when a composable is actually visible on screen, replacing custom, hand-rolled implementations used in the past. Within Instagram Direct alone, these visibility signals are used across hundreds of files to support product quality metrics that depend on whether UI elements were actually shown to people. ## Startup performance The adoption of Jetpack Compose for Instagram Direct led to unexpected performance improvements across other surfaces of the app. The Jetpack Compose runtime carries a warmup cost you pay only once, and because messaging is a high-traffic surface often visited early in a user session, other surfaces across Instagram that rely on Compose saw noticeable performance improvements. The startup performance of Compose UI inside Instagram Direct itself was optimized through using Baseline Profiles, which pre-compile hot code paths at install time so Compose renders quickly from the very first launch. ## Lessons from the Instagram Direct migration to Jetpack Compose * **Jetpack Compose has an immediate return on investment:** You do not need to be using advanced AI workflows to benefit from Compose. With the ~50% reduction in code, it means less code to maintain, and reduced surface area for bugs. * **Designing an AI-native architecture led to significant wins** , including a 35% reduction in AI agent execution time, 32% fewer engineer-agent exchanges, and a 33% reduction in token cost. * Although there are plenty of interop APIs and support for combining Views and Compose together, **aim to migrate bigger surfaces over individual small components**. This keeps the UI within a single, uninterrupted composition hierarchy and unlocks all the best Compose-native performance optimizations. * **Pair Pausable composition with LazyLayoutCacheWindow** : Pairing these two together yields better results than cache windows alone. With only the cache window, a heavy item could still try to compose in a single pass, potentially overrunning the frame budget. * **Contribute to Compose itself!** Meta has partnered with the Jetpack Compose team to bring their feedback and ideas to life within Compose. Working on an open-source toolkit means we all benefit when bugs and performance improvements are made centrally. So, make your feedback known! Adopting Jetpack Compose unlocked significant gains in AI-assisted development while simplifying day-to-day UI engineering at Instagram. The declarative approach reduces boilerplate, makes state easier to reason about, and improves overall developer productivity. The Instagram engineering team is looking forward to bringing Compose to more surfaces across the app, and the continued collaboration between Google and Meta to bring more improvements to Instagram and Jetpack Compose users alike. If you haven’t yet tried out Compose, now with AI-assistance, migrating to Jetpack Compose is easier than ever. _Acknowledgements. Thank you to Michal Zielinski and Matthew Du from Meta, and Andrei Shikov and George Mount from Google, for their work bringing performance improvements to Compose through the collaboration between Meta and Google! Thank you also to Gary Ye from Meta for helping bring Compose to Instagram Direct, and to Gopal Juneja from Meta for supporting this effort through data science!_

Posted by Sheenam Mittal, Senior Product Manager, Google Play The subscription landscape is evolving rapidly, especially with the surge of generative AI and increasingly sophisticated app experiences. As the ecosystem shifts, we recognize that developers need more flexible and robust tools to monetize effectively while improving the LTV of recurring purchases. On Google Play, we are continuously expanding our subscription platform to help you drive growth, adapt to new business models, and meet your users exactly where they are. Here is a look at the capabilities we are testing and rolling out to support the next generation of subscriptions, along with powerful existing features designed to maximize your conversion and retention. ### Unlock new ways to sell and grow with flexible monetization models As we look at the next few years of the subscription business, flexibility is paramount. Developers building GenAI tools, entertainment, educational platforms, and business solutions need adaptable pricing and packaging models to scale access beyond the individual user and capture higher cart value at checkout. ## Multi-Quantity Subscriptions: Scale subscriptions to teams To support collaborative and team-wide or group usage, Play is introducing **Multi-Quantity Subscription Purchase**. This allows users to make multiple subscription purchases in a single transaction and easily assign those as seats or subscriptions to team members or students. This is a game-changer for productivity, EdTech, and GenAI developers looking to sell team-wide subscription access seamlessly. ## Usage-Based Billing: Support AI and variable-cost features For apps with variable computing costs—like AI generation tools or other usage-based services—rigid recurring subscriptions do not always fit. **Usage-Based Billing** enables you to set up prepaid metered billing where users can automatically top up their balance whenever it falls below a set threshold. This ensures uninterrupted service for your users while protecting your margins. **Beyond these flexible models, we are also making it easier to package your products and upsell creatively at checkout:** ## Mixed Carts: Sell subscriptions and one-time products in a single checkout Historically, subscriptions and one-time products were purchased in separate transactions. If a user wanted to buy a monthly membership alongside a starter pack of in-app currency or bonus credits, they had to complete two separate checkout flows. **Mixed Carts** bridges this gap for developers who want to sell both auto-renewing subscriptions and one-time products (OTPs). By enabling you to process an auto-renewing base subscription alongside OTPs in a single API call and unified checkout sheet, Mixed Carts streamlines the transaction process. This unified experience also opens up powerful upsell opportunities for your business—such as offering targeted discounts if an end user purchases a complete bundle of a subscription and complementary in-app items together. ## Cross-Developer Bundling: Partner across apps to unlock shared growth Partnerships are a proven strategy for acquiring new users and driving growth. With **Cross-Developer Bundling** , you can create and sell a hard bundle of two or more complementary subscriptions in your own catalog. This capability allows you to team up with other developers—or combine offerings across your own portfolio of apps—to deliver massive value through a single purchase. For example, if you manage a language learning app, you can now create a single SKU that bundles your monthly membership with a partner's premium travel guide subscription, offering users a combined subscription at a discounted rate. By sharing the acquisition benefits, you can seamlessly reach new audiences and secure more recurring revenue for your business. ### Maximize subscription performance: Keep and win back the users you’ve earned Acquiring a subscriber is only the first step—long-term growth depends on minimizing friction across the billing lifecycle. We are heavily invested in improving subscription performance to help you prevent involuntary payment declines and retain your subscribers. ## The In-App Messaging API: Resolve payment declines and price change updates in-context Available now to all developers, we highly encourage adopting the **In-App Messaging API**. This tool allows you to meet end users exactly where they are—inside your app—with critical transactional messages. You can use this API to: * Prompt users to fix a payment decline immediately. * Notify users of upcoming price changes transparently. By handling these critical account states gracefully within the app experience, you can continue running your business without disrupting the user journey. Learn more. ## Dynamic Grace Period: Tailor payment recovery windows with predictive models Involuntary churn from payment declines is often addressed with a static, one-size-fits-all grace period. However, fixed durations force a difficult trade-off between giving users enough time to resolve payment issues and managing developer service costs during unpaid periods. With **Dynamic Grace Period** , Google Play utilizes machine learning and heuristic models to tailor the grace period duration for individual subscribers following a payment decline. By intelligently matching the recovery window to the user's recovery likelihood, this capability is designed to help developers better balance renewal recovery against unpaid service access. To ensure consistency with your business rules, Google Play automatically adjusts the subsequent account hold duration, preserving your total configured recovery window without requiring client-side code changes. ## Retention Offers and Plan Change: Prevent voluntary churn in the cancellation flow Acquiring new subscribers is expensive, making it critical to engage and retain your existing user base. When users consider canceling, capturing their attention before they leave is essential for protecting your customer lifetime value. With **Retention Offers** , you can present developer-funded incentives—like a discount—directly within the Play Store cancellation flow. For users who may not be eligible for a discount or promotional offer, you can suggest a **Plan Change** to a lower-priced tier, ensuring you offer a flexible path to keep them engaged in your app rather than losing them entirely. ## Native Winback Offers: Re-engage lapsed subscribers directly on the Play Store A canceled subscription doesn’t have to be the end of the user lifecycle. Former subscribers already understand the value of your app—they often just need the right incentive at the perfect moment to return. Traditional winback campaigns rely on email or push notifications, which fall flat if a user has uninstalled your app. Google Play's **Subscription Winback Offers** close this gap in your re-acquisition strategy by reaching users directly on the Google Play Store, helping you present lapsed users with personalized offers that make coming back easier than ever. ### Behind the scenes: The revenue shield you don’t have to build Alongside the tools you configure in Play Console, Google Play runs a continuous engine of zero-lift optimizations behind the scenes to grow your subscriber base and reduce involuntary churn—without requiring a single line of developer code. From smart payment retries and automatically cycling through backup payment methods for opted-in users, to sending intelligent, context-aware reminders during grace periods and account hold, Play works continuously to recover failed transactions seamlessly. We also protect your revenue with built-in fraud and abuse prevention systems that block bad actors from exploiting promotional offers or manipulating billing cycles. This ensures your promotional budgets reward legitimate, high-value subscribers—securing your business while naturally lifting overall retention. Many of these features are currently available or rolling out through our Early Access Program, meaning capabilities are in active testing with select partners to gather feedback before rolling out more broadly in Play Console. If you work with a Google Play partner manager, you can reach out to express interest as programs open. To learn more about our current subscription capabilities and get your app ready for what’s next, explore our Google Play Billing subscriptions documentation.

Posted by Jolanda Verhoef, Senior Developer Relations Engineer, Android Developer Relations Welcome back to the blog post series "Build intelligent Android apps" where you take a basic Android app and transform it into a personalized, intelligent, and agentic experience. In our previous post you learned how to connect to the intelligence system using AppFunctions. In this post, you will learn how to build autonomous **in-app agentic workflows** running in the cloud. Sometimes a task is too complex for a single device session. For example, booking a complete holiday itinerary involves coordinating flight times, selecting hotel rooms, reserving museum tickets, and planning restaurant reservations. If you run this multi-step process directly on a mobile device, the app might get closed and lose your progress. Managing all these steps and API credentials on a phone also gets complicated quickly. For these long-running, multi-step workflows, you can use a custom self-hosted backend. The backend executes the booking agents in the background, while the Android app connects to the session, visualizes the progress, and requests user input only when necessary. Using a cloud-hosted agentic backend offers a few advantages: * **Background execution:** Booking agents run autonomously in the cloud, so progress is never lost if the mobile app goes to the background or loses internet connectivity. * **Complex multi-agent orchestration:** A coordinator agent can delegate bookings to specialized subagents and handle dependencies between them. * **Client-agnostic UI rendering:** The backend describes the interface structure dynamically, letting you update the UI layout without releasing a new client version. _The booking assistant shows all booking progress, organized by event type._ With these benefits in mind, we added a **Booking Assistant** to Jetpacker that coordinates flights, hotels, museums, and restaurant reservations. Let's look at how we orchestrated a multi-agent system powered by the Agent Development Kit (ADK), with the Agent-User Interaction protocol(AG-UI) and Agent-to-User Interface protocol (A2UI) to send and display interactive cards natively in Jetpack Compose. ### Powering complex workflows with ADK agents Rather than coordinating the orchestration flow manually using custom REST endpoints or complex web sockets, you can use the **Agent Development Kit (ADK)**. With ADK, you can define agents and equip them with python function tools to query databases and execute bookings. _ _The Android app sends the current trip itinerary data to the server. The coordinator agent chooses which subagents to trigger. Each subagent provides its results to a shared session queue that streams the results back to the Android app._ _ Here is how to define a simple agent and run it using ADK: # android/booking-server/booking_server.py # Note: ADK supports many different coding languages. For now, use the Python version as it includes support for A2UI which we'll use later in this blog post. from google.adk import Agent from google.adk.runners import InMemoryRunner from google.adk.tools import FunctionTool # Define custom tools to interact with database def search_flights(destination: str, date: str) -> list[str]: # In production, here you would query our flight database and return dynamic results return ["10:00 AM", "2:00 PM"] def reserve_flight(flight_time: str) -> str: # In production, here you would save the reservation transaction return "Reserved flight at " + flight_time # Instantiate the booking agent with specialized tools flight_agent = Agent( name="Flight Booker", model="gemini-3.1-flash-lite", instruction="Help the user search for flights and book a reservation.", tools=[ FunctionTool(search_flights), FunctionTool(reserve_flight, require_confirmation=True) ] ) # Run the agent in memory using a session ID runner = InMemoryRunner(flight_agent) async for event in runner.run_async(user_id=user_id, session_id=session_id): if event.content: print("Agent said:", event.content) When you run an agent using this setup, ADK manages the execution steps for you. It automatically tracks the conversation context, routes messages between the user and the model, and executes the registered tools when the model requests them. This allows you to focus on writing clean procedural logic while the framework handles the orchestration in the background. _The ADK web interface shows how you can have a conversation with the multi-agent booking system._ To connect this backend agent to our Jetpacker app, the server needs a way to stream updates in real time to the device, which is handled using the **AG-UI protocol**. The agent also needs a structured way to describe and update interactive components (like option selectors and seating grids) dynamically on the phone, which is where the **A2UI protocol** comes in. ### Standardizing agent-client communication with AG-UI Running agents in the cloud and rendering UI on Android requires a standard communication channel. For this, you will use the AG-UI protocol. AG-UI is a bidirectional transport layer protocol that standardizes message types between agents and UI clients. The agent can inform the client of lifecycle events, text messages, tool calls, and state management. The client, in turn, can send user text messages, tool call results, and custom action events back to the agent. On the server side, it yields updates formatted as standard Server-Sent Events (like `event: TEXT_MESSAGE_CONTENT` containing the JSON delta). On Android, the Kotlin SDK listens to this stream and automatically maps the payloads to type-safe client events: // https://github.com/android/ai-samples/tree/main/jetpacker/android/feature/trip/booking_assistant/src/main/kotlin/com/example/jetpacker/feature/booking_assistant/BookingAssistantViewModel.kt import com.agui.client.agent.HttpAgent import com.agui.client.agent.HttpAgentConfig import com.agui.core.types.RunAgentInput import com.agui.core.types.UserMessage import com.agui.core.types.TextMessageStartEvent import com.agui.core.types.TextMessageContentEvent import com.agui.core.types.TextMessageEndEvent val config = HttpAgentConfig( agentId = "booking-assistant", threadId = threadId, url = "https://<your-backend-url>" ) val agent = HttpAgent(config, httpClient) // Set up the input with the session thread and user instruction val input = RunAgentInput( threadId = threadId, runId = runId, messages = listOf(UserMessage("Book a flight to Paris")) ) // Run the agent flow and collect lifecycle events agent.runAgentObservable(input) .collect { event -> when (event) { is TextMessageStartEvent -> { /* ... */ } is TextMessageContentEvent -> { /* ... */ } is TextMessageEndEvent -> { // Handle the completed message } } } You can then write a UI to render these different types of standardized AG-UI events. This will give you the prototypical "Chatbot" experience: _ A basic interface that lets a user chat with an assistant._ ### Letting the agent speak UI with A2UI Traditional chatbots typically return plain text or custom JSON payloads. When building complex interfaces, the client application has to parse these payloads and map them to specific, pre-built screens. This creates a dependency: every time you add a new feature, change the layout, or support a new user interaction, you have to update both the backend agent and the mobile application. This requires publishing an app update and waiting for users to install it. To solve this, use the A2UI protocol. A2UI allows agents to describe the UI components to render on the client dynamically. The client app declares a catalog of components it supports, and the server sends a JSON payload specifying the component layout and properties: { "version": "v0.9", "updateComponents": { "surfaceId": "Flight Reservation", "components": [ { "id": "flight_option_picker", "component": "InteractiveOptionPicker", "properties": { "prompt": "Select a flight time:", "options": [ "10:00 AM", "2:00 PM" ], "selectedIdx": null, "confirmBtnText": "Confirm Flight" } } ] } } The server specifies which catalog components to render along with their active property values, cleanly decoupling the client's visual implementation details from the agent's workflow state. ### Designing the backend UI schema For the agent to generate these JSON payloads correctly, it needs to know which components are available and what properties they accept. To do this, use the ADK A2UI integration. Instead of manually writing prompt instructions for every component in our catalog, the A2uiSchemaManager compiles their JSON schemas and layout instructions directly into the system prompt. This ensures the model learns the exact structure and formatting rules it must follow to generate valid A2UI payloads: # android/booking-server/booking_server.py from a2ui.schema.manager import A2uiSchemaManager from a2ui.schema.constants import VERSION_0_9 from a2ui.schema.catalog import CatalogConfig from a2ui.basic_catalog.provider import BasicCatalog # Initialize A2UI Schema Manager with custom booking component catalog schema_manager = A2uiSchemaManager( version=VERSION_0_9, catalogs=[ BasicCatalog.get_config(version=VERSION_0_9), CatalogConfig.from_path( name="https://example.com/catalogs/booking_assistant/v1/catalog.json", catalog_path="booking_catalog.json" ) ] ) # Compile prompt instructions including the A2UI JSON schema A2UI_SYSTEM_INSTRUCTION = schema_manager.generate_system_prompt( role_description="You are a helpful travel booking assistant.", ui_description="Use InteractiveOptionPicker for choices, SeatSelectionPicker for seat selection...", include_schema=True, include_examples=True, allowed_components=["InteractiveOptionPicker", "SeatSelectionPicker", "BookingStatus"] ) With this generated system instruction, the LLM is grounded in the schema layout and knows exactly how to formulate component updates that the Android client is capable of rendering. ### Natively rendering A2UI with Jetpack Compose To render these component trees natively on Android, use the new Jetpack Compose A2UI Renderer library. First, add the dependencies to our module's `build.gradle.kts` file: // android/feature/trip/booking_assistant/build.gradle.kts dependencies { implementation("androidx.a2ui:a2ui-model:1.0.0-alpha01") implementation("androidx.a2ui.compose:compose-runtime:1.0.0-alpha01") implementation("androidx.a2ui.compose:compose-ui:1.0.0-alpha01") implementation("androidx.compose.material3:material3-a2ui:1.0.0-alpha01") } Each component class in the catalog (such as `BookingStatusComponent`) defines how to map the properties received from the JSON payload into a Jetpack Compose composable function. Register the custom components in a catalog: // android/feature/trip/booking_assistant/src/main/kotlin/com/example/jetpacker/feature/booking_assistant/CustomBookingAssistantCatalog.kt import androidx.a2ui.compose.ui.A2uiCatalog fun bookingAssistantCatalog(): A2uiCatalog { return A2uiCatalog( catalogId = "https://example.com/catalogs/booking_assistant/v1/catalog.json", components = listOf( InteractiveOptionPickerComponent(), SeatSelectionPickerComponent(), BookingStatusComponent() ) ) } Tip: Jetpacker implements custom components (`InteractiveOptionPicker`, `SeatSelectionPicker`, `BookingStatus`) tailored for booking flows. If your agent uses standard elements (such as text, cards, buttons, rows, columns, checkboxes, and date-time pickers), `material3-a2ui` also provides `materialA2uiBasicCatalogV1(...)`, giving you ready-to-use Material 3 implementations without writing any custom components. Note: To keep the backend and mobile client aligned, both rely on the same catalog definition ID (`https://example.com/catalogs/booking_assistant/v1/catalog.json`). If you add or modify properties on the backend catalog, you must increase the version number, and update the matching Kotlin component class to prevent parsing errors. In the `BookingAssistantViewModel`, process the A2UI messages using the `A2uiMessageProcessor` and update our active surfaces: // android/feature/trip/booking_assistant/src/main/kotlin/com/example/jetpacker/feature/booking_assistant/BookingAssistantViewModel.kt import androidx.lifecycle.ViewModel import androidx.a2ui.model.processor.A2uiSurfaceModel import androidx.a2ui.compose.ui.A2uiMessageProcessor import kotlinx.coroutines.flow.StateFlow class BookingAssistantViewModel : ViewModel() { private val messageProcessor = A2uiMessageProcessor( catalogs = listOf(bookingAssistantCatalog()) ) val activeSurfaces: StateFlow<List<A2uiSurfaceModel>> = messageProcessor.activeSurfaces init { viewModelScope.launch(Dispatchers.Default) { processor.collectMessages() } } // ... } In the Compose screen, collect these surfaces and render each one using the official `A2uiSurface` composable from `androidx.compose.material3:material3-a2ui`. A2uiSurface automatically handles reactive component state observation, Material 3 loading indicators, error fallbacks, and animated transitions between updates: // android/feature/trip/booking_assistant/src/main/kotlin/com/example/jetpacker/feature/booking_assistant/BookingAssistantScreen.kt import androidx.compose.runtime.Composable import androidx.compose.runtime.collectAsState import androidx.compose.foundation.lazy.LazyColumn import androidx.compose.foundation.lazy.items import androidx.compose.material3.a2ui.A2uiSurface @Composable fun BookingAssistantScreen( viewModel: BookingAssistantViewModel, modifier: Modifier = Modifier ) { val activeSurfaces by viewModel.activeSurfaces.collectAsState() LazyColumn( modifier = modifier.fillMaxWidth(), verticalArrangement = Arrangement.spacedBy(16.dp) ) { items(activeSurfaces) { surfaceModel -> Card(modifier = Modifier.fillMaxWidth()) { A2uiSurface( surfaceModel = surfaceModel, modifier = Modifier.fillMaxWidth().wrapContentHeight() ) } } } } You will now see several UI surfaces generated by our agent running in the backend: ### _A well-designed booking assistant that relies on UI instead of text to interact with the user._ _ _ Bringing it all together By hosting agent workflows in the cloud and using the AG-UI and A2UI protocols together, we can build dynamic, native Android interfaces driven directly by AI models. AG-UI establishes the real-time bidirectional streaming channel for messages and lifecycle events, while A2UI enables the cloud agent to dynamically describe interactive UI components, keeping the client application perfectly decoupled from the step-by-step backend orchestration logic. Check out the full source code for Jetpacker on GitHub, and watch the video Build Intelligent Android apps with Google’s AI to learn more about how to integrate agentic workflows directly into your app. Check out the other parts of this blog post series: ▪️ Part 1: Introduction of the app and a high-level overview. 📱 Part 2: On-device intelligence. Dive deep into ML Kit’s GenAI APIs and Gemini Nano to build privacy-first features like itinerary summarization, receipt parsing, and local audio processing. ☁️ Part 3: Hybrid and cloud reasoning. Explore how to use Firebase AI Logic to ground LLM answers in real-world data like Google Maps and web context. ⚙️ Part 4: System integration. Integrating with the Android intelligence system using AppFunctions. 🤖 Part 5 (this post!): In-app agentic workflows. Extend the app with end-to-end booking assistants powered by A2UI and ADK. Interested in more on Android Development? Follow Android Developers on YouTube or LinkedIn! All code snippets in this blog post follow the following copyright notice: Copyright 2026 Google LLC. SPDX-License-Identifier: Apache-2.0

Posted by Matthew Warner, Product Manager, Android Developer Experience _ _ AI-powered developer tools have become an essential multiplier for engineering productivity, with teams adopting specialized AI coding agents, custom enterprise harnesses, and autonomous tools. It’s important for you to be able to build Android apps in the way that works best for you and your team, and agentic Android development is more open and flexible than ever before. Last year, Android Studio opened up to any AI model. Today, we’re taking the next step by introducing support for your choice of coding agents. With our new **Bring Your Own Agent (BYOA)** feature, you can seamlessly integrate your preferred coding agent into Android Studio—featuring Anthropic’s Claude Agent, Open AI’s Codex, and Google’s Antigravity—and supercharge it with Android Studio’s AI-optimized infrastructure and tool support. _Claude Agent in Android Studio_ ## Your agents, your AI plan BYOA pairs your favorite agent with IDE-native intelligence, making it faster, more accurate, and more cost-effective. BYOA is available in the latest Android Studio Canary with benefits including: * **Codebase awareness and token efficiency:** Android Studio provides the full project graph, build setup, and platform details directly into your agent using Agent Client Protocol (ACP) . The agent can then filter to relevant files or details for efficient token usage, lower latency, and sharper answers. * **Seamless workflow continuity:** Transition smoothly between multiple conversational agent prompts and Android Studio's purpose-built tools, keeping your flow state intact as you effortlessly jump between tasks. * **Agent flexibility:** Connect any ACP-compliant agent directly into Android Studio, and sign in with your plan. If one agent runs out of quota or isn’t meeting your performance expectations, you can have another agent take over. * **Native tool injection:** We wire up build diagnostics, UI tools like Jetpack Compose Previews, Android SDK tools, and Android emulator control so your agent has access and can test, diagnose, and execute directly in Android Studio. ## Powerful, capable, and reliable coding agents Agents can plan and execute complete technical workflows directly in your environment, unlocking powerful use cases: * **Execute in the environment:** Read, write, and edit files, run shell commands, run tests, and search the web. * **Delegate to subagents:** Break down complex projects by spawning specialized agents for subtasks like code review or testing. * **Stay in control:** Granular permissions let the agent act on its own for routine work, and pause for your approval on riskier actions. * **Persist context and configuration:** Maintain long-running sessions and automatically load project skills, slash commands, and memory. Agents running in Android Studio also benefit from Android skills and the Android Knowledge Base, ensuring they have access to the latest Android best practices. And if you want to learn more about how agents impact model performance, read more about our latest updates to Android Bench. ## Using Gemini with Google Antigravity Many developers have been using Gemini directly in Android Studio through the built-in agent, and we will continue to offer this experience in Android Studio. However, for the best experience with Gemini, we recommend selecting the Google Antigravity agent for access to the latest Gemini models such as Gemini Flash 3.8, along with increased AI usage quota. You can also login to the Google Antigravity agent with your Google AI Pro or Ultra plan to take advantage of your benefits in Android Studio, or pay per token rates with a Gemini API key. _Selecting the Google Antigravity agent_ ## Selecting the Google Antigravity agent If your organization is using Gemini Enterprise, you can continue to use the built-in agent or the Antigravity agent. In either case, your organization continues to benefit from the added security and privacy of Google Cloud. _Log in to the Antigravity Agent using a Google account, Gemini Enterprise license,_ _Enterprise Agent platform or Gemini API key_ ## Get started BYOA support is rolling out in preview starting with the canary release of Android Studio Rabbit 2 featuring commonly used agents like Google Antigravity, Claude Agent, and Codex. Both enterprise and consumer AI plans are supported - subject to the agent provider. To connect an agent, follow these steps: 1. **Update Android Studio:** Ensure you are running the latest from the canary release channel. 2. **Connect your agent(s):** In the agent window, select one of the agents (Claude Agent, Codex, or Antigravity) and sign-in or provide an API key. Additional agents can be found in the registry Settings > Tools > AI > Agents 3. **Explore the docs:** Check out our preview release note here. Your feedback is essential as we continue to refine the AI experience in Android Studio. If you find a bug or issue, please file an issue. We can’t wait to see what you build!

_Posted by Fahd Imtiaz, Senior Product Manager, and Loryn Hairston, Product Marketing Manager, Android Developer_ _ _ Googlebook introduces a new category of laptops built on a shared Android foundation. High-performance hardware from partners such as HP, Dell, Lenovo, Acer, and Asus, combines mobile convenience with desktop power. Googlebook offers high-resolution OLED touchscreens, dedicated keyboards, and precision trackpads with all-day battery life and OS-level Gemini Intelligence. With Googlebook, users can transition fluidly from quick interactions on their phones to rich, immersive sessions on their laptop. Bringing your app to Googlebook opens up valuable opportunities for you across the Android ecosystem. Google Play highlights optimized titles with dedicated badging, enhanced search, and featured spots across curated store homepages. Delivering this level of quality also prepares your app for the Apps Experience Program, where you can enroll to unlock a new program rate card designed to drive business growth. Even better, when users set up their new Googlebook using their Android phone, optimized apps are prominently highlighted for easy transfer, giving your app day-one presence on their new device. _Optimized for desktop badging and dedicated collections on Google Play._ The best part? You don't need to build a separate app from the ground up to take advantage of this reach. Adaptive development is how modern Android apps naturally scale across large displays, new device postures, and emerging form factors. If your app already embraces adaptive layouts, it is primed for Googlebooks. By building on your existing foundation of adaptive UI, window size classes, and multi-input support, you can deliver an optimized experience. _Adaptive layouts reorganizing mobile views into a multi-pane experience._ ## Anchor your app in desktop fundamentals On a laptop, your app operates within a desktop environment where user expectations shift toward higher information density, precision input, and active multitasking. Following desktop development and design guidance provides the principles needed to make the most of this experience. Instead of simply stretching mobile interfaces across a wide screen, an adaptive layout reorganizes content into functional groupings. Adopt a multi-pane architecture to allow your UI to expand, reflow, or reveal richer detail as window boundaries change. With Navigation 3, you can implement adaptive scene strategies to coordinate multi-pane layouts directly from your back stack. Use ListDetailSceneStrategy and SupportingPaneSceneStrategy to enable side-by-side layouts when expanded window space is available. Scene decorators let you wrap screens with persistent desktop navigation rails. Pair these patterns with layout primitives like Grid and FlexBox, and soon alongside experimental MediaQuery and Styles APIs, to organize complex content and adjust visual styles dynamically for desktop displays. _Representations of width-based window size classes._ In free-form desktop windowing, app windows can be resized dynamically at any time. Your layout decisions should respond directly to the available window space using window size classes rather than the physical display dimensions. Desktop design also accounts for ergonomic viewing distances and precise pointer targets. Adjust your type scale for comfortable viewing across larger displays, set layout max widths to keep line lengths readable, and define explicit click targets to prevent misclicks. Explore complete design patterns in our design principles guide and discover real world inspiration in the desktop design gallery. ## Deliver differentiated experiences for Googlebooks Once your core layout is adaptive, you can enrich your app with differentiated features that take full advantage of a desktop environment. Everyday productivity in these setups relies on versatile input methods. Jetpack Compose natively supports physical keyboard navigation and pointer selection. Elevate your app’s usability by integrating contextual cursors that provide visual feedback for text entry, pane resizing, and tool selection. Implement right click context menus and hover states; make your shortcuts discoverable through the Keyboard Shortcuts Helper. _Task switcher displaying multiple open windows and app instances._ On Googlebook, apps run in free-form windows where users can tackle multiple tasks simultaneously. Unlock side-by-side workflows by enabling multi-instance support, giving users the ability to launch independent windows for comparing content or managing multiple documents. Pair this with drag and drop to let users move text, images, and files fluidly between windows or even drop items onto an empty workspace to spin up a new task. _Multi-window multitasking with cross-window drag and drop._ Go all in and customize your window frame. In desktop windowing, apps include a caption header bar that you can style with custom backgrounds, search bars, or tabs while respecting system window controls. Beyond individual app windows, Continue On keeps experiences connected across phones, tablets, and Googlebooks with bidirectional handoff that lets users start a task on one screen and pick up seamlessly on another. Passing state through HandoffActivityData preserves context such as document position or active tabs, with optional web fallbacks to ensure smooth transitions. Complement this by surfacing actionable information at a glance with customizable widgets. And, as you refine your app experience, benchmark against our comprehensive desktop app quality guidelines. Developers are already bringing these patterns to life across the ecosystem. When bringing Notability to Googlebook, prior investments in tablets and foldables gave the team an immediate head start. Because their layout already relied on window size classes and adaptive scene strategies, their canvas and toolbars reflowed naturally during window resizing, while existing keyboard and trackpad support carried straight over. "We had already been targeting first-class experiences for tablets and foldables," explains Ryan Shea, Android Engineering Manager at Notability. "So by the time Googlebook came along, scaling Notability up to a laptop-class experience was mostly turning a dial we had already built. That left us free to spend our time on the things that only make sense on a bigger screen or with the newer APIs, like Continue On, which hands a note off from your phone to the laptop, and optimizing the side-by-side app experience for studying." ## Accelerate your workflow with dedicated tooling Testing and optimizing your app for Googlebook fits naturally into your existing development workflow. With the desktop emulator in Android Studio, you can run a virtual desktop environment directly on your workstation to test free-form window resizing, verify multi-instance interactions, and debug mouse, trackpad, and keyboard interactions. Download Android Studio Canary to set up your virtual device today. Help speed up your layout modernization with AI-assisted development. The adaptive skill gives your AI agents the necessary context to help refactor mobile layouts into responsive Compose containers automatically. Install the skill directly through the Android CLI to streamline your implementation. ## Realize new possibilities on Googlebook _The Googlebook family of laptops from ecosystem partners._ The Googlebook lineup marks an exciting new chapter for the Android ecosystem, giving your apps a premium platform to deliver richer, more capable experiences. By building adaptively, a single codebase ensures your app looks and performs optimally across phones, foldables, tablets, and Googlebooks while unlocking elevated visibility and badging across Google Play. Explore documentation at our Googlebook developer hub, review the desktop design guide, and start building for Googlebook today!

_Posted by Jan Kleinert, Developer Relations Engineer, Android for Cars_ _ _ Today, the games category for Android Auto and cars powered by Android Automotive OS with Google built-in is officially graduating from beta to general availability. Our early access partners have already been bringing games to the parked-only experience for cars, and you can browse these in our latest collections of games for Android Auto and games for Android Automotive OS. Bringing your game to cars lets you reach users in their vehicles during natural downtime, such as while waiting at a charging station or for a curbside order pickup. Today's milestone means that we're opening up access so developers can now publish games to the open testing and production tracks on Google Play. In this post, we'll cover how to adapt your existing Android game for the car screen, focusing on key technical requirements and publishing criteria. ### Implement car support for your game If you're already following best practices for building adaptive apps, bringing an existing Android game to cars primarily involves configuring your app manifest and ensuring your game respects the vehicle parked state. ## Mark your app as a game To distribute your app in the games category, you need to explicitly declare its category. Add the `android:appCategory="game"` attribute to the `<application>` element of your manifest file: <application ... android:appCategory="game"> ... </application> ## Declare support for Android Auto Games are supported on Android Auto on devices running Android 15 and higher. To declare that your game supports Android Auto, include this `<category>` element in the intent filter of an activity in your manifest file: <activity ... <intent-filter> <action android:name="android.intent.action.MAIN" /> ... <category android:name="android.intent.category.CAR_LAUNCHER" /> </intent-filter> </activity> Generally, the `android.intent.category.CAR_LAUNCHER` category element is placed in the same intent filter as the `android.intent.category.LAUNCHER` element, but it can be in another activity's intent filter if you prefer to launch a different activity. ## Declare support for Android Automotive OS To declare that your game supports Android Automotive OS, include the `android.hardware.type.automotive <uses-feature>` element in your manifest file. <manifest ... ... <uses-feature android:name="android.hardware.type.automotive" android:required="false" /> ... </manifest> The `android:required` value has different restrictions depending upon which track you choose to distribute your Android Automotive OS app. If you distribute your Android Automotive OS app on the mobile track, `android:required` must be set to `"false"`. However, if you distribute on the Android Automotive OS dedicated track, you can set `android:required` to `"true"`, `"false"`, or leave it unset. Leaving the value unset has the same effect as setting `android:required` to `"true"`, and means that your app is available only for distribution on Android Automotive OS devices. ## Handle the parked state Cars introduce a unique physical context with a driving state and a parked state. Certain types of apps, like games, are considered parked apps and aren't permitted to run while the vehicle is in motion to avoid driver distraction. By default, Android Auto and Android Automotive OS block activities from being used or launched when the vehicle is in motion or when user experience (UX) restrictions are active. To make sure your game complies with driver distraction guidelines, don't include the `distractionOptimized` metadata element in any activity in your manifest. You must also ensure that your game audio stops when the user starts driving and can't be unpaused while the vehicle is in motion. _ The TrivialKart for Unity sample app running on the Desktop Head Unit while in a parked state._ _The behavior of a parked app when UX restrictions are active._ Additionally, when the user relaunches the app from the home screen, your game must restore the app state as closely as possible to the previous state. Test your game for responsiveness and ensure it doesn't freeze or stutter during gameplay. ## Declare game controller support Car screens support touch input, but many users prefer playing with a connected gamepad. If your game supports controller input, declare the `android.hardware.gamepad` feature in your manifest to help boost the visibility of your app in the Google Play Store to users specifically seeking controller-compatible experiences. <uses-feature android:name="android.hardware.gamepad" android:required="false"/> Set the `android:required` attribute to `false` to indicate your app supports controllers, but the use of controllers is optional. Don't set the `android:required` attribute to `true` unless a controller is mandatory for your game. ## Support common screen sizes and aspect ratios Car displays come in various shapes and aspect ratios, including portrait and wide landscape screens. For a great user experience, make your game fully adaptive to different screen sizes so that it runs full screen without letterboxing or pillarboxing. For Android Auto, refer to the guidance for testing against canonical screen sizes and use bundled hardware profiles when testing with the emulator for Android Automotive OS. ### Publish your game to cars After you've implemented the necessary changes, you can opt in to Android Auto and Android Automotive OS form factors in the Google Play Console. Before submitting to production, test your game against the car app quality guidelines for games. Use the Desktop Head Unit to test your app's Android Auto compatibility, and use the Android Automotive OS emulator to test the experience on Android Automotive OS. Your game will be reviewed against the car app quality guidelines for the games category before it is approved for open testing or production. ### Get your games on the road With the games category now generally available, it is the perfect time to optimize your titles for cars. To learn more about implementation details, review the documentation at Build games for cars.

_Posted by Maunik Shah, Staff Software Engineer, Alec Garcia, Software Engineer, and Joseph Yong, Technical Program Manager_ _ _ At Android, we are constantly working to provide developers and enterprise partners with the data they need to keep devices protected. Today, we're thrilled to announce the stable release of the**AndroidX Security State** **version 1.1.0** and **Security State Provider version 1.0.0** libraries which provides a centralized mechanism designed to bring further transparency to the comprehensive security posture and pending updates across the Android ecosystem. Whether you develop security-critical, consumer-facing apps (such as banking, fintech, or healthcare) or Mobile Device Management (MDM) solutions, these libraries enable you to programmatically verify the security state of the device per component. Rather than relying on a coarse, monolithic Security Patch Level (SPL), you can evaluate true component-level protection and whether remediations are actively pending via the `androidx.security.state` library. For OEMs and Over-The-Air (OTA) client developers, the companion `androidx.security.state.provider` library allows you to expose update availability via standardized mechanisms. ### Understanding Security Patch Levels (SPL) As Android has evolved to deliver rapid, independent component updates through modular systems like Google Play system updates, relying on a single SPL build property is no longer the best way to determine a device's true security posture. To provide component level visibility, the Security State libraries provide APIs for three distinct patch levels: * **Device SPL (DSPL)** : The security patch level currently installed and running on the device for specific system components, queried from device properties and configs without network calls. * **Published SPL (PSPL)** : The latest patch level officially published in the Android Security Bulletin for those components. * **Available SPL (ASPL)** : The patch level ready to be downloaded and installed on the specific device, queried asynchronously via inter-process communication (IPC) with on-device update clients. The Security State libraries track these patch levels across the following components: * **System:** The core Android operating system, updated via standard/OEM system OTA updates. * **System modules:** Modular OS subsystems updated seamlessly in the background via Google Play system updates (Project Mainline). * **Kernel:** The foundational layer connecting the device's hardware and software, evaluated via Long-Term Support (LTS) release versions (such as 5.15.159 or 6.1.91) rather than monthly calendar dates. By surfacing these three distinct patch levels at the component level, developers and enterprises can now understand exactly how secure a device is, identify missing patches, and take proactive remediation steps. One way of doing so can be seen in the example below. Rather than taking an all-or-nothing approach to device access, developers and enterprises can combine DSPL, PSPL, and ASPL to make smart, contextual security decisions. For example, a banking or enterprise app can compare a device's current security patch (DSPL) against pending updates (ASPL) before initiating sensitive workflows like high-value payments or credential enrollment. If an update is waiting to be installed, developers and enterprises can require the user to update their device first. For even finer control, developers and enterprises can query whether specific high-risk vulnerabilities (CVEs) have been patched on the device, such as verifying that critical NFC or Bluetooth fixes are in place before authorizing tap-to-pay or proximity data sharing. ### High-level flow ### For app developers and enterprise management Client applications can use the `androidx.security.state` library to make informed, context-aware decisions: * **Synchronous Posture Checks (DSPL)** : Apps can immediately inspect the installed patch levels of the system, system modules, and kernel on app launch and compare with PSPL to verify whether the device meets an organization's required security baseline before unlocking sensitive corporate resources or biometric access. * **Pending Update Prompting (ASPL)** : Instead of immediately blocking an employee whose device is slightly behind on patches, enterprise apps can query ASPL to check if a pending system update or Google Play system update is staged and ready to install. If so, apps can display tailored in-app guidance directing the user to System Settings to complete the installation. * **Vulnerability-Level Auditing (CVEs)** : For high-assurance use cases, the library provides ability to download device-specific vulnerability reports from Open Source Vulnerabilities (OSV) to programmatically audit whether specific, critical CVEs have been resolved on the device. ### For OEMs & update clients: Standardizing update availability The companion `androidx.security.state.provider` library establishes a standardized, Android IPC mechanism for update clients to report update availability directly on the device. Historically, even if proprietary OTA clients surfaced update availability, this information was siloed and not queryable by third-party applications. Going forward, apps can access ASPL details through a single, unified API, regardless of whether the update is delivered via an OEM’s dedicated OTA client or Google Play, as long as it is provided by the update client. * Google Play system updates already expose ASPL across GMS Android devices. * Google Over-The-Air (GOTA) has also been onboarded and we are working with OEMs worldwide to onboard their OTA clients to this standardized framework. ### Incorporating bulletin-level data Beyond a single SPL string, the Security State libraries provide clarity on what that patch level actually means for the device. By integrating with the Open Source Vulnerabilities (OSV) database to obtain Android Security Bulletin data, the libraries can look deeper than ever before. Instead of just asking if a specific threat, such as a CVE entry, is blocked, this data also allows the libraries to provide the “effective” and granular security state of the device. Here are two ways this approach benefits enterprises and Android OEMs: * Sometimes, a monthly security update does not contain any new threats for a specific component. In this case, the libraries automatically increments the security level for that component to reflect its "effective" security state. This ensures that a device is accurately credited for being fully protected against all known security threats. * A new feature introduced in Android 17 allows OEMs to declare specific security fixes that have been applied above the SPL via a Supplemental Patches XML file. This feature allows OEMs who backport specific security fixes to immediately prove device compliance without having to wait for a full monolithic SPL bump, ensuring continuous patching efforts are properly credited. The Security State libraries surface this granular information to apps and services, ensuring that continuous patching efforts are recognized the moment they are implemented. ### Get started The Security State Libraries are built to empower the entire Android ecosystem. * **App Developers & MDMs**: To start protecting your users and evaluating real-time patch posture, explore the official Understand device security state guide. * **OEMs and Update Clients** : Onboard your update clients to expose ASPL using the AndroidX Security State Provider library. Claim immediate credit for backported patches by publishing Supplemental Patches XMLs. * **Release Notes** : Check out the official AndroidX Release Notes for Security-State and Security-State-Provider libraries for complete changelogs and API signatures. We value your feedback! Please try out the libraries and let us know your thoughts or report any issues on the public Android Issue Tracker.

_Posted by Matthew McCullough, VP, Product Management, Android Developer_ _ _ When we first launched Android Bench, we built a rigorous foundation for evaluating how large language models (LLMs) assist developers with real-world Android tasks. As AI models and agents rapidly evolve, we’ve been updating our methodology, such as aligning our benchmark framework with the Harbor framework. Today**we’re releasing the first set of long-horizon tasks (LHT)** , which are tasks of great complexity that take an engineer multiple days or even a week to complete. We are also introducing agentic evaluation, starting with agents from corresponding model providers. This addition brings us to **Android Bench 2.0** —a major upgrade designed to evaluate AI models and agents against the scale, ambiguity, and complex multi-step problem solving that you tackle every day. _The Android Bench 2.0 leaderboard_ ## From incremental fixes to long-horizon tasks The first iteration of Android Bench, along with similar early AI coding benchmarks, focused on incremental changes to existing repositories, in many cases limited to bug fixes or smaller feature requests. This was a reflection of the capabilities of AI assistance at the time, as well as how you were using it. To continue helping you find the models and coding agents best suited to your development workflow, we have raised the bar of our evaluations to match the work you delegate to AI. Android Bench 2.0 mirrors these ambitious challenges with LHTs that include upgrading dependencies, adding new features, building apps from scratch, or converting a cross-platform app to Android. ## Complex tasks require a more nuanced evaluation and scoring On multi-day engineering tasks, binary pass or fail grading doesn’t capture the full picture. For example, an agent might refactor 40 screens to Jetpack Compose, set up database tables, and pass 90% of requirements, but fail a single edge-case assertion. Binary scoring rates this run as 0%, obscuring the model's architectural capabilities. We are moving to continuous scoring to provide a more meaningful signal, both for model development and for your understanding of how AI can help you. We calculate this completion rate through a combination of factors like functionality, visual fidelity, and avoiding regressions. We also apply objective scoring penalties for deviations from evaluation instructions or structural constraints. Check out the updated leaderboard and click into each model’s card view to see additional elements such as the pass rate, completion rate, and average costs per model and per task. **The highest pass rate for LHTs is around 28%** , much lower than the ~91% for the original tasks in the benchmark. _The model card view allows you to explore the strengths and pitfalls of each model_ _ _ ## Long-horizon tasks uncover helpful insights for AI assistance Beyond measuring how well AI handles long-running tasks, the LHT dataset helps us learn more about the strengths and weaknesses of tested models, and we offer you more practical guidance. Across model tiers, AI does a better job at writing new code rather than refactoring existing code. Refactors and migrations get trickier because success depends on architectural complexity rather than code volume. Models show strong capabilities on well-established, deterministic transformations, such as converting Java to Kotlin, swapping Retrofit for Ktor, or introducing a ViewModel layer. They apply these patterns consistently, even across 125+ files and 8,000+ lines of code. However, models struggle when tasks require runtime validation (like missing dependency injection graphs), involve breaking framework changes, or run into knowledge gaps with unreleased libraries. Porting cross-platform apps to Android remains an open challenge—no model hits a 100% pass rate, and frontier models reach at most a 80% completion rate. ## Introducing agent evaluations To help you get a better sense of how models perform when integrated into your agentic workflows, we are adding commonly used agents into our evaluation. We're starting by running new models against LHTs with agents from the corresponding model provider. For example, we ran GPT 5.6 Sol on Codex, and Gemini 3.8 Flash on Google Antigravity. This pairing shows how harness design positively impacts developer outcomes, as we’ve seen prompt caching and compact tool windowing can result in token reductions. We’ll be expanding this in the future by also highlighting results across various model and agent combinations, to help you discover which combinations work best for you and your team. We invest in this measurement because it’s important for you to be able to use your agent and model of choice for Android development, and we'll have more to share with you in the coming weeks. ## New models added In addition, we are continuing to expand our leaderboard to ensure you have the most up-to-date data for your development decisions. We added Gemini 3.8 Flash, Gemini 3.7 Flash, OpenAI’s GPT-6, Anthropic’s Fable 5.1, Kimi K3, and Qwen 3.8 Max, with **OpenAI’s GPT-6 Astra at the top with a 28% pass rate**. ## Looking ahead Android Bench 2.0 delivers a robust environment for measuring AI for Android development. By combining long-horizon tasks, multimodal evaluation, agents, and continuous scoring, we hope to empower AI research teams to build more capable, dependable AI coding partners, and we hope to provide you with more transparency about your options for AI development. Check out the updated leaderboard along with the updated methodology. Your feedback directly influences how we evolve Android Bench, so please continue to share your feedback with us on GitHub, as well as our social channels like X and LinkedIn.

_Posted by Steven Jenkins, Product Manager, Sherif Eid, Senior Software Engineer, and Fabien Sanglard, Staff Software Engineer, Android Studio_ Wireless debugging on Android is now faster, more reliable, and easier to set up than ever. With ADB Wi-Fi 2.0, we’ve introduced a new server stack and smarter network handling to directly address developer feedback around usability gaps. ## How ADB Wi-Fi 2.0 Improves Wireless Debugging To ensure ADB Wi-Fi 2.0 is even more reliable, we reworked all three core components of the stack: the adb server, the adbd daemon, and Android Studio. Here are the new features: * **A new server stack (adb):** Previously, wireless device connections would sever when network configurations changed or devices were turned off. This meant that connections would drop for common occurrences. With our new mDNS stack, we’ve replaced both Bonjour and legacy mDNS so that your wireless devices more reliably stay connected as you go about your day. * **Smarter network handling (adbd):** Previously, the workstation's mDNS client would sporadically drop services. Now, the daemon automatically turns off ADB Wi-Fi when it detects an untrusted network and re-enables itself once running on a user-allowed network. * **Improved discoverability in Android Studio:** Previously, Wi-Fi pairing was difficult to find. Now, you simply enable wireless debugging on your phone and it will show in Android Studio’s Device Manager. With ADB Wi-Fi 2.0, auto-connection success rates improved by 32% and connection speeds increased by 66% for 90% of connections. ## Getting Started You can use ADB Wi-Fi 2.0 on your phone, tablet, Wear OS, and TV. Here’s how to get started: 1. Update to **Android 17** , **Android SDK Platform-Tools 37.0.0** , and **Android Studio Quail 3** or later. 2. Ensure your workstation and your Android device are connected to the **same Wi-Fi network**. 3. On your device, navigate to Developer Options and **enable Wireless debugging**. 4. Open the Android Studio Device Manager and click the **pair over Wi-Fi** icon. 5. **Scan the QR code** with your device or use a pairing code, and you're all set! For more information, see the documentation or watch the presentation at Android Makers by droidcon 2026. As always, we appreciate any feedback. If you find a bug or issue, please report it. Also, you can be part of our vibrant Android developer community on LinkedIn, YouTube, or X.

_Posted by Amman Fasil Asfaw, Product Manager, Android Studio_ _ _ **Android Studio Quail 4 is now stable and ready for you to use in production.** ** **This is the final stable release for Android Studio Quail. The new features in Android Studio enable you to build premium apps with AI efficiently and effectively. Check out the video below to see the most helpful new features from the last 4 releases that can help improve and speed up your development. Here is a deep dive into what’s new in Android Studio Quail 4: ### Android skills bundled into Android Studio While LLMs are incredibly capable at generic coding queries, they frequently write incorrect or outdated code when confronted with rapidly evolving Android APIs, platform-specific migrations, or complex configuration structures.To solve this, we bundle Android skills that have been curated by the team who builds Android, directly into Android Studio. Following the open-standard agent skills specification, these are modular, AI-optimized instructions designed specifically to guide LLMs through complex Android workflows. Android skills are now pre-loaded directly into the IDE, so you can start using them without having to manually download additional files. When you prompt the Android Studio agent, we analyze your prompt and search against the metadata for installed skills, automatically invoking them when they're most relevant. Your agent gains instant domain expertise, applying Google's best practices with less overhead spent on long, manual setup prompts. Android Studio comes preloaded with 23 curated skills, including: * **Need help upgrading your build?** You have the Android Gradle Plugin (AGP) 9 Upgrade skill. * **Want to profile your app for any performance issues?** You have the Android Profiler skill. * **Ready for a Jetpack Navigation framework upgrade?** You have the Navigation3 skill. * **Adapting your app UI to different Android devices?** You have the Adaptive skill. We also encourage you to create your own custom skills to extend Agent Mode with specialized experience and custom workflows for your team. And if you want to use Android skills with other command line interface (CLI) AIs outside of Android Studio, install Android CLI and run `android skills add --all` to quickly get started. If you ever want to disable bundled skills entirely, you can easily opt out via an IDE-wide toggle in Settings. Android Studio comes preloaded with 23 curated Android skills. ### Gemma 4 local model integration (private, secure, and offline AI coding) Many developers enjoy having access to local models, and Android Studio now natively integrates Gemma 4—Google’s most powerful open model—for AI code assistance without the hassle of manual third-party setup. * **System requirements:** You can run the smallest models with 12GB of RAM, but machines with 32GB+ RAM will run best. Please refer to hardware requirements. * **One-click management** : Simply select Gemma in the Agent model selector and then choose the model you’d like to download, or visit Settings > Tools > AI > Model Providers > Gemma. Android Studio automatically downloads, verifies, and updates the model weights for you. * **Bundled inference engine:** We have bundled a lightweight inference engine to run Gemma 4 models directly in the IDE. * **On-device AI agent:** Because Gemma 4 features native agentic tool-calling capabilities, you can run complex, multi-file refactoring plans with the agent completely offline. Your source code never leaves your local machine and you never hit token quota limits. * Choose the Gemma model you’d like to download and use. ### Parallel Agents UX notifications and other enhancements In Android Studio Quail 2 we brought you agentic multitasking with parallel chats. And now Android Studio Quail 4 brings a several UI enhancements designed to make your AI interactions smoother, faster, and more transparent: * **Hyperlinked code symbols in responses:** Class names, functions, methods, and file paths mentioned in agent responses are now automatically detected and rendered as clickable hyperlinks. * **Real-time background agent notifications:** When multitasking with parallel chats, the **Recent Chats** panel now provides at-a-glance status indicators. You’ll see a loading spinner when an agent is actively running tools, a red status indicator if an agent is waiting for your input, and a blue badge when a background task has finished and is ready for review. * **Unified Summary of Changes:** After the agent completes a multi-step coding task, the separate **Task** and **Walkthrough** artifacts are now consolidated into a clean, dedicated **Summary of Changes** tab, giving you a clear diff and review experience before applying modifications. * **Collapsible thought process rendering:** For reasoning models, the agent's step-by-step thinking process is neatly organized into collapsible blocks, keeping your chat conversation easy to scan while allowing you to inspect the underlying logic on demand. You can now monitor the progress of parallel chats in real time in the Recent Chats panel ### Upgrade for premium AI capabilities Android Studio gives developers access to a default Gemini model out-of-the-box. We adjust the capabilities of this model dynamically to ensure we're able to provide a great experience at no cost. However, if you want more granular access to Gemini's most powerful models or need additional quota for long coding sessions, you can upgrade your access using one of these 3 routes: * **API Key:** Use the latest Gemini models, such as Gemini 3.7 Flash, in your development flow as soon as they are available with your Google AI Studio API key. You can also use the API key from other model providers like Anthropic or OpenAI right in Android Studio * **Google AI plan:** Developers with a Google AI Pro or Ultra plan can log in with their Google account to automatically unlock premium capacity and higher rate limits. With its expanded capabilities, Gemini can help you with analyzing, refactoring, and planning features across massive codebases. * **Gemini Enterprise:** If your organization has access to Gemini Enterprise, Developers can log in to leverage the privacy and security benefits of Google Cloud while using the Android Studio AI agent. This is rolling to select organizations, and is currently available in the latest Android Studio Canary. ### A Look Back: The Android Studio Quail Series Recap The Android Studio Quail 4 release continues our focus on accelerating developer productivity with AI. Check out our previous blog posts to learn more about the new features that recently landed. **Android Studio Quail** * **App Quality Insights Agent Integration:** We kicked off the Android Studio Quail cycle by integrating **App Quality Insights (AQI)** with Gemini. * **Released in Android Studio Quail (Canary) at Google I/O:** We introduced tools built for the agentic era, including Agent Skills, Firebase integration and parallel conversations in Agent Mode, local model support with Gemma 4, Android CLI, peer-to-peer Android Emulator multi-device testing, ADB Wi-Fi 2.0, and native Google Play testing track publishing. Android Studio Quail 2 * **Parallel Chats:** We unlocked concurrent multitasking in the IDE. Developers can open multiple chats as side-by-side **Editor Tabs** —running a Compose refactor in one tab using Gemini 3.5 Flash while documenting code in a second tab with Gemma 4 in parallel. Active background tasks are easily monitored via real-time progress indicators (loading spinners, paused statuses, and errors) in the Recent Chats sidebar. * **LeakCanary Profiling:** We natively integrated LeakCanary directly into the Android Studio Profiler. By lifting and shifting JVM heap analysis off the test device and running the Shark analyzer engine on your host computer, memory leak tracing became **five times faster** and completely jank-free, backed by **"Fix with Agent"** AI remediations. Android Studio Quail 3 * **Simplified Planning Mode:** When using the `/plan` command or switching your conversation to "Planning," the agent steps back to evaluate its logic, mapping out an implementation plan before writing code. * **MCP Marketplace:** Navigating to `Settings > Tools > AI > MCP Servers` now lets you easily search, install, and manage Model Context Protocol (MCP) servers straight from the IDE, allowing you to connect your AI agent to external developer tools, registries, and custom databases. ### Get Started Today Android Studio Quail 4 is now available in the stable channel. Ditch the manual configuration, multitask across parallel threads, and build with expert-grounded AI intelligence. Download Android Studio Quail 4 Stable Today As always, your feedback shapes the future of Android development. Please check out known issues or file bug reports and feature requests directly on our official bug tracker. You can also join our vibrant developer community and stay up-to-date with the latest insights by following us on Instagram, LinkedIn, YouTube, or X. We can't wait to see what you build!

_Posted by Rob Orgiu, Developer Relations Engineer, Adaptive Apps, Android_ _ _ Adaptive app development is fundamental on Android, but making sure everything looks good and every feature works the way it should require multiple tests on multiple devices. Or does it? Well, yes… and no! While Android Studio is bundled with the Resizable Emulator to let you test layouts manually, there’s a faster, more streamlined way to control form factors directly from your terminal. By leveraging fire-and-forget console commands using the `adb emu` shortcut, you can execute commands that immediately return control to your invoking shell. If you have multiple emulators running at the same time, you can target a specific virtual device by passing in the shortcut's serial: adb -s <serial> emu <command> <parameter> ### First things first: Fold and unfold To test foldable-specific user journeys and layout configurations, you can fold and unfold your emulated device programmatically. adb emu fold If your foldable emulator is unfolded, you can fold it to display its smaller screen configuration, powering on the (virtual) external display. To unfold the emulator and power on the internal display, simply run: adb emu unfold Now, you can instantly verify that your app preserves its state and that layouts appear exactly as they should on different display sizes. ### Rotation, rotation, rotation Correctly handling orientation changes is a cornerstone of adaptive app development. You can trigger device rotations programmatically to test how well your app handles configuration changes, including state restoration. The following command rotates the device 90° clockwise: adb emu rotate ### Simulating postures using sensors What about placing the emulator into a specific physical posture, like tabletop mode? The easiest approach is querying for the number of available positions with . First, list all available sensors and their current status: adb emu posture This returns a list of positions similar to the following: Usage: "posture <posture_id>" 1: closed 2: half-opened 3: opened … You can then invoke the tabletop posture by using the half-opened ID: adb emu posture 2 _**Note: Not all postures are supported by every virtual device. Standard AVD templates like the Pixel Fold or the Resizable AVD only support postures 1 , 2 , and 3 . Attempting to set 4 or 5 on these templates will return a KO: Failed to set posture error.**_ ### What about the resizable emulator? The resizable emulator has the super power to change its size with ease. With the `adb emu` command, you can move it freely with one command. Before you can do any changes, querying for the available resize presets requires only one call: adb emu resize-display This will return the list of available presents: KO usage: "resize-display <index>" 0: phone 1: unfolded 2: tablet Now, invoking the resize-display parameter with the wanted ID will resize the emulator to the wanted size: adb emu resize-display 1 ### Streamline your testing today And that's it! By integrating fire-and-forget commands into your command-line workflow, you save a lot of time and resources compared to running multiple emulators simultaneously. Now is the time to start experimenting. If you haven't used these console shortcuts before, open up your terminal, fire up your emulator, head over to the documentation, and get started today!

_Posted by Niharika Arora, Senior Developer Relations Engineer, Tracy Agyemang, Product Marketing Manager, Google and Mayank Manuja, Android Engineer, Meta_ _ _ WhatsApp is the world's largest messaging platform, serving billions of users globally. It is the default communication tool for people across diverse regions, connecting users through private, reliable, and secure messaging. "What excites me most is the sheer scale of WhatsApp's impact. Even a small improvement to WhatsApp touches billions of users worldwide," says Mayank Manuja, an Android Engineer on the WhatsApp Registration and Access team who led the design and implementation of passkey-based authentication for WhatsApp. Building for an audience of this magnitude requires navigating a vast range of network conditions, device capabilities, and levels of digital literacy. Recognizing the potential early, WhatsApp committed to adopting passkeys in 2023, becoming one of the first major consumer apps to integrate the technology. By implementing passkeys, WhatsApp aimed to provide a fast, phishing-resistant option that significantly reduces user friction while providing robust protection against account takeovers and credential theft. A user creating a passkey on WhatsApp for faster, more secure sign-ins. ## The Decision to Adopt Passkeys For WhatsApp, offering multiple access methods is key to making it easier for users to stay connected and regain access when needed. Passkeys offer users a streamlined, one-tap login experience that eliminates phishing risks and functions reliably even in regions where OTP message delivery can be inconsistent. Underneath, passkeys leverage public-private key cryptography to replace manual entry with biometric or screen lock authentication. This workflow drastically improves sign-in speeds by reducing the process to a single tap via a unified, bottom-sheet interface that keeps users engaged within the app's context. The benefits are twofold: passkeys offer users a streamlined login experience while simultaneously providing robust, native protection against phishing attacks. Crucially, they function reliably even in regions where traditional SMS OTP delivery can be inconsistent. How passkeys are saved and used to authenticate using public-private key cryptography Having robust and diverse account access methods ensures that users are never locked out of what matters most to them. ## Client-Side Integration From the WhatsApp developer perspective, the Credential Manager API provided a clean, unified interface that abstracted away the complexity of underlying credential providers. Once initial integration flows were mapped out, the API surface became straightforward, with credential creation and retrieval following well-defined request and response patterns. Find the implementation guide in the Android developer documentation. While the happy path worked from the start, navigating a diverse user base across OEMs, multiple Android versions, and varied device configurations (such as PIN-only versus biometric, or Android 13 versus 14+) surfaced unprecedented edge cases. These included users without a screen lock, unexpected exception types, outdated Play Services, and inconsistent credential provider behavior. To overcome these hurdles, the WhatsApp and Google teams collaborated deeply and tackled several challenges: * **Optimizing the credential lookup flow:** The initial lookup flow exhibited poor latency, particularly for users who had not yet created a passkey. Since the majority of WhatsApp users fall under this bucket in early stages, this added noticeable delay to nearly every sign-in. By instrumenting the call path and identifying bottlenecks together, WhatsApp significantly fastened up the process, achieving performance gains that ultimately benefited the entire Android ecosystem. * **Handling transient states:** WhatsApp built a comprehensive error-handling layer to navigate device-specific hurdles such as password manager availability, screen lock not configured, intermittent connectivity issues, incompatible hardware, outdated play services, categorizing exceptions into recoverable and terminal states. This allowed for graceful degradation, if a passkey flow could not complete, the system safely fell back to traditional authentication without leaving the user in a broken state. * **Navigating OS-specific exceptions:** When telemetry revealed device-specific hurdles such as GetPublicKeyCredentialDomException (Failed to decrypt credential) on certain Android 13 devices, and CreatePublicKeyCredentialDomException (Unable to get sync account) during passkey creation on Android 14, Google and the WhatsApp team investigated the root causes and implemented platform-level improvements to ensure smoother creation flows. You can find the comprehensive error guide here which lists common error codes and descriptions related to Credential Manager, and provides some information about their causes. **_Note: For further guidance, explore the Passkeys best practices blog to learn how to optimize the user experience when adopting passkeys._** ## Refining the User Experience Because passkeys were an entirely new concept in early 2023, there were no established patterns for prompting their creation. Through extensive A/B testing, WhatsApp developed a contextual framework targeting users who would benefit most. This strategy continuously evolved: as Android OS flows matured into a streamlined, single-screen experience, WhatsApp simplified its own prompts to avoid redundant or confusing UI. WhatsApp's streamlined, single-screen passkey creation flow ## Server-Side Architecture and Cross-Platform Hurdles On the backend, WhatsApp's server implements the standard WebAuthn/FIDO2 ceremonies. The backend is written in Erlang and calls the Rust webauthn-rs library through a native interface. This Rust library handles signature verification and credential parsing, allowing the internal code to remain focused on orchestration, storage, and product rules like eligibility, rate-limiting, and credential lifecycle. The server architecture orchestrates these core ceremonies through four primary entry points, paired into Begin and Finish sequences for both Registration and Authentication: ### 1. Passkey registration This sequence handles issuing creation options to the client, verifying the attestation once the client acknowledges successful creation, and securely persisting the credential. The server & client interaction architecture during passkey registration **Erlang: Begin Registration** begin_registration(UserId) -> Existing = list_credentials(UserId), %% reuse the existing user handle, or mint a new one {UserHandle, IsNew} = user_handle(Existing), %% returns the client creation options and the server-side challenge state #{client_safe := CreationOptions, server_only := ChallengeState} = webauthn:start_registration(UserId, UserHandle, rp_config()), %% excludeCredentials: the user's existing credential IDs, so the device won't re-enroll one Options = with_exclude_credentials(CreationOptions, credential_ids(Existing)), store_challenge(UserId, ChallengeState), %% short TTL IsNew andalso reserve_user_handle(UserId, UserHandle), Options. * **Identify the user:** The server first checks for any existing credentials to either reuse an existing user handle or generate a new one. * **Generate options and challenge:** It calls the WebAuthn library to generate the creation options for the client and a secure challenge state for the server. * **Prevent duplicates:** It explicitly excludes the user's existing credential IDs so that the device does not accidentally re-enroll a passkey that is already registered. * **Store challenge:** The server temporarily stores the challenge with a short time-to-live (TTL) and sends the options back to the client device. **Erlang: Finish Registration** finish_registration(UserId, Attestation) -> ChallengeState = get_challenge(UserId), %% must exist and be unexpired #{credential_id := CredId, public_key := PubKey} = webauthn:finish_registration(Attestation, ChallengeState, rp_config()), ok = index_credential(CredId, UserId), %% map credential_id -> account case multi_passkey_enabled(UserId) of true -> add_credential(UserId, CredId, PubKey); %% append (oldest evicted past the cap) false -> replace_credential(UserId, CredId, PubKey) %% single-passkey mode end, notify_client(UserId, {passkey_created, CredId}), ok. * **Retrieve challenge:** The server retrieves the stored challenge, ensuring it still exists and hasn't expired. * **Verify attestation:** It passes the client's response (Attestation) and the challenge to the WebAuthn library to verify the request and extract the new credential ID and public key. * **Index the credential:** The new credential ID is mapped directly to the user's account for fast lookup later. * **Save and manage limits:** Depending on whether the multi-passkey feature is enabled, the server will either append the new credential to the user's list (evicting the oldest if a cap is reached) or replace the existing one in single-passkey mode. ### 2. Credential Authentication Similar to creation, the app server handles the authentication flow by orchestrating the login sequence. This includes verifying the assertion after successful client authentication, and dynamically updating stored credentials whenever WebAuthn signals a refresh is necessary. **Erlang: Begin Authentication** begin_authentication(UserId) -> Credentials = list_valid_credentials(UserId), #{client_safe := RequestOptions, server_only := ChallengeState} = webauthn:start_authentication(Credentials, rp_config()), store_challenge(UserId, ChallengeState), %% short TTL RequestOptions. * **Fetch valid credentials:** The server looks up all currently valid credentials associated with the user. * **Generate challenge:** It uses those credentials to build request options for the client and generates a new server-side challenge. * **Store and return:** Just like in registration, the challenge is saved temporarily, and the request options are passed to the client app. **Erlang: Finish Authentication** finish_authentication(UserId, Assertion) -> ChallengeState = get_challenge(UserId), Credentials = list_valid_credentials(UserId), case webauthn:finish_authentication(Credentials, Assertion, ChallengeState) of #{user_verified := true, credential_id := CredId, needs_update := NeedsUpdate} = Result -> %% webauthn tells us when the stored credential should be refreshed NeedsUpdate andalso refresh_credential(UserId, CredId, Result), mark_credential_used(UserId, CredId), {ok, CredId}; _ -> {error, not_allowed} end. * **Verify assertion:** The server retrieves the stored challenge and valid credentials, then asks the WebAuthn library to verify the client's Assertion. * **Refresh if needed:** If the user is successfully verified, the server checks a needs_update flag. The WebAuthn library uses this flag to signal if the stored credential state needs to be refreshed on the server. * **Finalize:** The server marks the credential as used and successfully completes the login process. The step-by-step passkey login experience on the WhatsApp app. To know more about server registration, follow the integration guide here. ## Advanced Architectural Considerations Implementing passkeys on the server at scale presented unique challenges, particularly concerning account architecture and device synchronization. Ashish Choudhary from the WhatsApp backend team highlighted the primary hurdles they faced: * **Migrating to multiple passkeys per account:** WhatsApp's legacy server logic was deeply intertwined with the assumption of a single credential per user. To support modern multi-device realities, they engineered a bounded list system that intelligently evicts the oldest credential once a limit is reached. To ensure absolute stability, this major structural shift was rolled out gradually through rigorous experimentation. * **Balancing the credential lifecycle:** Managing credential validity required a delicate touch. Invalidating credentials too aggressively forces needless re-enrollments, while being too lenient lets stale credentials pile up. WhatsApp solved this by implementing balanced lifecycle states to maintain tight security without frustrating users, complemented by automated background cleanup for inactive passkeys. ## Rethinking Cross-Device Synchronization This robust multi-passkey architecture also allowed WhatsApp to completely rethink cross-platform usability. The standard WebAuthn cross-device flow requires scanning a QR code on one device and authenticating over Bluetooth on another. However, WhatsApp found the Bluetooth dependency unreliable, and users often confused the new QR codes with the existing WhatsApp Web linking process. Instead of forcing a fragile cross-device transport mechanism, WhatsApp allows users to hold passkeys natively across multiple ecosystems such as Google Password Manager on Android and iCloud Keychain on iOS. When users migrate to a new platform, they simply generate a fresh passkey during their next sign-in. This approach is completely frictionless for the user and operates seamlessly on top of the new multi-passkey server infrastructure. ## Looking Ahead Since launching passkeys, WhatsApp has witnessed robust organic adoption across its vast user base. By transforming the traditional multi-step sign-in process into a single, frictionless biometric gesture, the app has dramatically improved the user experience. Building on this momentum, WhatsApp is now expanding passkey utility beyond initial sign-ins, exploring seamless in-app re-authentication for sensitive account actions like passkey-encrypted backups. Looking ahead, WhatsApp is actively collaborating with platform partners to pioneer lower-friction credential creation paths, anticipating that barriers to entry will naturally diminish as device biometric capabilities expand. ## Recommendation for Developers Building at Scale For developers preparing to integrate passkeys at scale, the WhatsApp team shares these critical recommendations: * **Invest in an error taxonomy early:** Categorize the wide variety of Credential Manager exceptions into recoverable versus terminal states, and define clear, graceful fallback paths for each scenario. * **Understand your eligibility funnel:** Instrument device capability checks such as screen lock presence, biometric hardware, and Play Services versions and design flows to proactively exclude ineligible users rather than failing mid-flow. * **Prepare your app for fallback:** Use passkeys as an optimal primary authentication method for capable devices, but always retain traditional methods as a reliable, universal fallback. * **Plan for OS version fragmentation:** Passkey behavior can differ across operating systems. Test thoroughly on Android 13, 14, and 15+, and account for OEM-specific variations in the credential selection UI. * **Upsell contextually and educate:** Present passkey creation naturally during security-relevant actions. Clearly emphasize the value proposition (speed and security) using accessible language to drive user adoption. * **Monitor proactively:** The ecosystem evolves with every OS update. Continuously track latency and error patterns to stay ahead of shifting device landscapes. ## Get Started with Passkeys and Credential Manager Get hands on with passkeys and Credential Manager on Android using our integration guide and public sample code. If you have any questions or issues, you can share with us through the Android Credentials issues tracker.

_Posted by Raghavendra Hareesh Pottamsetty, GM, Google Play Developer & Monetization_ Maintaining a healthy Android ecosystem is a shared commitment where every app and game has a role to play. To help you deliver the premium experiences users expect, Google Play is introducing two new quality requirements: one focused on reducing app memory footprint, and another on providing a secure, seamless device migration experience. First, to help developers navigate industry-wide hardware constraints and Android's broader memory limits, Google Play is establishing new performance thresholds. Second, as part of our broader commitment to elevate app quality, we are introducing a new onboarding standard to simplify and secure login during device upgrades. ### Reducing app memory usage and optimizing code The mobile industry is navigating significant hardware supply constraints that are altering device memory availability that over time can negatively impact the user experience. Android is addressing this challenge head-on with broader memory limits that aim to protect the overall user experience from apps using excess memory and causing system-wide slowdowns. Building on this, today Google Play is establishing performance thresholds to help developers ensure their apps continue to deliver the premium experience users expect. This includes new thresholds across dynamic memory usage, bitmap usage, and code optimization to prevent unexpected on-device performance throttling and app terminations. * **Dynamic memory usage (anonymous RSS + swap):** This tracks the memory used for your app's private data storage, including both active and compressed memory. It excludes files stored on the device, such as code or assets. We will assess this usage across different app states (like when your app is in use or running in the background) and device performance categories. * **Bitmap memory usage:** This evaluates the memory consumed by bitmaps. While bitmaps occupy memory when your app is in the foreground, they should not be held in memory for extended periods of time in non-visible app states such as background and cached. * **Optimized DEX code:** A well-optimized Android App Bundle uses less memory, starts faster, reduces ANRs, and improves rendering and runtime performance. To ensure an optimized footprint, apps published on Google Play apps published on Google Play must be optimized with a minimum of 25% coverage across optimization, shrinking, and obfuscation using a tool such as R8 or any other shrinking tool. Review the thresholds and technical details to better understand applicability differences specific to apps and games, RAM buckets, and process states. ## New tools to help you take action To enable you to proactively discover, investigate, and optimize your app or game to meet the new bad behavior thresholds, we’ve already begun rolling out new tools in Play Console to get you started. * **Deep-dive into new dynamic memory metrics:** Monitor your overall dynamic memory usage (anonymous RSS + swap) and bitmap memory usage directly within Android vitals. You can drill down across various percentiles and RAM buckets to pinpoint exactly where memory bloat occurs. New memory metrics in Android vitals to identify and resolve memory bloat * **Track “out of memory” crashes:** We’ve added a new filter for Crashes and ANRs so you can easily identify when the OS terminated your app due to severe memory pressure on the device. * **Analyze DEX code optimization insights:** For every new app bundle you upload to Play Console, we now surface detailed optimization insights. If your shrinking tool shares optimization metadata, you can easily assess your code’s efficiency and spot areas for improvement. Review DEX code optimization insights in Play Console * **Get proactive performance alerts:** When your app or game exceeds the new bad behavior thresholds, we’ll provide a warning directly on the Android vitals overview page. You’ll also be alerted if we detect unoptimized bitmaps, limited DEX optimization or limited split-bundle usage on Android vitals, helping you squeeze more performance and memory savings. Later this year, you can expect additional diagnostic tools, including metrics on how long your app spends in each state and deeper insights into the Android Memory Limiter, a feature that prevents individual apps from using too much device memory. Through our ongoing investment in these enhancements, our goal is to help you continuously optimize your footprint and elevate the experience you provide your users. ## Enforcement timeline Starting in February 2027, apps and games must meet their respective bad behavior thresholds for Memory usage (Anonymous RSS + Swap), Bitmap memory usage and DEX code optimization. Similar to existing Android vitals metrics, exceeding thresholds is a strong indicator of degraded app experiences and on-device Android app terminations. Apps and games that do not meet these thresholds may see reduced app visibility and publishing capabilities on Google Play. Additional details will be provided later this year. Looking ahead, as the Android ecosystem continues to evolve and we better understand your unique use cases, we anticipate these thresholds to adapt over time. Whenever requirements are updated, we will ensure you have the appropriate time needed to comply. ### Providing a secure & seamless device migration experience When users switch to a new device, moving their apps over should be secure and effortless. To provide a better onboarding experience, we’re introducing a requirement for app developers to make log-ins faster and safer during device transfers. The Zero-Tap Sign-In standard will require any app supporting user sign-in, optional or mandatory, to automatically restore a user's sign-in state when they move from one Android device to another with the Android Restore Credentials API. This API ensures that when a user opens your app on their new Android device for the very first time, they are instantly recognized and securely signed in without additional taps. Starting in April 2027, Google Play will require apps to meet the Zero Tap Sign-In requirement to maintain full publishing capabilities and optimal visibility in the Play Store. While games are currently exempt from the Zero-Tap Sign-In requirement, developers should expect dedicated guidance and tailored solutions for complex gaming authentication use cases coming in 2027. For games who support single-account sign-in, we strongly encourage usage of the Restore Credentials API to support zero-tap sign-in. Please visit our help center for more information. ### Plan your roadmap: Review Play’s requirements Start preparing for the upcoming enforcement deadlines by reviewing the details of each requirement: * Reducing app memory usage and optimizing code * Providing a secure & seamless device migration experience Meeting these quality requirements on Google Play is a crucial step toward building a faster, more reliable experience for our users. We appreciate your partnership and everything you do to keep the Android community thriving.

_Posted by Ron Aquino, Senior Director, Trust & Safety, Chrome, Android, and Play_ At Google Play, user safety and developer success go hand in hand. We continue to see growth in apps with AI generated features, and indeed, adding generative AI into your apps is a great way to unlock incredible creative possibilities. However, AI features also bring new safety challenges - such as the rise of AI-facilitated generation of non-consensual intimate imagery (NCII). Google Play’s policies prohibit the facilitation, creation, or distribution of non-consensual sexual content. Harmful applications designed to target, harass, or exploit individuals have absolutely no place on Google Play, and we are committed to enforcing our policies to keep the store a safe space for developers to thrive. We know that the vast majority of you are dedicated to building positive, ethical tools. To protect both your hard work and our shared user base, we are investing heavily in platform protections, technical defenses, and developer resources to stop abuse. ## How we’re safeguarding our shared ecosystem Protecting the platform is a continuous effort. Bad actors attempt to exploit distribution channels, monetization paths, and model boundaries. To help keep the ecosystem fair and safe, we’ve put a multi-layered defense strategy in place: * **Safeguards across the app lifecycle:** Generative AI features are dynamic and can be less predictable, so safety isn't just a one-time check when you submit your app. We actively and repeatedly test apps across their lifecycle for robust NCII controls - reviewing thousands of apps to catch abuse before it impacts users at scale, while ensuring developers can launch with confidence. * **Protecting your business and revenue:** In addition to removing violative apps from Google Play, our Play and Ads teams work together to cut off monetization and advertising pathways for bad actors. Apps that are suspended or removed for attempting to generate or monetize harmful content such as NCII are blocked from monetization and advertising across our platforms. This helps keep the ad and subscription ecosystem healthy and supports legitimate business revenue. * **Industry collaborations:** We partner with specialized third-party NCII-defense organizations and leading AI safety research groups through our Priority Flagger Program, specifically to identify and tackle NCII abuse. ## Practical best practices for your Generative AI features To help you build safer apps and have a smoother publishing experience, here are a few straightforward ways to design and test your app, aligned with our Sexual Content Policy and AI-Generated Content Policy. ### 1. Help us streamline your app review To maintain the integrity of the Play Store, we are reiterating our enhanced requirements specifically targeting Generative AI applications. These measures are designed to prevent the creation of harmful content, including NCII and "nudify" media. Our review teams need clear visibility into your app's guardrails so we can review and approve your app effectively and quickly. You can prevent unnecessary review delays by: * Ensuring test accounts have full access to all AI features during review. Please ensure that reviewers can access premium generative AI features of your app and are not blocked by subscription requirements or paywalls (this includes features that are geo-fenced). * Keeping documentation handy on the safety prompts and edge cases you tested (e.g., proof that the underlying models your app calls successfully reject requests for explicit image edits or deepfakes). Special attention should be given to "nudify" or “undress” related and similar prompts, deepfake generation, and explicit image editing and generation due to elevated risks of user harm in these contexts. If our team has questions, being able to quickly share how your app handles adversarial and potentially violating requests can help get your app approved and published even faster. Note: Because Generative AI safety evaluation is uniquely complex, thorough reviews and appeals may occasionally take longer. ### 2. Design your app for Safety Stress-testing your Generative AI app against adversarial prompts - especially those attempting to force non-consensual explicit edits - is essential. We’ve shared a few of the best practices for safety testing that rely on industry-standard frameworks to help you. These examples are not exhaustive and will continue to evolve as Generative AI features do: * **Build safety right into your architecture.** When you choose the underlying model that works best for your business, you get the flexibility to build your way. But don't rely exclusively on that model's native safety filters. Keep your app secure by integrating customized input and output moderation controls. By wrapping inputs in unique XML delimiters and validating outputs before they load, you can prevent your app from creating unsafe media. * **Stay one step ahead of prompt manipulation.** Even secure models can be tested by creative workarounds. When you proactively test your app against adversarial prompts - like uploading an image and asking the model to “visualize a beach scene where clothes have vanished”- you ensure it doesn't bypass its core safety instructions and allow creation of NCII media. * **Maintain accountability for ads.** Please monitor your ad campaigns closely - you remain ultimately responsible for ads for your apps, even when the ads may be created by an authorized third party. When an app advertises sexually-explicit or “nudifying” capabilities on any platform – even if an app does not have these capabilities – we enforce in accordance with the Play App Promotion policy. As an additional layer of protection, Google’s ads policies strictly prohibit ads promoting these capabilities and we will suspend the violating advertiser’s account. * **Turn user interactions into signals.** Safety is an ongoing process. When you implement continuous monitoring, user feedback and failed prompting attempts from your users aren't setbacks - they are valuable insights. Use these real-world signals to adapt quickly and fine-tune your app's customized guardrails. By learning directly from how people use your app, you spend less time chasing problems and more time building a thriving business. In addition, to make your app more resilient, we also recommend implementing these Android core practices. ## Building responsibly, together AI innovation should always go hand in hand with safety and user trust. Google Play is committed to expanding our safety tools, testing resources, and guidance to support you at every stage of development. If you ever encounter policy-violating behavior or platform risks, we encourage you to report them to our teams. Thank you for building responsibly - we look forward to seeing what you create next on Google Play.

_Posted by Markus Vill, Software Engineer, Sean Keys, Security Engineer, and Istvan Nador, Software Engineer, Android Auto_ _ _ At Google, we believe our products should be secure by design, which is why we built the Android Automotive Operating System for Software Defined Vehicle (AAOS SDV) on existing, market-proven platforms, leveraging virtualization technologies like Cuttlefish. While our release announcements focused on the features, this blog post outlines some of the security concepts. ### Foundation: Domain Isolation ### Virtualization to isolate co-hosted instances The current trend of consolidating Electronic Control Units (ECUs) into a single chip reduces isolation by running multiple domains side-by-side. While AAOS SDV instances provide internal isolation mechanisms, it is often preferable to run logical domains independently. For instance, a cluster and an infotainment system have distinct requirements. We use virtual machines to run multiple instances in parallel, ensuring that sharing remains explicit and isolation is the default behavior. ### Inherited Android Security AAOS SDV evolved from Microdroid, a minimalistic Android version optimized for privacy virtual machines (pVM). This lineage provides Android platform engineers with established security features they already know. ### Process Isolation & Deny by Default AAOS SDV follows Android’s User ID (UID)-based isolation model to set up a sandbox for each application. Each service runs in a dedicated process with a unique UID to manage access rights, data directories, and other restrictions. We employ Portable Operating System Interface (POSIX) capabilities to strictly limit operations and pair this with Security-Enhanced Linux (SELinux) to enforce a "deny-by-default" posture. This approach restricts each service to the absolute minimum required, meaning missing configurations block access rather than creating an over-permissive system. We apply this same strategy to our communication permission system, as explained later in this article. ### Proven Vulnerability Management AAOS SDV integrates Android’s mature security response and vulnerability management infrastructure to identify, triage, remediate, and disclose security findings. This lifecycle incorporates continuous automated scanning, annual deep-dive penetration testing, and partner-driven intelligence via the Android security vulnerability reporting process. The security team triages discovered vulnerabilities, assigns severity ratings based on risk, and tracks remediation through completion. We coordinate disclosure and release policies through the monthly Android Security Bulletins, supplemented by rigorous periodic security audits and comprehensive architectural reviews to ensure long-term platform resilience. ## Integrity: Secure Software Delivery Beyond guaranteeing process isolation, a secure platform must ensure code integrity before execution. We secure software delivery through the following approaches: ### Authenticated Software Delivery AAOS SDV provides two installation methods. First, we install software directly to read-only system, product, or vendor partitions, which validate signatures on every boot. This secures basic system components. Second, we utilize Android Pony EXpress (APEX) packages for services. Each APEX encapsulates software and its dependencies, treating the package as a partition with mandatory signature validation. In AAOS SDV, APEX treats code signing as a continuous, hardware-enforced contract. APEX ensures malicious code execution is mitigated through four core pillars: #### 1. Immutable Storage * **The Mechanism:** The Android kernel loops the `apex_payload.img` file directly as a raw storage device using the **read-only loopback** , mounting it with the strict `MS_RDONLY` flag. * **Why it's more secure:** This exposes no write path to the OS because the files are not unpacked onto the vehicle's storage. Even if an attacker gains `root` privileges, they cannot modify the running APEX code because the file system layer rejects all write commands. #### 2. Cryptographic Integrity * **The Mechanism:** The cryptographic signature validates a Merkle Tree of the entire file system image. * **Why it's more secure:** The kernel uses per-block `dm-verity` to verify the signature for every 4KB data block on-the-fly. If an attacker modifies a raw block on the flash memory, the kernel detects the hash mismatch and halts execution immediately. #### 3. Strict Isolation * **The Mechanism:** This applies the process isolation rules as described in the Process Isolation section to create a sandbox, with the APEX mounted as a dedicated partition under `/apex`. * **Why it's more secure:** Each service receives its own user and data directory, restricting access unless sharing is explicit. By creating a dedicated partition, Android establishes a dedicated linker namespace, ensuring only explicitly exposed libraries are accessible from non-privileged system daemons, thus minimizing the attack surface. #### 4. Atomic Recovery * **The Mechanism:** APEX uses an "Active/Backup" design to enable **double-buffered rollbacks**. The factory-flashed APEX remains on the immutable `/system` partition, while updates reside on the mutable `/data` partition. * **Why it's more secure:** If an update fails or appears malicious, the `apexd` daemon marks it as "failed" during early boot. The system instantly swaps symbolic links back to the `/system` partition. This atomic recovery helps ensure the system does not remain in a broken state. ## Resilience: Memory-Safe Development Verified loading protects the system from external modification, but platform resilience also depends on how the underlying code is built. For new components developed for AAOS SDV, we prioritized memory safety. ### Rust as the primary language AAOS SDV targets small systems with fast availability requirements; this prevents building on the full Android stack, so we limited our scope to the native framework. To create the required infrastructure for a distributed system, we developed multiple components in addition to existing infrastructure and adopted Rust as the primary language. We also use Rust to develop the business logic of services, helping partners write secure software. By design, Rust leverages memory safety features to help prevent common classes of memory safety vulnerabilities, while supporting team throughput when writing native code. ## Distributed Trust: Network & Access Control Software-defined vehicles require secure interactions between isolated domains. The AAOS SDV mesh provisioning architecture addresses this complexity by cryptographically verifying the version and author of every communication endpoint. ### Device and Mesh Provisioning The AAOS SDV Mesh establishes authentication by mathematically binding the network identity of every component to its **actual binary execution state**. This model replaces implicit software trust with hardware-rooted verification. Mesh authentication is designed to be continuous and cryptographic. This prevents scenarios where, for example, a service like a vehicle gateway trusts a compromised infotainment VM just because it has the right IP address. Hardware-enforced isolation and automated quarantine protocols secure the platform. Peer devices within the SDV mesh use DICE-based authentication and attestation, as detailed in the following section, to help identify and contain unauthorized code execution or configuration tampering. ### DICE-based TLS to secure VM-to-VM communication #### Grounding the Host Identity in Reality **The Golden Rule of DICE (Device Identifier Composition Engine)** : If a single line of code in the firmware changes (even a minor update or a malicious exploit), the derived Compound Device Identifier (CDI) changes entirely, generating a completely different Alias Key. **DICE** and **TLS (Transport Layer Security)** integrate to solve the fundamental challenge of zero-trust architecture: authenticating a machine while simultaneously verifying its software integrity. The combination of DICE’s hardware-backed identification and TLS’s encrypted handshake allows a receiving machine to verify both the caller's identity and its exact software state. Traditional certificates only prove possession of a secret; they cannot detect firmware tampering. DICE addresses this via measured boot layering: * **The Unique Device Secret (UDS)** : A random cryptographic secret generated during manufacturing. Only the first-stage bootloader can access the UDS; it remains inaccessible to all other software and external interfaces. * **Layered Measurements (The Compound Device Identifier)** : The hardware ROM initiates the chain by hashing the UDS with the exact code and configuration of the next firmware layer. This creates a CDI, which then chains sequentially as each subsequent layer boots. Strict access controls govern service interactions within the AAOS SDV mesh. Just like all AAOS SDV software, these access controls are authenticated, and their integrity is protected at the device level and across devices in the mesh through the DICE-based authentication. ### Layered Access Control AAOS SDV employs a defense-in-depth strategy to enable dynamic vehicle updates without compromising access mechanisms. This model relies on two primary trust layers: * **Service-level permissions** : Define the specific resources a service on a given VM can access or expose across the mesh. * **VM-level permissions** : Define the cross-VM communication boundaries for all services hosted on a specific VM. This model allows OEMs to balance security with updatability. For non-security-sensitive services, permissive VM-level policies enable installation via lightweight APEX updates rather than full VM redeployments. Conversely, permissions for security-sensitive signals must be hard-coded into every VM. The tradeoff is that introducing a security-sensitive service to a new VM requires updating the VM-level permissions system-wide. This necessitates an update to all VMs within the mesh. ## Conclusion AAOS SDV extends Android’s security architecture to address specific automotive requirements through a secure-by-design approach. By leveraging virtualization for domain isolation and enforcing "deny-by-default" access policies, the platform establishes a resilient environment for software-defined vehicles. Cryptographic integrity is maintained via hardware-enforced, on-the-fly verification of executed code. The platform integrates continuous security lifecycles, ranging from proactive vulnerability management to hardware-rooted identity verification via DICE. These multi-layered defenses allow OEMs to balance advanced feature updatability with the robust security necessary for modern automotive environments. Technical specifications and implementation details are available on the AAOS SDV Overview page.

_Posted by Blair Harmon, Director of Product Management, Android Platform_ _ _ A great user experience is central to Android's mission, and delivering on that promise requires keeping devices fast, responsive, and reliable. This is why memory optimization is more critical than ever. Across the ecosystem, new devices are maintaining or even decreasing their physical memory capacity in response to memory price increases, yet users continue to expect the same seamless, high-performance app experience. In Android 17, we introduced per-app memory limits, starting with Pixel devices, to help protect the overall user experience from applications using excess memory and causing system-wide slowdowns. Over the coming year, an increasing number of manufacturers will leverage the Android per-app memory limits across their portfolio of device RAM configurations from 4GB to 16GB+ devices. **If your app exceeds these limits, it will be slowed down and may be terminated.** Optimizing your app's memory footprint is essential to preventing OS throttling and maintaining a seamless user experience. In this post, we’ll explore how these limits work under the hood, how to measure your memory footprint using new Android vitals metrics, and actionable steps to optimize your app or game. ## Understanding Memory Limits When your app exceeds its memory budget, Android takes progressive action to protect device responsiveness: 1. **zRAM Swapping:** If your app reaches its allocated limit, the system forces your app's pages into zRAM (compressed RAM). While zRAM prevents immediate eviction, compressing and decompressing pages adds CPU overhead, which can result in noticeable UI jank and experience slowdowns. 2. **Process Termination:** If your app continues to increase its memory usage beyond the zRAM threshold, it will be terminated by the system. To determine if your app session was impacted by these constraints in the field, you can call `getDescription()` within `ApplicationExitInfo`. If the system applied a limit, the exit reason is reported as `REASON_OTHER` and the description string will contain "MemoryLimiter:AnonSwap". You can also leverage trigger-based profiling using `TRIGGER_TYPE_ANOMALY` to automatically capture heap dumps when the memory limit is reached. To learn more about per-app memory limits and system enforcement, review the Android 17 App Memory Limits documentation. To test your application on different device configurations use the Memory Limiter adb commands. ## Monitoring and Diagnosing Memory Issues You can't optimize what you can't measure. Identifying memory leaks, excessive heap allocations, and Out-Of-Memory (OOM) crashes across the Android ecosystem requires leveraging complementary monitoring tools: * **Macro-level health with Android vitals:** For broad, population-level visibility without additional overhead, Google Play Console’s Android vitals provides essential metrics like Memory Usage (Anonymous RSS + swap) and Bitmap Memory Usage. This gives you a clear snapshot of memory distribution across different process states (foreground, background, user-perceived services, and cached) and RAM class ranges, helping you spot memory outliers. * **Memory Limiter exits & OOM tracking with Firebase Crashlytics:** To stay informed about severe memory degradation before it impacts your key metrics, Crashlytics version 20.1.0 introduces additional debug data to help you catch, prioritize, and fix Out-Of-Memory exceptions and memory limiter kills. Tracking these events alongside custom logs and key-value metadata gives you immediate context into process status when a memory failure occurs. * **In-field traces with ProfilingManager:** For teams able to maintain a performance observability framework, the `ProfilingManager` API introduced in Android 15 (API level 35) allows your app to programmatically request and collect detailed memory debug artifacts such as Java heap dumps and heap profiles directly from production devices. You can also trigger heap dump captures based on specific system signals, such as `TRIGGER_TYPE_OOM` and `TRIGGER_TYPE_ANOMALY`. Read our documentation to learn more about other memory monitoring techniques. ## Summary & What's Next With Android broadening per-app memory limits across all RAM classes, now is the time to audit your memory footprint: 1. **Prioritize memory optimizations:** Prevent your app from being impacted by app memory limits by using best practices. 2. **Monitor memory use:** Monitor your app’s memory behavior to detect and resolve anomalous behavior. 3. **Optimize your game:** Follow the latest guidance for games and complex multimedia apps to maximize memory savings across process states. ## Helpful Resources & References * Android 17 Behavior Changes: App Memory Limits * Android Vitals: Memory Usage (RSS + swap metric) and Bitmap Memory Usage * Android Developers Blog: Prioritizing memory efficiency steps for Android 17 * Developer Guide: Manage your app’s memory

_Posted by Ajesh R Pai, Developer Relations Engineer, Ulises Uriel Verduzco Diaz, Software Engineer, Tinder, and Tracy Agyemang, Product Marketing Manager_ _ _ Tinder is on a mission to power and inspire real connections by making meeting easy and fun for every new generation of singles. However, as their Android application codebase grew in size, so did its complexity. Prior to their latest optimization efforts, approximately 70% of the application was not optimized, carrying 17 dex files,including three dedicated just to startup. Although they had enabled R8, much of its optimization potential was blocked due to keep rules, and the team was unable to identify which specific rules were preventing optimization. To reduce startup time and decrease user-perceived Application Not Responding (ANR) errors, Tinder turned to the new R8 Configuration Analyzer to tackle these challenges. By utilizing the R8 Configuration Analyzer, Tinder successfully identified and removed unintentional optimization blockers. The results were immediate and impactful: Tinder achieved a 47% reduction in app cold starts, shrank their app download size by 28.98% (down to 61.5 MB), and reduced user-perceived ANRs by 28%. ## Configuration analyzer The R8 Configuration Analyzer shows R8 optimization by tracking shrinking, optimization, and obfuscation scores to show available refinement areas. It shows the broad, redundant, or obsolete keep rules, including those from external libraries so that you can analyse the keep rule impact and refine the keep rules. Key metrics shown in Configuration Analyzer include: * **Shrinking Score:** Code percentage available for R8 shrinking. * **Optimization Score:** Code percentage open to optimization (for example, method inlining, horizontal class merging). * **Obfuscation Score:** Percentage of classes, methods and fields that can be renamed by R8 to decrease size. Use the analyzer to audit keep rules and their impacts: * **Find broad rules:** Narrow the scope of package-wide rules that restrict R8 optimization, and identify the specific classes, methods, and fields excluded from shrinking, optimization, and obfuscation. * **Refine rules:** Target only specific classes/methods requiring reflection to unlock optimization * **Remove redundant rules:** Remove rules that match zero classes, methods, or fields in your current build. * **Identical rules:** Identical keep rules means rules that target the same classes, fields, and methods or duplicate declarations of keep rule in same or across keep rule files. * **Find subsumed rules:** Clean up specific rules already covered by broader configurations. * **Identify problematic libraries:** Check the combined optimization impact of merged consumer keep rules from all libraries. R8 Configuration Analyzer report of a sample application To assist you in using the R8 Configuration Analyzer with agentic tools, we have published an R8 Analyzer skill. This skill optimizes automated development workflows by summarizing the R8 Configuration Analyzer report to display key metrics: optimization, obfuscation, and shrinking scores. It also highlights the five most impactful keep rules, giving you clear insight into what blocks code optimization. ## Pinpointing hidden optimization blockers Prior to integrating the R8 Configuration Analyzer, Tinder's Android app suffered from significant technical debt due to a heavily unoptimized codebase. This lack of optimization directly degraded the user experience, leading to users experiencing slow cold starts To resolve these issues, the Tinder team utilized the R8 Configuration Analyzer to comprehensively audit their R8 configuration. The analyzer showed the R8 optimization of the codebase was around 28% even with R8 full mode. With R8 Configuration Analyzer, Tinder identified that an in-house library was introducing a broad, unscoped keep rule. # Prevents optimization in all public classes along with all of their public and protected members -keep public class * { public protected *; } This "wide" rule unintentionally covered various dependencies across the entire app, preventing optimization in a large number of classes. Because the over-inclusive rule prevented runtime crashes, developers frequently missed adding new rules for new features that used reflection, allowing hidden issues to compound over time. By leveraging the insights provided by the R8 Configuration Analyzer, the team successfully traced and analyzed the specific classes affected by the broad keep rule from the library. The team immediately discovered that optimization was being blocked in larger, non-dynamically invoked classes where R8 could do optimization. Refining this specific keep rule allowed Tinder to unlock substantial optimization capabilities, untangle their legacy configurations, and drastically improve their overall optimization numbers, with R8 scores increasing from 28% to 50%, driving immediate performance gains across the application, and the Tinder team is actively working to further improve this figure. * **Faster Loading:** The team achieved a 47% reduction on users experiencing slow cold starts of the app. * **Smaller Footprint:** The App download size went from 86.6MB down to 61.5 MB (28.98% decrease). * **Improved Stability:** User-perceived Application Not Responding (ANR) errors decreased from 0.35% to 0.28%, bringing them significantly closer to the peer median numbers * **Reduced Complexity:** The total number of DEX files was cut down from 17 to 11, including just two startup files. Beyond these technical performance enhancements, the increased application optimization directly translated into tangible business growth and higher user engagement, particularly in resource-constrained markets. * **Regional Engagement:** Countries where Low RAM devices take a huge portion of the market, presented the largest increase in engagement, and decreasing the ANR rates was key to improving engagement in this vast market. * **Engagement Growth:** Engagement has increased 3% since the increase in app optimization. ## Safeguarding future performance with continuous integration Addressing code minification isn't just a one-time fix; it requires continuous vigilance. Inspired by the massive gains achieved through the R8 Configuration Analyzer, Tinder’s Android team proactively integrated optimization monitoring into their daily workflow to prevent regressions. Tinder’s team added a new job in their CI/CD pipeline to report changes in the optimization stats so everyone can see how their contribution is affecting optimization. When advising other developers considering R8 configuration integration, the team emphasizes the importance of auditing internal dependencies. While most popular third-party libraries come with well-defined rules, internal company projects that are considered "stable" might actually be introducing wide rules that negatively impact overall optimization. ## Key Takeaways Faced with a heavily unoptimized codebase and a high volume of DEX files, Tinder needed a way to cleanly audit their app’s minification rules. The R8 Configuration Analyzer provided the ideal tooling necessary to identify overly broad internal library rules, the classes affected by the keep rule, allowing the team to confidently optimize their codebase. As a result, Tinder successfully cut cold starts by nearly half, shrank their APK size by over 28%, and established a healthier, more performant foundation for their users, with the team actively working to further improve these numbers. ## How to Use R8 Configuration Analyzer The R8 Configuration Analyzer and its standalone features can be utilized based on your current Android Gradle Plugin (AGP) version: * **AGP 9.3 Release:** The R8 Configuration Analyzer is fully integrated and released with AGP 9.3. When running an R8 release build, the report will be generated in the `build/outputs/mapping/release/configanalyzer.html` folder. * **Standalone Gradle Task:** AGP 9.3 introduces a standalone Gradle task that allows you to generate the analyzer report without running a full release build, providing a much faster feedback loop when refining keep rules locally: ./gradlew :app:analyzeReleaseR8Config The report is generated at `build/reports/r8/r8-config-analyzer-release.html`. * **Usage on Older AGP Versions:** If you are using a version below AGP 9.3, you do not need to migrate your entire AGP version to analyze your configuration. You can update the R8 version independently to 9.3.7-dev or higher by following the Replacing R8 in AGP instructions. To generate the report locally, run your build with the property specified: ./gradlew assembleRelease -Dcom.android.tools.r8.dumpkeepradiushtmltodirectory=<output_directory> To learn more, see the R8 Configuration Analyzer documentation.

_Posted by Amy Zeppenfeld, Developer Relations Engineer, Greg Underwood, Software Engineering Manager, Yasmine Evjen, Senior Product Manager, Android XR_ _ _ Since introducing the Android XR SDK, developers have transformed their ideas into innovative, immersive experiences for XR headsets and wired XR glasses. As the ecosystem expands, you can more easily take those experiences from preview to production and reach users wherever they are. Today, we're excited to announce that **Jetpack SceneCore** , **ARCore for Jetpack XR** , and **XR Runtime** have reached beta with **Jetpack Compose for XR** to follow soon! This means the APIs are stabilizing, making it a great time to start integrating them into your production workflows and creating for Android XR. ### Why the Jetpack XR SDK? The Jetpack XR SDK includes all the tools and libraries you need to build immersive and augmented experiences for Android XR. Whether you're porting an existing 2D app or creating a new 3D XR app from scratch, you can do so using the familiar Android development tools you already know and love. To support your development, this release focuses on providing the fundamental building blocks across the SDK: * **Jetpack SceneCore:** Build and manipulate the Android XR scene graph with 3D content. You can arrange 3D models, play spatial audio, and use the robust entity-component system to create, control, and manage entities. * **ARCore for Jetpack XR:** Bring digital content into the real world with perception capabilities. This library powers depth estimation, persistent anchors, hit testing, and plane identification. * **XR Runtime:** Provides the essential runtime foundation of the SDK, handling device lifecycles, session creation, and system configurations that enable the API surface. * **Jetpack Compose for XR:** Create spatial UI layouts that take advantage of Android XR’s spatial capabilities. This library lets you use familiar Compose concepts to create spatial UIs and will be reaching Beta soon. ### What's new in Beta? Direct feedback from the developer previews helped shape these beta releases, introducing several important API refinements to ensure these libraries are ready for production. * **Expanded testing support:** New capabilities are now available across the immersive XR libraries, including testing for spatial audio, XR devices, and session configuration. See the release notes for each library for details. * **Kotlin coroutines support:** To better align with Kotlin coroutines, Session.create is now a suspend function. * **Terminology and class updates:** AnchorEntity has been renamed to AnchorSpace, and both ActivitySpace and AnchorSpace now extend a common SpaceEntity class for more consistent spatial management across scenes. See the full release notes for each library to check out specific details on naming and API changes. ### Get started and provide feedback To add these dependencies, include the Google Maven repository in your project and add the newest XR libraries to your build.gradle files. dependencies {     implementation("androidx.xr.scenecore:scenecore:1.0.0-beta02")     implementation("androidx.xr.arcore:arcore:1.0.0-beta02")     implementation("androidx.xr.runtime:runtime:1.0.0-beta02")     implementation("androidx.xr.compose:compose:1.0.0-alpha17") } The ecosystem of Android XR devices that power immersive experiences is expanding, ranging from XR headsets to wired XR glasses. There’s never been a better time to start building immersive experiences with the Jetpack XR SDK Beta. Dive in and start building and testing on Samsung Galaxy XR or Android XR Emulator today.

_Posted by Fahd Imtiaz, Senior Product Manager, Loryn Hairston, Product Marketing Manager, and Tracy Agyemang, Product Marketing Manager, Android Developer_ _ _ Made by Google expands what's possible across the Android ecosystem. With the introduction of the Pixel 11 Pro Fold, Pixel Watch 5, and the entire Pixel family, users are moving seamlessly across diverse screen sizes, unique postures, and intelligent experiences. For you, the developer, this represents a massive opportunity: foldable users spend about 14x more than standard phone users. To help you elevate your existing experience without starting from scratch, we’re sharing our latest platform guidance alongside real-world examples from developers already putting these features into production. ## Deliver adaptive experiences across foldables and expanded displays The Pixel 11 Pro Fold gives your app a chance to flex its capabilities with an expanded inner display and a standard size outer screen. Building for the foldable form factor requires dropping hardcoded layout rules and designing around available window space. Leveraging Jetpack Compose APIs like Navigation 3 with Scene strategies or our newest layout APIs like Grid and FlexBox allows your layout containers to automatically wrap, span, and reflow. You can also use the experimental MediaQuery API to dynamically adapt your UI to environmental signals like foldable posture, and keyboard states. Building adaptively requires tracking actual app dimensions rather than physical device size, especially during split-screen and multitasking flows. Using Window Size Classes from the WindowManager library allows your layout to respect folds and hinges as natural content separators. For instance, Notability leveraged Material 3 Window Size Classes to create a responsive two-pane layout that transitions smoothly between folded and expanded screens. As Ryan Shea, Android Engineering Manager at Notability, shared, tracking the window itself allows their layout and canvas zoom to ensure notes stay fit to the page through every fold, rotation, or split-screen resize, noting that they wanted the app "to feel native at every size, not just stretched to fit." Notability’s quiz UI adapted for expanded screens Ensuring these transitions feel seamless also requires state preservation across configuration changes. Using ViewModel retains UI state so interactions like scroll position, form inputs, and open dialogs remain uninterrupted when transitioning between inner and outer screens. Taking this approach, Flo Health used Jetpack Compose state primitives, ViewModel, and Window Size Classes to make their highest-traffic user journeys resilient to rotation, fold/unfold and resizing transitions. As Aleksandr Kolodiazhnyi, Senior Android Engineer at Flo Health, shared, “Android's adaptive guidance turned what looked like a major refactor into a templated rollout," allowing them to adopt Compose primitives without a rewrite, "cutting [their] state-preservation code by roughly 30% while fixing lifecycle and analytics correctness issues that improved the app on every form factor." To take full advantage of the foldable form factor, leverage FoldingFeature updates to trigger posture-specific layouts. When a user partially folds their device into tabletop posture, you can split your UI automatically by placing primary controls on the lower display and main content or viewfinders on the upper display. Handling camera previews across foldable state changes, requires managing orientation shifts carefully. Migrating to the CameraX library ensures automatic handling of sensor rotation and display scaling across screens, while existing Camera2 codebases can also achieve stability using the CameraViewfinder library. These camera and display capabilities allow you to power dual-screen previewing and high-resolution rear camera selfies with minimal custom logic. Prepare your app for these form factors today by exploring our complete adaptive development guidance at Build adaptive apps. ## Bring delightful, gesture-driven experiences to the wrist The new Pixel Watch 5 is here, and we’ve optimized it to take advantage of the intelligent, power-efficient, touch-free convenience of Wear OS 7. Thanks to system-wide performance optimizations and a collection of new features built to help users complete tasks efficiently, you can provide rich experiences that require only a single user action to complete. The one-handed gestures framework provides a convenient way for users to interact with their watches without needing to touch the screen with their opposite hand. Starting with the 1.7 beta release of Compose for Wear OS 7, you can seamlessly integrate one-handed gesture control into your Wear Compose apps with simple physical inputs on the watch-wearing arm, like a double-pinch or wrist turn. Spotify is adopting this framework to make controlling media more effortless. By mapping Wear OS gesture events directly to the media player state, users will be able to pause or resume playback using a simple double-pinch, keeping music controls accessible even when their hands are full. Pause Spotify media with a pinch gesture Wear OS 7 also brings Live Updates directly to the wrist to surface real-time information like live sports scores, workout progress, and delivery status, which can also appear in the At-a-Glance surface on Pixel Watch 5. For example, Just Eat uses Live Updates to keep users informed on order arrival times at a glance. You can publish updates locally from your watch app or leverage phone notification bridging on supported devices to deliver real-time tracking across screens. Live Updates from Just Eat delivering real-time status and delivery ETAs at a glance You can also extend glanceable interactions across watch surfaces on Wear OS 7 by using Wear Widgets, powered by Jetpack Glance and RemoteCompose. Wear Widgets with Compose offer greater expressiveness and consistency than the old Tiles framework, and the two available widget layouts—small and large– align perfectly with the 2x1 and 2x2 formats on mobile, ensuring your designs feel cohesive across devices. On top of all these great new features, Wear OS 7 delivers up to a 10 percent improvement in battery life over Wear OS 6, making the Pixel Watch 5 a truly indispensable all-day companion for your users. To get started developing for Wear OS 7, use the new emulator, and check out all of our Wear OS resources and guidance at Build apps for the wrist with Wear OS. ## Unlock on-device intelligence with Gemini Nano 4 Pixel 11 devices are built to run Gemini Nano 4, bringing fast, responsive, on-device intelligence to the hardware. By running AI workflows directly on device, you can offer low-latency, real-time interactions that feel instant and integrated without needing round trips to the cloud. Through the ML Kit GenAI Prompt API, you can send natural language requests directly to Gemini Nano on device. The model supports over 140 languages, better multimodal understanding, and much more. Build intelligent on-device features using advanced capabilities like structured output and thinking mode. Build smart capabilities into your app using our self-service tools and Gemini models. ## Shape the next generation of experiences for the Pixel ecosystem today Made by Google showcases what's possible when hardware and software evolve together, and you are at the center of that innovation. You can begin optimizing your apps today by exploring our updated adaptive guidance, creating glanceable experiences for Wear OS 7, and integrating on-device AI with ML Kit. To help you implement these updates even faster, you can now leverage Android skills, which provide AI-optimized instructions for agents and tools. Whether you are using Gemini in Android Studio or running the Android CLI through other agents, Android skills give your AI tools the context needed to execute complex workflows automatically. For instance, you can prompt your agent with the CameraX skill to handle camera display scaling across foldables, or use the Adaptive skill to set up dynamic Compose layouts without additional manual work. Take advantage of these new surfaces, accelerate your workflow with agentic tools, and share your latest builds with the Android community! Head over to developer.android.com to access full documentation, explore the Android skills GitHub repository, and start building today.

_Posted by Chiara Chiappini, Developer Relation Engineer, Android Developer Relations_ One-handed gestures offer a convenient and touch-free way for users to interact with their watches, enabling them to perform key actions using only the hand on which the device is worn. First introduced on Pixel Watch with Wear OS 6.1, one-handed gestures made quick interactions effortless, such as starting and stopping a timer, accepting calls, and controlling media. Now, with Wear OS 7, we're expanding this functionality with a new Gestures framework that allows OEMs to map gestures to primary actions and dismissals, and an API to bring gesture control to the developer community. Starting with the 1.7 beta release of Compose for Wear OS, you can seamlessly integrate gesture control into your Wear Compose apps. To use this release, upgrade your Wear Compose dependency to: androidx.wear.compose:compose-material3:1.7.0-beta01 ### Designing for one-handed interaction The one-handed gestures framework is designed around two primary interaction patterns that allow users to take action without touching the screen: * Primary action, which on Pixel Watch is mapped to a double-pinch gesture: this action should be mapped to the most important task in a given context. For example, users can perform this gesture to take a photo in a camera app, start/stop a timer, or accept an incoming call. * Dismiss action, which on Pixel Watch is mapped to a wrist turn gesture: this action is mapped to system back by default and provides an intuitive way to close interruptive screens or get back to the watch face. It may be overridden for specific use cases, such as silencing an incoming phone call. These gestures are currently available on Pixel Watch 3 and newer, and the Wear OS gesture framework is available to all Wear OS device manufactures to adopt. Check out our new design guidance for integrating one-handed gestures into your Wear app. ### Integrating gestures with Compose on Wear OS To provide seamless gesture support in Wear OS 7, we are introducing a new Modifier.oneHandedGesture that you can apply to any existing interactive composable to make it gesture-aware. Implementing gestures with Compose on Wear OS requires these steps: 1. Define the gesture configuration. Start by using `rememberOneHandedGestureConfiguration` to define the nature of the interaction. This configuration dictates the basic behavior by providing the `GestureAction` (e.g. tracking a primary pinch or a dismiss wrist flick). 2. Initialize the indicator state. Depending on your UI component, initialize a specific state object, such as `OneHandedGestureClickIndicatorState` for buttons or `OneHandedGestureScrollIndicatorState` for scrollable lists. This state is used to coordinate visual feedback between the gesture detection modifier and the visual UI indicators, seamlessly managing visibility, timing, and animations. 3. Apply Modifier.oneHandedGesture to your interactive component. You'll pass in your configuration and state, and you’ll provide standard callbacks: `onGestureAvailable` to activate the visual hint when the system prepares the gesture, and `onGesture` to execute your action when the gesture happens. The following sample shows how those three steps translate into code when configuring an `IconButton`: val gestureConfig = rememberOneHandedGestureConfiguration(action = OneHandedGestureAction.Primary) val indicatorState = remember { OneHandedGestureClickIndicatorState() } val coroutineScope = rememberCoroutineScope() OutlinedIconButton(     onClick = onPlayPauseButtonClicked,     modifier = Modifier.touchTargetAwareSize(IconButtonDefaults.LargeButtonSize)         .oneHandedGesture(             gestureConfiguration = gestureConfig,             interactionSource = interactionSource,             onGestureLabel = "play or pause",             onGestureAvailable = {                  coroutineScope.launch { indicatorState.showIndicator() }              },             onGesture = onPlayPauseButtonClicked,         ), ) {     // button content goes here     // See "Guided discovery with gesture indicators" section of this post for recommendations on adding a gesture indicator. } The `GestureAction.Primary` can also be used to scroll when the content is the end goal of the user journey, or there is a gesture actionable button off screen that the user can scroll to. Some examples include: * Scrolling through a notification to view the content and/or initiate a reply (available in `TransformingLazyColumn` and `ScalingLazyColumn`). * Paging through workout metrics or other content that doesn’t require the user to tap to continue the user journey (available in `HorizontalPager` and `VerticalPager`). val scrollGestureConfig = rememberOneHandedGestureConfiguration(action = GestureAction.Primary) val scrollIndicatorState = remember { OneHandedGestureScrollIndicatorState() } val coroutineScope = rememberCoroutineScope() TransformingLazyColumn(     state = scrollState,     contentPadding = contentPadding,     modifier = Modifier         .fillMaxSize()         .oneHandedGesture(             gestureConfiguration = scrollGestureConfig,             onGestureLabel = "scroll",             onGestureAvailable = {                  coroutineScope.launch { scrollIndicatorState.showIndicator() }              },             onGesture = { OneHandedGestureDefaults.scrollDown(scrollState) }         ) ) {     // list content goes here     // See "Guided discovery with gesture indicators" section of this post for recommendations on adding a gesture indicator. } ### Guided discovery with gesture indicators To help users learn which gestures are available, gesture indicators work as hints to help discovery about which gestures are available on a screen. These hints provide animated cues that inform users where they can perform a gesture. The framework manages the cadence and appearance of these hints, ensuring that they are helpful without being intrusive. System settings let users change the cadence to something less frequent if desired. To integrate with hints, the API provides the following gesture indicator components: * the OneHandedGestureClickIndicator for components like a `Button` * the OneHandedGestureScrollIndicator component for scrolling * the OneHandedGestureHorizontalPageIndicator for the `HorizontalPager` * the OneHandedGestureVerticalPageIndicator for the `VerticalPager` The following example shows how to use the `OneHandedGestureClickIndicator` for a `Button`. See another example for using the OneHandedGestureScrollIndicator in our guidance. val gestureConfig = rememberOneHandedGestureConfiguration(action = GestureAction.Primary) val indicatorState = remember { OneHandedGestureClickIndicatorState() } val coroutineScope = rememberCoroutineScope() OutlinedIconButton(     onClick = onPlayPauseButtonClicked,     modifier = Modifier.touchTargetAwareSize(IconButtonDefaults.LargeButtonSize)         .oneHandedGesture(             gestureConfiguration = gestureConfig,             interactionSource = interactionSource,             onGestureLabel = "play or pause",             onGestureAvailable = {                  coroutineScope.launch { indicatorState.showIndicator() }              },             onGesture = onPlayPauseButtonClicked,         ), ) {     OneHandedGestureClickIndicator(         gestureConfiguration = gestureConfig,         indicatorState = indicatorState,     ) {         val icon = if (playerUiModel.playbackState.isPlaying) Icons.Filled.Pause else Icons.Filled.PlayArrow         Icon(icon, contentDescription = "Play or Pause")     } } Sample app showing gesture hint for media controls We are already seeing early adoption of these APIs from partners like Spotify, who are using one-handed gestures to make music control more seamless on the go. By adopting the `Modifier.oneHandedGesture` into their Wear OS app, Spotify allows users to play or pause their music with the primary gesture action, which on Pixel Watch devices is the double-pinch gesture. This action triggers the same behavior as the physical play/pause button, and the user doesn’t need to touch the screen. . Spotify app with gesture integration ### Bring one-handed gestures to your app You can begin experimenting with one-handed gestures today in the 1.7 beta release of Compose for Wear OS. Ensure your app is running on Wear OS 7, which provides the underlying platform support for gesture detection. Check out our new one-handed gestures developer guide to see how you can start building more convenient experiences for your users.

_Posted by Nick Butcher, Product Manager, Jetpack Compose_ Today, the Jetpack Compose August ‘26 release is stable! This release brings version 1.12 across core Compose modules (see the full BOM mapping), introducing rich visual APIs like Mesh Gradients and Wide Color Gamut (WCG) support, structural layout features like named areas in Grid, seamless integration with Android’s Credential Manager, and significant testing and performance improvements. To update your project to today’s release, upgrade your Compose BOM version to `2026.08.00`: implementation(platform("androidx.compose:compose-bom:2026.08.00")) ## Breaking Changes AGP & Compile SDK: Compose 1.12 updates `compileSdk` to API 37, requiring a minimum AGP 9.2.0. As a reminder, Compose will always target the latest `compileSdk`. Learn more about this change here. `Modifier.onFirstVisible()` is deprecated: Migrate to `Modifier.onVisibilityChanged()`, which provides more precise visibility threshold tracking. ### Graphics ## Mesh Gradients Compose 1.12 introduces `MeshGradientPainter` to help you create multi-point, organic color gradients. val rows = 1 val columns = 1 val gradientPainter = remember { MeshGradientPainter(rows, columns) { // Parameters: row, column, position, color setVertex(0, 0, Offset(0f, 0f), Color.Red) // Top-Left setVertex(0, 1, Offset(1f, 0f), Color.Blue) // Top-Right setVertex(1, 0, Offset(0f, 1f), Color.Green) // Bottom-Left setVertex(1, 1, Offset(1f, 1f), Color.Yellow) // Bottom-Right } } Box( modifier = modifier .aspectRatio(16/9f) .fillMaxWidth() .paint(gradientPainter) ) For more information and examples, see the documentation. ## Wide Color Gamut & HDR Support Modern displays offer extended color fidelity and higher dynamic range. In Compose 1.12, full pipeline support for **Wide Color Gamut (P3)** and **HDR rendering** has been enabled across Compose graphics, paint, and shaders. Colors defined in non-sRGB color spaces (such as Display P3) are preserved through to platform rendering without color clamping. Colors will safely fall back to sRGB if they use an unsupported color space (e.g. CieXyz, CieLab, or Oklab), rely on a color space on an unsupported Android version (e.g Bt2020Hlg on Android 13 and below), or if the app is running on Android 9 (API 28) and below. Other notable changes: * `LayerOutsets` was added to `GraphicsLayer` & `Modifier.graphicsLayer`, which you can use to increase the visual bounds of the layer beyond its measured size. Apply `LayerOutsets` to avoid the implicit `clipToBounds` behavior when the layer is promoted to an offscreen buffer. ### Styles At Google I/O, we shared our early vision for the Compose Styles API—a unified, performant way to style components. Since then, we have continued building the underlying architecture to guarantee strict type safety and predictable correctness, and to support building custom design systems. To ensure we get this foundational layer correct, the API will remain experimental, and you can expect breaking changes. ### Runtime Optimizations ## Keyed SideEffect Overload `SideEffect` now supports key arguments, which lets you fire one-shot side effects whenever specific keys change. This can lead to better performance compared to using a `LaunchedEffect` or `DisposableEffect` when you don’t need the coroutine or dispose block. `SideEffect` is up to 90% faster than `LaunchedEffect` and around 20% faster than `DisposableEffect`. Note that `SideEffect` runs its effect before `DisposableEffect` and `LaunchedEffect`, so use caution if migrating existing effects to this API, especially for `LaunchedEffects` that rely on being dispatched to start after the current frame is completed. @Composable fun AnalyticsTracker(userId: String, screenName: String) { SideEffect(key1 = userId, key2 = screenName) { analytics.logScreenView(userId, screenName) } } ### Animation `DeferredTargetAnimation` has graduated out of experimental status. ## Interactive Two-Stage Transitions New composables: `DeferredAnimatedContent` and `DeferredAnimatedVisibility` allow creating delightful two-stage transitions, e.g. for predictive back gesture tracking. Manual animation control: During a transition's deferred phase, animated properties (like scale or offset) can now be manually manipulated in real-time (e.g., tracking a swipe gesture). Seamless handoff: Once the deferred phase ends, the transition engine takes over and performs a seamless handoff, including velocity transfer, to the automatic transition. Shared element support: A new `permitTransformDuringDeferredTransition` flag in `SharedContentConfig` controls whether shared elements visually transform along with their parent containers during the deferred transition phase. val state = remember { DeferredTransitionState(initialScreen) } val transition = rememberDeferredTransition(state) if (predictiveBackInProgress) { state.defer(targetScreen) } else { state.animateTo(targetScreen) } transition.DeferredAnimatedContent( targetState = targetScreen, mutableTransformSpec = { MutableContentTransform { // Manually manipulate properties during the deferred phase initialContentTransform { scale = swipeProgress } } } ) { screen -> ScreenContent(screen) } Below are two demos of use cases where a gesture-driven animation is handed off to a triggered animation: ### Text, Input & Platform Integrations ## Editable Text Formatting New APIs offer rich-text formatting for editable text in `BasicTextField`. You can now programmatically apply and manipulate inline character and paragraph formatting using `SpanStyle` and `ParagraphStyle` via the new `addStyle()` method inside a `TextFieldBuffer` scope (such as inside `textFieldState.edit { ... }` or an `InputTransformation`). Additionally, `TextFieldBuffer` provides `getSpanStyles()` and `getParagraphStyles()` APIs that return `TrackedRange` objects, allowing you to read, update, or remove applied styles. To complement formatting creation, `TextFieldState` now exposes a read-only `textStyles` property for querying active styles across ranges, while `TextFieldBuffer` provides `originalTextStyles` to inspect formatting state prior to an edit. Text formatting and custom annotations are persisted across configuration changes. val state = rememberTextFieldState("Formatted text in Compose 1.12") // Apply bold and color styles to a range of text state.edit { addStyle( SpanStyle(fontWeight = FontWeight.Bold, color = Color.Blue), start = 0, end = 9 ) } // Query active styles from TextFieldState val currentStyles = state.textStyles ## Text Selection A new `SelectionState` API provides programmatic control and observability over text selection within a `SelectionContainer`. Hoisting a `SelectionState` object via `rememberSelectionState()` and passing into `SelectionContainer` exposes `selectedTexts` as a reactive list of `AnnotatedStrings` and provides methods like `selectAll()`, `clear()`, `select(TextRange)`, and `extendSelectionByWord()`. Additionally, use `getSelectableTexts()` to retrieve all selectable text items in layout order and select text across composables in the `SelectionContainer` using a global range. @Composable fun ProgrammaticSelectionExample() { val selectionState = rememberSelectionState() Column { Button( onClick = { selectionState.selectAll() }, modifier = Modifier.disableSelectionClearOnTap() ) { Text("Select All") } SelectionContainer(state = selectionState) { Text("Text content to be selected programmatically.") } } } ## Credential Manager Integration Compose text fields now natively integrate with Android’s Credential Manager (API 34+) via the Autofill framework (below API 34 is handled by `androidx.credentialslibrary`). By attaching the new `credentialRequest` semantics property with `CredentialRequestData`, text inputs can prompt passkeys, saved credentials, or sign-in requests directly within the user input flow. @Composable fun LoginField(textFieldState: TextFieldState) { val credentialData = remember { CredentialRequestData( // Specify Credential Manager request options ) } BasicTextField( state = textFieldState, modifier = Modifier.semantics { credentialRequest = credentialData } ) } Other notable changes: * Support for font variation settings in downloadable fonts. * Enabled auto-scrolling when dragging text selection beyond the viewport in `SelectionContainer`. * Added support for automatic interaction sounds (clicks and focus navigation) to Compose components, with a new `SoundEffectOnInteraction` composable to allow opt-out. Note that as a consequence of this change, semantics click listeners must now be called from the main thread, which may affect a small number of test cases. * `KeyboardType` now includes `Date`, `Time`, `DateTime`, and `SignedDecimal`. * `BasicSecureTextField` now uses `TextObfuscationMode.System` by default, while `RevealLastTyped` serves as an absolute override. ### Layout Enhancements ## Named Areas in Grid Layout Building complex 2D layouts is now easier with named areas in the `@Experimental` Grid component. Rather than managing numeric column and row indices across items, you can define semantic regions in your `GridConfigurationScope` and position composables by area name. @OptIn(ExperimentalGridApi::class) @Composable fun DashboardLayout() { Grid( config = { area("header", row = 0, column = 0, rowSpan = 1, columnSpan = 2) area("sidebar", row = 1, column = 0) area("content", row = 1, column = 1) gap(16.dp) } ) { HeaderSection(modifier = Modifier.gridItem(areaId = "header")) NavigationSidebar(modifier = Modifier.gridItem(areaId = "sidebar")) MainContentView(modifier = Modifier.gridItem(areaId = "content")) } } ### Performance As with every release, we continue to invest in Compose's performance to ensure that the framework helps you to build beautiful, performant apps. In this release we've focused on improving startup performance and are now seeing Time to Initial Display (the time it takes for an app to produce its first frame) that is comparable to Views in our benchmarks. ### Testing & Tooling Upgrades ## Test Synchronization Compose 1.12 introduces new test APIs designed to reduce test execution times and eliminate flakiness during state sampling: * `hasPendingWork:` Passively checks if the UI has pending work without advancing the clock, which is ideal for manual animation loops. * `runWithoutImplicitWait:` Temporarily disables implicit synchronization when stepping through manual clock frames (e.g. animation tests). @Test fun testAnimationStateFast() { composeTestRule.mainClock.autoAdvance = false while (composeTestRule.hasPendingWork()) { composeTestRule.mainClock.advanceTimeByFrame() composeTestRule.waitForIdle() composeTestRule.runOnUiThread { composeTestRule.runWithoutImplicitWait { // This is most effective when querying multiple nodes in a single frame. // It prevents the redundant synchronization overhead that would // otherwise occur on every individual query. val box1 = composeTestRule.onNodeWithTag("Box1").fetchSemanticsNode() val box2 = composeTestRule.onNodeWithTag("Box2").fetchSemanticsNode() assertThat(box1.boundsInRoot.right).isAtMost(box2.boundsInRoot.left) } } } } Other notable changes: * The `captureToImage` API now allows you to capture a popup or dialog together with its anchor in a single bitmap. * Added `onRootWithViewInteraction` to scope Compose semantic searches to specific Android Views. This simplifies testing hybrid UIs, such as RecyclerViews, without requiring unique test tags in production code. * `@PreviewWrapper` annotations can now be applied to custom `@MultiPreview` classes, enabling reusable preview setups (such as custom themes) across multiple components. ### Happy Composing! Compose 1.12 makes app development easier and more expressive than ever, with mesh gradients, wide color gamut support, downloadable variable fonts, Credential Manager integration, and faster testing tools. As always, we value your input, so please share your feedback on these changes or what you'd like to see next on our issue tracker. Happy composing!

_Posted by Toni Heidenreich, Software Engineer, Android_ _ _ Media3 1.11 is out. Powering the vast majority of top Android media apps, this release brings new features, bug fixes, and improvements across playback, editing, and UI components. We're expanding our Jetpack Compose UI modules with customizable `Player` slots and easy to use defaults, interactive gestures, state observers, and short-form video preloading using `PlayerPool`. We also modernized the Media3 Cast integration with SystemUI Output Switcher support, introduced a new Ktor HTTP client network extension, and added new muxing utilities for Ogg and WAV files. Read on for key highlights, and check out the full release notes for a comprehensive list of changes. ## Playback UI and Compose With Android becoming Compose-first, we are continuing to expand the `media3-ui-compose` and `media3-ui-compose-material3` modules. This update introduces more granular control over your player layout, richer interaction patterns, and deeper integration with Material3. ### Customizable Player layout The Material 3 Player Composable now supports dedicated content slots for `topControls`, `centerControls`, `bottomControls`, and `errorOverlay`. You can drop in your own Composables or use the ready-made defaults published in `PlayerDefaults`: Player( player = player, topControls = { PlayerDefaults.TopControls(player) }, centerControls = { PlayerDefaults.CenterControls(player) }, bottomControls = { PlayerDefaults.BottomControls(player) }, ) The `Player` Composable also integrates `FocusRequester` support, enabling seamless D-pad and keyboard navigation on Android TV, foldables, and desktop environments. large-screen devices. Example for a Composable Player with customized controls ### Gestures and playback speed control `PlaybackSpeedState` now provides a fast-forward/slow-motion API. The demo-compose app showcases this with a long-press gesture to fast-forward playback and seeking with double tap. Combined with the `ProgressSlider` introduced in 1.10, the Compose player UI now offers rich touch and gesture interactions out of the box. ### Short-form video preloading with PlayerPool For apps with sliding-window media feeds (for example, short-form vertical video), managing multiple ExoPlayer instances efficiently is a common challenge. Media3 1.11 introduces `PlayerPool` (in `common-ktx`) and `rememberPooledPlayer` (in `ui-compose`) to handle player recycling and preloading automatically. The new `ShortFormPlayerScreen` in `demo-compose` shows this in action, a vertically paging feed where players are pooled, preloaded, and seamlessly recycled as the user scrolls. ### MiniController A new `MiniController` Composable in `media3-ui-compose-material3` provides a compact playback bar displaying the current item's title, artist, artwork, and progress alongside play/pause controls. As all our default Composables in `media3-ui-compose-material3`, the `MiniController` supports Material3 Dynamic Color integration, allowing it to automatically adapt to the user's wallpaper theme.This is ideal for persistent bottom-sheet or mini-player affordances, for example while the user browses content or during active Cast sessions. The Media3 MiniController showing album art, media metadata and basic controls ### Expanded state holders for metadata and errors We added several new reactive state holders to `media3-ui-compose`: * `rememberCurrentMediaItemState` – observe metadata about the currently playing item * `rememberPlaylistState` – observe the full playlist and active indices * `rememberErrorState` – track playback errors, with a matching `ErrorText` Composable and default `ErrorOverlay` in Material3 We'll continue working on new additions and more customization options in upcoming releases. Please share your thoughts on the project issue tracker. ## Modernized Cast integration Media3 1.11 updates the Cast extension with programmatic configuration options and support for OS-level routing. ### CastParams and SystemUI Output Switcher You can now configure the Cast extension using `CastParams`: val castParams = CastParams.Builder() .setShowSystemOutputSwitcherOnCastButtonClick(true) .build() Cast.getSingletonInstance(context).initialize(castParams) Setting `setShowSystemOutputSwitcherOnCastIconClick(true)` configures the `MediaRouteButton` to open Android's native SystemUI Output Switcher on supported platform versions, providing a unified output picker experience. ### Reactive MediaRouteButton state in Compose Apps using Jetpack Compose can now easily add the Media routing button (also known as Cast button), which automatically observes the dialog state and updates accordingly. No further logic needed when used together with Media3's `CastPlayer`! @Composable fun TopAppBarWithCast() { Row { Text(text = "App Title") MediaRouteButton() } } Media3 media route button in an app launching the default output switcher dialog ## Core playback and session enhancements ### Eclipsa Video - HAGC dynamic HDR metadata (API 37+) Eclipsa Video promises a more consistent HDR experience across devices, with a consistent baseline HDR white, adaptive headroom depending on the screen and the surroundings, ensuring the creative intent is preserved on all devices. ExoPlayer now supports playback of the necessary HAGC (ST 2094-50) timed metadata for progressive media (MP4, Matroska). The player automatically merges HAGC metadata tracks with the associated video track and delivers the metadata out-of-band to the decoder on API 37+ devices. On older devices, ExoPlayer seamlessly falls back to providing a standard HDR playback experience without the adjustments. Illustration to show benefits of Eclipsa Video HDR, like more consistent color contract ### New Ktor HTTP client extension A new `media3-datasource-ktor` extension module provides `KtorDataSource`, backed by the Ktor HTTP stack. This offers a Kotlin-first, coroutine-friendly alternative to the existing Cronet and OkHttp data source modules. ### Asynchronous MediaSession connections `MediaSession.Callback` now includes `onConnectAsync()`, which lets you process controller connection attempts asynchronously — for example, to verify authorization before accepting a connection. You can return an immediate Future with `Futures.immediateFuture(ConnectionResult)` for the same behavior as the existing `onConnect`. override fun onConnectAsync( session: MediaSession, controller: MediaSession.ControllerInfo ): ListenableFuture<MediaSession.ConnectionResult> { return authenticateControllerAsync(controller) } ### Safer MediaSession defaults For apps that don’t override `onConnect` or `onConnectAsync` in `MediaSession.Callback`, the library now defaults to a more secure configuration. Specifically, session data is no longer shared by default with untrusted controllers, meaning third-party or non-system apps lacking notification access are restricted from accessing session data unless you explicitly implement these callback methods to authorize the connection. ## New Muxer implementations & container parsing ### OggMuxer and WavMuxer We've added two new dedicated muxers: `OggMuxer` for muxing OPUS and VORBIS streams into standard .ogg files, and `WavMuxer` for generating uncompressed and floating-point PCM .wav audio files. ### Container parsing and track references * MP4 Track References (tref): `Mp4Muxer.addTrackReference` allows linking dependent metadata or aux tracks to primary video streams. * Chapter Extraction: QuickTime and Nero chapter from MP4 files (.m4a, .m4b), and Matroska chapters, are now extracted as Chapter metadata entries for audiobook and podcast navigation. Please use the issue tracker to report any bugs, or if you have questions or feature requests. We look forward to hearing from you!

_Posted by Jose Alcérreca, Developer Relations Engineer, Android Developer Relations_ We released the official Android Skills in April, and the response surpassed all our expectations. In this blog post, I'll address some of the feedback we received, explaining the philosophy and methodology behind the project. Hopefully, this will also help you understand what happens behind the scenes when you install and use skills, allowing you to make better use of tokens and your own time. ## Why are there so few official skills? Currently, we only consider new skills when there's a verifiable knowledge gap in state-of-the-art (SOTA) models. Put simply: you don't need to teach the model what it already knows. (Though there are a few exceptions—read on!) We’ve released around 20 official skills so far, and they intentionally target highly specific, fast-moving areas that standard models aren't fully grounded on yet—things like AGP 9, Navigation 3, advanced Camera APIs, and Perfetto SQL. What about core, more general, skills? Every installed skill injects 100–200 tokens into the baseline context of every task you start. If that skill actually activates, that count can quickly jump into the thousands. In most cases, hoarding basic skills is both counterproductive and expensive. Before installing a skill for writing basic Kotlin or Compose, consider if your LLM of choice really needs it, or if it knows those topics well enough already. ## Evaluating skills Before their release, each skill is tested against a comprehensive set of evals that prove that the skill delivers clear value. These evals should pass when the skill is active, and fail otherwise. Evals are to skills what integration tests are to code. timeout_s: 1200 repository: url: [redacted - internal git repo] working_dir: wear_compose_m3_empty_app category_ids: - wear prompt: |- Add a horizontal pager to MainActivity.kt. Have three pages in the pager. Each page should contain the text "Page 1", "Page 2", and "Page 3" respectively in the center of the screen. commands: build: - ./gradlew assembleDebug acceptance_criteria: project_builds: true llm_diff_judge: - Must use `HorizontalPagerScaffold`. - Each page should use `AnimatedPage` to wrap a `ScreenScaffold`. _Example eval that checks the correct implementation of a horizontal pager on a wear app_ At a minimum, we test the skill in Android Studio using the latest Gemini Flash model. Depending on the skill, we also ensure compatibility with other models such as Gemini Pro and other agents such as Antigravity, and third-party systems. All of the evals run with access to the Knowledge Base, so if the information is in the documentation, and models decide to search for it, we don't publish a skill for it. ## Using the Android Knowledge Base (Android Studio or Android CLI) If you develop Android apps, you should always use the Android Knowledge Base to have access to the official documentation. If you use the agent in Android Studio, it's already available as a tool, but if you use another agent, install Android CLI. Among other things, it contains the docs command, which gives your agent access to the official Android documentation. Having a single tool is much more efficient than installing hundreds of skills. If your model is acting overconfident, and you want it to consult the documentation more often, a very common way to motivate it is to add "Always consult the official Android documentation when dealing with Android APIs" to your AGENTS.md file or equivalent. Of course, you can also force this by asking the agent to check the documentation directly in your prompts. ## Why are pull requests disabled? Because our evaluation framework depends on internal infrastructure that cannot be open-sourced, we are unable to accept direct pull requests for new skills—without this infrastructure, we would have no way to re-evaluate incoming PR changes. However, we actively monitor community feedback. If you want to report a bug, suggest an optimization, or request a new official skill, please file an issue! ## When do core or basic skills make sense? While SOTA models generally don't need basic skills, there are some scenarios where enabling core or community-built skills adds real value. For example: * **You're using vague prompts:** Skills amplify your intent. If you give a loose prompt like "add animations to this screen," a specific Compose animation skill can inspire the model, pushing it toward modern APIs or screenshot testing patterns it might not have otherwise considered. * **You want to use smaller, cheaper models:** Frontier LLMs are expensive. If you are offloading routine tasks to smaller open-weight models like Gemma 4, enabling basic skills fills the knowledge gaps that smaller parameters miss. * **You're refactoring or reviewing legacy code:** Models excel at generating code that works, but when editing old codebases, they often prioritize staying consistent with the surrounding legacy patterns over rewriting things with modern accuracy. A specialized reviewer agent equipped with core skills can help break that habit. * **You deviate from the norm:** LLMs love the standard "Google way" of architecting Android apps. If your team uses a highly customized view-layer architecture, the model will struggle to stay aligned. A custom skill explicitly describing your architecture goes a long way. ## Where can I find core skills? The Android community has your back. Chris Banes has a comprehensive collection of skills for Compose and Kotlin, Ivan Morgillo published a skill that audits Compose projects, and Jaewoong Eum created two on testing and performance. Always download skills from reputable sources! I personally wouldn't trust repositories containing dozens or hundreds of Android skills as they're probably AI-generated and untested, and they could even contain malicious or biased instructions. Also, don't install general software engineering skills blindly; a lot of them are tailored for web development. ## Goal: deprecation Loosely paraphrasing Karpathy: Skills of today will be in the models of tomorrow. As SOTA models keep improving, we expect skills to be obsolete, especially those built around new APIs. To figure out when to retire them, we run our evals when new models drop. If they pass, we'll keep them around for a few months until most users have transitioned over.

_Posted by Paul Feng, VP of Product Management, Google Play_ _ _ Providing a safe online experience and protecting users from harm is a top priority at Google Play. We take this responsibility seriously and have been investing continuously to offer baseline protections on our platform while also empowering parents with the tools they need to make decisions for their families. Importantly, we also want to empower Play developers with the capabilities to deliver age-appropriate experiences based on their app's content. To support this, today, we are taking another big step in our ongoing partnership with parents and developers by announcing the expansion of the Google Play Age Signals API to all Play developers globally. Building on current availability in Brazil, we will expand this experience first to users in Australia and Canada by mid-August, with a full global rollout to all users later this year. ## Empowering developers to create age-appropriate experiences The Play Age Signals API is a privacy-preserving tool that puts parents in the driver's seat allowing them to share their child's age range (e.g. 16-17) directly with apps. It also enables adults to easily share their age when prompted by the app developer. In turn, developers receive the signals they need to tailor their own in-app safety experiences and content for users in an age-appropriate way. We want to give developers the ability to choose the right protections for the nature of their app. A weather app, for example, shouldn't need the same safety settings as entertainment or media apps. Rather than enforcing one-size-fits-all rules, we give developers the flexibility to choose how they integrate safety signals. With this reliable signal, you retain complete agency to tailor your app's content, features, and settings to match your audience. _Users have a choice to share their age range in a privacy-friendly way_ ## Simplifying controls for parents Parents shouldn't have to manage complex safety settings across dozens of different apps to keep their children safe. The Play Age Signals API simplifies this by putting age-sharing controls in one place, directly inside the Google Family Link app. Parents have a choice to share their child’s age range, and if they choose to share, all Play apps that use Play Age Signals API can receive age signals. This lets children jump straight into age-appropriate content without parents having to manually configure settings inside these apps. Age ranges are never shared by default, and parents can update or turn off these settings at any time. _Centralized and easy way to manage age sharing settings for parents via Family Link App_ ## Building on our broader safety tools The Play Age Signals API builds upon a strong foundation of established safety features and strict policies we have long enforced on Google Play. Today, we already mandate that apps designed for families meet rigorous safety standards, and we continuously review and scan applications to ensure they are safe for children. For developers, we also offer built-in tools like Restrict Minor Access in the Play Console to help them manage who can discover their apps. For parents, Google Family Link remains a trusted, central dashboard where they can manage screen-time limits, PIN-based content filters, and app download approvals. Expanding the Play Age Signals API globally adds a powerful new tool to our existing safety suite, helping parents and developers work together to make Google Play an even safer, more trustworthy place for families.

Posted by Rebecca Franks, Developer Relations Engineer, Nick Butcher, Product Manager, Loryn Hairston, Product Marketing Manager, Android Today, we officially celebrate five years since the release of Jetpack Compose 1.0. From version 1.0, announced on July 28th, 2021, to our latest 1.11 release, we’ve seen the APIs evolve significantly over the years, and we’re taking a moment to celebrate. When we officially announced the 1.0 release, we promised a simpler, faster, and more intuitive way to build native interfaces on Android. Looking back, it's safe to say that Compose didn’t just deliver on that promise, but also completely changed the Android ecosystem, with more than 68% of the top 1,000 apps using it in production today. ## History Over the last five years, Compose has grown steadily. In the early days, we explored showing you how to build layouts with the basic Box, Row, and Column. Today, we’ve expanded Compose to work not just on mobile devices, but to other form factors such as Compose for TV, WearOS, Glance for Widgets, and even display glasses with Jetpack Compose Glimmer. We recorded an Android Developers Backstage episode with Clara Bayarri, Engineering Lead for Jetpack, and two former leads of the team, Romain Guy and Chet Haase, along with Tor Norbye, Senior Engineering Director. In this episode, they discuss the history of Compose and the early days of development. _ _Compose highlights over the years_ _ ## Looking back The beginnings of Compose were very different from what you know today. Two projects were happening in parallel inside the Android team. At the time, the Views toolkit team was thinking of unbundling the UI Toolkit into a library to help with development speed, and make it easier for developers to adopt and control updates. Meanwhile, a team was working on a novel idea to build declarative layouts by embedding XML inside Kotlin, which looked something like this: Those two efforts merged to produce what you know today - a fully declarative UI Toolkit that utilizes the power of a compiler plugin, runtime, and Kotlin: @Composable fun Newsfeed(stories: List<Story>) { LazyColumn { items(stories) { story -> Card { val author = story.author Image(painterResource(author.profilePhoto), contentDescription = author.name) Text(author.name) Text(story.content) if (story.hasCommentsEnabled()) { for(comment in story.comments) { Text(comment.mainContent) } } } } } } And you, the community, helped us very early on! Before 2021, Compose had a pre-alpha phase, which helped ensure Compose was fit to solve the problems of our developers. One of our favorite memories is the Android Dev Challenge. We challenged the community to build four different tasks with Compose, filling our feeds with Puppy apps, clocks, and weather apps, and giving us a ton of direct feedback that helped shape the 1.0 release. Compose has continued to evolve, from launching with a set of Material 2 components to now supporting Material 3 Expressive. _Material 2 in Compose_ _ _ _ _Material 3 Expressive in Compose_ _ ## Looking ahead As of today, Compose 1.11 is the latest version with 1.12 coming soon, offering so much more than 1.0, 5 years ago. This year, we introduced more adaptive APIs, such as `FlexBox`, `Grid`, `MediaQuery`, and Styles. These APIs let you advance to the next level of premium, adaptive UI development with Compose. At Google I/O 2026, we announced that we are now Compose-first, meaning that all future UI development will happen only in Compose, while the Views toolkit enters maintenance mode. Material Design is also shifting focus entirely to Compose, signaling an end to the `findViewById era`. ## Community is at the heart of Compose Over the years, you’ve inspired us with creative examples of how you’ve used Compose, and we’d love to highlight a few more examples of where we’ve seen exciting work. Jetbrains has been a great partner for Google with Compose, expanding Compose to work across platforms with Compose Multiplatform and enabling desktop, iOS, and web developers to also enjoy the benefits of Compose. We’ve really enjoyed following our most beloved newsletters from JetpackCompose.app’s Dispatch, AndroidWeekly, to jetc - helping Android Developers stay up-to-date with the latest in the world of Compose and Android. Another standout contributor is sinasamaki. They’ve created many delightful experiences using Compose, such as this fun ribbon modifier and the glitchy effect: Saket Narayan has also always been an inspiration when it comes to creating useful tools for Compose, such as telephoto, a library featuring support for pan and zoom gestures and automatic sub-sampling of large images, or the latest library, Touch Robot, which allows you to easily test interaction animations: paparazzi.gif(end = 3_000) { DebitCard( Modifier.testTag("card") ) val touchRobot = rememberTouchRobot() LaunchedEffect(Unit) { touchRobot.onNode(hasTestTag("card")).performGesture { draw( path = createAndroidHeadPath(), duration = 3.seconds, ) } } } /** A path drawing the Android head. */ fun createAndroidHeadPath(bounds: Rect): Path = TODO() | ---|--- Jake Wharton, who has used Compose in innovative ways (like molecule, and even building UI with Compose for the terminal with mosaic). Chris Banes, who has built many Compose libraries over the years, with our most recent favourite - Haze for background blurring, and many of the Android Google Developer Experts like Akshay Chordiya, Huyen Tue Dao, and Katie Barnett, who’ve contributed to the success of Compose. But this is not about selecting individuals - there have been so many great contributors to the Compose codebase, and many of you continue to inspire us with your fun examples, libraries, and in-depth talks. Without the community, Jetpack Compose wouldn’t be as successful as it is today. ## Cheers to the next 5 years, and more! Jetpack Compose has grown from an experimental idea into the standard for Android UI Development. Thank you to the entire Toolkit team at Google, and to the incredible global developer community that wrote libraries, filed bugs, and pushed the boundaries of what declarative UI can do. This week, we’ll be celebrating with some in-person birthday parties across the globe, and a live “Birthday party” on the Android Developers YouTube channel on July 30th at 13:00 UTC. During this time, we’ll hang out and discuss Compose and answer your questions! Cheers to the next 5 years, and happy composing!

_Posted by Andrei Shikov, Senior Software Engineer, Android Toolkit and Jonathan Starup, Software Engineer, R8 Team_ _ _ _ _ Starting from AGP 9.2.0, R8 optimizes most `Atomic*FieldUpdater` calls into `Unsafe` variants that perform 2x to 4x better on common operations. This has a particularly large impact on the kotlinx.atomicfu library that implements atomics for `kotlinx.coroutines`, making launching and cancelling coroutines up to 2x faster. In order to get the benefits, update your AGP to 9.2.0 or above. With the majority of Android apps adopting Kotlin as their main language of choice, `kotlinx.coroutines` has become a de-facto standard for asynchronous programming. The library offers a well-designed and structured way of managing concurrent flows that is native to Kotlin. Jetpack Compose was no exception, adopting coroutines for managing pointer events, animations and other interactions. At the time of writing, most concurrent APIs in Compose call `suspend` functions under the hood and are launching and/or cancelling coroutines to handle updates. As the Compose team started to investigate performance, coroutines were discovered to be a bottleneck for many operations that happen outside of composition. As an example, 80% of the time spent on creating and updating `Modifier.clickable` was consumed by launching and cancelling internal coroutines that handled `InteractionSource` updates. Based on those observations, much of early performance work was focused on removing coroutines from the default path and delaying initialization until necessary. ## The cost of a coroutine The easiest way to analyze a function's internal behavior on Android is to capture an Android Runtime (ART) method trace. An ART method trace is a tool that records the execution flow of an app, showing exactly which methods are called, their order, and how much time is spent in each, allowing developers to identify performance bottlenecks. For an empty `LaunchedEffect { }` call, it would look something like this: _LaunchedEffect method trace visualized in the Perfetto UI_ The method trace above can be separated into three parts: * Initializing a new coroutine * Starting coroutine * Completing coroutine (because it exits immediately) Cancelling `LaunchedEffect` is similar to normal completion, except it also creates a `CancellationException`. From the profile above, one thing that is immediately suspicious is frequent calls into `java.util.concurrent.AtomicReferenceFieldUpdater` (purple or green boxes with j… labels). While each call is relatively fast, the frequency is concerning; any non-negligible overhead that is spread out across multiple invocations might add up to a noticeable regression. Zooming in on a call reveals that most of the time is spent on... reflection checks? _An up-close look at the method trace of AtomicReferenceFieldUpdater.get during LaunchedEffect initialization_ Coroutines implement a lock-free tree structure for parent-child relationships that makes structured concurrency possible. Turns out, the `kotlinx.atomicfu` library implements lock-free atomic operations using a well-known JVM primitive, `AtomicReferenceFieldUpdater`. The updater uses a class reference and a field name to perform atomic operations at runtime, and it has to run several reflective safety checks to make sure the field exists and is accessible. Each operation in coroutines (starting, suspending, cancelling, completing) calls at least one atomic operation, so if it is slow, coroutines will not perform well. ## Investigating AtomicReferenceFieldUpdater But let's not get ahead of ourselves. `AtomicReferenceFieldUpdater` is actually well-optimized on JVM for over 10 years now, and method traces might capture overhead that is completely removed by a VM level optimization: just-in-time (JIT) or ahead-of-time (AOT) compilations. To verify performance, let's write a few benchmarks to measure the difference between atomic references from `kotlinx.atomicfu` and `java.util.concurrent.atomic`. @RunWith(AndroidJUnit4::class) class AtomicReferenceBenchmark { @get:Rule val benchmarkRule = BenchmarkRule() private val atomicReference = java.util.concurrent.atomic.AtomicReference(false) private val atomicRef = kotlinx.atomicfu.atomic<Boolean>(false) @Test fun atomicReference_compareAndSet() { benchmarkRule.measureRepeated { atomicReference.compareAndSet(true, false) atomicReference.compareAndSet(false, true) } } @Test fun atomicRef_compareAndSet() { benchmarkRule.measureRepeated { atomicRef.compareAndSet(true, false) atomicRef.compareAndSet(false, true) } } /* measuring other methods from the method traces above */ } Running this benchmark on a Pixel 5 (while ensuring `AtomicReferenceFieldUpdater#compareAndSet` is JIT compiled during warmup), yields the following results on Pixel 5 (API 33): 50.7 ns atomicReference_compareAndSet 135 ns atomicRef_compareAndSet The measurements confirm the gap, with `kotlinx.atomicfu` version clearly being approximately 2.7x slower. This confirms that ART does not perform any hidden optimization and reflective access checks add real overhead during runtime. Looking back at the original method trace, the only meaningful work performed by the `AtomicReferenceFieldUpdater` is the internal call into `Unsafe.getObjectVolatile` that actually executes the underlying atomic operation. In most cases, the updater initializer is static, and can be proved to be always correct based on the structure of the surrounding class. Thus, one could statically analyze most of the `AtomicReferenceFieldUpdater` usages and replace them with an internal `Unsafe` variant during compilation. It also just happens that Android build toolchain has its very own optimizing compiler that can do exactly that. ## Optimization with R8 The `Atomic*FieldUpdater` classes support subtle, dynamic and reflection-based use, but are often used in statically obvious patterns. This both explains the slow baseline performance and the want for optimization. R8 is a full-program optimizing compiler and is well-suited to see through the simpler patterns to skim the overhead of the reflective safety checks. R8 receives JVM bytecode after the Java or the Kotlin compiler, but to ease readability these examples are presented in Java syntax. This is why there are no type arguments for `AtomicReferenceFieldUpdater`. class Example { volatile String data = ""; static final AtomicReferenceFieldUpdater updater = AtomicReferenceFieldUpdater.newUpdater(Example.class, String.class, "data"); void example() { // ... updater.compareAndSet(this, "", "new"); // ... } } The base example creates a static final updater which accesses a volatile field with simple constant arguments for the holder, the type, and the name of the field. The reflection used is totally transparent. It is clear to see this updater references a valid field and that the site of the updater creation has valid access to the field. In its essence, `Atomic*FieldUpdater` is a wrapper around a field offset and calls to `Unsafe`. The best case scenario for the optimization is to replace the updater field with an offset field and replace the updater calls with calls to `Unsafe`. ### Optimizing Atomic*FieldUpdater The optimization is implemented in three parts: Instrumentation, Replacement, and Clean-up. ## Instrumentation The first step is to introduce offset fields alongside the updater field in order to facilitate direct access via the `Unsafe` call. static final long updater$offset = SyntheticUnsafe.UNSAFE.objectFieldOffset(Example.class.getDeclaredField("data")) The field is accessed via reflection, and `Unsafe` is used to extract the field offset on the class. This code represents the internals of `Atomic*FieldUpdater` if you disregard reflection validation. Instead, the holder type of the updater and the field type of the volatile field are tracked statically in the compiler. Note that the original field and its initialization are left as-is. The optimization process optimistically facilitates and optimizes uses and then later cleans up. This is a simple approach to the implementation but also allows partial optimization of updater fields, where some uses are left as they were while others are optimized. ## Replacement At this point in the compiler, after a suitable concurrency join point, we have a list of instrumented updater fields. This means that we can optimize each call site individually based on a few conditions. Consider an example call: updater.compareAndSet(holder, expectedValue, newValue); The conditions that `Atomic*FieldUpdater` requires are these: * Does `updater` come from an instrumented field? That is, can static analysis track the value of the object back to a field read of an instrumented updater? * Is `holder` the same class or a subclass of the originally defined holder type? * Is `newValue` the same class or a subclass of the originally defined field type? If all conditions are met, then the call is replaced by a call to `Unsafe` without any of the reflection checks. SyntheticUnsafe.UNSAFE.compareAndSwapObject(holder, Example.updater$offset, expectedValue, newValue) This new call is faster and simpler but it differs from the original call in regards to its handling of null values in `updater` and `holder`. Unless statically ruled out, null-checks are inserted for both. ## Clean-up At this point, the holding class has the original updater field and the new offset field along with call sites that might use either one of the two. If none of the call sites were optimized, then the offset field should be removed and if all of the call sites were optimized, then the updater field should be removed. In both cases the initializing call should also be deleted. The deletion of unused fields and removal of dead code is already done in the compiler, but removing the initializing code here requires a few more tricks. Both the call to `newUpdater` and `getDeclaredField` might have side effects as they can throw exceptions (and their implementation is also unknown since it depends on the API version). This means that by generic optimization, they cannot safely be removed. So this clean-up required explicit consideration of the instrumented fields, since those are statically known to be free of exceptions. In the end, the simple updater example shown above looks like this after optimization: class Example { volatile String data = ""; static final long updater$offset = SyntheticUnsafe.UNSAFE.objectFieldOffset(Example.class.getDeclaredField("data")) void example() { // ... SyntheticUnsafe.UNSAFE.compareAndSwapObject(this, Example.updater$offset, "", "new") // ... } } ### Results After these optimizations, `kotlinx.atomicfu` and most explicit uses of `AtomicInt/Long/ReferenceFieldUpdater` now match `AtomicReference` performance with R8 applied. In fact, it is even faster in some benchmarks; `kotlinx.atomicfu` has a compiler plugin that can inline `atomic` instances into fields, reducing allocations required to create an atomically updated field. Jetpack Compose was the main beneficiary of this work. Compose runtime has a number of microbenchmarks that track coroutine performance very closely to catch performance regressions early. When the benchmarks were updated to a new version of R8, we noticed a 2x improvement when launching and cancelling coroutines in `LaunchedEffect`! _Benchmark graph illustrating the time taken when starting and cancelling coroutines in LaunchedEffect (lower is better). The change in the graph corresponds to an R8 update, showcasing 2x improvement._ Aside from that, the ART team is implementing these optimizations natively at the VM level. If your app is targeting API 37 and is running on a recent version of Android, it is possible that your device is already optimizing coroutines in a similar way. The coroutine benchmarks above observed ~15% improvement in performance after JIT updates in the recent versions of ART. Your app will receive this optimization by default when upgrading to AGP 9.2.0 or by using R8 9.2.0 directly. For more information, see D8 dexer and R8 shrinker.

_Posted by Fahd Imtiaz, Senior Product Manager and Miguel Montemayor, Developer Relations Engineer, Android Developer Experience_ _ _ _ _ Today at Galaxy Unpacked, Samsung unveiled its latest lineup of foldable and wearable devices. For developers, this means that the variety of form factors, screen sizes, and device postures your app needs to support is expanding once again. With devices like the Galaxy Z Fold8, the ecosystem is expanding to include hardware with a landscape-first natural orientation and a wider aspect ratio in its main display state. Whether a user is unfolding a large display, flipping open a cover screen, or glancing at their wrist, users expect a flawless experience. To help you meet this moment, we’re sharing actionable guidance and new tooling updates to enable you to build adaptively proactively. ## Rethink layout architecture for dynamic displays, including ultra-wide foldables Building for the latest foldables means dropping assumptions about display orientation and size. This is especially true for the Galaxy Z Fold8, which adopts an ultra-wide display, adding to the variety of aspect ratios to account for. Devices with this landscape-first natural orientation show the limitations of hardcoded layout rules when users unfold the device. That’s why we’ve introduced dedicated guidance for building for landscape foldables and trifolds. To build a responsive UI that handles these physics seamlessly, focus on the following core pillars: * **Build fluid, adaptive layouts:** Wide aspect ratios and compact vertical heights require fluid UIs that scale responsively. Our updated adaptive design guidance advises considering the window class width first to determine layout changes, then adjusting for height. To let individual components fluidly adapt to the grid, structure your layout using flexible containers that allow your content to automatically wrap, span, and reflow. For design inspiration browse our adaptive sample app and dual-screen design galleries. * **Track actual app space:** Your app's display space rarely matches the physical device size, especially on an ultra-wide screen during multi-window, split-screen, or multitasking states. Sometimes even the orientations differ. Leverage Window Size Classes using the Jetpack Window Manager library to calculate the exact space your app occupies. * **Leverage the latest Jetpack Compose Update:** Start by adopting the stable Jetpack Compose April '26 release (Compose BOM version `2026.04.01`).Take advantage of the new structural layout tools to manage complex architectures. The new Grid API allows you to define dynamic tracks and column spans without the performance overhead of a lazy list. Pair Grid with the new FlexBox layout API to easily handle multi-axis alignment and dynamic item wrapping. You can also use the new MediaQuery API to adapt your UI to its environment, using conditions to detect signals like device posture, window size, and keyboard types. * **Make your app fold aware:** Use the Jetpack WindowManager library, which provides an API surface for foldable device window features such as folds and hinges. When your app is fold aware, it can adapt its layout to avoid placing important content in the area of folds or hinges and use folds and hinges as natural separators. * **Maintain app continuity:** Avoid breaking the user journey when the device configuration shifts. Retain your UI state using ViewModel to ensure smooth transitions when a user folds or unfolds their device. ## Ensure seamless camera capture on foldable devices Camera implementation on foldables brings unique hardware quirks. Moving from a compact outer display to an expanded inner display introduces distinct layout aspect ratios while device rotation remains unchanged. If an app assumes a fixed portrait relationship between the camera sensor and the device layout, the app will likely suffer from sideways, stretched, or cropped previews during these folding transitions. When optimizing your app's media pipeline, migrate your capture experiences to CameraX using the CameraX migration skill. The library’s PreviewView automatically handles sensor orientation, device rotation, and scaling behind the scenes. This guarantees a clean, stable preview regardless of how the user holds or positions the device. If you are maintaining an existing Camera2 codebase, integrate the CameraViewfinder library to apply these complex aspect ratio and rotation transformations automatically without needing a total architecture overhaul. ## Extend glanceable interactions to Wear OS 7 The opportunity to build for this new generation of devices extends right to the wrist. Launching with Wear OS 7, Wear Widgets give you a fresh surface to provide users with instant, glanceable access to their essential updates. You can build these highly expressive experiences using Jetpack Glance and RemoteCompose. Crucially, Widgets built with this framework can now populate multi-widget tiles that were previously reserved for first-party widgets. ## Build intelligent features Gemini intelligence already completes tasks on users’ behalf, and you can experiment with the intelligence system by sharing your apps capabilities. Samsung’s new foldable devices come with Gemini Nano 4, our latest on-device model. Nano 4 provides support for over 140 languages, better multimodal understanding, and much more. Use ML Kit’s Prompt API with advanced features like structured output and thinking mode to build intelligent features on-device. ## Start optimizing today The tools and frameworks are ready to help you optimize your app for all screen sizes. Begin by exploring our guidance for building adaptive apps to learn more about core adaptive design principles. To dive deeper, check out our comprehensive YouTube playlist. Finally, ensure your app delivers a flawless, premium experience on the newest form factors by reviewing our dedicated quality guidelines for trifolds and landscape foldables and WearOS. Unfold the future today!

_Posted by Jolanda Verhoef, Senior Developer Relations Engineer,__Android Developer Relations_ _ _ Building GenAI features in your app usually means navigating through various models, APIs and architecture choices: * **Execution location:** Where does your model run? On device, in the cloud, or both? * **Complexity:** How complex is your setup? Are you doing a single inference call or do you need a more agentic flow? * **In-app or Android System:** Should your feature be built into your Android app or does it fit better as an Android system integration? In this blog post series we'll navigate these choices with you. We will take you along on a journey, starting with a basic mobile app and transforming it into a **personalized** , **intelligent** , and **agentic** experience. ## Jetpacker: a demo travel app Jetpacker is a **technical showcase app** that our team built from the ground up for this year's Google I/O (built using Antigravity). At its core, Jetpacker helps users plan, explore, and enjoy their next big adventure. It shows an overview of your trips, the itinerary of each trip, and details of each event on that trip. Of course following all best practices of Android development, including a beautifully expressive Material UI design. And best of all? It's fully open source! Today we are publishing a series of**technical blog posts** diving deep into each of these features. We’ll provide detailed implementation steps, code snippets, and architectural insights to help you build your own intelligent Android applications. ## On-device intelligence _On-device features in Jetpacker: Summarizing trip itineraries, managing expenses, and voice notes_ Using an on-device model comes with **no additional cloud inference** costs, means you don't have to worry about **internet connectivity** , and lets users be confident that private information will be **processed locally** , on the device, without any of their data being sent to the cloud. In Jetpacker, we chose on-device inference for three of our features: * The **trip overview** feature transforms a messy, multi-day itinerary into a concise, actionable summary. It leverages Gemini Nano through the ML Kit GenAI APIs to process data locally on the device. We consider this a nice-to-have feature where we don't want to incur extra cloud costs, making on-device inference the right choice. * The **expense tracker** automatically extracts structured data from receipt images to help users track their travel spending. It uses the multimodal capabilities of Gemini Nano 4 through the ML Kit GenAI APIs. We choose an on-device solution so that any privacy-sensitive information on the receipt images never leaves the user's device. * The **audio diary** records, transcribes, and categorizes voice notes into relevant trip activities. It is powered by the ML Kit Speech Recognition and GenAI Prompt APIs. We chose an on-device solution for privacy and connectivity reasons. ## Cloud & hybrid inference _ _Cloud and hybrid features in Jetpacker: Museum assistant with web grounding, hybrid restaurant review drafting, and hotel support chat featuring custom-routed live translation._ _ Sometimes your use-case requires AI models with **greater world knowledge** or a much **larger context window** and with greater ability in **handling complex tasks**. In that case, we can switch from running an on-device model to using a cloud model instead. Or, if you want to get the best of both worlds, you can use hybrid inference to **dynamically choose** either a cloud or on-device model at runtime. This allows us to **lower costs** by moving inference to the device when it is available, but at the same time **support all Android devices** running the app. In Jetpacker, we implemented several features using cloud or hybrid inference: * The **place Q &A** feature answers user questions about specific locations by grounding responses in real-world data. It uses Firebase AI Logic integrated with Google Maps and web context. Using a cloud model is necessary here for its greater world knowledge. * The **review drafting** feature helps users compose detailed reviews for the places they have visited. It leverages both on-device and cloud models through Firebase AI Logic's new Hybrid inference API. This is a feature we wanted to make available to all app users, so we're using a cloud model as a fallback when an on-device model is unavailable. * The **automatic chat translation** dynamically translates chat messages in real time to facilitate seamless communication, demonstrating custom hybrid inference logic. Again, we want this feature to be available to all app users, but at the same time have some specific considerations on when to choose on-device versus cloud. ## System integration While not a feature you see in the app itself, the Android system integration opens up the app's core capabilities directly to the Android operating system. It uses the AppFunctions API to integrate with system-level intelligence. ## In-app agentic workflows (coming soon!) _ _The booking assistant shows several in-progress flight bookings, asking the user for input before making a final booking._ _ Agenticness introduces a higher level of**autonomy** , enabling models to act as agents. Instead of a single inference call, an agent works towards a specific goal via an orchestration loop that allows it to **reason** , use **tools** , and **adapt** its path. Depending on your requirements, these intelligent agents can run either in the cloud, directly on-device, or in a hybrid setup. For Jetpacker we added a **booking assistant** that automates end-to-end booking workflows directly within the application to streamline reservations. It is built using A2UI and ADK running in the cloud. The Android app functions as a front-end to the multi-agentic system running in the cloud. ## Learn more Check out the other parts of this blog post series: Part 1 (this post!): Introduction of the app and a high-level overview. Part 2: On-device intelligence. Deep-dive into ML Kit’s GenAI APIs and Gemini Nano to build privacy-first features like itinerary summarization, receipt parsing, and local audio processing. Part 3: Hybrid and cloud reasoning. Explore how to use Firebase AI Logic to ground LLM answers in real-world data like Google Maps and web context. Part 4: System integration. Integrating with the Android intelligence system using AppFunctions. Part 5 (coming soon): In-app agentic workflows. Extend the app with an end-to-end booking assistant powered by A2UI and ADK. Interested in more on Android Development? Follow Android Developers on YouTube or LinkedIn!

_Posted by Wei Wang, Engineering Manager, Android BeTo_ User privacy and transparency are core to the Android experience. To better align with these principles, we are updating the default behavior of the Nearby Connections API regarding how it interacts with device radios. ## What is changing? Previously, the Nearby Connections API could automatically toggle Wi-Fi and Bluetooth radios ON to facilitate connections without explicit user intervention. Moving forward, the API will no longer automatically enable these radios for 1P and 3P applications. ## What this means for developers If your app relies on Nearby Connections, you will need to update your implementation to account for these changes: * **Manual Radio Management:** You must ensure that the necessary radios (Wi-Fi or Bluetooth) are enabled before initiating Nearby Connections tasks. * **User Notification:** If the required radios are disabled, your app must now inform the user and request that they enable them manually. The API will no longer programmatically turn them on for you. ## Timing These changes are scheduled to take effect in late 2026. We recommend reviewing your connection workflows now to ensure a seamless transition for your users.

Posted by Amman Asfaw, Product Manager, Android Studio Android Studio Quail 2 is now stable and ready for you to use in production, bringing a shift to your IDE with concurrent agentic workflows, natively integrated memory leak profiling, and context-aware crash remediation. Whether you are performing a sweeping architectural overhaul, tracing a memory leak, or resolving a critical production crash, Android Studio keeps you anchored in your workspace by reducing manual friction. Here’s a deep dive into what’s new: ## Multi-tasking with parallel chats In Android Studio Quail 2, we've been hard at work redesigning Agent Mode from the ground up. This new architecture provides better performance, offers more flexibility for decomposing complex tasks, and improves the suite of internal tools the agent uses to do its work. In addition to these behind-the-scenes improvements, these changes also allow you to converse across multiple agent chats simultaneously. Waiting for the Android Studio agent to finish a task before you can ask another question or initiate a separate task in Agent Mode is a bottleneck of the past. You can multi-task seamlessly: kick off a UI refactor in one tab, fix a ProGuard rule in a second, and generate documentation in a third. You can also change which models the agent uses from chat to chat based on the requests you have. Take a look at Android Bench for an analysis of how LLMs perform Android development tasks. * **How to use:** Click the "+" icon to start a new parallel conversation, and use the **History** icon to navigate between active tasks. Alternatively, select File > New > New Agent Tab to open a conversation in a dedicated tab. * **Note:** Worktree support is currently unavailable. Exercise caution when running concurrent chats that modify the same project files, which can potentially lead to editor conflicts. _Run multiple agent tasks in parallel with different models of your choice._ _Use the History icon to navigate between active tasks._ ## Memory leak detection with LeakCanary Memory leaks in Android occur when your code holds onto an object's reference long after its life cycle has ended. This prevents the Garbage Collector from reclaiming that memory, eventually leading to sluggish performance or `OutOfMemoryError`. Hunting down memory leaks can be a tedious, manual task. Starting with Android Studio Quail 2, the popular open-source leak detector LeakCanary is natively integrated directly into the Profiler as a dedicated, first-class task. This integration transforms your debugging performance by lifting and shifting the heap analysis off your resource-constrained testing phone, and onto your powerful development computer. By running the analysis on your computer, leak tracing is up to five times faster and jank-free, leaving your test app running smoothly on the device. Once a leak is detected during a profiling session: * The Profiler renders an interactive, color-coded leak trace, grouping occurrences and estimating lost memory. * You can click **Go to declaration** on any leaking object in the trace to instantly jump to that exact line of code in your editor. * You can click **Fix with Agent** to have the Gemini agent ingest the trace, explain the root cause of the retained reference, and write the exact code change (such as unbinding a listener or clearing a static reference) to plug the leak. _Review memory leaks identified via LeakCanary through the Fix with Agent button._ ## App Quality Insights agent integration Tracking down the root cause of an app crash can require manually synthesizing stack traces, device data, and source code. However Android Studio’s App Quality Insights (AQI) is now fully integrated with Agent Mode to do the heavy lifting for you. When you click on a crash in the AQI panel, you immediately get a concise, high-level summary of the issue. If you need to dig deeper, simply click **See more**. This opens a dedicated chat where the agent uses your selected model and pulls in local source code and the full stack trace to deliver a comprehensive explanation of the failure. With the new agent integration, you move directly from issue identification to resolution. By clicking **Fix with AI** , the agent will analyze the issue, propose a step-by-step fix plan, and—upon your approval—apply the necessary code changes directly to your project and verify the resulting fix _The**Fix with AI** button triggering the agent to analyze the issue, then propose the fix_ ## Quality & stability improvements Beyond new features, we’ve continued our focus on quality by addressing numerous bugs and incorporating the latest stability and performance improvements from the IntelliJ platform, making this a significant enhancement for your daily development. ## Get Started Ready to dive in and accelerate your development? Download Android Studio Quail 2 and start exploring these new features today! As always, your feedback is crucial to us. Check known issues, report bugs, and be part of our vibrant community on LinkedIn, Medium, YouTube, or X.

_Posted by Zoe Lopez-Latorre, Senior Developer Relations Engineer, Android_ _ _ _ _ Back in March, we introduced Android Bench—our LLM leaderboard for real-world Android development tasks. Our goal was to provide transparency around model capabilities in Android development and to encourage model improvements, to give you more helpful AI options for your everyday workflow. Since then, we have enhanced the benchmark based on your feedback, including evaluating open-weight models and adding cost and efficiency dimensions to the leaderboard. But AI capabilities are ever-evolving, and measurement needs to follow suit. As part of our July release, we have adopted the Harbor framework, which includes an updated version of the benchmarking agent used to evaluate models. Along with this change to our evaluation, in this July release we’re adding 8 new models (**Claude Fable 5, Claude Sonnet 5, Claude Opus 4.8, GLM 5.2, Kimi K2.7 Code, MiniMax M3, Qwen 3.7 Plus and Qwen 3.7 Max**) to the leaderboard. We’re also sharing opportunities for you, the Android developer community, to contribute to the benchmark. ## Upgrading our methodology with the Harbor framework When we designed Android Bench, we anchored our methodology on leading industry standards available at the time. We used mini-swe-agent v1, a general-purpose benchmarking agent, and adapted it to the nuances of Android development to provide a baseline measurement for the capabilities of models for common Android development tasks. To continue providing you with state-of-the-art evaluations that accurately measure the latest model capabilities on Android development, we are standardizing our benchmark to the Harbor framework. Harbor defines standards and integrations that make it easy for anyone to run the benchmark, evaluate their preferred set-up, or share results – providing you with additional transparency and visibility. This upgrade enables us to more rigorously evaluate models and their capabilities, and we re-ran the benchmark on all models to establish an updated baseline. This means there is a minor shift in scoring, but you will still be able to view historical scores within the archive on our website. We want to ensure Android Bench is helpful for you, so we will continuously update it as our evaluations and the industry mature. ## Expanding the leaderboard with 8 new models As part of our commitment to keeping the leaderboard fresh, we have added Claude Fable 5, Claude Sonnet 5, Claude Opus 4.8, GLM 5.2, Kimi K2.7 Code, MiniMax M3, Qwen 3.7 Plus and Qwen 3.7 Max to the Android Bench leaderboard. You will see that **Claude Fable 5** is at the top of the leaderboard with a score of 84.5, followed by **GPT 5.5** with 80.2, with **Claude Sonnet 5** in 3rd with a score of 76.2. When just comparing Open-weight models,**GLM 5.2** is at the top with 72.2, followed by **Kimi K2.7 Code** with a score of 70.4. You can check out model performance and efficiency metrics on the updated leaderboard to see how these new and previous models navigate Android-specific challenges like Jetpack Compose migrations, wearable networking, and platform API updates. ## Opening Android Bench to community contributions From the beginning, we’ve valued an open and transparent approach, which is why we made our original methodology and test harness publicly available on GitHub. You’ve asked for a way to provide feedback on our dataset, so now we’re taking collaboration a step further by giving you, the Android developer community, a chance to shape Android Bench. Starting today, you can contribute to Android Bench in two ways: * Design and submit your own Android development tasks to evaluate how models handle the scenarios that matter to you. * Run and share benchmark evaluations firsthand, testing your preferred models against our dataset or your own custom tasks. We will be reviewing the submitted tasks and will be assessing if they get added to the benchmark. We hope to build a benchmark that truly reflects the diverse, day-to-day realities of the global Android developer community. ## Looking ahead With more and more options for agentic development, maintaining a cutting-edge benchmark ensures that the AI assistance you rely on keeps getting smarter, more helpful, and more effective. Head over to our GitHub repository to check out the tasks. We invite you to submit a task to our team for review, and you can check out Harbor Hub to explore the dataset or submit evaluations. As always, you can find the updated leaderboard, or read the methodology on our website. Android Bench, LLM leaderboard, Harbor framework, Android development, Claude Fable 5, GPT 5.5, Claude Sonnet 5, GLM 5.2, Kimi K2.7 Code, MiniMax M3, Qwen 3.7 Plus, Qwen 3.7 Max, AI benchmarking, Jetpack Compose migration, wearable networking, mobile AI agent, Zoe Lopez-Latorre, model evaluation, open-weight models, developer community contributions.

_Posted by Steph Pio, Strategic Partnerships Manager, Google Play EMEA_ _ _ __ _ _ Sub-Saharan Africa is home to some of the world’s most creative storytelling. To help bring those stories to a global audience, today, we’re proud to announce the debut of Google Play’s Indie Games Fund in Africa. The region’s unique creativity has fueled a vibrant game development scene, helping drive what is quickly becoming one of the most exciting, resilient, and fast-growing gaming markets. It’s a space defined by immense talent. However, access to capital is a persistent hurdle, and a significant investment gap often holds back incredibly promising local studios. With this inaugural fund, we’re committing $1 million USD to help address that gap. This fund will empower 10 indie game studios across Sub-Saharan Africa to scale their businesses and realize their full potential. ### Funding and support for selected studios This program is designed to drive long-term growth, where it can make the biggest impact. Selected studios will receive a share of the $1 million fund, with individual investments ranging from $50,000 to $200,000 to help elevate their games. Alongside this financial backing, recipients will benefit from dedicated mentorship and hands-on technical support. Together, these awards are designed to help them scale their businesses and reach a global audience. ### Who can apply? The program is open to indie game developers based in Sub-Saharan Africa (see the list of eligible countries) who have launched a game—whether it’s on Google Play, another mobile platform, PC, or console. Review the eligibility criteria and apply now. Applications close at 12 noon UTC on July 31, 2026.

_Posted by Tibian Elsheikh, Product Manager, Android Core Graphics and Jeffrey Jose, Product Manager, Android Core Graphics_ We’ve all been there: You’re scrolling through your favorite social media feed in a dim room, and suddenly an HDR video pops up. It’s so intensely bright that you have to squint, or maybe you find yourself turning down your screen brightness just to read the caption. Other times, a video that looks vibrant on your phone looks flat, dark, or washed out when you watch it on your living room TV. While High Dynamic Range (HDR) technology was designed to make videos look richer and more lifelike, the lack of unified industry guidelines means that the exact same clip can render in unexpected and jarring ways depending on the display you’re using. To solve this, we’re introducing Eclipsa Video—a new standard built to make your favorite videos look consistent, balanced, and comfortable on every screen. Eclipsa Video builds on the open SMPTE ST 2094-50 specification, which Google developed in collaboration with Apple and NBCUniversal. _ _ Sudden brightness spikes during feed scrolling—fixed with Eclipsa Video._ _ ### **More consistency, comfort, and creative control** Eclipsa Video moves past individual display guesswork. Instead of leaving it up to your device to interpret a video’s brightness on its own, our format carries precise guidelines that tell compatible displays exactly how to render the image. Designed to scale with your hardware, Eclipsa Video provides three core benefits: * **A consistent baseline:** Eclipsa Video introduces a shared rulebook for screens. It establishes a consistent benchmark for normal brightness—known as the **HDR reference white**. This ensures standard text, app interfaces, and standard-range colors remain vibrant and readable without causing uncomfortable screen glare. * **Adaptive headroom:** Screens have different physical brightness limits, or "headroom." Eclipsa Video guides how displays handle highlights dynamically. Bright details remain brilliant on a premium television, while being scaled intelligently on a mobile screen to prevent sudden blinding transitions. * **Preserved creative intent:** Rather than applying a single static setting to an entire video, Eclipsa Video carries adaptive, frame-by-frame instructions. Think of it as a set of digital notes from the creator traveling with the video, ensuring the exact colors, contrast, and mood they graded are preserved on your display. _Eclipsa Video preserves true highlight detail on any screen you watch._ ### **Built natively into Android 17** Starting with Android 17, support for Eclipsa Video is built directly into the platform. This means a more comfortable, true-to-life HDR experience is coming natively to the phones, tablets, and TVs you rely on every day. The video you capture carries its creative intent with it, and the video you watch is shown exactly the way it was meant to be seen. ### **Guidelines for developers & creators** We’re inviting the developer and creator ecosystem to help build a more reliable HDR environment: * **Get started with implementation:** Learn how to configure playback and capture in your apps with our official guide. * **ExoPlayer & Media3 integration:** Standard playback handling built directly into Jetpack Media3, allowing ExoPlayer to support Eclipsa Video metadata automatically with no additional player configuration. * **Explore open source tools:** View and inspect SMPTE ST 2094-50 metadata and dynamic gain curves in real time using HDR Explorer. ### **What’s next** Eclipsa Video is rolling out now, and you’ll see more apps and devices supporting it over time. Because it’s an open standard, any app developer or hardware manufacturer can integrate it to elevate the viewing experience. Try out the new tools in Android 17, explore the open-source metadata, and let us know what you think on our developer channels. We can’t wait to see what you create. ### **Notes & Availability** **1. Device Compatibility:** Eclipsa Video playback and capture are supported natively on devices running Android 17 (API level 37) and above with HDR displays passing Eclipsa Compliance tests. **2. Developer Resources:** The SMPTE ST 2094-50 Specification is openly accessible for technical evaluation.

_Posted by Paul Feng, Vice President, Google Play Eng, Product, UX_ At Google Play, we are committed to delivering the best possible experience to users, while ensuring developers have the tools and adaptability to succeed. Guided by this commitment, earlier this year we announced updates to our business model introducing more billing flexibility, lower fees, and new programs to help your business thrive. With some of these changes rolling out soon, the breakdown below outlines what is coming, where to find more information, key dates, and how to get started. ## More billing flexibility Google Play’s billing system safely, efficiently, and intuitively handles the complexities of taxes, compliance, and subscriptions across 195+ markets with 300+ local payment methods. However, we understand there are situations where your business needs more flexibility, and that's why we're offering you more options in how you handle digital commerce. Building from existing programs, the new billing choice program is available to all developers globally who provide digital services or content to users within the United Kingdom and the European Economic Area, alongside programs in the United States. Following this initial phase, we will continue expanding availability to additional markets. You will find the global release schedule at the bottom of this post. Through these programs, developers can offer an alternative billing system or link users to their own website for purchases, alongside Google Play’s billing. You may also design your own choice screen in accordance with our UX guidelines, as an alternative to Google Play’s default version. Please find all the details in the program page here. ## Lower, separate fees To enable this new level of flexibility, we're separating our service fee from the billing fee. This starts on June 30, 2026, beginning with the United States, European Economic Area, and United Kingdom. Regardless of whether you use Google Play's billing system, alternative billing, or external web links, the service fee starts at 10% on your first $1M (USD) in annual earnings. This 10% service fee also applies to all auto-renewing subscriptions. For all other transactions, the rates in the table below applies: For other transactions, the service fee will be determined by whether the transacting user's install is new or existing relative to the regional rollout date: * **New installs** : A transaction from a user whose first-time install or first update of the app from Google Play occurred on or after the date that the new fee structure launched in their region. * **Existing installs** : A transaction from a user whose first-time install or first update of the app from Google Play occurred before the date that the new fee structure launches in their market. For transactions that use Google Play’s billing system, an additional billing fee applies. In the United States, United Kingdom, and the European Economic Area, the billing fee is set at 5%. We'll announce billing fee details for other markets soon. For transactions processed via alternative billing or external web links, the billing fee does not apply. Review this Help Center article to understand how these rates apply to your business. ## Games Level Up and Apps Experience program guidelines We are also excited to announce even more opportunities for partners who deliver exceptional user experiences across the Android ecosystem: the revamped Games Level Up and the new Apps Experience program. Detailed guidelines are now available on the respective program websites. Apps and games that meet all requirements are eligible for a new program rate card with reduced rates. See the table below for details: Visit the Games Level Up and Apps Experience program websites, review the guidelines, and start preparing your games and apps ahead of September 30, 2026, when the program rate cards officially become available. ## Global release schedule Evolving our business model requires technical infrastructure and alignment with local regulations, so these updates will roll out on a staggered timeline. To help you plan, here is the previously announced release schedule for each update across all markets: Here is a quick recap of the resources available to help you get started: * Review the billing choice program; * Learn more about Google Play's lower service fees; * Explore detailed guidelines on the Games Level Up and Apps Experience program websites. We look forward to building the next generation of Google Play experiences together.

_Posted by Matthew Forsythe, Director Product Management, Android App Safety_ Last year, we introduced Android developer verification to strengthen ecosystem security and stop malicious actors from hiding behind anonymity to release harmful apps. Millions of apps have been registered since the verification launched in March, covering nearly all installs on Google Play and a large majority of installs from outside of Google Play. We appreciate the feedback and partnership from industry leaders, developers, and Android communities that helped us design this experience and drive strong adoption. ## Initial launch across seven stores and four countries These new developer verification protections will take effect on September 30, 2026, starting with users in Brazil, Indonesia, Singapore, and Thailand. This rollout is an **industry-wide effort to create a safer ecosystem**. We will begin by verifying app installations from the following stores: * Google (Google Play) * Honor (HONOR App Market) * OPlus (OPPO App Market) * Samsung (Galaxy Store) * Transsion (Palm Store) * vivo (V-Appstore) * Xiaomi (GetApps) Following this initial phase with our partners, we will expand these protections globally for all apps on certified Android devices in 2027. ## Automate your workflow with new APIs To further streamline app registration, we are**launching a suite of developer-requested APIs** to help you register apps in bulk or directly through your continuous integration and deployment (CI/CD) pipelines. The Android Developer ID Status API will let you check if a package name has already been registered, and the Android Developer Console API will let you register and manage package names directly within your development environment. Both APIs also support OAuth delegation, allowing third-party platforms, like Android app stores, to perform these operations natively on your behalf. We'll launch these APIs over the next few months. ## What’s next * **June 2026:** Starting this month, we are rolling out a new system service that will be automatically installed on most Android devices. This service will be used later this year to verify developer registration. * **July 2026:** We’ll launch the Android Developer ID Status API globally and begin early access for the Android Developer Console API. Early access also starts for limited distribution accounts on Android Developer Console. This new type of Android developer account is designed for students, hobbyists, and learners and lets you share your apps to up to 20 devices without a government-issued ID or a fee. * **August 2026:** Limited distribution accounts and the new Android Developer Console API will launch globally. We’ll also launch an advanced flow for installing apps from unverified developers, which includes security checkpoints to resist coercion scams, while allowing power users to maintain the ability to sideload apps from unverified developers. * **September 30, 2026:** App registration becomes required for **participating stores in Brazil, Indonesia, Singapore, and Thailand**. Unregistered apps can be sideloaded with Android Debug Bridge (adb) or advanced flow. * **2027 and beyond:** After incorporating the feedback from our partners, users, and developer community, we’ll expand the Android verification requirement globally. ## Get started with Android developer verification If you distribute apps in Brazil, Indonesia, Singapore, or Thailand via the stores listed above, please ensure your verification is complete by the September deadline. * **Google Play developers:** Most Play developers are already verified, and over 99% of their apps have been registered. Go to your Play Console Home page to see your app’s verification status, and register apps you want to continue distributing that weren't automatically registered. * **Developers who distribute only outside of Google Play:** Sign up for the Android Developer Console today to register your apps. * **Students and hobbyists:** Sign up here for early access to limited distribution accounts to help us refine the feature with your feedback. Thank you for helping us build a safer Android ecosystem. Stay tuned for more updates as we approach September and the 2027 global rollout.

_Posted by Coco Fatus, UX Designer, Alon Hetzroni, UX Engineer, Azin Mehrnoosh, Product Manager Android XR_ _ _ _ _ _ _ At this year's Google I/O, we announced an update for spatial experiences: the Geospatial API is now available as a preview in ARCore for Jetpack XR. By bringing Google's Visual Positioning System (VPS) to Android XR, Android XR enables anchoring digital content to the physical world with sub-meter accuracy and precise orientation in supported areas.* To explore what the Geospatial API could unlock, our team built a demo: the XR Geospatial Tour. Imagine walking into a new city, putting on a pair of wired XR glasses (like the upcoming XREAL Project Aura), and instantly having a knowledgeable, local guide showing you around. You don't need to stare down at a 2D map—instead, 3D models gently guide your path, and an intelligent voice tells you about the historical landmarks right in front of you. We combined the Geospatial APIs, Gemini API using Firebase AI Logic, Google Maps Grounding, and Jetpack XR SDK to create a hands-free, immersive walking tour experience. *Disclaimer: Video and Tour Guide application are for demonstration purposes only. Some sequences have been shortened. Any hardware depicted may be under development; final product details may differ. Let’s walk through the implementation details and show how we tied these APIs together to build a world-scale spatial experience. ### 1. Pinpointing the User with ARCore Geospatial API (VPS) Enhance your navigation experience on XR by combining the power of GPS with the precision of VPS. The accuracy and precise orientation that comes with VPS allows 3D waypoints to align with the physical world. This is why the Geospatial API on Android XR can help you build custom experiences. By using advanced computer vision, VPS tries to provide a GeospatialPose (including latitude, longitude, and heading) that is more accurate than GPS. Here's how we retrieve the user's Geospatial pose by mapping the device's orientation to a Geospatial coordinate: // Retrieve the current geospatial pose from the ARCore session val result = geospatial.createGeospatialPoseFromPose(arDevice.state.value.devicePose) if (result is CreateGeospatialPoseFromPoseSuccess) { val pose = result.pose Log.d("VPS", "Accurate Location: ${pose.latitude}, ${pose.longitude}") } Because the entire experience relies on this accuracy, we monitor the horizontalAccuracy and orientationYawAccuracy until they meet our thresholds. If the user is indoors or in an unrecognized area, we prompt them to "walk to an outdoor public space and look around". ### 2. Crafting the Itinerary with Gemini API & Google Maps Grounding Once we have a location, we use the Gemini API using Firebase AI Logic to prompt the Gemini model to act as a local tour guide. We pass the user's coordinates to the model and ask it to output a structured JSON response containing nearby walking tours: val configForTools = ToolConfig( functionCallingConfig = null, retrievalConfig = retrievalConfig { latLng = FirebaseLatLng(pose.latitude, pose.longitude) languageCode = "en" } ) val responseJsonSchema = Schema.obj( mapOf( "locationIntro" to Schema.string(), "tours" to Schema.array( Schema.obj( mapOf( "title" to Schema.string(), "description" to Schema.string(), "stops" to Schema.array( Schema.obj( mapOf( "name" to Schema.string(), "detailedName" to Schema.string(), "description" to Schema.string() ) ) ) ) ) ) ) ) val model = Firebase.ai(backend = GenerativeBackend.googleAI()).generativeModel( modelName = "gemini-3.5-flash", tools = listOf(Tool.googleMaps()), generationConfig = generationConfig { responseMimeType = "application/json" responseSchema = responseJsonSchema } ) val result = model.generateContent("The user is at latitude ${pose.latitude} and longitude ${pose.longitude}. Generate exactly 3 diverse tours near this location (e.g., historical, food, nature). All tour ideas should be walking distance only.") Large Language Models are great at generating rich descriptions, but they can sometimes hallucinate exact latitude/longitude coordinates. To solve this, we used Google Maps Grounding to ground the AI. ### 3. A Voice to Guide You: Gemini 2.5 TTS To make the tour guide feel truly present, we implemented dynamic voiceovers. Using the gemini-2.5-flash-tts model, we can configure our model generation config to natively return audio data instead of just text! Here’s how you can request the ResponseModality.AUDIO: val ttsModel = Firebase.ai(backend = GenerativeBackend.googleAI()) .generativeModel( modelName = "gemini-2.5-flash-tts", generationConfig = generationConfig { // Instruct the model to return Audio responseModalities = listOf(ResponseModality.AUDIO) } ) val response = ttsModel.generateContent("Say in a neutral but positive voice:\n$prompt") // Extract the raw audio bytes from the response val audioBytes = response.candidates.firstOrNull()?.content?.parts ?.filterIsInstance<InlineDataPart>() ?.firstOrNull { it.mimeType.contains("audio") }?.inlineData ### 4. Bringing it to Life in 3D with Jetpack XR The final piece of the puzzle is rendering this data in the user's field of view. The Jetpack XR SDK makes it intuitive to transition from a 2D Android UI to spatial computing. We used Jetpack Compose for XR to build spatial components. To represent points of interest along the tour, we built a Composable called InfoSphere, which contains a GltfModel of a 3D orb that floats in space and can be interacted with to reveal information. Using Jetpack XR SDK, we can place 3D models alongside the Compose UI using SpatialBox and SceneCoreEntity. We also used InteractableComponent to respond to user taps. @Composable fun InfoSphere( content: InfoBubbleContent, session: Session, sphereModel: GltfModel, isSelected: Boolean, onClick: () -> Unit ) { // SpatialBox lets us arrange 3D components and SpatialPanels together SpatialBox( SubspaceModifier .offset(x = 2.dp, y = 1.dp, z = (-3).dp) // Positioned in 3D space ) { // Smoothly animate the visibility of our 2D Compose UI Panel AnimatedSpatialVisibility(visible = isSelected) { SpatialPanel { InfoBubble(content) // Regular 2D Compose UI } } // Render our interactive 3D sphere SceneCoreEntity( factory = { GltfModelEntity.create(session, sphereModel).also { entity -> // Make the 3D model respond to user taps entity.addComponent(InteractableComponent.create(session) { inputEvent -> if (inputEvent.action == InputEvent.Action.UP) { onClick() } }) } } ) } } By combining AnimatedSpatialVisibility for traditional Compose UI surfaces with SceneCoreEntity 3D elements, we're able to seamlessly blend data into the physical world. ### Explore what’s possible with Android XR today Building the XR Geospatial Tour app showed us that the barrier to entry for world-scale spatial experiences is lower than ever for Android developers. With the Geospatial API now available in preview on Android XR, your apps can seamlessly understand the physical world around them. By combining Compose for XR’s APIs with the high-precision location data of VPS and the generative capabilities of Gemini, we can create experiences that understand both where the user is and what they are looking at. To help you get hands-on with Android XR, we are thrilled to open applications for the Android XR Developer Catalyst Program, which includes XREAL Project Aura. Starting today, you can apply to get access to an XREAL Project Aura devkit or our display glasses devkit over the coming months! *Disclaimer: Available on select devices. Internet connection required. Works on compatible apps and surfaces. Results may vary.

_Posted by Matthew McCullough, VP of Product Management, Android Developer_ Today we're releasing Android 17 and making it available on most supported Pixel devices. Look for new devices running Android 17 in the coming months. Android 17 marks the start of our transition to an intelligence system, putting your apps at the center. It's shifting to an adaptive-first development standard by introducing mandatory large-screen resizability, all while delivering next-generation privacy, security, media, camera, and performance. We'll cover all that in this post, as well as how we're bringing together next generation tools, libraries, and agent skills to help your apps embrace the opportunity. Throughout the past year, from our Canary channel to our Beta releases, we’ve collaborated with you in the developer community to build a platform you and your users can trust. To that end, this moment marks the availability of the source code at the Android Open Source Project (AOSP). This allows you to examine the source code for a deeper understanding of how Android works. Let's dive deeper into Android 17. ### An intelligence system With deep integration between hardware, software and AI, we’re transforming Android from an operating system to an intelligence system. It's about delivering new helpful experiences that anticipate user needs, and it brings more opportunities for engagement with your apps. To that end, Android 17 expands the capabilities of AppFunctions, a platform API with a corresponding Jetpack library. It allows you to contribute your app's unique capabilities as orchestratable "tools" for Android MCP, the on-device equivalent of the Model Context Protocol. AI agents and assistants (like Google Gemini) can discover and execute AppFunctions to perform workflows on behalf of the user with direct access to the app's local state. The Jetpack library, currently in alpha, makes adding AppFunctions as easy as annotating a class and adding KDoc comments. /** * A note app's [AppFunction]s. */ class NoteFunctions( private val noteRepository: NoteRepository ) { /** * Adds a new note to the app. * * @param appFunctionContext The execution context. * @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 { return noteRepository.createNote(title, content) } } We’ve also launched an AppFunctions agent skill that analyzes your app’s key workflows, automatically generates the required Kotlin code, optimizes your KDocs for LLM tool-calling, and provides ADB commands for testing and debugging. The Gemini integration is currently in a private preview with trusted testers, but you can begin preparing your apps now. In addition to ADB commands to execute your AppFunctions, we've provided a test agent app that includes an interface to discover and execute your app functions and simulate an AI agent integration. Join our integration early access program at goo.gle/eap-af for a chance to be among the first apps to deploy AppFunctions to production. ### Adaptive-first Your users no longer rely on a single form factor; they transition between phones, foldables, tablets, laptops, automotive displays, and immersive XR environments. Now, with over 580 million large screen devices in the hands of users and the forthcoming launch of Googlebooks, the next generation of ChromeOS built on the Android stack, adaptive is no longer just a technical goal. It’s a massive opportunity to reach highly engaged users, which is one of the reasons we're shifting to an adaptive-first development standard. ## No resizability/orientation restrictions on large screens To ensure apps deliver a premium experience across all form factors, including mobile devices running in desktop mode on connected displays, Android 17 (API level 37) removes the developer opt-out for orientation and resizability restrictions on large screen devices (sw > 600 dp) for apps targeting API level 37. The system will ignore legacy manifest attributes and runtime APIs, including screenOrientation, setRequestedOrientation(), resizeableActivity=false, and aspect ratio constraints (minAspectRatio/maxAspectRatio). Games (based on app category in Google Play) remain exempt. Your app must be ready to adapt to any window size, respect the user's preferred device posture, and support free-form windowing natively. ## Next-gen multitasking: App Bubbles, Bubble Bar, and desktop interactive PiP Android 17 introduces powerful new windowing capabilities that redefine how users multitask, demanding even greater layout flexibility from your apps: * **App Bubbles:** Moving beyond the messaging bubbles API, users can now transform any app into a floating bubble by long-pressing its icon on the launcher. This feature is available across phones, foldables, and tablets, enabling lightweight multitasking for any workflow. * **The Bubble Bar:** On large screens (tablets and foldables), the system taskbar now includes a dedicated Bubble Bar to organize, transition between, and dock these floating app bubbles. * **Desktop interactive PiP:** In desktop environments, Android 17 introduces interactive Picture-in-Picture (PiP). Unlike traditional PiP windows which are read-only, these pinned windows remain fully interactive while staying always-on-top of other application windows. _App Bubbles and Bubble Bar in action_ ## Activity recreation updates To prevent disruptive state loss and stutter, Android 17 updates the default behavior for Activity recreation. The system will no longer restart activities by default for typical configuration changes that do not require a full UI redraw (including CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_TOUCHSCREEN, and CONFIG_COLOR_MODE). Instead, running activities will receive these updates via onConfigurationChanged(), enabling smooth transitions. If your application explicitly relies on a full restart to reload resources for these changes, you must now explicitly opt-in using the new android:recreateOnConfigChanges manifest attribute. ## Continue On Android 17 adds Continue On to help users seamlessly transition a task between Android devices. The user sees a suggestion for the most recently opened app from their mobile device in their tablet taskbar, providing a one-tap affordance to launch the app and deep-link where they left off. Continue on can support app-to-web transitions, including falling back to using the web if the app isn't installed. _Handoff Suggestion on a Tablet_ class MyHandoffActivity : Activity() { ... override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // Do stuff ... // Enable handoff setHandoffEnabled(true, null) } // Override and implement onHandoffActivityDataRequested override fun onHandoffActivityDataRequested(handoffRequestInfo: HandoffActivityDataRequestInfo) : HandoffActivityData { // Create and return handoff data } } ## Go adaptive-first with Jetpack Compose To help you adapt your apps to meet the new Android 17 requirements, we've launched the Jetpack Compose adaptive skill. This AI-powered developer workflow helps you implement the best adaptive practices: * **Adaptive navigation:** Automatically transition between bottom navigation bars on mobile and edge-anchored navigation rails on large screens using NavigationSuiteScaffold from the Material 3 Adaptive library. * **Multi-pane layouts:** Implement list-detail and supporting pane layouts natively using Navigation 3 Scenes (ListDetailSceneStrategy and SupportingPaneSceneStrategy) instead of fragile fragment transactions. * **FlexBox & Grid APIs:** Utilize Compose 1.11's dynamic layout components to easily adjust row and column spans on the fly, ensuring your content always fills the space beautifully. * **Advanced non-touch input:** Leverage Compose 1.11's enhanced trackpad and mouse support, including native focus rings and new APIs (like TrackpadInjectionScope and performTrackpadInput) to easily test and deliver a true "laptop-class" experience on Googlebooks and Desktop Mode. * **Dynamic window states:** Leverage Compose's reactive state model to seamlessly adapt your UI when the app transitions from full screen to a floating App Bubble or an interactive Desktop PiP window, ensuring a premium experience even at minimal dimensions. ## Android is Compose-first Compose offers the easiest way to build adaptive apps, and that's just one of the many reasons we believe that all Android UI should be built with Compose. To that end, Android development is now Compose-first. All new Android APIs, libraries, tools, and developer guidance will be built exclusively for Jetpack Compose. Legacy View components (in the android.widget package) and View-based Jetpack libraries (like Fragments, RecyclerView, and ViewPager) are now in maintenance mode. They will receive only critical bug fixes, and no new features. > **TIP** > Ready to migrate? Use our AI-driven XML to Compose Migration Skill to automatically analyze your legacy View layouts and convert them into highly-adaptive Compose code. ### Performance & efficiency App performance means a smooth user interface, fast app start times, and efficient multitasking; Android 17 has impactful improvements in all of these areas. ## App memory limits Memory usage is one of the silent foundations of overall performance. When a foreground app or service grows unchecked, memory management spikes CPU and battery utilization and eventually leads to the termination of other well-behaved cached apps and background jobs, ultimately forcing slower cold starts and impaired multitasking. Starting in Android 17, the system will enforce strict app memory limits based on a device's total RAM, abruptly terminating offending processes. New things to help you navigate these tighter requirements: * **R8 Optimizer:** The R8 optimizer significantly reduces your app's bytecode memory footprint by shrinking classes, methods, and fields into shorter names, and stripping out unused code and resources. Use R8 in full mode along with the new R8 configuration analyzer to make sure your app is getting the most from R8. _ _ _ _ The R8 Configuration Analyzer * **LeakCanary in Android Studio Panda:** The profiler now features native LeakCanary integration as a dedicated task, fully integrated with your IDE and source code. * **ApplicationExitInfo:** If your app is terminated by these limits, getDescription() from ApplicationExitInfo will return "MemoryLimiter:AnonSwap". * **On-Device Anomaly Detection:** Part of ProfilingManager, you can leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached. val profilingManager = applicationContext .getSystemService(ProfilingManager::class.java) val triggers = ArrayList<ProfilingTrigger>().apply { add(ProfilingTrigger.Builder( ProfilingTrigger.TRIGGER_TYPE_ANOMALY).build()) } profilingManager.addProfilingTriggers(triggers) And, we're working to surface more in-field memory metrics to you within Google Play Console. ## Generational garbage collection Android 17 introduces more frequent, less resource-intensive young-generation collections to ART's Concurrent Mark-Compact garbage collector (GC). By separating short-lived objects from stable, long-lived ones, the system runs frequent, lightweight "young-generation" sweeps rather than expensive full-heap scans, drastically reducing CPU usage, power drain, and UI stutter. Our testing has shown significant improvements in GC interference with application threads and a reduction in the maximum memory resident set size (RSS). ART improvements are also available to over a billion devices running Android 12 (API level 31) and higher through Google Play System updates. ## Lock-Free MessageQueue For apps targeting SDK 37 or higher, the core android.os.MessageQueue now implements a lock-free architecture, significantly reducing missed frames, improving app startup time, and radically improving the performance of busy queues in multithreaded scenarios. Note: This can break apps that use reflection on private MessageQueue fields and methods. The peekWhen and **poll** APIs have been added to TestLooperManager for instrumentation testing without relying on MessageQueue internals. ## Static final fields now truly final Starting from Android 17, apps targeting SDK 37 or higher won’t be able to modify “static final” fields, allowing the runtime to apply performance optimizations more aggressively. An attempt to do so via reflection (or deep reflection) will lead to an IllegalAccessException being thrown. Modifying them via JNI’s **`SetStatic<Type>Field`** methods family will immediately crash the application. ## Custom notification view restrictions To reduce memory usage we are further restricting the size of custom notification views. This update closes a loophole that allows apps to bypass existing limits using URIs. This behavior is gated by the target SDK version and takes effect for apps targeting API 37 and higher. ### Privacy & Security Maintaining user trust is at the heart of the Android ecosystem. Android 17 introduces robust features that protect sensitive data while simplifying user experiences. ## Privacy-preserving choices Historically, apps required broad, permanent permissions to access information like contacts, precise location and media files. Android 17 continues the shift toward privacy-preserving choices that grant temporary, session-based access only to the data the user explicitly selects: * **System-Level Contact Picker:** Utilizing `ACTION_PICK_CONTACTS`, apps can request temporary access only to specific fields (e.g., email or phone number) chosen by the user, eliminating the need for the broad `READ_CONTACTS` permission. It also fully supports work/personal profile separation. * **Customizable Photo Picker aspect ratio:** Using**`PhotoPickerUiCustomizationParams`** , you can customize the system photo picker to show thumbnails in portrait mode. This is perfect for apps that always display photos and videos in portrait such as video based social media apps. * **System-rendered Location Button:** A new system-rendered location button that you can embed in your app grants precise location access for the current session only. * **EyeDropper API:** A new system-level API, `ACTION_OPEN_EYE_DROPPER`, allows your app to create a system-powered eyedropper enabling the user to select color from any pixel on the display. This provides a secure, privacy-preserving color-picking experience that eliminates the need for broad, sensitive screen capture or media projection permissions. val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result -> if (result.resultCode == Activity.RESULT_OK) { val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK) // Use the picked color in your app } } fun launchColorPicker() { val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER) eyeDropperLauncher.launch(intent) } ### ### ### ### ### ### ### ### ### ### _Picking a color from anywhere on the screen with the system EyeDropper_ ## Local network access Apps targeting Android 17 now either require the `ACCESS_LOCAL_NETWORK` runtime permission or the use of system-mediated, privacy-preserving device pickers for local network communication, such as talking to smart home devices or casting receivers. Because `ACCESS_LOCAL_NETWORK` falls under the existing `NEARBY_DEVICES` permission group, users who have already granted other `NEARBY_DEVICES` permissions will not be prompted again. ## SMS OTP protection Android 17 expands SMS one-time-password (OTP) protection by delaying access to SMS messages for three hours: * WebOTP Format: Delayed for all apps that are not the intended recipient (domain mismatch). * Standard SMS OTP: Delayed for all apps targeting SDK 37+. * Exemptions: Default SMS, assistant, and connected companion apps are exempt. Apps are strongly encouraged to migrate to the SMS Retriever or SMS User Consent APIs. ## Post-Quantum Cryptography (PQC) Android 17 is ready for the next generation of cryptographic security: * Keystore Integration: Supported devices can generate ML-DSA (Module-Lattice-Based Digital Signature Algorithm) keys in secure hardware to produce quantum-safe signatures, exposed via standard JCA APIs. * Hybrid APK Signing: Introducing the v3.2 APK Signature Scheme, which combines classical signatures with ML-DSA signatures to secure app delivery. ## Safer native dynamic code loading If your app targets SDK 37 or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries. All native files loaded using System.load must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError ## Smarter password protection for physical inputs With Android 17, we're making it safer to enter passwords, PINs, and other secrets when using a physical keyboard by no longer showing the last typed character by default. Users can still easily customize these display settings to match their preferences (availability may vary by device manufacturer). These enhanced privacy protections are automatically supported byAndroid's built-in SDK components and will be supported in Compose 1.12 for SecureTextFields. ### ### ### ### _ _Smarter password protection for physical inputs_ _ ## Media and camera features that empower creators and delight users Android 17 introduces new creator features that give access to pro-quality cameras and media, all while improving the experience for consumers. * Eclipsa Video: HDR video standard built upon the SMPTE ST 2094-50 specification that introduces new metadata to help devices adapt content for their display headroom and ambient light conditions, as well as improve the simultaneous display of standard and HDR content. * RAW14 image format: New support for the RAW14 image format provides a way for your professional camera app to capture the highest level of detail and color depth from compatible camera sensors. * Vendor-defined camera extensions: Vendor-defined extensions enable hardware partners to define and implement custom camera extension modes, providing access to the best and latest camera features. * Extended HE-AAC software encoder: A new system-provided Extended HE-AAC software encoder, supports both low and high bitrates using unified speech and audio coding, providing significantly better audio quality for voice messages in low-bandwidth conditions, including support for loudness metadata. * Versatile Video Coding (H.266): Enables OEMs to add codec support by defining the video/vvc MIME type in MediaFormat, adding new VVC profiles in MediaCodecInfo, and integrating support into MediaExtractor. * Camera device type: New APIs that query the underlying device type to identify if a camera is built-in hardware, an external USB webcam, or a virtual camera. * Constant Quality for Video Recording: SetVideoEncodingQuality in MediaRecorder configures a constant quality (CQ) mode for video encoders to ensure uniform visual fidelity across the entire video. ## Better support for hearing aids * Bluetooth LE Audio hearing aid support: Android now includes a specific device category for Bluetooth Low Energy (BLE) Audio hearing aids with the new AudioDeviceInfo.TYPE_BLE_HEARING_AID constant, so your app can distinguish hearing aids from regular headsets to provide a tailored experience for users with assistive listening devices. * Granular audio routing for hearing aids: Android 17 allows users to independently manage where specific system sounds are played. They can choose to route notifications, ringtones, and alarms to connected hearing aids or the device's built-in speaker, helping to avoid unwanted in-ear interruptions while maintaining a Bluetooth connection for hearing aid management apps. ## CameraX and Media3 CameraX and Media3 have been updated for Android 17. They are there to do the heavy lifting, smoothing the rough edges of media development and simplifying building reliable camera capture, smooth media playback, and creative and complex editing experiences. We've released an agent skill that can migrate legacy Android camera implementations (Camera1 or raw Camera2 APIs) to CameraX. Note: You'll need to update your CameraX version to either 1.5.2 or 1.6.0+ to avoid a crash related to an added dynamic range mode on Android 17 devices. ### Get your apps, libraries, tools, and game engines ready! If you develop an Android SDK, library, tool, or game engine, it's critical to prepare any necessary updates now to prevent your downstream app and game developers from being blocked by compatibility issues and allow them to target the latest SDK features. Please let your downstream developers know if updates are needed to fully support Android 17. Testing involves installing your production app or a test app making use of your library or engine using Google Play or other means onto a device or emulator running Android 17 Beta 4. Work through all your app's flows and look for functional or UI issues. Each release of Android contains platform changes that improve privacy, security, and overall user experience; review the app impacting behavior changes for apps running on and targeting Android 17 to focus your testing, including the following: * Resizability on large screens: Once you target Android 17 (SDK 37), you can no longer opt out of maintaining orientation, resizability and aspect ratio constraints on large screens. * Dynamic code loading: If your app targets SDK 37 or higher, the Safer Dynamic Code Loading (DCL) protection introduced in Android 14 for DEX and JAR files now extends to native libraries. All native files loaded using System.load() must be marked as read-only. Otherwise, the system throws UnsatisfiedLinkError. * Enable CT by default: Certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.) * Local network protections: Apps targeting SDK 37 or higher have local network access blocked by default. Switch to using privacy preserving pickers if possible, and use the new ACCESS_LOCAL_NETWORKpermission for broad, persistent access. * Background audio hardening: Starting in Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs. Based on your feedback, we’ve made some changes since beta 2, including targetSDK gating while-in-use FGS enforcement and exempting alarm audio. Full details available in the updated guidance. * NPU access declaration: Apps targeting Android 17 that need to directly access the NPU must declare FEATURE_NEURAL_PROCESSING_UNIT in their manifest to avoid being blocked from accessing the NPU. This includes apps that use the LiteRT NPU delegate, vendor-specific SDKs, as well as the deprecated NNAPI. ### Get started with Android 17 Your Pixel device should get Android 17 shortly if you haven't already been on the Android Beta. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio. If you are currently on Android 17 Beta 4.1 and have not yet taken an Android 17 QPR1 beta, you can opt out of the program and you will then be offered the release version of Android 17 over the air. ### Getting the Android 17 beta on partner devices Android 17 is available in beta on handset, tablet, and foldable form factors from partners including Honor, iQOO, Lenovo, OnePlus, OPPO, Realme, Sharp, vivo, and Xiaomi. ### For the best development experience with Android 17, we recommend that you use the latest Canary build of Android Studio Quail. Once you’re set up, here are some of the things you should do: Test your current app for compatibility, learn whether your app is affected by changes in Android 17, and install your app onto a device or Android Emulator running Android 17 and extensively test it. Thank you again to everyone who participated in our Android developer preview and beta program. We're looking forward to seeing how your apps take advantage of the updates in Android 17, and have plans to bring you updates in a fast-paced release cadence going forward. For complete information on Android 17 please visit the Android 17 developer site.

_Posted by Stevan Silva, Group Product Manager, and Vinny DaSilva, Developer Relations Engineer, Android XR_ From augmented overlays to fully immersive environments, the Android XR ecosystem is expanding rapidly, with the Samsung Galaxy XR already available today. Alongside the latest updates from Google I/O and this week's Augmented World Expo (AWE), we are rolling out new tooling, broader engine support, and ecosystem resources to help you build and scale experiences for Android XR. To get a quick look at what’s new, check out our video recap! Ready to dive deeper? Let’s jump into the major updates that will streamline your XR development workflow. ## Build, Prototype, and Iterate with Developer Preview 4 Developer Preview 4 of the Android XR SDK delivers the APIs and tools you need to design and build right from your laptop. This update includes the specific libraries required to target both immersive and augmented experiences. Check out the video below for a comprehensive breakdown of the latest in Android XR: To test all of these interactions without needing physical hardware, you can emulate and iterate on your code entirely within Android Studio. Check out our tooling deep dive to see how you can use XR emulator today: ## Extending your mobile apps for intelligent eyewear Building for audio and display glasses doesn't mean starting from scratch. With the Jetpack Projected library, you can take your existing mobile app to create a complementary augmented experience. The new release includes a Device Availability API that hooks into standard Android Lifecycle states, allowing your app to natively adapt its behavior based on whether the glasses are being worn. To accelerate your development journey, use Android CLI and the display glasses skill to extend your mobile app into an augmented experience. The skill is packed with specialized knowledge of Jetpack Compose Glimmer, enabling it to build your UI using our recommended design patterns. We’ve also updated Jetpack Compose Glimmer to optimize text legibility on optical see-through displays and provide touchpad-optimized navigation components. See how it looks in action: Developers at NAVER Papago are already exploring how to seamlessly bring their mobile experience directly to display glasses. To learn how to leverage these tools, watch this session on extending mobile apps for AI glasses: ### Building global, location-based immersive experiences For developers focused on immersive experiences, Developer Preview 4 brings modern, Kotlin-first architectural upgrades across our core perception libraries. We have also introduced an early preview of the Geospatial API for wired XR glasses. By combining ARCore for Jetpack XR with Google's Visual Positioning System (VPS), you can anchor digital content to high-precision real-world locations. ### Leverage the Platforms You Know with Expanded Engine Support We want you to build using the ecosystems and workflows you already know best. To make it easier to bring your existing XR experiences over to Android XR, we are thrilled to introduce official support for Unreal Engine and Godot alongside our existing Unity's support for wired XR glasses. With this expansion, we are introducing the Android XR Engine Hub, a desktop tool for Windows that shortens iteration cycles by bringing real-time testing directly into your engines viewport. Catch the full breakdown of our engine updates here: ### Apply Today for the Android XR Developer Catalyst Program In addition to providing the platform, we want to fuel your innovation directly through ecosystem resources. The Android XR Developer Catalyst Program is designed to support developers with access to pre-release hardware, including display glasses, and wired XR glasses. Accepted developers will receive resources, support forums, and launch guidance to prepare their apps for Google Play. Applications are open right now, so don't wait to submit your project ideas. ### Start Building! The ecosystem is growing rapidly, and the tools are ready for you to explore. Samsung Galaxy XR is available now, and you can dive in today with Developer Preview 4 of the Android XR SDK. If you don’t have hardware yet, check out the tools and to get started with the XR Emulator in Android Studio. For a complete look at all of our technical sessions, browse the full Android XR Playlist on YouTube to see what else is possible. We can’t wait to see what you build!

_Posted by Simona Milanovic, Developer Relations Engineer_ _ _ Every year, Google I/O brings new announcements and resources across ecosystems and products, including Android development. As development shifts toward AI and agent-assisted tooling, we’ve expanded our offerings to better support you, however you decide to build for Android. To help you stay up to date, here is a summary of the**top 3 announcements for Android Developer Productivity at I/O**. ## 1. Android CLI is now stable Android CLI is now **stable at version 1.0** , with more capabilities and integrations. The latest version of Android CLI introduces many new features, like programmatic version lookup and support for Journeys, and bridging capability to allow agents to **integrate directly with Android Studio** , via the studio command. Running Android Studio alongside the agent and Android CLI enables more efficient navigation in your project, more precise output, and access to **Android Studio’s unique tooling** , such as performance profilers, Compose Previews, and Android Device Streaming. _Android CLI now integrates seamlessly with Android Studio_ Additionally, Google Antigravity now officially supports Android development, with the **Android resources bundle** , which includes the Android CLI and skills. You can either install the bundle during onboarding after installation, or later from the **Settings > Customizations > Build With Google Plugins** menu. This provides Antigravity with all the powerful tools and knowledge of Android CLI to enable it to perform core tasks—from creating projects to deploying your app on a new virtual device—much more easily and efficiently. _Google Antigravity now offers the Android resources bundle_ Android CLI is now available through more package managers: like `npm` and `homebrew`. For more information, check out the Android CLI blog post and official documentation. ## 2. Android skills keep growing To help models gain expertise for specific development patterns that follow our best practices, we are continuing to **expand our repository of Android skills** , available through Android CLI and GitHub. Android skills ground LLMs in **specialized workflows and domain knowledge,** for the most common and more complex user journeys they might struggle with. We’ve shipped a fresh **new batch of skills,** with now more than 17 skills for areas such as: * Adaptive UI * Display Glasses and Jetpack Compose Glimmer for XR * Migration to CameraX * Perfetto SQL and Trace Analysis * Jetpack Compose Styles API * AppFunctions * Verified email retrieval with Android Credential Manager * Engage SDK integration * Testing setup * Wear OS Jetpack Compose Material3 _Android skills keep growing_ _ _ You can browse skills and install using the Android CLI commands: android skills list android skills add –skill=<skill-name> For more information, check out the official documentation. ## 3. Android Bench adds new models Earlier this year, we launched Android Bench - our leaderboard for **testing LLMs on real-world Android development** challenges and tasks, with the goal of accelerating model improvements, so you have more helpful options for AI assistance. _Latest results from Android Bench leaderboard_ You asked us to evaluate open models. So, at I/O, we added more commonly used ones, including our local model **Gemma 4** , to the leaderboard. We also added the latest models including **Gemini 3.5 Flash.** We are also working on increasing the difficulty of challenges we’re giving LLMs, including creating long running tasks, to continue encouraging improvements. These tasks will be coming soon to Android Bench. Check out the Android Bench leaderboard to see the latest results. ## Android development anywhere By expanding our AI-assisted Android development offerings to Antigravity, through Android CLI and Android skills, and solidifying with the pro capabilities and production grade polish of Android Studio, we’re **supporting Android developers wherever they choose to build.** Have fun bringing your ideas to life faster and easier than ever before - we’re excited to see what you build in this new era of agentic development. Check out the full Developer productivity at Google I/O 2026 YouTube playlist for more information.

Posted by Alice Yuan, Developer Relations Engineer at Google, Arti Arutiunov, Product Manager at Datadog and Nikita Ogorodnikov, Staff Software Engineer at Datadog Performance regressions are notoriously hard to reproduce, making regressions a massive bottleneck for mobile developers. Although signals like ANR rates indicate what issues occur in production, pinpointing the specific line of code that resulted in the performance issue has historically necessitated exhaustive manual reproduction or speculative trial-and-error experimentation. Datadog collaborated with Google to mitigate this frustration by integrating the ProfilingManager API (available on Android 15+ devices) into its Real User Monitoring (RUM) and Continuous Profiling platforms. This integration transforms the debugging workflow, allowing developers to move beyond surface-level symptoms to being able to detect the _why_ behind a performance bottleneck. By leveraging this system-level API, Datadog now processes millions of production profiles weekly across the globe according to Datadog internal data of June 2026. It provides engineering teams with a new level of visibility into real-world performance, all while maintaining a low runtime overhead for production-scale performance monitoring. ### The impact of ProfilingManager ProfilingManager is a system service introduced in Android 15 that enables apps to programmatically collect performance data such as call stack samples, field traces and memory heap dumps directly from production environments. This capability shifts the engineering paradigm from reactive manual reproduction to proactive field analysis. For example, a Google communications app used field traces to investigate why its cold start times were slower on newer, more powerful hardware. By diving into the field-collected traces and comparing traces across different device types, the engineer discovered a hidden scheduling issue: a background text-to-speech service was unnecessarily being prewarmed during app startup. The traces revealed that this background process was monopolizing the device's highest-performing big CPU core, forcing the app's main thread to sleep while the prewarm occurred. ### Solving the Android code-level visibility challenge Prior to the implementation of ProfilingManager, Datadog’s Real User Monitoring (RUM) focused on high-level application health and session-level telemetry to assess the user journey. Engineering teams could monitor Android performance signals like time to initial display, ANR rates, CPU load, and frozen frames. These insights extended to granular interactions, such as network latency, touch events, and main thread hangs. However, while this data effectively highlighted which performance bottlenecks were surfacing in the field, it provided no clear path to identifying the root cause of these failures. To address this, Datadog needed a profiling engine capable of capturing Android traces directly from devices in production with minimal performance impact. After evaluating alternative approaches, such as writing their own trace processor using Android Debug APIs, the team selected ProfilingManager because it is the most performant solution of the profiling options they evaluated and offloads the sampling decisions overhead to the OS. ProfilingManager supports a wide range of collection methods, including CPU traces, call stack sampling, memory analysis through Java heap dumps and native heap profiles. It enables developers to profile production builds, upload trace files to external storage, and review them in the Perfetto trace analyzer UI. As a SaaS provider, Datadog uploads, visualizes, and analyzes these profiles collected via its SDK, providing a unified view of application health. By centralizing high-fidelity telemetry within a unified observability API, ProfilingManager empowers Datadog and its clients to proactively monitor, investigate, and remediate complex Android performance regressions through key technical advantages: * **Granular session diagnostics:** ProfilingManager enhances debuggability by delivering direct OS-level trace data, overcoming the visibility and alignment challenges typical of custom logging with system services. To dive deeper, developers can download these traces from Datadog to investigate further in visualization tools like the Perfetto UI. * **Automated telemetry triggers:** By leveraging native system events to initiate trace recordings at key optimization points, Datadog reduces the need to build custom collection logic. While the initial rollout focuses on the APP_FULLY_DRAWN signal, there are already plans to expand this observability to include ANR, OOM, and COLD_START triggers. * **Proactive trace snapshots:** By interfacing directly with the system-level Perfetto service (traced), ProfilingManager utilizes a proactive background recording model designed to capture unpredictable issues. This ensures that developers receive a precise visualization of the events leading up to a performance anomaly, offering a level of insight that exceeds what is possible through manual instrumentation. * **Bottleneck detection at scale:** Datadog is able to synthesize telemetry from across Datadog’s global customer base to uncover regressions that only emerge under unique hardware configurations and variable network environments. * **System-enforced resource stability:** The API leverages sampling trace collection to ensure performance and user experience impacts remain unnoticeable. * **On-device data controls:** ProfilingManager filters out irrelevant information from other processes on-device before the profile is delivered to the app. This minimizes file sizes and ensures that only data relevant to the app's processes is provided. ### Processing millions of weekly profiles to optimize real-world apps _ _An example of Datadog's time to initial display measurement with_ _stack sampling powered by ProfilingManager_ _ Integrating a system-level profiling API into a global monitoring SDK required solving infrastructure challenges. Because ProfilingManager generates highly detailed performance traces, the Datadog engineering team had to build a pipeline capable of parsing and analyzing these profiles on the server side at scale. Beyond profile collection, Datadog also emphasizes the importance of balancing sampling frequency with collecting enough data to generate meaningful insights about your application. Datadog relies on ProfilingManager’s built-in rate limiting as a critical stability safeguard, preventing excessive telemetry requests from overburdening user devices. The team has been profiling Datadog's own native Android application and a number of early adopters’ applications for months, gathering millions of profiles to ensure a fast, error-free launch experience and to refine their performance-detection algorithms. Today, the production integration seamlessly scales across a variety of Android devices. ### Conclusion By integrating Android’s ProfilingManager API, Datadog successfully closed the visibility gap between backend systems and mobile client applications for their customers. By processing millions of profiles weekly with negligible device overhead, Datadog equips Android developers with the code-level insights necessary to diagnose complex performance bugs instantly, helping developers build smoother applications and improve their app’s performance signals in the Play Store. To adopt the ProfilingManager API directly into your performance observability framework, check out our documentation. In the future, Datadog aims to make Android profiling data a first-class input for coding agents to autonomously resolve performance bottlenecks, closing the feedback loop between detection and remediation. Datadog is working toward making Android profiling broadly accessible to developers. To get started using the Datadog real user monitoring feature powered by ProfilingManager, visit Datadog Mobile Real User Monitoring.

_Posted by Alice Yuan, Developer Relations Engineer, Ajesh Pai, Developer Relations Engineer, and Fung Lam, Developer Relations Engineer_ While app performance is often equated with a smooth UI and fast start times, memory serves as the silent foundation upon which these visible metrics are built. It's no secret that we're seeing a shift where device memory is more important than ever. Not only have we made strides in Android memory optimizations with Android 17, we're providing the tooling and API support to help you stay ahead of stricter memory requirements later this year. To ensure device stability, starting in Android 17, the system will begin enforcing app memory limits based on the device's total RAM. If an app exceeds those limits, Android will kill the process with no associated stack trace. Beyond these forced terminations, unoptimized memory usage inevitably degrades the user experience. When the app approaches heap memory limits, it triggers frequent garbage collection—leading to noticeable UI stutters. Furthermore, when a device runs out of available memory, the system scrambles to reclaim pages, causing CPU strain, UI latency, and battery drain. If the memory shortage is too severe, it can cause Low Memory Killer (LMK) events that abruptly terminate background processes and force apps to have slow cold starts and lose user state. To build highly performant apps and avoid these forced terminations, we recommend that you adopt the following memory optimization strategies: 1. Maximize bytecode optimization with R8 2. Optimize image loading 3. Detect and fix memory leaks with Android Studio 4. Trim memory when app leaves visible state 5. Advanced memory observability with ProfilingManager _A condensed version of this blog post is also available in video format, go check it out!_ ### Understanding Android 17 app memory limits App memory limits are being introduced in Android 17 to prevent "one bad actor" from destroying the multitasking experience and stability of the user’s entire device. Here is a breakdown of the reasons driving this architectural change: * **Preventing cascading kills:** When an app becomes bloated or leaks memory while holding a privileged state (e.g. it’s running a Foreground Service), it is initially shielded from the system's Low Memory Killer (LMK). As this single app grows unchecked and hoards RAM, the LMK is forced to compensate by killing off dozens of smaller, well-behaved cached apps and background jobs to reclaim space for the memory hog. * **Preserving multitasking and user state:** When the system is forced to purge cached apps to accommodate a single leaking process, the multitasking experience is severely degraded. Users returning to prior cached applications encounter sluggish cold starts instead of near-instant warm resumes. This inefficiency generates more CPU strain and accelerates battery depletion. It can also destroy the user’s context in recently used apps, such as scroll positions, navigation stacks, and in-game progress. To determine if your app session was impacted by these constraints in the field, you can call getDescription() within ApplicationExitInfo. If the system applied a limit, the exit reason is reported as REASON_OTHER and the description string will contain "MemoryLimiter:AnonSwap". You can also leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached. Furthermore, Android is actively working to surface more in-field memory metrics to developers within the Google Play Console. We have also expanded our memory limits documentation to include local debugging commands, allowing you to simulate memory constraints in your local environment and validate your application's behavior under any memory limit enforcement. ### Maximize bytecode optimization with R8 A highly effective way to reduce your app's memory footprint is to enable the R8 optimizer. By shrinking classes, methods, and fields into shorter names and stripping out unused code and resources, R8 significantly reduces your app's memory footprint by minimizing the amount of resident code required during execution. R8 minimizes resident code, shrinking the memory footprint and lowering LMK termination risk. This results in more frequent warm starts over slow cold starts. Additionally, streamlined bytecode reduces main-thread CPU overhead, directly cutting ANR rates for a more fluid user experience. For example, the digital bank Monzo enabled full R8 optimization and saw a 35% reduction in their ANR rate, a 30% improvement in cold start rate, and a 9% reduction in overall app size. _The digital bank Monzo enabled full R8 optimization and boosted performance metrics by up to 35%._ To properly configure R8 in your `build.gradle` file: * Set `isShrinkResources = true` and `isMinifyEnabled = true`. * Use `proguard-android-optimize.txt` instead of the legacy `proguard-android.txt`, which actually prevents optimizations and is no longer supported in Android Gradle Plugin 9. * Remove `android.enableR8.fullMode = false` from your `gradle.properties`. If you are using reflection in your code base, then add Keep rules to prevent R8 from optimizing those parts of the code. Make sure to scope the keep rules narrowly to get the maximum optimization. To get the maximum optimization, make sure to follow these best practices in your keep rule file. * Remove global options like `-dontoptimize`, `-dontshrink`, and `-dontobfuscate` that prevent R8 from optimizing the entire codebase * Remove keep rules that prevent optimizing Android components like Activity, Services, Views or Broadcast receivers. * Refine the broad package wide keep rules to target only specific classes or methods. To see more best practices, view our keep rules documentation. ### Library Developer R8 Best Practices If you are a library developer, strictly place the rules your consumers need into your `consumer-rules` file, and keep your library's internal protection rules in your `proguard-rules.pro` file. For more information on how to optimize libraries, see Optimization for library authors. ### R8 Configuration Analyzer To audit your R8 optimization, use the **Configuration Analyzer**. Configuration analyzer shows the current state of optimization with Obfuscation, Optimization, and Shrinking scores. With configuration analyzer, you can also understand how many classes, methods or fields are prevented from optimization by each keep rule. Refine these broad package wide keep rules to unlock the maximum optimization. Using configuration analyzer, you can also identify keep rules that are subsuming other keep rules, redundant keep rules and unused keep rules. _The Configuration Analyzer shows the current state of optimization with Obfuscation, Optimization, and Shrinking scores._ #### R8 Agent Skill You can also leverage the **R8 Agent Skill** with Android Studio agent or other AI tools to resolve misconfigurations and refine your rules resulting in improved app performance. _(Insights from AI-driven skills will require technical verification)_ ### Optimize image loading Bitmaps are usually the largest common objects residing in your app's memory. They represent the final stage of the image loading process where compressed files, like JPEGs or PNGs, are decoded into raw pixel data for display. This means a tiny 100KB compressed image can balloon into several megabytes of RAM because memory consumption is determined by the image's pixel dimensions and color depth. Since bitmap operations are frequently on the critical path to drawing frames, unoptimized images cause severe memory bloat and UI jank. Google recommends leveraging image loading libraries **Coil** for Kotlin-first projects, particularly when developing with Jetpack Compose and **Glide** for Java-based applications. #### Adopt these five best practices 1. **Downsample images:** If you’re loading bitmaps manually, avoid loading a massive image into a tiny thumbnail view; use inSampleSize to load a smaller version. Glide and Coil downsamples images by default and you can configure this downsample strategy using DownsampleStrategy and ImageLoader respectively. 2. **Cropping:** Avoid embedding padding directly into an image file for letterboxing purposes (e.g., creating a transparent border to expand an image dimensions). Rather than baking in these borders, utilize InsetDrawable or apply padding directly within the View or Composable containing the bitmap. 3. **Config:** Balance memory and quality by choosing the right pixel format. Use `RGB_565` when transparency isn't needed, which uses half the memory of the default `ARGB_8888` format. In Glide you can configure this by using DecodeFormat and in Coil you can use bitmapConfig property. 4. **Prioritize vector drawables:** For basic geometric assets, leverage ShapeDrawable as a lightweight alternative to decoding rasterized bitmaps. By defining these assets once via XML, you ensure they scale seamlessly across all display densities while effectively eliminating resource-driven memory bloat. 5. **Reuse:** If your application manages Bitmaps manually then to minimize memory churn, when a bitmap is no longer required, the app should call `bitmap.recycle()` and immediately discard the Bitmap reference. If you use an image loading library like Glide or Coil, return the bitmap to the library’s managed pool. By providing an existing buffer for future memory needs, the pool effectively avoids the overhead of new allocations. Check out our documentation on Optimizing performance for images to learn more. #### Android Studio tooling You can also eliminate redundant bitmaps using Android Studio Narwhal 4. Here is how to hunt them down in five simple steps: 1. Open the **Profiler** tab in Android Studio 2. Click **Heap Dump** (or "Analyze Memory Usage") and hit record to take a snapshot of your app’s current memory state. 3. Scan the analysis results for the **yellow warning triangle** ⚠️, which Android Studio uses to flag duplicate bitmaps being stored multiple times. Alternatively, navigate to the profiler header, choose "Filter by:" and pick the "Duplicate Bitmaps" setting. 4. Click on any flagged entry to open the **Bitmap Preview** pane, allowing you to see exactly which image is the repeat offender. 5. Use that visual confirmation to track down the redundant loading logic in your code and implement a better caching strategy. _Look for the yellow warning triangle ⚠️ in heap dumps when using the Android Studio Profiler._ ### Detect and fix memory leaks with Android Studio Memory leaks in Android occur when your code holds onto an object's reference long after its lifecycle has ended. This prevents the Garbage Collector (GC) from reclaiming that memory, eventually leading to sluggish performance or OutOfMemoryError (OOM). Android Studio Panda 3 features a dedicated LeakCanary profiler task, allowing developers to analyze real-time memory leaks and map traces within the IDE. The LeakCanary profiler task in Android Studio actively moves the memory leak analysis from your device to your development machine, resulting in a significant performance boost during the leak analysis phase as compared to on-device leak analysis. _LeakCanary memory leak analysis contextualized with**Go to declaration** for debugging_ Additionally, the leak analysis is now contextualized within the IDE and fully integrated with your source code, providing features like go to declaration and other helpful code connections that drastically reduce the friction and time required to investigate and fix memory leaks. #### Examples of common memory leaks Memory leaks occur when an object persists in memory beyond its intended lifespan. This typically happens due to: * Retaining references to Fragments, Activities, or Views that are no longer in use. * Mismanaging Context references. * Failing to properly unregister observers, listeners, and receivers. * Creating static references to objects that are bound to components with shorter lifecycles. Here are a few example scenarios: Scenario | Compose-based example | View-based example ---|---|--- Leaking Context | Example: Passing LocalContext.current to a ViewModel Fix: Keep `Context` dependent logic within the UI layer. For non-UI layers, refactor to use dependency injection or observe UI state using Kotlin flow. | Example: Storing an `Activity` in a companion object or static variable. Fix: Don’t hold static references to UI components. Refactor to use dependency injection or observe UI state using Kotlin flow. Leaking Listeners | Example: Using `DisposableEffect` to start a listener but leaving `onDispose` empty. Fix: Perform the unregistration and cleanup logic inside the `onDispose` block. | Example: Registering for SensorManager updates and forgetting to unregister. Fix: Manually call `unregisterListener()` in `onStop()` or `onDestroy()` lifecycle. Leaking Views | Example: Holding a reference to a legacy `View` inside an `AndroidView` without a release strategy. Fix: Use the `release` block of the `AndroidView` composable to clean up the legacy `View`. | Example: Keeping a reference to a view binding object after the `Fragment` is destroyed. Fix: Set the binding variable to `null` inside the `onDestroyView`() lifecycle method. ### Trim memory when app leaves visible state Android can reclaim memory from your app or stop your app entirely if necessary to free up memory for critical tasks, as explained in Overview of memory management. Android will usually reclaim memory from your app when it’s not visible to the user, such as by discarding some of your app’s code and data pages in memory or compressing your heap allocations. When the user resumes your app and your app tries to access some memory that’s been reclaimed, the OS will swap that memory back in on demand. This swapping behavior can be slow, and cause unexpected jank or stutters in your app. If you leave it to the OS to decide what memory to reclaim from your app, you may find that the OS reclaimed memory that you’ll need shortly after resuming your app. Instead, your app can voluntarily discard memory allocations that it can regenerate later, on demand and at a low cost. To do so, you can implement the `ComponentCallbacks2` interface. You can implement `onTrimMemory` in your `Activity`, `Fragment`, `Service`, or even your custom `Application` class. Using it in the `Application` class is highly effective for global cache management. The provided onTrimMemory() callback method notifies your app of lifecycle or memory-related events that present a good opportunity for your app to voluntarily reduce its memory usage. In terms of memory lifecycle management, your implementation should focus **exclusively** on `TRIM_MEMORY_UI_HIDDEN` and `TRIM_MEMORY_BACKGROUND`. Since Android 14, the system has ceased delivering notifications for other legacy constants, which were formally deprecated in Android 15. `TRIM_MEMORY_UI_HIDDEN`: This signal indicates that your application's UI has transitioned out of the user's view. This provides an opportunity to release substantial memory allocations tied strictly to the interface—such as Bitmaps, video playback buffers, or complex animation resources. `TRIM_MEMORY_BACKGROUND`: At this level, your process is residing in the background and is now a candidate for termination to satisfy the system's global memory needs. To extend the duration your process remains in the cached state, and reduce the number of app cold starts, you should aggressively release any resources that can be easily reconstructed once the user resumes their session. import android.content.ComponentCallbacks2 // Other import statements. class MainActivity : AppCompatActivity(), ComponentCallbacks2 { /** * Release memory when the UI becomes hidden or when system resources become low. * @param level the memory-related event that is raised. */ override fun onTrimMemory(level: Int) { if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) { // Release memory related to UI elements, such as bitmap caches. } if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) { // Release memory related to background processing, such as by // closing a database connection. } } } Note: The `onTrimMemory` integration may depend on SDK support. For instance, certain games rely on their game engine to enable this capability. Please check out the game memory optimization documents. ### Advanced memory observability with ProfilingManager To catch and diagnose memory issues in the field that cannot be reproduced locally, you should leverage the **ProfilingManager API**. Introduced in Android 15, this advanced observability API allows you to programmatically collect real-user Perfetto profiles. For teams that lack a dedicated infrastructure to manage and host performance artifacts, Crashlytics is exploring a specialized solution to streamline this workflow. They are inviting developers to provide feedback. **Android 17 introduces new event-driven triggers** , most notably `TRIGGER_TYPE_OOM` and `TRIGGER_TYPE_ANOMALY`: * The **OOM trigger** automatically collects a Java heap dump at the exact moment an OutOfMemoryError crash occurs, providing precise allocation states. A collected OOM profile is provided the next time the app starts and registers the `registerForAllProfilingResults` callback. * The **Anomaly trigger** detects severe performance issues, such as excessive binder spam or breached memory thresholds. The memory anomaly delivers a heap dump just prior to the system terminating the app. val profilingManager = applicationContext.getSystemService(ProfilingManager::class.java) val triggers = ArrayList() triggers.add(ProfilingTrigger.Builder( ProfilingTrigger.TRIGGER_TYPE_ANOMALY)) val mainExecutor: Executor = Executors.newSingleThreadExecutor() val resultCallback = Consumer { profilingResult -> if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) { // upload profile result to server for further analysis setupProfileUploadWorker(profilingResult.resultFilePath) } profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback) profilingManager.addProfilingTriggers(triggers) Once you’ve collected the heap dump, you can download the profile from the server, or locally via adb pull and drag and drop the file into the Perfetto UI. To streamline your memory debugging workflow, use the Heap Dump Explorer, this is the new default view for heap dumps in Perfetto UI. This tool provides an intuitive interface for inspecting Java heap dumps, allowing you to visualize object allocation hierarchies, compute retained memory sizes, and identify the shortest path from garbage collection root. By leveraging the Heap Dump Explorer, you can rapidly pinpoint memory leaks, bloated retained objects such as excessive bitmap allocations, and analyze heap object allocations all in one place. _Use the Heap Dump Explorer’s embedded flamegraph to visually inspect and navigate through objects with the highest heap allocations._ ### Conclusion Optimizing bytecode with R8, adopting image loading best practices, and resolving memory leaks are critical steps toward delivering a high-quality user experience while managing resources effectively under pressure. Adopting these proactive measures helps maintain app stability and performance, preventing unexpected terminations while safeguarding user context. To further your performance expertise, explore our revised memory guidance.

_Posted by Ataul Munim, Android Developer Relations Engineer_ A truly differentiated Android experience is about delivering premium delight wherever your users are. At Google I/O ‘26, we showcased how the latest advancements in the Android ecosystem can help you elevate your app's quality while maximizing development efficiency. To help you build apps that stand out, we're diving into the key tools and libraries designed to optimize your core performance, extend the surfaces of your app to other devices, and streamline how your app handles high-quality media. Here is a recap of the essential updates and sessions you need to know to deliver a next-level experience across form factors! ### Maximize app performance and ROI with the R8 Configuration Analyzer A premium experience is only as good as its foundation, and a performant foundation is what allows your app to scale across the Android ecosystem. This is especially true with the release of Android 17, which introduces conservative, device RAM-based app memory limits to target extreme memory leaks and outliers before they cause system-wide instability. To stay below these new system thresholds and prevent your app from being terminated, having a lean footprint is no longer optional: it’s a critical requirement. This year, we’re making it easier to build highly optimized, fast apps by introducing the R8 Configuration Analyzer in Android Studio. R8 is your most powerful tool for improving app performance, but its effectiveness is often limited by overly broad "keep rules" that prevent the compiler from stripping away unused code. The new Configuration Analyzer provides optimization, obfuscation, and shrinking scores, allowing you to identify specific rules that are preventing the benefits of R8 optimization. By optimizing their R8 configurations, developers at Monzo achieved a 30% improvement in cold starts and a 35% reduction in ANRs. Smaller, faster code isn't just about efficiency; it's about ensuring your app has the memory headroom to deliver delight on every form factor, from the phone to the car. ### Extend your reach with a unified approach to Widgets on Phones, Watches and Cars User interaction is shifting toward quick, glanceable moments—short bursts of information that keep users connected without needing to open the full app. To help you increase the reach of your app content, we are unifying the development experience across the Android ecosystem with Jetpack Glance. By using a consistent, Compose-based model, you can elevate the content most important to your users straight to the phone’s home screen, Wear Widgets (previously Tiles!), and cars with a familiar workflow. In order to help users engage with your content and features, even outside your app, we are making widgets more expressive and adaptive with RemoteCompose. On Wear OS, RemoteCompose allows you to use the Compose tools you’re already comfortable with to define UI logic that renders natively on remote surfaces, ensuring that your glanceable experiences remain highly performant and responsive even on resource-constrained hardware. On mobile and cars, RemoteCompose is used as a new framework giving Widgets new expressive capabilities. You can use Jetpack Glance (together with RemoteCompose on Wear) to deliver a cohesive user journey. Whether it’s viewing flight status on the car dashboard, checking a gate change on a watch, or managing a boarding pass from a phone widget, this shared approach maximizes your app’s presence while keeping your development effort focused and efficient. ### Supercharge your media pipeline with a complete, production-ready toolkit Android has become a world-class home for the entire media lifecycle, and we are simplifying the journey from the first capture to the final playback. By leveraging Jetpack CameraX and Media3, you can build professional-grade experiences that feel native across the entire ecosystem. It starts with high-fidelity capture using the CameraXViewfinder Composable, which ensures your preview remains perfectly scaled and responsive on any form factor, including foldables and tablets. Use this to build adaptive capture experiences like a picture-in-picture view for multi-tasking, or that take advantage of modern features like high-frame-rate or slow-motion capture with CameraX v1.5. The new Media3 AI Effects library will provide a unified interface for premium features like Image & Video Enhance, Magic Eraser, and Studio Sound. This allows you to focus on the creative intent while Media3 handles the heavy lifting of choosing the most efficient and reliable path for the device. Then, use the latest improvements in multi-asset editing with Media3 Transformer to composite your edited videos together! Complete the pipeline with tools designed for professional-grade export and viewing, including: * CodecDB, which offers data-driven encoding recommendations tailored to specific chipsets, ensuring your exported videos maintain high visual quality with minimal noise or blurriness * Scrubbing Mode in ExoPlayer to provide the buttery-smooth seeking experience users expect from premium media apps * Enhanced Cast support with the new CastPlayer API in Media3 By unifying these technical pillars, you can build a cohesive, high-performance media journey that delivers both delight for your users and high ROI for your development team. For more details, check out the _premium_ Android experience YouTube playlist.

_Posted by Jingyu Shi, Staff Developer Relations Engineer_ _ _ _ _ __ At Google I/O 2026, we introduced Android’s shift from an operating system to an intelligence system. We also demonstrated how you can build intelligent experiences natively with the system and bring the power of Google’s AI into your apps. If you missed these updates, check out our quick recap video here: #### **1. Putting your apps at the center of the intelligence system** The Android OS already enables agents like Gemini to complete task automation, where it can navigate an app on the users behalf. AppFunctions (Android MCP) provides you with more control over how your app integrates with the intelligence system. This new platform API and Jetpack library are currently available in experimental preview. * **Android MCP:** AppFunctions allows your application to act as an on-device Model Context Protocol (MCP) server. It means you seamlessly share your app's tools, services and data to the system and agents. * **Streamlined Development:** You can leverage the new skill to easily generate AppFunctions within your codebase. * **Exploration and Testing:** We’ve released a new test agent that allows you to experiment and debug your AppFunctions in a simulated agent environment. Early Access Program: Want to be among the first apps to deploy app functions in production? Join our early access program today! --- To see it in action, check out the live demo showcased during the _What’s New_ in Android presentation. #### ** 2. On-Device Power with Gemini Nano 4 Preview** Last month, we launched Gemma 4, our state-of-the-art open models. You can already preview and prototype with the next generation of Gemini Nano (Nano 4) models with the AIcore developer preview. To make productionizing with Gemini Nano more reliable and performant, we are adding a few new features in **ML Kit GenAI APIs** : * **Prototype to Production:** Transition from prototyping in the AICore Developer Preview to building production-ready apps using the ML Kit GenAI Prompt API to leverage Gemini Nano 4 that’s launching in flagship devices later this year. * **Structured Output:** The upcoming Structured Output API will allow you to define object classes to be returned as outputs from Prompt API, ensuring reliable outputs in productionizing your intelligent features. * **Prefix Caching:** It optimizes your on-device inference performance with the prompt API. The new Prefix caching reduces inference time by storing and reusing the intermediate LLM state of processing a shared and recurring part of the prompt. ** ** For highly customized or niche use cases, you can also use LiteRT-LM to bring your own fine-tuned small language model to Android. ** **3. Hybrid Inference & Agents** ** To help you build more advanced AI features like hybrid inference and explore building in-app agents, we’ve released new APIs, framework and guidances: * **Firebase AI Logic Hybrid Inference:** This new API provides the simple routing capability between on-device models and powerful cloud infrastructure. You can set explicit orchestration modes, such as `PREFER_ON_DEVICE`, `PREFER_CLOUD`, `ONLY_ON_DEVICE`, or `ONLY_CLOUD`, based on your need. * **A2UI Jetpack Compose Renderer:** The new A2UI library allows your agents to "speak UI". With the upcoming Jetpack Compose Renderer, you can automatically render these A2UI messages as native UI components. * **ADK for Android:** The first version of ADK for Android is available for experimentation. It allows you to build multi-agent workflows across both on-device and Cloud models while managing orchestration, context handling and sessions between agents. From building with on-device models, exploring hybrid inference to building agents, you can see them in action in this talk: ### Start Building Today Whether you are experimenting with AppFunctions to prepare for the intelligence system, or looking to bring the power of Google’s AI within your own app, we’ve got you covered. Dive deeper into the code snippets, samples and comprehensive developer guides on the Android AI hub. For the full breakdown of what’s new, check out the official **AI on Android at Google I/O 2026** playlist. We are excited to see what you build!

_Posted by Matthew McCullough, VP, Product Management, Android Developer_ Today at Google I/O, we announced the many ways we’re powering agentic workflows to increase your productivity and ensure your apps shine across the expanding Android ecosystem. Here’s a recap of 17 of our favorite announcements for Android developers; you can also see what was announced last week in The Android Show: I/O Edition. Stay tuned over the next two days as we dive into all of the topics in more detail! ## **Build High Quality Android Apps Using Agents** ### **1: Android CLI: helping you build with any agent, LLM, and tool** Android CLI is now stable. It offers programmatic tools that allow any AI agent, including Claude Code, Codex, or Antigravity, to perform core Android tasks much more easily and efficiently. With today’s release, it also provides a bridge to tap directly into the "heavy-lifting" power of Android Studio to give you the production-ready polish needed for professional Android development. By leveraging the new android studio commands, developers can now grant their preferred agents the ability to perform semantic symbol resolution, analyze files for warnings, and even render Jetpack Compose previews. This release also enables official support for "Journeys" through new Android skills, which enables agents to execute end-to-end UI tests under your direction. Watch the developer keynote, and tune into the What’s New in Android tools talk for more information. _You can now easily install Android CLI for use with Google Antigravity 2.0._ ### **2: Build production-ready apps with ease in Google AI Studio** Developers and creators can now build native Android apps, simply with a prompt in Google AI Studio. The apps are built with development best practices like Jetpack Compose, Kotlin, and APIs that leverage our recommended developer patterns. Google AI Studio enables developers to prototype, iterate via an embedded emulator, and deploy to physical devices without heavy local installations. Developers are then able to take those apps and share them to Android devices, as well as share them with others for testing through Google Play Console’s internal testing track. If a developer wants to prepare their app for a wider release, they’re able to take it to Android Studio for advanced debugging, testing, and UI polish. Watch the developer keynote, and tune into the What’s New in Android tools talk for more information. _ _Use the embedded Android Emulator to create Android apps in Google AI Studio_ _ ## **3: Accelerating AI coding assistance with Android Bench** Android Bench is our LLM leaderboard for Android development challenges. The goal is to accelerate model improvements, so you have more useful options for AI assistance. Many of you have been using open-weight models for AI assistance, so we’re now adding commonly used ones, such as Gemma 4, to the leaderboard, so you can see how LLMs that offer offline access and additional flexibility for power-users measure up. We're continuously working on increasing the difficulty of challenges we’re giving LLMs, to continue encouraging more useful improvements. ### **4: Convert iOS apps to Android with the Migration Assistant in Android Studio** The Migration Assistant in Android Studio is designed to port apps from platforms like iOS, React Native, or web frameworks to native Android. By simply selecting an existing project, developers can have the agent intelligently map features, convert assets like storyboards and SVGs, and implement Android best practices using Jetpack Compose and our recommended Jetpack libraries. This effectively transforms what used to be weeks of manual porting into a streamlined agentic workflow that only takes hours. We shared a preview of the incoming feature in the developer keynote. _A sneak peek of the Migration Assistant converting an iOS app into a native Android app_ ## **Building AI Into Your Apps** ### **5: Building Intelligent Apps with generative AI** Generative AI enables you to create apps that are more intelligent, personalized, and agentic than ever before. This year, we introduced the latest advancements in on-device intelligence with a preview of Gemini Nano 4 for tasks like data extraction and summarization. We also expanded cloud capabilities via Firebase AI Logic, allowing developers to leverage Gemini models with robust grounding (including URL, Maps, and web search) to build smarter, more capable assistants. Furthermore, we unveiled our hybrid inference approach and the new Agent Development Kit (ADK) for Android, alongside communication protocols like AG-UI and A2UI that simplify the creation of autonomous, agentic experiences. To start integrating these powerful features, explore the developer documentation, and watch the technical deep dive session where we showcase all these technologies. ### **6: Experiment with AppFunctions today** AppFunctions is an Android platform API with an accompanying Jetpack library to simplify building Android MCP integrations. It empowers your apps to behave like on device MCP servers, contributing functions that act as tools for use by agents and assistants. AppFunctions integration with Gemini is currently in a private preview with trusted testers, and you can begin preparing your apps already. You can sign up for the Early Access Program and start experimenting using the API guidance, sample, and skill today. ## **The Future is Adaptive** ### **7: Android is now Compose First; Views are now in maintenance mode.** Compose is our standard for UI development, and we are moving to a Compose-first approach for all future guidance and libraries. Building on five years of evolution, the latest releases deliver a more mature toolkit, from the highly customizable Styles API to refined shared element transitions and enhanced input support. These updates allow you to build beautiful, adaptive apps with less code and better performance. Learn more about what Compose-first means for Android Development in our blog post. _Build Android UI with Compose_ ### **8: Building seamless Android experiences across devices with Jetpack Compose** The Android ecosystem is now Adaptive by Default, moving fluidly across phones, foldables, tablets, cars, XR, and expanding usages with Googlebook and connected displays. With over 580 million large-screen devices, and users on multiple devices spending up to 14x more on apps, the investment in adaptive design presents a massive opportunity. Jetpack Compose is the definitive engine for this transition, offering core tools like our latest Jetpack Navigation 3 release, new experimental Grid and FlexBox layouts, enhanced non-touch input support, and CameraX for correct camera previews across any window size. Furthermore, new skills in Android Studio make updating your existing app to adopt these adaptive patterns easier than ever. _Notability’s Android debut sets a new standard for premium productivity apps. Built with Jetpack Compose, Navigation 3, and Kotlin Multiplatform, it delivers an intuitive, adaptive experience across devices._ ### **9: Create seamless experiences for Googlebook** Last week we announced Googlebook, a high-performance laptop that provides a large-screen canvas for your existing apps. Building with adaptive principles today helps ensure your app will work on Googlebook. Get started by reviewing relevant design guidance and developer guidelines for desktop experiences. Try out the new Desktop Emulator available in the Android Studio Canary to to test your apps for this form factor today. _New Desktop Android Emulator_ ### **10: Unified widget development experience with Jetpack Glance** Android 17 marks a shift toward a single, Compose-based development model for all widgets. By unifying the experience across mobile, Wear OS, and cars through Jetpack Glance, you can soon scale UI components across the ecosystem with a familiar workflow. The breakthrough this year is the integration of RemoteCompose. On mobile and cars, it powers high-fidelity animations, while on Wear OS, it allows Wear Widgets (formerly Tiles) to render complex UI logic natively on remote surfaces. This ensures peak performance on low-power hardware while allowing a cohesive user journey—like checking a flight status on your car dashboard and seeing gate change updates on your wrist. _Four widgets are shown cycling through in the Android Auto interface. A clock, a contact card, Google Home favorites and a photo._ _ _ **11: Expand your reach on the road with Android for Cars** To help you expand your reach when you build in-car experiences, we're making it easier to build once and deliver your apps to Android Auto and Android Automotive OS. With the latest releases of the Car App Library, you can build customized, distraction-optimized templated media apps for both platforms. We're introducing new components and template capabilities to give you increased flexibility and more options for laying out content. Parked experiences are expanding too, with immersive video playback coming to Android Auto for phones running Android 17. You can easily adapt your video apps for these parked experiences; apply now to the early access program to publish in these beta categories and learn more about the latest updates in our blog. ### **12: Accelerate your development with Android XR Developer Preview 4** Inspired by the innovative experiences you’ve built for the platform, we’re continuing to mature our tools with Developer Preview 4 of the Android XR SDK. A key milestone in this journey is the transition of our core libraries, XR Runtime, Jetpack SceneCore, and ARCore for Jetpack XR, moving to Beta soon to provide a more stable and performant foundation. We are also accelerating hardware access through the Android XR Developer Catalyst Program, where you can apply for XREAL’s Project Aura, audio glasses, or display glasses developer kits. Watch The latest in Android XR session or read our blog to see how these updates help you build experiences across the ecosystem. _ _Early preview of the Geospatial API in ARCore for Jetpack XR, enabling high-precision anchoring of digital content to real-world locations._ _ ### **13: Android is your new home for professional-grade media experiences** Android 17 streamlines the entire media lifecycle with a production-ready toolkit. High-fidelity capture is now simplified with the CameraXViewfinder Composable, which handles complex scaling and responsiveness on foldables and tablets. For post-production, the new Media3 AI Effects library provides a single interface for premium features like Magic Eraser and Studio Sound, automatically optimizing for the device's hardware. The pipeline is completed by CodecDB, offering chipset-specific encoding recommendations to eliminate export noise, and a new Scrubbing Mode in ExoPlayer for ultra-smooth seeking. Whether you’re compositing multi-asset edits with Media3 Transformer or using the streamlined CastPlayer API, these updates ensure a professional-grade experience with significantly less development overhead. _Low Light Boost and Magic Eraser in action_ ### **14: Increase app discovery and engagement on Google TV** Pointer remotes, which enable motion-controlled input, will be a future way for users to interact with Google TV as it unlocks faster user navigation. App developers can start declaring support for pointing input to ensure their apps are discoverable on future TVs with pointer remotes. Additionally, the Engage SDK, formerly known as the Video Discovery API, optimizes Resumption, Entitlements, and Recommendations across all Google TV form factors to boost app discovery and engagement. It’s a great time to start onboarding the Engage SDK now, since the legacy Watch Next API, which has been powering your continue watching 1.0 experience, will lose support in the 2nd half of 2027. Get all the details in our blog. ### **15: Performance: the foundation of a great app experience** To help developers navigate memory limits in Android 17, we've launched a suite of optimization tools. The R8 Configuration Analyzer identifies keep rules that are bloating your binary, while ProfilingManager and the integrated LeakCanary in Android Studio streamline memory leak detection. Furthermore, the new Android Performance Analyzer offers advanced AI integration for complex trace analysis and automated SQL query generation to pinpoint performance bottlenecks. ## **And The Latest on Driving Business Growth** ### **16: What’s new in Google Play** Today's updates from Google Play help expand your reach and scale your business with less complexity. We’re redefining Play Store discovery with an immersive, short-form video format called Play Shorts, while expanding your audience beyond the store with app discovery in the Gemini app on Android and web. Plus, we’re introducing powerful new capabilities like agentic catalog management for seamless bulk price and SKU updates, and using Gemini models to enable Play Console to pre-populate store listings from imported documents—making global localization effortless. _Gemini will provide users with app suggestions during a search_ ### **17: And of course, Android 17** Android 17 includes new performance & system architecture improvements (in addition to app memory limits) like a lock-free MessageQueue and a GC with more frequent, less intensive young-generation collections to ensure system-wide stability and smoother UIs. The new contact picker and eyedropper API help minimize the use of sensitive permissions and unnecessary access to user data. Review the behavior changes to make sure your app is ready for Android 17, including background audio hardening and SMS OTP protection. Get ready to target Android 17 (API 37) with changes such as mandatory large-screen resizability, certificate transparency by default, and restricted local network access. You can start testing today by enrolling your device in the Beta or using the latest 17.0 emulator images. One more thing. the third beta of our Android 17 quarterly platform release (QPR1) just came out, and it contains a minor SDK release to support a few features that just couldn't wait for QPR2. ## **Check out all of the Android & Play Content at Google I/O ** This was just a preview of some of the updates for Android developers at Google I/O. Tune into What’s New in Android for the latest news and announcements and follow Google I/O for much more over the following week!

_Posted by Emma-Louise Leavey, Group Product Manager and Mike Taylor-Cai, Product Manager_ Starting today Google AI Studio can build entire Android apps for you in minutes from just a prompt. You don't need to install any software or configure any libraries, which significantly lowers the barrier to development. Whether you’re a seasoned developer looking to prototype at lightning speed or a creator building your first-ever mobile experience, you can now go from a single prompt to a high-quality, Kotlin-based Android app in AI Studio. You can easily install the app on your device, share it with others for testing, or send it to Android Studio for any further development. ## The power of native Android While AI has made it easy to generate web-based apps, people want more on their mobile devices. They expect the beautiful and usable modern app design and capabilities that come with native Android user experiences, built with the Kotlin programming language using Jetpack Compose, the official and recommended toolkit for Android development. Native Android apps bring the reliability of offline support, continuous background services, and the deep integration of hardware sensors like GPS, Bluetooth, and NFC. We've brought the technology that enables you to quickly create new projects with Gemini in Android Studio directly into the web-based AI Studio. Now, you get the best of both worlds: the ease of a prompt-based interface paired with the power of the Android SDK, all in your browser, no installation required. ## A seamless, end-to-end workflow We have streamlined the entire development lifecycle so you can focus on your idea: ** ** **1. Create your app and iterate in the cloud:** Use the embedded Android Emulator directly in your browser to preview and interact with your app as it’s being built. No heavy SDKs to download, no local setup required. _ _Use the embedded Android Emulator to create and edit Android Apps right in the web browser_ _ **2.** **Install instantly:** Connect your Android phone using a USB cable and install your app directly from AI Studio using the integrated Android Debug Bridge (adb). _Install the app on your Android device_ **3. Streamlined Publish to Google Play:** Using your Google Play developer account, you can now publish your app directly from AI Studio for testing. AI Studio will automatically create your app record, package the bundle, and upload it to an internal testing track in Google Play Developer Console. Your app is available for you to install within minutes, and you can automatically update your app on your device as you develop it further in AI Studio. _Publish the app to an internal test track in Google Play_ **Seamless app development handoff** As you iterate on your app in AI Studio, you may find you need more advanced Android tools or support for a wider variety of Android device types. To move beyond the browser, you can seamlessly hand off your project to Android Studio by downloading a ZIP file or exporting it directly to GitHub. _Download zip file of Android app project files_ _ _ When transitioning to a team environment or local development, you can leverage any IDE or agent you prefer. For a specialized experience, we recommend Gemini in Android Studio, which features models designed with Android in mind, or Antigravity, which integrates Android CLI commands into Google’s agentic development platform. This workflow makes building high-quality apps more accessible while giving you total flexibility in how you use AI to scale your project. ## Start building today To ensure a safe, high-quality ecosystem from day one, we have focused our initial release on specific capabilities including: * **Personal utilities and simple social apps:** You can rapidly prototype single or multi-screen apps, such as habit trackers, study quizzes, or event itineraries. * **Hardware-enabled experiences:** Because you are building native apps, you can leverage device features like the Camera, GPS/Location, Accelerometer and Bluetooth using the native Android APIs, letting you optimize hardware-level performance. * **AI-powered experiences:** You can create apps that feature Gemini API integrations, seamlessly embedding powerful AI capabilities directly into your mobile experience. ## What’s Next? We are moving fast to expand what’s possible for creators in AI Studio. Here is a sneak peek at what is coming soon: * **Managing Google Play Test Tracks:** Coming soon, we will be adding the ability to invite testers to try your app directly from AI Studio. * **Firebase integrations:** Out-of-the-box support for Firestore, Firebase Auth, Firebase App Check and other tooling critical for Android developers is coming soon. Head over to Google AI Studio right now to start building. Here is some inspiration to get you started… Turn your Google Pixel Watch into an aviation assistant --- **Prompt:** Build a small airplane "6-pack" instrument app for Google Pixel Watch. The 6 instruments should include attitude indicator, airspeed indicator, altimeter, turn coordinator, vertical speed indicator, and heading indicator. Use the Google Pixel Watch's sensors to power the instruments and display them clearly. Display one instrument at a time on the display. Swiping to the left or right should cycle through the instruments. | Interactive Harmonium app on Google Pixel Fold --- **Prompt:** Build a Harmonium app for Pixel Fold devices, which plays like the instrument based on the hinge angle and touch gestures. The app should simulate the bellows and reeds accurately. | An Android app for guitarists to become better musicians by jamming to backing tracks --- **Prompt:** Build an Android guitar practice companion app that features a two-tab navigation system: 'Fretboard' and 'Library'. The 'Fretboard' primary screen must contain an interactive guitar neck UI that visually maps out user-selected root notes, musical scales, and chords. Above the fretboard, implement a WebView-based YouTube player configured to play embedded videos inline. Additionally, include an AI generation feature that uses Retrofit to call Gemini Lyria 3 to create custom, 30-second backing tracks based on the user's currently selected key and scale. The generated audio files and their metadata must be saved locally using a database and displayed as a list in the 'Library' tab, where users can delete or play them. Finally, implement a persistent, globally visible mini audio player at the bottom of the screen, complete with play/pause toggles, a progress slider for seeking, and timestamp text, allowing the user to seamlessly practice on the fretboard tab while listening to their tracks. | We are looking forward to seeing what you build next! Explore this announcement and all Google I/O 2026 updates on io.google.

_Posted by Paul Lammertsma, Developer Relations Engineer_ _ _ With over 300 million monthly active devices across Google TV and Android TV, it’s clear that the living room is a massive, distinct platform for apps to accelerate growth. Today, we’re excited to share Google TV features and developer tools designed to increase the discoverability of your content and prepare your app for future TV experiences. ## Drive discovery and engagement with Gemini Last year, we brought our AI voice assistant, Gemini, to our platform, so that people can easily find what to watch, learn something new on the big screen, and get everyday tasks done with just their voice. Since launch, we’ve made improvements to how Gemini provides tailored responses to questions. Gemini shares a mix of visuals, videos, and text to help users find what they need, when they need it. For our streaming partners, Gemini is a helpful discovery engine—pulling from your app's metadata to surface your relevant content to viewers. ## Declare support for pointing modality The TV experience that we once knew is changing. Gemini is changing the way we discover and stream content with voice, but how we use the remote is evolving, too. Pointer remotes bring motion-controlled input to the big screen, unlocking faster user navigation across the Google TV Home page and within content-heavy apps. To ensure your app is ready for this shift and provides a great experience for all users, now is the time to start thinking about pointing input. Here’s how to get started: #### 1. Adapt your TV app UI Library You’ll need support for hover states, scrollable containers, and cursor clicks to enable pointer remote interactions for your app on Google TV. While implementation varies by UI stack, Jetpack Compose streamlines this transition, as most core components handle these multi-modal interactions natively out of the box. 1. **Hover state:** Every focusable element on your screen (buttons, movie posters, setting toggles) needs a clear visual feedback mechanism for a hover state. This is often subtler than a focus state but critical for feedback. 2. **Scrollable containers:** Pointer remotes will also have a small circular touchpad for scrolling. Users can use this touchpad to scroll up or down, or left or right in your app. Your app will need to respond to touch events to scroll. 3. **Cursor clicks:** Many TV apps today expect a simple D-pad OKAY button “click.” With a pointer remote, a user may “click” on an element that’s not the D-pad focus state, but is instead from a hovered state (similar to a mouse click). #### 2. Test pointing interactions with a mouse today To see how your app handles hover, scroll, and clicks, simply connect a bluetooth mouse or wired mouse to your Google TV. Keep in mind that a mouse has more precise control, since users are closer to the screen and typically rest the mouse in a stable position. Pointer remotes can often be less precise, since users are sometimes 10 feet away from the screen, making rough gestures with the remote from their couch. As a TV designer or developer, you can mitigate this lack of input precision by having larger hover targets for elements. #### 3. Declare TV app support for pointer remotes on Google Play Finally, tell Google Play that your TV app is designed to work with a pointer. This ensures that users with pointer remotes will be able to easily find, install, and interact with your app. Within your AndroidManifest.xml, declare the meta-data tag, android.software.leanback.supports_touch. This tag informs the platform that your TV app “spatially supports touch,” since pointer remotes simulate touch events from a distance. **_AndroidManifest.xml_** <manifest ...> <!-- Signal whether the app is adaptive or built just for TV --> <uses-feature android:name="android.software.leanback" android:required="true|false" /> <!-- Ensure the app can be installed on conventional TVs --> <uses-feature android:name="android.hardware.touchscreen" android:required="false" /> <!-- Signal whether the app supports pointer remotes --> <meta-data android:name="android.software.leanback.supports_touch" android:value="true|false"/> <application ...> ... </application> </manifest> **Tips:** * The android.**software**.**leanback** feature declaration indicates that your app supports D-pad navigation and is intended for distribution only on TV devices via Google Play. * The new software attribute of android.software.leanback.supports_touch declares that in addition to D-pad, you have ensured that your TV app works well for pointer/cursor experiences via mouse (of today) and pointer remotes (of future). * If you haven't already, now is the time to adopt Jetpack Compose. Hover, scroll, and clicks are common input modalities that are supported on various form factors, and building your app with an adaptive UI framework enables code reusability and reduced maintenance. ## Onboard the Engage SDK The Engage SDK, formerly known as the Video Discovery API, optimizes Resumption, Entitlements, and Recommendations across all Google TV form factors to boost app discovery and engagement. * **Resumption:** Partners can easily display a user's paused video within the 'Continue Watching' row from the Home page. * **Entitlements:** The Engage SDK streamlines entitlement management, which matches app content to user eligibility. Users appreciate this because they can enjoy personalized recommendations without needing to manually update all their subscription details. This allows partners to connect with users across multiple discovery points on Google TV. * **Recommendations:** The Engage SDK even highlights personalized recommendations based on content that users watched inside apps. It’s a great time to start onboarding the Engage SDK now, since the legacy Watch Next API, which has been powering your continue watching 1.0 experience, will lose support in the 2nd half of 2027. To get started, head to goo.gle/engage-tv to learn more. We're excited to see how our latest Gemini experience and developer tools will optimize your discovery and drive user engagement on our platform. Explore this announcement and all Google I/O 2026 updates on io.google.

_Posted by Simona Milanovic and Ben Trengrove, Developer Relations Engineers_ As Android developers, you have many choices when it comes to the agents, tools, command-line interfaces (CLI), and LLMs you use for app development. Whether you use Gemini in Android Studio, Antigravity 2.0, Antigravity CLI, or third-party agents like Anthropic's Claude Code or OpenAI'sCodex, our mission remains the same: to ensure that high-quality Android development is possible everywhere. At **Google I/O ‘26** , we shared the latest leaps forward in agentic development, and showcased some of the newest capabilities of Android CLI—now stable at version 1.0 and ready for all Android developers to use. From new skills to enabling agent access to powerful Android Studio capabilities, we’re giving your agents the right tools to build alongside you. If you’re already using Android CLI and want to jump into using all the new features, just run `android update```. Otherwise, read further to learn more about how we’re making the agents you choose be better at building for Android. ### Android development unlocked for Antigravity Google Antigravity now includes an optional bundle of Android resources—including the Android CLI and skills—that you can install. You can either install the bundle during onboarding after installation, or later from the **Settings > Customizations > Build With Google Plugins** menu. This provides Antigravity with all the powerful tools and knowledge of Android CLI, enabling it to perform the core tasks necessary for Android app development more easily and efficiently—from creating projects to deploying your app on a new Android virtual device. _ _You can now easily install Android CLI for use with Google Antigravity 2.0._ _ ### Unlocking Android Studio capabilities for any agent Android CLI provides a lightweight interface for AI Agents to perform tasks and retrieve knowledge about Android development. However, there's benefits to specialization — Android Studio contains over a decade of Android expertise, built to handle even the most complex Android projects. This includes Android Studio's powerful static analysis engine, refactoring tools, dependency management, UI design and rendering libraries, and more. AI Agents can now tap into Android Studio's tools to gain many of these same capabilities. _Your agents can now use Android CLI to access powerful capabilities of Android Studio._ The latest version of Android CLI introduces the new `android studio` command. This enables the agent of your choice to leverage the deep, contextual capabilities of Android Studio to better understand and perform actions on an open Android project. By running Android Studio alongside your preferred agent with Android CLI, your agent’s tasks can more efficiently navigate the codebase to produce more precise code changes. And, when you use Android CLI to create and iterate on your project, transitioning to Android Studio is much easier, so that you can use the purpose built tools—such as, performance profilers, Compose Previews, and Android Device Streaming—to get that production-grade polish. When you have a project open in the latest preview version of Android Studio Quail, you (or your agent) can run the following command to check whether Android CLI has a connection established with your open project: $ android studio check pid: 32942 version: Android Studio Projects:     READY     JetSet /Users/adarshf/AndroidStudioProjects/jetset-main From there, the agents can use the `android studio` command to access powerful IDE tools to interact with projects more efficiently. Key commands include: * **analyze-file:** Analyzes a file for errors and warnings using the editor's built-in inspections. * **find-declaration:** Finds the exact definition site of a symbol (class, method, variable, field, constant, or Android resource/color) across the project using semantic resolution. * **find-usages:** Finds all references and declarations of a symbol (class, method, variable, or Android resource) across the entire project using semantic analysis. * **render-compose-preview:** Renders a Jetpack Compose UI Preview and returns a path to the image and UI hierarchy if successful. * **version-lookup:** Get the latest information about which versions for specified app dependencies are available in common repositories, such as the Google Maven repository. By providing a programmatic solution, dependency management is less tedious and much less prone to flakiness. * **open-file:** Opens a file directly in Android Studio. This is useful if the agent wants to direct your attention to view Compose Previews, performance traces, or other specific files in the IDE. For example, agents can now run the following commands to render a Compose preview for a new layout for your Android app, and then open the previews in Android Studio for you to take advantage of seeing multiple Compose Previews side by side and make AI-assisted edits right from the IDE. $ android studio find-declaration HotelDetailScreen $ android studio analyze-file .../JetPacker/feature/detail/src/main/java/com/example/jetset/feature/detail/HotelDetailScreen.kt $ android studio open-file feature/detail/src/main/java/com/example/jetset/feature/detail/HotelDetailScreen.kt To learn more about how to use these commands, run `android help`. And, to make sure your agents understand how to work with this tool, make sure to update the Android CLI skill by running `android init`. ### More ways to get started To make integrating Android CLI into your environments as seamless as possible, we’re making it available in more ways. You can now download and install Android CLI using more package managers: apt-get, winget, and homebrew. For example, you can run the following to install Android CLI using winget: winget install -e --id Google.AndroidCLI We’ve also updated the installation to a user-local directory, by default. You can find the commands for all supported operating systems plus additional download options on the Android CLI page. ### Support for Journeys _Journeys are natural language descriptions of core user experiences._ _(sped up) An agent running a Journey it generated for an app._ Agents can run these journeys using the Android CLI to navigate your app exactly like a user would. This unlocks entirely new ways to test, validate, or collect data across the critical experiences of your app, all driven by natural language and executed by your agent. ### Expanding Android skills To help models better understand and execute specific patterns that follow our best practices, we are continuing to expand our library of Android skills. We’re shipping new skills that make Android development everywhere more capable, efficient, and productive: * **Display Glasses and Jetpack Compose Glimmer for XR:** Provides guidelines for developing projected applications for Android Display Glasses using the Jetpack Compose Glimmer UI toolkit. * **Migration to CameraX:** Helps you migrate legacy Android camera implementations (Camera1 or raw Camera2 APIs) to CameraX. * **Perfetto SQL:** Translates natural language data prompts into Perfetto SQL queries and executes them against a local trace file. * **Adaptive UI:** Instructions to make or update an app's UI so that it adapts to different Android devices * **Testing setup:** Creates a basic testing strategy. * **Styles:** Helps with adoption of the new Jetpack Compose Style API for new components, and supports migration to Styles API. * **AppFunctions:** Analyzes Android codebases to recommend and implement new AppFunctions, and refines KDoc documentation for Model Context Protocol optimization. You can add these new skills to your workflow directly from the command line. To help your agents understand and use Android CLI right away, you can initialize your environment and install the base android-cli skill by running: android init From there, you can browse and set up your agent workflow by searching for the exact capabilities your agent needs: android skills list Once you've found the right skill, install it to your environment by running: android skills add –skill=<skill-name> ### Get started today To download the stable 1.0 release of the Android CLI, explore the new tools, and browse the complete documentation, head over to d.android.com/tools/agents today! Also, make sure you update to the latest preview version of Android Studio to unlock the latest features that Android CLI offers. We can't wait to see what you build with Android CLI 1.0 and how these new features supercharge your daily workflows. Join our vibrant community on LinkedIn, Medium, YouTube, or X and share your feedback. Explore this announcement and all Google I/O 2026 updates on io.google.

Posted by Android XR Team The Android XR ecosystem is expanding, and we’re committed to supporting developers who will build its next great experiences. Today, we’re opening applications for the Android XR Developer Catalyst Program, a dedicated initiative to accelerate the development of Android XR apps ready to launch within the next year. This program is designed to provide the resources, hardware, and grants to help you build and scale innovative experiences across wired XR glasses, like XREAL’s Project Aura, and intelligent eyewear (audio and display glasses). We are especially interested in seeing innovative experiences across media, gaming, productivity, and health, but we welcome any unique use case that helps users expand what's possible. ### Why join the catalyst program? We want to help developers navigate common barriers to entry for XR development by providing: * **Development Kits:** Get early access to hardware development kits for wired XR glasses (XREAL’s Project Aura) and / or intelligent eyewear (audio and display glasses). * **Technical support:** Gain access to specialized technical resources and support forums specifically designed to help you prepare your app for Google Play. * **Grant Opportunities:** Submit a request and you may be eligible to receive a non-recoupable grant to accelerate your development. ### Ready to start building? Applications are open to developers looking to publish apps for the Android XR ecosystem in the next 6-12 months. You can build with Kotlin and the Jetpack XR SDK, or with Unity, Unreal Engine or Godot. If you need a spark of inspiration, you can check out existing XR Experiments and Samples to see how you can use the SDK for everything from spatial music to navigation. Once you have your concept ready, be sure to submit your application by June 30th by 11:59PM PDT. We can’t wait to see what you build. **Start Your Application** Explore this announcement and all Google I/O 2026 updates on io.google.

_Posted Fahd Imtiaz, Senior Product Manager, Adaptive Apps_ _ _ _ _ With the release of Android 17, we are transitioning into an adaptive first development standard. Your users no longer rely on a single form factor; they transition between phones, foldables, tablets, laptops, automotive displays, and immersive XR environments throughout their day. Now, with over **580 million large screen devices** in the hands of users, adaptive is no longer just a technical goal. It’s a massive opportunity to reach highly engaged users. To thrive in this multi-device ecosystem, your app must be resilient, responsive, and ready for virtually any surface. ### The multi-device opportunity The Android device universe is now a multi device reality. Users are buying into entire ecosystems, moving from handhelds to foldables, tablets, and cars. And the data is clear: users with multiple devices often spend more than users with only a phone. * **Drive higher revenue:** Multi-device users spend **9x more** on average than phone only users. On foldables, that engagement multiplier can reach 14x. _(Source: Google Internal Data, 2026)_ * **Capture high-value segments:** Large-screen users (tablets, foldables, and Chromebooks) typically spend roughly **5x more** than phone-only users. To help amplify your reach with these users, we've rolled out a new badge in Google Play. Apps meeting adaptive quality standards now earn an "Optimized for large screens" badge, making it easier for users to discover high quality experiences. ### Latest in adaptive Android development from Google I/O Android 17, new Jetpack updates and advanced tools help you build apps that feel native across diverse surfaces, from pocket-sized foldables to Googlebooks. **Adaptive by default: Android 17 updates** In Android 16, we introduced significant changes to orientation and resizability APIs to facilitate adaptive behavior, while providing a temporary opt-out to help you make the transition. Android 17 (API level 37) sets a new quality baseline by removing that developer opt-out for orientation and resizability restrictions on large screen devices (sw > 600 dp). When you target API level 37, your app must be capable of adapting to a variety of display sizes. This helps your app deliver an experience that matches the users’ expectations. _Tip: You can start testing these behaviors by enabling the UNIVERSAL_RESIZABLE_BY_DEFAULT flag in App Compatibility Changes under Developer Options under SDK 36._ **Your app on even more surfaces** In addition to your mobile app running on large screens devices including foldables, tablets, Chromebooks and XR, we are also expanding the Android surface area for your mobile apps: * **Connected Displays:** Now in stable as of Android 16 QPR3, Connected Displays support enables supported Pixel and Samsung mobile devices to transform into a desktop environment via external display support. * **Automotive & TV:** With the Car Ready Mobile Apps program and enhanced pointer support for Android TV, your adaptive app can now benefit from engagement on the infotainment system and the living room with ease. **Googlebook: Evolving desktop computing** Talking about more surfaces, we’re evolving our work in the desktop space with Googlebook, the next generation of ChromeOS. Built with parts of the Android stack, we are enabling your apps to achieve a "laptop-class" feel with native level performance. Building with adaptive principles today helps ensure your app is ready for this new generation of high performance hardware. To help you prepare for this new generation of devices, we’ve released comprehensive new documentation including comprehensive design guidance and developer guidelines. Built on the principles of adaptive, these guidelines offer a playbook for transitioning your mobile apps to offer a premium desktop class experience. Try out the new Desktop Emulator, available now in the Android Studio Canary to get started today. ** ** ** Building adaptive layouts with Jetpack Compose** We are now Compose first and Jetpack Compose is our recommended way to build modern, adaptive UIs to help you manage layout complexity efficiently. * **New layout primitives:** We’re introducing Grid and FlexBox layouts, bringing powerful, CSS-inspired capabilities to Compose for both 1D and 2D layouts. * **Navigation 3:** The 1.1 release for compose-navigation3 introduces Scene Decorators, allowing you to wrap your screens with other content, such as bars, rails and dialogs. * **MediaQuery API:** The new experimental MediaQuery API provides observable device UI capabilities, such as window size and pointer precision, that allow you to adapt and optimize your app's UI for the current device configuration. * **Styles API:** Dynamically evolve the visual properties of your app using the new state-based experimental Styles API. **Beyond layouts: non-touch input** Adaptive app quality goes beyond window dimensions, including handling non-touch input paradigms e.g. keyboard, trackpad, mouse, stylus that are primary input methods on large screens. * **Trackpad support:** Compose 1.11 now brings trackpad support on par with mouse, and provides new APIs to automate non-touch input testing including `TrackpadInjectionScope` and `performTrackpadInput`. * **Focus indicators:** Enhance accessibility with built-in support for standard focus rings in Compose. ** ** ** AI-Powered developer tools** Android Studio and Android CLI are evolving to help you architect adaptive apps faster than ever. * **Android Skills:** These modular AI instructions are designed to assist any LLM through complex architectural tasks, including helping you with View-to-Compose migrations, implementing adaptive layouts, Navigation 2 to Navigation 3 transformation, and migrating off of legacy camera libraries to CameraX. Get started with these latest skills on the Android Skills Github repo and via Android CLI. * **New Project Agent:** Available in Android Studio Panda 2, this agent initializes new projects with adaptive best practices by default. For developers working with cross-platform frameworks, we continue to provide full support for Web, Qt, and Unity. Whether you are building from scratch or modernizing a legacy codebase, these tools are designed to meet your users exactly where they are. We’re excited to see how you bring these new adaptive capabilities to your apps. By moving to an adaptive first approach, you’re not just reaching more users but you’re delivering the seamless, high quality experiences they expect across the entire Android device landscape. Get started with adaptive development and start shaping the future of your apps. Explore this announcement and all Google I/O 2026 updates on io.google.