Database Develop

[MOD] eRecovery for CM7/stock ...

Hi all!
Surfing a bit into XDA, I've created this mod in order to add to Froyo/GB/CM7 the way to access CWM on boot pressing any hardware keys.
Once installed, to access recovery you only have to repeatedly press any hard key; it works like eRecovery in Nova ROM.
In order to install/remove it, you only have to flash it via CWM, so you need CWM recovery installed at your OB.
V20B:
Installer: http://dl.dropbox.com/u/4629711/zeus/huexxx-eRecovery-V20B.zip
Remover: http://dl.dropbox.com/u/4629711/zeus/huexxx-eRecovery-remover-V20B.zip
V20N:
Installer: http://dl.dropbox.com/u/4629711/zeus/huexxx-eRecovery-V20N.zip
Remover: http://dl.dropbox.com/u/4629711/zeus/huexxx-eRecovery-remover-V20N.zip
CM7:
Installer: http://dl.dropbox.com/u/4629711/cm7/huexxx-eRecovery-CM7.zip
Remover: http://dl.dropbox.com/u/4629711/cm7/huexxx-eRecovery-remover-CM7.zip
Stock V10D:
Installer: http://dl.dropbox.com/u/4629711/cm7/huexxx-eRecovery-V10D.zip
Remover: http://dl.dropbox.com/u/4629711/cm7/huexxx-eRecovery-remover-V10D.zip
Stock V10E:
Installer: http://dl.dropbox.com/u/4629711/cm7/huexxx-eRecovery-V10E.zip
Remover: http://dl.dropbox.com/u/4629711/cm7/huexxx-eRecovery-remover-V10E.zip
PD: This stuff will probably work flawlessly in other stock rom versions, but to ensure that it will work, send me your /system/bin/pvrsrvinit file indicating your ROM version and I will create a specific .zip for this version. Thanks pbog1 for the file.
Credits go to knzo and D4rKn3sSyS.
If you find this useful, please thank it!
Regards.

No need to nandroid before install it... is fully probed.
Regards!

Suggestion: Information about CWM version?

It only changes one file at /system/bin, then I would suggest to use the latest CWM.
Regards.

It's a bit late on the boot, inject a sooner service.

Yeah, it's still at beta stage.
I though it would be a good point because is just before init.d starts.
I will find the first service and hijack it, but at least this mod can handle framework's loopboots.
Regards!

i'm doing the same thing for 2.3.4
but i was failed.
i hijacked lgdrmserver,no response
can you help me?

Try with another service... I can't say more ATM...

Send me the init.rc

This is great news!! AAMOF, the no-hard-reboot is one of the things that prevents me from flashing these days. Last time I bicked the phone I lost one full day.
I'll install this as soon as it's improved.
Thank you Huexx!

knzo said:
Send me the init.rc
Click to expand...
Click to collapse
sorry i dont know why i can't send you pm,here's link
http://hotfile.com/dl/132897861/3f3e377/init.rar.html
thx

Try to inject: /system/bin/pvrsrvinit.
It's the PowerVR SGX 540 driver and it's earlier in the boot.
Rename it to /system/bin/pvrsrvinit2, then create an empty bash file with that name and inject the command I used on my eRecovery and in the last line (after the keypress check) run /system/bin/pvrsrvinit2 or it won't boot.

got it,try it now thx

Hi all.
Looking at init.rc and according with the suggested service by knzo, why you say that my inject point would be sooner?
sysinit is executed before ueventd, console, adbd, pvrsrvinit, etc... it's before ALL the services, and I haven't to modify it because it's a script by itself.
Regards.

Huexxx said:
sysinit is executed before ueventd, console, adbd, pvrsrvinit, etc... it's before ALL the services, and I haven't to modify it because it's a script by itself.
Click to expand...
Click to collapse
That doesn't even make sense.
You want to execute a sh without console running?
Or why can you see the first init.d in the adb logcat then?
Just because it comes in a previous line doesn't make it start sooner.

Well, if I've understood, the place at init.rc doesn't determines the run order, doesn't it?
Then how can you know which service will be launched the first?
If I hack pvrsrvinit, would it check for keystroke sooner?
Regards.

Depends on the trigger/call.
Pvrsrvinit ought to be sooner indeed.

Ok, let's try it then!
Regards.

it make nosense at all.
i don't know where i did wrong.
hijack pvrsrvinit,and create init.d folder ,write script to make original pvrsrvinit run...

My version doesn't work...
It's strange... later but It sholud run.

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

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

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

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

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

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

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

[AOSP] sepolicy patch for Marshmallow ROMs

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 ,

ViPER4Android 2.5.0.5

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.

[Module] [Magisk] init.d link v1.3 | require Magisk 12.0+

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.