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 !

[Guide] Installing Fedora 12 on SGS4G

Good news for this guide:
I've done it already so you just need to download the files and follow these simple instructions:
YouTube Video of earlier stages of me running Fedora 12
0) make sure your Android Device is rooted (added so I get less nonsensical "It doesn't work!!!!!" and more "I followed everything I get an <insert error here> error! HELP!"
1) download files from http://zornco.net/androfedora/
2) extract fedora_scripts.rar and place all four files (bootfedora, unmountfedora, fedora.sh, fedora.img) in /sdcard/fedora/
3) open android terminal emulator
4) run command "su" (you might have to press allow in the Superuser App)
5) run command "cd /sdcard/fedora"
6) run command "sh fedora.sh"
7) run command "bootfedora" If that returns "not found" run "sh /sdcard/fedora/bootfedora"
8) now you're in fedora (should now see [[email protected] /]#)
OPTIONAL:
9) run "service sshd start" - to run an SSH server
P.S.: I set the root password to password
P.S.S.: I'm pretty sure it's impossible to screw up your Android OS doing this unless you terribly, terribly mess up this guide
Run the scripts and post your errors <- this will help me immensely to make this available on all Android Devices! please, thank you, and have fun!

N4melessS0ldier said:
Good news for this guide:
I've done it already so you just need to download the files and follow these simple instructions:
0) make sure your SGS4G is rooted (added so I get less nonsensical "It doesn't work!!!!!" and more "I followed everything I get an <insert error here> error! HELP!"
1) download files from http://anonymouslyacquired.info/fedoraonsgs4g/
2) place all three files in /sdcard/fedora/
3) open android terminal emulator
4) run command "su" (you might have to press allow in the Superuser App)
5) run command "sh /sdcard/fedora/fedora.sh"
6) run command "bootfedora" If that returns "not found" run "sh /sdcard/fedora/bootfedora"
7) now you're in fedora (should now see [[email protected] /]#)
8) run "startvnc" (my automated vncserver script)
AND/OR
9) run "service sshd start"
If you want to see your newly installed Fedora 12 OS:
android-vnc-client to localhost:5901 with password = password
P.S.: I set the root password to password
P.S.S.: I'm pretty sure it's impossible to screw up your Android OS doing this unless you teriibly, terribly mess up this guide
P.S.S.S: I'm running a rooted Bionix Frost SGS4G ROM with Bali KERNEL (don't think that matters but I do know being rooted matters!)
edit: apparently this isn't working for anyone but myself so far sooooo:
To Moderators: You may delete this thread and move the thread in Galaxy S 4G General: [Guide] Installing Fedora 12 on SGS4G to Galaxy S 4G Android Development (I only posted in General because I didn't have permissions to post here yet and posting here (I hope) will increase my ability to make this available to all SGS4G owners!)
Click to expand...
Click to collapse
forgive me for asking because im usually one to read to learn, but since you made this
what BENEFITS are gained from fedora?
i just dont know exactly what it is? thank you

I suppose mainly for developing. If you have fedora installed on a phone with a kernel that supports adding kernel modules and the kernel headers then you can build new modules for your phone on your phone. Also, it's sortof fun to show off, and it can potentially do some neat things (potentially aircrack-ng if it supports the WiFi device - maybe unlocking some features by allowing you to add linux tools and binaries - adding new media players - converting different media files to things accessible by Android Apps (or just playing them from Fedora) - extracting weird archives - and I'm sure if you take them time you can probably think of cool things you can do with an extremely portable, extremely customizable Linux Operating System Distribution (whether "legit" or less than))
edit: also, most things are already precompiled on a Fedora 12 ARM repo but if they aren't you can easily compile them from your phone (I suggest plugging it in and compiling/installing so you don't waste battery life (also I suggest doing that from your computer to your phone through SSH for easier typing, quicker command entering, etc.) and it may take some time depending on how overclocked the phone is)

Thanks for the explanation brotha!
sent from my sgs4g 2.3.3, finally

So I would be able to modify the frameworkres.apk and other things of that nature?
Sent from my SGH-T959V using XDA Premium App

I got it!
http://forum.xda-developers.com/showpost.php?p=8755526&postcount=7
If bootubuntu gets executed before Android loads all app2sd applications, it is possible solves the loop device busy error even with App2SD applications installed. It requires a very perfect timing, today after few experiments on my phone, I worked out a process which can always boot up Ubuntu on my phone:
1. Reboot phone
2. as soon as you enter lock screen, unlock screen
3. quickly go to terminal emulator
4. become su by typing su and enter
5. type bootubuntu and wait (type it fast... practice )
Click to expand...
Click to collapse
So apparently it's apps2sd causing this problem. I used the ubuntu guide but I'm sure fedora will work now, since it was just a mounting issue.
What I did to type this quickly was change the bootubuntu (or bootfedora in this case) script to just b so i could just do su, press enter, then b, press enter
EDIT
This means that it's possible to boot it as an init.d script to make sure it loads before the phone is done scanning the SD card. I think I'll wind up doing that... It's easier to kill the script when you don't need it than boot it when you want it.

Oh gosh, thank you so much I was just about to give up on public releases. Now that I know the problem I can fix my scripts to get arpund it. Thanks so much!
Sent from my SGH-T959V using XDA App

Just wanted to post again to express my gratitude I will definitely post a new script that will mount regardless of app2sd. Thank you! Thank you! Thank you!
Sent from my SGH-T959V using XDA App

Hey man I'm as happy as you are... Just spent the last few hours messing with ubuntu on the phone. Piece of work that is. You said fedora has sound support when booting on the phone?

Yeah I managed to get sound working.... sad part is my (granted I forgot to make a backup) version of the filesystem image became corrupt.... oops. Well, I'm buying a larger sd card in about 30 mins and I'm going to redo it so soon I'll upload the new img and scripts aswell as a kernel module for you and others using a different linux distro than fedora
Sent from my SGH-T959V using XDA App

Sounds great. Just a heads up, I was messing with the bootscript and I added the lines that mount the sdcard to the other OS's filesystem. Twice I got the phone freezing up so I did a hard reboot (battery pull) and when the phone rebooted it seems as if the /data partition got wiped (except for my background image which got saved, go figure). Weird, not even sure how that could've happened.

Very odd. If this forum has private messaging, PM me exactly what you added so I can make sure that or something more serious doesn't happen to others. Thanks
Sent from my SGH-T959V using XDA App

I just updated the script to mount whether or not you have App2SD installed on your phone.
It turns out App2SD uses a separate loop device for each app you have moved to your SD Card.
I've set the script "bootfedora" to create a "/dev/loop99"
So, unless you have 99 or more Apps moved to your SD Card it should work!
Re-download "bootfedora" from:
http://anonymouslyacquired.info/fedoraonsgs4g/
edit: currently working on new version of my Fedora 12 filesystem (should include a lot more (including working sound for a "nicer" feel) but it sucks if you have less than 2GB of freespace on your SD Card)

I'm completely in the dark when it comes to Fedora but I find it very interesting. It is going to be a Big Development for our phone I'm sure.
Wish I could help you but this is way out of my league.
I'm definitely following your progresses closely. Keep up the Great Work fellas!
Thanks

N4melessS0ldier said:
I just updated the script to mount whether or not you have App2SD installed on your phone.
It turns out App2SD uses a separate loop device for each app you have moved to your SD Card.
I've set the script "bootfedora" to create a "/dev/loop99"
So, unless you have 99 or more Apps moved to your SD Card it should work!
Re-download "bootfedora" from:
http://anonymouslyacquired.info/fedoraonsgs4g/
edit: currently working on new version of my Fedora 12 filesystem (should include a lot more (including working sound for a "nicer" feel) but it sucks if you have less than 2GB of freespace on your SD Card)
Click to expand...
Click to collapse
Alright man, I got it to boot perfectly without doing this at boot startup! Aww yeah, it's on!
One thing though, the scripts you've been posting lately have windows line endings insteads of Unix, so I had to convert them before they worked.

FBis251 said:
Alright man, I got it to boot perfectly without doing this at boot startup! Aww yeah, it's on!
One thing though, the scripts you've been posting lately have windows line endings insteads of Unix, so I had to convert them before they worked.
Click to expand...
Click to collapse
I'm not sure what I'm doing wrong but I keep getting the error
chroot: notfound
: not found
Shutting down Fedora
: not found

glt0404 said:
I'm not sure what I'm doing wrong but I keep getting the error
chroot: notfound
: not found
Shutting down Fedora
: not found
Click to expand...
Click to collapse
What rom/kernel are you using?

FBis251 said:
What rom/kernel are you using?
Click to expand...
Click to collapse
Stock rom with Bali 3.3UV
I'm pretty sure that's not the problem cause I've successfully booted Ubuntu (without gui).

Post up the whole list of commands you ran, plus the errors. Just copy the whole command line text

FBis251 said:
Post up the whole list of commands you ran, plus the errors. Just copy the whole command line text
Click to expand...
Click to collapse
This is what I got.
Code:
export PATH=/data/local/bin:$PATH
# #cd /sdcard/fedora/
# su
# sh fedora.sh
Usage: mount [-r] [-w] [-o options] [-t type] device directory
Usage: mount [-r] [-w] [-o options] [-t type] device directory
rm failed for -f, No such file or directory
: not found
: not found
: not found
: not found
: not found
: not found
Fedora Chroot Bootloader v0.1
Fedora Bootloader is now installed!
This process does NOT damage Android OS!
Original Installer by Charan Singh
Modified for Fedora Chroot by N4melessS0ldier
To enter the Fedora Linux console just type 'bootfedora'
: not found
: not found
# sh bootfedora
Usage: mount [-r] [-w] [-o options] [-t type] device directory
Usage: mount [-r] [-w] [-o options] [-t type] device directory
: No such file or directoryxtcard2
': Read-only file systemctory '/mnt/extcard2
'knod: invalid number '0
losetup: not found
failed: No such file or directory/extcard2
': No such file or directoryy '/mnt/extcard2/rootfs-f12
failed: No such file or directoryp1 on /mnt/extcard2/rootfs-f12
': No such file or directoryy '/mnt/extcard2/rootfs-f12
failed: No such file or directoryard2/rootfs-f12
': No such file or directoryrd2/rootfs-f12
': No such file or directoryrd2/rootfs-f12
failed: No such file or directoryrd2/rootfs-f12
failed: No such file or directoryxtcard2/rootfs-f12
failed: No such file or directoryrd2/rootfs-f12
failed: No such file or directoryrd2/rootfs-f12
Setting /etc/resolv.conf to Google Open DNS 8.8.8.8 and 8.8.4.4
: directory nonexistentte /mnt/extcard2/rootfs-f12
: directory nonexistentte /mnt/extcard2/rootfs-f12
Setting localhost on /etc/hosts
: directory nonexistentte /mnt/extcard2/rootfs-f12
Operation complete!
Courtesy N4melessS0ldier!
chroot: not found
: not found
Shutting down Fedora
: not found
#

[DEV][SCRIPT] First-Boot App Install

First-Boot Install System​
I have searched Far and wide for something like this since i first put out SleeperROM in November and always come up empty.
So with the latest release, i decided it was finally time to do it myself.
All you have to do is, using the following package as a template either on its own or in your ROM, make sure your batch folder with the .apk's to install are in /data/.firstboot/
Why
Some apps like QuickPic, ConnectBot, TinyFlashlight, Flash, Google Goggles and others that rely on linked libs don't like to simply be copied to their install dir because many won't install their own libs unless the PackageManager does it and/or they won't add themselves to the packages list (like QuickPic). The old solution is to include the lib either in the /data/data/appdir/lib with the rom install OR in /system/lib but this is quite wasteful especially in the case of big apps like Flash where including the libs separately from the app effectively doubles the space taken up on the rom by that single app since the apk still contains the lib files within.
So the solution is to install on first boot by including the apps in a batch folder for the script to process.
How it works
What it does is run from the init scripts, as one of the last scripts to run, it waits until the Android core system is up (checks to be sure by waiting for the SystemUI process is running then waits for an additional 10 seconds)
Then runs /data/.firstboot.sh, which is where you should put your first boot routines. Included in this script is the batch app installer which looks for the apps in /data/.firstboot/ and stores temporary app backups in /cache/tmp -- so be mindful that on MTD roms, the cache partition is smaller so may have to modify the $tmp variable to wherever you want to store temporaries
After installing, it sleeps for a proportional number of seconds (5 seconds per app installed) to ensure there is no race condition between installs or the final permissions_fix, zipalign and tmp cleanup. The /data/.firstboot.sh script removes itself when everything is complete.
The remaining components are kept in there for additional use by the /etc/init.d/Y02firstboot script in the future, so then all that needs to be put on the phone is a new /data/.firstboot/ dir and replacement /data/.firstboot.sh to run a batch of updates.
The Apps MUST be named by their package name.
I.e. Titanium Backup MUST be named com.keramidas.TitaniumBackup.apk
the file name must correspond with the name of the data dir in /data/data/ the script is lazy in that way, i didn't feel like keeping a file manifest of installs, instead just like to drop in apps to install.
The installer
consists of the following components:
- /system/etc/init.d/Y02firstboot
- /system/xbin/rsync
- /system/xbin/fix_permissions
- /system/xbin/batch_zipalign
- /system/xbin/sleeperlog (echos, logcats, and writes a log of activity to /sdcard/sleeperlog.txt)
- /data/.firstboot.sh
- /data/.firstboot/ (batch app directory)
- NOT INCLUDED, there must be a busybox bin somewhere in $PATH - this is not a problem for most roms
See the package link for a ready to use first-boot installer [CWM] flashable. Just drop your apks into /fs/data/.firstboot/ for a batch app updater
Download the template/usable package
DOWNLOAD MOD_CWM-FirstBoot-20120112.zip
File size: 341.07 KB / MD5 23d88c349b8d2fa3cd2f9958ae99a1f6
​
THE MAIN COMPONENTS:
/system/etc/init.d/Y02firstboot
Code:
#!/system/bin/sh
# execute post-install script on First boot
# 01022012 SENSEISIMPLE
SLEEP=3
FBSCR="/data/.firstboot.sh"
BB="busybox"
pg () {
$BB ps | $BB grep "[email protected]" | $BB grep -v "$( echo $BB grep [email protected] )"
}
if [ -f "$FBSCR" ]; then
#install apps on first boot after system services have started
sleeperlog "Found $FBLOC"
sleeperlog "Waiting for system"
$BB chmod 0755 $FBSCR
while : ; do
if pg systemui; then
$BB sleep 10
sleeperlog "system loaded."
log -p i -t boot "Executing $FBSCR script"
sleeperlog "Running FirstBoot init"
$FBSCR
break
fi
sleeperlog "WAITING FOR SYSTEM SERVICE: sleeping for $SLEEP s..."
$BB sleep $SLEEP
done
fi
/data/.firstboot.sh
Code:
#!/system/bin/sh
#
# 20120107 - SENSEISIMPLE
#
log -p i -t init:firstboot "INIT.firstboot BEGIN: USER SCRIPT $FBLOC.sh"
sleeperlog "FirstBoot Script OK TO RUN"
FBLOC="/data/.firstboot"
tmp="/cache/tmp/firstboot"
bak="$tmp/bak/data/data/"
BB="busybox"
RM="$BB rm"
CP="$BB cp"
MV="$BB mv"
MKDIR="$BB mkdir"
LS="$BB ls"
CHMOD="$BB chmod"
SLEEP="$BB sleep"
GREP="$BB grep"
pg () {
$BB ps | $BB grep "[email protected]" | $BB grep -v "$( echo $BB grep [email protected] )"
}
$CHMOD 0777 /data
#install apps on first boot
if [ -d $FBLOC ]; then
sleeperlog "Found $FBLOC"
if [ "$($LS $FBLOC)" ]; then
cd $FBLOC
$MKDIR -p $bak
for pkg in *.apk; do
log -p i -t init:firstboot "INIT.firstboot INSTALLING: $pkg"
sleeperlog "PREPARING: $pkg"
pkgname=${pkg%.*}
sleeperlog "BACKING UP APP DATA - $pkgname"
#back up data, delete the original data dir to prevent install errors (pm isn't very good at what it does)
if [ -d /data/data/$pkgname ]; then
$CP -a /data/data/$pkgname $bak/$pkgname
$RM -rf /data/data/$pkgname
fi
#WAIT, then install, then WAIT SOME MORE
$SLEEP 2
sleeperlog "INSTALLING $pkgname"
pm install -r $FBLOC/$pkg &
$SLEEP 10
#REIntegrate application data
if [ -d "$bak/$pkgname" ]; then
sleeperlog "\nSYNCING APP DATA \n\n$(/system/xbin/rsync -auv --exclude=lib $bak/$pkgname/ /data/data/$pkgname/)\n"
fi
i=$((i+1))
#Move the install .apk to tmp
if $LS /data/app | $GREP "$pkgname"; then
sleeperlog "Package appears to have installed."
$MV "$pkg" $tmp/
fi
#If the firstboot batch dir is empty, delete it now
! [ "$($LS $FBLOC)" ] && $RM -rf $FBLOC
done
#WAIT for [#ofapps x 5 seconds each] to avoid a race condition
waitsecs=$(( i * 5 ))
sleeperlog "Waiting for ${waitsecs}s before Fixing Permissions"
$SLEEP $waitsecs
sleeperlog "Fixing Permissions $(/system/xbin/fix_permissions)"
sleeperlog "Running batch zipalign \n\n $(/system/xbin/zipalign)"
sleeperlog "Clearing tmp $tmp"
fi
fi
sleeperlog "FIRSTBOOT SCRIPT COMPLETE"
log -p i -t init:firstboot "INIT.firstboot SELF DESTRUCT FIRSTBOOTSCRIPT"
if ! [ "$($LS $FBLOC)" ]; then
$MV $0 $tmp/.firstboot
# COMMENT THIS OUT FOR DEBUGGING, TO NOT REMOVE THE TMP DIR
$RM -r $tmp
echo ""
fi
echo -e "#\n#COMPLETED ON $(date)\n#" >> $0
sleeperlog "FirstBoot Apoptosis"
log -p i -t init:firstboot "INIT.firstboot END: USER SCRIPT $FBLOC.sh"
THANKS
CyanogenMod team for the Fix_permissions script
DarkyROM for the Batch Zipalign script

Saving this seat . . .

does this work with a bml rom?

^^^^In theory, it would work with an NTFS rom, if one existed - different filesystems don't [usually] create any changes on the surface... if you try to copy a file from a partition of any file system to a partition of any other file system, you don't have to explicitly tell the system the fs types involved. I haven't looked through the entire script, but if there are any commands that must specify the partition type, it would be a simple matter of changing any occurances of EXT4 to YAFFS2, etc.
This could be a great way to make a clean reinstall with all of your apps intact (minus app data, do a separate backup with your backup app of choice) - first, backup your installed apps by copying them to the appropriate directory, then do a full wipe and install, with the script automatically reinstalling your apps on first boot...
EDIT: I just looked through the script more closely. First, it appears that data is backed up. Second, I can confirm that the standard, non-file system-specific linux commands are used for file operations (cp to copy, etc), so this script shouldn't need any adjustment to accomodate different file systems
Sent from my SPH-D700 using XDA App

Is it possible for someone to develop an application to backup your personal apps and then running a script in clockwork or on first boot that does the same thing as this, alllowing for personal apps to be in the rom directly after flashing. I understand that sometimes apps may not be compatible, but can randomroms rdu script be modified to choose to do this?
Sent From My Cyan4g

Good looking script SenseiSimple!!

Okay, I'm trying to use this script, but you said to put the apps in fs/data/firstboot/ but where is "fs"? I found the "firstboot.sh" file, but I'm sure I can't put the apk's in there...
In loving memory of my son "Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 :'(

sniperkill said:
Okay, I'm trying to use this script, but you said to put the apps in fs/data/firstboot/ but where is "fs"? I found the "firstboot.sh" file, but I'm sure I can't put the apk's in there...
In loving memory of my son "Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 :'(
Click to expand...
Click to collapse
If you look at the folder structure inside the SleeperROM zip, you'll see he uses an fs directory to hold his system and data folders for installation. If you're developing a ROM, you can adapt the script to point to wherever your data folder is (most other ROMs just have system and data in the root directory of the zip, so the path would just be data/firstboot/).
EDIT: no need to look in SleeperROM zip, the firstboot zip in the OP has the same folder structure. It just doesn't seem to have the firstboot directory inside data. You'll need to add that.
Sent from my SPH-D700 using XDA App

bbelos said:
If you look at the folder structure inside the SleeperROM zip, you'll see he uses an fs directory to hold his system and data folders for installation. If you're developing a ROM, you can adapt the script to point to wherever your data folder is (most other ROMs just have system and data in the root directory of the zip, so the path would just be data/firstboot/).
EDIT: no need to look in SleeperROM zip, the firstboot zip in the OP has the same folder structure. It just doesn't seem to have the firstboot directory inside data. You'll need to add that.
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Thanks for the reply buddy, so what I THINK your saying is to create a folder called "first boot" in my data folder?
In loving memory of my son" Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 - RIP :'(

sniperkill said:
Thanks for the reply buddy, so what I THINK your saying is to create a folder called "first boot" in my data folder?
In loving memory of my son" Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 - RIP :'(
Click to expand...
Click to collapse
Are you trying to do this in a ROM or on the phone? Sorry if that's a dumb question, but I just want to be sure we're on the same page.
Sent from my SPH-D700 using XDA App

sniperkill said:
Thanks for the reply buddy, so what I THINK your saying is to create a folder called "first boot" in my data folder?
In loving memory of my son" Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 - RIP :'(
Click to expand...
Click to collapse
bbelos said:
Are you trying to do this in a ROM or on the phone? Sorry if that's a dumb question, but I just want to be sure we're on the same page.
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
i hadn't noticed my zip routine apparently skips empty .folders
in the zip, there SHOULD have been /fs/data/.firstboot into which you place whatever apk files named according to their actual package name i.e. com.keramidas.TitaniumBackup.apk for Titanium Backup, com.alensw.PicFolder.apk for QuickPic and so on...
you can find out this info in Titanium Backup by finding the app in the list and tapping its name to show the data store location.
it HAS to correspond to the actual package name in order to properly back up the data files because the package manager binary as run from a script won't overwrite the data dir so the old data has to be synced back into the new install (rsync)
I am currently refactoring the script to reduce the number of dependencies... the system will then consist of the init.d script, zipalign and rsync bins, and the /data/.firstboot.sh, /data/.firstboot dir all in one place rather than scattered throughout the system.

irule9000 said:
Is it possible for someone to develop an application to backup your personal apps and then running a script in clockwork or on first boot that does the same thing as this, alllowing for personal apps to be in the rom directly after flashing. I understand that sometimes apps may not be compatible, but can randomroms rdu script be modified to choose to do this?
Sent From My Cyan4g
Click to expand...
Click to collapse
it would be possible to create an app to do this, and i considered it because of the need to make sure the android system is fully loaded for package manager to work, but given the requirement for full root access to start running before the system is up without having to worry about android permissions or getting SuperUser approval it's easier/more effective to do it as part of the system init in a script.
as far as randomking's rdu script, they would be compatible, but they exist separately as in one shouldn't interfere with the other, because the firstboot script runs long after install once the system is up and running.
you could modify the rdu setup to include/exclude the /data/.firstboot dir and .firstboot.sh script based on the selected config, since the init script does nothing if it doesn't see the /data/.firstboot.sh file, and the .firstboot.sh script does nothing if it doesn't see the .firstboot dir

SenseiSimple said:
it would be possible to create an app to do this, and i considered it because of the need to make sure the android system is fully loaded for package manager to work, but given the requirement for full root access to start running before the system is up without having to worry about android permissions or getting SuperUser approval it's easier/more effective to do it as part of the system init in a script.
as far as randomking's rdu script, they would be compatible, but they exist separately as in one shouldn't interfere with the other, because the firstboot script runs long after install once the system is up and running.
you could modify the rdu setup to include/exclude the /data/.firstboot dir and .firstboot.sh script based on the selected config, since the init script does nothing if it doesn't see the /data/.firstboot.sh file, and the .firstboot.sh script does nothing if it doesn't see the .firstboot dir
Click to expand...
Click to collapse
Expanding on the rdu script idea, how about a prop variable in the config to specify a user apps directory on the sdcard (best if standardized)? The user can store the apks to be installed after a clean flash in this directory. The rdu script would be modified to copy those apks to the firstboot directory. Although how to handle data? Maybe another script to be run before flashing that checks the apks in the sdcard folder, and copies the current data folder to the sdcard. This data is then restored somehow with the firstboot script. This all can be in addition to the firstboot apps included with the rom.
Sent from my SPH-D700 using XDA App

app
I honestly have no developing experience. To clarify, I was I simply asking if the app could back up the users personal apps/data to the specified folders, to make this script fool proof. Then when a rom is flashed the randomromkings rdu script which currently decides on lite roms or full roms could be modified to either install apps or not install apps depending on the rom compatibility. Finally data is wiped, rom flashes, and your script runs on boot allowing the apps to all be there. Expanding on that if the ROM allows apps to be re installed via your script, through the modified rdu, your script could be moved from one directory to another allowing the process to happen and at the end moves itself back to the original directory. This means that the end user who has no clue how to do anything but flash roms (like myself, but I want to learn) has done nothing accept backing up their apps. I know this is all hypothetical, but would this be possible, and also I have another idea that is probably impossible. If a script could be written so that the apps are backed up when the rom flashes, then the rom automatically does a factory restore and wipes the various caches, meaning that less people are going to have force close issues or other avoidable bugs because they didnt wipe. thanks for all your hard work

Clear Me Here !!
You said that the script (.firstboot.sh) removes itself, but does it remove Y02firstboot script from init.d?? I don't think so, also, there are no disadvantages of this after first boot, as it won't find .firsboot.sh and skip the operation, but why shud it execute unneccesarily everytime??
@OP--Plz. tell me if i am right or wrong.......If right, plz. add a function to remove that script from init.d. However files in /xbin are OK though, so no need to remove them............

Everybody is writing and making this appear as complicated as possible! So let me clarify what I believe the idea is here. First of all, the 'RDU script' I assume you're referring to is simply a flash-able zip to set you phone for a lite or full installation. It sets a config file. I use it in my rom, and I also currently use that config file to set several other features upon installation, and changeable at anytime one of my themes is flashed.
RDU was simply meant to jump start the idea of developers making installations more uniform. Which has happened to various extents, for example, I've used this first-boot install to solve my quickpic(I love the app) and flash pre-install problems. It also fixes usb tether, vlingo, terminal, etc.
SO, what are we saying here? We'd like to be able to backup our apps to the sd card, as many apps can do for us. Then, we'd like to either:
A. Build a script into a rom to restore these apps prior to or upon installation.
or
B. Build a separate script which would be run AFTER a rom installation to restore these apps from CWM.
Yes?
P.S. I see this is very late to the game, didn't realize this thread was being revived...
Still. Neat idea, sorry I hadn't noticed it yet.

+1 Thanks
After integrating this into my custom ROM, my phone (Galaxy S 4G) would only install the first .apk file in the .firstboot directory. After I removed the code which tells it to backup/restore the /data/data directories, it worked fine. I won't need that code since the ROM does a full wipe of /data every time anyway, but I'm not sure why it doesnt work when it's there. I'm not well versed enough with Java's syntax yet to comprehend why.
Also, your first post says that it should record logs to \sdcard\sleeperlog.txt but the script tries to record it to \sdcard\sleeperromlog.txt and neither one of those files actually appear on the sd card.
Edit: I had to remove the check to make sure the .firstboot directory is empty before deleting it, but it works fine on my Galaxy S 4G ROM as long as there are no /data/data directories for the programs I am installing.

does anyone still have a template of this? The link is down.
Edit: nevermind I don't need it anymore.

[SHELL] Proper init.d and shared standard

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

[ROOT][FILESYSTEM]Full 500MB SuperSU rooted Root.fs for BlueStacks

Current rooted version: 0.8.3.3026
!!!UPDATE 07DEC13!!! -> With SuperSU v1.80!
Here are the rewritable rooted filesystem-files for BlueStacks. Easy if you want to install BlueStacks for development reasons and don't want to go through the trouble of rooting it yourself.
I'll try to keep it updated as they make their updates, but since they don't really announce them, forgive me if I skip some. :silly:
It's also allowed to point me out there's a new version, I'll probably get to it faster that way.
Anyway,
Usage:
Install BlueStacks
Quit Bluestacks completely.
- (By clicking on their tray icon and selecting Quit, or by running the HD-Quit.exe)
Go to your BlueStacks-ProgramData directory
- (In Windows Vista and up it's: x:\ProgramData\BlueStacks)
- (In Windows XP it'll be: x:\Documents and Settings\All Users\Application Data\BlueStacks)
Unpack and replace Root.fs and initrd.img with the 2 files in this 7zip
Restart BlueStacks
If "Installer" asks root access, give it root access... ;p
Done!
Code:
[URL="http://cur.lv/5atkp"][COLOR="DeepSkyBlue"][U]Download both files 7zip'd from 'ADrive' here[/U][/COLOR][/URL] (269.3MB)
Mirrors:
[URL="http://cur.lv/5atb6"][COLOR="SeaGreen"][U]Download both files 7zip'd from 'FileDropper' here[/U][/COLOR][/URL] (269.3MB)
[URL="http://cur.lv/5blid"][COLOR="DarkBlue"][U]Download both files 7zip'd from 'Dev-Host' here[/U][/COLOR][/URL] (269.3MB)
[URL="http://cur.lv/5blth"][COLOR="DarkOrchid"][U]Download both files 7zip'd from 'MediaFire' here[/U][/COLOR][/URL] (269.3MB)
[URL="http://cur.lv/5bpjr"][COLOR="Red"][U]Download both files 7zip'd from 'Android File Host' here[/U][/COLOR][/URL] (269.3MB)
---
[URL="http://bit.ly/1bP5VjD"]MD5 Checksum[/URL]: 0f199f0f353e701a7b9c535098b243b3
Please excuse me trying to get something out of the trouble, though. ;p
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Then, for the noobs that just can't get it working and the limitless downloaders who just don't look at filesize, next, I give you the full 'Android' directory! 7zipped while not running, these files are a certainty that all should work, because they come with /system and /data together and are meant to replace your own. All your own apps and settings (not your backupz to SD) will have gone after doing the following, so it's only recommended when you're planning to start anew anyway or when you just can't get the root into it for some reason... Or maybe you planned ahaed and backed everything up anyway... ;p These files are certain to give you not only SuperSU-root access, but also a Play Store ready to use and as a bonus a full Debian Linux (Jessie) installed underneath it. (This is why it's so much bigger. ;p)
A little info on the linux:
Debian's root password is set to "bluestacks", and it's also the password for the "BlueStacks" user. You can change these without any problems. You can also just enter Debian Linux by opening the installed Terminal. I already preset it to do this. I also used the none standard Terminal app so you can use the normal one for your own purpouses without constantly fiddling and swapping with it's settings. ;p
So, just kill BlueStacks completely and swap the contents of this 7z with the contents of your ProgData-BlueStacks-Android dir (except for the missing sdcard.sparsefs, of course).
It should be located here:
- For XP: x:\documents and settings\all users\application data\BlueStacks\Android
- For Vista, 7, 8,...: x:\programdata\BlueStacks\Android
(x marks the drive your windows is installed on. )
And restart BlueStacks.
Code:
[URL="http://cur.lv/5d4xj"][COLOR="DeepSkyBlue"][U]Download the BlueStacks Androdebian Project from 'ADrive' here[/U][/COLOR][/URL] (622.3MB)
[URL="http://cur.lv/5dbr7"][COLOR="SeaGreen"][U]Download the BlueStacks Androdebian Project from 'FileDropper' here[/U][/COLOR][/URL] (622.3MB)
[URL="http://cur.lv/5dct9"][COLOR="DarkBlue"][U]Download Part 1 of the BlueStacks Androdebian Project from 'Dev-Host' here[/U][/COLOR][/URL] (311.5MB)
[URL="http://cur.lv/5dcyx"][COLOR="DarkBlue"][U]Download Part 2 of the BlueStacks Androdebian Project from 'Dev-Host' here[/U][/COLOR][/URL] (310.8MB)
[URL="ttp://cur.lv/5d51y"][COLOR="DarkOrchid"][U]Download the BlueStacks Androdebian Project from 'MediaFire' here[/U][/COLOR][/URL] (622.3MB)
[URL="http://cur.lv/5dciu"][COLOR="Red"][U]Download the BlueStacks Androdebian Project from 'Android File Host' here[/U][/COLOR][/URL] (622.3MB)
---
[URL="http://bit.ly/JbVniG"]MD5 Checksum (Full File)[/URL]: 5763bf8f96d4f4990494d4bab1b2fd0b
[URL="http://bit.ly/18mVKlB"]MD5 Checksum (Part 1)[/URL]: 32ee4dc23717c2c5878dfdf125231fe1
[URL="http://bit.ly/Jg3v1H"]MD5 Checksum (Part 2)[/URL]: 7a989a027454786ab45fe4eb6d3917b7
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
And btw, if you want to try it yourself, I always write down my steps taken, so here they are:
Rooting BlueStacks as I did it:
For this you will need the following programs:
BlueStacks (of course)
IOBit Uninstaller
7zip
Notepad++
Portable Ubuntu
I used Windows XP x86, but I added the info for higher windows versions and x64 windows versions as well)
x marks the drive your windows is installed on.
Winkey-R (Run) "%programfiles%\BlueStacks\HD-Quit.exe" (or "%Programfiles(x86)%\BlueStacks\HD-Quit.exe" for x64);
Kill HD-LogRotatorService.exe in Task Manager;
I used IOBit Uninstaller because I hate waiting on the Windows internal one and it does a lot more stuff we need done.
(If you want it and haven't already, get IOBit Uninstaller here!);
Uninstall BlueStacks with IOBit Uninstaller;
Choose to scan for remaining stuff and delete all of the findings;
Uninstall BlueStacks Notification Center
When it asks to keep all data and userfiles, say no;
Delete x:\Documents and Settings\All Users\Application Data\BlueStacksSetup (or x:\ProgramData\BlueStacksSetup in Vista or higher)
('BlueStacks' dir has been removed by clicking 'yes' in uninstall, if not, remove it as well);
If you can't delete hyperviser.log, you'll have to reboot first, then delete the BlueStacks folder before you'll be able to continue.
Re-install BlueStacks
(If you haven't already, get BlueStacks here!);
Download "busybox-i686" from this site and rename it to "busybox";
Download SuperSU in flash zip format from this site.
Inside this zip is more then just SuperSU. Unzip these files to "c:\pubuntu":
(out of zipped directory "/common"
- "Superuser.apk";
- "install-recovery.sh";
- "99SuperSUDaemon";
(out of zipped directory "/x86"
- "su";
Open Superuser.apk with 7zip, extract the files "/assets/chattr.x86.png" and "/assets/supersu.x86.png to any temporary directory, rename the files to "chattr.arm.png" and "supersu.arm.png", re-insert them (by dragging them back to the still open 7zip) and replace the other 2 png-files.
(If you haven't already, get 7zip here!);
Close 7zip and save;
Open x:\Documents and Settings\All Users\Application Data\BlueStacks (or x:\ProgramData\BlueStacks in Vista or higher);
Open "initrd.img" with 7zip;
Unpack "initrd" to any temporary dir;
Open "initrd" with Notepad++
(If you haven't already, get Notepad++ here!);
Search for " ro " (including the spaces, not the quotationmarks)
There should be two results, change the first to " rw "
- Hint: It's not the one which starts with "Option: ro (read-only",
It's the one that resembles 'try_mount ro $1 /mnt && [ -e /mnt/$SRC/ramdisk.img ]'. ;P;
Save "initrd" and close Notepad++;
Drag it back into the 7zip application where "initrd.img" is still open and overwrite existing "initrd";
Close 7zip;
Then you'll need Portable Ubuntu
(If you haven't already, get Portable Ubuntu here!);
NOTE: Portable Ubuntu does not work on x64 Windows, so if you're not running an x86 Windows, you'll need to use a Linux box or vm (with shared folders) here instead.
- If you have Windows installed on any other drive than C, do the following, if it's installed in C, skip this:
- Open Ubuntu Portable folder;
- Go to the "config" subfolder;
- Edit the file "portable_ubuntu.conf";
- Under the line: "shared_folder0=c:\" add "shared_folder1=x:\" (where x is still the drive your windows is on);
- Save "portable_ubuntu.conf" and exit Notepad++;
Open Portable Ubuntu;
Open the terminal window once it's fully loaded;
Do the following in the exact order:
Code:
sudo su
(pubuntu's password is '123456')
mkdir /n
mkdir /n/rootfs
mkdir /n/sfs
mkdir /n/img
[B]- If windows was on C:[/B]
e2fsck -f -y "/media/cofs2/Documents and Settings/All Users/Application Data/BlueStacks/Android/Root.fs"
resize2fs -f "/media/cofs2/Documents and Settings/All Users/Application Data/BlueStacks/Android/Root.fs" 500M
mount -o loop "/media/cofs2/Documents and Settings/All Users/Application Data/BlueStacks/Android/Root.fs" /n/rootfs
[COLOR="Gray"](or for Vista and up:
e2fsck -f -y "/media/cofs2/ProgramData/BlueStacks/Android/Root.fs"
resize2fs -f "/media/cofs2/ProgramData/BlueStacks/Android/Root.fs" 500M
mount -o loop "/media/cofs2/ProgramData/BlueStacks/Android/Root.fs" /n/rootfs
)[/COLOR]
[B]- If not:[/B]
[I]e2fsck -f -y "/media/cofs3/Documents and Settings/All Users/Application Data/BlueStacks/Android/Root.fs"
resize2fs -f "/media/cofs3/Documents and Settings/All Users/Application Data/BlueStacks/Android/Root.fs" 500M
mount -o loop "/media/cofs3/Documents and Settings/All Users/Application Data/BlueStacks/Android/Root.fs" /n/rootfs
[COLOR="Gray"](or for Vista and up:
e2fsck -f -y "/media/cofs3/ProgramData/BlueStacks/Android/Root.fs"
resize2fs -f "/media/cofs3/ProgramData/BlueStacks/Android/Root.fs" 500M
mount -o loop "/media/cofs3/ProgramData/BlueStacks/Android/Root.fs" /n/rootfs
)[/COLOR][/I]
mount -o loop /n/rootfs/android/system.sfs /n/sfs
cp /n/sfs/system.img /n/rootfs/android
e2fsck -f -y /n/rootfs/android/system.img
resize2fs -f /n/rootfs/android/system.img 480M
umount /n/sfs
rm /n/rootfs/android/system.sfs
rmdir /n/sfs
mount -o loop /n/rootfs/android/system.img /n/img
mkdir /n/img/bin/.ext
mkdir /n/img/etc/init.d
cp "/media/cofs2/pubuntu/su" /n/img/xbin/daemonsu
cp "/media/cofs2/pubuntu/su" /n/img/xbin/su
cp "/media/cofs2/pubuntu/su" /n/img/bin/.ext/.su
cp "/media/cofs2/pubuntu/Superuser.apk" /n/img/app/SuperSU.apk
cp "/media/cofs2/pubuntu/install-recovery.sh" /n/img/etc/install-recovery.sh
cp "/media/cofs2/pubuntu/99SuperSUDaemon" /n/img/etc/init.d/99SuperSUDaemon
cp "/media/cofs2/pubuntu/busybox" /n/img/xbin
echo 1 > /n/img/etc/.installed_su_daemon
chown 0:2000 /n/img/bin/.ext
chown 0:2000 /n/img/bin/.ext/.su
chown 0:2000 /n/img/xbin/su
chown 0:2000 /n/img/xbin/daemonsu
chmod 777 /n/img/bin/.ext
chmod 6755 /n/img/bin/.ext/.su
chmod 6755 /n/img/xbin/su
chmod 6755 /n/img/xbin/daemonsu
chmod 755 /n/img/etc/install-recovery.sh
chmod 755 /n/img/etc/init.d/99SuperSUDaemon
chmod 644 /n/img/etc/.installed_su_daemon
chmod 644 /n/img/app/SuperSU.apk
umount /n/img
rmdir /n/img
chown 0:2000 /n/rootfs/android/system.img
chmod 0644 /n/rootfs/android/system.img
umount /n/rootfs
rmdir /n/rootfs
rmdir /n
exit
exit
Shutdown Portable Ubuntu;
Boot BlueStacks;
Install custom launcher like ADW, Go or Apex (Superuser app does not show up in BlueStacks' Launcher);
Install Root Explorer;
Move custom launcher from "/data/app" to "/system/app";
Reboot BlueStacks;
You can now safely remove apps like "Launcher2.apk" and "new_Home.apk" and other original launcher related stuff.
Enjoy and grtz,
~ Nephatiu

Can you explain the steps to root my version manually instead of downloading a 500mb file, if not possible then can you please provide a mirror since Adrive gives Public File Busy error all the time to me?
Thanks
Edit:
Never mind, ignore it. Got it now. Although it's better if you could provide mirrors for others as Adrive is giving problems. I had to download using a premium downloader.

nicesoni_ash said:
Can you explain the steps to root my version manually instead of downloading a 500mb file, if not possible then can you please provide a mirror since Adrive gives Public File Busy error all the time to me?
Thanks
Edit:
Never mind, ignore it. Got it now. Although it's better if you could provide mirrors for others as Adrive is giving problems. I had to download using a premium downloader.
Click to expand...
Click to collapse
Still want instructions, then?
Cause I wrote down the steps I took, so I could easily paste them here (and adapt them a little for others to read, of course. ).
Grtz,
~ Nephatiu

Sure go ahead if you already wrote them down. It will be useful since it's a separate thread then your other post where you put these download links. The only thing messing up my plans right now is to download that portable linux for 1+gb file so for now I have downloaded your files and they work great, I will make them manually next time when there will be a new bluestack update.
Thanks

Rewritable initrd.img (1.3MB)
Rooted Root.fs (500MB)
Click to expand...
Click to collapse
Don't work this url...

nicesoni_ash said:
Sure go ahead if you already wrote them down. It will be useful since it's a separate thread then your other post where you put these download links. The only thing messing up my plans right now is to download that portable linux for 1+gb file so for now I have downloaded your files and they work great, I will make them manually next time when there will be a new bluestack update.
Click to expand...
Click to collapse
Okay, I'll add it in the original post,... ;p
Grtz,
~ Nephatiu

New Version
Version 0.8.2.3018 is out.
I accepted the update & Root Checker Pro says I still have root.

SuperSU updated
SuperSU just updated a few hours ago. Problems to update the apk. Could someone please update Root.fs and initrd.img with the new superSU apk.
Thank you

0.8.2.3018 updates and root is still there except the root apk is gone as the Root.fs has been replaced.

Almighty2 said:
0.8.2.3018 updates and root is still there except the root apk is gone as the Root.fs has been replaced.
Click to expand...
Click to collapse
I'll be adding my new Root.fs here later today. Just got back from a few days trip, and first of all I need some sleep, but when I wake, I'll get right to it.
Grtz,
~ Nephatiu

Nephatiu said:
I'll be adding my new Root.fs here later today. Just got back from a few days trip, and first of all I need some sleep, but when I wake, I'll get right to it.
Grtz,
~ Nephatiu
Click to expand...
Click to collapse
If possible could the root files be compressed before theyre uploaded by any chance in .7z? it would half the download size from 500MB to around 256MB, im sure the many with sucky internet speeds would appreciate it >.<
Hope you enjoyed le trip ~

Chakkas said:
If possible could the root files be compressed before theyre uploaded by any chance in .7z? it would half the download size from 500MB to around 256MB, im sure the many with sucky internet speeds would appreciate it >.<
Hope you enjoyed le trip ~
Click to expand...
Click to collapse
Good idea. I don't know why I didn't do that in the first place...
Ah, well, I'll 7zip them and up them again,...
Grtz,
~ Nephatiu

Great!!, you update with the last version of bluestacks, but supersu.apk is still version 1.69. Could you please update with SuperSU version 1.75. This is the last one.
Thanks!!

huisterduin said:
Great!!, you update with the last version of bluestacks, but supersu.apk is still version 1.69. Could you please update with SuperSU version 1.75. This is the last one.
Click to expand...
Click to collapse
Why? What's so new about it? This one works and was already unpacked to me. (Lazyness ftw. ;p) Also, it's still the last one available on Google Play Store, since it doesn't want to update, so I'm guessing that it's probably not that much of an update. (Haven't checked though. )
And I don't see why you wouldn't be able to upgrade it yourself... Just install the new SuperSU (replace other in system/app or install in data and don't touch system/app, your choice.
I'll see what I can do next release.
Grtz,
~ Nephatiu

1.75 has actually been available on Google Play Store since November 20, 2013 and these are the changes:
What's New
- Fixed OTA survival 4.3 --> 4.4
- Fixed unresponsive tabs on 2.x devices
- Fixed white flicker when using dark theme
- Fixed issue with language resetting on some firmwares
- Fixed upgrading from CWM SU to SuperSU on 4.3+ without reboot
- Added mgyun root (vroot) uninstall procedure
- Added xxhdpi and xxxhdpi icons (if available)
- Stop touching .has_su_daemon
- Several dozen security hardening commits (mini-audit by Kevin Cernekee)
- Fixed issues with sd-ext based ROMs
- Updated language files
Except from reading the thread, 1.75 still has problems with some devices as some people have lost root trying to upgrade according to the xda thread so better wait for a stable version before replacing it. 1.69 is fine as long as swiping works across the tabs and the request for su prompt comes up as that was what people were complaining about in 1.69.
I'll test to see if 1.75 works by upgrading once I finish downloading since installing rhe apk is the easy part, it's updating the su binary that is always the problem with SuperSU.

Almighty2 said:
1.75 has actually been available on Google Play Store since November 20, 2013 and these are the changes:
Click to expand...
Click to collapse
Ok, strange, I checked yesterday on BlueStacks, right before posting my answer (to make sure). I opened Play Store on it, looked up SuperSU (had to go through the whole 1-click setup again, even ) and it said: Open and Uninstall... No update.
I'll admit I did wanted it not to be, so I had a proper excuse next to me being lazy, but I swear to you, I checked and there wasn't. Not on my BlueStacks, anyway. Haven't checked my phone, since there was no version numbering to be found in their "What's New", so I had no way to check it there without first installing it.
Almighty2 said:
- Fixed OTA survival 4.3 --> 4.4
- Fixed unresponsive tabs on 2.x devices
- Fixed white flicker when using dark theme
- Fixed issue with language resetting on some firmwares
- Fixed upgrading from CWM SU to SuperSU on 4.3+ without reboot
- Added mgyun root (vroot) uninstall procedure
- Added xxhdpi and xxxhdpi icons (if available)
- Stop touching .has_su_daemon
- Several dozen security hardening commits (mini-audit by Kevin Cernekee)
- Fixed issues with sd-ext based ROMs
- Updated language files
Click to expand...
Click to collapse
This was indeed what it said when I checked for the update on BlueStacks,... But it did not give me the Update button, just the Open button, so I expected it to have been the 1.69 release adding those stuff... (I don't really follow SuperSU, so for as far I knew, it could have been and would've easily be explained by the '.su' file and the 'otasurvival' zip in 1.69... ;p)
Almighty2 said:
Except from reading the thread, 1.75 still has problems with some devices as some people have lost root trying to upgrade according to the xda thread so better wait for a stable version before replacing it. 1.69 is fine as long as swiping works across the tabs and the request for su prompt comes up as that was what people were complaining about in 1.69.
Click to expand...
Click to collapse
Apart from the fact it didn't even want to update in my Market,...
Almighty2 said:
I'll test to see if 1.75 works by upgrading once I finish downloading since installing rhe apk is the easy part, it's updating the su binary that is always the problem with SuperSU.
Click to expand...
Click to collapse
You think SuperSU won't be able to update, when it's already the main superuser app? I understand the problems when changing with apps from other users you have no control over, but not over one's own stuff...
Why is this SuperSU app so wanted anyway? It seems to have more bugs than any other... And 99% of the time you're just going to push "Allow" anyway...
Grtz,
~ Nephatiu

The version numbering is always under the description in Google Play Store. I downloaded the Root.fs and initrd.img and just tried to update to SuperSU 1.75 and just as I had suspected, installation of the su binary failed. CWM's Superuser installs but the su binary on that one seems to be dead as it doesn't prompt and one can't even su in terminal mode with all versions released after the CWM Superuser you included in the earlier BS Root.fs.
As for SuperSU, here is the comparison and I think both CWM and SuperSU are good, it's just the original Superuser that sucks...
Superuser, the original by chainsdd, is open source, and has been used the longest. The problem is that it has been outdated and it required work to get it on 4.2
SuperSU is a closed source app from chainfire, a well known developer. Its got a ton of options and its well made. This one was made because of the issues in the original superuser app. Lots of people personally use this one.
Superuser by koush was designed to make a working superuser app, that was open source. It comes built into the settings menu of AOKP and Cyanogenmod.

Almighty2 said:
The version numbering is always under the description in Google Play Store. I downloaded the Root.fs and initrd.img and just tried to update to SuperSU 1.75 and just as I had suspected, installation of the su binary failed. CWM's Superuser installs but the su binary on that one seems to be dead as it doesn't prompt and one can't even su in terminal mode with all versions released after the CWM Superuser you included in the earlier BS Root.fs.
Click to expand...
Click to collapse
Always wondered where that info was... It somehow feels like it should have a more obvious place. And although this seems to be the official place for it, indeed, it's often mentioned in What's New too,... Anyway, I know now, and I can clearly see version 1.75, but then I wonder why I didn't get the Update button in BlueStacks? Because that's the main thing I took as evidence.
Almighty2 said:
As for SuperSU, here is the comparison and I think both CWM and SuperSU are good, it's just the original Superuser that sucks...
Superuser, the original by chainsdd, is open source, and has been used the longest. The problem is that it has been outdated and it required work to get it on 4.2
SuperSU is a closed source app from chainfire, a well known developer. Its got a ton of options and its well made. This one was made because of the issues in the original superuser app. Lots of people personally use this one.
Click to expand...
Click to collapse
Yeah, I was along with everybody else to change and change it every ROM again,... But then CM began to build in theirs (as did AOKP), and it didn't actually bother me, had the same functionality (notification per app settings and such...) and has a much nice clear popup, imho, where as SuperSU has that small white one which still looks Gingerbreadlike. ;p So, again, in my eyes as I did before, I moved on. Some people tend to get stuck with their first change, they never change again, that's why I ask why SuperSU would be better, if it's such a mess even updating it... ;p As I remember CWM's su updated just fine, even on BlueStacks... Dunno if it could handle SuperSu, though, but if it didn't I'd expect it to be more SuperSU's fault than CMWsu's. ;p
Almighty2 said:
Superuser by koush was designed to make a working superuser app, that was open source. It comes built into the settings menu of AOKP and Cyanogenmod.
Click to expand...
Click to collapse
And a good job they did, imho. ;p
Grtz,
~ Nephatiu

My problem is SuperSU is nice but the SU binary isen't istalled. I keep getting no root privilages error. am i doing something wrong?
For me in a sence its not really rooted it just has a superuser app installed which isen't rooted.

CptKlink said:
My problem is SuperSU is nice but the SU binary isen't istalled. I keep getting no root privilages error. am i doing something wrong?
For me in a sence its not really rooted it just has a superuser app installed which isen't rooted.
Click to expand...
Click to collapse
And you are using my Root.fs ánd my initrd.img? Because they work fine here, though, and from recent reply's I think I can confirm more people having it working. :/ Try uninstalling BlueStacks completely, removing everything (like in the beginning of my tutorial for rooting BS in the OP), rebooting, and reinstalling BS with a clean slate. All su binaries and the sudaemon should be pre-installed on it. :/ I forgot to make a symlink to /system/bin this time, but apparently it wasn't needed and the /system/xbin/su should do. This can be done later (with root of course) by going to /system/bin with the android terminal and typing:
Code:
su
ln -s ../xbin/su
Oh, right, and do check if SuperSU doesn't get updated automatically by your Play Store or anything. It should stay v1.69, because it fails at updating it's own su binaries for some reason...
Can anyone else confirm the last release has working root, though, just to be sure? Because they could always have changed something to make rooting harder, disabling the 'just replace Root.fs' possibility with some build in checker. I highly doubt that's the case, though.
Anyway, keep me updated. ;p
Grtz,
~ Nephatiu