 The main idea behind the app is to remotely control the enterprise app. Suppose the app is installed both in a client-side and server-side, that means the company is an industry app, the employee's device means, so that he can remotely control the employee's device through his app. The core idea of the app is not only monitoring what the enterprise is doing, but also to kind of a parental guide. We have a multiple usage for this core idea of this app actually. If you want to have a tic-tac kind of message to be shared between two devices, you can easily do this. The main advantage of this, like, unless the normal SQTPS calls requires some time, we need network connections to push our apps' teams and download our responses, not like that. So once you push to the Google Play service, we have that messages in a queue. So you can see the live example here, where the Wi-Fi keeps on, it keeps on coming and going in the under room. If I'm going to push some messages to my clients' applications, so what it will do is it will put all the messages in a queue, and of course it has some limitations. So it will put all the messages in a queue. When the client applications goes to the network-available area, so you can easily access the network and you can be able to pass the response, whatever things you are getting. And so the idea of what we've done is here is, like, use the GCM server and the device, I mean, the API, what Android's people provide. And we're going to show some demo, like, how remotely we can lock a device and how remotely we can write the data of the device. Locking the device in the sense I'm not going to lock only the lock features of this functionality. So I can reset the password remotely so that the other side, take for example the employee has lost his device, so he can complain to his admin saying that he lost his device. He may have some sensitive data, like mails and everything, it will be there in the client application. So if the admins come to know that the device has got lost, we can remotely lock the device, setting some password, what he knows. So at the time, when he got back the devices, he can be able to reset the password with that. And if at all, if the device has lost completely, he can wipe the data completely. So that was the main idea. So you can see, now you can see the third party server was running, the Stomcat server. So what I'm just refreshing, refreshing this thing. You can see the data of the server. And you can see the other stuff, things that are client, I mean the employees applications was installed in the side of the screen. So whenever, if two or more employees or a random number of employees are going to include in that, they're going to have a refresh site on there. You can see these refresh sites. They keep track of the list of the users in there. So what I mean to do is, so you can see here the request ID. So intentionally I just keep this request ID to know you guys. Usually you can put an hash map, you can map with some device, one device with the names and we can do it. But initially I can show this request ID, what we are getting from, registration from the ECM server, what we are getting back to the device side. So this registration ID, what I'm doing is, I'm just logging back to remote device. I'm going to go for a demo. You can see the request to your blog. And you can see the password, I said some password like random one to three. So what we tried is actually, what we couldn't achieve in this hack night is like, we tried something new, instead of having this HTTPS thing, what old thing was provided, we tried something like CCS, Cloud Connection Service. So what basically is like, now the thing is like, what I'm doing is, I'm connecting the two things. One is the CCM layer, what it was providing from the Google page service, and the normal HTTPS protocol, what it was going to make, to make these things happen. So with the CCS, what we can do is, we can use the same layer, what is provided by the Google page service. You can put a minimum kind of data on upstream. Because if we keep the same way, how it was provided, pushing the data to the number of devices. You can put all the data in the queue, again, it's going to be in the same way. You can put all the data in the queue, and whenever that particular server, you can be able to make the connection and push with the party server. That way we can do it. So the main thing we can make use of this, like the tic-tac thing, what the interaction would be like, it's kind of a WhatsApp kind of app, and you can be able to do it easily. If you're going to integrate in this, and one of the things like last function, what I'm going to do is I'm going to wipe the data. So the data is going to be totally wiped. And the camera functionality is again, so it was just an hard-ported thing, what do I give it here, to be open, because the CCS function, what we were about to plan was not working perfectly for us. So once that happens, we can easily upstream or laden long. Whenever user moves from here and there, we can easily make use of it. Of course you can use a location manager or it will be a battery consuming. So instead of that, we plan in that way. So a few questions. First thing is, how different is this from the Google device administration? Google admin administrators, like we need to be with it manually. So instead of remotely accessing something, we need to be with something as a manually, and you need to set some time for something to be run inside. In IT, admin kind of things, you can have a good user interface, what the employees are doing. Of course we haven't added the most functionality, what we can able to do with this. You can able to set the password, set the office, and of course Android is providing many, its minimal kind of admin, what we can able to do with it. So what you said is we can able to think of, it's kind of a library kind of a thing, you know. I was just wondering, given what you guys have built, do you think it would make sense even to restrict the apps being installed on the device? The restrictions are basically what you are doing now is just using or controlling the settings of the phone. But from a device, for example, 90% people want to restrict the apps what the particular user is going to install or what he can open. Yes, you can able to do it. It's kind of R and D kind of thing, I can able to propose certain things like whenever users go for certain things, the launcher will be triggered and the application what's running in the background, we can able to get it. Basically the application name, something we can able to get it. So with that we can able to, what to say, we can able to have a callback from the client application we need to lock it, that's what we can able to do. Other than that, I don't think we can able to go and uninstall the applications remotely it's not possible, unless you route the device. So one of the things, myself and my friend got a router devices so when you install this admin app so it was the thing in the background we can able to uninstall, it's normally going from the application manager. So we need to go to the thing like route the device uninstall that thing so that is the thing So that will basically mean you also need to write a launcher because yes okay