 My name is Nate. I work here at Google on the Android WebView team, and I'm here to talk to all of you today about What is Android WebView and why do we care? So this is Chrome University, but We're at a talk called Android WebView and how is this Android WebView thing connected to Chrome? well, Android WebView is a project in the chromium repository and The idea behind this project is we want to bring the best parts of chromium to the Android platform So that all Android developers all around the world can take advantage of the really cool stuff We have here in chromium talking about blink v8 multi-process browsing architecture, you know all this really great stuff and You may be wondering well, how does this actually affect me? Like I said, we're a project in chromium, which means that your work here in chromium Depending on you know the the code you're writing where you're writing this code might actually be impacting all of these Android apps all over the world So if you ever tried to ship a feature in Chrome or you've tried to ship a new feature in the web platform You're asked does this get supported on all of our support OS is all of our platforms and the very last one in the List is Android WebView Okay, so what actually is this Android WebView thing that we're all apparently contributing to? So Android WebView is an Android view and an Android view is really just a fancy word for a rectangle It's a visual rectangle that shows up in Android apps. It's a rectangle that the user sees there's all kinds of views There are text views for showing text image views for showing images and a web view is a view for showing the web web contents and Beyond just being a rectangle we come with hundreds and hundreds of APIs spread across dozens of different Java classes The Android developers can call to configure this web view to interact with it to kind of poke the web contents in Whatever way they need to So what does this actually look like in reality? So you can kind of think of web view in four very broad use cases And some of these might surprise you so Over here on the left. We've got a picture of Gmail and here we are we call this the embedded use case So Gmail is primarily an Android app, you know implemented in Android views But those emails are arbitrary HTML. So it makes a lot of sense to use a web rendering components It's actually render that HTML The second case is maybe the most obvious You know Android comes with this web view components. It knows everything about the web Navigation JavaScript rendering all of it. So it makes a lot of sense to try to Build a web browser with a component like this It does most of the heavy lifting and you just wire up a URL bar some buttons and some things like that This third case Maybe some of you are familiar with it. There is an app framework called Cordova I believe it was previously called phone gap and the idea here is we have all these developers out there in the world Who know the web platform? They know how to build a website? HTML JavaScript CSS all that good stuff, but they want to launch a mobile app. So Cordova is more or less one giant web view your entire app lives in this web view You get to write code in your favorite language and this web view You know runs everything all your business logic is in Java and everything you see there as beautiful It is as it is is all HTML. There's not a single native Android view in there except for the web view holding everything And a fourth case that is very important is Advertisements there's a huge network of web-based internet ads and it makes a lot of sense to Not reinvent the wheel. We have all these web ads out there Let's just reuse them in mobile ad frameworks and we use a web view to show that content But you may be surprised at all the times you've encountered web view sometimes it really Fits in seamlessly with the rest of the Android offering. So Here are a few different scenarios You may have hit on your Android phone and you may be wondering well, which of these are web views and which aren't So if you've ever set up an Android phone, you've probably gone through the setup wizard You've added your account to the phone That's what we see here on the left and it looks like a simple text input and you know, there's a next button Seems pretty straightforward. There's this Gmail compose. Obviously. This is a huge text field where you're writing the content of your email Nothing too surprising there if you're reading an email it might have a link you click on the link you navigate to that page This is pretty obviously web content. We went out over the internet. We fetched that URL And a very similar use case user experience. We've got the Facebook app You're scrolling down the news feed click on a link that your friend posted and you know, you're seeing that URL So which of these are actually web views? It turns out most of them are that very simple Google sign-in. That's actually just navigating to a website You know, it's just navigating to a mobile site and you're using the web right there This Gmail compose it feels like a text input. It's actually a web view You're actually editing a DOM tree when you're writing your email. That makes sense. We're making HTML in the end This third thing is actually not a web view even though it feels like it might be you know, we're in the Gmail app We're looking at a web page. This is actually a Chrome tab this is something called Chrome custom tabs and this is an offering that we work on elsewhere in Chrome and That's running in a totally separate process. It has a back button to go back to the rest of Gmail It feels very much like you're in the app, but it is actually Chrome The fourth thing even though it's the same exact user experience is actually not a Chrome custom tab Facebook decided that they like this concept of this you know in app browser But they want to implement some of that UI themselves and they're using a web view to actually do the heavy lifting for the web content So web view is used everywhere and basically every app you've ever used in ways You may not have noticed for a huge variety of use cases that you may not as developers actually be expecting and There's two points here that I really want to highlight There's a huge opportunity for impact. You know be like I said, this is a Chromium project I'll get to that in a moment But we all have the opportunity to contribute to this so the huge opportunity for your features to have a positive impact on the ecosystem But with this comes a lot of responsibility We need to think about all these different use cases and make sure that this feature makes sense for all these use cases because they are quite varied and Then just to give you a very brief look why are people drawn to this web view thing? What's so enticing about it? These are some of the differences perhaps with something like Chrome custom tabs we have some APIs to interact with this web contents and You know the API as you might expect are there You know, there's an API to load a URL and this is analogous to typing a URL in the URL bar and clicking go You navigate to this page Kind of not surprising There are callbacks about the page navigation life cycle saying the page started loading the page finished loading You might use these in a browser app to tell the user. Okay. It's done. You know ready to use this web page and Sometimes loading goes wrong. So we have some error callbacks. These could be network errors HDP errors Security errors, you know, you name it. We've got callbacks for it. But this is all kind of basic Web view provides a lot more control for app developers more control than you might initially expect so we have APIs to inject JavaScript and execute arbitrary JavaScript code to interact with the DOM tree and the web contents We have APIs to give direct access to the cookie jar. You can look, you know, exactly at what cookies are there You can modify cookies Clear all the cookies, whatever you want We have full control over the net stack we should intercept request This is a way for the application to modify a request cancel a request Totally fake a request to a fake page or you know substitute the response with whatever they want So the app has quite a bit of power when it comes to Android web view Now this might seem a little bit scary for us in Chrome land You know, we don't want apps fiddling around with web contents But you have to remember the app is the browser in this case You know, just like your browser has access to your cookies. Well, the app has access to your cookies It's understand why this isn't, you know, a huge problem. I think we can dive a little bit deeper into what I call the technical guts So I think it's important to understand. What is the trust model here for Android web view? The very first thing we have to mention is that the browser process is the app process when an app wants to load an Android web view It starts calling these API's All of our code gets loaded into the app process. We share the same address space There is no process boundary between us and the app. So we trust the app entirely And this aligns very much with our goal We want to bring the best of Chromium to the Android platform We don't want to be, you know, enforcing what the app can or can't do You know, we just want to expose the best parts of the web platform and help the app take advantage of these But this is okay because each app is roughly equivalent to a different install of Chrome So if you have the Gmail app and the Facebook app, they're each going to have their own cookie jar They're each going to have their own HTTP cache and everything's pretty isolated and Within an app you can think of each web view as a tab So each web view is allowed to have access to the same cookie jar in this app just like all your tabs would you know share this state Now one of the things you have to understand about Android web view is we are an Android view and with this comes certain privileges and certain responsibilities so One of the drawbacks to being Android view is that we have to integrate very closely with the view system and One of the issues here is that the view system is this huge hierarchy this each tree structure of different Android views And they all get called Their on-draw method all gets called at the same moment and everybody has to render synchronously Into the view tree and web use no exception and sometimes this means we have very slow graphics operations that are blocking but This is unfortunately one of the consequences of being an Android view One of the other issues is that when Android rolls out new features We want web view to blend seamlessly with the rest of the Android platform We don't want you to notice if you're looking at a web view versus a text view unless the developer wants you to notice So when Android launches smart text selection or text magnifier or autofill Web view has to support it in exactly the same way And this is to give the user a very consistent experience app to app And One of the perks though of being an Android view is that we get to write APIs and these APIs are available to every Android application And this is our opportunity to expose the best of the web platform And the example here is we have an API to control and configure the service worker that's shared between all the apps web views But Android web view is of course more than just an Android view. It's also a chromium thing So what exactly do we mean? Some of you may be familiar with this diagram on the rights Except for the little markup I have at the top. This is the chrome layer cake And chrome is all the way at the top We have content right beneath it and there's a bunch of other Lower layers. This content is out of date. I didn't try to fix the lower layers But the top of it is so accurate. We have a content layer and a chrome layer Well, Android web view is not chrome. Android web view is a separate project But we are a content embedder, which means you can swap out the chrome layer and replace it with the android web view layer And we are a top level directory in chromium Android underscore web view So we're a content embedder and this means that if you're working on any of these lower layers the net stack If you're working on the web platform v8 all of your contributions are Instantly inherited by android web view and this is really great because as we're evolving the web platform It's really nice that web view is able to take advantage of this and give this to android developers But again, this is a double-edged sword One of the issues is that if you're designing a huge architectural change or you're changing some core service You have to ask yourself does this service make sense for android applications? Does this architectural change benefit android web views all over the world all over the android ecosystem? So like I said, we're a content embedder and one of the really great things In the content layer is chromes famous Multi process architecture. We do multi process browsing where we've got a browser process all these renderer processes It looks more or less like what we see here. We've got some utility processes for services network service gpu service There's a whole bunch of others. This is perhaps a too simplified version Uh, and this is what chrome looks like and web view has sort of a similar architecture But before we get to that, I think I should talk about a slight caveat chrome sometimes looks a little different on low memory android devices All these extra processes come with some memory overhead and we don't want to be spending too much of the user's memory So what we do is we run some of these services in process and the advantage here is we avoid the memory overhead But it comes with the trade-off of stability security. We can't do sandboxing on these processes But this is the trade-off we decided was right for chrome for android, but we still have more or less the same thing with the renderers So web views architecture is actually quite similar to chrome's low memory architecture We still have the Browser process as I mentioned before this is shared with the app. This is the app process We run the network service and gpu service in process among many other services Uh, one of the main differences here is that we have a single renderer process This is different from chrome where we have the opportunity to isolate all these different sites from each other Web view doesn't have that opportunity right now We're looking at expanding this some multiple renderer processes But with each renderer process comes more memory overhead And given that there's so many web view apps out there It doesn't quite make sense To apply the same policy for web view as we do for chrome I would just take up too much memory One of the other points that I will mention here is that uh, Right in the title I say android o plus So what I mean here is that recent versions of the android operating system orio pie And you know, hopefully all the future versions use this architecture For technical reasons on the earlier versions of android lollipop march mellow and nougat We have to have a different architecture and it looks like this Uh, maybe I should have led with this diagram because it's so much simpler Uh, it's all in one process So we call this an in-process renderer runs in the browser process And the obvious Issue here is we're not sandboxing web content in the renderer from the browser process This is even an even bigger issue because if this renderer gets compromised It's not just the browser, but it's really the entire app that can be compromised So this is kind of why our team worked very hard to launch the out of process renderer for android orio All right, so now that we kind of understand a little bit about what web view is what it looks like to users, you know, the technical guts Uh, hopefully everyone wants to launch features for the web platform and architectural features for web view too So what does that actually look like? So the developer workflow is actually pretty similar to chrome for android We work pretty hard to make it very consistent and you're compiling an apk. You're installing it Anyone who's worked on chrome for android is probably familiar with this But if you're not we have documentation for how to work on this You just need to grab an android emulator on your computer or an android device here at google But one of the Issues with web view is that the web view apk only implements these apis and that in itself is not so interesting You want to start calling the apis? So you do need an app to actually use web view and the like I said, there's a bunch of android apps out there on the google play store But if you need an android app You can use the web view shell, which is a very thin wrapper around web view. It implements a browser type app Now if you are designing your features for web view, there are some fun challenges Unlike chrome where the viewport is basically the full or the web content is the full size of the viewport Android web view could be any size. It could be quite small. It could be quite large This was a fun challenge. We got when working on safe browsing and bringing this to web view We wanted to make interstitials Meaningful and have a very good user experience Even when web view is quite small. So this was our solution And we just detect the size of the web view But there are also some very weird restrictions that you might not be expecting Web view runs in the app. So if the app hasn't requested internet permission Well, web view doesn't get that internet permission. So we Have to operate under the assumption that internet might not be available Sometimes there are network configurations that web view has to respect That you might not be expecting in chrome land Another interesting restriction is that we can't create our own UI we can't create our own pop-ups. So if you're implementing javascript alerts or dialogue boxes Web view has to request that the app creates this because the app gets the final say on whatever UI shows up to our users Now if you've designed a feature for web view, you may be wondering how does it go out to our users The release process is exactly the same as chrome for android We release the same exact version on the same day to the same exact users Sometimes it's even in the same apk, but I won't get into that now chrome and android chrome for android and android web view are both pre-installed on google devices We've pre-installed the same exact version One of the issues here is that if you're implementing a feature It's not enough to make sure it works right on chrome. You have to make sure it works right on web view too And if there's a bug in web view and you have to respin for this bug Well, you have to respin for chrome as well. We're pushing new chrome updates to all our users And of course same release schedule means we have the same channels We have canary if you want to verify quick fixes. We have dev if you need to Check for crashes beta if you want to look at metrics data and of course stable when we launch to the bulk of the population And on the subject of metrics web view also supports the same metrics infrastructure we use for most of the other chromium projects If you want to log metrics use the same histogram logging functions and macros If you want to look it up in the dashboard, it's platform equals android web view If you want to roll your feature out with finch also called variations or field trials Then again, it's just platform equals android web view And if you're working in one of these lower layers content layer base something like this We know about all the feature flags to find there So, you know, you can use the exact same feature flag you've already used and just add platform equals android web view It's the list in your finch config So it's really really consistent So I'd like to thank you all for your time and hopefully when you're designing your features in the lower layers Or if you're even adding chrome only features you think about bringing them to android web view