We’re in an important moment where AI changes everything, from how we work to the expectations that users have for your apps, and our goal on Android is to transform this AI evolution into opportunities for you and your users. Today in our Fall episode of The Android Show, we unpacked a bunch of new updates towards delivering the highest return on investment in building for the Android platform. From new agentic experiences for Gemini in Android Studio to a brand new on-device AI API to the first Android XR device, there’s so much to cover – let’s dive in! 

Build your own custom Gen AI features with the new Prompt API

On Android, we offer AI models on-device, or in the cloud.  Today, we’re excited to now give you full flexibility to shape the output of the Gemini Nano model by passing in any prompt you can imagine with the new Prompt API, now in Alpha. For flagship Android devices, Gemini Nano lets you build efficient on-device options where the users’ data never leaves their device. At I/O this May, we launched our on-device GenAI APIs using the Gemini Nano model, making common tasks easier with simple APIs for tasks like summarization, proofreading and image description. Kakao used the Prompt API to transform their parcel delivery service, replacing a slow, manual process where users had to copy and paste details into a form into just a simple message requesting a delivery, and the API automatically extracts all the necessary information. This single feature reduced order completion time by 24% and boosted new user conversion by an incredible 45%.

Tap into Nano Banana and Imagen using the Firebase SDK 

When you want to add cutting-edge capabilities across the entire fleet of Android devices, our  cloud-based AI solutions with Firebase AI Logic are a great fit. The excitement for models like Gemini 2.5 Flash Image (a.k.a. Nano Banana) and Imagen have been incredible; now your users can now generate and edit images using Nano Banana, and then for finer control, like selecting and transforming specific parts of an image, users can use the new mask-based editing feature that leverages the Imagen model. See our blog post to learn more. And beyond image generation, you can also use Gemini multimodal capabilities to process text, audio and image input. RedBus, for example, revolutionized their user reviews using Gemini Flash via Firebase AI Logic to make giving feedback easier, more inclusive, and reliable. The old problem? Short, low-quality text reviews. The new solution? Users can now leave reviews using voice input in their native languages. From the audio Gemini Flash is then generating a structured text response enabling longer, richer and more reliable user reviews. It’s a win for everyone: travelers, operators, and developers!

Helping you be more productive, with agentic experiences in Android Studio

Helping you be more productive is our goal with Gemini in Android Studio, and why we’re infusing AI across our tooling. Developers like Pocket FM have seen an impressive development time savings of 50%. With the recent launch of Agent Mode, you can describe a complex goal in natural language and (with your permission), the agent plans and executes changes on multiple files across your project. The agent’s answers are now grounded in the most modern development practices, and can even cross-reference our latest documentation in real time. We demoed new agentic experiences such as updates to Agent Mode, the ability to upgrade APIs on your behalf, the new project assistant, and we announced you’ll be able to bring any LLM of your choice to power the AI functionality inside Android Studio, giving you more flexibility and choice on how you incorporate AI into your workflow. And for the newest stable features such as Back Up and Sync, make sure to download the latest stable version of Android Studio.

Elevating AI-assisted Android development, and improving LLMs with an Android benchmark

Our goal is to make it easier for Android developers to build great experiences. With more code being written by AI, developers have been asking for models that know more about Android development. We want to help developers be more productive, and that’s why we’re building a new task set for LLMs against a range of common Android development areas. The goal is to provide LLM makers with a benchmark, a north star of high quality Android development, so Android developers have a range of helpful models to choose for AI assistance. 

To reflect the challenges of Android development, the benchmark is composed of real-world problems sourced from public GitHub Android repositories. Each evaluation attempts to have an LLM recreate a pull request, which are then verified using human authored tests. This 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’re finalizing the task set we’ll be testing against LLMs, and will be sharing the results publicly in the coming months. We’re looking forward to seeing how this shapes AI assisted Android development, and the additional flexibility and choice it gives you to build on Android.

Ink API is now in beta and is ready to be integrated in your app.. This milestone was made possible by valuable developer feedback, leading to continuous improvements in the API’s performance, stability, and visual quality.

Google apps, such as Google Docs, Pixel Studio, Google Photos, Chrome PDF, Youtube Effect Maker, and unique features on Android such as Circle to Search all use the latest APIs. 

To mark this milestone, we’re excited to announce the launch of Cahier, a comprehensive note-taking app sample optimized for Android devices of all sizes particularly tablets and foldable phones.

What is Cahier?

Cahier (“notebook” in French) is a sample app designed to demonstrate how you can build an application that enables users to capture and organize their thoughts by combining text, drawings, and images. 

The sample can serve as the go-to reference for enhancing user productivity and creativity on large screens. It showcases best practices for building such experiences, accelerating developer understanding and adoption of related powerful APIs and techniques. This post walks you through the core features of Cahier, key APIs, and the architectural decisions that make the sample a great reference for your own apps.

Key features demonstrated in the sample include:

• Versatile note creation: Shows how to implement a flexible content creation system that supports multiple formats within a single note, including text, freeform drawings, and image attachments.

• Creative inking tools: Implements a high performance, low latency drawing experience using the Ink API. The sample provides a practical example of integrating various brushes, a color picker, undo/redo functionality, and an eraser tool.

• Fluid content integration with drag and drop: Demonstrates how to handle both incoming and outgoing content using drag and drop. This includes accepting images dropped from other apps and enabling users to drag content out of your app for seamless sharing.

• Note organization: Mark notes as favorites for quick access. Filter the view to stay organized.

• Offline first architecture:  Built with an offline first architecture using Room, ensuring all data is saved locally and the app remains fully functional without an internet connection.

• Powerful multi-window and multi-instance support: Showcases how to support multi-instance, allowing your app to be launched in multiple windows so users can work on different notes side by side, enhancing productivity and creativity on large screens.

• Adaptive UI for all screens: The user interface seamlessly adapts to different screen sizes and orientations using ListDetailPaneScaffold and NavigationSuiteScaffold to provide an optimized user experience on phones, tablets, and foldables.

• Deep system integration: Provides a guide on how to make your app the default note-taking app on Android 14 and higher by responding to system wide Notes intents, enabling quick content capture from various system entry points.

Built for productivity and creativity on large screens

For the initial launch, we’re centering the announcement on a few core features that make Cahier a key learning resource for both productivity and creativity use cases.

A foundation of adaptivity

Cahier is built to be adaptive from the ground up. The sample utilizes the material3-adaptive library specifically ListDetailPaneScaffold and NavigationSuiteScaffold to seamlessly adapt the app layout to various screen sizes and orientations. This is a crucial element for a modern Android app, and Cahier provides a clear example of how to implement it effectively.

Cahier adaptive UI built with Material 3 Adaptive library.

Showcasing key APIs and integrations

The sample is focused on showcasing powerful productivity APIs that you can leverage in your own applications, including:

• Ink API

• Notes role

• Multi-instance, Multi-window, and Desktop windowing

• Drag and drop

A Closer look at key APIs

Let’s dive deeper into two of the cornerstone APIs that Cahier integrates to deliver a first class note-taking experience.

Creating natural inking experiences with the Ink API

Stylus input transforms large screen devices into digital notebooks and sketchbooks. To help you build fluid and natural inking experiences, we’ve made the Ink API a cornerstone of the sample. Ink API makes it easy to create, render, and manipulate beautiful ink strokes with best in class low latency.

Ink API offers a modular architecture, so you can tailor it to your app’s specific stack and needs. The API modules include:

• Authoring modules (Compose – views): Handle realtime inking input to create smooth strokes with the lowest latency a device can provide.

In DrawingSurface, Cahier uses the newly introduced InProgressStrokes composable to handle realtime stylus or touch input. This module is responsible for capturing pointer events and rendering wet ink strokes with the lowest possible latency.

• Strokes module: Represents the ink input and its visual representation.  a user finishes drawing a line, the onStrokesFinished callback provides a finalized/dry Stroke object to the app. This immutable object, representing the completed ink stroke, is then managed in DrawingCanvasViewModel.

• Rendering module: Efficiently displays ink strokes, allowing them to be combined with Jetpack Compose or Android views.

To display both existing and newly dried strokes, Cahier uses CanvasStrokeRenderer  in DrawingSurface for active drawing and in DrawingDetailPanePreview for showing a static preview of the note. This module efficiently draws the Stroke objects onto a Canvas.

• Brush modules (Compose – views): Provide a declarative way to define the visual style of strokes. Recent updates (since the alpha03 release) include a new dashed line brush, particularly useful for features like lasso selection. DrawingCanvasViewModel holds the state for the currentBrush. A toolbox in DrawingCanvas allows users to select different brush families (like StockBrushes.pressurePen() or StockBrushes.highlighter()) and change colors. The ViewModel updates the Brush object, which is then used by the InProgressStrokes composable for new strokes.

• Geometry modules (Compose – views): Support manipulating and analyzing strokes for features like erasing and selecting.

The eraser tool within the toolbox and functionality in DrawingCanvasViewModel rely on the geometry module. When the eraser is active, it creates a MutableParallelogram around the path of the user’s gesture. The eraser then checks for intersections between the shape and bounding boxes of existing strokes to determine which strokes to erase, making the eraser feel intuitive and precise.

• Storage module: Provides efficient serialization and deserialization capabilities for ink data, leading to significant disk and network size savings. To save drawings, Cahier persists the Stroke objects in its Room database. In Converters, the sample uses the storage module’s encode function to serialize the StrokeInputBatch (the raw point data) into a ByteArray. The byte array, along with brush properties, is saved as a JSON string. The decode function is used to reconstruct the strokes when a note is loaded.

Beyond these core modules, recent updates have expanded the Ink API’s capabilities:

• New experimental APIs for custom BrushFamily objects empower developers to create creative and unique brush types, providing the possibilities for tools like Pencil and Laser Pointer brushes.

Cahier leverages custom brushes, including the unique music brush showcased below, to illustrate advanced creative possibilities.

Rainbow laser created with Ink API’s custom brushes.

Music brush created with Ink API’s custom brushes.

• Native Jetpack Compose interoperability modules streamline the integration of inking functionalities directly within your Compose UIs for a more idiomatic and efficient development experience.

Ink API offers several advantages that make it the ideal choice for productivity and creativity apps over a custom implementation:

• Ease of use: Ink API abstracts away the complexities of graphics and geometry, allowing you to focus on Cahier’s core features.

• Performance: Built-in low latency support and optimized rendering ensure a smooth and responsive inking experience.

• Flexibility: The modular design allows you to pick and choose the components needed, which enables seamless integration of the Ink API into Cahier’s architecture.

Ink API has already been adopted across many Google apps, including for markup in Docs and for Circle to Search as well as partner apps like Orion Notes, and PDF Scanner.

“Ink API was our first choice for Circle-to-Search (CtS). Utilizing their extensive documentation, integrating the Ink API was a breeze, allowing us to reach our first working prototype w/in just one week. Ink’s custom brush texture and animation support allowed us to quickly iterate on the stroke design.” – Jordan Komoda, Software Engineer – Google.

Becoming the default notes app with notes role

Note-taking is a core capability that enhances user productivity on large screen devices. With the notes role feature, users can access  your compatible apps from the lock screen or while other apps are running. This feature identifies and sets system wide default note-taking apps and grants them permission to be launched for capturing content. 

Implementation in Cahier

Implementing the notes role involves a few key steps, all demonstrated in the sample:

1. Manifest declaration: First, the app must declare its capability to handle note-taking intents. In AndroidManifest.xml, Cahier includes an <intent-filter> for the android.intent.action.CREATE_NOTE action. This signals to the system that the app is a potential candidate for the notes role.

2. Checking role status: SettingsViewModel uses Android’s RoleManager to determine the current status. SettingsViewModel checks whether the notes role is available on the device (isRoleAvailable) and whether Cahier currently holds that role (isRoleHeld). This state is exposed to the UI using Kotlin flows.

3. Requesting the role: In the Settings.kt file, a Button is displayed to the user if the role is available but not held. When clicked, the button calls the requestNotesRole function in the ViewModel. The function creates an intent to open the default app settings screen where the user can select Cahier. The process is managed using the rememberLauncherForActivityResult API, which handles launching the intent and receiving the result.

4. Updating the UI: After the user returns from the settings screen, the ActivityResultLauncher callback triggers a function in the ViewModel to update the role status, ensuring the UI accurately reflects whether the app is now the default.

Learn how to integrate the notes role in your app in our create a note-taking app guide.

Cahier launched in a floating window as the default note-taking app on a Lenovo tablet.

A major step forward: Lenovo enables notes role

We’re thrilled to announce a major step forward for large screen Android productivity: Lenovo has enabled support for Notes Role on tablets running Android 15 and higher! With this update, you can now update your note-taking apps to allow users with compatible Lenovo devices to set them as default, granting seamless access from the lock screen and unlocking system level content capture features.

This commitment from a leading OEM demonstrates the growing importance of the notes role in delivering a truly integrated and productive user experience on Android. 

Multi-instance, multi-windowing, and desktop windowing

Productivity on a large screen is all about managing information and workflows efficiently. That’s why Cahier is built to fully embrace Android’s advanced windowing capabilities, providing a flexible workspace that adapts to user needs. The app supports:

• Multi-windowing: The fundamental ability to run alongside another app in split-screen or free-form mode. This is essential for tasks like referencing a web page while taking notes in Cahier. 

• Multi-instance: This is where true multitasking shines. Cahier allows users to open multiple, independent windows of the app simultaneously. Imagine comparing two different notes side by side or referencing a text note in one window while working on a drawing in another. Cahier demonstrates how to manage these separate instances, each with its own state, turning your app into a powerful, multifaceted tool.

• Desktop windowing: When connected to an external display, Android desktop mode transforms a tablet or foldable into a workstation. Because Cahier is built with an adaptive UI and supports multi-instance, the app performs beautifully in this environment. Users can open, resize, and position multiple Cahier windows just like on a traditional desktop, enabling complex workflows that were previously out of reach on mobile devices.

Cahier running in desktop window mode on Pixel Tablet.

Here’s how we implemented these features in Cahier:

To enable multi-instance, we first needed to signal to the system that the app supports being launched multiple times by adding the PROPERTY_SUPPORTS_MULTI_INSTANCE_SYSTEM_UI property to MainActivity ‘s declaration in AndroidManifest:

Next, we implemented the logic to launch a new instance of the app. In CahierHomeScreen.kt, when a user opts to open a note in a new window, we create a new Intent with specific flags that instruct the system on how to handle the new activity launch. The combination of FLAG_ACTIVITY_NEW_TASK, FLAG_ACTIVITY_MULTIPLE_TASK, and FLAG_ACTIVITY_LAUNCH_ADJACENT ensures the note opens in a new, separate window alongside the existing one.

To support multi-window mode, we needed to signal to the system that the app supports resizability by setting the Manifest’s <activity> or <application> element.

The UI itself being built with the Material 3 adaptive library enables it to adapt seamlessly in multi-window scenarios like Android’s split screen mode. 

To enhance user experience, we added support for drag and drop. See below how we implemented this in Cahier.

Drag and drop

A truly productive or creative app doesn’t function in isolation; it interacts seamlessly with the rest of the device’s ecosystem. Drag and drop is a cornerstone of this interaction, especially on large screens where users are often working across multiple app windows. Cahier fully embraces this by implementing intuitive drag and drop functionality for both adding and sharing content.

• Effortless Importing: Users can drag images from other applications—like a web browser, photo gallery, or file manager—and drop them directly onto a note canvas. For this, Cahier uses the dragAndDropTarget modifier to define a drop zone, check for compatible content (like image/*), and process the incoming URI.

• Simple sharing: Content inside Cahier is just as easy to share as content from other apps. Users can long-press an image within a text note, or long-press the entire canvas of a drawing note and image composite, and drag it out to another application.

Technical deep dive: Dragging from the drawing canvas

Implementing the drag gesture on the drawing canvas presents a unique challenge. In our DrawingSurface, the composables that handle live drawing input (the Ink API’s InProgressStrokes) and the Box that detects the long-press gesture to initiate a drag are sibling composables.

By default, the Jetpack Compose pointer input system is designed so that just one sibling composable —the first one in declaration order that overlaps the touch location—receives the event. In Cahier’s case, we want our drag-and-drop input handling logic to have a chance to run and potentially consume inputs before the InProgressStrokes composable uses all unconsumed input for drawing and then consumes that input. If we don’t arrange things in the right order, our Box won’t detect the long-press gesture to start a drag, or InProgressStrokes won’t receive the input to draw.

To solve this, we created a custom pointerInputWithSiblingFallthrough modifier, and we put our Box using that modifier before InProgressStrokes in the composable code. This utility is a thin wrapper around the standard pointerInput system but with one critical change: it overrides the sharePointerInputWithSiblings() function to return true. This tells the Compose framework to allow pointer events to pass through to sibling composables, even after being consumed.

Here’s how it’s used in DrawingSurface:

With this in place, the system correctly detects both the drawing strokes and the long-press drag gesture simultaneously. Once the drag is initiated, we create a shareable content:// URI with FileProvider and pass the URI to the system’s drag and drop framework using view.startDragAndDrop(). This solution ensures a robust and intuitive user experience, showcasing how to overcome complex gesture conflicts in layered UIs.

Built with modern architecture

Beyond specific APIs, Cahier demonstrates crucial architectural patterns for building high-quality, adaptive applications.

The presentation layer: Jetpack Compose and adaptability

The presentation layer is built entirely with Jetpack Compose. As mentioned, Cahier adopts the material3-adaptive library for UI adaptability. State management follows a strict Unidirectional Data Flow (UDF) pattern, with ViewModel instances used as data containers that hold note information and UI state.

The data layer: Repositories and Room

For the data layer, Cahier uses a NoteRepository interface to abstract all data operations. This design choice cleanly allows the app to swap between a local data source (Room) and a potential future remote backend. The data flow for an action like editing a note is straightforward:

1. The Jetpack Compose UI triggers a method in the ViewModel.

2. The ViewModel fetches the note from NoteRepository, handles the logic, and passes the updated note back to the repository.

3. NoteRepository saves the update to a Room database.

Comprehensive input support

To be a true productivity powerhouse, an app must handle a variety of input methods flawlessly. Cahier is built to be compliant with large screen input guidelines and supports:

• Stylus: Integration with the Ink API, palm rejection, registration for the notes role, stylus input in text fields, and immersive mode.

• Keyboard: Support for most common keyboard shortcuts and combinations (like ctrl+click, meta+click) and clear indication for keyboard focus.

• Mouse and trackpad: Support for right-click and hover states.

Support for advanced keyboard, mouse, and trackpad interactions is a key focus for further improvements. 

Get started today

We hope Cahier serves as a launchpad for your next great app. We built it to be a comprehensive, open source resource that demonstrates how to combine an adaptive UI, powerful APIs like Ink and notes role, and a modern, adaptive architecture.

Ready to dive in?

• Explore the code: Head over to our GitHub repository to explore the Cahier codebase and see the design principles in action.

• Build your own: Use Cahier as a foundation for your own note-taking, document markup, or creative application.

• Contribute: We welcome your contributions! Help us make Cahier an even better resource for the Android developer community.

Check out the official developer guides and start building your next generation productivity and creativity app today. We can’t wait to see what you create!

Capturing fast-moving action with clarity is a key feature for modern camera apps. This is achieved through high-speed capture—the process of acquiring frames at rates like 120 or 240 fps. This high-fidelity capture can be used for two distinct purposes: creating a high-frame-rate video for detailed, frame-by-frame analysis, or generating a slow-motion video where action unfolds dramatically on screen.

Previously, implementing these features with the Camera2 API was a more hands-on process. Now, with the new high-speed API in CameraX 1.5, the entire process is simplified, giving you the flexibility to create either true high-frame-rate videos or ready-to-play slow-motion clips. This post will show you how to master both. For those new to CameraX, you can get up to speed with the CameraX Overview.

The Principle Behind Slow-Motion

The fundamental principle of slow-motion is to capture video at a much higher frame rate than it is played back. For instance, if you record a one-second event at 120 frames per second (fps) and then play that recording back at a standard 30 fps, the video will take four seconds to play. This “stretching” of time is what creates the dramatic slow-motion effect, allowing you to see details that are too fast for the naked eye.

To ensure the final output video is smooth and fluid, it should typically be rendered at a minimum of 30 fps. This means that to create a 4x slow-motion video, the original capture frame rate must be at least 120 fps (120 capture fps ÷ 4 = 30 playback fps).

Once the high-frame-rate footage is captured, there are two primary ways to achieve the desired outcome:

• Player-handled Slow-Motion (High-Frame-Rate Video): The high-speed recording (e.g., 120 fps) is saved directly as a high-frame-rate video file. It is then the video player’s responsibility to slow down the playback speed. This gives the user flexibility to toggle between normal and slow-motion playback.

• Ready-to-play Slow-Motion (Re-encoded Video): The high-speed video stream is processed and re-encoded into a file with a standard frame rate (e.g., 30 fps). The slow-motion effect is “baked in” by adjusting the frame timestamps. The resulting video will play in slow motion in any standard video player without special handling. While the video plays in slow motion by default, video players can still provide playback speed controls that allow the user to increase the speed and watch the video at its original speed.

The CameraX API simplifies this by giving you a unified way to choose which approach you want, as you’ll see below.

The New High-Speed Video API

The new CameraX solution is built on two main components:

• Recorder#getHighSpeedVideoCapabilities(CameraInfo): This method lets you check if the camera can record in high-speed and, if so, which resolutions (Quality objects) are supported.

• HighSpeedVideoSessionConfig: This is a special configuration object that groups your VideoCapture and Preview use cases, telling CameraX to create a unified high-speed camera session. Note that while the VideoCapture stream will operate at the configured high frame rate, the Preview stream will typically be limited to a standard rate of at least 30 FPS by the camera system to ensure a smooth display on the screen.

Getting Started

Before you start, make sure you have added the necessary CameraX dependencies to your app’s build.gradle.kts file. You will need the camera-video artifact along with the core CameraX libraries.

A Note on Experimental APIs

It’s important to note that the high-speed recording APIs are currently experimental. This means they are subject to change in future releases. To use them, you must opt-in by adding the following annotation to your code:

Implementation

The implementation for both outcomes starts with the same setup steps. The choice between creating a high-frame-rate video or a slow-motion video comes down to a single setting.

1. Set up High-Speed Capture

First, regardless of your goal, you need to get the ProcessCameraProvider, check for device capabilities, and create your use cases.

The following code block shows the complete setup flow within a suspend function. You can call this function from a coroutine scope, like lifecycleScope.launch.

2. Choosing Your Output

Now, you decide what kind of video you want to create. This code would run inside the setupCamera() suspend function shown above.

Option A: Create a High-Frame-Rate Video

Choose this option if you want the final file to have a high frame rate (e.g., a 120fps video).

Option B: Create a Ready-to-play Slow-Motion Video

Choose this option if you want a video that plays in slow motion automatically in any standard video player.

This single flag is the key to creating a ready-to-play slow-motion video. When setSlowMotionEnabled is true, CameraX processes the high-speed stream and saves it as a standard 30 fps video file. The slow-motion speed is determined by the ratio of the capture frame rate to this standard playback rate.

For example:

• Recording at 120 fps will produce a video that plays back at 1/4x speed (120 ÷ 30 = 4).

• Recording at 240 fps will produce a video that plays back at 1/8x speed (240 ÷ 30 = 8).

Putting It All Together: Recording the Video

Once you have configured your HighSpeedVideoSessionConfig and bound it to the lifecycle, the final step is to start the recording. The process of preparing output options, starting the recording, and handling video events is the same as it is for a standard video capture.

This post focuses on high-speed configuration, so we won’t cover the recording process in detail. For a comprehensive guide on everything from preparing a FileOutputOptions or MediaStoreOutputOptions object to handling the VideoRecordEvent callbacks, please refer to the VideoCapture documentation.

Google Photos Support for Slow-Motion Videos

When you enable setSlowMotionEnabled(true) in CameraX, the resulting video file is designed to be instantly recognizable and playable as slow-motion in standard video players and gallery apps. Google Photos, in particular, offers enhanced functionality for these slow-motion videos, when the capture frame rate is 120, 240, 360, 480 or 960fps:

• Distinct UI Recognition in Thumbnail: In your Google Photos library, slow-motion videos can be identified by specific UI elements, distinguishing them from normal videos.

• Adjustable Speed Segments during Playback: When playing a slow-motion video, Google Photos provides controls to adjust which parts of the video play at slow speed and which play at normal speed, giving users creative control. The edited video can then be exported as a new video file using the Share button, preserving the slow-motion segments you defined.

A Note on Device Support

CameraX’s high-speed API relies on the underlying Android CamcorderProfile system to determine which high-speed resolutions and frame rates a device supports. CamcorderProfiles are validated by the Android Compatibility Test Suite (CTS), which means you can be confident in the device’s reported video recording capabilities.

This means that a device’s ability to record slow-motion video with its built-in camera app does not guarantee that the CameraX high-speed API will function. This discrepancy occurs because device manufacturers are responsible for populating the CamcorderProfile entries in their device’s firmware, and sometimes necessary high-speed profiles like CamcorderProfile.QUALITY_HIGH_SPEED_1080P and CamcorderProfile.QUALITY_HIGH_SPEED_720P are not included. When these profiles are missing, Recorder.getHighSpeedVideoCapabilities() will return null.

Therefore, it’s essential to always use Recorder.getHighSpeedVideoCapabilities() to check for supported features programmatically, as this is the most reliable way to ensure a consistent experience across different devices. If you try to bind a HighSpeedVideoSessionConfig on a device where Recorder.getHighSpeedVideoCapabilities() returns null, the operation will fail with an IllegalArgumentException. You can confirm support on Google Pixel devices, as they consistently include these high-speed profiles. Additionally, various devices from other manufacturers, such as the Motorola Edge 30, OPPO Find N2 Flip, and Sony Xperia 1 V, also support the high-speed video capabilities.

Conclusion

The CameraX high-speed video API is both powerful and flexible. Whether you need true high-frame-rate footage for technical analysis or want to add cinematic slow-motion effects to your app, the HighSpeedVideoSessionConfig provides a unified and simple solution. By understanding the role of the setSlowMotionEnabled flag, you can easily support both use cases and give your users more creative control.

We’re excited to announce that Material 3 Adaptive 1.2.0 is now stable!

This release continues to build on the foundations of previous versions, expanding support to more breakpoints for window size classes and new strategies to place display panes automatically.

What’s new in Material 3 Adaptive 1.2.0

This stable release is built on top of WindowManager 1.5.0 support for large and extra large breakpoints, and introduces the new reflow and levitate strategies for ListDetailPaneScaffold and SupportingPaneScaffold. 

New window size classes: Large and Extra-large

WindowManager 1.5.0 introduced two new breakpoints for width window size class to support even bigger windows than the Expanded window size class. The Large (L) and Extra-large (XL) breakpoints can be enabled by adding the following parameter to the currentWindowAdaptiveInfo() call  in your codebase:

This flag enables the library to also return L and XL breakpoints whenever they’re needed.

New adaptive strategies: reflow and levitate

Arranging content and display panes in a window is a complex task that needs to take into account many factors, starting with window size. With the new Material 3 Adaptive library, two new technologies can help you achieve an adaptive layout with minimal effort.

With reflow, panes are rearranged when window size or aspect ratio changes, placing a second pane to the side of the first one when the window is wide enough, or reflow the second pane underneath the first pane whenever the window is taller. This technique applies also when the window becomes smaller: content reflows to the bottom.

Reflowing a pane based on the window size

While reflowing is an incredible option in many cases, there might be situations in which the content might need to be either docked to a side of the window or levitated on top of it. The levitate strategy not only docks the content, but also allows you to customize features like draggability, resizability, and even the background scrim.

Levitating a pane from the side to the center based on the aspect ratio

Both the flow and levitate strategies can be declared inside the Navigator constructor using the adaptStrategies parameter, and both strategies can be applied to list-detail and supporting pane scaffolds:

To learn more about how to leverage these new adaptive strategies, see the Material website and the complete sample code on GitHub.