Hi Inosh, No one can disable/remove a system app unless the user has root access to the device or the system app is disabled by another device administrator app.
Also +1 for the concern of tracking the system app status in the server side. Main concern for coming up with this system app was targeting the customers who has firmware access or who can get vendor signing done. But totally +1 to make it more flexible as you suggested. And I should also mention, the agent app is anyways executing the system operations only if the system app is available. So that is anyways handled that way. Thanks On Tue, Jan 26, 2016 at 11:33 AM, Inosh Perera <[email protected]> wrote: > Hi Kasun, > > This system service runs as a separate service where our android agent > application can invoke this service to get above operations executed. > I think another usage of this would be in case, we managed to get some > vendor signing our-selves, these service apps can be hosted in a public > location such as Google playstore which can be used in a cloud based > scenario. I think the same approach is followed by other EMM solutions in > could deployments. > > Is there any possibility of disabling the service app? usually system > services are grayed out in apps, so probably not, isn't it? > Also, I suggest we have a way to inform EMM server at the device > enrollment, telling that the device has the service app installed or not. > Only if it is installed, the server should be able to send operations that > requires root access. Also if the service app is not installed and there > must be a way to add an app policy to the device asking to install the > service app. This also depends on company requirement, therefore we must > have a setting at the server side to set if the service app is required or > not. > > Regards, > Inosh > > On Tue, Jan 26, 2016 at 10:58 AM, Kasun Dananjaya Delgolla < > [email protected]> wrote: > >> Hi All, >> >> We have come up with the following architecture for the $subject after >> going through the possibilities. This is basically for COPE (Corporate >> Owned Personally Enabled) devices. This system service will basically >> require root (system level) access from android system. Therefore this can >> be used when the device has corporate owned (customized) firmware or when >> there's a possibility of vendor signing [1] the system service app. In >> these scenarios above mentioned system service application will run as a >> system app in the device. >> >> The reason for us to come up with this approach is to enable enterprises >> to have full control over the devices (COPE) by enabling system level >> features such as silently install/uninstall apps, execute shell commands as >> super user, reboot device, retrieve system logs, OTA (Over The Air) update >> device firmware control advanced system settings etc. >> >> This system service runs as a separate service where our android agent >> application can invoke this service to get above operations executed. >> Reason for us to separate this service from our agent app is to have the >> flexibility of using a single agent app for both COPE and other >> (BYOD/Mixed) scenarios. So the agent app will externally invoke this >> service in cases of COPE operations mentioned above. Basic communication >> flow is as follows, >> >> >> >> *Security level* >> >> To make the system service secured, we made the system serviced access >> level to "signature"[2]. This means only the apps signed with the same key >> as the key used to sign the system service ONLY can access the system >> service application. Therefore the EMM Agent app and the system service >> need to be signed with the same signing key when deploying. Also the system >> service will not be visible in the foreground in any scenario since it's a >> standalone service runs in the system. >> >> Two apps will communicate by using the Messanger/Handler mechanism[3]. >> [4] for further explanations on the communication protocol. >> >> Please go through the above and reply to the same thread if you have any >> concerns. >> >> >> [1] - https://source.android.com/devices/tech/ota/sign_builds.html >> [2] - >> http://developer.android.com/training/articles/security-tips.html#IPC >> [3] - http://developer.android.com/guide/components/bound-services.html >> [4] - >> http://www.truiton.com/2015/01/android-bind-service-using-messenger/ >> >> Thank you >> >> -- >> Kasun Dananjaya Delgolla >> >> Software Engineer >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> Tel: +94 11 214 5345 >> Fax: +94 11 2145300 >> Mob: + 94 771 771 015 >> Blog: http://kddcodingparadise.blogspot.com >> Linkedin: *http://lk.linkedin.com/in/kasundananjaya >> <http://lk.linkedin.com/in/kasundananjaya>* >> > > > > -- > Inosh Perera > Software Engineer, WSO2 Inc. > Tel: 077813 7285, 0785293686 > -- Kasun Dananjaya Delgolla Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware Tel: +94 11 214 5345 Fax: +94 11 2145300 Mob: + 94 771 771 015 Blog: http://kddcodingparadise.blogspot.com Linkedin: *http://lk.linkedin.com/in/kasundananjaya <http://lk.linkedin.com/in/kasundananjaya>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
