Skip to content

Conversation

@linxinan-chops
Copy link
Contributor

Cache manifest defined splash video

  1. A new SplashScreenManager class is introduced to handle all splash screen logic.
  2. CobaltActivity is updated to use the new SplashScreenManager and to load the splash screen from a data URL.
  3. CobaltWebContentsObserver is updated to trigger caching splash video at DidUpdateWebManifestURL event.

Bug: 454630524

to be controlled by a boolean flag and to
use a data URL for the splash screen content.

A new SplashScreenManager class is introduced to handle all splash screen logic.
CobaltActivity is updated to use the new SplashScreenManager and to load the splash screen
from a data URL.
CobaltWebContentsObserver is updated to trigger caching splash video at DidUpdateWebManifestURL event.
Bug: 454630524
@linxinan-chops linxinan-chops changed the title Refactor the splash screen implementation Cache manifest defined splash video Nov 4, 2025
@linxinan-chops
Copy link
Contributor Author

@yell0wd0g Quote your questions here:

@linxinan-chops IIUC there's two parts here, one is the refactor of splash related
code to SplashScreenManager and then the addition of the base64 caching. Could we
have two separate PRs? The former, SplashScreenManager, should be easy to review
since it'd be just a cleanup.

Another question is: I thought @borongc made the splash resources
accessible via a Chrome UI protocol ("h5vcc-embedded"), does this
PR/CL respect that?

For two PRs, sure will do.

Regarding, "Chrome UI protocol ("h5vcc-embedded")", I saw it in the bug, but not sure how to consume it yet, maybe @borongc may provide more info around it.

@@ -0,0 +1,227 @@
<!doctype html>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Putting this file as an Android asset made this solution only Android-specific, we should consider 3P platform as well. Same for SplashScreenManager.java.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is splash requires fast response once the app spin up, any chromium aka platform agnostic solution may take extra time. So I think platform specific implementation is a trade off.

The splash.html is a temp and handy solution for now, I guess. In long term, we should have a native API to consume it, probably.

Copy link
Contributor

@borongc borongc Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR (#7805) allows you to access the file in memory using h5vcc-embedded://{filename}, just put {filename} under cobalt/shell/embedded_resources/ and add it to BUILD.gn, then you can access it both on 3P and Android platform.

This also bypasses CSP and HTTPs enforcement, as it is only local, so it is safe and won't cause any security issues.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Synced with @borongc,

  1. better not write any files to file asset for security
  2. use PWA solution for platform agnostic

For 2, I can use the installable manager in my old #7642 to fetch and parse manifest. But two issues need to figure out:

  1. how to notify the java native side if the chromium cache is available.
  2. hot to detect if the video file has updated and need to fetch again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants