 Hey, everyone, thanks for joining us. My name is Sam Richard, and this is the Adding Your Progressive Web App to the Google Play Store workshop as part of Chrome Dev Summit 2021. I am a progressive web app and Chrome OS developer advocate here on the Chrome OS team. And with me is Joyce and Andre, who are also from Google. Joyce, Andre, would you like to introduce yourselves? Yeah, thanks, Sam. Hi, everyone. I'm Joyce, and I'm also a developer advocate on the Chrome OS team on Google and very excited to be here. And I'll be here to just help run the workshop and then answer any questions that anyone has that might show up in our chat or the Q&A functionality. Hello, everyone. I'm Andre. I'm also a developer relations engineer working on the Chrome team. And yeah, I'll be around helping us in questions. Great, thanks. We have both the chat to answer questions and there is Q&A functionality. In the lower right corner of Meet, you should see an activities button. It looks like a triangle, a square and a circle. If you click that, there should be a Q&A option. But anytime you have a question, pop your Q or pop, sorry, pop your question into there and me, Joyce or Andre, will try and answer it. Thanks. Let's get started. So before we get started, you should have received an email with a number of prerequisites for this workshop. You're gonna need a progressive web app that you already have launched that you can make changes to. You're gonna need the bubble wrap command line interface already installed and ready to use. And you're going to need a Google Play Developer account. Hopefully you have all these and are ready to roll with us throughout this workshop. If you don't have these ready to work with right now, that's okay. There's gonna be some portion of the workshop you're not gonna be able to follow along with, but otherwise you can listen in and keep going with us. Fortunately, this whole workshop is available for you to look at after this. After this. So we're going to be using this code lab to go through and teach you everything you need to know about launching your PWA into play. So you can follow along with that while we're showing it and sharing it here. Or you can come back to it later. It's up to you. So with that, we're gonna get started. First up is bubble wrap. I'm going to ask some of these questions, some of these before you start questions, just throw your answers into the chat window. So question for all of you. Bubble wrap is a tool for wrapping your progressive web app into an Android app bundle, as easy as a couple of CLI commands. It does this by generating an Android project from your progressive web app and using it in a trusted web activity. So my question is, what kind of information might bubble wrap need about your progressive web app to generate an Android project? Feel free to throw your answers into our message. I'll give you all like a minute to do so. Permissions, a manifest file, layouts, developer identity, web views, country settings, permissions, and if it's about a COVID tracking app. Those are all great answers, great thoughts. Not gonna give you the answer yet, we're gonna learn about that throughout this section. So to use bubble wrap, the first thing we recommend is creating a directory to run it from. Bubble wrap is a command line tool. These are all going to be in Unix style commands. So if you use like PowerShell or something else, just kind of do that translation in your head from these Unix commands into the command line interface you're used to. So the first thing we're gonna do, we're gonna create a directory called mypwa. It can be whatever you'd like and CD into it. Then you're gonna run the bubble wrap command. So the bubble wrap command is bubble wrap and we're going to initialize a new bubble wrap project and we're gonna pass it the manifest flag. That manifest flag should point to your PWA's web at manifest, often at manifest.json. When you install bubble wrap for the very first time, it will download a bunch of extra dependencies. Those include the Java development kit and the Android command line tools. To ensure that the correct versions are downloaded for each dependency, we strongly recommend allowing bubble wrap to download the correct versions instead of using ones you might already have. So with this command, bubble wrap initializes with the location of your PWA's web at manifest file. This will generate default configuration for the web at manifest, from the web at manifest and start an in console wizard that allows you to change the default configuration, following the wizard to change any of the values generated by the tool. So it'll figure out your domain. It'll figure out what path to open for your progressive web app, stuff like that. Next, you'll need to deal with signing keys. So Google Play Store requires application packages to be digitally signed with a certificate when uploaded, often referred to as a signing key. This is a self-signed certificate and it's different from the one used to serve your application over HTTPS. Bubble wrap will ask for the path for the key when creating the application, if you already have one. If you already have one, you need to use the same key here as you did for other applications that you've uploaded. If you don't have signing keys though, you can create a new one with bubble wrap. Bubble wrap will let you create new signing keys. It's very important that you ensure that the signing keys that are generated and the passwords for those are stored in a safe place. You need them to build the application for the first time and also to update your app on the Play Store regularly. What do you get out of running bubble wrap? Well, after initializing your bubble wrap project and completing the wizard, you'll have the following items. You'll have a TWA manifest.json file. This is the project configuration reflecting the values chosen in the bubble wrap wizard. You want to track this file in your version control system as it can be used to regenerate the entire bubble wrap project if need be. You'll also get Android project files. The remaining files in the directory are the generated Android project. So bubble wrap does build an Android project for you. This project is the source used for the bubble wrap build command which we'll see later on. You can optionally track these files within your version control system if you'd like to. But like I said, TWA manifest.json can regenerate the software for you as well. And if you had bubble wrap generate signing keys, you'll get signing keys at the output location described in the wizard. Like I said before, I'm sure the signing keys are kept safe and limit the number of people who have access to it. It is what is used to prove that apps on the Play Store come from you. With all of these files, we now have everything we need to build an Android application bundle. So from within the same directory that you ran the bubble wrap initialization command, run the following. Remember, you'll need the passwords for your signing key. Bubble wrap build. The build command generates two important files for you. The first one is appreleasebundle.aab. This is your PWA's Android app bundle. This is the file you will upload to the Google Play Store. The next is your apprelease signed.apk. This is an Android packaging format that can be used to install applications directly to a development device using the bubble wrap install command. So before we go to the next step, let's field some questions. We've got one question. Does our PWA using this lab have to sit on a public-facing web server or is a web server behind a VPN okay? I believe that bubble wrap will need to be able to get access to it. So if bubble wrap can't get access to it, you won't be able to run the initialization with the manifest. I haven't built one that runs behind a VPN yet, so you can try. If it's possible to have it not run behind a VPN, that's probably best. But you might be able to do it. Like I said, I haven't tried. Does anyone else have questions? Great. So for the next about 15 minutes, we have a task for you. Now it's your turn. Using what we just learned, try and complete the following steps. I'll answer that question in one second. Create a directory to hold your generated Android project. Initialize that directory with bubble wrap and your PWA's web app manifest. Generate new signing keys. You reuse existing ones if you have them. And then build your Android app bundle from the generated Android project. Let me answer this question before we get going. Can bubble wrap create an app that needs no internet access? Joyce, do you know the answer to this? So usually bubble wrap, I don't think that should be an issue, but I guess I would need a little bit more context as to why you would wanna create an app that needs no internet access because the whole point of bubble wrap is to wrap your PWA for Android. So I think I can elaborate on that a little bit more. A bubble wrap does not bundle assets in it, like your HTML or your CSS file. It's not like web packaging. So you do need to go through the standard service worker lifecycle with the progressive web app in a bubble wrap packaged app. So you go to the page first on that first page, then it installs a service worker, your service worker caches whatever you want. And if things work offline with that service worker, then it works. But I don't believe it will work offline out of bubble wrap without at least hitting the network once to initialize the service worker. And for offline support, again, the same answer. So bubble wrap is a wrapper for your existing progressive web app, but it doesn't bundle assets. So you will need to hit the network at least once for your service worker to get your page and for your service worker to start its lifecycle during service worker install. You can cache stuff for offline and then your progressive web app can work offline. Any other questions? Okay, great. So let's take 15 minutes and have you all try this out. If you have questions while you're working through this, throw them in chat and Joyce or I will be happy to answer them. On your mark, let's get set, go. Hey, everyone, we're about halfway through. Okay, everyone, we've got about three minutes left. I just wanna check how everyone's doing. If you need more time to complete these steps, either use the raise hand functionality in Meet or send a message in the messages. If no one needs more time, we'll keep going. Okay, I see at least one person needs a little more. So we'll keep going. One more minute. Okay, great. I hope everyone got to the end of that. If not, you can play with a little bit more as we continue through the rest of the next section. So next up, add your app to Google's Play Store. Now that you have an Android app bundle for your PWA, it's time to upload it to Google's Play Store. Once you've registered your developer account, you can go to the Play Console to log in and get started. So I've got a question for you all. What do you think the different types of signing keys are that you need to create a release in Play? Feel free to answer in messages. So we have one signing key that was what we used, what was potentially generated by Bubblewrap. Are there different kinds of signing keys? What might those be? And why might you need them for releasing in Play? Does anyone have any thoughts? It's okay if they're just guesses. App signing key, upload key, what else? We can keep going. So first up is creating an app. Once logged in, you'll see a screen that shows all of your apps. Near the top, there is a button called Create App. That, when clicked, will show the following screen to guide you through creating a new Android app listing. There are a number of fields here to fill out, including app name, default language, whether it's an app or a game, whether it's free or paid, and a number of declarations. You'll not be able to create an app without agreeing to the declarations. So it's important that you read through them and understand them before agreeing to them. An important note about progressive web apps in Play. While you are given the option to make your app free or paid, the PWA you bundle for inclusion in Play must be available to the wider internet, or at least anyone who can access that new particular URL in order to work. And there is no way to reliably detect that a user is accessing your PWA from your app instead of from the browser or another installation method. As such, we recommend you monetize your PWA through means other than charging to download it from the store. So once you've filled out all of the information and click the Create App button at the bottom of the form, you'll be taken to the dashboard for your new app. In the dashboard, you'll see checklists of tasks that you need to complete in order to set up, start testing, and release your app. Internal testing is a great way to get your app released quickly without review to a group of trusted testers you select. View the tasks in the Start Testing Now checklist and select the Select Testers task. Clicking that task will bring you to the internal testing page. This is where you'll manage the testing setup for your app. You can navigate to it again by opening the testing section under the Release menu in the sidebar. The first thing to do here is to create an email list of testers to test your app. To do so, click the Create Email List link in the Tester section of the page. This will open up a popup to create your email list. In this popup, you'll name your email list and can either manually enter email addresses or upload a CSV of email addresses to use. Once done, press the Save Changes button. You'll be able to go back into email lists you've already created to add or remove email addresses as needed. After adding your testers, it's time to create a testing release. Click the Create New Release button at the top of the page. After clicking on the Create New Release button, you'll be prompted through a number of sections. The first app integrity is where you choose how to manage your app's signing key. The default option is to let Google manage your signing key and it is the recommended option and it is both secure and keeps your app recoverable in case you lose your upload key. So let's talk about Play App Signing quickly. Starting in August of 2021, which was only a couple of months ago, Play App Signing is required in order for the Play Store to manage and protect the final signing of your application. With Play App Signing, Google manages and protects your app's signing key for you and uses it to sign your Android apps for distribution to users. The key that Bubble Wrap generates for you becomes your upload key instead of your signing key. While Google manages the signing key for you, you manage and keep private your upload key, which you use each time you sign your app for upload to the Play Console. This system makes it possible for you to reset your upload key if you ever get lost or compromised by contacting the Play Support Team. So this is kind of what the flow looks like. You as a developer have an upload key, you generate your app and you sign it with the upload key. You then upload that to Google, the Play Store, Google has the app signing key and that's what actually signs it for distribution to the user. So after you've dealt with app integrity and signing, it's time to upload your app and finalize it for release. So after choosing how to manage your signing key, you'll be asked to upload your app bundle to your release. To do so, drag and drop the app release bundle.aab file that Bubble Wrap generated into the form. To finalize the release, fill in the remaining details and then click save and then review release. And finally, start rollout to internal testing buttons to get your release started. This will make your app available to your internal testers. Back in the testers tab of the internal testing page, you can copy a link to share with your testers so they can get access to your app. Something to bear in mind is that while testing apps don't go through the full Play Store review process, it may take some time before they're available to download and test after creating and rolling out your release. Just keep that in mind. So before we move on, does anyone have any questions? See no questions, it's your turn. So what you're gonna do now, we're gonna give you 20 minutes to do this, is you're gonna create a new app for your PWA in the Play Console. You're gonna set up internal testing for the app and make sure you add yourself as a tester. You're gonna upload your bundle and creating testing release for your app. And then try and install your app from the Play Store on an Android device you have or a Chrome OS device you have using the testing link. Does anyone have any questions before we get started? Seeing none, go have at it. Hey everyone, we're about halfway through. So one of the questions is one of our customers that we've implemented in the TWA app for points out that their customers are pointing out slow performance of the app. Shouldn't it be the same like for their mobile website as seen on Google Chrome? Joyce, do you have thoughts here? Yeah, so what Bubble Wrap actually does for you is it'll take your PWA and wrap it in essentially an Android app shell, but when it actually launches in, whether on a mobile Android device or on your Chromebook, which runs Chrome OS, it'll start with the Android app, but it actually just directly launches your PWA. So it's really running just your PWA. So maybe like in the initial startup of the app because it starts with the Android app first before it launches your PWA, there might be some performance issues there, but once it's actually just running your PWA, it's all the PWA I think, yeah. The other thing to look for, Michael, is if there's any extra things that are happening inside of that app, that might be causing a slowdown because like Joyce said, the actual view is pretty much the same view as if you had launched it in Chrome. So it should be running at about that's the same speed. So if it's the same web app, the place where I would look at is the Android app. So one thing we don't explicitly talk about is how often you should update things wrapped in PWA's wrapped in TWAs and the actual underlying code that displays the web app does get updated periodically. So you should maybe six months every year rebuild your Android app and re-upload it to make sure that you're running whatever the latest version of everything is. And if it really is just a one-for-one app, make sure that the only activity that the Android app has is the TWA activity, the Trusted Web Activity. Bubblewrap is a great way to do this. Your TWA manifest JSON file, you can just rebuild your app when like once every six months or something and re-sign it and re-upload it. John has a question, is it possible to append a Chrome OS only bundle to a pre-existing Android app in the Play Store? The answer is yes, that is a little bit out of scope for this particular workshop, but if we have time at the end, we can go back and we can talk through that. There is a link at the beginning of this code lab that will point you to some existing documentation we have on Chrome OS to do that. But like I said, if we've got time at the end, we'll be happy to go through that. And with that, there are five minutes left. If anyone needs more time, please raise your hand or throw a message into chat. And if anyone needs more time, we'll wait that five minutes, otherwise we'll move on to the next section. I'm sorry to hear that, CloudDeck. I will make sure that we update the requirements in the future, but I'm going to paste this link again. Once you have a public-facing PWA to work from, you can go through this whole deck on your own, in your own time, and yeah, you'll be able to catch back up. So is there a way to ask a question? I have a fact. Let me check with the Chrome Dev Summit or with the Chrome Dev Summit organizers and I'll get back to you before the end of the workshop. And Mohawk, yeah, every six months to a year or something is like a good rule of thumb for when you should just rebuild your app and re-upload it. If it's a TWA, Joyce has worked a little bit more on this than I have, so Joyce can give you more information. Yeah, we recommend it, but I'm going to leave it recommend about six months to a year just because that's also how often relatively that bubble wrap will also have new releases that incorporates a couple of new features as well as updates the Android SDK version. So yeah, it's just a good idea to keep it updated every so often. And then also I can drop a link that answers John's question from a couple questions ago about having Chrome was a bundle to adding it to a pre-existing Android app. If we don't get time to talk about it later, I'll just drop this link. So to answer the question after the fact question, there is an official Chrome Devs, well, I don't know if it's official, but there is a Chrome Dev Summit Discord server. The link is there. And if you sign up for there, we should be able to get answers to your questions after the workshop is done. So Moha, are you asking about an index DB database or another type of database? Index DB? Okay. I believe it should stay between app updates, but we will check back. I don't know a good way to get an answer to that before the end of the workshop is done. We will check on it though. We'll check on that though and get back to you. With that, that is five minutes. And that's the end of our create an app time. We're gonna move on to the next section. So, digital asset links. If you've gotten to test your PWA in play, you might have noticed that it doesn't run full screen right now. That's because you haven't verified ownership of the site through a digital asset links file yet. While bubble wrap is able to configure and build your Android application bundle, you need to finish the link by updating your web application. So, a question for all of you. How might digital asset links prove your app and your PWA are both owned by you? Anyone have thoughts, answers? Throw them up in chat, please. Neal's answering Moe's question. The old database will still be there in the newly built app. We're checking on that as well to confirm that. John has an answer to this, the signing key. Does anyone else have thoughts? Okay, let's keep rolling. So, let's talk about SHA-256 fingerprints. To configure digital asset links, you'll need the SHA-256 fingerprint for the certificate used to sign the package the user receives on their phone. So, this is important. The certificate used to sign the package the user receives on their phone. So, if you're using play app signing, which hopefully you will be, if you set up play app signing for your app when creating your release, like we said, was recommended, the SHA-256 fingerprint can be found in the play console. Remember, this certificate is different than the one used to upload your application. To obtain the fingerprint, from within your application in the play console, go to releases, setup, app integrity, and then there you'll see a number of options under app signing key certificate. Copy the value for the SHA-256 fingerprint. If you didn't use play app signing, the key used to sign your final application will be the same one used to upload the application to the play console. You can use Java's key tool to extract the fingerprint using the key tool list command. And then adding in the key store, the path to the key store, the key alias, the key store's password and the store password. And out of all that, you can get the SHA-256 fingerprint. To create your digital asset link file, you can use bubble wrap. Bubble wrap can manage the signature fingerprints you've retrieved and generate the correct digital asset links file for you. To add a fingerprint with bubble wrap, run the following command from within the same directory created during the bubble wrap in your PWA step, which was our first step of the day. Replacing fingerprint with the fingerprint copied from the previous step. Bubble wrap fingerprint, add fingerprint. This command will add the fingerprint to the application's fingerprint list and will generate an asset links.json file. Upload this file to the dot well-known directory on the same origin as your PWA. This is super important. Asset links.json must be placed within the dot well-known folder. Must be named asset links.json. Must be on the same origin as your PWA. And therefore must be accessible at your PWA's origin slash dot well-known slash asset links.json. Any derivation of this will prevent it from being found and correctly linked to your app. You can verify your digital asset link is set up properly using the digital asset links API. So questions about same origins. Everyone should hopefully know about the same origin policy building PWAs, but we're just gonna go over it again super quick. So there are two plus N portions of an origin or there are multiple portions of an origin. So the first portion of an origin is the protocol used. FTP, HTTP, HTTPS, so you've got your protocol. Then you have the top level domain. That's an additional portion of an origin. You have the domain name, which is an additional portion of the origin and you have subdomains and you can have as many subdomains as you want. In order for something to be considered the same origin, every single one of those pieces must match. You must match the protocol, you must match any and all subdomains, you must match the domain and the top level domain. All of those items need to match for something to be on the same origin. Michael asked what about TWA or well, actually that's a different question. We'll get that question in a second. So quiz for all of you, just write same or different in chat. HTTP colon forward slash forward slash example.com verse HTTPS colon forward slash forward slash example.com. Are those the same origin? Different, different, anyone else? Different, correct, different origins. What about HTTPS colon forward slash forward slash photos.example.com or HTTPS colon forward slash forward slash music.example.com. Same origin or different origin? Different, different, different. Different, correct, different origins. Okay, HTTPS colon forward slash forward slash example.com.uk HTTPS colon forward slash forward slash example.com. Same or different origins? Different, different, okay. Final one, HTTPS colon forward slash forward slash example.com slash en HTTPS colon forward slash forward slash example.com slash es same origin, different origin. Awesome, we have some disagreement here. Same origin verse different origin. We have some disagreement. Okay, so most people think it's the same. Someone thinks it's different. So this is the same origin. Why is it the same origin? They're protocol, they're all of their subdomains. They don't have any. All of their domains, the same. All of their top level domains, all the same. Ports the same. The only thing that's different is a sub resource. So something that comes after the top level domain. Subresources don't count towards origins. So, as long as all of the parts that come before your top level domain and your port are the same, that's the origin. Anything after that, those are subresources and they're considered part of the same origin. Cool, excellent. MDN, which this same origin link actually points to, has a great description of sub or same origin. And I kind of sort of just gave you one of the tables that they have there. So feel free to go check that out for more information on same origin. Any other question? Oh, question. TWA, this was a question from Michael. Sorry, that got lost. What about TWA's that contain multiple subsites under distinct subdomains or even different domains? So the answer today is they don't work super well. They don't work super well. If you're on an Android device and you navigate to a link, that's a different origin, even if it's the same site, like an English version of the site versus a German version of the site that have different top level domains for the, top level domains or even subdomains for that. For instance, whatever language or whatever domain or origin the PWA was installed from is considered the main origin and anything that's not that is considered a different origin even if they're owned by the same people. So on Android devices you'll get what's called a Chrome custom tab. So basically it'll look like you've navigated to a tab and it'll see the different origin and you'll see the title of that tab. And then when you go back to the original origin, it'll look like an app again. On Chrome OS devices, if you try and navigate to an origin that is outside of the installed app's origin, it'll open a tab in Chrome. There are a lot of proposals to try and figure this out. Things ranging from your TWA manifest files and things in your Android app to actual web app manifest extensions, but there isn't one that's complete yet and implemented yet. So unfortunately the recommendation right now is try your best not to have different domains or subdomains for different portions of your site. It's something that was super popular many years ago but it makes building PWAs slightly harder. So try and avoid that where possible and follow along on some of those new and upcoming standards that are being worked on to voice your opinions on them and give feedback on them to improve how this works. Question from CloudDeck, are there problems with cross-origin calls on JavaScript, JavaScript? Wow, in a bubble wrapped PWA, if course headers are properly set, can course headers be properly set for this? So think about the PWA that bubble wrap wraps as if it's running in a browser tab. So if it'll work in a browser tab, it'll work in your bubble wrap wrapped app. So if everything is set correctly and it works correctly in browser, it will work correctly in your PWA. That said, or in your Android app. That said, don't expect you to be able to bypass things like cores just because it's wrapped in a TWA. You're not making server side calls. You're still making client side calls as if it's running in browser. Does anyone else have any questions? Try it out. Go spend the next 10-ish minutes. Adding a digital asset link to your site. We'll meet back here at, when does this end? This ends at the top of the hour, doesn't it? So maybe spend five minutes trying to get this to work. Go ahead. Okay, everyone. I'm sure you might not have all finished, but you can finish this up after the workshop because we're almost done. We just have one more thing to do and I wanna see what y'all have learned throughout this workshop. So we're gonna do a quick little quiz. Feel free to put your answer in chat, one, two, three, or four. So the first question is after generating her Android project with bubble wrap Sally commits the generated blank file to her version control system so she can rebuild it whenever she needs. Do we think it's one, twamanifest.json, two, signing key, three, appreleasebundle.aav, or four, build.gradle. What do you all think, one, two, three, or four? The answer is TWA manifest, correct. Next, Jack is looking to have his QA team test his PWA Android app. He blank his Android app bundle to an internal testing track. Uploads, builds and uploads, releases, or signs and uploads. Which one do we think it is, one, two, three, or four? Two, four, two, twos, and a four, four. So we've got some disagreement here. So the answer is four. He signs and uploads his Android app bundle to an internal testing track. While an Android app bundle does need to be built, in order for it to be uploaded, it must be signed. So the most correct answer here is sign and upload his Android app bundle to the internal testing track. And then the final question. Oogie Boogie's PWA Android app isn't running full screen. To fix that, they get their SHA-256 certificate fingerprint for their blank and upload it to the digital asset links file located at blank on the same origin as their PWA. Upload key, well-known slash assetlinks.json. Upload key, assetlinks.json. Signing key, well-known slash assetlinks.json or signing key, assetlinks.json. What do we think it is? One, who else? Three, you've seen at least four of you respond to these so far, so I'm looking for two more answers. One, three, four, three. Okay, so the correct answer is three. Why is it three? Well, the SHA-256 fingerprint we need is the one that actually signed the app for the user. The upload key is what lets us put it onto the Play Store, but the Play Store is the one that actually owns the signing key. So we need the signing key. And then the assetlinks file needs to be inside the dot well-known folder. So it's signing key and dot well-known slash assetlinks.json. And with that, we're done. Congratulations, everyone. Thanks for doing all of this work and joining us for this code lab for adding your progressive web app to the Google Play Store as part of Chrome Dev Summit 2021. Thank you very much. If you have additional questions, feel free to ask them on Discord. Also, Grant has just sent a link with feedback for the workshop. Please fill that out so we can improve this workshop. Thank you very much.