Google I/O 2011: Taking Android to Work

>>Gabe Cohen: Hi, everybody. Welcome to Taking Android to Work. My name is Gabe Cohen. I’m the product manager for Android Enterprise And I have with me Fred Chung, who’s a developer advocate on Android, and Andy Standler, who’s one of the senior engineers on Android We’re going to talk today about enterprise mobility, Android’s enterprise features, and how you can extend Android in the enterprise But first, a little bit of housekeeping. And you’ve been through this for many, many sessions now. You’ve got our links to provide feedback on the session, whether or not you find it useful. And also to submit questions via moderator Of course, we’ll take live questions also So let’s get started As you’ve been hearing over the last couple of days, Android is growing very, very fast There are hundreds of devices, hundreds of carriers, 400,000 devices being activated a day, and over 100 million device activations to date But you might not know it’s also growing fast in the workplace. But why is that? You could point to that consumer growth as the source of the momentum. But how does it actually translate into workplace acceptance? Well, let’s think back a second It used to be the case that the I.T. department bought smartphones. They’d buy hundreds and thousands of devices. They’d set them up, they’d give them to the users, they’d support the users, they’d pay for the data plans and so on. And then really good smartphones started coming out that were targeted directly at consumers and consumers started buying the smartphones themselves. And some of those consumers, namely, C-level executives at Fortune 500 companies started demanding that they take those phones to work. Because nobody wants a cool personal smartphone and a lame corporate phone; right? But to make that work, a phone needs to do a lot of things Uh-oh. I still have a printer update. That’s amazing Sorry Anyway, in order to make that work, the device needs to do a lot of things. It needs to meet your home needs, you personal needs, your social needs; it needs to meet your work and your productivity needs; and it needs to meet the needs of the CIO and the I.T. department Companies have a really big incentive to work with their employees to accept their personal phones because there’s a lot of money to be saved in both the hardware and the data plans Let’s talk about how a company decides to accept a mobile platform So let’s put on our CIO hats for a second and funny-looking glasses, bow ties, whatever, and talk about the main concerns a CIO has when accepting a new platform First of all, they’re securing the corporate data from loss or from theft. There’s managing you in and more diverse devices at scale And then there’s apps, which is all about the CIO’s responsibility to make the company more productive with new technology So let’s take a second and walk through each of these in a little more detail So first of all, the CIO needs to make sure that the company’s data is secure. And even an employee with the best of intentions is a threat to your data security. Because after four drinks, he leaves his phone on the bar [ Laughter ] >>Gabe Cohen: And he probably doesn’t read your memos that you send out about setting a password and a lock screen for your devices Maybe he takes that phone to Starbucks and logs onto the corporate intranet, you better hope you’re using SSL or VPN. In the worst case, a competitor could find your vice president’s home, break into her car, steal her phone, rip out the battery, put it in a faraday cage You get the idea Secondly, the CIO needs to figure out the processes that are required to manage all of these new devices, more diverse devices at scale. Which means they need to set processes for the users, how do they know whether or not their phone is accepted? How do they set it up? How do they bring it online on the network and to the intranet, the mail service, et cetera? They need to define security policies for the company or potentially for individual organizations within the company that have different security needs depending on the types of information they handle. They need to figure out how to support more users over time on different kinds of devices, if they have problems using the device, if they forget their password, which is extremely common, if they lose it. And then, finally, over time, they need to keep a holistic view of the entire fleet Finally, the CIO needs to make the company more productive with the new technology. And that means they need to look at the key software that their employees use, they need to look at whether or not there are mobile interfaces or apps available for that software, and then decide whether or not to build mobile apps for that software or buy them. And once they have the software, they have to get it to the users. How do they distribute the apps to those users’ devices? And then over time, how do they maintain them? And in some cases they need to lock down the applications users can use on devices because there might be liability issues. You know, with users consuming mature content or consuming lots of data that might come back in a corporate overage bill. They might also have regulatory

issues they need to comply with So now that we’ve looked at those three major areas the enterprises consider when deciding to decide a platform, I want to talk quickly about how Android actually addresses those needs So Android is first and foremost focused on users. We want to build hardware and software that users lust after. We also want to build the ecosystem as big and as fast as possible, because it pays all these dividends in terms of network benefits; right? We get more developers, we get more applications, more devices, and more user choice But there’s a lot of money being spent in the enterprise. Enterprises spend millions and millions of dollars on hardware, software, services, support, and so on. And there are actually a lot of users in the enterprise as well. Like, a lot of consumers actually have jobs. And those are the users that we’re focused on here. We want to unlock their ability to take their personal phone to work and use it for both purposes But it’s really important that we keep the enterprise support that’s in Android open and extensible, because we want OEMs and software vendors to go out there and make money in the enterprise today. And they’re actually doing that. If you look at the Motorola, they released an enterprise-focused device, the Droid Pro. It has a better keyboard for business usage You can look at NitroDesk. They released TouchDown, which is a drop-in Outlook replacement, essentially, for your phone that’s available in Market It’s extremely popular One of our partners, Mobile Iron, actually has added Android support to the platform to their Mobile Device Management Suite So we have a lot of partners out there doing different things. And especially when you look at the OEMs and the carriers, they’re doing a lot of interesting things and moving potentially in a lot of different directions It’s a good thing, because they’re out there actually getting devices into the workplace today. But Android actually needs to introduce standards over time into the platform so that the enterprise features that are there for developers are exposed in a consistent way So next I want to talk just briefly about the features we’ve actually added to the platform over time So way back in Donut, we introduced some of the first relevant features, secure Wi-Fi and VPN support. In Eclair, we added basic exchange support for e-mail and contacts In Froyo, we completed the exchange support by adding calendar. And then we added a really important piece we’re going to talk about again — talk about in a minute, which is device policy management, which is about setting up security features and requirements for the phones. In Gingerbread, we added more productivity features into GMail and calendar and contacts. And in Honeycomb, we added some really interesting stuff. We added more security policies that control passwords. We added support for device encryption, which is one of the most frequently requested features we have been getting from enterprise customers We added global address list support across the suite of apps and in contacts for both exchange and Google Apps So that’s kind of an overview of how Android is approaching the enterprise, the features that we built, how we’re prioritizing things And I hope that’s been useful to you guys Next I’m going to hand it over to Andy Standler, who’s going to talk a little bit about device policy management framework >>Andy Stadler: Thanks, Gabe Okay. Hi, my name is Andy Standler, and I’m going to sort of address the fact that this is a developers’ conference and dive into a little bit more of a development topic, actually. And that is how you, as developers, can tackle one of the problems that Gabe touched on. And that is how can your app ensure that it is running on a secure device. Or how can your app control the aspects of your device configuration to make sure that it is in a secure environment Now, what kind of apps need this? I’ve kind of broken it down into three really broad categories. The first is apps that are really the client end point of fleet management solutions And I’ve listed a couple here that you’re almost certainly familiar with. These are the apps that provide an administrator with the ability to control and monitor the security status of a whole fleet of devices Now, some apps don’t work with a server, but they really need to also provide the assurance that they are on a secure device and that the data that they’re collecting or presenting is safe, remains safe, and is presented only to the intended users And, finally, there are apps that provide device management or fleet management types of capabilities, but they are really oriented toward single users Now, these are really just a loose collection of overlapping suggestions. There are plenty of other kind of interesting ways to deploy and use these devices. And our challenge was to enhance the Android framework in a way that could support applications like these, applications you can come up with, and, most importantly, support multiple applications We’ve always believed strongly that Android apps need to coexist peacefully with each other. And security-oriented applications

really are no different So in order to support applications like the ones I have described, we developed the Device Policy Manager. And in the next few slides, I’m going to show you what it does and how you can write apps to use it So the first thing to tell you about is policies And these are the actual specific controls that an app can place on a device. So you’re very familiar with policies, things like require a screen lock password, require the device to be encrypted. These are policies We introduced policies in Froyo. We enhanced and added to them in Honeycomb. And we are going to keep on adding policies as releases continue And if you want to think about where — the roles involved, there are really these roles: Applications that you write are going to set the policies. The Device Policy Manager is the APIs and the framework for maintaining those policies and communicating them among the various modules. And, finally, the rest of the system is supposed to obey the policies Now, let’s look at one sort of interesting aspect of this, which is, what happens when you have multiple apps that are trying to control policies? When there are multiple sources of security policies, we need to consider what I call the principle of increasing security. Any app can make or set policies that increase the security of the device, but no app can use policies to reduce the security of the device In practice, this really just boils down to a simple set of rules for each policy. So, for example, passwords need to keep getting longer and stronger or more complex. And things like a screen-lock timeout would get shorter and shorter, which makes for a more secure device You might be wondering if the policies I’m describing or the concept of policies is really just a different version of Android permissions And they’re a little different in a subtle but important way Policies — I’m sorry, permissions are — they basically let your apps do things that are risky or may be costly or might expose data Policies, on the other hand, actually increase the security of the device. So they kind of — the more policies, you’re moving in the more secure direction Anyway, now, with these policies in place, we just have to define an API and a work flow for using them Now, in order for you to create a policy management application, you need to add the following three elements. The first is that you need to explicitly define the policies that you’re going to enforce The second is you write a receiver. This is very similar to a broadcast receiver. And this is so that you may be notified of the changes to the device security status And third, you’re going to write a policy controller. And this is where you actually write your own code which interacts with the Device Policy Manager to monitor and control the security status of your device and also to enforce whatever business logic is associated with that security So now we’re going to take a look at a sample implementation. We’ll start with the policy declarations. This is simply a list, like I said, of the policies that your app intends to enforce. And each policy directly corresponds to one or more API calls. If you don’t declare the policy, you may not make these calls And we’re going to see later this same list will be shown to the user in a system activity But, of course, it’ll be formatted quite a bit more nicely And the next thing you’re going to implement is a receiver. And this is where your app can be notified of changes to device security state. I added one little note here, because this is one of these things that — just one of these general Android programming reminders, is that notifications come in on the UI thread We always have to be careful and not get ANRs and things like that But the most important thing is, this is where you learn about the changes to the device status And a little later, we’ll talk about the things that you might do when you respond to these Okay. So, finally, we’re going to implement a policy controller. This will take a few slides, but we’ll walk through the pieces of a sort of sample typical policy controller In this case, it’s going to be one that requires a specific policy for your device, that the user must have created either a PIN or a password for their screen lock So the first thing we need to do is find out if our app has even been activated as a device policy administrator. And if our app hasn’t been activated, we will not be able to make any policy calls at all So the next step is to ask the user to activate our app. And this is the place where policies are like permissions. They are all exposed to the user. The user sees them and accepts them before we can proceed. We don’t allow just any app to start enforcing policies on the device So when you make this start activity call, it presents a system activity which explains to the users what they’re about to authorize And the app only receives permission to assert the policies if the user clicks “activate.” Even though this is a system activity, your app does have a chance to insert some text, which gives a chance to tell the user what’s

about to happen and why. And, by the way, the user might help cancel here. What do you do? We’ll talk about it a little later. But the simplest thing to say is that you need to be ready to keep trying. If you need to get your device to a secure state, you need to be able to retry this process until the user gets there. And, obviously, you’re not going to want to present the secure data or make the secure connections or whatever it is that your app does until they get through all these steps Now, once we have been activated, we can start working with the specific policy APIs This next step highlights an important concept, which is that there are many policies where just because you’ve set a policy, it doesn’t actually mean the device has become more secure So, for example, in this case, we can set a policy. We can require the user to enter a PIN or a password. But until they actually go through the process of entering a PIN or a password, the device isn’t really as secure as we want it to be. So here you see in this code the first call sets the policy. And then the second call asks the question, “Has the user done what they need to do to reflect the policies we’ve set?” And in the case that they haven’t done it yet, we need to again set the policies we want and do what we need to do to get the user to make the changes. And in this case, we’re going to use standard start activity call to send an intent, launch the setting screen where the user can enter a new PIN or password Now, normally, the user can choose from four types of screen lock: None, pattern, PIN, or password. But now, because we’ve established a policy, the user will only be allowed to choose a PIN or a password. So this is a direct example of the policies that you’ve set affecting the behavior of the system Now, once again, this is a place where the user might not continue. They might hit back or home or get a phone call or — anyway, they don’t get past the step and they don’t finish creating the PIN or password. So once again, this is one of those places where you need to be ready to sort of restart or dealing with this Before we wrap up, I would just like to cover a few issues that are pretty important when you are developing device policy applications First, as I’ve been mentioning before, there’s no denying that it does take a few steps to get through the process of getting a device to a sufficiently secure state. You need to account for the fact that the user might not get through all the steps the first time And your policy controller needs to be able to restart the process at any point in the sequence. And your design should focus on moving the device step by step towards the sufficiently secure state So, to use an example, in the platform e-mail application, where we walk through this exact same set of steps, anytime the user exits before the completion of the sequence, we post a notification that says there’s a security — security steps are required. But then we just leave it there, let the user respond to the notification, and at that point, bring them back into the sequence The other thing you might consider is through the use of dialogues or other ways of communicating with the user, tell them what they’re about to do. Because, for example, if you just suddenly present a password entry screen, they might not understand why. So dialogues, notification texts, these are all your friends here Next, there are going to be times when the security level of the device actually decreases An example here is that some of the newer policies we’ve added allow you to set device PIN codes or passwords that have expirations on them. These are designed to force the user to enter a new one, say, every 30 or 60 days Now, if they allow those codes to expire, your device is not really secure at this point, because it’s using an old code. So the device is now in a less secure date than your app wants it to be. However, it’s really up to you — again, this is a business logic question It’s really up to you what to do at that point And, finally, if you are implementing account-based policy applications and if you support multiple accounts, then you’re going to be partially responsible for the increasing security notions that I described earlier. Make sure you don’t let any one of your accounts reduce the security levels that was required by any of your other accounts Now that I’ve covered the things that you need to do when you implement a device administrator Fred Chung is going to show you a demo app that actually walks you through a few of these steps [ Applause ] >>Fred Chung: Thanks, Andy Hello, everyone I’m Fred Chung. I’m a developer advocate on Android. I work with a lot of external developers, and my focus area is enterprise Well, Andy just talked about the detailed implementation of the device policy management API. In this section, I’m going to do a demo that shows a practical application of the

API What — the use case is actually pretty straightforward We are trying to enhance the security of an internal application Well, by internal application, it can really be referring to any applications containing sensitive information. Well, for example, your HR application, where it contains my salary information, I really want to secure that kind of information Typically, those applications may already have an app-specific password requiring users to authenticate. Here’s the problem. Can I see a show of hands, how many of you have your screen-lock password set up? Including the device you got yesterday All right. As it turns out, more than half of smartphone users don’t have their screen lock set up. For those of you that didn’t raise your hand, I urge you to please set it up after this session So back to the demo We’re trying to, you know, perform a demo that’s aiming to enhance the security of the application by ensuring the proper screen lock is set up Well, before diving into the demo, let’s have a, you know, quick overview of the high-level architecture of the application As you can see on the screen, in the middle is the Android client in the tablet form factor On the right is an admin server that’s sitting somewhere in the cloud. For this demo application, the admin server is built on Google App Engine for Java. But in reality, it can be based on any technology stacks. It doesn’t really matter The admin server exposes a couple of interfaces It exposes an HTML administrative interface, allowing system administrators to go in and define security policies. And what I mean by “security policies” is that they can define such things as what’s the minimum length of my password, does the password have to be PIN type or alphanumeric or pattern or so on and so forth Now, the second interface that is exposed by the administrative server is a Web service interface in order to facilitate two-way communication between the Android client and the server Okay. Let’s jump right into the demo Right here is — I’m using this laptop to access — I’m sorry. Can we switch to demo? >>Gabe Cohen: You’re on >>Fred Chung: All right Can we switch back to demo, please On your right, I’m looking at my admin server through Chrome browser. And right here, I am working on a Motorola XOOM, obviously running on Honeycomb. And this icon here is the demo app Let me go to the admin server first. I’m going to go in and log in as a user, a test user All right. I’m looking at the administrative interface. It’s a pretty clean UI. It is an admin interface allowing administrator to go in and define security policy Let’s go ahead and set up a test security policy, say, requiring PIN of minimum of four digits in length. I’m going to go ahead and save it. Now it’s persisted to Google App Engine Now I’m going to go back to the Android client right here. Before launching, I want to say that when you launch the app, it’s going to present you with a series of setup steps Here’s the first step. It contains a bunch of instructions, basically, telling me to go to the admin server and set up a security policy. Since I’ve already done that, I’m going to go back to the Android client and click “next.” Now it shows me the list of accounts that are already set up on the device. And I’m just going to and click on the one account that I have set up Now, the app is about to perform a number of steps outlined in Andy’s section. In reality, those steps will probably complete within a fraction of a second So — and, therefore, in order to make it — in order to make this demo more meaningful and make this demo easier to follow by everyone, we have deliberately introduced a number of processes requiring human intervention in between steps just to make sure the concept is clearly communicated across The next step that I’m going to perform is to synchronize the security policy from the server. It’s syncing. Through 3G network I’m glad that it works So it came back, brought back with the security policy that we just set up, as you can see, with PIN and a minimum password length of four Notice the two question mark icons. Those

icons represent the fact that at this state, the application doesn’t know how to deal with the security policy, because it hasn’t been activated as a device administrator. And I’m going to go ahead and do that next by hitting on this button “activate.” It then triggers a system dialogue box. And as Andy also pointed out earlier, that in this system dialogue box, you can put in some customized message to make — get clearer to the users what they are dealing with Now, at this point, there could be multiple outcomes; right? The users could click on “activate” or they could click on “cancel,” or “back.” So when you’re dealing with an application, you need to account for different possibilities like that. Let’s go back to the activate screen. This is the same screen we just looked at. And let’s now go ahead and activate it. The application has been activated as a system administrator. As you notice on the — for the icons, they switch from question marks to exclamation points, meaning that the existing password, which doesn’t exist on this device, the existing no password set up on this device actually is not sufficient as per the device policy And, therefore, it’s presenting me with this enforce password button. And I’m going to click on this, which then triggers another system intent to cause this password change screen to appear If you remember, we defined a security policy requiring a PIN type of password. You notice how these selections of not secure and patterns are disabled, because these are deemed less secure than what’s being required by the security policy Let’s go ahead and set up a pin-type password of — I’m not telling you Okay. Now, I have set up a PIN, and the device recognizes that. Okay, the existing password actually is sufficient for the — what’s being defined by the security policy. And then I can actually go ahead and access my security — my sensitive content Okay. Now that the device is properly set up with a screen lock password, and I’m going to show you what additional security can be provided by the administrative API in conjunction with cloud-to-device messaging. For those of you who are not familiar with that, cloud-to-device messaging is Google’s implementation of push messaging So — and one of the criteria that Gabe talked about in his talk that the CIOs need to really care about device loss, theft, right, in the event that happens, they need to have a way to be able to remotely control the device or remotely limit certain access. And that’s what this next part of the demo is about Let’s go back to the admin server screen and navigate to remote admin interface. There are two buttons. Okay, I’m going to just go ahead and click on “lock device.” What happens after clicking on this is that it’s going to send a push message through C2DM to the device and the device should react to it by locking up the screen. Give it a few seconds >>Gabe Cohen: Show your hands >>Fred Chung: And, of course, it’s not working Let me give it one more try Well, it’s not working. But I hope you get the idea. All right. Can we actually switch back to presentation mode, please All right. That’s too bad. But, trust me, it works [ Laughter ] >>Fred Chung: Let’s see. So that concludes the demo, at least part of the demo, where we just looked at a proof of concept on the kinds of device management capabilities that are possible What we just looked at is open source under Google Project Hosting. I strongly encourage you to have a look at it As developers, you can further expand on these kind of capabilities by incorporating more useful features such as remote wipe or password

resets Now, let’s switch topics a little bit and talk about a different thing One of the criteria CIOs consider is how to get apps to users’ devices. And let’s talk about that in the next section All right. Well, you may consider, you know, a — a system administrator of a company may already have a collection of Android apps that they want their users to install. Well, some of these apps may be home-grown applications that are highly proprietary to the business flows of the business. And other types of apps could be coming from third-party applications that are publicly available. And these types of applications are aimed to increase the productivity of the workforce. For example, TouchDown clients or Documents to Go or Angry Birds. The last one may not make sense, may not be such a good idea for certain businesses But I hope you get the idea For these types of publicly available apps, right, you may want to direct your employees to Android Market Let’s see Okay. Well, Android Market is a great distribution vehicle for distributing publicly facing applications like what we just talked about. All you have to do is to direct your users to a URL of this format by including the package name of the apps you want them to install. Using Android Market, it gives you, you know, a number of very useful features at no development cost. Just to name a couple, hosting, hosting is something that you don’t need to worry about. Also, any app updates are automatically made available to the clients automatically However, internal app distribution may require different solutions, because, well, in some occasions, it doesn’t really make sense for others to see your internal applications Of the or you simply don’t want others to know the existence of certain private apps I’m going to show you two commonly used approaches to distribute internal apps next Well, let’s first have a look at side-loading I’m showing the audience here, the majority of you should probably know what it is. It’s actually pretty straightforward. One pretty common implementation is to host the APKs on a server. It can be any server capable of serving files. It can be Apache, or it could even be based on Google Sites works pretty well, too To install apps, users just need to point their browsers to their URLs, or by simply clicking on a hyperlink. When the download completes, users taps on the APK, then the standard app installation screens will take over I also want to point out that in order for side-loading to work, you need to make sure that the unknown sources selection under settings is checked. And since Android is an open system, right, different OEMs or carriers may choose to do different things. Some have chosen to disable these settings altogether. And in that case, side-loading may not be possible on those affected devices. I just want to make sure that people are aware of that Now, we talked about side loading just now With this approach, as you can imagine, as your usage grows over time — which, by the way, is a good problem to have — it may become a little hard for your employees to manage all of the URLs that they are given. Or sometimes they may get all the URLs or the updates mixed up In order to circumvent this, I’m going to talk to you about a more sophisticated approach, which is what I’m calling Internal App Directory Let’s have a look at an overview of what this Internal App Directory is all about In a typical deployment, it involves a — you know, a piece of server software and a corresponding Android client If you look at this setup, it’s not that different from the demo setup that we just saw Through an administrative interface, system administrators can publish a bunch of apps that they want to be made available to their users. Periodically, the Android app would check in and say, “Hey, give me a list of apps that my user can install.” The list would then get displayed on screen And at this point, the Android client can perform a number of validations, for example, he can check whether the list of apps already

exists on the device, and if so, flag the user appropriately And if you need to build these kind of solutions yourself, I strongly encourage you just to bookmark this API doc for Package Manager This API — this class exposes maybe a few dozens of methods that allows you to gain visibility into the various packages that are already installed on the device Just to name a couple, this API gives you visibility into the kinds of applications that already exist on the device. And get package archive info allows you to do something like to check the validity of a downloaded APK and stuff like that So when the user chooses a particular app that they want to download, the actual download of the APK happens, and it may get stored in external storage. And lastly, it — the user — when a user clicks on it, you can fire a system intent to trigger the installation flow Well, as you can see, this is a pretty involved method. But over the long term, we believe that if you — if you wanted to invest in these kind of solutions, you could build something like this yourself, or you can purchase some existing solutions out there in the market And the functionality is pretty similar, actually Well, I wanted to close with sharing a few resources related to what we talked about today. We are excited about Android’s momentum as a team in the consumer space, obviously, and also in the enterprise sector In the enterprise sector, as well, we know that we are not there yet. We have some more work to do. And our team is actually working pretty hard to make sure we become successful in this area as well Lastly, for developers, we are looking forward to seeing the kinds of innovations from this audience right here. Of the and we’ll hope that you can build a pretty healthy business and be very successful in the long run Thank you very much [ Applause ] >>Fred Chung: So if you have any feedback, please provide us. We’d love to hear your feedback through this URL And I’m going to open it up for Q&A. For those of you that are watching the stream — the live streaming, you can use the Google Moderator for Q&A >>Andy Stadler: Who is broadcasting that >>Gabe Cohen: I am. I’ll get it on the screen Just make that a little larger Let’s start in the crowd. First question up front >>> Are there any plans to implement user accounts, say, different users could log in with different passwords to a tablet, and different applications would be enabled based on that user’s profile? >>Gabe Cohen: I can take that That’s something we’re thinking about. I mean, when we first started building Honeycomb and thought about the tablet use cases, like, passing advice between users on the couch, it became apparent we might need something like that in the future. We definitely also get a lot of questions about people, again, in the stool use scenario having different security requirements, you know, not wanting to impose the harder security requirements to access their personal stuff. The and then, of course, in the worst case, what happens when they leave the company, what gets wiped So we’re thinking about that. The but no specific plans >>> Thank you >>Gabe Cohen: Yeah. Maybe from the back mike >>> Two questions. One is, is there any way for an application to detect that a device is rooted? >>Fred Chung: I believe that there’s a programmatic way that I’ve seen once on stack overflow But I don’t know off the top of my head what that approach is >>> You’ve seen some app that has managed to do it without asking the user any questions, right, because the user will obviously say, no, it isn’t rooted, because they want access to enterprise resources, so they won’t give you access they won’t give me root access to figure out whether the device is rooted or not In this case, the user is the enemy in some sense, because the enterprise — >>Andy Stadler: I totally understand the question you’re asking. And it’s an important question I don’t think any of us can answer it >>Gabe Cohen: I think that’s a question best targeted at your security team, in case they have ideas. And it may vary from device to device also >>Andy Stadler: Yeah >>> And the other question was, are you planning to support certificates for active sync? >>Gabe Cohen: That’s actually one of the questions in the moderator queue We’ve been hearing that pretty frequently also. We’ve noticed that users have had a number of setup problems, because we don’t support certificate authentication in AOSP exchange today. So that’s something we’re actually working on >>> Thank you >>> So I have a question about the suggested

method for using the — what you call the internal app So it sounds like Google doesn’t have a solution, so you’re just asking the developers that build to come up with their own distribution mechanism But it sounds like that’s still going to require side-loading to be enabled. And that doesn’t work at all on AT&T phones. And I don’t know on other carriers in other countries whether they enable side-loading or not So — and in many ways, to ask people to enable side-loading kind of means less security to them. So it seems counterintuitive that you would do it that way So are there any plans to incorporate some type of enterprise type of market in the future? >>Fred Chung: Well, good feedback. I think we can take that back and look into that further >>Gabe Cohen: We’re definitely aware of those problems. We’re thinking about it. But I don’t think we have any solutions right now >>> Okay But then it will require side loading through that mechanism; right? >>Fred Chung: That’s going to be the mechanism >>Gabe Cohen: That’s correct >>Fred Chung: Yeah >>> Okay. Thanks >>> One of the things that you didn’t mention about the device admin is that once you enable it, you’re unable to uninstall the app Can you explain what the motivation is behind that and why it’s not documented >>Andy Stadler: Well, I’ll answer the second one first. Anything that’s not documented is certainly not intentional. And so, you know, we welcome your feedback on places where you’re finding things missing in the documentation I think that’s a fair statement on any API Now, in terms of why you can’t uninstall an active administrator, the answer is quite simply because, you know, this is something that has made assertions about the security state of your device. And to simply uninstall it would be to drop everything Now, the good news, however, is that you can un- — you can deactivate an administrator app, at which point you can uninstall it And when you deactivate it, that’s one of those call-backs I mentioned. So, for example, when you see that you’ve been deactivated, that’s one of those regressions in security I was talking about, you know. If you’re protecting data, that’s the time to wipe it or whatever >>> Right. But there’s no security preventing someone from deactivating it. So it just seems like it’s an extra check box a user has to uncheck. It doesn’t actually make it impossible to uninstall or anything like that. It’s just an extra hoop you have to jump through first >>Andy Stadler: It’s more than an extra hoop It’s very explicitly a notification. So the question is really, then, one of are we going to block it forever, which I think is what you’re suggesting, or are we going to allow the users to do that change, but at least give the apps the notifications they need And the choice was made in the framework design to take the latter course, which is we’re going to let the users do this — You know, this is, again, one of these things where it’s the user phone versus the corporate phone And the current, you know, direction is that we, you know — the user still has the control of their phone. So we make sure that the corporate data has an ability to detect that some changes are happening and protect itself in whatever way is necessary. But we’re not currently going to block that change entirely >>> Okay. The current error message is just uninstall failed. It’s not very useful >>Andy Stadler: I — I’m not surprised >>> Thank you >>Andy Stadler: Very good feedback. Thank you >>Gabe Cohen: Let me take a couple of the moderator questions we have up here The first one I don’t have a great answer for. Are there plans to explicitly support remote control apps so enterprise I.T. can solve problems directly on employees’ phones? I think the answer is, today, I’ve seen some vendors in this space actually partnering with OEMs to expose the APIs they need. For instance, one of the, you know, APIs I’ve seen requested by people who do this kind of support is, you know, I need to screen cap or actually remote control, like, super dangerous permissions that we haven’t actually figured out how we’re going to expose, like, if they would be in Market or what have you So we’re thinking about this, but I don’t have any direct solutions today. I think in some cases, a lot of our partners go to OEMs to accomplish specifically what they need, and then if they’re really bold, they try to create standards across the OEMs I think we still need to figure out which are kind of the most common features we need to support remote control, and then ultimately we would like to incorporate them into the platform Assuming that the user is informed that, they give consent, and it doesn’t neuter sort of the user experience So for the second question up here, let me jump down. Are there plans to implement a VPN provider API at the platform level so different VPN types could be installed through the market? This is also a case where people are solving this problem today by going to OEMs. You know, I think Cisco has an OEM partnership to provide one of their VPN clients. There are a few others. I know the Droid Pro package is something

else What we’d really like to see it that any vendor has access to the users via the market. Again, VPNs are extremely dangerous because they can basically monitor all network traffic when they are active. So we’re actually working on coming up with a solution that allows these types of things to exist in user space, to be distributed through Market. But working on the usability and the experience is kind of challenging for something that’s so dangerous We need to make sure there are a lot of hoops to jump through. Not unlike a device management agent Back to the mic >> Is there any way to push configuration on the phone, like VPN settings, for example? >>Gabe Cohen: We are definitely thinking about that in conjunction on working on improving VPN support, but nothing specific >>Andy Stadler: Aren’t some of the third parties showing some things along those lines? >>Gabe Cohen: I know some third parties have gone to OEMs to get APIs or are using private APIs because they have been side loaded with root privileges by OEMs to do remote configuration I actually think this is one of the most important areas that’s going to be the most common across devices that we will need to tackle in the future, but we are not quite there yet Yeah >> Hi. If a company wanted to start using your device manager API for internal applications, they would want to ask questions about what tools you have so we can test the application to be sure they are actually secure >>Andy Stadler: I’m sorry, what’s the question? >> What testing tools are available? >>Andy Stadler: None that I’m aware of, but maybe you can tell me what you had in mind and we can start to look at that >> A lot of companies will have like a corporate I.T. policy that this has to go through some kind of penetration testing >>Andy Stadler: Ah, I see >>Gabe Cohen: No, I don’t know that we necessarily have any vision for best practices for penetration testing of Android apps. It might be a interesting question for security team, also. Sorry >>Fred Chung: We will be glad to get more information from you after this session >>Gabe Cohen: Next mic question >> Yes. Are there any plans to add programmatic — the programmatic ability that certificates into the certificate store? Because currently if a certificate has a C.A. that isn’t built into the Android OS, that presents a bit of a problem >>Andy Stadler: Yeah, and so I know Gabe mentioned earlier because we had another question about certificates, and, really, what we are, in fact, working on is we didn’t want to just jam certificates into one app. So there’s under way basically a more integrated solution for dealing with certificates and things like you are talking about are definitely part of the work flows we are looking at >>Gabe Cohen: It’s a known requirement. It’s not one certificate. It’s many certificates in order to bootstrap an email client. So, yeah >> I have two questions. First one was in the first part of the demo you had some policies apply to a specific user account. So I guess that implied that you could have different policies for different accounts; is that correct? >>Andy Stadler: Yeah, I think what he was showing was an example where the server would be tracking multiple accounts >> Right >>Andy Stadler: Not the device >> Not the device >>Andy Stadler: Right >> And the second one, you compared policies with permissions. It’s possible to create custom permissions. Can you do that with custom policies? Like can an application define a custom policy? >>Andy Stadler: No, and the reason is because the policies don’t work, they don’t really matter unless they have some teeth to them So a policy — you can’t just say I want to make a new policy. You have to have the REST of the OS obeying that policy So, really, the policies kind of come from the bottom-up. A particular piece of the system will — The thing I didn’t describe in the device policy manager is there’s two tracks of API. There’s the parts that apps would use to assert policies and then there’s the parts that the REST of the system uses to say, well, what are the current policies? What do I need to do? And so an app coming up with a policy won’t really help unless the system is watching for that policy >> See, I am employed by a device manufacturer so I have the ability to do the other part of it so, I don’t know, how would I implement something like I only want certain users to be able to change any settings, for example? >>Andy Stadler: I see. If you are working for an device manufacturer, of course you have the ability to add methods to APIs. That’s, obviously, a capability you will have. Then you would be talking about running apps that would only be able to talk to that so you probably want to use a shared library to distribute for those devices These are the things that are fairly standard in terms of how OEMs can add functionality to specific devices. Nothing really special here The main issue is, again, a policy doesn’t matter unless somebody is listening to that point of impact. And I would obviously suggest

starting there >>Gabe Cohen: Thanks Yes >> If a user enables a policy, say, on a Froyo phone, and the app declares something like encryption which doesn’t exist yet, is the policy granted when the user upgrades? And if it’s not granted, does a user have to activate again? Or if we upgrade our app to add a new policy, do they have to walk through that whole process again? >>Andy Stadler: No. In fact, that’s a really great question, because you have actually noticed one of the subtle but important distinctions, is that when we present the list of policies to the user, we do, in fact, list them explicitly And when they hit activate, we basically, in the system, we copy down which policies the user accepted Now, in this — So, for example, I think you hit a perfect one which is encryption. Let’s say they go through that on a Froyo device, and then that device is it upgraded to Honeycomb Or Ice Cream Sandwich or something. The user has only accepted the original and smaller set of policies. And if the app was — If the app was upgraded to request some newer policies, like encryption, it’s going to continue to run just fine until it tries to assert the encryption policy So it’s going to be bounded within the ones which were accepted However, there is an API, I didn’t show it in the sample code but there is an API where you can basically look at policies on a one–by-one basis. You only need to use this if you have upgraded that policy. And you can say, oh, do I have this one? And if not, then, yes, you do have to loop back and have them accept it one more time Because it really — I mean, you can’t just go do something based on this smaller set You have got to show it to the user and say I need you to give me the OK to do this >> And does the user have to accept all the policies again? >>Andy Stadler: Yeah, it’s Al an all or nothing There are no check boxes or anything like that Yeah >>Speaker4: Front mic >> I have a question. If the application is active, can it actually lower the requirements for security? Example would be, for example, e-mail application. If you had exchange account and admin requires it, if you remove the account it doesn’t actually lower the policies >>Andy Stadler: So what happens is that — remember, I mentioned how there’s policies, and then there’s the state of the device. And they are linked but they are not 100 percent connected So to walk through a typical example, let’s say that you add an account that requires a password. The user enters a password. You have done all the right things. Now you have got a device in that state Now, if they delete that account, we do all the right things, we delete the data that’s associated with that account, we’re going to release those policy assertions. But we’re not going to actively change their password on them So now the device is in a state where it has a secure setting, such as a password or a short screen lock or whatever, might still be encrypted. But if the user happens to go back to the settings for that setting, for that device state, they will see that they have regained the ability to reduce the security on their own At this point it doesn’t matter because we no longer have the accounts in place >> OK. I was testing it on tablet and actually after removing account it didn’t allow me to remove the PIN. So I guess — >>Andy Stadler: It’s either a bug or there was some other source of policies So like, for example, I know when I have been working with policy code — and by the way, I should have mentioned this. In the standard API demos, which is our sort of sample app, we have a whole page where you can manually set and control policies. And sometimes I will use that when I am exploring policy issue, and sometimes I will forget that I left a policy asserted in API demos, and then my other app doesn’t work right. It might not be what happened to you, but most commonly, that’s the case unless there’s a bug. Most commonly it’s that somebody else is setting that policy >> This is just a built in mail application And the second question was talking corporate, any support for — support for proxy? >>Gabe Cohen: Yeah. We implemented it in 3.1, although I haven’t seen that information publicized anywhere, and I am hoping that it actually made it into the release. I think it did So I believe it’s there in 3.1, basic proxy support, although we don’t support auto configuration or authenticated proxy, so it’s not done And actually it’s a little more nuanced than that because Android apps can use different network stacks. That proxy is applying to browser and stacks that use I believe the Java networking stack >>Andy Stadler: Don’t look at me. I don’t know >>Gabe Cohen: I’m like, Andy, come on But not necessarily everything. It’s fob to bypass that, use lower level networking. Then you don’t actually integrate with that proxy support. So we are still thinking about how to complete that. There’s actually a question in moderator here about that that I was going to talk to We also need to think about how to manage proxy support but that’s fairly dangerous in terms of application control of system proxy because, again, that allows monitoring

of all network traffic >> Is it then implemented per connection or systemwide? >>Gabe Cohen: It’s per Wi-Fi network access point >> Thank you >>Gabe Cohen: Yeah Back mic >> Quick question. Is there any plan to implement the way that the applications are pushed from the Web site, the Android Market Web site, from something that will be agreed upon? You know, I am thinking about Google Apps for domain, for business. Once the policies agree to the device, the admin push directly apps to the devices that he has the right for >>Gabe Cohen: That’s something we’ve actually talked about. It seems like that would be useful as a feature, although we haven’t actually come to agreement on how and if we should expose something like that. Again, security considerations in mind. But it’s something we are thinking about >> Okay. Obviously it has to be secure, but once it’s for the device that are linked to Google Apps for business domain, there’s already a lot of policies that you can wipe directly from the (inaudible). I was thinking from this part of the domain, push from here >>Andy Stadler: One thing I want to just mention is every time Gabe says we are thinking about something — >> It’s done already? >>Andy Stadler: — he really means it. His job is to maintain a very long list of priorities >>Gabe Cohen: And I sit in a cubicle and I think about them >>Andy Stadler: And future requests that believe me we know all of you have been asking for And it’s one of Gabe’s responsibilities is keeping track of that So when he says we’re thinking about it, we really have had many discussions about it, I want to let you know >>Gabe Cohen: I mean, that particular idea could be a really great end-user experience, so it is a good idea >> As a user during the week I may have a bunch of applications that have very high security demands, but on the weekends I may want to not use these applications and have lower security requirements, like not having to put in a password every time the lock screen comes in Now, at the moment I can set that up on Friday night, I can remove these applications, remove the security and reset it up on Monday morning >>Gabe Cohen: You can factory reset every week, too >> Sure. Would like a “go secure” mode or a per-application model be more appropriate for that kind of user? >>Gabe Cohen: So there’s a few interesting things we’re seeing in the marketplace. Actually, if you drop by the enterprise booth they are doing something kind of interesting today to address this sort of dual profile scenario It kind of gets to the earlier question we got about profiles, too So, yeah, don’t really have a great answer for this today, but I think it’s a real requirement Yeah, I mean, we’ve struggled with this when we’re enacting one policy for Google users on Android devices, what kind of pass code requirement, and the interaction between our multifactor authentication, or device pass codes. You want to work with the I.T. admin to come up with the minimum acceptable security requirements because users see this for everything >>Andy Stadler: It drives them crazy >>Gabe Cohen: And it drives them insane, you want to make sure you sort of minimize the impact while maintaining whatever your minimum security requirements are Most people don’t really — we have this great conversation about the entropy differences in terms of security between certain length pattern and certain length PINs, and if you think really carefully about what your real security requirements are, potentially you can lower that so it’s not quite as painful >> You will never have agreement with the security I.T. guy and the guy on the weekend Your own data showed that most people weren’t locking their screens Thanks, guys >>Gabe Cohen: So I think we need to wrap up Let me see if we addressed some of the other moderator questions that are here I think we talked about the need for unknown sources. We addressed that. I talked about proxy We talked about VPN specifically, and to this question of, you know, device manufacturers basically extending enterprise support, we think this is a really great thing because people want to use Android for work now. And if they really want to do that, they can buy a device that meets those needs from a manufacturer that meets those capabilities I feel my personal responsibility is to look at what the OEMs are doing to find the things that are going to be the most common, and make sure those are baked into the platform because we don’t want an app developer who is talking to device management to have five different APIs they have to deal with for the leading OEMs to control something like device encryption So we’re trying to introduce standards over time. Like we introduced encryption in Honeycomb, as people were start to go at it on top of Froyo >>Andy Stadler: And Honeycomb encryption is a good example, actually, because we knew how to encrypt the device but we also knew that a lot of other OEMs were also working on encrypting devices. And so, really — and

it’s funny, we get questions like how many bits is the encryption and really the answer is it just needs to be really secure and you all know what that means. But the important thing for us is is there an API for it. Do we have an API and does that API really clearly describe we are going to encrypt at least this much of the data on the phone, and, therefore, any OEM can wire up their encryption system to that? That’s important, because that’s what reduces fragmentation, not putting down a bunch of mandates about you must have this many bits or, you know, blah, blah, blah >>Gabe Cohen: Yeah. So we plan to control these things basically through AOSP APIs >>Andy Stadler: And we’re out of time >>Gabe Cohen: Thanks