I was looking at the code for GladRoot (http://forum.xda-developers.com/showthread.php?t=1016060) and I had a couple of questions I was hoping someone could answer.
First of all, does anyone have the code for psneuter?
Secondly, if the goal of rooting is to Superuser.apk, why is temporary root access necessary? I've never used adb before this, but isn't the point that developers can easily do things like install applications using it? The superuser apk might grant super user access after it's installed, but before that it's just like any other apk.
I'd appreciate it if someone could answer these questions. Thanks.
Anyone want to help me out? Doesn't seem like too hard of a question...
Id take a look at What is root access on google. It sounds like you have no idea about the basics. There is a ton of info for beginners even on this site. If I misunderstood you I apologize but your question would only leave me to believe you need to learn the basics. Good luck
Sent using the phone with the biggest balls....Atrix 4G
Gladroot doesn't give temporary root access either unless it changed.
Sent using the phone with the biggest balls....Atrix 4G
dupreeks said:
Id take a look at What is root access on google. It sounds like you have no idea about the basics. There is a ton of info for beginners even on this site. If I misunderstood you I apologize but your question would only leave me to believe you need to learn the basics. Good luck
Sent using the phone with the biggest balls....Atrix 4G
Click to expand...
Click to collapse
Well I'm definitely a beginner, but not that beginner. I'll show you what I'm talking about:
Code:
rem If we do, since we need to run several commands as root, use psneuter to
rem temporarily root the device.
echo.
echo Obtaining temporary root access...
%~dp0adb push %~dp0bin\psneuter /tmp/psneuter > NUL 2>&1
if not errorlevel 0 set message=Unable to send psneuter. && goto abort
set retval=
for /f "tokens=*" %%l in ('%~dp0adb.exe shell "/bin/chmod 6755 /tmp/psneuter > /dev/null 2>&1 && echo PASS"') do set retval=%%l
if "%retval%" neq "PASS" set message=Unable to chmod psneuter. && goto abort
set retval=
for /f "tokens=*" %%l in ('%~dp0adb.exe shell "/tmp/psneuter > /dev/null 2>&1"') do set retval=%%l
if "%retval%" neq "" set message=Unable to execute psneuter. && goto abort
echo.
echo Waiting for root access to kick in...
timeout /t 5 /nobreak > NUL 2>&1
So what I said was correct. GladRoot definitely get's temp root access. After it does that, it changes some settings and installs superuser.apk:
Code:
rem Remount the /system read/write.
echo.
echo Mounting /system as read/write...
%~dp0adb.exe shell mount -o rw,remount /dev/block/mmcblk0p12 /system > NUL 2>&1
rem Install sqlite3 for additional system changes required later in the script.
rem This is silent because it shouldn't interfere with anything even if it's
rem not used.
%~dp0adb.exe push %~dp0bin\sqlite3 /system/bin > NUL 2>&1
%~dp0adb.exe shell chmod 6755 /system/bin/sqlite3 > NUL 2>&1
echo.
echo Ready to root.
echo.
pause
rem Let's root!
rem Check for duplicate busybox installation and remove it.
echo.
echo Cleaning up SuperOneClick mess...
%~dp0adb.exe shell "find /system/xbin -type l | xargs rm" > NUL 2>&1
%~dp0adb.exe shell rm /system/xbin/busybox > NUL 2>&1
rem Copy su over and set permissions for use.
echo.
echo Rooting your device ...
%~dp0adb.exe push %~dp0bin\su /system/bin > NUL 2>&1
%~dp0adb.exe shell chmod 6755 /system/bin/su > NUL 2>&1
rem Install the Superuser app for allowing other apps root access.
echo.
echo Installing Superuser app...
%~dp0adb.exe install -r %~dp0bin\Superuser.apk > NUL 2>&1
echo.
echo Root complete.
echo.
So again my question is why do you need temp root access to install superuser.apk?
Temp root access is needed because superuser is installed in system/apps in the system partition. Without root a user does not have read write permissions in the system partition. This means a user cannot uninstall apps or install apps with out root permission. Temp access allows a script or person to modify the system partition, in this case it gives apps access to permanent root. The source code for psneuter is here.
on21st said:
Temp root access is needed because superuser is installed in system/apps in the system partition. Without root a user does not have read write permissions in the system partition. This means a user cannot uninstall apps or install apps with out root permission. Temp access allows a script or person to modify the system partition, in this case it gives apps access to permanent root. The source code for psneuter is here.
Click to expand...
Click to collapse
Yeah that pretty much sums it up. Gladroot was and still is my method of root. I wish I could unlock the boot loader with my current 1.8.3 setup I have and not lose anything. If anyone has a solution I would really appreciate it. I like my phone how it is but want to be able to make nand backups basically. I am not huge on CM7 and it doesn't seem like there are many stable roms for the Atrix right now.
You can there should be a pudding for 1.8.3. I remember using it. It wipes data and allows you to unlock the boot loader if you choose. HERE
Just choose the correct sbf to download and then follow instructions in thread.
Related
First off, I want to say thanks to Kam187 & the Creators of asroot
Okay, Below is the Method I used for getting Root working for my app's.
Even though Shell is running as Root, any Call's made to su trigger's the white List Superuser.apk, So don't think your phone is wide open. G1's & MT3G Setup's are the same regard sh.
I'm not sure is the apk is counted as warez or not, if so I hope a Mod will remove the link to the Apk or let me know to Remove it...
Okay, File's Need to complete the Task is....
Try3 Placed in C:\SDK\tools> found here > File's attached below
SU for /system/bin found here > File's attached below
Superuser app control for our App's found Here > File's attached below
Next, Mount the SDCARD and place the SU file in the root of the sdcard like so ( /sdcard ). This is Important!!!
From here we do the Following.. ( Kam187 script the I edited ).
adb push try3 /data/local
adb shell chmod 0755 /data/local/try3
adb shell
/data/local/try3 /system/bin/sh
mount -o rw,remount /dev/st9 /system
chmod 04755 /system/bin/sh
cat /sdcard/su > /system/bin/su1
cat /sdcard/su > /system/bin/su
chmod 04755 /system/bin/su
su
cat /system/bin/playlogo > /system/bin/playlogo_real
/system/bin/chmod 0755 /system/bin/playlogo_real
echo "#!/system/bin/sh
/data/local/try3 /system/bin/sh
mount -o rw,remount /dev/st9 /system
chmod 04755 /system/bin/sh
cat /system/bin/su1 > /system/bin/su
chmod 04755 /system/bin/su
/system/bin/playlogo_real" > /system/bin/playlogo
Click to expand...
Click to collapse
Once Done, place the Superuser.apk in your SDK tools Directory.
Mine happens to look like this
C:\SDK\tools>
Click to expand...
Click to collapse
Once you have that Copied over, Open a Command prompt and CD to your sdk\tools directory and type the following.
adb install Superuser.apk
Click to expand...
Click to collapse
Once done, do a reboot of the Phone, Once boot up is complete open a Command Prompt ( or app that needs Root ).
For Command Prompt, type:
adb shell
Click to expand...
Click to collapse
su
Click to expand...
Click to collapse
If done correctly you will now see the deny or allow prompt on the Phone, or just open any app that needs root & you will see the same window.
Here's some Picture of it working
SU working with SU apk on Twitpic & SU working with SU apk on Twitpic
I always have problems to root official 2.3 with automatic ways, and found that this caused from some adb miscommunication.
So this is how to do it manual, in case automatic ways stacked.
First install adb-sdk and add its path to system variables, so to don't have to go to adb' s path before you can run it.
Then download doomlord' s rooting tool and extract it to drive C:\DoomLordRoot.v3.
http://forum.xda-developers.com/attachment.php?attachmentid=784296&stc=1&d=1321435888
Preparation steps on device:
1) Dial: *#*#2846579#*#*
2) Go to projectmenu > background settings > log settings > log switch > set Log on
3) Reboot Phone
4) Switch USB Debugging ON
5) uncheck fast boot from settings -> applications
Click to expand...
Click to collapse
Open windows command prompt window and do the above:
Code:
adb push c:\DoomLordRoot.v3\files\zergRush /data/local/tmp/
[COLOR="DarkSlateBlue"]adb shell[/COLOR]
chmod 777 /data/local/tmp/zergRush
./data/local/tmp/zergRush
[COLOR="DarkSlateBlue"]Hit CTRL+C to exit from adb shell[/COLOR]
adb push c:\DoomLordRoot.v3\files\busybox /data/local/tmp/
[COLOR="DarkSlateBlue"]adb shell[/COLOR]
su
chmod 755 /data/local/tmp/busybox
/data/local/tmp/busybox mount -o remount,rw /system
dd if=/data/local/tmp/busybox of=/system/xbin/busybox
chown root.shell /system/xbin/busybox
chmod 04755 /system/xbin/busybox
/system/xbin/busybox --install -s /system/xbin
rm -r /data/local/tmp/busybox
[COLOR="DarkSlateBlue"]Hit CTRL+C to exit again from adb shell[/COLOR]
adb push c:\DoomLordRoot.v3\files\su /system/bin/su
[COLOR="DarkSlateBlue"]adb shell[/COLOR]
su
chown root.shell /system/bin/su
chmod 06755 /system/bin/su
rm /system/xbin/su
ln -s /system/bin/su /system/xbin/su
[COLOR="DarkSlateBlue"]Hit CTRL+C to exit once more from adb shell[/COLOR]
adb push c:\DoomLordRoot.v3\files\Superuser.apk /system/app/
[COLOR="DarkSlateBlue"]adb shell[/COLOR]
su
cd /data/local/tmp/
rm *
reboot
This is basic what the runme.bat file does, just some paths corrected to point to the right locations.
I have the latest official gingerbread (I think v3) and have been trying to root with no luck. I've gone through the steps here but when try to get root access (su), it gives me permission denied...
Any ideas?
Oneclickroot v2. 2 did the work for me or something like this
Sent from my U8800
SS said:
I have the latest official gingerbread (I think v3) and have been trying to root with no luck. I've gone through the steps here but when try to get root access (su), it gives me permission denied...
Any ideas?
Click to expand...
Click to collapse
This probably means that rooting failed.
What messages you get when you run zergrush?
dancer_69 said:
This probably means that rooting failed.
What messages you get when you run zergrush?
Click to expand...
Click to collapse
I got messages for sending 149, then 189 zerglings, then messages about not being able to mount, find or write to directories.
It seems like it wasn't able to get root access to be able to run its process.
In any case, I just downgraded to the previous release and then used ZergRush, which worked perfectly
don't work.
try this, it works for my B528 rom!
http://forum.xda-developers.com/showpost.php?p=23565074&postcount=7
Guys, need a nudge in right direction.
EDIT: I am running stock ROM
I have a rooted DroidX. Will be getting RAZR MAXX next month and want to sell my DX. So i want to take it back to stock to sell.
I have searched but couldn't find anything close to my situation.
Any ideas would be appreciated or can I just do a factory reset?
Here are the specifics.......
Had DX running .605.
I rooted using this video http://www.youtube.com/watch?v=Pxks-o2cd7E&feature=plcp
This is the version of the script I used.. I still have the script but there is not an "unroot" option in it.
Code:
echo ***************************************************************************
echo * *
echo * DROID 3 Easy Root script v7 *
echo * *
echo ***************************************************************************
echo *
I can post entire code if needed.
Here is where I am running into my specific problem.
When .621 OTA update was coming down, I installed OTA rootkeeper.
I took the OTA update and was able to retain root and be on .621
Only other mods done were supercharger (which I reversed to stock) and a mod to get wifi hotspot going.
The hotspot mod I did was a complicated one. Downloaded some program from Motorola and went in and edited some values in a database in the phone.
Where can I go to figure out how to reverse this back to stock so I can sell it in good faith?
Unfortunately I was extremely new to all of this when I rooted it and didn't think about going back.
I have a full Titanium Backup of the system after root and before .621 update.
Heck, here is the entire rooting code if it helps.
Code:
@echo off
cls
adb kill-server > NUL
COLOR B0
TITLE DROID 3 Easy Root Script
cls
echo ***************************************************************************
echo * *
echo * DROID 3 Easy Root script v7 *
echo * *
echo ***************************************************************************
echo *
echo * Please make sure you meet these pre-requisites:
echo *
echo * (a) install the correct driver
echo * (b) turn on USB debugging (on your phone under Settings -^> Applications)
echo * (c) plug in your phone and set your USB mode to 'charging only'
echo *
echo * Note: your phone will reboot twice during this procedure. This is normal.
echo *
echo * READY TO ROOT YOUR DROID 3 WHEN YOU ARE!
echo *
COLOR E0
pause
echo *
echo * Waiting for your phone to be connected...
echo *
adb wait-for-device > NUL
COLOR B0
echo * Running exploit [part 1 of 3]...
adb kill-server > NUL
adb shell rm /data/local/12m.bak > NUL
adb shell mv /data/local/12m /data/local/12m.bak > NUL
adb shell ln -s /data /data/local/12m
adb reboot
echo *
echo * Rebooting the phone... please wait.
adb kill-server > NUL
COLOR E0
adb wait-for-device > NUL
adb wait-for-device > NUL
COLOR B0
echo *
echo * Running exploit [part 2 of 3]...
adb shell rm /data/local/12m
adb shell mv /data/local/12m.bak /data/local/12m
adb shell rm /data/local.prop.bak > NUL
adb shell mv /data/local.prop /data/local.prop.bak
adb shell echo "ro.sys.atvc_allow_netmon_usb=0" ^> /data/local.prop
adb shell echo "ro.sys.atvc_allow_netmon_ih=0" ^>^> /data/local.prop
adb shell echo "ro.sys.atvc_allow_res_core=0" ^>^> /data/local.prop
adb shell echo "ro.sys.atvc_allow_res_panic=0" ^>^> /data/local.prop
adb shell echo "ro.sys.atvc_allow_all_adb=1" ^>^> /data/local.prop
adb shell echo "ro.sys.atvc_allow_all_core=0" ^>^> /data/local.prop
adb shell echo "ro.sys.atvc_allow_efem=0" ^>^> /data/local.prop
adb shell echo "ro.sys.atvc_allow_bp_log=0" ^>^> /data/local.prop
adb shell echo "ro.sys.atvc_allow_ap_mot_log=0" ^>^> /data/local.prop
adb shell echo "ro.sys.atvc_allow_gki_log=0" ^>^> /data/local.prop
adb reboot
echo *
echo * Rebooting the phone... please wait.
adb kill-server > NUL
COLOR E0
adb wait-for-device > NUL
adb wait-for-device > NUL
COLOR B0
echo *
echo * Running exploit [part 3 of 3]...
adb remount
adb push busybox /system/xbin/busybox
adb push su /system/xbin/su
adb push Superuser.apk /system/app/Superuser.apk
adb shell chmod 4755 /system/xbin/su
adb shell chmod 755 /system/xbin/busybox
adb shell chown system.system /data
echo *
echo * ALL DONE! YOUR PHONE SHOULD BE ROOTED!
echo *
echo ******************************************************************************
echo.
echo You may now close this window...
echo.
COLOR A0
adb kill-server > NUL
pause
TITLE Command Prompt
COLOR 07
Just simply try a factory reset
Sent from my shiny new white LOCKED SCH-I535 using xda app-developers app
If that didn't work just sbf back to stock. That will work for sure and gives the buyer the new phone experience
Sent from my SCH-I535 using xda app-developers app
dbett4 said:
Just simply try a factory reset
Sent from my shiny new white LOCKED SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
Lol didnt mean to thank you but oh well...
Any ways lol to OP you can factory reset a hundred times and you still won't remove root.
Why remove root anyways you'll sell the phone faster and save someone the hassle of rooting again
As for the regs who don't know that root is... meh. Again won't hurt the phone in any way.
You will have to sbf back to what ever firmware you want. Afaik it's the only way to remove root. I'm not experienced enough for manual removal, and sbf is so simple and hassle free...when done right.
Easy to f-up if not lol.
Gl
Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
I just checked ebay completed autions. Rooted phones do sell fast and are selling for more!! Great. Thanks for the tip.
If I do a factory reset, then it will go back to stock except it will leave root?? The main thing I was worried about was with the OTA upgrade.
If all else fails I will sbf with version .621 (afaik you can't go back further once you have .621 OTA) then re-root.
I did the same I had a deal and bought two DROIDX and rooted both then upgraded but kept root same way you did but my brother got a new phone so I went to market and downloaded an app called ginger unroot and bam full unroot. I even downloaded su and a root checker but no root. Hope this helps
Sent from my DROIDX using xda premium
Instead of SBF'ing I just did a factory reset. And it did in fact keep root.
Thanks guys.
Here's what ya do:
Factory reset
You will still have root.
Inform prospective buyer about rootkeeper.
Instruct them exactly what to do (don't make this part of your auction, just offer the advice after the sale;
make sure they know:
ota update =by by root)
Once buyer sets up their Google act and installs rootkeeper buyr can now ota with out worries of loosing root.
I just sold my dx and did this exact same thing.
Buyer was more than happy.
Hope that helps and glws
Sent from my DROID X2 using Tapatalk 2
How much did you get for it?
Sent from my Kindle Fire using xda app-developers app
I have been resisting the urge to flash a custom ROM for a bit, but I really miss having init.d support. So I read a few threads for other phones and rolled my own.
Warnings
I borrowed bits and pieces from various places. If you don't know what init.d is, you probably don't want to do this. If you aren't willing to take responsibility for bricking your tablet, don't do this. Seriously, the risk of bricking is very low, but if you aren't comfortable booting into an adb shell from recovery, maybe this is not for you. Strongly suggest a nandroid backup before you get started so if you totally bork things you can just hit rewind.
Note: The latest CWM may prompt you on a reboot that the ROM may overwrite the bootloader and offer to fix it for you. Don't do that. The init.d hack takes over the bootloader install script, but does not change your bootloader! If you accidentally do let it fix things for you, just rebuild the install-bootloader.sh file. The other steps should be fine.
Prerequisites
First, you need root, busybox, and some sort of terminal (either adb, or some terminal you like using on the tablet).
I have found that I like Busybox Installer (from the market; https://play.google.com/store/apps/details?id=com.jrummy.busybox.installer) but for some reason it doesn't create new symlinks unless you click advanced install.
Let's get to it!
In the shell (don't type # or anything after #):
Code:
su # get root
mount -o remount,rw /system # get access to /system (4.04 seems to mount ro as is usual; seems like the original mounted rw)
which run-parts # if you don't see /system/xbin/run-parts you need to install/reinstall busybox; if it is somewhere else, note it
mkdir /system/etc/init.d
Create a file called sysinit -- we are going to put it in /system/bin. You can edit it in place with vi, mount your tablet and edit it on your computer, or create it on the computer and push it via adb. Whatever.
Here's the file (you do need the # and the things after it in the file!):
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper /system/xbin/run-parts /system/etc/init.d
Note that if your run-parts is not in /system/xbin (from the which command) then fix the above to reflect your reality.
In the shell, make it executable
Code:
chmod 755 /system/bin/sysinit
Now go in the init.d directory and create some things you want to run at start up. For example:
Code:
cd /system/etc/init.d
echo '#!/system/bin/sh' >99test # note: you do need the first # in this line but not the 2nd!
echo 'date >>/data/tmp/init.d-log.txt' >>99test
chmod 755 99test
Here's a more practical one (yes, you need the # signs). Name it something like 10diskperf -- don't forget to chmod it.
Code:
#!/system/bin/sh
# Set disk read aheads to 1024
chmod 777 /sys/block/mmcblk0/queue/read_ahead_kb
echo "1024" > /sys/block/mmcblk0/queue/read_ahead_kb
chmod 777 /sys/block/mmcblk1/queue/read_ahead_kb
echo "1024" > /sys/block/mmcblk1/queue/read_ahead_kb
chmod 777 /sys/devices/virtual/bdi/179:0/read_ahead_kb
echo "1024" > /sys/devices/virtual/bdi/179:0/read_ahead_kb
Or here is one to tweak some TCP parameters (25sysctl):
Code:
#!/system/bin/sh
sysctl -w net.core.rmem_max=524288
sysctl -w net.core.wmem_max=524288
sysctl -w net.ipv4.tcp_rmem=6144 87380 524288
sysctl -w net.ipv4.tcp_wmem=6144 87380 524288
Whatever files you put in, you need to remember to make them executable (chmod 755).
Finally, you need to kick it all off at start up. The hack for that is we are going to create /system/etc/install-recovery.sh which apparently runs on each boot.
Code:
cd /system/etc
echo '#!/system/bin/sh' >install-recovery.sh
echo '/system/bin/sysinit' >>install-recovery.sh
chmod 755 install-recovery.sh
Tips and troubleshooting
If you are too lazy to cut and paste I have the files here (View attachment init.d-support.zip) that you can just move to the right places and change permission. If you are really lazy there is lightly tested install script below.
I like to try running the whole thing before a reboot to see if I get any errors:
Code:
/system/etc/install-recovery.sh
I'd suggest putting the 99test file in first. Verify that you get the expected file in /data/tmp and then reboot and check again. Then you can remove 99test.
Same goes for adding new scripts. Try running them from the shell to see if they throw errors before you reboot!
If you have trouble, see if this looks right:
Code:
ls -ld /system/etc/install-recovery.sh /system/bin/sysinit /system/etc/init.d /system/xbin/run-parts
-rwxr-xr-x root root 39 2012-07-14 10:00 install-recovery.sh
-rwxr-xr-x root root 140 2012-07-14 10:01 sysinit
drwxrwxrwx root root 2012-07-14 10:10 init.d
lrwxrwxrwx root root 2012-07-14 09:55 run-parts -> /system/xbin/busybox
For the brave
The install-init.d zip file (View attachment install-init.d.zip) contains a lightly tested script that SHOULD do the install steps for you.
Send the file to your android to someplace that can execute code (e.g., /system/xbin; I had to use adb to put it on the sdcard and then move it to /systemxbin in the shell since I don't have the adb root kernel installed).
Code:
cd /system/xbin # or wherever you have it
chmod 755 install-init.d
./install-init.d
It performs rude checks to see if init.d exists, and tries to handle moving or missing busybox. It only installs 99test as a script.
Let me know if this works or doesn't work for you.
For the extra brave: There is no reason this should only work on the Samsung. This ought to work on pretty much most stock ROMs as long as they execute install-recovery.sh on start up.
Scripts
What do you put in your init.d? If you post anything cool I'll put it up here in the op.
One that gave me some real gains in I/O performance required a new version of the tune2fs executable. By default, it is part of busybox but the busybox one only has a few simple options. I've included a stand alone version and the script 10disktune here View attachment disktune.zip. Unpack the zip and put the 10disktune in /system/etc/init.d (don't forget to chmod) and put tune2fs in /system/bin (chmod that too). Note that busybox has one in /system/xbin but the script specifically calls out the one in /system/bin.
Here's one that will zipalign your apks on each boot
Code:
#!/system/bin/sh
for apk in /data/app/*.apk ; do
zipalign -c 4 $apk
ZCHECK=$?
if [ $ZCHECK -eq 1 ]; then
zipalign -f 4 $apk /cache/$(basename $apk)
if [ -e /cache/$(basename $apk) ]; then
cp -p -f /cache/$(basename $apk) $apk
rm /cache/$(basename $apk)
fi;
fi;
done;
Fin
Corrections welcome. I considered using exec or . to load some of this into one shell but given that it runs once at startup, I figured it is fine as is.
All files for reference
View attachment init.d-support.zip
View attachment install-init.d.zip
View attachment disktune.zip
Great guide, gonna try it tonight.
Sent from a GNote, hell yeah!
SirRhor said:
Great guide, gonna try it tonight.
Sent from a GNote, hell yeah!
Click to expand...
Click to collapse
I'm curious how it went. If you ran into any issues, let me know so I can update the op. Thanks!
Hmm did anyone get this to work?
wd5gnr said:
Hmm did anyone get this to work?
Click to expand...
Click to collapse
I did it on my Galaxy Nexus.
It works great, I had a bit of problem with the sysinit file, but when I downloaded your zip file and used your sysinit, it worked, so it must be a problem from my side
Thanks for this, I can finally use "Odex Me"
aavan said:
I did it on my Galaxy Nexus.
It works great, I had a bit of problem with the sysinit file, but when I downloaded your zip file and used your sysinit, it worked, so it must be a problem from my side
Thanks for this, I can finally use "Odex Me"
Click to expand...
Click to collapse
Great, just wanted to be sure I hadn't made any typos/errors in the guide.
A lot of init.d files collected here: http://forum.xda-developers.com/showthread.php?t=1227269
Also build.prop things, etc.
Thanks, I use your guide and worksperfect for my RK3066 devices. Very simple to understand all steps and what we are doing to our system, perfect for me. Thanks again dude
Melch1zedeK said:
Thanks, I use your guide and worksperfect for my RK3066 devices. Very simple to understand all steps and what we are doing to our system, perfect for me. Thanks again dude
Click to expand...
Click to collapse
Glad to help!
What is thhe utility of this?
moliverac8 said:
What is thhe utility of this?
Click to expand...
Click to collapse
Init.d is how Linux and many Android (which is kind of Linux, after all) systems manage executing commands on boot up.
The /etc/init.d files run in numerical order as root and you can do things like change system settings, manipulate the file system, etc.
See the init.d section linked below for some ideas.
http://forum.xda-developers.com/showthread.php?t=1227269
Question? what is the difference in this method and running a script?
wd5gnr said:
Init.d is how Linux and many Android (which is kind of Linux, after all) systems manage executing commands on boot up.
The /etc/init.d files run in numerical order as root and you can do things like change system settings, manipulate the file system, etc.
See the init.d section linked below for some ideas.
http://forum.xda-developers.com/showthread.php?t=1227269
Click to expand...
Click to collapse
I use the "swap memory script" and was wondering if it would also work this way with the init.d If so would there be any benefit this way over the current way of running it one way or the other? One drawback I see running the script as is is that I have to wait once the system has fully booted until the script has run and I see the Smanager screen to let me know that my memory has been remounted.
Thanks for the info and the learning process.
Here is the script and the link.
http://forum.xda-developers.com/showthread.php?t=1961097
Code:
sleep 5
mount -o remount,rw /
mount -t vfat -o umask=0000 /dev/block/vold/179:25 /mnt/sdcard
sleep 5
mount -o bind /data/media /mnt/extSdCard
As long as the device is ready to mount at boot time and doesn't get remounted, ought to work. Backup and try it
External memory wasn't ready
wd5gnr said:
As long as the device is ready to mount at boot time and doesn't get remounted, ought to work. Backup and try it
Click to expand...
Click to collapse
Thanks for the guide, but I think that the external memory was not ready to be mounted at that time. it didn't see the card till after boot. It was worth a shot, Reverted back to the script in /data and all worked again,
Note: I didn't find /system/xbin/run-parts however, I did find /system/bin/run-parts and changed the path to reflect that, I don't think this was an issue but I'm not 100% sure.
I had some trouble trying to make Viper4Android v2.4.0.1 work on my Honor 5C running Android 6.0. This could be helpful…
Viper4Android didn't work after installation and reboot, the driver status showing as "abnormal". It seems related to a change in default SELinux policy.
I read that changing globally the SELlinux policy to "permissive" can solve the problem but it may be an extreme solution (SELinux is a security feature to restrict what an application can do, I don't know the potential edge effects).
I found another solution on the web, which consists in patching the SELinux policies at boot, just enough for Viper4Android to work.
If you did not make a systemless installation of SuperSU, open an adb shell and use these commands (courtesy of androiding.how):
Code:
su
mount -o rw,remount /system
cd /system/su.d
echo '#! /system/bin/sh' > 50viper.sh
echo '/system/xbin/supolicy --live "allow mediaserver mediaserver_tmpfs:file { read write execute };"' >> 50viper.sh
chmod 755 50viper.sh
cd /
mount -o ro,remount /system
And reboot.
If you did make a systemless installation of SuperSU, open an adb shell and use this instead:
Code:
su
mount -o rw,remount /su
cd /su/su.d
echo '#! /system/bin/sh' > 50viper.sh
echo '/su/bin/supolicy --live "allow mediaserver mediaserver_tmpfs:file { read write execute };"' >> 50viper.sh
chmod 755 50viper.sh
cd /
mount -o ro,remount /su
exit
And reboot.
Didn't work for me, tried the 2nd method as the first one gave an error at the 3rd step, completed everything, rebooted, still no luck
imrock said:
Didn't work for me, tried the 2nd method as the first one gave an error at the 3rd step, completed everything, rebooted, still no luck
Click to expand...
Click to collapse
I just noticed that in my 2nd block the characters ’ and ” were used instead of ' and ". I'm not a POSIX shell expert but since these are not the same characters it can make a difference.
I've updated the 2nd method, you can give it a try — you can use it "as it is", it will overwrite the previously created file.
This trick didn't work for me.
I ended up installing SELinuxModeChanger and now Viper is rockin' :good: