AppManager
AppManager copied to clipboard
MuntashirAkon
ADB working mode gets lost
Please check before submitting an issue
- [x] I know what my device, OS and App Manager versions are
- [x] I know how to take logs
- [x] I know how to reproduce the issue which may not be specific to my device
Describe the bug
My phone doesn't have root, so I used the ADB mode to let it work. Just ahead, I don't blame any developer - they did and do a great job here. The issue is likly systematic and can't be avoided or doesn't depend on the app itself. Bit behavior does cause me some headache, mostly because I didn't understand it all.
After a while (so by time), by change of WiFi network or any other event the Init fails. That means starting of app takes long, showing an "Init ...." and finally reports the "requested mode can't be used". Than I need to do a longer sequence:
- Settings/DeveloperSettings/Enable Debugging via Wifi (again)
- Long press on AppManager icon, App-info/Force stop/Open
I wasn't aware that "Debugging via Wifi" is responsible, as it sometimes work after that has been already disabled (by system?). I understand it like that, that is might be some caching/background issue.
Does anybody found a shortcut to enable Debugging via Wifi or get AppManager back in ADB mode running? Could AppManager maybe gets some info that "Debug via Wifi" is enabled again and switches its mode back atomically?
Thanks for this great tool, I like it to create the Icons to freeze apps automatically when Screen is off. The only thing that confuses me is that "Select all" is preselected, but I need to enably all 3 buttons below too?!? But that a different thing - sorry to mentioned that here.
To Reproduce
No response
Expected behavior
No response
Screenshots
No response
Logs
No response
Device info
- Device:
- OS Version:
- App Manager Version:
- Mode: Root/ADB/NonRoot
Additional context
No response
Could AppManager maybe gets some info that "Debug via Wifi" is enabled again and switches its mode back atomically?
App Manager attempts to do this automatically if it has enough permission to do so. But certain devices may have additional restrictions (you haven't included your device info).
The only thing that confuses me is that "Select all" is preselected, but I need to enably all 3 buttons below too?!?
That's a bug. It shouldn't have been selected.
Sorry I am running a Samsung S23 (Android 14).
In case it shows "Initialisierung" and it fails, this doesn't stop by itself. You can not press any other button/as settings. Just swipe it away (from bottom to top). But even after enable WifiDebug it will not (always) work again. (USB debugging is always on here). Right now even disable USB debug and WifiDebug, enabling, Stop AppManager and start it not always works, you need to wait some time before restart AppManager.
Sometimes it is rather easy, sometimes difficult. And - what can I do if I am away from home without WiFi? I mean, I am really happy to have this mode, as I don't have root. But sometimes it is hard to manage.
Having the same problem time to time. Using Samsung A55. If you need any more information, i'm willing to help.
I also get this same issue, and have for a while now. Like others mentioned above, it requires having to jump through a few of hoops to reestablish AM having "ADB mode" access again.
What about the possibility of AppManager utilizing Shizuku for ADB access? A number of other apps do this.
Not only is Shizuku's sole purpose to handle this, Shizuku will never lose ADB access given its nature as an always running service/daemon (and ability to auto-start on boot). It's also open source and has a convenient API for apps to utilize. (I have no ties to Shizuku)
This would work around the issue of situations where AppManager is force-closed, intentionally or unintentionally, the user having to then re-pair/resync ADB access. And particularly in situations where wireless debugging is switched off and a nearby wifi network isn't available, when users are mobile or on-the-go.
AM utilizing ADB via Shizuku API would render these situations non-issue, since Shizuku is always available and never gets force-closed.
Note20 Ultra Android 13 AppManager v4.02 (442)
ADB Mode is running (as far as I know) via debug via Wifi. But what when I am not at home and don't have wifi?
@Coldblackice See #55. Not planned.
Would this discussion updated yesterday potentially signal an openness to this going forward? https://github.com/MuntashirAkon/AppManager/issues/55#issuecomment-2916720252
@Coldblackice @starbrights @MuntashirAkon to the best of my understanding this is almost exclusively a Samsung issue related to them hardening up their oneui some odd years ago.
take a look at https://github.com/MuntashirAkon/AppManager/issues/1355 because this is a duplicate of that Imo and that shouldn't have been closed, or at least, my pitch in the comments was never fixed. described exactly what you have described here, there, from a non coder POV.
I have confirmed this affects: A13 5G S25 Ultra 12gb 512gb
doesn't matter if you disable phantom process monitoring (it's one of the few things Samsung lets you do at least on s25u). you eventually get into a state where basically unless you reboot the device, you can only get adb out of like, shizuku, but never a-m.
and it doesn't matter if you have multiple a-m installed. when it stops working they all stop working until you reboot.
I haven't yet tried device manager or device owner software like owndroid, dhizuku, island, shelter, ice box, etc. but if someone ever does, someone who also has experienced this issue, like someone with a Samsung that's ~android 13-15, let me know if that works.
Thanks for your observations. Indeed - I am using AM on an another device (Samsung S5e but with LineageOS) without any problems. Although I could always get ADB mode running there are some steps, and I didn't find a reliable shortcut. Sometimes it works without some of the steps inbetween, sometimes not.
- Force AM stop
- disable ADB over Wifi
- disable ADB USB (?)
- wait some time and/or Screen off / on
- enable ADB over Wifi
- wait some time and/or Screen off / on
- Start AM
My hope is that maybe a switch to Shizuku or other alternatives might help. I mean it is great to have this ADB mode to enable things beyond normal user operations. But there is one even bigger problem: While the strategy above is just time consuming, what if you are not in a WiFi net (out of home)? It won't work at all!
Although I could always get ADB mode running there are some steps, and I didn't find a reliable shortcut. Sometimes it works without some of the steps inbetween, sometimes not.
- Force AM stop
- disable ADB over Wifi
- disable ADB USB (?)
- wait some time and/or Screen off / on
- enable ADB over Wifi
- wait some time and/or Screen off / on
- Start AM
Thanks for sharing this. These steps (and also the unrelated discussion from issue #1355) are suggesting that App Manager is unable to communicate with the local server as it has somehow become unresponsive.
In any ADB (or non-root privileged) mode, App Manager manages a privileged interface in the following way:
During the initial step, it creates a local server under the privileged UID (in this case, UID 2000), which means the local server is a child process of the process where the start command is run (effectively sharing the same UID as SELinux usually assigns the same UID to the child process unless there is explicit rule that bars this). After that, it runs several local services (similar to service components in Android apps) in the local server, and App Manager binds to those services and execute privileged instructions or command using those services. When a user exits from App Manager, those bound services are lost and needs to be run again the next time they launch App Manager again. Now, this (binding/unbinding), in general, is not a problem for rooted users since root privilege is available all the time, and those services can be run any time. But for these other modes of operation, the privilege is not readily available all the time. Therefore, App Manager keeps the local server running all the time (until, say, it's parent process is dead or the process is killed forcefully) so that next time the user launches App Manager, it can quickly run those services instead of starting all over again (which is not always possible, such as when Wi-Fi is unavailable).
But this creates a problem (or introduces a bottleneck) when the local server becomes unresponsive. When a local server becomes unresponsive, it can potentially be solved by launching App Manager two times (must be removed from Recents or force-stopped every time depending on whether App Manager isn't set to run in the background):
- At first launch, it tries to connect to
am_local_serveruntil it times out. If it times out, it tries to stop the server and tries again. But it can still fail to start the server due to unknown reason (the issue is very hard to reproduce in Lineage OS or Pixel ROM which are the devices I've access to). - At second launch, it successfully creates a new local server and works as expected.
So, if your instructions indeed solve the issue, then its likely that this am_local_server is still present even after launching App Manager multiple times. So, killing the server manually may actually solve the issue instead of disabling USB debugging altogether (which effectively exits all the processes under adbd process as it exits the process). (You can kill it by running killall am_local_server in any ADB shell.) Let me know how it goes.
Some Samsung users have also reported that running App Manager in the background also minimized the problem.
on both of my Samsung's I don't have the ability to run as root because the bootloader is locked--on a13 5g, I updated past Android 12 which has oem unlock. and then I didn't know about the other opportunity where an old version of a Samsung app lets you get lower level access to do low level stuff. I updated past that opportunity not being aware and the s25u never had oem unlock due to USA version (no OEM unlock ever sadly).
I can try some of that stuff but basically I have tried force stopping cycling modes etc. it especially appears to flare up due to running shizuku but it can happen unrelated to shizuku being run at all and then no matter how many force stops, cache clear, cycle modes etc it never seems to get back onto an adb mode until I reboot @MuntashirAkon
also I need to clarify that it will say it's running adb mode (wireless debug will notify me) but then I'll check settings and it'll be on non root mode
on both of my Samsung's I don't have the ability to run as root because the bootloader is locked--on a13 5g, I updated past Android 12 which has oem unlock. and then I didn't know about the other opportunity where an old version of a Samsung app lets you get lower level access to do low level stuff. I updated past that opportunity not being aware and the s25u never had oem unlock due to USA version (no OEM unlock ever sadly).
You do not need root to kill the server.
on both of my Samsung's I don't have the ability to run as root because the bootloader is locked--on a13 5g, I updated past Android 12 which has oem unlock. and then I didn't know about the other opportunity where an old version of a Samsung app lets you get lower level access to do low level stuff. I updated past that opportunity not being aware and the s25u never had oem unlock due to USA version (no OEM unlock ever sadly).
You do not need root to kill the server.
Cool I'll have to go back over your post later and I'll let you know whether I'm able to do so, unable to do so, whether it made any difference, etc.
I'm in the android 16 beta for the s25u, so I may have more interesting data for you in time. certain software doesn't even run (MX player, most of the good lock suite, etc.).
...> So, if your instructions indeed solve the issue, then its likely that this am_local_server is still present even after launching App Manager multiple times. So, killing the server manually may actually solve the issue instead of disabling USB debugging altogether (which effectively exits all the processes under adbd process as it exits the process). (You can kill it by running killall am_local_server in any ADB shell.) Let me know how it goes.
Thanks for explaining this. To bad, that I don't understand this internal things good enough to really get it. Question: can I have a adb shell on device itself? I think I need a PC and USB cable for this operation (that would be even more effort). Also, how can I enforce AppManager to keep running in background? I guess whether app is closed or not is decided by OS itself, isn't it?
Yes, you can run an ADB shell directly on the device itself, as long as the device is rooted and you use have a shell or Termux.
Self-ADB Shell from Termux (SU Required)
Start ADB server in TCP mode
su -c 'setprop service.adb.tcp.port 5555' su -c 'stop adbd' su -c 'start adbd'
Connect ADB to local device
adb connect localhost:5555 adb shell
You now have an ADB shell from the device, on the device via localhost:5555.
I use Termux for this.
To Check if it's listening with:
su -c 'netstat -tulnp | grep 5555'
Question #2
Disable Battery Optimization for App Manager app
Go to Settings > Battery > Battery Optimization.
Find App Manager in the list.
Set it to "Not Optimized".
Or TERMUX Cmd:
dumpsys deviceidle whitelist +com.APK_NAME
@shi88ihs : Don't have root, but I set Appmanager to "not optimzed" and see how it will behave.
Just as as short feedback. Setting Appmanager to "not optimized" in terms of battery helps a lot. The number of "inits" are way lesser than before. Still a problem if that happens and your are away from home and don't have WiFi.
Just as as short feedback. Setting Appmanager to "not optimized" in terms of battery helps a lot. The number of "inits" are way lesser than before. Still a problem if that happens and your are away from home and don't have WiFi.
Without following troubleshooting options in https://github.com/MuntashirAkon/AppManager/issues/1596#issuecomment-2975559753, there's no way to figure out the underlying cause since I cannot reproduce it on my device (running Pixel).
@shi88ihs @starbrights You don't need root to run a local ADB shell. There are apps on F-Droid and Play Store that offer a local ADB shell, most utilize Shizuku. You can also use Termux with Shizuku Rish (Use Shizuku in terminal apps option in Shizuku), or install the android-tools package in Termux and pair the adb client with wireless debugging (adb pair localhost:PORT PAIRING_CODE).
@MuntashirAkon I'd say your analysis is correct, killall am_local_server resolves the issue of App Manager not getting past the Initialization... screen (on a Motorola with Hello UI based on Android 15).
Ahead, I think that is not an issue of AM, it is a Samsung/OneUI problem. Running perfectly fine on my LineageOS.
After I disabled battery optimization some few weeks back it works much better. But since yesterday I observe something strange:
Without any major change (Update in Samsung (got A16 but already 2 week ago) or Appmanager (still 4.0.5) I have now the strange behavior that after close display the Appmanagers "ADB Mode" ist gone. That drives me nuts. The Wireless Debug keeps active in device setting, the app seems to stay active. But after switch off display and switch on again, the AppManager's Working Mode is gone. It shows
- remote server is inactive
- remote services are inactive
- couldn't connect via ADB to TCP
When I press "Change Mode" (ADV via TCP is preselected) it works again. WTF!?!?! Any idea what could be the reason for that?
When enabling the ADB mode (either ADB via TCP or Debugging via WIFI in the Status line on top appears a litte icon a 45° rotated square (Debugging via WiFi is connected). It also disappears with screen is off/on, that seems to be related.