Launching a new Chromium-based WebView for Android

Launching a new Chromium-based WebView for Android

Our in-app browser for Facebook on Android has historically relied on an Android system web view based on Chromium, the open source project that powers many browsers on Android and other operating systems. On other mobile operating systems, the System WebView component cannot be updated without updating the entire operating system. On Android this works differently, allowing the System WebView component and the Chrome app to be updated through Google Play instead of OS updates, which is better to ensure users can access critical security updates. Despite this, over the past few years, we have observed that many Android users update their Facebook app but do not update their Chrome and WebView apps, which can lead to security risks and negative user experience. .

For example, people with outdated versions of Chrome and WebView apps may be more susceptible to zero-day exploits and other security vulnerabilities that may have been patched in newer versions of Chromium. Additionally, we also observed that due to the way Android loads the System WebView, when users updated the System WebView app, they encountered a Facebook app crash.

To help solve these problems and following the precedent of browser vendors such as Microsoft Edge, Samsung Internet, and Mozilla Firefox all offering custom browser engines on Android – we’ve been building and testing a separate Chromium-based WebView for a few years. This will serve as an alternative to System WebView for the in-app browser for Facebook on Android. This web view can be updated in sync with Facebook app updates and work as an instant replacement for System WebView in the Facebook app without compromising or altering the user experience in any way.

We’ve done initial testing on this Chromium-based WebView, and we’ll start rolling this version out to more Facebook app users with compatible devices.

More security, stability and better performance


Since we are now able to bundle updates to our WebView with our application, we can ensure that people who use our Chromium-based WebView receive the latest Chromium security patches, which immediately helps to mitigate the security risks. Also, our WebView works the same as the System WebView.

Following industry best practices, we rebase our WebView to the latest versions of Chromium at regular intervals. This helps us ensure that our WebView has the latest Chromium security patches.


Android loads System WebView code into an application’s memory when the component is used. After the code is loaded, the application can use the WebView API to interact with the WebView component code in application memory. This has tangible benefits for the user, as it means that one application’s use of the WebView component will not influence or slow down another. It also has security benefits because with this kind of isolation, apps can’t see what people are doing inside WebView components in other apps.

How the WebView system is loaded

When the WebView app is updated, Android must ensure that all instances of WebView are stopped, otherwise an app could have an outdated version of WebView that is incompatible with the code downloaded when updating the System app WebView. In order to fix this issue, Android will cause apps that used System WebView to crash when updating System WebView. On Android, there is no way to cleanly offload these components from an app’s memory, which means that if an app was using a WebView API at some point, it would crash even if the user wasn’t looking. currently a WebView, which creates a negative user live.

Our WebView solves this problem by letting us rely on Chromium which is loaded from our app storage instead of the System WebView app storage. So Android no longer needs to load System WebView code into Facebook app memory, which means Android no longer needs to crash the app to allow System WebView to fully update. .

How our WebView is loaded


Our Webview also improves rendering performance. Modern browser engines have a component called composer, which is the part of a browser engine used to figure out how to display a page. Typically on modern browser engines, the composer runs in a separate GPU process and can run asynchronously from other parts of the browser. However, the System WebView composer needs to consider the different ways Android allows apps to display it. For this reason, it must run synchronously with the Android widget layout, which means it cannot run in a separate GPU process.

As we are able to limit the display of WebView in our applications, we can enable GPU process for our WebView. This improves the rendering performance and stability of web pages and Instant Games.

Our open source commitment

Meta has a long history of commitment to open source, especially when it comes to web standards as well as upstream Chromium contributions. For example the isInputPending and JavaScript self-profiling APIs are two standards that Meta helped create, write and then validate upstream of Chromium, so that all Chromium-based browsers can ship these new APIs. Meta is also leading many efforts on the WebXR Standard. While this engine allows us to experiment with new web standards, we intend to continue submitting any major changes to Chromium upstream.

Not a developer? The key things to know

  • We’re making a backend update to improve the user experience of loading web content in Facebook’s in-app browser on Android devices.
  • This change will improve security and performance and reduce app crashes when people view websites in our Facebook app.
  • Other companies like Mozilla, Microsoft, and Samsung already have custom browser engines on Android.
  • This update does not affect users’ existing privacy choices on Meta Services.

Learn more about our in-app browsers in our Help Center.

#Launching #Chromiumbased #WebView #Android

Leave a Comment

Your email address will not be published. Required fields are marked *