hey guys,
I'm trying to write an addon.d script to keep Avast Anti-Theft installed after OpenDelta's upgrades.
it only has the ability to self add a backup script in CM roms.
I looked for the list of files being kept at the appropriate .sh file for CM, and wrote the following "91-antitheft.sh" :
Code:
#!/sbin/sh
#
# /system/addon.d/91-antitheft.sh
# During a system upgrade, this script backs up avast anti theft,
# /system is formatted and reinstalled, then the files is restored.
#
. /tmp/backuptool.functions
list_files() {
cat <<EOF
priv-app/com.avast.android.antitheft.apk
etc/com.avast.android.antitheft.backup.enc
EOF
}
case "$1" in
backup)
list_files | while read FILE DUMMY; do
backup_file $S/$FILE
done
;;
restore)
list_files | while read FILE REPLACEMENT; do
R=""
[ -n "$REPLACEMENT" ] && R="$S/$REPLACEMENT"
[ -f "$C/$S/$FILE" ] && restore_file $S/$FILE $R
done
;;
pre-backup)
# Stub
;;
post-backup)
# Stub
;;
pre-restore)
# Stub
;;
post-restore)
# Stub
;;
esac
unfortunately, that doesn't keep the files.
the 2 files are definitely the following:
com.avast.android.antitheft.apk located in /system/priv-app
com.avast.android.antitheft.backup.enc located in /system/etc
what is wrong with the code?
thanks
Just use the same .sh file they developed for CM - our backuptool implementation is fully compatible.
thanks for your answer!
I went from CM 4.3 to OmniROM 4.4, so for 4.3 this is what I found in my /system:
custom_backup_list.txt inside /system/etc
containing:
Code:
app/com.avast.android.antitheft.apk
etc/com.avast.android.antitheft.backup.enc
and 99-cm.sh containing:
Code:
#!/sbin/sh
#
# /system/addon.d/50-cm.sh
# During a CM10 upgrade, this script backs up /system/etc/hosts,
# /system is formatted and reinstalled, then the file is restored.
#
. /tmp/backuptool.functions
list_files() {
cat <<EOF
app/com.avast.android.antitheft.apk
etc/com.avast.android.antitheft.backup.enc
EOF
}
case "$1" in
backup)
list_files | while read FILE DUMMY; do
backup_file $S/"$FILE"
done
;;
restore)
list_files | while read FILE REPLACEMENT; do
R=""
[ -n "$REPLACEMENT" ] && R="$S/$REPLACEMENT"
[ -f "$C/$S/$FILE" ] && restore_file $S/"$FILE" "$R"
done
;;
pre-backup)
# Stub
;;
post-backup)
# Stub
;;
pre-restore)
# Stub
;;
post-restore)
# Stub
;;
esac
so, I'm not sure OmniROM supports "custom_backup_list.txt"
and for the 99-cm.sh file, it says "app/com..." so I changed it to "priv-app/com....".
and it doesn't work. the 2 files are not there after the upgrade is finished.
so it must be something with my code, no?
hmm, custom_backup_list is something I've never seen in CM... Just backuptool in /system/addon.d/
You should be able to take the example backuptool shell file, replace the files to be backed up with the ones you want, and it should work, although you might need to make sure the file mode/ownership match the other shell files in /system/addon.d/
I changed the hosts "template" file and it works.
it's super weird because there's no real difference to what I've previously wrote.
might be that last unused # dangs it all up.
thanks for your help, Entropy512.
I've attached the sh file to whom it may concern
shmizan said:
I changed the hosts "template" file and it works.
it's super weird because there's no real difference to what I've previously wrote.
might be that last unused # dangs it all up.
thanks for your help, Entropy512.
I've attached the sh file to whom it may concern
Click to expand...
Click to collapse
Where do we put the file once we download it? Will it autorun every time we flash a nightly?
inside /system/addon.d/
and yes it will.
I followed your instructions exactly, unfortunately avast anti-theft still isn't being kept whenever I flash a new nightly. Did I need to do something else or?
Jokerswild2412 said:
I followed your instructions exactly, unfortunately avast anti-theft still isn't being kept whenever I flash a new nightly. Did I need to do something else or?
Click to expand...
Click to collapse
I think u have to remove the .txt and then save it. (save it as a .sh file)
Thanks for the script. I was just wondering how to make a script for that and then I thought let's give Google a try
And I found your post. Thanks
There's also another method.
When installing Anti-theft from within Avast you are asked if you want to install it in the system directory or make a flashable update.zip. Select the update.zip method. Then you take that zip and rename it to Update1.zip and move it to /"sdcard folder"/OpenDelta/FlashAfterUpdate/
When storing the settings for hard reset protection selec also the update.zip method rename the zip to Update2.zip and move it to the same folder.
Those two files will be flashed after every update.
The problem with this method is that you'll have to update the zips whenever there's an update for Anti-theft, but that doesn't happen really often.
I am not using OmniRom so I dont think its gonna work for me.
But the script method isn't more useful ? I mean, it does work even after flashing a new rom, or I am mistaken ?
johnannis said:
I am not using OmniRom so I dont think its gonna work for me.
But the script method isn't more useful ? I mean, it does work even after flashing a new rom, or I am mistaken ?
Click to expand...
Click to collapse
The script method is more useful for ROMs that support addon.d. As far as lately, I've only ran omni and CM. But possibly other aosp derivatives like pac, carbon, PA, etc support this as well. Check your roms OP as well as code for better answers on this.
I am on PA, but nevermind I ll keep it script method, it seems better for my needs
Sent from my Nexus 5 using Tapatalk
Related
Hi all,
I've been trying hard to replicate the 'echo mode' of SyncToy (Microsoft freeware) using rsync. If you want to understand how this mode acts, here is an illustration:
ht***tp://ww***w.laboratoire-microsoft.org/articles/win/synctoy/images/echo.jpg (sorry, i can't publish urls from my noob account)
Basically, the DEST folder is never analysed and only the changes made on the SOURCE folder between date 1 and date 2 are repeated on DEST folder.
Assuming that i never make any manual modification to my DEST folder this is the perfect solution.
Actually, i presume iTunes acts exactly this way and that's why syncs are so faster with iphone and ipod.
Why do I want to replicate this mode?
My sdcard is a class2 and it's really sloooow. Each time I run rsync, it tries to analyse my mac partition (ssd) AND my sdcard, and compare the two directories....which takes at least 1h30 for my whole library even if only 2 files have been added to SOURCE folder between date 1 and date 2!!
SyncToy is a Windows program, I use a macbook
All my music library is on my mac partition
Note: for the moment i run synctoy through a virtual machine with my itunes library folder being shared. It's working but it's not the best solution...
So if there is any rsync guru here: do you think there is any possibility to recreate this 'echo mode' using rsync?
Is rsync really what you want, given you don't need any of the clever things it can do?
My shell scripting knowledge is very sparse, but wouldn't something like this do:
find $SourceDir -mtime +1 -mtime -4 -type f -exec cp {} $DestDir \;
where in this example it (maybe ) copies any file last modified between 2 & 4 days ago (inclusive & exclusive respectively) from $SourceDir to $DestDir.
NB This is untested, I'm clueless & it also might need to be a bit smarter to handle anything other than a flat file structure (in which case replace cp with something that will make each ancestor directory if absent from the destination & will then cp into that), so you have been warned.
[Edit:] Yes, you'd need something like cpio instead of cp. If you're interested search for info on "cpio -pd"
Otherwise I was thinking about making a script:
1. create a simple text file with lines like that "/full/path/to/file/filename.ext;SizeInByte;LastModificationTime" for each file file in SOURCE dir at date 1.
2. At date 2, create a new similar text file
3. Compare the 2 text files and keep only different lines
4. Differences coming from date1 text file are deleted from DEST dir and differences coming from date 2 file are copied/overwritten.
Does your command deletes files that have been deleted in SOURCE dir between the two dates?
Isn't cpio for archiving, like tar,gz2,etc...?
venezia64 said:
Otherwise I was thinking about making a script:
1. create a simple text file with lines like that "/full/path/to/file/filename.ext;SizeInByte;LastModificationTime" for each file file in SOURCE dir at date 1.
2. At date 2, create a new similar text file
3. Compare the 2 text files and keep only different lines
4. Differences coming from date1 text file are deleted from DEST dir and differences coming from date 2 file are copied/overwritten.
Does your command deletes files that have been deleted in SOURCE dir between the two dates?
Isn't cpio for archiving, like tar,gz2,etc...?
Click to expand...
Click to collapse
Deletes? No, that would be impossible if you aren't allowed to scan the destination folder, /unless/ you follow a plan such as you outline above. I didn't realise you required this.
cpio with the -p option (passthrough) is effectively just a copy command which maintains the directory hierarchy.
Your above strategy sounds best. For the stored records, I think I'd use:
find $Dir -type f -printf %p\\0%s\\0%A+\\0\\n > file.log
as you can rely on \0 not turning up in any of the fields it separates; the \n just added to tidy the log up should you wish to check it in a text editor. Oh & the %A+ date format so that if you need to order two dates a lexical comparison is adequate, whilst still being human readable.
That said, you don't appear to want to use the size or time fields, & not storing them would slightly simplify the code. <-- Sorry, that's rubbish on my part; how else would you notice when a file had changed.
Then probably compare them using diff:
diff -a file1.log file2.log > diff.log
Parsing diff.log should then be a trivial matter of checking each line in turn & for those commencing <, remove the named file; for those commencing >, copy the file over.
It's possible for a file to change resulting in both lines above appearing in diff.log for the one file. In that case you obviously need to process the removal first & it's not obvious to me if < will always appear in the log before >, so maybe safer to handle all the < removals first then handle the > copies.
OTOH if the above assumption is safe /&/ you modify the above to process the directories as well as files, you might be able to get away with making the diff.log parsing step a simple matter of applying a suitable regexp match & replace to each line in the diff.log, with the resulting output being a script that does the removals & copies. That'd be quite cool.
>> [That said, you don't appear to want to use the size or time fields, & not storing them would slightly simplify the code.]
Well, if I just add an albumart to my music file or change a tag, the filename will not necessarily change but the ModificationTime will, for sure.
I'll have a look at your shell commands.
Btw, thanks a lot for helping me
venezia64 said:
>> [That said, you don't appear to want to use the size or time fields, & not storing them would slightly simplify the code.]
Well, if I just add an albumart to my music file or change a tag, the filename will not necessarily change but the ModificationTime will, for sure.
Click to expand...
Click to collapse
I know. Stupid oversight on my part which I realised just before you posted
I edited my post to reflect this & had to resort to colouring the incorrect comment as xda-dev doesn't seem to support any strikethrough markup.
I managed do the script but there is still one issue: at the beginning, when I declare the path variable, I cannot include a path with one or more spaces. For the moment, I just created symbolic links.
Code:
left=$HOME"/Desktop/SyncAndroid/left"
right=$HOME"/Desktop/SyncAndroid/right"
temp=$HOME"/Desktop/SyncAndroid/temp"
rightSED=$(echo $right | sed -e 's/\//@@@/g')
leftSED=$(echo $left | sed -e 's/\//@@@/g')
mkdir "$temp"
cd $left
find . -type d -print | sort > $temp/LOG_leftD
cd $right
find . -type d -print | sort > $temp/LOG_rightD
cd $temp
diff -a LOG_leftD LOG_rightD > diffD
cat diffD | grep '^>' | sed -e 's/^\> \./rm -r \"'$rightSED'/' | sed -e 's/\(.\)$/\1\"/' | sed -e 's/@@@/\//g' | sed -e 's/\([$]\)/\\\1/g' > rmdir
cat diffD | grep '^<' | sed -e 's/^\< \./mkdir \"'$rightSED'/' | sed -e 's/\(.\)$/\1\"/' | sed -e 's/@@@/\//g' | sed -e 's/\([$]\)/\\\1/g' > mkdir
chmod +x rmdir
chmod +x mkdir
./rmdir
./mkdir
cd $left
find . -type f -ls | sed -e '/DS_Store/d' | sed -e 's/^ *[0-9]* *[0-9]* [-rwx]* *[0-9] [a-zA-Z]* *[a-z]* *//' | sort > $temp/LOG_left
cd $right
find . -type f -ls | sed -e '/DS_Store/d' | sed -e 's/^ *[0-9]* *[0-9]* [-rwx]* *[0-9] [a-zA-Z]* *[a-z]* *//' | sort > $temp/LOG_right
cd $temp
diff -a LOG_left LOG_right > diff
cat diff | grep '^>' | sed 's/^.*[0-9] \./rm -r \"'$rightSED'/' | sed -e 's/\(.\)$/\1\"/' | sed -e 's/@@@/\//g' | sed -e 's/\([$]\)/\\\1/g' > remove
cat diff | grep '^<' | sed 's/^.*[0-9] \.//' > copy0
cat copy0 | sed -e 's/\(.\)$/\1\"/' > copy1
cat copy0 | sed -e 's/[^/]\{1,\}\.*[a-zA-Z0-9]*$//' | sed -e 's/^/\"'$rightSED'/' | sed -e 's/@@@/\//g' | sed -e 's/\(.\)$/\1\"/' | sed -e 's/\([$]\)/\\\1/g' > copyPath
cat copy1 | sed -e 's/^/cp -p \"'$leftSED'/' | sed -e 's/@@@/\//g' | sed -e 's/\([$]\)/\\\1/g' > copy
paste copy copyPath > copy2
chmod +x remove
chmod +x copy2
./remove
./copy2
rm -r "$temp"
UPDATE 1: the code to take $ symbol (like in Ke$ha) in file path or filename
UPDATE 2: log files are sorted to fix some library updating bugs
NOTE: this scripts scans the right AND the left folder. In fact, I realised that scaning the music folder in the class2 sdcard only took 1-2seconds... Btw, I still don't understand why rsync takes so much time to sync the two folders (even if i don't ask for checksums comparisons)...
venezia64 said:
I managed do the script but there is still one issue: at the beginning, when I declare the path variable, I cannot include a path with one or more spaces. For the moment, I just created symbolic links.
<snip>
UPDATE 1: the code to take $ symbol (like in Ke$ha) in file path or filename
UPDATE 2: log files are sorted to fix some library updating bugs
NOTE: this scripts scans the right AND the left folder. In fact, I realised that scaning the music folder in the class2 sdcard only took 1-2seconds... Btw, I still don't understand why rsync takes so much time to sync the two folders (even if i don't ask for checksums comparisons)...
Click to expand...
Click to collapse
Glad you were able to devise a solution. Sed always gives me a headache as I can never remember what needs to be escaped & what doesn't. Clearly your grasp of shell scripting is better than mine.
Re the space in path issue, I take it it isn't adequate just to escape each space? The speed of rsync is puzzling. Is it definitely not connected to the sdcard? If you apply rsync to the same data, but with both directories on your pc, do you get the same performance differential?
I've tried doing this sync using rsync:
between 2 folders on my HDD, only modifications are done to the DEST folder
between a folder on my HDD and another one on my sdcard, each file file is copied all over again each time... which, obviously, takes time
I DID IT! If we look at rsync manual:
Code:
When comparing two timestamps, rsync treats the timestamps as
being equal if they differ by no more than the modify-window
value. This is normally 0 (for an exact match), but you may
find it useful to set this to a larger value in some situations.
In particular, when transferring to or from an MS Windows FAT
filesystem (which represents times with a 2-second resolution),
--modify-window=1 is useful (allowing times to differ by up to 1
second).
My sdcard partition is in FAT...
So the final rsync command which works really well
Code:
rsync -arv --delete --force --modify-window=1 "/Users/XXXXX/Music/iTunes/iTunes Music/Music/" "/Volumes/NO NAME/Music"
a for archive mode
r for recursive deletions (combined with --force)
v for more verbose (optional)
--delete to delete any file in DEST dir that is not in SRC dir
--force to force the deletion of not empty folders
--modify-window=1 to tolerate 1sec of difference between two corresponding files.
So forget about the previous script. This single commandline replaces it.
phewww
Awesome. Congratulations on figuring it out
Hello all,
Just got my first android phone. I need to port a tiny C application I have to my phone. It worked when I compiled a static binary but now I'm trying to compile a dynamic one, but before that, I'm trying to run a native hello world on it but not having much luck. When I run it on the emulator, it prints "Hello world" and then segfaults after that. When I run it on the phone, it doesn't even get that far. It says link_image[1995] CANNOT LINK EXECUTABLE.
These are my test files
test.c
Code:
#include <stdio.h>
int main (int argc, char *argv[])
{
printf ("Hello world!\n");
return 0;
}
Makefile
Code:
APP := test
ROOT:=$(HOME)/Projects/Android
NDK_PLATFORM_VER := 8
INSTALL_DIR := /data/tmp
ANDROID_NDK_ROOT:=$(ROOT)/android-ndk-r5b
ANDROID_NDK_HOST:=linux-x86
ANDROID_SDK_ROOT:=$(ROOT)/android-sdk-linux_x86
PREBUILD:=$(ANDROID_NDK_ROOT)/toolchains/arm-eabi-4.4.0/prebuilt/$(ANDROID_NDK_HOST)
BIN := $(PREBUILD)/bin
CPP := $(BIN)/arm-eabi-g++
CC := $(BIN)/arm-eabi-gcc
CFLAGS := -I$(ANDROID_NDK_ROOT)/platforms/android-$(NDK_PLATFORM_VER)/arch-arm/usr/include -fno-short-enums
LDFLAGS := -Wl,--entry=main,-rpath-link=$(ANDROID_NDK_ROOT)/platforms/android-$(NDK_PLATFORM_VER)/arch-arm/usr/lib,-dynamic-linker=/system/bin/linker -L$(ANDROID_NDK_ROOT)/platforms/android-$(NDK_PLATFORM_VER)/arch-arm/usr/lib
LDFLAGS += -nostdlib -lc -disable-multilib
all: $(APP)
OBJS += $(APP).o
$(APP): $(OBJS)
$(CPP) $(LDFLAGS) -o [email protected] $^
%.o: %.c
$(CC) -c $(INCLUDE) $(CFLAGS) $< -o [email protected]
install: $(APP)
$(ANDROID_SDK_ROOT)/platform-tools/adb push $(APP) $(INSTALL_DIR)/$(APP)
$(ANDROID_SDK_ROOT)/platform-tools/adb shell chmod 777 $(INSTALL_DIR)/$(APP)
shell:
$(ANDROID_SDK_ROOT)/platform-tools/adb shell
run:
$(ANDROID_SDK_ROOT)/platform-tools/adb shell $(INSTALL_DIR)/$(APP)
r: $(APP)
$(ANDROID_SDK_ROOT)/platform-tools/adb push $(APP) $(INSTALL_DIR)/$(APP)
$(ANDROID_SDK_ROOT)/platform-tools/adb shell chmod 777 $(INSTALL_DIR)/$(APP)
$(ANDROID_SDK_ROOT)/platform-tools/adb shell $(INSTALL_DIR)/$(APP)
clean:
@echo "Cleaning up..."
rm -f $(APP).o $(APP)
Output:
Code:
[[email protected] app]$ make run
/home/hacker/Projects/Android/android-sdk-linux_x86/platform-tools/adb shell /data/tmp/test
Hello world!
[1] Segmentation fault /data/tmp/test
[[email protected] app]$
Output (on the phone):
Code:
# /data/local/test
link_image[1995]: failed to link /data/local/test
CANNOT LINK EXECUTABLE
#
What am I doing wrong?
I've never been successful with dynamic executables using a plain Makefile. I've always had to use the JNI approach with an appropriate Android.mk configuration. To do this, make an empty directory for your project. Within this directory, make a dir called "jni" and cd to it and copy your "hello.c" source file there. Add an Andriod.mk file that looks like this:
Code:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := hello
LOCAL_SRC_FILES := hello.c
include $(BUILD_EXECUTABLE)
Then, with the ndk path set appropriately (ie, on my system):
Code:
export PATH=${PATH}:/usr/src/android-ndk-r4b/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/
just run the ndk-build script (again, modify to point to your ndk installation):
Code:
/usr/src/android-ndk-r4b/ndk-build
This will produce two additional directories in the dir above "jni": "obj" and "libs". In the libs/armeabi/ dir, you'll find your (non-stripped) executable.
Just curious, where'd you get the Makefile? It looks like it should work, but I can't really see where it is getting it's libc.so.
I got the Makefile from http://betelco.blogspot.com/2010/01/buildingdebugging-android-native-c.html
It's for Cygwin so I made a few changes. The last comment says I should link it against crtend_android.o to prevent the segfaults but that didn't work for me. Maybe I did something wrong. I'm not really a C programmer and the only experience I have is with writing extremely basic apps so, honestly, I don't know much about linking but I'm trying to let that not discourage me from trying. It usually takes me days to get something simple done but it feels great once I manage to get my app to work.
I'll try your approach in a few hours and post back.
Oh, and I thought I should mention my phone is running Froyo at the moment.
Since I'm completely new to writing code on the phone, I thought I should ask if it is a bad idea to push the app to the phone and run it directly or should I really be using the emulator instead (since I'm not an experienced programmer)? I've got a very old PC and the emulator is slow as hell on it so it'll be great if i can avoid that.
I visited that site and read over their comments and modified the makefile at the end to match my system (gentoo linux) and it works fine on my phone (HTC Inspire 4G). I didn't do the "make run" thing, but just "make" and then pushed it to my phone manually and ran it from an adb shell. Worked fine. I'm using the r4b plaform ndk so that might be something. I'll D/L the r5b ndk and check it out.
I tried what you suggested and it works perfectly. Thanks!
Gene Poole said:
I visited that site and read over their comments and modified the makefile at the end to match my system (gentoo linux) and it works fine on my phone (HTC Inspire 4G). I didn't do the "make run" thing, but just "make" and then pushed it to my phone manually and ran it from an adb shell. Worked fine. I'm using the r4b plaform ndk so that might be something. I'll D/L the r5b ndk and check it out.
Click to expand...
Click to collapse
I still do have a segmentation fault... I stated all what I did here :
http://stackoverflow.com/questions/20936770/android-command-line-executable
Any good idea would be appreciated !
Thx
I have been resisting the urge to flash a custom ROM for a bit, but I really miss having init.d support. So I read a few threads for other phones and rolled my own.
Warnings
I borrowed bits and pieces from various places. If you don't know what init.d is, you probably don't want to do this. If you aren't willing to take responsibility for bricking your tablet, don't do this. Seriously, the risk of bricking is very low, but if you aren't comfortable booting into an adb shell from recovery, maybe this is not for you. Strongly suggest a nandroid backup before you get started so if you totally bork things you can just hit rewind.
Note: The latest CWM may prompt you on a reboot that the ROM may overwrite the bootloader and offer to fix it for you. Don't do that. The init.d hack takes over the bootloader install script, but does not change your bootloader! If you accidentally do let it fix things for you, just rebuild the install-bootloader.sh file. The other steps should be fine.
Prerequisites
First, you need root, busybox, and some sort of terminal (either adb, or some terminal you like using on the tablet).
I have found that I like Busybox Installer (from the market; https://play.google.com/store/apps/details?id=com.jrummy.busybox.installer) but for some reason it doesn't create new symlinks unless you click advanced install.
Let's get to it!
In the shell (don't type # or anything after #):
Code:
su # get root
mount -o remount,rw /system # get access to /system (4.04 seems to mount ro as is usual; seems like the original mounted rw)
which run-parts # if you don't see /system/xbin/run-parts you need to install/reinstall busybox; if it is somewhere else, note it
mkdir /system/etc/init.d
Create a file called sysinit -- we are going to put it in /system/bin. You can edit it in place with vi, mount your tablet and edit it on your computer, or create it on the computer and push it via adb. Whatever.
Here's the file (you do need the # and the things after it in the file!):
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper /system/xbin/run-parts /system/etc/init.d
Note that if your run-parts is not in /system/xbin (from the which command) then fix the above to reflect your reality.
In the shell, make it executable
Code:
chmod 755 /system/bin/sysinit
Now go in the init.d directory and create some things you want to run at start up. For example:
Code:
cd /system/etc/init.d
echo '#!/system/bin/sh' >99test # note: you do need the first # in this line but not the 2nd!
echo 'date >>/data/tmp/init.d-log.txt' >>99test
chmod 755 99test
Here's a more practical one (yes, you need the # signs). Name it something like 10diskperf -- don't forget to chmod it.
Code:
#!/system/bin/sh
# Set disk read aheads to 1024
chmod 777 /sys/block/mmcblk0/queue/read_ahead_kb
echo "1024" > /sys/block/mmcblk0/queue/read_ahead_kb
chmod 777 /sys/block/mmcblk1/queue/read_ahead_kb
echo "1024" > /sys/block/mmcblk1/queue/read_ahead_kb
chmod 777 /sys/devices/virtual/bdi/179:0/read_ahead_kb
echo "1024" > /sys/devices/virtual/bdi/179:0/read_ahead_kb
Or here is one to tweak some TCP parameters (25sysctl):
Code:
#!/system/bin/sh
sysctl -w net.core.rmem_max=524288
sysctl -w net.core.wmem_max=524288
sysctl -w net.ipv4.tcp_rmem=6144 87380 524288
sysctl -w net.ipv4.tcp_wmem=6144 87380 524288
Whatever files you put in, you need to remember to make them executable (chmod 755).
Finally, you need to kick it all off at start up. The hack for that is we are going to create /system/etc/install-recovery.sh which apparently runs on each boot.
Code:
cd /system/etc
echo '#!/system/bin/sh' >install-recovery.sh
echo '/system/bin/sysinit' >>install-recovery.sh
chmod 755 install-recovery.sh
Tips and troubleshooting
If you are too lazy to cut and paste I have the files here (View attachment init.d-support.zip) that you can just move to the right places and change permission. If you are really lazy there is lightly tested install script below.
I like to try running the whole thing before a reboot to see if I get any errors:
Code:
/system/etc/install-recovery.sh
I'd suggest putting the 99test file in first. Verify that you get the expected file in /data/tmp and then reboot and check again. Then you can remove 99test.
Same goes for adding new scripts. Try running them from the shell to see if they throw errors before you reboot!
If you have trouble, see if this looks right:
Code:
ls -ld /system/etc/install-recovery.sh /system/bin/sysinit /system/etc/init.d /system/xbin/run-parts
-rwxr-xr-x root root 39 2012-07-14 10:00 install-recovery.sh
-rwxr-xr-x root root 140 2012-07-14 10:01 sysinit
drwxrwxrwx root root 2012-07-14 10:10 init.d
lrwxrwxrwx root root 2012-07-14 09:55 run-parts -> /system/xbin/busybox
For the brave
The install-init.d zip file (View attachment install-init.d.zip) contains a lightly tested script that SHOULD do the install steps for you.
Send the file to your android to someplace that can execute code (e.g., /system/xbin; I had to use adb to put it on the sdcard and then move it to /systemxbin in the shell since I don't have the adb root kernel installed).
Code:
cd /system/xbin # or wherever you have it
chmod 755 install-init.d
./install-init.d
It performs rude checks to see if init.d exists, and tries to handle moving or missing busybox. It only installs 99test as a script.
Let me know if this works or doesn't work for you.
For the extra brave: There is no reason this should only work on the Samsung. This ought to work on pretty much most stock ROMs as long as they execute install-recovery.sh on start up.
Scripts
What do you put in your init.d? If you post anything cool I'll put it up here in the op.
One that gave me some real gains in I/O performance required a new version of the tune2fs executable. By default, it is part of busybox but the busybox one only has a few simple options. I've included a stand alone version and the script 10disktune here View attachment disktune.zip. Unpack the zip and put the 10disktune in /system/etc/init.d (don't forget to chmod) and put tune2fs in /system/bin (chmod that too). Note that busybox has one in /system/xbin but the script specifically calls out the one in /system/bin.
Here's one that will zipalign your apks on each boot
Code:
#!/system/bin/sh
for apk in /data/app/*.apk ; do
zipalign -c 4 $apk
ZCHECK=$?
if [ $ZCHECK -eq 1 ]; then
zipalign -f 4 $apk /cache/$(basename $apk)
if [ -e /cache/$(basename $apk) ]; then
cp -p -f /cache/$(basename $apk) $apk
rm /cache/$(basename $apk)
fi;
fi;
done;
Fin
Corrections welcome. I considered using exec or . to load some of this into one shell but given that it runs once at startup, I figured it is fine as is.
All files for reference
View attachment init.d-support.zip
View attachment install-init.d.zip
View attachment disktune.zip
Great guide, gonna try it tonight.
Sent from a GNote, hell yeah!
SirRhor said:
Great guide, gonna try it tonight.
Sent from a GNote, hell yeah!
Click to expand...
Click to collapse
I'm curious how it went. If you ran into any issues, let me know so I can update the op. Thanks!
Hmm did anyone get this to work?
wd5gnr said:
Hmm did anyone get this to work?
Click to expand...
Click to collapse
I did it on my Galaxy Nexus.
It works great, I had a bit of problem with the sysinit file, but when I downloaded your zip file and used your sysinit, it worked, so it must be a problem from my side
Thanks for this, I can finally use "Odex Me"
aavan said:
I did it on my Galaxy Nexus.
It works great, I had a bit of problem with the sysinit file, but when I downloaded your zip file and used your sysinit, it worked, so it must be a problem from my side
Thanks for this, I can finally use "Odex Me"
Click to expand...
Click to collapse
Great, just wanted to be sure I hadn't made any typos/errors in the guide.
A lot of init.d files collected here: http://forum.xda-developers.com/showthread.php?t=1227269
Also build.prop things, etc.
Thanks, I use your guide and worksperfect for my RK3066 devices. Very simple to understand all steps and what we are doing to our system, perfect for me. Thanks again dude
Melch1zedeK said:
Thanks, I use your guide and worksperfect for my RK3066 devices. Very simple to understand all steps and what we are doing to our system, perfect for me. Thanks again dude
Click to expand...
Click to collapse
Glad to help!
What is thhe utility of this?
moliverac8 said:
What is thhe utility of this?
Click to expand...
Click to collapse
Init.d is how Linux and many Android (which is kind of Linux, after all) systems manage executing commands on boot up.
The /etc/init.d files run in numerical order as root and you can do things like change system settings, manipulate the file system, etc.
See the init.d section linked below for some ideas.
http://forum.xda-developers.com/showthread.php?t=1227269
Question? what is the difference in this method and running a script?
wd5gnr said:
Init.d is how Linux and many Android (which is kind of Linux, after all) systems manage executing commands on boot up.
The /etc/init.d files run in numerical order as root and you can do things like change system settings, manipulate the file system, etc.
See the init.d section linked below for some ideas.
http://forum.xda-developers.com/showthread.php?t=1227269
Click to expand...
Click to collapse
I use the "swap memory script" and was wondering if it would also work this way with the init.d If so would there be any benefit this way over the current way of running it one way or the other? One drawback I see running the script as is is that I have to wait once the system has fully booted until the script has run and I see the Smanager screen to let me know that my memory has been remounted.
Thanks for the info and the learning process.
Here is the script and the link.
http://forum.xda-developers.com/showthread.php?t=1961097
Code:
sleep 5
mount -o remount,rw /
mount -t vfat -o umask=0000 /dev/block/vold/179:25 /mnt/sdcard
sleep 5
mount -o bind /data/media /mnt/extSdCard
As long as the device is ready to mount at boot time and doesn't get remounted, ought to work. Backup and try it
External memory wasn't ready
wd5gnr said:
As long as the device is ready to mount at boot time and doesn't get remounted, ought to work. Backup and try it
Click to expand...
Click to collapse
Thanks for the guide, but I think that the external memory was not ready to be mounted at that time. it didn't see the card till after boot. It was worth a shot, Reverted back to the script in /data and all worked again,
Note: I didn't find /system/xbin/run-parts however, I did find /system/bin/run-parts and changed the path to reflect that, I don't think this was an issue but I'm not 100% sure.
With Android 4.2's multi-user stuff and the dreaded "0" folder, Google broke mounting of CIFS shares for good. (They basically implemented something utterly useless for my needs, and broke something I need on a daily basis.) Cyanogenmod fixed that for mounts outside the /storage hierarchy, but many apps can't go there. And with 4.2.2, Google made using adb on the device very annoying as well, which adds to problems for a workaround for mounting shares in a useful place.
So I looked around for various fixes for that issue and compiled those into one method that works perfectly well for me on a P6810 running the current PAC ROM 20130629. It should probably work for any other CM10.1 or PA3.6x-based ROM as well. A nls_utf8.ko module compiled for the Nexus 10 is included as well, which can be loaded via punchmod (at least in PAC), so you can access shares with Ümläüts in them.
Prerequisites: SManager, SMWidgets, and a working Busybox install (I use Stericson's Busybox Installer).
1.) Extract nls_utf8.ko and punchmod from the attached .zip file and put them in /system/lib/modules. You can put them in some other place as well, but my scripts need to be adjusted then. Next, give the files sufficient permissions:
Code:
chmod 644 /system/lib/modules/nls_utf8.ko
chmod 755 /system/lib/modules/punchmod
2.) Optional: if you want the module to auto-start, create a file called 00punch-nls_utf8 (or whatever you like) with the content below, put it in /etc/init.d and chmod it to 755. To check if nls-utf8 is loaded after a reboot, type lsmod in a terminal window or adb shell - it should display the module name. If punchmod auto-detection fails, read here how to get the right vermagic string for your device: http://forum.xda-developers.com/showthread.php?p=41920265#post41920265
Code:
#!/system/bin/sh
sleep 10
/system/lib/modules/punchmod /system/lib/modules/nls_utf8.ko ""
3.) Here's the script that mounts a CIFS share. Edit the settings on top and either put your correct vermagic string as well, or delete the "$VERMAGIC" part in line 22 and try your luck with auto-detection. I put some sanity checks in the script, but it might not work for all directories in /sdcard (or, /data/media/0, to call it by its 'real' name/location). If you don't want to use the nls-utf8 module, just delete lines 18-23, and iocharset=utf8 in line 67.
Name the script mount-music.sh or something, put the script wherever you like, open SManager and navigate to the script. Run the script with SU permissions. If everything goes well, it will ask you to accept an adb RSA key, and then adb mounts the share. You can also add a desktop widget for quick access to the script with SMWidgets.
Code:
#!/system/bin/sh
# Your settings here
IP="192.168.1.123"
SHARE="Music"
USER="yourusername"
PASS="yourpassword"
MOUNTPOINT="/data/media/0/cifs"
VERMAGIC="3.0.31-CM-ga034655-dirty SMP preempt mod_unload ARMv7 p2v8 "
# Load cifs (if it isn't already loaded)
if [ `lsmod | grep -o cifs` ] ; then
:
else
insmod /system/lib/modules/cifs.ko
fi
# Load nls_utf8 brute-force style (if it isn't already loaded)
if [ `lsmod | grep -o nls_utf8` ] ; then
:
else
/system/lib/modules/punchmod /system/lib/modules/nls_utf8.ko "" "$VERMAGIC"
fi
# Check if cifs $MOUNTPOINT dir exists, create it if not, give sufficient permissions
if [ -d $MOUNTPOINT ] ; then
:
else
mkdir $MOUNTPOINT
fi
chmod 755 $MOUNTPOINT
# Check if $SHARE directory is empty - if not, unmount the share
if [ "$(su root -c busybox ls -A $MOUNTPOINT/$SHARE 2> /dev/null)" == "" ] ; then
:
else
/system/xbin/busybox umount -l $MOUNTPOINT/$SHARE
fi
# Create $SHARE directory if necessary, give sufficient permissions
if [ -d $MOUNTPOINT/$SHARE ] ; then
:
else
mkdir $MOUNTPOINT/$SHARE
fi
chmod 755 $MOUNTPOINT/$SHARE
# Starting adb
adb kill-server
export HOME=/sdcard
# PORT=`getprop service.adb.tcp.port`
setprop service.adb.tcp.port 5555
adb start-server
cat /sdcard/.android/adbkey.pub >> /data/misc/adb/adb_keys
stop adbd
start adbd
adb connect localhost
# Make sure we only use the first device (sometimes there is more than one)
SERIAL=`adb devices | head -n2 | tail -n1 | cut -f1`
if [ "$SERIAL" = "" ] ; then
echo "ERROR: Could not find ADB device.";
fi
# Mounting share via adb
echo Mounting share via adb...
adb -s $SERIAL shell su root -c /system/xbin/busybox mount -t cifs //$IP/$SHARE $MOUNTPOINT/$SHARE -o user=$USER,pass=$PASS,iocharset=utf8,cache=none,directio,CIFSMaxBufSize=130048,rw,file_mode=0777,dir_mode=0777,uid=1015,gid=1015
# If you started adb, then stop it here for security
adb disconnect localhost
stop adbd
PORT=`getprop service.adb.tcp.port`
setprop service.adb.tcp.port $PORT
start adbd
# Show some results
RESULT=`mount | grep $MOUNTPOINT/$SHARE`
if [ "$RESULT" = "" ] ; then
echo "FAILED! //$IP/$SHARE could not be mounted."
else
echo "SUCCESS! //$IP/$SHARE has been mounted on $MOUNTPOINT/$SHARE."
fi
echo
echo All done. You may close this script window now.
4.) This is the script to unmount the share. Name it unmount-music.sh or similar, and edit your settings at the beginning of the script. Again, run it in SManager with SU permissions, and add a desktop widget with SMWidgets if you like.
Code:
#!/system/bin/sh
# Your settings here
SHARE="Music"
MOUNTPOINT="/data/media/0/cifs"
# Check if $SHARE directory exists
if [ -d $MOUNTPOINT/$SHARE ] ; then
# Check if $SHARE directory is empty - if not, unmount the share
if [ "$(su root -c busybox ls -A $MOUNTPOINT/$SHARE 2> /dev/null)" == "" ] ; then
echo "$MOUNTPOINT/$SHARE is empty."
else
su root -c busybox umount -l $MOUNTPOINT/$SHARE
fi
fi
# Show some results
RESULT=`mount | grep $MOUNTPOINT/$SHARE`
if [ "$RESULT" = "" ] ; then
echo "SUCCESS! $MOUNTPOINT/$SHARE has been unmounted."
else
echo "FAILED! $MOUNTPOINT/$SHARE could not be unmounted."
fi
echo
echo All done. You may close this script window now.
Hope this helps some of you. It sure stumped me how incredibly convoluted this simple and much needed procedure has become on Android 4.2.2... just because of that multi-account stuff and new restrictions on adb.
Credits:
Script bits and nls_utf8.ko by H3g3m0n
More script bits by dafunk60 and jmtw000
Punchmod by Jann Horn
Punchmod info by idcrisis
Thanks man, looks awesome, I am going to try it on my 6800.
Do you know how to mount ext4 or ntfs sdcard on CM10.1 based roms?
Removed the original post, still trying to make it work!
I checked vermagic in some existing ko files and found that it is exactly the same as yours.
Sent from my GT-p6800 using Tapatalk HD
m0bster said:
Removed the original post, still trying to make it work!
I checked vermagic in some existing ko files and found that it is exactly the same as yours.
Sent from my GT-p6800 using Tapatalk HD
Click to expand...
Click to collapse
You can try loading the UTF8 module without vermagic string as well, it should work on PAC. Or, make sure you have a blank space at the end of the vermagic string, it is required. Maybe read the short tutorial here: http://forum.xda-developers.com/showthread.php?p=41920265#post41920265
dfkt_ said:
You can try loading the UTF8 module without vermagic string as well, it should work on PAC. Or, make sure you have a blank space at the end of the vermagic string, it is required. Maybe read the short tutorial here: http://forum.xda-developers.com/showthread.php?p=41920265#post41920265
Click to expand...
Click to collapse
I finally managed to mount cifs shares, after loading original cifs and punmode load of nls_utf8.ko.
But I mounted it with cifsmanager. The script always shows "failure to mount" !
Everytime I flash the latest nightly thru opendelta, my xposed framework becomes uninstalled. What can I do to prevent this? Perhaps a flashable zip somewhere?
Have you tried this?
http://forum.xda-developers.com/showthread.php?t=2575966
Honestly, the easiest and surest process would be to use an addon.d script to back up and restore it, while Omni is being updated. Similar to the script that backs up and restores gapps. Rename this file to 90-xposed.sh (also attached), and put it int /system/addon.d/
Code:
#!/sbin/sh
#
# /system/addon.d/90-xposed.sh
# During an upgrade, if /system/bin/app_process.orig exists, this
# script backs up /system/bin/app_process, /system is formatted
# and reinstalled, the ROM bundled /system/bin/app_process is copied as
# /system/bin/app_process.orig, then /system/bin/app_process is restored
# (as would the Xposed Installer do)
. /tmp/backuptool.functions
APP_PROCESS=bin/app_process
case "$1" in
backup)
[ -e "$S/${APP_PROCESS}.orig" ] && backup_file "$S/${APP_PROCESS}"
;;
restore)
if [ -e "$C/$S/${APP_PROCESS}" ]; then
echo "Backuping new $S/${APP_PROCESS} as $S/${APP_PROCESS}.orig"
cp -p "$S/${APP_PROCESS}" "$S/${APP_PROCESS}.orig"
echo "Restoring Xposed $S/${APP_PROCESS}"
restore_file "$S/${APP_PROCESS}"
echo "If your system bootloops, you can either:"
echo " - Replace $S/${APP_PROCESS} with $S/${APP_PROCESS}.orig"
echo " - Remove $S/${APP_PROCESS} and reinstall your ROM"
fi
;;
pre-backup)
# Stub
;;
post-backup)
# Stub
;;
pre-restore)
# Stub
;;
post-restore)
# Stub
;;
esac
PonsAsinorem said:
Honestly, the easiest and surest process would be to use an addon.d script to back up and restore it, while Omni is being updated. Similar to the script that backs up and restores gapps. Rename this file to 90-xposed.sh (also attached), and put it int /system/addon.d/
Code:
#!/sbin/sh
#
# /system/addon.d/90-xposed.sh
# During an upgrade, if /system/bin/app_process.orig exists, this
# script backs up /system/bin/app_process, /system is formatted
# and reinstalled, the ROM bundled /system/bin/app_process is copied as
# /system/bin/app_process.orig, then /system/bin/app_process is restored
# (as would the Xposed Installer do)
. /tmp/backuptool.functions
APP_PROCESS=bin/app_process
case "$1" in
backup)
[ -e "$S/${APP_PROCESS}.orig" ] && backup_file "$S/${APP_PROCESS}"
;;
restore)
if [ -e "$C/$S/${APP_PROCESS}" ]; then
echo "Backuping new $S/${APP_PROCESS} as $S/${APP_PROCESS}.orig"
cp -p "$S/${APP_PROCESS}" "$S/${APP_PROCESS}.orig"
echo "Restoring Xposed $S/${APP_PROCESS}"
restore_file "$S/${APP_PROCESS}"
echo "If your system bootloops, you can either:"
echo " - Replace $S/${APP_PROCESS} with $S/${APP_PROCESS}.orig"
echo " - Remove $S/${APP_PROCESS} and reinstall your ROM"
fi
;;
pre-backup)
# Stub
;;
post-backup)
# Stub
;;
pre-restore)
# Stub
;;
post-restore)
# Stub
;;
esac
Click to expand...
Click to collapse
That'll work. Another option that requires less modification of the script is to copy and modify the example script in /system/addon.d/
i wonder if the xposed toggle actually reinstalls the frameworks files.
XxPixX said:
Have you tried this?
http://forum.xda-developers.com/showthread.php?t=2575966
Click to expand...
Click to collapse
This way works great for me
Sent from my GT-I9505 using xda app-developers app
PonsAsinorem said:
Honestly, the easiest and surest process would be to use an addon.d script to back up and restore it, while Omni is being updated. Similar to the script that backs up and restores gapps. Rename this file to 90-xposed.sh (also attached), and put it int /system/addon.d/
Code:
#!/sbin/sh
#
# /system/addon.d/90-xposed.sh
# During an upgrade, if /system/bin/app_process.orig exists, this
# script backs up /system/bin/app_process, /system is formatted
# and reinstalled, the ROM bundled /system/bin/app_process is copied as
# /system/bin/app_process.orig, then /system/bin/app_process is restored
# (as would the Xposed Installer do)
. /tmp/backuptool.functions
APP_PROCESS=bin/app_process
case "$1" in
backup)
[ -e "$S/${APP_PROCESS}.orig" ] && backup_file "$S/${APP_PROCESS}"
;;
restore)
if [ -e "$C/$S/${APP_PROCESS}" ]; then
echo "Backuping new $S/${APP_PROCESS} as $S/${APP_PROCESS}.orig"
cp -p "$S/${APP_PROCESS}" "$S/${APP_PROCESS}.orig"
echo "Restoring Xposed $S/${APP_PROCESS}"
restore_file "$S/${APP_PROCESS}"
echo "If your system bootloops, you can either:"
echo " - Replace $S/${APP_PROCESS} with $S/${APP_PROCESS}.orig"
echo " - Remove $S/${APP_PROCESS} and reinstall your ROM"
fi
;;
pre-backup)
# Stub
;;
post-backup)
# Stub
;;
pre-restore)
# Stub
;;
post-restore)
# Stub
;;
esac
Click to expand...
Click to collapse
Made this for myself using your script. Thanks, thought I would share.
https://www.dropbox.com/s/ijyat7g5gdb8mq2/xposed_OTA_survival.zip
hlxanthus said:
Made this for myself using your script. Thanks, thought I would share.
https://www.dropbox.com/s/ijyat7g5gdb8mq2/xposed_OTA_survival.zip
Click to expand...
Click to collapse
You should just have to flash it once, not put it in the flash after update location. Once the script is in the correct location, it's pretty much a fire and forget. No more flashing required.
Edit: I know you didn't say that's where it goes, just filling in this info for others. A lot of people like to stack a bunch of zips in that directory for some reason.
Similar script for kernel?
Is there a way to keep the kernel in a similar fashion (e.g. I have franco's kernel flashed for N5 and would like to keep it even with nightly updates)?
Thanks
The update script can't do that. But i think i remember s.o. mentioning using opendelta to reflash the ZIP.
Sent from my Find 5 using XDA Premium 4 mobile app
The Xposed method
Xposed installer itself can give you the solution:
Inside Xposed installer, in settings, choose install method to be zip & manual flash, hit install and it will create the required flashable zip that installs/enables the Xposed framework. Now find that file (remember the path from the confirmation dialog) and copy it into OpenDelta's FlashAfterUpdate folder. You are done.
dumb question how do i copy that 90-xposed.sh to the /system/addon.d/ folder?
adb? if so, what is the command? sorry I am alittle dumb to doing this.
thanks!
spacemanvt said:
dumb question how do i copy that 90-xposed.sh to the /system/addon.d/ folder?
adb? if so, what is the command? sorry I am alittle dumb to doing this.
thanks!
Click to expand...
Click to collapse
If using adb,
adb push /path/to/file/on/your/pc /desired/path/to/file/on/your/phone
Or use a root file explorer to just copy and paste.