FORUMS
Remove All Ads from XDA
Honor 7x
Win an Honor 7X!

[DEVS-ONLY] SuperSU developer discussion

11,218 posts
Thanks Meter: 86,186
 
By Chainfire, Senior Moderator / Senior Recognized Developer - Where is my shirt? on 5th September 2014, 04:57 PM
Post Reply Email Thread
14th January 2016, 01:27 PM |#21  
nkk71's Avatar
Recognized Developer / Recognized Contributor
Flag Beirut
Thanks Meter: 7,421
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

Thanks for the update. I'll have a look at those commands. losetup -f is specifically not used because I have already encountered devices/recoveries where the built-in losetup does not support this flag. So just loop0 and loop1 are tried, on failure, too bad (guess that could use improvement, hehe). The same goes for the -b test for if, and the -f flag for readlink. While I have not specifically tested the block device test, I know the symlink test fails on some devices. So I need to do some testing.

This is why some things in the ZIP are done is such weird ways instead of just using standard command, they're all work-arounds for encounted recovery versions that didn't support command X or flag Y ...

If it's just regarding MultiROM Recovery versions, then I believe I can fix the loop device release, even without touching your script; MultiROM Recovery does indeed release loop devices, but after it tries to unmount the partitions first; I could rewrite that, to release /data/su.img before starting the other unmounts.

But regarding the dd command, that's going to be an issue... we could work around it with some kind of specific check just for this, but that is not ideal; I'm sure you have your reasons why to first null out the partition (not needed on my devices), before flashing the real kernel, but if the readlink & block device checks are unreliable, perhaps just limit the amount of data dd nulls out
giving dd "free reign" to null out as much as it possible can, could also be potentially unwanted for other recoveries/devices
 
 
14th January 2016, 02:58 PM |#22  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,186
 
Donate to Me
More
Quote:
Originally Posted by nkk71

If it's just regarding MultiROM Recovery versions, then I believe I can fix the loop device release, even without touching your script; MultiROM Recovery does indeed release loop devices, but after it tries to unmount the partitions first; I could rewrite that, to release /data/su.img before starting the other unmounts.

But regarding the dd command, that's going to be an issue... we could work around it with some kind of specific check just for this, but that is not ideal; I'm sure you have your reasons why to first null out the partition (not needed on my devices), before flashing the real kernel, but if the readlink & block device checks are unreliable, perhaps just limit the amount of data dd nulls out
giving dd "free reign" to null out as much as it possible can, could also be potentially unwanted for other recoveries/devices

Oh, I wasn't saying the changes won't happen, just that it may not be a copy/paste of what you stated.

For example, the way it will be used in the script with the expected input and output, "readlink -f FILE" can be replaced with "readlink FILE || echo FILE" twice.

Similarly, instead if "if -b" a "grep /dev/block" after using readlink should work.

Is it 100% foolproof? No. But I'll bet it'll work on every recovery/device currently out there.

As for releasing /data/su.img, I will definitely put this into the script as well. No need to patch MultiROM.
The Following 2 Users Say Thank You to Chainfire For This Useful Post: [ View ]
21st January 2016, 12:25 AM |#23  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,186
 
Donate to Me
More
Quote:
Originally Posted by nkk71

...

Please see the attached version.

Reading again through this thread, I believe the following issues have been fixed:

- The symlink of the boot image partition to somewhere outside /dev/block is now detected, and the wipe skipped
- The loop device link to the /data/su.img or /cache/su.img file is now released after unmount
- The remount_ro section in launch_daemonsu.sh has been removed, as I now have a different workaround for the remount r/w issue
- If 'setprop sukernel.mount 1' fails to mount, a fallback attempt is made with losetup

That should cover all the issues you raised (correct me if I'm wrong), and hopefully this makes the entire thing work with MultiROM. Please do let me know
Attached Files
File Type: zip SuperSU-v2.66-20160121002226.zip - [Click for QR Code] (4.07 MB, 120 views)
The Following 2 Users Say Thank You to Chainfire For This Useful Post: [ View ]
21st January 2016, 08:28 PM |#24  
nkk71's Avatar
Recognized Developer / Recognized Contributor
Flag Beirut
Thanks Meter: 7,421
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

Please see the attached version.

Reading again through this thread, I believe the following issues have been fixed:

- The symlink of the boot image partition to somewhere outside /dev/block is now detected, and the wipe skipped
- The loop device link to the /data/su.img or /cache/su.img file is now released after unmount
- The remount_ro section in launch_daemonsu.sh has been removed, as I now have a different workaround for the remount r/w issue
- If 'setprop sukernel.mount 1' fails to mount, a fallback attempt is made with losetup

That should cover all the issues you raised (correct me if I'm wrong), and hopefully this makes the entire thing work with MultiROM. Please do let me know

A late reply (I see 2.67 is already out), but ran into a little hiccup

But can confirm all issues are fixed with your attached zip for MultiROM
  1. Installer
    • no longer causes unneccessary wiping
    • releases loop device fine
      .
  2. Bootup behaves as expected
    • first boot will reboot after installing the apk
    • second boot works fine, SuperSU fully functional

Many thanks @Chainfire


If I figure out why the setprop didnt work, I'll post back

Also, just an fyi, not sure how important / relevant / intended they are, since SuperSU flashes and works just fine:

1- extract of recovery.log:
Code:
- System-less mode, boot image support required
- Creating image
Creating filesystem with parameters:
    Size: 33554432
    Block size: 4096
    Blocks per group: 32768
    Inodes per group: 2048
    Inode size: 256
    Journal blocks: 1024
    Label: 
    Blocks: 8192
    Block groups: 1
    Reserved block group size: 7
Created filesystem with 11/2048 inodes and 1166/8192 blocks
/data/su.img: clean, 11/2048 files, 1166/8192 blocks
- Mounting image
mknod: /dev/block/loop0: File exists
CANNOT LINK EXECUTABLE: cannot locate symbol "__register_atfork" referenced by "/system/bin/toolbox"...
page record for 0xb6ef304c was not found (block_size=32)
- Creating paths
- Removing old files


2- Patching sepolicy
Code:
check_zero_def "" "LD_LIBRARY_PATH=$SYSTEMLIB 
/su/bin/sukernel --cpio-add /sutmp/ramdisk 
/sutmp/ramdisk 644 sepolicy /sutmp/sepolicy_patched"
Code:
-rw-rw-rw-    1 root     root       2279160 Jan 21 17:19 ramdisk
-rw-rw-rw-    1 root     root       1199423 Jan 21 17:19 ramdisk.packed
-rw-rw-rw-    1 root     root        240961 Jan 21 17:19 sepolicy
-rw-------    1 root     root        243577 Jan 21 17:19 sepolicy_patched
Neither of the above two affect anything, as far as I can see, just mentioning it
The Following User Says Thank You to nkk71 For This Useful Post: [ View ]
21st January 2016, 11:27 PM |#25  
Surge1223's Avatar
Recognized Contributor
Flag Iowa
Thanks Meter: 6,917
 
Donate to Me
More
@Chainfire are you using sush to change the default path? After boot even though init.environ.rc is patched? The reason I ask is because when I switch to root user in shell and thus the shell changes from mksh to sush, my path changes and for some reason sbin isn't in either path (not as su or default shell user)

I noticed sush evaluates the default path but I don't know if this is intentional or if it's related to something I've messed up on my part

The only differences from the patched ramdisk that supersu 2.66/67 creates and my current ramdisk is that I changed the perms for /su to 750 instead of 755 and I added some paths to init.environ.rc

Code:
 
# set up the global environment
on init
    export PATH /su/bin:/sbin:/vendor/bin:/system/sbin:/system/bin:/su/xbin:/system/xbin:/sbin:/data/local/tmp:/data/toolchain/bin:/tmp/bin
setenv LD_LIBRARY_PATH /data/vendor/lib64:/vendor/lib64:/data/lib64:/system/lib64:/data/vendor/lib:/vendor/lib:/data/lib:/system/lib:/data/toolchain/lib
    export ANDROID_BOOTLOGO 1
    export ANDROID_ROOT /system
    export ANDROID_ASSETS /system/app
    export ANDROID_DATA /data
    export ANDROID_STORAGE /storage
    export EXTERNAL_STORAGE /sdcard
    export ASEC_MOUNTPOINT /mnt/asec
    export BOOTCLASSPATH /system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/telephony-common.jar:/system/framework/voip-common.jar:/system/framework/ims-common.jar:/system/framework/apache-xml.jar:/system/framework/org.apache.http.legacy.boot.jar
    export SYSTEMSERVERCLASSPATH /system/framework/services.jar:/system/framework/ethernet-service.jar:/system/framework/wifi-service.jar
Attached Thumbnails
Click image for larger version

Name:	1453414994937.jpg
Views:	304
Size:	166.6 KB
ID:	3618049  
The Following User Says Thank You to Surge1223 For This Useful Post: [ View ] Gift Surge1223 Ad-Free
22nd January 2016, 12:55 AM |#26  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,186
 
Donate to Me
More
Quote:
Originally Posted by Surge1223

@Chainfire are you using sush to change the default path? After boot even though init.environ.rc is patched? The reason I ask is because when I switch to root user in shell and thus the shell changes from mksh to sush, my path changes and for some reason sbin isn't in either path (not as su or default shell user)

sush is just a copy of /system/bin/sh with a different SELinux context applied. Nothing more, nothing less.

Quote:

I noticed sush evaluates the default path but I don't know if this is intentional or if it's related to something I've messed up on my part

I don't know either. /sbin is in my $PATH on my test device both with and without root.

Quote:

The only differences from the patched ramdisk that supersu 2.66/67 creates and my current ramdisk is that I changed the perms for /su to 750 instead of 755 and I added some paths to init.environ.rc

Why would you change it to 750 ?

Not sure if your env changes can cause this, tbh.
The Following User Says Thank You to Chainfire For This Useful Post: [ View ]
22nd January 2016, 06:16 PM |#27  
nkk71's Avatar
Recognized Developer / Recognized Contributor
Flag Beirut
Thanks Meter: 7,421
 
Donate to Me
More
@Chainfire regarding that hiccup (courtesy of @Captain_Throwback ) , I mentioned earlier, it seems it's back / still there.

At first we thought it's due to the size of the kernel, but turns out that's not the issue.

Trying to find the cause is proving difficult, so I'll just summarize my findings as best I can:


When installing SuperSU 2.67 from within a custom rom (twrp flashable zip), it fails to properly create the new boot.img (it's truncated for some reason):

extract of the updater-script:
Code:
set_progress(0.700000);
ui_print("Extracting boot image...");
ui_print(" ");
package_extract_file("boot.img", "/dev/block/platform/msm_sdcc.1/by-name/boot");
set_progress(0.800000);
#ROOT
ui_print("Installing SuperSU..."); ui_print(" ");
package_extract_dir("supersu", "/tmp/supersu");
run_program("/sbin/busybox", "unzip", "/tmp/supersu/BETA-SuperSU-v2.67.zip", "META-INF/com/google/android/*", "-d", "/tmp/supersu");
run_program("/sbin/busybox", "sh", "/tmp/supersu/META-INF/com/google/android/update-binary", "dummy", "0", "/tmp/supersu/BETA-SuperSU-v2.67.zip");
ui_print(" ");


extract of the recovery.log error
(towards the end of the SuperSU script, when it runs
/su/bin/sukernel --bootimg-replace-ramdisk $STOCKBOOTIMAGE /sutmp/ramdisk.packed /sutmp/boot.img)
Code:
 
sukernel v2.67 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire
 
Loading from [/dev/block/mmcblk0p42] ...
 
magic: [ANDROID!]
kernel: [6662360] (6664192) @ 0x00008000
ramdisk: [1193431] (1193984) @ 0x02000000
second: [0] (0) @ 0x00f00000
tags: @ 0x01e00000
page size: 2048
unused: [0x0040f800] [0x00000000]
dtb(?): [4257792] (4257792)
name: []
command line: [console=ttyHSL0,115200,n8 androidboot.hardware=qcom user_debug=30 msm_rtb.filter=0x3b7 ehci-hcd.park=3]
extra command line: []
id: [0xc760d7abbc1949e9deaa692a43b1f4b1deee5c43000000000000000000000000]
 
Loading from [/sutmp/ramdisk.packed] ...
 
Saving to [/sutmp/boot.img] ...
 
magic: [ANDROID!]
kernel: [6662360] (6664192) @ 0x00008000
ramdisk: [1200876] (1202176) @ 0x02000000
second: [0] (0) @ 0x00f00000
tags: @ 0x01e00000
page size: 2048
unused: [0x0040f800] [0x00000000]
dtb(?): [4257792] (4257792)
name: []
command line: [console=ttyHSL0,115200,n8 androidboot.hardware=qcom user_debug=30 msm_rtb.filter=0x3b7 ehci-hcd.park=3]
extra command line: []
id: [0xaba2324aa866e82c9a07e21a90b4ea37d01877aa000000000000000000000000]
 
Could not write data
2954+0 records in
2954+0 records out
12099584 bytes (11.5MB) copied, 0.095180 seconds, 121.2MB/s
 
script result was [M8 GPE 5.07.1700.9 CDMA Edition Installed]
 
M8 GPE 5.07.1700.9 CDMA Edition Installed
I:Legacy property environment disabled.
rm: can't remove 'META-INF/com/google/android': No such file or directory
ZIP successfully installed
I:Running cmd "rm "/dev/block/mmcblk0p42""
I:Running cmd "mv "/dev/block/mmcblk0p42"-orig "/dev/block/mmcblk0p42""
Restoring mounts...

It says succeeded, but the log shows "Could not write data",
and the resulting boot.img is actually too small (it should be 12126208 bytes, not 12099584) and therefore corrupt (which will throw an error, since multirom can inject it's own changes into the kernel)


I've tried debugging, but results are quite confusing

1- added a sleep command just after
check_zero_def "- Creating boot image" "LD_LIBRARY_PATH=$SYSTEMLIB /su/bin/sukernel --bootimg-replace-ramdisk $STOCKBOOTIMAGE /sutmp/ramdisk.packed /sutmp/boot.img"
checked the recovery log, and it showed "Could not write data" (and incorrect size of boot.img in /sutmp)
opened an adb shell and manually ran
/su/bin/sukernel --bootimg-replace-ramdisk /dev/block/mmcblk0p42 /sutmp/ramdisk.packed /sutmp/boot.img
(p42 is the same as the script is using)
--> succeeded with correct boot.img size, let the script continue and all went well


2- put the script to sleep, and manually ran all the commands from adb shell
Code:
/su/bin/sukernel --bootimg-extract-ramdisk /dev/block/mmcblk0p42 /sutmp/ramdisk.packed
/su/bin/sukernel --ungzip /sutmp/ramdisk.packed /sutmp/ramdisk
/su/bin/sukernel --cpio-extract /sutmp/ramdisk sepolicy /sutmp/sepolicy
/su/bin/supolicy --file /sutmp/sepolicy /sutmp/sepolicy_patched
/su/bin/sukernel --cpio-add /sutmp/ramdisk /sutmp/ramdisk 644 sepolicy /sutmp/sepolicy_patched
/su/bin/sukernel --cpio-add /sutmp/ramdisk /sutmp/ramdisk 700 sbin/launch_daemonsu.sh /tmp/supersu/common/launch_daemonsu.sh
/su/bin/sukernel --patch /sutmp/ramdisk /sutmp/ramdisk /dev/block/mmcblk0p42
/su/bin/sukernel --gzip /sutmp/ramdisk /sutmp/ramdisk.packed
/su/bin/sukernel --bootimg-replace-ramdisk /dev/block/mmcblk0p42 /sutmp/ramdisk.packed /sutmp/boot.img

once using "/sutmp/tst_boot.img" and once directly with "/dev/block/mmcblk0p42", as the script would do
-> both generated the correct patched boot.img


3- changed the SuperSU update-binary to include at line 1184 (after the patch check, but before patching the kernel):
Code:
    cp $STOCKBOOTIMAGE /sutmp/wrk_boot.img
    STOCKBOOTIMAGE=/sutmp/wrk_boot.img
--> succeeded, no issues


I tried playing around with sukernel a bit, and found the following very curious:
Code:
C:\ADB\ADB_M8>adb push C:\ADB\ADB_M8\MM3\tst_boot.img /tmp
3705 KB/s (12118016 bytes in 3.193s)
 
C:\ADB\ADB_M8>adb shell

~ # [6n /su/bin/sukernel --backup /tmp/tst_boot.img
/su/bin/sukernel --backup /tmp/tst_boot.img
sukernel v2.67 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire
 
[/tmp/tst_boot.img](12118016) --> [/data/stock_boot_22acb886172c5eb575bfd7c9ee070fc2f2cc8bf7.img.gz](8629168)
 
 
~ # [6n dd if=/tmp/tst_boot.img of=/dev/block/mmcblk0p42
dd if=/tmp/tst_boot.img of=/dev/block/mmcblk0p42
23668+0 records in
23668+0 records out
12118016 bytes (11.6MB) copied, 0.398213 seconds, 29.0MB/s
 
 
~ # [6n /su/bin/sukernel --backup /dev/block/mmcblk0p42
/su/bin/sukernel --backup /dev/block/mmcblk0p42
sukernel v2.67 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire
 
[/dev/block/mmcblk0p42](12058624) --> [/data/stock_boot_18effe115987f74d93b0657b3da93c2e4e95a7f6.img.gz](8616560)
 
 
~ # [6n sha1sum /dev/block/mmcblk0p42
sha1sum /dev/block/mmcblk0p42
22acb886172c5eb575bfd7c9ee070fc2f2cc8bf7  /dev/block/mmcblk0p42


Hope this helps you narrow it down

PS: at first I thought it was a memory issue, but that is sort of ruled out by the --backup command, and number 2 and 3 above
23rd January 2016, 02:23 PM |#28  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,186
 
Donate to Me
More
Quote:
Originally Posted by nkk71

@Chainfire regarding that hiccup (courtesy of @Captain_Throwback ) , I mentioned earlier, it seems it's back / still there.

This only happens when SuperSU is embedded in another ZIP ?

It does smell of a memory issue, but indeed the output is weird.
23rd January 2016, 02:41 PM |#29  
nkk71's Avatar
Recognized Developer / Recognized Contributor
Flag Beirut
Thanks Meter: 7,421
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

This only happens when SuperSU is embedded in another ZIP ?

It does smell of a memory issue, but indeed the output is weird.

Yes, only when embedded in another ZIP.

I tried the exact same ROM without SuperSU installation chained in the installer; then immediately flashed SuperSU 2.67 afterwards, and it went through perfectly.
Also using the copy to a tmp file "wrk_boot.img", also worked fine directly in the embedded zip.

What I find most peculiar is the output of the --backup , which was done on a clean reboot into recovery, so plenty of free space
- backing up from file, yields proper size and sha1
- backing up from "fake" mmcblk, yields incorrect size and wrong sha1
---- but running sha1sum on the fake mmcblk gives the correct sha1
---- and cp from fake mmcblk, as well as dd from fake mmcblk, also work properly

As for the memory issue, I'm honestly uncertain, the device in question is the HTC One M8 (tested on GSM and Sprint variants), which reports 1.8GB space in recovery, 1.6GB free.
The ROM itself is ~500MB compressed and ~1GB uncompressed, that should still leave enough "working space" for pretty much anything
30th January 2016, 12:13 AM |#30  
Flyview's Avatar
Senior Member
Flag Toronto/San Diego
Thanks Meter: 1,389
 
More
Hey @Chainfire , I've been using the context switching command to make the root commands work in my app LeanDroid. You probably don't remember but when Lollipop was new you showed me how to use your SuperSU library to switch context to system. As I understood this was in order to get around selinux restricting my root commands which involve system processes. My app calls the "phone" service through root and it seems that they only work by switching the context to system. I have been requiring my users to have SuperSU as their root, as for example CyanogenMod's built in root still isn't working. Is SuperSU still the only root option that allows context switching or can I code the call to work with other root modules as well?

Thanks for your time!

Code:
if(systemAppContext) {
                    Shell.run("su --context u:r:system_app:s0", commands, null, false);
                } else {
                    Shell.SU.run(commands);
                }
31st January 2016, 02:46 AM |#31  
Try Root G925S Android 6.0.1
I tried to modified ramdisk to Root G925S - Android 6.0.1 Rom, but get bootloop!

I see su binary,... in /system/xbin/ and symlink app_process > daemonsu in /system/bin/, but symlink app_process64 > daemonsu is missing

My modified:
- Patched sepolicy by SuperSU 2.67 via N920P - Android 5.1.1 devices
- Remove ",support_scfs,verify" in fstab files
- Add /sbin/injectsu.sh , /sbin/busybox & sbin/su/ (include SuperSU 2.67 binary files,...)
Code:
#!/system/bin/sh

/sbin/busybox mount -o remount,rw /system

# Inject SuperSU
if [ ! -f /system/xbin/su ]; then
	# Make necessary folders
	/sbin/busybox mkdir /system/etc/init.d

	# Extract SU from ramdisk to correct locations
	/sbin/busybox rm -rf /system/bin/app_process
	/sbin/busybox rm -rf /system/bin/install-recovery.sh
	/sbin/busybox cp /sbin/su/supolicy /system/xbin/
	/sbin/busybox cp /sbin/su/su /system/xbin/
	/sbin/busybox cp /sbin/su/libsupol.so /system/lib64/
	/sbin/busybox cp /sbin/su/install-recovery.sh /system/etc/
	/sbin/busybox cp /sbin/su/99SuperSUDaemon /system/etc/init.d/

	# Begin SuperSU install process
	/sbin/busybox cp /system/xbin/su /system/xbin/daemonsu
	/sbin/busybox cp /system/xbin/su /system/xbin/sugote
	/sbin/busybox cp /system/bin/sh /system/xbin/sugote-mksh
	/sbin/busybox mkdir -p /system/bin/.ext
	/sbin/busybox cp /system/xbin/su /system/bin/.ext/.su

	/sbin/busybox cp /system/bin/app_process64 /system/bin/app_process_init
	/sbin/busybox mv /system/bin/app_process64 /system/bin/app_process64_original

	/sbin/busybox echo 1 > /system/etc/.installed_su_daemon

	/sbin/busybox chmod 755 /system/xbin/su
	/sbin/busybox chmod 755 /system/xbin/daemonsu
	/sbin/busybox chmod 755 /system/xbin/sugote
	/sbin/busybox chmod 755 /system/xbin/sugote-mksh
	/sbin/busybox chmod 755 /system/xbin/supolicy
	/sbin/busybox chmod 777 /system/bin/.ext
	/sbin/busybox chmod 755 /system/bin/.ext/.su
	/sbin/busybox chmod 755 /system/bin/app_process_init
	/sbin/busybox chmod 755 /system/bin/app_process64_original
	/sbin/busybox chmod 644 /system/lib64/libsupol.so
	/sbin/busybox chmod 755 /system/etc/install-recovery.sh
	/sbin/busybox chmod 644 /system/etc/.installed_su_daemon
	
	/sbin/busybox ln -s /system/etc/install-recovery.sh /system/bin/install-recovery.sh
	/sbin/busybox ln -s /system/xbin/daemonsu /system/bin/app_process
	/sbin/busybox ln -s /system/xbin/daemonsu /system/bin/app_process64

	/system/xbin/su --install
fi

# Inject Busybox if not present
if [ ! -f /system/xbin/busybox ]; then
	/sbin/busybox cp /sbin/busybox /system/xbin/
	/sbin/busybox chmod 755 /system/xbin/busybox
	/system/xbin/busybox --install -s /system/xbin
fi
	
# Kill securitylogagent
if [ -d /system/app/SecurityLogAgent ]; then
	/sbin/busybox rm -fR /system/app/SecurityLogAgent
	/sbin/busybox rm -fR /system/priv-app/KLMSAgent
	/sbin/busybox rm -fR /system/app/*Knox*
	/sbin/busybox rm -fR /system/app/*KNOX*
	/sbin/busybox rm -fR /system/container
	/sbin/busybox rm -fR /system/app/Bridge
	/sbin/busybox rm -fR /system/app/BBCAgent
	/sbin/busybox rm -fR /system/priv-app/FotaClient
	/sbin/busybox rm -fR /system/priv-app/SyncmIDM
	/sbin/busybox rm -fR /system/priv-app/*FWUpdate*
fi
	
# Enforce init.d script perms on any post-root added files
/sbin/busybox chmod 755 /system/etc/init.d
/sbin/busybox chmod 755 /system/etc/init.d/*

# Run init.d scripts
/sbin/busybox mount -t rootfs -o remount,rw rootfs
/sbin/busybox run-parts /system/etc/init.d

# Deep sleep fix
if [ ! -d /system/su.d ]; then
	/sbin/busybox mkdir /system/su.d
	/sbin/busybox chmod 0700 /system/su.d
	if [ ! -f /system/su.d/000000deepsleep ]; then
		/sbin/busybox cp -f /sbin/su/000000deepsleep /system/su.d/
		/sbin/busybox chmod 0700 /system/su.d/000000deepsleep
	fi
	/system/bin/reboot
fi

#  Wait for 5 seconds from boot before starting the SuperSU daemon
/sbin/busybox sleep 5
/system/xbin/daemonsu --auto-daemon &

sync
- Add lines to init.rc file
Code:
# Inject SuperSU
service daemonsu /sbin/injectsu.sh
    class late_start
    user root
    seclabel u:r:init:s0
    oneshot


Sorry bad english
The Following User Says Thank You to Manh_IT For This Useful Post: [ View ] Gift Manh_IT Ad-Free
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes