Before we get started, let's get a quick breakdown of the room. Do we have any developers in the room? All right. Pretty much everybody, hopefully. Are there any IT admins, product folks, business people? Okay, mostly developers. That's great. That kind of makes sense, I guess. This talk is going to be relevant if you're an independent software vendor, an ISV, a

development agency, or your company just wants to build internal apps. We're going to talk about tools and best practices, how to build apps for the enterprise, which is a little bit different than you might be used to. So, this talk is going to encompass three main points. First, we're going to talk about design, and that's going to encompass the user experience,

thinking about your product holistically, as well as kind of features that you can use. Secondly, obviously, for developers, we're going to talk about how to build this, and that's going to encompass just going through lots of different APIs that we have and things to be aware of. And finally, deployment.

As Sean mentioned, managed Google Play is a really great way to expose your apps to the enterprise. It's a great way to curate your app store for you and your company. So before we jump in too far, I work with a lot of our top partners and customers for

Android, and very frequently I get asked, like, you know, there's lots of different use cases and situations, but one of them is, hey, we have 100 iOS apps and we have 50 web applications and we're new to Android, where do we even get started? This is actually a pretty challenging problem to solve because they were all these apps

might have been built by different teams, different development agencies, you know, there's no overall product, and they might span multiple lines of business. So you know, usually when someone wants to build Android, a lot of the first thought is, hey, let's just build 150 or 100 Android apps to just replace this and get going as

fast as possible. But in reality, that's probably not the best way to go. You know, that's going to, you know, introduce a lot of pain points for your users, your customers, which could be employees, it could be consumers as well, depending on what kind of app that you have.

So I think some of these are fairly obvious, but there's lots of different sensors, as you can imagine, on the Android device, or on Android, yeah, an Android device. Most importantly is, like, connectivity, so there's cellular Wi-Fi, you might be working,

you know, with an app that doesn't necessarily have internet access, depending on where you are. You know, if you're working, you know, for like a transit authority or like a subway-type system, you're going to be underground, you're not going to have all these things, so it's good to keep that in mind. And I'm not going to go through all these, I think everyone probably knows mostly

what these do. So one use case that we kind of work with, we're working with British Gas, and one issue they had was they wanted to make meter reading easier for their users. Anyway, there's a flashlight icon in the upper right, as you can see, it's something

we had them do, and we worked with them on this, is to basically use the flashlight of the camera, the torch, depending on where you're from, to make it easier to read meters. So from a code perspective, this is actually pretty simple. If you get the camera manager, you can basically ask or query the device, hey, what

cameras do I have available, and then ask again if they actually have a flash. So looping through all the cameras we can find, if there's flash info available, that means basically like, yes, there's a flash, and you can use the camera manager to turn this on with set torch mode. Alternatively, if you're on a device, you know, a tablet per se or something that doesn't

really have a flash, you can use the screen brightness as well, so you can turn the screen towards it and actually be able to see this. That's actually even simpler, but you need the right settings permission, and you need to be able to turn the brightness to 255. So it goes 0 to 255, 0 being very dark, 255 being very bright.

One thing to keep in mind, you should definitely remember the previous number before, or the previous setting before you do that, so you won't blind yourself all day. Being a bit more aggressive or ambitious, you could use augmented reality. So for mariners to be able to see and identify boats easily, you know, we helped create this

app, which basically puts an overlay on top of, you know, a camera in real time. So if you move the camera around, you can see that, or you would be able to see, you know, that boat obviously moving and the label staying on it as well as any other vessels in the area.

To do this, you actually have to have an anchor point for gravity, which is basically saying, like, everything points down, and you need to be able to manage one layer and being able to put another layer on top of it and make sure that you have the same focal point. So from a code perspective, ignoring the, you know, generation of images in the AR piece,

you can get the sensor manager, and we're going to use gravity in this case because that's something that universally globally works on the earth, and we need to get the vector of where we are, and this is going to be changing in real time. So with the sensor manager callback, you can see that there's an X, Y, and Z axis,

and that's something that is going to constantly be changing. You need to register for this using the sensor manager listener, and basically this is going to be, like, in real time updating, so this is going to be called very frequently, so you need to make sure that you're asynchronously updating any other image layers that you might have, so it's not, like, you know, skipping around.

And finally, this is an internal app we have at Google. It's called Fixit, and it's for reporting issues, you know, with the Google GBCs, which is our video chat units that are in all of our conference rooms, as well as pretty much any other kind of facilities issue we might have.

Sorry. One thing that it does, which is pretty interesting, is it uses a GPS location to help you quickly put bugs in because it automatically knows where you are, and not only it doesn't know exactly what building you're in, but it can actually tell what floor you're on. So there's a couple of ways to do this.

Starting out, Google or Android always generally knows your last location. It's not updated very often, but it's a pretty good test if you haven't been moving around too much, and it's very quick, it doesn't really require much battery, and that's something you're going to use is the location manager getting the last known location at the top.

But let's say you want to actually do a little bit better job and you might have been moving around, and that is, you know, you want elevation, and that's going to be actually giving you, like, the floor as well. So in this case, we actually know what floor you're on, we know what area of the building you're in, and we can quickly actually say, oh, you're probably in this area, so you're probably having an issue with one of the things here, and that uses the camera as well.

So when you're starting up an app like this, the first thing you do is get the last known location to kind of set the stage of where you are, and then finally, as you're launching the app, you can use the location manager to start requesting a GPS location, which takes a little bit longer and uses a little bit more battery, but it will end up being more accurate.

So let's move on to building. So how do we actually build an app? What are the best practices for building a great enterprise app? So there's a few things to call out. You know, Jetpack, which is actually unrelated to enterprise, but I think it's worth mentioning. Single sign-on management and security.

So before we get started with this, I just want to call out one change that we made to Google Play, and that is, as of August this year and November this year respectively,

any new or updated app in the Google Play Store is going to be required to target Android Oreo. So this means that if you have an app currently on Play Store, even on managed Play, that doesn't update to API level 26 or Android Oreo 8.0, you will not be able to update it.

There's a couple of caveats to this. If using the Play publishing API or using, you know, a command line tool like Fastlane, it will be exempt from this only on the managed side. So any new app that's going to be uploaded to Play in August is going to require that you're targeting the latest level of Android.

This is a greater initiative to help Android apps stay more current and just have generally higher quality. And as I mentioned, any app that's already in the store must be upgraded to Oreo or APL of 26 before November this year.

And there is enormous amounts of documentation in this and how to upgrade your app from basically any version, and we have actually specific documentation for the enterprise side as well for any other use cases that might be out there. So Jetpack, really quick. There's lots of talks at IO about this. We just announced it this year.

Jetpack gives you a nicer way to handle all sorts of things like the support library, any of the foundational classes, screen rotation updates, things like that. It has architecture components which were announced a year or two ago at IO as well, which a lot of it is a semi-replacement for ReactiveX or RX, which is nice.

So if you don't use RX extensively, you can actually use Jetpack in this case. It also has behavioral components for testing as well as UI components just to help, you know, make everything a little more uniform on the Android platform without having to use as many third-party libraries.

But again, this is unrelated to enterprise, and please check this out. So let's move to security. So this is one of the most important topics, and this probably deserves its own talk or two here today. But, you know, one of the biggest things is I was talking about the platform, which is Android. I know if you heard Sean's talk, you know, he went through how we're doing an enterprise-recommended program

with Android devices, and that's saying, like, we know these devices are secure, we've hardened the Android platform, and we know they're going to perform well. Our ecosystem, so this is going to be Google Play and managed Google Play for managing your applications. Google Play Protect is a constant system that's always running,

which is always looking at your apps to make sure they're free of vulnerabilities, malware, and using legacy versions of libraries that might have issues. And finally, your app. So that's why everyone's here today to learn about how do you build secure apps, and this is where everyone here has to do a good job of trying to build vulnerable free apps.

So jumping into that more, if we had to pick three things about app security, what would they be? First, secure network protocols. Don't send clear text traffic or passwords or anything like that. Secondly, storage on the device. There's a few different ways this can be done,

and this needs to be done properly from an enterprise context. And finally, our safety net APIs, which help make sure that the device and the apps you're running aren't fraudulent, haven't been hacked, haven't been compromised in any way.

So secure network protocols. In your Android manifest, you can actually turn off the ability to send clear text. So this means that you can force SSL or HTTPS to be on all the time, so if there is a library or any type of call that's attempted to be made,

whether it's malicious or not, it just will not go through. So you could use a third-party API, like anything that, you know, your company might have policies on, you know, everything has to be secure, everything has to go over SSL, but you might be using a third-party app or a third-party library that doesn't necessarily conform to that. Firebase by default actually conforms to this, so if you use Firebase,

if you use like crash reporting or analytics or any of those kinds of features, it already works, which is nice. So, moving on to proxies. So, if your company needs to, if you're in a regulated market, if you're on a fully managed device where the company owns the device, there's a few things to be aware of. You can actually intercept the traffic on the device if you need to mount in the middle of it.

This is done for, you know, pretty good business reasons usually. From Android 7 forward, apps have to explicitly trust user-generated certificates on the device. So the app actually has to opt in and say, I trust the certificate.

And again, this is done in the network config, which goes into the Android manifest. So right there in the middle where it says like trust anchors, like that's where you actually list certificates that you trust and this app will trust, and this has to be in here, otherwise if you have a certificate that's on the device, it will be ignored. Same thing with domains. If you have a smaller, if you're, you know,

if you're working on like a smaller app that doesn't use a lot of domains, you can actually list them directly in here to say like, these are the only domains that this app will trust and this app will be able to reach out to. That kind of locks down where traffic can go and come from, so you can't be going to rogue networks or accidentally trying to load something you're not supposed to.

This can also be done through EMM's and management, as well as certificate management, if you're using an EMM to manage your device deployments. So use default storage. So the storage that comes with, you know, is based in the sandbox environment.

So every app on Android is in a sandboxed execution environment, so every app has its own area that's protected. You know, in Android 7, at Nougat, we changed this so you can actually have a different key for the work profile and the personal profile on the device, which means that you can actually encrypt data separately and differently between the two profiles.

So, as you can see here, you know, data from app A cannot interact with app B, and data from one profile cannot talk to data from another profile. And finally, external storage.

So this is something that could possibly be disabled on the device and not be there. One issue with enterprise apps in general is, you know, your device is being controlled by an EMM, or one of the profiles is being controlled by an EMM, and there's a lot of features that could be turned off, and external storage is one of them. So you need to make sure that you're not using this in a way that could cause issue,

or basically, you know, the external storage is a shared place that any app on the profile can see, so it could be untrusted, so any data that's stored there needs to be validated before being brought back into the app. Safety net.

So, safety net is our suite of APIs that allow you to check the device and the apps that you're running to make sure that they're safe, to make sure that they're CTS compliant, to make sure that the device is not rooted. To go through how this works, the safety net APIs are part of Google Play services.

API-wise, they're actually fairly simple from the application side, but they do require a server component. So from an application side, you generate a nonce, or basically a one-time use byte array, as like an identifier, and pass it into the test method in the safety net API.

Most of the code here, this is Android, but most of the work actually has to be done on the server side, because if you're making decisions about can I trust this device, can I trust this app, you shouldn't be doing that in an app, or not in an environment that you don't know if you can trust or not. So, after you call safety net API test, you're going to get a JSON web signature,

which is going to be an encrypted string, you're going to send that to your server, validate the fact that your trust chain is in place, you have to verify the signature of the JWS, you're going to send the nonce that you created to make sure that this is actually the same request, any timestamps, and this is what the payload looks like.

So the two really important pieces here, besides just checking, you know, yes, this is the nonce I sent, yes, this is the time that I did this, and the package name to make sure that, yes, this is the app we're talking about, is CTS profile match and basic integrity. So CTS profile match means I'm on a genuine Android device that Google knows about, that we check with our CTS compliance suite,

and the device is not rooted, it has not been compromised in any way. This is something that, from an enterprise perspective, you always want to make sure it's true. If your enterprise is a little bit more lax, or maybe you're in a BYOD case, maybe in a retail case where, you know, some folks bring their own device, and it's not maybe as big of a deal, basic integrity,

that means that the device is still not rooted, but the device might not have been CTS compliant, which means it could have been a device that's from a smaller OEM or manufacturer. So one of the other parts of SafetyNet is the Verify Apps API.

This is actually a pretty simple list of APIs that allow you to just check to make sure, one, is Verify Apps enabled, which is part of Google Play Protect, and there's no other harmful apps on the device. So the most important thing here is really the list of harmful apps.

Generally speaking, you want to make sure that, just in case Verify Apps is not enabled, you can check and you can enable it, but more importantly, you want to be able to list the harmful apps, and what this is going to do is enable your application to kind of be a reporter

of any type of, I guess, malware on the device. So you're going to be able to call this SafetyNet List Harmful Apps Method, and that's going to give you actually a list back of apps that are potentially harmful. The payload is going to be something like the package name, as well as a list of reasons why we think these apps are harmful. This is something that has to be built into your enterprise,

and will have to be built into a reporting system of some sort to make sure that, one, this app is disabled right away, or admin is made aware of the issue. So single sign-on user authentication. So, you know, on the web today, we're used to seeing something like this, right?

It's, you know, when you use Gmail, use Drive, use Docs, you know, any of the kind of Google services out there, you log in once and it just kind of works all over the place. You don't have to think about how to do this, because, you know, the web's already there, it's already done, you know, it's all using OAuth.

So, what about when you're actually building, you know, your own app? This actually becomes a little more complex if you haven't put any forethought into it on how to actually build this properly. So, you know, the first step is fine, that's pretty easy, but when you go to this case and you build, you know, two more apps or end more apps or 50 apps, you know, you don't want the user having to sign in

and dealing with the sign-on constantly of each app, because that's pretty unattainable, and this is actually an issue right now depending on, you know, the company or the products that you're working with. So, wouldn't it be great if it just did this? We go to multiple app sign-in to handling and understanding how to sign in in one common way.

So, let's look at a diagram of how this could possibly work. So, your EMM provider or your mobility manager is going to provide your app with a login hint, or it should provide it with a login hint. This could be a username or email address, most likely. We're going to send that to your backend,

so your backend is going to have to, you know, basically have a discovery service of some source to say, okay, I understand this username, I understand the context or the app that it's coming from, you know, and provide and give you a login screen. So, it's going to be like a similar OAuth login screen, again, similar to like logging into Gmail or on G Suite. And the user types in their password, it returns, they're logged in.

The one thing that we didn't talk about yet was the fact that they're actually using a Chrome custom tab under the covers. So, we use Chrome custom tabs to make sure that one, you know, when the user's logging in, they can't actually modify the URL, so they can't go somewhere else.

You know, it's hosted in a secure context, so the app actually can't pull any data out of there, so they can't like, you know, try to like listen for your password or do anything nefarious. All the cookies are shared across any instance of any Chrome custom tab on Android as well as Chrome itself.

And finally, it's actually using the real Chrome browser and actually showing you that under the covers in an app context instead of the whole app itself. So, that kind of gives you a lot of power. So, automatically, if you're using a similar login provider and using Chrome custom tabs in your Android app, you're already getting single sign-on.

So, now you're able to basically log in in this way and you can do that for any of your applications provided you're using Chrome custom tabs. The OpenID Foundation has a wrapper and has done a great job of wrapping OAuth2 and OpenID Connect in a great, you know,

in a nice library that everyone can use. So, hopefully at the end of the day, all of your sign-ins will look something like this and work pretty seamlessly together. If you want to learn more about OpenID, github.com slash openid,

they do a really great job of providing single sign-on and OAuth libraries. So, you're going to hear more about this later, so I'm not going to go into this too much. As Sean mentioned and you're going to hear from my colleague Kenneth at 205, you know, Chrome runs Android now, or Chrome OS runs Android now. So, that means there's actually a Play Store on Chrome OS,

you know, most of the time apps just work, most of the time, but you'll find out why. And you can also manage this similar to an EMM, but it's a little bit different, but you will hear more about that later. So, everything you've heard so far is, you know, a best practice or, you know,

something you could use on any Android device right now. You could build an app and use all those tools. So, you know, this part of the talk is actually specific to Enterprise, and you can't actually really use these features without actually having an EMM set up. So, as you know, there's two profiles on the device,

so there's two kind of modes. One of them is bring your own device, you know, this allows for data separation, this allows you to bring your own phone to work and securely and safely use a work profile and a personal profile. There's data separation, you don't have to worry about, you know, your company spying on you, they can't see what apps are installed on the personal side.

IT admins like it, you know, we talked about GDPR, I'm sure everyone knows what that is by now. You know, so there's kind of a built-in way to not allow your company to spy on what you're doing from a corporate perspective. You know, on the managed side, if your company provides you with a device, this gives them the ability to do deep inspection, forensics,

remote logging, and remote bug reporting, which is very powerful in cases where, you know, your company needs, you know, especially regulated markets like banks and financials, they have to do these things. So, work profile compatibility. So, when you're building an app,

any app that could run in a work profile, and today a lot of them actually do, and this is actually a fairly large issue across the app ecosystem. Like let's say you install WhatsApp, you know, from Play into a work profile. Well, you might try to look at contacts and realize that this, you know, to get contacts in a work profile and a personal profile, you know,

on a bring-your-own-device setup actually is a little bit different. So, you'll realize that if you go to your contacts, you're only going to see one side of it. You're not going to see both. You actually have to make code changes to fix that. So, the other issue is, too, there's two basic issues with enterprise apps today,

running an app in an enterprise context. One is intents. Sharing intents across profiles is generally turned off by your EMM or your admin, and that can cause like almost instant crashes, because almost generally speaking, no one really expects intents that you create to not work. So, the fix is really easy.

You call resolve activity, and basically if you get a non-null result, the intents fine. If it's null, don't call it. Your app will definitely crash. Conversely, you know, for files, you know, a lot of times it's really, if you're actually saving files directly on the device or you're trying to save files across profiles, you know, it's pretty easy to just give a file URL

and say, oh, just save this there, because it's, you know, provided you make sure that you're saving the right location, it's probably just going to work. On an enterprise context, that's definitely not the case. You should use content URIs for sharing. So, if you actually want to share data

or share files with other applications, you actually have to declare this and use context.grant-uri permission. If you don't do this, your apps, especially in the workflow file, won't be able to share anything directly across each other. And finally, don't use file URLs. You're going to have a bad time. So, back to configuring from a managed perspective.

So, I'm sure we've all seen, you know, screens like this, if you're setting up an email client, a VPN client, you know, it's kind of a pain. There's a lot of information in there that's usually kind of annoying to set up. But, for an enterprise context, you want to make sure that, you know,

if I'm going to have an email account set up on a device or a VPN client set up on a device, you're using the right one. You don't want someone going rogue and using their own VPN or using a different email account or something like that. So, with managed config, you can force set or tell the app to basically inject these settings into the user's application.

So, how does that work exactly? So, there's a few steps that has to happen here. If you're using an EMM with Google Play, your EMM has actually implemented Google Play APIs to push configuration changes to your application.

And also, at the same time, your app is actually going to have a schema in the manifest that declares the variables that you're going to be able to set. So, basically, in your app, when you're building it, you're going to be able to declare, hey, I'm expecting, you know, an email server, a port, maybe the security type and something else. And your EMM will be able to read those values through Google Play.

And your EMM or your admin is going to be able to set those values, which will get pushed down to the device when the app is actually installed. So, at a super basic example, when we talked about SSO, we had a login hint. So, this is a really basic version of a restrictions file,

it's called, a restrictions XML. You know, as you see, the key is login hint, it's a string, and, you know, there's a basic description. And this description is going to show up in the EMM console, and all this information will get transferred and sent to your admin for setting. So, the types, any basic type, you can also use arrays

and you can send in bundles. So, if you have a complex configuration, that's perfectly fine. Or if you have to send in multiple profiles or multiple levels of data, that's okay. You can also send in a code adjacent in a string as well, whatever works, you know, for your app and what makes the most sense.

So, it's actually, you know, now that we say, okay, we've exposed our restrictions, we've exposed our login hint, so we want to be able to, you know, our app wants to be able to launch and be passed in a username or an email address. Well, so far, it wouldn't do anything, right, because we actually have to pay attention to this.

So, using the restrictions manager, you can basically say, get me the login hint. The code's pretty simple for that. The important part here is to put this, you know, when your app starts up and in onResume, and that means that every time your app comes back, you want to make sure you want to read these configuration changes to make sure nothing has changed

because your email could change them at any time, and the app is not going to notice this unless you ask for it. So, to be really sure, you can use a broadcast receiver with the intent action application restrictions changed, and this means that any time that, you know, your admin pushes down changes to your app configuration,

your app will be alerted to this. So, obviously, we've had the same code probably written three times now. I would recommend putting this part in a library so you can easily just kind of call into it. So, the app config community. This is something I just want to raise awareness to. This is a community of, basically, set up by industry leaders on the enterprise side.

It's cross-platform. It's best practices for configuration, generally speaking. So, if you want to learn how, you know, the best way to, you know, manage your apps, manage your app data, it's just a good place to look at or a good resource for that. So, finally, you know, we talked about, you know,

single-use devices like kiosks, and, you know, Android is used across lots of devices. So, that could be, you know, ruggedized, you know, point-of-sale devices, manufacturing equipment. You know, this is partially something you're going to have to do. You have to do a little bit of work in your app to make sure that, you know, the user can't tamper with it.

I don't know about anyone else, but I haven't done this lately, but usually when you see, you know, a tablet somewhere and it's a little bit harder to do now, I don't know. Like, I'm an engineer. I want to go mess with it. Can I break this? So, we can lock this down on Android.

So, as Sean mentioned in his presentation, post, you know, Android P does this in a way that your app doesn't actually have to write any code for. But before that, we have to do something called lock task mode. So, there's a couple of things to be aware of here. If you're going to have a single-use app

which is going to take over the screen, that means the home button, the recent button, and settings is going to be disabled, your EMM or your management, device manager has to whitelist this app for it. So, this is something you're going to need to check for. So, if your app is not whitelisted, none of this code will actually work. It's fairly basic.

You basically want to get, you know, the device policy manager and basically say, hey, on my activity, start lock task mode. That's going to put your app in the foreground and make sure that it can't be messed with, it can't be turned off, you can't get out of it in any way. If you're debugging and testing, really important, make sure that you have some way to stop lock task mode

and unlock me right there. If you don't do that, you're going to have to restart the device and it's going to take a long time to try to actually figure out what you're doing. So, deployment. So, we talked about how to design your app,

how to think about your product holistically, and a lot of different tools and best practices you need to use to build apps for the enterprise. So, as we mentioned before, managed Google Play is really important here. That enables your apps to be configured remotely through managed configurations. It also allows you to basically curate an app store

for your company or your enterprise. You can also blacklist apps and you can also upload private apps. So, basically, you can actually have apps listed on here that aren't even hosted on Play, but they're posted somewhere else, but they're listed here, which is really nice.

So, I'm not going to harp on a lot of these. I know we went through most of them earlier. I think most people probably know how Google Play works. But from a management perspective, you know, one other thing I didn't mention before is you don't actually have to use G Suite or Google Account at all to use managed Play, which is really nice. So, you can actually use your own setup.

Back to Google Play Protect. One part of managed Google Play is you also get Google Play Protect, which tests for, this is a small subset of issues that have happened, basically, you know, legacy code, things like that. This might not even be malicious. It might just be, oh, we haven't updated our SSL library.

You might have gotten the Heartbleed bug, which a lot of people did, unfortunately, a couple of years ago, or a year ago. So, this list is always changing. We're always checking all the apps in the App Store. This will even work for your internal apps. None of this data is sent to Google or anything else. It's more just making sure that your apps are, you know, there's nothing, you know, there's no malware,

and there's no obvious vulnerabilities. It's not 100%. Obviously, there could be other things we don't know about, but it's a pretty nice check against some obvious stuff without having to manually go through everything you're doing. So, one other thing as well is that managed play allows you to do testing. So, there's an alpha channel and a beta channel,

and you can do both open and closed testing. So, you know, when you're building an app internally, you probably don't want to just roll that out to everyone or give it to everyone right away. You probably want to have some testing done first and probably some sort of dog fooding, if everyone knows what that is. You know, one other great thing as well is we've had this on play for a while, but we just added this to managed play is being able to do staged rollout,

which means you can slowly start to roll out an application to a portion of your users. And you can also, now you can stop that. So, if you find, okay, there's an issue, there's a bug, this isn't working, so we're going to stop the rollout. And finally, we have time publishing.

So, this means that, hey, we know we have a service window between 2 a.m. or something like that, and no one wants to stay up and push buttons. You can just say, I want to launch this at 2 a.m. I don't know, it's Saturday night, which is probably not a great time to launch an app, but you can do it.

Computer almost went to sleep. So, one other thing as well, if you're working with a development agency, managed play has very granular permissions.

So, you can actually give permissions per app and per user to almost any type of permission you can think of. So, publishing, uploading APKs, like pretty much anything, managing your alpha beta users, stuff like that. So, and finally, let's summarize real quick.

You know, this talk is meant for, you know, internal developers building apps, ISVs, and development agencies. We talked about design, building great apps, building products that make sense, not just doing a one-to-one translation from other platforms to Android. You know, building apps in a secure and enterprise-focused way,

with, you know, single sign-on, managed configurations, you know, making sure that you're handling profile issues with, you know, not handling, you know, handling intents properly, handling files properly. And finally, deploying on Google Play. So, anyway, thanks everyone for joining us.

I'm John Markoff. I'm going to be around the next two days, so if you guys have any questions, I'm just happy to help you out, since it's a pretty complex topic. John, thanks a lot.