Android Developers Blog

Delivering safer, age-appropriate experiences on Google Play

2026-07-29T06:00:00.000-07:00

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.

Celebrating 5 years of Jetpack Compose

2026-07-28T09:00:00.000-07:00

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!

How R8 made Kotlin Coroutines on Android 2x faster

2026-07-27T06:00:00.000-07:00

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.

Optimize your apps for the next generation of Samsung Galaxy devices

2026-07-22T12:00:00.000-07:00

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!

Build intelligent Android apps: Cloud and hybrid inference

2026-07-21T06:00:00.000-07:00

Posted by Thomas Ezan, Jolanda Verhoef, Caren Chang, Senior Developer Relations Engineers, Android Developer Relations

Welcome back to the blog post series "Build intelligent Android apps" where we take a basic Android app and transform it into a personalized, intelligent, and agentic experience. In our previous post we explored how to build intelligent on-device features using Gemini Nano through ML Kit's Prompt API.

In this post, we will look at how you can leverage Firebase AI Logic to build cloud-hosted and hybrid AI features:

Grounding answers in real-world context
Routing requests dynamically between cloud and local execution using hybrid inference
Translating content with custom routing systems

Sometimes a use case requires AI models with greater world knowledge, a much larger context window, or the ability to handle complex queries. In those scenarios, we can leverage cloud models.

Other times, you want the best of both worlds: using hybrid inference to run on-device when available to lower costs, while falling back to the cloud to ensure compatibility for all devices.

Cloud and hybrid features in Jetpacker: Museum assistant with web grounding, hybrid restaurant review drafting, and support chat featuring custom-routed live translation.

Let’s look at how we implemented three cloud and hybrid features in Jetpacker:

a museum assistant with web grounding
hybrid restaurant review drafting
hotel support chat featuring custom-routed live translation.

Use LLM grounding for up-to-date informationMuseum assistant chatbot with LLM grounding

The Museum assistant is an interactive chatbot designed to help users plan their museum visits. It provides visitors with up-to-date details regarding specific exhibits, current opening hours, ticket pricing, and more.

Museum assistant is a chatbot that answers questions, such as

‘How can I get a ticket discount for Le Louvre?’

When building AI features, getting the model to answer with fresh, accurate, and specific real-world information is a common challenge. While cloud models possess massive amounts of world knowledge, they might not know about seasonal exhibits or the current day’s opening hours.

Grounding data is added to the context window to enable the model

to answer questions correctly and accurately.

To bridge this gap, we can use grounding techniques to add extra context to the model’s context window. The Firebase AI Logic SDK supports three types of grounding:

URL grounding: Grounding responses using content from a specific webpage (e.g. current ticket prices or museum rules).
Google Search grounding: Letting the model query the real-time Google search index for up-to-date details.
Maps grounding: Using Google Maps location data.

In Jetpacker, we dynamically construct the available tools based on enabled feature flags and initialize the generative model using the Firebase AI SDK:

// implementation("com.google.firebase:firebase-ai-logic")

private var toolList = mutableListOf<Tool>()

init {
    if (ENABLE_SEARCH_GROUNDING) {
        toolList.add(Tool.googleSearch())
    }
    if (ENABLE_URL_GROUNDING) {
        toolList.add(Tool.urlContext())
    }
}

private val generativeModel = Firebase.ai(backend = GenerativeBackend.googleAI())
    .generativeModel(
        modelName = "gemini-3-flash",
        systemInstruction = content {
            text("You are a helpful museum assistant answering questions about a museum. Use plain text.")
        },
        tools = toolList
    )

When the user queries the assistant, if URL grounding is enabled, we append the specific museum resource URLs directly into the prompt:

val groundingText = if (FeatureFlags.ENABLE_URL_GROUNDING) {
    "\n If the following message above is about the rules and terms to visit Le Louvre, " +
    "if needed answer this urls ${urlList.joinToString()}"
} else {
    ""
}

val prompt = "$text $groundingText"

var response = chat.sendMessage(prompt)

Hybrid inference: On-device review generation with Maps deep link

Not every AI task requires a cloud-based model, and not every device is online. To help developers balance latency, cost, and offline availability, we recently introduced the Firebase API for Hybrid Inference.

In Jetpacker, the restaurant review feature lets users review select topics and automatically drafts a review. To enable this for all users, we prioritize local execution with Gemini Nano, and fall back to cloud models on devices that don’t support Gemini Nano.

The restaurant review feature uses hybrid inference to draft a review based on topics

// implementation("com.google.firebase:firebase-ai-logic")
// implementation("com.google.firebase:firebase-ai-ondevice:16.0.0-beta03")


// Initialize the model with hybrid routing configuration
val reviewModel = Firebase.ai.generativeModel(
    modelName = "gemini-3.1-flash-lite",
    onDeviceConfig = OnDeviceConfig(
        inferenceMode = InferenceMode.PREFER_ON_DEVICE
    )
)

The Hybrid Inference API supports four distinct routing modes:

PREFER_ON_DEVICE: Prioritizes local execution and falls back to cloud if Gemini Nano is unavailable.
PREFER_IN_CLOUD: Prioritizes cloud execution and falls back to on-device if the device goes offline.
ONLY_ON_DEVICE: Restricts execution strictly to the device.
ONLY_IN_CLOUD: Restricts execution strictly to the cloud.

Once the review is generated, we copy it to the clipboard and use an intent to open Google Maps directly to the restaurant's review page, providing a seamless user experience:

private fun copyAndOpenMapsReview(context: Context, reviewText: String, placeId: String) {
    val clipboard = context.getSystemService(Context.CLIPBOARD_SERVICE) as ClipboardManager
    val clip = ClipData.newPlainText("User Review", reviewText)
    clipboard.setPrimaryClip(clip)

    val uri = Uri.parse("https://search.google.com/local/writereview/mobile?placeid=$placeId")
    val intent = Intent(Intent.ACTION_VIEW, uri).apply {
        setPackage("com.google.android.apps.maps")
    }
    context.startActivity(intent)
}

Custom hybrid routing: Hotel support chat translation with simulated personas

The hotel support chat was built to let users finalize logistics and check on hotel details. This feature uses system instructions to configure a localized receptionist assistant. By passing specific information—such as the preferred language and hotel information—in the instructions, we can set up a conversational persona representing a specific hotel.

private val generativeModel = Firebase.ai(backend = GenerativeBackend.googleAI())
    .generativeModel(
        systemInstruction = content {
            text("""
              You are a helpful hotel receptionist at $hotelName only speaking $language. 
              Answer politely in $language. The bar closes at 10pm and breakfast is from 7am to 10am.
              There's someone at the desk 24/7. You can retrieve your luggage from the storage room 
              at the back of the lobby at any time.
              """)
        },
        modelName = "gemini-3-flash-preview"
    )

Because receptionist responses are in the hotel's local language (for example, French for Hotel Le Meurice in Paris), we need to translate messages to the user’s preferred language.

Hotel support chat messages are automatically translated to the user’s preferred language

While hybrid models can configure simple routing preferences, complex scenarios require custom routing logic. In Jetpacker, we implement a custom routing stack that takes into account:

Language identification: Using the on-device ML Kit Language Identification API, we can detect the incoming message language.
On-device translation (Gemini Nano): ML Kit’s Prompt API lets us translate common language pairs directly on the device, saving bandwidth and cloud cost.
Cloud translation (Gemini 3 Flash): For more complex languages, we use Gemini Flash 3 to get a higher quality translation.

// implementation("com.google.android.gms:play-services-mlkit-language-id:17.0.0") 

// ML Kit for Language Identification (powered by Google Play Services)
private val languageIdentifier = LanguageIdentification.getClient()

// On-device translator model (prefer Gemini Nano) for translating common language pairs
private val hybridTranslationModel = Firebase.ai(backend = GenerativeBackend.googleAI())
    .generativeModel(
        modelName = "gemini-3-flash",
        onDeviceConfig = OnDeviceConfig(mode = InferenceMode.PREFER_ON_DEVICE)
    )

// Cloud translator model for more complex language pairs
private val cloudTranslationModel = Firebase.ai(backend = GenerativeBackend.googleAI())
    .generativeModel(
        modelName = "gemini-3-flash"
    )

When a message needs to be translated, we identify the source language and apply our custom routing logic, executing either on-device or cloud translation:

fun translateMessage(message: SupportChatMessage) {
    viewModelScope.launch {
        // 1. Detect language using ML Kit Language Identification
        val sourceLang = try {
            Tasks.await(languageIdentifier.identifyLanguage(message.text))
        } catch (e: Exception) {
            "Undefined"
        }

        // 2. Custom routing: we've verified the translation quality for English and Korean with Gemini Nano, and will translate message on-device for those two languages
        val routeToCloud = sourceLang != "en" && sourceLang != "kr"

        val prompt = "Translate the following text to $selectedLanguage. Just return the translated sentence: ${message.text}."

        val (translatedText, routePrefix) = if (routeToCloud) {
            val result = cloudTranslationModel.generateContent(prompt)
            result.text to "[Cloud]"
        } else {
            val result = hybridTranslationModel.generateContent(prompt)
            result.text to "[On-Device]"
        }

        if (translatedText != null) {
            _translations.update { current ->
                current + (message.id to "$routePrefix: $translatedText")
            }
        }
    }
}

In this example, the custom routing logic only takes into consideration the translation’s source and target language. However, based on your app’s use case, you can expand the routing logic to include other factors such as the on-device model version, network connectivity, battery status, and more.

Securing the AI Pipelines: Firebase App Check

Lastly, using AI in the cloud opens up possibilities of API key abuse or unauthorized billing. To secure API calls, we integrated Firebase App Check using both Play Integrity (production) and the local Debug Provider (for local development or emulators).

In the JetPackerApplication.kt file, we install the debug provider at startup and trigger anonymous authentication to establish a secure user session:

//  implementation("com.google.firebase:firebase-appcheck-playintegrity") 
//  implementation("com.google.firebase:firebase-appcheck-debug")  
//  implementation("com.google.firebase:firebase-auth") 

override fun onCreate() {
    super.onCreate()
    Firebase.initialize(context = this)
    Firebase.appCheck.installAppCheckProviderFactory(
        DebugAppCheckProviderFactory.getInstance()
    )
    Firebase.auth.signInAnonymously()
}

When building locally on an emulator, App Check prints a local token secret to logcat:

Enter this debug secret into the allow list in the Firebase Console: a8c2dd4c-xxxx-xxxx-xxxx-ef6c114ba27e

Once registered in the Firebase console, local requests are fully verified and authenticated by App Check, protecting our backend while letting us test the app locally.

Conclusion

By combining cloud model capabilities (grounding, system instructions) with on-device capabilities (hybrid routing, translation, security app checks), we created a travel app that is smart, secure, and available offline.

Check out the full source code for Jetpacker on GitHub, and explore the Firebase documentation to get started:

Firebase AI Logic Documentation
Firebase Hybrid Inference API

Learn more

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. 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 (this post!): 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!

All code snippets in this blog post follow the following copyright notice:

Copyright 2026 Google LLC.
SPDX-License-Identifier: Apache-2.0

Build intelligent Android apps: Integrate into Android's intelligence system using AppFunctions

2026-07-21T06:00:00.000-07:00

Posted by Ben Weiss, Senior Developer Relations Engineer, Android Developer Relations

Welcome back to the blog post series "Build intelligent Android apps" where we take a basic Android app and transform it into a personalized, intelligent, and agentic experience. In our previous post, we explored how to leverage Firebase AI Logic to build cloud-hosted and hybrid AI features.

Traditional mobile UIs excel at focused, hands-on tasks, and the Android intelligence system is introducing complementary features to make complex, multi-step actions even easier. By supplementing traditional user interfaces, AppFunctions provide a powerful new entry point: A privileged agent on the device can access app features in the background. This can be particularly helpful when users are driving, walking or otherwise multitasking.

In this article, we'll show you how we designed and integrated these capabilities into our travel planning app, JetPacker, using Android AppFunctions. We'll explore the rationale behind our feature choices, discuss the specialized tooling we used to accelerate development, and dive into the code that makes it all work.

Designing AI-ready features: making choices that matter for your users

To select which features to provide to the intelligence system, we looked for tasks where a voice or text command is objectively faster than tapping through screens. In this side-by-side screen recording you can see this contrast perfectly: on the left, a user tapping through multiple screens to log an expense; on the right, the same task completed instantly in the background via a privileged agent.

Our first choice was expense tracking. Logging a coffee expense during a trip usually takes quite a few taps—unlocking the phone, opening the app, finding the active trip, navigating to the expenses tab, tapping the add button, taking a picture of the receipt, and checking the result. By providing the addExpense and getExpenses features as AppFunctions, the system agent handles the heavy lifting. When the user says, "Add a five-dollar coffee expense to my Paris trip," the agent automatically searches for the correct trip ID in the background and inserts the expense, skipping the manual UI flow entirely.

We also prioritized itinerary management. Finding what activity is next on a busy trip itinerary usually requires scrolling through a dense timeline view. By providing getItinerary and addItineraryEvent to the system, the user can simply ask, "What am I doing next in Paris?" and get an immediate answer.

Finally, we focused on hands-free note capturing. Typing out reminders or notes while walking down a busy street is difficult and unsafe. Exposing a voice note capability allows the user to say, "The flight was amazing, I saw a beautiful sunset and managed to sleep well," and the privileged agent automatically transcribes and saves it directly into the travel database using the addVoiceNote AppFunction.

Android MCP powered by AppFunctions

This entire experience is built on Android MCP. Under this design, the app acts as a local MCP server. Rather than remote APIs, you provide your app features directly to the on-device intelligence system.

Android AppFunctions is the API that brings this concept to life. It reads annotated Kotlin functions and compiles them into type-safe, sandboxed tool definitions that the privileged agent can discover and invoke locally on the device.

Diagram highlighting our apps, the android platform, and system agents coordinate AppFunctions.

Under the Android MCP model, your app acts as a local MCP server that exposes structured tools, while the Android platform serves as the central tool registry. On the MCP client side, agent apps are registered with the intelligence system after being granted system-privileged permissions to access the registry.

When a user interacts with a registered agent, its LLM determines if the request can be handled by an AppFunction, queries the platform's metadata, and executes the appropriate registered functions in the background. This local MCP client-server design gives you full control: you choose exactly which features are accessible to the agent, keeping the rest of your app's data private.

How we accelerated development with Android skills

To streamline the integration process, we leveraged the AppFunctions development skill. The AppFunctions development skill is a complete development companion. It guided us through the entire lifecycle: mapping Kotlin data classes to serialize parameters, generating the necessary Service entry points, refining our KDoc documentation to ensure the LLM understands parameter boundaries, and setting up automated testing using ADB.

Providing app features to the intelligence system

Enough with the theory, let's dive into the implementation.

Configuration and dependency setup

We begin by adding the AppFunctions dependencies. One for the API and one for the Kotlin Symbol Processing compiler.

implementation("androidx.appfunctions:appfunctions:1.0.0-alpha10")
ksp("androidx.appfunctions:appfunctions-compiler:1.0.0-alpha10")

Modeling custom data types

Any custom object exchanged with the agent must be annotated with @AppFunctionSerializable. In our TripSerializable.kt file, we define our trip data model:

@AppFunctionSerializable(isDescribedByKDoc = true)
data class TripSerializable(
    /** The trip's unique identifier. */
    val id: String,
    /** The trip's title. */
    val title: String,
    /** The trip's destination location. */
    val location: String,
    /** The trip's start date in milliseconds. */
    val startDate: Long,
    /** The trip's end date in milliseconds. */
    val endDate: Long,
    /** A list of participants. */
    val participants: List<String>,
)

Providing features using the @AppFunction annotation

Next, the skill wrote the Kotlin functions that perform the database queries and annotate them with @AppFunction. We can view this in searchTrip:

/**
 * Looks for trips based on optional filters like id, title (name), location, and dates.
 *
 * @param id The unique identifier of the trip.
 * @param title The title or name of the trip.
 * @param location The destination location.
 * @param startDate The minimum start date in milliseconds.
 * @param endDate The maximum end date in milliseconds.
 * @return A list of trips matching the filters.
 */
@AppFunction(isDescribedByKDoc = true)
suspend fun searchTrip(
    id: String? = null,
    title: String? = null,
    location: String? = null,
    startDate: Long? = null,
    endDate: Long? = null
): List<TripSerializable> {
    return withContext(Dispatchers.IO) {
    // implementation
}

Since AppFunctions run on the UI thread by default, we use withContext(Dispatchers.IO) to switch to a background dispatcher. Additionally, we refine our KDoc to use clear, imperative verbs and specify parameter constraints. This documentation compiles directly into the tool's schema, which the privileged agent uses to resolve parameters and handle runtime errors.

The service entry point and Hilt integration

To register these features with the intelligence system, we create an abstract base class that extends AppFunctionService. We annotate it with @AppFunctionServiceEntryPoint:

@RequiresApi(36)
@AndroidEntryPoint
@AppFunctionServiceEntryPoint(
    serviceName = "JetPackerAppFunctionService",
    appFunctionXmlFileName = "jetpacker_app_function_service"
)
abstract class BaseJetPackerAppFunctionService : AppFunctionService() {
    @Inject internal lateinit var tripDao: TripDao
    // DAOs and database references are injected here...
}

During compilation, KSP generates the final concrete service subclass, JetPackerAppFunctionService, as declared with the serviceName parameter. We also register app_metadata.xml in the app's manifest. This file provides global operational rules for JetPacker's declared AppFunctions.

Testing and verifying your AppFunctions

Once implemented, you should verify that your AppFunctions are registered and working correctly.

Running devices or emulators with Android 17 or newer, you can use ADB commands from your terminal to list and invoke your functions. Running adb shell cmd app_function list-app-functions displays all registered functions for your package. You can then execute a specific function and test its database integration by running adb shell cmd app_function execute-app-function while passing a raw JSON parameters string.

Instead of these ADB commands, you can also use the AppFunctions Testing Agent to inspect your configuration, list and execute AppFunctions, and even see how your AppFunctions behave in a real conversational flow.

Wrapping it up

When thinking about app features that can be contributed to the intelligence system using AppFunctions requires a slight shift in how we think about code and documentation. AppFunctions enable you to use this new interaction model for apps, which allows using an agent to access app features..

First, the AppFunctions development skill is an essential lifecycle tool, helping you discover features, implement and refine AppFunctions for your apps. Second, KDoc comments are a compiled API asset; clear parameter descriptions directly impact the execution accuracy of the system agent. Finally, Android MCP provides local-first execution allowing apps to safely collaborate with AI agents.

Contributing app features through AppFunctions makes your application ready for the intelligence system. Let us know how you are adapting your apps for the agentic era!

Learn more

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. 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 (this post!): 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!

All code snippets in this blog post follow the following copyright notice:

Copyright 2026 Google LLC.
SPDX-License-Identifier: Apache-2.0

Build intelligent Android apps: Introduction to Jetpacker

2026-07-21T06:00:00.000-07:00

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!

Build intelligent Android apps: On-device inference

2026-07-21T06:00:00.000-07:00

Posted by Caren Chang, Developer Relations Engineer, Android Developer Relations

Welcome back to the blog post series "Build intelligent Android apps" where we take a basic Android app and transform it into a personalized, intelligent, and agentic experience. In our previous post we introduced Jetpacker, the demo app we'll use throughout this series.

In this blog post, we will share how you can use Gemini Nano through ML Kit’s Prompt API to build intelligent on-device features.

Building intelligent on-device features refers to the ability to process prompts and data directly on a device without sending data to a server. This offers a few advantages:

User data can be processed locally on the device, preserving user privacy
Functionality of the model is reliable even with spotty or no internet connection
No additional cloud inference cost, since everything runs on the user’s hardware

With the benefits of on-device in mind, we identified three features to add in Jetpacker that can improve the user experience: summarizing trip itineraries, managing expenses, and capturing voice notes.

On-device features in Jetpacker: Summarizing trip itineraries, managing expenses, and voice notes

High quality tailored summarization of short texts

The itinerary screen gives users a quick overview of all activities for a given trip. Since this screen contains a lot of information, it can quickly become overwhelming. To help users prepare without feeling overwhelmed, we can add a ‘Get ready for your trip’ section at the top.

The romantic Paris trip is summarized as a classic Parisian adventure blending art, sights, and delicious food. A tip and some useful phrases are also added.

By inputting a trip itinerary and asking an LLM to summarize it, we can generate a quick summary of the trip along with packing tips and useful local phrases. This is a great use case for an on-device model for several reasons:

Performance and quality: Both the input and output text are relatively short. With that, we can expect the performance and quality of an on-device solution to be on par with more powerful cloud models.
Scalability: Shifting inference on-device allows us to scale this feature from a few users to millions without worrying about managing increasing cloud inference costs.
Low latency and reliability: On-device inference guarantees low latency, providing a reliable experience even when users are offline.

To build with on-device, we use Gemini Nano, Google’s most efficient model optimized for mobile devices. Gemini Nano was first introduced a few years ago, and is now running on over 140 million devices. The latest version of the model, Gemini Nano 4, is built on the architecture foundation of the recently released Gemma 4 model, and is further optimized for maximum battery and performance efficiency.

Using ML Kit’s Prompt API, we can take advantage of Gemini Nano 4’s new model capabilities to prototype our on-device features. We’ll create a prompt that includes the itinerary of a trip and ask the model to generate a summary along with any preparation tips.

// implementation("com.google.mlkit:genai-prompt:1.0.0-beta3") 

// Define the configuration for Gemini Nano 4 E2B preview model
val previewFastConfig = generationConfig {
    modelConfig = modelConfig {
        releaseStage = ModelReleaseStage.PREVIEW
        preference = ModelPreference.FAST
    }
}

val geminiNano2BPreviewModel = Generation.getClient(previewFastConfig)

val tripItinerary = ...

val getReadyForYourTripSummary = geminiNano2BPreviewModel
 .generateContent("Given this trip itinerary: $tripItinerary, 
     generate the following: overall vibe, tips on how to prepare for this
     trip, and common short phrases to learn for the trip.")

Finding the optimal prompt usually requires some iteration, and the AICore app is perfect for this step in the process. After opting into the developer preview option for AICore, we can download preview models such as Gemini Nano 4 to test prompts and see the model’s expected outputs. With a few iterations on the prompt, we were able to improve the speed of the response from 13 seconds to under 2 seconds! Check out the final code implementation and prompt here.

The first iteration of our prompt generated way too many tokens, and optimizing it helped keep responses quick and to the point.

Local processing for sensitive user input

Next, to help users enjoy their trip even more, we’ll build a simple expense manager that takes the manual work out of sorting through receipts and calculating budgets.

Taking a photo of a restaurant bill, data is parsed and shown in the expense overview screen of the app.

Since receipts might contain sensitive information like credit card number and addresses, this is another great use case for an on-device solution. With on-device, users can be confident that private information will be processed locally on the device without any of their data being sent to the cloud.

In addition, Gemini Nano 4 has improved model capabilities for multimodality, especially for image understanding tasks like OCR and visual data extraction, making it a great solution for tasks like extracting information from receipts.

For this use case, the prompt will analyze an image of the receipt, and output information such as: a generated title, amount spent and category of the expense. To ensure the model outputs the information in the preferred format, we can use ML Kit’s Structured Output API to seamlessly output a Kotlin data object that we define.

// implementation("com.google.mlkit:genai-prompt:1.0.0-beta3")
// ksp("com.google.mlkit:genai-schema-compiler:1.0.0-alpha1")

@Generable("Information extracted from an expense receipt")
data class ParsedReceipt(
  @Guide("Generated title for the expense less than 6 words. Based on restaurant or activity name.")
  val title: String,
  @Guide("Total amount of the expense. Look for values at the bottom and words like total or balance due.")
  val amount: Double,
  @Guide("Type of expense", enumValues = ["travel", "food", "shopping", "entertainment", "other"])
  val category: String,
)

val prompt = "Determine if the image is a receipt or expense. 
    If it is NOT a receipt or expense, output the text 'NOT_A_RECEIPT'.
    Otherwise, parse the receipt information."

val request = generateContentRequest(ImagePart(bitmap), TextPart(prompt)) {}
val requestWithStructuredOutput = generateTypedContentRequest(request, ParsedReceipt::class)

// Define the configuration for Gemini Nano 4 E4B preview model  
// When selecting models, you can specify which performance charactertists are most important
//  for your use case. Use ModelPreference.FULL when you want to prioritize reasoning power over speed. 
//  Use ModelPreference.FAST when complex logic is not required and latency is a priority.
val previewFullConfig = generationConfig {
    modelConfig = modelConfig {
        releaseStage = ModelReleaseStage.PREVIEW
        preference = ModelPreference.FULL
    }
}

val geminiNano4BPreviewModel = Generation.getClient(previewFullConfig)
val response = geminiNano4BPreviewModel.generateContent(requestWithStructuredOutput)
val parsedReceipt: ParsedReceipt? = response.candidates.firstOrNull()?.response

Multimodal input

Lastly, to help users record audio memos during the trip, let’s build a fully on-device voice notes feature. Using ML Kit’s Speech Recognition API, we’ll enable users to record short voice notes that are automatically transcribed to text. With the transcribed text, we’ll use ML Kit’s Prompt API to identify which trip activity is associated with the recorded voice note, letting users easily recap their trip as they scroll through the trip’s itinerary.

The Roman holiday itinerary shows voice note extracts.

The ML Kit GenAI Speech Recognition API allows you to transcribe audio content to text fully on-device using two distinct modes. Basic mode uses a traditional on-device speech recognition model and is available on most Android devices with API level 31 and higher. Advanced mode uses Gemini Nano to offer broader language coverage and better quality, and is currently supported on Pixel 10 devices.

For our feature we combine the Speech Recognition API with the ML Kit GenAI Prompt API:

// implementation("com.google.mlkit:genai-prompt:1.0.0-beta3")
// implementation("com.google.mlkit:genai-speech-recognition:1.0.0-alpha1")

val tripEvents = ... 

// Set up speech recognition
val speechRecognizerOptions =
    speechRecognizerOptions {
        locale = Locale.US
        preferredMode = SpeechRecognizerOptions.Mode.MODE_ADVANCED
    }
val speechRecognizer: SpeechRecognizer = SpeechRecognition.getClient(speechRecognizerOptions)

suspend fun transcribeVoiceNote(recognizer: SpeechRecognizer) {
    // Display partial text as the user is recording audio
    var partialTextResponse = ""

    // Display the full text once user is finished recording audio
    var transcription = ""

    val request: SpeechRecognizerRequest
        = speechRecognizerRequest { audioSource = AudioSource.fromMic() }
    recognizer.startRecognition(request).collect { response ->
        when (response) {
            is SpeechRecognizerResponse.PartialTextResponse -> {
                partialTextResponse = response.text
            }
            is SpeechRecognizerResponse.FinalTextResponse -> {
                transcription = response.text
                processAndCategorizeVoiceNote(transcription, tripEvents)
            }
        }
    }
}

fun processAndCategorizeVoiceNote(transcribedVoiceNote: String, events: List) {
    val prompt = "Given the voice note $transcribedVoiceNote
     and the following events for this trip: $events, rewrite this transcription
     to remove filler words. Then, identify which events from the
     list this rewritten transcription matches to."

     // Utilize ML Kit's Prompt API to process voice note and tag it with the relevant trip activities
     Generation.getClient().generateContent(prompt)
}

Conclusion

Using ML Kit’s GenAI APIs, we were able to take advantage of Gemini Nano to develop fully on-device intelligent features for the JetPacker app, and provide an improved user experience without any additional cloud costs.

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 intelligent features directly into your app using on-device models, cloud-powered reasoning, and the latest agentic frameworks.

Learn more

Check out the other parts of this blog post series:

Part 1: Introduction of the app and a high-level overview.
Part 2 (this post!): 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!

All code snippets in this blog post follow the following copyright notice:

Copyright 2026 Google LLC.
SPDX-License-Identifier: Apache-2.0

Upcoming Changes to the Nearby Connections API

2026-07-20T06:00:00.000-07:00

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.

Android Studio Quail 2 is Stable: Multi-task with the Android Studio AI agent

2026-07-14T04:00:00.000-07:00

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.

Evolving how LLMs are measured for Android: the next era of Android Bench

2026-07-08T06:00:00.000-07:00

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.

Google Play launches the first Indie Games Fund in Africa

2026-07-06T06:00:00.000-07:00

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.

Eclipsa Video: HDR That Looks Right on Every Screen

2026-06-29T13:00:00.000-07:00

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.

Expanded billing choice and lower fees on Google Play

2026-06-24T07:00:00.000-07:00

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.

Android developer verification: Building a safer ecosystem together

2026-06-18T07:00:00.000-07:00

Posted by Matthew Forsythe, Director Product Management, Android App Safety

July 15, 2026: Updated Play Console requirements for Play developers

To meet Android developer verification and updated Play Console Requirements, Play developers must register their Play apps in Play Console. While 99% of apps on Play have been registered automatically, you should check your Play Console Home page to register any remaining apps by September 30, 2026 to avoid global removal from Google Play and ensure a seamless user installation experience.

You can also use Play Console to register apps you distribute outside of Google Play to ensure they can be installed on certified Android devices.

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.

Building a Mixed-Reality Tour Guide with Android XR, the Geospatial API, and Gemini

2026-06-17T10:00:00.000-07:00

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!

Android 17 is here

2026-06-16T06:00:00.000-07:00

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: UsingPhotoPickerUiCustomizationParams, 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.

What’s New in Android XR: Tooling, Engine Support, and Ecosystem Updates

2026-06-15T06:00:00.000-07:00

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!

Top 3 updates for Android developer productivity

2026-06-09T06:00:00.000-07:00

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.

Datadog delivers millions of in-depth performance insights with ProfilingManager

2026-06-08T06:00:00.000-07:00

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.

Prioritizing Memory Efficiency: Essential Steps for Android 17

2026-06-02T12:00:00.000-07:00

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:

Maximize bytecode optimization with R8
Optimize image loading
Detect and fix memory leaks with Android Studio
Trim memory when app leaves visible state
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

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.
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.
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.
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.
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:

Open the Profiler tab in Android Studio
Click Heap Dump (or "Analyze Memory Usage") and hit record to take a snapshot of your app’s current memory state.
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.
Click on any flagged entry to open the Bitmap Preview pane, allowing you to see exactly which image is the repeat offender.
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.

Building Premium Android Experiences at Google I/O ‘26

2026-06-02T10:00:00.000-07:00

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.

Top AI on Android updates for building intelligent experiences from Google I/O ‘26

2026-05-26T10:30:00.000-07:00

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!

17 Things to know for Android developers at Google I/O

2026-05-19T06:00:00.000-07:00

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!

Build native Android apps in Google AI Studio

2026-05-19T05:45:00.000-07:00

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.

Android Developers Blog

Delivering safer, age-appropriate experiences on Google Play

Empowering developers to create age-appropriate experiences

Simplifying controls for parents

Building on our broader safety tools

Celebrating 5 years of Jetpack Compose

History

Looking back

Looking ahead

Community is at the heart of Compose

Cheers to the next 5 years, and more!

How R8 made Kotlin Coroutines on Android 2x faster

The cost of a coroutine

Investigating AtomicReferenceFieldUpdater

Optimization with R8

Optimizing Atomic*FieldUpdater

Instrumentation

Replacement

Clean-up

Results

Optimize your apps for the next generation of Samsung Galaxy devices

Rethink layout architecture for dynamic displays, including ultra-wide foldables

Ensure seamless camera capture on foldable devices

Extend glanceable interactions to Wear OS 7

Build intelligent features

Start optimizing today

Build intelligent Android apps: Cloud and hybrid inference

Use LLM grounding for up-to-date informationMuseum assistant chatbot with LLM grounding

Hybrid inference: On-device review generation with Maps deep link

Custom hybrid routing: Hotel support chat translation with simulated personas

Securing the AI Pipelines: Firebase App Check

Conclusion

Learn more

Build intelligent Android apps: Integrate into Android's intelligence system using AppFunctions

Designing AI-ready features: making choices that matter for your users

Android MCP powered by AppFunctions

How we accelerated development with Android skills

Providing app features to the intelligence system

Configuration and dependency setup

Modeling custom data types

Providing features using the @AppFunction annotation

The service entry point and Hilt integration

Testing and verifying your AppFunctions

Wrapping it up

Learn more

Build intelligent Android apps: Introduction to Jetpacker

Jetpacker: a demo travel app

On-device intelligence

Cloud & hybrid inference

System integration

In-app agentic workflows (coming soon!)

Learn more

Build intelligent Android apps: On-device inference

On-device features in Jetpacker: Summarizing trip itineraries, managing expenses, and voice notesHigh quality tailored summarization of short texts

Local processing for sensitive user input

Multimodal input

Conclusion

Learn more

Upcoming Changes to the Nearby Connections API

What is changing?

What this means for developers

Timing

Android Studio Quail 2 is Stable: Multi-task with the Android Studio AI agent

Multi-tasking with parallel chats

Memory leak detection with LeakCanary

App Quality Insights agent integration

Quality & stability improvements

Get Started

Evolving how LLMs are measured for Android: the next era of Android Bench

Upgrading our methodology with the Harbor framework

Expanding the leaderboard with 8 new models

Opening Android Bench to community contributions

Looking ahead

Google Play launches the first Indie Games Fund in Africa

Funding and support for selected studios

Who can apply?

Eclipsa Video: HDR That Looks Right on Every Screen

More consistency, comfort, and creative control

Built natively into Android 17

Guidelines for developers & creators

On-device features in Jetpacker: Summarizing trip itineraries, managing expenses, and voice notes

High quality tailored summarization of short texts