[Bug]: am reports ActivityManager.START_SUCCESS but activity is not launched

[twaik]

Problem description

As I said in description, am reports ActivityManager.START_SUCCESS but activity is not launched.

What steps will reproduce the bug?

1. Open Termux app.
2. sshd
3. Connect to sshd using PC.
4. Hide Termux's activity (go to home or another app).
5. am start --user 0 smth
6. Am reports no error but no activity is launched.

What is the expected behavior?

Android should start activity, report error starting activity or perform some actions to make starting activity possible.

System information

~ $ termux-info
Application version:
0.117
Packages CPU architecture:
aarch64
Subscribed repositories:
# sources.list
deb https://termux.librehat.com/apt/termux-main/ stable main
# game-repo (sources.list.d/game.list)
deb https://packages.termux.org/apt/termux-games games stable
# science-repo (sources.list.d/science.list)
deb https://packages.termux.org/apt/termux-science science stable
# x11-repo (sources.list.d/x11.list)
deb https://packages.termux.org/apt/termux-x11 x11 main
Updatable packages:
apt/stable 2.3.9 aarch64 [upgradable from: 2.3.8]
gpgv/stable 2.3.2-1 aarch64 [upgradable from: 2.3.1-1]
grep/stable 3.7-1 aarch64 [upgradable from: 3.6]
gzip/stable 1.11-3 aarch64 [upgradable from: 1.10-4]
harfbuzz/stable 2.9.1 aarch64 [upgradable from: 2.9.0-1]
openssl/stable 1.1.1l aarch64 [upgradable from: 1.1.1k-2]
termux-keyring/stable 2.0 all [upgradable from: 1.9]
Android version:
11
Kernel build information:
Linux localhost 4.19.87-20970822 termux/termux-packages#1 SMP PREEMPT Fri Aug 6 19:16:20 KST 2021 aarch64 Android
Device manufacturer:
samsung
Device model:
SM-G780F

[Grimler91]

Possible duplicate of, or at least related to, termux/termux-api#311

[twaik]

Looks like I found a solution for this bug here.
And now I am sure it is termux-app's bug, not termux-am's. After granting this permission I succeded to start my activity while another activity is running.

[agnostic-apollo]

It is not a bug of termux-app, its android 10 background restrictions as mentioned in the issue linked above. https://developer.android.com/guide/components/activities/background-starts

The Draw Over Apps or its internal name SYSTEM_ALTERT_WINDOW is required to start activities from background. You should check logcat for such exceptions. Considering, START_SUCCESS is being returned, that means android is not returning a failure despite missing permission, etc. The exceptions to the "rule" listed in the link above would likely be handled elsewhere, and failure logged to logcat, so such errors can't be solved by termux-app or termux-am if they aren't being notified of it. However, termux-app does have a check for missing permission and does not start TermuxActivity if permission is missing and notifies the user about it for foreground commands started by plugins or RUN_COMMAND intent. Such a check could probably be added to termux-am as well (will have to handle calling package), but its still not a bug in code, but android design.

[twaik]

I know it is Android design. But still think it is a bug because it is Android behaviour not handled by app. You can try to ask for this permission on termux-am package install (post-install) and in case it was installed from foreground you can ask it every time termux-am starts until a permission is received. Because we can not ask it while termux-app is in background.

[twaik]

And one more thing: I did not see any errors or warnings in logcat after failing to start an activity.

[agnostic-apollo]

You can try to ask for this permission on termux-am package install (post-install)

It comes as part of bootstrap and rarely ever updated.

you can ask it every time termux-am starts until a permission is received.

To check the permission, you need a Context object for the application/package, and Am doesn't have that and I don't think its even possible to get it in it. You would need a mechanism like termux-api in termux-app to check such stuff.

And one more thing: I did not see any errors or warnings in logcat after failing to start an activity.

How and where are you running the logcat command. Are you running as termux user or via adb/shell user. Such log entries would be part of OS logs and not part of termux app process so won't show in termux unless its granted READ_LOGS permission.

[twaik]

To check the permission, you need a Context object for the application/package

Is there a way to reflect PermissionManager's checkPermission?

How and where are you running the logcat command

I checked it via adb logcat.

[agnostic-apollo]

You could try, not sure if its gonna work. Running /system/bin/service call permissionmgr 11 s16 android.permission.SYSTEM_ALERT_WINDOW s16 com.termux i32 0 always returns -1/false too, as per this, even with adb. The permission would be affected by sharedUserId too.

[gety9]

Looks like I found a solution for this bug here. And now I am sure it is termux-app's bug, not termux-am's. After granting this permission I succeded to start my activity while another activity is running.

@twaik thank you for starting the issue! i was battling with similar problem and no hints of permission requirement were deceptive.

(was not able to open links in termux/vncserver when connecting from vnc viewer app)

[twaik]

Looks like I found a way to check if termux-app has SYSTEM_ALERT_WINDOW permission...

    boolean checkAppearOnTopPermission() {
        AppOpsManager appOpsManager = (AppOpsManager) ServiceManager.getService(Context.APP_OPS_SERVICE);
        int mode = appOpsManager.checkOpNoThrow("android:system_alert_window",
                android.os.Process.myUid(), "com.termux");
        return mode == AppOpsManager.MODE_ALLOWED;
    }

It worked on my device but it requires some changes in build.gradle (to access hidden API's)

apply plugin: 'dev.rikka.tools.refine'
...
dependencies {
    compileOnly 'dev.rikka.hidden:stub:2.3.1'
    implementation 'dev.rikka.hidden:compat:2.3.1'
    implementation 'dev.rikka.tools.refine:runtime:3.1.1'
    annotationProcessor 'dev.rikka.tools.refine:annotation-processor:3.1.1'
    compileOnly 'dev.rikka.tools.refine:annotation:3.1.1'
}

[twaik]

Ok, this solution works even without external dependencies.
But it needs some reflection.
https://github.com/termux/termux-x11/blob/c9ac9957ff95f453509913b8b472d8ff73fcb991/starter/src/main/java/com/termux/x11/starter/Compat.java#L46
It looks like this non-SDK API is stable.