Android activity.stopLockTask() causing SecurityException

I am calling stopLockTask on an Activity, but after a few times of turning lock task mode on and off, the call will eventually cause a Security Exception:

SecurityException: Invalid uid, expected 0.

I am not sure why this is happening. The activity is the same one that called startLockTask, is not null when called, but it still throws the error.

Code is pretty simple, so not sure there is much as for snippets that will help. The Fragment is calling getActivity().startLockTask(), getActivity.stopLockTask()

Am I missing something obvious here?

Solution

This needs to be setup with DPC first. Lock task mode explains this step by step; as it seems, there are only certain devices supported. The error message SecurityException: Invalid uid, expected 0 generally means, that you're not running this as device owner or admin, which results in "nope". Since the recent GSuite to Workplace migration, there's also two levels of end-device management plans available - which may eventually limit or enable end-device management possibilities (I don't know). It's more difficult than setting up a single PC for kiosk mode - because not having ROOT_UID 0 generally translates to: "not owning the device" (contrary to what the sales person may have told you). That's why the SecurityException is being thrown ...unless taking device ownership first.

This AndroidManifest.xml shows the environment you'd need for lock-task mode.
But the current status of this is unsure, as no more custom DPC will be accepted.
So this may not be wrongful, but stale to outdated information; see part two.

2021 Update.
Just seen that meanwhile the Android Management API is being suggested,
were a device policy alike this might be similar to what you're trying to do ...

It's not the app in lock-task mode, but the app being installed in KIOSK mode:

"applications": [
  {
    "packageName": "com.example.app",
    "installType": "KIOSK",
    "defaultPermissionPolicy": "GRANT"
  }
]

There's also a google-api-services-androidmanagement library,
which both may generally be the more future-proof alternative.