Related
Hey everyone,
wesgarner said:
Zip Align reduces the amount of RAM used during processing running for a major speed increase in running the apps: http://developer.android.com/guide/developing/tools/zipalign.html
Click to expand...
Click to collapse
I had been messing about with a script to pull apks off my phone, zipalign them and then push them back, but then I saw wesgarner's CM build with a binary and script for use on your phone. I don't really want to mess round with flashing a ROM just for that though, so I've ripped them out and uploaded them below. Another reason is I want to run this manually (with GScript) rather than on boot (as it does in wesgarner's ROM).
I take no credit for this, the binary and script were both taken from wesgarner's CM buiild.
To "install" this, just adb push the two files in the zip below onto your phone with:
Code:
adb shell mount -o remount,rw /system
adb push zipalign /system/bin
adb push zipalign_apks /system/sd/zipalign_apks.sh
adb shell chmod 755 /system/bin/zipalign /system/sd/zipalign_apks.sh
adb shell mount -o remount,ro /system
Then anytime you want to run the script just do:
Code:
adb shell sh /system/sd/zipalign_apks.sh
Or in terminal:
Code:
su
sh /system/sd/zipalign_apks.sh
Has been tested on CM 4.2.7.1
ZipAlign
senab said:
Hey everyone,
I had been messing about with a script to pull apks off my phone, zipalign them and then push them back, but then I saw wesgarner's CM build with a binary and script for use on your phone. I don't really want to mess round with flashing a ROM just for that though, so I've ripped them out and uploaded them below. Another reason is I want to run this manually (with GScript) rather than on boot (as it does in wesgarner's ROM).
I take no credit for this, the binary and script were both taken from wesgarner's CM buiild.
To "install" this, just adb push the two files in the zip below onto your phone with:
Code:
adb shell mount -o remount,rw /system
adb push zipalign /system/bin
adb push zipalign_apks.sh /system/sd
adb shell chmod 755 /system/bin/zipalign /system/sd/zipalign_apks.sh
adb shell mount -o remount,ro /system
Then anytime you want to run the script just do:
Code:
adb shell /system/sd/zipalign_apks.sh
Or in terminal:
Code:
su
sh /system/sd/zipalign_apks.sh
Has been tested on CM 4.2.7.1
Click to expand...
Click to collapse
i do not even know what zipalign does .. but i did add this to my script
# lucid -z
so .. what does it do exactly?
Sweet... Thanks...
I was surprised that more than half of the Apps I have were already ZipAligned...
LucidREM said:
i do not even know what zipalign does .. but i did add this to my script
# lucid -z
so .. what does it do exactly?
Click to expand...
Click to collapse
APKs (as you probably already know) are just zip files. zipalign simply aligns the APK on 4-byte boundaries which Android is more efficient wrt memory access.
You can read more from Jean-Baptiste Queru at http://android-developers.blogspot.com/2009/09/zipalign-easy-optimization.html
Vermithrax said:
Sweet... Thanks...
I was surprised that more than half of the Apps I have were already ZipAligned...
Click to expand...
Click to collapse
Since the 1.6 SDK was released, the ADT does this automatically on APK export. Therefore any app which has been updated since ~September (and was developed using the ADT Eclipse plugin) will be zipalign'd. I was more surprised that 12 out of the 43 apps on my phone weren't aligned!
ZipAlign
senab said:
APKs (as you probably already know) are just zip files. zipalign simply aligns the APK on 4-byte boundaries which Android is more much efficient wrt memory access.
You can read more from Jean-Baptiste Queru at http://android-developers.blogspot.com/2009/09/zipalign-easy-optimization.html
Click to expand...
Click to collapse
that's awesome .. thanks for the link .. i hadn't read about that
Thanks much for this!
Here is a simple gscript to install zipalign after a wipe or new build flash.
You must first create directory /sdcard/zipalign and place zipalign from the zip in the OP there. Path to the file should now be /sdcard/zipalign/zipalign.
Place this script in your gscript folder (after removing .txt from the name) and load it in gscript with su permissions.
I also find it easier to run the script in the zip from the OP in Gscript as well. Instead of placing it in /system/sd run this (assumes zipalign_apks.sh is at root of C:\)
Code:
adb remount
adb push C:\zipalign_apks.sh /sdcard/gscript/zipalign_apks.sh
Then just load it into Gsrcipt with su permissions as with the other script.
Easiest of all may just be to use the commands within Lucid's script. But, I'm comfortable with Gscript, and I can make it 2 clicks away.
EDIT: First execution, you may want to run the original way, because guess what? Gscript isn't zipaligned. But it worked fine just the same.
worked great thanks.
Thanks. I didn't want to flash whole ROM to zipalign apps, so script was very handy.
Actually I've zipaligned only 2 apps, one of them was everybody loved Linda
so anyone wanna bless me with a terminal code to install the script?
garz said:
so anyone wanna bless me with a terminal code to install the script?
Click to expand...
Click to collapse
Read, its on the first post....xD
ZipAlign
garz said:
so anyone wanna bless me with a terminal code to install the script?
Click to expand...
Click to collapse
# lucid -z
yeah so su? then #lucid -z? cause that did nothing for me...
LucidREM said:
i do not even know what zipalign does .. but i did add this to my script
# lucid -z
so .. what does it do exactly?
Click to expand...
Click to collapse
I put a quick explanation of my script on my ROM page: here ya go (rough explanation)
Zip Align reduces the amount of RAM used during processing running for a major speed increase in dex-opt and running the apps, along with the RAM hack and a CC (or your userinit) boots speeds incredibly and better usability of apps (boot and system) in Android: http://developer.android.com/guide/d.../zipalign.html
Most developers have not used this yet (CM does ZipAlign his apps), but this does for the system apps provided from the now old Google Apps
Click to expand...
Click to collapse
senab said:
Since the 1.6 SDK was released, the ADT does this automatically on APK export. Therefore any app which has been updated since ~September (and was developed using the ADT Eclipse plugin) will be zipalign'd. I was more surprised that 12 out of the 43 apps on my phone weren't aligned!
Click to expand...
Click to collapse
Agreed. The Market won't let non-zipaligned apps be uploaded.
AndroidAppCritic said:
Agreed. The Market won't let non-zipaligned apps be uploaded.
Click to expand...
Click to collapse
it will really, it doesn't detect the diff
Also, SDK4 didn't really include an enforced ZipAlign like SDK5 (eclair) does
Plus I built the ZipAlign from source from eclair - so this script may not update them all perfectly
garz said:
yeah so su? then #lucid -z? cause that did nothing for me...
Click to expand...
Click to collapse
Unzip the files to your SD Card, then:
Code:
su
mount -o remount,rw /system
mv /sdcard/zipalign /system/bin
mv /sdcard/zipalign_apks /system/sd/zipalign_apks.sh
chmod 755 /system/bin/zipalign /system/sd/zipalign_apks.sh
mount -o remount,ro /system
Post deleted becoz it was redundant
can someone make a script for windows or a bat file that can zipalign a batch of apks? I am not that ofay with line commands and when i create a new theme (which i often do), i then have to go and zipalign every single apk i have altered 1 at a time..... i do:
Code:
zipalign -f -v 4 E:\app\theapp.apk E:\app\theapp.apk.out
senab said:
Unzip the files to your SD Card, then:
Code:
su
mount -o remount,rw /system
cp /sdcard/zipalign /system/bin
cp /sdcard/zipalign_apks.sh /system/sd
chmod 755 /system/bin/zipalign /system/sd/zipalign_apks.sh
mount -o remount,ro /system
Click to expand...
Click to collapse
This isnt working for me bc of the .sh after zipalign_apks .. do i rename the zipalign_apks to zipalign_apks.sh after unzipping?
edit:that worked THANKS!
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 !
Quadrant Score now on stock ROM: 1754 (before 1090)
In everyday usage the speed improvement is NOT increased that way (50% - only a benchmark), but eg gallery IS much faster.
You have to have root..
type via console:
mount -o remount,noauto_da_alloc /data /data
or (recomended)
download "scripter" from market
-> new script
-> name it as you want
-> script: mount -o remount,noauto_da_alloc /data /data
-> save and
-> run script
It's only temp "hack"! - after every reboot you have to run the script again unless it isn't included in a ROM or kernel.
Thanks to supercurio for this.
Original thread http://forum.xda-developers.com/showthread.php?t=876069
I don't know if init.d is supported on the desire s since i don't have one, but you could create a script for init.d so it gets executed at each startup
coldflid said:
I don't know if init.d is supported on the desire s since i don't have one, but you could create a script for init.d so it gets executed at each startup
Click to expand...
Click to collapse
Yes, works, thanks-
The 2 customs do have the line in init.d
Hi,
I am trying Beta 3.1 SMS KJ6 kernel.
I went to General Section -> "random reboots" after having some, and was told
that it was caused due to inability to write to system, so i was told to add
systemctl init.d script this line :
mount -oremount,rw /dev/block/stl9 /system
just before line
sysctl -p
Other than that i need to "fix permissions".
but doing this once did not prevent further reboots.
My question is : Is there a way to fix all permissions on init.d script,
so it will be done on every boot ?
will it even help ?
Thanks.
itzik2sh said:
Hi,
I am trying Beta 3.1 SMS KJ6 kernel.
I went to General Section -> "random reboots" after having some, and was told
that it was caused due to inability to write to system, so i was told to add
systemctl init.d script this line :
mount -oremount,rw /dev/block/stl9 /system
just before line
sysctl -p
Other than that i need to "fix permissions".
but doing this once did not prevent further reboots.
My question is : Is there a way to fix all permissions on init.d script,
so it will be done on every boot ?
will it even help ?
Thanks.
Click to expand...
Click to collapse
You can if you know what all permissions are 'fixed' when CWM does that. I'm sure by looking at CWM source we could figure it out then add the necessary commands after the mount and before the sysctl -p line.
itzik2sh said:
Hi,
I am trying Beta 3.1 SMS KJ6 kernel.
I went to General Section -> "random reboots" after having some, and was told
that it was caused due to inability to write to system, so i was told to add
systemctl init.d script this line :
mount -oremount,rw /dev/block/stl9 /system
just before line
sysctl -p
Other than that i need to "fix permissions".
but doing this once did not prevent further reboots.
My question is : Is there a way to fix all permissions on init.d script,
so it will be done on every boot ?
will it even help ?
Thanks.
Click to expand...
Click to collapse
You can try putting this into a script and calling it in your init.d
http://forum.xda-developers.com/showthread.php?t=1221591
Although I believe permissions shouldn't be lost when you reboot, so your problem is likely something else.
ignacioxd said:
You can try putting this into a script and calling it in your init.d
http://forum.xda-developers.com/showthread.php?t=1221591
Although I believe permissions shouldn't be lost when you reboot, so your problem is likely something else.
Click to expand...
Click to collapse
+1 to that.
Hi
I saw that post...
Unlike mounting system as read/write, which is really easy to validate,
how can i know it was actually performed ?
You can manually changea file you know is supposed to be fix in the script b4 running it, than run it and see if it changed back
Sent from my SGH-T959V using XDA App
Thanks mate, I'll give it a try...
Sent from me
Welcome :-D
Sent from my SGH-T959V using XDA App
itzik2sh said:
Hi,
I am trying Beta 3.1 SMS KJ6 kernel.
I went to General Section -> "random reboots" after having some, and was told
that it was caused due to inability to write to system, so i was told to add
systemctl init.d script this line :
mount -oremount,rw /dev/block/stl9 /system
just before line
sysctl -p
Other than that i need to "fix permissions".
but doing this once did not prevent further reboots.
My question is : Is there a way to fix all permissions on init.d script,
so it will be done on every boot ?
will it even help ?
Thanks.
Click to expand...
Click to collapse
Doesnt Valhalla Final already do that? i checked whitehawkx OP and that is included in the features.
Most people in here knows what init.d is, and almost all their devices (If not all) has init.d implemented, a widely used feature that a lot of people (Users and Devs) finds essential for any ROM. There is however one major issue with init.d implementations on Android, that is, we do not have any standards for how it should work.
The two most used methods are
Starting a service at boot which executes 'run-parts' on the init.d folder
Doing a direct execution of 'run-parts' at boot on the init.d folder
In the init.rc code they don't look much different from one another. Both will make sure that run-parts is executed from the onboot section, but they could not be further apart from the way they do it.
Executing run-parts from a service will transfer the whole execution to a new process, meanwhile init continues with the rest of the boot process. This means that all of the scripts are executed while the phone continues to start it's services and prepare everything. Depending on the scripts in init.d and the speed of the device, it might even start completely into the UI before init.d has finished all of it's scripts.
Executing run-parts directly from init.rc however, will execute the init.d scripts in the same process. This means that init cannot continue with anything until all of the init.d scripts has finished. This is the way that init.d should work, and here is why.
Some times you will get or make a script where it is essential that it get to finish before anything else is executed or started. One example could be sd-ext which job is to move content between partitions. This is not a job that works well while a device is booting, as a lot of the data being parsed around is actually being used by the system during boot.
Also should you have a script that needs to be executed while the device is booting, then it is quite simple to accomplish this by adding a function to the script and start that into another process from within the script. However this does not work the other way around. So you can use the second init.d implementation for both purposes.
But it gets even worse. This article explains how to add init.d to ROM's without altering the ramdisk. The problem is that this introduces a third way of how init.d might operate, as this will not execute init.d neither before or during boot, but after. Looking at the default implementation of install-recovery.sh, this file is not executed until after the UI has been started, meaning when the device is fully booted.
We need a standard here people. Something that will ensure anyone building init.d scripts of how and when the scripts will be executed. Otherwise we are limited to small operations where init.d's implementation has no factor, in which case we might as well just stop implementing it in the first place.
Last I want to make a notice to anyone that thinks it is wise to place Sleep commands in init.d scripts.
Code:
#!/system/bin/sh
# Wait until we see some android processes to consider boot is more or less complete
while ! pgrep com.android ; do
sleep 1
done
# ... The rest of the code
This is an example I have made. First consider all of the scripts in init.d that is set to be executed after this one. Now consider adding this script to ROM's with the second init.d implementation (Hint, the device will never boot).
The better way to do something like this, is like fallowing
Code:
#!/system/bin/sh
)
# Wait until we see some android processes to consider boot is more or less complete
while ! pgrep system_server; do
sleep 1
done
# ... The rest of the code
) &
if pgrep logwrapper; then
killall logwrapper
fi
First of all this will allow the rest of the init.d scripts to be executed right away. Secondly it will allow anyone with the second init.d implementation to boot in the first place.
Note the "killall logwrapper". Almost every init.d implementation adds logwrapper to execute run-parts, "/system/bin/logwrapper /system/bin/run-parts /system/etc/init.d". However, logwrapper will not continue until all of the scripts sub-processes has finished. So we will have to force our way out. The script will continue normally below the kill code and the rest of init.d will as well.
Nice info man.
I've been avoiding bootloops or no boot with the bulletproof apps script by doing $0 & exit 0.
If it read any android process, it would then be able to sleep safely.
Obviously, this is a more eloquent method
Thanks
Thank you for this info. Very helpful
Sent from my SPH-L710 using TapaTalk 4 BETA
Want to speed up your device? Click here
great post, much needed discussion given the variety of ROM implementations out there. i for one have had to learn about and experiment the hard way across several methods due to locked bootloader and use of virtual ROM slots for my device (damn you to hell Motorola).
that being said, what are your thoughts on proper init.d implementation if a boot hijack is in use (2nd init i believe it's
called?)
Sent from my DROID BIONIC using Tapatalk 2
How about using pgrep system_server than pgrep com.android?
LENAROX said:
How about using pgrep system_server than pgrep com.android?
Click to expand...
Click to collapse
That's funny. I though the same thing
Sent from my SPH-L710 using Tapatalk 2
LENAROX said:
How about using pgrep system_server than pgrep com.android?
Click to expand...
Click to collapse
Have no idea. I got this from one of the scripts I wrote about. Guess it depends on what they were trying to catch. But then again, why not com.android over system_server? I don't see a performance issue and both would tell that the system has been started. If anything, com.android only takes up 11 characters while system_server takes 13
dk_zero-cool said:
Have no idea. I got this from one of the scripts I wrote about. Guess it depends on what they were trying to catch. But then again, why not com.android over system_server? I don't see a performance issue and both would tell that the system has been started. If anything, com.android only takes up 11 characters while system_server takes 13
Click to expand...
Click to collapse
characters dont matter much.(couple of ticks on cpu wont matter much either)
You should do system_server or zygote instead of com.android for accuracy.
Just maybe if there wont be any process name that starts with com.android, It might not work.
And did you know?
- system_server calls dalvik vm function. -> Start of the android os.
-zygote launches system_server and its stayed on ram as a forked process.
LENAROX said:
characters dont matter much.(couple of ticks on cpu wont matter much either)
Click to expand...
Click to collapse
LOL, I know. Just the only difference I could find. Like I said, I did not make it, so I don't know why it was used. If you check my scripts like Mounts2SD, you will see that I use system_server as well
LENAROX said:
And did you know?
Click to expand...
Click to collapse
I also build ROM's, so yes I did
dk_zero-cool said:
LOL, I know. Just the only difference I could find. Like I said, I did not make it, so I don't know why it was used. If you check my scripts like Mounts2SD, you will see that I use system_server as well
I also build ROM's, so yes I did
Click to expand...
Click to collapse
I knew you would already know that. Just checking
LENAROX said:
I knew you would already know that. Just checking
Click to expand...
Click to collapse
Well I live to please, so I have changed the OP example to use "system_server" rather than "com.android"
dk_zero-cool said:
Well I live to please, so I have changed the OP example to use "system_server" rather than "com.android"
Click to expand...
Click to collapse
I've always looked for "android"
Why?
Because the later a script runs, the less chance of a bootloop.
And depending on what the script is doing, later rather than earlier may be preferred anyway.
zeppelinrox said:
I've always looked for "android"
Why?
Because the later a script runs, the less chance of a bootloop.
And depending on what the script is doing, later rather than earlier may be preferred anyway.
Click to expand...
Click to collapse
And I see no problem with it. com.android.systemui will always be available on an Android device. And when this is started, the device is more or less fully booted. system_server get's started at the end of onBoot, which means right when the device starts to boot. So yes, the question would properly be whether or not a script should execute at the beginning or at the end of the boot cycle.
Exactly.
I'd rather the device be pretty much fully booted so that the kernel is less likely to trump settings that I apply.
Of course, if its a mount script or something like that, the earlier, the better so you wouldn't want to grep android in that instance.
I don't know but the "while ! grep system_server and while ! grep com.android" both cause sh stall issues on some devices. I found placing a simple "busybox sleep 45" fixes the sh stall and gives Roms time to boot before running some init.d parts. No bootloops have been reported
Sent from my SPH-L710 using Tapatalk 2
Exit_Only said:
I don't know but the "while ! grep system_server and while ! grep com.android" both cause sh stall issues on some devices. I found placing a simple "busybox sleep 45" fixes the sh stall and gives Roms time to boot before running some init.d parts. No bootloops have been reported
Sent from my SPH-L710 using Tapatalk 2
Click to expand...
Click to collapse
not grep.... pgrep
however, not all busybox builds have pgrep.... which can be another problem.
To avoid that, I use ps and grep like so...
Code:
while [ ! "`ps | grep [a]ndroid`" ]; do sleep 10; done;
I put the square brackets in [a]ndroid so that grep won't find a match for itself (ie. ps | grep android can result in a "grep android" showing up as a running process) and result in a false positive.
Oh yeah... I do sleep 10 instead of sleep 1 which avoids needlessly usage of battery/cpu cycles (which is fine if you rather run stuff late)
Exit_Only said:
I don't know but the "while ! grep system_server and while ! grep com.android" both cause sh stall issues on some devices. I found placing a simple "busybox sleep 45" fixes the sh stall and gives Roms time to boot before running some init.d parts. No bootloops have been reported
Sent from my SPH-L710 using Tapatalk 2
Click to expand...
Click to collapse
'grep' is used to search for matches in a file. The syntax here is "grep %match %file". If you do "grep %match", grep starts a never ending process. On a service implemented init.d ROM, the device will boot because init.d is running it it's own nested process. However, init.d will never finish. On a direct executed init.d implemented ROM, the device will never boot, because init.d is executed from the same process as init is running in.
So when making a script, it is important to use a lot of debug logging when making them, to make sure that they behave as they should. For an example if you make a script which uses sqlite3 (Properly other binaries as well), it is good to notice that on direct executed init.d ROM's, it will not work, because the 'exec' function does not parse the PATH variable from init.rc, which means that BOOTCLASSPATH is missing. This describes where sqlite3 can locate it's binaries. And most /system/bin/sysinit files only provide the PATH variable.
dk_zero-cool said:
'grep' is used to search for matches in a file. The syntax here is "grep %match %file". If you do "grep %match", grep starts a never ending process. On a service implemented init.d ROM, the device will boot because init.d is running it it's own nested process. However, init.d will never finish. On a direct executed init.d implemented ROM, the device will never boot, because init.d is executed from the same process as init is running in.
So when making a script, it is important to use a lot of debug logging when making them, to make sure that they behave as they should. For an example if you make a script which uses sqlite3 (Properly other binaries as well), it is good to notice that on direct executed init.d ROM's, it will not work, because the 'exec' function does not parse the PATH variable from init.rc, which means that BOOTCLASSPATH is missing. This describes where sqlite3 can locate it's binaries. And most /system/bin/sysinit files only provide the PATH variable.
Click to expand...
Click to collapse
I know that it was a typo on my end.
Sent from my SPH-L710 using Tapatalk 2