Systemless features

[MuntashirAkon]

After I've added a systemless tag for apps installed systemless-ly using Magisk, I've thought of adding a Magisk module to allow systemless installation of apps and solve various problems people face when debloating Android. From the beginning, my intention is not to touch the system partition and I want to keep it that way.

Features

• Install. Install an app in the systemless-ly. For system apps with mismatched signature, apps can be installed systemless-ly directly from the installer (see replace below). For other cases, apps have to be installed as user apps first and then the user has to use the corresponding option in the App Info tab to convert the app into a system app.
• Replace. The system app can be replaced with an apk of different signature (e.g. webview) in two ways: a. Install the app as a system app by replacing the directory at /system/app or wherever the file is located at the system partition and then install the app again after a reboot (this is probably due to the oat file). b. Replace the directory of the system app so that the app can be installed as a user app
• Uninstall/disable/debloat/remove. Replacing the directory of the responsible app (with removing updates first) would completely remove the app. This is helpful for apps that cannot be prevented from running by any means.

Fail-safe mechanism The module will be very different from a typical module in the sense that the management will be very different. AM will keep a database of tasks handled by the module and can be reverted from AM without uninstalling the module. This is helpful to prevent unwanted situation. For example, when some disabled/replaced system app causes bootloop, the user can boot into safe mode, remove the last changes. At the same time, uninstalling the module from Magisk manager should also remove all the configurations immediately.

Additional features Often it might be necessary to add certain whitelists or permissions (such as #132) for the system apps. For these cases, it's better to use a separate module but could be useful if implemented on AM as well.

[MuntashirAkon]

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

[DrymarchonShaun]

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.

[fabiorzfreitas]

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.

[zer0def]

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.

[fabiorzfreitas]

@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...

[zer0def]

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.