Our in-app browser for Facebook on Android has historically relied on an Android System WebView 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 via Google Play instead of with operating system updates, which is preferable to ensure that users are able to access critical security updates. Despite this, over the past few years, we’ve observed that many Android users are updating their Facebook app but not updating their Chrome and WebView apps, which may result in security risks and a negative user experience.
For example, people with outdated versions of the Chrome and WebView apps may be more susceptible to zero day exploits and other security holes that might have been fixed in newer versions of Chromium. In addition, we also observed that, due to the way Android loads the System WebView, when users were updating the System WebView app, they were experiencing a Facebook app crash.
To help solve these issues – and following the precedent of browser vendors such as Microsoft Edge, Samsung Internet, and Mozilla Firefox who all ship custom browser engines on Android – we have been building and testing a separate Chromium-Based WebView for a few years. This will act as an alternative for the System WebView for the in-app browser for Facebook on Android. This WebView can update in sync with Facebook app updates, and function as a drop-in replacement for the System WebView inside the Facebook app without compromising or changing the user experience in any way.
We have been conducting early tests on this Chromium-Based WebView, and we will begin rolling out this version to more Facebook app users that have compatible devices.
More security, stability, and better performance
Security
Because we are now able to bundle updates to our WebView alongside our app, we can ensure that people who are using our Chromium-Based WebView receive the latest Chromium security patches, which immediately helps mitigate security risks. Additionally, our WebView runs in the same manner as the System WebView.
Keeping in line with best industry practices, we perform rebases of our WebView onto the latest versions of Chromium at regular intervals. This helps us ensure that our WebView has the latest Chromium security patches.
Stability
Android loads the System WebView code into an app’s memory when the component is in use. Once the code is loaded, the app can use the WebView API to interact with the WebView component code in the app’s memory. This has tangible user benefits since it means that one app’s use of the WebView component will not influence or slow down another. It also has security benefits because, with this type of isolation, apps are unable to see what people are doing inside of WebView components in other apps.
When the WebView app gets updated, Android needs to ensure that all instances of the WebView are stopped, otherwise an application might have an outdated version of the WebView that is incompatible with code that was downloaded during the System WebView app’s update. In order to solve this issue, Android will cause apps that have used the System WebView to crash when the System WebView is updated. On Android there is no way to cleanly unload such components from an app’s memory, so this means that if an app used any WebView API at any point it would crash even if the user is not currently looking at a WebView, which creates a negative user experience.
Our WebView fixes this by allowing us to rely on Chromium that’s loaded from our app’s storage instead of the System WebView app’s storage. Thus, Android no longer needs to load the System WebView code into the Facebook app’s memory, which means that Android no longer needs to crash the app in order to allow the System WebView to fully update.
Performance
Our Webview also improves on rendering performance. Modern browser engines have a component called a compositor, which is the part of a browser engine that is used to figure out how to display a page. Typically on modern browser engines the compositor runs in a separate GPU process and is able to run asynchronously from other parts of the browser. However, the System WebView compositor needs to account for the various ways Android allows apps to display it. Because of this, it needs to run synchronously with the Android widget layout, which means that it is unable to run in a separate GPU process.
Because we are able to constrain how the WebView gets displayed within our apps, we can enable the GPU process for our WebView. This improves rendering performance and stability of web pages and Instant Games.
Our open source commitment
Meta has a strong history of commitment to open source, particularly 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 originate, draft and then commit upstream to Chromium, so all Chromium-based browsers could ship these new APIs. Meta is also leading many of the efforts on the WebXR standard. While this engine enables us to experiment with new web standards, we intend to continue to submit any major changes to upstream Chromium.
Not a developer? Key things to know
- We are 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 impact people’s existing privacy choices on Meta services.
Learn more about our in-app browsers in our Help Center.
