[DEV][SCRIPT] First-Boot App Install

Search This thread

SenseiSimple

Senior Member
Jun 17, 2008
340
543
Austin, TX
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 "$@" | $BB grep -v "$( echo $BB grep $@ )"
}

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 "$@" | $BB grep -v "$( echo $BB grep $@ )"
}

$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
 
Last edited:
D

Deleted member 2831641

Guest
does this work with a bml rom?
 
Last edited by a moderator:

styles420

Senior Member
Nov 12, 2010
2,379
1,390
Samsung Galaxy S21
^^^^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
 
Last edited:
  • Like
Reactions: SenseiSimple

irule9000

Senior Member
Dec 5, 2010
222
56
Boston, MA
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
 

sniperkill

Senior Member
Sep 27, 2010
1,648
320
Maryland
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 :'(
 

bbelos

Inactive Recognized Developer
Apr 23, 2011
923
2,780
Chicago
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 :'(

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
 
Last edited:
  • Like
Reactions: SenseiSimple

sniperkill

Senior Member
Sep 27, 2010
1,648
320
Maryland
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

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 :'(
 

bbelos

Inactive Recognized Developer
Apr 23, 2011
923
2,780
Chicago
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 :'(

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
 

SenseiSimple

Senior Member
Jun 17, 2008
340
543
Austin, TX
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 :'(

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

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.
 

SenseiSimple

Senior Member
Jun 17, 2008
340
543
Austin, TX
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

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
 

bbelos

Inactive Recognized Developer
Apr 23, 2011
923
2,780
Chicago
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

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
 

irule9000

Senior Member
Dec 5, 2010
222
56
Boston, MA
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
 

aayushARM

Senior Member
Apr 24, 2011
312
50
Ahmedabad
Clear Me Here !!:D:D

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............
 

RandomKing

Retired Recognized Developer
Mar 4, 2011
1,487
1,461
Random Land
randomkings.wordpress.com
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.
 
Last edited:
  • Like
Reactions: aayushARM

NuVanDibe

Member
May 28, 2009
15
1
+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.
 
Last edited:

ANDROID2468

Senior Member
Oct 19, 2016
375
143
Nashville
does anyone still have a template of this? The link is down.
Edit: nevermind I don't need it anymore.
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 12
    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 "$@" | $BB grep -v "$( echo $BB grep $@ )"
    }
    
    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 "$@" | $BB grep -v "$( echo $BB grep $@ )"
    }
    
    $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
    3
    Saving this seat . . .
    1
    ^^^^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
    1
    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 :'(

    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
    1
    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.