[Magisk] eierfrucht:
xxxxx I hope one day you will learn at least to read the posts you are quoting, and skim through the overall context. First off, you only need to deodex framework.jar, not the whole ROM. That's what I used to do to my EMUI 9.0 based ROM back in the day, and I've already mentioned it in a previous post. Secondly--as I have already mentioned--my current EMUI 9.1 based ROM has EROFS and is READ ONLY. xxxxxx I can't xxxx patch anything, it's xxxx EROFS and that's what I actually have started my plight with. Why do I need to retype the same things over and over again, I don't know. My English must suck.

On Huawei devices, Magisk resides inside vanilla recovery. It's the only way to get it working on Huawei, and that's what the manual says. So by replacing Magisk with TWRP--and I did that to get microG working on my earlier ROMs because there used to exist compatible TWRP versions tailored for use with the named ROMs, unlike the current one--you basically make the Nanodroid installer script think there is no Magisk installed (because you have to temprorarily replace it with TWRP as the only way to run the installer) so it will attempt to install everything to /system instead of detecting Magisk.

I'm pretty sure, at least in theory, you don't need TWRP to map a bunch of .apk's on top of existing /system/priv-app .apk's in Magisk, because a lot of modules to exactly that. I've been hoping Nanodroid developer isn't crazy enough to have locked out that option, and I do hope he is aware about the situation with recent Huawei devices that neither allow modifications to /system due to EROFS nor allow the simultaneous use of TWRP and Magisk because to work, one has to replace the other and vice versa.

Magisk modules do not install ANYTHING to /system. They take a bunch of files from /data and MAP them during boot time over a given location in /system so for all intents and purposes, the kernel perceives them as is they resided in /system, but actually they do not. That's why you are able to 'modify' /system without writing a single byte to it, and that's what the word 'systemless' is about.

You have to get rid of the original system apps to do that, which is impossible with an EROFS-based ROM. These user apps could be installed as updates to system apps if they had the correct signatures, but microG dev has good reasons not to rig them that way. So the only way out seems to use a Magisk module that would literally replace certain .apk's in /system/priv-app with microG ones by mapping the microG stuff over that location.

I definitely remember a Magisk module with just the RemoteDroidGuard because the location provider just won't work correctly unless it is placed in /system/priv-app. That module became obsolete after the Systemize module became available so you could just install anything as a user app then map it to /system/priv-app systemlessly using that Systemize thing. I've never seen a module in the repo that would install the entire microG.

Nanodroid installer does in fact do some very lame things to your system. First off, it would wipe every gapp it's aware of. If you configured it to keep gapps, it would reinstall them after wiping. 'Don't touch anything' is obviously not an option. And a lot of people only want microG for a better battery life, not because they hate gapps and surveillance. In fact, a lot of gapps work with microG, it's kind of a big point of the whole project.

By wiping what doesn't need wiped then reinstalling some of it the wrong way, Nanodroid installer breaks certain permissions. As a result, some of the Google Sync options will go missing or start failing, like Contacts and/or Gmail -- even though microG has supported that since at least v2.8.

So I had to use Nanodroid only as a sigspoof patcher (after deodexing framework.jar). I would turn the rest of the options off. Then I would manually remove every basic Google package that would conflict with microG ones using adb. Just that little bunch including gmscore and GSF, you know the drill. Then I would manually install vanilla microG packages from the dev site, then Systemize them using the Systemize Magisk module. Blam! All the sync options ever supported by microG would start working for me! Unlike the broken Nanodroid installer that would half-ass through the job.

I considered reporting it to Nanodroid's author, but it felt useless to negotiate with a person crazy enough to pack the installer with Zelda ringtones and fonts, bandwagoned by a trove of stuff that totally does not need or want to be installed to /system, by no healthy consideration. All that stuff like Osmand, F-Droid, whatever--you can very easily obtain it from official sources, and should you ever need that stuff in /system/priv-app, you can always use the Systemize module. Even though none of these apps would profit from systemizing them. For a systemless environment, there's always the Aurora Services Magisk module, and that's about the only thing from this whole open source scene that ever needs sitting in /system/priv-app. Get that and you will get both Aurora Droid and Aurora Store the highest privilege level they will ever need, that's the point behind the existence of Aurora Services and its predecessor F-Droid Privileged Extension as separate apps.

Why would one lump together a few hundred megabyte worth of open source stuff and stick it with the microG installer/patcher, I have no idea... Why would one want to keep that stuff mapped--or outright physically placed--in /system, I'm clueless... About the Zelda rubbish, I'm speechless... Like, people are sentient and we aren't THAT stupid. We would pretty much on our own discover the amazing open source stuff like Osmand and F-Droid/Aurora Droid, and even the Zelda ringtones and fonts, once we need them. We don't want to be tube-fed all that stuff at once, not even as an 'option'. That's too a nuisance because it needs editing some config files and doesn't cut the overall package size. xxxxxxxxxxxxx

Anyway it looks like the guy himself won't come and tell a way to install just the microG bits from Nanodroid as Magisk Modules without using TWRP or changing anything in /system, just because a lot of devices these days neither have compatible TWRP nor allow modifying /system on a filesystem level. So I'm done with my rant and off to study Magisk documentation. Looks like there's no proper, easy-to-use systemless microG and I must make one myself...