Database Develop

[MOD][P905] enable init.d support for stock rom LTE QUALCOMM ONLY!

At first, I am not liable for any harm or damage that may happen to your device!
If you have su and didn't trigger knox, I CANNOT guarantee that running this script won't cause 0x1!
Requirements:
1) P905/viennalte/Qualcomm based model ONLY (won't work on Exynos devices. MIGHT work on other Qualcomm LTE deices from Note Pro and Tab Pro series - feel free to repost but give credits!) running 4.4.2 stock;
2) root access with SuperSU (using cf-root - credits to chainfire);
3) busybox installed (I do recommend this paid installer: https://play.google.com/store/apps/details?id=stericson.busybox.donate , MOST PROBABLY free version will be more than enough, too, but I haven't tested it as I have license...)
4) Android Terminal Emulator installed ( free at: https://play.google.com/store/apps/details?id=jackpal.androidterm )
Installation:
1) download file init.d_qcom.sh using below link and put it in the root of internal memory (so it will be placed in: /sdcard/init.d_qcom.sh)
2) run Android Terminal Emulator
3) at command line, type:
Code:
su -c /sdcard/init.d_qcom.sh
(give it an access if requested)
4) voila.
Additional info for advanced users:
1) scripts in /system/etc/init.d shall be root:root 755 (and NOT 777 as stated in A LOT of sources, thou has to be a heavy idiot to give write access for system files to "world"...)
2) init.d is handled from one of the /system/etc qualcomm additional scripts as it refused to work using regular install-recovery.sh method...
3) scripts are triggered paralelly but I am using different method (find/nohup/su combination...), as this damn rom refused to simply execute "run-parts" applet...
4) init.d permission helper script included (just put your scripts in init.d and they'll receive proper permissions on reboot)
Download:
http://www12.zippyshare.com/v/32009778/file.html

Nice to see some developement for this tab!
Anyway to port it to exynos? :fingers-crossed:

prohackerbro said:
Nice to see some developement for this tab!
Anyway to port it to exynos? :fingers-crossed:
Click to expand...
Click to collapse
+1
sent from my amazing NotePro 12.2 via Tapatalk

Criminal23 said:
+1
sent from my amazing NotePro 12.2 via Tapatalk
Click to expand...
Click to collapse
I might try, however I do not own the device and the file structure is completely different.. Can you first enter via Android Terminal:
Code:
su
ls -l / >/sdcard/content.txt
ls -l /system/etc >>/sdcard/content.txt
And post the /sdcard/content.txt file which will be created (or its contents only)?
Also, i would be glad if you copy every *.rc file from root of filesystem to a dir , compress it to one file and post it too

esgie said:
I might try, however I do not own the device and the file structure is completely different.. Can you first enter via Android Terminal:
Code:
su
ls -l / >/sdcard/content.txt
ls -l /system/etc >>/sdcard/content.txt
And post the /sdcard/content.txt file which will be created (or its contents only)?
Also, i would be glad if you copy every *.rc file from root of filesystem to a dir , compress it to one file and post it too
Click to expand...
Click to collapse
Here you are
Criminal23

Criminal23 said:
Here you are
Criminal23
Click to expand...
Click to collapse
Criminal23 said:
Here you are
Criminal23
Click to expand...
Click to collapse
After looking into sent (and posted) files, I have to say that the init process in our devices are ABSOLUTELY different.
Qualcomm version triggers about 7-8 scripts lying in /system, which are provided by Qualcomm, which are pointed in configuring all the hardware provided with their chipset - in addition to init.???.rc files from the kernel. The clue was to add init.d execution command at the very end of one of those scripts (and that is done automatically with script attached in the first post).
Exynos version does not launch (almost - see below) ANY external script during the boot. Whole process seems to be performed by rc files lying in root of the filesystem, which are embedded in kernel's ramdisk and any edits won't preserve the reboot, so it cannot be done without repacking the kernel and that is something far more troublesome to perform without device in hand, without the firmware on disk and without a plenty of time.
BUT
it still runs /system/etc/install-recovery.sh which is an Android standard and which genuine purpose was to reflash recovery back to stock if a custom one was detected. Now, it is sometimes utlized to run somehing at boot, especially: it is used by SuperSu (in addition with other methods) to run its daemon. The problem is that kitkat introduced enforcing SELinux, that Samsung SELinux policy adds special security context for this file, that install-recovery.sh won't be launched if the file has no proper security label - and that while installing SuperSu, the context is set in a different way and in final, install-recovery.sh isn't launched, until we restore /system context, and restoring context to the system ends with... non working su, so we have to flash it again, breaking install-recovery.sh context... Did you get it? - it's a loop as fixing one thing breaks the second, and fix to the second breaks the first That is why on my qualcomm device i have chosen another script file to run the init.d - and as you don't have any other script except install-recovery.sh, I don't know where it might be put...
BUT also I cannot guarantee that the behavior above is not qualcomm-exclusive and it is possible that on exynos device everything will work without problem!
That's why you may want to try standard method for all the devices (term init - uses install-recovery.sh method described above):
http://forum.xda-developers.com/showthread.php?t=1933849
and if it won't work then you have to wait for - at least - repacked kernel with init.d support embedded into init.rc files or run your script by an external app, ie SManager. Just be aware that even if term init work, it may stop working every time you flash SuperSu, so remember to run the script again then.
Sorry for not being too helpful.

Working with su.d

Hi @Chainfire,
So, a while ago, I posted in the Liveboot thread inquiring as to how I'd go about incorporating liveboot into a ROM so that it could just run on first boot.
Your instructions were to chmod 0770 both the files and folders in su.d, and it should work:
If /system/su.d/0000liveboot.script exists (chmod 0644, not 0700 like other files in /system/su.d/ !), this script will be run instead of logcat and dmesg, and its output will be shown in white (stdout) and red (stderr).
Click to expand...
Click to collapse
However, I tried this, and never got it to work, and essentially moved on to other stuff for a while.
Today, I tried to revisit it, and while I was at it, replace my current init.d stuff with su.d.
So, I created the folder in /system which gets copied with t he rest of the ROM on install. I'm setting folder and file permissions to 0700, owner and group to root, SE context to ubject_r:system_file:s0, which, is exactly the same as what I'm seeing on 0000liveboot when I look at it's info.
This leaves two questions.
One, the above quote you say to set it to 0644, but liveboot itself sets it to 0700 when it installs it.
Two, what is the trick to getting other scripts to work? In your "How to SU" guide, you mention this:
From versions 2.22 onwards, after the policies have been patched and the daemon is ready to go, all executables in the /system/su.d/ directory are executed (chmod 0700 both the directoy and the scripts), followed by setprop supolicy.loaded 1. This is akin to /system/(etc/)init.d/, though execution of those scripts is both kernel-dependent and they may run before the SELinux are patches and/or su is available.
Click to expand...
Click to collapse
Setprop supolicy.loaded. Where am I supposed to do that? You say execution of those scripts is kernel-dependent - you're referring to init.d, yes? So, again, what am I missing?
This is 5.0.1 GPE for M8VZW. I have selinux set to permissive via boot image in init.rc, and verify that "getenforce" returns "permissive" from shell.
Any help you could lend would be greatly appreciated - which is also why I'm posting this as a thread...because su.d sounds like an awesome idea, and I bet more devs would like to start using this method over init.d.
Thank!

digitalhigh said:
One, the above quote you say to set it to 0644, but liveboot itself sets it to 0700 when it installs it.
Click to expand...
Click to collapse
liveboot sets the script that gets run by SuperSU to 0700. The script which I said to be set 0644 is a different script, and is not executed by SuperSU, but by liveboot.
Setprop supolicy.loaded. Where am I supposed to do that?
Click to expand...
Click to collapse
You don't. SuperSU sets this. Kernel developers can hook this event to run their own code.
You say execution of those scripts is kernel-dependent - you're referring to init.d, yes?
Click to expand...
Click to collapse
Yes, not all kernels support init.d, and init.d stuff generally runs before SuperSU patches policies, so there's no guarantees about any SELinux state.
So, again, what am I missing?
Click to expand...
Click to collapse
I don't know. Make sure you are running the latest version of SuperSU (2.46 at the time of writing). Make sure /system/su.d is chmod 0700. Make sure the scripts you want to run are also chmod 0700 and #!'d to a working shell executable. Keep in mind that the scripts are called one-by-one, in a blocking way. So if a script never exits, the next script isn't run.

Deleted

Say I have SU v2.62. I have 2 files in my /system/su.d folder. The first file doesn't have an exit, neither does the second. The second file DOES get executed as it sets selinux to permissive at boot as directed. First file is 0700 (text file), second is 0755 (a .sh file).
Now, I want to take an init.d setprop script and try it via su.d.
1) Do the other files need exit commands?
2) What should the third file (setprop file) be set to, 0755? A .sh or text file?
3) Are the other two set to the correct chmod?
Thank you for any input!
EDIT: Left it as text, and 0755. No exits, and it worked?

Using su.d to disable doze
Is it possible to use su.d in order to load a script that disables Android doze mode?
I'm trying to run this script:
Code:
#!/system/bin/sh
dumpsys deviceidle disable
Script file is located in root\su\su.d
Permissions are set to 0700.
However, script is not loaded automatically during the boot, because if I run the script manually in SManager I get a response Idle mode disabled, which means su.d script wasn't loaded.
Currenlty I use SManager to execute this doze disabling script automatically on every boot, but I wonder why wouldn't the same script work using su.d?
I use another su.d script that disables LED back-lights of hardware navigation buttons and the script works just fine.
I'm using SuperSU v2.82
Thanks for your input.

[MODULE] Insecure adbd for Pixel devices

Hi everyone, I made a simple module for my own needs and I figured I'd share it here as well.
This module enables "insecure adbd" on Pixel devices, which allows you to restart adbd in root mode via "adb root" and push/pull to/from the /data partition among other things.
Note it was only tested on latest stock Pie with November security patches on a Pixel 2 XL, but I took a look at the Pie images of other Pixel devices and it should work for them too. No guarantees about other devices, although if "adbd" is located in /system/bin (the actual binary, not the symlink) rather than in /sbin, it's an arm64 device and it runs Pie, chances are it'll work.
If anyone is curious about how it works, it replaces /system/bin/adbd systemlessly with one from an userdebug AOSP ROM, modified to remove the check for ro.debuggable (as that would be bad for SafetyNet passing) and to use magisk's SELinux context, and it adds sepolicy rules for adbd taken from the AOSP source to make it actually work on stock.
Download:
View attachment insecureadbdv2.zip
View attachment 0001-Insecure-adbd-stuff.patch

You should remove /system/bin/adbd from the replace list in config.sh. That list is used to remove directories systemlessly, not replace files with the ones already in the module... Details here: https://topjohnwu.github.io/Magisk/guides.html#remove-folders

Didgeridoohan said:
You should remove /system/bin/adbd from the replace list in config.sh. That list is used to remove directories systemlessly, not replace files with the ones already in the module... Details here: https://topjohnwu.github.io/Magisk/guides.html#remove-folders
Click to expand...
Click to collapse
Fixed, I also realized the SELinux setup wasn't anywhere near complete (adb install wouldn't work, etc), and rather than hunting down all the changes necessary to make u:r:su:s0 workable with root I modified adbd to use u:r:magisk:s0 which is already setup by Magisk for use with root and I compiled it from latest AOSP, and I removed all u:r:su:s0 rules. Works flawlessly now.

Curious to try
Phoenix Wright said:
Hi everyone, I made a simple module for my own needs and I figured I'd share it here as well.
This module enables "insecure adbd" on Pixel devices, which allows you to restart adbd in root mode via "adb root" and push/pull to/from the /data partition among other things.
Note it was only tested on latest stock Pie with November security patches on a Pixel 2 XL, but I took a look at the Pie images of other Pixel devices and it should work for them too. No guarantees about other devices, although if "adbd" is located in /system/bin (the actual binary, not the symlink) rather than in /sbin, it's an arm64 device and it runs Pie, chances are it'll work.
If anyone is curious about how it works, it replaces /system/bin/adbd systemlessly with one from an userdebug AOSP ROM, modified to remove the check for ro.debuggable (as that would be bad for SafetyNet passing) and to use magisk's SELinux context, and it adds sepolicy rules for adbd taken from the AOSP source to make it actually work on stock.
Download:
View attachment 4650649
Click to expand...
Click to collapse
This work for OnePlus 6? Or be editable?
I'm magisk rooted, just no adb insecure,
Have even decompiled the kernel, made prop edits.
Tried chainfire insecure method (decompile app, use 17.png as adb) both fail.
Build.prop loads correct edits on boot. No adb root :-/
Figured this would be an easy edit as I already have root... Maybe I'm missing something simple

Yamaha169 said:
This work for OnePlus 6? Or be editable?
I'm magisk rooted, just no adb insecure,
Have even decompiled the kernel, made prop edits.
Tried chainfire insecure method (decompile app, use 17.png as adb) both fail.
Build.prop loads correct edits on boot. No adb root :-/
Figured this would be an easy edit as I already have root... Maybe I'm missing something simple
Click to expand...
Click to collapse
If /system/bin/adbd is a binary and not a symbolic link I'd try it. You need to be on Pie of course.
As an explanation, to get adb "insecure" to work you need a few things:
- an "adbd" binary from an "userdebug" build of AOSP (stock roms are "user" builds) for your Android version/CPU architecture. There's no way around this, "user" builds of adbd lack the necessary code. This module has a Pie userdebug adbd for aarch64 SoCs (so you should be fine on Pie as I said).
- ro.debuggable set to 1 or adbd will say that "adb root can't be used on production builds". This check was removed from the adbd binary I compiled because it messes up Safetynet, so it doesn't care about ro.debuggable.
- adbd needs to have a SELinux context that's appropriate for root. Clean adbd uses "u:r:su:s0" which is correctly configured in SELinux in userdebug builds. However, configuring it on user builds is a chore, but as it turns out we already have a SELinux context that's good for root execution with magisk, aka u:r:magisk:s0. So I changed the adbd code to transition to u:r:magisk:s0. I also have a post-fs-data script that grants adbd permission to transition to that context.

Phoenix Wright said:
If /system/bin/adbd is a binary and not a symbolic link I'd try it. You need to be on Pie of course.
As an explanation, to get adb "insecure" to work you need a few things:
- an "adbd" binary from an "userdebug" build of AOSP (stock roms are "user" builds) for your Android version/CPU architecture. There's no way around this, "user" builds of adbd lack the necessary code. This module has a Pie userdebug adbd for aarch64 SoCs (so you should be fine on Pie as I said).
- ro.debuggable set to 1 or adbd will say that "adb root can't be used on production builds". This check was removed from the adbd binary I compiled because it messes up Safetynet, so it doesn't care about ro.debuggable.
- adbd needs to have a SELinux context that's appropriate for root. Clean adbd uses "u:r:su:s0" which is correctly configured in SELinux in userdebug builds. However, configuring it on user builds is a chore, but as it turns out we already have a SELinux context that's good for root execution with magisk, aka u:r:magisk:s0. So I changed the adbd code to transition to u:r:magisk:s0. I also have a post-fs-data script that grants adbd permission to transition to that context.
Click to expand...
Click to collapse
the file you reffer in system/bin is a real .BIN no symlinks.
so i will try this method report back
---------- Post added at 07:22 PM ---------- Previous post was at 07:08 PM ----------
Phoenix Wright said:
Hi everyone, I made a simple module for my own needs and I figured I'd share it here as well.
This module enables "insecure adbd" on Pixel devices, which allows you to restart adbd in root mode via "adb root" and push/pull to/from the /data partition among other things.
Note it was only tested on latest stock Pie with November security patches on a Pixel 2 XL, but I took a look at the Pie images of other Pixel devices and it should work for them too. No guarantees about other devices, although if "adbd" is located in /system/bin (the actual binary, not the symlink) rather than in /sbin, it's an arm64 device and it runs Pie, chances are it'll work.
If anyone is curious about how it works, it replaces /system/bin/adbd systemlessly with one from an userdebug AOSP ROM, modified to remove the check for ro.debuggable (as that would be bad for SafetyNet passing) and to use magisk's SELinux context, and it adds sepolicy rules for adbd taken from the AOSP source to make it actually work on stock.
Download:
View attachment 4650649
Click to expand...
Click to collapse
Which partition is this script dealing with?
Ill do backup and test.
(Systemless kinda rules out /system)

Yamaha169 said:
the file you reffer in system/bin is a real .BIN no symlinks.
so i will try this method report back
---------- Post added at 07:22 PM ---------- Previous post was at 07:08 PM ----------
Which partition is this script dealing with?
Ill do backup and test.
(Systemless kinda rules out /system)
Click to expand...
Click to collapse
It uses magisk to replace adbd without actually changing /system

South
Phoenix Wright said:
It uses magisk to replace adbd without actually changing /system
Click to expand...
Click to collapse
Shouldn't crash me... But say it does...
I'm guessing this similar to a init.D script through magisk?
Reflash magisk if crash to fix ?
Or find your script in. ?? /sbin/.magisk/img/.core/post-fs-data.d
Delete from folder?
Srry I'm away for next 20. But I will try it .. have twrp backups too already...
Just want know what I'm flashing to fix easiest
---------- Post added at 07:46 PM ---------- Previous post was at 07:40 PM ----------
Also, these are both real files.... Hmmm... Messed up symlink in recovery?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Vs /bin
My worry

Yamaha169 said:
Shouldn't crash me... But say it does...
I'm guessing this similar to a init.D script through magisk?
Reflash magisk if crash to fix ?
Or find your script in. ?? /sbin/.magisk/img/.core/post-fs-data.d
Delete from folder?
Srry I'm away for next 20. But I will try it .. have twrp backups too already...
Just want know what I'm flashing to fix easiest
Click to expand...
Click to collapse
Deleting /data/adb/magisk.img from TWRP should do

Yamaha169 said:
Shouldn't crash me... But say it does...
I'm guessing this similar to a init.D script through magisk?
Reflash magisk if crash to fix ?
Or find your script in. ?? /sbin/.magisk/img/.core/post-fs-data.d
Delete from folder?
Srry I'm away for next 20. But I will try it .. have twrp backups too already...
Just want know what I'm flashing to fix easiest
---------- Post added at 07:46 PM ---------- Previous post was at 07:40 PM ----------
Also, these are both real files.... Hmmm... Messed up symlink in recovery?
Vs /bin
My worry
Click to expand...
Click to collapse
It's a real file.

I know this is from 2018, but your module works on my LG V40 on Android Pie! Thank you for making such a useful tool! Magisk too? I REALLY appreciate you making this!

I'm having a hard time finding a version of adbd which is ARM 32-bit, but 64-bit won't work on my device. Any ideas?

Is Magisk Faux root?

I have been rooting my Androids since the original G1 and obviously have always used a traditional root method. I have been trying to do some research on what to do with my next device, traditional root or systemless. The obvious advantage of systemless is passing safety net and probably not have to worry about using root cloak, although root cloak still serves me well to this day. The disadvantages I have found is that because Magisk doesnt actually modify system files it just puts a modified file over the existing one on boot you cannot actually simply go into say root explorer, take any file on the system partition and modify it. Which to me seems like a major disadvantage to anyone who likes to modify files in the system partition. I mean something as simple as swapping out a font file is not longer just a copy paste and change permissions. Am i completely off base on this thinking? Please correct me if I am wrong. The only part that seems to be a huge disadvantage to true root is no one is actually developing SuperSU anymore now that ChainFire sold it from what I understand but there is still the old school superuser app that i believe was open source and could be developed on, as I understood the Superuser apps only denied or granted superuser authority did not actually root the device in the first place anyway.

First of all, SuperSU was systemless root long before Magisk...
I believe you're confusing MagiskSU with Magisk modules and Magic mounting. It's perfectly possible to alter /system while Magisk is installed, as long as you don't have a module that is magic mounting files over that particular part of /system. If that's the case, you'll just be trying to alter the Magisk mask instead of the actual files. If you're not using modules, or if you keep Core Only Mode enabled this won't be an issue.
But, even with magic mounting active you've got full access to the original /system files in /sbin/.magisk/mirror.

Didgeridoohan said:
First of all, SuperSU was systemless root long before Magisk...
I believe you're confusing MagiskSU with Magisk modules and Magic mounting. It's perfectly possible to alter /system while Magisk is installed, as long as you don't have a module that is magic mounting files over that particular part of /system. If that's the case, you'll just be trying to alter the Magisk mask instead of the actual files. If you're not using modules, or if you keep Core Only Mode enabled this won't be an issue.
But, even with magic mounting active you've got full access to the original /system files in /sbin/.magisk/mirror.
Click to expand...
Click to collapse
ah yes i do recall hearing about systemless SuperSU but it seemed that it just installed SuperSU on the user partition and not as a system app and still allowed modifying the system partition. Sorry for my ignorance about this just tough to google how magisk actually works compared to normal root. So if I have magisk it is systemless root but I can still modify the system partition? Thats good to know. What about when it comes to Xposed, can you use normal Xposed with systemless root or do you have to use systemless xposed? Im currently running lolipop with full root and xposed framework but have a new device with Oreo that Ill probably give Magisk a shot with I just want to know the differences I should expect with what you can and cannot do.

Joe333x said:
ah yes i do recall hearing about systemless SuperSU but it seemed that it just installed SuperSU on the user partition and not as a system app and still allowed modifying the system partition. Sorry for my ignorance about this just tough to google how magisk actually works compared to normal root. So if I have magisk it is systemless root but I can still modify the system partition? Thats good to know. What about when it comes to Xposed, can you use normal Xposed with systemless root or do you have to use systemless xposed? Im currently running lolipop with full root and xposed framework but have a new device with Oreo that Ill probably give Magisk a shot with I just want to know the differences I should expect with what you can and cannot do.
Click to expand...
Click to collapse
Yes you can use normal xposed on systemless root, systemless root basically roots by patching the kernel's ramdisk with the SU binary them magisk just install it's remaining binaries in the data partition and them proceeds to hide them through some Linux mounting tricks (it's just a simplified explanation) it's still normal root but the system partition gets intact,magisk and it's modules (in it's repository) use systemless installations as to hide from integrity checks like safetynet and allows you to more easily retain mods during rom updates,other than that magisk is just root with module and hiding functionality
---------- Post added at 12:53 AM ---------- Previous post was at 12:46 AM ----------
Joe333x said:
ah yes i do recall hearing about systemless SuperSU but it seemed that it just installed SuperSU on the user partition and not as a system app and still allowed modifying the system partition. Sorry for my ignorance about this just tough to google how magisk actually works compared to normal root. So if I have magisk it is systemless root but I can still modify the system partition? Thats good to know. What about when it comes to Xposed, can you use normal Xposed with systemless root or do you have to use systemless xposed? Im currently running lolipop with full root and xposed framework but have a new device with Oreo that Ill probably give Magisk a shot with I just want to know the differences I should expect with what you can and cannot do.
Click to expand...
Click to collapse
And if you are wondering how systemless mods (magisk modules) work they are basically 'mirrored' to the system partition during start up but the module itself is in the data partition

DanGLES3 said:
Yes you can use normal xposed on systemless root, systemless root basically roots by patching the kernel's ramdisk with the SU binary them magisk just install it's remaining binaries in the data partition and them proceeds to hide them through some Linux mounting tricks (it's just a simplified explanation) it's still normal root but the system partition gets intact,magisk and it's modules (in it's repository) use systemless installations as to hide from integrity checks like safetynet and allows you to more easily retain mods during rom updates,other than that magisk is just root with module and hiding functionality
---------- Post added at 12:53 AM ---------- Previous post was at 12:46 AM ----------
And if you are wondering how systemless mods (magisk modules) work they are basically 'mirrored' to the system partition during start up but the module itself is in the data partition
Click to expand...
Click to collapse
Thanks for the explanation I appreciate it, so now i guess my only question left is after I use magisk to root and then modify a file on the system partition will I now not pass safety net? I typically dont care about passing since I havent in years but just figured its a question worth asking.

Joe333x said:
Thanks for the explanation I appreciate it, so now i guess my only question left is after I use magisk to root and then modify a file on the system partition will I now not pass safety net? I typically dont care about passing since I havent in years but just figured its a question worth asking.
Click to expand...
Click to collapse
If you are on an old device it's possible you still will pass,but sometimes altering an file on the conventional way will trip safetynet,that's why systemless modules are a thing

Just altering regular files shouldn't affect things though. It usually takes ROM level alterations...

[QUESTION] How to REALLY integrate apps?

Hello.
As we know, Magisk won't touch system partition. But.... There is there a way to really integrate apps to /system?
I'm asking because I use Cerberus, and want to integrate some app's updates also (so, if I reset my phone, don't need a lot of updates again). I want to remove some useless apps also, but all of them are back if I reset my phone.
For Cerberus, I have tested and it won't survive after a hard reset from recovery and/or settings if it is integrated while Magisk is running. So, I had to systemize it from TWRP, using some terminal commands.
I think something like "Link2SD for TWRP", as we can't play with system partition while Magisk is running. Sorry if this question already exists, but I don't find any thread yet.
Thank you in advice.

You can "play with system partition" when Magisk is running. It's mounted in /sbin/.magisk/mirror. You could also enable Core Only Mode (disables all modules) which would mean that the magic mask doesn't get mounted in place of the actual system. Might not be good if you have a bunch of modules though...
Mainly, if you do need apps to do real system modifications with Magisk's magic mask in place you need to ask the developers to make sure that it works. Magisk is the current root solution of choice for most users, and root app developers will simply have to adapt...

Thank you.
I don't have any module running. I only need root to systemize Cerberus and remove some useless apps, nothing else.
So, is possible that an app can write directly to /system instead of Magisk link? If yes, even Titanium Backup needs an upgrade...

In that case, just enabling Core Only Mode should make things work as you expect (in theory) and there won't be a magic mask in the way.
Edit: of course, there might be all kinds of other things in your way, such as SAR, logic partitions, etc.

Thanks, and sorry for late reply.
As soon I can, I'll test and report here.

Just tested. I don't reset my phone, but enabled core mode.
As 'cat /proc/monts' says /system is on Magisk mount, I think core mode isn't the answer.
I'll systemize Magisk Manager, also. So, if I reset, I'll not lose it. Is there a way to keep Manager settings after a reset? Cerberus won't have root until Manager comes up!

romulocarlos said:
Just tested. I don't reset my phone, but enabled core mode.
As 'cat /proc/monts' says /system is on Magisk mount, I think core mode isn't the answer.
I'll systemize Magisk Manager, also. So, if I reset, I'll not lose it. Is there a way to keep Manager settings after a reset? Cerberus won't have root until Manager comes up!
Click to expand...
Click to collapse
Magisk overlays whatever module you decide to install. So that being said grab a root explorer go to /data/adb/modules, I used the osmosis BusyBox module. When in the BusyBox module you click on /system there will only be a
/bin folder jus add /app or /priv-app or / product/app or /product/priv-app depending on where it needs to go. Then you can place your app that needs to be systemized in the folder set the permissions then restart. I have a Pixel 3 XL running Android 10 on logic partitions and this is the only way. Also trying to had ringtones/notifications to /product/media doesn't work you'll need to put whatever ringtone/notification you want In The ringtone/notification folder on the sdcard not the removable sdcard but the phones sdcard
---------- Post added at 08:52 PM ---------- Previous post was at 08:45 PM ----------
If you ain't using the Pixel 3 you would be able to use a add-on.d script to keep magisk installed after a factory reset
---------- Post added at 08:59 PM ---------- Previous post was at 08:52 PM ----------
https://github.com/topjohnwu/Magisk/blob/master/scripts/addon.d.sh
Another option you should try is verity disabler.
https://forum.xda-developers.com/android/software/universal-dm-verity-forceencrypt-t3817389/amp/
This option worked before the logical partitions on my Pixel 3 XL which allowed me to place what I wanted in the actual system folders an restart an they still be there.
Without the disabler you would need a custom kernel to do this. There's an actual way of doing this while flashing the phone it has to do with vbmeta IMG but I couldn't figure it out I'd imagine it has to do with being on a user build and not a Dev build. You will need a working trwp for this to work. When in twrp you'll need to do a complete wipe. Then without restarting the phone adb the zip over to flash

Thank you
My phone is a Xiaomi Mi A2 Lite. The only way to really systemize is through TWRP, with some commands. Not so much work...