Hi, it's great to be back here in Berlin, back at Droidcon, I enjoy coming here a lot because that's where I started off as an Android developer a while ago. And now I work at Google and we'll talk a little bit about Android Instant Apps and what they can do for your app and how you can use them.

But the gist and probably the most asked question before we don't have any time in the end is, is my app suitable to be an Instant App? And if you have some URL behind your app, so a website or whatever that you can address your app with, even if you don't have it already, if you could do that, then, yes,

your app is generally suitable as an Instant App. So like I said, I'm Ben, I'm an engineer on the Android developer relations framework team based in London and I spent a fair amount of time working with the Instant Apps team even before it launched. We started it in 2016, we opened up and said this is what we're doing, this is the

idea behind it. 2017 at Google I O we opened up the SDK so everybody can play around with it if they use the new Android Studio builds. It's quite cool because it's basically, it's based around the three principles. It's about discoverability, so making sure that your app gets discovered, also performance,

and the third key principle of Android Instant Apps is security and privacy. And those are the three main topics that we'll take you through today from both the user perspective as well as the developer's perspective. So let's get started with the discoverability. Basically, so far when you wanted to find an app that meant you had the trodden path.

So you look for an app either like on the Pixel launcher through the phone, you're looking for something that does photos, searching for more apps, it takes you to Play Store, you find apps that have photos or you browse the Play Store or somebody gives you a recommendation for an app or you find it through an ad or whatever and you download it, you install it, and you play around with it a little bit. Then you forget about it and after a while you find it again via an intent and oh yeah,

I actually have this app and it does stuff or while browsing through your app folder and just you have drawn like oh yeah, cool, I have this app, I use it, or I just deleted it, which is sad because that means that your app doesn't get the exposure and the usage it actually should get. So just to make it a little bit more clear, what happens is in trodden path is yeah,

the user has to find your app and then they have to install it and they have to use it, which is the one thing why we actually make apps is we want people to use it and make their lives easier. So there is a lot of friction involved. So we decided to reuse it a little bit and let's take a look at how that works with Instant Apps instead of getting a link, in this case,

Joy sent me a link to BuzzFeed Tasty, instead of going to their website, which is a great website to be fair, but instead of going there, I get this screen that shows me oh, there is an app available and it's being downloaded directly and I can use it in an instant without having to go through the whole

friction of hey, have you seen this app and everything, but I just get a link. Cool thing is this doesn't just work from chats, it works from basically everywhere where you can get a link from. So it would even work for local cases like beacons within conferences or having an NFC tag on a machine or something like that.

We started off with 50 early access partners from all different kinds of companies and all different way, a lot of different companies that from all over the world that did a lot of different things and achieved a lot with Instant Apps, even with the early access SDK. The SDK is now generally available and a lot of more apps have been developed

by now and are in development and being tested already. And there's currently the last milestone that we published was more than 500 million devices, it's more than half a billion devices that can use Android Instant Apps. So you've got quite a big user base and that's one of the really nice things

for a feature that just actually shipped a couple of months ago. That's quite an impressive number. So how does it work? Why do you actually want to do this? One of the things is your app is a monolith, right? It's just this one thing and just one APK that gets installed on a device so you don't really have to care for it, right?

Actually it's not that simple. So your app consists of multiple features and those features have some commonalities. And your code in most cases doesn't reflect that because there was no need to do it, which is cool because you can just throw all the things in one module and you have your packet structure and that's really nice,

but you might end up with a little bit of duplication and with a little bit of mess that you actually don't have to go through. And that's where Instant Apps is really cool to help you with. So your code could actually look like that. So no overlap at all would of course be the optimum. You've got a base feature which contains all the basic functionality

which is shared over the other features that are on top of that and all the other features that are just attached on top of that. For an installed app, that would still mean that you have your base APK, your base features as well as the features that you have on top of that just in one APK. It's just different libraries that you include

instead of having everything compiled directly into the APK, you have the libraries already. And on the device it would be the same thing. You just install this one APK. So nothing much changed other than your code structure so your users won't notice the difference if they install the app the regular way that they already did it before.

But for an Instant App, what happens, the Gradle plugin does not produce one single APK but each of those features, the base feature as well as the feature modules on top of that, are APKs themselves with their own manifests, their own Dax files, their own resources and everything. So they could in theory run on themselves.

Usually a base APK does not have an activity so it can't really run anything but it could have and it could work. So if you just have one single feature module that you want to play around with for example or your app is small enough that it just chips with that, it's fine, you just have to still have one APK but your users don't actually have to actively search for it

and can easily use it directly from the get-go. So the power of Instant Apps is actually that you don't have to install everything at once. So if you have multiple features, you can just have the base APK which always gets installed

because it has the shared common code as well as common resources in there that you want to have for all your other features and on top of that you can have just one feature installed which means that you would reduce your download time from that perspective because you don't have to download and install the other features

but literally just a very lean and slim portion of your app. But if the user decides to go through another entry point, cool thing is that only the other feature gets installed and if you have everything modularized into your different features and everything is addressable as part of the Instant App, then everything can still be on the device. It doesn't have to be but it can be at the same point in time.

So quite cool, you get fine-grained control over all your features, you've got a lot cleaner edges because you actually have to define those interfaces and you have to make sure that everything is self-contained and it works on its own which is really cool because it gives you the smaller sizes on the one hand over the wire as well as on the device.

Also your build times, not in the first case but over time the build times improve because you don't have to build everything all the time but only the modules that you actually work with. Also your architecture consecutively will improve and you have stability because you have to actually clean up after yourself which is when you work with an app that has been developed for a long, long time,

in many cases overdue. I've been there, I've done that, so it's really good to find a place where you can say, hey, this product owner, we actually want to make sure that stuff gets better and this is a good way to do it. And I can show you how you can pitch it. So just to recap that, you can have one Android app which is before you install it or after you install it.

It's basically the same thing. The only difference is from the user perspective is that small icon which just shows that it is an Instant App. Straightforward, neat, that's all from the series so far. So let's take a look at what the requirements are for running and developing an Instant App.

On the one hand, it's Lollipop Plus, so a cool thing is you don't really have to worry for all the lower API levels for now. Your app still can target lower API levels. Your installable app still can do, but your Instant App basically just targets API level 21 or one of the newer ones and you're good to go from that point.

When you want to start with development, you use Android Studio 3.0 which comes with new plugins with the Instant App SDK, the new Gradle plugins for, on the one hand, the feature plugin which will either output the APK if you're on the Instant App path or output a library if you're on the installed app path as well as the Instant App plugin

which is used to replace the application plugin. Also gives you the app links assistant which makes it easy to generate the file that you put on your server to actually tell the Play Store where to look for the match between the Android app and your website.

There's already good documentation so I won't go into too much detail on that end. Also, the emulator supports Instant Apps. All you have to do is have a test account on that, so basically just any Google account will do to allow you to work directly on your emulator and give you results even with tests so you don't have to attach a device.

Also, there's another thing which is the refactoring tool which has just been recently introduced. Which allows you to give you a brief, very quick refactoring possibilities from your app to just go from this is what I have, this whole clutter bunch of code. Just take one, for example, one activity and I want to refactor that into a separate module.

It takes all the resources that are somehow wired with that activity and pulls it out and puts it into a separate module. Also works with code that is not an activity so you can just use your model package for example and put that into your base module and work from there.

So what do you have to do? That's the part where it actually gets interesting for developers. But before we dive into that, who of you has already taken a look into Android Instant Apps other than this? Cool, who of you is considering changing their app to an Instant App? Wow, cool, looking forward to that.

So if you have questions, please just shoot me questions either after that or on Twitter or wherever you can get a hold of me. So let's see how we can do the modularization part. Yes, there might be some severe refactoring. So it can take a while and it can take a buy-in from people other than the engineering team

because it's a cool feature, yes. I really like working with it but there's people in companies that actually decide over time of engineers. I know that but so let's take a look at how we can make that easier. So depending on your app structure, all you have to do is from the common part of you, basically have your settings.gradle file

which has in many cases just one app module, maybe more but let's assume that there's just this one app module. All you have to do to make an Instant App is remove that. And then replace that for example with the base module, the hello module, one of the other modules and another module. Those are all your code modules.

This is where all your affected code lives. On top of that, you create one installed module which is the module that you already had but renamed as well as an Instant module. Naming scheme is completely up to you. I recommend this, having your features in a path, so basically just having one folder features

and under that you have all your features because it makes it easier to discover and work with on the file system as well. Well, that was easy. So let's take a look at what we actually have to do. For your base module, you apply the feature plugin and set base feature to true. So Android and Gradle know that this is the base feature and this is the one that all the other dependencies

can rely on so you can easily include it as a dependency from your other features. Next up, the feature modules. Well, basically the same thing but not setting the base feature to true and depending on the implementation of the project as well as on any other libraries.

So if you have libraries that are only being used in one module, I recommend scoping them narrowly. So don't just put all your dependencies in your base module but make sure that you have them as narrowly scoped as you actually can do because that will save you bandwidth in the first place.

For the installed app, all you have to do is just add your implementations, all your features that you have in there and you've got your go. And for the installed app, you just have the same thing but with a different plugin. So instead of application, you use the installed plugin and that's it, at least from the Gradle perspective. Also, your manifest might have to adjust

just a little bit, luckily. All the activities that you want to start will have to have the action view as well as the browsable category. One of them will have to have default which is your main entry that you already had in the first place. So usually the one that you have as a launcher icon as well.

Which also should have, each of them has to have a URL that they can be addressed with. And your default activity has to have the default URL metadata. So this is where the Play Store will easily just send your users this way if no other URL was found for the matching patterns that you created.

Also, this is a really cool thing with Android Oreo. We introduced a new sandbox version to make Instant Apps secure or more secure than they already were. And the cool thing that we can introduce with that is migrating user data from Instant App to installed App.

So you don't have to start from scratch, at least from user perspective. The users don't have to start from scratch when they decide to install the app and use it on a longer basis. But we'll come to that later.

So what does performance mean? It means a lot of things, but in that context, let's take a look at what we want to do. You want to have your users get from the link to actually being able to use the app in an instant. Excuse me, the pun, but that's basically what you want to have.

You want to make your users wait as little as possible. You want to make sure that your users can use your app after they click, that they don't have to wait a long time. And how do you make that possible? That is the main question for this section. So main thing is constraining your size. This is where it gets interesting for how to pitch to your team.

When you develop, you've got unlimited file size that you can use. So while you just push it through ADB on your device, your file size does not matter at all. So if your app has a couple of hundred megabytes, then you can still install it directly and play around with it. So all you have to do is just add a new branch,

make sure that you have your modules and have the greater plugins that I showed you earlier, and then you can already use it. You can already run an instant app and that's cool for pitching it to the rest of the team, your product owners and all the people that have to buy into the app that you actually want to develop.

So when you work on shipping it on the Play Store, then you are on the development track in the first place, which will constrain you to 10 megabytes per downloadable bundle. That doesn't mean that it's the full app, but just the bundle, I'll come to that in a second. Once you decide to ship to a beta or you're aiming for release,

your bundle will have to have less than four megabytes. Aim for less because again, your users will thank you for that and also users probably won't have the fastest ever bandwidth in most cases. Bandwidth will definitely be not as good as it is within the office

and within the tests that you work there. How do we calculate that? It's basically just 1024 times 1024 and times the megabytes, so yeah. So what's with the bundle size? Let's assume that you've got a base APK or base module that has three megabytes because there's a lot of resources in there and all that

so I can understand it, but all you have is one more megabyte for one feature. That's four megabytes, but you could have another feature that has another megabyte because that's a different bundle that can be downloaded so those two add up to four megabytes and you could have combined features, again, a megabyte.

Just to make it a little bit more clear, if you extract that, you could have up to seven megabytes with just extracting that and this will combine feature into two different features. If you make sure that your base module gets smaller, you even have more space so you can occupy a lot of space on the device, but I recommend still going for as little as possible.

So you have those four megabytes and in order to make sure that users are getting the app as quickly as possible and don't get lost on the way or don't get bored and do something completely different, aim for less. So let's take a look into the tools

that we offer next to the Gradle plugins that you can use. On the one hand, really handy is the APK Analyzer, which probably should have cropped it differently, but this is for just an installed app. You can see that all the resources are under there that the classes take a lot of the code. Usually the resources take a lot of the file size. Usually the resources are bigger,

but in that case, because it's a very simple sample, it's just the classes that takes the biggest chunk and it also works with Instant Apps. So you have your different APKs and you can see, hey, the basic APK is the biggest, so I may be able to reduce that. And you can easily just see what's going on where and which part you actually want to make smaller and how big your file size actually is.

At some point, there will be something on there as well for Instant App, but at the time I took the screenshot, it wasn't there. Also, there's a couple of good sessions I will mention later on for reducing your app's file size. So that's the part for the tools that we offer

for Instant Apps within Android Studio and making sure that your file size is constrained enough. Also, another thing that we haven't talked about yet is a really cool thing which allows you with configuration splits, so it's basically kind of like split APKs but different.

It allows you to split up different APKs in terms of screen size as well as the processor architecture that you're running on. If you have native code, that's super handy. And the user's language because, yeah, if you have a lot of translations in there and the users just use one, why ship all of them because you could make it faster,

easier for them to access everything. Also, same thing with screen density because all your drawables are in there and all your drawables are in all the different sizes, which means that they will take a lot of space on the user's device. So how does it work? You just say, generate pure splits. You enable them for either density, for ABIs.

Density will automatically gather all the available densities for your app and will produce APKs just based on that. So you will have from LDPI to XXXTPI APKs, which literally just hosts those drawables and map maps.

Also, there will be one which hosts everything in case there can't be a match made. So you won't run into the trouble that you don't have the matching APK for your user's device. Works as well with languages. So you have to specify the languages that you want to split up. Same here.

You will still end up with one single APK as well, as added to that, different APKs for all that. The plugin does all the magic of matching that. And the Play Store ships it accordingly to the user's device configuration. It's cool. I like that. Once I saw it, I was like, yep, this makes it a lot faster and a lot smaller. Quite happy for that.

Also, further reducing your APK size, just a couple of small things is within the Gradle plugin. Again, code modification, resource shrinking, as well as use ProGuard. And that's quite important. Works super easy, so no reason why not to do it. Well, unless you encounter any bugs.

If you do, let me know. And another question that I get asked every now and then is, do I have to migrate everything at once? Well, the answer is no, just the feature that you want to ship as an Instant App in the first place. And your user might end up at the edge of your Instant App. And you haven't done the next part of your app already.

So you want to gracefully upgrade them to the installed app, which basically means you could either do that by saying this is the install button or within your app drawer, you can have the install button as well, or I'm not that much of a fan of modal dialogues myself, but works in that case as well.

Just saying, oh, this is not done yet with developing. So let's install the app instead. So that's quite cool. You don't have to do everything in the first place. Works, again, super easy. Just check whether it's an Instant App. And then you show the prompt with your referrer. And the Play Store handles the rest. So you basically get the pop-up of the Play Store,

which says this is the app I want to install, and go ahead from there. Next principle for Instant Apps is privacy and security. Well, one of the things to make sure that you don't leak any data and make sure that your users are kept secure, we demand that you use Smart Lock, which is super handy.

I've seen it the first time with Netflix ages ago. And every time I install Netflix on a new device, what happens is I'm logged in. And that's bliss. It's super easy. It's super handy. And I very much love it. And it's easy to implement as well, like a couple of lines of code.

And you don't have to deal with storing password user data, because all of that gets taken care of already. As well as payments, you can use the already existing and familiar in-app billing APIs for digital stuff. So if you sell whatever it is that is just digital, you can use those, or you can use the Google Payments API for anything that you want to ship in the real world.

So for example, you want to deliver a pizza. That's the way to go for this API. If you want to buy a shiny new sword in your game, then that would be the in-app billing API. So nothing new on that. To make sure that your users are actually kept secure, we don't give all of the permissions to Instant Apps that the installed apps have.

There's still quite a handful. Of course, internet and checking whether there's network available and all the other ones, so that's really nice. Also, there's two new permissions for Oreo and above. So your Instant App could have a foreground service, which displays a notification, like playing music, does that.

So you would use that, as well as being able to read phone numbers. For background services, they can run when you have an Instant App. When the Instant App is being used, you can do stuff in the background, so you're not limited on that extent. But if the user stops using it, service might just terminate.

A lot less gracefully than it does with an installed app. That is by design, and that is the way it should be. Because if the user stops using it, why should your app still use resources? Also, you probably want to store something on the device of the users. So you can use local private storage, use the cache directory, the cookie API,

or share preferences, just as you already did with your installed app. Or you could use internal content providers, or SQLite databases, so those work fine as well. But you don't get access to external storage or exported content providers, because that would

leak user data in the worst case. So we tried to make this, tighten this up a little bit, make sure it's as secure as possible. Good thing is that if you rely on that, at least if some parts of your app rely on it, you can still have that within your installed app. So you're not completely bound into not using either external storage or exported content providers.

But for the Instant App, you don't get that. Like I said earlier, migrating user data works with the sandbox version that you have to declare on your installed app in order to tell the Android system that this app is compatible, and you potentially could use the cache API,

cookie API, which is available to installed and Instant Apps. So it doesn't really matter which end of the spectrum your app is on. And it's also available through the package manager or the support package manager, which you can just use like this.

So you get the package manager, and you just check whether your cookie would fit into the cookie storage. And then you update your Instant App cookie. Nice, straightforward. And it is a byte array giving you a high amount of flexibility. So there is some parsing from this end and that end involved.

But yeah, you can just store everything as long as it fits the cookie jar. Reading it, same thing. You just get the package manager, and you get the Instant App cookie out of that. And then you retrieve your stored data and make sure that it's converted to the proper data types on the other end.

And you can just delete it as well. Well, it would be sad if it still would sit there forever. But you can use it instead of a couple of other things. So if you already did shared preferences to store user data and you want to be compatible with Instant Apps, it might be worth looking into that. Also, a couple of other use cases in just persisting things that you want to, from the Instant App,

get over to the installed app. There's a lot of samples available on GitHub. If you are missing samples, file an issue. And I will see whether it's already there or we're already working on it.

Or if we actually see, yep, we're missing that because there's just so much time that I can spend on working on the samples as well. So that was a little bit faster than I expected with the content. But before I finish, there's still a couple of things. One of the things is there's the obvious geoco link.

For Instant Apps, this is where all the information is in. This is what you want to take a look at if you want to get started with Instant Apps. It has literally the bootstrapping information on top of what I've told you today. Also, there's the samples. And there's a lot of questions on Stack Overflow already. So if you have questions on why doesn't this work,

what are you doing wrong, please go to Stack Overflow. If you have issues with the samples themselves, post them on the samples. And if you have suggestions for new samples, I'm happy to accept those and take a look into what we can do with that. Those are the sessions I mentioned earlier that I want to talk about. Definitely would ask you to take a look into

if you're considering using Instant Apps. They're on YouTube, which means you can speed them up as well and just pause when there's a point where you actually want to slow down and try to reconcile what they just said. It's introduction to Android Instant Apps, also building an Android Instant App, which is a, so one is more the,

over the big picture of what is Instant Apps, the other one is actually diving deep into building an Instant App. And it's also live coding involved, so it's always fun to watch that. And also, Wojtek did a session at IO, best practices to slim down your app size, which has more tips on how to make sure

your app is as small as possible without sacrificing anything on your user's side. With that, thank you very much for your time. And I'm. Thank you, Ben, and now it's time,

rather much time for questions, if there are any. Are there? Yes, please. Thank you for the talk, first of all. Thank you. My question is about that, do we have to have one single base,

or can we have multiple, or even if we have the multiples, then we need to create one single to depend on them and then mark as a base. So let me try and rephrase that. Do you have to have one base APK and all the other features on top of that? Yes.

For now, kind of. But you still can have all the other features that you want to have. So there is a limit to layering those, which currently you can have one base APK and on top of another APK, another feature. Yes, but my question is mostly about

marking as a base in the gradle. Okay. Is it only possible for one module, or can we mark multiple ones as a base? Well, you can have one base module that you can ship within one app. So that's that. Yeah. Okay.

But if it turns out to be more effective for more people to have a deeper hierarchy in that, we're happy to reconsider it. But for now, it works for most people. If you run into issues, like I said, I'm happy to take a look and see why we can solve them. Okay, thank you. Welcome.

Hi. Thank you for your talk. Thanks for your time. My question is about, do you have any recommendation about theming? Material design? Yeah, design, theme. Yeah, material design is always a good choice. Is the Instant App different color than the Instant App? No, I would totally go for the same theme

for everything that looks and feels the same. So it shouldn't be, I wouldn't consider it as a different app. It's literally the same app before you install it or after you install it. So would you define it in everything in the base module? Everything that's required in there, yes.

Okay. So if you can scope things a little bit narrower, then maybe you might want to have a, just have a dummy declaration in your base module. So you can still, for example, have that in your, in the modules on top of that. And you can basically fill them in later on. Okay, I have to try that.

Hi. Hi. So what happens after a user decides to install the app? Do the base, does the base app and the feature apps, the APKs, they get installed? Or what happens? Or is it different, the APK that gets installed? Because the, so you have the installed app,

which is one single APK, and you have the Instant Apps, Instant App, which is three, in this case, in my samples, was three APKs. And to make sure that you have one single APK, so you get the APK, actually it gets downloaded from Play Store. So the new one, your installed APK gets downloaded. So the output is basically,

for the Instant App is a feature APKs and a base APK, and there is a different output for the one that gets installed from the Play Store. Like is there a bigger APK containing all the features and the data? No, it's a zip file.

It's a zip file containing all the features. So you, the output is a zip file and you upload that zip file to the Play Store. And the Play Store then decides what to ship, because in the end, you might end up with, if you use configuration splits, you might end up with a lot of different APKs. And all those APKs are just picked, like cherry picked, to match the user configuration.

And if you then decide to install the app, then the installed APK that you already built before will get downloaded and installed, and that's when you can migrate the user data. Okay, so the app that gets installed is different. It's not the same, then eventually.

I mean, how I imagined it is I decide to install an app, and then it's gonna install every single feature in the app. I mean, since there are- Well, yeah, that's where the installed app has all the features in there. Let me just jump back on that.

So many slides. Should have started the other way around. So there we go.

This is what it looks like on the device, which is what it can look like on the device with an instant app. It can have all the different features. But for your, this is what the build output is again. So this is what you will get if you click the install button.

The fresh APK gets downloaded with everything inside already. Okay, so does this kind of isolation, to make it compatible with producing instant apps, does it introduce limitations, generally when the app gets installed fully? So the way modules inside within the app interact with each other,

will it be different in any way than it is at the moment? No. Okay. So for your installed app, you can do everything just as you did before, but for the instant app, you just have to limit yourself with background usage, with the permissions that I mentioned before. You don't get access to everything. If there is a valid use case for a new permission that has to be introduced or is opening something up,

bring it to me. I'm happy to take a look into it and talk with the engineering team on that to make sure that it actually is a good thing for all the users. Thanks. Thank you. Two more questions from this side and then one from there. Are there potentially any problems with splitting everything up in modules

if I heavily use flavors? Yes and no. So with flavors, until recently, you had to declare the flavors because of a run time, a race condition, you had to declare them in each and every module that you want to use, but by now that should be resolved.

It's been a while since I looked into that. There was a sample that I'm still bound to do and after this and another conference, I'm on vacation for a little while and after that, I will look into that again. If you don't see it, just ping me again and I'm happy to work on it.

And also if you encounter features because not everybody uses flavors heavily, but if you do and you encounter error issues, please let me know. We're more than happy to work on those issues. Okay, thank you. Thank you. Please try to brief you now with your question. Hello, you said the permissions were reduced. Can you access the media store or the SD card? No. Okay.

So you can use internal storage, but external storage is not allowed. What about the media store, where you store pictures? You can still? No. No, okay. Sorry for that. Next one. Hello, my question is related. Can you transfer data from the Instant App to the full app so that the user continues?

Yes, that's what the cookie API is for. So in the cookie API, what you get is your, you can store the byte array and on the other side you can read it. So if you're signing it the same way and your package name is the same, you can just use that data and migrate it over to the installed app.

Okay, last question. Hello, quick question. When you get the app, the Instant App, you can actually get all sort of permissions, right? If there is a broadcast receiver, you can ask the permission and then start using the broadcast receiver, technically. No. No? No.

How about services? Yeah. When you are using the app, when you are using the app, can the background services keep running? While you use the app, the background service can run, but as soon as the user stops using it, it can't. All the services are also gonna be killed? Well, it will get killed. It's not as gracefully as it's done with an installed app, but with an installed app, it just might get killed at any point

when the user stops using it. Okay, as example, you cannot, you cannot listen to the broadcast receiver for sort of incoming caller or stuff within Instant Apps. No, because you don't have the permission for incoming calls. But I can ask the permission when the user opens the Instant App. No, because it is Sandbox. That's what the Sandbox 2 does. You just get a limited set of permissions

to not allow you to do that. Users are not allowed to do it? You can try and get that permission, but you won't get it. You won't get it, okay, thanks. If you get it, let me know and we'll fix it. Okay, are we done with the questions? Oh, we have one more. Very brief. Okay. If I understood, there are now several APKs packed in a zip file.

Correct. Does it means that we have DEX limitation on zip file now? No, the zip file gets unpacked by the Play Store and you basically have something like multi DEX because you have different APKs and they all have their own DEX. Yeah, thank you. Thank you. Thank you.

Danny, could you come to the stage to plug your machine? Thank you. Thank you, Ben.