Assistance modifying build.prop from updater script. - Google Pixel 3 XL Themes, Apps, and Mods
Hi all -
I have made updated scripts before, but something isn't working out for me. I started with this guys script here:
https://forum.xda-developers.com/showpost.php?p=19093919&postcount=20
Purpose is to add lines to build.prop from the script (also does a backup).
First time through I was getting an error which I resolved by updating to a different updater-binary.
I know that the .sh script that I am copying over is running (using some simple touch statements), however it never seem to touches my build.prop.
I think the issue is that somehow it can't access the build.prop file, possibly because it isn't mounting /system properly.
It seems to use busybox commands which I don't have on my device (and I'd rather not install, as I don't want to have to depend on it after clean flash).
Can someone help me out or point me to another script/method of updating build.prop via updater-script?
thanks
Yeah, I don't know what's going on.
I've also tried these scripts meant to modify build.prop:
https://forum.xda-developers.com/android/apps-games/pie-pixel-stuff-t3846138 (the prop patch script)
and
https://forum.xda-developers.com/showthread.php?t=2664332
Scripts appear to run fine, but build.prop is never edited.
None of these scripts states they are for the 3, but they do indicate they at least worked with the original Pixel.
Is something different in the 3 that would be preventing any of these from working?
TraderJack said:
Yeah, I don't know what's going on.
I've also tried these scripts meant to modify build.prop:
https://forum.xda-developers.com/android/apps-games/pie-pixel-stuff-t3846138 (the prop patch script)
and
https://forum.xda-developers.com/showthread.php?t=2664332
Scripts appear to run fine, but build.prop is never edited.
None of these scripts states they are for the 3, but they do indicate they at least worked with the original Pixel.
Is something different in the 3 that would be preventing any of these from working?
Click to expand...
Click to collapse
Try changing the updater-script code from busybox to toybox.
Edit: I took the script and made one that seems to work on Pixel 3's. Like the one you posted, put the lines you want added in the tmp/misc text file.
Tulsadiver said:
Try changing the updater-script code from busybox to toybox.
Edit: I took the script and made one that seems to work on Pixel 3's. Like the one you posted, put the lines you want added in the tmp/misc text file.
Click to expand...
Click to collapse
Thanks...is the one you sent meant to be a Magisk flashable module or a TWRP one? It looks like a Magisk one.
The problem I was having with most of the other scripts was two-fold:
1) There did seem to be some mount issues. Not all the scripts I was using used busybox, the just specified "mount". Additionally, some scripts appeared to do mount commands in the updater-script (with its special syntax) while others attempted to do them in the script that was called via the run_program() calls. I think the mounts were working in most cases, though some seemed to fail on remounts if the /system was already mounted. It seems the correct way to do this (at least on Pixel 3) is to use toybox mount commands in updater-script. I couldn't find a lot of info about this, but is toybox built into the Pixel 3? I assume so, unless Magisk was putting it in the /sbin directory (which I doubt).
2) Most of the scripts I was working with are twrp flashable files, and none of those were working (no errors though). Definitely the issue I found was that build.prop is not located in /system when twrp has mounted the filesystem. It is in /system/system/build.prop. I was able to get scripts working to modify this by ensuring the mount commands worked and pointing to /system/system/build.prop. I don't understand the change in the extra subdirectory, and not many people have mentioned it.
I haven't been really up on recent developments. It seems that people have become adverse to installing TWRP permanently in the recovery and maybe people aren't really using TWRP modules anymore instead of going to Magisk ones? I don't really understand why not to install TWRP because I can still pass all the safety checks, use google pay, etc with TWRP installed. But if this is the way the community is going, I guess I need to stop assuming I can do these things via TWRP flashes.
TraderJack said:
Thanks...is the one you sent meant to be a Magisk flashable module or a TWRP one? It looks like a Magisk one.
The problem I was having with most of the other scripts was two-fold:
1) There did seem to be some mount issues. Not all the scripts I was using used busybox, the just specified "mount". Additionally, some scripts appeared to do mount commands in the updater-script (with its special syntax) while others attempted to do them in the script that was called via the run_program() calls. I think the mounts were working in most cases, though some seemed to fail on remounts if the /system was already mounted. It seems the correct way to do this (at least on Pixel 3) is to use toybox mount commands in updater-script. I couldn't find a lot of info about this, but is toybox built into the Pixel 3? I assume so, unless Magisk was putting it in the /sbin directory (which I doubt).
2) Most of the scripts I was working with are twrp flashable files, and none of those were working (no errors though). Definitely the issue I found was that build.prop is not located in /system when twrp has mounted the filesystem. It is in /system/system/build.prop. I was able to get scripts working to modify this by ensuring the mount commands worked and pointing to /system/system/build.prop. I don't understand the change in the extra subdirectory, and not many people have mentioned it.
I haven't been really up on recent developments. It seems that people have become adverse to installing TWRP permanently in the recovery and maybe people aren't really using TWRP modules anymore instead of going to Magisk ones? I don't really understand why not to install TWRP because I can still pass all the safety checks, use google pay, etc with TWRP installed. But if this is the way the community is going, I guess I need to stop assuming I can do these things via TWRP flashes.
Click to expand...
Click to collapse
This is TWRP flashable to system. Not a module and cannot be installed via magisk manager.
Edit. The script was hard coded on that one. If you want to do custom scripting and not just add lines, use this one. In this one, bptweaks.sh and misc text are tweakable. In the first one, just misc.
This is not my work other than a few tweaks. This is an altered magisk installer. Used to be able to mount and run scripts.
Tulsadiver said:
This is TWRP flashable to system. Not a module and cannot be installed via magisk manager.
Edit. The script was hard coded on that one. If you want to do custom scripting and not just add lines, use this one. In this one, bptweaks.sh and misc text are tweakable. In the first one, just misc.
This is not my work other than a few tweaks. This is an altered magisk installer. Used to be able to mount and run scripts.
Click to expand...
Click to collapse
Thanks. I have not run this yet. It's not that I don't trust you, but I like to audit the script and since this appears to be a modified template the script is rather large and appears to be doing a bunch of things. Therefore I don't want to run it on my phone until I know exactly what it is modifying.
However, I can't see how this will work because it seems to have the same issue as the other scripts. In updater-script it has the following relevant section:
Code:
bp="/system/build.prop"
toybox mount /system
toybox mount /data
if [ -f /system/build.prop.bak ];
then
rm -rf $bp
cp $bp.bak $bp
else
cp $bp $bp.bak
fi
echo " " >> $bp
echo "# Enable pixel theme" >> $bp
echo " " >> $bp
for mod in misc;
do
for prop in `cat /data/tmp/tmp/$mod`;do
export newprop=$(echo ${prop} | cut -d '=' -f1)
sed -i "/${newprop}/d" /system/build.prop
echo $prop >> /system/build.prop
done
done
So it uses toybox to mount /system and then attempts to modify /system/build.prop by iterating through the misc file and editing inline the changes found therein. The problem here is that build.prop isn't in that location on my phone. Look at this adb output from my phone with TWRP running (slightly edited because I get linker errors on every command once /system is mounted..due to some endless recursion in the file system I think?):
Code:
crosshatch:/ # ls -l /system
total 0
drwx------ 3 root root 0 1970-08-29 20:11 etc
crosshatch:/ # toybox mount /system
crosshatch:/ # ls /system
acct d firmware init.recovery.crosshatch.rc lost+found postinstall storage
bin data init init.recovery.sdm845.rc metadata proc sys
bugreports default.prop init.crosshatch.rc init.usb.configfs.rc mnt product [B]system[/B]
cache dev init.environ.rc init.usb.rc odm res ueventd.rc
charger dsp init.rc init.zygote32.rc oem sbin vendor
config etc init.recovery.blueline.rc init.zygote64_32.rc persist sdcard
crosshatch:/ # cd /system/system
crosshatch:/system/system # ls
app [B]build.prop[/B] etc fake-libs64 framework lib64 product vendor
bin compatibility_matrix.xml fake-libs fonts lib priv-app usr
So I simply don't see how it is possible that the script you sent would modify /system/system/build.prop.
You have a Pixel 3 and ran this and it worked? If so, I'm curious does your build.prop show in the same location as mine within your adb session?
The only way I could see this working is if there is something magic in the code I haven't reviewed yet or somehow the filesystem from *within* twrp (the context of where this runs) looks different than if I do this over adb. I don't think that is likely, but I'm not an expert.
TraderJack said:
Thanks. I have not run this yet. It's not that I don't trust you, but I like to audit the script and since this appears to be a modified template the script is rather large and appears to be doing a bunch of things. Therefore I don't want to run it on my phone until I know exactly what it is modifying.
However, I can't see how this will work because it seems to have the same issue as the other scripts. In updater-script it has the following relevant section:
Code:
bp="/system/build.prop"
toybox mount /system
toybox mount /data
if [ -f /system/build.prop.bak ];
then
rm -rf $bp
cp $bp.bak $bp
else
cp $bp $bp.bak
fi
echo " " >> $bp
echo "# Enable pixel theme" >> $bp
echo " " >> $bp
for mod in misc;
do
for prop in `cat /data/tmp/tmp/$mod`;do
export newprop=$(echo ${prop} | cut -d '=' -f1)
sed -i "/${newprop}/d" /system/build.prop
echo $prop >> /system/build.prop
done
done
So it uses toybox to mount /system and then attempts to modify /system/build.prop by iterating through the misc file and editing inline the changes found therein. The problem here is that build.prop isn't in that location on my phone. Look at this adb output from my phone with TWRP running (slightly edited because I get linker errors on every command once /system is mounted..due to some endless recursion in the file system I think?):
Code:
crosshatch:/ # ls -l /system
total 0
drwx------ 3 root root 0 1970-08-29 20:11 etc
crosshatch:/ # toybox mount /system
crosshatch:/ # ls /system
acct d firmware init.recovery.crosshatch.rc lost+found postinstall storage
bin data init init.recovery.sdm845.rc metadata proc sys
bugreports default.prop init.crosshatch.rc init.usb.configfs.rc mnt product [B]system[/B]
cache dev init.environ.rc init.usb.rc odm res ueventd.rc
charger dsp init.rc init.zygote32.rc oem sbin vendor
config etc init.recovery.blueline.rc init.zygote64_32.rc persist sdcard
crosshatch:/ # cd /system/system
crosshatch:/system/system # ls
app [B]build.prop[/B] etc fake-libs64 framework lib64 product vendor
bin compatibility_matrix.xml fake-libs fonts lib priv-app usr
So I simply don't see how it is possible that the script you sent would modify /system/system/build.prop.
You have a Pixel 3 and ran this and it worked? If so, I'm curious does your build.prop show in the same location as mine within your adb session?
The only way I could see this working is if there is something magic in the code I haven't reviewed yet or somehow the filesystem from *within* twrp (the context of where this runs) looks different than if I do this over adb. I don't think that is likely, but I'm not an expert.
Click to expand...
Click to collapse
Most of the code has to do with mounting and unmounting magisk.img and not applicable. I ran this on my pixel 3XL and did indeed put the code in my build.prop. I'm not saying the code itself works, just that this edits the build.prop. Here is a version that has a bit more of the code stripped out.
Edit:. That code in bptweaks.sh and that you posted is not mine either. It came from one of the links in your original post. I thought you were indicating that you could not get a script to install. All I did was try and make a vehicle for a script that could modify the build.prop.
Tulsadiver said:
Most of the code has to do with mounting and unmounting magisk.img and not applicable. I ran this on my pixel 3XL and did indeed put the code in my build.prop. I'm not saying the code itself works, just that this edits the build.prop. Here is a version that has a bit more of the code stripped out.
Click to expand...
Click to collapse
That's really interesting/strange. Would you do me a favor when you have a few minutes and adb in with twrp booted and see if your file system mirrors mine? Specifically, when you mount /system does build.prop show inside /system or in /system/system/build.prop.
If I adb into my phone with the OS booted it is in /system/build.prop, but from within twrp it is one more /system directory deep.
I'll try to review the latest one you sent and run it on my phone to see if it indeed works. I have a bit more confusion because the way this zip is built is that the updater-script looks to be a normal shell script. In most of these flashables I have seen the update-script is a special script that only uses a special syntax of commands, such as:
Code:
package_extract_file();
set_perm();
mount();
run_program("/tmp/backuptool.sh", "backup");
etc...
The code I see in this update-script is what you would normally find in an external shell script like that referenced in the run_program() above.
I don't know how Magisk actually builds theirs, though I can say that the updater-binary is significantly larger than the one used in other flashable zip files I have seen. Can you speak to that at all?
TraderJack said:
That's really interesting/strange. Would you do me a favor when you have a few minutes and adb in with twrp booted and see if your file system mirrors mine? Specifically, when you mount /system does build.prop show inside /system or in /system/system/build.prop.
If I adb into my phone with the OS booted it is in /system/build.prop, but from within twrp it is one more /system directory deep.
I'll try to review the latest one you sent and run it on my phone to see if it indeed works. I have a bit more confusion because the way this zip is built is that the updater-script looks to be a normal shell script. In most of these flashables I have seen the update-script is a special script that only uses a special syntax of commands, such as:
Code:
package_extract_file();
set_perm();
mount();
run_program("/tmp/backuptool.sh", "backup");
etc...
The code I see in this update-script is what you would normally find in an external shell script like that referenced in the run_program() above.
I don't know how Magisk actually builds theirs, though I can say that the updater-binary is significantly larger than the one used in other flashable zip files I have seen. Can you speak to that at all?
Click to expand...
Click to collapse
The update-binary is the BusyBox installer script and zip extraction. It runs first, then the updater-script runs. Open the update-binary with a text editor. Above the ELF files is script.
Tulsadiver said:
The update-binary is the BusyBox installer script and zip extraction. It runs first, then the updater-script runs. Open the update-binary with a text editor. Above the ELF files is script.
Click to expand...
Click to collapse
Ok...so that appears to be completely different to how most "normal" flashable zip files work where the update-binary is a smaller full binary script that then launches the update-script which uses the syntax I mentioned above. Clearly the Magisk devs know what they are doing but all the other flashables I have downloaded (and created) have not used this method. Unfortunately, it makes it impossible for me to compare apples to apples in why nothing else works and really doesn't answer any of the questions. While this script may work, it gives me no answers as to why it does, and why the others fail :/
TraderJack said:
Ok...so that appears to be completely different to how most "normal" flashable zip files work where the update-binary is a smaller full binary script that then launches the update-script which uses the syntax I mentioned above. Clearly the Magisk devs know what they are doing but all the other flashables I have downloaded (and created) have not used this method. Unfortunately, it makes it impossible for me to compare apples to apples in why nothing else works and really doesn't answer any of the questions. While this script may work, it gives me no answers as to why it does, and why the others fail :/
Click to expand...
Click to collapse
Yes, it's in the mounting. Pixel 3's don't seem to use BusyBox. They've looks like they've gone to toybox. What this dumbed down version of magisk util_function.sh appears to be doing is installing BusyBox and setting it to be used instead. This one is more like you are used to seeing. The only way I could get it to work is still by using magisk util_function.sh for mounting purposes. I would not be able to write a script like that myself.
I haven't read all of the replies in this thread so forgive me if I'm saying something that someone else has already said.
I had the same issue as you've had when I first started flashing custom files onto my 1st Gen Pixel and what I've found that's worked for me is to do this:
1.) Boot into TWRP & flash Magisk
2.) Reboot into bootloader
3.) Boot into TWRP again & flash your custom files
4.) Boot up the phone as you normally would
Not 100% sure this will work since you have a Pixel 3 and this worked for me on a Pixel 1 but I'd think it would be worth trying.
HesThatGuy said:
I haven't read all of the replies in this thread so forgive me if I'm saying something that someone else has already said.
I had the same issue as you've had when I first started flashing custom files onto my 1st Gen Pixel and what I've found that's worked for me is to do this:
1.) Boot into TWRP & flash Magisk
2.) Reboot into bootloader
3.) Boot into TWRP again & flash your custom files
4.) Boot up the phone as you normally would
Not 100% sure this will work since you have a Pixel 3 and this worked for me on a Pixel 1 but I'd think it would be worth trying.
Click to expand...
Click to collapse
Thanks, but 100% not relevant - not only to the replies, but also to the OP.
TraderJack said:
Thanks, but 100% not relevant - not only to the replies, but also to the OP.
Click to expand...
Click to collapse
Sounds like you need to disable dm-verity to edit build prop without using Magisk. Magisk is one big overlay seems to be the way of the future tho. I personally been disabling verity then adding xbin folder to root then linking to system then installing BusyBox to xbin. I don't like using Magisk to install BusyBox module or any module that alters the system because you will have to use Magisk to modify system from there on out instead of jus manully doing it yourself with a root explorer.
Also if you was to flash a open gapps zip it would add a addon.d folder to system. which open gapps and Magisk will install their backup scripts to the addon.d folder. would be a good place for you to add your own backup script as well.
Yeah, you need to disable verity to properly mount /system, /vendor, and /product partitions. It is not hard. In magisk manager just go to advanced options, untick verity, then install magisk from the app. After changes you can put verity back if that bugs you.
Related
superuser,busybox and mount system
I was going to make a Rom but as we are waiting for 2.1 I saw no point!I did this instead..... This update.zip should be flashed through a custom recovery!! it will root and install busybox.Also includes a script to mount system. after obtaining su and pressing allow type mnt in shell or terminal to mount system. saves having to type mount -o re,remount -t yaffs2 /dev/block/mtdblock3 /system everytime. Also contains apps2sd which is working (as far as i can see) on a standard kernel! to turn it on.. in cmd window type adb shell mnt followed by apps2sd on this will only work if you have a ext2/3 partition BEWARE it may remove your apps so you will need to reinstall them download... http://www.multiupload.com/05RYNZXFMX
Does it work with stock kernel?
yes I am using stock kernel from 2.73.405.66
Oh.. great news! I am trying to install busybox for days without any success... But could you tell us what to do with these scripts ? Thanks a lot!
i would call it a zipfile, not a script, and looking at it it seems that it should be flashed through the custom recovery image... btw, will this be suitable to root the final release, once it is out? i suppose it will have ro.secure=0 and therefore boot.img needs to be altered?
it contains no boot.img yet so is useable on any rom i think? As for the script all it does is mount the system like adb remount but on a standard kernel/rom it will say operation not permitted or something similar, so instead with this update.zip type (in a cmd window) adb shell then mnt and it will say System mounted OK. Voila the system is mounted to allow such things as apps2sd on,rm <FILE> etc.. Installing it through custom recovery SHOULD install all the parts inside and give permissions. Have updated first post..
what i meant is will it work on a stock rom with release-keys? but nevermind, i'll just try when it is there...
i have reflashed my phone with WWE 2.73.405.5 146733 CL#61267 release-keys and yes,it works. I wouldnt just go flashing the 2.1 update when it arrives though you should look into extracting a rom.zip from RUU and only flash the boot.img and the system.img. Otherwise you could end up with a perfected SPL and never be able to root
have now tried with ALL available release key kernels and confirm it works well.Apart from apps2sd,this is random on what kernels it works. when 2.1 is released I will edit the standard kernels ro.secure thing and will be available here.
[MOD] HULU Flash Hack - Flashex 2.05(5/2/12) Auto Hex-edit libflashplayer.so
FLASHEX 2.05 (unified release 4)(Release Date: 5/2/2012) Description Flashex is designed to allow people using an Android device to watch hulu and some other restricted sites with Adobe Flash Player and a properly configured web browser as if it was a Windows PC. Dolphin HD Stock Browser(choose "request desktop site" in menu each time) is a good choice but any browser that allows you to act as Desktop via settings should work. Note: Dolphin HD has some issues with full screen video at the moment so I have switched over to useing the stock browser and selecting "request desktop site" from the upper right-hand menu for now this works and has good full screen performance on FlexReaper and Stock ICS 4.0.3. How it works The script will look for libflashplayer.so then attempt to create a copy, edit the copy, and copy the edited version back. It stores the edited copy, and writes it over the default file each time it's run. It will check the version of the current libflashplayer.so file each time before it copies the edited version over. If libflashplayer.so's version has been upgraded or downgraded it will make a new copy, edit, write it back and store the new one to use each time. I suggest using Script Manager to run the script at boot once you run it the first time manually to make the first edited copy. What's New in Version 2.05? -Added a few more checks for libflashplayer.so to help improve troubleshooting and configuring on different ROMs and to eliminate the possibility of a hang if libflashplayer.so is not readable. (Still waiting on feed back and/or -x mode debug output reports. feel free post them or better yet PM them to me) What's New in Version 2.04? -Added support for Custom BusyBox from CynogenMod (BusyBox 1.19.4-cm9) when testing the Busybox version What's New in Version 2.03? -Added checks to verify Busybox location, permisssions, and version to verify compatability and inform the user if they need to update/reinstall busybox or make a configuration change. -Various minor refinements. -Can now safely be test run on ANY device since it will verify the location of all required elements prior to performing any task. NOTE: This doesnt mean it will enable hulu on an old 500mhz 2.2 device, just that it should be safe to use to modify Adobe Flash on any device capable of properly running it.(If your Adobe Flash is installed in a diffrent location you will need to configure the script to point it's install directory, or put a copy of your libflashplayer.so file into the Flashex2 directory and name it AND_libflashplayer.so and copy the resulting WIN_libflashplayer.so back by hand if you prefer.) What was new in Version 2.02? -Fixed various typoes in output messages -Added a fix for people having issues with strings, grep etc returning as not found when /system/xbin is either not in the users default $PATH or is too low in the list to get used. What was new in Version 2.01? -Many minor bug fixes -Scripts have been unified into a single script. -Made some changes to how version checking is done -Script is safer, more reliable, and easier to use over all.(at least IMO hehe) -Automatic re-edit of edited source file, when either an upgrade or downgrade is detected. This allows the script to be run at boot via Script Manager, or other while still leaving, Adobe Flash to auto update. -Script is now a single executable file that will both hex edit Adobe Flash(each update), and copy the edited file over to /data when needed. -Improved version detection -Improved output messages Some notes on running during bootup Once you have decompressed the Flashex2 folder and flashex.sh script to /mnt/sdcard/Flashex2 you will be able to run it automatically at boot via Script Manager if you wish. I currently have been using it this way. I have tested it performing the hexedit during a boot up. It works fine. Known Limitation Note: This only applies to auto-running the script via Script Manager, Cron, what ever It takes about 2 minutes with a Tegra 2 to complete the hexedit of the file. Because of this when booting after an update to libflashplayer.so it will be editing the file for a min or two after your home screen shows. You will want to wait 3 min or so to be safe before you try to use Adobe Flash. This will ONLY happen when the version changes. Since Adobe Flash isn't changed that often it's not a big deal. The rest of the time, it will be the same version so it will just take a few seconds to copy the file over. This allows you to just watch when you like even right after a system boot. Install Instructions Quick Directions: Download file, unzip/extract the Flashex2 folder and it's contents, copy it to the sdcard to end up with /mnt/sdcard/Flashex2/flashex.sh. Run flashex.sh as root. Set web browser to Desktop. Enjoy watching hulu. Full Directions: When using Flashex205.zip via a File Manager like Astro for example. 1) Either download Flashex204b.zip directly to your tablet, or copy it to a micro SD card via PC.(note: you could unzip the contents in Windows if you prefer) 2) Save, Copy or Move Flashex205.zip to /mnt/sdcard/ It has a folder inside already of the correct name. 3) Open Flashex205.zip, then copy/paste the whole folder to /mnt/sdcard/ Note: After you do this you should have a folder named Flashex2 on your internal sdcard example: /mnt/sdcard/Flashex2 4) Inside the Flashex2 folder from the zipfile is flashex.sh 5) run flashex.sh either via terminal emulator or with an app like Script Manager. The script "can" be run without root, BUT it will only make the hexedited file. It MUST be run as root if you also want the script to install the edited file so you can watch hulu. You can also copy the file by hand. When using flashex205.tar.gz via a terminal emulator do the following. 1) Either download the file directly to your tablet, or copy it to a micro SD card. 2) Copy or Move the file to /mnt/sdcard/ example(copy): cp /mnt/external_sd/flashex205.tar.gz /mnt/sdcard/ example(move): mv /mnt/external_sd/flashex205.tar.gz /mnt/sdcard/ 3) unzip and untar the Flashex folder and flashex.sh script from flashex205.tar.gz gzip -d /mnt/sdcard/flashex205.tar.gz tar -xvf /mnt/sdcard/flashex205.tar Note: If you get an error saying not found. Your trying to install it in a diffrent location then it's currently configured you can probably figure out how to make it work easy enough. Just remember to set the path to the script inside the script it's self so it knows where make/read the edited file. 4) Now change working directories and run the script. cd /mnt/sdcard/Flashex2 5) Run the script(su is optional, but running as root it wont copy the edited file over) su sh flashex.sh Note: I suggest using sh before the script name though it's not nessesary if the path to sh at the top of the script matches yours. Confirmed Compatable Device List(Make sure you are rooted if you want to use the script to install the modified file) Acer Iconia A100, A200, A500 HC or ICS, FlexReaper ------ Use Latest Version Samsung Galaxy S 4G rooted modified Gingerbread 2.3 --- Use Latest Version Samsung Galaxy Nexus LTE ----------------------------------- Use Latest Version Asus Eepad Transformer Prime ------------------------------- Use Version 2.2 or Latest Version Motorola Droid Razr ------------------------------------------- Use Latest Version HTC EVO 3D --------------------------------------------------- Use Latest Version HTC EVO 4G running mikg v11 ------------------------------- Use Latest Version Note: Any Device that is compatable with Adobe Flash and capable of playing hulu videos(500 Mhz or better ARM7 CPU 256 MB ram, Android 2.2 or better) that has been rooted and has busybox installed should be compatable If you are attempting to use a Busybox older then v1.18.1 You will have to change a value at the top of the script before attempting to run it since I'm not sure how old of versions are 100% compatible. =============================================== ATTN: SUPPORT, QUESTIONS, COMMENTS If you need help getting it to work for your device and cant post in this section you can follow this ->SUPPORT LINK HERE You can PM me or you can also try me on Twitter Legal Info Flashex205.sh was made by NoSudo for personal use anyone may use it or change it but I retain creative licence for my work. You should only take credit for your changes. I take no reponsablility for anyone elses actions. If you break something or violate any rules it's on you. If you wish to try and make money on it or use it for any comercial venture I expect to be contacted and informed so I may negociate an acceptable for profit licence with compensation. This software is FREE and yours to enjoy, give away, edit, use for Non-Profit purposes ONLY. A NOTE ON VERSIONS! I recommend the use of the latest version Flashex204.sh. If you have old versions installed. MAKE SURE YOU RUN THE RIGHT ONE. It's up you to reconfigure Script Manager etc. so don't forget or it will keep running the old one. ALSO Please remember to hit that Thanks button if you find my script useful.
I have been doing a little version testing. I can confirm that flashex v2.01 does edit other versions so far I have tested it with. I just tested with 11.1.115.7 and it works fine via xxd. Im going to test on Android with Busybox's hexdump next. I can also confirm that it works on 11.1.111.8 since my tablet just auto-updated. I simply ran the script and updated my hexed version from 11.1.111.7 to 11.1.111.8 as designed.
Just tried the new version and still a no go. See the pic for the full error. Ran with terminal emulator, gscript, and root explorer. Same error for all. And you have the .so file from the old version thread. .so path: /data/data/com.adobe.flashplayer/lib/libflashplayer.so ICS Leak .012. busybox 1.19.3
Joecascio2000 said: Just tried the new version and still a no go. See the pic for the full error. Ran with terminal emulator, gscript, and root explorer. Same error for all. And you have the .so file from the old version thread. .so path: /data/data/com.adobe.flashplayer/lib/libflashplayer.so ICS Leak .012. busybox 1.19.3 Click to expand... Click to collapse Weard here is the output I got running a test edit. I used the same 2.01 script just modified so it doesn't write to my adobe flash. Kind of sandbox I guess. As you can see it reads and edits it fine. I'll look some more. Command: '/mnt/sdcard/FLASHEX2_vtest/flashex_vtest.sh' ------------- Out: $ exec sh '/mnt/sdcard/FLASHEX2_vtest/flashex_vtest.sh' ================================================= Source Files Doesn't Exist Destination File: /mnt/sdcard/FLASHEX2_vtest/DST/libflashplayer.so Destination Ver: Adobe Flash says AND(Androiud) v1111157 Detected READ access for /mnt/sdcard/FLASHEX2_vtest/DST/libflashplayer.so Created /mnt/sdcard/FLASHEX2_vtest/cache Sucessfully... Checking... /mnt/sdcard/FLASHEX2_vtest/DST/libflashplayer.so preparing to copy and edit file........ Copy: /mnt/sdcard/FLASHEX2_vtest/cache/libflashplayer_PREMOD looks good ================================================= Preparing to create a hexdump......... Dont panic...This could take over a minute on a Tegra 2.. Its Converting an 8MB or so Binary on a little tablet...Just wait its fine Created a hexdump of /mnt/sdcard/FLASHEX2_vtest/cache/libflashplayer_PREMOD ================================================= Preparing to edit /mnt/sdcard/FLASHEX2_vtest/cache/libflashplayer_HEXDUMP.. This might take a minute too.... /mnt/sdcard/FLASHEX2_vtest/cache/libflashplayer_HEXDUMP has been edited... ================================================= Converting /mnt/sdcard/FLASHEX2_vtest/cache/libflashplayer_EDITED to binary... Binary File: /mnt/sdcard/FLASHEX2_vtest/WIN_libflashplayer.so created... Checking Binary file /mnt/sdcard/FLASHEX2_vtest/WIN_libflashplayer.so... ================================================= HEXEDIT SUCCESSFUL File: /mnt/sdcard/FLASHEX2_vtest/WIN_libflashplayer.so now reads as Version: WIN 11,1,115,7 Sent from my A100 using XDA
I'm at a bit of a loss as to why it's not working for you Joecascio2000. I'm still looking into it. I can confirm if I copy your libflashplayer.so v 11.1.115.7 to my device and run the script on it. I AM able to edit the file and get a good binary at the end. I was able to run it via Terminal IDE, Terminal Emulator, and Script Manager. Going by the error your getting I would say the issue could be related to Busybox. I know you say you have 1.19.3(same as mine) what happens if you try this from a Terminal strings /data/data/com.adobe.flashplayer/lib/libflashplayer.so | grep "AND 1[0-2],[0-9]*" You should get back a list of strings out of the binary, and one of them should say something like "AND 11,1,115,7" If that doesnt return the correct line, what does this return strings /data/data/com.adobe.flashplayer/lib/libflashplayer.so | grep "AND 1" This should return "AND 11,1,115,7" if it doesn't then I would take a closer look at your strings, and grep binaries which would indicate a possible issue with your copy of Busybox or maybe your $PATH as it could effect what version gets used when running a shell command. I still feel very confused by it working on my device and not on yours with the same file. However I also feel confident that since it works on my A100 we can get it working on yours too without much hassle. We just need to figure out what the deal is.
NoSudo said: Sent from my A100 using XDA Click to expand... Click to collapse Yeah so weird. I just tried it again after uninstalling flash and re-installing it. Same error. Maybe I'm executing it wrong. This is what I put: su sh /mnt/sdcard/Flashex2/flashex201.sh It does seem to work, just give me an error with the .so file. EDIT: and both string lines return "no such file or director". I just copy and pasted them in, maybe I did something wrong?...maybe its busybox...?
I just copy and pasted them in, maybe I did something wrong? Click to expand... Click to collapse copy and past of the strings command above should work yes. You can even just run the following strings /data/data/com.adobe.flashplayer/lib/libflashplayer.so If that give you bad command or something then you have an issue with either Busybox or your $PATH $PATH is a special variable that unix/linux/android uses to store the locations of programs like grep, strings, etc. It specifies various directories commands are stored in. If the directory strings is stored in IS NOT in your path the script will not be able to access the command, so I can't say at this point which issue it in fact is, but I'm 99% sure it's one of those two things at this point. That error is kinda old and can be erroneous. I'll look at that area a little closer later and see. If you rerun the script after a successful edit it will tell you if it was successful BTW. If /data/data/com.adobe.flashplayer/lib/libflashplayer.so is already edited and is the same version as the WIN_libflashplayer.so Source file it will just print out a message that displays the actual version string from inside both files. The output will look somthing like this Source File: /2.01FLASHEX_Dev/Lib_Version_Testing/WIN_libflashplayer.so Source Ver: Adobe Flash says WIN(Windows) v1111157 Destination File: /2.01FLASHEX_Dev/Lib_Version_Testing/DST/libflashplayer.so Destination Ver: Adobe Flash says WIN(Windows) v1111157 ================================================= It looks like you dont need make any further changes at this time. Make sure you have set your browser to Desktop in settings(try Dolphin HD) a
Joecascio2000 said: Yeah so weird. I just tried it again after uninstalling flash and re-installing it. Same error. Maybe I'm executing it wrong. This is what I put: su sh /mnt/sdcard/Flashex2/flashex201.sh It does seem to work, just give me an error with the .so file. EDIT: and both string lines return "no such file or director". I just copy and pasted them in, maybe I did something wrong?...maybe its busybox...? Click to expand... Click to collapse It could be. If you don't have a "strings" command the script wont work for you in it's current state. I made extensive use of strings to read info out of the binary files for version checking and to confirm the edit. The error you got is something you could get from no strings command. It could also just be that the location "strings" is installed if it IS NOT in your $PATH for your ENV this would be a simple fix, in fact I'm tempted to add a PATH="" export PATH line back into the script just in case of stuff like this. I had removed it thinking it overkill. Two diffrent folks seem to have a Busybox installer available via play.google.com. I use the one from J Rummy because it's only 1.99 for the Pro version instead of 4.99 and so far it has all the features I want and even has 1.19.4 available currently. It sounds like you may just need to figure out the location of the strings command and make sure that directory is exported as part of your $PATH. Let me know if would like assistance figuring this out.
NoSudo said: It could be. If you don't have a "strings" command the script wont work for you in it's current state. I made extensive use of strings to read info out of the binary files for version checking and to confirm the edit. The error you got is something you could get from no strings command. It could also just be that the location "strings" is installed if it IS NOT in your $PATH for your ENV this would be a simple fix, in fact I'm tempted to add a PATH="" export PATH line back into the script just in case of stuff like this. I had removed it thinking it overkill. Two diffrent folks seem to have a Busybox installer available via play.google.com. I use the one from J Rummy because it's only 1.99 for the Pro version instead of 4.99 and so far it has all the features I want and even has 1.19.4 available currently. It sounds like you may just need to figure out the location of the strings command and make sure that directory is exported as part of your $PATH. Let me know if would like assistance figuring this out. Click to expand... Click to collapse When I open terminal emulator the first line reads: [email protected]:/ $ export PATH=/data/local/bin: $PATH Also, I can't update busybox because for my current root method 1.19.3 is required.
Joecascio2000 said: When I open terminal emulator the first line reads: [email protected]:/ $ export PATH=/data/local/bin: $PATH Also, I can't update busybox because for my current root method 1.19.3 is required. Click to expand... Click to collapse You don't need a newer version of Busybox I'm running the same version. it's your $PATH I will post an updated version that includes an Export PATH line to resolve after I eat some dinner. for now you can copy/paste this into a terminal before running the script. Im guessing if you run that, then the script it will work PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/system/sbin:/system/xbin:/system/bin:/data/local/bin:/vendor/bin; export PATH
Darn...still isn't working. Lol my tab hates me. See the pic I think its a little different. here's a link the one below is a little low res: http://i.imgur.com/uP9ZR.png
Joecascio2000 said: Darn...still isn't working. Lol my tab hates me. See the pic I think its a little different. here's a link the one below is a little low res: http://i.imgur.com/uP9ZR.png Click to expand... Click to collapse It looks like you might still be missing the strings command. Because it doesnt look like anything is getting passed to grep. It looks like strings didnt run, so grep tried to look for the search expression as a file name. what do you get if you type ls -la /system/xbin/strings or even just ls -la /system/xbin I show a symbolic link for /system/xbin/strings that points to Busybox. If it's in another location with your version of Busybox you just need to make sure the strings command is located in the path you use. If you dont have a strings command at all for some reason since you have the same version of Busybox 1.19.3 you should be able to just make a Symbolic Link in /system/xbin(or what ever space you are configured to use) called strings that points to busybox. All those buxybox commands are symlinks to the same binary file in reality.
NoSudo said: It looks like you might still be missing the strings command. Because it doesnt look like anything is getting passed to grep. It looks like strings didnt run, so grep tried to look for the search expression as a file name. what do you get if you type ls -la /system/xbin/strings or even just ls -la /system/xbin I show a symbolic link for /system/xbin/strings that points to Busybox. If it's in another location with your version of Busybox you just need to make sure the strings command is located in the path you use. If you dont have a strings command at all for some reason since you have the same version of Busybox 1.19.3 you should be able to just make a Symbolic Link in /system/xbin(or what ever space you are configured to use) called strings that points to busybox. All those buxybox commands are symlinks to the same binary file in reality. Click to expand... Click to collapse Both commands showed: not found, however, I looked in /system/xbin/ and busybox and strings are in that folder. Also, right under strings is ( -> busybox )
Joecascio2000 said: Both commands showed: not found, however, I looked in /system/xbin/ and busybox and strings are in that folder. Also, right under strings is ( -> busybox ) Click to expand... Click to collapse Yep the strings --> busybox is the way strings and the other Busybox commands look the "--> Busybox" is to show what it links to, but the name is still strings. It's sorta like a shortcut in windows in a way. Anyway that means you should be able to use strings try copy/paste this before you run the script in the same terminal. PATH=$PATH:/system/xbin; export PATH that take what ever you currently have for a $PATH and add /system/xbin to it you can view your $PATH by typing echo $PATH Either way if your Busybox is properly installed into /system/xbin this should return a few lines out the binary. Just to confirm it's a working command on your system. /system/xbin/strings /data/data/com.adobe.flashplayer/lib/libflashplayer.so | grep "AND" I will come up with an up date to check for the location of Busybox and use hard paths for the commands, later in the week. That should avoid this issue coming up in the future.
First off thank you for helping with my pain-in-the-you-know-what tablet. But sadly still a no go. I did get some more info though: http://i.imgur.com/oVxBz.png It showed AND 11,1,115,7. I think it's either the way I'm putting in the commands or the way my tab is rooted.
Joecascio2000 said: First off thank you for helping with my pain-in-the-you-know-what tablet. But sadly still a no go. I did get some more info though: http://i.imgur.com/oVxBz.png It showed AND 11,1,115,7. I think it's either the way I'm putting in the commands or the way my tab is rooted. Click to expand... Click to collapse First off, Your very welcome. I actually enjoy this kinda stuff as long as I have time. Next, Since it DID respond with AND 11,1,115,7 I am sure you CAN use the script, once updated. I will be working on an update this weekend. I may have a revised version made today, if I get an extra hour to dedicate to make the changes. The issue seems to be, for what ever reason your device is having an issue with /system/xbin not being in your PATH or PATH and ENV not working as it should, BUT since /system/xbin/busybox and the symlink /system/xbin/strings both work when you type the full path, it's not a big deal. I'm also going to try to write in a feature to test the location and version of Busybox and make sure it lists "strings" as a defined function, so the script can identify and resolve the issue when possible.
Updated Version should resolve any issues with the script not being able to use strings, grep etc on some systems. Also check here for information on configuring Terminal Emulator to work correctly with Busybox. This I belive would get the old script working for those that had issues also for what it's worth.
NoSudo said: Updated Version should resolve any issues with the script not being able to use strings, grep etc on some systems. Also check here for information on configuring Terminal Emulator to work correctly with Busybox. This I belive would get the old script working for those that had issues also for what it's worth. Click to expand... Click to collapse This is with the new version 2.02 and after configuring Terminal Emulator: http://i.imgur.com/Rb458.png
Joecascio2000 said: This is with the new version 2.02 and after configuring Terminal Emulator: http://i.imgur.com/Rb458.png Click to expand... Click to collapse Man I am at a total loss as to what your system is doing. That just doesn't make any sense at all. Are you running the script or Copy/Pasting lines into Terminal? What Busybox are you running anyway, not the version where did you get it? It seems totally defective honestly. The script should work fine for you at this point TBH. Heck it works for me on my Linux PC too when I change the paths, and swap out xxd for hexdump and change the pattern format. At this point I can only conclude that either you have a bad version of Busybox or you are doing something wrong. Here is an example of what I mean BUSYBOXPATH="/system/xbin" if [ -e "$BUSYBOXPATH/busybox" ]&&[ -e "$BUSYBOXPATH/grep" ]; then echo "Found BusyBox in $BUSYBOXPATH" BSYBX_VER=`$BUSYBOXPATH/busybox | $BUSYBOXPATH/grep "BusyBox v"` echo "Version: $BSYBX_VER" else echo "Unable to confirm location of BusyBox, please configure the script" exit 3 fi This statement says if /system/xbin/busybox and /system/xbin/busybox exist to echo "Found" etc. Your output has those lines, so those commands HAVE to exist in those locations or it would respond with Unable to confirm location of BusyBox, please configure the script. However the script is unable to read the Version line off busybox because busybox isnt spitting out anything or maybe it's been modified and no longder displays the correct response. Again even a Desktop PC with Linux on it get's this response from Busybox. What happens when you just type /system/xbin/busybox Do you get anything? You should get something like; $ busybox BusyBox v1.19.3 (2011-11-22 01:37:10 MST) multi-call binary Copyright (C) 1998-2011 Erik Andersen, Rob Landley, Denys Vlasenko and others. Licensed under GPLv2. See source distribution for full notice. Usage: busybox [function] [arguments]... or: function [arguments]... BusyBox is a multi-call binary that combines many common Unix utilities into a single executable. Most people will create a link to busybox for each function they wish to use and BusyBox will act like whatever it was invoked as! Currently defined functions: [, [[, addgroup, adduser, adjtimex, ar, arping, ash, awk, basename, brctl, bunzip2, bzcat, bzip2, cal, cat, chgrp, chmod, chown, chroot, chvt, clear, cmp, cp, cpio, crond, crontab, cut, date, dc, dd, deallocvt, delgroup, deluser, df, dirname, dmesg, dos2unix, dpkg, dpkg-deb, du, dumpkmap, echo, ed, egrep, eject, env, expand, expr, false, fbset, fdflush, fdisk, fgrep, find, fold, free, freeramdisk, fsck.minix, ftpget, ftpput, getopt, getty, grep, gunzip, gzip, halt, head, hexdump, hostid, hostname, httpd, hwclock, id, ifconfig, ifdown, ifup, init, ip, ipcalc, kill, killall, klogd, last, length, less, linuxrc, ln, loadfont, loadkmap, logger, login, logname, logread, losetup, ls, lzmacat, makedevs, md5sum, mdev, mesg, microcom, mkdir, mkfifo, mkfs.minix, mknod, mkswap, mktemp, more, mount, mt, mv, nameif, nc, netstat, nslookup, od, openvt, passwd, patch, pidof, ping, ping6, pivot_root, poweroff, printf, ps, pwd, rdate, readlink, realpath, reboot, renice, reset, rm, rmdir, route, rpm, rpm2cpio, run-parts, sed, setkeycodes, sh, sha1sum, sleep, sort, start-stop-daemon, static-sh, strings, stty, su, sulogin, swapoff, swapon, sync, syslogd, tac, tail, tar, tee, telnet, telnetd, test, tftp, time, top, touch, tr, traceroute, true, tty, udhcpc, umount, uname, uncompress, unexpand, uniq, unix2dos, unlzma, unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, vlock, watch, watchdog, wc, wget, which, who, whoami, xargs, yes, zcat Note: Busybox in Android will have a slightly diffrent list of functions but the version line etc is the same.
NoSudo said: Man I am at a total loss as to what your system is doing. That just doesn't make any sense at all. Are you running the script or Copy/Pasting lines into Terminal? What Busybox are you running anyway, not the version where did you get it? It seems totally defective honestly. The script should work fine for you at this point TBH. Heck it works for me on my Linux PC too when I change the paths, and swap out xxd for hexdump and change the pattern format. At this point I can only conclude that either you have a bad version of Busybox or you are doing something wrong. Click to expand... Click to collapse The command I'm using is Su Sh /mnt/sdcard/flashex2/flashex202.sh I think it might be my version of busybox. I think its a modified version because rooting ICS on the a100 was a difficult process. It also says not to update busybox because root will be broken. Sent from my A100 using XDA Premium HD app
[Q] Rooting does not work 100% fine
Hello. I have rooted my phone using http://htc-one.wonderhowto.com/how-to/unlock-bootloader-root-your-htc-one-m8-0154444/ (in short, it's using SuperSU 2.00) After some efforts, Root Checker says i am fine. I can get id 0 from adb, and via ssh. But ... Busybox fails to install. And if I remount /system RW, and mess in there a bit (like mkdir /system/tmp ), the mess is removed after reboot. Changes are not permanent. Must I change my su app for superuser mentionned in the FAQ of the section (via recovery) ? Are there things to do before this migration ? Other possible issues ? I am used to fully unlocked HTC Sensation, where I changes to /system are easily permanent. But it was done using an exploit, few before HTC allowed rooting officially. Rooted M8 does not seem as much friendly ... I *really* need busybox to work, and make permanent changes to /system. I am stuck. Thanks.
doublehp said: Hello. I have rooted my phone using http://htc-one.wonderhowto.com/how-to/unlock-bootloader-root-your-htc-one-m8-0154444/ (in short, it's using SuperSU 2.00) After some efforts, Root Checker says i am fine. I can get id 0 from adb, and via ssh. But ... Busybox fails to install. And if I remount /system RW, and mess in there a bit (like mkdir /system/tmp ), the mess is removed after reboot. Changes are not permanent. Must I change my su app for superuser mentionned in the FAQ of the section (via recovery) ? Are there things to do before this migration ? Other possible issues ? I am used to fully unlocked HTC Sensation, where I changes to /system are easily permanent. But it was done using an exploit, few before HTC allowed rooting officially. Rooted M8 does not seem as much friendly ... I *really* need busybox to work, and make permanent changes to /system. I am stuck. Thanks. Click to expand... Click to collapse The /system partition is write protected on stock, meaning you can't add, modify, or delete files there. To disable this, you need to flash a kernel or rom with this disabled. Pretty much all sense based roms/kernels will state this in the features. I believe S-Off also disables it if you want to go the extra mile. PS: Write protection is disabled in recovery. That is why superuser/root could be installed there. PPS: Here is the kernel I run (protection disabled): http://forum.xda-developers.com/showthread.php?t=2705613
akitten007 said: The /system partition is write protected on stock, meaning you can't add, modify, or delete files there. To disable this, you need to flash a kernel or rom with this disabled. Pretty much all sense based roms/kernels will state this in the features. I believe S-Off also disables it if you want to go the extra mile. PS: Write protection is disabled in recovery. That is why superuser/root could be installed there. PPS: Here is the kernel I run (protection disabled): http://forum.xda-developers.com/showthread.php?t=2705613 Click to expand... Click to collapse So, is there a way to install busybox via recovery ? I did 3 things in recovery: all in /system/xbin - chmod +s su - touch t - mkdir tmp after reboot to normal mode, SUID bit was removed, but t and tmp are still here. So, how do I install busybox ? New issue: /data has the nodev flag; is it possible to remove it ? I did not found /dev/shm ; was it moved somewhere else ? Any other place for similar use ? (world write temp folder in RAM).
akitten007 said: PPS: Here is the kernel I run (protection disabled): http://forum.xda-developers.com/showthread.php?t=2705613 Click to expand... Click to collapse If your kernel allows me to install busybox, can i backup my original kernel to restaure it afterwards ? Can I install busybox manually via recovery+adb ? I don't have any dev suite, but a good linux station; so, I can unzip, list, copy, and so on ... if there is not too much work to do.
doublehp said: If your kernel allows me to install busybox, can i backup my original kernel to restaure it afterwards ? Can I install busybox manually via recovery+adb ? I don't have any dev suite, but a good linux station; so, I can unzip, list, copy, and so on ... if there is not too much work to do. Click to expand... Click to collapse Now you're starting to go over my head. If you want to keep your current kernel, I would try using this method here to manually add the module that disables the protection http://forum.xda-developers.com/showthread.php?t=2702575. I usually just install busybox using rom toolbox or any other busybox app. You could search for a busybox zip, but just disabling the write protection is a better option in my opinion. And I have actually 0.00 idea what flags mean on folders (sorry).
I rooted using TWRP recovery and super su. That guide you posted gives unnecessary instructions. TWRP automatically installs the SU binary and Super su the first time you boot into it. I was able to update Super su via google play, no need for the update zip. Just follow the instructions after rebooting to system from TWRP recovery. I'm s-off, unlocked, my kernel, firmware and os are stock, only thing that isn't is recovery. I have write access to system and external sd card. All I did was make it writable with root explorer and have installed busy box no problem using this app https://play.google.com/store/apps/details?id=stericson.busybox.
I was given a better fix. http://forum.xda-developers.com/showthread.php?t=2701816 In short: adb push /mnt/big/tmp/wp_mod_m8.ko /mnt/sdcard/Download/ insmod /mnt/sdcard/Download/wp_mod_m8.ko mount -o remount,rw /system cd /system touch z mkdir zz reboot [email protected]_m8:/storage/emulated/legacy # cd /system/ [email protected]_m8:/system # ls app bin build.prop customize etc fonts framework lib lost+found media priv-app tts usr vendor xbin z zz [email protected]_m8:/system # The miror is on maintainance for now. So, the guy on IRC gave me his local backup. I will push it here for 30 days: http://dl.free.fr/gSha53ljz (server will delete it after 30d nobody downloads it) Busybox still fails to install; don't know why.
[SCRIPT] [XMS/XMD] [JB 4.3] [FULL ROOT] Quick Way to Fix reboot,mount issue.
Hi all I have read many threads with similar issue, then this my way how to fix it. Ie: Folder mount app, which make reboot the phone after we mount a folder. Just add this line to this file : /system/etc/install-recovery-2.sh If the file is missing, just create it. Requirement: on JB 4.3 superSU atleast v200 installed busybox installed, got it from Playstore, ie: Busybox X, Code: #!/system/bin/sh pkill -f /sbin/ric; mount -o remount,rw /; chmod 644 /sbin/ric #just to make sure ric is killed pkill -f /sbin/ric How to: You better know than me. but here my way. if your phone reboot after you touch mount rw in root explorer then adb or terminal emulator is your friend remount rw system, make the file, then push/copy to target directory, and set correct permission , chmod 755 install-recovery-2.sh done. .
This thread lacks a lot of info. You just forgot to cite you must have busybox installed and that this line should be put in install-recovery-2.sh if running Android 4.3 firmware to avoid conflicts with daemonsu... conclusion: You didn't search enough
mbc07 said: This thread lacks a lot of info. You just forgot to cite you must have busybox installed and that this line should be put in install-recovery-2.sh if running Android 4.3 firmware to avoid conflicts with daemonsu... conclusion: You didn't search enough Click to expand... Click to collapse Hi mbc07, i have put the line in that file and of course is work. never get reboot again. i have read the note by superSU in that file too. but iam forgot to cite the busybox, and i have busybox installed. but hey thanks, i edited the OP.
Android N: Not able to execute shell script from boot image
I am not sure if this should go here or the Android Development section, but here goes.. I modify boot images for some android phones, and I add custom services to the init.rc to execute some shell scripts when some property is set.. Code: service myservice /system/bin/sh /myservice.sh oneshot disabled on property:log.myservicestart start myservice I also add myservice.sh file in the boot image with some code I need to execute. This has always worked well for me. In certain cases where I had selinux issues, I used to patch the sepolicy file using supolicy before making the boot image (or I just copy the supolicy from Autoroot recovery images sometimes). Somehow, this doesn't seem to work for Android N. It listens to property changes (if I had a setprop in there to set another property, it works), but it never executes the shell script. I don't see any selinux denial errors, or any other error in logcat either! I unpack and repack images using AIK-Linux, and I have the latest code (and the binaries). Anyone has any idea about this? Edit: Never mind, it looks like I needed seclabel to be explicitly set for Android N.