Related
A few months ago, I upgraded to my phone to 7.1, and for some reason, my carrier disables tethering on my plan for this version. I did some poking around and found this article, which provided the fix. Namely:
setprop net.tethering.noprovisioning=true
settings put global tether_dun_required 0
The next issue I encountered was that these settings would be reverted any time I updated my ROM. Enter Magisk and stangri's tethering module, which addresses the first half of that issue flawlessly. I am, however, left with the second half of the puzzle that needs to be fixed after each flash.
I've tried placing a few simple lines in services.sh to perform a quick check to see what that setting's value is and adjust it as needed, I've tried putting scripts in various places to run on boot, and I've tried anything else I can think of, but it seems I'm not savvy enough to solve this particular problem on my own. So, I turn to you for suggestions. Can I either systemlessly set the value "tether_dun_required" to 0 via a Magisk module or use a Magisk module to place a script that'll run on boot and check the value? If it's even possible, can I get a hint on how it would be done? Thanks in advance.
You should be able to use the General Purpose Boot Scripts that @topjohnwu talks about here: https://forum.xda-developers.com/showpost.php?p=70897029&postcount=12.
Didgeridoohan said:
You should be able to use the General Purpose Boot Scripts that @topjohnwu talks about here: https://forum.xda-developers.com/showpost.php?p=70897029&postcount=12.
Click to expand...
Click to collapse
Hmm, yeah that has potential, but I suspect I'd run into the same problem I've encountered when putting the script into a module. Namely, it doesn't run. Maybe I'm missing something? For testing purposes, I've been keeping it to a single line with the actual command (settings put global tether_dun_required 0), but it doesn't actually do anything.
Note: This module won't work with v10-v11.6 since some syntax err in the mounting scripts. More info here. https://github.com/topjohnwu/Magisk/commit/624b7616d082feced71bff0474c64c1b4afd5cc0
If you're using a beta one newer than v11.6. Try this module.
Init.d Link (Magisk)
Intro
The module solves the situation when /system/etc/init.d doesn't exist, some app, let's say Kernel Auditor Beta, doesn't recognize the *.d folder provided by MagiskSU and tries to create the init.d folder by itself. So we'd better symlink one from an available *.d — post-fs-data.d, service.d or su.d.
- The module symlinks a *.d folder as init.d,
- or simply create one systemlessly.
- Init.d scripts will be run by an existing superuser — MagiskSU, phh's superuser or SuperSU — or the kernel,
- but NOT by the module itself, in case of collision with the func of kernel.
Symlink Priority:
1. /magisk/.core/service.d (Magisk v12)
2. /magisk/.core/post-fs-data.d (Magisk v11)
3. /magisk/phh/su.d
4. /su/su.d
5. /magisk/.core/post-fs-data.d (Magisk v12)
6. /magisk/.core/service.d (Magisk v11)
The last resort will be the creation of a systemless init.d folder.
NOTE: init.d will be symlinked only if available *.d foler exists.
Installation
Flash it in RECOVERY ONLY.
Credit
https://github.com/laggardkernel/init.d-link by laggardkernel
Changelog
v1.3
- Fix mount of su.img
v1.2
- Update to module template v3
- Add link target info into module.prop.
- Reorder init.d link priority for Magisk v12:
1. /magisk/.core/service.d (Magisk v12)
2. /magisk/.core/post-fs-data.d (Magisk v11)
3. /magisk/phh/su.d
4. /su/su.d
5. /magisk/.core/post-fs-data.d (Magisk v12)
6. /magisk/.core/service.d (Magisk v11)
- There is also a post-fs-data branch keep post-fs-data.d at high priority by force.
Reserved.
How to use this module?
ngtung84 said:
How to use this module?
Click to expand...
Click to collapse
Just download the zip and flash it in your recovery. Then the module will create a /system/etc/init.d link directing to /magisk/.core/post-fs-data.d SYSTEMLESS. This will solve the pain that some apps, like Kernel Manager beta, don't recognize Magisk's post-fs-data.d and create a init.d itself to put their init scripts.
laggardkernel said:
Just download the zip and flash it in your recovery. Then the module will create a /system/etc/init.d link directing to /magisk/.core/post-fs-data.d SYSTEMLESS. This will solve the pain that some apps, like Kernel Manager beta, don't recognize Magisk's post-fs-data.d and create a init.d itself to put their init scripts.
Click to expand...
Click to collapse
I have some scripts. Can I put them into /system/etc/init.d created by this module?
You make some really nice little modules. I really believe you should submit them to the repo... It's gonna need some updating to the latest template and maybe also some updates for v12 though. From the v12 release notes:
It is recommended to run most scripts in the service mode (service.d/service.sh), except a. mounting files; b. patching system props; c. time critical operations
Click to expand...
Click to collapse
Didgeridoohan said:
You make some really nice little modules. I really believe you should submit them to the repo... It's gonna need some updating to the latest template and maybe also some updates for v12 though. From the v12 release notes:
Click to expand...
Click to collapse
Gotta disagree with you here. This module is ALL OVER THE PLACE. The code in the startup scripts is doing TONS of unadvertised stuff:
There is code related to @ahrion Dolby Atmos (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L108) that will potentially put your device into Permissive Mode without telling you.
No idea what this code is doing, but certainly doesn't relate to init.d symlinks (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L93).
Appears to attempt to install a non-existent APK called '*.apk' with package name '*.*.*' (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L68).
And that's all on every startup.
I would be careful with this module...
Jman420 said:
Gotta disagree with you here. This module is ALL OVER THE PLACE. The code in the startup scripts is doing TONS of unadvertised stuff:
There is code related to @ahrion Dolby Atmos (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L108) that will potentially put your device into Permissive Mode without telling you.
No idea what this code is doing, but certainly doesn't relate to init.d symlinks (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L93).
Appears to attempt to install a non-existent APK called '*.apk' with package name '*.*.*' (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L68).
And that's all on every startup.
I would be careful with this module...
Click to expand...
Click to collapse
Hm... Thank's for pointing that out. I'm not at all fluent enough in scripting to have caught that without some serious scrutiny, and I've not had the time for that today.
Perhaps we'll get an explanation from @laggardkernel about what's going on.
Didgeridoohan said:
Hm... Thank's for pointing that out. I'm not at all fluent enough in scripting to have caught that without some serious scrutiny, and I've not had the time for that today.
Perhaps we'll get an explanation from @laggardkernel about what's going on.
Click to expand...
Click to collapse
Best guess i can come up with is that stuff is left over from other experiments. He seems to be using the same repo for multiple projects and separating them with branches. That seems to have caused some cross contamination in his branches.
As a general development rule you should have one project/solution per repo. Your branches usually represent new features for the project.
Jman420 said:
Best guess i can come up with is that stuff is left over from other experiments. He seems to be using the same repo for multiple projects and separating them with branches. That seems to have caused some cross contamination in his branches.
As a general development rule you should have one project/solution per repo. Your branches usually represent new features for the project.
Click to expand...
Click to collapse
If you look in config.sh you'll see that the module isn't even using post-fs-data.sh (POSTFSDATA=false). And the files on GitHub doesn't match the files in the module zip. Look at update-binary in the zip and then on GitHub. In the zip you'll find the symlinking, but not on GitHub...
So yeah, I guess we're talking about a bunch of code left over from previous experiments.
Jman420 said:
Gotta disagree with you here. This module is ALL OVER THE PLACE. The code in the startup scripts is doing TONS of unadvertised stuff:
There is code related to @ahrion Dolby Atmos (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L108) that will potentially put your device into Permissive Mode without telling you.
No idea what this code is doing, but certainly doesn't relate to init.d symlinks (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L93).
Appears to attempt to install a non-existent APK called '*.apk' with package name '*.*.*' (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L68).
And that's all on every startup.
I would be careful with this module...
Click to expand...
Click to collapse
I took all of that setenforce stuff out of my script. And in my release notes it clearly stated when I release v1.2 that I added the script to AudModLib. However I removed it because I found a workaround in v1.3.
With Audmodlib we have only audio server media server, and system prop contextd permissible for ONLY system and priv apps. Which is what I had to replace with the setenforce stuff.
He's not doing anything shady when looking at the code, it looks like he was following my example. I would submit a git issue to tell him to update the mod.
Hope this clears things up man.
Jman420 said:
Gotta disagree with you here. This module is ALL OVER THE PLACE. The code in the startup scripts is doing TONS of unadvertised stuff:
There is code related to @ahrion Dolby Atmos (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L108) that will potentially put your device into Permissive Mode without telling you.
No idea what this code is doing, but certainly doesn't relate to init.d symlinks (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L93).
Appears to attempt to install a non-existent APK called '*.apk' with package name '*.*.*' (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L68).
And that's all on every startup.
I would be careful with this module...
Click to expand...
Click to collapse
1. Look into the config.sh;
2. Post-fs-data.sh, service.sh are NOT enabled;
3. Post-fs-data.sh, service.sh will NOT be copied to your device.
4. I use a template with some additional features myself. Maybe I'm too laggard to clean up unused codes. But I'm sure I commented out, disabled all unnecessary parts.
laggardkernel said:
Maybe I'm too laggard to clean up unused codes.
Click to expand...
Click to collapse
Ha ha!
But yeah, like it shows, you're gonna scare some people leaving it in there.
True, you'll only get scared if you don't look at the entire thing, but still...
laggardkernel said:
Maybe I'm too laggard to clean up unused codes.
Click to expand...
Click to collapse
hehehe, i see what you did there.
laggardkernel said:
1. Look into the config.sh;
2. Post-fs-data.sh, service.sh are NOT enabled;
3. Post-fs-data.sh, service.sh will NOT be copied to your device.
4. I use a template with some additional features myself. Maybe I'm too laggard to clean up unused codes. But I'm sure I commented out, disabled all unnecessary parts.
Click to expand...
Click to collapse
Yeah, deeper review does show that those scripts aren't installed or used. But leaving them there makes reviewing the module much harder since you have to go looking for that 1 flag which indicates they aren't used. As a developer if I see code in a script I expect that it's meant to be executed and a reviewer won't necessarily know which piece is correct (the flag disabling the script or the script itself).
The module is definitely benign, but on a quick surface review the dead code seems strange in the context of the module itself. Just a suggestion, but cleaning up that dead code would make the module easier to review and avoid having that code get executed accidentally or misinterpreted.
Didgeridoohan said:
But yeah, like it shows, you're gonna scare some people leaving it in there.
True, you'll only get scared if you don't look at the entire thing, but still...
Click to expand...
Click to collapse
Even a full review would raise some concerns with me. Mainly which is correct; having the script disabled or enabled. That concern can only be addressed through a discussion like this. A full review would make me feel a bit more secure since the script isn't executed, but would make me question whether the full functionality of the module is actually in place.
@laggardkernel This is all good work, so I hope you don't take any of this the wrong way. I just happen to do development (more accurately software engineering) as a career and see this kind of stuff all over the place in enterprise software and it makes my eyes bleed every time I see it. Now that I've gotten into a cyber security role I'm even more sensitive to this stuff since they end up constituting security holes (either maliciously or accidentally, usually the latter).
Flash it from recovery, it say Error... because there is already has init.D folder ?
So i have to delete the folder first ?
Vuska said:
Flash it from recovery, it say Error... because there is already has init.D folder ?
So i have to delete the folder first ?
Click to expand...
Click to collapse
If you already have init.d support you don't need this module.
And if you want proper help, where's your recovery log?
Does this module already support Magisk 13.1?
Magisker said:
Does this module already support Magisk 13.1?
Click to expand...
Click to collapse
Not yet. I haven't migrated to v13+ and I'm still waiting for the update of the all-in-one wiki.
laggardkernel said:
Not yet. I haven't migrated to v13+ and I'm still waiting for the update of the all-in-one wiki.
Click to expand...
Click to collapse
The template v4 is already there tho
https://github.com/topjohnwu/magisk-module-template
magisk 14 does not mount magisk.img. It creates a different set up. There is no magisk folder at root containing post-fs-data.d and service.d folders. If they are not there in magisk 14, where are the scripts to be placed for running at boot. Anybody could help on this.
Hi Guys!
Recently I hope to use Tasker to do something automatically when the phone is turned on, but I found that Tasker can't start when my phone is turned on but locked.
So I wrote an Android app that uses the shell to enter the password at boot time, but even if I used DirectBoot mode(developer.android.com/training/articles/direct-boot) it still doesn't work.
So I tried to write a module using Magisk, and automatically entered the password when I booted. This time I raised succeeded.
I think there may be other people who have the same needs as me, so I do a function that can customize the password for others to use.
At first we need install AutoInputBootPinManager(github.com/ZeroingIn/AutoInputBootPinManager) to configure your PIN. The application needs to grant root privileges.
Next we download and install this module(github.com/ZeroingIn/AutoInputBootPin) and reboot phone to enjoy it.
If you have any questions, please submit an issue.
Thank you all.
Interesting idea.
There are several modules available that use a shell script UI, run through a terminal emulator, to change settings for the module. App systemizer, Unified Hosts Adblock, MagiskHide Props Config, Energized Protection, etc. Take a look at them for inspiration.
A couple of things:
An explanation of the command in post-fs-data.sh might be a good idea.
Code:
supolicy --live "allow untrusted_app default_android_service service_manager find"
And, why are you setting this prop? As far as I can tell that's for the app Brevent...
Code:
log.tag.BreventServer=DEBUG
Didgeridoohan said:
Interesting idea.
There are several modules available that use a shell script UI, run through a terminal emulator, to change settings for the module. App systemizer, Unified Hosts Adblock, MagiskHide Props Config, Energized Protection, etc. Take a look at them for inspiration.
A couple of things:
An explanation of the command in post-fs-data.sh might be a good idea.
Code:
supolicy --live "allow untrusted_app default_android_service service_manager find"
And, why are you setting this prop? As far as I can tell that's for the app Brevent(play.google.com/store/apps/details?id=me.piebridge.brevent&hl=en)...
Code:
log.tag.BreventServer=DEBUG
Click to expand...
Click to collapse
Thank you very much for your advice, I will try it. Any progress, I will be posted in this post.
The setting of this prop is my mistake, and you have carefully discovered this bug that I have not noticed.
Because I was a beginner to make the Magisk module, I didn't see the Magisk Module Template(github.com/topjohnwu/magisk-module-template) at first, so I wrote it with reference to the Privileged Api Booter(github.com/Magisk-Modules-Repo/magisk-privileged-api-booter).I will fix this problem right away.
ZeroingIn said:
Thank you very much for your advice, I will try it. Any progress, I will be posted in this post.
The setting of this prop is my mistake, and you have carefully discovered this bug that I have not noticed.
Because I was a beginner to make the Magisk module, I didn't see the Magisk Module Template(github.com/topjohnwu/magisk-module-template) at first, so I wrote it with reference to the Privileged Api Booter(github.com/Magisk-Modules-Repo/magisk-privileged-api-booter).I will fix this problem right away.
Click to expand...
Click to collapse
In that case you have a couple of more things to rectify. The first part I mentioned, about the post-fs-data.sh script is also from that module. So, I'm going to assume you do not need it for your purpose. I'd suggest removing that as well... And after you've done that, you should also go in and edit config.sh and change PROPFILE and POSTFSDATA from true to false, because you're not using them anymore. From the looks of it you're only using service.sh, so only LATESTARTSERVICE needs to be active.
Didgeridoohan said:
In that case you have a couple of more things to rectify. The first part I mentioned, about the post-fs-data.sh script is also from that module. So, I'm going to assume you do not need it for your purpose. I'd suggest removing that as well... And after you've done that, you should also go in and edit config.sh and change PROPFILE and POSTFSDATA from true to false, because you're not using them anymore. From the looks of it you're only using service.sh, so only LATESTARTSERVICE needs to be active.
Click to expand...
Click to collapse
You are right, I modified it with reference to the template.Thanks a lot.
Are you going to.update this at all?
I have a bug if you are...
I only have 1 pin... But all 3 fire... Since there's no way to stop them without deleting it from the script
Hi! Is there a way to enable/disable a Magisk Module with a script?
I'm using a Xiaomi Mi A1 and I would like to use Measure App. It works only the first time (or so) I disable/enable the module to change device fingerprint. Is it possible to run a script that disables and re-enables the module at boot? Thanks.
Disabling and then enabling a module takes a reboot between every action. It can't be done in one boot...
But, I suspect that this might not actually be the solution you're looking for. Provide more details, please. What module are you talking about? What functionality is it that you're after? What is it that doesn't work? Logs. Etc...
Didgeridoohan said:
Disabling and then enabling a module takes a reboot between every action. It can't be done in one boot...
But, I suspect that this might not actually be the solution you're looking for. Provide more details, please. What module are you talking about? What functionality is it that you're after? What is it that doesn't work? Logs. Etc...
Click to expand...
Click to collapse
Thanks for your quick reply.
I'm using a module that changes device fingerprint to Pixel2 to be able to use Measure app. Measure works properly only one or two times after enabling the module. Then it stops finding available surfaces until I disable, re-enable module and reboot. The same problem occurs if I use your MagiskHide Props Config (great work btw). After disabling-enabling-rebooting Measure works properly again. If I simply reboot without touching the module Measure app starts but it can't find any suitable surface.
Here's a logcat, hope it helps.
Do I understand you correctly? You're talking about disabling/enabling the module in the Magisk Manager, right? And disabling and then enabling right after, with no reboot in-between? If so, that makes no sense, because the only thing disabling the module does is to create a file in the module folder named "disable". On the next boot, Magisk will detect this file and won't load the module. Enabling the module simply deletes the file again, and on the next boot the module will load (since there's no "disable" file)..
I really do believe there's something else going on...
Didgeridoohan said:
Do I understand you correctly? You're talking about disabling/enabling the module in the Magisk Manager, right? And disabling and then enabling right after, with no reboot in-between? If so, that makes no sense, because the only thing disabling the module does is to create a file in the module folder named "disable". On the next boot, Magisk will detect this file and won't load the module. Enabling the module simply deletes the file again, and on the next boot the module will load (since there's no "disable" file)..
I really do believe there's something else going on...
Click to expand...
Click to collapse
I know it makes no sense but it works that way for me and for other people with the same phone/module. I was trying to find a way to automate this process at every boot so that at least the first time (after every boot) I'll use Measure it will work well. Otherwise log keep saying "Received image measurement before corresponding IMU measurement" then app crashes.
I'm 100% sure that it's got nothing to do with creating and deleting a file named "disable" in the module directory... There's something else going on, it's just that noone's figured out what.
Didgeridoohan said:
I'm 100% sure that it's got nothing to do with creating and deleting a file named "disable" in the module directory... There's something else going on, it's just that noone's figured out what.
Click to expand...
Click to collapse
I really don't know but I can reproduce this bug every time. How can I create and delete this file? Is there a path where I can put this file or magisk.img can be mounted? Sorry if it sounds ridiculous, I am not a developer...
If you really want to try you can just place a boot script in post-fs-data.d that creates and deletes the file in the module directory. Something like:
Code:
#!/system/bin/sh
touch <path_to_module>/disable
rm -f <path_to_module>/disable
The path to the module depends on what version of Magisk you're using (although there's backwards compatibility symlinks in place). In the current stable release the modules are in /sbin/.magisk/img, but the current code (in the Canary builds and in future releases) have moved this to /data/adb/modules.
Perfectly working, thanks. I used macrodroid to run the scripts you gave me after every boot.
Hello everyone, I try to create a module to replace my build.prop because I do not please change it (system play only).
I do not understand much to magisk modules, can someone make me the module or I can put my build,prop please?
Or if impossible to replace the buil.prop by magisk, can be add the line :
persist.debug.wfd.enable=1
Thank you I've been trying since yesterday and I really can't do it so it seems to be simple
You don't need a module to do that.
Edit: For future reference... I've been reminded that persist props are, well, persistent. No boot script is needed, just run the resetprop command and the value will remain set even across reboots. Until a new value is set, of course.
Simplest way is to just use a boot script and the resetprop tool:
Code:
resetprop persist.debug.wfd.enable 1
Or if you really want to use a module you'll just have to add the line to system.prop and nothing else:
Code:
persist.debug.wfd.enable=1
Or you could use MagiskHide Props Config and the custom prop feature.
And Magisk doesn't actually alter the build.prop file:
https://github.com/Magisk-Modules-R...etting-a-custom-prop-or-removing-a-prop-value
Thank you for this quick response. I'm going to try to figure out how to do this script because I really don't know all this
Hi, I solved the problem with the module activated and in termux
Code:
su
Props resetprop persist.debug.wfd.enable 1
Now he finds the TV but restarts the phone as soon as he connects on it
If you're having problems creating a boot script it might be easier to use the MagiskHide Props Config module. It'll do it for you.
Hi, I aI think I did it. Here's how to do it with the installed module magiskhide props
Code:
su
Props resetprop persist.debug.wfd.enable=1
He finds me the TV, but as soon as he connects to the phone restarts is there a way to solve this problem?
chuppito said:
Hi, I aI think I did it. Here's how to do it with the installed module magiskhide props
Code:
su
Props resetprop persist.debug.wfd.enable=1
He finds me the TV, but as soon as he connects to the phone restarts is there a way to solve this problem?
Click to expand...
Click to collapse
I'm not sure what you're doing there, but that's not right...
If you're gonna use MagiskHide Props Config, just run
Code:
su
props
And then pick the "Add/edit custom props" menu (#4). Follow the on-screen instructions to set your prop.
If you're going to use resetprop as a standalone tool you run:
Code:
su
resetprop persist.debug.wfd.enable 1
That will only survive until a reboot though, which is why you would have to put the line in a service.d boot script if you want it to be permanent.
Edit: For future reference... I've been reminded that persist props are, well, persistent. No boot script is needed, just run the resetprop command and the value will remain set even across reboots. Until a new value is set, of course.
If I use props, I have no options
If I use setprop it doesn't tell me anything
Edit :
With props where I have more options I managed to do.
It was already on 1 while it started again several times.
I watch as soon as I get home if it connects or restarts as soon as it tries
The TV is well detected but as soon as I try to connect, the phone makes a small reboot
chuppito said:
If I use props, I have no options
If I use setprop it doesn't tell me anything
Edit :
With props where I have more options I managed to do.
It was already on 1 while it started again several times.
I watch as soon as I get home if it connects or restarts as soon as it tries
Click to expand...
Click to collapse
Does your edit mean you figured it out? If you didn't, here goes:
From your first screenshot, showing the props module ui, it tells you to "Enter the prop to set". So if you enter persist.debug.wfd.enable you'll get to the next screen where you can enter your desired value (and also see what the current value, if any, is).
The second screenshot is exactly as it should be. You're not supposed to get any feedback if it works.
About your other issues, I have no idea...
Yes I was able to understand how it works. I found a post for other problems on xda, if I understand, google deleted files last July to make this trick obsolete and sell its chomecast