Related
As I've been working on the Stock ROM release of 10.1.1.A.1.307 some of my users started reporting that the issues I fixed for my 10.1.1.A.1.253 release started popping up again: whenever anyone with a locked bootloader tried to remount /system writable (remount,rw) it spontaneously sprung a reboot... very annoying, to say the least!
It gets even better (or worse, depends on how you look at it) when you consider any CWM version ever released for our Z/ZL models will ask us if we want it to prevent the ROM from flashing STOCK recovery... /system/etc/install-recovery.sh is the culprit here as it is what CWM disables by making it non-executable when you say YES to the question 'ROM may flash stock recovery on boot, fix?'. It actually is an important part of the rooting process we all know. It stopped the RIC service and prevented the reboots from happening. If someone said YES, the issue mentioned in the previous paragraph would also start happening and some users have even reported loss of root and even bootloops because of this...
I've set out to find a fix for it, one that eliminates the chance a regular run-of-the-mill CWM user will ever encounter the question ever again.
For all of the regular users, download one of these:
Warning for Xperia T [ALL VERSIONS] Users: There is a problem with this patch combined with the CWM package for your phones, it seems to be busybox related. @garik.007 found the solution to this issue: BusyBox by Robert Nediyakalaparambil. Install that app, update your busybox and it will fix CWM and the remount-reboot fix
WINDOWS INSTALLER: [NUT]'s definitive remount-reboot fixer!
Make sure you have USB debugging turned ON.
Download the package, save it somewhere you remember
Unzip it somewhere you remember
Run the install.bat file and choose the superuser app you are using.
Done!
The phone should do what the installer tells you it's doing, so if it says your phone will reboot, it will. If it did NOT explicitly say that it would then something went wrong!
RECOVERY FLASHABLE: [NUT]'s definitive remount-reboot fixer!
This is a flashable ZIP, install using CWM or TWRP and you're done!
It is safe to use on any STOCK (Read: NOT CM Based) ROM version released for all Xperia phones with the ric binary incorporated in the ramdisk (/sbin/ric) up to now. To see if this fix will work for your device, check if the 'ctrlaltdel' command is executed from the init.sony[anything].rc scripts. If it is, this will work!
NOTE: As this fix needs busybox to function and will install or update busybox in /system/xbin if no busybox or no busybox binary which supports the 'nohup' applet was found in /system/bin, /system/xbin or /sbin.
NOTE 2: As soon as you have installed this rootfixer and you saw it replace the already installed busybox, remove any and all busybox installer apps you have, it will probably break the rootfixer if you update busybox using that app. The version this rootfixer installs is rock solid and is used by most if not every kernel dev working on Xperia line kernels.
NOTE 3: If you have an unlocked bootloader, you can actually also install it, it won't hurt and you'll be protected from the reboots if you re-lock your phone!
XDA:DevDB Information
The definitive root Remount-Reboot fix!, Tool/Utility for the Sony Xperia Z
Contributors
[NUT]
Version Information
Status: Stable
Stable Release Date: 2013-06-25
Created 2013-06-27
Last Updated 2015-02-05
Reserved
For the ROM chefs and other devs on XDA:
I'm proud to donate the following to the dev-community on XDA, for anyone who wants to integrate it in his/her ROM or rooting tool, there is no need to ask for permissions: you can!
This hijacks the toolbox command 'ctrlaltdel' executed from init.sony-platform.rc line 13. It will take it's place in a similar way as the chargemon gets replaced to make the recoveries possible on locked bootloaders. As it is a symlink to /system/bin/toolbox there is NO need to create a copy to something else to make this work. The script that takes it's place is this:
Code:
#!/system/bin/sh
#####
#
# Completely demolish the RIC service and make sure the phone will survive a remount of /system
#
# Author: [NUT] from XDA
#
ARGS="$1 $2"
# Check busybox path and export it
if [ -x "/system/xbin/busybox" ]; then
export BUSYBOX="/system/xbin/busybox"
elif [ -x "/system/bin/busybox" ]; then
export BUSYBOX="/system/bin/busybox"
elif [ -x "/sbin/busybox" ]; then
export BUSYBOX="/sbin/busybox"
fi
# Mount rootfs rw, if it isn't already
ROOTFSMOUNTEDRO=`$BUSYBOX grep "rootfs ro,relatime" /proc/mounts | $BUSYBOX wc -l`
if [ "$ROOTFSMOUNTEDRO" = "1" ]; then
$BUSYBOX touch /tmp/remountedrootfs
$BUSYBOX mount -o remount,rw /
fi
# Edit the init.rc so the service never gets to start
$BUSYBOX sed -i '/"# Start RIC"/N;s/service ric /sbin/ric/#service ric /sbin/ric/g' /init.sony.rc
$BUSYBOX sed -i '/"#service ric /sbin/ric"/N;s/ class main/# class main/g' /init.sony.rc
$BUSYBOX sed -i '/"# class main"/N;s/ user root/# user root/g' /init.sony.rc
$BUSYBOX sed -i '/"# user root"/N;s/ group root/# group root/g' /init.sony.rc
# chmod the ric binaries so they can't start anymore, as a failsafe
if [ -x "/sbin/ric" ]; then
$BUSYBOX chmod 644 /sbin/ric
fi
if [ -x "/system/bin/ric" ]; then
$BUSYBOX chmod 644 /system/bin/ric
fi
# Make sure the RIC service gets killed if it manages to start up...
# This process will drop in the background and keeps running untill it did!
$BUSYBOX nohup /system/bin/killric.sh &
# Execute the actual command now
exec /system/bin/toolbox ctrlaltdel $ARGS
As you can see I'm spawning a process into the background to kill the RIC service. Even though I commented out the service in init.sony.rc it still manages to start up as init reads and buffers all of it's scripting before it actually starts to do anything... so the service will run regardless of the changes we make to it. This step was just for any form of runlevel change to prevent that from triggering a restart. As a secondary measure it disables the binary all the way by setting 644 permissions on it.
Code:
#!/system/bin/sh
#####
#
# Check RIC looper, it will exit as soon as it found and killed it!
#
# Author: [NUT] from XDA
#
DoesFileExist() {
if [ -f "/tmp/killedric" ]; then
return 0
else
return 1
fi
}
# As the init.rc scripts seem to be running parallel, lets kill ric if it got started.
until DoesFileExist
do
RICCHECK=`$BUSYBOX ps | $BUSYBOX grep "/sbin/ric" | $BUSYBOX wc -l`
if [ $RICCHECK -gt 1 ]; then
$BUSYBOX pkill -f /sbin/ric
fi
if [ $RICCHECK -eq 1 ]; then
$BUSYBOX touch /tmp/killedric
fi
$BUSYBOX sleep 2
done
exit 0
This does a loop every 2 seconds and tries to pkill /sbin/ric. When successful it will exit.
To double check if these 2 scripts did their job you can check /tmp for 2 empty files:
- /tmp/remountedrootfs
and
- /tmp/killedric
If they exist, checking the processlist should end up empty when trying to find killric.sh, ctrlaltdel and /sbin/ric. If so, on a locked bootloader, you can now safely remount /system and rootfs (/) and survive it
This is my gift to the community, enjoy a trouble free root experience with it!
Thanks go to:
@DooMLoRD for the chat about the init process
@RoberM for testing and suggestions, he found out pkill does successfully kill the ric process in .307
@fards for the brainstorming in my .307 ROM thread
@Carceri for the brainstorming in my .307 ROM thread
Has this fix been implemented in latest dual boot recovery for locked boatloader?
Sent from my C6603 using xda app-developers app
shoey63 said:
Has this fix been implemented in latest dual boot recovery for locked boatloader?
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
No, but it will
XZDualRecovery 2.4 will get this fix as well.
In the mean time you can flash this just as well
Ok
Reason I ask is this:-
I Flashed stock .434, rooted it, flashed your dual boot recovery and did an OTA update to .253.
To my amazement, update worked, plus Root and your dual recovery were still intact! Also no reboot when accessing system as R/W:good:
I will apply your patch and see what happens when OTA for .307 comes through (eventually)
My phone switches off after the Xperia wave animation.
Facts:
Locked BL
on .253
Rooted
Did not have the R/W mount issue, but I flashed it anyway
Latest CWM/TWRP recovery
I have Fidelity V4 (If that is of any consequence here)
While flashing it detected that I had busybox (If that is of any consequence as well)
Restoring system from old backup fixed it.
Great job with fixing this and making it easy for other people to use in their ROMs.
At first I thought there was a problem with this fix due to a race condition: As far as I can see rootfs is mounted r/w before ric is killed, so I would expect that sometimes ric might start early, see that / is rw and reboot the phone. I was surprised that this did not happen, but actually it seems that ric does not check permissions on rootfs (I could mount it r/w with ric running without getting a reboot).
chmod 644 /sbin/ric is (for me at least) not just a failsafe. It is needed because otherwise ric keeps being respawned whenever it's killed giving another race condition where sometimes it might have time to reboot the phone before it is killed again.
So: This fix should work as long as ric behaves as it does on the kernel that comes with 307.
As I said I also made my own version of a fix in parallel. I wrote it in C as I needed access to some system calls. Basically it is an executable that can be run from whereever one wants to start a program. It runs as a daemon that waits for /sbin/ric to be started. Once it sees ric, it forces ric and itself to run on the same CPU, schedules itself with realtime priority on that CPU so ric never gets a chance to run, replaces the ric executable in /sbin/ric by a dummy version that justs sleeps and kills the original ric process. I could also have deleted it, but whatever respawns ric now don't have to try to start a new process all the time, since it will see that ric is still running.
I have tested my own solution for the past day or so and it seems to work fine. I'll probably post the binary and source code for it later.
008bond said:
My phone switches off after the Xperia wave animation.
Facts:
Locked BL
on .253
Rooted
Did not have the R/W mount issue, but I flashed it anyway
Latest CWM/TWRP recovery
I have Fidelity V4 (If that is of any consequence here)
While flashing it detected that I had busybox (If that is of any consequence as well)
Restoring system from old backup fixed it.
Click to expand...
Click to collapse
Hmm, maybe your ROM chef built in something that conflicts with this script. His own solution to RIC maybe?
Sent from my C6603 using xda app-developers app
[NUT] said:
Hmm, maybe your ROM chef built in something that conflicts with this script. His own solution to RIC maybe?
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
I'm using stock. I think the issue lies with me flashing Fidelity V4.0.
EDIT: I can confirm that Fidelity patch is the issue.
008bond said:
I'm using stock. I think the issue lies with me flashing Fidelity V4.0.
EDIT: I can confirm that Fidelity patch is the issue.
Click to expand...
Click to collapse
Cr*p, I'm out of thanks to give the usual way today, so:
Thanks for the useful info, you scared me a bit there
Carceri said:
Great job with fixing this and making it easy for other people to use in their ROMs.
At first I thought there was a problem with this fix due to a race condition: As far as I can see rootfs is mounted r/w before ric is killed, so I would expect that sometimes ric might start early, see that / is rw and reboot the phone. I was surprised that this did not happen, but actually it seems that ric does not check permissions on rootfs (I could mount it r/w with ric running without getting a reboot).
chmod 644 /sbin/ric is (for me at least) not just a failsafe. It is needed because otherwise ric keeps being respawned whenever it's killed giving another race condition where sometimes it might have time to reboot the phone before it is killed again.
So: This fix should work as long as ric behaves as it does on the kernel that comes with 307.
As I said I also made my own version of a fix in parallel. I wrote it in C as I needed access to some system calls. Basically it is an executable that can be run from whereever one wants to start a program. It runs as a daemon that waits for /sbin/ric to be started. Once it sees ric, it forces ric and itself to run on the same CPU, schedules itself with realtime priority on that CPU so ric never gets a chance to run, replaces the ric executable in /sbin/ric by a dummy version that justs sleeps and kills the original ric process. I could also have deleted it, but whatever respawns ric now don't have to try to start a new process all the time, since it will see that ric is still running.
I have tested my own solution for the past day or so and it seems to work fine. I'll probably post the binary and source code for it later.
Click to expand...
Click to collapse
The way i do the remount of / is no problem in 2 ways: it only remounts when really needed and as it is indirectly executed by init, it will never cause ric to intervene and trigger a reboot. If you have the reboot issue, remounting rootfs (/) from any root explorer app actually does cause a reboot.
About your ric killer application: nice! I've never programmed in C, otherwise I might have attempted something similar. But I know bash/ash scripting, so I fixed it the way I knew best
From my perspective you could make your daemon exit once it has killed /sbin/ric after changing it's permissions to 644. I've been testing my fix for a few days now (on stock kernel and re-locked bootloader) and the method in this thread completely prevents it from starting /sbin/ric ever again :victory:
My daemon does exit once it has killed ric and made sure it cannot start again.
Whatever respawns init keeps checking, so deleting the file, making it non executable or replacing it with a dummy all works. If you chmod 755 it again, ric does respawn on my phone, so something (probably init) keeps trying to start it if it isn't running.
On my phone (before killing ric) mounting / rw does not cause a reboot, but mounting /system rw does. Weird.
Carceri said:
My daemon does exit once it has killed ric and made sure it cannot start again.
Whatever respawns init keeps checking, so deleting the file, making it non executable or replacing it with a dummy all works. If you chmod 755 it again, ric does respawn on my phone, so something (probably init) keeps trying to start it if it isn't running.
On my phone (before killing ric) mounting / rw does not cause a reboot, but mounting /system rw does. Weird.
Click to expand...
Click to collapse
That would be init indeed, as it's a service without 'oneshot' (fires only once, then init stops monitoring) or 'disabled' (init never fires it but it waits for an explicit call to get that service started).
I've found a guide on the Android init daemon/process, I'll post a link to it in this thread tonight, it's an interesting read
I never tried to restart the init process to be able to disable the service though, might be attempting to do so some day. It is what the recoveries do with the chargemon hijack method, they stop all services, unmount everything, cleans up the ramdisk and then unpacks the recovery to start it's init binary.
I'll try that some time soon and see if that will work as well, that would probably be the cleanest way, it would render killric.sh and your application useless as they would no longer be needed, simplifying and 'niceifying' the entire process.
Yep, this fix works perfectly!
Flashed stock .307, unlocked bootloader, flashed @DooMLoRD kernel then rooted through recovery, flashed root fix, flashed stock .307 kernel and then restored TA partition.
Rebooted and used Root explorer in system with R/W permissions. No reboots
Congrats @[NUT] :good:
@Carceri
[NUT] said:
I never tried to restart the init process to be able to disable the service though, might be attempting to do so some day. It is what the recoveries do with the chargemon hijack method, they stop all services, unmount everything, cleans up the ramdisk and then unpacks the recovery to start it's init binary.
I'll try that some time soon and see if that will work as well, that would probably be the cleanest way, it would render killric.sh and your application useless as they would no longer be needed, simplifying and 'niceifying' the entire process.
Click to expand...
Click to collapse
I've been experimenting with that and so far I have not been very successful... apart from not working as i hoped (it reboots after the second init attempt), it also repeats a few parts of the boot process as crtlaltdel is executed too late during the init and thus it will allow you to enter recovery twice for example :silly:
It might be needed to re-hijack the chargemon process as this is executed precisely at the right time for this idea to work... but doing so will break compatibility with all available recoveries... and throws in some caveats for the recovery users... just the thing i was trying to fix for all and any of the Z/ZL lovers
Stuff to ponder on...
*ponders on* Maybe I can use the ctrlaltdel script to 'fix' anything that breaks and then trigger a reboot to make sure the user gets to boot in to a good working android...
chargemon would be my new rickiller script, it checks for the flagfile it creates itself, if it's not found it will do the RIC fix, then create's the flagfile and restarts init. With the second init it will find the flagfile and will execute the re-hijacked chargemon hijack script to offer recovery. If not chosen to enter recovery it will just continue boot.
Once ctrlaltdel gets started it checks if the md5sum of the chargemon script is what it's supposed to be. If not, it will create a backup of that chargemon file for execution by the re-hijacked chargemon script that it copies from a backup file somewhere (probably simply in /system/bin) corrects permissions and then triggers a reboot...
PRECAUTION: This post is on the file attached, it has no meaning regarding the OP: that fix works just fine.
Well, I'm putting my scripting online that i wrote on the above idea for those in the know, I'm not sure why it does not work but
THIS DOES NOT WORK
For anyone who wants to help out, you are welcome to take a look... you can even try it (put the 2 files inside /system/bin) but note the warning above...
To recover from the tantrum it throws, be sure to have an unlocked bootloader and DooMKernel installed. You will need TWRP to get you out of trouble, which is easy: mount system, use advanced -> filemanager and look inside /system/bin. chmod chargemon and ctrlaltdel to 644. Reboot and you're out of trouble.
Who has any idea why this does not work?
well, it sadly doesn't help me.. I'm on Odexed Stock ROM .307
if I try to rename / delete / add an apk into /system/app/ my phone still reboots..
FSN said:
well, it sadly doesn't help me.. I'm on Odexed Stock ROM .307
if I try to rename / delete / add an apk into /system/app/ my phone still reboots..
Click to expand...
Click to collapse
Can you check if there is a file called killedric in /tmp?
Sent from my C6603 using xda app-developers app
[NUT] said:
Can you check if there is a file called killedric in /tmp?
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
I don't have this file. Locked BL, flashed w/ TWRP 2.4.0.0
FSN said:
I don't have this file. Locked BL, flashed w/ TWRP 2.4.0.0
Click to expand...
Click to collapse
Right, then check things in succession, stop and report which you stopped at:
1. Check if /system/bin/killric.sh exists.
2. Open /system/bin/ctrlaltdel to see if it looks like the one on the OP.
3. Open a terminal app and see if killric.sh is running by typing the command 'ps | grep killric.sh'
If you have to say no to 1 and 2, reflash the zip. Then try again, if it still fails send me the logs from /cache/recovery
Sent from my C6603 using xda app-developers app
[NUT] said:
Right, then check things in succession, stop and report which you stopped at:
1. Check if /system/bin/killric.sh exists.
2. Open /system/bin/ctrlaltdel to see if it looks like the one on the OP.
3. Open a terminal app and see if killric.sh is running by typing the command 'ps | grep killric.sh'
If you have to say no to 1 and 2, reflash the zip. Then try again, if it still fails send me the logs from /cache/recovery
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
1. Yes
2. Yes
3. If it returns 1 it runs, right?
Could it have something to do with the exFAT patch (for 64GB sd cards)?
I am not responsible for any possible bad effects which may result from using included software! You flash it on your own risk!!!
STOCK RELOADED v1 fix 1
Kernel base: stock XXUANC3 (kernel 3.4.0-1131235)
Kernel ramdisk: modded
Features: a few...
Security level: low!
Purpose: giving everyone who loves free exploring of Android secrets and who doesn't consider security as an absolute priority and who wants to put some life in this, indeed, awesome device, a possibility of playing with his device without disturbing restrictions, forced by Samsung, at least until fully-custom kernels, compiled from sources, appear (and that may take some time, as source code available atm seems to be broken, causing all the compiled kernels to stuck at boot screen).
Features working out-of-the-box:
- su binary from SuperSU by Chainfire @ /sbin/su (binary only for scripting purposes! Flash cf-root to use SuperSU app!)
- busybox 1.22.1 binary compiled by Stericson @ /sbin/busybox
- init.d support - just put your favorite scripts into /system/etc/init.d using any file manager and chmod 755 (not 777! it's NOT smart to permit write access for "world" to any system file), chown root:root, they will run on every boot. Well, to be honest, above permissions are given to all the scripts automatically during boot, but it has not yet been tested
- SELinux: Permissive - Samsung's most recent policy of forcing SELinux Enforcing mode by pre-compiling it into a kernel binary part, found in latest KitKat builds since at least a few months, HACKED FOR THE FIRST TIME EVER using innovative method of injecting an information directly into kernel memory space and forcing overwriting potentially-persistent kernel symbol value on-line during boot!)
- unsecure adb access (not tested yet)
- ext4 tweak: 20 sec (instead of stock 5 sec) write commit delay for /data partition (significantly increases IO performance!)
- some further, minor modifications
WARNING!!!
- flashing this WILL undoubtly trip KNOX, avoiding your warranty (which atm cannot be reverted! in any way)
- flashing this WILL cause a warning message of avoided warranty to be displayed on every boot (ofc it disappears right after reverting to stock boot.img)
- flashing this WILL disable some of the very important security features provided with stock firmware!!!! For advanced and experienced users only!!! Use at your own risk!
Known issues:
- AllCast Share mirroring not working (typical for all Samsung devices running not-exactly-stock kernels since S3). WORKING FIX AT POST #16!!!
http://forum.xda-developers.com/showpost.php?p=54516532&postcount=16
Please consider solution from post #3 as not-always-working and depreciated!
Installation:
- compatibile with XXUANC3 firmwares but probably also with other (past and hope future too...) KitKat 4.4.2 Samsung branded firmwares;
- rooting by Chainfire's CF-Root first recommended as it will install SuperSU app in Android (this kernel contains su binary only giving su access without any policy settings!);
- enter download mode and plug the tablet via USB...
- ...select provided file in PDA section (and NOT touch anything except that)...
- ...and flash with Odin in a same way as CF-Root or like anything else...
- enjoy.
DOWNLOAD HERE:
Current version - STOCK RELOADED v1 fix 1
http://www63.zippyshare.com/v/87557346/file.html
FIXED: file name changed so it can be flashed directly by Odin without renaming! Sorry for this silly mistake!
=======
Changelog:
v1 fix1:
- fixed permissive mode due to trivial error;
- delayed init.d execution to a moment AFTER init process set cfq scheduler so it is not overriding mmcblk0 tweaks (if put in init.d) anymore;
- minor code cleanups
v1:
- initial release
- init.d support
- SELinux permissive
- unsecure ADB
- ext4 delayed commit for /data
=======
Stock XXUANC3 kernel (to revert changes)
http://www65.zippyshare.com/v/32441894/file.html
Revert using Odin, in the same way you've installed a Reloaded Version....
Awww man,...I wish i could flash this, but I'm on the exynos =(
Sent from my SM-P900 using Tapatalk
rgolnazarian said:
Awww man,...I wish i could flash this, but I'm on the exynos =(
Sent from my SM-P900 using Tapatalk
Click to expand...
Click to collapse
Sorry pal, Qualcomm only, not even a chance to run this same way as the devices (and mostly important: provided software, ie. system structure) DIFFER A LOT between themselves.
Update 1: uploaded fix #1 which is resolving some trivial issues found in initial version; sorry for that, now we can say that every described feature has been included hope for some feedback... thank you...
Update 2: FIX FOR NOT WORKING SCREEN MIRRORING CAN BE DOWNLOADED HERE:
http://www67.zippyshare.com/v/25492738/file.html
I have personally modified a library that is being used by screen mirroring feature, which forces video encryption using keys from stock kernel, and which prevents to run mirroring at all . This is an issue of any modified kernel, on any Samsung device. Attached library fixes this, by disabling HDCP at all. It has been reported that the library resolves the issue for any Qualcomm based Samsung device running 4.4.2 KitKat and for any custom kernel. It will NOT work for Exynos devices...
Installation:
- download attached libwfdsm.so file
- overwrite genuine one in/system/vendor/lib (important! NOT /system/lib!!!!)
- chmod 644 libwfdsm.so ||| chown 0.0 libwfdsm.so ||| restorecon -R /system/vendor/lib
- mirroring will work again after reboot!!
YAY!
Beautiful, absolutely beautiful. You made ma a very happy man with this. I'll flash this as soon as I get home from work. Can't wait to try it out, the stock kernel is giving me SOD and frozen wifi issues sometimes.
esgie said:
Sorry pal, Qualcomm only, not even a chance to run this same way as the devices (and mostly important: provided software, ie. system structure) DIFFER A LOT between themselves.
Update 1: uploaded fix #1 which is resolving some trivial issues found in initial version; sorry for that, now we can say that every described feature has been included hope for some feedback... thank you...
Update 2: FIX FOR NOT WORKING SCREEN MIRRORING CAN BE DOWNLOADED HERE:
http://www67.zippyshare.com/v/25492738/file.html
I have personally modified a library that is being used by screen mirroring feature, which forces video encryption using keys from stock kernel, and which prevents to run mirroring at all . This is an issue of any modified kernel, on any Samsung device. Attached library fixes this, by disabling HDCP at all. It has been reported that the library resolves the issue for any Qualcomm based Samsung device running 4.4.2 KitKat and for any custom kernel. It will NOT work for Exynos devices...
Installation:
- download attached libwfdsm.so file
- overwrite genuine one in/system/vendor/lib (important! NOT /system/lib!!!!)
- chmod 644 libwfdsm.so ||| chown 0.0 libwfdsm.so ||| restorecon -R /system/vendor/lib
- mirroring will work again after reboot!!
Click to expand...
Click to collapse
I was literally just about to post in the old thread with bad news about the modified "libwfdsm.so" file & screen mirroring with a custom kernel...if u remember i confirmed that the file u altered would work with a custom recovery on the 8.4 lte & i just assumed that it would work with an altered boot.img as well but unfortunately thats not the case after testing the other night (unless something else is wrong with my setup). So...my question is have u changed something else since then to allow it to work again & have u personally tested this yourself?
sorry to hijack the thread...didnt know if i should pm or post in the older thread
THEDEVIOUS1 said:
I was literally just about to post in the old thread with bad news about the modified "libwfdsm.so" file & screen mirroring with a custom kernel...if u remember i confirmed that the file u altered would work with a custom recovery on the 8.4 lte & i just assumed that it would work with an altered boot.img as well but unfortunately thats not the case after testing the other night (unless something else is wrong with my setup). So...my question is have u changed something else since then to allow it to work again & have u personally tested this yourself?
sorry to hijack the thread...didnt know if i should pm or post in the older thread
Click to expand...
Click to collapse
No problem, anyway, thanks for pointing the issue out! This may be an important information for mirroring users!
Since then I didn't change anything, yet. Really, I am also not sure if I have tested it with modified kernel, as the one posted here is the first kernel for P905 at all, and it's not even "fully" customized, as the kernel binary base was left unchanged.
So, I'd like to be sure: you are saying that modded lib:
- fixed the problem for custom recovery, but...
- ...didn't fix it for custom kernel
right?
I was looking for a solution to persistent enforcing mode since some time, so I was flashing test boot.imgs from time to time, then reverting to stock again, meanwhile I created above lib, I can't really be sure about if it is working when both bootimg and kernel are customized (this would also be an opposite to previous Sammy's Android releases, where a single fix was solving all the issues related to customizations of both kernel and recovery!).
We also have to be aware that the issues may not be a result of flashing different kernel at all, but a result of the changes themselves, ie. disabled knox, disabled encryption of i-dont-really-know-what, etc, etc.
And the most important thing! Since I have heard of AllShareCast/Screen Mirroring for the first time (it probably appeared for the first time in S3/Note2/Note10.1), it always required resetting the flash counter - which could be viewed in download mode and which is NOT the same as Knox flag - to ZERO and that requirement AFAIR remained totally independent from the requirement of having stock boot/kernel (or lib patch). Have you checked the counter state? Did you reset it to zero again using Chainfire's Triangle Away after flashing non-stock kernel (which, obviously, TRIPPED the counter)? Can you check if it is working? Note that at least on my P905, Triangle Away still works flawlessly and resets the counter without any problems and even without a need of reboot!
Please check above info and try if the issue is fixed after running Triangle Away. I am leaving for a short business trip soon, so I'll perform my own tests with AllShare cast until next of the week, however, neither today nor tomorrow...
I get an "md5 error! binary is invalid" when I choosse the file in Odin. I downloaded the file 6 times, and every time I get the md5 error.
What do I do?
EDIT: Renaming the file to "boot.tar.md5" seemed to solve the problem.
cavkic said:
I get an "md5 error! binary is invalid" when I choosse the file in Odin. I downloaded the file 6 times, and every time I get the md5 error.
What do I do?
EDIT: Renaming the file to "boot.tar.md5" seemed to solve the problem.
Click to expand...
Click to collapse
Argh possibly too many dots in filename... will correct it tomorrow.
cavkic said:
I get an "md5 error! binary is invalid" when I choosse the file in Odin. I downloaded the file 6 times, and every time I get the md5 error.
What do I do?
EDIT: Renaming the file to "boot.tar.md5" seemed to solve the problem.
Click to expand...
Click to collapse
same here...
Hi,
I have a problem with screen mirroring.
Installed the patch and mirroring connects to the dongle, but the TV screen turns just black.
The dongle works perfect with HTC One M8, it must be a softwareproblem?
Thanks for help!!!
Will this work on the P905V (Verizon Variant)? I need to downgrade the permissions in my Security in order to use Towelroot, because they're set to Medium and I believe that prevents Towelroot to work properly. Most of the other Note 12.2 variants have been rooted....except the Verizon version.
Can anyone give me some advice please. When I enter the command in terminal emulator I get an error saying "Unable to open chown. No such file or directory". Am I missing something obvious lol.
Will this work on p907a AT&T version of note pro 12.2?
Sent from my SAMSUNG-SM-P907A using XDA Premium 4 mobile app
cnote74 said:
Will this work on p907a AT&T version of note pro 12.2?
Sent from my SAMSUNG-SM-P907A using XDA Premium 4 mobile app
Click to expand...
Click to collapse
On the topic name it says [P905 LTE ONLY], and your device is some different..
tdetroit said:
Will this work on the P905V (Verizon Variant)? I need to downgrade the permissions in my Security in order to use Towelroot, because they're set to Medium and I believe that prevents Towelroot to work properly. Most of the other Note 12.2 variants have been rooted....except the Verizon version.
Click to expand...
Click to collapse
I would like this answered as well. I also have the "v" variant. Maybe saying LTE includes many? See my link I attached, found while investigating this specific question.
http://www.usatoday.com/story/tech/2013/07/07/sprint-att-verizon-phones-network-carriers/2486813/
Ever since I rooted my tablet it goes on random reboot kicks. I want to start over. Also TWRP will not stick when I try to flash it.
I have many issues which I'm currently posing in their appropriate forums. It would be nice to wipe to a rooted stock.
Guys!
I have probably found another solution for non-working Screen Mirroring / AllShare Cast when custom kernel is flashed (again, LTE devices only).
No need of modded lib
Seems that the only thing we need is to
1) run Terminal Emulator and type:
Code:
su -c setprop wlan.wfd.hdcp disable
(will work immediately; won't stick between reboots!), OR...
2) edit /system/build.prop file with any root file manager/text editor and add a line (no matter where):
Code:
wlan.wfd.hdcp=disable
(will work only after reboot; will stick between reboots).
Try this using kernel from op waiting for feedback!
Thanks. The Galaxy is connecting to theTV, but the screen is only turning black - no Display...
Any idea?
Thank you.
esgie said:
Guys!
I have probably found another solution for non-working Screen Mirroring / AllShare Cast when custom kernel is flashed (again, LTE devices only).
No need of modded lib
Seems that the only thing we need is to
1) run Terminal Emulator and type:
Code:
su -c setprop wlan.wfd.hdcp disable
(will work immediately; won't stick between reboots!), OR...
2) edit /system/build.prop file with any root file manager/text editor and add a line (no matter where):
Code:
wlan.wfd.hdcp=disable
(will work only after reboot; will stick between reboots).
Try this using kernel from op waiting for feedback!
Click to expand...
Click to collapse
esgie said:
Guys!
I have probably found another solution for non-working Screen Mirroring / AllShare Cast when custom kernel is flashed (again, LTE devices only).
No need of modded lib
Seems that the only thing we need is to
1) run Terminal Emulator and type:
Code:
su -c setprop wlan.wfd.hdcp disable
(will work immediately; won't stick between reboots!), OR...
2) edit /system/build.prop file with any root file manager/text editor and add a line (no matter where):
Code:
wlan.wfd.hdcp=disable
(will work only after reboot; will stick between reboots).
Try this using kernel from op waiting for feedback!
Click to expand...
Click to collapse
I tried both methods and still get no devices found when I turn on screen mirroring.
ColBill said:
I tried both methods and still get no devices found when I turn on screen mirroring.
Click to expand...
Click to collapse
Hm.
This is weird, as the problems with allshare cast + custom kernels is not that "no devices are found" but that devices ARE found without any problem but the connection process fails after a few secs. This solution may help with the issue i described, but it will surely not solve the problem with no peers detected at all.
No peers detected = problems with wifi direct (are you able to send files between wifi direct between devices?)
Can you tell me what is your exact device config? And are you using allsharecast dongle or other third party hardware?
@fokus
Only one: also reset flash counter with Triangle Away and then try again. And make sure you spell the value in the command as "disable" not "disabled" - it's tricky and one can miss it...
Well, there are two additional things to add.
Guys, make sure you have updated Samsung's ScreenMirroring firmware update app to the latest version. And check out the samsung mirroring fix app in google play, which solves some issues for various devices (dunno which ones exactly as i have never been in need of using it).
The fix half worked for me lol. The tablet now connects fine to the Netgear PTV3000 but all I get is black screen. Step in the right direction though as at least it connects now. Just need to get a picture to show lol.
Hi @Chainfire,
So, a while ago, I posted in the Liveboot thread inquiring as to how I'd go about incorporating liveboot into a ROM so that it could just run on first boot.
Your instructions were to chmod 0770 both the files and folders in su.d, and it should work:
If /system/su.d/0000liveboot.script exists (chmod 0644, not 0700 like other files in /system/su.d/ !), this script will be run instead of logcat and dmesg, and its output will be shown in white (stdout) and red (stderr).
Click to expand...
Click to collapse
However, I tried this, and never got it to work, and essentially moved on to other stuff for a while.
Today, I tried to revisit it, and while I was at it, replace my current init.d stuff with su.d.
So, I created the folder in /system which gets copied with t he rest of the ROM on install. I'm setting folder and file permissions to 0700, owner and group to root, SE context to ubject_r:system_file:s0, which, is exactly the same as what I'm seeing on 0000liveboot when I look at it's info.
This leaves two questions.
One, the above quote you say to set it to 0644, but liveboot itself sets it to 0700 when it installs it.
Two, what is the trick to getting other scripts to work? In your "How to SU" guide, you mention this:
From versions 2.22 onwards, after the policies have been patched and the daemon is ready to go, all executables in the /system/su.d/ directory are executed (chmod 0700 both the directoy and the scripts), followed by setprop supolicy.loaded 1. This is akin to /system/(etc/)init.d/, though execution of those scripts is both kernel-dependent and they may run before the SELinux are patches and/or su is available.
Click to expand...
Click to collapse
Setprop supolicy.loaded. Where am I supposed to do that? You say execution of those scripts is kernel-dependent - you're referring to init.d, yes? So, again, what am I missing?
This is 5.0.1 GPE for M8VZW. I have selinux set to permissive via boot image in init.rc, and verify that "getenforce" returns "permissive" from shell.
Any help you could lend would be greatly appreciated - which is also why I'm posting this as a thread...because su.d sounds like an awesome idea, and I bet more devs would like to start using this method over init.d.
Thank!
digitalhigh said:
One, the above quote you say to set it to 0644, but liveboot itself sets it to 0700 when it installs it.
Click to expand...
Click to collapse
liveboot sets the script that gets run by SuperSU to 0700. The script which I said to be set 0644 is a different script, and is not executed by SuperSU, but by liveboot.
Setprop supolicy.loaded. Where am I supposed to do that?
Click to expand...
Click to collapse
You don't. SuperSU sets this. Kernel developers can hook this event to run their own code.
You say execution of those scripts is kernel-dependent - you're referring to init.d, yes?
Click to expand...
Click to collapse
Yes, not all kernels support init.d, and init.d stuff generally runs before SuperSU patches policies, so there's no guarantees about any SELinux state.
So, again, what am I missing?
Click to expand...
Click to collapse
I don't know. Make sure you are running the latest version of SuperSU (2.46 at the time of writing). Make sure /system/su.d is chmod 0700. Make sure the scripts you want to run are also chmod 0700 and #!'d to a working shell executable. Keep in mind that the scripts are called one-by-one, in a blocking way. So if a script never exits, the next script isn't run.
Deleted
Say I have SU v2.62. I have 2 files in my /system/su.d folder. The first file doesn't have an exit, neither does the second. The second file DOES get executed as it sets selinux to permissive at boot as directed. First file is 0700 (text file), second is 0755 (a .sh file).
Now, I want to take an init.d setprop script and try it via su.d.
1) Do the other files need exit commands?
2) What should the third file (setprop file) be set to, 0755? A .sh or text file?
3) Are the other two set to the correct chmod?
Thank you for any input!
EDIT: Left it as text, and 0755. No exits, and it worked?
Using su.d to disable doze
Is it possible to use su.d in order to load a script that disables Android doze mode?
I'm trying to run this script:
Code:
#!/system/bin/sh
dumpsys deviceidle disable
Script file is located in root\su\su.d
Permissions are set to 0700.
However, script is not loaded automatically during the boot, because if I run the script manually in SManager I get a response Idle mode disabled, which means su.d script wasn't loaded.
Currenlty I use SManager to execute this doze disabling script automatically on every boot, but I wonder why wouldn't the same script work using su.d?
I use another su.d script that disables LED back-lights of hardware navigation buttons and the script works just fine.
I'm using SuperSU v2.82
Thanks for your input.
THIS THREAD IS FOR DEVELOPERS ONLY. IF YOU ARE NOT A DEVELOPER (or very tech-savvy and well-versed), MOST LIKELY YOU SHOULD NOT POST HERE.
By request, I am creating this thread for developer discussion. This is the place for developers to ask questions about how to handle/implement/embed SuperSU, discuss the operation of SuperSU, suggest improvements to compatibility, etc.
This thread hopefully reduces important developer related matters from being buried in the more user-oriented threads.
Please always include the version number of SuperSU you are referring to, even if it's the latest version right now. If applicable, also include information about phone and firmware you are testing with.
Chainfire said:
The stop-gap solution is to disable this caching completely, which is what the 000000deepsleep script does, which you can find mentioned or quoted in many posts around the forum. From SuperSU 2.66 onwards, that script is automatically installed on Samsung devices when systemless root is used.
Click to expand...
Click to collapse
Please forgive me for posting (in a cf-auto-root thread) and digging afterwards. I had thought I'd just dump the info and forget about it, but I couldn't stop digging...
...which led me to the quoted material.
Digging in the supersu 2.66 update-scriptbinary, I see that you're detecting "samsung" in the build fingerprint, and if true, doing a systemless install AND applying a deepsleep fix. This works for Galaxy S6 devices, but not for some other similar platform devices. In particular, the Note5 has THREE devices that need caching disabled in order for deep sleep to function. (0:0:0:3 as well as :2 and :1.)
My first question is: does the SGS6 even have a file named "/sys/class/scsi_disk/0:0:0:3/cache_type"? If not, just write to all three files and don't worry about it. The third write would fail on the SGS6 and all would be good. It'd be no worse of a work-around than already exists (and I think it's a bad work-around.)
If that file DOES exist in the SGS6, then something would have caching turned off that really shouldn't. Of course, existing or not, automatically tossing in this deepsleep patch for every single device that has "samsung" in the build fingerprint would seem likely break proper caching in some yet unknown samsung device. Perhaps the SGS7 will change things up so that :1 should be left cache flushable, and :2 would be the only one that should block cache flushing.
As well, it's also possible that Samsung will pull in the kernel fix to resolve this issue before they release Android M. (Okay, perhaps it'd be more likely for Samsung to open source touchwiz... but we can always have fantasies.)
My problem with the work-around is expressed above: it can break something in the future (and cause a support headache when some ONE exynos7420 device is fixed, but the rest aren't.) As well, it sets precedent of having platform specific hacks in the generic update.zip (but only allowing for a single platform and not in an easily expandable way.)
Obviously, it would be a maintenance nightmare to have different "00000deepsleep" files for every different device model. (if 'zerolte.*', SGS6. If 'nobellte.*', Note5, etc.)...
In keeping with what I tell other people, I feel I now have an obligation to suggest A Better Way. (a person shouldn't complain about something unless they can make a reasonable suggestion on how it'd be better.)
So, here's my slightly convoluted (but expandable) suggestion:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
Code:
echo PLATFORMSTARTUP='echo "temporary none" > /sys/class/scsi_disk/0:0:0:1/cache_type' >> /data/.supersu
(I'd have included both (or all three) needed lines for samsung deep sleep, but I forget how to include CR in a shell cmdline.. )
Then, the supersu installer script would just read PLATFORMSTARTUP and write it's contents to /su/su.d/00000platformstartup (and set perms.)
Given this type of thing, the existing 000000deepsleep hack would be removed. Then, individual devs could easily create simplistic "pre-installers" for supersu for specific platforms that need changes. Those "pre" installers would just write the needed PLATFORMSTARTUP lines to /data/.supersu...
... and then supersu.zip no longer needs platform specific hacks.
Some random XDA developer could then generate a simple "SGS6-supersu.zip" would only contain an edify script to mount /data and add/edit the .supersu file's PLATFORMSTARTUP variable to contain the two lines needed for deep sleep (and another dev could write a Note5 for the 3 lines needed on that platform... and so on..)
Take care
Gary
garyd9 said:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
...
Click to expand...
Click to collapse
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep. The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
NZgeek said:
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep.
Click to expand...
Click to collapse
The problems with the existing solution are:
1. It blindly alters the system kernel behavior for every single device samsung manufactures.
2. It only actually does any good for a single one of the dozens of devices from that sam manufacturer.
3. It completely ignores every OTHER device that might need a bit of help (and potentially does more harm than good for those devices.)
4. It encourages device developers (users on XDA) to download SuperSU.zip and re-package it to have device specific hacks in the .zip archive (creating a mess.)
Actually, I don't think I need to explain all the problems with the existing hack. I'd imagine (hope) that it was done as something quick to test out an idea, and was never intended to be left in place in it's current form.
NZgeek said:
The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
Click to expand...
Click to collapse
Which 5 devices? Who maintains that list? Who updates it for each firmware change that might require an update? Will there be a new "SuperSU.zip" package each time a firmware change on a device requires that one of those 5 be changed? Who deals with the support nightmare of saying "use SuperSU v a.bc for device X firmwawre Y" and "superSU v d.ef for device X firmware Z", etc?
My proposed solution takes all the device-specific stuff completely out of the SuperSU package. It changes it from a device-specific solution to be a more generic and expandable solution that requires LESS support from SuperSU and places the device specific burden outside.
Instead of encouraging device developers to repackage supersu to device specific packages, it encourages device developers to package something else alongside supersu that would work with the existing (and unaltered) supersu.zip (and would be future compatible.)
Take care
Gary
spiral777 said:
would there be a way to get kexec/ multirom working with systemless root?
and would flashing a modified boot image to a rom also effect the kexec hardboot partch of the kernel?
Click to expand...
Click to collapse
1- the current versions of systemless root make changes/additions to the kernel, but you're not "flashing a modified boot img", so kexec is not broken, since the kernel is in essence the same as before
2- yes it is possible for systemless root (tested with 2.65) to get it working on multirom, however some changes were needed; we're still debugging the problem to try to narrow down the issue, to get it to work with as little changes as possible
EDIT: I'll just mention the problems encountered in case @Chainfire wants to be aware of them
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
EDIT2: thanks @Captain_Throwback for the reminder
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
just FYI, but I'll check more thoroughly when I get a chance
@garyd9 @NZgeek
Some good points are raised. I am not going to go into them all individually.
There is one core point of disagreement though. While I do not think device-specific patches generally have a place in the SuperSU ZIP installer, the deep sleep issue affects so many million users it is too big to ignore. (By the way, as far as I know this issue affects all recent high-end Samsungs).
While I don't disagree with your ideal of custom pre/post installers, in reality most users will never discover the issue, and just blame SuperSU for suddenly bad battery life. This leads to many support emails, thread posts, bad rep, etc.
Contrast this to for example the LG G3 compatibility patch, which requires the user to indeed write a file to /data or use a pre-installer that does that, the device will simply not boot, which forces the user to either go back to stock, or search for and discover the fix.
Either way, you are right, the patch doesn't even work right for Note users. Thank you for pointing that out - nobody else ever did. I have come up with the following improved script. If for the moment, we put aside our differences regarding the inclusion of any device-specific fixes, what do you think of the following?
It will perform the cache_type change for any scsi_disk, but will skip the ones not set to write protected. This should catch the problem with devices that have a different disk layout, and prevent accidental reduced I/O speed for devices that are not affected.
Note that it is my understanding that the write protection mode cannot be reset without a flash chip power cycle, and as the protection is set by the bootloader long before our check, checking once at boot should suffice.
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Chainfire said:
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Click to expand...
Click to collapse
I won't be able to properly test this until at least tomorrow (Wed) evening... However, in the meantime, the following screenshots suggest that it'd also work on the Note5:
https://goo.gl/photos/61JWzoA5ir3PcDNr9
(This is with a custom kernel, however. I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Let me know when you'd like to debate on if SuperSU should fix (non-root related) bugs in only specific devices, all devices, no devices, or if it should just support a hook to allow third parties to fix both current and future/past devices. (Please don't get the wrong impression from that statement. SuperSU is your product, not mine... However you implement things is up to you.)
Please do let me know if I can be of further assistance to fix compatibility.
nkk71 said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
Click to expand...
Click to collapse
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
Click to expand...
Click to collapse
Where is this?
Chainfire said:
Please do let me know if I can be of further assistance to fix compatibility.
Click to expand...
Click to collapse
Thank you, I will let you know once I've had a chance to properly debug further
I initially only wanted to get systemless root to work, which using the workarounds (even though not ideal), was proof it can be done
(at the time it was SuperSU v2.65)
Chainfire said:
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
No need to take double symlinks into account, only the real one is changed as follows:
the real one is renamed with a "-orig" extension, and a symlink is created to an imaginary normal file:
Code:
cd [B][COLOR="Blue"]/dev/block[/COLOR][/B]
ls -l
...
brw------- 1 root root 259, 24 Jan 12 18:18 mmcblk0p40
brw------- 1 root root 259, 25 Jan 12 18:18 mmcblk0p41
[B]lrwxrwxrwx 1 root root 67 Jan 12 18:19 mmcblk0p42 -> /realdata/media/0/multirom/roms/HTC_One_M8_GPe_Marshmallo1/boot.img[/B]
[B]brw------- 1 root root 259, 26 Jan 12 18:18 mmcblk0p42-orig[/B]
brw------- 1 root root 259, 27 Jan 12 18:18 mmcblk0p43
...
all other symlinks to the block device remain as is:
Code:
cd[B][COLOR="Blue"] /dev/block/platform/msm_sdcc.1/by-name[/COLOR][/B]
ls -l
...
lrwxrwxrwx 1 root root 21 Jan 12 18:18 adsp -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 Jan 12 18:18 board_info -> /dev/block/mmcblk0p3
[B]lrwxrwxrwx 1 root root 21 Jan 12 18:18 boot -> /dev/block/mmcblk0p42[/B]
lrwxrwxrwx 1 root root 21 Jan 12 18:18 cache -> /dev/block/mmcblk0p46
...
Chainfire said:
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Will check, thanks.
Chainfire said:
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
Click to expand...
Click to collapse
Not really, everything else in init.rc get's executed properly; (and obviously the in launch_daemonsu.sh as well)
Chainfire said:
Where is this?
Click to expand...
Click to collapse
at the beginning of launch_daemonsu.sh:
Code:
if [ ! -d "/su/bin" ]; then
# if we fstab'd system/vendor/oem to rw, remount them ro here
remount_ro /system
remount_ro /vendor
remount_ro /oem
^^ I commented all three of them out, which worked out fine.
MultiROM's secondary ROMs always have system mounted rw, and the above remount_ro will force an immediate reboot
I need to do further testing on these issues, as soon as I come up with something more concrete, I will report back.
EDIT: forgot to mention, can confirm this for the HTC One M7, M8 and M9
garyd9 said:
I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Click to expand...
Click to collapse
So, two replies. I've edited the results to just show the device and value of write_protect. The first one is a KNOX tripped device with completely stock firmware/kernel (no root):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 1
scsi_disk/0:0:0:2 1
scsi_disk/0:0:0:3 1
The second is from a stock device where KNOX has never been tripped (the results are expected, but nice for confirmation):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 0
scsi_disk/0:0:0:2 0
scsi_disk/0:0:0:3 0
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
garyd9 said:
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
Click to expand...
Click to collapse
Knock yourself out. I'm not in a rush though. I don't expect to release another update for another few days at least.
Chainfire said:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Click to expand...
Click to collapse
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
dr.ketan said:
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
Click to expand...
Click to collapse
I don't know, since you changed it up, and your statement is a bit confusing.
Try this:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo Write protected: $i
else
echo Write enabled: $i
fi
done
Copy/paste the output.
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
dr.ketan said:
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
Click to expand...
Click to collapse
That's not needed, just run the other script I pasted above. It'll show what we need to know regardless of your kernel being patched or not.
[email protected]lelte:/ $ su
[email protected]:/ # ls -l /sys/class/scsi_disk/
lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:0 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:1 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:1/scsi_disk/0:0:0:1lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:2 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:2/scsi_disk/0:0:0:2lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:3 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:3/scsi_disk/0:0:0:[email protected]:/ # cat /sys/class/scsi_disk/*/write_protect
0
1
1
1
[email protected]:/ #
dr.ketan said:
...
Click to expand...
Click to collapse
Seems fine!
I had some time to check a few things, so please find below my findings / possibly solutions
Chainfire said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
Fixed it by using the following code (perhaps the readlink -f is redundant, but it worked fine)
(at line 1199 of SuperSU 2.66 updater-binary):
Code:
if [ -b `readlink -f $BOOTIMAGE` ]; then
dd if=/dev/zero of=$BOOTIMAGE bs=4096
fi
Chainfire said:
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Turns out the loop device was in fact the problem; after umount /su, it still showed:
Code:
~ # [6n[B]losetup -a[/B]
losetup -a
/dev/block/loop0: 0 /data/su.img
so I just used/added (at line 1218 of SuperSU 2.66 updater-binary)
Code:
umount /su
[B]losetup -d /dev/block/loop0[/B]
I know it was on loop0 so I didnt need to account for anything else, but maybe using
Code:
LOOPDEVICE=`losetup -f`
or something similar, and continuing from there could be an option
Haven't tried checking on the other issues, but will report back when I have something on those
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
nkk71 said:
I had some time to check a few things, so please find below my findings / possibly solutions
Click to expand...
Click to collapse
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 ...
garyd9 said:
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
Click to expand...
Click to collapse
Good news, as expected.
Hello, i had read many things at the forum but i still very confused. .please in a simple answer, which one is the correct and the download link. .please i can damage my cel.
Hgt45 said:
Hello, i had read many things at the forum but i still very confused. .please in a simple answer, which one is the correct and the download link. .please i can damage my cel.
Click to expand...
Click to collapse
Hello,
first i am not sure that u are in the right forum section.
About your demand, you haven't mention the CPU arch of your phone and have you reboot in custom recovery to flash the downloaded zip ?
Rom said:
Hello,
first i am not sure that u are in the right forum section.
About your demand, you haven't mention the CPU arch of your phone and have you reboot in custom recovery to flash the downloaded zip ?
Click to expand...
Click to collapse
Hello Lyon, hope everything happy... well, i don't know if its the right fórum,, here the info:
SYSTEM: SDK versión 6.0.1 ID:MMB29M OS name: Linux OS versión:3.10.40-9120850 Dalvik VM versión: 2.1.0
DEVICE: Model: SM-N910P Product: trltespr Board:APQ8084 Brand: Samsung Fingerprint: Samsung/trltespr/trltespr:6.0.1/MMB29M/N910PVPS4DQD1:user/reléase-keys
CPU: Name: ? Current freq.: 1958.4MHz Max freq.: 2649.6MHz Min freq.: 300MHz Cores: 4
Architecture: 7 BogoMIPS:38.40 Hardware: Qualcomm APQ8084 Revisión: 1
Serial #:0000000000000000
Memory
Total:2845492kbB Free:97792kB Inactive:896648kB
I haven't reboot in custom recovery to flash the downloaded zip XposedInstaller_by_dvdandroid.apk because of the warning its shows ( i send the pictures ).. i don't want to damage my note 4.. its the righ one ?
If you or anyone can help me to easy way to do it..
1- is,, XposedInstaller_by_dvdandroid.apk ? safe to run in custon recovery ? i Yes, how to, if No, which one to download it.
Regards.
H.
Hgt45 said:
Hello Lyon, hope everything happy... well, i don't know if its the right fórum,, here the info:
SYSTEM: SDK versión 6.0.1 ID:MMB29M OS name: Linux OS versión:3.10.40-9120850 Dalvik VM versión: 2.1.0
DEVICE: Model: SM-N910P Product: trltespr Board:APQ8084 Brand: Samsung Fingerprint: Samsung/trltespr/trltespr:6.0.1/MMB29M/N910PVPS4DQD1:user/reléase-keys
CPU: Name: ? Current freq.: 1958.4MHz Max freq.: 2649.6MHz Min freq.: 300MHz Cores: 4
Architecture: 7 BogoMIPS:38.40 Hardware: Qualcomm APQ8084 Revisión: 1
Serial #:0000000000000000
Memory
Total:2845492kbB Free:97792kB Inactive:896648kB
I haven't reboot in custom recovery to flash the downloaded zip XposedInstaller_by_dvdandroid.apk because of the warning its shows ( i send the pictures ).. i don't want to damage my note 4.. its the righ one ?
If you or anyone can help me to easy way to do it..
1- is,, XposedInstaller_by_dvdandroid.apk ? safe to run in custon recovery ? i Yes, how to, if No, which one to download it.
Regards.
H.
Click to expand...
Click to collapse
I don't see your CPU arch in your details, you are in the wrong forum section and on Android 5.0+ you must flash your zip in custom recovery.
Rom said:
I don't see your CPU arch in your details, you are in the wrong forum section and on Android 5.0+ you must flash your zip in custom recovery.
Click to expand...
Click to collapse
Thank you ROM,,for answer me, sorry I'm not an experienced tech... . and I'm afraid to flash zip in custom recovery mode if is not the right one,, in other words, I haven't did before, I just install framework in my S4 with no problems before. ..
I find out CPU arch: ARMv7-A Qualcomm APQ8084 ,,etc,, see attachment.
Please could you please tell me and help me ?....
If someone move these Thread to the right place. .
Sorry if I'm bothering
Regards
H.
Hgt45 said:
Thank you ROM,,for answer me, sorry I'm not an experienced tech... . and I'm afraid to flash zip in custom recovery mode if is not the right one,, in other words, I haven't did before, I just install framework in my S4 with no problems before. ..
I find out CPU arch: ARMv7-A Qualcomm APQ8084 ,,etc,, see attachment.
Please could you please tell me and help me ?....
If someone move these Thread to the right place. .
Sorry if I'm bothering
Regards
H.
Click to expand...
Click to collapse
Hello,
Apparently your CPU is an arm32 bits processor, so dl the last zip from this page:
http://dl-xda.xposed.info/framework/sdk23/arm/
And flash it via custom recovery.
After flash the zip, reboot in classic mode and check again by opening XPosed Installer app.
Rom said:
Hello,
Apparently your CPU is an arm32 bits processor, so dl the last zip from this page:
http://dl-xda.xposed.info/framework/sdk23/arm/
And flash it via custom recovery.
After flash the zip, reboot in classic mode and check again by opening XPosed Installer app.
Click to expand...
Click to collapse
Hello Rom, wishing your are very happy...
look the picture and see what is happening..
Overall Status: Congratulations! This device has root access!
Feedback
Stage 1 - Superuser App: Installed
Installed: SuperSU by Chainfire - version 2.82
Stage 2 - Superuser Binary Files: Installed
Standard System-less Location
Command: ls -l /su/bin/su
Result: -rwxr-xr-x root root 75352 2017-09-22 16:39 su
Version: 2.82:SUPERSU
Analysis: Root access IS correctly configured for this file! Executing this file can grant root access! Root user ownership is present and setuid attribute is not present.
Standard System Location
Command: ls -l /system/bin/su
Result: /system/bin/su: No such file or directory
Analysis: File /system/bin/su does not exist.
Standard System Location
Command: ls -l /system/xbin/su
Result: /system/xbin/su: No such file or directory
Analysis: File /system/xbin/su does not exist.
Alternative Location
Command: ls -l /sbin/su
Result: /sbin/su: Permission denied
Analysis: File system permissions restricted and denied access.
Alternative Location
Command: ls -l /system/sbin/su
Result: /system/sbin/su: No such file or directory
Analysis: File /system/sbin/su does not exist.
Alternative Location
Command: ls -l /system/xbin/sudo
Result: /system/xbin/sudo: No such file or directory
Analysis: File /system/xbin/sudo does not exist.
Alternative Location
Command: ls -l /magisk/.core/bin/su
Result: /magisk/.core/bin/su: No such file or directory
Analysis: File /magisk/.core/bin/su does not exist.
Alternative System Environment Location
Command: ls -l /vendor/bin/su
Result: /vendor/bin/su: No such file or directory
Analysis: File /vendor/bin/su does not exist.
Alternative System Environment Location
Command: ls -l /su/xbin/su
Result: /su/xbin/su: No such file or directory
Analysis: File /su/xbin/su does not exist.
Stage 3 - Root User Account: Success
Root user id: uid=0(root)
Root group id: gid=0(root) groups=0(root)
Root SELinux context: context=u:r:init:s0
Optional - ADB Shell User
Status: Non-Root Shell User
Setting stored in /default.prop and configured as: ro.secure=1
Additional - Google SafetyNet Status
SafetyNet Status: False
Google evaluates hardware and software against Android specifications
Additional - System Environment PATH
System Environment PATH: /su/bin /sbin /vendor/bin /system/sbin /system/bin /su/xbin /system/xbin
Results provided for your SM-N910P - Android 6.0.1 device by Root Checker Pro version 6.1.5 from joeykrim in Google Play - http://goo.gl/NcnHn
thanks..
h.
Hgt45 said:
Hello Rom, wishing your are very happy...
look the picture and see what is happening..
Overall Status: Congratulations! This device has root access!
Feedback
Stage 1 - Superuser App: Installed
Installed: SuperSU by Chainfire - version 2.82
Stage 2 - Superuser Binary Files: Installed
Standard System-less Location
Command: ls -l /su/bin/su
Result: -rwxr-xr-x root root 75352 2017-09-22 16:39 su
Version: 2.82:SUPERSU
Analysis: Root access IS correctly configured for this file! Executing this file can grant root access! Root user ownership is present and setuid attribute is not present.
Standard System Location
Command: ls -l /system/bin/su
Result: /system/bin/su: No such file or directory
Analysis: File /system/bin/su does not exist.
Standard System Location
Command: ls -l /system/xbin/su
Result: /system/xbin/su: No such file or directory
Analysis: File /system/xbin/su does not exist.
Alternative Location
Command: ls -l /sbin/su
Result: /sbin/su: Permission denied
Analysis: File system permissions restricted and denied access.
Alternative Location
Command: ls -l /system/sbin/su
Result: /system/sbin/su: No such file or directory
Analysis: File /system/sbin/su does not exist.
Alternative Location
Command: ls -l /system/xbin/sudo
Result: /system/xbin/sudo: No such file or directory
Analysis: File /system/xbin/sudo does not exist.
Alternative Location
Command: ls -l /magisk/.core/bin/su
Result: /magisk/.core/bin/su: No such file or directory
Analysis: File /magisk/.core/bin/su does not exist.
Alternative System Environment Location
Command: ls -l /vendor/bin/su
Result: /vendor/bin/su: No such file or directory
Analysis: File /vendor/bin/su does not exist.
Alternative System Environment Location
Command: ls -l /su/xbin/su
Result: /su/xbin/su: No such file or directory
Analysis: File /su/xbin/su does not exist.
Stage 3 - Root User Account: Success
Root user id: uid=0(root)
Root group id: gid=0(root) groups=0(root)
Root SELinux context: context=u:r:init:s0
Optional - ADB Shell User
Status: Non-Root Shell User
Setting stored in /default.prop and configured as: ro.secure=1
Additional - Google SafetyNet Status
SafetyNet Status: False
Google evaluates hardware and software against Android specifications
Additional - System Environment PATH
System Environment PATH: /su/bin /sbin /vendor/bin /system/sbin /system/bin /su/xbin /system/xbin
Results provided for your SM-N910P - Android 6.0.1 device by Root Checker Pro version 6.1.5 from joeykrim in Google Play - http://goo.gl/NcnHn
thanks..
h.
Click to expand...
Click to collapse
Hello,, any sugestion. ?
Have a great day.
H.
: (
Sent from my SM-N910P using Xposed Modules
Hgt45 said:
: (
Sent from my SM-N910P using Xposed Modules
Click to expand...
Click to collapse
Read fully, gather resources, install prerequisites on PC and study before proceeding AND only with confidence, considering all risks. Steps are generally in order but start with verifying reactivation lock is not enabled at Settings/Security while phone is booted.
I'd also recommend that you begin with fingerprints removed and no encryption. Make backups frequently in TWRP recovery beginning with suggested stock backup on ext sdcard as explained along the way.
Note: remember, before making any backups that fingerprints should be removed. Fingerprints do not restore from custom backups and don't work as expected even restored in a backup. Problematic!
Steps may contain redundant reminders and links because I've reiterated important things more than once.
Begin here when prerequisites, explained, are installed and gathered. The SuperSU zip and Wanam unofficial Xposed can be downloaded to phone's internal memory or retained for safe keeping on your micro sdcard. Just remember where downloaded to find when flashing in recovery. Always verify md5 of zips before extracting or flashing (as applies) where available. Sanity check to be safe.
USB driver will be installed on PC as executable; Odin will be extracted to Odin folder; your user files are good location to place this folder with extracted files; the exe file is an Odin application launcher executable with dependencies. The TWRP img.tar file will be downloaded to PC to install with Odin as explained along the way.
You can use the 3.1.1 Xposed Installer apk but your Xposed framework is going to be an unofficial one from Wanam for touchwiz lollipop and marshmallow.
Wanam also has an Xposed module suggested for touchwiz marshmallow: XTouchWiz (found with download search in Xposed Installer application when successful in installing all that I've given guidance for) . You might try that one first for SM-N910P; (other likened Xposed modification modules may not be as compatible as this Wanam module-- not too be confused with Wanam unofficial framework zip for recovery flashing to install Xposed framework). Note the differences.
https://forum.xda-developers.com/showpost.php?p=62377731&postcount=1
The file you'll eventually find is Wanam unofficial Xposed framework for SDK 23 arm.
https://www.androidfilehost.com/?fid=529152257862685344
I don't believe you're rooted. It also appears you're trying to flash custom zips with stock recovery? Are you familiar with TWRP recovery by Team Win? You'll need that to backup your ROM and flash custom zips like SuperSU zip and unofficial Xposed framework by Wanam. (Bootloader is already unlocked on SM-N910P; please make sure that is your model number because that's what I'm recommending files for).
https://dl.twrp.me/trltespr/twrp-3.0.2-0-trltespr.img.tar
The file above is latest custom recovery for SM-N910P or any Qualcomm Note 4. Recently, the TWRP recovery became unified by processor but common mistakes users of Qualcomm Note 4 make is not knowing which to flash and what's required for Odin install and how to properly flash in Odin. What's Odin? It's a utility made for flashing custom tar files and stock tar updates for rooted users. There are many updates and untrusted sources (beware of adware or malware!) but basically it's installed on a PC as an executable file. But you'll also need the official USB driver to help the PC discover your phone when placed in download mode to flashed with Odin. What will you flash? The tar.img file above.
To get started download USB driver and Odin. Install USB on PC with its exe file.
http://org.downloadcenter.samsung.c...G_USB_Driver_for_Mobile_Phones_v1.5.45.00.exe
Latest Odin trusted download is below. Unzip or extract contents in a folder named Odin
https://forum.xda-developers.com/showpost.php?p=51767811&postcount=1
If you have Samsung Smart Switch or Samsung KIES installed on PC, you need to ensure all process and apps sessions are closed before using Odin. Also note that launching Odin exe on Windows 8 and below requires to launch with administrative permission (right click the executable file and select launch with administrative permission). Windows 10 does not require administrative mode at launch.
Are you familiar with launching download mode? Power Off, pull battery after charging to at least 80% (general rules for flashing in Odin download mode- never use a "boot to download mode" shortcut from system booted state; actually, that necessity applies to flashing full stock tar but remember that; make it a practice is my suggestion to avoid catheter csc errors with full stock tar flashes with Odin-- that's how rooted users update). Reinstall battery and press hold volume down, home and power button until it vibrates or launches. Read the prompt on phone* this is important because flashes are always a risk. Launch Odin on PC and goto options tab and uncheck auto restart and return to to log tab. While watching "COM" field with USB cable connected (must be data USB type cable- original Samsung Note 4 is recommended), follow prompt* I believe it's volume up to continue. Read your phone's state and see that COM field populated with your device (likely a port or device number unique to your PC where phone USB cable is connected or your phone* it only populates when you accept/commit download mode with phone and PC connected via USB with data support). Do not proceed until verifying your phone display shows Odin fast mode and that reactivation lock is disabled or inactive. If that is a go, load the img.tar in AP slot. You still see the file name fill that slot when you navigate to it on your PC and select it. The install button will be at bottom of Odin screen, I believe. Begin when all is verified.
If all above is a go, just remember that you're looking for a green field that fills and says SUCCESS! Happens quickly and stops (if you setup as directed). Wait until you see Odin log file state that "1 passed, 0 failed". Give it a minute to declare "disconnected" or just wait one minute before proceeding. Since auto reboot was unchecked, you'll have to remove USB and pull battery manually (wait at least 30 seconds after pulling battery before reinstalling). And close Odin after each flash session; you're actually done with the PC for this directive. IMPORTANT: If you fail to go directly to recovery mode after reinstalling the battery, stock recovery will restore itself and you'll have to do the Odin flash of TWRP again. To do this, press and hold volume up, home and power simultaneously until it vibrates; TWRP recovery should launch. You're now ready to backup your stock un-rooted ROM. I recommend backing up to ext SD Card (micro sdcard).
To familiar yourself with TWRP install and use, there's a support thread for that. There's also an official TWRP recovery application in Google Play. Search it there. Note the thread hasn't reflected latest update or developer notes since the official TWRP recovery app launched in Google Play but many unique questions are answered there. Ignore any suggestions to use an older TWRP version or any specific update or Android version. Suggestions like this change over time and may not be relevant at present.
https://forum.xda-developers.com/no...ility-twrp-2-8-1-0-teamwin-t2915591?nocache=1
After backup, I'd recommend installing SuperSU zip with TWRP recovery.
https://forum.xda-developers.com/showpost.php?p=68475511&postcount=1
Make a rooted TWRP backup before applying Xposed and label accordingly, saving to ext sdcard. You can edit the generalized title of backup as you prefer. Rather than the extended fine stamp, shorten to include your description.
Then you can install the Xposed Installer apk (install by sideload method not recovery- you may have already done this) and Wanam unofficial Xposed zip. Follow this thread; I've already linked the zip above but usually you're looking for the highlighted download link and browse to marshmallow SDK 23 arm.
https://forum.xda-developers.com/showpost.php?p=62377731&postcount=1
All threads referenced are your support threads for files referenced. Understand before flashing that there risks you assume yourself. Never a guarantee that you'll be successful or the inevitable happens from followed instructions offered by me or anyone else I've linked you to.
Again, make sure you haven't set reactivation lock in phone's Settings/Security tab before beginning and verify the phone display and Odin states before flashing. Not following could result in phone activating a factory reset protection mode. Not sharing to warning while flashing TWRP recovery may only refuse to flash due to reactivation lock enabled and may state such when using recent Odin releases. But that message may be only abbreviated and cause question of its intent.
Only flash when familiar and confident with instructions. Better to ask than risk misunderstood direction. There may recent demo videos to follow but avoid using suggested older files, noting date of your video; they're not necessarily scripture to live by. Best to use recent files and direction because unlike a certain BOOK, updates and time changes with Samsung, touchwiz and Note 4 development.
There's also some custom ROMs to consider if you follow the road map of XDA links for Sprint Note 4 at top of thread: Note 4 development, rather than Note 4 original development where TWRP support thread. Updates for TWRP can be found in the official TWRP recovery app but I've linked you latest recommended release for flashing in Odin.
Questions? Ask away or read the support threads to familiarize yourself. Many questions are answered there.
Sent from my SM-N920P using Tapatalk
---------- Post added at 10:28 PM ---------- Previous post was at 09:59 PM ----------
Final result on my SM-N910P Note 4. See screenshots.
I'm using a couple of non Xposed modules to compliment modification outside of Xposed. Since compatible modules and applications are sometimes limited, I'll include those for clarification. Both linked below by Google Play link. Strictly optional. Both contain back to kill foreground app shortcuts but may be premium only features- I'm not sure on both or whether one or the other would be ideal. I sort of discovered these apps by recommendation and haven't tried eliminating one or the other.
https://play.google.com/store/apps/details?id=flar2.homebutton
https://play.google.com/store/apps/details?id=com.goodmooddroid.gesturecontrol
Sent from my SM-N920P using Tapatalk
samep said:
Read fully, gather resources, install prerequisites on PC and study before proceeding AND only with confidence, considering all risks. Steps are generally in order but start with verifying reactivation lock is not enabled at Settings/Security while phone is booted.
I'd also recommend that you begin with fingerprints removed and no encryption. Make backups frequently in TWRP recovery beginning with suggested stock backup on ext sdcard as explained along the way.
Note: remember, before making any backups that fingerprints should be removed. Fingerprints do not restore from custom backups and don't work as expected even restored in a backup. Problematic!
Steps may contain redundant reminders and links because I've reiterated important things more than once.
Begin here when prerequisites, explained, are installed and gathered. The SuperSU zip and Wanam unofficial Xposed can be downloaded to phone's internal memory or retained for safe keeping on your micro sdcard. Just remember where downloaded to find when flashing in recovery. Always verify md5 of zips before extracting or flashing (as applies) where available. Sanity check to be safe.
USB driver will be installed on PC as executable; Odin will be extracted to Odin folder; your user files are good location to place this folder with extracted files; the exe file is an Odin application launcher executable with dependencies. The TWRP img.tar file will be downloaded to PC to install with Odin as explained along the way.
You can use the 3.1.1 Xposed Installer apk but your Xposed framework is going to be an unofficial one from Wanam for touchwiz lollipop and marshmallow.
Wanam also has an Xposed module suggested for touchwiz marshmallow: XTouchWiz (found with download search in Xposed Installer application when successful in installing all that I've given guidance for) . You might try that one first for SM-N910P; (other likened Xposed modification modules may not be as compatible as this Wanam module-- not too be confused with Wanam unofficial framework zip for recovery flashing to install Xposed framework). Note the differences.
https://forum.xda-developers.com/showpost.php?p=62377731&postcount=1
The file you'll eventually find is Wanam unofficial Xposed framework for SDK 23 arm.
https://www.androidfilehost.com/?fid=529152257862685344
I don't believe you're rooted. It also appears you're trying to flash custom zips with stock recovery? Are you familiar with TWRP recovery by Team Win? You'll need that to backup your ROM and flash custom zips like SuperSU zip and unofficial Xposed framework by Wanam. (Bootloader is already unlocked on SM-N910P; please make sure that is your model number because that's what I'm recommending files for).
https://dl.twrp.me/trltespr/twrp-3.0.2-0-trltespr.img.tar
The file above is latest custom recovery for SM-N910P or any Qualcomm Note 4. Recently, the TWRP recovery became unified by processor but common mistakes users of Qualcomm Note 4 make is not knowing which to flash and what's required for Odin install and how to properly flash in Odin. What's Odin? It's a utility made for flashing custom tar files and stock tar updates for rooted users. There are many updates and untrusted sources (beware of adware or malware!) but basically it's installed on a PC as an executable file. But you'll also need the official USB driver to help the PC discover your phone when placed in download mode to flashed with Odin. What will you flash? The tar.img file above.
To get started download USB driver and Odin. Install USB on PC with its exe file.
http://org.downloadcenter.samsung.c...G_USB_Driver_for_Mobile_Phones_v1.5.45.00.exe
Latest Odin trusted download is below. Unzip or extract contents in a folder named Odin
https://forum.xda-developers.com/showpost.php?p=51767811&postcount=1
If you have Samsung Smart Switch or Samsung KIES installed on PC, you need to ensure all process and apps sessions are closed before using Odin. Also note that launching Odin exe on Windows 8 and below requires to launch with administrative permission (right click the executable file and select launch with administrative permission). Windows 10 does not require administrative mode at launch.
Are you familiar with launching download mode? Power Off, pull battery after charging to at least 80% (general rules for flashing in Odin download mode- never use a "boot to download mode" shortcut from system booted state; actually, that necessity applies to flashing full stock tar but remember that; make it a practice is my suggestion to avoid catheter csc errors with full stock tar flashes with Odin-- that's how rooted users update). Reinstall battery and press hold volume down, home and power button until it vibrates or launches. Read the prompt on phone* this is important because flashes are always a risk. Launch Odin on PC and goto options tab and uncheck auto restart and return to to log tab. While watching "COM" field with USB cable connected (must be data USB type cable- original Samsung Note 4 is recommended), follow prompt* I believe it's volume up to continue. Read your phone's state and see that COM field populated with your device (likely a port or device number unique to your PC where phone USB cable is connected or your phone* it only populates when you accept/commit download mode with phone and PC connected via USB with data support). Do not proceed until verifying your phone display shows Odin fast mode and that reactivation lock is disabled or inactive. If that is a go, load the img.tar in AP slot. You still see the file name fill that slot when you navigate to it on your PC and select it. The install button will be at bottom of Odin screen, I believe. Begin when all is verified.
If all above is a go, just remember that you're looking for a green field that fills and says SUCCESS! Happens quickly and stops (if you setup as directed). Wait until you see Odin log file state that "1 passed, 0 failed". Give it a minute to declare "disconnected" or just wait one minute before proceeding. Since auto reboot was unchecked, you'll have to remove USB and pull battery manually (wait at least 30 seconds after pulling battery before reinstalling). And close Odin after each flash session; you're actually done with the PC for this directive. IMPORTANT: If you fail to go directly to recovery mode after reinstalling the battery, stock recovery will restore itself and you'll have to do the Odin flash of TWRP again. To do this, press and hold volume up, home and power simultaneously until it vibrates; TWRP recovery should launch. You're now ready to backup your stock un-rooted ROM. I recommend backing up to ext SD Card (micro sdcard).
To familiar yourself with TWRP install and use, there's a support thread for that. There's also an official TWRP recovery application in Google Play. Search it there. Note the thread hasn't reflected latest update or developer notes since the official TWRP recovery app launched in Google Play but many unique questions are answered there. Ignore any suggestions to use an older TWRP version or any specific update or Android version. Suggestions like this change over time and may not be relevant at present.
https://forum.xda-developers.com/no...ility-twrp-2-8-1-0-teamwin-t2915591?nocache=1
After backup, I'd recommend installing SuperSU zip with TWRP recovery.
https://forum.xda-developers.com/showpost.php?p=68475511&postcount=1
Make a rooted TWRP backup before applying Xposed and label accordingly, saving to ext sdcard. You can edit the generalized title of backup as you prefer. Rather than the extended fine stamp, shorten to include your description.
Then you can install the Xposed Installer apk (install by sideload method not recovery- you may have already done this) and Wanam unofficial Xposed zip. Follow this thread; I've already linked the zip above but usually you're looking for the highlighted download link and browse to marshmallow SDK 23 arm.
https://forum.xda-developers.com/showpost.php?p=62377731&postcount=1
All threads referenced are your support threads for files referenced. Understand before flashing that there risks you assume yourself. Never a guarantee that you'll be successful or the inevitable happens from followed instructions offered by me or anyone else I've linked you to.
Again, make sure you haven't set reactivation lock in phone's Settings/Security tab before beginning and verify the phone display and Odin states before flashing. Not following could result in phone activating a factory reset protection mode. Not sharing to warning while flashing TWRP recovery may only refuse to flash due to reactivation lock enabled and may state such when using recent Odin releases. But that message may be only abbreviated and cause question of its intent.
Only flash when familiar and confident with instructions. Better to ask than risk misunderstood direction. There may recent demo videos to follow but avoid using suggested older files, noting date of your video; they're not necessarily scripture to live by. Best to use recent files and direction because unlike a certain BOOK, updates and time changes with Samsung, touchwiz and Note 4 development.
There's also some custom ROMs to consider if you follow the road map of XDA links for Sprint Note 4 at top of thread: Note 4 development, rather than Note 4 original development where TWRP support thread. Updates for TWRP can be found in the official TWRP recovery app but I've linked you latest recommended release for flashing in Odin.
Questions? Ask away or read the support threads to familiarize yourself. Many questions are answered there.
Sent from my SM-N920P using Tapatalk
---------- Post added at 10:28 PM ---------- Previous post was at 09:59 PM ----------
Final result on my SM-N910P Note 4. See screenshots.
I'm using a couple of non Xposed modules to compliment modification outside of Xposed. Since compatible modules and applications are sometimes limited, I'll include those for clarification. Both linked below by Google Play link. Strictly optional. Both contain back to kill foreground app shortcuts but may be premium only features- I'm not sure on both or whether one or the other would be ideal. I sort of discovered these apps by recommendation and haven't tried eliminating one or the other.
https://play.google.com/store/apps/details?id=flar2.homebutton
https://play.google.com/store/apps/details?id=com.goodmooddroid.gesturecontrol
Sent from my SM-N920P using Tapatalk
Click to expand...
Click to collapse
Hello Samep, I'm impressed and thankful on how you describe everything, I know its takes lon time and dedication to write,, THANKS A LOT, I know these will be the most comprehensive for many many users... I will try to do what you explained. ..
Also thanks to Rom and others for your suggestions and help.
Have a great weekend.. all the best wishes for all.
Regards
Herm.
slm note 4
note 4 I am using n910c 6.0.1. I have installed the device rooted twrp but I do not know which xposed i will install. I write armv7l in the kernel.
I do not know how many sdk I have to help you rejoice