You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I got stucked with weird bug/problem with the Termux:API app's NotificationAPI. The command that is executed from the notifications action/buttons/on-delete methods is getting replaced with a command that has been previously used for other notification's actions.
I can probably assume the problem is somewhere around Termux:TermuxService
You can see action: termux-dialog in Bundle is getting replaced with termux-toast -g top NotWorking at Arg 2.
The new [malicious] command (here it is toast -g top NotWorking), that replaces the original one, will be updating sooner or later after sometime (hours or days).
termux-dialog will become the next malicious command after some time.
It's working like First In First Out, buffering commands and replacing future commands.
termux-dialog will become the next malicious command for any new notifications created later and the same repeats.
Steps to reproduce
I still can't understand where the problem came from.
What I did is:
git cloned the termux-api repo
Open it in Android Studio
Build the app and deploy on device
Here comes the magic 🪄:
Step 1: termux-notification --action x -t T -c C
Android Notification gets created, execute it(tap action). "x" will be executed.
Step 2: termux-notification --on-delete y -t T2 -c C2
Another Android Notification gets created, but when tried to delete this notification(execute command "y"), "x" will be executed!!!
Problem description
Hello there,
I got stucked with weird bug/problem with the Termux:API app's NotificationAPI. The command that is executed from the notifications action/buttons/on-delete methods is getting replaced with a command that has been previously used for other notification's actions.
Here is the logcat:
And the command that created the log:
I can probably assume the problem is somewhere around
Termux:TermuxService
You can see action:
termux-dialog
in Bundle is getting replaced withtermux-toast -g top NotWorking
at Arg 2.The new [malicious] command (here it is
toast -g top NotWorking
), that replaces the original one, will be updating sooner or later after sometime (hours or days).termux-dialog
will become the next malicious command after some time.It's working like First In First Out, buffering commands and replacing future commands.
termux-dialog
will become the next malicious command for any new notifications created later and the same repeats.Steps to reproduce
I still can't understand where the problem came from.
git cloned the termux-api repo
Here comes the magic 🪄:
Step 1:
termux-notification --action x -t T -c C
Step 2:
termux-notification --on-delete y -t T2 -c C2
Expected behavior
I expect it to work without flaws. 🙂
Additional information
Termux:API App Info (Current)
APP_NAME:
Termux:API
PACKAGE_NAME:
com.termux.api
VERSION_NAME:
0.50.1
VERSION_CODE:
51
UID:
10225
TARGET_SDK:
28
IS_DEBUGGABLE_BUILD:
true
SE_PROCESS_CONTEXT:
u:r:untrusted_app_27:s0:c225,c256,c512,c768
SE_FILE_CONTEXT:
u:object_r:app_data_file:s0:c225,c256,c512,c768
SE_INFO:
default:targetSdkVersion=28:complete
APK_RELEASE:
Github
SIGNING_CERTIFICATE_SHA256_DIGEST:
B6DA01480EEFD5FBF2CD3771B8D1021EC791304BDD6C4BF41D3FAABAD48EE5E1
Termux App Info
APP_NAME:
Termux
PACKAGE_NAME:
com.termux
VERSION_NAME:
0.118.0
VERSION_CODE:
118
UID:
10225
TARGET_SDK:
28
IS_DEBUGGABLE_BUILD:
true
SE_PROCESS_CONTEXT:
u:r:untrusted_app_27:s0:c225,c256,c512,c768
SE_FILE_CONTEXT:
u:object_r:app_data_file:s0:c225,c256,c512,c768
SE_INFO:
default:targetSdkVersion=28:complete
TERMUX_APP_PACKAGE_MANAGER: -
TERMUX_APP_PACKAGE_VARIANT: -
APK_RELEASE:
Github
SIGNING_CERTIFICATE_SHA256_DIGEST:
B6DA01480EEFD5FBF2CD3771B8D1021EC791304BDD6C4BF41D3FAABAD48EE5E1
Device Info
Software
OS_VERSION:
4.19.127-ge275d78fd-dirty
SDK_INT:
30
RELEASE:
11
ID:
RP1A.200720.012
DISPLAY:
RP1A.200720.012 release-keys
INCREMENTAL:
eng.compil.20230306.183730
SECURITY_PATCH:
2022-05-01
IS_DEBUGGABLE:
0
IS_TREBLE_ENABLED:
true
TYPE:
user
TAGS:
release-keys
Hardware
MANUFACTURER:
vivo
BRAND:
vivo
MODEL:
vivo 1901
SUPPORTED_ABIS:
arm64-v8a, armeabi-v7a, armeabi
The text was updated successfully, but these errors were encountered: