Yep! Lol told you, duraspeed is not the only issue. It’s part of it.
i wasnt having any of these issue when i deleted it so…
I’m not telling you not to delete it.
I just won’t.
i went thorugh many logcats with chatgpt and the maskana is that duraspeed is still killing the accsesibilty for egate despite the whitlist sometimes it takes a couple second sometimes less and sometimes it doesnt start back up at all (interesting to note that FNG with the whitelist doesnt have problem and consistently starts up in 2 seconds so maybe its egate related)
1 Like
if i were to edit the egate android manifest to make it so you cant open egate (remove main activity) than i should have no problems because it will act like the external accseibilty apk right???
Yes, but then you wouldn’t be able to set settings in it.
Technically you can start it with am start or monkey, but I don’t get what you’d be accomplishing exactly.
The same thing could be accomplished by not opening it.
Why are you so against my janky script 
I did notice something like what your describing with egate, even with the whitelist.
The whitelist is definitely working partially, because my script won’t work without it at all.
nothing im might actually implement it
but if im setting it up for someone else it a one time and done type of thing
2 Likes
check this out From your logcat, what’s happening is that the Accessibility service (part of Android’s system services) is being stopped and restarted each time you swipe the accessibility app away.
When you close an accessibility app, Android treats it like any other background service — if it’s providing an ongoing system function (like screen reading, gesture assistance, or automation), the AccessibilityManagerService restarts it.
The reason it’s taking longer each time is likely because:
-
Service restart delays — Android uses an increasing back-off delay when the same service crashes or is killed repeatedly in a short period of time. This is to prevent “restart loops” from eating resources.
-
System process reloads — Each restart re-registers event listeners, reloads settings, and re-binds to other services (seen in the logs where
AccessibilityManagerService$Lifecycleruns again). -
Other boot-phase work — If other background services are still initializing or reclaiming memory, the accessibility service’s restart can be slowed down.
In short — nothing is “broken,” but Android is intentionally slowing the restart after repeated kills to protect performance and battery. That’s why after the 3rd swipe-away, the start-up pause was noticeably longer.
If you want, I can dig through your log further to pinpoint exactly which accessibility app is restarting and the restart delays Android is applying. That would tell you whether the slowdown is from system throttling or the app’s own heavy startup. Would you like me to check that?
You said:
what function of android slows the restart - can i make it not do that at least for specific apps
ChatGPT said:
What’s slowing the restart in your case is Android’s ActivityManagerService crash/kill restart back-off policy.
Here’s the breakdown:
-
In Android, when a service (including accessibility services) is killed too many times in a short window — whether by the user swiping it away or it crashing —
ActivityManagerServiceputs it into a “restart later” queue. -
This uses an exponential back-off: first restart is almost instant, the second might be a few seconds, then 10+ seconds, and so on. This is a built-in ANR and battery-protection mechanism to avoid “restart storms” that drain power or hog CPU.
-
Accessibility services get restarted by
AccessibilityManagerService, but the timing is still controlled byActivityManagerService’s scheduling.
2 Likes
And what do you know its a problem in the services.jar 
1 Like
I applaud all the interesting work happening here. Keep it up, and we actually might manage to fix the Qins.
3 Likes
So much smali…
I’ll look back at my notes and get back to you.
When discussing with the person who figured it out, everything I tried he said was not it.
I think ActivityManager.smali (or was i ActivityManagerService.smali?) in services.jar is the culprit, but I can’t be sure.
One thing, I don’t believe the “fix” is SPECIFICALLY for accessibility. It should work system wide for normal apps (eg music apps stopping to play) and even vpns stopping when the app is closed. Everything.
2 Likes
If it’s a one and done thing, doesn’t systemizing it take care of this issue?
If you’re setting it up one time…
That being said, that’s not a solution for everyone.
Mind if I stick the accessibility fix above in your Google ROM?
Don’t really have the patience to make a new ROM. If somebody does, I’d be happy to give you all files to place and instructions.
Would include the whitelist APK to update for more apps.
Anyone ever try this ROM?
From 2024, so gapps are probably not too outdated.
yup
1 Like
There’s a small problem with the app will upload fix soon
So, even with my script, if you time it just right and are on the accessibility screen, you can turn off egate.
Will add an input to go to home screen in the script, that should take care of it.
Actually, will just force stop settings app.
New links:
Release curl/wget + apk · alltechdev/duraspeed-whitelist
New script, really seems to be perfect this time.
Updated the original post
Someone please try it and report back 
Alright.
First module I put out, perfect with fng, issues with egate.
Second module I put out, perfect with egate, issues with fng and TripleUmdm.
I’m going to have to edit the module some more, I know I can do it, just going to take time and a bit more complicated to work across the board for all accessability apps.
1 Like
Thanks for putting in the dirty work
2 Likes