If interested, you could check how it works - frankly, too complicated for me since I don't know the details about the second Playstore's database:
auto-updates:
/data/data/com.android.vending/databases/localappstate.db
detaching:
/data/data/com.android.vending/databases/library.db
It uses sqlite3 and two functions (from its utils.sh script):
- it stops Playstore
- prevents auto-updates by disable_au()
- then detach()
But the good thing is that configuration is absolutely easy, you simply need detach.txt file on the Internal memory / with the list of package names for the apps to detach, like (default list, in the mindetach.zip):
com.google.android.youtube
com.google.android.apps.youtube.music
Hence when you want to detach more apps, just edit that list/file and reboot
PS: It seems there is a bug (incomplete functionality), when you remove a package name from the detach.txt list, it does not revert the states in databases, hence the app removed from the list remains detached (even when you uninstall the mindetach module)
I saw and tested other projects (as I wanted a working one for me), and could see where they could fail. At this stage, my method still works, so I target my TeMeFI dev time elsewhere.
As for config, in my opinion, I think a provided GUI interface was a better choice. I also provide reports showing the state of each individual app, through the same singular GUI, and not a command line. And I also have a method to check what updates have happened (detached AND non-detached) It also removes the risk of user typos by name or file format & location, as I give them the correct and only choices. There are a lot of people not comfortable with editing text files, and are prone to error.
As for removal of the detach-ing app, I have said the same as for TeMeFI. Where TeMeFI falls over is on a PlayStore wipe or blanket update from Google PlayStore, will also make his/her quick methods, even more susceptible to damage (less layers). But, where he will be saved is that if the module stays installed,. it may save the user if the damage is close to the end of the day, and the next reboot will put it back in place, before the PlayStore sees the issue. All dependent on timing.
I just did a quick check, and although it will do better than some modules I have seen (my method was made/researched many years before his first check-in), it appears to rely on only a few (I only saw
two three in my quick check). Its the many layers that made it work reliably for me, and not just
two three approaches. I wrote it a while ago, so maybe I will check if the second step is also in mine. I think I have about 20, and I am a LOT more aggressive via Method 3. Methods 1 & 2 Work ok for non google apps, and do not bring the PlayStore to its knees; but still cover more than 2 layers. Every detach can collapse the PlayStore during an attempted update from google, and thereby block other updates. But, during my testing, the approaches used in this module, failed my testing on youtube. The other methods are working for my non-google apps, and are appropriate for those non google apps, allo9wing other updates, but at a slower speed.
PS: as for rebooting, I think you could simply run the provided services.sh file without rebooting. I tell people to reboot after mine, but there is no real technical basis for it. It was an early inclusion while I was still in early testing. And without a check, you do not know if or when it needs to be run.
edit: PPS: I *think* if you rerun the service.sh script after you change the settings, (i.e. a delete AND/OR an addition) it would work. Or a reboot and have the module startup fix itself.
