Database Info

[DEV] Script for tweaks (version 1.02) 18-12-2010

Here is a script i've made (had nothing to do, so...).
Phone must be rooted and have busybox installed.
What first menu looks like:
1 - enable/disable hardware acceleration
2 - enable/disable jit
3 - enable/disable stagefright player
4 - change heapsize
s - show status
r - revert to original configuration
q - quit (don't forget to reboot your phone!)
==================
enter your option:
Click to expand...
Click to collapse
Download:
http://www.4shared.com/file/gApTB6EG/tweaks.html
md5 b0865d9de67a82215913512cb644211d
Just copy the file to your sdcard. Then in a terminal emulator run:
su
cat /sdcard/tweaks > /data/tweaks
rm /sdcard/tweaks
cd /data/
./tweaks
If it doesn't run, type first:
chmod 755 /data/tweaks
Additional notes:
Script does not work if run from sdcard, must be in /data/ or /system/ (this one goes to allsalvati for testing)
---
If anything is wrong i will fix it, but only if you give me feedback
If you know any good tweaks, say it and i'll add them.
---
Changelog:
version 1.02:
backup/restore added
version 1.01d:
working again. sorry for the mess...
version 1.01c:
nothing new. just rearranging code
version 1.01b:
messages were not staying in output. fixed
version 1.01a:
small fix. v1.01 was not working
version 1.01:
added status menu

ruigui said:
Here is a script i've made (had nothing to do, so...). Phone must have busybox.
Download:
http://www.4shared.com/file/gApTB6EG/tweaks.html
md5 ea568c399c67ecd87db0dd790cdf0e93
Just copy the file to your sdcard. Then in a terminal emulator run:
cd /sdcard/
./tweaks
If it doesn't run, type first:
chmod 777 /sdcard/tweaks
Please give me some feedback. I don't own the phone so i can't test.
Click to expand...
Click to collapse
what the script does?

So script should be able to do:
enable/disable hw acceleration
enable/disable jit
enable/disable stagefright player
change heapsize

Yes. For now it's what it does.
The ideia is to be able to enable/disable a certain tweak, without reflashing zips, and rewriting files in phone.
But i need some feedback to know if it is working. I can't test it.
It will only change values in /data/local.prop, nothing else.

It seems that it is well written, so I will try that and let you know what's happened.

Thanks for testing. I'm still waiting to have some money so i can buy this phone...
Meanwhile, i'm "playing" with ROMs and files. I'm not good at scripting, but i'm trying to learn while doing something useful.

How much did you increase the heap size?

domenic_s said:
How much did you increase the heap size?
Click to expand...
Click to collapse
I didn't increase it. Script shows this message:
"default=24, recommended=32"
"enter new heapsize value (1-64): "
You can enter any value between 1 and 64.
If you enter any other value, or a string, character, symbol... script will show this message:
"wrong value"
"please input a value between 1 and 64"

For those who don't feel like editing this themselves this is great. Thanks for releasing it for people to try out more tweaks on stock ROMs.

i'm trying to run this script and gives me the following message: ./tweaks: permission denied
Before anything i typed su, then chmod 777 and it gave me error.

It should work be working...
Anyone else confirms this issue? Is this script running or not?
If it is working and there are more tweaks, i can easilly add them to the script.
If this is an isolated case, i really can't help. I don't own an android phone (yet), so i can't test....
allsalvati do you have busybox installed?

No, i don't.
Sent from my LG-P500h using XDA App

That may be your issue.
You must mount /system/ as read-write, then copy busybox binary to /system/xbin/, then run these commands in terminal emulator:
su
cd /system/xbin
/system/bin/chmod 755 busybox
./busybox --install -s /system/xbin
After that you can mount /system/ as read only again, and reboot your phone.
I don't know if there is another way to install it that is easier.

I downladed busybox installer from market and the app says that was installed. The. /tweaks gives me the same message.
How do i test if busybox was installed right?
Sent from my LG-P500h using XDA App

I found this:
That is a problem, you cannot chmod a script to executable on the SD card. (well some things can, but 99% no) the system is designed to prevent u executing scripts from an SD card
cp it to /system/xbin or /system/bin.
Or if u hate to see it in system', use /data/
THEN chmod it. should be fine to run
Click to expand...
Click to collapse
Try to copy the file to /data/ (so you don't mess with /system/), and then try to run it with:
cd /data/
chmod 777 tweaks
./tweaks
It should not need to be run as root

Moved to /data and worked.
I changed heap size to 32 and disabled hardware accelaration just to test.
With hw acc - 981 on Quadrant
Without - 820
So i think this is working.
Perhaps you should print the values so the user can see what is enabled or not before apply.
Thanks for your help
Sent from my LG-P500h using XDA App

Can you test something for me?
Make sure you have hardware acceleration disabled, and reboot you phone.
Then open terminal and run:
getprop | grep hw (see what it outputs)
then run the script, enable hardware acceleration on it, but DON'T reboot your phone yet.
Then exit script, and run again:
getprop | grep hw
Has the value changed, or is it the same?
I need to know if the system assumes immediately any changes (although they may not be functional until reboot).
This is needed to work on your request.
allsalvati said:
Perhaps you should print the values so the user can see what is enabled or not before apply.
Click to expand...
Click to collapse
I'll work on that and post an update after someone tries what i asked above.
Thanks for testing
EDIT: to test benchmarks, enable/disable jit. It gives greater differences in values

I tried what you say and both outputs are the same:
$getprop | grep hw
[debug.sf.hw]: [0]
[hw.keyboards.65537.devname]: [7k_handset]
[hw.keyboards.65540.devname]: [thunder_keypad]
[hw.keyboards.65541.devname]: [touch_mcs6000]
[hw.keyboards.65542.devname]: [atcmd_virtual_kbd]
Edit: Tested disabling JIT and it worked. Linpack Before 7.35 - After 4.3

So i can't rely on getprop to check current values...
If anything is changed, getprop won't give the right output till reboot.
Damn... Script was almost updated. Now i must find a new way and redo this section.
Thanks for testing again
EDIT:
New version for download at first post. status menu added.
I think it's all ok.

It seems work fine on my phone. But I can't see the status. When I choose to see current status or status after reboot, the screen of my emulator returns too fast to the selection menu (show curent status or after reboot) and I can't see anything !

Bug report on fix_permissions.sh

Hi all,
According to this thread (http://forum.xda-developers.com/showthread.php?t=522935&page=14) the fix_permissions.sh file can be found here:
ezterry said:
I usually just grab it from CyanogenMod's git hub when I need a stand alone copy (or to copy it into my ezGingerbread repo)
https://github.com/CyanogenMod/andro...ix_permissions
Click to expand...
Click to collapse
This post just to report that a line such as
Code:
FP_NUMS=$( $CAT /data/system/packages.xml | $EGREP "^<package.*serId" | $GREP -v framework-res.apk | $GREP -v com.htc.resources.apk | $WC -l )
is now false. Some ROMs get their packages.xml in /dbdata/system.
Something like this should be put in the code:
Code:
for dir in /dbdata/system /data/system; do
[[ -d "${dir}" ]] && break
done
PACKAGES="${dir}/packages.xml"
Sorry for reporting here, but it seems that newbies cannot post in developers forums nor make a decent signature to inform on who they are

fix_permissions script fix for some ROMs
This saved my day/week/month!! Thanks man!
I got tired of having to re-configure all my apps after a re-flash (TBU backs up, but refuses to restore anything for me!!), so i've been wrestling with a bunch of settings recovered from a TBU archive. Dropping them into the proper locations caused all the relevant apps to FC. (I guess that's because the apps don't have rights to their settings.)
The only possible solution I've been able to find is to use fix_permissions, but the latest version (2.04) kept giving me an error and I'm too much of a noob to guess another location for packages.xml.
I changed your code a bit because the mod I'm using (Serendipity) has both a /dbdata/system and a /data/system directory, so it would have always used the first directory in the list. The change worked great though.
For other semi-capable hackers who might need this (and since I'm not in a position to post it back to github), I took the v2.04 of fix_permissions (here: github.com/CyanogenMod/android_vendor_cyanogen/raw/gingerbread/prebuilt/common/bin/fix_permissions) and added
Code:
for packdir in /dbdata/system /data/system; do
[[ -f "${packdir}/packages.xml" ]] && break
done
PACKAGES="${packdir}/packages.xml"
in the Initialise vars section, and then changed the 4 instances of data/system/packages.xml to $PACKAGES
The updated version is attached below. Hope this helps someone too.

Glad to see that the post helps at least one person
Rereading it, I feel ashame by my mistake trying to mend the script
Anyway, your fix works of course.
By the way, the cause of all this seems bug traced in android code as bug 9976 (sorry I still cannot post the link, you'll have to find it by yourself in code.google.com)

I know I'm digging up an old thread, but I am having trouble locking down where fix_permissions.sh 2.04 came from. The link above doesn't work etc. I've pulled it from twrp recovery (though according to their page/source its rewritten in c++), not really sure how to compile just that as I only need the script.
Anyway, just as an FYI for anyone pulling the script from here, ther script there is a slight bug on line 251 that probably won't affect most people as long as cut works from the command line, but
Code:
FP_OLDPER=$( $ECHO $FP_OLDPER | cut -c2-10 )
should be
Code:
FP_OLDPER=$( $ECHO $FP_OLDPER | $CUT -c2-10 )
Only noticed this since I had to push over my own busybox and changed the commands to be ./busybox to use the busybox pushed with the script to the phone and noticed the cut command was failing.

[Q] Is there an easy way to apply the patch files from the OTA on a PC?

I'm looking for a way to apply the patch files to the TF system image on a PC. This is not about how to get the ota to flash- I got that covered. This is about repacking roms or making flashable updates that don't rely on stock firmware.
I found a few ways, but none of them seem "easy."
The dirty way- apply the OTA and grab the system image.
From the PC command line - Linux has diff/patch, but that doesn't work for some of the patches in "IMGDIFF2" format. Besides, I'm not sure I ever got the regular BSDIFF40 patches to work.
The git option- There is the apply_patch source code in github. This works great, but I have to run it on the TF. Is it possible to compile this to work on my ubuntu box?
Maybe there is some magic script out there called apply_ota?
Thanks in advance

gee one said:
I'm looking for a way to apply the patch files to the TF system image on a PC. This is not about how to get the ota to flash- I got that covered. This is about repacking roms or making flashable updates that don't rely on stock firmware.
I found a few ways, but none of them seem "easy."
The dirty way- apply the OTA and grab the system image.
From the PC command line - Linux has diff/patch, but that doesn't work for some of the patches in "IMGDIFF2" format. Besides, I'm not sure I ever got the regular BSDIFF40 patches to work.
The git option- There is the apply_patch source code in github. This works great, but I have to run it on the TF. Is it possible to compile this to work on my ubuntu box?
Maybe there is some magic script out there called apply_ota?
Thanks in advance
Click to expand...
Click to collapse
I recently wrote some code for a ARM basestation (basically like a Freescale cell-phone board), and had to be able to supply some updates over time. Before the project ended, I'd also found bsdiff and bspatch and tested them on linux, where they worked fine (as long as you'd created either an ARM bsdiff/patch version or somehow took the big/little endianness of the hardware into account).
At first I thought it wasn't working but it seemed to do OK on standard cross-compiled-for-ARM files. (well, they still ran and performed the same stunt..).
The thing that worried me about this method is that they'd never have the same md5sum before as after, likely because they had a different amount of bytes. (e.g. you make your own before and after and build each, then create the patch file using bsdiff, then patch the old file using the patch file, and create a 'newtestfile', but look at the number of bytes (or md5sum it) difference between the original stage 2 file and the stage 1 + the patch file via bspatch).
Sorry that is pretty confusing the way I just tried to explain it.. I'll look this over again tomorrow and figure out if I said anything worthwhile

For inputs, the applypatch binary takes the file names, sha1 checksums of the before and after, and the final target size. Chance are high that the patch would only work if everything went in and came out properly.
Code:
apply_patch("/system/framework/framework-res.apk", "-",
99b382b5886e505508fa3f730d778a1bed4bc04e, 9761707,
a4798fb8d61d08b6f067e522e67107f6dd556148, package_extract_file("patch/system/framework/framework-res.apk.p"));
I think that bsdiff/patch will generally work on most of the OTA (BSDIFF40 files), but some of the files are IMGDIFF2, which targets binary/data files.
The applypatch binary works on both and as far as I can tell, is the same binary that the TF uses. Here is a snippet from the AOSP recovery... TF binary included Use the binary on your TF, not applypatch.sh! I suppose you can put it in system/xbin/
It would resolve the issue if I could compile this to run on my desktop from ubuntu. Short of that, I'm working on a script for the TF to parse the updater script.

gee one said:
For inputs, the applypatch binary takes the file names, sha1 checksums of the before and after, and the final target size. Chance are high that the patch would only work if everything went in and came out properly.
Code:
apply_patch("/system/framework/framework-res.apk", "-",
99b382b5886e505508fa3f730d778a1bed4bc04e, 9761707,
a4798fb8d61d08b6f067e522e67107f6dd556148, package_extract_file("patch/system/framework/framework-res.apk.p"));
I think that bsdiff/patch will generally work on most of the OTA (BSDIFF40 files), but some of the files are IMGDIFF2, which targets binary/data files.
The applypatch binary works on both and as far as I can tell, is the same binary that the TF uses. Here is a snippet from the AOSP recovery... TF binary included Use the binary on your TF, not applypatch.sh! I suppose you can put it in system/xbin/
It would resolve the issue if I could compile this to run on my desktop from ubuntu. Short of that, I'm working on a script for the TF to parse the updater script.
Click to expand...
Click to collapse
I'm not sure I understand the intent. I've just awoken and that's probably part of the problem..
'applypatch' is part of the standard (say 10.04 ubuntu) repo and is in a package called makepatch. Did you want to be able to run it "from" a standard x86 Ubuntu dist but have it targeting "armle" files or just be able to run it both on Ubuntu & Android correctly?
The files I tested were a) both binaries in different stages of evolution, and b) both built for armle(droids) and x86_64 and didn't behave differently, worked, and the checksum could be pre-calculated.
I'm going to mess around with applypatch when I'm out of my morning coma and get back to this in a bit.
Hah -- I do wonder if there's already a script (maybe it's a binary though) that lives in the dm* app on the tf101 that just does this already. You may have been right about that. Something has to apply those OTA patches. There's a few mechanisms for detecting them but I hadn't thought about how they're applied.
I'm trying to think if there's any scenario where the market applies 'patches' rather than always downloads the next version in entirety. Not sure about that.
Anyway, I'll see if I can get anywhere with applypatch.
Edit:: After a little messing around :
I finally see what you are trying to do and why what I'm doing is totally useless for that. I'm going to spend a little time looking over the imgdiff2 (apk) deal, and probably end up now figuring out a thing.

I'll look into the makepatch package later today. Maybe that might be what I'm looking for.
Just to be clear, the intent is to be able to patch a "stock" system without it actually running on the TF. For example, to take the stock 8.6.5.9 image, decompress system/ to the PC, apply the patches from the OTA, and then end up with a stock 8.6.5.13 image. This would all happen on the PC, not the TF. It would streamline the ROM cooking process and make it easier and faster to spit out a complete, flashable update that won't fail sha1 checks because of mods.
sent from my cyanogen(mod) vision

Zombie Thread Alert!!!
You have been warned....
OK, so my C-fu isn't strong enough to figure out how to cross compile the apply patch binary to run on a x86 computer. However, I did notice that the applypatch binary gets built in the aosp/generic_x86 build, specifically in the system/bin folder.
This will be an exectuble file that will run on a x86 linux based system and do the same thing that the applypatch binary does to the ota package during the ota update. In other words, you can apply the ota patch to a system image from the comfort of the linux command line without having to actually flash the ota. This will allow you to be the first one on your block to have the new system image without having to mess up whatever rom you are currently running.
Of course, this might all be moot if we don't see another ota for our tf. Come on ASUS, just one more so I can test this out on a live update.
OK, so if you read this far, repo sync your aosp source and build the generic_x86 branch. The binary is aosp/target/product/generic_x86/system/bin/applypatch_static
edit: then after you've done that, use a script to parse the updater-script to extract the patching commands and then she-bang! I'll post mine a little later- I've got to get some flowers for tonight

Any luck with that? I'm also searching for a way to apply an OTA update to a ROM using Ubuntu.

bgcngm said:
Any luck with that? I'm also searching for a way to apply an OTA update to a ROM using Ubuntu.
Click to expand...
Click to collapse
Yeah, it works like a charm. The binary is compiled in the aosp/generic_x86 build. There is no need to flash, you can just pull it out of the system/bin folder after compiling the source. You can probably use an "mmm" command to make just files you want, but I'm not sure which package it's in. Then, I use a script that converts the OTA patch commands in the updater-script to a script file that runs on my linuxbox that calls the binary and patches the ROM under linux/ubuntu.

Do you mind sharing your applypatch binary? I don't have AOSP source on my Ubuntu installation right now, so if you don't mind sharing I wouldn't need to build it from sources...

bgcngm said:
Do you mind sharing your applypatch binary? I don't have AOSP source on my Ubuntu installation right now, so if you don't mind sharing I wouldn't need to build it from sources...
Click to expand...
Click to collapse
I attached the applypatch binary- it should work on most x86 linux distros, maybe.
As I stated in my earlier post, the binary is built with the x86 build. I'm not so good with the build system, but I think the code is from the bootable/recovery/applypatch. I included the relevant notices for that code.
In the OTA updater-script, there will be a bunch of applypatch commands- you might have to change the name/permissions of the binary, but that syntax should be what you are looking for.
Enjoy!

Thank you very much for your time. It seems we are almost the only one trying this. The thing is that I really need to get this done because OTA update is failing for me by running it the usual way.
I've tried your binary and it works under my Ubuntu installation, however I was trying to manually patch just one file and got this:
Code:
[email protected]:~/Desktop/system/app$ applypatch_static ./ApplicationsProvider.apk - d9023cd58fd055e1ca3c8f8492b2c36aba923c6a 6184 69bea5d5a62980c611b903de8243d980f30e5fb5:../../patch/system/app/ApplicationsProvider.apk.p
applying patch to ./ApplicationsProvider.apk
target 6184 bytes; free space 1080520704 bytes; retry 1; enough 1
chown of "./ApplicationsProvider.apk.patch" failed: Operation not permitted
I got that chown error message although ApplicationsProvider.apk.patch was created. Is this the patched file?
EDIT: Nevermind, I forgot to run the command as superuser.
EDIT2: Would it be too much if I ask you also to share the script that converts OTA commands from updater-script into the correct syntax to run on Ubuntu?

There is no guarantee that this will work on your machine. It's a work in progress and will probably require some editing. This just creates the scripts that extract the commands from the OTA updater-script.
I haven't used it in a while since ASUS hasn't put out any updates lately, but I would copy the updater-script and rename it delete_source. Then I would edit out everything in delete_source except the delete commands. There might be an issue with a trailing ; or similar character. The script runs on the copy of the updater-script to pull out the applypatch commands and the delete_source to pull out the files that need to be deleted from the rom.
Check the syntax, but it will be something like ./tf_file <head of stock rom> <head of patch source>
If you have the donor stock system folder and the patch folder from the OTA at the same dir level, it would be ./tf_file system patch
The script also assumes that the applypatch binary is in your path as apply_patch. You can adjust as needed.
Lastly, my bash skills are probably pretty weak, so if you see ways to improve this script or add error/path checking, feel free to post improvements, etc. There is probably a really slick way to do this with just one script and not a script that makes three other scripts. The historical reason for this is that I used to transfer the files to my transformer and run the script on there. Running in Ubuntu is much faster!
Good luck!
Code:
#!/bin/bash
# extract_source is used to pull files to be patched from source tree
# delete_source is ued to delete unneeded files from the source tree
# tf_file applies the patches to the extracted source files
# don't forget to copy the direct updates in the OTA
# usage is apply_ota
# assumes that updater-script and delete-script are at same directory level
# updater-script is from META-INF folder, delete-script is from updater-script
# add error checking to count number of patches and number of patched files
# parse trailing / in folder names
work_dir=`pwd`
tf_file=$work_dir"/tf_file"
extract_source=$work_dir"/extract_source"
delete_file=$work_dir"/delete_source"
work_file=$work_dir"/work_file"
echo "#!/bin/bash" > $tf_file
sed ':a;N;$!ba;s/\n/\ /g' updater-script | sed -e 's/;/\n/g' -e 's/\ \ */\ /g' | grep "apply_patch(" | sed -e 's/"//g' -e 's/,\ p/\:p/g' -e 's/,//g' -e 's/package_extract_file(/$2\//g' -e 's/(/\ $1/g' -e 's/))//g' >> $tf_file
chmod 755 $tf_file
echo "#!/bin/bash" > $extract_source
#sed ':a;N;$!ba;s/\n/\ /g' updater-script | sed -e 's/;/\n/g' -e 's/\ \ */\ /g' | grep "apply_patch(" | cut -d \" -f 2 |sed -e s'/^/cp\ --parents\ $1/g' -e s'/$/\ \$2"\/\"/g' >> $extract_source
sed ':a;N;$!ba;s/\n/\ /g' updater-script | sed -e 's/;/\n/g' -e 's/\ \ */\ /g' | grep "apply_patch(" | cut -d \" -f 2 |sed -e 's/^/cp\ --parents\ $1/g' -e 's/$/\ \$2"\/\"/g' -e 's:/system::g' >> $extract_source
chmod 755 $extract_source
sed -e 's:",:\n:g' -e 's:\ ::g' delete-script > $delete_file
sort -r $delete_file > $work_file
echo "#!/bin/bash" > $delete_file
grep / $work_file | grep -v /$ | sed -e 's:"/:rm\ \$1/:g' >> $delete_file
grep /$ $work_file | sed -e 's:"/:rmdir\ \$1/:g' >> $delete_file
chmod 755 $delete_file
exit 0

IMGDIFF Tool Needed...
Hello Sir, i am looking for a tool to generate IMGDIFF patches on windows... i already have a BSDIFF tool, but coudn't find IMGDIFF... Thank You

I have no idea about windows, but the source is here.
https://android.googlesource.com/platform/bootable/recovery/+/master
You could install linux and build it from there. Follow these directions http://source.android.com/source/building.html
There is also lots of great info here http://wiki.cyanogenmod.org/w/Development#Learning_To_Build_CM
Good luck!

gee one said:
Good luck!
Click to expand...
Click to collapse
I am very thankful to you for replying me sir... these guides are awesome, but i dont think my slow internet connection and PC with 1GB RAM will be allowing me to download or compile
actully i was making a tool to apply OTA Updates in PC, it is semi functional for now, it is able to read updater script and apply bsdiff patches, but can't handle imgdiff patches and now i am stuck at this point because of no imgdiff port for windows... :crying:
i will be very thankful if you or @bgcngm can compile imgdiff at least for cygwin? else i will have to postpond this project until someone else compile and port imgdiff for win/cygwin

Sorry- I'm clueless about cygwin. You could try dual booting to linux to compile from there.

gee one said:
You could try dual booting to linux to compile from there.
Click to expand...
Click to collapse
Thanks alot for taking your time to reply me sir now it seems like linux is the only option left
as you are a linux user will it be too much if i ask you to find a right guide to compile ota tools only? cause i don't know much about linux, and it will be difficult for me to find right guide to compile ota tools only...

jawad6233 said:
Hello Sir, i am looking for a tool to generate IMGDIFF patches on windows... i already have a BSDIFF tool, but coudn't find IMGDIFF... Thank You
Click to expand...
Click to collapse
Answer is here - [Tool]imgdiff executable for windows. BTW, anybody have applypatch for Win32?

Hoping this works for lollipop.

Better integrating Busybox (2012-11-17)

Most Android ROMs use toolbox as primary binary with symlinks in /system/bin and /system/xbin. The problem with toolbox is that it sucks. On some ROMs it's even so limited that it does not even allow for --prefix
Busybox is a great replacement for toolbox, but in order to use it, you have to call it using 'busybox cmd'. I would much rather use it by calling 'cmd' but this would execute toolbox instead of busybox.
Most would think the command 'busybox --install' would fix this, but it does'nt. It tries to install links at /bin and /sbin.
The script below will replace any toolbox links in /system/bin and /system/xbin that is supported by the busybox version installed on the Android device running the script. This will make busybox the default binary when executing regular commands without adding 'busybox' at the beginning of the command.
For an example 'ls' instead of 'busybox ls'
Download as an update.zip
v1.3.0 (Nov 17, 2012) (MD5: c233964f0f62a16d7376739041e8b250) - busybox_installer.zip (Only for ArmV7 devices)
v1.3.0 (Nov 17, 2012) (MD5: e921a6c4119644a18d4feea565824ab1) - busybox_installer-nobin (Without binaries)
busybox.sh
Code:
#!/sbin/sh
for cmd in test find basename readlink ln rm; do
eval export "_$cmd=\"/sbin/busybox $cmd\""
done
_busybox=$($_find /system -type f -name "busybox")
_toolbox=$($_find /system -type f -name "toolbox")
if $_test -e "$_busybox" && $_test -e "$_toolbox"; then
sToolboxList="watchprops wipe vmstat date uptime reboot getevent getprop setprop id iftop ioctl ionice log lsof nandread newfs_msdos notify ps r schedtop sendevent setconsole setprop sleep smd start stop top"
sBusyboxList="`$_busybox --list`"
for applet in $sBusyboxList; do
if $_test -L /system/bin/$applet; then
if $_test "`$_basename $($_readlink -f /system/bin/$applet)`" = "toolbox"; then
$_ln -sf $_busybox /system/bin/$applet
if $_test -L /system/xbin/$applet; then
$_rm -rf /system/xbin/$applet
fi
fi
elif $_test -L /system/xbin/$applet; then
if $_test "`$_basename $($_readlink -f /system/xbin/$applet)`" = "toolbox"; then
$_ln -sf $_busybox /system/xbin/$applet
fi
elif ! $_test -e /system/bin/$applet && ! $_test -e /system/xbin/$applet; then
$_ln -sf $_busybox /system/bin/$applet
fi
done
for applet in $sToolboxList; do
$_ln -sf $_toolbox /system/bin/$applet
done
fi
Toolbox install links
watchprops, wipe, vmstat, date, uptime, reboot, getevent, getprop, setprop, id, iftop, ioctl, ionice, log, lsof, nandread, newfs_msdos, notify, ps, r, su, schedtop, sendevent, setconsole, setprop, sleep, smd, start, stop, top
Busybox install links
Whatever the currently installed busybox supports that is not in the list of toolbox install links
Change log
Dec 10 2011, 21:39 UTC:
The script will now leave skip replacing /system/bin/reboot as it needs to be pointed at toolbox
Dec 11 2011, 10:08 UTC:
Added an update zip that will configure busybox and it provides an extended 1.4MB binary instead of the regular 480KB most ROM's provide
Dec 12 2011, 09:25 UTC:
Added new busybox build (1.20.0.git 2011-12-11) since there was problem with the old one for some people
Added more busybox search dirs (/system/sbin and /sbin)
Added Toolbox install to make sure that some android specific links uses toolbox instead of busybox. See list above.
Jun 27 2012, 13:45 UTC:
Better Busybox and Toolbox search
Added symlink check to make sure that busybox only replaces toolbox links and not things like "sh -> mksh"
Nov 17 2012, 10:30 UTC:
Added a custom toolbox binary to the ArmV7 installer
Added latest CM9 busybox binary to the ArmV7 binary
Added an auto search function to locate the binaries on the device
Fixed both installers to work with newer devices that uses EXT4 file system

Thanks, dk_zero-cool. I've been looking for a guide to installing BusyBox, since I can only find an add-supported installer in the Android Market.

Thanks, nice job!!

Ran the script, worked and did fine....ONE BIG ISSUE....now if you have any script or app that relies on the "reboot" function, it no longer works. For example, rom manager & bootstrapper will not boot into recovery. I even open up terminal and typed:
Code:
$ su
# reboot
...and nothing...does the reboot in /bin need to not be linked to busybox?

KMDonlon said:
Ran the script, worked and did fine....ONE BIG ISSUE....now if you have any script or app that relies on the "reboot" function, it no longer works. For example, rom manager & bootstrapper will not boot into recovery. I even open up terminal and typed:
Code:
$ su
# reboot
...and nothing...does the reboot in /bin need to not be linked to busybox?
Click to expand...
Click to collapse
Try to relink it back to toolbox and then I will update the script to leave reboot alone.
1: mount -o remount,rw /system
2: rm -r /system/bin/reboot
3: ln -s /system/bin/toolbox /system/bin/reboot

Great! Will try again!

Cool... can I steal this?
I'd implement it with a busybox install script
I'm not a super expert on the subject but is /system/sbin a possible location?

zeppelinrox said:
Cool... can I steal this?
I'd implement it with a busybox install script
I'm not a super expert on the subject but is /system/sbin a possible location?
Click to expand...
Click to collapse
You can use this as you like.
And you can type "echo $PATH" in an adb shell, if /system/sbin is there, then it will work. But why? /system/xbin is usually the default dir for placing busybox, otherwise /system/bin. And you will have to change the script since it will only check in /system/bin and /system/xbin

All times in my scripts report UTC time instead of system time, I am sure there is one other applet in /bin that was linked to toolbox that is now linked to busybox and reporting the date wrong or at least the date/time that busybox says (UTC time).

KMDonlon said:
All times in my scripts report UTC time instead of system time, I am sure there is one other applet in /bin that was linked to toolbox that is now linked to busybox and reporting the date wrong or at least the date/time that busybox says (UTC time).
Click to expand...
Click to collapse
Do the same as before, only this time replace 'reboot' with 'date'
This must be a setting in the busybox compile menu. A new binary might fix this because busybox should be able to display system time. But for now point date back to toolbox and it will work for you.

Yup, did what you just said and all is fine. Thanks! Is there a way you can implement the reboot and date applet ignore in the script within the .zip you made.... I think it will save users some headaches.

dk_zero-cool said:
You can use this as you like.
And you can type "echo $PATH" in an adb shell, if /system/sbin is there, then it will work. But why? /system/xbin is usually the default dir for placing busybox, otherwise /system/bin. And you will have to change the script since it will only check in /system/bin and /system/xbin
Click to expand...
Click to collapse
Well bb is sometimes installed elsewhere.
At first SuperCharger only looked in those 2 locations and stopped when it wasn't found.
What would happen if there was a second version elsewhere?
I suppose it wouldn't matter because of the symlinks.

KMDonlon said:
Yup, did what you just said and all is fine. Thanks! Is there a way you can implement the reboot and date applet ignore in the script within the .zip you made.... I think it will save users some headaches.
Click to expand...
Click to collapse
The reboot fix is already in the zip file.
The date fix I don't want in it, I would much rather fix busybox to work properly.
I'm currently looking at that.
zeppelinrox said:
Well bb is sometimes installed elsewhere.
At first SuperCharger only looked in those 2 locations and stopped when it wasn't found.
What would happen if there was a second version elsewhere?
I suppose it wouldn't matter because of the symlinks.
Click to expand...
Click to collapse
No that does not mater because of the symlinks.
That's why I referrer to the complete path, f.eks, "/system/xbin/busybox" and not just the binary name "busybox".

I am going to try your binary for Busybox and see, I am currently using JRummy's BB installer which installed v1.19.3 which is about 1.06MB....
EDIT: Just flashed the .zip, my phone will not boot past the logo....did a battery pull several times and can't get into CWR....SBF time

KMDonlon said:
I am going to try your binary for Busybox and see, I am currently using JRummy's BB installer which installed v1.19.3 which is about 1.06MB....
EDIT: Just flashed the .zip, my phone will not boot past the logo....did a battery pull several times and can't get into CWR....SBF time
Click to expand...
Click to collapse
Put in your USB cable, open a terminal/console on your computer and try "adb logcat" to see what it says when it stops booting.
You must of cause have adb installed on your computer, and USB drivers if you use windows, which I don't and cant help with.

Already reflashed phone back....sorry, no logcat....

Do it again...
C'mon take one for the team... hehe...

LMFAO!!!! Sorry dude, I ain't gonna do it....will let some other poor soul ....I got honey do's today, it's Sunday!!

Whatever it was I can't recreate it. Works fine when I flash the damn thing.

Here's a thought.....make a script that reverses the toolbox links, I can undo it and try to flash again....I was unable to manually install your busybox version so I think some other toolbox applet is causing me trouble.....

Android 7 overwrites /system/build.prop on every boot?

First post, please move my thread to a more appropriate category if needed or send me to a duplicate thread if I missed it.
It looks like Android 7/Nougat overwrites the /system/build.prop file on every boot, and I'm trying to figure out - am I editing it wrong or is that a new design? It did not happen in Android 6/Marshmallow. I have a Nexus 5X FWIW, and being a software engineer I am comfortable with adb and fastboot and even wrote a couple Android apps in the past, but the android file system is a black box to me. This is what I did:
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write, edited build.props
$ adb shell
# cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
# echo 'net.tethering.noprovisioning=true' >> /system/build.prop
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
# exit
// Rebooted into stock
$ adb reboot
$ adb shell
$ cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
// See how the net.tethering line is not there
// Rebooted into twrp
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write
$ adb shell
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
// See how the net.tethering is still there
If this is as designed, why does /system/build.prop differ when booting stock vs twrp?

mgbelisle said:
First post, please move my thread to a more appropriate category if needed or send me to a duplicate thread if I missed it.
It looks like Android 7/Nougat overwrites the /system/build.prop file on every boot, and I'm trying to figure out - am I editing it wrong or is that a new design? It did not happen in Android 6/Marshmallow. I have a Nexus 5X FWIW, and being a software engineer I am comfortable with adb and fastboot and even wrote a couple Android apps in the past, but the android file system is a black box to me. This is what I did:
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write, edited build.props
$ adb shell
# cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
# echo 'net.tethering.noprovisioning=true' >> /system/build.prop
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
# exit
// Rebooted into stock
$ adb reboot
$ adb shell
$ cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
// See how the net.tethering line is not there
// Rebooted into twrp
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write
$ adb shell
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
// See how the net.tethering is still there
If this is as designed, why does /system/build.prop differ when booting stock vs twrp?
Click to expand...
Click to collapse
Have you tried pulling a copy of build.prop then opening it in a text editor and make your changes to it then save it and push the edited copy back to /system?
Sent from my SCH-I535 using Tapatalk

Droidriven said:
Have you tried pulling a copy of build.prop then opening it in a text editor and make your changes to it then save it and push the edited copy back to /system?
Click to expand...
Click to collapse
Thanks for the reply Droidriven. I did not try that because the bash commands I did seem like the same thing. But I tried it just now, and it's the same result.

mgbelisle said:
Thanks for the reply Droidriven. I did not try that because the bash commands I did seem like the same thing. But I tried it just now, and it's the same result.
Click to expand...
Click to collapse
You're using a temp recovery aren't you? Are you using that because your bootloader is locked? Are you rooted?
Sent from my SCH-I535 using Tapatalk

Yes I'm using a temp recovery to make the edit as root, twrp specifically, like my shell commands show in the first post. My bootloader does happen to be unlocked, but the reason I'm using the temp recovery is so my firmware stays stock so I can use Android Pay. Which answers your last question incidentally, no I'm not rooted.

mgbelisle said:
Yes I'm using a temp recovery to make the edit as root, twrp specifically, like my shell commands show in the first post. My bootloader does happen to be unlocked, but the reason I'm using the temp recovery is so my firmware stays stock so I can use Android Pay. Which answers your last question incidentally, no I'm not rooted.
Click to expand...
Click to collapse
I doubt you'll make the changes and keep them without root.
Sent from my SCH-I535 using Tapatalk

Droidriven said:
I doubt you'll make the changes and keep them without root.
Click to expand...
Click to collapse
Hmm but that doesn't quite make sense to me. I made the changes as root and they've definitely persisted (even when I reboot into twrp) and the changes are there if you do the same thing in Android 6. There are many references to doing changes this way like in http://forum.xda-developers.com/nexus-5x/general/guide-how-to-unlock-tethering-nexus-5x-t3231301 but it's just with Android 7 now, the stock 7 firmware is mounting something on /system/build.prop that is different than what TWRP mounts at /system/build.prop. I'll try the same thing with CyanogenMod Recovery, maybe that will have different results.

mgbelisle said:
Yes I'm using a temp recovery to make the edit as root, twrp specifically, like my shell commands show in the first post. My bootloader does happen to be unlocked, but the reason I'm using the temp recovery is so my firmware stays stock so I can use Android Pay. Which answers your last question incidentally, no I'm not rooted.
Click to expand...
Click to collapse
I don't see where actually flashing TWRP would cause a problem instead of using a temp recovery. Your stock firmware will still be full stock, I don't think which recovery you have would cause a problem with android pay.
Sent from my SCH-I535 using Tapatalk

Droidriven said:
I don't see where actually flashing TWRP would cause a problem instead of using a temp recovery. Your stock firmware will still be full stock, I don't think which recovery you have would cause a problem with android pay.
Click to expand...
Click to collapse
Yeah I understand that, but even though it wouldn't cause a problem it doesn't seem that would be necessary. Interestingly, when I'm booted into twrp with /system mounted, the build.prop file has the contents and timestamp I expect.
# ls -la /system/build.prop
-rw-r--r-- 1 root root 4919 Dec 17 16:52 /system/build.prop
But when booted into system (stock Android 7 like I mentioned) the timestamp shows a very different file is being mounted.
$ ls -la /system/build.prop
-rw-r--r-- 1 root root 4876 2009-01-01 03:00 /system/build.prop

More info, flashing twrp as opposed to just booting it had the same effect. I tried that because of what you said Droidriven, BTW thanks for your help so far.

Ever get any farther with this? I'm having the same issues on my Stock bl-unlocked Google Play N5X 7.1.1 NMF26F
Booting into TWRP, pulling /system/build.prop, editing, mounting /system RW, replacing /system/build.prop, still not making changes.
Also for some reason every SuperSU attempt I make (for any versions since 2.78 (and 2.79+) fails at Patching sepolicy - Failure, aborting.
Ugh...

tronik said:
Ever get any farther with this? I'm having the same issues on my Stock bl-unlocked Google Play N5X 7.1.1 NMF26F
Booting into TWRP, pulling /system/build.prop, editing, mounting /system RW, replacing /system/build.prop, still not making changes.
Also for some reason every SuperSU attempt I make (for any versions since 2.78 (and 2.79+) fails at Patching sepolicy - Failure, aborting.
Ugh...
Click to expand...
Click to collapse
I never figured out why it was happening, but when I flashed TWRP and installed SuperSU (which were successful for me, no errors) then the problem went away and I was able to persist edits to /system/build.prop. That is odd how SuperSU installation fails for you with that error. I have the exact same setup as you Nexus 5X 7.1.1 NMF26F and following these instructions I installed SuperSU without error.
http://www.theandroidsoul.com/npf10c-root-android-7-1-1-nexus-5x-6p/
The version I used were twrp-3.0.2-2-bullhead.img and SR5-SuperSU-v2.78-SR5-20161130091551.zip

mgbelisle said:
I never figured out why it was happening, but when I flashed TWRP and installed SuperSU (which were successful for me, no errors) then the problem went away and I was able to persist edits to /system/build.prop. That is odd how SuperSU installation fails for you with that error. I have the exact same setup as you Nexus 5X 7.1.1 NMF26F and following these instructions I installed SuperSU without error.
http://www.theandroidsoul.com/npf10c-root-android-7-1-1-nexus-5x-6p/
The version I used were twrp-3.0.2-2-bullhead.img and SR5-SuperSU-v2.78-SR5-20161130091551.zip
Click to expand...
Click to collapse
Appreciate the prompt response. Yeah, I'm using twrp 3.0.2-2 also, and I've tried numerous versions of SuperSU all failing with the same sepolicy update error... I just don't get it. Never had these problems before Nougat.
Just tried with the specific one in the article you linked:
"Patching sepolicy
--- Failure, aborting"
So weird. Anyway, glad to know yours was fixed!
edit:
I finally decided to try this other root method (phh) and it is working: http://www.theandroidsoul.com/npf10c-root-android-7-1-1-nexus-5x-6p/
I don't know why my trusty SuperSU no longer works.
Oh well.