[Feature Request] start lock task mode (Dhizuku) using overlay and/or foreground service

[nktnet1]

Following up from #203,

 

Would it be possible to still implement this using screen overlay?

This will require the permission:

<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/>

Some helpful resources:

• Manage Overlay Permission (ACTION_MANAGE_OVERLAY_PERMISSION)
• SYSTEM_ALERT_WINDOW Permission
• Check Overlay Permission (Settings.canDrawOverlays)
• Android 11 Overlay Permission Changes
• Request Overlay Permission (Gist)

---

Also, regarding returning to OwnDroid via notifications, perhaps a Foreground service can be used to always keep the notification there:

• https://developer.android.com/develop/background-work/services/fgs

Allowing the user to return to OwnDroid when the foreground service notification is clicked on (or closed).

Note that on Android 14, even when using .setOngoing(true) for persistence, the notification can still be dismissed (with some exceptions, e.g. device owner):

• https://developer.android.com/about/versions/14/behavior-changes-all#non-dismissable-notifications

  

There is a potential workaround listed here to keep the notification persistent:

• https://stackoverflow.com/a/77080872/22324694

[BinTianqi]

It's not the notification issue. Only device owner can start an app in lock task mode. In Dhizuku mode, OwnDroid isn't the device owner.

[nktnet1]

@BinTianqi are you certain? From my testing, the only requirement seems to be that the application is in the allowlist for Lock Task Packages.

For example, I'm able to launch OwnDroid in Lock Task Mode just fine from my own app, which only has Dhizuku privileges (and not device owner), using

val options = ActivityOptions.makeBasic().setLockTaskEnabled(true)
context.startActivity(intent, options.toBundle())

Video demo:

owndroid-lock-task-mode.webm

also uploaded it here in case you can't play it - expires in 2 days

• https://streamable.com/g2b6dt

P.s. From the video, during the first launch of OwnDroid from my app, it didn't trigger lock task mode because OwnDroid was already running and I didn't have the "NEW TASK" flag.

Closing OwnDroid to start fresh and launching the second time puts it in lock task mode (as shown by the hidden status bar, and the home launcher app being unavailable).

[BinTianqi]

You are right. I tried to start an app in lock task mode when OwnDroid was in Dhizuku mode, the system status bar appeared, so I thought it's not in lock task mode, actually, it's because I had enabled the "allow system info" feature.

But there's still a problem: OwnDroid can't track the locked app's lifecycle. It means that OwnDroid can't cancel the notification(or overlay) itself when the user exit lock task mode in other ways.

[nktnet1]

I think you may be able to track this with polling?

This is the trick I use since my app needed to work with Screen Pinning (same API as lock task mode, but for regular phones without Device Owner).

For example, a function like:

fun getIsLocked(activityManager: ActivityManager): Boolean {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
        // This catches both [ActivityManager.LOCK_TASK_MODE_PINNED, ActivityManager.LOCK_TASK_MODE_LOCKED]
        return activityManager.lockTaskModeState != ActivityManager.LOCK_TASK_MODE_NONE
    } else {
        @Suppress("DEPRECATION")
        return activityManager.isInLockTaskMode
    }
}

This function can then be called every second in a foreground service, for example.

[BinTianqi]

Try CI version

[MrRare2]

Also trying to start Lock Task without the "Allow notification" or the app not being in the list of lock task packages, would likely lock the user out of lock task mode and can't exit, and when trying to start Lock task with the starter package being itself (OwnDroid starting OwnDroid in lock task mode), would not actually start Lock task, causing to the situation above what I said where the notification disappears after a second

[MrRare2]

@MrRare2 I assume it's working the first time, then after that if you launch the same app, it won't enter lock task mode (because the task already exists). After 3 seconds, the notification should be cleared (OwnDroid sets an initial delay of 3 seconds, then 1-second polling afterwards).

I think this will be fixed after merging #214 - i.e. point 3 from my comment above.

I'm going to try #214 in my OwnDroid fork if it works

[nktnet1]

Yeah, I think the crucial things to check are:

1. OwnDroid is in the list of Locked Task Permitted
2. Lock Task Feature -> Home
   • this means you can always return to the launcher (even if there's a warning about it not working). From the launcher, you can open any apps that are lock task permitted
3. Lock Task Feature -> Notifications (which is dependent on "Home") - tap to unlock

Technically, the combination of either

• 1 and 2
• 3 (which implies 2)

will be sufficient to not end up trapped.

Another workaround would be to implement SYSTEM_ALERT_WINDOW (overlay).

[MrRare2]

I'm going to try #214 in my OwnDroid fork if it works

I tested it and it works consistently now
Now we only need to solve the trap case

How would the system overlay work? Sometimes in the settings it disappears for obvious reasons so technically there's still a way to trap yourself by only allowing the settings app.

I saw that TestDPC needs self adding itself to the lock task packages for it to even start Lock task mode , maybe doing the same with OwnDroid?

[nktnet1]

System overlay can work by, for example, adding a small and invisible rectangle at the bottom of the screen on top of other applications. When this rectangle is tapped multiple times, it unlocks the screen.

Sometimes in the settings it disappears for obvious reasons so technically there's still a way to trap yourself by only allowing the settings app.

There's no need to add the settings app - OwnDroid should be added to lock task packages. This is just so that you can open it from the launcher and remove the app that is holding lock task mode (or launch a new one).

The reason Test DPC adds itself is the same - it's so that you can open Test DPC when in lock task mode, which can then be used to remove the app/package holding the lock.