Search Results

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

What's new in the Jetpack Compose August '26 release

Matched "Google Developers"Found in Description

Mobile GamesRelease

What's new in the Jetpack Compose August '26 release

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

Android Developers BlogAugust 12, 20268 min read

Inside Android Skills - Built for deprecation

Matched "Google Developers"Found in Description

MobileRelease

Inside Android Skills - Built for deprecation

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

Android Developers BlogAugust 6, 20265 min read