Android Developers Blog

6/24/2026

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

6/18/2026

Posted by Matthew Forsythe, Director Product Management, Android App Safety Last year, we introduced Android developer verification to strengthen ecosystem security and stop malicious actors from hiding behind anonymity to release harmful apps. Millions of apps have been registered since the verification launched in March, covering nearly all installs on Google Play and a large majority of installs from outside of Google Play. We appreciate the feedback and partnership from industry leaders, developers, and Android communities that helped us design this experience and drive strong adoption. Initial launch across seven stores and four countries These new developer verification protections will take effect on September 30, 2026, starting with users in Brazil, Indonesia, Singapore, and Thailand. This rollout is an industry-wide effort to create a safer ecosystem. We will begin by verifying app installations from the following stores: Google (Google Play) Honor (HONOR App Market) OPlus (OPPO App Market) Samsung (Galaxy Store) Transsion (Palm Store) vivo (V-Appstore) Xiaomi (GetApps) Following this initial phase with our partners, we will expand these protections globally for all apps on certified Android devices in 2027. Automate your workflow with new APIs To further streamline app registration, we are launching a suite of developer-requested APIs to help you register apps in bulk or directly through your continuous integration and deployment (CI/CD) pipelines. The Android Developer ID Status API will let you check if a package name has already been registered, and the Android Developer Console API will let you register and manage package names directly within your development environment. Both APIs also support OAuth delegation, allowing third-party platforms, like Android app stores, to perform these operations natively on your behalf. 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.

6/17/2026

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

6/16/2026

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

6/15/2026

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!

6/9/2026

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.

6/8/2026

Posted by Alice Yuan, Developer Relations Engineer at Google, Arti Arutiunov, Product Manager at Datadog and Nikita Ogorodnikov, Staff Software Engineer at Datadog 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. 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. 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. Datadog Mobile Real User Monitoring.

6/2/2026

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

6/2/2026

Posted by Ataul Munim, Android Developer Relations Engineer 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.

5/26/2026

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!

5/19/2026

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 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 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 developer documentation, and watch the technical deep dive session where we showcase all these technologies. 6: Experiment with AppFunctions today 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. 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 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 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 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 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 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!

5/19/2026

Posted by Emma-Louise Leavey, Group Product Manager and Mike Taylor-Cai, Product Manager 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 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.

5/19/2026

Posted by Paul Lammertsma, Developer Relations Engineer Drive discovery and engagement with Gemini Gemini, to our platform, so that people can easily find what to watch, learn something new on the big screen, and get everyday tasks done with just their voice. Since launch, we’ve made improvements to how Gemini provides tailored responses to questions. Gemini shares a mix of visuals, videos, and text to help users find what they need, when they need it. For our streaming partners, Gemini is a helpful discovery engine—pulling from your app's metadata to surface your relevant content to viewers. Declare support for pointing modality 1. Adapt your TV app UI Library Hover state: Every focusable element on your screen (buttons, movie posters, setting toggles) needs a clear visual feedback mechanism for a hover state. This is often subtler than a focus state but critical for feedback. Scrollable containers: Pointer remotes will also have a small circular touchpad for scrolling. Users can use this touchpad to scroll up or down, or left or right in your app. Your app will need to respond to touch events to scroll. Cursor clicks: Many TV apps today expect a simple D-pad OKAY button “click.” With a pointer remote, a user may “click” on an element that’s not the D-pad focus state, but is instead from a hovered state (similar to a mouse click). 2. Test pointing interactions with a mouse today 3. Declare TV app support for pointer remotes on Google Play android.software.leanback.supports_touch. This tag informs the platform that your TV app “spatially supports touch,” since pointer remotes simulate touch events from a distance. AndroidManifest.xml <manifest ...> <!-- Signal whether the app is adaptive or built just for TV --> <uses-feature android:name="android.software.leanback" android:required="true|false" /> <!-- Ensure the app can be installed on conventional TVs --> <uses-feature android:name="android.hardware.touchscreen" android:required="false" /> <!-- Signal whether the app supports pointer remotes --> <meta-data android:name="android.software.leanback.supports_touch" android:value="true|false"/> <application ...> ... </application> </manifest> Tips: The android.software.leanback feature declaration indicates that your app supports D-pad navigation and is intended for distribution only on TV devices via Google Play. The new software attribute of android.software.leanback.supports_touch declares that in addition to D-pad, you have ensured that your TV app works well for pointer/cursor experiences via mouse (of today) and pointer remotes (of future). If you haven't already, now is the time to adopt Jetpack Compose. Hover, scroll, and clicks are common input modalities that are supported on various form factors, and building your app with an adaptive UI framework enables code reusability and reduced maintenance. Onboard the Engage SDK Resumption: Partners can easily display a user's paused video within the 'Continue Watching' row from the Home page. Entitlements: The Engage SDK streamlines entitlement management, which matches app content to user eligibility. Users appreciate this because they can enjoy personalized recommendations without needing to manually update all their subscription details. This allows partners to connect with users across multiple discovery points on Google TV. Recommendations: The Engage SDK even highlights personalized recommendations based on content that users watched inside apps. goo.gle/engage-tv to learn more. We're excited to see how our latest Gemini experience and developer tools will optimize your discovery and drive user engagement on our platform. Explore this announcement and all Google I/O 2026 updates on io.google.

5/19/2026

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

5/19/2026

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

5/19/2026

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

5/19/2026

Posted by Stevan Silva, Group Product Manager and Amy Zeppenfeld, Developer Relations Engineer Today we're excited to launch Developer Preview 4 of the Android XR SDK, continuing our focus on unifying cross-device development for headsets, wired XR glasses, and intelligent eyewear. To keep our platform intuitive, we are adopting more descriptive naming for our form factors, where AI glasses are now audio glasses and display AI glasses are now display glasses, with these changes appearing in our documentation starting today. This release is packed with updates that help you build incredible experiences for XR devices, enable deeper immersive experiences on XR headsets, and streamline the path for creating augmented experiences on audio and display glasses. Also, our core libraries—including XR Runtime, Jetpack SceneCore, and ARCore for Jetpack XR— will be officially moving to Beta soon! To give you early access to hardware and resources for building immersive and augmented experiences on upcoming devices—like display and audio glasses and XREAL’s Project Aura — we’re announcing the Android XR Developer Catalyst Program. Learn more and start your application today. Building Augmented Experiences for Audio and Display Glasses Starting out with our libraries for augmented experiences, Developer Preview 4 introduces new APIs that help you create and test your apps. Jetpack Projected: Device Availability and ProjectedTestRule APIs The Jetpack Projected library helps bridge app experiences from the phone to the user's field of view. We've added the Device Availability API, which consolidates wear state and connectivity signals into standard Android Lifecycle.State values. This lets you adjust your applications behavior based on whether the device is worn. val xrDevice = XrDevice.getCurrentDevice(projectedContext) // Observe the device lifecycle flow xrDevice.getLifecycle().currentStateFlow .collect { state -> when (state) { Lifecycle.State.STARTED -> { /* Device is available (worn) */ } Lifecycle.State.CREATED -> { /* Device is unavailable (not worn) */ } Lifecycle.State.DESTROYED -> { /* Device is DISCONNECTED */ } } } To simplify testing, the new ProjectedTestRule API in the projected-testing artifact automates the setup of projected test environments. This helps you write clean, reliable unit tests without the boilerplate code. // from the 'androidx.xr.projected:projected-testing:1.0.0-alpha07' artifact @get:Rule val projectedTestRule = ProjectedTestRule() @Test fun testProjectedContextInitialization() { // by default, ProjectedTestRule automatically creates and connects // a projected device before each test val projectedContext = ProjectedContext.createProjectedDeviceContext(context) // assert the projected context is successfully initialized assertThat(projectedContext).isNotNull() } Jetpack Compose Glimmer: Google Sans Flex and new components Our UI library for display glasses, Jetpack Compose Glimmer, now includes Google Sans Flex for improved legibility on optical see-through displays. We’ve also added several interactive components: Stacks: Designed for touchpad-optimized groups, showing one item at a time. Title Chips: Provides categorization and context for content cards. Building Immersive Experiences for XR Headsets and Wired XR Glasses If you're looking to build fully immersive experiences for XR Headsets and wired XR Glasses, we have several big updates. Beta Transition & Modern Architecture XR Runtime, Jetpack SceneCore, and the ARCore for Jetpack XR perception features (Depth Maps, Eye/Hand Tracking, Hit Testing, and Spatial Anchors) will soon move to Beta, so we’ve streamlined the Jetpack XR APIs. We've removed legacy Guava and RxJava3 packages in favor of a modern, Kotlin-first architecture. Jetpack SceneCore: glTF and Custom Meshes We're expanding 3D model capabilities by adding the ability to fine tune 3D models and access specific nodes with a 3D model. Using GltfModelNode, you can modify properties like pose, materials, and textures, and even run animations for specific nodes. // Create a new PBR material pbrMaterial = KhronosPbrMaterial.create( session = xrSession, alphaMode = AlphaMode.OPAQUE ) // Load a texture. val texture = Texture.create( session = xrSession, path = Path("textures/texture_name.png") ) // Apply the texture and configure occlusion pbrMaterial.setOcclusionTexture( texture = texture, strength = 0.5f ) // Access the hierarchy of nodes val entityNodes = entity.nodes // Find the specific node val myEntityNode = entityNodes.find { it.name == "node_name" } // Apply the PBR material override myEntityNode?.setMaterialOverride( material = newMaterial ) We're also bringing Custom Meshes to SceneCore. Custom meshes let you build geometry on the fly programmatically, which is ideal for creating custom 3D models. This feature will launch as experimental, so try it out and let us know what you think!   // Create the mesh val roadMesh =     CustomMesh.BuilderFromMeshData(session, roadVertexLayout)         .addVertexData(ByteBufferRegion(roadDataBuffer, 0, vertexDataSize))         .setIndexData(ByteBufferRegion(roadDataBuffer, vertexDataSize, indexDataSize))         .setTopology(MeshSubsetTopology.TRIANGLES)         .build() // Define the material val roadMaterial = KhronosPbrMaterial.create(session, AlphaMode.OPAQUE) // Instantiate the entity using the custom mesh and material val roadEntity =     MeshEntity.create(         session,         roadMesh,         listOf(roadMaterial),         pose = roadPose, ) Compose for XR: Native glTF Support We now have native glTF support directly in Compose for XR with SpatialGltfModel. Use this along with SpatialGltfModelState to access nodes and animations in the glTF model, or use them to add textures and materials to your 3D models. val myGltfModelState = rememberSpatialGltfModelState( source = SpatialGltfModelSource.fromPath( Paths.get("models/my_animated_model.glb") ) ) val myGltfAnimation = myGltfModelState.animations.find { it.name == "animation_name" } DisposableEffect(myGltfAnimation) { myGltfAnimation?.loop() onDispose { myGltfAnimation?.stop() } } SpatialGltfModel(state = myGltfModelState, modifier = modifier) ARCore for Jetpack XR: Geospatial API Preview for Wired XR Glasses We’re also providing an early preview of the Geospatial API for wired XR Glasses in ARCore for Jetpack XR. This update enables high-precision anchoring of digital content tied to real-world locations in over 87 countries. By combining ARCore’s Visual Positioning System (VPS) with the reasoning and audio capabilities of the Gemini Live API, you can create contextually aware experiences that understand both the location and position of your user. Imagine building an immersive, AI-guided walking tour that provides real-time audio descriptions of nearby places, seamlessly blending digital information with the physical environment. Start Building the Future Today It's an amazing time to develop for Android XR. With the Jetpack XR SDK moving to Beta soon and a robust set of new tools at your fingertips, explore each of the following areas to get your app's experiences ready for XR! Read the documentation, explore the samples, and check out the XR experiments Head to the official Android Developer site for full technical guides, API reference, and instructions on setting up the new emulator. Get inspired with our samples and experiments. See how we've used these APIs to build immersive spatial layouts, load 3D models, explore spatial audio, and more! Visit the Android XR webpage Explore XR examples Explore XR experiments Check out what's new for game engines We've added official support for Unreal Engine and Godot, and we've launched two new tools to accelerate development for Android XR with Unity and the Android XR Interaction Framework. And, based on your feedback, we are introducing the Android XR Engine Hub to allow you to run your experiences directly from your preferred engine, Read the blog post about what's new for game engines Apply for the Android XR Developer Catalyst Program Don’t miss your chance to build for the latest Android XR hardware. Apply today for the opportunity to gain access to pre-release hardware, including our audio and display glasses prototype and XREAL’s Project Aura. Learn more and apply today. We look forward to seeing the amazing XR experiences you build as we move toward the launch of more Android XR devices later this year! Explore this announcement and all Google I/O 2026 updates on io.google.

5/19/2026

Posted by Luke Hopkins, Android Developer Relations Engineer for OpenXR & Ryan Bartley, Android XR Product Manager Today, we are excited to announce that official support for Unreal Engine and Godot has arrived for Android XR. Alongside these engine expansions, we are also launching new tools designed to boost your productivity and enable new XR capabilities: the Android XR Engine Hub and the Android XR Interaction Framework. Android XR Engine Hub The Android XR Engine Hub is currently available for Windows and is your mission control for development. It unifies your workflow across Unity, Unreal Engine, and Godot by serving as a high-speed bridge that streams device-created perception data straight from your device into the engine of your choice. Real-Time Streaming via OpenXR The Hub bridges the gap between desktop power and mobile sensor data. Instead of requiring a full build to see how your app reacts to the world, the Hub streams OpenXR extensions from the physical Android XR device directly to your Windows machine. This means you can iterate on complex interactions in "Play Mode" while receiving live, high-fidelity data from the headset’s sensors. Without this streaming capability, testing even a minor change to eye-tracking or spatial mapping would require a full APK export and installation. The Hub enables low-latency testing for the following streamed extensions: Core & Interaction Support XR_EXT_hand_tracking & hand_interaction: Streams 26-point hand meshes and joint data for immediate interaction testing. XR_EXT_eye_gaze_interaction: Virtualizes eye-gaze data to test UI and foveated logic on your PC. XR_EXT_palm_pose & XR_EXT_uuid: Real-time precision tracking and persistent object ID streaming. Android XR Vendor Extensions Eye & Face Tracking (XR_ANDROID): Stream expressive avatar data to your editor to refine social presence without building. Passthrough & Trackables: Access live environmental understanding—like plane detection and hit testing—directly within the engine's viewport. By virtualizing the device's hardware capabilities and streaming them over a low-latency desktop bridge, the Android XR Engine Hub allows for game engine developers to quickly iterate. Download the Hub: Get the Android XR Engine Hub for Windows Learn more about Direct Preview Expanding Game Engine Support Through our commitments to OpenXR standards, we are ensuring that whether you are a veteran studio or an indie developer, you have best-in-class tools to help bring your creative vision to life. Unreal Engine Unreal Engine support is now available in developer preview, targeting version 5.6.1. This integration is built directly on using OpenXR with the support for AndroidXR vendor specific API using the Android XR vendor plugin for Unreal, you can access platform-specific extensions for advanced hand tracking, face tracking, and scene understanding (like plane detection and depth) whilst making use of Unreal blueprints or C++ support. Get Started with Unreal: Download the Android XR Extension Plugin for Unreal Official Unreal Engine Website View the Unreal Engine Development Guide Godot In partnership with the Godot Foundation and W4 Games, we are bringing official Godot support to Android XR for Godot 4.6.2 and higher. We are already seeing incredible momentum from W4 as they have ported experiences like MoAT and Expedition to Blobotopia that are already live on Google Play, proving that Godot is ready for production-grade spatial experiences today. To unlock the full potential of the platform, use the Godot OpenXR Vendors plugin 5.1, which provides the necessary Android XR vendor extensions for features like scene meshing, dynamic resolution, light estimation and much more. We're collaborating with Godot to optimize the OpenXR implementation for the Android XR power profile and input standards. Get Started with Godot: Download the Godot OpenXR Vendors Plugin Official Godot Engine Website View the Godot XR Setup Guide Unity The Unity OpenXR: Android XR 1.13 package is now available for Unity 6.5 Beta. Unity has expanded Application SpaceWarp support to include both uGUI and TextMeshPro. Keep an eye out for the general release of Unity 6.5 and more platform enhancements arriving this summer. Android XR Extensions v1.3.1 for Unity Everything else you need for comprehensive platform integration is available in our latest Android XR Extensions release: Spatial API Support: You can now manage the android.software.xr.api.SPATIAL manifest tag directly through XRSessionFeature settings, making it easier than ever to define your app's Spatial API requirements and target levels. Fine Eye Face Tracking: A new Fine Eye Poses feature provides high-precision eye poses using the TryGetFineEyePoses extension method. Direct Preview Support: The Android XR Streaming feature enables Direct Preview support within Unity Editor's PlayMode (Windows only). Note: Android XR (Extensions): Hand Mesh has been removed; you should now use the unified Hand Mesh Data within the extensions package. Android XR Interaction Framework for Unity The Android XR Interaction Framework (AXRIF) is now available in developer preview. AXRIF is an unstyled, opinionated input toolkit that abstracts the complex logic required to build interfaces that are consistent with Android XR system interactions. Instead of focusing on UI visuals, AXRIF prioritizes the underlying mechanics of the Android XR user experience. At its core is the same Transition Manager that powers the system's rich multimodal inputs, enabling state switching between 6DoF controllers, 3D mouse, hand tracking, and eye gaze. By leveraging this framework, developers can significantly reduce the implementation burden required to bring Android XR's full complement of robust interactions to their apps. At launch, the framework provides three core capabilities: Automated Multimodal Input Transitions: The framework manages the state machine for switching between input modalities. For example, it handles the transition logic when a user moves from gaze-targeting an object to directly touching it, simplifying simultaneous support for hands, controllers, and mice. Gaze-Assisted Gesture Interaction: AXRIF combines gaze vector targeting with hand gesture recognition (such as pinch-to-select) for precise distant interaction, matching the system's default behavior. Physics-Based 2D UI Interaction: The framework maps high-fidelity hand tracking to 2D plane interactions, enabling intuitive poke and swipe gestures on floating panels while respecting physical boundary constraints. By adopting AXRIF, your app inherits the platform's native interaction model, ensuring your app feels consistent with the rest of the OS. Explore the Toolkit: Interaction Framework Documentation Download the Unity Package  Get Started Today: There has never been a better time to dive into Android XR development. With support across Unity, Unreal, and Godot, the platform is ready for your creative vision, no matter which engine you call home. Explore our official engine partners to get started: Unity Developer Portal Unreal Engine Developer Community Official Godot Engine Website Explore this announcement and all Google I/O 2026 updates on io.google.

5/19/2026

By Simon Cooke, Developer Relations Engineer (X) and Mayank Jain, Product Manager (X) What is Android Performance Analyzer? Android Performance Analyzer (APA) is Android’s new profiler and performance analysis tool for the Android mobile ecosystem.  APA is intended as a profiling tool for any developer building for Android who needs to make their app or game run better and faster. It is helpful for all performance-minded engineers, especially those using Vulkan in their game engines who want to squeeze every bit of performance out of their code. APA aims to be the tool that helps you optimize apps and games for all modern Android devices and simplifies your most common workflows, with a simple interface that anyone on your team can quickly learn and be productive.  Available today in open beta is APA’s new System Profiler that you can use to analyze the CPU, GPU, Memory, and power usage of your app or game - and see how it interacts with system behavior. Developed in collaboration with Samsung Austin Research Center (SARC) and LunarG, APA relies on Perfetto for system tracing and its upcoming frame profiling/debugging features (stay tuned!) are powered by LunarG’s GFXReconstruct technology for graphics capture and replay. Devices running Android 12+ will provide the best experience for capturing system-wide performance and GPU counters and render stages. We’re also working across the Android ecosystem with our esteemed industry partners to bring more profiling & optimization related data into APA.  Android Performance Analyzer How to get Android Performance Analyzer APA ships in two different forms, and you can download whichever one suits your needs best As a lightweight standalone desktop app. And also integrated directly into Android Studio as the updated System Trace viewer (available in Panda 4 canary builds and later). The standalone desktop app is intended to be used without an Android Studio project or Gradle build - and provides deep customization of recording configuration, built-in Vulkan layers for graphics analysis, deep inspection of GPU counters and much more. APA is also cross-platform: works natively on Windows, MacOS, and Linux. Features in this release Basic profiling functionality Capturing your profile data You don’t always want to take a capture immediately at application or game launch. APA allows you to choose, and capture traces from your device at launch or triggered manually. The user interface allows you to select which GPU counters and other data is captured in a trace - and if you have more complex needs, you can provide your own custom Perfetto configuration. Deep-Dive System Analysis With APA, you can analyze the entire system’s behavior in one view. For example, you can easily examine CPU cores - both their frequencies and the work scheduled on them or inspect processes & their thread activity. For graphics-heavy apps, APA provides GPU performance counter data across hardware from Qualcomm, Arm, Imagination, and Samsung. You can even track battery and power consumption to see the impact of your code on power consumption. To understand exactly where frames are spending time, SurfaceFlinger events provide deep visibility into the rendering and display composition pipeline, from initial code acquisition to final display. And with the new screenshots feature, you can visually scrub through to easily find the exact areas where you want to focus your attention. You can open existing Perfetto traces, zoom through the timeline for precise detail, and use rulers to measure the duration of work and events. APA also lets you bookmark and annotate interesting findings, and you can pin critical tracks to the top of your screen to keep your focus exactly where it needs to be as you optimize. Workflow features Tabbed interface and split windows: You can open multiple traces in side-by-side tabs or split a single trace into two windows to compare different regions of the same trace simultaneously. Tabbed interface showing two traces side-by-side. Project-based workflow: APA uses a project model that allows you to keep track of multiple traces from the project sidebar. This is especially useful for gathering the results of A/B testing and longitudinal tests, and keeping all of your results together for comparison & quick access purposes. The new project window helps you manage multiple traces. Navigate visually using screenshots: APA lets you capture screenshots during a trace (without any noticeable performance overhead) to home in on areas where you saw something affect performance by scrubbing through the timeline. Or even just to get your bearings. Scrubbing the timeline using screenshots for navigation (trace taken from NetMarble’s Seven Deadly Sins: Origin). Persistent view customizations: When you pin or vertically resize tracks, we save those customizations so that they persist the next time you open the trace. Analysis tools & new skills for AI agents Vulkan debug trace markers for render passes: We support Vulkan debug annotations for render passes - which allow you to view Render Pass names you set from your codebase directly in the tracks and slices shown in APA. This immensely helps you to make logical connections between the workloads you see in the profiler to where they are originating from in your codebase. Vulkan Debug Markers allow you to keep track of what kind of work is being performed in your trace. Use AI to build SQL queries for custom analysis work: APA supports trace analysis via SQL queries and ships with a new Perfetto SQL skill for use with your favorite AI agents. This makes it easier to build queries without needing to remember Perfetto SQL schemas or the SQL syntax. AI helps you build SQL queries to perform custom analysis on traces. Ask Gemini to analyze traces for you: We’ve also added another Perfetto Analysis skill to answer high-level questions for you - like “Why is my app startup slow?” - helping you to find starting points when analyzing complex traces, using your favorite AI agent to pinpoint the answers. Agentic trace analysis in Android Performance Analyzer FPS and Frame Duration times : You can review the FPS and Frame duration time at a glance in the tracks to correlate it with other activity happening in your trace.  FPS and Frame timing tracks in APA Speed & robustness improvements Speed and robustness improvements: Rendering a trace is now typically 6x to 26x faster than Android GPU Inspector, and APA is significantly more stable when working with large traces. Case studies We’ve worked with our early access partners to create detailed case studies showcasing how APA could be used to improve performance for Vulkan apps & games. The Forge Interactive The Forge used Android Performance Analyzer to identify the need to batch calls to vkCmdBindDescriptorSets, which reduced CPU setup costs by ~50%. This, in turn, slowed heat production on their device by 2-3x, leading to longer session times. They also used APA to identify opportunities to move font and UI rendering work over to the GPU, improving scalability. You can read the full case study from The Forge here. Note: This case study demonstrates how to use custom SQL queries in the profiler to generate a total rendering cost metric. The Forge case study showing frames presented consistently at a stable 30 FPS using APA NetMarble – Seven Deadly Sins: Origin Netmarble used Android Performance Analyzer to fine-tune their game Seven Deadly Sins: Origin, focusing particularly on improving performance by making changes to the precision of their shaders, and exploring the impact of upscaling on the performance of their renderer. This allowed them to reduce the GPU cost of rendering some scenes by up to 90%.  Read the full NetMarble case study here. Netmarble validating pre- and post-optimization performance changes using APA for their game: Seven Deadly Sins: Origin Profiling model complexity in Google’s Filament engine Google has been improving the Filament glTF Viewer, our physically-based rendering engine. We spent some time digging into the viewer with a variety of scenes, and showed how to use Android Performance Analyzer to identify scenes that are too complex for the GPU, and how to trim them down to hit a target 60FPS, by improving texture compression and optimizing geometry. Memory consumption was also reduced in this process. You can read our exploration of Filament here. Screenshot showing GPU wait time was reduced from 25ms to 20ms by introducing dynamic resolution and measuring it through APA Try out the Android Performance Analyzer Beta today! The Android Performance Analyzer is available for you to try out and use today: Standalone profiler: https://developer.android.com/android-performance-analyzer Android Studio Canary Build (Panda 4 canary builds and later): https://developer.android.com/studio/preview This is beta software, which means that you might run into an occasional bug – please report it to us if you find any (Help Menu > Submit a bug report). We’re excited to see how you use the new Android Performance Analyzer, and how it will help your project’s performance and reliability. Explore this announcement and all Google I/O 2026 updates on io.google.

5/19/2026

Posted by Matthew Warner, Google Product Manager This year at Google I/O we are going beyond iterative changes, towards a fundamental shift in how apps are built. Our newest tools are built for the agentic era with features that boost productivity for you as an Android developer AND supercharge the AI agents you deploy in your codebase. So, whether you are building exclusively with AI or you prefer being the architect of every line of code, our tools will keep you ahead of the curve. As we move from "AI-assisted" to "Agentic" development, we’re making it easier than ever to turn a spark of an idea into a high-quality production app with significantly less developer effort. So what’s new with Android developer tools? We will cover 3 main areas in this blog: Let your agent handle it: Whatever development task you are working on, the Android Studio agent can help: from planning the app architecture and design, to writing code, to unit testing and bug fixing. Any AI provider, anywhere you build: In Android Studio, you can use any model and we even help guide you to the best performing ones. Choose any of the top remote models from Google, Anthropic, OpenAI, or if you need to run locally - Gemma 4 is our most capable and efficient local model! And with Android CLI, you can build Android apps faster and easier using the agents and developer environments of your choice. As always, performance and quality remain top priorities: We continue to invest in the Android developer tools you love: from the Emulator, to Profilers, performance analyzers, and more! 1: Let your agent handle it Agent skills Android Studio now supports Agent Skills, modular instruction sets that ground LLMs in specialized workflows and domain-specific knowledge. By adding skills to your project, you can teach the agent to follow specific best practices, architecture patterns, or library workflows. This enables more accurate, context-aware code generation and automated skill activation for an appropriate task, ensuring the agent acts as an expert. We’ve bundled many of the top Android and Firebase agent skills in the latest Android Studio Canary build, so you can skip straight to building! Skills in Agent Mode You can create your own skill, or use Android CLI to install our official skills - a repository that covers some of the most common workflows that some Android developers and LLMs may struggle with. They help models better understand and execute specific patterns that follow our best practices and guidance on Android development, such as XML to Compose migration, Edge-to-edge, Navigation 3, and more. You can even build for Android XR, starting with a beautiful Display Glasses app with Jetpack Compose Glimmer. Official Android skills are automatically bundled with the latest Android Studio so the Agent is ready to build! Build full-stack apps with Firebase in Agent Mode Firebase services like Auth and Firestore databases can now be enabled directly within Agent Mode in Android Studio using the Agent Skills for Firebase. Your agent will be able to complete Firebase integration and configure backend services. This integration empowers you to build robust, full-stack Android applications without ever leaving your IDE! Building a full-stack app with Firebase via Agent Mode Parallel conversations You can now run multiple conversations with Agent Mode in parallel. In one conversation, run tests and while you are waiting, you can kick off planning mode for a new feature in your app while using a third conversation thread to write documentation for your app. These improvements will save you time and improve your productivity.  Parallel conversations in Agent Mode A more capable New Project Agent Android Studio's New Project Agent has evolved into a powerful full-stack development tool, utilizing a multi-step execution plan and an autonomous "generation loop" that self-corrects build errors and configures dependencies across multiple files. This advanced capability is significantly amplified by its new integration with Firebase Agent Skills, allowing developers to seamlessly build, debug, and deploy complete full-stack applications directly from a single prompt to final production. Building an app with New Project Agent Additionally, it now offers support for large screens. You can scaffold your project with layouts, navigation, and components optimized for tablets, foldables, and laptop devices from the get-go. It has additional logic to test your app on large-screen emulators if you have one enabled. Simply configure the required device in the Android Emulator and the Agent can test it out! Build large screen apps for foldables and tablet devices 2: Any AI provider, anywhere you build Build Android apps in Google AI Studio Google AI Studio now features full Android app development capabilities. Users can generate new applications, preview them instantly via an embedded Android Emulator, and deploy them directly to physical devices using ADB over USB. Additionally, developers can publish straight to Google Play; AI Studio handles the app record creation, bundles the package, and uploads it to an internal testing track. For advanced development and production readiness, projects can be exported as a ZIP file and opened seamlessly in Android Studio. To get started, visit Google AI Studio today and start building! Google AI Studio build mode with Android framework Android CLI helps you build faster, more efficiently with any agent Android CLI enables you to build apps using any agent, LLM, and tool of your choice. Android CLI is designed to help AI agents build faster, and use less tokens when compared to only using generic LLM tools. By grounding agents with Android Knowledge Base and Android skills, you can now have your agent of choice follow the latest best practices across any coding environment. Additionally, when using the latest Canary version of Android Studio Quail, Android CLI enables your agent to leverage powerful capabilities of the IDE, such as analyzing files for issues or finding symbol declarations. Google Antigravity 2.0 now offers official support for Android development with Android CLI. Android CLI enables any agent with the tools and knowledge to build for Android. Google AI plan You can now use your Google AI Pro or Ultra plan to get access to dedicated capacity and higher rate limits for Gemini in Android Studio. This is especially helpful for long agentic Android development sessions, which can require using more tokens. Android Studio detects your subscription automatically when you log in with your Google account.   Use your Google AI plan in Agent Mode Gemma 4 for local code assist and on-device AI Gemma 4 is a state-of-the-art local model trained for Android development. It’s our most efficient local model and is capable of complex multi-step agentic coding in Android Studio. It’s ideal for developers who require data privacy, offline access, or have run into quota issues with other models. And now in the latest Canary build, you can download and run Gemma 4 directly from the IDE, without needing to set up an external server. Model selector in Agent Mode Bring your own model to Android Studio Android Studio allows developers to bring any model they choose into the IDE for agentic AI assistance. Power your workflow with models like Gemini, GPT, and Claude or use a local model like Gemma 4. This flexibility offers developers greater control over performance, privacy, and cost. Settings, Model Provider Android Bench highlights the top models Earlier this year we launched Android Bench, the benchmark and leaderboard designed to evaluate how effectively LLMs handle real-world Android development tasks. The goal is to accelerate AI improvements, leading to more helpful models for you to use for AI assistance, which will lead to better quality apps for Android users. You asked us to evaluate open models, so we added them to the leaderboard to help you see how LLMs with additional privacy and offline access measure up. We are also working on significantly increasing the difficulty of challenges we’re giving LLMs, to continue encouraging improvements. This includes creating long running tasks, which take a typical Android engineer multiple days to complete. Latest results as of May 18th 2026, check here for updates 3: As always, performance and quality remain top priorities: Test multi-device interactions with the Android Emulator The Android Emulator now features a new networking stack that enables zero-configuration, peer-to-peer connectivity between multiple virtual devices on the same host machine. This update eliminates the need for manual port forwarding, allowing developers to easily test multi-device scenarios like local multiplayer gaming, file sharing, and companion app pairing. By creating a shared virtual network backplane, the Android Emulator provides a more stable and consistent environment for building complex, interconnected app experiences across different form factors. Multi -device testing with the Android Emulator Android Debug Bridge Wi-Fi 2.0 ADB Wi-Fi 2.0 offers significantly more reliable wireless debugging. With the latest ADB command line tool from Android Platform Tools v37 and an Android 17 device, you can now change networks, shut down your machine, and go about your typical day and your devices will stay connected. Additionally, devices with wireless debugging enabled will automatically show in Android Studio’s Device Manager, streaming the pairing process and making it easier than ever to connect Android phones, watches, and more. Pair devices with Wi-Fi Android Studio now lets you publish to Google Play for testing Android Studio now gives you the ability to upload new releases of your app directly to Google Play Console test tracks. You can do this by selecting a new option to continue to “Publish for Testing” at the end of the Generate Signed App Bundle flow. This integration supports uploading an initial release of a brand-new app to Play Console’s internal test track. You can also use this feature to upload releases to existing apps to test tracks. You need to be registered on Google Play Console to take advantage of this functionality. Read the ‘What’s new in Google Play’ blog to learn about all the updates from Play at I/O. Upload App Bundle to Google Play Android developer verification support You can now see your app's registration status right in Android Studio when you generate a signed App Bundle or APK. Seeing this information in Android Studio enables you to address registration issues early and ensure your apps are ready before the verification requirement goes into effect for certified Android devices starting in September 2026. App registration status with Android developer verification 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 (GC) from reclaiming that memory, eventually leading to sluggish performance or OutOfMemoryError (OOM). The Android Studio LeakCanary profiler task significantly enhances developer productivity by enabling the analysis and inspection of memory leak traces directly on the desktop development environment rather than on the mobile device. Furthermore, Android Studio streamlines troubleshooting by providing tools like “Go to declaration” to map the leak analysis directly to the codebase, allowing developers to quickly locate and resolve memory leaks. Starting from the Android Studio Quail 1 release, you can now also request Gemini to review the memory leak for you using the “Fix with Agent” button. Review memory leaks identified via LeakCanary through the “Fix with Agent” button Android Performance Analyzer (APA) Android Performance Analyzer (APA) is the next generation of performance profiler for Android and provides a cohesive analysis of CPU, GPU, memory, and power usage for your apps and games running on Android 12+ devices. APA is engineered for reliability and performance with trace rendering speeds which are up to 26x faster from previous tooling. Android Performance Analyzer (APA) running in Android Studio showing two traces side by side APA integrates natively with AI agents and offers two new skills: Perfetto SQL skill and the Perfetto Analysis skill, which helps with questions like "Why is my app startup slow?" Analysis of traces using Perfetto Analysis skill R8 Configuration Analyzer R8 is one of the best ways to improve your app’s performance and reduce memory footprint. The performance benefits you can get from R8 are directly correlated to how much of your codebase R8 is able to optimize. We’ve introduced a new tool to help you to unlock the maximum optimization from R8 – the R8 Configuration Analyzer. It provides insights into R8 configuration quality and how your keep rules impact your app. We have also introduced three scores that show how much of your codebase is available for optimization, obfuscation, and shrinking. Suggested fixes for crashes with Agent integration in AQI The App Quality Insights tool window is now integrated with the AI agent to analyze crash data along with your source code to provide detailed explanations and suggest potential fixes. After selecting a crash in the App Quality Insights tool window, navigate to the Insights tab and click “See more” to see a detailed explanation of the crash. Click “Fix with AI” to have the agent suggest code changes that you can review and accept. App Quality Insights and Fix with AI Get started Android Studio is closing the gap between ideation and implementation. With powerful tools built for agentic development, it’s never been easier to build and ship high-quality Android apps. Download the latest Android Studio Quail preview build and try these new features. As always, your feedback is crucial to us. Check known issues, report bugs, and be part of our vibrant community on LinkedIn, YouTube, or X. Happy coding! Explore this announcement and all Google I/O 2026 updates on io.google.

5/19/2026

Posted by Nick Butcher, Product Manager In the almost-5-years since Jetpack Compose launched, we've invested in bringing you all the features, performance and tools that you need to build amazing UIs across the variety of Android devices. Compose helps you to build beautiful, adaptive UIs that meet the demands of modern UI design. Rich feature set: With a powerful library of layouts, input, graphics, animation APIs, and the latest Material Design components, Compose empowers you to build anything. Highly performant: Out of the box, Compose offers native performance, delivering a delightful experience to your users. Adaptive: Compose offers the easiest way to build adaptive apps that work across the range of Android form factors. Productive: With powerful tools like Previews and Live Edit and the full expressiveness of Kotlin, teams tell us that they move much faster when building with Jetpack Compose, reducing the time to market. Compose has matured into the standard for Android UI development—we believe that all Android UI should be built with Compose; we call this going Compose First. From today, we'll provide all APIs, libraries, tools and guidance in Compose. We now consider the View components that Compose replaces (components in the android.widget package) to be in maintenance mode. We have no plans to deprecate or remove View components and will continue to support them with critical bug fixes, but they will receive no new features. View-based Jetpack Libraries The same goes for View based libraries like Fragments, RecyclerView or Viewpager — we consider them complete and will only publish critical bugfixes. For a complete list of libraries now in maintenance mode, see here. Tools Any new Android Studio UI tools will be built for Jetpack Compose only. Existing view-based tools (such as the Navigation Editor and Layout Editor) are now in maintenance mode and will not receive new features. Guidance Documentation, codelabs, and samples will focus on building UI with Jetpack Compose. You can still find Views-specific documentation linked from pages that contain generic and Compose information, where relevant. Happy Composing We recommend that you build all new features with Compose and convert existing features when you touch them to gain the many Compose benefits. Check out our XML to Compose migration skill to help you convert existing layouts to Compose. To learn about the latest Compose release, check out What’s new in the Jetpack Compose April ‘26 release blog and the roadmap for what’s planned ahead. Thank you for all of the feature-requests and feedback that have helped shape Compose to become our recommended UI toolkit. As always, if you have any more feedback, let us know. Happy composing! Explore this announcement and all Google I/O 2026 updates on io.google.

5/19/2026

Posted by Jan Kleinert, Developer Relations Engineer, Android for Cars, Noam Gefen, Senior Product Manager, and Thomas Weathers, Developer Relations Engineer, Android for Cars We're thrilled to see developers continuing to bring their apps and experiences to Android for Cars! Over the past year, we've continued to see strong growth and momentum in the app ecosystem on Android Auto and cars with Google built-in. This year at Google I/O, we're introducing updates that benefit both drivers and developers by enabling richer, more differentiated in-car experiences. With new features and templates that allow you to build once to reach users across different infotainment screens and car platforms, it's easier than ever to build for the road. What's new in the Car App Library We're bringing more flexibility, new components, and new template capabilities to the Car App Library. Car App Library 1.8.0-beta01 and Car App Library 1.9.0-alpha01 are now available. Build templated media apps for both Android Auto and Android Automotive OS Developers can now build customized, distraction-optimized, media browsing and playback experiences for Android Automotive OS, making it easier to build once and deliver these templated media apps to more users and more cars. To help you test the experiences on Android Automotive OS, we'll be launching updated system images for the Android Automotive OS emulator. Beginning with revision 3, the API level 35-ext15 system images will support apps built using the Car App Library media templates. Unlocking developer creativity with Car App Library 1.9.0 alpha With the 1.9.0-alpha01 release of the Car App Library, we're bringing features to help you build more differentiated, expressive experiences across Android Auto and cars with Google built-in. We're increasing the modularity of existing templates to give developers more flexibility and options for laying out content. These improvements include expanded headers for better visual emphasis, such as on detail pages, spotlight sections that can be placed in scrollable areas to highlight specific content, and grid item variations to support different content types and states. We're introducing new components and template capabilities to help developers build even more engaging experiences. For media apps, we're introducing an adaptive mini-player, so users can browse while still easily managing playback. Finally, we're adding more component types including Chip and CondensedItem to increase the ways that content can be displayed and interacted with. App developers, including those shown below, have already begun building upgraded media experiences using these new Car App Library features. You can join these developers and prepare to distribute your own media apps built with the Car App Library templates by applying to participate in our early-access beta program. Amazon Music, Gaana, PocketFM, Spotify, TuneIn, YouTube Music Distribute your adaptive video apps to more cars with minimal effort You’ve already built the apps, now we’re helping you reach more users. For the first time in Android Auto, users will be able to sit back, relax, and watch videos while parked. Apps, like YouTube, will be able to deliver smooth, 60fps HD video playback. This brings the Android Auto parked experience in line with the high-fidelity, immersive experiences users already enjoy in cars with Google built-in. This capability will start rolling out to compatible vehicles later this year, for users with phones running Android 17 and higher. If your video app is already adaptive, making it available for parked use cases in cars requires minimal effort. To express interest in making your video app available on Android Auto, fill out this form. Widgets are coming to cars The next generation of Android Auto brings a more expansive user interface and the Material 3 Expressive design system you know from the phone into the car, built to seamlessly fill larger screens no matter what shape they are. With this new design, the investments you've already made in mobile widgets will be available to users of Android Auto this year, and cars with Google built-in later on, opening up new ways to reach and engage with your users while they're on the road. We're excited to unlock these new glanceable user journeys! The road ahead You can look forward to even more updates coming to cars later this year. To deliver a more continuous user experience, we're making it possible for you to provide a templated experience while driving that can seamlessly transition to a native, adaptive app experience when the vehicle is parked. New components and conversational templates will be coming to the Car App Library, so you can integrate agentic and voice-based flows more seamlessly in apps. Improved app brand expression across all car surfaces allow experiences built with the Car App Library to feel easily recognizable by your users. Google Maps SDK support is coming to cars with Google built-in. With this change, you'll be able to use the Google Maps SDK to render map-based content with the MapWithContentTemplate in point-of-interest (POI) and Weather apps on both Android Auto and cars with Google built-in. Stay updated on these features and start building with the latest at goo.gle/cars-whats-new. Explore this announcement and all Google I/O 2026 updates on io.google.

5/19/2026

Posted by Paul Feng, VP, Google Play Eng, Product, UX At Google Play, we’re passionate about helping people connect with the experiences they’ll love, while empowering developers like you to turn great ideas into lasting business success. At this year’s Google I/O, we talked about our evolving business model that offers more choice and new ways for your apps and content to be discovered on and off the store. We also unveiled advanced tools and insights that will help scale your business with less complexity. Expanding your reach by meeting users where they are Your apps and the incredible worlds you build are no longer just a single destination, but connected experiences that reach users across surfaces and devices. To help you meet users where they are, Google Play continues to evolve into a content-forward destination that delivers immersive and personalized experiences on the store, across their devices, and directly within your apps and games. Beyond the store: Expanding discovery to new surfaces & devices We're unlocking new opportunities for your apps and content to be discovered across the wider Android ecosystem. Surfacing your apps and content in Gemini: As people increasingly start their journeys with virtual assistants, we want to ensure your apps and their content are an essential part of this. In the coming weeks, we're enabling app discovery in the Gemini app on Android and Web, connecting your apps and games to millions of Gemini users. Later this year, Gemini will also surface over 450,000 movies and TV shows, as well as where to stream live sports, and deep-link users directly into your app content. Gemini will provide users with app suggestions and direct access  to entertainment content during a search. Delivering personalized content across the ecosystem: Engage SDK surfaces deliver your content to over 30 million monthly active users and drive millions of app opens every month—a massive 45% increase year-over-year. And we’re making it even more powerful by expanding support for new surfaces and devices. Store listing integration: Starting next month, existing users will see Engage SDK content directly on your store listings. New tablet surfaces: We’re broadening reach across Android tablet surfaces, including home screen Collections. Global scale: Every Engage SDK surface can now scale your content across over 80 Play markets. Boost re-engagement by integrating with Engage SDK today. If your app is already integrated, no further action is required to benefit from these updates. On the store: Enhancing content formats and conversational search We’re also optimizing the Play Store to help grow your audience with engaging content formats and a more intelligent search experience, to make it easier than ever for users to find and connect with your app. Capturing attention with Play Shorts: Our full-screen, portrait, short-form video feed gives users a glimpse of your app’s look, feel, and functionality. Play Shorts is rolling out to users in the US and select developers, and we look forward to expanding this to more markets and developers in the coming months. Play Shorts provides a glimpse into your app’s look, feel & functionality. Enabling deeper search journeys with Ask Play: Building on AI-powered Q&A, which already answers 95% of user queries, we’re introducing Ask Play. This AI-powered overlay turns discovery into a natural conversation, understanding the full context of a user's question and adapting to follow-ups to recommend the right app. Plus, with Ask Play highlights, users can get a high-level summary of complex searches directly on the search results page to help find the right apps or games more effortlessly. Ask Play understands the full context and helps users find the right apps or games. In your games: Deepening player engagement and community Once players launch your title, the real challenge is keeping them in the action. Play Games Sidekick provides an in-game overlay that gives players instant access to gaming information—like AI-generated Game Tips, rewards, and achievements — driving higher engagement while keeping players immersed. Sidekick has already debuted in over 100+ titles, and we’re building on this momentum with: New social features: Starting next month, players can see which friends are playing the same game and track their achievements Global expansion: Sidekick expands to all participating titles this summer. Head over to Play Console to enable Sidekick and begin testing the user experience so that you're ready for our global launch, while also meeting one of our core Level Up program guidelines. Scaling your business with less complexity We’re streamlining your day-to-day tasks while providing more comprehensive reporting to help you capture more growth opportunities. Streamline your Play Store operations with AI We’re using Gemini models to handle the heavy lifting of localizing your store content and managing your catalog. Localize with less effort: Eliminate manual copy-pasting by uploading a structured file (like a CSV or Google Sheet). Gemini models enable Play Console to pre-populate your listings across different languages for your review. You can also leverage AI-translated subscription benefits to quickly scale your localization efforts. Instantly pre-populate store listings with localized translations. Convert search trends into growth: We’ve simplified the path from insight to action. When you click a keyword recommendation on your Grow overview page, Gemini creates a new custom store listing automatically tailored to that keyword—ready to deploy with just one click. Simplify catalog management: We’re introducing agentic catalog management to help you manage your one-time products. Soon, you can leverage new in-console capabilities to execute bulk price changes, import SKUs, and configure metadata, saving hours of manual work. New agentic capabilities in Play Console will make managing your catalog seamless. Behind-the-scenes features that optimize your revenue We’re building tools to maximize your revenue at every stage—with zero developer work required. When a user decides to buy, our platform helps ensure that the transaction completes at the point of conversion, renewal, and retention. Optimizing conversion with delayed charging: When a payment initially fails, our risk models evaluate the transaction. If it’s low-risk, we grant the user access to your paid content while we retry the charge in the background. This means your lowest-risk subscribers get the best experience and you are less likely to lose them due to a temporary glitch. Boosting renewals with extended recovery periods: To prevent involuntary churn, we’ve extended the default account recovery period from 30 to 60 days to give subscribers more time to fix failed payments, like expired credit cards. This shift has driven up to an 18% reduction in involuntary churn and a 9% reduction in total churn for top developers. Maximizing retention with flexible flows: A rigid experience makes retention nearly impossible. Coming soon, our new in-app subscription management API lets subscribers change plans or accept a downgrade offer the moment they hit “cancel.” Combined with replacement modes that automate prorated refunds, you’ll have a powerful toolkit to save at-risk subscribers. Flexible flows let subscribers change plans or accept downgrades to boost retention. More reporting and AI-powered insights We’re providing more data and more AI-powered insights to help you understand your performance and ROI on Play. Measure your full marketing impact: See your app’s total visibility on Play with our new reach metric. Gain better insight into store listing performance with indirect value not previously reported. Analyze downstream impact—like engagement, retention, and monetization—with our new traffic source breakdowns. Optimize the path to purchase and retention: We’ve added cart conversion rates to your core performance metrics to help you identify and fix friction in your checkout flow. New data on subscriber tenure and churn reasons allow you to better pinpoint why subscribers leave and which segments are most at risk. Get faster answers: Using Gemini models, we’re expanding chart descriptions from the Statistics page to the Reach & Devices and Store Performance pages to help you spot trends instantly. With new interactive Q&A and proactive monetization insights, you can ask why a metric shifted and instantly receive tailored recommendations to optimize your business. Get instant answers and recommendations for optimizing your business. Protecting your success In addition to making it easier and faster to publish safer apps, we’re also making it easier to secure your app’s revenue and reputation. Defend your business against fraud and abuse: The new Protected with Play dashboard helps you monitor and configure your integrity, distribution, and monetization defenses all in one place. We’re also reducing warm-up latency for Play Integrity API, so you can use these checks during speed-critical user journeys to block threats and risky devices faster. The Protected with Play dashboard provides centralized insights to help you safeguard your app. Get proactive protection for your store and revenue: We work behind the scenes to help stop malicious activity before it impacts your business. Last year, our automated anti-spam protections blocked 160 million spam ratings and reviews while our anti-fraud efforts automatically protected apps using Play Billing from 3.2 billion dollars in fraud and abuse. Growing your business on Google Play Our latest updates reinforce our commitment to deliver the highest return on your team’s investment, by expanding your reach beyond the store, simplifying your day-to-day operations, and helping you better safeguard your success. We’re excited to see you use these new capabilities to create even more impactful experiences. Thank you for being a part of the Google Play community. Learn more about these announcements and all other Google I/O 2026 updates on io.google starting May 21.

5/19/2026

Posted by John Zoeller, Developer Relations Engineer Today, we are excited to introduce Wear OS 7, a major update that brings a new era of power efficiency and intelligence to users and developers alike. We recognize that watches are essential, all-day companions to your users. That’s why we're continuing to invest in power optimizations so your users can do more with their favorite apps. For watches upgrading from Wear OS 6 to Wear OS 7, average users can expect up to 10% improvement in battery life. As part of a broader rollout to the Android ecosystem, select watches arriving later this year will come with Gemini Intelligence, providing proactive and personalized help to our users so they can focus on what matters. With Wear OS 7, we’re introducing new system capabilities and enhanced developer tools. New user-facing features like Live Updates, and enhanced media controls deliver a smarter, more intuitive personalized experience on the wrist. And with enhancements to our developer toolkit such as Wear Compose 1.6 and AppFunctions, developers will be able to streamline their apps for efficient, intuitive experiences on the wrist. Let's dive right in! Wear OS 7 Canary You can now try out the next version of Google’s smartwatch platform, Wear OS 7 Canary Emulator, based on Android 17 that's arriving later this year. The new emulator allows you to get hands-on with the developer features and tools mentioned above while testing your app for compatibility with the upcoming platform. Check out what’s changed and start testing your app today. Explore new Wear OS features Wear OS Widgets Full-screen Tiles have been a go-to surface on Wear OS, providing users with instant, glanceable access to their essential updates. As the Android ecosystem moves further toward a unified vision for widgets, we’re bringing the watch closer to the rest of the Android family with the goal of minimizing efforts for developers. Today, we’re excited to introduce the next step in the evolution of Tiles: flexible and dynamic Wear Widgets. Powered by Jetpack Glance and the new RemoteCompose framework, Wear Widgets offer greater expressiveness and consistency with Compose than the Tiles ProtoLayout libraries. Wear Widgets support two new card layouts—small and large, that align perfectly with the 2x1 and 2x2 formats on mobile, ensuring your designs feel cohesive across devices, while still allowing you to optimize your designs for the wrist. It’s easy to adapt the UI from the mainSlot of your full-screen tile to a 2x2 Widget. Take a look! Check out the Widgets I/O Talk later this week for full details on the new features, and try out our Widgets Getting Started Guide to add a Widget to your Wear OS experience. Live Updates Wear OS 7 brings Live Updates to watches! You can use Live Updates to surface real-time, important information from your watch or mobile app, providing your users with timely updates at a glance. In your watch app, use Live Updates instead of the Ongoing Activities API to provide local update publishing on all Wear 7 devices. For supporting OEMs, Live Updates published by your phone app will also be bridged to users' watches. Check out how Just Eat provides updates to their users, above! For more information, check out Notifications on Wear OS. Connect your app to the intelligence system We're working on several ways for developers to provide agentic experiences on the watch, from AppFunctions to task automation tools. We’ll announce these on our developer blog when they’re ready, and provide an all-encompassing developer guide to help you choose the right one and craft a robust implementation. For now, here's a quick look. AppFunctions The AppFunctions API allows developers to integrate their apps with agents and assistants, like Google Gemini, enabling users to complete tasks using voice, often replacing the need for step-by-step, manual navigation with your UI.   For example, to start a run with the Samsung Health app, users are able to tell Gemini: “Start tracking my run.” We’re currently running an Early Access Program for any developers who are interested. Sign up in our form to express your interest. Task automation Also coming soon, without any development effort at all, users will be able to invoke and track automated app tasks, for selected phone apps, directly from their watch, like placing an order with DoorDash! Keep an eye out for these flexible options on how to prepare and connect your app to the Android intelligence system on our developer blog. Wear Workout Tracker We know that building a full-featured, high-quality fitness tracking experience on Wear OS from scratch is resource-intensive, so we built the all new Wear Workout Tracker experience for exercise apps. It will be included in Wear OS later in the year.  The workout tracker provides a rich standardized workout tracking experience which includes heart rate monitoring, media control, and a collection of other useful features to help you reduce development investment while guaranteeing a high-quality experience for your users. We’ve been working closely with ASICS Runkeeper to bring it to their users, check it out! Enhanced System Media Controls in Wear OS 7 Wear OS 7 enhances the System Media Controls, giving users more control and seamless experiences for their media. Per-App media auto-launch controls Users can now personalize their media auto-launch experience per-app directly from the System Media Controls on the watch. For any app where the user has ‘Auto-launch Settings’ toggled on, media controls will automatically appear on the watch when media is started on the phone. Developers with an existing implementation of media apps that extend on the watch can benefit from this feature without additional effort. Seamless audio routing with the Remote Output Switcher Managing audio output is now easier than ever with the new Remote Output Switcher integrated into the System Media Controls.  When listening to media on a paired phone, users can effortlessly switch the device the media is played back on directly from their wrist. UI Library updates To go along with all these new features for users, we’re introducing some powerful enhancements to our developer toolkits to help developers prepare for the future of Wear OS! Compose for Wear OS 1.6 As the foundation for Wear OS development, Compose for Wear OS 1.6 has arrived. It includes powerful updates including: Streamlined navigation with Navigation 3 Developers can Integrate with Navigation 3 to provide a more flexible and Compose-idiomatic way to handle navigation on Wear OS. @Composable fun WearApp() { val backStack = rememberNavBackStack(MenuScreen) WearAppTheme { AppScaffold { val entryProvider = remember { entryProvider<NavKey> { entry<MenuScreen> { GreetingScreen() } entry<ListNavScreen> { ListScreen() } } } val swipeDismissableSceneStrategy = rememberSwipeDismissableSceneStrategy<NavKey>() NavDisplay( backStack = backStack, entryProvider = entryProvider, sceneStrategies = listOf(swipeDismissableSceneStrategy) ) } } } List management improvements for TransformingLazyColumn Significant improvements are here for advanced list management with TransformingLazyColumn, including enhanced padding support via the new minimumVerticalContentPadding modifier, and other new features like snapping and reverse layout. val listState = rememberTransformingLazyColumnState() val transformationSpec = rememberTransformationSpec() /*  * TransformingLazyColumn takes care of the horizontal and vertical  * padding for the list and handles scrolling.  */ ScreenScaffold(scrollState = listState) { contentPadding ->     TransformingLazyColumn(         state = listState,         contentPadding = contentPadding     ) {         item {             ListHeader(                 modifier = Modifier                     .fillMaxWidth()                     .transformedHeight(this, transformationSpec)                     .minimumVerticalContentPadding(                         ListHeaderDefaults.minimumTopListContentPadding                     ),                     transformation = SurfaceTransformation(transformationSpec)             ) { Text(text = "Header") }         }     } } Optimize ambient experiences with LocalAmbientModeManager The all new LocalAmbientModeManager is optimized for handling ambient flows, giving developers greater control over how their ambient experiences are presented to users. override fun onCreate(savedInstanceState: Bundle?) {     setContent {         val ambientModeManager = rememberAmbientModeManager()         CompositionLocalProvider(LocalAmbientModeManager provides ambientModeManager) {             val localAmbientModeManager = LocalAmbientModeManager.current             val ambientMode = localAmbientModeManager?.currentAmbientMode             Column(                 verticalArrangement = Arrangement.Center,                 horizontalAlignment = Alignment.CenterHorizontally,                 modifier = Modifier.fillMaxSize(),             ) {                 val ambientModeName =                     when (ambientMode) {                         is AmbientMode.Interactive -> "Interactive"                         is AmbientMode.Ambient -> "Ambient"                         else -> "Unknown"                     }                 val color = if (ambientMode is AmbientMode.Ambient) Color.Gray                     else Color.Yellow                 Text(text = "$ambientModeName Mode", color = color)             }         }     } } Protolayout & Tiles updates While we encourage developers to adopt the new Wear Widgets, we will continue to support our Protolayout and Tiles libraries for some time, and we’ve got new stable versions of both. Protolayout 1.4 and Tiles 1.6 work together to provide several notable new features including: Inlined Image Resources: ImageResource can now be directly inlined within a layout, and Tiles now support automatic resource collection through ProtoLayoutScope,removing the need for manual resource mapping and splitting into separate methods. In addition to better code quality, this improves Tiles loading latency via consolidation into a single binder call from system to the provider service. Material3TileService: Tiles can be implemented as a Material3TileService – an all-encompassing suspend function which returns both tile layout and resources, while automatically managing the MaterialScope and ProtoLayoutScope to simplify the development experience. Dynamic Service Switching: On Wear 7, multiple TileService instances can now be grouped in the manifest to enable dynamic switching between different services that represent the same tile. Check out the new Tiles sample here. WFF 5 Watch Face Format version 5 (WFF5) is now available with a host of new features to make it easier to build watch faces, including: Enhanced Alignment Options: Text elements like TextCircular have additional alignment options, including verticalAlign on the same baseline for multiple text elements. Auto-Size Enhancements: isAutoSize can now be used on TextCircular,and a new attribute, minSize, has been added to the Font element to limit the minimum size when autosizing is enabled. Blend Modes: Group and ComplicationSlot elements now support blend mode, in addition to existing support on Part* elements. Stroke Joins: Stroke and WeightedStroke elements now include a join attribute. Hierarchical settings: User Styles can now be structured as a hierarchy, where some settings are visible only when other settings have specific values. User Styles can now enable or disable complication slots as well. These can be configured using the childSettingIds and complicationSlotIds on User Style Options. Check out our new developer guidance to learn more about WFF 5. Start building for Wear OS 7 now With these updates, there’s never been a better time to develop an app on Wear OS. These technical resources are a great place to learn more about how to get started: Learn about designing and developing for Wear OS Check out Wear OS samples on Github Get started with the latest Wear OS 7 emulator We’re looking forward to seeing the experiences that you build on Wear OS! Explore this announcement and all Google I/O 2026 updates on io.google.

5/15/2026

Posted by Garan Jenkin, Wear OS Developer Relations Engineer FotMob recently experienced its largest single-day increase on Wear OS among its installed audience in 5 years, at 2-3x the daily average. The secret? A simple cross-device installation flow that helps users discover their Wear OS app directly from their phone. FotMob is one of the world’s most popular football (some call it soccer!) platforms, known for its mobile app that provides real-time scores, statistical analysis, and news. FotMob is available on mobile and Wear OS In addition to the mobile app, FotMob is available on Wear OS, allowing users to keep on top of the latest scores and results directly from their wrist. “Many FotMob users follow matches live, and that often happens when they’re not actively using their phone,” says Roy Solberg, Android Tech Lead at FotMob. “Wear OS gives fans a quick way to glance at scores, match events, and updates directly from their wrist, so we saw it as a natural extension of the FotMob experience.” By providing a smooth experience across different form factors, FotMob ensures that their users can continue to get the most from their platform, in the most convenient form. This includes ensuring that settings and preferences–such as favorite teams–are synced across devices. The Discovery Gap Despite many FotMob users having a Wear OS device, FotMob realized that some users might not be aware of the Wear OS app. This led the team to consider technical options for how to educate users about and ultimately install the Wear OS app directly from within the core phone app. Fortunately, the Wearable library on Android and Wear OS provides exactly the building blocks that FotMob needed to create an in-app experience that would allow their users to do just that. Detecting Eligible Wear OS Devices Within the FotMob phone app, the team used the NodeClient to identify connected Wear OS devices - candidates for the Wear OS app: val connectedNodes = nodeClient.connectedNodes.await() Additionally, the team defined a capability within the Wear OS app, indicating that FotMob was installed on the device. This is defined as an XML resource in the Wear OS package, and then queried within the phone app: val nodesWithApp = capabilityClient .getCapability(CAPABILITY_WEAR_APP, CapabilityClient.FILTER_REACHABLE) .await() .nodes By looking for only nodes without the capability, the team ensured the FotMob phone app only lists Wear OS devices without the app. Initiating the install flow The FotMob team designed an educational half-page prompt that quickly makes the user aware of the opportunity, allowing them either to kick off the install flow, or dismiss it. This featured a prominent screenshot of the Wear OS experience, allowing the user to immediately see how the app might look on their watch. To start the installation, the app uses the RemoteActivityHelper API, to launch the Play Store on the watch: val remoteActivityHelper = RemoteActivityHelper(context) remoteActivityHelper.startRemoteActivity( Intent(Intent.ACTION_VIEW) .setData("market://details?id=${context.packageName}".toUri()) .addCategory(Intent.CATEGORY_BROWSABLE), nodeId ).await() Results “The Wearable APIs made the implementation straightforward,” says Roy. “Being able to detect connected devices and query capabilities meant we could quickly determine whether the watch app was already installed. From there it was mostly about designing a prompt that felt helpful to users rather than intrusive.” The rollout of the cross-device installation feature saw the largest single-day increase in FotMob’s installed audience on Wear OS in 5 years, 2-3x higher than the normal install rate. Within 48 hours of the rollout reaching 100%, the watch app gained over 1,500 new installs¹. “Within the first 10 days we saw a significant jump in new Wear OS installs,” says Roy. “The watch app has been around for years, but this confirmed that many users with compatible devices simply weren’t aware it existed.” Evolving cross-device installs In addition to the solution employed by FotMob, we’ve now launched a library to make it even easier to implement these cross-device installation journeys through the In-App Install Prompts library. The following is an example of adding an installation prompt at the appropriate point in your app: val crossDevicePromptManager = CrossDevicePromptManagerFactory.create(activity) val request = CrossDevicePromptInstallationRequest.create() try { val info = crossDevicePromptManager.requestInstallationPromptFlow(request).await() crossDevicePromptManager.launchPromptFlow(activity, info).await() } catch (e: CrossDevicePromptException) { Log.e(TAG, "Cross-device prompt failed with error: ${e.errorCode}", e) } Next steps: Start building your own cross-device journey today Dive into the DataLayer sample to learn more about how to add cross-device functionality to your app, and explore the new In-App Install Prompts library, providing you with options for how you help your users achieve cross-device installation. [1]. Install data from Play Developer Console

5/14/2026

Posted by Nataraj KR, Android Developer Relations Engineer The initial launch of the Jetpack Telecom library introduced CallsManager, replacing the legacy ConnectionService API to simplify VoIP integration. CallsManager streamlines call lifecycle management and audio routing while enabling interactions with remote surfaces like smartwatches, Bluetooth devices, and Android Auto. Additionally, it supports call extensions for richer features—such as participant handling, custom icons, call silencing and meeting summary on remote surfaces—all while maintaining backward compatibility down to Android O (API Level 26). Building on this foundation, Jetpack Telecom v1.1.0 brings native-level visibility and convenience to third-party VoIP apps. This latest release introduces powerful new capabilities, including unified call history, call log exclusion, and native callback functionality, making call management more seamless than ever for users. Here is a closer look at what’s new and how you can implement these features in your applications. Bridging the Dialer Gap: Unified Call History and Callbacks Historically, users have had to open individual third-party apps to view their VoIP call history or return a missed call. With the new integrated call logging feature, system dialer apps can now surface call logs directly from third-party VoIP apps. Even better, users can now initiate a callback to a VoIP contact straight from their native system dialer, streamlining the communication experience. How it works: To opt-in to this feature, do the following: Register for Callbacks: Your VoIP app must register a new system-protected intent: TelecomManager.ACTION_CALL_BACK. Log the Call: Use TelecomManager.addCall (or related Jetpack APIs) to ensure the system automatically logs the call. Manage Call IDs: When a call is registered, CallControlScope.getCallId provides a unique UUID. The system dialer uses this exact TelecomManager.EXTRA_UUID when creating the callback intent. Initiate the Callback: Your application must store and manage the call details associated with this UUID. When the system dialer fires the callback intent with the EXTRA_UUID, your app can seamlessly resolve the ID and initiate the call with the correct details. Fine-Grained Control: Call Log Exclusion We recognize that not every VoIP call should be visible in the system's native dialer history. Whether for privacy reasons, ephemeral communication, or app-specific behavior, you need control over what gets surfaced. To address this, we are introducing Call Log Exclusion. You can now prevent specific calls from being logged into the system call logs by setting the isLogExcluded boolean to true within CallAttributesCompat. By configuring this flag, the call remains completely hidden from the system logs, and the native dialer will not display it. Important Note on Compatibility here to compile your app with Android SDK 36.1. Get Started We encourage developers to test these integrations and explore how unified call history and callbacks can improve the daily user experience of your VoIP applications. To help you get started and see these APIs in action, we have put together a sample application demonstrating the new integrations. View the sample app here: https://github.com/android/platform-samples/tree/main/samples/connectivity/telecom Check out the release notes and documentation to start implementing these features today! Note: Although Jetpack Telecom v1.1.0 APIs are accessible for integration, the system dialer's ability to render native call logs is being introduced in phases, beginning with Google Meet. To safeguard against spam, native dialers utilize secure package allowlists to control VoIP display. For local testing of your callback and logging implementations, we recommend using the open-source Telecom Sample Dialer app as your emulator environment.

5/12/2026

Posted by Matthew McCullough, VP, Product Management, Android Developer Announced today during The Android Show, Android is transitioning from an operating system to an intelligence system, creating more opportunities for engagement with your apps. Through deep integration between hardware and software, Android devices will be able to handle the heavy lifting of anticipating user needs, so your app can focus on delivering that experience at the right moment. As part of this, we are announcing Gemini Intelligence, a suite of new features that bring the best of Gemini to our most advanced Android devices. Task Automation with Gemini automate tasks across selected apps on behalf of the user with built-in transparency and control. This creates another avenue for user engagement, driving high-intent traffic to your app without requiring code or major engineering work from you. By allowing Gemini to navigate complex, multi-step tasks, such as ordering a latte from a cafe or building a shopping cart from a grocery list in a notes app, Gemini handles the logistics for users, so you’re free to focus on innovation and building great features. Increase Engagement with AppFunctions For more control over how agents interact with your app, you can use Android AppFunctions. This empowers you to provide specific tools, such as services, data, and actions directly to the OS and agents, paired with natural language descriptions. The system can then discover and execute these tools across form factors, enabling users to trigger your app’s functionality through the intelligence system for richer and more customized experiences with task automation. We’ve started testing these early stage APIs in a private preview with apps like KakaoTalk to enable users to “send messages” or “initiate voice calls” through this new framework. AppFunctions have already enabled local execution of 25 apps’ use cases across device manufacturers. You can experiment with the API locally and already register your interest to join the AppFunctions Early Access Program for full integration opportunities. We’re providing multiple integration paths to meet you wherever you are on this intelligence journey, whether it’s with an effortless, “no-code change” app automation or using the AppFunctions API, to provide you with more control in an MCP-like fashion. Enhanced User Experience with Widgets We’re elevating the user experience by expanding widget support to new form factors, starting with cars. This creates new opportunities for you to engage with users on 250M Android Auto compatible vehicles. Jetpack Glance makes it easy to build high-quality widgets, and it is now getting powerful new capabilities thanks to a new underlying framework called RemoteCompose. New richer, premium interactions: Built to be deeply adaptive and battery efficient, RemoteCompose allows Glance to deliver richer, more premium interactions. You can soon leverage new capabilities, including snapscroll, expressive buttons, and particle effects to create more engaging widgets. Built-in Backward Compatibility: These expressive RemoteCompose features are supported out-of-the-box on Android 16 and above. By using Jetpack Glance as your API, you maintain complete backward compatibility. Your widgets will automatically leverage these premium UI features on newer devices while gracefully degrading to support older OS versions. Furthermore, RemoteCompose is the engine behind Create My Widget, a feature where users can ask Gemini to build fully adaptive custom widgets that can be resized and optimized seamlessly for the user's home screen or Wear OS watch. Building Adaptively Beyond the Phone From foldables, tablets, compatible cars, and XR headsets to the new Googlebooks, the canvas for Android apps has expanded across screens and form factors. Here are some of the updates to help you build adaptively: Jetpack Navigation 3: Our latest Jetpack Navigation 3 offers deeper adaptive support adding Scene decorators to the Scene API. Scene decorators can be used to modify the scene calculated by your app's scene strategy. For example, they can be used to add common UI elements such as top app bars and navigation bars/rails that you’d like to add at the scene, rather than nav entry level. NavDisplay now includes built-in functionality that makes nav entries shared elements so now you can smoothly transition between scenes. Check out our Nav3-recipes for more. Jetpack Compose: Adopting Compose into your app remains the easiest way to start building adaptive UIs, and we want to ensure that you have the right level of architectural support. We are working on a new set of building blocks in Compose 1.11 for responsive layouts and customization with Grid, Flexbox, MediaQuery and Style. We would love your feedback on them before removing the Experimental flag. Design guidance: Explore our updated design gallery to be inspired, our new desktop design hub or our adaptive layout guidance to get started. For device-differentiated experiences, take advantage of the latest updates to: Car App Library: We’re streamlining development by expanding the Car App Library, which allows you to "build once" and deliver customized, distraction-optimized media experiences to both Android Auto and Android Automotive OS. We’re further enabling richer in-car engagement by expanding support for adaptive video apps, so that videos can played full screen when cars are parked. Android XR SDK: The Android XR SDK allows you to build deeply differentiated, custom experiences for a growing spectrum of XR devices, including upcoming wired XR glasses (like XREAL’s Project Aura), while existing adaptive apps automatically surface in immersive environments without additional developmental effort. You can get ready for display glasses by using Jetpack Compose Glimmer to build glanceable UIs tailored for display glasses, alongside Jetpack Projected APIs to bridge app experiences from the phone to the user’s field of view. The developer preview 4 of the Android XR SDK, coming next week, introduces new interactive components like Title Chips and Button Groups that optimize input for glasses touchpads. It streamlines your workflow with the new ProjectedTestRule API to automate testing environments. A New Age for Your Users on Android From the shift to an intelligence system to the expansion of new form factors like Googlebooks, Android is creating new ways for people to get more out of their device experiences with developers and app makers at the center of it. Gemini Intelligence features will roll out in waves as they become ready, starting with the latest Samsung Galaxy and Google Pixel phones this summer. They will also become available across your Android devices including your watch, car, glasses and laptops later this year. Stay tuned for even more news about app development in this new era at Google I/O next week.

5/8/2026

Posted by Ash Nohe and Amrit Sanjeev, Android Developer Relations Engineers Practicing gratitude may decrease symptoms of depression and anxiety, and improve mental health and life satisfaction1. Consistent gratitude practice may lead to sustained improvements that last months2. The mindfulness app Gratitude encourages consistency through micro daily journaling, affirmations, and vision boards. The app has over 6 million downloads, 150 thousand 5-star ratings, and 100 million journal entries logged. Developers Divij Gupta and Narendra Aanjna developed widgets for each of their app’s core user journeys. Their goal was to meet users in their everyday moments without requiring the overhead of a full app session. By surfacing interactive journaling prompts, affirmations, vision board images and metrics directly on the user’s home screen, the team lowered the barrier to entry for daily reflection and reported a 25% increase in retention for widget users and ~1K weekly journal entries from widgets. This increase in user loyalty translates to tangible health outcomes for the users: consistent habit formations that support long-term mental well-being. “Widgets helped us make the app more present in users’ daily routines by providing quick inspiration, reminders, and reflections directly on the home screen. This increased engagement and made it easier for users to stay consistent with their mindfulness practices.” – Divij Gupta The Challenge: modernize without decreasing retention The Solution Part 1: migrating from XML to Jetpack Glance To modernize their widgets, the team turned to Jetpack Glance. They first consulted the Widgets on Android design page and canonical widget layouts to understand best practices for displaying information within a limited amount of space. Then, they migrated their widget suite to Jetpack Glance. This declarative framework enabled the developers to move from planning to shipping in less than a month, saving about 50% development time, and saw two additional advantages: Replacing restrictive XML layouts with declarative code made the codebase easier to read, maintain, and reduced developer effort. Jetpack Glance allowed the team to more easily implement dynamic colors, flexible resizing, and expanded configuration options. These features ensure the widgets harmonize with a user's unique home screen layout. The following GIF shows two Gratitude widgets and adaptive resizing: While Glance simplified the UI, the team noted that testing across various OEM launchers was also essential to ensure layout consistency across devices. The team also implemented Generated Widget Previews so users can see personalized previews. They noted that testing Generated Previews could be slow, as the previews are rate limited to preserve battery. To bypass the rate limiting for testing, use the adb command: adb shell device_config put systemui  generated_preview_api_reset_interval_ms 0 All of their efforts have made the Gratitude widget high quality and differentiated. The Solution Part 2: promote new widgets in-app The developers then used in-app widget pinning to increase widget discoverability and widget installs. Asking users to install widgets at a contextually relevant moment within the app helps users find their widgets without needing to go through the system widget picker. The following GIF shows Gratitude’s bottom sheet to add widgets from within the app: The team also refactored widget packages, which changed widget receiver paths and caused widgets to be deleted from users’ home screens. Using previously stored user flags to identify widget users, they triggered another requestPinGlanceAppWidget prompt inviting widget users to use the new modernized widgets. Developer Tip: To maintain widget installs while migrating from RemoteViews to Jetpack Glance, ensure your GlanceAppWidgetReceiver uses the same class name and package as your previous AppWidgetProvider in the Android Manifest. If a new class name or package location is required, follow the Gratitude’s lead by using in-app pinning to help users restore their widgets. The strategy is working, as 10% of total DAU have adopted widgets.   Conclusion  This Gratitude story shows that widgets can be tools for habit formation. By implementing quick actions to self-reflect right from the home screen, the team may have improved user loyalty. Gratitude reduced technical debt and modernized their widgets by adopting Jetpack Glance, and prompted users to add widgets within their app. “Our experience with Jetpack Glance has been excellent. The Compose-based approach feels much more modern, flexible, and aligned with the way we build the rest of our UI today. It allows us to express widget layouts more naturally, reuse familiar Compose components, and iterate on UI changes much faster. Many of the UI constraints we previously faced with RemoteViews are no longer an issue, which made it easier to build widgets that better match our app’s design and experience.” – Divij Gupta Getting Started To get started with Jetpack Glance and learn about the technologies mentioned in this post, see these guides: Jetpack Glance Overview Widgets on Android design page Canonical widget layouts Generated Widget Previews Widget Quality Tiers In-app widget pinning Dynamic colors Resizing Configuration activities See other widget case studies: Google’s Contacts app created a new widget 25% faster using Jetpack Glance SoundCloud uses Jetpack Glance to build Liked Tracks widget in just 2 weeks 1: Diniz, G., Korkes, L., Tristão, L. S., Pelegrini, R., Bellodi, P. L., & Bernardo, W. M. (2023). The effects of gratitude interventions: a systematic review and meta-analysis. einstein (Sao Paulo)., 21, eRW0371. https://doi.org/10.31744/einstein_journal/2023RW0371 2: Bohlmeijer, E., Kraiss, J., Schotanus-Dijkstra, M., & ten Klooster, P. (2022). Gratitude as mood mediates the effects of a 6-weeks gratitude intervention on mental well-being: post hoc analysis of a randomized controlled trial. Front. Psychol., 12, 799447. https://doi.org/10.3389/fpsyg.2021.799447

5/7/2026

Posted by Vijaya Kaza, VP, Product, App & Ecosystem Trust The mobile ecosystem is always evolving, bringing both new opportunities and new threats. Through these changes, Android and Google Play remain committed to ensuring that billions of users can continue to enjoy their apps with confidence and developer innovation can thrive. Earlier this year, we shared how Android and Google Play kept the ecosystem safe in 2025 by deepening our investments in AI and real-time defenses. Today, we’re giving you a look at how we’re making it easier and faster than ever for millions of developers to publish safer apps. Simpler ways to build safer apps from the start To help you catch potential issues before you hit submit, we’re integrating insights and new customized guidance built with AI to your publishing journey: Catch policy issues while you code with expanded Play Policy Insights in Android Studio, which now offer warnings for common issues, like missing login credentials. Later this year, when you choose to connect your Play developer account directly to Android Studio, you’ll get tailored insights. Choose the right SDKs with confidence by leveraging SDK Index. Later this year, we are bringing SDK insights directly into your development workflow so you can instantly see which SDKs comply with Play policies. More powerful protection for your business and users With new ways to stay ahead of fraud and abuse, and better tools to protect your users, we’re also making it easier to secure your app’s revenue and reputation. Detect security threats and abuse faster with our stronger Play Integrity API, which developers rely on to make billions of checks everyday to help keep their business secure. With significantly shorter warm-up latency, you can use these real-time checks in your most speed-critical user journeys, like logins or payments, to catch unauthorized access and risky interactions. Simplify how you manage user privacy with easy-to-integrate tools like the contact picker and location button to give users clearer choices. We're also updating our policies to raise the standard for user privacy. Future-proofing app signing security on your behalf. We’re adding support for post-quantum cryptography in Play App Signing this year, which will protect your apps and app updates from potential threats with the emergence of quantum computing. Faster, more predictable app publishing We know how important it is to maintain a predictable release cycle, so we’re making the publishing process faster and more transparent. Avoid unexpected review rejections with our expanding pre-review checks, which now identify unnecessary photo permission requests and other common violations before you submit. Improve the speed and predictability of your review cycles by using the new release status API to check if your release is approved and published. We also added a new way for you to block new commits if a review is already in progress, so you don’t unintentionally restart your place in the queue. Publish your releases even faster when we change our review architecture later this year to enable parallel publishing and faster reviews for your test tracks. You’ll be able to isolate your closed, open, and production tracks so that a review on one track no longer holds up updates on another. Track your release history with the Submission history log later this year. Built at your request, this feature provides a complete record of every time you send an app or update for review and its status. This makes it easier for your team to coordinate and troubleshoot without digging through multiple menus. Manage business changes securely with the account transfers feature to help you move ownership to new partners, entities, or team members (video). We’ve designed this highly developer-requested feature with safeguards to protect your business from fraud and account hijacking. Get the right policy support when you need it. In the coming months you'll see AI-powered recommendations directly in your Play Console that help you resolve minor issues immediately. For more complex issues, you can create a ticket to connect with our policy specialists. We’re also giving new developers more guided support, including new Play Academy courses, to publish their first app with confidence. Later this year, we’ll expand this coaching experience for new developers. Stronger security across the ecosystem Finally, we’re bringing developer verification to the entire Android ecosystem to add another layer of security and make it much harder for malicious actors to repeatedly spread harm. Starting in September, these protections will roll out in select countries to help users feel more confident in the apps they download and without changing most users’ install experience. We will also update Android Bench to uplift the entire ecosystem’s ability to build and launch safer, higher quality apps using generative AI. What’s next Google Play is committed to helping you grow your business while keeping users safe, and we appreciate your continued feedback on the tools and programs. Thank you for partnering with us to make Android and Google Play a secure, trusted platform for everyone. Android security ecosystem Play Policy Insights SDK compliance tools Real-time fraud detection Post-quantum cryptography for apps Google Play parallel publishing Release status API Developer account transfers AI-powered developer support Android developer verification

5/4/2026

Posted by Thomas Ezan, Sr Developer Relations Engineer and Tracy Agyemang, Product Marketing Manager Karrot is a hyperlocal, community-driven peer-to-peer marketplace app that enables users to buy, sell, and trade items with other verified users. Since launching in South Korea in 2015, the platform has expanded into global markets, amassing over 43 million registered users. Integrating Gemini Firebase AI Logic Integrating Firebase AI Logic into the app was a “remarkably straightforward experience,” according to TaeGyu An, an Android Software Engineer on Karrot’s Mobile Platform team. TaeGyu and the team used the platform’s documentation and code samples to build a proof of concept in under three hours. guides and tips made it easy to quickly identify the right direction for improving translation quality,” said WonJoong Lee, an Android Software Engineer on Karrot’s North America Product Team. This low barrier to entry and rapid turnaround time enabled engineers to keep development costs low and go from proof of concept to production code in just two weeks—all without setting up a dedicated backend. That also freed up time to focus on UX and policy design, such as opt-in behavior and the conditions for the translation banner. Driving sales with enhanced AI features Since implementing translation using Gemini and Firebase AI Logic, the Karrot team observed higher purchasing conversion among non-English users, indicating that the translation feature is helping drive sales. one in three of them who were shown the translation banner actively used the feature. The team has also observed that buyers offered translation functionality were 2.4X more likely to start a chat with a seller than those who weren’t. The flexibility and simplicity of deploying Firebase AI Logic has led the team to explore other features to simplify the workstreams of its engineers. “It’s rewarding to build features that scale across diverse Android devices while helping neighbors connect and interact within their local communities,” concluded TaeGyu. Going forward, the team plans to implement Server Prompt Templates to adjust prompts after release without shipping a new version of the app. This, combined with Remote Config, should help the team iterate faster and reduce operational overhead. Get started Firebase AI Logic to deliver better experiences to your users, faster. Karrot marketplace, hyperlocal P2P app, Gemini Flash Lite integration, Firebase AI Logic for Android, AI-powered app translation, South Korea marketplace global expansion, peer-to-peer trading accessibility, machine learning for mobile apps, increasing purchasing conversion with AI, Gemini API for developers, Firebase SDK translation, Server Prompt Templates, Remote Config Android, non-English user engagement, Gemini Nano vs ML Kit, Karrot North America expansion, community-driven marketplace tech.

4/22/2026

Posted by Meghan Mehta, Android Developer Relations Engineer Today, the Jetpack Compose April ‘26 release is stable. This release contains version 1.11 of core Compose modules (see the full BOM mapping), shared element debug tools, trackpad events, and more. We also have a few experimental APIs that we’d love you to try out and give us feedback on. To use today’s release, upgrade your Compose BOM version to: implementation(platform("androidx.compose:compose-bom:2026.04.01")) Changes in Compose 1.11.0 Coroutine execution in tests UnconfinedTestDispatcher, which executed coroutines immediately, the v2 APIs use the StandardTestDispatcher. This means that when a coroutine is launched in your tests, it is now queued and does not execute until the virtual clock is advanced. This better mimics production conditions, effectively flushing out race conditions and making your test suite significantly more robust and less flaky. To ensure your tests align with standard coroutine behavior and to avoid future compatibility issues, we strongly recommend migrating your test suite. Check out our comprehensive  migration guide for API mappings and common fixes. Shared element improvements and animation tooling We’ve also added some handy visual debugging tools for shared elements and Modifier.animatedBounds. You can now see exactly what’s happening under the hood—like target bounds, animation trajectories, and how many matches are found—making it much easier to spot why a transition might not be behaving as expected. To use the new tooling, simply surround your SharedTransitionLayout with the LookaheadAnimationVisualDebugging composable. LookaheadAnimationVisualDebugging( overlayColor = Color(0x4AE91E63), isEnabled = true, multipleMatchesColor = Color.Green, isShowKeylabelEnabled = false, unmatchedElementColor = Color.Red, ) { SharedTransitionLayout { CompositionLocalProvider( LocalSharedTransitionScope provides this, ) { // your content } } } Trackpad events PointerType.Mouse events, aligning mouse and trackpad behavior to better match user expectations. Previously, these trackpad events were interpreted as fake touchscreen fingers of PointerType.Touch, which led to confusing user experiences. For example, clicking and dragging with a trackpad would scroll instead of selecting. By changing the pointer type these events have in the latest release of Compose, clicking and dragging with a trackpad will no longer scroll. We also added support for more complicated trackpad gestures as recognized by the platform since API 34, including two finger swipes and pinches. These gestures are automatically recognized by components like Modifier.scrollable and Modifier.transformable to have better behavior with trackpads. These changes improve behavior for trackpads across built-in components, with redundant touch slop removed, a more intuitive drag-and-drop starting gesture, double-click and triple-click selection in text fields, and desktop-styled context menus in text fields. To test trackpad behavior, there are new testing APIs with performTrackpadInput, which allow validating the behavior of your apps when being used with a trackpad. If you have custom gesture detectors, validate behavior across input types, including touchscreens, mice, trackpads, and styluses, and ensure support for mouse scroll wheels and trackpad gestures. Before After Composition host defaults (Compose runtime) HostDefaultProvider, LocalHostDefaultProvider, HostDefaultKey, and ViewTreeHostDefaultKey to supply host-level services directly through compose-runtime. This removes the need for libraries to depend on compose-ui for lookups, better supporting Kotlin Multiplatform. To link these values to the composition tree, library authors can use compositionLocalWithHostDefaultOf to create a CompositionLocal that resolves defaults from the host. Preview wrappers PreviewWrapperProvider interface and applying the new @PreviewWrapper annotation, you can easily inject custom logic, such as applying a specific Theme. The annotation can be applied to a function annotated with @Composable and @Preview or @MultiPreview, offering a generic, easy-to-use solution that works across preview features and significantly reduces repetitive code. class ThemeWrapper: PreviewWrapper {     @Composable     override fun Wrap(content: @Composable (() -> Unit)) {         JetsnackTheme {             content()         }     } } @PreviewWrapperProvider(ThemeWrapper::class) @Preview @Composable private fun ButtonPreview() {     // JetsnackTheme in effect     Button(onClick = {}) {         Text(text = "Demo")     } } Deprecations and removals As announced in the Compose 1.10 blog post, we’re deprecating Modifier.onFirstVisible(). Its name often led to misconceptions, particularly within lazy layouts, where it would trigger multiple times during scrolling. We recommend migrating to Modifier.onVisibilityChanged(), which allows for more precise manual tracking of visibility states tailored to your specific use case requirements. The ComposeFoundationFlags.isTextFieldDpadNavigationEnabled flag was removed because D-pad navigation for TextFields is now always enabled by default. The new behavior ensures that the D-pad events from a gamepad or a TV remote first move the cursor in the given direction. The focus can move to another element only when the cursor reaches the end of the text. Upcoming APIs compileSdk will be upgraded to compileSdk 37, with AGP 9 and all apps and libraries that depend on Compose inheriting this requirement. We recommend keeping up to date with the latest released versions, as Compose aims to promptly adopt new compileSdks to provide access to the latest Android features. Be sure to check out the documentation here for more information on which version of AGP is supported for different API levels. In Compose 1.11.0, the following APIs are introduced as @Experimental, and we look forward to hearing your feedback as you explore them in your apps. Note that @Experimental APIs are provided for early evaluation and feedback and may undergo significant changes or removal in future releases. Styles (Experimental) styling. The Style API is a new paradigm for customizing visual elements of components, which has traditionally been performed with modifiers. It is designed to unlock deeper, easier customization by exposing a standard set of styleable properties with simple state-based styling and animated transitions. With this new API, we’re already seeing promising performance benefits. We plan to adopt Styles in Material components once the Style API stabilizes. @Composable fun LoginButton(modifier: Modifier = Modifier) { Button( onClick = { // Login logic }, modifier = modifier, style = { background( Brush.linearGradient( listOf(lightPurple, lightBlue) ) ) width(75.dp) height(50.dp) textAlign(TextAlign.Center) externalPadding(16.dp) pressed { background( Brush.linearGradient( listOf(Color.Magenta, Color.Red) ) ) } } ){ Text( text = "Login", ) } } Check out the documentation and file any bugs here. MediaQuery (Experimental) mediaQuery API provides a declarative and performant way to adapt your UI to its environment. It abstracts complex information retrieval into simple conditions within a UiMediaScope, ensuring recomposition only happens when needed. With support for a wide range of environmental signals—from device capabilities like keyboard types and pointer precision, to contextual states like window size and posture—you can build deeply responsive experiences. Performance is baked in with derivedMediaQuery to handle high-frequency updates, while the ability to override scopes makes testing and previews seamless across hardware configurations. Previously, to get access to certain device properties — like if a device was in tabletop mode — you’d need to write a lot of boilerplate to do so: @Composable fun isTabletopPosture( context: Context = LocalContext.current ): Boolean { val windowLayoutInfo by WindowInfoTracker .getOrCreate(context) .windowLayoutInfo(context) .collectAsStateWithLifecycle(null) return windowLayoutInfo.displayFeatures.any { displayFeature -> displayFeature is FoldingFeature && displayFeature.state == FoldingFeature.State.HALF_OPENED && displayFeature.orientation == FoldingFeature.Orientation.HORIZONTAL } } @Composable fun VideoPlayer() { if(isTabletopPosture()) { TabletopLayout() } else { FlatLayout() } } UIMediaQuery, you can add the mediaQuery syntax to query device properties, such as if a device is in tabletop mode: @OptIn(ExperimentalMediaQueryApi::class) @Composable fun VideoPlayer() { if (mediaQuery { windowPosture == UiMediaScope.Posture.Tabletop }) { TabletopLayout() } else { FlatLayout() } } documentation and file any bugs here. Grid (Experimental) Grid is a powerful new API for building complex, two-dimensional layouts in Jetpack Compose. While Row and Column are great for linear designs, Grid gives you the structural control needed for screen-level architecture and intricate components without the overhead of a scrollable list. Grid allows you to define your layout using tracks, gaps, and cells, offering familiar sizing options like Dp, percentages, intrinsic content sizes, and flexible "Fr" units. @OptIn(ExperimentalGridApi::class) @Composable fun GridExample() {     Grid(         config = {             repeat(4) { column(0.25f) }             repeat(2) { row(0.5f) }             gap(16.dp)         }     ) {         Card1(modifier = Modifier.gridItem(rowSpan = 2)         Card2(modifier = Modifier.gridItem(colmnSpan = 3)         Card3(modifier = Modifier.gridItem(columnSpan = 2)         Card4()     } } Check out the documentation and file any bugs here. FlexBox (Experimental) FlexBox is a layout container designed for high performance, adaptive UIs. It manages item sizing and space distribution based on available container dimensions. It handles complex tasks like wrapping (wrap) and multi-axis alignment of items (justifyContent, alignItems, alignContent). It allows items to grow (grow) or shrink (shrink) to fill the container. @OptIn(ExperimentalFlexBoxApi::class) fun FlexBoxWrapping(){ FlexBox( config = { wrap(FlexWrap.Wrap) gap(8.dp) } ) { RedRoundedBox() BlueRoundedBox() GreenRoundedBox(modifier = Modifier.width(350.dp).flex { grow(1.0f) }) OrangeRoundedBox(modifier = Modifier.width(200.dp).flex { grow(0.7f) }) PinkRoundedBox(modifier = Modifier.width(200.dp).flex { grow(0.3f) }) } } Check out the documentation and file any bugs here. New SlotTable implementation (Experimental) SlotTable, which is disabled by default in this release. SlotTable is the internal data structure that the Compose runtime uses to track the state of your composition hierarchy, track invalidations/recompositions, store remembered values, and track all metadata of the composition at runtime. This new implementation is designed to improve performance, primarily around random edits. To try the new SlotTable, enable ComposeRuntimeFlags.isLinkBufferComposerEnabled. Start coding today! migrate to Jetpack Compose. As always, we value your feedback and feature requests (especially on @Experimental features that are still baking) — please file them here. Happy composing!

4/22/2026

Posted by Niharika Arora, Senior Developer Relations Engineer and Jean-Pierre Pralle, Product Manager, Credential Manager In the modern digital landscape, the first encounter a user has with an app is often the most critical. Yet, for decades, this initial interaction has been hindered by the friction of traditional verification methods. Today, we're excited to announce a new verified email credential issued by Google, which developers can now retrieve directly from Android’s Credential Manager Digital Credential API. The Problem: Authentication Friction in the Modern Era The "current era" of authentication is defined by a trade-off between security and convenience. To ensure that a user owns the email address they provide, you typically rely on One-Time Passwords (OTPs) or "magic links" sent by email or SMS. While effective, these traditional steps introduce significant hurdles: Context switching: Users must leave the app, open their inbox or messaging app, find the code, and return, a process where many potential users simply drop off. Delivery issues: While Emails are free, they can be delayed or diverted to spam folders. Onboarding friction: Every extra second spent in the "verification loop" is a second where a user might lose interest, directly impacting conversion rates. The Solution: Seamless, Verified Email Google now issues a cryptographically verified email credential directly to Android devices. This verified email credential is delivered through the Credential Manager API, which is Android's implementation of the W3C's Digital Credential API standard. For users, this completely removes the need to manually verify their email through external channels. For developers, the API securely delivers these verified user claims for any scenario whether you are building an account creation flow, a recovery process, or a high-risk step-up authentication. While this specific verified email address is sourced securely from the user's Google Account on their device, the underlying Digital Credentials API is issuer-agnostic. This fosters an open ecosystem, allowing any holder of a digital credential with an email claim to offer that verification to your app. User Experience The beauty of this API lies in its simplicity for the end user. Instead of hunting for OTP codes, the experience is integrated directly into the Android OS: Initiation: The process begins when a user focuses on an email input field or taps a "Sign up" or "Recover account" button. You can also initiate the process on page load. Transparency: A native Android bottom sheet appears, clearly detailing exactly what data is being requested (for example, user’s verified email address). One-tap consent: The user simply taps "Agree and continue" to share the data. Immediate progress: Once consent is given, the app receives the data instantly. For sign-up or account recovery flows, you can then seamlessly transition the user into passkey creation, ensuring: Users do not have to enter any user information manually, as compared to the traditional username/password registration. Their next login is even faster and more secure. Use case 1. Sign up Accelerate onboarding by fetching a verified email the moment the user taps "Sign up". We strongly recommend you pair the verified email retrieval with passkey creation, also part of the Credential Manager API: Note: You can also fetch other unverified fields such as a user’s given name, family name, name, profile picture and the hosted domain connected with the verified email. Use case 2. Account recovery Eliminate the frustration of users hunting for recovery codes in their spam folders by allowing them to recover their account using the verified email securely stored on their device. Use case 3. Re-authentication for sensitive actions Protect sensitive user actions, such as changing settings or updating profile details, by requiring a quick re-authentication step. Instead of an OTP, you can provide a low-friction verification using the device's verified email. Important Considerations As you design your authentication architecture around the Digital Credentials API, keep the following details in mind: Account support: For the specific email credential issued by Google, only regular consumer Google Accounts are supported (Workspace and supervised accounts are currently not supported). Keep in mind that the Credential Manager API itself is issuer-agnostic, meaning other identity providers can issue credentials with their own account support policies. Other user data: Beyond email, you can request the user's given name, family name, full name, and profile picture. However, note that only the email is verified by Google. Auto verify your @gmail accounts: The API provides verified emails for all consumer Google Accounts. We recommend auto-verifying @gmail.com users and routing custom domains to your existing verification flow - for example, an OTP flow. This ensures you maintain long-term access for external domains not directly managed by Google. Complementary to Sign in with Google: While both the new verified email credential & Sign in with Google API provides a verified email, the choice depends on the intended user experience: Use Sign in with Google when your users want to create a federated login session. Use Verified Email when your users want to sign in traditionally with a username/password or passkey but want to auto-verify the email address without the manual chore of an OTP. Conclusion and Next steps By integrating the new verified email via Credential Manager API, you can drastically reduce onboarding friction and provide users with a more streamlined, secure authentication journey. This represents a shift toward a future where "verification" is no longer a manual chore for the user, but a seamless, integrated part of the native mobile experience. Ready to see how this fits into your own app? To get started, update your project to the latest Credential Manager API and explore our Integration Guide. We encourage you to explore how this streamlined verification can simplify your critical user journeys from optimizing account creation, to enhancing re-authentication flows.

4/21/2026

Posted by Matt Dyor, Senior Product Manager Android Studio Panda 4 is now stable and ready for you to use in production. This release brings Planning Mode, Next Edit Prediction, and more, making it easier than ever to build high-quality Android apps. Here’s a deep dive into what’s new: Planning Mode Before the Agent starts working on complex tasks for you, it would be helpful if it could come up with a detailed plan. Jumping straight into a large coding project without a design often leads to technical debt or logic errors; the same is true for AI. That’s why we’re adding Planning Mode. In this mode, the Agent comes up with a detailed project plan before executing tasks. Instead of a single pass where the model directly predicts the next token of code, Planning Mode facilitates a multi-stage reasoning process — giving the agent additional space to evaluate its own proposed logic for potential issues before presenting it to you. This is especially useful for complex and long-running tasks which demand a high degree of architectural precision. To use Planning Mode, switch your conversation mode to "Planning" in the agent input box and enter your prompt. to “Planning” and enter your prompt. Switch to Planning Mode In Planning Mode, the agent examines your request and may generate an implementation plan for large or complex tasks. You have the opportunity to fix mistakes or clarify which approaches to use—all before the agent has spent any time or tokens heading in the wrong direction. Open Implementation Plan Add Comments to Implementation Plan After adding comments, simply hit “Submit Comments” and the agent will use your feedback to revise the implementation plan. To stay on track during execution—which is particularly important with larger changes—the agent organizes its work and generates a "Task List" artifact. You can sit back and watch as the agent methodically completes all of the tasks. Task List Artifact After the work is done, the agent produces a “Walkthrough” artifact, giving you a clear summary of exactly what has been changed—making it easy to review the agent's changes. Build with more confidence and control using Planning Mode in the latest release of Android Studio. Add Comments to Implementation Plan Next Edit Prediction Classic autocomplete is great for finishing your sentences, but coding is rarely a linear path. Often, a change in one place requires a secondary change elsewhere—like adding a new parameter to a function and then needing to update its invocations, or a UI preview update when a Composable is changed. Traditionally, this meant breaking your focus to hunt down the related lines of code that need attention. Next Edit Prediction (NEP) evolves code completion by anticipating your next move, even when it’s not at your current cursor position. By analyzing your recent edits, Android Studio recognizes the logical pattern of your workflow. If you modify a data class or update a constructor, NEP can suggest the next relevant edit—perhaps in a distant function—allowing you to jump straight to the fix. Instead of manually navigating back and forth, you can accept these multi-location suggestions with a single keystroke. This keeps you deep in the "flow state," reducing the cognitive load of routine updates and letting you focus on the complex logic that truly matters to your application. Experience a more intuitive, non-linear way to code in the latest version of Android Studio.   NEP Updating Function Name NEP Adding New Line Gemini API Starter Template Adding powerful AI features to your app just got easier, introducing the Gemini API Starter Template for Android Studio! Integrating generative AI into your Android application used to mean managing complex backend plumbing and worrying about API key security. With the new Gemini API Starter template in Android Studio, developers can now jump straight into building features rather than spending time configuring infrastructure. Key benefits include: Zero API key management: Stop worrying about provisioning or rotating keys. By leveraging Firebase AI Logic, the template eliminates the need to embed sensitive credentials in your client-side code. Automated Firebase integration: The backend plumbing is handled for you. The template automatically connects your project to Firebase services, ensuring a secure bridge between your app and Google’s Gemini models. Built to scale: This isn't just for prototypes. The production-ready architecture allows you to scale from a local test to a global user base without redesigning your foundation. Multimodal processing: Supports text, image, video, and audio inputs. You can build features like real-time image analysis, video summarization, and audio transcription. Get Started Open Android Studio. Navigate to File > New > New Project. Select the Gemini API Starter template from the gallery. Gemini API Starter new project template Agent Web Search When you’re deep in development, the right answer is often just a search away—but leaving your IDE to find it can snap you out of your flow. Whether you need the exact version number for a dependency or the latest API changes for a third-party library, the Agent Web Search tool is here to help without you ever having to leave Android Studio. While Android Studio’s agent already leverages the Android Knowledge Base for official documentation, modern Android development relies on a vast ecosystem of external libraries. Agent Web Search expands Gemini's reach, allowing it to query Google directly to fetch current reference material from across the web. From checking the latest setup guides for Coil to finding advanced configuration tips for Koin or Moshi, the agent can now pull in the most up-to-date information in real time. The Agent Web Search tool is designed to be helpful but unobtrusive; it will automatically trigger a web search when it identifies a gap in its local knowledge. You can also take the wheel by asking it to find something specific—simply include "search the web for..." in your prompt. By integrating live web results directly into your workspace, Agent Web Search ensures you’re always building with the most current data available, speeding up your workflow and keeping your project on the cutting edge.   Agent Web Search Tool Invocation Android Studio Panda Releases Go from prompt to working prototype with Android Studio Panda 2 and Increase Guidance and Control over Agent Mode with Android Studio Panda 3. Android Studio Panda 2 AI-powered New Project flow: Allows you to build a working app prototype with a single prompt. The agent manages initial setup, navigation configuration, and proper dependencies, and features an autonomous generation loop to handle build errors and deploy to an emulator. Version Upgrade Assistant: Automates dependency management and updates, iteratively attempting builds and resolving conflicts until a stable configuration is found. Android Studio Panda 3 Agent skills: Specialized, user-defined instructions (stored in a .skills directory) that teach the AI agent project-specific capabilities, coding standards, or library usage. Agent permissions: Provides fine-grained control over what agents can do, with features like "Always Allow" rules for trusted operations. For even more security, you can also use an optional sandbox to enforce strict, isolated control over the agent. Empty Car App Library App template: Simplifies building driving-optimized apps for Android Auto and Android Automotive OS by handling required boilerplate code. Get started Dive in and accelerate your development. Download Android Studio Panda 4 and start exploring these powerful new agentic 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. Happy coding! Android Studio, androidstudio, Android Studio Panda, featured, Gemini in Android Studio, AI-powered new project flow, version upgrade assistant

4/17/2026

Posted by Thomas Ezan, Senior Developer Relations Engineer If you are an Android developer looking to implement innovative AI features into your app, we recently launched powerful new updates: Hybrid inference, a new API for Firebase AI Logic to leverage both on-device and Cloud inference, and support for new Gemini models including the latest Nano Banana models for image generation. Let’s jump in! Experiment with hybrid inference With the new Firebase API for hybrid inference, we implemented a simple rule-based routing approach as an initial solution to let you use both on-device and cloud inference via a unified API. We are planning on providing more sophisticated routing capabilities in the future. It allows your app to dynamically switch between Gemini Nano running locally on the device and cloud-hosted Gemini models. The on-device execution uses ML Kit's Prompt API. The cloud inference supports all the Gemini models from Firebase AI Logic in both Vertex AI and the Developer API. To use it, add the firebase-ai-ondevice dependencies to your app along with Firebase AI Logic: dependencies { [...] implementation("com.google.firebase:firebase-ai:17.11.0") implementation("com.google.firebase:firebase-ai-ondevice:16.0.0-beta01") } During initialization, you create a GenerativeModel instance and configure it with specific inference modes, such as PREFER_ON_DEVICE (falls back to cloud if Gemini Nano is not available on the device) or PREFER_IN_CLOUD (falls back to on-device inference if offline): val model = Firebase.ai(backend = GenerativeBackend.googleAI()) .generativeModel( modelName = "gemini-3.1-flash-lite", onDeviceConfig = OnDeviceConfig( mode = InferenceMode.PREFER_ON_DEVICE ) ) val response = model.generateContent(prompt) The Firebase API for hybrid inference for Android is still experimental, and we encourage you to try it in your app, especially if you are already using Firebase AI Logic. Currently, on-device models are specialized for single-turn text generation based on text or single Bitmap image inputs. Review the limitations for more details. We just published a new sample in the AI Sample Catalog leveraging the Firebase API for hybrid; it demonstrates how the Firebase API for hybrid inference can be used to generate a review based on a few selected topics and then translating it into various languages. Check out the code to see it in action! The new hybrid inference sample in action Try our new models As part of the new Gemini models, we've released two models particularly helpful to Android developers and easy to integrate in your application via the Firebase AI Logic SDK. Nano Banana Last year we released Nano Banana, a state-of-the-art image generation model. And a few weeks ago, we released a couple of new Nano Banana models. Nano Banana Pro (Gemini 3 Pro Image) is designed for professional asset production and can render high-fidelity text, even in a specific font or simulating different types of handwriting. Nano Banana 2 (Gemini 3.1 Flash Image) is the high-efficiency counterpart to Nano Banana Pro. It's optimized for speed and high-volume use cases. It can be used for a broad range of use cases (infographics, virtual stickers, contextual illustrations, etc.). The new Nano Banana models leverage real-world knowledge and deep reasoning capabilities to generate precise and detailed images. We updated our Magic Selfie sample (use image generation to change the background of your selfie!) to use Nano Banana 2. The background segmentation is now handled directly with the image generation model which makes the implementation easier and lets Nano Banana 2 improved image generation capabilities shine. See it in action here. The updated Magic Selfie sample uses Nano Banana 2 to update a selfie background You can use it via Firebase AI Logic SDK. Read more about it in the Android documentation. Gemini 3.1 Flash-Lite We also released Gemini 3.1 Flash-Lite, a new version of the Gemini Flash-Lite family. The Gemini Flash-Lite models have been particularly favored by Android developers for its good quality/latency ratio and low inference cost. It’s been used by Android developers for various use-cases such as in-app messaging translation or generating a recipe from a picture of a dish. Gemini 3.1 Flash-Lite, currently in preview, will enable more advanced use cases with latency comparable to Gemini 2.5 Flash-Lite. To learn more about this model, review the Firebase documentation. Conclusion It’s a great time to explore the new Hybrid sample in our catalog to see these capabilities in action and understand the benefits of routing between on-device and cloud inference. We also encourage you to check out our documentation to test the new Gemini models.

4/16/2026

Posted by Dan Galpin, Developer Relations Engineer Android 17 has reached beta 4, the last scheduled beta of this release cycle, a critical milestone for app compatibility and platform stability. Whether you're fine-tuning your app's user experience, ensuring smooth edge-to-edge rendering, or leveraging the newest APIs, Beta 4 provides the near-final environment you need to be testing with. 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, you can no longer opt out of maintaining orientation, resizability and aspect ratio constraints on large screens. Dynamic code loading: If your app targets Android 17 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 Android 17 or higher have local network access blocked by default. Switch to using privacy preserving pickers if possible, and use the new ACCESS_LOCAL_NETWORK permission 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 updated guidance. App memory limits Android is introducing app memory limits based on the device's total RAM to create a more stable and deterministic environment for your applications and Android users. In Android 17, limits are set conservatively to establish system baselines, targeting extreme memory leaks and other outliers before they trigger system-wide instability resulting in UI stuttering, higher battery drain, and apps being killed. While we anticipate minimal impact on the vast majority of app sessions, we recommend the following memory best practices, including establishing a baseline for memory. In the current implementation, getDescription in ApplicationExitInfo will contain the string "MemoryLimiter" if your app was impacted. You can also use trigger-based profiling with TRIGGER_TYPE_ANOMALY to get heap dumps that are collected when the memory limit is hit. The LeakCanary task in the Android Studio Profiler To help you find memory leaks, Android Studio Panda adds LeakCanary integration directly in the Android Studio Profiler as a dedicated task, contextualized within the IDE and fully integrated with your source code. A lighter memory footprint translates directly to smoother performance, longer battery life, and a premium experience across all form factors. Let’s build a faster, more reliable future for the Android ecosystem together! Profiling triggers for app anomalies Android introduces an on-device anomaly detection service that monitors for resource-intensive behaviors and potential compatibility regressions. Integrated with ProfilingManager, this service allows your app to receive profiling artifacts triggered by specific system-detected events. Use the TRIGGER_TYPE_ANOMALY trigger to detect system performance issues such as excessive binder calls and excessive memory usage. When an app breaches OS-defined memory limits, the anomaly trigger allows developers to receive app-specific heap dumps to help identify and fix memory issues. Additionally, for excessive binder spam, the anomaly trigger provides a stack sampling profile on binder transactions. This API callback occurs prior to any system imposed enforcements. For example, it can help developers collect debug data before the app is terminated by the system due exceeding memory limits. To understand how to use the trigger check out our documentation on trigger based profiling. val profilingManager = applicationContext.getSystemService(ProfilingManager::class.java) val triggers = ArrayList<ProfilingTrigger>() triggers.add(ProfilingTrigger.Builder( ProfilingTrigger.TRIGGER_TYPE_ANOMALY)) val mainExecutor: Executor = Executors.newSingleThreadExecutor() val resultCallback = Consumer<ProfilingResult> { 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) Post-Quantum Cryptography (PQC) in Android Keystore Android Keystore added support for the NIST-standardized ML-DSA (Module-Lattice-Based Digital Signature Algorithm). On supported devices, you can generate ML-DSA keys and use them to produce quantum-safe signatures, entirely in the device’s secure hardware. Android Keystore exposes the ML-DSA-65 and ML-DSA-87 algorithm variants through the standard Java Cryptographic Architecture APIs: KeyPairGenerator, KeyFactory, and Signature. For further details, see our developer documentation. KeyPairGenerator generator = KeyPairGenerator.getInstance( “ML-DSA-65”, "AndroidKeyStore"); generator.initialize( new KeyGenParameterSpec.Builder( “my-key-alias”, KeyProperties.PURPOSE_SIGN | KeyProperties.PURPOSE_VERIFY) .build()); KeyPair keyPair = generator.generateKeyPair(); Get started with Android 17 You can enroll any supported Pixel device to get this and future Android Beta updates over-the-air. 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 in the Android Beta program, you will be offered an over-the-air update to Beta 4. Continue to report issues and submit feature requests on the feedback page. The earlier we get your feedback, the more we can include in our work on the final release. For the best development experience with Android 17, we recommend that you use the latest preview of Android Studio (Panda). Once you’re set up, here are some of the things you should do: Compile against the new SDK, test in CI environments, and report any issues in our tracker on the feedback page. 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 emulator running Android 17 and extensively test it. We’ll update the preview/beta system images and SDK regularly throughout the Android 17 release cycle. Once you’ve installed a beta build, you’ll automatically get future updates over-the-air for all later previews and Betas. For complete information, visit the Android 17 developer site. Join the conversation Your feedback remains our most valuable asset. Whether you’re an early adopter on the Canary channel or an app developer testing on Beta 4, consider joining our communities and filing feedback. We’re listening.

4/16/2026

Posted by Adarsh Fernando, Group Product Manager and Esteban de la Canal, Senior Staff Software Engineer As Android developers, you have many choices when it comes to the agents, tools, and LLMs you use for app development. Whether you are using Gemini in Android Studio, Gemini CLI, Antigravity, or third-party agents like Claude Code or Codex, our mission is to ensure that high-quality Android development is possible everywhere. Today, we are introducing a new suite of Android tools and resources for agentic workflows — Android CLI with Android skills and the Android Knowledge Base. This collection of tools is designed to eliminate the guesswork of core Android development workflows when you direct an agent’s work outside of Android Studio, making your agents more efficient, effective, and capable of following the latest recommended patterns and best practices. Whether you are just starting your development journey on Android, are a seasoned Android developer, or managing apps across mobile and web platforms, building your apps with the latest guidance, tools, and AI-assistance is easier than ever. No matter which environment you begin with these resources, you can always transition your development experience to Android Studio—where the state-of-the-art tools and agents for Android development are available to help your app experience truly shine. (Re)Introducing the Android CLI Your agents perform best when they have a lightweight, programmatic interface to interact with the Android SDK and development environment. So, at the heart of this new workflow is a revitalized Android CLI. The new Android CLI serves as the primary interface for Android development from the terminal, featuring commands for environment setup, project creation, and device management—with more modern capabilities and easy updatability in mind. The create command makes an Android app project in seconds. In our internal experiments, Android CLI improved project and environment setup by reducing LLM token usage by more than 70%, and tasks were completed 3X faster than when agents attempted to navigate these tasks using only the standard toolsets. Key capabilities available to you include: SDK management: Use android sdk install to download only the specific components needed, ensuring a lean development environment. Snappy project creation: The android create command generates new projects from official templates, ensuring the recommended architecture and best practices are applied from the very first line of code. Rapid device creation and deployment: Create and manage virtual devices with android emulator and deploy apps using android run, eliminating the guesswork involved in manual build and deploy cycles. Updatability: Run android update to ensure that you have the latest capabilities available. Android CLI can create a device, run your app on it, and make it easier for agents to navigate UI. While Android CLI will empower your agentic development flows, it’s also been designed to streamline CI, maintenance, and any other scripted automation for the increasingly distributed nature of Android development. Download and try out the Android CLI today! Grounding LLMs with official Android Skills Traditional documentation can be descriptive, conceptual, and high-level. While perfect for learning, LLMs often require precise, actionable instructions to execute complex workflows without using outdated patterns and libraries. To bridge this gap, we are launching the Android skills GitHub repository. Skills are modular, markdown-based (SKILL.md) instruction sets that provide a technical specification for a task and are designed to trigger automatically when your prompt matches the skill's metadata, saving you the hassle of manually attaching documentation to every prompt. Android skills cover some of the most common workflows that some Android developers and LLMs may struggle with—they help models better understand and execute specific patterns that follow our best practices and guidance on Android development. In our initial release, the repository includes skills like: Navigation 3 setup and migration. Implementing edge-to-edge support. AGP 9 and XML-to-Compose migrations. R8 config analysis, and more! If you’re using Android CLI, you can browse and set up your agent workflow with our growing collection of skills using the android skills command. These skills can also live alongside any other skills you create, or third-party skills created by the Android developer community. Learn more about getting started with Android skills. Install Android skills via the Android CLI to make your agent more effective and efficient. The latest guidance via the Android Knowledge Base The third component we are launching today is the Android Knowledge Base. Accessible through the android docs command and already available in the latest version of Android Studio, this specialized data source enables agents to search and fetch the latest authoritative developer guidelines to use as relevant context. The Android Knowledge Base ensures agents have the latest context, guidance, and best practices for Android. By accessing the frequently updated knowledge base, agents can ground their responses in the most recent information from Android developer docs, Firebase, Google Developers, and Kotlin docs. This ensures that even if an LLM's training cutoff is a year old, it can still provide guidance on the latest frameworks and patterns we recommend today. Android Studio: The ultimate destination for premium apps In addition to empowering developers and agents to handle project setup and boilerplate code, we’ve also designed these new tools and resources to make it easier to transition to Android Studio. That means you can start a prototype quickly with an agent using Android CLI and then open the project in Android Studio to fine-tune your UI with visual tools for code editing, UI design, deep debugging, and advanced profiling that scale with the growing capabilities of your app. And when it is time to build a high-quality app for large-scale publication across various device types, our agent in Android Studio is here to help, while leveraging the latest development best practices and libraries. Beyond the powerful Agent and Planning Modes for active development, we have introduced an AI-powered New Project flow, which provides an entry point to rapidly prototyping your next great idea for Android. These built-in agents make it simple to extend your app ideas across phones, foldables, tablets, Wear OS, Android Auto, and Android TV. Equipped with full context of your project’s source code and a comprehensive suite of debugging, profiling, and emulation tools, you have an end-to-end, AI-accelerated toolkit at your disposal. Get started today Android CLI is available in preview today, along with a growing set of Android skills and knowledge for agents. To get started, head over to d.android.com/tools/agents to download Android CLI.

4/15/2026

Posted by Bennet Manuel, Group Product Manager, App & Ecosystem Trust We strive to make Google Play the safest and most trusted experience possible. Today, we’re announcing a new set of policy updates and an account transfer feature to boost user privacy and protect your business from fraud. By providing better features for users and easy-to-integrate tools for you, we’re making it simpler to build safer apps so you can focus on creating great experiences. We’re also expanding our features to help you manage new contact and location policy changes, so you have a smoother, more predictable app review experience. By October, Play policy insights in Android Studio can help you proactively identify if your app should use these new features and guide you on the exact steps to take. Additionally, new pre-review checks in the Play Console will be available starting October 27 to flag potential contacts or location permissions policy issues so you can fix them before you submit your app for review. Here is what is new and how you can prepare. Contact Picker: A privacy-friendly way to access contacts Android is introducing the Android Contact Picker as the new standard for accessing contact information (e.g., for invites, sharing, or one-time lookups). This picker lets users share only the specific contacts they want to, helping build trust and protect privacy. Alongside this tool, we are updating our policy to require that all applicable apps use the picker, or other privacy-focused alternatives like Sharesheet, as the primary way to access users’ contacts. READ_CONTACTS will be reserved for apps that can’t function without it. What you’ll need to do If your app asks for access to contacts for features like sharing or inviting, you should update your code to use the picker and remove the READ_CONTACTS permission entirely (if targeting Android 17 and above). If your app requires full, ongoing access to a user’s contact list to function, you must justify this need by submitting a Play Developer Declaration in the Play Console. This form will be available before October. Location button: More privacy-friendly way to access location Android is introducing a new, streamlined location button to make requesting precise data easier for one-time actions, like finding a store or tagging a photo. This feature replaces complex permission dialogs with a single tap, helping users make clearer choices about how much information they share and for how long. We’re updating our policy to require apps to use this button for one-time precise location access unless they require persistent, always-on location access. This creates a faster, more predictable experience for your users and reduces the friction of traditional permission requests. What you’ll need to do Review your app's location usage to ensure you are requesting the minimum amount of location data needed for your app to work. If your app targets Android 17 and above and uses precise location for discrete, temporary actions, implement the location button by adding the onlyForLocationButton flag in your manifest. If your app requires persistent precise location to function, you will need to submit a Play Developer Declaration in Play Console to show why the new button or coarse location isn’t sufficient for your app’s core features. This form will be available before October. Account Transfer: Protecting your business You asked for a secure way to transfer app ownership during business changes, and we listened. We’re launching an official account transfer feature directly in Play Console that’s designed to help you easily transfer ownership during sales and mergers while also protecting your business from fraud. Starting May 27, account ownership changes must use this official feature. That means that unofficial transfers (like sharing login credentials or buying and selling accounts on third-party marketplaces) which leave your business vulnerable are not permitted. What you’ll need to do Initiate any future account owner changes through the "Users and permissions" page in Play Console. Every transfer will include a mandatory 7-day security cool-down period. This gives your team time to spot and cancel any unauthorized attempts to take over your account. See Transferring ownership of a Play Console developer account for more guidance. What’s next We want to give you plenty of time to review these changes and update your apps. For more information, deadlines, and the full list of Google Play policy updates we’re announcing today, please visit the Policy Announcements page. Thank you for your partnership in keeping Play safe for everyone.

4/14/2026

Google I/O 2026: Livestream Schedule Revealed Posted by The Google I/O team The Google I/O schedule is here! Tune in May 19–20 as we unveil Google’s biggest updates across AI, Android, Chrome, and Cloud. Discover new tools and features designed to unlock the future of development with agentic coding. We’re kicking things off with the Google keynote at 10:00 am PT on May 19, followed by the Developer keynote at 1:30 pm PT. Block your calendars for two days of live sessions, straight from Mountain View, full of announcements, live demos, and new professional development sessions. Here’s a sneak peak at what we’ll cover: The agentic era of development: Discover how the next evolution of our developer tools is transforming the way you write software. Learn how to seamlessly transition from rapid ideation to orchestrating powerful, autonomous workflows, allowing AI to handle the heavy lifting while you focus on the big picture. Enabling Android development anywhere: Learn how we are making AI even more helpful for your app workflows. From initial prototyping to final native polish, explore the latest ways we’re making it easier and faster to build high quality Android experiences. Building powerful, agentic web applications: The web is accelerating faster than ever, and we are equipping you for what's next. Discover new tools to build agent-ready web applications, automate complex debugging workflows, and ship highly interactive UI directly in the browser. Join us online May 19–20, followed by a fresh drop of on-demand sessions and codelabs on May 21. Register today to explore the full program and catch all the latest developer updates, featuring sessions like: What's new in Android What’s new in Google AI What's new in Chrome Build core skills to thrive as an AI-era developer

4/13/2026

Posted by Steven Jenkins, Product Manager, Android Studio Testing multi-device interactions is now easier than ever with the Android Emulator. Whether you are building a multiplayer game, extending your mobile application across form factors, or launching virtual devices that require a device connection, the Android Emulator now natively supports these developer experiences. Previously, interconnecting multiple Android Virtual Devices (AVDs) caused significant friction. It required manually managing complex port forwarding rules just to get two emulators to connect. Now you can take advantage of a new networking stack for the Android Emulator which brings zero-configuration peer-to-peer connectivity across all your AVDs. Interconnecting emulator instances The new networking stack for the Android Emulator transforms how emulators communicate. Previously, each virtual device operated on its own local area network (LAN), effectively isolating it from other AVDs. The new Wi-Fi network stack changes this by creating a shared virtual network backplane that bridges all running instances on the same host machine. Key Benefits: Zero-configuration: No more manual port forwarding or scripting adb commands. AVDs on the same host appear on the same virtual network. Peer-to-peer connectivity: Critical protocols like Wi-Fi Direct and Network Service Discovery (NSD) work out of the box between emulators. Improved stability: Resolves long-standing stability issues, such as data loss and connection drops found in the legacy stack. Cross-platform consistency: Works the same across Windows, macOS and Linux. Use Cases Multi-device apps: Test file sharing, local multiplayer gaming, or control flows between a phone and another Android device. Continuous Integration: Create robust, automated multi-device test pipelines without flaky network scripts. Android XR & AI glasses: Easily test companion app pairing and data streaming between a phone and glasses within Android Studio. Automotive & Wear OS: Validate connectivity flows between a mobile device and a vehicle head unit or smartwatch. The new emulator networking stack allows multiple AVDs to share a virtual network,  enabling direct peer-to-peer communication with zero configuration. Get Started The new networking capability is enabled by default in the latest Android Emulator release (36.5), which is available via the Android Studio SDK Manager. Just update your emulator and launch multiple devices! If you need to disable this feature or want to learn more, please refer to our documentation. As always, we appreciate any feedback. If you find a bug or issue, please file an issue. Also you can be part of our vibrant Android developer community on LinkedIn, Medium, Youtube, or X.

4/2/2026

Posted by Matthew Warner, Google Product Manager Every developer's AI workflow and needs are unique, and it's important to be able to choose how AI helps your development. In January, we introduced the ability to choose any local or remote AI model to power AI functionality in Android Studio, and today, we're announcing the availability of Gemma 4 for AI coding assistance in Android Studio. This new local model trained on Android development provides the best of both worlds: the privacy and cost-efficiency of on-device processing alongside state-of-the-art reasoning and tool-calling capabilities. AI assistance, locally delivered By running locally on your machine, Gemma 4 gives you AI code assistance that doesn't require an internet connection or an API key for its core operations. Key benefits include: Privacy and security: Your code stays on your machine. Gemma 4 processes all Agent Mode requests locally, making it an ideal choice for developers working with data privacy requirements or in secure corporate environments. Cost efficiency: Run complex agentic workflows without worrying about hitting quotas. Gemma 4 is optimized to run efficiently on modern development hardware, utilizing local GPU and RAM to provide snappy, responsive assistance. Offline availability: Use the agent to write code even when you don’t have an internet connection. State-of-the-art reasoning: Gemma 4 delivers best-in-class reasoning, capable of complex multi-step coding tasks in Agent Mode. Powerful agentic coding Gemma 4 was trained for Android development with agentic tool calling capabilities. When you select Gemma 4 as your local model, you can leverage Agent Mode for a variety of development use cases, such as: Designing new features: Developers can ask the agent to build a new feature or an entire app with commands like “build a calculator app” and the agent will not only generate the UI code but will use Android best practices like writing in Kotlin and using Jetpack Compose. Refactoring: You can give high-level commands such as "Extract all hardcoded strings and migrate them to strings.xml." The agent will scan your codebase, identify instances requiring changes, and apply the edits across multiple files simultaneously. Bug fixing and build resolution: If a project fails to build or has persistent lint errors, you can prompt the agent to "Build my project and fix any errors." The agent will navigate to the offending code and iteratively apply fixes until the build is successful. Recommended hardware requirements The 26B MoE is recommended for Android app developers using a machine with the minimum hardware requirements. Total RAM needed includes both Android Studio and Gemma. Model Total RAM needed Storage needed Gemma E2B 8GB 2 GB Gemma E4B 12 GB 4 GB Gemma 26B MoE 24 GB 17 GB Get started To get started, ensure you have the latest version of Android Studio installed. Install an LLM provider, such as LM Studio or Ollama, on your local computer. In Settings > Tools > AI > Model Providers add your LM Studio or Ollama instance. Download the Gemma 4 model from Ollama or LM Studio. Refer to hardware requirements for model size selection. In Agent Mode, select Gemma 4 as your active model. For a detailed walkthrough on configuration, check out the official documentation on how to use a local model. We are excited to see how Gemma 4 enables more private, secure, and powerful development workflows. As always, your feedback is essential as we continue to refine the AI experience in Android Studio. If you find a bug or issue, please file an issue. Also you can be part of our vibrant Android developer community on LinkedIn, YouTube, or X. Happy coding!

4/2/2026

Posted by David Chou, Product Manager and Caren Chang, Developer Relations Engineer At Google, we’re committed to bringing the most capable AI models directly to the Android devices in your pocket. Today, we’re thrilled to announce the release of our latest state-of-the-art open model: Gemma 4. These models are the foundation for the next generation of Gemini Nano, so code you write today for Gemma 4 will automatically work on Gemini Nano 4-enabled devices that will be available later this year. With Gemini Nano 4, you’ll benefit from our additional performance optimizations so you can ship to production across the Android ecosystem with the most efficient on-device inference. You can get early access to this model today through the AICore Developer Preview. Select the Gemini Nano 4 Fast model in the Developer Preview UI to see its blazing fast inference speed in action before you write any code Because Gemma 4 natively supports over 140 languages, you can expect improved localized, multilingual experiences for your global audience. Furthermore, Gemma 4 offers industry-leading performance with multimodal understanding, allowing your apps to understand and process text, images, and audio. To give you the best balance of performance and efficiency, Gemma 4 on Android comes in two sizes: E4B: Designed for higher reasoning power and complex tasks. E2B: Optimized for maximum speed (3x faster than the E4B model!) and lower latency. The new model is up to 4x faster than previous versions and uses up to 60% less battery. Starting today, you can experiment with improved capabilities including: Reasoning: Chain-of-thought commands and conditional statements can now be expected to return higher quality results. For example: “Determine if the following comment for a discussion thread passes the community guidelines. The comment does not pass the community guideline if it contains one or more of these reason_for_flag: profanity, derogatory language, hate speech”. If the review passes the community guidelines, return {true}. Otherwise, return {false, reason_for_flag}.” Math: With better math skills, the model can now more accurately answer questions. For example: “If I get 26 paychecks per year, how much should I contribute each paycheck to reach my savings goal of $10,000 over the course of a year?” Time understanding: The model is now more capable when reasoning about time, making it more accurate for use cases that involve calendars, reminders, and alarms. For example: “The event is at 6PM on August 18th, and a reminder should be sent out 10 hours before the event. Return the time and date the reminder should be sent.” Image understanding: Use cases that involve OCR (Optical Character Recognition) - such as chart understanding, visual data extraction, and handwriting recognition - will now return more accurate results. Join the Developer Preview today to download these models in preview models and start building next-generation features right away. Start building with Gemma 4 Start testing the model You can try out the model without code by following the Developer Preview guide. If you want to jump straight into integrating these models with your existing workflow, we’ve made that seamless. Head over to Android Studio to refine your prompt and build with the familiar ML Kit Prompt API. We’ve introduced a new ability to specify a model, allowing you to target the E2B (fast) or E4B (full) variants for testing. // Define the configuration with a specific track and preference val previewFullConfig = generationConfig { modelConfig = ModelConfig { releaseTrack = ModelReleaseTrack.PREVIEW preference = ModelPreference.FULL } } // Initialize the GenerativeModel with the configuration val previewModel = GenerativeModel.getClient(previewFullConfig) // Verify that the specific preview model is available val previewModelStatus = previewModel.checkStatus() if (previewModelStatus == FeatureStatus.AVAILABLE) { // Proceed with inference val response = previewModel.generateContent("If I get 26 paychecks per year, how much I should contribute each paycheck to reach my savings goal of $10k over the course of a year? Return only the amount.") } else { // Handle the case where the preview model is not available // (e.g., print out log statements) } What to expect during the Developer Preview The goal of this Developer Preview is to give you a head start on refining prompt accuracy and exploring new use cases for your specific apps.  We will be making several updates throughout the preview period, including support for tool calling, structured output, system prompts, and thinking mode in Prompt API, making it easier to take full advantage of the new capabilities and significant performance optimizations in Gemma 4. The preview models are available for testing on AICore-enabled devices. These models will run on the latest generation of specialized AI accelerators from Google, MediaTek, and Qualcomm Technologies. On other devices, the models will initially run on a CPU implementation that is not representative of final production performance. If your device is not AICore-enabled, you can also test these models via the AI Edge Gallery app. We’ll provide support for more devices in the future. How to get started Ready to see what Gemma 4 can do for your users? Opt-in: Sign up for the AICore Developer Preview. Download: Once opted in, you can trigger the download of the latest Gemma 4 models directly to your supported test device. Build: Update your ML Kit implementation to target the new models and start building in Android Studio.

4/2/2026

Posted by Matthew McCullough, VP of Product Management Android Development Today, we are enhancing Android development with Gemma 4, our latest state-of-the-art open model designed with complex reasoning and autonomous tool-calling capabilities. Our vision is to enable local agentic AI on Android across the entire software lifecycle, from development to production. Android supports a range of Gemma 4 models, from the most efficient ones running directly on-device in your apps to more powerful ones running on your development machine to help you build apps. We are bringing Gemma 4 to Android developers through two pillars: Local-first Agentic coding: Experience powerful, local AI code assistance with Gemma 4 in Android Studio in your development computer. On-device intelligence: Build intelligent experiences using the ML Kit GenAI Prompt API to run Gemma 4 directly on Android device hardware. Coding with Gemma 4 in Android Studio When building Android apps, Android Studio can use Gemma 4 to leverage its state-of-the-art reasoning power and native support for tool use, while keeping the model and inference contained entirely on your local machine. Gemma 4 was trained on Android development and designed with Agent Mode in mind. This means that when you select Gemma 4 as your local model, you can leverage the full suite of Agent Mode capabilities for a variety of Android development use cases, including refactoring legacy code, building an entire app or new features, and applying fixes iteratively. Learn more about the possibilities Gemma 4 brings to your app development flow and how to get started. Prototyping with Gemma 4 on-device Since the introduction of Gemini Nano as the foundation model on Android, it has become available on over 140 million devices. Gemma 4 is the base model for the next generation of Gemini Nano (Gemini Nano 4) that is optimized for performance and quality on Android devices. This model is up to 4x faster than the previous version and uses up to 60% less battery. To make it as easy as possible to preview and prototype with Gemma 4 E2B and E4B models directly on AICore-supported devices, we’re launching the AICore Developer Preview. While we continue to expand the ML Kit GenAI Prompt API surface to unlock additional advanced capabilities of the model, you can already start exploring new use cases with Gemma 4 using the Prompt API. Prepare your apps for the launch of the Gemini Nano 4 on the new flagship Android devices later this year by prototyping with Gemma 4 today. Read about the upcoming features and deep dive into AICore Developer Preview and its Gemma 4 support here. Local agentic intelligence with Gemma 4 Running Gemma 4 locally, you can leverage its advanced reasoning and tool-calling capabilities in your entire workflow, from developing with the AI coding assistant in Android Studio to shipping intelligent features in your app with ML Kit GenAI Prompt API. This local-first approach, available under Gemma’s open Apache license, provides an alternative for developers to innovate in a privacy-centric and cost effective manner.  In a future release, we will update Android Bench to include Gemma 4 and other open models, providing the quantified data you need to navigate performance trade-offs and select the best model for your use case. We can’t wait to see what you build!

4/2/2026

/* Responsive CSS for Mobile */ .post-body-wrapper { line-height: 1.6; font-family: inherit; } .post-body-wrapper img { max-width: 100%; height: auto; display: block; } /* On mobile, stack images. On desktop (wider than 600px), use floats. */ @media screen and (min-width: 601px) { .float-right { float: right; margin: 0 0 1em 1em; } .float-left { float: left; margin: 0 1em 1em 0; } } .code-span { color: #188038; font-family: "Roboto Mono", monospace; font-size: 11pt; } .separator { clear: both; text-align: center; } Posted by Matt Dyor, Senior Product Manager Android Studio Panda 3 is now stable and ready for you to use in production. This release gives you even more control and customization over your AI-powered workflows, making it easier than ever to build high-quality Android apps. Whether you're bringing new capabilities to an existing app or standing up a brand new app, these updates elevate your development experience by allowing your AI Agent in Android Studio to learn your specific practices and giving you granular control over its permissions. Lastly, in addition to AI skills and Agent Mode enchantments, Android Studio Panda 3 also includes updated support for build Android apps for cars. Here’s a deep dive into what’s new: Agent skills Create a more helpful AI agent by using agent skills in Android Studio. Agent skills are specialized instructions that teach the agent new capabilities and best practices for a specific workflow, which the agent can then leverage as needed. This significantly reduces the level of detail required for your day-to-day prompts. Agent skills work with Gemini in Android Studio or with other remote 3rd party LLMs you integrate into the agent framework in Android Studio. You and members of your team can create skills that tell the agent exactly how you want to handle specific tasks in your codebase. For example, you could create a custom “code review” skill tailored to your organization's coding standards, or custom skill to provide the agent with more information on using an in-house library. Once you have created a skill, the agent will be able to use it automatically, or you can manually trigger it by typing @ followed by the skill name. Check out the documentation to learn more about how to create skills for your codebase, or better yet—ask your agent to help you build a new skill and it will guide you through the details! Manually Trigger Agent Skill in Android Studio Getting Started To build a skill for your project, do the following: Create a .skills directory inside your project's root folder. Place a SKILL.md file inside this new directory. Add a name and description to the file to define your custom workflow, and your skill is ready. Optionally include scripts, assets, and references to provide even more guidance to your agent. Agent skills in Android Studio Manage permissions for Agent Mode You control your codebase, and you can now be more deliberate with which data and capabilities you choose to share with AI agents. The new granular agent permissions in Android Studio let you decide exactly what agents can do for you. When Agent Mode needs to read files, run shell commands, or access the web, it explicitly asks for your permission. We know that 'approval fatigue' is a real risk in AI workflows—when a tool asks for permission too often, it’s easy to start clicking 'Allow' without fully reviewing the action. By offering granular 'Always Allow' rules for trusted operations and an optional sandbox for experimental ones, Android Studio helps you stay focused on the high-stakes decisions that actually require your manual sign-off. Agent Permissions Agent permissions are intuitive to set up and use. For example, granting high-level permissions automatically authorizes related sub-tools, while commands you have previously approved will run automatically without interrupting your flow. Rest assured, accessing sensitive files like SSH keys will always require your explicit sign-off. For even more security, you can also use an optional sandbox to enforce strict, isolated control over the agent. Agent Shell Sandbox Empty Car App Library App template We’re making it easier to build Android apps for cars. Building apps for the car used to mean wrestling with complex configurations just to get the project to build successfully. Now, you can accelerate your development with the new “Empty Car App Library App” template in Android Studio. This template takes care of the required boilerplate code for a driving-optimized app on both Android Auto and Android Automotive OS, saving you significant time and effort. Instead of getting bogged down in setup, you can focus on creating the best experience for your users on the road. Getting Started To use the new template: Select New Project on the Welcome to Android Studio screen (or File > New > New Project from within a project). Search for or select the Empty Car App Library App template. Name your app and click Finish to generate your driving-optimized app. Empty Car App Library App template Android Studio Panda releases  Panda 3 builds off last month’s AI-focused Panda 2 release. Check out Go from prompt to working prototype with Android Studio Panda 2 post to learn more about new Android Studio features, including the AI-powered New Project Flow that takes you from prompt to prototype and the Version Upgrade Assistant that takes the toil out of updating your dependencies. Get started Dive in and accelerate your development. Download Android Studio Panda 3 and start exploring these powerful new agentic 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. Happy coding!

4/1/2026

Posted by Michael Stillwell, Developer Relations Engineer and Dimitris Kosmidis, Product Manager, Wear OS 64-bit architectures provide performance improvements and a foundation for future innovation, delivering faster and richer experiences for your users. We’ve supported 64-bit CPUs since Android 5. This aligns Wear OS with recent updates for Google TV and other form factors, building on the 64-bit requirement first introduced for mobile in 2019. Today, we are extending this 64-bit requirement to Wear OS. This blog provides guidance to help you prepare your apps to meet these new requirements. The 64-bit requirement: timeline for Wear OS developers Starting September 15, 2026: All new apps and app updates that include native code will be required to provide 64-bit versions in addition to 32-bit versions when publishing to Google Play. Google Play will start blocking the upload of non-compliant apps to the Play Console. We are not making changes to our policy on 32-bit support, and Google Play will continue to deliver apps to existing 32-bit devices. The vast majority of Wear OS developers has already made this shift, with 64-bit compliant apps already available. For the remaining apps, we expect the effort to be small. Preparing for the 64-bit requirement Many apps are written entirely in non-native code (i.e. Kotlin or Java) and do not need any code changes. However, it is important to note that even if you do not write native code yourself, a dependency or SDK could be introducing it into your app, so you still need to check whether your app includes native code. Assess your app Inspect your APK or app bundle for native code using the APK Analyzer in Android Studio. Look for .so files within the lib folder. For ARM devices, 32-bit libraries are located in lib/armeabi-v7a, while the 64-bit equivalent is lib/arm64-v8a. Ensure parity: The goal is to ensure that your app runs correctly in a 64-bit-only environment. While specific configurations may vary, for most apps this means that for each native 32-bit architecture you support, you should include the corresponding 64-bit architecture by providing the relevant .so files for both ABIs. Upgrade SDKs: If you only have 32-bit versions of a third-party library or SDK, reach out to the provider for a 64-bit compliant version. How to test 64-bit compatibility The 64-bit version of your app should offer the same quality and feature set as the 32-bit version. The Wear OS Android Emulator can be used to verify that your app behaves and performs as expected in a 64-bit environment. Note: Since Wear OS apps are required to target Wear OS 4 or higher to be submitted to Google Play, you are likely already testing on these newer, 64-bit only images. When testing, pay attention to native code loaders such as SoLoader or older versions of OpenSSL, which may require updates to function correctly on 64-bit only hardware. Next steps We are announcing this requirement now to give developers a six-month window to bring their apps into compliance before enforcement begins in September 2026. For more detailed guidance on the transition, please refer to our in-depth documentation on supporting 64-bit architectures. This transition marks an exciting step for the future of Wear OS and the benefits that 64-bit compatibility will bring to the ecosystem.

3/30/2026

Posted by Andrew Lewis, Software Engineer Media3 1.10 is out! Media3 1.10 includes new features, bug fixes and feature improvements, including Material3-based playback widgets, expanded format support in ExoPlayer and improved speed adjustment when exporting media with Transformer. Read on to find out more, and check out the full release notes for a comprehensive list of changes. Playback UI and Compose We are continuing to expand the media3-ui-compose-material3 module to help you build Compose UIs for playback. We've added a new Player Composable that combines a ContentFrame with customizable playback controls, giving you an out-of-the-box player widget with a modern UI. This release also adds a ProgressSlider Composable for displaying player progress and performing seeks using dragging and tapping gestures. For playback speed management, a new PlaybackSpeedControl is available in the base media3-ui-compose module, alongside a styled PlaybackSpeedToggleButton in the Material 3 module. We'll continue working on new additions like track selection utils, subtitle support and more customization options in the upcoming Media3 releases. We're eager to hear your feedback so please share your thoughts on the project issue tracker.  Player Composable in the Media3 Compose demo app Playback feature enhancements Media3 1.10 includes a variety of additions and improvements across the playback modules: Format support: ExoPlayer now supports extracting Dolby Vision Profile 10 and Versatile Video Coding (VVC) tracks in MP4 containers, and we've introduced MPEG-H UI manager support in the decoder_mpeghextension. The IAMF extension now seamlessly supports binaural output, either through the decoder viaiamf_tools or through the Android OS Spatializer, with new logic to match the output layout of the speakers. Ad playback: Improvements to reliability, improved HLS interstitial support forX-PLAYOUT-LIMIT  and X-SNAP, and with the latest IMA SDK dependency you can control whether ad click-through URLs open in custom tabs with setEnableCustomTabs. HLS: ExoPlayer now allows location fallback upon encountering load errors if redundant streams from different locations are available. Session: MediaSessionService now extends LifecycleService, allowing apps to access the lifecycle scoping of the service. One of our key focus areas this year is on playback efficiency and performance. Media3 1.10 includes experimental support for scheduling the core playback loop in a more efficient way. You can try this out by enabling experimentalSetDynamicSchedulingEnabled() via the ExoPlayer.Builder. We plan to make further improvements in future releases so stay tuned! Media editing and Transformer For developers building media editing experiences, we've made speed adjustments more robust. EditedMediaItem.Builder.setFrameRate()can now set a maximum output frame rate for video. This is particularly helpful for controlling output size and maintaining performance when increasing media speed with setSpeed(). New modules for frame extraction and applying Lottie effects In this release we've split some functionality into new modules to reduce the scope of some dependencies: FrameExtractor has been removed from the main media3-inspector module, so please migrate your code to use the new media3-inspector-framemodule and update your imports toandroidx.media3.inspector.frame.FrameExtractor. We have also moved theLottieOverlayeffect to a separate media3-effect-lottie module. As a reminder, this gives you a straightforward way to apply vector-based Lottie animations directly to video frames. Please get in touch via the issue tracker if you run into any bugs, or if you have questions or feature requests. We look forward to hearing from you!

3/30/2026

.post-container { font-family: 'Segoe UI', Roboto, Helvetica, Arial, sans-serif; line-height: 1.6; color: #333; max-width: 800px; margin: auto; } .highlight-box { background-color: #f2f2f2; border-left: 5px solid #666; padding: 20px; margin: 25px 0; } .stats-table { width: 100%; border-collapse: collapse; margin: 20px 0; } .stats-table th, .stats-table td { border: 1px solid #ccc; padding: 12px; text-align: left; } .stats-table th { background-color: #e0e0e0; color: #222; } .code-block { background-color: #f7f7f7; color: #333; padding: 18px; border-radius: 4px; overflow-x: auto; font-family: 'Consolas', 'Monaco', monospace; font-size: 14px; margin: 20px 0; border: 1px solid #ddd; } .quote { font-style: italic; font-size: 1.1em; color: #444; padding: 10px 25px; border-left: 4px solid #bbb; margin: 30px 0; } h2 { color: #222; /* Section line removed here */ padding-bottom: 8px; margin-top: 30px; } a { color: #444; text-decoration: underline; } .bullet-point { color: #777; margin-right: 8px; } .separator img { max-width: 100%; height: auto; } Posted by Ben Weiss, Senior Developer Relations Engineer Unlocking broad performance wins with R8 full mode ● Startup Reliability: Cold starts improved by 30%, Warm starts by 24%, and Hot starts by 14%. ● Launch Speed: P50 launch times improved by 11% and P90 launch times by 12%. ● Efficiency: Overall app size was reduced by 9%. ● Stability: ANR reduction of 35%. Enabling optimizations with a single change Many Android apps use an outdated default configuration file which disables most functionality of the R8 optimizer. The main change Monzo made to unlock these performance improvements was to replace the proguard-android.txt default file with proguard-android-optimize.txt. This change removes the -dontoptimize instruction and allows R8 to properly do its job. buildTypes { release { isMinifyEnabled = true isShrinkResources = true proguardFiles( getDefaultProguardFile("proguard-android-optimize.txt"), ) } } After making this change, it's worth looking at your Keep configuration files. These files tell R8 which parts of your code to leave alone (usually because they're called dynamically or by external libraries). Tidying up unnecessary Keep rules means R8 can do more. Improving scroll performance with Baseline Profiles Baseline Profiles, specifically targeting scroll and rendering performance on their main feed. This strategy ensured that the most common user journeys—opening the app and scrolling the feed—were fully optimized. The impact on rendering was substantial: P90 scroll performance became 71% faster, and P95 scroll performance improved by 87%. Now scrolling the app is smoother than before. Monzo built this into their release process to maintain these improvements over time. "We trigger the baseline profile generation every week day (before running our nightly builds) and commit the latest changes once completed," Neumayer explains. Keeping up with modern Android development Neumayer's advice for other teams? Regularly check your practices against current standards: "Take a look at the latest recommendations from Google around app performance and check if you're following all the latest advice." To get started and learn more about R8, visit https://d.android.com/r8

3/30/2026

Posted by Matthew Forsythe, Director Product Management, Android App Safety Android is for everyone. It’s built on a commitment to an open and safe platform. Users should feel confident installing apps, no matter where they get them from. However, our recent analysis found over 90 times more malware from sideloaded sources than on Google Play. So as an extra layer of security, we are rolling out Android developer verification to help prevent malicious actors from hiding behind anonymity to repeatedly spread harm. Over the past several months, we’ve worked closely with the community to improve the design so we account for the many ways people use Android to balance openness with safety. Start your verification today Today, we’re starting to roll out Android developer verification to all developers in both the new Android Developer Console and Play Console. This allows you to complete your verification and register your apps before user-facing changes begin later this year. If you only distribute apps outside of Google Play, you can create an account in Android Developer Console today. If you're on Google Play, check your Play Console account for updates over the next few weeks. If you’ve already verified your identity here, then you’re likely already set. Most of your users’ download experience will not change at all While verification tools are rolling out now, the experience for users downloading your apps will not change until later this year. The user side protections will first go live in Brazil, Indonesia, Singapore, and Thailand this September, before expanding globally in 2027. We’ve shared this timeline early to ensure you have ample time to complete your verification. Following this deadline, for the vast majority of users, the experience of installing apps will stay exactly the same. It’s only when a user tries to install an unregistered app that they’ll require ADB or advanced flow, helping us keep the broader community safe while preserving the flexibility for our power users. Developers can still choose where to distribute their apps. Most users’ download experience will not change Tailoring the verification experience to your feedback To balance the need for safety with our commitment to openness, we’ve improved the verification experience based on your feedback. We’ve streamlined the developer experience to be more integrated with existing workflows and maintained choice for power users. For Android Studio developers: In the next two months, you’ll see your app's registration status right in Android Studio when you generate a signed App Bundle or APK. You’ll see your app's registration status in Android Studio when you generate a signed App Bundle or APK. For Play developers: If you've completed Play Console's developer verification requirements, your identity is already verified and we'll automatically register eligible Play apps for you. In the rare case that we are unable to register your apps for you, you will need to follow the manual app claim process. Over the next couple of weeks, more details will be provided in the Play Console and through email. Also, you’ll be able to register apps you distribute outside of Play in the Play Console too. The Android developer verification page in your Play Console will show the registration status for each of your apps. For students and hobbyists: To keep Android accessible to everyone, we're building a free, no government ID required, limited distribution account so you can share your work with up to 20 devices. You only need an email account to get started. Sign up for early access. We’ll send invites in June. For power users: We are maintaining the choice to install apps from any source. You can use the new advanced flow for sideloading unregistered apps or continue using ADB. This maintains choice while protecting vulnerable users. What’s next? We’re rolling this out carefully and working closely with developers, users, and our partners. In April, we’ll introduce Android Developer Verifier, a new Google system service that will be used to check if an app is registered to a verified developer. April 2026: Users will start to see Android Developer Verifier in their Google Systems services settings. June 2026: Early access: Limited distribution accounts for students and hobbyists. August 2026:  Limited distribution accounts launch globally. Advanced flow for power users launches globally. September 30, 2026: Apps must be registered by verified developers in order to be installed and updated on certified Android devices in Brazil, Indonesia, Singapore, and Thailand. Unregistered apps can be sideloaded with ADB or advanced flow. 2027 and beyond: We will roll out this requirement globally. We’re committed to an Android that is both open and safe. Check out our developer guides to get started today.

3/26/2026

Posted by Robert Clifford, Developer Relations Engineer and Manjeet Rulhania, Software Engineer A pillar of the Android ecosystem is our shared commitment to user trust. As the mobile landscape has evolved, so does our approach to protecting sensitive information. In Android 17, we’re introducing a suite of new location privacy features designed to give users more control and provide developers elegant solutions for data minimization and product safety. Our strategy focuses on introducing new tools to balance high-quality experiences with robust privacy protections, and improving transparency for users to help manage their data. Introducing the location button: simplified access for one time use For many common tasks, like finding a nearby shop or tagging a social post, your app doesn’t need permanent or background access to a user's precise location.With Android 17, we are introducing the location button, a new UI element designed to provide a well-lit path for responsible one time precise location access. Industry partners have requested this new feature as a way to bring a simpler, and more private location flow to their users. Users get better privacy protection Moving the decision making for location sharing to the point where a user takes action, helps the user make a clearer choice about how much information they want to share and for how long. This empowers users to limit data sharing to only what apps need in that session. Once consent is provided, this session based access eliminates repeated prompts for location dependent features. This benefits developers by creating a smoother experience for their users and providing high confidence in user intent, as access is explicitly requested at the moment of action. Full UI customization to match your app’s aesthetic The location button provides extensive customization options to ensure integration with your app's aesthetic while maintaining system-wide recognizability. You can modify the button's visual style including: Background and icon color scheme Outline style Size and shape Additionally, you can select the appropriate text label from a predefined list of options. To ensure security and trust, the location icon itself remains mandatory and non-customizable, while the font size is system-managed to respect user accessibility settings Simplified Integration with Jetpack and automatic backwards compatibility The location button will be provided as a Jetpack library, ensuring easy integration into your existing app layouts similar to any other Jetpack view implementation, and simplifying how you request permission to access precise location. Additionally, when you implement location button with the Jetpack library it will automatically handle backwards compatibility by defaulting to the existing location prompt when a user taps it on a device running Android 16 or below. The Android location button is available for testing as of Android 17 Beta 3.  Location access transparency Users often struggle to understand the tools they can use to monitor and control access to their location data. In Android 17, we are aligning location permission transparency with the high standards already set for the Microphone and Camera.     Updated Location Indicator: A persistent indicator will now appear to inform a user whenever a non-system app accesses their location Attribution & Control: Users can tap the indicator to see exactly which apps have recently accessed their location and manage those permissions immediately through a "Recent app use" dialog. Strengthening user privacy with density-based Coarse Location Android 17 is also improving the algorithm for approximate (coarse) locations to be aware of population density. Previously, coarse locations used a static 2 km-wide grid, which in low-population areas may not be sufficiently private since a 2km square could often contain only a handful of users. The new approach replaces this fixed grid with a dynamically-sized area based on local population density. By increasing the grid for areas with lower population density, Android ensures a more consistent privacy guarantee across different environments from dense urban centers to remote regions. Improved runtime permission dialog The runtime permission dialog for location is one of the more complex flows for users to navigate, with users being asked to decide on the granularity and length of permission access they are willing to grant to each app. In an effort to help users to make the most informed privacy decisions with less friction, we’ve redesigned the dialog to make "Precise" and "Approximate" choices more visually distinct, encouraging users to select the level of access which best suits their needs.   Start building for Android 17 The new location privacy tools are available now in Beta 3. We’re looking for your feedback to help refine these features before the general release. Feedback: Report issues on the [Official Tracker]. Build a smoother, more private experience today.

3/26/2026

Posted by Matthew McCullough, VP of Product Management, Android Developer Android 17 has officially reached platform stability today with Beta 3. That means that the API surface is locked; you can perform final compatibility testing and push your Android 17-targeted apps to the Play Store. In addition, Beta 3 brings a host of new capabilities to help you build better, more secure, and highly integrated applications. Get your apps, libraries, tools, and game engines ready! If you develop an SDK, library, tool, or game engine, it's even more important 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 3. Work through all your app's flows and look for functional or UI issues. Review the behavior changes to focus your testing. Each release of Android contains platform changes that improve privacy, security, and overall user experience, and these changes can affect your apps. Here are some changes to focus on: Resizability on large screens: Once you target Android 17, you can no longer opt out of maintaining orientation, resizability and aspect ratio constraints on large screens. Dynamic code loading: If your app targets Android 17 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 Android 17 or higher have local network access blocked by default. Switch to using privacy preserving pickers if possible, and use the new ACCESS_LOCAL_NETWORK for broad, persistent access. Media and camera enhancements Photo Picker customization options Android now allows you to tailor the visual presentation of the photo picker to better complement your app’s user interface. By leveraging the new PhotoPickerUiCustomizationParams API, you can modify the grid view aspect ratio from the standard 1:1 square to a 9:16 portrait display. This flexibility extends to both the ACTION_PICK_IMAGES intent and the embedded photo picker, enabling you to maintain a cohesive aesthetic when users interact with media. This is all part of our effort to help make the privacy-preserving Android photo picker fit seamlessly with your app experience. Learn more about how you can embed the photo picker directly into your app for the most native experience. val params = PhotoPickerUiCustomizationParams.Builder() .setAspectRatio(PhotoPickerUiCustomizationParams.ASPECT_RATIO_PORTRAIT_9_16) .build() val intent = Intent(MediaStore.ACTION_PICK_IMAGES).apply { putExtra(MediaStore.EXTRA_PICK_IMAGES_UI_CUSTOMIZATION_PARAMS, params) } startActivityForResult(intent, REQUEST_CODE) Support for the RAW14 image format: Android 17 introduces support for the RAW14 image format — the de-facto industry standard for high-end digital photography — via the new ImageFormat.RAW14 constant. RAW14 is a single-channel, 14-bit per pixel format that uses a densely packed layout where every four consecutive pixels are packed into seven bytes. Vendor-defined camera extensions: Android 17 adds Vendor-defined extensions to enable hardware partners define and implement custom camera extension modes to provide you access to the best and latest camera features, such as 'Super Resolution' or cutting-edge AI-driven enhancements. You can query for these modes using the isExtensionSupported(int) API. Camera device type APIs: New Android 17 APIs allow you to query the underlying device type to identify if a camera is built-in hardware, an external USB webcam, or a virtual camera. Bluetooth LE Audio hearing aid support Android now includes a specific device category for Bluetooth Low Energy (BLE) Audio hearing aids. With the addition of the AudioDeviceInfo.TYPE_BLE_HEARING_AID constant, your app can now distinguish hearing aids from regular headsets. val audioManager = getSystemService(Context.AUDIO_SERVICE) as AudioManager val devices = audioManager.getDevices(AudioManager.GET_DEVICES_OUTPUTS) val isHearingAidConnected = devices.any { it.type == AudioDeviceInfo.TYPE_BLE_HEARING_AID } 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. Extended HE-AAC software encoder Android 17 introduces a system-provided Extended HE-AAC software encoder. This encoder supports both low and high bitrates using unified speech and audio coding. You can access this encoder via the MediaCodec API using the name c2.android.xheaac.encoder or by querying for the audio/mp4a-latm MIME type. val encoder = MediaCodec.createByCodecName("c2.android.xheaac.encoder") val format = MediaFormat.createAudioFormat(MediaFormat.MIMETYPE_AUDIO_AAC, 48000, 1) format.setInteger(MediaFormat.KEY_BIT_RATE, 24000) format.setInteger(MediaFormat.KEY_AAC_PROFILE, MediaCodecInfo.CodecProfileLevel.AACObjectXHE) encoder.configure(format, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE) Performance and Battery Enhancements Reduce wakelocks with listener support for allow-while-idle alarms Android 17 introduces a new variant of AlarmManager.setExactAndAllowWhileIdle that accepts an OnAlarmListener instead of a PendingIntent. This new callback-based mechanism is ideal for apps that currently rely on continuous wakelocks to perform periodic tasks, such as messaging apps maintaining socket connections. val alarmManager = getSystemService(AlarmManager::class.java) val listener = AlarmManager.OnAlarmListener { // Do work here } alarmManager.setExactAndAllowWhileIdle( AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + 60000, listener, null ) Privacy updates System-provided Location Button Android is introducing a system-rendered location button that you will be able to embed directly into your app's layout using an Android Jetpack library. When a user taps this system button, your app is granted precise location access for the current session only. To implement this, you need to declare the USE_LOCATION_BUTTON permission. Discrete password visibility settings for touch and physical keyboards This feature splits the existing "Show passwords" system setting into two distinct user preferences: one for touch-based inputs and another for physical (hardware) keyboard inputs. Characters entered via physical keyboards are now hidden immediately by default. val isPhysical = event.source and InputDevice.SOURCE_KEYBOARD == InputDevice.SOURCE_KEYBOARD val shouldShow = android.text.ShowSecretsSetting.shouldShowPassword(context, isPhysical) Security Enforced read-only dynamic code loading To improve security against code injection attacks, Android now enforces that dynamically loaded native libraries must be read-only. If your app targets Android 17 or higher, all native files loaded using System.load() must be marked as read-only beforehand. val libraryFile = File(context.filesDir, "my_native_lib.so") // Mark the file as read-only before loading to comply with Android 17+ security requirements libraryFile.setReadOnly() System.load(libraryFile.absolutePath) Post-Quantum Cryptography (PQC) Hybrid APK Signing To prepare for future advancements in quantum computing, Android is introducing support for Post-Quantum Cryptography (PQC) through the new v3.2 APK Signature Scheme. This scheme utilizes a hybrid approach, combining a classical signature with an ML-DSA signature. User experience and system UI Better support for widgets on external displays This feature improves the visual consistency of app widgets when they are shown on connected or external displays with different pixel densities using DP or SP units. val options = appWidgetManager.getAppWidgetOptions(appWidgetId) val displayId = options.getInt(AppWidgetManager.OPTION_APPWIDGET_DISPLAY_ID) val remoteViews = RemoteViews(context.packageName, R.layout.widget_layout) remoteViews.setViewPadding( R.id.container, 16f, 8f, 16f, 8f, TypedValue.COMPLEX_UNIT_DIP ) Hidden app labels on the home screen Android now provides a user setting to hide app names (labels) on the home screen workspace. Ensure your app icon is distinct and recognizable. Desktop Interactive Picture-in-Picture Unlike traditional Picture-in-Picture, these pinned windows remain interactive while staying always-on-top of other application windows in desktop mode. val appTask: ActivityManager.AppTask = activity.getSystemService(ActivityManager::class.java).appTasks[0] appTask.requestWindowingLayer( ActivityManager.AppTask.WINDOWING_LAYER_PINNED, context.mainExecutor, object : OutcomeReceiver<Int, Exception> { override fun onResult(result: Int) { if (result == ActivityManager.AppTask.WINDOWING_LAYER_REQUEST_GRANTED) { // Task successfully moved to pinned layer } } override fun onError(error: Exception) {} } ) Redesigned screen recording toolbar Core functionality VPN app exclusion settings By using the new ACTION_VPN_APP_EXCLUSION_SETTINGS Intent, your app can launch a system-managed Settings screen where users can select applications to bypass the VPN tunnel. val intent = Intent(Settings.ACTION_VPN_APP_EXCLUSION_SETTINGS) if (intent.resolveActivity(packageManager) != null) { startActivity(intent) } OpenJDK 25 and 21 API updates This update brings extensive features and refinements from OpenJDK 21 and OpenJDK 25, including the latest Unicode support and enhanced SSL support for named groups in TLS. Get started with Android 17 You can enroll any supported Pixel device or use the 64-bit system images with the Android Emulator. Compile against the new SDK and report issues on the feedback page. Test your current app for compatibility and learn whether your app is affected by changes in Android 17. For complete information, visit the Android 17 developer site.

3/25/2026

Posted by Robbie McLachlan, Developer Marketing The wait is over! We are incredibly excited to share the Google Play Apps Accelerator class of 2026. We’ve handpicked a group of high-potential studios from across the globe to embark on a 12-week journey designed to supercharge their success. Here’s what’s in store for the program’s first ever class: Curated learning: virtual masterclasses and workshops led by industry trailblazers. Guidance & mentorship: 1-to-1 sessions covering everything from technical scaling to leadership. Direct access: exclusive sessions with experts from Google and the world's top studios. Without further ado, join us in congratulating them! Google Play Apps Accelerator | Class of 2026 Americas Anytune AstroVeda BetterYou Changed Focus Forge Human Program Know Your Lemons kweliTV Language Innovation Matraquinha MR ROCCO MUU nutrition NKENNE Skarvo Starcrossed Wishfinity Asia Pacific Human Health Kitakuji Lazy Surfers Mellers Tech Reehee Company Europe, Middle East & Africa cabuu Class54 Education Digital Garden EverPixel Geolives HelloMind ifal Idea Accelerator Maposcope Ochy Picastro Pixelbite Record Scanner Talkao unorderly Xeropan International Congratulations again to all the founders selected, we can’t wait to see your apps grow on our platform. The Google Play Apps Accelerator is part of our mission to help businesses of all sizes grow on Google Play and reach their full potential. Discover more about Google Play’s programs, resources and tools.

3/24/2026

Posted by Roxanna Aliabadi Walker, Senior Product Manager Privacy and user control remain at the heart of the Android experience. Just as the photo picker made media sharing secure and easy to implement, we are now bringing that same level of privacy, simplicity, and great user experience to contact selection. A New Standard for Contact Privacy Historically, applications requiring access to a specific user's contacts relied on the broad READ_CONTACTS permission. While functional, this approach often granted apps more data than necessary. The new Android Contact Picker, introduced in Android 17, changes this dynamic by providing a standardized, secure, and searchable interface for contact selection. This feature allows users to grant apps access only to the specific contacts they choose, aligning with Android's commitment to data transparency and minimized permission footprints. How It Works Developers can integrate the Contact Picker using the Intent.ACTION_PICK_CONTACTS intent. This updated API offers several powerful capabilities: Granular Data Requests: Apps can specify exactly which fields they need, such as phone numbers or email addresses, rather than receiving the entire contact record. Multi-Selection Support: The picker supports both single and multiple contact selections, giving developers more flexibility for features like group invitations. Selection Limits: Developers can set custom limits on the number of contacts a user can select at one time. Temporary Access: Upon selection, the system returns a Session URI that provides temporary read access to the requested data, ensuring that access does not persist longer than necessary. Access to other profiles: When using this new intent, the interface will allow users to select contents from other user profiles such as a work profile, cloned profile or a private space. Optimized Performance: The Contact Picker returns a single Uri that allows for collective result querying, eliminating the need to query individual contact Uri separately as required by ACTION_PICK. This efficiency further reduces system overhead by utilizing a single Binder transaction. Backward Compatibility and Implementation For devices running Android 17 or higher, the system automatically upgrades legacy ACTION_PICK intents that specify contact data types to the new, more secure interface. However, to take full advantage of advanced features like multi-selection, developers are encouraged to update their implementation code and utilize the ContentResolver to query the returned Session URI. Integrate the contact pickerTo integrate the Contact Picker, developers use the  ACTION_PICK_CONTACTS intent. Below is a code example demonstrating how to launch the picker and request specific data fields, such as email and phone numbers. // State to hold the list of selected contacts var contacts by remember { mutableStateOf<List<Contact>>(emptyList()) } // Launcher for the Contact Picker intent val pickContact = rememberLauncherForActivityResult(StartActivityForResult()) { if (it.resultCode == Activity.RESULT_OK) { val resultUri = it.data?.data ?: return@rememberLauncherForActivityResult // Process the result URI in a background thread coroutine.launch { contacts = processContactPickerResultUri(resultUri, context) } } } // Define the specific contact data fields you need val requestedFields = arrayListOf( Email.CONTENT_ITEM_TYPE, Phone.CONTENT_ITEM_TYPE, ) // Set up the intent for the Contact Picker val pickContactIntent = Intent(ACTION_PICK_CONTACTS).apply { putExtra(EXTRA_PICK_CONTACTS_SELECTION_LIMIT, 5) putStringArrayListExtra( EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS, requestedFields ) putExtra(EXTRA_PICK_CONTACTS_MATCH_ALL_DATA_FIELDS, false) } // Launch the picker pickContact.launch(pickContactIntent) After the user makes a selection, the app processes the result by querying the returned Session URI to extract the requested contact information. // Data class representing a parsed Contact with selected details data class Contact(val id: String, val name: String, val email: String?, val phone: String?) // Helper function to query the content resolver with the URI returned by the Contact Picker. // Parses the cursor to extract contact details such as name, email, and phone number private suspend fun processContactPickerResultUri( sessionUri: Uri, context: Context ): List<Contact> = withContext(Dispatchers.IO) { // Define the columns we want to retrieve from the ContactPicker ContentProvider val projection = arrayOf( ContactsContract.Contacts._ID, ContactsContract.Contacts.DISPLAY_NAME_PRIMARY, ContactsContract.Data.MIMETYPE, // Type of data (e.g., email or phone) ContactsContract.Data.DATA1, // The actual data (Phone number / Email string) ) val results = mutableListOf<Contact>() // Note: The Contact Picker Session Uri doesn't support custom selection & selectionArgs. context.contentResolver.query(sessionUri, projection, null, null, null)?.use { cursor -> // Get the column indices for our requested projection val contactIdIdx = cursor.getColumnIndex(ContactsContract.Contacts._ID) val mimeTypeIdx = cursor.getColumnIndex(ContactsContract.Data.MIMETYPE) val nameIdx = cursor.getColumnIndex(ContactsContract.Contacts.DISPLAY_NAME_PRIMARY) val data1Idx = cursor.getColumnIndex(ContactsContract.Data.DATA1) while (cursor.moveToNext()) { val contactId = cursor.getString(contactIdIdx) val mimeType = cursor.getString(mimeTypeIdx) val name = cursor.getString(nameIdx) ?: "" val data1 = cursor.getString(data1Idx) ?: "" // Determine if the current row represents an email or a phone number val email = if (mimeType == Email.CONTENT_ITEM_TYPE) data1 else null val phone = if (mimeType == Phone.CONTENT_ITEM_TYPE) data1 else null // Add the parsed contact to our results list results.add(Contact(contactId, name, email, phone)) } } return@withContext results } Check out the full documentation here. Best Practices for Developers To provide the best user experience and maintain high security standards, we recommend the following: Data Minimization: Only request the specific data fields (e.g., email) your app needs. Immediate Persistence: Persist selected data immediately, as the Session URI access is temporary.

3/24/2026

Posted by Eser Erdem, Senior Engineering Manager, Android Automotive At Google we’re deeply committed to the automotive industry--not just as a technology provider, but as a partner in the industry's transformation. We believe that car makers and users should have choice and flexibility, and that open platforms are the best enablers. For over a decade, we have provided Android Automotive OS (AAOS) as an open platform for infotainment, enabling rich innovation and differentiation in the in-vehicle digital experience. However, as vehicles modernize, car makers face new hurdles: fragmented software across compute components, poor portability between architectures, and a lack of granular update capabilities. To address these problems, we are expanding AAOS beyond infotainment with Android Automotive OS for Software Defined Vehicles (AAOS SDV)--an open platform featuring a modular structure, a topology-agnostic communication layer, and the support for granular updates. The transition toward SDVs is an incredible industry transformation, and we are eager to contribute to the broader ecosystem making it happen. Later this year, AAOS SDV will be available in the Android Open Source Project (AOSP) for uses beyond infotainment. By bringing our SDV platform into the open-source domain, we empower the industry to develop or enhance features that lower costs, accelerate time to market, and provide significant advantages across the automotive landscape. A Foundation for the Software-Defined Vehicle AAOS SDV is engineered to address the core challenges of modern vehicle development. This new AAOS expansion provides a compact, performant and scalable software foundation based on a headless Android native stack, extending much deeper into the vehicle architecture to power software components throughout the vehicle such as the seat actuator, instrument cluster, climate control, lighting, cameras, mirrors, telemetry, and more. AAOS SDV’s core is a lightweight Android-based operating system incorporating low-level automotive specific frameworks for communications, diagnostics, software updates, and more. This enables AAOS SDV to power many different vehicle controllers, tackling Core Compute, Body Controls, and Cluster domains. In addition, the AAOS SDV platform includes a new framework, Display Safety, for implementing instrument cluster applications including audible chimes, regulatory camera, and sophisticated graphics that blend seamlessly with AAOS IVI content. Display Safety includes a safety design toolchain and a reference safety monitor, allowing OEMs to meet functional safety requirements leveraging the diverse platform safety mechanisms of Automotive SoCs. Flexible Deployment for AAOS SDV Engineered for flexibility, the AAOS SDV framework can utilize hypervisor-backed virtualization with virtio support to separate software domains, or it can be deployed on bare metal for optimal low-latency performance. Transforming the Developer Experience AAOS SDV is designed to power modern vehicles, but it was also designed to change how modern vehicle software is developed, tested and delivered with the goals to reduce development time and cost while increasing innovation and agility. With its optimized development workflows, our open-source SDV platform provides a wide range of benefits across the automotive industry: Accelerated Time-to-Market: AAOS SDV components can accelerate development with production ready software for various components that can be further modified. Standard Signal Catalog: A new standard signal catalog to bring OEMs and automotive suppliers onto the same page eliminates redundant engineering efforts and significantly reduces platform development costs. Optimized for virtual cloud development: AAOS SDV was designed ground-up to support virtual cloud development - enabling partners to design, test and validate components in the car well ahead of hardware availability. AAOS SDV already runs on Android Virtual Device (Cuttlefish), and works well with existing Google Cloud integrations such as Google Cloud Horizon, enabling a digital twin solution at scale. A Service-Oriented Architecture: Vehicle functions are developed as topology-agnostic services which are reusable across different architectures. The platform treats the vehicle as a dynamic, connected system. This allows for granular, service-level updates with built-in dependency handling, enabling you to deploy new features over-the-air and create continuous improvement loops. Future-Ready for new services: The platform is designed to simplify the development of telemetry, AI training feedback loops, accelerating the deployment of advanced features for both enterprise fleets and consumer vehicles. Production Ready: Partnering with Renault We are proud to highlight our deep partnership with Renault to underscore the production readiness of the AAOS SDV platform. Renault is currently leveraging the Android Automotive OS SDV platform for its upcoming Renault Trafic e-Tech, “[...] production set to begin in late 2026”. The Renault Trafic e-Tech validates the platform's ability to accelerate development and enable a new generation of software-defined commercial vehicles. Scaling Ready: Partnering with Qualcomm Qualcomm is scaling the Android Automotive OS SDV platform through our strategic partnership. At CES 2026, Qualcomm introduced Snapdragon vSoC on Google Cloud and announced a scaling collaboration to deliver a turnkey, pre-integrated AAOS SDV stack on Snapdragon Digital Chassis platforms. Building an Open AAOS Ecosystem The power of AAOS comes from its vibrant ecosystem. To prepare for the open source release later this year, we are proactively working with leading industry carmakers, suppliers, silicon platforms, and software vendors to ensure that the AAOS SDV platform is well supported and robustly integrated within the automotive ecosystem. We look forward to sharing more updates with our partners in the months ahead.

3/19/2026

Posted by Matthew Forsythe, Director Product Management, Android App Safety Android proves you don't have to choose between an open ecosystem and a secure one. Since announcing updated verification requirements, we've worked with the community to ensure these protections are robust yet respectful of platform freedom. We've heard from power users that they want to take educated risks to install software from unverified developers. Today, we're sharing details on a new advanced flow that provides this option. Advanced flow safeguards against coercion Android is built on choice. That is why we’ve developed the advanced flow – an approach that allows power users to maintain the ability to sideload apps from unverified developers. This flow is a one-time process for power users – but it was designed carefully to prevent those in the midst of a scam attempt from being coerced by high pressure tactics to install malicious software. In these scenarios, scammers exploit fear – using threats of financial ruin, legal trouble, or harm to a loved one – to create a sense of extreme urgency. They stay on the phone with victims, coaching them to bypass security warnings and disable security settings before the victim has a chance to think or seek help. According to a 2025 report from the Global Anti-Scam Alliance (GASA), 57% of surveyed adults experienced a scam in the past year, resulting in a global consumer loss of $442 billion. Because the consequences of these scams that use sophisticated social engineering tactics are so severe, we have carefully engineered the advanced flow to provide the critical time and space needed to break the cycle of coercion. How the advanced flow works for users Enable developer mode in system settings: Activating this is simple. This prevents accidental triggers or "one-tap" bypasses often used in high-pressure scams. Confirm you aren't being coached: There is a quick check to make sure that no one is talking you into turning off your security. While power users know how to vet apps, scammers often pressure victims into disabling protections. Restart your phone and reauthenticate: This cuts off any remote access or active phone calls a scammer might be using to watch what you’re doing. Come back after the protective waiting period and verify: There is a one-time, one-day wait and then you can confirm that this is really you who’s making this change with our biometric authentication (fingerprint or face unlock) or device PIN. Scammers rely on manufactured urgency, so this breaks their spell and gives you time to think. Install apps: Once you confirm you understand the risks, you’re all set to install apps from unverified developers, with the option of enabling for 7 days or indefinitely. For safety, you’ll still see a warning that the app is from an unverified developer, but you can just tap “Install Anyway.” A secure Android for every developer We know a "one size fits all" approach doesn't work for our diverse ecosystem. We want to ensure that identity verification isn't a barrier to entry, so we’re providing different paths to fit your specific needs. In addition to the advanced flow we’re building free, limited distribution accounts for students and hobbyists. This allows you to share apps with a small group (up to 20 devices) without needing to provide a government-issued ID or pay a registration fee. This ensures Android remains an open platform for learning and experimentation while maintaining robust protections for the broader community. Limited distribution accounts and advanced flow for users will be available in August before the new developer verification requirements take effect. Visit our website for more details. We look forward to sharing more in the coming days and weeks.

3/16/2026

Posted by Ivy Knight, Senior Design Advocate, Android We're thrilled to announce major updates to our design resources, giving you the comprehensive guidance you need to create polished, adaptive Android apps across all form factors! We now have Desktop Experience guidance and a refreshed Android Design Gallery. New Desktop Experience Design Guidance Your users are engaging with Android apps on more diverse devices than ever before—from phones and foldables to laptops and external monitors. A "desktop experience" occurs anytime your app is in a desktop-like mode, typically involving a non-touch input device like a keyboard or mouse, or another display such as a monitor (read more in the connected display announcement). This means designing for larger screens and accommodating additional input states. These new design experiences are meant to maximize productivity for your users with higher information density, multi-tasking capabilities. Dive into desktop experience guidance to help optimize your app with desktop design principles, input interaction guidance, and system UI considerations. The new guidance includes foundational guides where you can learn design principles that make desktop experiences unique, such as how multitasking is at the core of desktop experiences. When your app is in a desktop experience, keep in mind crucial interaction experiences, such as how to best design around unique input interactions, like choosing cursors from system provided cursors. For specialized actions not covered by system icons, consider creating a custom cursor icon, while ensuring it remains easy for users to find on the page. A desktop experience brings more multitasking features, like windowing, so expect your app to take on a variety of dimensions with a header bar. Desktops have much larger screens than mobile, and users typically interact using a mouse which has finer precision than a finger on a touch screen. This means you can present a UI with higher information density so your users can be more productive! Want to get started quickly? Check out the walkthrough to go from mobile to desktop and design along with the updated Adaptive Design lab.  For more on criteria that makes a differentiated quality app, read the newly updated adaptive app quality guidelines and adaptive developer guidance. Introducing the Android Design Gallery Looking for inspiration? We've launched the Android Design Gallery! This new resource is a living catalog of inspirational examples across multiple verticals, form factors, and UX patterns. We'll be continually adding new inspirational examples, so check back often to see the latest and greatest in Android design.

3/13/2026

Posted by Daniel Santiago Rivera, Software Engineer The first alpha of Room 3.0 has been released! Room 3.0 is a major breaking version of the library that focuses on Kotlin Multiplatform (KMP) and adds support for JavaScript and WebAssembly (WASM) on top of the existing Android, iOS and JVM desktop support. In this blog we outline the breaking changes, the reasoning behind Room 3.0, and the various things you can do to migrate from Room 2.0. Breaking changes Room 3.0 includes the following breaking API changes: Dropping SupportSQLite APIs: Room 3.0 is fully backed by the androidx.sqlite driver APIs. The SQLiteDriver APIs are KMP-compatible and removing Room’s dependency on Android's API simplifies the API surface for Android since it avoids having two possible backends. No more Java code generation: Room 3.0 exclusively generates Kotlin code. This aligns with the evolving Kotlin-first paradigm but also simplifies the codebase and development process, enabling faster iterations. Focus on KSP: We are also dropping support for Java Annotation Processing (AP) and KAPT. Room 3.0 is solely a KSP (Kotlin Symbol Processing) processor, allowing for better processing of Kotlin codebases without being limited by the Java language. Coroutines first: Room 3.0 embraces Kotlin coroutines, making its APIs coroutine-first. Coroutines is the KMP-compatible asynchronous framework and making Room be asynchronous by nature is a critical requirement for supporting web platforms. A new package To prevent compatibility issues with existing Room 2.x implementations and for libraries with transitive dependencies to Room (for example, WorkManager), Room 3.0 resides in a new package which means it also has a new maven group and artifact ids. For example, androidx.room:room-runtime has become androidx.room3:room3-runtime and classes such as androidx.room.RoomDatabase will now be located at android.room3.RoomDatabase. Kotlin and Coroutines First With no more Java code generation, Room 3.0 also requires KSP and the Kotlin compiler even if the codebase interacting with Room is in Java. It is recommended to have a multi-module project where Room usage is concentrated and the Kotlin Gradle Plugin and KSP can be applied without affecting the rest of the codebase. Room 3.0 also requires Coroutines and more specifically DAO functions have to be suspending unless they are returning a reactive type, such as a Flow. Room 3.0 disallows blocking DAO functions. See the Coroutines on Android documentation on getting started integrating Coroutines into your application. Migration to SQLiteDriver APIs With the shift away from SupportSQLite, apps will need to migrate to the SQLiteDriver APIs. This migration is essential to leveraging the full benefits of Room 3.0, including allowing the use of the bundled SQLite library via the BundledSQLiteDriver. You can start migrating to the driver APIs today with Room 2.7.0+. We strongly encourage you to avoid any further usage of SupportSQLite. If you migrate your Room integrations to SQLiteDriver APIs, then the transition to Room 3.0 is easier since the package change mostly involves updating symbol references (imports) and might require minimal changes to call-sites. For a brief overview of the SQLiteDriver APIs, check out the SQLiteDriver APIs documentation. For more details on how to migrate Room to use SQLiteDriver APIs, check out the official documentation to migrate from SupportSQLite. Room SupportSQLite wrapper We understand completely removing SupportSQLite might not be immediately feasible for all projects. To ease this transition, Room 2.8.0, the latest version of the Room 2.0 series, introduced a new artifact called androidx.room:room-sqlite-wrapper. This artifact offers a compatibility API that allows you to convert a RoomDatabase into a SupportSQLiteDatabase, even if the SupportSQLite APIs in the database have been disabled due to a SQLiteDriver being installed. This provides a temporary bridge for developers who need more time to fully migrate their codebase. This artifact continues to exist in Room 3.0 as androidx.room3:room3-sqlite-wrapper to enable the migration to Room 3.0 while still supporting critical SupportSQLite usage. For example, invocations of Database.openHelper.writableDatabase can be replaced by roomDatabase.getSupportWrapper() and a wrapper would be provided even if setDriver() is called on Room’s builder. For more details check out the room-sqlite-wrapper documentation. Room and SQLite Web Support Support for the Kotlin Multiplatform targets JS and WasmJS and brings some of the most significant API changes. Specifically, many APIs in Room 3.0 are suspend functions since proper support for web storage is asynchronous. The SQLiteDriver APIs have also been updated to support the Web and a new web asynchronous driver is available in androidx.sqlite:sqlite-web. It is a Web Worker based driver that enables persisting the database in the Origin private file system (OPFS). For more details on how to set up Room for the Web check out the Room 3.0 release notes. Custom DAO Return Types Room 3.0 introduces the ability to add custom integrations to Room similar to RxJava and Paging. Through a new annotation API called @DaoReturnTypeConverter you can create your own integration such that Room’s generated code becomes accessible at runtime, this enables  @Dao functions having their custom return types without having to wait for the Room team to add the support. Existing integrations are migrated to use this functionality and thus will now require for those who rely on it to add the converters to the @Database or @Dao definitions. For example, the Paging converter will be located in the android.room3:room3-paging artifact and it's called PagingSourceDaoReturnTypeConverter. Meanwhile for LiveData the converter is in android.room3:room3-livedata and is called LiveDataReturnTypeConverter. For more details check out the DAO Return Type Converters section in the Room 3.0 release notes. Maintenance mode of Room 2.x Since the development of Room will be focused on Room 3, the current Room 2.x version enters maintenance mode. This means that no major features will be developed but patch releases (2.8.1, 2.8.2, etc.) will still occur with bug fixes and dependency updates. The team is committed to this work until Room 3 becomes stable. Final thoughts We are incredibly excited about the potential of Room 3.0 and the opportunities it unlocks for the Kotlin ecosystem. Stay tuned for more updates as we continue this journey!

3/13/2026

Posted by Ajesh R Pai, Developer Relations Engineer & Ben Trengrove, Developer Relations Engineer TikTok is a global short-video platform known for its massive user base and innovative features. The team is constantly releasing updates, experiments, and new features for their users. Faced with the challenge of maintaining velocity while managing technical debt, the TikTok Android team turned to Jetpack Compose. The team wanted to enable faster, higher-quality iteration of product requirements. By leveraging Compose, the team sought to improve engineering efficiency by writing less code and reducing cognitive load, while also achieving better performance and stability. Streamlining complex UI to accelerate developer productivity TikTok pages are often more complex than they appear, containing numerous layered conditional requirements. This complexity often resulted in difficult-to-maintain, sub-optimally structured View hierarchies and excessive View nesting, which caused performance degradation due to an increased number of measure passes. Compose offered a direct solution to this structural problem. Furthermore, Compose’s measurement strategy helps reduce double taxation, making measure performance easier to optimize.  To improve developer productivity, TikTok’s central Design System team provides a component library for teams working on different app features.  The team observed that Development in Compose is simple; leveraging small composables is highly effective, while incorporating large UI blocks with conditional logic is both straightforward and has minimal overhead. Building a path forward through strategic migration By strategically adopting Jetpack Compose, TikTok was able to stay on top of technical debt, while also continuing to focus on creating great experiences for their users. The ability of Compose to handle conditional logic cleanly and streamline composition allowed the team to achieve up to a 78% reduction in page loading time on new or fully rewritten pages. This improvement was 20–30% in smaller cases, and 70–80% for full rewrites and new features. They also were able to reduce their code size by 58%, when compared to the same feature built in Views. The team has further shared a couple of learnings:   TikTok team’s overall strategy was to incrementally migrate specific user journeys. This gave them an opportunity to migrate, confirm measurable benefits, then scale to more screens. They started with using Compose to simplify the overall structure in the QR code feature and saw the improvements. The team later expanded the migration to the Login and Sign-up experiences.  The team shared some additional learnings:   While checking performance during migration, the TikTok team found that using many small ComposeViews to replace elements inside a single ViewHolder, caused composition overhead. They achieved better results by expanding the migration to use one single ComposeView for the entire ViewHolder. When migrating a Fragment inside ViewPager, which has custom height logic and conditional logic to hide and show ui based on experiments, the performance wasn’t impacted. In this case, migrating the ViewPager to Composable performed better than migrating the Fragment.  Jun Shen really likes that Compose "reduces the amount of code required for feature development, improves testability, and accelerates delivery". The team plans to steadily increase Compose adoption, making it their preferred framework in the long term. Jetpack Compose proved to be a powerful solution for improving both their developer experience and production metrics at scale. Get Started with Jetpack Compose Learn more about how Jetpack Compose can help your team.

3/11/2026

Posted by Maru Ahues Bouza, PM Director, Games on Google Play Last September, we shared our vision for the future of Google Play Games grounded in a core belief: the best way to drive your game’s success is to deliver a world-class player experience. We launched the Google Play Games Level Up program to recognize and reward great gaming experiences, while providing you with a powerful toolkit and new promotional opportunities to grow your games.   The momentum since our announcement has been incredibly positive, with more than 600 million gamers now using Play Games Services every month. Developers are also finding success, with one-third of all game installs on the Play Store now coming from editorially-driven organic discovery. In fact, in 2025, Level Up features have driven over 2.5 billion incremental acquisitions for featured games, in addition to an average uplift of 25% in installs during the featuring windows.    Today, we're inviting you to start testing Play Games Sidekick to keep your players in the action, sharing new Play Console updates to optimize your reach, and helping you prepare for our upcoming program milestones. Boost retention and immersion with Play Games Sidekick Play Games Sidekick is a helpful in-game overlay that gives players instant access to relevant gaming information—like rewards, offers, achievements, and quest progress— keeping them immersed while driving higher engagement for developers.  It serves as a seamless bridge to the highly visible "You" tab, connecting your game to 160 million monthly active users already engaging there and doubles as an active gaming companion that enhances the player experience with helpful, AI-generated Game Tips. Deep Rock Galactic: Survivor keeps players in the action with Play Games Sidekick Today, Sidekick officially debuts in over 90 games, with the experience expanding to all Level Up titles later this year. But you don’t need to wait for the broader rollout to get your game ready. You can now enable Sidekick through Play Console to preview and test how your players will interact with features like Achievements, Streaks, Play Points Coupons, and Game Tips.  Upon completing your testing, be sure to push Sidekick for production to ensure your game meets the Level Up user experience guidelines.  Enable Play Games Sidekick in Play Console to begin testing Optimize reach and operations with new Play Console updates We are also rolling out two new Play Console updates to help you optimize your reach and streamline operations: Pre-reg device breakdowns: To aid launch decisions, you can now analyze the device distribution of your pre-registered audience by key device attributes including Android version, RAM and SoC. This enables you to optimize game performance, minimum specs, and marketing spend for the players already waiting for your game. Identify launch-day risks and optimize performance for your players with new pre-registration device breakdowns Real-time feedback:  With Level Up+, our tier for high-performing games, qualifying titles can unlock promotional content featuring and tools like deep-links and audience targeting. While submissions must meet Play’s quality guidelines, you no longer have to wait 24 hours to learn about issues. You can now get immediate feedback on quality whenever possible. Your 2026 checklist: Securing your Level Up benefits Today, all games on Google Play qualify for Google Play Games Level Up. However, in order to maintain access to Level Up benefits like Play Points offers, expanded APK size limits, Play Store collections and campaigns consideration, or access to high-visibility surfaces like You tab and Sidekick, you’ll need to ensure your game meets user experience guidelines by their upcoming milestones:  By July 2026:  Integrate Play Games Sidekick to offer a quick and easy entry point to access rewards, offers, and achievements through an in-game overlay. Implement achievements with Play Games Services, to support authentication with the modern Gamer Profile, and to keep players engaged across the lifespan of your game.   By November 2026: Implement cloud save to enable progress sync across devices. Last week, we announced that we’re working on an expanded Level Up program that builds on our successful foundation to further improve gaming experiences. The update will introduce new requirements that will unlock additional benefits like lower service fees. Engaging with the program now ensures your work is strategically aligned with these future updates. We’ll share more details in the coming months. In the meantime, the path to your first program milestone begins today. By prioritizing these user experience guidelines now, you’re investing in the long-term value of your game and ensuring it’s built to thrive for every player. Head over to Play Console to start testing Sidekick and take the next step in your Level Up journey.

3/11/2026

Posted by Aurash Mahbod, VP and GM, Games on Google Play Google Play is proud to be the home of over 200,000 games—many of which defined the mobile-first era. But as cross-platform becomes the standard for players, we are evolving our ecosystem to match the scale of your ambitions. In recent years, we focused on elevating Android gaming quality while significantly deepening our support for native PC titles. We know that maximizing your game’s reach across different platforms is complex. The Level Up program serves as your strategic roadmap, helping you prioritize optimizations that drive great experiences on Android. Building on this foundation, we’re doubling down on our investment to make Play the most accessible home for every category of play. We’re adding new tools for paid games and making the PC game discovery to purchase seamless. Keep reading to learn more about how we’re creating a bigger stage for your games. Scale your discovery across mobile and PC platforms Building a bigger stage starts with making your games easier to find—and easier to buy—no matter which device your players prefer. We’re expanding your reach by bringing cross-platform discovery directly to the mobile storefront.  With the new PC section in the Games tab, your PC titles gain high visibility placement among our most active mobile players.  The PC badge ensures your cross-platform investment is recognized. This creates more opportunities to acquire players on mobile and transition them seamlessly to your high-fidelity PC experience. PC in the Games tab and PC badging expands your game’s reach With ‘buy once play anywhere’ pricing, we’re making it easier to sell your games across different devices.  If you choose to opt-in your mobile game for Google Play Games on PC, you can now offer a single price that covers both mobile and PC versions. We’re rolling out this feature in EAP with select games including Brotato: Premium.  For PC-only games, players can now complete the full purchase journey on Google Play Games on PC with the same trusted security and privacy standards they expect from Google Play.  'Buy once play anywhere’ pricing to sell your games across devices Lower the purchase barrier with Game Trials  To help you convert high-intent buyers with less friction, we’re introducing Game Trials, a feature that enables players to experience your game for a limited time before making a purchase on mobile. Accessible directly from your game’s store listing, Game Trials provides a fast-track for players to start exploring your world with a single tap. Game trials are now in testing with select titles and we’ll roll it out to more titles soon.  To ensure this is low maintenance for you, Game Trials is added directly into your Android App Bundle. This enables you to offer a high quality trial without the burden of a separate codebase or a demo version of your app.  Play ensures trials are secure and seamless. Game Trials are once per user and protects your game while the trial is active. When it ends, players can purchase your game and keep their progress.  We’re also working on tools that will give you more control—such as specifying a custom time limit or an in-game event to conclude the trial.  Game Trial for DREDGE to help convert high-intent buyers Diversify your revenue with a dedicated player community on Play Pass Play Pass is another way to diversify revenue and grow your player audience. It has been a strong launchpad for indie hits such as Isle of Arrows, Slay the Spire, and Dead Cells. With Play Pass, you can reach highly dedicated players seeking a more curated gaming experience, free of ads and in-app purchases. To help you deepen engagement, paid titles on Play Pass can now opt in to Google Play Games on PC — making it easy for players to find and play your games on a larger screen. Later this year, you can nominate your game through a streamlined opt-in process directly in Play Console.    Drive long term sales with Wishlists and Discounts Wishlists and Discounts are one of the most effective ways to capture player intent and drive long term sales. To support players at every stage of their purchase journey, we’re integrating them directly into Play. Players can save titles to their wishlist and manage them from library settings. To keep your game top-of-mind, players will receive automated notifications for your latest discounts — starting with mobile and expanding soon to PC games.  Wishlist and discount notifications drives long term sales, rolling out today How leading studios are finding a new path to success on Play We’re thrilled to welcome Sledding Game, 9 Kings, Potion Craft, Moonlight Peaks, and Low Budget Repairs to Play [1]. It marks an exciting expansion of our catalog and a step forward in our mission to build a bigger gaming ecosystem for all developers. This growth is fueled by our developer community, whose feedback continues to shape our roadmap and help us better support your success. Sledding Game, 9 Kings, Potion Craft, Moonlight Peaks, and Low Budget Repairs is coming to Play. That mission brings us to GDC and the Independent Games Festival (IGF) Awards [2], where the next generation of games awaits! This year, we’re inviting you to come along for the ride as we go backstage to chat with the finalists and winners, sharing the moments of triumph and the creative stories behind their development. Not joining us at GDC? You can take the next step in your journey to launch your game on Google Play today. 1. Sledding Game, 9 Kings, Potion Craft, and Moonlight Peaks are coming to Google Play in 2026. Low Budget Repairs is scheduled for release in 2027. [Back] 2. Independent Games Festival (IGF) Awards is hosted by Game Developers Conference (GDC) and requires a valid GDC pass for entry. [Back]

3/10/2026

Posted by Yabin Cui, Software Engineer We are the Android LLVM toolchain team. One of our top priorities is to improve Android performance through optimization techniques in the LLVM ecosystem. We are constantly searching for ways to make Android faster, smoother, and more efficient. While much of our optimization work happens in userspace, the kernel remains the heart of the system. Today, we’re excited to share how we are bringing Automatic Feedback-Directed Optimization (AutoFDO) to the Android kernel to deliver significant performance wins for users. What is AutoFDO? During a standard software build, the compiler makes thousands of small decisions, such as whether to inline a function and which branch of a conditional is likely to be taken, based on static code hints.While these heuristics are useful, they don't always accurately predict code execution during real-world phone usage. AutoFDO changes this by using real-world execution patterns to guide the compiler. These patterns represent the most common instruction execution paths the code takes during actual use, captured by recording the CPU's branching history. While this data can be collected from fleet devices, for the kernel we synthesize it in a lab environment using representative workloads, such as running the top 100 most popular apps. We use a sampling profiler to capture this data, identifying which parts of the code are 'hot' (frequently used) and which are 'cold'. When we rebuild the kernel with these profiles, the compiler can make much smarter optimization decisions tailored to actual Android workloads. To understand the impact of this optimization, consider these key facts: On Android, the kernel accounts for about 40% of CPU time. We are already using AutoFDO to optimize native executables and libraries in the userspace, achieving about 4% cold app launch improvement and a 1% boot time reduction. Real-World Performance Wins We have seen impressive improvements across key Android metrics by leveraging profiles from controlled lab environments. These profiles were collected using app crawling and launching, and measured on Pixel devices across the 6.1, 6.6, and 6.12 kernels. The most noticeable improvements are listed below. Details on the AutoFDO profiles for these kernel versions can be found in the respective Android kernel repositories for android16-6.12 and android15-6.6 kernels. These aren't just theoretical numbers. They translate to a snappier interface, faster app switching, extended battery life, and an overall more responsive device for the end user. How It Works: The Pipeline Our deployment strategy involves a sophisticated pipeline to ensure profiles stay relevant and performance remains stable. Step 1: Profile Collection While we rely on our internal test fleet to profile userspace binaries, we shifted to a controlled lab environment for the Generic Kernel Image (GKI). Decoupling profiling from the device release cycle allows for flexible, immediate updates independent of deployed kernel versions. Crucially, tests confirm that this lab-based data delivers performance gains comparable to those from real-world fleets. Tools & Environment: We flash test devices with the latest kernel image and use simpleperf to capture instruction execution streams. This process relies on hardware capabilities to record branching history, specifically utilizing ARM Embedded Trace Extension (ETE) and ARM Trace Buffer Extension (TRBE) on Pixel devices. Workloads: We construct a representative workload using the top 100 most popular apps from the Android App Compatibility Test Suite (C-Suite). To capture the most accurate data, we focus on: App Launching: Optimizing for the most visible user delays AI-Driven App Crawling: Simulating contiguous, evolving user interactions System-Wide Monitoring: Capturing not only foreground app activities, but also critical background workloads and inter-process communications Validation: This synthesized workload shows an 85% similarity to execution patterns collected from our internal fleet. Targeted Data: By repeating these tests sufficiently, we capture high-fidelity execution patterns that accurately represent real-world user interaction with the most popular applications. Furthermore, this extensible framework allows us to seamlessly integrate additional workloads and benchmarks to broaden our coverage. Step 2: Profile Processing We post-process the raw trace data to ensure it is clean, effective, and ready for the compiler. Aggregation: We consolidate data from multiple test runs and devices into a single system view. Conversion: We convert raw traces into the AutoFDO profile format, filtering out unwanted symbols as needed. Profile Trimming: We trim profiles to remove data for "cold" functions, allowing them to use standard optimization. This prevents regressions in rarely used code and avoids unnecessary increases in binary size. Step 3: Profile Testing Before deployment, profiles undergo rigorous verification to ensure they deliver consistent performance wins without stability risks. Profile & Binary Analysis: We strictly compare the new profile's content (including hot functions, sample counts, and profile size) against previous versions. We also use the profile to build a new kernel image, analyzing binaries to ensure that changes to the text section are consistent with expectations. Performance Verification: We run targeted benchmarks on the new kernel image. This confirms that it maintains the performance improvements established by previous baselines. Continuous Updates Code naturally "drifts" over time, so a static profile would eventually lose its effectiveness. To maintain peak performance, we run the pipeline continuously to drive regular updates: Regular Refresh: We refresh profiles in Android kernel LTS branches ahead of each GKI release, ensuring every build includes the latest profile data. Future Expansion: We are currently delivering these updates to the android16-6.12 and android15-6.6 branches and will expand support to newer GKI versions, such as the upcoming android17-6.18. Ensuring Stability A common question with profile-guided optimization is whether it introduces stability risks. Because AutoFDO primarily influences compiler heuristics, such as function inlining and code layout, rather than altering the source code's logic, it preserves the functional integrity of the kernel. This technology has already been proven at scale, serving as a standard optimization for Android platform libraries, ChromeOS, and Google’s own server infrastructure for years. To further guarantee consistent behavior, we apply a "conservative by default" strategy. Functions not captured in our high-fidelity profiles are optimized using standard compiler methods. This ensures that the "cold" or rarely executed parts of the kernel behave exactly as they would in a standard build, preventing performance regressions or unexpected behaviors in corner cases. Looking Ahead We are currently deploying AutoFDO across the android16-6.12 and android15-6.6 branches. Beyond this initial rollout, we see several promising avenues to further enhance the technology: Expanded Reach: We look forward to deploying AutoFDO profiles to newer GKI kernel versions and additional build targets beyond the current aarch64 support. GKI Module Optimization: Currently, our optimization is focused on the main kernel binary (vmlinux). Expanding AutoFDO to GKI modules could bring performance benefits to a larger portion of the kernel subsystem. Vendor Module Support: We are also interested in supporting AutoFDO for vendor modules built using the Driver Development Kit (DDK). With support already available in our build system (Kleaf) and profiling tools (simpleperf), this allows vendors to apply these same optimization techniques to their specific hardware drivers. Broader Profile Coverage: There is potential to collect profiles from a wider range of Critical User Journeys (CUJs) to optimize them. By bringing AutoFDO to the Android kernel, we’re ensuring that the very foundation of the OS is optimized for the way you use your device every day.

3/5/2026

Posted by Mayuri Khinvasara Khabya, Developer Relations Engineer (LinkedIn and X) In the dynamic world of social media, user attention is won or lost quickly. Meta apps (Facebook and Instagram) are among the world's largest social platforms and serve billions of users globally. For Meta, delivering videos seamlessly isn't just a feature, it's the core of their user experience. Short-form videos, particularly Facebook Newsfeed and Instagram Reels, have become a primary driver of engagement. They enable creative expression and rapid content consumption; connecting and entertaining people around the world.  This blog post takes you through the journey of how Meta transformed video playback for billions by delivering true instant playback. The latency gap in short form videos Short-form videos lead to highly fast paced interactions as users quickly scroll through their feeds. Delivering a seamless transition between videos in an ever-changing feed introduces unique hurdles for instantaneous playback. Hence we need solutions that go beyond traditional disk caching and standard reactive playback strategies. The path forward with Media3 PreloadManager To address the shifts in consumption habits from rise in short form content and the limitations of traditional long form playback architecture, Jetpack Media3 introduced PreloadManager. This component allows developers to move beyond disk caching, offering granular control and customization to keep media ready in memory before the user hits play. Read this blog series to understand technical details about media playback with PreloadManager. How Meta achieved true instant playback Existing Complexities Previously, Meta used a combination of warmup (to get players ready) and prefetch (to cache content on disk) for video delivery. While these methods helped improve network efficiency, they introduced significant challenges. Warmup required instantiating multiple player instances sequentially, which consumed significant memory and limited preloading to only a few videos. This high resource demand meant that a more scalable robust solution could be applied to deliver the instant playback expected on modern, fast-scrolling social feeds. Integrating Media3 PreloadManager To achieve truly instant playback, Meta's Media Foundation Client team integrated the Jetpack Media3 PreloadManager into Facebook and Instagram. They chose the DefaultPreloadManager to unify their preloading and playback systems. This integration required refactoring Meta's existing architecture to enable efficient resource sharing between the PreloadManager and ExoPlayer instances. This strategic shift provided a key architectural advantage: the ability to parallelize preloading tasks and manage many videos using a single player instance. This dramatically increased preloading capacity while eliminating the high memory complexities of their previous approach. Optimization and Performance Tuning The team then performed extensive testing and iterations to optimize performance across Meta's diverse global device ecosystem. Initial aggressive preloading sometimes caused issues, including increased memory usage and scroll performance slowdowns. To solve this, they fine-tuned the implementation by using careful memory measurements, considering device fragmentation, and tailoring the system to specific UI patterns. Fine tuning implementation to specific UI patterns Meta applied different preloading strategies and tailored the behavior to match the specific UI patterns of each app: Facebook Newsfeed: The UI prioritizes the video currently coming into view. The manager preloads only the current video to ensure it starts the moment the user pauses their scroll. This "current-only" focus minimizes data and memory footprints in an environment where users may see many static posts between videos. While the system is presently designed to preload just the video in view, it can be adjusted to also preload upcoming (future) videos.  Instagram Reels: This is a pure video environment where users swipe vertically. For this UI, the team implemented an "adjacent preload" strategy. The PreloadManager keeps the videos immediately after the current Reel ready in memory. This bi-directional approach ensures that whether a user swipes up or down, the transition remains instant and smooth. The result was a dramatic improvement in the Quality of Experience (QoE) including improvements in Playback Start and Time to First Frame for the user. Scaling for a diverse global device ecosystem Scaling a high-performance video stack across billions of devices requires more than just aggressive preloading; it requires intelligence. Meta faced initial challenges with memory pressure and scroll lag, particularly on mid-to-low-end hardware. To solve this, they built a Device Stress Detection system around the Media3 implementation. The apps now monitor I/O and CPU signals in real-time. If a device is under heavy load, preloading is paused to prioritize UI responsiveness. This device-aware optimization ensures that the benefit of instant playback doesn't come at the cost of system stability, allowing even users on older hardware to experience a smoother, uninterrupted feed. Architectural wins and code health Beyond the user-facing metrics, the migration to Media3 PreloadManageroffered long-term architectural benefits. While the integration and tuning process needed multiple iterations to balance performance, the resulting codebase is more maintainable. The team found that the PreloadManager API integrated cleanly with the existing Media3 ecosystem, allowing for better resource sharing. For Meta, the adoption of Media3 PreloadManager was a strategic investment in the future of video consumption.  By adopting preloading and adding device-intelligent gates, they successfully increased total watch time on their apps and improved the overall engagement of their global community.  Resulting impact on Instagram and Facebook The proactive architecture delivered immediate and measurable improvements across both platforms.  Facebook experienced faster playback starts, decreased playback stall rates and a reduction in bad sessions (like rebuffering, delayed start time, lower quality,etc) which overall resulted in higher watch time.  Instagram saw faster playback starts and an increase in total watch time. Eliminating join latency (the interval from the user's action to the first frame display) directly increased engagement metrics. The fewer interruptions due to reduced buffering meant users watched more content, which showed through engagement metrics. Key engineering learnings at scale As media consumption habits evolve, the demand for instant experiences will continue to grow. Implementing proactive memory management and optimizing for scale and device diversity ensures your application can meet these expectations efficiently. Prioritize intelligent preloading Focus on delivering a reliable experience by minimizing stutters and loading times through preloading. Rather than simple disk caching, leveraging memory-level preloading ensures that content is ready the moment a user interacts with it. Align your implementation with UI patterns Customize preloading behavior as per your apps’s UI. For example, use a "current-only" focus for mixed feeds like Facebook to save memory, and an "adjacent preload" strategy for vertical environments like Instagram Reels. Leverage Media3 for long-term code health Integrating with Media3 APIs rather than a custom caching solution allows for better resource sharing between the player and the PreloadManager, enabling you to manage multiple videos with a single player instance. This results in a future-proof codebase that is easier for engineering teams to not only maintain and optimize over time but also benefit from the latest feature updates. Implement device aware optimizations Broaden your market reach by testing on various devices, including mid-to-low-end models. Use real-time signals like CPU, memory, and I/O to adapt features and resource usage dynamically. Learn More To get started and learn more, visit  Explore the Media3 PreloadManager documentation. Read the blog series for advanced technical and implementation details. Part 1: Introducing Preloading with Media3 Part 2: A deep dive into Media3's PreloadManager Check out the sample app to see preloading in action. Now you know the secrets for instant playback. Go try them out!

3/5/2026

Posted by Matthew McCullough, VP of Product Management, Android Developer We want to make it faster and easier for you to build high-quality Android apps, and one way we’re helping you be more productive is by putting AI at your fingertips. We know you want AI that truly understands the nuances of the Android platform, which is why we’ve been measuring how LLMs perform Android development tasks. Today we released the first version of Android Bench, our official leaderboard of LLMs for Android development. Our goal is to provide model creators with a benchmark to evaluate LLM capabilities for Android development. By establishing a clear, reliable baseline for what high quality Android development looks like, we’re helping model creators identify gaps and accelerate improvements—which empowers developers to work more efficiently with a wider range of helpful models to choose for AI assistance—which ultimately will lead to higher quality apps across the Android ecosystem. Designed with real-world Android development tasks We created the benchmark by curating a task set against a range of common Android development areas. It is composed of real challenges of varying difficulty, sourced from public GitHub Android repositories. Scenarios include resolving breaking changes across Android releases, domain-specific tasks like networking on wearables, and migrating to the latest version of Jetpack Compose, to name a few. Each evaluation attempts to have an LLM fix the issue reported in the task, which we then verify using unit or instrumentation tests. This model-agnostic approach allows us to measure a model’s ability to navigate complex codebases, understand dependencies, and solve the kind of problems you encounter every day.  We validated this methodology with several LLM makers, including JetBrains. “Measuring AI’s impact on Android is a massive challenge, so it’s great to see a framework that’s this sound and realistic. While we’re active in benchmarking ourselves, Android Bench is a unique and welcome addition. This methodology is exactly the kind of rigorous evaluation Android developers need right now.”   - Kirill Smelov, Head of AI Integrations at JetBrains. The first Android Bench results For this initial release, we wanted to purely measure model performance and not focus on agentic or tool use. The models were able to successfully complete 16-72% of the tasks. This is a wide range that demonstrates some LLMs already have a strong baseline for Android knowledge, while others have more room for improvement. Regardless of where the models are at now, we’re anticipating continued improvement as we encourage LLM makers to enhance their models for Android development.  The LLM with the highest average score for this first release is Gemini 3.1 Pro, followed closely by Claude Opus 4.6. You can try all of the models we evaluated for AI assistance for your Android projects by using API keys in the latest stable version of Android Studio. Providing developers and LLM makers with transparency We value an open and transparent approach, so we made our methodology, dataset, and test harness publicly available on GitHub. One challenge for any public benchmark is the risk of data contamination, where models may have seen evaluation tasks during their training process. We have taken measures to ensure our results reflect genuine reasoning rather than memorization or guessing, including a thorough manual review of agent trajectories, or the integration of a canary string to discourage training.  Looking ahead, we will continue to evolve our methodology to preserve the integrity of the dataset, while also making improvements for future releases of the benchmark—for example, growing the quantity and complexity of tasks. We’re looking forward to how Android Bench can improve AI assistance long-term. Our vision is to close the gap between concept and quality code. We're building the foundation for a future where no matter what you imagine, you can build it on Android.

3/5/2026

Posted by Alice Yuan, Senior Developer Relations Engineer In recognition that excessive battery drain is top of mind for Android users, Google has been taking significant steps to help developers build more power-efficient apps. On March 1st, 2026, Google Play Store began rolling out the wake lock technical quality treatments to improve battery drain. This treatment will roll out gradually to impacted apps over the following weeks. Apps that consistently exceed the "Excessive Partial Wake Lock" threshold in Android vitals may see tangible impacts on their store presence, including warnings on their store listing and exclusion from discovery surfaces such as recommendations. Users may see a warning on your store listing if your app exceeds the bad behavior threshold. This initiative elevated battery efficiency to a core vital metric alongside stability metrics like crashes and ANRs. The "bad behavior threshold" is defined as holding a non-exempted partial wake lock for at least two hours on average while the screen is off in more than 5% of user sessions in the past 28 days. A wake lock is exempted if it is a system held wake lock that offers clear user benefits that cannot be further optimized, such as audio playback, location access, or user-initiated data transfer. You can view the full definition of excessive wake locks in our Android vitals documentation. As part of our ongoing initiative to improve battery life across the Android ecosystem, we have analyzed thousands of apps and how they use partial wake locks. While wake locks are sometimes necessary, we often see apps holding them inefficiently or unnecessarily, when more efficient solutions exist. This blog will go over the most common scenarios where excessive wake locks occur and our recommendations for optimizing wake locks.  We have already seen measurable success from partners like WHOOP, who leveraged these recommendations to optimize their background behavior. Using a foreground service vs partial wake locks We’ve often seen developers struggle to understand the difference between two concepts when doing background execution: foreground service and partial wake locks. A foreground service is a lifecycle API that signals to the system that an app is performing user-perceptible work and should not be killed to reclaim memory, but it does not automatically prevent the CPU from sleeping when the screen turns off. In contrast, a partial wake lock is a mechanism specifically designed to keep the CPU running even while the screen is off.  While a foreground service is often necessary to continue a user action, a manual acquisition of a partial wake lock is only necessary in conjunction with a foreground service for the duration of the CPU activity. In addition, you don't need to use a wake lock if you're already utilizing an API that keeps the device awake.  Refer to the flow chart in Choose the right API to keep the device awake to ensure you have a strong understanding of what tool to use to avoid acquiring a wake lock in scenarios where it’s not necessary. Third party libraries acquiring wake locks It is common for an app to discover that it is flagged for excessive wake locks held by a third-party SDK or system API acting on its behalf. To identify and resolve these wake locks, we recommend the following steps: Check Android vitals: Find the exact name of the offending wake lock in the excessive partial wake locks dashboard. Cross-reference this name with the Identify wake locks created by other APIs guidance to see if it was created by a known system API or Jetpack library. If it is, you may need to optimize your usage of the API and can refer to the recommended guidance. Capture a System Trace: If the wake lock cannot be easily identified, reproduce the wake lock issue locally using a system trace and inspect it with the Perfetto UI. You can learn more about how to do this in the Debugging other types of excessive wake locks section of this blog post. Evaluate Alternatives: If an inefficient third-party library is responsible and cannot be configured to respect battery life, consider communicating the issue with the SDK's owners, finding an alternative SDK or building the functionality in-house. Common wake lock scenarios Below is a breakdown of some of the specific use cases we have reviewed, along with the recommended path to optimize your wake lock implementation. User-Initiated Upload or Download Example use cases:  Video streaming apps where the user triggers a download of a large file for offline access. Media backup apps where the user triggers uploading their recent photos via a notification prompt. How to reduce wake locks:  Do not acquire a manual wake lock. Instead, use the User-Initiated Data Transfer (UIDT) API. This is the designated path for long running data transfer tasks initiated by the user, and it is exempted from excessive wake lock calculations. One-Time or Periodic Background Syncs Example use cases:  An app performs periodic background syncs to fetch data for offline access.  Pedometer apps that fetch step count periodically. How to reduce wake locks:  Do not acquire a manual wake lock. Use WorkManager configured for one-time or periodic work.  WorkManager respects system health by batching tasks and has a minimum periodic interval (15 minutes), which is generally sufficient for background updates.  If you identify wake locks created by WorkManager or JobScheduler with high wake lock usage, it may be because you’ve misconfigured your worker to not complete in certain scenarios. Consider analyzing the worker stop reasons, particularly if you’re seeing high occurrences of STOP_REASON_TIMEOUT. workManager.getWorkInfoByIdFlow(syncWorker.id) .collect { workInfo -> if (workInfo != null) { val stopReason = workInfo.stopReason logStopReason(syncWorker.id, stopReason) } } In addition to logging worker stop reasons, refer to our documentation on debugging your workers. Also, consider collecting and analyzing system traces to understand when wake locks are acquired and released. Finally, check out our case study with WHOOP, where they were able to discover an issue with configuration of their workers and reduce their wake lock impact significantly. Bluetooth Communication Example use cases:  Companion device app prompts the user to pair their Bluetooth external device. Companion device app listens for hardware events on an external device and user visible change in notification. Companion device app’s user initiates a file transfer between the mobile and bluetooth device. Companion device app performs occasional firmware updates to an external device via Bluetooth. How to reduce wake locks:  Use companion device pairing to pair Bluetooth devices to avoid acquiring a manual wake lock during Bluetooth pairing.  Consult the Communicate in the background guidance to understand how to do background Bluetooth communication.  Using WorkManager is often sufficient if there is no user impact to a delayed communication. If a manual wake lock is deemed necessary, only hold the wake lock for the duration of Bluetooth activity or processing of the activity data. Location Tracking Example use cases:  Fitness apps that cache location data for later upload such as plotting running routes Food delivery apps that pull location data at a high frequency to update progress of delivery in a notification or widget UI. How to reduce wake locks:  Consult our guidance to Optimize location usage. Consider implementing timeouts, leveraging location request batching, or utilizing passive location updates to ensure battery efficiency. When requesting location updates using the FusedLocationProvider or LocationManager APIs, the system automatically triggers a device wake-up during the location event callback. This brief, system-managed wake lock is exempted from excessive partial wake lock calculations. Avoid acquiring a separate, continuous wake lock for caching location data, as this is redundant. Instead, persist location events in memory or local storage and leverage WorkManager to process them at periodic intervals. override fun onCreate(savedInstanceState: Bundle?) { locationCallback = object : LocationCallback() { override fun onLocationResult(locationResult: LocationResult?) { locationResult ?: return // System wakes up CPU for short duration for (location in locationResult.locations){ // Store data in memory to process at another time } } } } High Frequency Sensor Monitoring Example use cases:  Pedometer apps that passively collect steps, or distance traveled.  Safety apps that monitor the device sensors for rapid changes in real time, to provide features such as crash detection or fall detection. How to reduce wake locks:  If using SensorManager, reduce usage to periodic intervals and only when the user has explicitly granted access through a UI interaction. High frequency sensor monitoring can drain the battery heavily due to the number of CPU wake-ups and processing that occurs. If you’re tracking step counts or distance traveled, rather than using SensorManager, leverage Recording API or consider utilizing Health Connect to access historical and aggregated device step counts to capture data in a battery-efficient manner. If you’re registering a sensor with SensorManager, specify a maxReportLatencyUs of 30 seconds or more to leverage sensor batching to minimize the frequency of CPU interrupts. When the device is subsequently woken by another trigger such as a user interaction, location retrieval, or a scheduled job, the system will immediately dispatch the cached sensor data. val accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER) sensorManager.registerListener(this, accelerometer, samplingPeriodUs, // How often to sample data maxReportLatencyUs // Key for sensor batching ) If your app requires both location and sensor data, synchronize their event retrieval and processing. By piggybacking sensor readings onto the brief wake lock the system holds for location updates, you avoid needing a wake lock to keep the CPU awake. Use a worker or a short-duration wake lock to handle the upload and processing of this combined data. Remote Messaging Example use cases:  Video or sound monitoring companion apps that need to monitor events that occur on an external device connected using a local network. Messaging apps that maintain a network socket connection with the desktop variant. How to reduce wake locks:  If the network events can be processed on the server side, use FCM to receive information on the client. You may choose to schedule an expedited worker if additional processing of FCM data is required.  If events must be processed on the client side via a socket connection, a wake lock is not needed to listen for event interrupts. When data packets arrive at the Wi-Fi or Cellular radio, the radio hardware triggers a hardware interrupt in the form of a kernel wake lock. You may then choose to schedule a worker or acquire a wake lock to process the data. For example, if you’re using ktor-network to listen for data packets on a network socket, you should only acquire a wake lock when packets have been delivered to the client and need to be processed. val readChannel = socket.openReadChannel() while (!readChannel.isClosedForRead) { // CPU can safely sleep here while waiting for the next packet val packet = readChannel.readRemaining(1024) if (!packet.isEmpty) { // Data Arrived: The system woke the CPU and we should keep it awake via manual wake lock (urgent) or scheduling a worker (non-urgent) performWorkWithWakeLock { val data = packet.readBytes() // Additional logic to process data packets } } } Summary By adopting these recommended solutions for common use cases like background syncs, location tracking, sensor monitoring and network communication, developers can work towards reducing unnecessary wake lock usage. To continue learning, read our other technical blog post or watch our technical video on how to discover and debug wake locks: Optimize your app battery using Android vitals wake lock metric. Also, consult our updated wakelock documentation. To help us continue improving our technical resources, please share any additional feedback on our guidance in our documentation feedback survey.

3/4/2026

Posted by Breana Tate, Developer Relations Engineer, Mayank Saini, Senior Android Engineer, Sarthak Jagetia, Senior Android Engineer and Manmeet Tuteja, Android Engineer II Building an Android app for a wearable means the real work starts when the screen turns off. WHOOP helps members understand how their body responds to training, recovery, sleep, and stress, and for the many WHOOP members on Android, reliable background syncing and connectivity are what make those insights possible. Earlier this year, Google Play released a new metric in Android vitals: Excessive partial wake locks. This metric measures the percentage of user sessions where cumulative, non-exempt wake lock usage exceeds 2 hours in a 24-hour period. The aim of this metric is to help you identify and address possible sources of battery drain, which is crucial for delivering a great user experience. Beginning March 1, 2026, apps that continue to not meet the quality threshold may be excluded from Google Play discovery surfaces. A warning may also be placed on the Google Play Store listing, indicating the app might use more battery than expected. According to Mayank Saini, Senior Android Engineer at WHOOP,  this “presented the team with an opportunity to raise the bar on Android efficiency,” after Android vitals flagged the app’s excessive partial wake lock % as 15%—which exceeded the recommended 5% threshold. The team viewed the Android vitals metric as a clear signal that their background work was holding the CPU awake longer than necessary. Resolving this would allow them to continue to deliver a great user experience while simultaneously decreasing wasted background time and maintaining reliable and timely Bluetooth connectivity and syncing. Identifying the issue To figure out where to get started, the team first turned to Android vitals for more insight into which wake locks were affecting the metric. By consulting the Android vitals excessive partial wake locks dashboard, they were able to identify the biggest contributor to excessive partial wake locks as one of their WorkManager workers (identified in the dashboard as androidx.work.impl.background.systemjob.SystemJobService). To support the WHOOP “always-on experience”, the app uses WorkManager for background tasks like periodic syncing and delivering recurring updates to the wearable.  While the team was aware that WorkManager acquires a wake lock while executing tasks in the background, they previously did not have visibility into how all of their background work (beyond just WorkManager) was distributed until the introduction of the excessive partial wake locks metric in Android vitals. With the dashboard identifying WorkManager as the main contributor, the team was then able to focus their efforts on identifying which of their workers was contributing the most and work towards resolving the issue. Making use of internal metrics and data to better narrow down the cause WHOOP already had internal infrastructure set up to monitor WorkManager metrics. They periodically monitor: Average Runtime: For how long does the worker run? Timeouts: How often is the worker timing out instead of completing? Retries: How often does the worker retry if the work timed out or failed? Cancellations: How often was the work cancelled? Tracking more than just worker successes and failures gives the team visibility into their work’s efficiency. The internal metrics flagged high average runtime for a select few workers, enabling them to narrow the investigation down even further.  In addition to their internal metrics, the team also used Android Studio’s Background Task Inspector to inspect and debug the workers of interest, with a specific focus on associated wake locks, to align with the metric flagged in Android vitals. Investigation: Distinguishing between worker variants WHOOP uses both one-time and periodic scheduling for some workers. This allows the app to reuse the same Worker logic for identical tasks with the same success criteria, differing only in timing. Using their internal metrics made it possible to narrow their search to a specific worker, but they couldn't tell if the bug occurred when the worker was one-time, periodic, or both. So, they rolled out an update to use WorkManager’s setTraceTag method to distinguish between the one-time and periodic variants of the same Worker. This extra detail would allow them to definitively identify which Worker variant (periodic or one-time) was contributing the most to sessions with excessive partial wake locks. However, the team was surprised when the data revealed that neither variant appeared to be contributing more than the other. Manmeet Tuteja, Android Engineer II at WHOOP said “that split also helped us confirm the issue was happening in both variants, which pointed away from scheduling configuration and toward a shared business logic problem inside the worker implementation.” Diving deeper on worker behavior and fixing the root cause With the knowledge that they needed to take a look at logic within the worker,  the team re-examined worker behavior for the workers that had been flagged during their investigation. Specifically, they were looking for instances in which work may have been getting stuck and not completing. All of this culminated in finding the root cause of the excessive wake locks: A CoroutineWorker that was designed to wait for a connection to the WHOOP sensor before proceeding.  If the work started with no sensor connected, whoopSensorFlow–which indicates if the sensor is connected– was null. The SensorWorker didn’t treat this as an early-exit condition and kept running, effectively waiting indefinitely for a connection. As a result, WorkManager held a partial wake lock until the work timed out, leading to high background wake lock usage and frequent, unwanted rescheduling of the SensorWorker. To address this, the WHOOP team updated the worker logic to check the connection status before attempting to execute the core business logic. If the sensor isn’t available, the worker exits, avoiding a timeout scenario and releasing the wake lock. The following code snippet shows the solution: class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) { override suspend fun doWork(): Result { ... // Check the sensor state and perform work or return failure return whoopSensorFlow.replayCache .firstOrNull() ?.let { cachedData -> processSensorData(cachedData) Result.success() } ?: run { Result.failure() } } Achieving a 90% decrease in sessions with excessive partial wake locks After rolling out the fix, the team continued to monitor the Android vitals dashboard to confirm the impact of the changes.  Ultimately, WHOOP saw their excessive partial wake lock percentage drop from 15% to less than 1% just 30 days after implementing the changes to their Worker. As a result of the changes, the team has seen fewer instances of work timing out without completing, resulting in lower average runtimes.  The WHOOP team’s advice to other developers that want to improve their background work’s efficiency: Want to dive deeper into the details and hear more insights from the developers? Check out the WHOOP team's blog. Get Started If you’re interested in trying to reduce your app’s excessive partial wake locks or trying to improve worker efficiency, view your app’s excessive partial wake locks metric in Android vitals, and review the wake locks documentation for more best practices and debugging strategies.

3/4/2026

Posted by Sameer Samat, President of Android Ecosystem Android has always driven innovation in the industry through its unique flexibility and openness. At this important moment, we want to continue leading the way in how developers distribute their apps and games to people on billions of devices across many form factors. A modern platform must be flexible, providing developers and users with choice and openness as well as a safe experience. Today we are announcing substantial updates that evolve our business model and build on our long history of openness globally.  We’re doing that in three ways: more billing options, a program for registered app stores, and lower fees and new programs for developers. Expanded billing choice on Google Play for users and developers Google Play is giving developers even more billing choice and freedom in how they handle transactions. Mobile developers will have the option to use their own billing systems in their app alongside Google Play’s billing, or they can guide users outside of their app to their own websites for purchases. Our goal is to offer this flexibility in a way that maximizes choice and safety for users.  Leading the way in store choice  We’re introducing a program that makes sideloading qualified app stores even easier. Our new Registered App Stores program will provide a more streamlined installation flow for Android app stores that meet certain quality and safety benchmarks.  Once this change has rolled out, app stores that choose to participate in this optional program will have registered with us and so users who sideload them will have a more simplified installation flow (see graphic below).  If a store chooses not to participate, nothing changes for them and they retain the same experience as any other sideloaded app on Android.   This gives app stores more ways to reach users and gives users more ways to easily and safely access the apps and games they love.  This Registered App Store program will begin outside of the US first, and we intend to bring it to the US as well, subject to court approval. Lower pricing and new programs to support developers   Google Play’s fees are already the lowest among major app stores, and today we are taking this even further by introducing a new business model that decouples fees for using our billing system and introduces new, lower service fees. Once this rolls out: Billing: For those developers who choose to use Google Play’s billing system, they will be charged a market-specific rate separate from the service fee. In the European Economic Area (EEA), UK, and US that rate will be 5%. Service Fees:   For new installs (first time installs from users after the new fees are launched in a region), we are reducing the in-app purchase (IAP) service fee to 20%.   We are launching an Apps Experience Program and revamping our Google Play Games Level Up program to incentivize building great software experiences across Android form factors associated with clear quality benchmarks and enhanced user benefits.  Those developers who choose to participate in these programs will have even lower rates. Participating IAP developers will have a 20% service fee for transactions from existing installs and a 15% fee on transactions from new app installs. Our service fee for recurring subscriptions will be 10%. Rollout timelines  This is a significant evolution, and we plan to share additional details in the coming months. To make sure we have enough time to build the necessary technical infrastructure, enable a seamless transition for developers, and ensure alignment with local regulations, these updated fees will roll out on the following staggered schedule: By June 30: EEA, the United Kingdom and the US. By September 30: Australia   By December 31:  Korea and Japan By September 30, 2027: The updates will reach the rest of the world. We will also launch the updated Google Play Games Level Up program and new App Experience program by September 30 for EEA, UK, US, and Australia and then it will roll out in line with the rest of the schedule above.  We plan to launch Registered App Stores with a version of a major Android release by the end of the year. Resolving disputes with Epic Games  With these updates, we have also resolved our disputes worldwide with Epic Games.  We believe these changes will make for a stronger Android ecosystem with even more successful developers and higher-quality apps and games available across more form factors for everyone. We look forward to our continued work with the developer community to build the next generation of digital experiences.

3/3/2026

Posted by Francesco Romano, Senior Developer Relations Engineer on Android  We are excited to announce a major milestone in bringing mobile and desktop computing closer together on Android: connected display support has reached general availability with the Android 16 QPR3 release! As shown at Google I/O 2025, connected displays allow users to connect their Android devices to an external monitor and instantly access a desktop windowing environment. Apps can be used in free-form or maximized windows and users can multitask just like they would on a desktop OS. Google and Samsung have collaborated to bring a seamless and powerful desktop windowing experience to devices across the Android ecosystem running Android 16 while connected to an external display. This is now generally available on supported devices* to users who can connect their supported Pixel and Samsung phones to external monitors, enabling new opportunities for building more engaging and more productive app experiences that adapt across form factors. How does it work? When a supported Android phone or foldable is connected to an external display, a new desktop session starts on the connected display. The experience on the connected display is similar to the experience on a desktop, including a taskbar that shows active apps and lets users pin apps for quick access. Users are able to run multiple apps side by side simultaneously in freely resizable windows on the connected display. Phone connected to an external display with a desktop session on the display while the phone maintains its own state. When a device that supports desktop windowing (such as a tablet like the Samsung Galaxy Tab S11) is connected to an external display, the desktop session is extended across both displays, unlocking an even more expansive workspace. The two displays then function as one continuous system, allowing app windows, content, and the cursor to move freely between the displays. Tablet connected to an external display, extending the desktop session across both displays. Why does it matter? In the Android 16 QPR3 release, we finalized the windowing behaviors, taskbar interactions, and input compatibility (mouse and keyboard) that define the connected display experience. We also included compatibility treatments to scale windows and avoid app restarts when switching displays. If your app is built with adaptive design principles, it will automatically have the desktop look and feel, and users will feel right at home. If the app is locked to portrait or assumes a touch-only interface, now is the time to modernize. In particular, pay attention to these key best practices for optimal app experiences on connected displays: Don't assume a constant Display object: The Display object associated with your app's context can change when an app window is moved to an external display or if the display configuration changes. Your app should gracefully handle configuration change events and query display metrics dynamically rather than caching them. Account for density configuration changes: External displays can have vastly different pixel densities than the primary device screen. Ensure your layouts and resources adapt correctly to these changes to maintain UI clarity and usability. Use density-independent pixels (dp) for layouts, provide density-specific resources, and ensure your UI scales appropriately. Correctly support external peripherals: When users connect to an external monitor, they often create a more desktop-like environment. This frequently involves using external keyboards, mice, trackpads, webcams, microphones, and speakers. Improve the support for keyboard and mouse interactions. Building for the desktop future with modern tools We provide several tools to help you build the desktop experience. Let’s recap the latest updates to our core adaptive libraries! New window size classes: Large and Extra-large The biggest update in Jetpack WindowManager 1.5.0 is the addition of two new width window size classes: Large and Extra-large. Window size classes are our official, opinionated set of viewport breakpoints that help you design and develop adaptive layouts. With 1.5.0, we're extending this guidance for screens that go beyond the size of typical tablets. Here are the new width breakpoints: Large: For widths between 1200dp and 1600dp Extra-large: For widths ≥1600dp The different window size classes based on display width. On very large surfaces, simply scaling up a tablet's Expanded layout isn't always the best user experience. An email client, for example, might comfortably show two panes (a mailbox and a message) in the Expanded window size class. But on an Extra-large desktop monitor, the email client could elegantly display three or even four panes, perhaps a mailbox, a message list, the full message content, and a calendar/tasks panel, all at once. To include the new window size classes in your project, simply call the function from the WindowSizeClass.BREAKPOINTS_V2 set instead of WindowSizeClass.BREAKPOINTS_V1: val currentWindowMetrics = WindowMetricsCalculator.getOrCreate() .computeCurrentWindowMetrics(LocalContext.current) val sizeClass = WindowSizeClass.BREAKPOINTS_V2 .computeWindowSizeClass(currentWindowMetrics) Then apply the correct layout when you’re sure your app has at least that much space: if(sizeClass.isWidthAtLeastBreakpoint( WindowSizeClass.WIDTH_DP_LARGE_LOWER_BOUND)){ ... // Window is at least 1200 dp wide. } Build adaptive layouts with Jetpack Navigation 3 Navigation 3 is the latest addition to the Jetpack collection. Navigation 3, which just reached its first stable release, is a powerful navigation library designed to work with Compose. Navigation 3 is also a great tool for building adaptive layouts by allowing multiple destinations to be displayed at the same time and allowing seamless switching between those layouts. This system for managing your app's UI flow is based on Scenes. A Scene is a layout that displays one or more destinations at the same time. A SceneStrategy determines whether it can create a Scene. Chaining SceneStrategy instances together allows you to create and display different scenes for different screen sizes and device configurations. For out-of-the-box canonical layouts, like list-detail and supporting pane, you can use the Scenes from the Compose Material 3 Adaptive library (available in version 1.3 and above). It's also easy to build your own custom Scenes by modifying the Scene recipes or starting from scratch. For example, let’s consider a Scene that displays three panes side by side: class ThreePaneScene<T : Any>( override val key: Any, override val previousEntries: List<NavEntry<T>>, val firstEntry: NavEntry<T>, val secondEntry: NavEntry<T>, val thirdEntry: NavEntry<T> ) : Scene<T> { override val entries: List<NavEntry<T>> = listOf(firstEntry, secondEntry, thirdEntry) override val content: @Composable (() -> Unit) = { Row(modifier = Modifier.fillMaxSize()) { Column(modifier = Modifier.weight(1f)) { firstEntry.Content() } Column(modifier = Modifier.weight(1f)) { secondEntry.Content() } Column(modifier = Modifier.weight(1f)) { thirdEntry.Content() } } } In this scenario, you could define a SceneStrategy to show three panes if the window width is wide enough and the entries from your back stack have declared that they support being displayed in a three-pane scene. class ThreePaneSceneStrategy<T : Any>(val windowSizeClass: WindowSizeClass) : SceneStrategy<T> { override fun SceneStrategyScope<T>.calculateScene(entries: List<NavEntry<T>>): Scene<T>? { if (windowSizeClass.isWidthAtLeastBreakpoint(WIDTH_DP_LARGE_LOWER_BOUND)) { val lastThree = entries.takeLast(3) if (lastThree.size == 3 && lastThree.all { it.metadata.containsKey(MULTI_PANE_KEY) }) { val firstEntry = lastThree[0] val secondEntry = lastThree[1] val thirdEntry = lastThree[2] return ThreePaneScene( key = Triple(firstEntry.contentKey, secondEntry.contentKey, thirdEntry.contentKey), previousEntries = entries.dropLast(3), firstEntry = firstEntry, secondEntry = secondEntry, thirdEntry = thirdEntry ) } } return null } } You can use your ThreePaneSceneStrategy with other strategies when creating your NavDisplay. For example, we could also add a TwoPaneStrategy to display two panes side by side when there isn't enough space to show three. val strategy = ThreePaneSceneStrategy() then TwoPaneSceneStrategy() NavDisplay(..., sceneStrategy = strategy, entryProvider = entryProvider { entry<MyScreen>(metadata = mapOf(MULTI_PANE_KEY to true))) { ... } ... other entries... } ) If there isn't enough space to display three or two panes—both our custom scene strategies return null. In this case, NavDisplay falls back to displaying the last entry in the back stack in a single pane using SinglePaneScene. By using scenes and strategies, you can add one, two, and three pane layouts to your app!    An adaptive app showing three-pane navigation on wide screens. Checkout the documentation to learn more on how to create custom layouts using Scenes in Navigation 3. Standalone adaptive layouts If you need a standalone layout, the Compose Material 3 Adaptive library helps you create adaptive UIs like list-detail and supporting pane layouts that adapt themselves  to window configurations automatically based on  window size classes or device postures.  The good news is that the library is already up to date with the new breakpoints! Starting from version 1.2, the default pane scaffold directive functions support Large and Extra-large width window size classes. You only need to opt-in by declaring in your Gradle build file that you want to use the new breakpoints: currentWindowAdaptiveInfo(supportLargeAndXLargeWidth = true) Getting started Explore the connected display feature in the latest Android release. Get Android 16 QPR3 on a supported device, then connect it to an external monitor to start testing your app today!  Dive into the updated documentation on multi-display support and window management to learn more about implementing these best practices. Feedback Your feedback is crucial as we continue to refine the connected display desktop experience. Share your thoughts and report any issues through our official feedback channels. We're committed to making Android a versatile platform that adapts to the many ways users want to interact with their apps and devices. The improvements to connected display support are another step in that direction, and we think your users will love the desktop experiences you'll build! *Note: At the time the article is written, connected displays are supported on Pixel 8, 9, 10 series and on a wide array of Samsung devices, including S26, Fold7, Flip7, and Tab S11.

3/3/2026

Posted by Matt Dyor, Senior Product Manager Android Studio Panda 2 is now stable and ready for you to use in production. This release brings new agentic capabilities to Android Studio, enabling the agent to create an entire working application from scratch with the AI-powered New Project flow, and allowing the agent to automate the manual work of dependency updates. Whether you're building your first prototype or maintaining a large, established codebase, these updates bring new efficiency to your workflow by enabling Gemini in Android Studio to help more than ever. Here’s a deep dive into what’s new: Create New Projects with AI Say goodbye to boilerplate starter templates that just get you to the start line. With the AI-powered New Project flow, you can now build a working app prototype with just a single prompt. The agent reduces the time you spend setting up dependencies, writing boilerplate code, and creating basic navigation, allowing you to focus on the creative aspects of app development. The AI-powered New Project flow allows you to describe exactly what you want to build - you can even upload images for style inspiration. The agent then creates a detailed project plan for your review.  When you're ready, the agent turns your plan into a first draft of your app using Android best practices, including Kotlin, Compose, and the latest stable libraries. Under your direction, it creates an autonomous generation loop: it generates the necessary code, builds the project, analyzes any build errors, and attempts to self-correct the code, looping until your project builds successfully. It then deploys your app to an Android Emulator and walks through each screen, verifying that the implementation works correctly and is true to your original request. Whether you need a simple single-screen layout, a multi-page app with navigation, or even an application integrated with Gemini APIs, the AI-powered New Project flow can handle it. Getting Started To use the agent to set up a project, do the following: Start Android Studio. Select New Project on the Welcome to Android Studio screen (or File > New > New Project from within a project) Select Create with AI. Type your prompt into the text entry field and click Next.  For best results we recommend using a paid Gemini API key or third-party remote model. Create a New Project with AI in Android Studio 5. Name your app and click Finish to start the generation process. 6. Validate the finished app using the project plan and by running your app in the Android Emulator or on an Android device.    AI-powered New Project flow For more details on the New Project flow, check out the official documentation. Share What You Build We want to hear from you and see the apps you’re able to build using the New Project flow. Share your apps with us by using #AndroidStudio in your social posts. We’ll be amplifying some of your submissions on our social channels. Unlock more with your Gemini API key While the agent works out-of-the-box using Android Studio's default no-cost model, providing your own Google AI Studio API key unlocks the full potential of the assistant. By connecting a paid Gemini API key, you get access to the fastest and latest models from Google. It also allows the New Project flow to access Nano Banana, our best model for image generation, in order to ideate on UI design — allowing the agent to create richer, higher fidelity application designs. In the AI-powered New Project flow, this increased capability means larger context windows for more tailored generation, as well as superior code quality. Furthermore, because the Agent uses Nano Banana behind the scenes for enhanced design generation, your prototype doesn't just work well—it features visually appealing, modern UI layouts and looks professional from the get go. Version Upgrade Assistant Keeping your project dependencies up to date is time-consuming and often causes cascading build errors. You fix one issue by updating a dependency, only to introduce a new issue somewhere else. The Version Upgrade Assistant in Android Studio just made that a problem of the past. You can now let AI do the heavy lifting of managing dependencies and boilerplate so you can focus on creating unique experiences for your users. To use this feature, simply right-click in your version catalog, select AI, and then Update Dependencies. Version Upgrade Assistant accessed from Version Catalog You can also access the Version Upgrade Assistant from the Refactor menu—just choose Update all libraries with AI.  Version Upgrade Assistant accessed from the Refactor menu The agent runs multiple automated rounds—attempting builds, reading error messages, and adjusting versions—until the build succeeds. Instead of manually fighting through dependency conflicts, you can let the agent handle the iterative process of finding a stable configuration for you. Read the documentation for more information on Version Upgrade Assistant.  Gemini 3.1 Pro is available in Android Studio We released Gemini 3.1 Pro preview, and it is even better than Gemini 3 Pro for reasoning and intelligence. You can access it in Android Studio by plugging in your Gemini API key. Put the new model to work on your toughest bugs, code completion, and UI logic. Let us know what you think of the new model. Gemini 3.1 Pro Now Available in Android Studio Get started Dive in and accelerate your development. Download Android Studio Panda 2 and start exploring these powerful new agentic 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. Happy coding!

3/2/2026

Posted by Trevor Johns, Developer Relations Engineer In January we announced Android Studio Otter 3 Feature Drop in stable, including Agent Mode enhancements and many other updates to provide more control and flexibility over using AI to help you build high quality Android apps. To help you get the most out of Gemini in Android Studio and all the new capabilities, we sat down with Google engineers and Google Developer Experts to gather their best practices for working with the latest features—including Agent mode and the New Project Assistant. Here are some useful insights to help you get the best out of your development: Build apps from scratch with the New Project Assistant The new Project Assistant—now available in the latest Canary builds—integrates Gemini with the Studio's New Project wizard. By simply providing prompts and (optionally) design mockups, you can generate entire applications from scratch, including scaffolding, architecture, and Jetpack Compose layouts. Integrated with the Android Emulator, it can deploy your build and "walk through" the app, making sure it’s functioning correctly and that the rendered screens actually match your vision. Additionally, you can use Agent Mode to then continue to work on the app and iterate, leveraging Gemini to refine your app to fit your vision. Also, while this feature works with the default (no-cost) model, we highly recommend using this feature with an AI Studio API Key to access the latest models — like Gemini 3.1 Pro or 3.0 Flash — which excel at agentic workflows. Additionally, adding your API Key allows the New Project Assistant to use Nano Banana behind the scenes to help with ideating on UI design, improving the visual fidelity of the generated application! - Trevor Johns, Developer Relations Engineer. Dialog for setting up a new project. 2. Ask the Agent to refine your code by providing it with ‘intentional’ contexts When using Gemini Agents, the quality of the output is directly tied to the boundaries you set. Don't just ask it to "fix this code"— be very intentional with the context that you provide it and be specific about what you want (and what you don't). Improve the output by providing recent blogs or docs so the model can make accurate suggestions based on these. Ask the Agent to simplify complex logic, or if it see’s any fundamental problems with it, or even ask it to scan for security risks in areas where you feel uncertain. Being firm with your instructions—even telling the model "please do not invent things" in instances where you are using very new or experimental APIs—helps keep the AI focused on the outputs you are trying to achieve. - Alejandra Stamato, Android Google Developer Expert and Android Engineer at HubSpot. 3. Use documentation with Agent mode to provide context for new libraries To prevent the model from hallucinating code for niche or brand-new libraries, leverage Android Studio’s Agent tools, to have access to documentation: Search Android Docs and Fetch Android Docs. You can direct Gemini to search the Android Knowledge Base or specific documentation articles. The model can choose to use this if it thinks it’s missing some information, which is good especially when you use niche API’s, or one’s which aren’t as common.  If you are certain you want the model to consult the documentation and to make sure those tools are triggered, a good trick is to add something like ‘search the official documentation’ or ‘check the docs’ to your prompts. And for documentation on different libraries which aren’t Android specific, install a MCP Server that lets you access documentation like Context7 (or something similar). - Jose Alcérreca, Android Developer Relations Engineer, Google. 4. Use AI to help build Agents.md files for using custom frameworks, libraries and design systems To make sure Agent uses custom frameworks, libraries and design systems you have two options 1) In settings, Android Studio allows you to specify rules to be followed when Gemini is performing these actions for you. Or 2) Create Agents.md files in your application and specify how things should be done or act as guidance for when AI is performing a task, specific frameworks, design systems, or specific ways of doing things (such as the exact architecture, things to do or what not to do), in a standard bullet point way to give AI clear instructions.  Manage AGENTS.md files as context. You can also use Agents.md file at the root of the project, and can have them in different modules (or even subdirectories) of your project as well! The more context you have or the more guidance available when you’re working, that will be available for AI to access. If you get stuck creating these Agents.md files you can use AI to help build them, or give you foundations based on the projects you have and then edit them so you don’t have to start from scratch. - Joe Birch, Android Google Developer Expert and Staff Engineer at Buffer. 5. Offload the tedious tasks to Agent and save yourself time You can get Gemini in Android Studio agent to help you make tasks such as writing and reviewing faster. For example it can help writing commit messages, giving you a good summary which you can then review and save yourself time. Additionally, get it to write tests; under your direction the Agent can look at the other tests in your project and write a good test for you to run following best practices just by looking at them. Another good example of a tedious task is writing a new parser for a certain JSON format. Just give Gemini a few examples and it will get you started very quickly. - Diego Perez, Android Software Engineer, Google  6. Control what you are sharing with AI using simple opt-outs or commands, alongside paid models. If you want to control what is shared with AI whilst on the no-cost plans, you can opt out some or all your code from model training by adding an AI exclusions file (‘.aiexclude’) to your project. This file uses glob pattern matching similar to a .gitignore file, specifying sensitive directories or files that should be hidden from the AI. You can place .aiexclude files anywhere within the project and its VCS roots to control which files AI features are allowed to access. An example of an `.aiexclude` file in Android Studio. Alternatively, in Android Studio settings, you can also opt out of context sharing either on a per project or per user basis (although this method limits the functionality of a number of features because the AI won’t see your code). Remember, paid plans never use your code for model training. This includes both users using an AI Studio API Key, and businesses who are subscribed to Gemini Code Assist. - Trevor Johns, Developer Relations Engineer. Hear more from the Android team and Google Developer Experts about Gemini in Android Studio in our recent fireside chat and download Android Studio to get started.

2/26/2026

Posted by Matthew McCullough, VP Product Management, Android Developer Today we're releasing the second beta of Android 17, continuing our work to build a platform that prioritizes privacy, security, and refined performance. This update delivers a range of new capabilities, including the EyeDropper API and a privacy-preserving Contacts Picker. We're also adding advanced ranging, cross-device handoff APIs, and more. This release continues the shift in our release cadence, following this annual major SDK release in Q2 with a minor SDK update. User Experience & System UI Bubbles Bubbles is a windowing mode feature that offers a new floating UI experience separate from the messaging bubbles API. Users can create an app bubble on their phone, foldable, or tablet by long-pressing an app icon on the launcher. On large screens, there is a bubble bar as part of the taskbar where users can organize, move between, and move bubbles to and from anchored points on the screen. You should follow the guidelines for supporting multi-window mode to ensure your apps work correctly as bubbles. Bubbles aren't yet fully enabled in Beta 2. Look for them in a future build of Android 17. EyeDropper API A new system-level EyeDropper API allows your app to request a color from any pixel on the display without requiring sensitive screen capture 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) } Contacts Picker A new system-level contacts picker via ACTION_PICK_CONTACTS grants temporary, session-based read access to only the specific data fields requested by the user, reducing the need for the broad READ_CONTACTS permissions. It also allows for selections from the device’s personal or work profiles. val contactPicker = rememberLauncherForActivityResult(StartActivityForResult()) { if (it.resultCode == RESULT_OK) { val uri = it.data?.data ?: return@rememberLauncherForActivityResult // Handle result logic processContactPickerResults(uri) } } val dataFields = arrayListOf(Email.CONTENT_ITEM_TYPE, Phone.CONTENT_ITEM_TYPE) val intent = Intent(ACTION_PICK_CONTACTS).apply { putStringArrayListExtra(EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS, dataFields) putExtra(EXTRA_ALLOW_MULTIPLE, true) putExtra(EXTRA_PICK_CONTACTS_SELECTION_LIMIT, 5) } contactPicker.launch(intent) Easier pointer capture compatibility with touchpads Previously, touchpads reported events in a very different way from mice when an app had captured the pointer, reporting the locations of fingers on the pad rather than the relative movements that would be reported by a mouse. This made it quite difficult to support touchpads properly in first-person games. Now, by default the system will recognize pointer movement and scrolling gestures when the touchpad is captured, and report them just like mouse events. You can still request the old, detailed finger location data by explicitly requesting capture in the new “absolute” mode. // To request the new default relative mode (mouse-like events) // This is the same as requesting with View.POINTER_CAPTURE_MODE_RELATIVE view.requestPointerCapture() // To request the legacy absolute mode (raw touch coordinates) view.requestPointerCapture(View.POINTER_CAPTURE_MODE_ABSOLUTE) Interactive Chooser resting bounds By calling getInitialRestingBounds on Android's ChooserSession, your app can identify the target position the Chooser occupies after animations and data loading are complete, enabling better UI adjustments. Connectivity & Cross-Device Cross-device app handoff A new Handoff API allows you to specify application state to be resumed on another device, such as an Android tablet. When opted in, the system synchronizes state via CompanionDeviceManager and displays a handoff suggestion in the launcher of the user's nearby devices. This feature is designed to offer seamless task continuity, enabling users to pick up exactly where they left off in their workflow across their Android ecosystem. Critically, Handoff supports both native app-to-app transitions and app-to-web fallback, providing maximum flexibility and ensuring a complete experience even if the native app is not installed on the receiving device. Advanced ranging APIs We are adding support for 2 new ranging technologies -  UWB DL-TDOA which enables apps to use UWB for indoor navigation. This API surface is FIRA (Fine Ranging Consortium) 4.0 DL-TDOA spec compliant and enables privacy preserving indoor navigation  (avoiding tracking of the device by the anchor). Proximity Detection which enables apps to use the new ranging specification being adopted by WFA (WiFi Alliance). This technology provides improved reliability and accuracy compared to existing Wifi Aware based ranging specification. Data plan enhancements To optimize media quality, your app can now retrieve carrier-allocated maximum data rates for streaming applications using getStreamingAppMaxDownlinkKbps and getStreamingAppMaxUplinkKbps. Core Functionality, Privacy & Performance Local Network Access Android 17 introduces the ACCESS_LOCAL_NETWORK runtime permission to protect users from unauthorized local network access. Because this falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions will not be prompted again. By declaring and requesting this permission, your app can discover and connect to devices on the local area network (LAN), such as smart home devices or casting receivers. This prevents malicious apps from exploiting unrestricted local network access for covert user tracking and fingerprinting. Apps targeting Android 17 or higher will now have two paths to maintain communication with LAN devices: adopt system-mediated, privacy-preserving device pickers to skip the permission prompt, or explicitly request this new permission at runtime to maintain local network communication. Time zone offset change broadcast Android now provides a reliable broadcast intent, ACTION_TIMEZONE_OFFSET_CHANGED, triggered when the system's time zone offset changes, such as during Daylight Saving Time transitions. This complements the existing broadcast intents ACTION_TIME_CHANGED and ACTION_TIMEZONE_CHANGED, which are triggered when the Unix timestamp changes and when the time zone ID changes, respectively. NPU Management and Prioritization 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. ICU 78 and Unicode 17 support Core internationalization libraries have been updated to ICU 78, expanding support for new scripts, characters, and emoji blocks, and enabling direct formatting of time objects. SMS OTP protection Android is expanding its SMS OTP protection by automatically delaying access to SMS messages with OTP. Previously, the protection was primarily focused on the SMS Retriever format wherein the delivery of messages containing an SMS retriever hash is delayed for most apps for three hours. However, for certain apps like the default SMS app, etc and the app that corresponds to the hash are exempt from this delay. This update extends the protection to all SMS messages with OTP. For most apps, SMS messages containing an OTP will only be accessible after a delay of three hours to help prevent OTP hijacking. The SMS_RECEIVED_ACTION broadcast will be withheld and sms provider database queries will be filtered. The SMS message will be available to these apps after the delay. Delayed access to WebOTP format SMS messages If the app has the permission to read SMS messages but is not the intended recipient of the OTP (as determined by domain verification), the WebOTP format SMS message will only be accessible after three hours have elapsed. This change is designed to improve user security by ensuring that only apps associated with the domain mentioned in the message can programmatically read the verification code. This change applies to all apps regardless of their target API level. Delayed access to standard SMS messages with OTP For SMS messages containing an OTP that do not use the WebOTP or SMS Retriever formats, the OTP SMS will only be accessible after three hours for most apps. This change only applies to apps that target Android 17 (API level 37) or higher. Certain apps such as the default SMS, assistant app, along with connected device companion apps, etc will be exempt from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality. The Android 17 schedule We're going to be moving quickly from this Beta to our Platform Stability milestone, targeted for March. At this milestone, we'll deliver final SDK/NDK APIs. From that time forward, your app can target SDK 37 and publish to Google Play to help you complete your testing and collect user feedback in the several months before the general availability of Android 17. A year of releases We plan for Android 17 to continue to get updates in a series of quarterly releases. The upcoming release in Q2 is the only one where we introduce planned app breaking behavior changes. We plan to have a minor SDK release in Q4 with additional APIs and features. Get started with Android 17 You can enroll any supported Pixel device to get this and future Android Beta updates over-the-air. 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 in the Android Beta program, you will be offered an over-the-air update to Beta 2. If you have Android 26Q1 Beta and would like to take the final stable release of 26Q1 and exit Beta, you need to ignore the over-the-air update to 26Q2 Beta 2 and wait for the release of 26Q1. We're looking for your feedback so please report issues and submit feature requests on the feedback page. The earlier we get your feedback, the more we can include in our work on the final release. For the best development experience with Android 17, we recommend that you use the latest preview of Android Studio (Panda). Once you’re set up, here are some of the things you should do: Compile against the new SDK, test in CI environments, and report any issues in our tracker on the feedback page. 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 emulator running Android 17 and extensively test it. We’ll update the preview/beta system images and SDK regularly throughout the Android 17 release cycle. Once you’ve installed a beta build, you’ll automatically get future updates over-the-air for all later previews and Betas. For complete information, visit the Android 17 developer site. Join the conversation As we move toward Platform Stability and the general availability of Android 17 later this year, your feedback remains our most valuable asset. Whether you’re an early adopter on   the Canary channel or an app developer testing on Beta 2, consider joining our communities and filing feedback. We’re listening.

2/25/2026

Posted by Matthew McCullough, VP of Product Management, Android Development User expectations for AI on their devices are fundamentally shifting how they interact with their apps. Instead of opening apps to do tasks step-by-step, they're asking AI to do the heavy lifting for them. In this new interaction model, success is shifting from getting users to open your app, to successfully fulfilling their tasks and helping them get more done faster.  To help you evolve your apps for this agentic future, we're introducing early stage developer capabilities that bridge the gap between your apps and agentic apps and personalized assistants, such as Google Gemini. While we are in the early, beta stages of this journey, we’re designing these features with privacy and security at their core as our first step in exploring this paradigm shift as an app ecosystem. Empowering apps with AppFunctions Android AppFunctions allows apps to expose data and functionality directly to AI agents and assistants. With the AppFunctions Jetpack library and platform APIs, developers can create self-describing functions that agentic apps can discover and execute via natural language. Mirroring how backend capabilities are declared via MCP cloud servers, AppFunctions provides an on-device solution for Android apps. Much like WebMCP, it executes these functions locally on the device rather than on a server. The Samsung Gallery integration with Gemini on the Galaxy S26 series showcases AppFunctions in action. Instead of manually scrolling through photo albums, you can now simply ask Gemini to "Show me pictures of my cat from Samsung Gallery." Gemini takes the user query, intelligently identifies and triggers the right function, and presents the returned photos from Samsung Gallery directly in the Gemini app, so users never need to leave. This experience is multimodal and can be done via voice or text. Users can even use the returned photos in follow-up conversations, like sending them to friends in a text message. This integration is currently available on the Galaxy S26 series and will soon expand to Samsung devices running OneUI 8.5 and higher. Through AppFunctions, Gemini can already automate tasks across app categories like Calendar, Notes, and Tasks, on devices from multiple manufacturers. Whether it’s coordinating calendar events, organizing notes, or setting to-do reminders, users can streamline daily activities in one place. Enabling agentic apps with intelligent UI automation While AppFunctions provides a structured framework and more control for apps to communicate with AI agents and assistants, we know that not every interaction has a dedicated integration yet. We’re also developing a UI automation framework for AI agents and assistants to intelligently execute generic tasks on users’ installed apps, with user transparency and control built in. This is the platform doing the heavy lifting, so developers can get agentic reach with zero code. It’s a low-effort way to extend their reach without a major engineering lift right now.  To get feedback as we refine this framework, we’re starting with an early preview on the Galaxy S26 series and select Pixel 10 devices, where users will be able to delegate multi-step tasks to Gemini with just a long press of the power button. Launching as a beta feature in the Gemini app, this will support a curated selection of apps in the food delivery, grocery, and rideshare categories in the US and Korea to start. Whether users need to place a complex pizza order for their family members with particular tastes, coordinate a multi-stop rideshare with co-workers, or reorder their last grocery purchase, Gemini can help complete tasks using the context already available from your apps, without any developer work needed. Users are in control while a task is being actioned in the background through UI automation. For any automation action, users have the option to monitor a task’s progress via notifications or "live view" and can switch to manual control at any point to take over the experience. Gemini is also designed to alert users before completing sensitive tasks, such as making a purchase. Looking ahead In Android 17, we’re looking to broaden these capabilities to reach even more users, developers, and device manufacturers. We are currently building experiences with a small set of app developers, focusing on high-quality user experiences as the ecosystem evolves. We plan to share more details later this year on how you can use AppFunctions and UI automation to enable agentic integrations for your app. Stay tuned for updates.

2/17/2026

Posted by The Google I/O Team Google I/O returns May 19–20 Google I/O is back! Join us online as we share our latest AI breakthroughs and updates in products across the company, from Gemini to Android, Chrome, Cloud, and more. Tune in to learn about agentic coding and the latest Gemini model updates. The event will feature keynote addresses from Google leaders, forward-looking panel discussions, and product demos designed to showcase the next frontier of technology. Register now and tune in live Visit io.google and register to receive updates about Google I/O. Kicking off May 19 at 10am PT, this year we’ll be livestreaming keynotes, demos, and more sessions across two days. We’ll also be bringing back the popular Dialogues sessions featuring big thinkers and bold leaders discussing how AI is shaping our future.

2/17/2026

Posted by Shai Barack, Android Platform Performance Lead and Charles Munger, Principal Software Engineer In Android 17, apps targeting SDK 37 or higher will receive a new implementation of MessageQueue where the implementation is lock-free. The new implementation improves performance and reduces missed frames, but may break clients that reflect on MessageQueue private fields and methods. To learn more about the behavior change and how you can mitigate impact, check out the MessageQueue behavior change documentation. This technical blog post provides an overview of the MessageQueue rearchitecture and how you can analyze lock contention issues using Perfetto. The Looper drives the UI thread of every Android application. It pulls work from a MessageQueue, dispatches it to a Handler, and repeats. For two decades, MessageQueue used a single monitor lock (i.e. a synchronized code block) to protect its state. Android 17 introduces a significant update to this component: a lock-free implementation named DeliQueue. This post explains how locks affect UI performance, how to analyze these issues with Perfetto, and the specific algorithms and optimizations used to improve the Android main thread. The problem: Lock Contention and Priority Inversion The legacy MessageQueue functioned as a priority queue protected by a single lock. If a background thread posts a message while the main thread performs queue maintenance, the background thread blocks the main thread. When two or more threads are competing for exclusive use of the same lock, this is called Lock contention. This contention can cause Priority Inversion, leading to UI jank and other performance problems. Priority inversion can happen when a high-priority thread (like the UI thread) is made to wait for a low-priority thread. Consider this sequence: A low priority background thread acquires the MessageQueue lock to post the result of work that it did. A medium priority thread becomes runnable and the Kernel's scheduler allocates it CPU time, preempting the low priority thread. The high priority UI thread finishes its current task and attempts to read from the queue, but is blocked because the low priority thread holds the lock. The low-priority thread blocks the UI thread, and the medium-priority work delays it further. Analyzing contention with Perfetto You can diagnose these issues using Perfetto. In a standard trace, a thread blocked on a monitor lock enters the sleeping state, and Perfetto shows a slice indicating the lock owner. When you query trace data, look for slices named “monitor contention with …” followed by the name of the thread that owns the lock and the code site where the lock was acquired. Case study: Launcher jank To illustrate, let’s analyze a trace where a user experienced jank while navigating home on a Pixel phone immediately after taking a photo in the camera app. Below we see a screenshot of Perfetto showing the events leading up to the missed frame: Symptom: The Launcher main thread missed its frame deadline. It blocked for 18ms, which exceeds the 16ms deadline required for 60Hz rendering. Diagnosis: Perfetto showed the main thread blocked on the MessageQueue lock. A “BackgroundExecutor” thread owned the lock. Root Cause: The BackgroundExecutor runs at Process.THREAD_PRIORITY_BACKGROUND (very low priority). It performed a non-urgent task (checking app usage limits). Simultaneously, medium priority threads were using CPU time to process data from the camera. The OS scheduler preempted the BackgroundExecutor thread to run the camera threads. This sequence caused the Launcher’s UI thread (high priority) to become indirectly blocked by the camera worker thread (medium priority), which was keeping the Launcher’s background thread (low priority) from releasing the lock. Querying traces with PerfettoSQL You can use PerfettoSQL to query trace data for specific patterns. This is useful if you have a large bank of traces from user devices or tests, and you’re searching for specific traces that demonstrate a problem. For example, this query finds MessageQueue contention coincident with dropped frames (jank): INCLUDE PERFETTO MODULE android.monitor_contention; INCLUDE PERFETTO MODULE android.frames.jank_type; SELECT process_name, -- Convert duration from nanoseconds to milliseconds SUM(dur) / 1000000 AS sum_dur_ms, COUNT(*) AS count_contention FROM android_monitor_contention WHERE is_blocked_thread_main AND short_blocked_method LIKE "%MessageQueue%" -- Only look at app processes that had jank AND upid IN ( SELECT DISTINCT(upid) FROM actual_frame_timeline_slice WHERE android_is_app_jank_type(jank_type) = TRUE ) GROUP BY process_name ORDER BY SUM(dur) DESC; In this more complex example, join trace data that spans multiple tables to identify MessageQueue contention during app startup: INCLUDE PERFETTO MODULE android.monitor_contention; INCLUDE PERFETTO MODULE android.startup.startups; -- Join package and process information for startups DROP VIEW IF EXISTS startups; CREATE VIEW startups AS SELECT startup_id, ts, dur, upid FROM android_startups JOIN android_startup_processes USING(startup_id); -- Intersect monitor contention with startups in the same process. DROP TABLE IF EXISTS monitor_contention_during_startup; CREATE VIRTUAL TABLE monitor_contention_during_startup USING SPAN_JOIN(android_monitor_contention PARTITIONED upid, startups PARTITIONED upid); SELECT process_name, SUM(dur) / 1000000 AS sum_dur_ms, COUNT(*) AS count_contention FROM monitor_contention_during_startup WHERE is_blocked_thread_main AND short_blocked_method LIKE "%MessageQueue%" GROUP BY process_name ORDER BY SUM(dur) DESC; You can use your favorite LLM to write PerfettoSQL queries to find other patterns. At Google, we use BigTrace to run PerfettoSQL queries across millions of traces. In doing so, we confirmed that what we saw anecdotally was, in fact, a systemic issue. The data revealed that MessageQueue lock contention impacts users across the entire ecosystem, substantiating the need for a fundamental architectural change. Solution: lock-free concurrency We addressed the MessageQueue contention problem by implementing a lock-free data structure, using atomic memory operations rather than exclusive locks to synchronize access to shared state. A data structure or algorithm is lock-free if at least one thread can always make progress regardless of the scheduling behavior of the other threads. This property is generally hard to achieve, and is usually not worth pursuing for most code. The atomic primitives Lock-free software often relies on atomic Read-Modify-Write primitives that the hardware provides. On older generation ARM64 CPUs, atomics used a Load-Link/Store-Conditional (LL/SC) loop. The CPU loads a value and marks the address. If another thread writes to that address, the store fails, and the loop retries. Because the threads can keep trying and succeed without waiting for another thread, this operation is lock-free. ARM64 LL/SC loop example retry: ldxr x0, [x1] // Load exclusive from address x1 to x0 add x0, x0, #1 // Increment value by 1 stxr w2, x0, [x1] // Store exclusive. // w2 gets 0 on success, 1 on failure cbnz w2, retry // If w2 is non-zero (failed), branch to retr (view in Compiler Explorer) Newer ARM architectures (ARMv8.1) support Large System Extensions (LSE) which include instructions in the form of Compare-And-Swap (CAS) or Load-And-Add (demonstrated below). In Android 17 we added support to the Android Runtime (ART) compiler to detect when LSE is supported and emit optimized instructions: / ARMv8.1 LSE atomic example ldadd x0, x1, [x2] // Atomic load-add. // Faster, no loop required. In our benchmarks, high-contention code that uses CAS achieves a ~3x speedup over the LL/SC variant. The Java programming language offers atomic primitives via java.util.concurrent.atomic that rely on these and other specialized CPU instructions. The Data Structure: DeliQueue To remove lock contention from MessageQueue, our engineers designed a novel data structure called DeliQueue. DeliQueue separates Message insertion from Message processing: The list of Messages (Treiber stack): A lock-free stack. Any thread can push new Messages here without contention. The priority queue (Min-heap): A heap of Messages to handle, exclusively owned by the Looper thread (hence no synchronization or locks are needed to access). Enqueue: pushing to a Treiber stack The list of Messages is kept in a Treiber stack [1], a lock-free stack that uses a CAS loop to update the head pointer. public class TreiberStack <E> { AtomicReference<Node<E>> top = new AtomicReference<Node<E>>(); public void push(E item) { Node<E> newHead = new Node<E>(item); Node<E> oldHead; do { oldHead = top.get(); newHead.next = oldHead; } while (!top.compareAndSet(oldHead, newHead)); } public E pop() { Node<E> oldHead; Node<E> newHead; do { oldHead = top.get(); if (oldHead == null) return null; newHead = oldHead.next; } while (!top.compareAndSet(oldHead, newHead)); return oldHead.item; } } Source code based on Java Concurrency in Practice [2], available online and released to the public domain Any producer can push new Messages to the stack at any time. This is like pulling a ticket at a deli counter - your number is determined by when you showed up, but the order you get your food in doesn't have to match. Because it's a linked stack, every Message is a sub-stack - you can see what the Message queue was like at any point in time by tracking the head and iterating forwards - you won't see any new Messages pushed on top, even if they're being added during your traversal. Dequeue: bulk transfer to a min-heap To find the next Message to handle, the Looper processes new Messages from the Treiber stack by walking the stack starting from the top and iterating until it finds the last Message that it previously processed. As the Looper traverses down the stack, it inserts Messages into the deadline-ordered min-heap. Since the Looper exclusively owns the heap, it orders and processes Messages without locks or atomics. In walking down the stack, the Looper also creates links from stacked Messages back to their predecessors, thus forming a doubly-linked list. Creating the linked list is safe because links pointing down the stack are added via the Treiber stack algorithm with CAS, and links up the stack are only ever read and modified by the Looper thread. These back links are then used to remove Messages from arbitrary points in the stack in O(1) time. This design provides O(1) insertion for producers (threads posting work to the queue) and amortized O(log N) processing for the consumer (the Looper). Using a min-heap to order Messages also addresses a fundamental flaw in the legacy MessageQueue, where Messages were kept in a singly-linked list (rooted at the top). In the legacy implementation, removal from the head was O(1), but insertion had a worst case of O(N) – scaling poorly for overloaded queues! Conversely, insertion to and removal from the min-heap scale logarithmically, delivering competitive average performance but really excelling in tail latencies. Legacy (locked) MessageQueue DeliQueue Insert O(N) O(1) for calling thread O(logN) for Looper thread Remove from head O(1) O(logN) In the legacy queue implementation, producers and the consumer used a lock to coordinate exclusive access to the underlying singly-linked list. In DeliQueue, the Treiber stack handles concurrent access, and the single consumer handles ordering its work queue. Removal: consistency via tombstones DeliQueue is a hybrid data structure, joining a lock-free Treiber stack with a single-threaded min-heap. Keeping these two structures in sync without a global lock presents a unique challenge: a message might be physically present in the stack but logically removed from the queue. To solve this, DeliQueue uses a technique called “tombstoning.” Each Message tracks its position in the stack via the backwards and forwards pointers, its index in the heap’s array, and a boolean flag indicating whether it has been removed. When a Message is ready to run, the Looper thread will CAS its removed flag, then remove it from the heap and stack. When another thread needs to remove a Message, it doesn't immediately extract it from the data structure. Instead, it performs the following steps: Logical removal: the thread uses a CAS to atomically set the Message’s removal flag from false to true. The Message remains in the data structure as evidence of its pending removal, a so-called “tombstone”. Once a Message is flagged for removal, DeliQueue treats it as if it no longer exists in the queue whenever it’s found. Deferred cleanup: The actual removal from the data structure is the responsibility of the Looper thread, and is deferred until later. Rather than modifying the stack or heap, the remover thread adds the Message to another lock-free freelist stack. Structural removal: Only the Looper can interact with the heap or remove elements from the stack. When it wakes up, it clears the freelist and processes the Messages it contained. Each Message is then unlinked from the stack and removed from the heap.  This approach keeps all management of the heap single-threaded. It minimizes the number of concurrent operations and memory barriers required, making the critical path faster and simpler. Traversal: benign Java memory model data races Most concurrency APIs, such as Future in the Java standard library, or Kotlin’s Job and Deferred, include a mechanism to cancel work before it completes. An instance of one of these classes matches 1:1 with a unit of underlying work, and calling cancel on an object cancels the specific operations associated with them. Today’s Android devices have multi-core CPUs and concurrent, generational garbage collection. But when Android was first developed, it was too expensive to allocate one object for each unit of work. Consequently, Android’s Handler supports cancellation via numerous overloads of removeMessages - rather than removing a specific Message, it removes all Messages that match the specified criteria. In practice, this requires iterating through all Messages inserted before removeMessages was called and removing the ones that match. When iterating forward, a thread only requires one ordered atomic operation, to read the current head of the stack. After that, ordinary field reads are used to find the next Message. If the Looper thread modifies the next fields while removing Messages, the Looper’s write and another thread’s read are unsynchronized - this is a data race. Normally, a data race is a serious bug that can cause huge problems in your app - leaks, infinite loops, crashes, freezes, and more. However, under certain narrow conditions, data races can be benign within the Java Memory Model. Suppose we start with a stack of: We perform an atomic read of the head, and see A. A’s next pointer points to B. At the same time as we process B, the looper might remove B and C, by updating A to point to C and then D. Even though B and C are logically removed, B retains its next pointer to C, and C to D. The reading thread continues traversing through the detached removed nodes and eventually rejoins the live stack at D. By designing DeliQueue to handle races between traversal and removal, we allow for safe, lock-free iteration. Quitting: Native refcount Looper is backed by a native allocation that must be manually freed once the Looper has quit. If some other thread is adding Messages while the Looper is quitting, it could use the native allocation after it’s freed, a memory safety violation. We prevent this using a tagged refcount, where one bit of the atomic is used to indicate whether the Looper is quitting. Before using the native allocation, a thread reads the refcount atomic. If the quitting bit is set, it returns that the Looper is quitting and the native allocation must not be used. If not, it attempts a CAS to increment the number of active threads using the native allocation. After doing what it needs to, it decrements the count. If the quitting bit was set after its increment but before the decrement, and the count is now zero, then it wakes up the Looper thread. When the Looper thread is ready to quit, it uses CAS to set the quitting bit in the atomic. If the refcount was 0, it can proceed to free its native allocation. Otherwise, it parks itself, knowing that it will be woken up when the last user of the native allocation decrements the refcount. This approach does mean that the Looper thread waits for the progress of other threads, but only when it’s quitting. That only happens once and is not performance sensitive, and it keeps the other code for using the native allocation fully lock-free. There’s a lot of other tricks and complexity in the implementation. You can learn more about DeliQueue by reviewing the source code. Optimization: branchless programming While developing and testing DeliQueue, the team ran many benchmarks and carefully profiled the new code. One issue identified using the simpleperf tool was pipeline flushes caused by the Message comparator code. A standard comparator uses conditional jumps, with the condition for deciding which Message comes first simplified below: static int compareMessages(@NonNull Message m1, @NonNull Message m2) { if (m1 == m2) { return 0; } // Primary queue order is by when. // Messages with an earlier when should come first in the queue. final long whenDiff = m1.when - m2.when; if (whenDiff > 0) return 1; if (whenDiff < 0) return -1; // Secondary queue order is by insert sequence. // If two messages were inserted with the same `when`, the one inserted // first should come first in the queue. final long insertSeqDiff = m1.insertSeq - m2.insertSeq; if (insertSeqDiff > 0) return 1; if (insertSeqDiff < 0) return -1; return 0; } This code compiles to conditional jumps (b.le and cbnz instructions). When the CPU encounters a conditional branch, it can’t know whether the branch is taken until the condition is computed, so it doesn’t know which instruction to read next, and has to guess, using a technique called branch prediction. In a case like binary search, the branch direction will be unpredictably different at each step, so it’s likely that half the predictions will be wrong. Branch prediction is often ineffective in searching and sorting algorithms (such as the one used in a min-heap), because the cost of guessing wrong is larger than the improvement from guessing correctly. When the branch predictor guesses wrong, it must throw away the work it did after assuming the predicted value, and start again from the path that was actually taken - this is called a pipeline flush. To find this issue, we profiled our benchmarks using the branch-misses performance counter, which records stack traces where the branch predictor guesses wrong. We then visualized the results with Google pprof, as shown below: Recall that the original MessageQueue code used a singly-linked list for the ordered queue. Insertion would traverse the list in sorted order as a linear search, stopping at the first element that’s past the point of insertion and linking the new Message ahead of it. Removal from the head simply required unlinking the head. Whereas DeliQueue uses a min-heap, where mutations require reordering some elements (sifting up or down) with logarithmic complexity in a balanced data structure, where any comparison has an even chance of directing the traversal to a left child or to a right child. The new algorithm is asymptotically faster, but exposes a new bottleneck as the search code stalls on branch misses half the time. Realizing that branch misses were slowing down our heap code, we optimized the code using branch-free programming: // Branchless Logic static int compareMessages(@NonNull Message m1, @NonNull Message m2) { final long when1 = m1.when; final long when2 = m2.when; final long insertSeq1 = m1.insertSeq; final long insertSeq2 = m2.insertSeq; // signum returns the sign (-1, 0, 1) of the argument, // and is implemented as pure arithmetic: // ((num >> 63) | (-num >>> 63)) final int whenSign = Long.signum(when1 - when2); final int insertSeqSign = Long.signum(insertSeq1 - insertSeq2); // whenSign takes precedence over insertSeqSign, // so the formula below is such that insertSeqSign only matters // as a tie-breaker if whenSign is 0. return whenSign * 2 + insertSeqSign; } To understand the optimization, disassemble the two examples in Compiler Explorer and use LLVM-MCA, a CPU simulator that can generate an estimated timeline of CPU cycles. The original code: Index 01234567890123 [0,0] DeER . . . sub x0, x2, x3 [0,1] D=eER. . . cmp x0, #0 [0,2] D==eER . . cset w0, ne [0,3] .D==eER . . cneg w0, w0, lt [0,4] .D===eER . . cmp w0, #0 [0,5] .D====eER . . b.le #12 [0,6] . DeE---R . . mov w1, #1 [0,7] . DeE---R . . b #48 [0,8] . D==eE-R . . tbz w0, #31, #12 [0,9] . DeE--R . . mov w1, #-1 [0,10] . DeE--R . . b #36 [0,11] . D=eE-R . . sub x0, x4, x5 [0,12] . D=eER . . cmp x0, #0 [0,13] . D==eER. . cset w0, ne [0,14] . D===eER . cneg w0, w0, lt [0,15] . D===eER . cmp w0, #0 [0,16] . D====eER. csetm w1, lt [0,17] . D===eE-R. cmp w0, #0 [0,18] . .D===eER. csinc w1, w1, wzr, le [0,19] . .D====eER mov x0, x1 [0,20] . .DeE----R ret Note the one conditional branch, b.le,  which avoids comparing the insertSeq fields if the result is already known from comparing the when fields. The branchless code: Index 012345678 [0,0] DeER . . sub x0, x2, x3 [0,1] DeER . . sub x1, x4, x5 [0,2] D=eER. . cmp x0, #0 [0,3] .D=eER . cset w0, ne [0,4] .D==eER . cneg w0, w0, lt [0,5] .DeE--R . cmp x1, #0 [0,6] . DeE-R . cset w1, ne [0,7] . D=eER . cneg w1, w1, lt [0,8] . D==eeER add w0, w1, w0, lsl #1 [0,9] . DeE--R ret Here, the branchless implementation takes fewer cycles and instructions than even the shortest path through the branchy code - it’s better in all cases. The faster implementation plus the elimination of mispredicted branches resulted in a 5x improvement in some of our benchmarks! However, this technique is not always applicable. Branchless approaches generally require doing work that will be thrown away, and if the branch is predictable most of the time, that wasted work can slow your code down. In addition, removing a branch often introduces a data dependency. Modern CPUs execute multiple operations per cycle, but they can’t execute an instruction until its inputs from a previous instruction are ready. In contrast, a CPU can speculate about data in branches, and work ahead if a branch is predicted correctly. Testing and Validation Validating the correctness of lock-free algorithms is notoriously difficult! In addition to standard unit tests for continuous validation during development, we also wrote rigorous stress tests to verify queue invariants and to attempt to induce data races if they existed. In our test labs we could run millions of test instances on emulated devices and on real hardware. With Java ThreadSanitizer (JTSan) instrumentation, we could use the same tests to also detect some data races in our code. JTSan did not find any problematic data races in DeliQueue, but - surprisingly -actually detected two concurrency bugs in the Robolectric framework, which we promptly fixed. To improve our debugging capabilities, we built new analysis tools. Below is an example showing an issue in Android platform code where one thread is overloading another thread with Messages, causing a large backlog, visible in Perfetto thanks to the MessageQueue instrumentation feature that we added. To enable MessageQueue tracing in the system_server process, include the following in your Perfetto configuration: data_sources { config { name: "track_event" target_buffer: 0 # Change this per your buffers configuration track_event_config { enabled_categories: "mq" } } } Impact DeliQueue improves system and app performance by eliminating locks from MessageQueue. Synthetic benchmarks: multi-threaded insertions into busy queues is up to 5,000x faster than the legacy MessageQueue, thanks to improved concurrency (the Treiber stack) and faster insertions (the min-heap). In Perfetto traces acquired from internal beta testers, we see a reduction of 15% in app main thread time spent in lock contention. On the same test devices, the reduced lock contention leads to significant improvements to the user experience, such as: -4% missed frames in apps. -7.7% missed frames in System UI and Launcher interactions. -9.1% in time from app startup to the first frame drawn, at the 95%ile. Next steps DeliQueue is rolling out to apps in Android 17. App developers should review preparing your app for the new lock-free MessageQueue on the Android Developers blog to learn how to test their apps. References [1] Treiber, R.K., 1986. Systems programming: Coping with parallelism. International Business Machines Incorporated, Thomas J. Watson Research Center. [2] Goetz, B., Peierls, T., Bloch, J., Bowbeer, J., Holmes, D., & Lea, D. (2006). Java Concurrency in Practice. Addison-Wesley Professional.

2/13/2026

Posted by Miguel Montemayor, Developer Relations Engineer, Android  With the release of Android 16 in 2025, we shared our vision for a device ecosystem where apps adapt seamlessly to any screen—whether it’s a phone, foldable, tablet, desktop, car display, or XR. Users expect their apps to work everywhere. Whether multitasking on a tablet, unfolding a device to read comfortably, or running apps in a desktop windowing environment, users expect the UI to fill the available display space and adapt to the device posture. We introduced significant changes to orientation and resizability APIs to facilitate adaptive behavior, while providing a temporary opt-out to help you make the transition. We’ve already seen many developers successfully adapt to this transition when targeting API level 36. Now with the release of the Android 17 Beta, we’re moving to the next phase of our adaptive roadmap: Android 17 (API level 37) removes the developer opt-out for orientation and resizability restrictions on large screen devices (sw > 600 dp). When you target API level 37, your app must be capable of adapting to a variety of display sizes. The behavior changes ensure that the Android ecosystem offers a consistent, high-quality experience on all device form factors. What’s changing in Android 17 Apps targeting Android 17 must ensure their compatibility with the phase out of manifest attributes and runtime APIs introduced in Android 16. We understand for some apps this may be a big transition, so we’ve included best practices and tools for helping avoid common issues later in this blog post. No new changes have been introduced since Android 16, but the developer opt-out is no longer possible. As a reminder: when your app is running on a large screen—where large screen means that the smaller dimension of the display is greater than or equal to 600 dp—the following manifest attributes and APIs are ignored: Note: As previously mentioned with Android 16, these changes do not apply for screens that are smaller than sw 600 dp or apps categorized as games based on the android:appCategory flag. Manifest attributes/APIIgnored values screenOrientationportrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape setRequestedOrientation()portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape resizeableActivityall minAspectRatioall maxAspectRatioall Also, users retain control. In the aspect ratio settings, users can explicitly opt-in to using the app’s requested behavior. Prepare your app Apps will need to support landscape and portrait layouts for display sizes in the full range of aspect ratios in which users can choose to use apps, including resizable windows, as there will no longer be a way to restrict the aspect ratio and orientation to portrait or to landscape. Test your app Your first step is to test your app with these changes to make sure the app works well across display sizes. Use Android 17 Beta 1 with the Pixel Tablet and Pixel Fold series emulators in Android Studio, and set the targetSdkPreview = “CinnamonBun”. Alternatively, you can use the app compatibility framework by enabling the UNIVERSAL_RESIZABLE_BY_DEFAULT flag if your app does not target API level 36 yet. We have additional tools to ensure your layouts adapt correctly. You can automatically audit your UI and get suggestions to make your UI more adaptive with Compose UI Check, and simulate specific display characteristics in your tests using DeviceConfigurationOverride. For apps that have historically restricted orientation and aspect ratio, we commonly see issues with skewed or misoriented camera previews, stretched layouts, inaccessible buttons, or loss of user state when handling configuration changes.  Let’s take a look at some strategies for addressing these common issues. Ensure camera compatibility A common problem on landscape foldables or for aspect ratio calculations in scenarios like multi-window, desktop windowing, or connected displays, is when the camera preview appears stretched, rotated, or cropped. Ensure your camera preview isn’t stretched or rotated. This issue often happens on large screen and foldable devices because apps assume fixed relationships between camera features (like aspect ratio and sensor orientation) and device features (like device orientation and natural orientation). To ensure your camera preview adapts correctly to any window size or orientation, consider these four solutions: Solution 1: Jetpack CameraX (preferred)  The simplest and most robust solution is to use the Jetpack CameraX library. Its PreviewView UI element is designed to handle all preview complexities automatically: PreviewView correctly adjusts for sensor orientation, device rotation, and scaling PreviewView maintains the aspect ratio of the camera image, typically by centering and cropping (FILL_CENTER) You can set the scale type to FIT_CENTER to letterbox the preview if needed For more information, see Implement a preview in the CameraX documentation. Solution 2: CameraViewfinder  If you are using an existing Camera2 codebase, the CameraViewfinder library (backward compatible to API level 21) is another modern solution. It simplifies displaying the camera feed by using a TextureView or SurfaceView and applying all the necessary transformations (aspect ratio, scale, and rotation) for you. For more information, see the Introducing Camera Viewfinder blog post and Camera preview developer guide. Solution 3: Manual Camera2 implementation  If you can't use CameraX or CameraViewfinder, you must manually calculate the orientation and aspect ratio and ensure the calculations are updated on each configuration change: Get the camera sensor orientation (for example, 0, 90, 180, 270 degrees) from CameraCharacteristics Get the device's current display rotation (for example, 0, 90, 180, 270 degrees) Use the camera sensor orientation and display rotation values to determine the necessary transformations for your SurfaceView or TextureView Ensure the aspect ratio of your output Surface matches the aspect ratio of the camera preview to prevent distortion Important: Note the camera app might be running in a portion of the screen, either in multi-window or desktop windowing mode or on a connected display. For this reason, screen size should not be used to determine the dimensions of the camera viewfinder; use window metrics instead. Otherwise you risk a stretched camera preview. For more information, see the Camera preview developer guide and Your Camera app on different form factors video. Solution 4: Perform basic camera actions using an Intent  If you don't need many camera features, a simple and straightforward solution is to perform basic camera actions like capturing a photo or video using the device's default camera application. In this case, you can simply use an Intent instead of integrating with a camera library, for easier maintenance and adaptability.  For more information, see Camera intents. Avoid stretched UI or inaccessible buttons If your app assumes a specific device orientation or display aspect ratio, the app may run into issues when it’s now used across various orientations or window sizes. Ensure buttons, textfields, and other elements aren’t stretched on large screens. You may have set buttons, text fields, and cards to fillMaxWidth or match_parent. On a phone, this looks great. However, on a tablet or foldable in landscape, UI elements stretch across the entire large screen. In Jetpack Compose, you can use the widthIn modifier to set a maximum width for components to avoid stretched content: Box( contentAlignment = Alignment.Center, modifier = Modifier.fillMaxSize() ) { Column( modifier = Modifier .widthIn(max = 300.dp) // Prevents stretching beyond 300dp .fillMaxWidth() // Fills width up to 300dp .padding(16.dp) ) { // Your content } } If a user opens your app in landscape orientation on a foldable or tablet, action buttons like Save or Login at the bottom of the screen may be rendered offscreen. If the container is not scrollable, the user can be blocked from proceeding. In Jetpack Compose, you can add a verticalScroll modifier to your component: Column( modifier = Modifier .fillMaxSize() .verticalScroll(rememberScrollState()) .padding(16.dp) ) By combining max-width constraints with vertical scrolling, you ensure your app remains functional and usable, regardless of how wide or short the app window size becomes. See our guide on building adaptive layouts. Preserve state with configuration changes Removing orientation and aspect ratio restrictions means your app's window size will change much more frequently. Users may rotate their device, fold/unfold it, or resize your app dynamically in split-screen or desktop windowing modes. By default, these configuration changes destroy and recreate your activity. If your app does not properly manage this lifecycle event, users will have a frustrating experience: scroll positions are reset to the top, half-filled forms are wiped clean, and navigation history is lost. To ensure a seamless adaptive experience, it’s critical your app preserves state through these configuration changes. With Jetpack Compose, you can opt-out of recreation, and instead allow window size changes to recompose your UI to reflect the new amount of space available. See our guide on saving UI state. Targeting API level 37 by August 2027 If your app previously opted out of these changes when targeting API level 36, your app will only be impacted by the Android 17 opt-out removal after your app targets API level 37. To help you plan ahead and make the necessary adjustments to your app, here’s the timeline when these changes will take effect: Android 17: Changes described above will be the baseline experience for large screen devices (smallest screen width > 600 dp) for apps that target API level 37. Developers will not have an option to opt-out. The deadlines for targeting a specific API level are app-store specific. For Google Play, new apps and updates will be required to target API level 37, making this behavior mandatory for distribution in August 2027. Preparing for Android 17 Refer to the Android 17 changes page for all changes impacting apps in Android 17. To test your app, download Android 17 Beta 1 and update to targetSdkPreview = “CinnamonBun” or use the app compatibility framework to enable specific changes. The future of Android is adaptive, and we’re here to help you get there. As you prepare for Android 17, we encourage you to review our guides for building adaptive layouts and our large screen quality guidelines. These resources are designed to help you handle multiple form factors and window sizes with confidence. Don’t wait. Start getting ready for Android 17 today!

2/13/2026

Posted by Matthew McCullough, VP of Product Management, Android Developer Today we're releasing the first beta of Android 17, continuing our work to build a platform that prioritizes privacy, security, and refined performance. This build continues our work for more adaptable Android apps, introduces significant enhancements to camera and media capabilities, new tools for optimizing connectivity, and expanded profiles for companion devices. This release also highlights a fundamental shift in the way we're bringing new releases to the developer community, from the traditional Developer Preview model to the Android Canary program Beyond the Developer Preview Android has replaced the traditional "Developer Preview" with a continuous Canary channel. This new "always-on" model offers three main benefits: Faster Access: Features and APIs land in Canary as soon as they pass internal testing, rather than waiting for a quarterly release. Better Stability: Early "battle-testing" in Canary results in a more polished Beta experience with new APIs and behavior changes that are closer to being final. Easier Testing: Canary supports OTA updates (no more manual flashing) and, as a separate update channel, more easily integrates with CI workflows and gives you the earliest window to give immediate feedback on upcoming potential changes. The Android 17 schedule We're going to be moving quickly from this Beta to our Platform Stability milestone, targeted for March. At this milestone, we'll deliver final SDK/NDK APIs and largely final app-facing behaviors. From that time you’ll have several months before the final release to complete your testing. A year of releases We plan for Android 17 to continue to get updates in a series of quarterly releases. The upcoming release in Q2 is the only one where we introduce planned app breaking behavior changes. We plan to have a minor SDK release in Q4 with additional APIs and features. Orientation and resizability restrictions With the release of the Android 17 Beta, we’re moving to the next phase of our adaptive roadmap: Android 17 (API level 37) removes the developer opt-out for orientation and resizability restrictions on large screen devices (sw > 600 dp). When your app targets SDK 37, it must be ready to adapt. Users expect their apps to work everywhere—whether multitasking on a tablet, unfolding a device, or using a desktop windowing environment—and they expect the UI to fill the space and respect their device posture. Key Changes for SDK 37 Apps targeting Android 17 must ensure compatibility with the phase-out of manifest attributes and runtime APIs introduced in Android 16. When running on a large screen (smaller dimension ≥ 600dp), the following attributes and APIs will be ignored: Manifest attributes/APIIgnored values screenOrientationportrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape setRequestedOrientation()portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape resizeableActivityall minAspectRatioall maxAspectRatioall Exemptions and User Control These changes are specific to large screens; they do not apply to screens smaller than sw600dp (including traditional slate form factor phones). Additionally, apps categorized as games (based on the android:appCategory flag) are exempt from these restrictions. It is also important to note that users remain in control. They can explicitly opt-in/out to using an app’s default behavior via the system's aspect ratio settings. Updates to configuration changes To improve app compatibility and help minimize interrupted video playback, dropped input, and other types of disruptive state loss, we are updating the default behavior for Activity recreation. Starting with Android 17, the system will no longer restart activities by default for specific configuration changes that typically do not require a UI recreation, including CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_UI_MODE (when only UI_MODE_TYPE_DESK is changed), CONFIG_TOUCHSCREEN, and CONFIG_COLOR_MODE. Instead, running activities will simply receive these updates via onConfigurationChanged. If your application relies on a full restart to reload resources for these changes, you must now explicitly opt-in using the new android:recreateOnConfigChanges manifest attribute, which allows you to specify which configuration changes should trigger a complete activity lifecycle (from stop, to destroy and creation again), together with the related constants mcc, mnc, and the new ones keyboard, keyboardHidden, navigation, touchscreen and colorMode. Prepare Your App We’ve released tools and documentation to make it easy for you. Our focused blog post has more guidance, with strategies to address common issues. Apps will need to support landscape and portrait layouts for window sizes across the full range of aspect ratios, as restricting orientation or aspect ratio will no longer be an option. We recommend testing your app using the Android 17 Beta 1 with Pixel Tablet or Pixel Fold emulators (configured to targetSdkPreview = "CinnamonBun") or by using the app compatibility framework to enable UNIVERSAL_RESIZABLE_BY_DEFAULT on Android 16 devices. Performance Lock-free MessageQueue In Android 17, apps targeting SDK 37 or higher will receive a new implementation of android.os.MessageQueue where the implementation is lock-free. The new implementation improves performance and reduces missed frames, but may break clients that reflect on MessageQueue private fields and methods. Generational garbage collection Android 17 introduces generational garbage collection to ART's Concurrent Mark-Compact collector. This optimization introduces more frequent, less resource-intensive young-generation collections alongside full-heap collections. aiming to reduce overall garbage collection CPU cost and time duration. ART improvements are also available to over a billion devices running Android 12 (API level 31) and higher through Google Play System updates. Static final fields now truly final Starting from Android 17 apps targeting Android 17 or later 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 (and deep reflection) will always lead to 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 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. New performance debugging ProfilingManager triggers We’ve introduced several new system triggers to ProfilingManager to help you collect in-depth data to debug performance issues. These triggers are TRIGGER_TYPE_COLD_START, TRIGGER_TYPE_OOM, and TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE. To understand how to set up the new system triggers, check out the trigger-based profiling and retrieve and analyze profiling data documentation. Media and Camera Android 17 brings professional-grade tools to media and camera apps, with features like seamless transitions and standardized loudness. Dynamic Camera Session Updates We have introduced updateOutputConfigurations() to CameraCaptureSession. This allows you to dynamically attach and detach output surfaces without the need to reconfigure the entire camera capture session. This change enables seamless transitions between camera use cases and modes (such as shooting still images vs shooting videos) without the memory cost and code complexity of configuring and holding onto all camera output surfaces that your app might need during camera start up. This helps to eliminate user-visible glitches or freezes during operation. fun updateCameraSession(session: CameraCaptureSession, newOutputConfigs: List<OutputConfiguration>)) { // Dynamically update the session without closing and reopening try { // Update the output configurations session.updateOutputConfigurations(newOutputConfigs) } catch (e: CameraAccessException) { // Handle error } } Logical multi-camera device metadata When working with logical cameras that combine multiple physical camera sensors, you can now request additional metadata from all active physical cameras involved in a capture, not just the primary one. Previously, you had to implement workarounds, sometimes allocating unnecessary physical streams, to obtain metadata from secondary active cameras (e.g., during a lens switch for zoom where a follower camera is active). This feature introduces a new key, LOGICAL_MULTI_CAMERA_ADDITIONAL_RESULTS, in CaptureRequest and CaptureResult. By setting this key to ON in your CaptureRequest, the TotalCaptureResult will include metadata from these additional active physical cameras. You can access this comprehensive metadata using TotalCaptureResult.getPhysicalCameraTotalResults() to get more detailed information that may enable you to optimize resource usage in your camera applications. Versatile Video Coding (VVC) Support Android 17 adds support for the Versatile Video Coding (VVC) standard. This includes defining the video/vvc MIME type in MediaFormat, adding new VVC profiles in MediaCodecInfo, and integrating support into MediaExtractor. This feature will be coming to devices with hardware decode support and capable drivers. Constant Quality for Video Recording We have added setVideoEncodingQuality() to MediaRecorder. This allows you to configure a constant quality (CQ) mode for video encoders, giving you finer control over video quality beyond simple bitrate settings. Background Audio Hardening Starting in Android 17, the audio framework will enforce restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.  If the app tries to call audio APIs while the application is not in a valid lifecycle, the audio playback and volume change APIs will fail silently without an exception thrown or failure message provided. The audio focus API will fail with the result code AUDIOFOCUS_REQUEST_FAILED. Privacy and Security Deprecation of Cleartext Traffic Attribute The android:usesCleartextTraffic attribute is now deprecated. If your app targets (Android 17) or higher and relies on usesCleartextTraffic="true" without a corresponding Network Security Configuration, it will default to disallowing cleartext traffic. You are encouraged to migrate to Network Security Configuration files for granular control. HPKE Hybrid Cryptography We are introducing a public Service Provider Interface (SPI) for an implementation of HPKE hybrid cryptography, enabling secure communication using a combination of public key and symmetric encryption (AEAD). Connectivity and Telecom Enhanced VoIP Call History We are introducing user preference management for app VoIP call history integration. This includes support for caller and participant avatar URIs in the system dialer, enabling granular user control over call log privacy and enriching the visual display of integrated VoIP call logs. Wi-Fi Ranging and Proximity Wi-Fi Ranging has been enhanced with new Proximity Detection capabilities, supporting continuous ranging and secure peer-to-peer discovery. Updates to Wi-Fi Aware ranging include new APIs for peer handles and PMKID caching for 11az secure ranging. Developer Productivity and Tools Updates for companion device apps We have introduced two new profiles to the CompanionDeviceManager to improve device distinction and permission handling: Medical Devices: This profile allows medical device mobile applications to request all necessary permissions with a single tap, simplifying the setup process. Fitness Trackers: The DEVICE_PROFILE_FITNESS_TRACKER profile allows companion apps to explicitly indicate they are managing a fitness tracker. This ensures accurate user experiences with distinct icons while reusing existing watch role permissions. Also, the CompanionDeviceManager now offers a unified dialog for device association and Nearby permission requests. You can leverage the new setExtraPermissions method in AssociationRequest.Builder to bundle nearby permission prompts within the existing association flow, reducing the number of dialogs presented to the user. Get started with Android 17 You can enroll any supported Pixel device to get this and future Android Beta updates over-the-air. 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 in the Android Beta program, you will be offered an over-the-air update to Beta 1. If you have Android 26Q1 Beta and would like to take the final stable release of 26Q1 and exit Beta, you need to ignore the over-the-air update to 26Q2 Beta 1 and wait for the release of 26Q1. We're looking for your feedback so please report issues and submit feature requests on the feedback page. The earlier we get your feedback, the more we can include in our work on the final release. For the best development experience with Android 17, we recommend that you use the latest preview of Android Studio (Panda). Once you’re set up, here are some of the things you should do: Compile against the new SDK, test in CI environments, and report any issues in our tracker on the feedback page. 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 emulator running Android 17 and extensively test it. We’ll update the preview/beta system images and SDK regularly throughout the Android 17 release cycle. Once you’ve installed a beta build, you’ll automatically get future updates over-the-air for all later previews and Betas. For complete information, visit the Android 17 developer site. Join the conversation As we move toward Platform Stability and the final stable release of Android 17 later this year, your feedback remains our most valuable asset. Whether you’re an early adopter on   the Canary channel or an app developer testing on Beta 1, consider joining our communities and filing feedback. We’re listening.

1/29/2026

Posted by Phalene Gowling, Product Manager, Google Play To build a thriving business on Google Play, you need more than just data  – you need a clear path to action. Today, we’re announcing a suite of upgrades to the Google Play Console and beyond, giving you greater visibility into your financial performance and specific, data-backed steps to improve it. From new, actionable recommendations to more granular sales reporting, here’s how we’re helping you maximize your ROI. New: Monetization insights and recommendations Launch Status: Rolling out today The Monetize with Play overview page is designed to be your ultimate command center. Today, we are upgrading it with a new dynamic insights section designed to give you a clearer view of your revenue drivers. This new insights carousel highlights the visible and invisible value Google Play delivers to your bottom line – including recovered revenue. Alongside these insights, you can now track these critical signals alongside your core performance metrics: Optimize conversion: Track your new Cart Conversion Rate. Reduce churn: Track cancelled subscriptions over time. Optimize pricing: Monitor your Average Revenue Per Paying User (ARPPU). Increase buyer reach: Analyze how much of your engaged audience convert to buyers. But we aren’t just showing you the data – we’re helping you act on it. Starting today, Play Console will surface customized, actionable recommendations. If there are relevant opportunities – for example, a high churn rate – we will suggest specific, high-impact steps to help you reach your next monetization goal. Recommendations include effort levels and estimated ROI (where available), helping you prioritize your roadmap based on actual business value. Learn more. Granular visibility: Sales Channel reporting Launch Status: Recently launched We recently rolled out new Sales Channel data in your financial reporting. This allows you to attribute revenue to specific surfaces - including your app, the Play Store, and platforms like Google Play Games on PC.  For native-PC game developers and media & entertainment subscription businesses alike, this granularity allows you to calculate the precise ROI of your cross-platform investments and understand exactly which channels are driving your growth. Learn more. Operational efficiency: The Orders API Launch Status: Available now The Orders API provides programmatic access to one-time and recurring order transaction details. If you haven't integrated it yet, this API allows you to ingest real-time data directly into your internal dashboards for faster reconciliation and improved customer support. Feedback so far has been overwhelmingly positive: Level Infinite (Tencent) says the API  “works so well that we want every app to use it." Continuous improvements towards objective-led reporting  You’ve told us that the biggest challenge isn't just accessing data, but connecting the dots across different metrics to see the full picture. We’re enhancing reporting that goes beyond data dumps to provide straightforward, actionable insights that help you reach business objectives faster. Our goal is to create a more cohesive product experience centered around your objectives. By shifting from static reporting to dynamic, goal-orientated tools, we’re making it easier to track and optimize for revenue, conversion rates, and churn. These updates are just the beginning of a transformation designed to help you turn data into measurable growth.

1/28/2026

Posted by Chetan Tekur, PM at AI Innovation and Research, Chao Zhao, SWE at AI Innovation and Research, Paul Zhou, Prompt Quality Lead at GCP Cloud AI and Industry Solutions, and Caren Chang, Developer Relations Engineer at Android Automated Prompt Optimization (APO) To further help bring your ML Kit Prompt API use cases to production, we are excited to announce Automated Prompt Optimization (APO) targeting On-Device models on Vertex AI. Automated Prompt Optimization is a tool that helps you automatically find the optimal prompt for your use cases. The era of On-Device AI is no longer a promise—it is a production reality. With the release of Gemini Nano v3, we are placing unprecedented language understanding and multimodal capabilities directly into the palms of users. Through the Gemini Nano family of models, we have wide coverage of supported devices across the Android Ecosystem. But for developers building the next generation of intelligent apps, access to a powerful model is only step one. The real challenge lies in customization: How do you tailor a foundation model to expert-level performance for your specific use case without breaking the constraints of mobile hardware? In the server-side world, the larger LLMs tend to be highly capable and require less domain adaptation. Even when needed, more advanced options such as LoRA (Low-Rank Adaptation) fine-tuning can be feasible options. However, the unique architecture of Android AICore prioritizes a shared, memory-efficient system model. This means that deploying custom LoRA adapters for every individual app comes with challenges on these shared system services. But there is an alternate path that can be equally impactful. By leveraging Automated Prompt Optimization (APO) on Vertex AI, developers can achieve quality approaching fine-tuning, all while working seamlessly within the native Android execution environment. By focusing on superior system instruction, APO enables developers to tailor model behavior with greater robustness and scalability than traditional fine-tuning solutions. Note: Gemini Nano V3 is a quality optimized version of the highly acclaimed Gemma 3N model. Any prompt optimizations that are made on the open source Gemma 3N model will apply to Gemini Nano V3 as well. On supported devices, ML Kit GenAI APIs leverage the nano-v3 model to maximize the quality for Android Developers APO treats the prompt not as a static text, but as a programmable surface that can be optimized. It leverages server-side models (like Gemini Pro and Flash) to propose prompts, evaluate variations and find the optimal one for your specific task. This process employs three specific technical mechanisms to maximize performance: Automated Error Analysis: APO analyzes error patterns from training data to Automatically identify specific weaknesses in the initial prompt. Semantic Instruction Distillation: It analyzes massive training examples to distill the "true intent" of a task, creating instructions that more accurately reflect the real data distribution. Parallel Candidate Testing: Instead of testing one idea at a time, APO generates and tests numerous prompt candidates in parallel to identify the global maximum for quality. Why APO Can Approach Fine Tuning Quality It is a common misconception that fine-tuning always yields better quality than prompting. For modern foundation models like Gemini Nano v3, prompt engineering can be impactful by itself: Preserving General capabilities: Fine-tuning ( PEFT/LoRA) forces a model's weights to over-index on a specific distribution of data. This often leads to "catastrophic forgetting," where the model gets better at your specific syntax but worse at general logic and safety. APO leaves the weights untouched, preserving the capabilities of the base model. Instruction Following & Strategy Discovery: Gemini Nano v3 has been rigorously trained to follow complex system instructions. APO exploits this by finding the exact instruction structure that unlocks the model's latent capabilities, often discovering strategies that might be hard for human engineers to find.  To validate this approach, we evaluated APO across diverse production workloads. Our validation has shown consistent 5-8% accuracy gains across various use cases.Across multiple deployed on-device features, APO provided significant quality lifts. Use Case Task Type Task Description Metric APO Improvement Topic classification Text classification Classify a news article into topics such as finance, sports, etc Accuracy +5% Intent classification Text classification Classify a customer service query into intents Accuracy +8.0% Webpage translation Text translation Translate a webpage from English to a local language BLEU +8.57% A Seamless, End-to-End Developer Workflow It is a common misconception that fine-tuning always yields better quality than prompting. For modern foundation models like Gemini Nano v3, prompt engineering can be impactful by itself: Preserving General capabilities: Fine-tuning ( PEFT/LoRA) forces a model's weights to over-index on a specific distribution of data. This often leads to "catastrophic forgetting," where the model gets better at your specific syntax but worse at general logic and safety. APO leaves the weights untouched, preserving the capabilities of the base model. Instruction Following & Strategy Discovery: Gemini Nano v3 has been rigorously trained to follow complex system instructions. APO exploits this by finding the exact instruction structure that unlocks the model's latent capabilities, often discovering strategies that might be hard for human engineers to find.  To validate this approach, we evaluated APO across diverse production workloads. Our validation has shown consistent 5-8% accuracy gains across various use cases.Across multiple deployed on-device features, APO provided significant quality lifts. Conclusion The release of Automated Prompt Optimization (APO) marks a turning point for on-device generative AI. By bridging the gap between foundation models and expert-level performance, we are giving developers the tools to build more robust mobile applications. Whether you are just starting with Zero-Shot Optimization or scaling to production with Data-Driven refinement, the path to high-quality on-device intelligence is now clearer. Launch your on-device use cases to production today with ML Kit’s Prompt API and Vertex AI’s Automated Prompt Optimization.  Relevant links:  ML Kit Prompt API, Vertex AI Prompt Optimizer documentation Gemma 3N Announcement Blog