HTTPS by default

One year from now, with the release of Chrome 154 in October 2026, we will change the default settings of Chrome to enable “Always Use Secure Connections”. This means Chrome will ask for the user's permission before the first access to any public site without HTTPS.

The “Always Use Secure Connections” setting warns users before accessing a site without HTTPS

Chrome Security's mission is to make it safe to click on links. Part of being safe means ensuring that when a user types a URL or clicks on a link, the browser ends up where the user intended. When links don't use HTTPS, an attacker can hijack the navigation and force Chrome users to load arbitrary, attacker-controlled resources, and expose the user to malware, targeted exploitation, or social engineering attacks. Attacks like this are not hypothetical—software to hijack navigations is readily available and attackers have previously used insecure HTTP to compromise user devices in a targeted attack.

Since attackers only need a single insecure navigation, they don't need to worry that many sites have adopted HTTPS—any single HTTP navigation may offer a foothold. What's worse, many plaintext HTTP connections today are entirely invisible to users, as HTTP sites may immediately redirect to HTTPS sites. That gives users no opportunity to see Chrome's "Not Secure" URL bar warnings after the risk has occurred, and no opportunity to keep themselves safe in the first place.

To address this risk, we launched the “Always Use Secure Connections” setting in 2022 as an opt-in option. In this mode, Chrome attempts every connection over HTTPS, and shows a bypassable warning to the user if HTTPS is unavailable. We also previously discussed our intent to move towards HTTPS by default. We now think the time has come to enable “Always Use Secure Connections” for all users by default.

Now is the time.

For more than a decade, Google has published the HTTPS transparency report, which tracks the percentage of navigations in Chrome that use HTTPS. For the first several years of the report, numbers saw an impressive climb, starting at around 30-45% in 2015, and ending up around the 95-99% range around 2020. Since then, progress has largely plateaued.

HTTPS adoption expressed as a percentage of main frame page loads

This rise represents a tremendous improvement to the security of the web, and demonstrates that HTTPS is now mature and widespread. This level of adoption is what makes it possible to consider stronger mitigations against the remaining insecure HTTP.

Balancing user safety with friction

While it may at first seem that 95% HTTPS means that the problem is mostly solved, the truth is that a few percentage points of HTTP navigations is still a lot of navigations. Since HTTP navigations remain a regular occurrence for most Chrome users, a naive approach to warning on all HTTP navigations would be quite disruptive. At the same time, as the plateau demonstrates, doing nothing would allow this risk to persist indefinitely. To balance these risks, we have taken steps to ensure that we can help the web move towards safer defaults, while limiting the potential annoyance warnings will cause to users.

One way we're balancing risks to users is by making sure Chrome does not warn about the same sites excessively. In all variants of the "Always Use Secure Connections" settings, so long as the user regularly visits an insecure site, Chrome will not warn the user about that site repeatedly. This means that rather than warn users about 1 out of 50 navigations, Chrome will only warn users when they visit a new (or not recently visited) site without using HTTPS.

To further address the issue, it's important to understand what sort of traffic is still using HTTP. The largest contributor to insecure HTTP by far, and the largest contributor to variation across platforms, is insecure navigations to private sites. The graph above includes both those to public sites, such as example.com, and navigations to private sites, such as local IP addresses like 192.168.0.1, single-label hostnames, and shortlinks like intranet/. While it is free and easy to get an HTTPS certificate that is trusted by Chrome for a public site, acquiring an HTTPS certificate for a private site unfortunately remains complicated. This is because private names are "non-unique"—private names can refer to different hosts on different networks. There is no single owner of 192.168.0.1 for a certification authority to validate and issue a certificate to.

HTTP navigations to private sites can still be risky, but are typically less dangerous than their public site counterparts because there are fewer ways for an attacker to take advantage of these HTTP navigations. HTTP on private sites can only be abused by an attacker also on your local network, like on your home wifi or in a corporate network.

If you exclude navigations to private sites, then the distribution becomes much tighter across platforms. In particular, Linux jumps from 84% HTTPS to nearly 97% HTTPS when limiting the analysis to public sites only. Windows increases from 95% to 98% HTTPS, and both Android and Mac increase to over 99% HTTPS.

In recognition of the reduced risk HTTP to private sites represents, last year we introduced a variant of “Always Use Secure Connections” for public sites only. For users who frequently access private sites (such as those in enterprise settings, or web developers), excluding warnings on private sites significantly reduces the volume of warnings those users will see. Simultaneously, for users who do not access private sites frequently, this mode introduces only a small reduction in protection. This is the variant we intend to enable for all users next year.

“Always Use Secure Connections,” available at chrome://settings/security

In Chrome 141, we experimented with enabling “Always Use Secure Connections” for public sites by default for a small percentage of users. We wanted to validate our expectations that this setting keeps users safer without burdening them with excessive warnings.

Analyzing the data from the experiment, we confirmed that the number of warnings seen by any users is considerably lower than 3% of navigations—in fact, the median user sees fewer than one warning per week, and the ninety-fifth percentile user sees fewer than three warnings per week..

Understanding HTTP usage

Once “Always Use Secure Connections” is the default and additional sites migrate away from HTTP, we expect the actual warning volume to be even lower than it is now. In parallel to our experiments, we have reached out to a number of companies responsible for the most HTTP navigations, and expect that they will be able to migrate away from HTTP before the change in Chrome 154. For many of these organizations, transitioning to HTTPS isn't disproportionately hard, but simply has not received attention. For example, many of these sites use HTTP only for navigations that immediately redirect to HTTPS sites—an insecure interaction which was previously completely invisible to users.

Another current use case for HTTP is to avoid mixed content blocking when accessing devices on the local network. Private addresses, as discussed above, often do not have trusted HTTPS certificates, due to the difficulties of validating ownership of a non-unique name. This means most local network traffic is over HTTP, and cannot be initiated from an HTTPS page—the HTTP traffic counts as insecure mixed content, and is blocked. One common use case for needing to access the local network is to configure a local network device, e.g. the manufacturer might host a configuration portal at config.example.com, which then sends requests to a local device to configure it.

Previously, these types of pages needed to be hosted without HTTPS to avoid mixed content blocking. However, we recently introduced a local network access permission, which both prevents sites from accessing the user’s local network without consent, but also allows an HTTPS site to bypass mixed content checks for the local network once the permission has been granted. This can unblock migrating these domains to HTTPS.

Changes in Chrome

We will enable the "Always Use Secure Connections" setting in its public-sites variant by default in October 2026, with the release of Chrome 154. Prior to enabling it by default for all users, in Chrome 147, releasing in April 2026, we will enable Always Use Secure Connections in its public-sites variant for the over 1 billion users who have opted-in to Enhanced Safe Browsing protections in Chrome.

While it is our hope and expectation that this transition will be relatively painless for most users, users will still be able to disable the warnings by disabling the "Always Use Secure Connections" setting.

If you are a website developer or IT professional, and you have users who may be impacted by this feature, we very strongly recommend enabling the "Always Use Secure Connections" setting today to help identify sites that you may need to work to migrate. IT professionals may find it useful to read our additional resources to better understand the circumstances where warnings will be shown, how to mitigate them, and how organizations that manage Chrome clients (like enterprises or educational institutions) can ensure that Chrome shows the right warnings to meet those organizations' needs.

Looking Forward

While we believe that warning on insecure public sites represents a significant step forward for the security of the web, there is still more work to be done. In the future, we hope to work to further reduce barriers to adoption of HTTPS, especially for local network sites. This work will hopefully enable even more robust HTTP protections down the road.

Posted by Chris Thompson, Mustafa Emre Acer, Serena Chen,Joe DeBlasio, Emily Stark and David Adrian, Chrome Security Team

High-Speed Capture and Slow-Motion Video with CameraX 1.5

Posted by Leo Huang, Software Engineer


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.


// build.gradle.kts (Module: app)


dependencies {

    val camerax_version = "1.5.1"


    implementation("androidx.camera:camera-core:$camerax_version")

    implementation("androidx.camera:camera-camera2:$camerax_version")

    implementation("androidx.camera:camera-lifecycle:$camerax_version")

    implementation("androidx.camera:camera-video:$camerax_version")

    implementation("androidx.camera:camera-view:$camerax_version")

}


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:

@kotlin.OptIn(ExperimentalSessionConfig::class, ExperimentalHighSpeedVideo::class)

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.


// Add the OptIn annotation at the top of your function or class

@kotlin.OptIn(ExperimentalSessionConfig::class, ExperimentalHighSpeedVideo::class)

private suspend fun setupCamera() {

    // Asynchronously get the CameraProvider

    val cameraProvider = ProcessCameraProvider.awaitInstance(this)


    // -- CHECK CAPABILITIES --

    val cameraInfo = cameraProvider.getCameraInfo(CameraSelector.DEFAULT_BACK_CAMERA)

    val videoCapabilities = Recorder.getHighSpeedVideoCapabilities(cameraInfo)

    if (videoCapabilities == null) {

        // This camera device does not support high-speed video.

        return

    }


    // -- CREATE USE CASES --

    val preview = Preview.Builder().build()    


    // You can create a Recorder with default settings.

    // CameraX will automatically select a suitable quality.

    val recorder = Recorder.Builder().build()


    // Alternatively, to use a specific resolution, you can configure the
    // Recorder with a QualitySelector. This is useful if your app has
    // specific resolution requirements or you want to offer user
    // preferences. 

    // To use a specific quality, you can uncomment the following lines.

    // Get the list of qualities supported for high-speed video. 

    // val supportedQualities = videoCapabilities.getSupportedQualities(DynamicRange.SDR)

    // Build the Recorder using the quality from the supported list.

    // val recorderWithQuality = Recorder.Builder()

    //     .setQualitySelector(QualitySelector.from(supportedQualities.first()))

    //     .build()


    // Create the VideoCapture use case, using either recorder or recorderWithQuality

    val videoCapture = VideoCapture.withOutput(recorder)

    // Now you are ready to configure the session for your desired output...

}


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


// Create a builder for the high-speed session

val sessionConfigBuilder = HighSpeedVideoSessionConfig.Builder(videoCapture)

    .setPreview(preview)


// Query and apply a supported frame rate. Common supported frame rates include 120 and 240 fps.

val supportedFrameRateRanges =

    cameraInfo.getSupportedFrameRateRanges(sessionConfigBuilder.build())


sessionConfigBuilder.setFrameRateRange(supportedFrameRateRanges.first())


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.


// Create a builder for the high-speed session

val sessionConfigBuilder = HighSpeedVideoSessionConfig.Builder(videoCapture)

    .setPreview(preview)


// This is the key: enable automatic slow-motion!

sessionConfigBuilder.setSlowMotionEnabled(true)


// Query and apply a supported frame rate. Common supported frame rates include 120, 240, and 480 fps.

val supportedFrameRateRanges =

   cameraInfo.getSupportedFrameRateRanges(sessionConfigBuilder.build())

sessionConfigBuilder.setFrameRateRange(supportedFrameRateRanges.first())


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.

// Bind the session config to the lifecycle

cameraProvider.bindToLifecycle(

    this as LifecycleOwner,

    CameraSelector.DEFAULT_BACK_CAMERA,

    sessionConfigBuilder.build() // Bind the config object from Option A or B

)


// Start the recording using the VideoCapture use case

val recording = videoCapture.output

    .prepareRecording(context, outputOptions) // See docs for creating outputOptions

    .start(ContextCompat.getMainExecutor(context)) { recordEvent ->

        // Handle recording events (e.g., Start, Pause, Finalize)

    }

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.

Normal video thumbnail

Slow-motion video thumbnail

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

Normal video playback

Slow-motion video playback with editing controls

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.


High-Speed Capture and Slow-Motion Video with CameraX 1.5

Posted by Leo Huang, Software Engineer


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.


// build.gradle.kts (Module: app)


dependencies {

    val camerax_version = "1.5.1"


    implementation("androidx.camera:camera-core:$camerax_version")

    implementation("androidx.camera:camera-camera2:$camerax_version")

    implementation("androidx.camera:camera-lifecycle:$camerax_version")

    implementation("androidx.camera:camera-video:$camerax_version")

    implementation("androidx.camera:camera-view:$camerax_version")

}


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:

@kotlin.OptIn(ExperimentalSessionConfig::class, ExperimentalHighSpeedVideo::class)

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.


// Add the OptIn annotation at the top of your function or class

@kotlin.OptIn(ExperimentalSessionConfig::class, ExperimentalHighSpeedVideo::class)

private suspend fun setupCamera() {

    // Asynchronously get the CameraProvider

    val cameraProvider = ProcessCameraProvider.awaitInstance(this)


    // -- CHECK CAPABILITIES --

    val cameraInfo = cameraProvider.getCameraInfo(CameraSelector.DEFAULT_BACK_CAMERA)

    val videoCapabilities = Recorder.getHighSpeedVideoCapabilities(cameraInfo)

    if (videoCapabilities == null) {

        // This camera device does not support high-speed video.

        return

    }


    // -- CREATE USE CASES --

    val preview = Preview.Builder().build()    


    // You can create a Recorder with default settings.

    // CameraX will automatically select a suitable quality.

    val recorder = Recorder.Builder().build()


    // Alternatively, to use a specific resolution, you can configure the
    // Recorder with a QualitySelector. This is useful if your app has
    // specific resolution requirements or you want to offer user
    // preferences. 

    // To use a specific quality, you can uncomment the following lines.

    // Get the list of qualities supported for high-speed video. 

    // val supportedQualities = videoCapabilities.getSupportedQualities(DynamicRange.SDR)

    // Build the Recorder using the quality from the supported list.

    // val recorderWithQuality = Recorder.Builder()

    //     .setQualitySelector(QualitySelector.from(supportedQualities.first()))

    //     .build()


    // Create the VideoCapture use case, using either recorder or recorderWithQuality

    val videoCapture = VideoCapture.withOutput(recorder)

    // Now you are ready to configure the session for your desired output...

}


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


// Create a builder for the high-speed session

val sessionConfigBuilder = HighSpeedVideoSessionConfig.Builder(videoCapture)

    .setPreview(preview)


// Query and apply a supported frame rate. Common supported frame rates include 120 and 240 fps.

val supportedFrameRateRanges =

    cameraInfo.getSupportedFrameRateRanges(sessionConfigBuilder.build())


sessionConfigBuilder.setFrameRateRange(supportedFrameRateRanges.first())


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.


// Create a builder for the high-speed session

val sessionConfigBuilder = HighSpeedVideoSessionConfig.Builder(videoCapture)

    .setPreview(preview)


// This is the key: enable automatic slow-motion!

sessionConfigBuilder.setSlowMotionEnabled(true)


// Query and apply a supported frame rate. Common supported frame rates include 120, 240, and 480 fps.

val supportedFrameRateRanges =

   cameraInfo.getSupportedFrameRateRanges(sessionConfigBuilder.build())

sessionConfigBuilder.setFrameRateRange(supportedFrameRateRanges.first())


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.

// Bind the session config to the lifecycle

cameraProvider.bindToLifecycle(

    this as LifecycleOwner,

    CameraSelector.DEFAULT_BACK_CAMERA,

    sessionConfigBuilder.build() // Bind the config object from Option A or B

)


// Start the recording using the VideoCapture use case

val recording = videoCapture.output

    .prepareRecording(context, outputOptions) // See docs for creating outputOptions

    .start(ContextCompat.getMainExecutor(context)) { recordEvent ->

        // Handle recording events (e.g., Start, Pause, Finalize)

    }

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.

Normal video thumbnail

Slow-motion video thumbnail

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

Normal video playback

Slow-motion video playback with editing controls

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.


Building the future with Blockly at Raspberry Pi Foundation

Blockly logo with blocks and playful shapes

Building the future with Blockly at the Raspberry Pi Foundation

By Rachel Fenichel, Blockly

Today we're announcing that Blockly, Google's open source library for drag-and-drop programming, is moving to the stewardship of the Raspberry Pi Foundation on November 10, 2025.

Since its creation at Google in 2011, Blockly has grown from a passion project to a standard for visual programming. Educational platforms such as Scratch, MakeCode, and LEGO Education use Blockly to remove barriers to entry into the world of programming. Blockly's move to the Raspberry Pi Foundation reflects close alignment with its education-focused mission.

The Raspberry Pi Foundation is one of the world's leading non-profits dedicated to advancing computing education. This move is designed to sustain Blockly's long-term stability and continued innovation as a foundational tool for block-based coding and computer science worldwide.

We are delighted that the Raspberry Pi Foundation will be the new home for Blockly, the world's leading open source library for visual programming. We are committed to maintaining Blockly as an open source project and look forward to working collaboratively with the amazing community of developers and educators to increase its reach and impact in the years to come.
– Philip Colligan, Chief Executive at Raspberry Pi Foundation

Blockly's growth, evolution, and success rest on a foundation of support and investment in open source software from Google over many years. Google.org's support for Blockly's future at Raspberry Pi Foundation strengthens the ecosystem built on block-based coding, fostering greater innovation and expanding access to computational thinking for people around the world.

Looking forward, I'm excited for our future collaborations with the Foundation's world-class research, learning and product teams. We are committed to Blockly's ongoing development, including both feature development and support. Blockly will continue to be free and open source, and existing projects do not need to change anything about how they use Blockly.

To learn more about the transition and read the FAQ, visit blockly.com