[Feature]: Bypassing Phantom Killer Using a LADB-Like Solution

[IntinteDAO]

Feature description

This is a concept that isn't talked about much, but perhaps it should be.

In short, if you don't have root, tutorials suggest doing it manually using adb.

In short, it often works like this: you enable ADB network debugging, connect to your device using adb, and issue commands.

LADB is no different here, as it does the same thing, but automatically. It enables network debugging and executes commands (makes commands available to you). This solution isn't without its drawbacks, as you obviously need to be connected to Wi-Fi (as with ADB network debugging), but it would allow (if implemented in Termux) reconfiguration of Android and disabling unnecessary security features without user intervention (just pairing with ADB is enough).

Of course, restarting the phone doesn't affect LADB's operation. This means that if a similar functionality to Termux were implemented, even system updates might not break it. But if something were to happen, the user would be informed.

Additional information

LADB

[twaik]

Note. It requires WRITE_SECURE_PERMISSION permission so Google Play will not like it. https://github.com/tytydraco/LADB/blob/a3a33620d2815cd6499dc41024d815208f5f7fb6/app/src/main/java/com/draco/ladb/utils/ADB.kt#L112-L283

[robertkirkman]

Of course, restarting the phone doesn't affect LADB's operation.

I didn't know that it was possible to programmatically do that from inside of an app.

When I tested, it really does appear to be able to do it. That's very convenient, thank you for showing LADB.

This code appears to be key to being able to do that:

• android.permission.WRITE_SECURE_SETTINGS https://github.com/tytydraco/LADB/blob/a3a33620d2815cd6499dc41024d815208f5f7fb6/app/src/main/AndroidManifest.xml#L15

• Settings.Global.putInt(context.contentResolver, "adb_wifi_enabled", 1) https://github.com/tytydraco/LADB/blob/a3a33620d2815cd6499dc41024d815208f5f7fb6/app/src/main/java/com/draco/ladb/utils/ADB.kt#L341

However, other than that, it does appear that it still requires the initial Pairing with Wireless ADB to involve having the Developer Options Wireless ADB Pairing Code Popup on the screen at the same time as the ADB client app in a Slitscreen or Freeform Window view in order to be able to see and type the Wireless ADB Pairing Code into the ADB client app.

This means that, from a clean installation that isn't already Paired, for the purpose of turning off the Phantom Process Killer from inside the Termux App itself, it would be just a slightly more convenient, or slightly more scripted, equivalent to this:

https://www.youtube.com/watch?v=SjjALJ9fiBc

Since the clean install of LADB still requires the ADB Pairing Code Popup to be manually opened and the Pairing Code manually typed while looking at it, it seems like adding a scripted "Disable Phantom Process Killer" routine inside of the official Termux app itself would possibly be just a little more convenient than the current options, but it would not be possible for it to be 100% fully noninteractively automatic, so it would not be all that much more convenient in the big picture.

[robertkirkman]

Note. It requires WRITE_SECURE_PERMISSION permission so Google Play will not like it. https://github.com/tytydraco/LADB/blob/a3a33620d2815cd6499dc41024d815208f5f7fb6/app/src/main/java/com/draco/ladb/utils/ADB.kt#L112-L283

This is not the Google Play Termux repository so I don't think Google Play is relevant, but my perspective is that even with WRITE_SECURE_PERMISSION, that appears to only permit automatically turning on Wireless ADB, and not actually automatically Pairing Wireless ADB from a clean install of an app, so it seems like the added convenience would only be very slight in the big picture since a clean installed Termux still wouldn't be able to automatically, noninteractively disable the Phantom Process Killer by itself.

[Sfb1975]

Ggqsoxzc

في الاثنين، ١٧ نوفمبر ٢٠٢٥، ٩:٠٤ م Twaik Yont @.***> كتب:

twaik left a comment (termux/termux-app#4857) https://github.com/termux/termux-app/issues/4857#issuecomment-3543430132

Note. It requires WRITE_SECURE_PERMISSION permission so Google Play will not like it.

https://github.com/tytydraco/LADB/blob/a3a33620d2815cd6499dc41024d815208f5f7fb6/app/src/main/java/com/draco/ladb/utils/ADB.kt#L112-L283

— Reply to this email directly, view it on GitHub https://github.com/termux/termux-app/issues/4857#issuecomment-3543430132, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6EX7K7447AI7SPRLAU4TB335IL5DAVCNFSM6AAAAACMLX2F6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBTGQZTAMJTGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[IntinteDAO]

@robertkirkman

I completely agree – it's simply a bypass that automates the problem. You do one configuration and it automatically works (assuming you have Wi-Fi – I don't know if tethering works, it doesn't for me).

Is there another option? You could create an Android emulator, they already exist, and run Termux in it xD

[robertkirkman]

Is there another option? You could create an Android emulator, they already exist, and run Termux in it xD

I am not sure what is meant by this. What does this idea have to do with Android emulators?

[agnostic-apollo]

It is planned to add adb and root shell support in Termux app for running commands like with APIs, once that is done, it can also be used to grant termux app permissions and disable phantom process killer. A notification based pairing method like shizuku uses could then be added as well.

[IntinteDAO]

Is there another option? You could create an Android emulator, they already exist, and run Termux in it xD

I am not sure what is meant by this. What does this idea have to do with Android emulators?

It's just a hypothetical idea I've been thinking about. Phantom Killer works in different ways. You can't spawn more than 32 processes or kill an application if it uses too much RAM. I was wondering what could be done to limit the number of processes and RAM.

In theory, QEMU or a similar solution. They are not efficient (at least without KVM), but I think it is possible to make assumptions about the virtual machine so that it never falls under the Phantom Killer rules.

I know there are solutions like Visual Master (closed source code) that run Android on Android, but with very high performance (e.g., for old games that don't run on Android 15). This way, you could theoretically run Android on Android, which would run Termux in such a way that Phantom Killer would never get it xD

I doubt anyone would implement this, of course.

[robertkirkman]

For general purposes QEMU is very slow. I regularly use it, but for tasks where I am OK with it being very slow.

For possibly working around Phantom Process Killer, the software that comes from pkg install cpulimit might be more practical than QEMU. I have, in the past, used that software to great effect and utility on Desktop Linux for niche purposes unrelated to Android. However, I have not used it on Termux very much and I don't know what would happen if you try it. It might help with Phantom Process Killer, but it might not help at all with it.

[IntinteDAO]

For general purposes QEMU is very slow. I regularly use it, but for tasks where I am OK with it being very slow.

For possibly working around Phantom Process Killer, the software that comes from pkg install cpulimit might be more practical than QEMU. I have, in the past, used that software to great effect and utility on Desktop Linux for niche purposes unrelated to Android. However, I have not used it on Termux very much and I don't know what would happen if you try it. It might help with Phantom Process Killer, but it might not help at all with it.

Yep, but Visual Master don't use virtualization I think, but they have (I think) something like LXC without kernel modules. But still it's not usable in our problem