Hi All, Given below are the tasks which are in progress on the Android device management layer. I'm listing this down according to the priority with the challenges we faced so far.
1. Policy Monitoring - Plugin level implementation. - We need to generalize all the platforms in this scenario specially when it comes to the three Monitoring types (Acknowledge, Enforce, Warning). In iOS, Enforce mode should send the policy payload back to the device. But in Android it's not required since we are storing the policy in the Agent app. We overcame this issue by re-sending policy payload (Policy Bundle command) to the device. Android Agent will just ignore the policy if it matches with the existing policy. 2. Policy Monitoring - Agent level implementation. - Completed Implementation. 3. Policy Revoke - Android Agent - We have implemented a revoking mechanism for policies to be used in situations like dis-enrollment, device administration force disabling and apply new policies. In such situations android agent is now revoking the existing policy by retrieving the current policy and revoking one by one (Ex: If the policy disabled the camera, revoke function will enable the camera) 3. BYOD + COPE Separation. - Completed and made UI and flow changes to the Android agent accordingly. In COPE mode, in the enrollment, license agreement + PIN setting will not pop up and user will not be able to dis-enroll the device unless the EMM Admin sends a dis-enroll command. In BYOD mode, licence will be shown before enrollment, critical operation PIN have to be given as well. User can dis-enroll the device at anytime in this mode(in dis-enrollment Android agent will auto clear the app data such as access tokens etc + agent will initiate an enterprise wipe). 4. Tenant configuration + Settings (This is common to all platforms) - This is to set settings such as monitoring frequency, email settings etc. - MDM jaggery app level implementation + Service layer. - Completed the jaggery UIs and the back end services are in the process of development. We have decided to have the tenant configurations persisted in the registry. And retrieve it from their whenever required. (Ex: Android enrollment - Notification mode [GCM/LOCAL], GCM sender ID, Notifier frequency etc have to be retrieved from configurations) 5. Containerization feature integration - Lollipop API support in Android Agent level. - We are currently in the process of going through the documentation by Google on which features we can integrate and how we can get them in place to provide a proper container solution for Android. 6. Gradle build - Upgrading the current build script to generate signed APK taking the keys from a configurable location. - Currently we have completed the maven script to invoke gradle build script and build the APK (unsigned release APK) and copy it to MDM jaggery app downloads location. But there is an intermittent issue we are yet to figure out which happens when the build is trying to download Gradle wrapper dependency. This dependency is 50+ MB (1st a JAR and then JAR invokes a download of 40+ MB file) and in case if it failed in between, the build fails. So we need to figure out whether to have these dependency in the pack itself and bring the JAR to orbit. We need an input on this. Please go through and reply in the same thread with your concerns. Thanks -- 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>*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
