1

So to clarify, I would like to know how a system app is able to resurrect itself (auto start) after I issue a kill command. There are ways to remove apps, by using apps-removal apps as well as directly using rm command to physically erase the apk/odex and folders. And there are plenty of answers on this around. My question is related to the auto-starting "mechanism" itself. That is, is there some xml file and some main process running that checks it? Or something like that. For reference, I'm using Android 6.0.1 and MIUI 8.5.3 on a Rooted device.

Basically I'm exploring the possibility that some system apps which you remove (and then they send your phone into bootloop) are not required, but the checking/trying-to-start process is what makes it loop. The reasoning is that, aside from "application stopped working" error, the system seems unaffected. So it's the message that's creating the problem and whatever is behind generating it. This answer will enable me to test out this possibility, and post any findings here.

Edit1: So looks like the answer to half of my own question, (assuming no other "black magic" is going on such as another app checking status...) - restarting is most likely achieved via BroadcastReceiver.

An app can Register a Broadcast Receiver for System Events. The way it works is, when an event happens on the system (USB is plugged in, internet is detected etc) a Broadcast is sent out to all the apps which are Registered to listen for this event. An app can register through its AndroidManifest.XML or pragmatically. But the main part of the question is - where is this registry and how is it possible to alter it (on a rooted device of course)

Edit2: A bit more info. If I do ps, the process shows as normal:

finddevice [....] SyS_epoll_ 7f83b48c54 S com.xiaomi.finddevice

But if I rename a folder of this system process (to disable it), and then kill the process, seems it's binder thread (binder_thr) trying to bring it back to life:

finddevice [....] binder_thr 7f83b48d44 S com.xiaomi.finddevice

And as soon as I rename the folder back to original, it starts it right back displaying as SyS_epoll_

Improve this question
6
  • Apps register themselves (if they need so) with the system for broadcasts, such as network connectivity changed, device orientation changed, etc. When such a change happens, the broadcast triggers the app. If you have Xposed Framework installed, try this: repo.xposed.info/module/de.defim.apk.receiverstop, and see if the app still wakes up on its own.
    – Firelord ♦
    Jul 25, 2017 at 12:48
  • @Firelord If I'm correct, then this is doable even from SD Maid, for non-Xposed users.
    – Grimoire
    Jul 25, 2017 at 13:31
  • @DeathMaskSalesman Tried SD Maid, it's a nice tool and does work on some system apps, but not on all. Says "failed" when I try to disable their listeners in Receiver Manager.
    – Emil
    Jul 25, 2017 at 17:08
  • @Firelord I don't have Xposed installed. So when one of these resistant system apps re-start, it is their listener that's doing something? Or can it also be some other app that's listening and when it sees you killed his "buddy" he resurrect it? I mean, the first option is the one that I've read about in a few places, just wondering if the 2nd option could also be possible. Is there a common registry place where these things are stored (and could be edited)?
    – Emil
    Jul 25, 2017 at 17:25
  • 1
    @Firelord I installed Xposed, to test this theory, but ReceiverStop module only offers control over system apps in paid version. (and I only need it for testing) I found alternative in Xposed module: repo.xposed.info/module/cn.wq.myandroidtoolsxposed But this app offers limited documentation. Just a list of apps with single check box next to each. When I click on this system app check box, and click save I get a toast: "Done." App still restarts.
    – Emil
    Jul 27, 2017 at 11:07

1 Answer 1

Reset to default
0

I couldn't comprehend this code much but the information about receivers seems to be kept only in memory (no index file in internal storage). You can use the following command to see which receiver is registered for which type of broadcast.

adb shell dumpsys package

As for disabling a particular receiver, try Elixir 2. You can go into its Applications section, choose your app and then scroll down to find the receivers (static). Next to them would be the option to disable that component.

Another option is to use ReceiverStop Xposed module. Its free version allows disabling receivers for user-installed apps only.

As for command-line, if you know the name of the receiver/component, you could do:

adb shell su -c 'pm disable PKG/COMP'         # where PKG is package name of the app and COMP is the component you intend to disable.

That said, I did not test whether the said solutions work for dynamically registered receivers.

Improve this answer
3
  • It goes without saying that the answer is valid for rooted Android devices only.
    – Firelord ♦
    Jul 27, 2017 at 15:57
  • 1
    Well, that's the thing, pm disable doesn't work for these "tough" system packages. (Does work for some system apps though) For now I'm using a script that I wrote to do the disabling/enabling alternatively. Script 1) renames .apk and .odex files and 2) kill the process. This creates infinite loop of pop-up which says "unfourtunately..." Then I toggle the script back on. And the process restarts itself and errors go away. The apps that behave this way, will cause a bootloop if I reboot, so it saves time testing.
    – Emil
    Jul 28, 2017 at 10:48
  • 1
    Thanks for the Elixir2 link, it gives additional useful details. But just like SD Maid, it doesn't work for these apps. Clicking [disable] next to Activities/Receivers has no effect. ReceiverStop, like you said only gives access to system apps in paid version. But I only need this for testing. That is to remove Receivers and see if ROM is still stable. If Yes, then the problem would be identified and I would try to come up with a script-way to do this somehow.
    – Emil
    Jul 28, 2017 at 10:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .