The WebViewClient supports a method, shouldInterceptRequest, which allows developers to intercept network activity and modify HTTP headers, etc. This API does not have access to the Cookie header and relies on the Android CookieManager API in order to query what cookies are available for a particular request URL. However, partitioned cookies are double-keyed on the top-level site and the site of the URL using the cookies. Currently, the CookieManager API provides no way for developers to query partitioned cookies correctly, and this will cause a mismatch between what the Java API returns and what frames in WebView will actually be in their Cookie header. After discussing this with the WebView team, we believe that the option that will minimize potential app breakage is to disable CHIPS on WebView until we are able to ship support for the Cookie header to shouldInterceptRequest. We will release the changes to shouldInterceptRequest in the next target SDK version (API level 36). Enterprise workflows that use WebView to load web content that relies on partitioned cookies will have their state cleared. I am not aware of partners adopting CHIPS specifically for WebView or enterprise use cases. WebView apps still have access to unpartitioned 3P cookies and cookies set with Partitioned after the change will revert to their legacy pre-CHIPS behavior until we relaunch the feature.