I'm looking for a module to be created, or if I could do it not sure. Something to do the same as "lockscreen disabler" did in Xposed. Willing to donate. App in question for exchange email is "Email MOTOEMAIL.00.05.0072". Currently running XT1254, 6.0.1, stock rom. Thank you.
Shtiff1 said:
I'm looking for a module to be created, or if I could do it not sure. Something to do the same as "lockscreen disabler" did in Xposed. Willing to donate. App in question for exchange email is "Email MOTOEMAIL.00.05.0072". Currently running XT1254, 6.0.1, stock rom. Thank you.
Click to expand...
Click to collapse
maybe it is enough if you download the module-template edit config.sh and module.prop to an ID if your choice and in config.sh also the REPLACE part with /system/app or priv-app/Lockscreen/ ?
something like this maybe? but here ends my know-how
Shtiff1 said:
I'm looking for a module to be created, or if I could do it not sure. Something to do the same as "lockscreen disabler" did in Xposed. Willing to donate. App in question for exchange email is "Email MOTOEMAIL.00.05.0072". Currently running XT1254, 6.0.1, stock rom. Thank you.
Click to expand...
Click to collapse
First, that's not a donation you're talking about, it's a bounty.
Second, if it can't be done without Xposed, it can't be done with Magisk. So don't hold your breath.
wiQbold said:
maybe it is enough if you download the module-template edit config.sh and module.prop to an ID if your choice and in config.sh also the REPLACE part with /system/app or priv-app/Lockscreen/ ?
Click to expand...
Click to collapse
What? I don't think you understand what the REPLACE part of the config.sh file does.
During installation, that little entry puts a file called "replace" in each folder listed, in the module folder structure. Every time Magisk mounts a module and finds that file it will completely wipe (systemlessly, of course) the corresponding folder in /system.
If you want to replace a file on your device with one you've edited, all you have to do is to put that file in the module zip, under the same folder structure it can be found on your device. After that Magisk's Magic Mount will do it's thing...
Didgeridoohan said:
First, that's not a donation you're talking about, it's a bounty.
Second, if it can't be done without Xposed, it can't be done with Magisk. So don't hold your breath.
What? I don't think you understand what the REPLACE part of the config.sh file does.
During installation, that little entry puts a file called "replace" in each folder listed, in the module folder structure. Every time Magisk mounts a module and finds that file it will completely wipe (systemlessly, of course) the corresponding folder in /system.
If you want to replace a file on your device with one you've edited, all you have to do is to put that file in the module zip, under the same folder structure it can be found on your device. After that Magisk's Magic Mount will do it's thing...
Click to expand...
Click to collapse
right. my consideration was to wipe the lockscreen folder in system to disable it
wiQbold said:
right. my consideration was to wipe the lockscreen folder in system to disable it
Click to expand...
Click to collapse
Ok. In that case I believe you haven't quite understood the request...
Didgeridoohan said:
Ok. In that case I believe you haven't quite understood the request...
Click to expand...
Click to collapse
that could be true. do not have any device older then nougat and can t try the xposed-module.
thought it disable only the lockscreen.
wiQbold said:
that could be true. do not have any device older then nougat and can t try the xposed-module.
thought it disable only the lockscreen.
Click to expand...
Click to collapse
From what I can tell it disables the lockscreen while tricking apps that require a lockscreen into thinking it's enabled.
Easy-ish with Xposed, impossible with Magisk unless you manually edit the app in question to not detect the lockscreen state and then use a Magisk module to mount it to your device.
Didgeridoohan said:
From what I can tell it disables the lockscreen while tricking apps that require a lockscreen into thinking it's enabled.
Easy-ish with Xposed, impossible with Magisk unless you manually edit the app in question to not detect the lockscreen state and then use a Magisk module to mount it to your device.
Click to expand...
Click to collapse
That is correct. When i opened phone before it just had swipe up to open. Now I have to enter lock code every time. I haven't done anything with adb before, always do everything from the phone. I've seen the apk "exchangenopin" but I can't try it, cause I can't download the apk anywhere. Those from other thread seem to go to ad sites. I figured that it wouldn't of been that difficult because the exchangenopin "supposedly" works w/o Xposed. That's why I was hoping for a module. I found something to replace my "insert custom text" module from Xposed, now just need something to replace for lockscreen. Lol. Liking Magisk though.
I experienced the same problem with my realme 5i smartphone, I tried to install the latest Magisk via the OrangeFox recovery because I had never rooted my smartphone before. but I have installed pixel 5 archipelago project. In this case, after installing magisk and successfully entering the lockscreen, here the problem occurs because I can't enter the lockscreen PIN and can't do anything, I can't even turn off my phone. But here I found a solution, namely using a google account and trying to wipe data via the Google Play application, namely find my devices and then delete it there and it worked for me
Related
This has been fixed xda postNote: This is a temporary solution until someone fixes this in Xposed. Also I use my module "SnapColors" as a example throughout this post but this fix should for work any module. I've tested it with other modules and it works. If the module did not previously work on 5.0 then ignore this post and continue on with life.
TL;DR Version:
I found a temporary solution of getting modules to work on 5.1 for modules that worked on 5.0 but don't work on 5.1.
Non-TL;DR Version: Backstory and how I found his temporary solution
So a couple days ago I decided to start working on bring my module(s) to Xposed running on 5.1. In doing so what I noticed with a lot of the modules they seem to crash the app without throwing any kind of error whatsoever. Take for example one of my modules "SnapColors", if SnapColors was enabled in Xposed Installer SnapChat would always crash without throwing any error it wouldn't even say anything along the lines of "process has stopped unexpectedly" it would just close the app. So because of this behavior it led me to believe something was wrong with Xposed and not with my module(s). So I went thought what could be broken in Xposed thats causing this because 5.0 is just one up to 5.1 so the changes couldn't be that big. I went though the things that could cause this and came across "dalvik-cache" I remember reading somewhere Xposed makes some changes to the cache file (.dex) thats created during the creation of dalvik-cache files. So then I thought what if in 5.1 a small change was made to the process of making the dalvik cache files and thats what is causing the problem. So I decided to delete the dalvik cache file for SnapChat which is what my module was hooking into, then I tried opening SnapChat again but it crashed so I tried opening it again and what do you know it opened without any problems with my module fully working without any problems. The fix was kind of a guess too.
The fix/Solution
Note: If you reboot your device you have to do the fix again. Also you are deleting the dalvik cache so you won't benefit from it any more for the app(s) you delete it for. Unless you reboot then everything gets reverted.
What you have to do is delete the dalvik cache file for the app the module is for.
Example: SnapColors a module for SnapChat, so we have to delete the dalvik cache file for SnapChat.
What you need:
1) A file manager with root access, or terminal knowledge.
2) Package name example for SnapChat its "com.snapchat.android". How to get the package name look below theres a how to.
Steps for deleting the cache file:
Make sure the app is not running in the background close it if it is.
Method 1) Via terminal command:
Code:
cd /data/dalvik-cache/arm/ && rm [email protected]@"package name here without the quotes"*
Example command for SnapChat would be don't forget the "*" at the end:
Code:
cd /data/dalvik-cache/arm/ && rm [email protected]@com.snapchat.android*
Method 2) Via file manager: Navigate to /data/dalvik-cache/arm/ look for a file starting with the name [email protected]@"package name here without the quotes".apk delete this file and thats it.
Now try and open the app if it doesn't work close the app then try opening it again. make sure that apps not running in the background before trying again.
Getting package name
Via terminal command:
Code:
ls /data/data/ | grep "the app name here without quotes"
Via app: Install https://play.google.com/store/apps/details?id=com.electricsheep.asi
Open it-> Apps tab-> Tap the app-> look for "Package name:" should be the first thing.
Great job figuring that out! I hope @romracer takes a look at it and releases an update with permanent fix
mmamedov said:
Great job figuring that out! I hope @romracer takes a look at it and releases an update with permanent fix
Click to expand...
Click to collapse
Yup. I wish I could help but my knowledge of c++ is limited.
Why are apps on 5.1 creating this dalvik file if the runtime is ART?
r25txe said:
Why are apps on 5.1 creating this dalvik file if the runtime is ART?
Click to expand...
Click to collapse
The files are used by art despite the name of the folder "dalvik-cache". I think don't quote me on that.
Subscribed
sent from your moms phone
Can I get gravitybox to work?
Sent from my Nexus 5 using XDA Free mobile app
Programming4life said:
Yup. I wish I could help but my knowledge of c++ is limited.
Click to expand...
Click to collapse
Enough knowledge to help me out on twitter ALLLL the time! Lol
Great Finding. Thanks for the info.
Any chance of getting work Xposed GEL setting with CM12.1 Android 5.1
Thanks
lolzas said:
Can I get gravitybox to work?
Sent from my Nexus 5 using XDA Free mobile app
Click to expand...
Click to collapse
For module related stuff post on there thread. Getting modules to work is on the dev of the module.
mjrifath said:
Great Finding. Thanks for the info.
Any chance of getting work Xposed GEL setting with CM12.1 Android 5.1
Thanks
Click to expand...
Click to collapse
For module related stuff post on there thread. Getting modules to work is on the dev of the module.
Another step into 5.1 with xposed.. Only needs rovo magic Touch.. Thanks for it...
Programming4life said:
For module related stuff post on there thread. Getting modules to work is on the dev of the module.
Click to expand...
Click to collapse
So can you tell us what are those 95% modules for xposed on Lolli 5.1?
Can you give us some examples what modules are working on your smart phone with your metods?
Thanks...
spaxon said:
So can you tell us what are those 95% modules for xposed on Lolli 5.1?
Can you give us some examples what modules are working on your smart phone with your metods?
Thanks...
Click to expand...
Click to collapse
I said ~95% because some modules need to be updated strictly for lollipop and won't work no matter what. Its more like 99% but 95% just in case.
Programming4life said:
The fix/Solution
Note: If you reboot your device you have to do the fix again. Also you are deleting the dalvik cache so you won't benefit from it any more for the app(s) you delete it for. Unless you reboot then everything gets reverted.
Click to expand...
Click to collapse
Something I dont understand, for almost every module in xposed on every version of android, you must enable that module in xposed and reboot smartphone to get it work... is it true?
I have tried Gravitybox LP and some more modules like Flat Style Bar Indicators, with deleting them in /data/dalvik-cache/arm/ but they dont work at all, i have tried couple of times starting them.
Also I tried deleting them in twrp file manager and I have bootloop (but no worries I deleted those modules and started the phone )
Am I doing something wrong?
spaxon said:
Something I dont understand, for almost every module in xposed on every version of android, you must enable that module in xposed and reboot smartphone to get it work... is it true?
I have tried Gravitybox LP and some more modules like Flat Style Bar Indicators, with deleting them in /data/dalvik-cache/arm/ but they dont work at all, i have tried couple of times starting them.
Also I tried deleting them in twrp file manager and I have bootloop (but no worries I deleted those modules and started the phone )
Am I doing something wrong?
Click to expand...
Click to collapse
After installing a module you must enable it and then do a reboot/soft reboot yes that is true. Gravitybox LP and Flat Style Bar Indicators both modify the android system itself so theres nothing we can really do until someone fixes this bug in Xposed's code.
What if we modify the permissions or the file itself so we don't have to constantly delete it upon reboots?
Sent from my Nexus 5 using Tapatalk
Youtube background playback don`t works with that method
FuMMoD said:
What if we modify the permissions or the file itself so we don't have to constantly delete it upon reboots?
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
Android doesn't like it when the permissions are changed for a cache file so it'll just fc the app.
jabarel said:
Youtube background playback don`t works with that method
Click to expand...
Click to collapse
Worked for me you may have a out dated version of YouTube or YouTube background.
Hi,
Sometimes in Lollipop some module don't work. Then, in my case I reboot to recovery and I touch the file "conf/disabled" for starting without Xposed. After that, I like to disable the module in the UI of the Xposed Installer App... but when the framework is disabled, this option is disabled.
Please, can you change this?
Thank you!
Note: Yes, is posible to manually change the "/conf/modules.list" file from the recovery, but this is more complicated.
manos78 said:
Hi,
Sometimes in Lollipop some module don't work. Then, in my case I reboot to recovery and I touch the file "conf/disabled" for starting without Xposed. After that, I like to disable the module in the UI of the Xposed Installer App... but when the framework is disabled, this option is disabled.
Please, can you change this?
Thank you!
Note: Yes, is posible to manually change the "/conf/modules.list" file from the recovery, but this is more complicated.
Click to expand...
Click to collapse
Why don't you just disable the module, reboot, enable the module again and reboot again? No need to place any files through recovery?
By the way: could you give us more information about your device, the Android version and the Xposed files you use? Those are important information, without them nobody might help you.
orville87 said:
Why don't you just disable the module, reboot, enable the module again and reboot again? No need to place any files through recovery?
Click to expand...
Click to collapse
Because the device don't boot (bootloop on the boot animation)!!!
So, in this case the ONLY solution is: boot to recovery, touch the "disable" file, reboot with Xposed disabled... and then: How to DISABLE the module? The UI is blocking the option of enable/disable modules when the framework is disabled!
Please, remove this arbitrious limitation in the UI.
Thank you!
Why don't you just delete the modules.list inside the
data/data/de.robv.android.xposed.installer/conf/
folder?
corncobman said:
Why don't you just delete the modules.list inside the
data/data/de.robv.android.xposed.installer/conf/
folder?
Click to expand...
Click to collapse
Good alternative, but this disables all modules and you lost the info related to enabled/disabled modules... or not?
manos78 said:
Good alternative, but this disables all modules and you lost the info related to enabled/disabled modules... or not?
Click to expand...
Click to collapse
Yes, this method disables all modules. But what info related to enabled/disabled modules are you talking about? Which modules have been enabled and which not?
... you lost the info related to enabled/disabled modules... or not?
Click to expand...
Click to collapse
Not. The list of which modules are selected and which are not selected are still shown. Just disable the offending module and reboot.
corncobman said:
Not. The list of which modules are selected and which are not selected are still shown. Just disable the offending module and reboot.
Click to expand...
Click to collapse
Then you recommend "delete this file" instead of "touch the disable file" for disable only the loading of the modules but enable the framework? Then, when rebooting the phone the module list will be re-created?
The module list will be created when you change the list, i.e. toggle one module on or off. The changes only apply when you reboot.
manos78 said:
Then you recommend "delete this file" instead of "touch the disable file" for disable only the loading of the modules but enable the framework? Then, when rebooting the phone the module list will be re-created?
Click to expand...
Click to collapse
Do you want to permanently disable the module that causes the issue or do you want to use the module again after reboot?
In the first case, you can delete the corresponding module by using the in-build file manager of your recovery. Just navigate to /data/app and delete the module's folder. Done.
Otherwise, you only have the limited options presented to you (but I don't know why someone would continue using a module that is causing issues again and again).
orville87 said:
Do you want to permanently disable the module that causes the issue or do you want to use the module again after reboot?
In the first case, you can delete the corresponding module by using the in-build file manager of your recovery. Just navigate to /data/app and delete the module's folder. Done.
Otherwise, you only have the limited options presented to you (but I don't know why someone would continue using a module that is causing issues again and again).
Click to expand...
Click to collapse
Hi, I agree!
However, when a module "fails" I don't like to uninstall it... I like only to disable it. Why? Because I like to contact with the author and try fix the bug. Sometimes the problem is an update, o some other times the module is part of an App that has another functionalities. Then the best option is disable the module and not uninstall/remove it.
So, my concern is related to the best option to fix a bootloop when a module is creating some interference. Until now my best option is disable the Xposed framework, but here the recomendation is disable the load of modules. In this last case, I need to know if this file is re-created by the Xposed framework. And however, I feel is a good recomendation to enable the UI of the modules when the framework is disabled... the current behaviour is annoying.
Regards!
manos78 said:
Hi, I agree!
However, when a module "fails" I don't like to uninstall it... I like only to disable it. Why? Because I like to contact with the author and try fix the bug. Sometimes the problem is an update, o some other times the module is part of an App that has another functionalities. Then the best option is disable the module and not uninstall/remove it.
So, my concern is related to the best option to fix a bootloop when a module is creating some interference. Until now my best option is disable the Xposed framework, but here the recomendation is disable the load of modules. In this last case, I need to know if this file is re-created by the Xposed framework. And however, I feel is a good recomendation to enable the UI of the modules when the framework is disabled... the current behaviour is annoying.
Regards!
Click to expand...
Click to collapse
Ah, I see your point there. Well, I have some thoughts about another possibility. I haven't tried it yet, so no guarantee can be given if this will work. But before updating a module, you could backup the folder of the module from /data/app and place it's backup folder somewhere else. Then update the module and reboot. When facing a bootloop, just use the recovery file manager to replace the new files of the module with the old ones and reboot. This way one does not have to disable all modules or even disable/uninstall the entire framework.
orville87 said:
This way one does not have to disable all modules or even disable/uninstall the entire framework.
Click to expand...
Click to collapse
Yes, but I like the most simple option: At time, I do this when bootloop:
a) Reboot to recovery.
b) Open Aroma File Manager.
c) Rename "_disabled" to "disabled" in the xposed/config directory
d) Reboot
And when the device boots, I like to "disable" in the Xposed App... the problem is the UI... it disables interaction when the framework ins't loaded. From my point of view is a mistake! Why force this? Any reason that I don't view?
Another option is remove the file with the list of modules, but I don't know if the Xposed App recreates this file after boot, and if it's maintains the selected/unselected list of modules (normally I have some modules installed but disabled... think on Apps with Xposed add-ons that I don't like to use!).
Any comment?
manos78 said:
Yes, but I like the most simple option: At time, I do this when bootloop:
a) Reboot to recovery.
b) Open Aroma File Manager.
c) Rename "_disabled" to "disabled" in the xposed/config directory
d) Reboot
And when the device boots, I like to "disable" in the Xposed App... the problem is the UI... it disables interaction when the framework ins't loaded. From my point of view is a mistake! Why force this? Any reason that I don't view?
Another option is remove the file with the list of modules, but I don't know if the Xposed App recreates this file after boot, and if it's maintains the selected/unselected list of modules (normally I have some modules installed but disabled... think on Apps with Xposed add-ons that I don't like to use!).
Any comment?
Click to expand...
Click to collapse
When you have deleted the module list from recovery, Xposed will not create a new list after the following boot process. You have to open Xposed Installer and disable/enable a module, then reboot. This time, Xposed will create a new module list (with exactly the modules states they had before deleting the module list file apart from the last modification you have done to trigger this recreation) and you are free to go. Nevertheless, a cumbersome solution.
I have no idea why one isn't able to interact with the checkboxes, but my best bet would be to prevent the user from thinking that Xposed is indeed active and modules are not working despite being enabled.
orville87 said:
I have no idea why one isn't able to interact with the checkboxes, but my best bet would be to prevent the user from thinking that Xposed is indeed active and modules are not working despite being enabled.
Click to expand...
Click to collapse
Ok. I understand this point... with this the user don't be confused.
So, why not add one option menu in the screen of modules for "enable changes" when the framework is disabled? This option implies "the framework is disabled, but you can change the options". This be user friendly and powerful at time.
What you think?
manos78 said:
Ok. I understand this point... with this the user don't be confused.
So, why not add one option menu in the screen of modules for "enable changes" when the framework is disabled? This option implies "the framework is disabled, but you can change the options". This be user friendly and powerful at time.
What you think?
Click to expand...
Click to collapse
Might be a good point, but you have to ask rovo89 for feature requests. But I highly doubt that he will implement such thing.
orville87 said:
Might be a good point, but you have to ask rovo89 for feature requests. But I highly doubt that he will implement such thing.
Click to expand...
Click to collapse
Well, I hope Rovo89 will read this and agree to implement... it's a very simple change in the UI. :fingers-crossed:
manos78 said:
Hi,
Note: Yes, is posible to manually change the "/conf/modules.list" file from the recovery, but this is more complicated.
Click to expand...
Click to collapse
Not really complicated. If you've access to ADB simply do
Code:
adb shell sed -i '/.*PACKAGE.*/d' /data/data/de.robv.android.xposed.installer/conf/modules.list
adb shell sed -i '/.*PACKAGE.*/d' /data/data/de.robv.android.xposed.installer/shared_prefs/enabled_modules.xml
Change PACKAGE with the package name of the app.
The first command would disable only the module, not the framework, not the rest of the modules. The second command would make sure that when you open the Xposed app -> Modules, your module shows up as unchecked. The second command is not important but it is good to keep confusion at a distance.
If you don't have access to PC always, you can keep a script inside your sdcard or `/data` as
Code:
#!/bin/sh
sed -i '/.*PACKAGE.*/d' /data/data/de.robv.android.xposed.installer/conf/modules.list
sed -i '/.*PACKAGE.*/d' /data/data/de.robv.android.xposed.installer/shared_prefs/enabled_modules.xml
If you've TWRP, you can edit the file to change the package name and run the script without the need of a PC.
nomap_here said:
If you've TWRP, you can edit the file to change the package name and run the script without the need of a PC.
Click to expand...
Click to collapse
Thank you!
But quite complex! I prefer to "touch disable" for disable Xposed (fail safe boot mode) and in the UI of the App (when the Xposed is disabled) then enable/disable the ofending module. I feel is MORE SIMPLE and INTUITIVE!
I hope Tovo read this and change the UI. :fingers-crossed:
Root Explorer & AutoRun Receiver modification How to? (Going from SuperSu to Magisk)
I'm old school, using SuperSu, looking at a new phone will have to use Magisk. I understand it is systemless still unsure if i can do what I did prior with SuperSu like running root explorer and making changes to the system partition files does not appear to be as simple as it was with SuperSu. A thread mentioned that a module is needed. Can someone explain to me in detail what is required to make a change to a system file and if my understanding is correct I can't just fire up Root Explorer and make the changes on the fly?
This also ties to other apps like AutoRun which I use to manage all the receivers for all the apps and system apps. How can this be achieved with Magisk which is systemless root?
SuperSU is systemless root, just as Magisk is... What most get confused about is that Magisk also can do systemless system modifications.
The only time you would run into any trouble would be if you have a Magisk module mounting the same file(s) you want to edit manually. Other than that it shouldn't be any different. It's just root by different names...
You only need to use modules if you want to do systemless modifications (which has a few advantages, like being easy to revert, sticking across system updates, etc).
..
Didgeridoohan said:
SuperSU is systemless root, just as Magisk is... What most get confused about is that Magisk also can do systemless system modifications.
The only time you would run into any trouble would be if you have a Magisk module mounting the same file(s) you want to edit manually. Other than that it shouldn't be any different. It's just root by different names...
You only need to use modules if you want to do systemless modifications (which has a few advantages, like being easy to revert, sticking across system updates, etc).
Click to expand...
Click to collapse
Thanks for that explanation, coming from SuperSu and reading the different threads and articles really does cause confusion.
So if I understand correctly, if I buy an S10, root it per the instructions i can use Root Explorer and Autorun & AdAway for example to make changes to system files and it will behave the same as SuperSu on older platforms?
You mentioned the benefits of systemless modifications is easy to revert, i guess for those that don't document changes or make a backup this is a benefit but i do both so it wouldn't make much sense for me.
But you touched on something important about sticking across system updates. If I manually edit the system files like I do in SuperSu, doesn't that render system updates obsolete because the phone is now rooted and system files have been modified and OTA updates no longer work? I assume by updates you mean manual updates and not OTA so I just want to confirm.
Another question regarding manually changing system files how does that affect SafetyNet checks and Magisk ability to Hide root from banking apps. Would these still work if I use root explorer, AutoRun & Adaway for example?
Thanks a lot
Correct, I'm talking about manual updates, not OTA (which won't work with a modified /system).
Most system edits you do will still make it possible to pass SafetyNet, but that all depends on what kind of edit you do. I don't have an example of any kind of edit that would trigger it though, so generally you should be safe.
There's actually another very good reason to start doing systemless modifications... From what @topjohnwu has been telling me it's actually going to be impossible to do manual modifications of /system starting from Android Q. I'm not even going to pretend to understand it all, but that's what he's apparently found while looking into rooting the Pixel 3/3XL on Q. It might not happen on all devices updating to Q (and knowing Samsung they'll likely come up with some sort of hybrid solution of their own), but that seems to be the future of Android modding.
arf8 said:
Thanks for that explanation, coming from SuperSu and reading the different threads and articles really does cause confusion.
So if I understand correctly, if I buy an S10, root it per the instructions i can use Root Explorer and Autorun & AdAway for example to make changes to system files and it will behave the same as SuperSu on older platforms?
You mentioned the benefits of systemless modifications is easy to revert, i guess for those that don't document changes or make a backup this is a benefit but i do both so it wouldn't make much sense for me.
But you touched on something important about sticking across system updates. If I manually edit the system files like I do in SuperSu, doesn't that render system updates obsolete because the phone is now rooted and system files have been modified and OTA updates no longer work? I assume by updates you mean manual updates and not OTA so I just want to confirm.
Another question regarding manually changing system files how does that affect SafetyNet checks and Magisk ability to Hide root from banking apps. Would these still work if I use root explorer, AutoRun & Adaway for example?
Thanks a lot
Click to expand...
Click to collapse
Generally speaking if you touch (actual) system files you'll not pass SafetyNet anymore. Neither will be able to do OTA updates. Besides that you'll have to reapply all your changes if you update system manually.
That's where Magisk comes. During boot Magisk builds a new system and apply the changes (with modules) that you want on it, not touching the actual device system files. This is the "systemless" concept.
For instance on Magisk there's an option (a module) that will let edit hosts file systemless. That way you can use AdAway without problems, its hosts file will be replacing Magisk system hosts, but not the actual device system hosts.
In a nut shell and simple words it is this way:
device boots.
Magisk gets the actual system and clone it.
Magisk apply the changes you want - modules that you have installed or manually written on appropriate folder - to this system clone only.
You never touch actual device system.
Magisk this way can hide whole root and system changes to Google and other apps.
You can update OTA or manually with no worries. All your changes will be always reapplied by Magisk over whatever actual system you have.
If you want to change system files ( systemless) you can:
write a module and add it to Magisk Manager app
or with a file manager manually put some files on a specific folder of Magisk (same place that modules do)
or use some of the already available modules that let's you do some generic stuff (for instance edit props, debloat, systemize apps,...)
But if you really want to change your actual system (NOT systemless) sure you can. You can do that under recovery. Or you can do that with regular root file manager on a specific Magisk folder that is a link (mirror) to actual system.
All those folders and how to deal with them are explained on Magisk Github readme. Search there for file structure.
Didgeridoohan said:
SuperSU is systemless root, just as Magisk is... What most get confused about is that Magisk also can do systemless system modifications.
The only time you would run into any trouble would be if you have a Magisk module mounting the same file(s) you want to edit manually. Other than that it shouldn't be any different. It's just root by different names...
You only need to use modules if you want to do systemless modifications (which has a few advantages, like being easy to revert, sticking across system updates, etc).
Click to expand...
Click to collapse
Didgeridoohan said:
Correct, I'm talking about manual updates, not OTA (which won't work with a modified /system).
Most system edits you do will still make it possible to pass SafetyNet, but that all depends on what kind of edit you do. I don't have an example of any kind of edit that would trigger it though, so generally you should be safe.
There's actually another very good reason to start doing systemless modifications... From what @topjohnwu has been telling me it's actually going to be impossible to do manual modifications of /system starting from Android Q. I'm not even going to pretend to understand it all, but that's what he's apparently found while looking into rooting the Pixel 3/3XL on Q. It might not happen on all devices updating to Q (and knowing Samsung they'll likely come up with some sort of hybrid solution of their own), but that seems to be the future of Android modding.
Click to expand...
Click to collapse
Thanks again, very useful information.
The edits will be to XML files to tweak and mod the usual CSC open up hidden features, etc so hopefully that does not trigger SafetyNet.
I did read a little about Q on and Pixel 3. I believe he achieved root on Pixel 2. If this is the case it is a sad day for those of us who like to do mods the old fashion way.
With respect to doing these mods via systemless, i understand that modules have to be created. I assume this is a straight forward process? I've never dabbled in Magisk or its modules, if i want to make a simple change to an XML file is there a tutorial on how to do so and how the modules have to be loaded?
Thanks
arf8 said:
With respect to doing these mods via systemless, i understand that modules have to be created. I assume this is a straight forward process? I've never dabbled in Magisk or its modules, if i want to make a simple change to an XML file is there a tutorial on how to do so and how the modules have to be loaded?
Thanks
Click to expand...
Click to collapse
It's quite easy to make modules, yes. @topjohnwu has it laid out pretty well in the docs:
https://topjohnwu.github.io/Magisk/guides.html
And it's all pretty well explained in the template files as well:
https://github.com/topjohnwu/magisk-module-installer
Basically you place the files in the same directory structure as you'd find them on your device's /system partition and Magisk will do the rest. And, this community is generally very helpful so if you ever need help getting a module together it's just a matter of asking. :good:
wilsonhlacerda said:
Generally speaking if you touch (actual) system files you'll not pass SafetyNet anymore. Neither will be able to do OTA updates. Besides that you'll have to reapply all your changes if you update system manually.
That's where Magisk comes. During boot Magisk builds a new system and apply the changes (with modules) that you want on it, not touching the actual device system files. This is the "systemless" concept.
Click to expand...
Click to collapse
I thought based on the response from Didgeridoohan that touching some system files does not trigger safetynet?
wilsonhlacerda said:
For instance on Magisk there's an option (a module) that will let edit hosts file systemless. That way you can use AdAway without problems, its hosts file will be replacing Magisk system hosts, but not the actual device system hosts.
In a nut shell and simple words it is this way:
device boots.
Magisk gets the actual system and clone it.
Magisk apply the changes you want - modules that you have installed or manually written on appropriate folder - to this system clone only.
You never touch actual device system.
Magisk this way can hide whole root and system changes to Google and other apps.
.
Click to expand...
Click to collapse
Thanks this makes sense, but how does one create a module for an application that modifies countless files. I get AdAway modifies the hosts file and changing xml files is easy enough to change because you know what file changed. But for a program like AutoRun Manager which changes countless program receivers, how do you make a module out of that? The application itself modifies countless files based on the changes made in the application. I don't assume everything can be done through a Systemless module or am I wrong?
wilsonhlacerda said:
You can update OTA or manually with no worries. All your changes will be always reapplied by Magisk over whatever actual system you have.
If you want to change system files ( systemless) you can:
write a module and add it to Magisk Manager app
or with a file manager manually put some files on a specific folder of Magisk (same place that modules do)
or use some of the already available modules that let's you do some generic stuff (for instance edit props, debloat, systemize apps,...)
Click to expand...
Click to collapse
Understand on the updates if changes are done via systemless.
So if i copy a system file and place it in the specific folder of Magisk is there more required to make this a module. You will have to excuse my Magisk ignorance. I'll have to look at those modules to see how they made them and see if i can apply the same to the mods I want to do on single files but the bigger issue is on applications itself that modify multiple files like Autorun, Tasker, VPN clients etc.
wilsonhlacerda said:
But if you really want to change your actual system (NOT systemless) sure you can. You can do that under recovery. Or you can do that with regular root file manager on a specific Magisk folder that is a link (mirror) to actual system.
All those folders and how to deal with them are explained on Magisk Github readme. Search there for file structure.
Click to expand...
Click to collapse
Thanks I read through the readme at Github but I had more questions than answers.
Didgeridoohan said:
It's quite easy to make modules, yes. @topjohnwu has it laid out pretty well in the docs:
https://topjohnwu.github.io/Magisk/guides.html
And it's all pretty well explained in the template files as well:
https://github.com/topjohnwu/magisk-module-installer
Basically you place the files in the same directory structure as you'd find them on your device's /system partition and Magisk will do the rest. And, this community is generally very helpful so if you ever need help getting a module together it's just a matter of asking. :good:
Click to expand...
Click to collapse
I will have to keep reading and looking at examples to make sure I understand. It seems pretty easy the way you put it by copying the file in the same directory structure but it seems like there is more to it than that?
My question is how do you apply systemless changes when it is not just a single file for example AutoRun manager that manages the Receivers of every single application in the phone which could be hundreds including system files. How do you make a module or systemless change at this point? Perhaps I should stick with what I know from the SuperSu days and let the application do its job and not upgrade to Q. Mind you I'm on a rooted S6edge with SuperSu on PingPong exploit so I'm very familiar with this phones file systems and documented all my changes but I also rely on many applications to do the changes through their front end.
arf8 said:
I will have to keep reading and looking at examples to make sure I understand. It seems pretty easy the way you put it by copying the file in the same directory structure but it seems like there is more to it than that?
Click to expand...
Click to collapse
No, that's basically it. Put the files in the proper place in the zip, flash it in the Manager or recovery and you're good to go. Or, you could even do it manually while booted by creating the module directory under /data/adb/modules_update. There you can then place the module.prop file (so that the module is recognised by the Manager) and a /system (and/or /system/vendor) directory where you put all the files you want to replace with your own. Reboot, and voila.
My question is how do you apply systemless changes when it is not just a single file for example AutoRun manager that manages the Receivers of every single application in the phone which could be hundreds including system files. How do you make a module or systemless change at this point? Perhaps I should stick with what I know from the SuperSu days and let the application do its job and not upgrade to Q. Mind you I'm on a rooted S6edge with SuperSu on PingPong exploit so I'm very familiar with this phones file systems and documented all my changes but I also rely on many applications to do the changes through their front end.
Click to expand...
Click to collapse
Does the app in question actually edit the system and/or vendor partitions? Or is it simply updating system settings that are found elsewhere? If it's the latter it doesn't really matter...
Didgeridoohan said:
No, that's basically it. Put the files in the proper place in the zip, flash it in the Manager or recovery and you're good to go. Or, you could even do it manually while booted by creating the module directory under /data/adb/modules_update. There you can then place the module.prop file (so that the module is recognised by the Manager) and a /system (and/or /system/vendor) directory where you put all the files you want to replace with your own. Reboot, and voila.
Does the app in question actually edit the system and/or vendor partitions? Or is it simply updating system settings that are found elsewhere? If it's the latter it doesn't really matter...
Click to expand...
Click to collapse
It sounds very simple the way you put it. I looked for some examples on XDA to see if I understand the changes but what threw me off for example on this one below is that the changes are being made to the build.prop file but I don't see a build.prop in any of the folders? instead there is a system.prop?
https://github.com/Magisk-Modules-Grave/voenabler
That is a great question, i don't know to be honest, I do know the app does require root to function in making changes to system files so lets assume the former instead of the latter. Does that mean Magisk can no longer "hide root" if this app is used?
How about Ti backup or more specifically flash fire? Currently I have flashfire backups for any major change I make so if something goes south i recover the entire phone using this tool. Its a beautiful tool for creating snapshots and full recovery, no config needed. I don't suppose it will work any longer with systemless option?
This is just my ignorance as I read more I have more questions, but supersu for example exploited vulnerabilities to achieve root. Is Magisk actually exploiting any vulnerabilities or simply taking advantage of the fact the bootloader is unlocked and therefore it mimics various system partitions to give you a faux root? I'm trying to understand if there is no actual vulnerability to exploit like PingPong in Lollipop for example how can I make changes manually to the system files using Root Explorer? On my S6 Edge it has a locked bootloader, but I still have root access with SuperSu via an exploit, I don't think this is possible with Magisk b/c the bootloader is locked so is Magisk really root?
thanks again for your patience but I'm sure this will come up for anyone doing from SuperSu to Magisk
arf8 said:
It sounds very simple the way you put it. I looked for some examples on XDA to see if I understand the changes but what threw me off for example on this one below is that the changes are being made to the build.prop file but I don't see a build.prop in any of the folders? instead there is a system.prop?
https://github.com/Magisk-Modules-Grave/voenabler
Click to expand...
Click to collapse
Whenever Magisk changes a prop value that you normally would find in build.prop it doesn't actually alter the file, but instead loads a new value in the old ones place. That's done with the resetprop tool and Magisk reads the system.prop file during boot to load the new values.
That is a great question, i don't know to be honest, I do know the app does require root to function in making changes to system files so lets assume the former instead of the latter. Does that mean Magisk can no longer "hide root" if this app is used?
Click to expand...
Click to collapse
As mentioned earlier, it's all a matter of what kind of edits you make... But any edit that's not been done through Magisk cannot be hidden by MagiskHide.
How about Ti backup or more specifically flash fire? Currently I have flashfire backups for any major change I make so if something goes south i recover the entire phone using this tool. Its a beautiful tool for creating snapshots and full recovery, no config needed. I don't suppose it will work any longer with systemless option?
Click to expand...
Click to collapse
There's a very real chance that Flashfire will not work. This is simply because it is practically abandoned and as far as I know @Chainfire has no interest in spending the considerable effort it would take to get it up to speed with the current Android situation.
This is just my ignorance as I read more I have more questions, but supersu for example exploited vulnerabilities to achieve root. Is Magisk actually exploiting any vulnerabilities or simply taking advantage of the fact the bootloader is unlocked and therefore it mimics various system partitions to give you a faux root? I'm trying to understand if there is no actual vulnerability to exploit like PingPong in Lollipop for example how can I make changes manually to the system files using Root Explorer? On my S6 Edge it has a locked bootloader, but I still have root access with SuperSu via an exploit, I don't think this is possible with Magisk b/c the bootloader is locked so is Magisk really root?
thanks again for your patience but I'm sure this will come up for anyone doing from SuperSu to Magisk
Click to expand...
Click to collapse
Magisk does not use any exploits and you will have to unlock your bootloader to install it. There is nothing faux about MagiskSU. It's just as real as any other root solution you'll find out there...
Didgeridoohan said:
Whenever Magisk changes a prop value that you normally would find in build.prop it doesn't actually alter the file, but instead loads a new value in the old ones place. That's done with the resetprop tool and Magisk reads the system.prop file during boot to load the new values.
Click to expand...
Click to collapse
Makes sense, i was looking for build.prop
As mentioned earlier, it's all a matter of what kind of edits you make... But any edit that's not been done through Magisk cannot be hidden by MagiskHide.
Click to expand...
Click to collapse
understand
There's a very real chance that Flashfire will not work. This is simply because it is practically abandoned and as far as I know @Chainfire has no interest in spending the considerable effort it would take to get it up to speed with the current Android situation.
Click to expand...
Click to collapse
This is probably the most disheartening to hear as I'm not sure what other alternative there is to make a complete snapshot. I assume TWRP but i'm not familiar enough with it and it does not work with the S10.
Magisk does not use any exploits and you will have to unlock your bootloader to install it. There is nothing faux about MagiskSU. It's just as real as any other root solution you'll find out there...
Click to expand...
Click to collapse
Again my ignorance is getting the better of me here so bear with me. SuperSu used the PingPong kernel exploit in Lollipop to achieve root, regardless if it had a locked/unlocked bootloader. How does Magisk actually achieve root on the S10 and provide elevated privileges if it is not exploiting a known vulnerability? Or is it exploiting a vulnerability? Is my assumption not correct that because the bootloader is unlocked, it is simply (over simplifying) make a copy of the system partitions and than gives you the impression you have root?
Very enlightening information.
Upon further reading, it looks like Magisk zip contains the su binary which gives you root access without having to exploit a vulnerability so it only works with unlocked bootloader.
arf8 said:
Again my ignorance is getting the better of me here so bear with me. SuperSu used the PingPong kernel exploit in Lollipop to achieve root, regardless if it had a locked/unlocked bootloader. How does Magisk actually achieve root on the S10 and provide elevated privileges if it is not exploiting a known vulnerability? Or is it exploiting a vulnerability? Is my assumption not correct that because the bootloader is unlocked, it is simply (over simplifying) make a copy of the system partitions and than gives you the impression you have root?
Very enlightening information.
Click to expand...
Click to collapse
arf8 said:
Upon further reading, it looks like Magisk zip contains the su binary which gives you root access without having to exploit a vulnerability so it only works with unlocked bootloader.
Click to expand...
Click to collapse
Mornin'.
Correctamundo... No exploits, no vulnerabilities, just old-fashioned root.
Besides the su binary, Magisk also needs to modify the boot image, or in the S10's and some other modern devices case the recovery image. That's why we need to have the bootloader unlocked, to flash the modified file to the boot/recovery partition.
Didgeridoohan said:
Whenever Magisk changes a prop value that you normally would find in build.prop it doesn't actually alter the file, but instead loads a new value in the old ones place. That's done with the resetprop tool and Magisk reads the system.prop file during boot to load the new values.
As mentioned earlier, it's all a matter of what kind of edits you make... But any edit that's not been done through Magisk cannot be hidden by MagiskHide.
There's a very real chance that Flashfire will not work. This is simply because it is practically abandoned and as far as I know @Chainfire has no interest in spending the considerable effort it would take to get it up to speed with the current Android situation.
Magisk does not use any exploits and you will have to unlock your bootloader to install it. There is nothing faux about MagiskSU. It's just as real as any other root solution you'll find out there...
Click to expand...
Click to collapse
Didgeridoohan said:
Mornin'.
Correctamundo... No exploits, no vulnerabilities, just old-fashioned root.
Besides the su binary, Magisk also needs to modify the boot image, or in the S10's and some other modern devices case the recovery image. That's why we need to have the bootloader unlocked, to flash the modified file to the boot/recovery partition.
Click to expand...
Click to collapse
Thanks as usual for the confirmation.
To summarize & correct me if I'm wrong, but the take away for anyone else coming from SuperSu to Magisk who read this thread, is that you will still be able to modify the system files the same old fashion way with apps like Root Explorer, caveat pre-Q (upcoming Android OS), but you give up the ability to Hide Root, which is one the key features what Magisk is known for. Otherwise you can go the modules route which is "systemless" and maintain the ability to hide root.
Does that sound right?
For those like me who are used to the old fashion way of tweaking it will take some getting used to modules and creating them. The problem or issue becomes older style apps which can't be adopted to modules is where the issue arises for systemless conversion. I learned a lot so I appreciate your feedback. If you ask me some of this info should be sticky'd somewhere.
You've almost got it... Even with most old-fashioned system modifications you should be able to hide root. The problem arises if you do some kind of edit that apps looking for root usually look for, like installing Busybox. But that specific case shouldn't be an issue, since there's a Busybox module available in the Magisk repo.
Actually, many if the things you'd normally edit after having rooted can be done through Magisk modules already available.
Debloating - use Debloater.
Systemising apps - use App Systemizer.
Editing build.prop and other prop values- use MagiskHide Props Config.
Hosts adblocking - use the built-in systemless hosts module (Manager settings) and AdAway (or your hosts editor of choice).
Etc...
Thanks, I do have busybox installed so I will use the Module for sure and all the other modules you mentioned. The concern is applications themselves like AutoRun for example and I'm sure more. But good to know the option is there to manually make changes like the old fashion way if you are not concerned about hiding or passing safetynet. I personally don't have anything I want to hide, using this method will trip knox so samsung pay on the phone is out the door. Setting up Samsung Pay on a Gear watch is a different story so that will be beneficial.
In regards to adblocking, are you saying you can use the built-in systemless hosts module and also install the Adaway apk like you normally would? Does it require a modified version of the Adaway app or the regular apk for F-Droid for example will work fine?
One final question since we touched on this earlier. Since FlashFire will not work and TWRP is not an option. What is an alternative for taking a complete snapshot of your phone for backup and recovery?
arf8 said:
In regards to adblocking, are you saying you can use the built-in systemless hosts module and also install the Adaway apk like you normally would? Does it require a modified version of the Adaway app or the regular apk for F-Droid for example will work fine?
Click to expand...
Click to collapse
Yup. Enable the option in the Magisk Manager and reboot. After that Adaway (the regular one from F-Droid) will not touch /system.
One final question since we touched on this earlier. Since FlashFire will not work and TWRP is not an option. What is an alternative for taking a complete snapshot of your phone for backup and recovery?
Click to expand...
Click to collapse
I'm assuming you mean to get the Exynos version of the S10 (since you won't be able to unlock the bootloader otherwise), so: https://twrp.me/samsung/samsunggalaxys10.html
But, I'm not the right person to ask about full snapshot backups... I never do that (haven't for years), but instead make sure that any important data (photos, etc) always is backed up to the cloud. The rest is easy to set up again after a reset (and a reset is good to do once in a while).
rooted with magisk and i'm trying to transfer a file into system/bin but when i click r/w in root explorer nothing happens and when i try to copy it from the sd card it says fail. Anyone else?
Make sure AVB verity is unchecked in magisk then reinstall from the app
qman66 said:
rooted with magisk and i'm trying to transfer a file into system/bin but when i click r/w in root explorer nothing happens and when i try to copy it from the sd card it says fail. Anyone else?
Click to expand...
Click to collapse
If the pixel 4 is any like pixel 3 with its logical partitions you'll have to use magisk to add to system. Easy way download a magisk module. Then go to /data/adb/modules then the module you installed if u need to add to /system/app you might have to add the /app set permissions then add what is wanted set permissions then restart. easy way without having to make your on module you can always go to magisk thread an learn to make a module as well either way only way I've been able to do it on Android 10 which I reverted back to pie so much better in my opinion
virtyx said:
Make sure AVB verity is unchecked in magisk then reinstall from the app
Click to expand...
Click to collapse
It's always been unchecked
billyt1 said:
If the pixel 4 is any like pixel 3 with its logical partitions you'll have to use magisk to add to system. Easy way download a magisk module. Then go to /data/adb/modules then the module you installed if u need to add to /system/app you might have to add the /app set permissions then add what is wanted set permissions then restart. easy way without having to make your on module you can always go to magisk thread an learn to make a module as well either way only way I've been able to do it on Android 10 which I reverted back to pie so much better in my opinion
Click to expand...
Click to collapse
Ok I'm willing to do this. What module do I download exactly?
qman66 said:
It's always been unchecked
Click to expand...
Click to collapse
Strange
That's the only thing I know that could cause you're issue
Android 10 requires you to so any system changes through Magisk in a "systemless" manner. As mentioned above, it needs to be in a module. If you can't do it yourself, ask for help from one of the devs. If it is a common task that others could benefit from, create a thread with the request and I am sure someone will come through...
CyberpodS2 said:
Android 10 requires you to so any system changes through Magisk in a "systemless" manner. As mentioned above, it needs to be in a module. If you can't do it yourself, ask for help from one of the devs. If it is a common task that others could benefit from, create a thread with the request and I am sure someone will come through...
Click to expand...
Click to collapse
ok does anyone know?
bump
qman66 said:
ok does anyone know?
Click to expand...
Click to collapse
What exactly is the question?
trying to transfer a file into system/bin but when i click r/w in root explorer nothing happens and when i try to copy it from the sd card it says fail.
qman66 said:
trying to transfer a file into system/bin but when i click r/w in root explorer nothing happens and when i try to copy it from the sd card it says fail.
Click to expand...
Click to collapse
I think it needs to be done "systemless" with a magisk module. Maybe if you ask @Tulsadiver nicely, he might be able to give you a template or even make you up what is needed. If so and it's possible others might have used for it you could share it.
qman66 said:
trying to transfer a file into system/bin but when i click r/w in root explorer nothing happens and when i try to copy it from the sd card it says fail.
Click to expand...
Click to collapse
You are welcome to try this. Put your file in the vrtheme/system/bin folder. Leave the system folder alone. This is untested.
qman66 said:
Ok I'm willing to do this. What module do I download exactly?
Click to expand...
Click to collapse
BusyBox is the module I always use
So like a total dumbass I didn't check the source and downloaded a module (fde.ai) from magiskroot.net . Seemed to install fine, boot took a bit longer than usual, after boot the module was not listed in Magisk manager.
Is that site safe?
Thanks!
PS I guess I'm asking opinions about the specific site...
I would investigate and open the zip and look what it changes? Did you install it in recovery or in magisk?
I don't know that site.
McFlypants said:
I would investigate and open the zip and look what it changes? Did you install it in recovery or in magisk?
I don't know that site.
Click to expand...
Click to collapse
In Magisk. I'm trying to search for added files in the system right now, nothing found so far. I have also opened the zip (just before your reply) but I'm not sure I'll be able to decipher...
krakout said:
In Magisk. I'm trying to search for added files in the system right now, nothing found so far. I have also opened the zip (just before your reply) but I'm not sure I'll be able to decipher...
Click to expand...
Click to collapse
a magisk module wouldn't change system files it'll just create a folder in data/adb/modules so look there for strange folders
jons99 said:
a magisk module wouldn't change system files it'll just create a folder in data/adb/modules so look there for strange folders
Click to expand...
Click to collapse
Only the few, known modules there. Should I assume I'm ok then?
krakout said:
Only the few, known modules there. Should I assume I'm ok then?
Click to expand...
Click to collapse
not sure it might have done something else like put a script that magisk run on boot or something maybe send me this module in pm and I'll look at what's in there
Sure thing, thanks. Also, here is the Magisk log:
jons99 said:
not sure it might have done something else like put a script that magisk run on boot or something maybe send me this module in pm and I'll look at what's in there
Click to expand...
Click to collapse
Sure thing, thanks. Also, here is the Magisk boot log: