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.
Related
After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy
sepolicy patch is here: https://github.com/PureNexusProject...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a
Stickied.
sorry to be that guy, but how does this affect the average joe?
does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?
WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.
Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.
Chainfire said:
Stickied.
Click to expand...
Click to collapse
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
BeansTown106 said:
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
Click to expand...
Click to collapse
There is no such thing now as "all current root apps working".
If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.
What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.
As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")
Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.
Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):
Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.
In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.
Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.
A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy
as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Chainfire said:
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?
BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688
Thank you for your work!
Link in OP its no longer working...
Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.
I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.
It reminds me of Korean dramas ,
Please note, this requires SELinux Permissive (included init.d script/instructions for PHH). It will not work on Enforcing, even with supolicy (I've tried. If anyone has an idea how to get it working with "soundserver" and setting supolicy "read write execute", please let me know)
Setting SELinux to Permissive is a security risk.
ViPER4Android for Mate 9
Slightly modified guitardedhero script.
Contains "Kernel" and "Profile" for V4A from auras76 kang rom
Note:
The following files are backed up automatically so you can easily revert with the removal script:
/system/lib/soundfx/libeffectproxy.so -> /system/lib/soundfx/libeffectproxy.so.bak
/system/etc/audio_effects.conf -> /system/etc/audio_effects.conf.bak
/vendor/etc/audio_effects.conf -> /vendor/etc/audio_effects.conf.bak
If those .bak files are not found the removal script won't run (to prevent running it without V4A installed, it would simply just remove the files leaving you with no files at all.)
It does not edit audio_policy.conf as it doesn't have the deep_buffer section in it, so no point in having it edited.
Requirements:
SuperRoot/SuperSU (No verity is probably needed as we're modifying both /system and /vendor)
A way to set SELinux to Permissive (SuperSU init.d/phh 'su --init' or SELinuxToggler, see 'Alternative'.)
If you're on Magisk use the V4A module instead
For SuperSU
If you use the one posted above
Simply flash the zip in TWRP and you should be good to go. It copies the 00selinux script directly to /system/etc/init.d/ and runs at boot so you'll have SELinux set to Permissive after flashing.
For PHH su
Flash the zip in TWRP, boot up fully.
Now open a terminal and issue the command
Code:
su --init /system/etc/init.d/00selinux
Then reboot.
To remove the phh init use 'su --init !/system/etc/init.d/00selinux'.
For Magisk
Search for Viper4Android in the Downloads section in Magisk Manager, it's a module so no need to download anything in this thread
Alternative:
(You still need root for this but no init script.)
SELinuxSwitch by @Ibuprophen
Download:
ViPER4Android 2.5.0.5
Dropbox Mirror
Removal script download:
Removal script
Removal script Dropbox Mirror
Thanks to V4A team,
guitardedhero for his script,
auras76 for the profiles/makers of said profiles,
Ibuprofen for The SELinux Switch.
@ante0 bro thanks for porting it... have a question, we have to mount system in terminal for writting in system partition,,, can i use init to mount system rw for all time so that i dont need to give command everytime
HassanMirza01 said:
@ante0 bro thanks for porting it... have a question, we have to mount system in terminal for writting in system partition,,, can i use init to mount system rw for all time so that i dont need to give command everytime
Click to expand...
Click to collapse
Yes, if you use supersu, make a script in /system/etc/init.d/
Code:
#!/system/bin/sh
mount -o rw,remount /system
Make sure it runs after any other scripts if they remount system to read only. Scripts are loaded in order, so name it accordingly.
If you use phh, place script where you want and from a terminal
Code:
su --init /path/to/script
I wanna put all this in my Kernel... Or boot.img...
I have root in my kernel using phh superuser... I dont want to add anything in system by myself, i want that a zip should do it... Will be best if kernel did all this... In MM, we dont need to do rw ourself, in N we needed...
Also, am not a dev, just a pro member, know how to edit and understand commands etc...
May I ask whats the difference between this and Viper4Arise.
HassanMirza01 said:
I wanna put all this in my Kernel... Or boot.img...
I have root in my kernel using phh superuser... I dont want to add anything in system by myself, i want that a zip should do it... Will be best if kernel did all this... In MM, we dont need to do rw ourself, in N we needed...
Also, am not a dev, just a pro member, know how to edit and understand commands etc...
Click to expand...
Click to collapse
I sent you a pm instead
ante0 said:
I sent you a pm instead
Click to expand...
Click to collapse
Sure bro... Am waiting... And i have somehow injected phh superuser r275 in boot.img... I will be thankful if u tell me the whole correct procedure to inject files of superuser zip in boot.img.... By flashing superuser r275 on stock boot, we can have root but on that root, titanium like apps didnot work :/
SlyUK said:
May I ask whats the difference between this and Viper4Arise.
Click to expand...
Click to collapse
Arise is based off of V4A, but with their own audio effects and a modified V4A app.
https://www.reddit.com/r/androidapps/comments/5dpvcz/slug/da6ux9k
SlyUK said:
May I ask whats the difference between this and Viper4Arise.
Click to expand...
Click to collapse
It's just a skin difference. Viper4Arise is themed by an arise member. The only difference is the theme.
ante0 said:
Arise is based off of V4A, but with their own audio effects and a modified V4A app.
https://www.reddit.com/r/androidapps/comments/5dpvcz/slug/da6ux9k
Click to expand...
Click to collapse
Hello,
Will V4A work on P9, P9 plus and P9 lite if we flash those files?
Coolyou said:
Hello,
Will V4A work on P9, P9 plus and P9 lite if we flash those files?
Click to expand...
Click to collapse
I don't know. But I don't see why it wouldn't.
Backup system and try.
You'll have to use the phh init script though as I don't think supersu works with P9 on emui5?
Edit: actually, if your audio_effects.conf file is not in /system/etc/ or /vendor/etc/ the script needs to be modified. And if your audio_policy.conf contains the deep_buffer section.
You guys can use this app for switching SELinux to Permissive - https://forum.xda-developers.com/android/apps-games/app-selinuxtoggler-t3574688
It was featured a few days back on XDA blog, hope it will help the users.
DJBhardwaj said:
You guys can use this app for switching SELinux to Permissive - https://forum.xda-developers.com/android/apps-games/app-selinuxtoggler-t3574688
It was featured a few days back on XDA blog, hope it will help the users.
Click to expand...
Click to collapse
Oh, he finally released it
I'll update OP, thanks for heads-up.
Works like a charm, thanks
hi..I'm on aura's rom. and I can't install drivers. can you please teach me how can I make it work..thanks
s2pfie said:
hi..I'm on aura's rom. and I can't install drivers. can you please teach me how can I make it work..thanks
Click to expand...
Click to collapse
assuming everything else but the driver is installed,
simply download Viper4android_2.5.0.5_mate9.zip, extract.
go to customize/lib, rename libv4a_fx_jb_NEON.so to libv4a_fx_jb_ics.so
copy it to your phone.
Use a root file manager and copy and paste to /system/lib/soundfx/libv4a_fx_jb_ics.so.
And set permissions of that file to 0644 (RW-R--R--).
Then reboot and open up viper4android again and see if still complains.
If it doesn't, go to "hamburger" menu in V4A and tap on Driver Status, it should say Status: Normal. If it says abnormal something else is wrong.
ante0 said:
assuming everything else but the driver is installed,
simply download Viper4android_2.5.0.5_mate9.zip, extract.
go to customize/lib, rename libv4a_fx_jb_NEON.so to libv4a_fx_jb_ics.so
copy it to your phone.
Use a root file manager and copy and paste to /system/lib/soundfx/libv4a_fx_jb_ics.so.
And set permissions of that file to 0644 (RW-R--R--).
Then reboot and open up viper4android again and see if still complains.
If it doesn't, go to "hamburger" menu in V4A and tap on Driver Status, it should say Status: Normal. If it says abnormal something else is wrong.
Click to expand...
Click to collapse
thanks bro but still an error occurred..still abnormal
update:
just flashed your zip now its normal..thank you
@ante0, I just wanted to give you a quick heads up...
There's a new app (currently being beta tested) that will supercede/replace The SELinux Toggler....
It's a new app called "The SELinux Switch". Though, it will look like "The SELinux Toggler" but, I had to recreate, pretty much, the whole app.
The reason i had to do this is, primarily, to completely sever it from the older package name (or Installation Directory) that was also being used by the "SELinuxModeChanger" app.
I also had made some minor enhancements and a few compatibility improvements but, there's still some more improvements to be made.
In addition, the app has been passing the beta testing extremely well (thankfully after about 6 +/- months into it) and it should be released soon but, when the app has completed the beta testing and, ready for its debut, it will be released under a whole new thread.
Thank you all for your time, understanding and, especially, your support for my development.
Please let me know if you have any questions or concerns.
______________
PLEASE NOTE: I welcome any member to help with further valuable information/clarification for any of my posts.
Has anybody used the ARISE aroma installer (twrp flashable zip)? I've used it on a few other devices, coming to the M9 from a Le Pro 3 and it works nice and easy and patches selinux permanently. It seems the way Huawei does things is much different though, so I'd be suprised if it works as easily as on other phones.
In the end, it's just installing 2.5.0.5 anyway with a few other tweaks and a whole bunch of IRS response profiles. So that part's not very different.
Just a quick heads-up @ante0...
The SELinux Toggler has now Officially been Discontinued for the launching of the new app...
[APP][TOOL][4.2+][OFFICIAL]The SELinux Switch by Ibuprophen
Those of you who currently has The SELinux Toggler, and want to switch to The SELinux Switch, please be sure to read the OP for instructions.
Thank you ALL!
______________
PLEASE NOTE: I welcome any member to help with further valuable information/clarification for any of my posts.
Deprecated - Use the New ViPER4Android v2.7:
GO TO THE THREAD LINKED ABOVE. You don't need to flash any zips. Just install it as a regular apk, allow it to install the drivers, and you're good to go.
For magisk users: I made a zip on the repo that includes the original vdc's and my profile converter (will convert your old profiles to the new and better format).
For rootless users: I made a zip to install drivers and such
Zips can be found here
ALL SUPPORT QUESTIONS FOR 2.7 SHOULD BE AT THE THREAD ABOVE.
This is ViPER4Android FX and Xhifi Unity installers
These installers utilize my Unified installer that can install on Magisk OR System if Magisk is not detected (with Pixel support).
Credits of Originality:
- @zhuhang (Official Thread)
- @Osm0sis
- Viper's Audio (Official blog)
- @ViPER520
- @Team_DeWitt
Special Instructions:
If you already know which original v4a you want to use, just add 'old' for 2.3.4.0, 'mid' for 2.4.0.1, 'new' for 2.5.0.5, or 'mat' for material to the zipname prior to flashing.
If you already know if you want it installed as a user or system app, add "uapp" for user app or "sapp" to system app to zipname.
If you already know if you want to apply the libstdc++.so lib workaround, add "lib" or "nlib" to zipname (note that there are some devices that are already known to require it and so they'll apply workaround regardless of choice)
If you already know if your device/rom requires the v4a open/close/fc audioserver workaround, add "ocw" to zipname. Otherwise, add "nocw" to zipname
To skip volkeys (if your device isn't compatible with them), add "novk" to the zipname. Note that if you don't specify the above, defaults will be applied which are: sapp, new
Make sure there are no spaces in the zipname
Audio Mod Troubleshooting Guide
Downloads
XDA:DevDB Information
ViPER4Android FX Legacy/XHiFI [Unity], App for the XDA Community Apps
Contributors
ahrion, Zackptg5
Version Information
Status: Stable
Current Stable Version: v4.4
Stable Release Date: 2019-08-11
Created 2019-01-18
Last Updated 2020-01-01
great!
Hi, tried your two modules you've posted on my Nexus 6P stock ROM. March update. Both causing bootloop and using the uninstaller provided doesn't help. Have to use mount Magisk then go to file explorer in TWRP recovery and delete the modules from Magisk folder.
kartikb said:
Hi, tried your two modules you've posted on my Nexus 6P stock ROM. March update. Both causing bootloop and using the uninstaller provided doesn't help. Have to use mount Magisk then go to file explorer in TWRP recovery and delete the modules from Magisk folder.
Click to expand...
Click to collapse
Hmm. This is probably a kernel or magisk limitation with your rom. Are you running 11.6? Try to run it without the deep_buffer Remover because this is probably what bootloops your phone. It's only necessary when you've NEED it, otherwise it may cause adverse effects. Just install V4A and see if it works.
Currently magisk still has limited boot.img compatibility which causes so.e mods to not work properly or bootloops when it's not the mod itself.
ahrion said:
Hmm. This is probably a kernel or magisk limitation with your rom. Are you running 11.6? Try to run it without the deep_buffer Remover because this is probably what bootloops your phone. It's only necessary when you've NEED it, otherwise it may cause adverse effects. Just install V4A and see if it works.
Currently magisk still has limited boot.img compatibility which causes so.e mods to not work properly or bootloops when it's not the mod itself.
Click to expand...
Click to collapse
Hi, I'm on 11.6. I've tried both modules on their own and they both have caused boot loops unfortunately.
Thanks anyway..
kartikb said:
Hi, I'm on 11.6. I've tried both modules on their own and they both have caused boot loops unfortunately.
Thanks anyway..
Click to expand...
Click to collapse
Magisk limitation. @topjohnwu is always improving magisk. I do recommend may e trying another kernel for your device which may help compatibility.
Gave this module a go, and: it's a no go... Will not boot on my Nexus 6 running Vanilla ROM 7.1.1_r26, Franco Kernel r65 and Magisk v.11.6 - MagiskSU.
After flashing uninstaller the device still doesn't boot. Had to manually remove audmodlib from /magisk in TWRP to make it boot again. And it's in audmodlib the problem is. I did a quick test where I removed audmodlib after installation (kept v4afx in place) and it booted right up (with a non-functioning module, obviously).
Attaching installation and uninstallation recovery logs. Unfortunately I'm not at a computer with ADB, otherwise I would have captured a logcat of boot for you. Maybe later...
Didgeridoohan said:
Gave this module a go, and: it's a no go... Will not boot on my Nexus 6 running Vanilla ROM 7.1.1_r26, Franco Kernel r65 and Magisk v.11.6 - MagiskSU.
After flashing uninstaller the device still doesn't boot. Had to manually remove audmodlib from /magisk in TWRP to make it boot again. And it's in audmodlib the problem is. I did a quick test where I removed audmodlib after installation (kept v4afx in place) and it booted right up (with a non-functioning module, obviously).
Attaching installation and uninstallation recovery logs. Unfortunately I'm not at a computer with ADB, otherwise I would have captured a logcat of boot for you. Maybe later...
Click to expand...
Click to collapse
The only real thing in audmodlib is could be is service.sh or system.prop otherwise it would be the vendor file, which would mean that for some reason 11.6 is bugged for vendor file mounting. Try installing and remove those ONLY and and see if it fixes it.
If that fixes it then it's one of those two. And if you're cool can you see which one it is exactly.
ahrion said:
The only real thing in audmodlib is could be is service.sh or system.prop otherwise it would be the vendor file, which would mean that for some reason 11.6 is bugged for vendor file mounting. Try installing and remove those ONLY and and see if it fixes it.
If that fixes it then it's one of those two. And if you're cool can you see which one it is exactly.
Click to expand...
Click to collapse
There has been an issue with vendor mounting in Magisk, but I believe that was for devices with separate vendor partitions (Nexus 6P, Nexus 5X, etc). I haven't seen any commits on GitHub about it though (although I haven't been keeping that close attention), so I don't know if it's been fixed.
I did find the culprit though: it's system.prop. With that file removed from /magisk/audmodlib my device booted up just fine.
kartikb said:
Hi, I'm on 11.6. I've tried both modules on their own and they both have caused boot loops unfortunately.
Thanks anyway..
Click to expand...
Click to collapse
If you wanna try this is my module for Nexus phones. I use this in my Nexus 5X Stock and PureNexus
https://www.androidfilehost.com/?fid=529152257862713260
Sry ahrion for use your thread
Seyaru said:
If you wanna try this is my module for Nexus phones. I use this in my Nexus 5X Stock and PureNexus
https://www.androidfilehost.com/?fid=529152257862713260
Sry ahrion for use your thread
Click to expand...
Click to collapse
You are literally advertising your mods in everyone's threads. Stop this and make your own thread.
This is a magisk forum, not a system mod forum.
Didgeridoohan said:
There has been an issue with vendor mounting in Magisk, but I believe that was for devices with separate vendor partitions (Nexus 6P, Nexus 5X, etc). I haven't seen any commits on GitHub about it though (although I haven't been keeping that close attention), so I don't know if it's been fixed.
I did find the culprit though: it's system.prop. With that file removed from /magisk/audmodlib my device booted up just fine.
Click to expand...
Click to collapse
I will remove it with next release. Thank you man. This **** only started happening with 11.6. this was the reason Atmos was boot looping as well so I removed system.prop in Atmos.
Can you do me a favor and remove a few lines to see if it's just the specific lines? I think that certain lines don't play nice with your phone.
Remove the first part, low power audio tweaks, reboot and see if it works. If it doesn't then that's the culprit. If not then remove the first two on the other audio tweaks.
Seyaru said:
If you wanna try this is my module for Nexus phones. I use this in my Nexus 5X Stock and PureNexus
https://www.androidfilehost.com/?fid=529152257862713260
Sry ahrion for use your thread
Click to expand...
Click to collapse
Hi there, thanks for the suggestion. I've tried it already and it didn't work. Asked for drivers to be installed when I opened the app after installing the module and restarting the phone.
kartikb said:
Hi there, thanks for the suggestion. I've tried it already and it didn't work. Asked for drivers to be installed when I opened the app after installing the module and restarting the phone.
Click to expand...
Click to collapse
Enable permissive.
Turn off audiofx
ahrion said:
Enable permissive.
Turn off audiofx
Click to expand...
Click to collapse
I'll try again when I get a chance to. Thanks for the suggestion.
[UPDATED] ViPER4Android FX <2.5.0.5>
v1.1:
- Updated to Audio Modification Library (Magisk) v1.1
This should fix the boot loop issues seen in only Magisk v11.6
Download: Link - Mirror
Previous Changelogs (Unified installer):
HTML:
V1.0:
- Initial release
- Smali edits to automatically enable storage permissions
- Audio Modification Library v1.0 is included
- Unified installer that will install mod for both Magisk and System
- Pixel support included
- Magisk Template v3 support
kartikb said:
Hi, I'm on 11.6. I've tried both modules on their own and they both have caused boot loops unfortunately.
Thanks anyway..
Click to expand...
Click to collapse
Didgeridoohan said:
There has been an issue with vendor mounting in Magisk, but I believe that was for devices with separate vendor partitions (Nexus 6P, Nexus 5X, etc). I haven't seen any commits on GitHub about it though (although I haven't been keeping that close attention), so I don't know if it's been fixed.
I did find the culprit though: it's system.prop. With that file removed from /magisk/audmodlib my device booted up just fine.
Click to expand...
Click to collapse
Try 1.1.
ahrion said:
Try 1.1.
Click to expand...
Click to collapse
Thanks, I'll give it another go and report back.
Update: my phone reboots into Android fine now however it doesn't process audio on phone speaker.
kartikb said:
Thanks, I'll give it another go and report back.
Update: my phone reboots into Android fine now however it doesn't process audio on phone speaker.
Click to expand...
Click to collapse
Flash my deep buffer remover. Look in the magisk forum.
ahrion said:
Flash my deep buffer remover. Look in the magisk forum.
Click to expand...
Click to collapse
Thanks, it all finally works on my Nexus 6P. Now to try on my OnePlus 3..
Hello everyone
Well... Not much to say.
I've made that very simple module for my personal use and just sharing it with the community in case anyone needs it.
What it does it really simple.
It installs (or replaces) sqlite3 binary in /system/bin to be used by any app or from terminal.
It's for ARM7 only.
Have fun
Credits: @topjohnwu for the template and @tech128 for the binary used.
Thank you for your effort... Do you have binary of sqlite of 64bit?
lssong99 said:
Thank you for your effort... Do you have binary of sqlite of 64bit?
Click to expand...
Click to collapse
I'm currently on G5 which is 64bit and binary works just fine.
Yes, it will work. However my situation is a bit complex that I call sqlite from Tasker and there is a bug in Tasker's that Tasker will invoke 64 bit libraries and throw error even if sqlite is 32 bit.
There is a work around but a bit complex so I am searching for 64 bit binary...
Sorry but what is SQLite
kwanthenewbie said:
Sorry but what i SQLite
Click to expand...
Click to collapse
You don't need it probably xD
It's the "program" to manipulate sqlite databases.
lssong99 said:
Yes, it will work. However my situation is a bit complex that I call sqlite from Tasker and there is a bug in Tasker's that Tasker will invoke 64 bit libraries and throw error even if sqlite is 32 bit.
There is a work around but a bit complex so I am searching for 64 bit binary...
Click to expand...
Click to collapse
https://github.com/stockrt/sqlite3-android
Build one by yourself. I guess you need arm64-v8a ?
DenyDarko said:
I'm currently on G5 which is 64bit and binary works just fine.
Click to expand...
Click to collapse
DenyDarko said:
https://github.com/stockrt/sqlite3-android
Build one by yourself. I guess you need arm64-v8a ?
Click to expand...
Click to collapse
Haha! Thanks.... Actually I had been trying very hard to resist the urge to build one myself (too lazy....). Maybe I should starting setup the tool train now....
Anyway thanks!
lssong99 said:
Haha! Thanks.... Actually I had been trying very hard to resist the urge to build one myself (too lazy....). Maybe I should starting setup the tool train now....
Anyway thanks!
Click to expand...
Click to collapse
It's not that hard and it's fun. Plus this git contains a customised sqlite for android.
It's not like building a kernel or smth. Give it a try xD
Hi @DenyDarko,
Please, can you update your module? It doesn't install with last version of Magisk. Futhermore, it will be interesting to include all binaries: sqlite3.arm; sqlite3.arm64; sqlite3.x64; etc. and add a symlink for the run architecture to "sqlite3". And last, publish it in the official repository.
Thank you!
manos78 said:
Hi @DenyDarko,
Please, can you update your module? It doesn't install with last version of Magisk. Futhermore, it will be interesting to include all binaries: sqlite3.arm; sqlite3.arm64; sqlite3.x64; etc. and add a symlink for the run architecture to "sqlite3". And last, publish it in the official repository.
Thank you!
Click to expand...
Click to collapse
@ianmacd added an updated version to the official repo already
DenyDarko said:
@ianmacd added an updated version to the official repo already
Click to expand...
Click to collapse
Ha. I didn't know there was already an SQLite module. I checked the official Magisk repo and didn't find one, so I made one for my own use and submitted it so that others could hopefully benefit from the work.
ianmacd said:
Ha. I didn't know there was already an SQLite module. I checked the official Magisk repo and didn't find one, so I made one for my own use and submitted it so that others could hopefully benefit from the work.
Click to expand...
Click to collapse
I even use yours now myself xD
@DenyDarko
Can you somehow check if this sqlite3 works ?
ianmacd said:
Ha. I didn't know there was already an SQLite module. I checked the official Magisk repo and didn't find one, so I made one for my own use and submitted it so that others could hopefully benefit from the work.
Click to expand...
Click to collapse
Hi @ianmacd,
I installed your Magisk module. However, I found a trouble: when enabling your module, the SafetyNet check never completes or indicates "the response is invalid".
So, please verify or review your module. Only disabling it the SafetyNet continues working well.
Or almost, put this info in the description, because your module is now in the official repository.
Regards.
manos78 said:
Hi @ianmacd,
I installed your Magisk module. However, I found a trouble: when enabling your module, the SafetyNet check never completes or indicates "the response is invalid".
So, please verify or review your module. Only disabling it the SafetyNet continues working well.
Or almost, put this info in the description, because your module is now in the official repository.
Regards.
Click to expand...
Click to collapse
The issue might be that the module mounts the binary to /system/xbin, and that your device doesn't have a xbin folder by default. This has been known to cause issues, and seem to be even more prevalent on recent Magisk releases. Try changing the modules xbin folder to bin and reboot, to see if it makes any difference.
@ianmacd It's a good idea to look for the existence of xbin at installation and use bin instead if it doesn't exist.
Didgeridoohan said:
The issue might be that the module mounts the binary to /system/xbin, and that your device doesn't have a xbin folder by default. This has been known to cause issues, and seem to be even more prevalent on recent Magisk releases. Try changing the modules xbin folder to bin and reboot, to see if it makes any difference.
@ianmacd It's a good idea to look for the existence of xbin at installation and use bin instead if it doesn't exist.
Click to expand...
Click to collapse
Thanks for the tip, @Didgeridoohan.
I'll have to read up on the Magisk installation environment to ensure that I write the logic in a sane way. By that, I mean, for example, that I'm unsure whether I can just check for [ -d /system/xbin ], or whether I might get a false positive if some other module has erroneously faked the existence of this directory.
ianmacd said:
Thanks for the tip, @Didgeridoohan.
I'll have to read up on the Magisk installation environment to ensure that I write the logic in a sane way. By that, I mean, for example, that I'm unsure whether I can just check for [ -d /system/xbin ], or whether I might get a false positive if some other module has erroneously faked the existence of this directory.
Click to expand...
Click to collapse
Good point... Check for /sbin/.core/mirror/system/xbin. That's the untouched /system mirror.
ianmacd said:
Thanks for the tip, @Didgeridoohan.
I'll have to read up on the Magisk installation environment to ensure that I write the logic in a sane way. By that, I mean, for example, that I'm unsure whether I can just check for [ -d /system/xbin ], or whether I might get a false positive if some other module has erroneously faked the existence of this directory.
Click to expand...
Click to collapse
Alternately you can just use bin and forget about xbin. There's really no technical reason to use xbin unless you're installing alternate forms of existing commands.
jcmm11 said:
Alternately you can just use bin and forget about xbin. There's really no technical reason to use xbin unless you're installing alternate forms of existing commands.
Click to expand...
Click to collapse
That's actually also been known to cause issues on some systems. While investigating issues like this, a while back, I believe it was found that it was most compatible to use xbin if it exists and bin if it doesn't.
Hi Guys,
My Pixel 2XL "magically automatically" updated itself to Android 11, so I've been forced to migrate to the Canary build of Magisk
to get root back etc.
The problem I have, is that the modules are not being 'detected' despite being installed.
EG: Active Edge Mod for Pixel, module is installed in Magisk, but the app doesn't detect the installation.
Same for other Magisk modules.
I'm hoping its something simple I need to do to detect these, I've searched, but found no definitive answer.
Anyone have any suggestions? Or can point me to more info on canary?
Thanks in Advance!
I noticed v21 has been released, so I jumped back to the stable channel and updated app to 8.0.1, but strangely still have the same issue!
Modules aren't being detected.
I get the following error when I try to run energized in terminal;
/system/bin/energized[13]: .: /sbin/ .magisk/modules/energizedprotection/system/bin/setupFiles.sh: No such file or directory
You've got two rather special modules there, so they're hardly the benchmark for if things work or not.
For Active Edge Mod you're probably better of asking for help with the developer. And judging by that error the Energized developer also need to update their module, since that path no longer exists on A11 (and it's bad practise to hardcode the path like that anyway). You could edit the energized file in the module directly, to point to the correct path (check the module thread, I'm sure someone has brought this up already).
So, in conclusion: unless there are other more "normal" modules that doesn't work there's no issue and you need to contact the developers of these two modules so that they can fix them.
Thanks @Didgeridoohan, I wasn't aware that the paths had changed. That would explain a lot...
Out of curiosity, what would you consider a "normal" module? For testing purposes..
Cheers!
Thanks @Didgeridoohan, I wasn't aware that the paths had changed. That would explain a lot...
Out of curiosity, what would you consider a "normal" module? For testing purposes..
Cheers!
I always like @osm0sis' modules. They utilise the module installer scripts very nicely and pretty much always work (and if they don't something usually has gone horribly wrong).
Well, hijack the module installer scripts nicely.
Well, I do have @osm0sis BusyBox Magisk Module installed, but I think I read a tweet that TopJohnWu was incorporating a busybox binary in Magisk..
I can see that all of my Magisk modules (except Systemless Host) has a "folder icon with an i" on it. Can't find what that means.. and I get a blank screen when i press it.
Magisk has had Busybox integrated for ages... Lately it's become more usable for scripts and modules though. It's not exposed to the rest of the system like @osm0sis module is.
The icon you're seeing is the module readme. Click that and it should open in the window that you see.