Ok, sorry ESET, but this feature looks very interesting, so I looked at the decompiled sources :)
The main workflow is as follows:
com.eset.ems.antitheft.receiver.AdminReceiver DeviceAdminReceiver registered for translational actions
DEVICE_ADMIN_ENABLED and
DEVICE_ADMIN_DISABLED When the device administrator is disconnected
com.eset.ems.antitheft.receiver.AdminReceiver.onDisabled() is called
com.eset.ems.antitheft.LockActivity AdminReceiver.onDisabled() LockActivity shows
com.eset.ems.antitheft.LockingDialog where the most blocking magic happens
As for the Home antivirus and other buttons, do the following trick: it uses an ActivityManagerNative from Android internal systems. To keep LockActivity at the top of all other actions, it starts a thread, which usually calls ActivityManagerNative.moveTaskToFront() with the LockActivity task LockActivity . Prior to reflection, the API level 10 is used to access the hidden moveTaskToFront() from the ActivityManager , and after API 10 it simply uses the ActivityManagerNative code from the Android code to access it. Also, both the LockActivity and LockingDialog call the ActivityManagerNative.closeSystemDialogs() method many times. This is probably done in order to cancel the system dialog that occurs after a long press of the power button.
Regarding the termination of DeviceAdminReceiver.onDisableRequested , in fact, I did not notice anything special in this code. It starts activity only after the device administrator is disconnected and thatβs it. And on my phone, the admin device turned off after I took out the battery.
source share