There's a new app in town which uses somewhat similar concept that I was planning to do: https://github.com/sunilpaulmathew/De-Bloater

It looks like that same developer is working on an app similar to this one -- https://github.com/SmartPack/PackageManager -- just to throw out a random thought, maybe you should contact them and see if either of you could help each other; maybe you could either implement the functions of https://github.com/sunilpaulmathew/De-Bloater into this app, or create a way to interface with that app from this one, if its installed? An even more out there idea would be the possibility of merging all three apps into one? This is coming from someone that doesn't really know anything about this stuff past that it generally isn't as easy as it might seem.

I'm not sure if this is the correct page to ask about this, but by searching the Issues, I found many references to #150.

I was searching on how to install an app as a system app and stumbled upon major contributors of this project agreeing that the best way to achieve this would be a systemless approach. It sounds conflicting to me, but I don't really need to understand, I'd just like to ask is if there's already an option to install apps as system (I wasn't able to find one, though) or if the changes proposed here will add that feature.

PS: my intent is to have the anti-theft app Cerberus survive a factory reset by installing it as system to /system/priv-app. They suggest a Magisk module for that, but it hasn't been updated since 2017, so I searched this feature on App Manager, which I already used.

Also, I'd appreciate if someone could inform me if that this Cerberus method is completely outdated and won't work on A13 or there's already a solution, maybe a Magisk module, that's better suited for this.

Modules (be it KernelSU or Magisk) generally store themselves in /data/adb/modules, mostly because they have no other reliable options of persistence, meaning they get wiped during a factory reset, since that just formats your userdata partition, which is mounted under /data.

The flip side is that some devices may have their system partitions (/system, /system_ext, /product, /vendor, …) on read-only filesystems (EROFS comes to mind, squashfs would be an example, but not in use in the Android ecosystem), which would prevent you from modifying them from recovery, but that's not a given.

The flip side of the flip side (that is, if your device's system partitions are on writable filesystems) is that it might be self-defeating to the entire intent, because if the intented user can modify system partitions from recovery, so could an unintended user. But if you can (from a technical standpoint) and want to take that route (your threat assessment is to prevent dipshit petty thievery, but doesn't concern itself with technically sophisticated mal-actors out for your data, not your device), you'd be putting together an OTA/zip very much akin to custom GApps installers to flash after your ROM. This is probably the answer you'd be looking for and outside of the scope of this application's concerns.

The middle-ground would be something primarily device vendors would be able to achieve (to a point, until someone EDLs themselves beneath the entire charade), for example, by putting the device in some deep sleep mode during "power-off" (airquotes, since it would still sip on battery more than a regular powered off discharge would), much like Apple's FMD, but likely goes outside of Cerberus' scope.

@zer0def Thanks for your reply.

But what if I were to use something like Terminal Systemizer to install Cerberus to /system/priv-app, as they suggest, and disable hardware buttons with kiosk mode, wouldn't that be enough to prevent any access without the pin? I mean, can you even use adb on a locked device? I even disallowed the dropdown menu while locked.

Finally, while detecting nearby WiFis may be enough, I'm also thinking about preventing SIM Card removal. I'm on Pixel, so no room for SD Cards, and I also don't see myself changing carriers anytime soon (unless I travel somewhere else on vacation, but that's remote), so I'll even consider gluing it. And considering that I always have some Isopropyl Alcohol on my workbench, perhaps this gluing method wouldn't even need to be permanent...

Terminal Systemizer falls squarely within the first paragraph, while modifying it's own overlay directories with each app you add/remove.

As for inducing adb on locked devices: it's certainly possible, depending on a device's state and bugs in the system itself. There's no clear "yes" or "no" answer in this situation, only varying degrees of "maybe", even dependent on your device's incremental update.

All mentioned topics effectively fall within every user's individual threat assessment, as it might be easier to develop fallbacks instead of preventions as long as known attack vectors are accounted for. On top of that, some issues may end up much easier to solve when treated as a behavioral problem, not a technical one.