How to wipe Android device when device admin is deactivated?
Asked Answered
M

2

12

In my application, which is a device admin, I need to wipe the entire device when the user tries to deactivate the admin function of the application. When the user goes to Settings / Security / Device admins and deactivates the admin app, first a dialog is presented "Do you want to deactivate". If the user says "yes", then another small dialog is presented, with the text provided by the application's AdminReceiver in onDisableRequested(). If the user then says "yes", I want to wipe the entire device. How to accomplish this?

I tried everything, searched long for answers, found no real solutions.

What I tried:

  • AdminReceiver has a function onDisable(). I tried to wipe the device in that function. However, it appears that onDisable() is called after the admin has been disabled. Thus the app cannot use the wipeData() function at all (a security exception is thrown). I have also verified that isAdminActive() returns false at that time.

Official documentation does not say this clearly, but it seems that the admin is already disabled when onDisable() is called. Thus we have to wipe the device before that time.

  • AdminReceiver has a function onDisableRequested(), which returns CharSequence. I tried to put another alert box in that function. This crashes because an alert box cannot be called from a non-activity context, which seems to be what we have when we are in onDisableRequested().

  • AdminReceiver has a function onReceive(), which gets called on any events. In this function, again, we are not in an activity context and cannot present our own dialogs.

  • I tried creating another activity from onReceive(). This works; during onReceive() when we get ACTION_DISABLE_ADMIN_REQUESTED, the admin is still active and we can wipe the device. However, the system still presents its own dialog asking the user whether to deactivate the admin. If the user says no to our dialog but yes to the system dialog, the admin will be deactivated and we will have failed to wipe the device.

I tried the following, in my subclass of DeviceAdminReceiver:

@Override
public void onReceive(Context context, Intent intent) {
 // detect whether disabling is requested?
 if (intent.getAction().equals(ACTION_DEVICE_ADMIN_DISABLE_REQUESTED)) {
            confirmWipeDevice(context);

 } else {
    super.onReceive(context, intent);
 }      
}

In other words, I do not call super.onReceive() if the action is to disable the admin. The function confirmWipeDevice() shows a different activity with a dialog. This does not show the system dialog for confirming the disabling of my admin app. However, this does not prevent the app from being actually disabled!

It seems that the Android system does the following:

  • Send ACTION_DEVICE_ADMIN_DISABLE_REQUESTED to the AdminReceiver

  • Proceed with disabling the admin regardless of what the admin app wants to do

  • If the user cancels the disabling, fine; if not, the app is disabled. There is no way for the app to refuse being disabled, or to perform the device wipe upon disabling.

The only solution so far is to wipe immediately without confirmation when the user wants to disable the admin app. In other words, I can call getManager().wipeData() immediately in onDisableRequested(). At that time, the admin is still active and this works.

Is this correct? How to wipe the device when the user chooses to disable the admin app?

Medulla answered 15/2, 2012 at 17:39 Comment(4)
I'm finding that trying to do a wipeData() call in onDisableRequested() or onDisable() puts things in a shaky state, and the data wipe fails if the screen turns off. Have you had any further luck with this?Sampson
Can the data wipe ever succeed if the screen turns off? We did not test this. (We changed the device to Android 3.2 where we can do things in onDisabled.)Medulla
I was able to get it to work if I started an AsyncTask from onDisableRequested(). I think that whatever thread is executing when onDisableRequested() is called, a wipeData() call can't reliably be made here. When I fired it from an AsyncTask, I see the PowerOff dialog come up almost immediately.Sampson
onDisableRequested is Called when the user has asked to disable the administrator, as a result of receiving ACTION_DEVICE_ADMIN_DISABLE_REQUESTED, giving you a chance to present a warning message to them.---I think the message returned by onDisableRequested is the last chance to WARN user, if user press "yes" to confirm to diable device admin, then wipe the device.Lowther
M
4

In Android 3.2 they have fixed this problem. In Android 3.1 the problem was still present.

Now (Android 3.2) in onDisabled you still have admin privileges and so you can wipe the device.

Medulla answered 20/6, 2012 at 10:8 Comment(1)
This sounds like a solution. You should just accept your own answer as a solution. And this will help others too, because then your question will be presented to others as one that was solved and thus is more interesting for those looking for a solution in a similar matter.Thaumatology
K
5

My recommendation: Don't do that unless it's like a corporate-type thing.

But. In onDisableRequested(), you could startActivity for the home screen, and then startActivity for an Activity you created that confirms whether they want to continue or not. If they choose yes, then you do as you desire (wipe the device), if they say no, then just startActivity for the home screen again (or finish()).

This does still run the risk that they can launch the same settings page from the recent tasks, under which circumstance they will likely be able to press "yes" (or ok) on the dialog that popped up with your custom text and then continue with disabling device admin. To try and avoid that from happening, you could do this in the hopes it will start the initial settings page and clear the top-most disable device admin screen.

Instead of wiping, you could always do resetPassword("new password") and then lockNow(). If it's a security-related app, then the person's device doesn't have to be wiped, and the password would have been pre-defined by the person who installed the app.

Let me know if you have any other questions. I hope this helps.

EDIT: I got an upvote that reminded me this answer exists, so I figured I'd add some info.

You could use lockNow() in conjunction with an Activity that will show on top of the lock screen if you want to lock then still offer the wipe or whatever else.
And locking before starting the wipe would be a good idea to prevent problems if the wipe has an error or delay for any reason.

And if doing anything like this on a distributed app (via app stores), take care not to violate their polices because a policy violation CAN cause a permanent ban from the app store (it happened to me on Google Play, due to nothing more than a misunderstanding.)

Kuehl answered 15/2, 2012 at 21:57 Comment(3)
- it is a "corporate-like thing" :) The app is required required to wipe the device. - I already tried starting a new activity; but the user can always press "back" and get rid of it, and then disable admin without doing anything. - if I want to reset password and lock, I need to be an active admin, so again I cannot do this after presenting the confirmation dialog.Medulla
- I will try to see what happens if I force-start the initial settings page.Medulla
When I suggested using locknow, I meant before showing the dialog as a partial solution in case you didn't just want to wipe without confirmation - you'd lock instead, then maybe supervisors or whatever would have the passwors. If you can find a way to clear recent apps (long press home), then you could start the home activity and you'd be set, but I don't believe there is any legitimate way to clear the recent apps.Kuehl
M
4

In Android 3.2 they have fixed this problem. In Android 3.1 the problem was still present.

Now (Android 3.2) in onDisabled you still have admin privileges and so you can wipe the device.

Medulla answered 20/6, 2012 at 10:8 Comment(1)
This sounds like a solution. You should just accept your own answer as a solution. And this will help others too, because then your question will be presented to others as one that was solved and thus is more interesting for those looking for a solution in a similar matter.Thaumatology

© 2022 - 2024 — McMap. All rights reserved.