Related
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.
Hi Folks,
By request from a friend i've created a sh script to move all [email protected] dalvik cache files to /cache/dalvik-cache because some roms store [email protected] dalvik files in /data/dalvik-cache. So for those that need or wont to save some space in /system follow this steps:
1 - You need a rooted phone
2 - You need terminal emulator
3 - Download script from here
4 - Open terminal, navigate to where you downloaded the script and run sh dalvik.sh
5 - Reboot
!!Warning!!
Only run script in roms that store [email protected] dalvik files in /data/dalvik-cache otherwise you will experience some bugs in aplications.
Please post your feedback please
Thanks to HeD_pE for testing!
Cheers,
h4ck3dm1nd
DISCLAIMER: I am not the author of this tool!
All credits goes to tommytomatoe and you can press thanks in this thread because there is no dedicated thread for DEXO @xda (at least I found none)
theking_13 said:
thiagomme said:
Why does it give better battery life? Thank you.
Click to expand...
Click to collapse
Because it splits the .apk (app package) into two parts, the .apk and a .odex file. Usually, for the phone to use an app, it has to decompile the .apk and get the parts it needs to run the app. With the odex files, which stands for "Optimized Dex" the startup time is much faster since the phone doesn't have to perform any optimizing at startup/runtime, and because of that, it also uses less CPU power, and thus makes it faster, smoother, and battery life is increased.
Click to expand...
Click to collapse
OK. So what is this tool?
This tool doesn’t deal with partially odexed ROMs. This tool is for odexing a ROM that is completely DEODEX.
The benefits? Faster boot, smaller imprint on /data/ partition, overall faster feeling
The myths? I can’t theme ODEX! WRONG! You can theme odex just fine! Just use baksmali and smali.
Click to expand...
Click to collapse
Requirements:Of the author:
adb
Linux, Mac OS X, Windows
Android device with busybox
Four minutes of your day
Added by me:
You have finally settled on a ROM that you want to use for some time without an intention to modify it further
You will need about 100 MB free space on system (my free space decreased from 160 MB to 96 MB after the completion of the process) To free some you can delete some apps from /system/app or move them to /data/app with a root file explorer (do not forget to set the correct permissions afterwards) or even better: to move your /system/lib folder to the lib partition without reflashing the ROM (see below for details)
Tested on Fallout 5.0 and Virtuous Infinity 1.35 with my Tweaked3 8.6 kernel. If you are using this it is at your own will and risk
NOT WORKING on CoolDroid and Sabsa Prime 6.5, probably because they have mixed framework from different Sense versions! Do not do on other similar ROMs only on ones with an original (even modded) framework!
Procedure:Go here and read carefully. It is basically some adb commands.
Out of respect to the author I will not mirror his link nor the instructions----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------How to free about 120 MB space on /system by moving the lib folder to its dedicated partition without reflashing the ROM
This is only for ICS Sense ROMs. AOSP ROMs have enough free space to run the script without issues. I am not sure about the GB Sense ROMs, but if I remember correct they have enough free space on /system too. (if I am wrong please PM me to add GB Sense boot.img)
Requirements:
Bootloader with /system/lib support: 2.xx or 7.xx
150 MB free space on your SDcard
adb drivers installed (link in my signature)
4EXT Recovery (or any other recovery that has a menu entry for mounting /system/lib partition)
good attention while copy/paste the commands from here. One typo will lead to a bootloop
Download Tweaked3: XI_lib_bootimg.zip
md5sum: 1bc1d645b8212cdb2e4e949c6b7b3312
Download Patched: 3089_lib_bootimg.zip
md5sum: f1ae0228eb4057b4e4c4934a1e8a0515The zips contain boot images of my Tweaked3 and Patched kernels with /system/lib support (I am not advertising them but this are the files I have ready, you can use a Stock kernel as well). There are 4 of them:
Sense4_lib_boot.img - for ALL Sense 4 ROMs (except VIrtuous Infinity)
Sense36_exp_lib_boot.img - for custom Sense 3.6 ROMs with experimental WiFi driver (Experimental kernel)
Sense36_lib_boot.img - for custom Sense 3.6 ROMs with stock WiFi driver (Stable kernel)
Virtuous_lib_boot.img - the name speaks for itself
Extract the archive in the folder where your fastboot executable is. This is not a flashable zip!orDownload 2: b2b_lib_bootimg.zip
md5sum: 4bb4d44506eae5f247b69f9c5663e3a8The zip contains boot images of my B2B kernel with /system/lib support (I am not advertising it but this are the files I have ready, you can use a Stock kernel as well). There are 2 of them:
Sense4_lib_boot.img - for ALL Sense 4 ROMs (except VIrtuous Infinity)
Sense36_lib_boot.img - for custom Sense 3.6 ROMs
Extract the archive in the folder where your fastboot executable is. This is not a flashable zip!NOTE: your ROM has to be on the same version of the kernel before the procedure, otherwise your WiFi will stop working. Or you will need to download the zip from the kernel thread and copy the modules to /system/lib/modules manually giving them right permissions (644 or -rw-r--r--)Procedure:# Connect the device to PC, open Command Prompt (cmd) and browse to the folder where are your adb and fastboot executables are (example: cd C:\android-tools)
# Reboot to Recovery (4EXT recommended)
Code:
adb reboot recovery
# Make a Nandroid backup
# Mount manually /system and /sdcard from the "mounts | storage" menu of the Recovery
# Copy the content of /system/lib to the SDcard
Code:
adb shell
mkdir /sdcard/system
cp -r /system/lib /sdcard/system
# Clean /system/lib
Code:
rm -r /system/lib
# Recreate empty /system/lib and set permissions
Code:
mkdir /system/lib
chmod 755 /system/lib
# Unmount manually /system from the "mounts | storage" menu of the Recovery
# Mount manually /system_lib from the "mounts | storage" menu of the Recovery
# Copy the lib contents to /system/lib
Code:
cp -r /sdcard/system/lib/* /system_lib
# Set permissions to /system/lib
Code:
cd /system_lib
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
[I]# Creating symlinks [COLOR=Red]Only for Virtuous Infinity![/COLOR][/I]
ln -s libhtc_ril.so librilswitch.so
cd hw
ln -s copybit.msm8660.so copybit.msm7x30.so
ln -s gralloc.msm8660.so gralloc.msm7x30.so
ln -s lights.msm8660.so lights.msm7x30.so
# Remove the SDcard /system/lib folder
Code:
rm -r /sdcard/system
exit
# Unmount manually /system_lib and /sdcard from the "mounts | storage" menu of the Recovery
# Reboot to bootloader
Code:
adb reboot bootloader
# Flash the boot.img and reboot
Code:
fastboot erase boot
fastboot flash boot XXX_lib_boot.img
fastboot reboot
Now you can use the tool above without concerns about free space
Enjoy!
amidabuddha, thanks for sharing. Have you tried this?
old.splatterhand said:
amidabuddha, thanks for sharing. Have you tried this?
Click to expand...
Click to collapse
Yes of course. Read the Requirements part
Sent from my HTC Desire S
Ok, i need help, cause i don't do this things often:
Fifth step, run it!
Click to expand...
Click to collapse
What and how?
old.splatterhand said:
Ok, i need help, cause i don't do this things often:
What and how?
Click to expand...
Click to collapse
Read further in the instructions, Theres a complete usage example with all the commands
Sent from my Desire S using xda app-developers app
Gonna try it today on CM10.
Tapatalked from Desire S running Andromadus
teadrinker said:
Read further in the instructions, Theres a complete usage example with all the commands
Click to expand...
Click to collapse
Sorry, my fault! I thought this come after the 5 steps.
if a rom is zipaligned, doesn't this mean that there's no need being odexed - kind of same thing? (same performance, battery life...)
i've read that, but i'm no expert...
toxic-hero said:
if a rom is zipaligned, doesn't this mean that there's no need being odexed - kind of same thing? (same performance, battery life...)
Click to expand...
Click to collapse
Zipaligning is about better RAM utilization. Odexing is about reducing the Dalvik VM which in theory should reduce CPU use and make the system run smoothly. You can watch the video, it is made by one of the Elite Recognized Developers of XDA so this guy probably knows what he is talking about. Moreover ALL Stock ROMs are odexed and I am sure that the companies developers are not just too lame to use it for nothing
tried the above...pasted something wrong and now phone stuck on htc screen and can't get into recovery
mackhenri said:
tried the above...pasted something wrong and now phone stuck on htc screen and can't get into recovery
Click to expand...
Click to collapse
Have you provided enough free space on your system partition? Try with a factory reset.
And once again:
If you are using this it is at your own will and risk
Click to expand...
Click to collapse
i think it was due to less space but still will try it once again after making space
Was a hard task to get enough space free.
Let's see how it works now.
old.splatterhand said:
Was a hard task to get enough space free.
Let's see how it works now.
Click to expand...
Click to collapse
Yes this may be an issue with the bigger ROMs. The easiest way is to move some app that you use rarely to /data/apps
The other way is to use the lib partition but this needs ramdisk modification and a hboot that supports it. It is not hard I may add a small how-to if more users want to use this tool
Sent from my HTC Desire S
amidabuddha said:
Yes this may be an issue with the bigger ROMs. The easiest way is to move some app that you use rarely to /data/apps
The other way is to use the lib partition but this needs ramdisk modification and a hboot that supports it. It is not hard I may add a small how-to if more users want to use this tool
Sent from my HTC Desire S
Click to expand...
Click to collapse
Get it on buddy.....I am ready to try whatever u make as you seem to give life to my phone once again and all the devs here and I am become a flashaholic...
Sent from my HTC Desire S using xda premium
amidabuddha said:
The other way is to use the lib partition but this needs ramdisk modification and a hboot that supports it. It is not hard I may add a small how-to if more users want to use this tool
Click to expand...
Click to collapse
This would b great, I did it once for Fallout with one of your kernel ramdisks, but it was not so trivial and a pain in the a** doing this all by hand. Though it worked perfectly, I don't remember every step I did, and mayb I didn't do it the elegant way, as I'm not very experienced.
As far as I remember the complicated part was unpacking kernel+ramdisk, modifing ramdisk, repacking everything and signing it. But this has to be done only once (by one idividual) for every kernel (+ramdisk). The rest ist more or less flashing and copying from /system to /system/lib partition (can be done in recovery easily). The latter mayb realised with one single script installer for every kernel (and rom) I guess. But here I also lack the experince with script installers, elsewise I would have shared the info.
I did it on Windows with bootimg-tools via Cygwin (unpacking, repacking), with SignApk on cmd (signing), in recovery (flashing, copying). For flashing I guess fastboot is more elegant (reflashed whole rom with mod boot.img). For the rest I didn't found something more convinient, but maybe soemone can enlighten me.
HOW-TO move your /system/lib folder to the dedicated partition added to the first post. Tested and verified working. Just copy the commands carefully
Enjoy!
Thx, the new guide worked like a charm for me on Fallout v5.0.0 with your kernel v8.5. I think it is more or less what I did, when it worked for me before. Also the odexing stuff worked well. What I am just wondering about, as this is odexing Rosie, will this affect the Fallout Tweaks for Rosie? And I tended to use Titanium Backup to merge updated system apps (like Facebook) into rom (essentially moving to system I guess), are there any drawbacks doing it with odexed apps?
kwisatz79 said:
Thx, the new guide worked like a charm for me on Fallout v5.0.0 with your kernel v8.5. I think it is more or less what I did, when it worked for me before. Also the odexing stuff worked well. What I am just wondering about, as this is odexing Rosie, will this affect the Fallout Tweaks for Rosie? And I tended to use Titanium Backup to merge updated system apps (like Facebook) into rom (essentially moving to system I guess), are there any drawbacks doing it with odexed apps?
Click to expand...
Click to collapse
All apps will work the same way after odexing. I can confirm all Rosie tweaks in Fallout working.
As per the Titanium stuff I have no idea try it and let us know
Sent from my HTC Desire S
when I am trying to copy /sdcard/system/lib to /system_lib it is showing not enough space....
Also in 4extrecovery - two system_lib are showing...
Any ideas?
BTW I am on Fallout 5.0...
So after a mix and match party, I got init.d to work on Stock ICS , and cwm on every boot just like the old days.
Here's how to set it up:
Make a backup before you do anything, people often overlook this step lol. Better to have one and not need it, then need it and not have one.
DON'T try to use this with BootMenu Manager, this is the CWM at every boot setup. If you want to use BootMenu Manager, then some of this will need to be tweaked. So, uninstall BBM if you have it before you try this.
1 - Install Busybox, more importantly, make sure run-parts is in /system/xbin
if using Jrummy's installer, make sure you use advanced install. I installed v1.20.2, it works fine.
2 - Copy the two zips and powerboost script and 00test script to your SDcard. Move the powerboost script to /system/xbin and make it executable.
Code:
adb shell
su
mount -o rw,remount /dev/block/mtdblock3 /system
chmod 755 /system/xbin/powerboost
Unzip the Unthrottle.zip to the root of your SDcard. (If you have one present already, delete it.)
3 - Install Atrix2Bootsrap, bootstrap the recovery, then boot into recovery.
4 - Flash the stockinit_Mod.zip and reboot.
5 - Open superuser, deny permission to Atrix2Bootstrap, then go and uninstall the app.
6- Run the powerboost script
Code:
adb shell
su
powerboost
Press N to not install busybox (you already have it, and it's more updated anyways).
Press 5 next to install CWM on every boot, Y to confirm
Press 8 last to reboot, Y to confirm.
That's it, old school CWM on every boot like rdavisct setup originally back on GB.
To test init.d support, after the reboot, copy the 00test script to /system/etc/init.d/ and reboot.
After the reboot, navigate to /data and look for Test.log and read it. It should have a confirmation and a timestamp showing that init.d is working.
I take no credit for developing any of this, I just made it work for Stock ICS. I pulled all of the info I needed from these two threads, and the respective owner/s deserve all the credit. I think now I might try to make a reboot option for the power menu and try to get a proper reboot and a CWM recovery reboot. Try and not have a boot into CWM at every boot, just when you want to. I know none of this is new or exciting, but as we all seen, it doesn't just happen for Stock ICS.
Sources:
http://forum.xda-developers.com/showthread.php?t=1294009
http://forum.xda-developers.com/showthread.php?t=1606257
Nice work and thank you.
Sent from my SAMSUNG-SGH-I997 using xda premium
Yes, Init.d and CWM on every boot!!! Thank you for this great detailed guide.
Sent from my A2
Amazing job man! Thank you, making me stick with stock for AWHILE now lol!
Sent from my MB865 using xda premium
Makes me think of jumping off bmm ship, but we will see. This is what I was looking for anyway. Great job.
Sent from my MB865 using xda premium
Works flawlessly...
BTW. Do I need to keep the powerboost script and unthrottle files or can safely delete them after the install?
duchski said:
Works flawlessly...
BTW. Do I need to keep the powerboost script and unthrottle files or can safely delete them after the install?
Click to expand...
Click to collapse
You may delete the unthrottle folder and powerboost script if you like.
unable to copy script to system/xbin
I want to get this on my atrix 2. I am stuck in intial stage of copying powerboost script to the sys/xbin folder it gives error "not enough space" what to do
DISCLAIMER
This project may brick you phone. Use at your own risk.
What's New in v3
I don't quiet understand SELinux, so the v2 did not process SELinux contexts while restoring "system", "data" and "cache" partitions. Now v3 fix it. If you'd ever restored them by v2, run v3 sub-menu "Tools"->"Restore SELinux security contexts" to fix it.
Add backup boot.img and "sdcard/Android/data".
Add "Wipe Dalvik cache".
Add functionality to fix common boot-loop problems including "Switch runtime to Dalvik from Art", "Disable Xposed", and "Fix build.prop permission".
What's New in v2
The major functionality added from v1 is to support nandroid backup/restore for "system", "data" and "cache" partitions to/from internal sdcard by using the supplied "ea-menu" shell script.
The "ea-menu" also support partition management such as mount, unmout, ro and rw.
Background
This is a project for developers who need a quick fixing and nandroid backup/restore environment for LG-D838 that still cannot install custom recovery currently. If you want to test, hack or modify system apks and/or Xposed modules but are afraid of bricking, you may try this project. Without this project, although you can recover the phone by flashing official firmware, reconstructing user settings and data is time-consuming. Normal ADB might be a solution for fixing, but you may not have enough time to fix problems before system hang up or goes into boot loop. And normal ADB cannot do nandroid backup/restore.
The Early-ADB sits in the early stage of Linux init process, right after "/system" mounted, far before Android stuffs starting. This way keeps the Early-ADB alive even if the Android stuffs such as apks or jars crash. Therefore, you can fix problems of Android stuffs by ADB through PC console.
The newly added backup/restore functions make it easier to backup and restore /system, /data and /cache partition with archive format compatible with CWM recovery.
More Information
See post #2 for more background information. And welcome to provide any technical information for FURTHER DEVELOPMENT section in post #2.
How It Works
The project hijacks e2fsck to interrupt Linux init process and redirect to its custom ADB daemon, the Early-ADB, so that you can access ADB by PC console in the early stage if required. The hijack concept comes from 2nd-init and Safestrap. While installing this project, the installer backup original e2fsck and replace it with a script. On each boot up, this script determine to go for original e2fsck as normal boot or go for Early-ADB by checking the Volume-Up key.
Basic Q&A
See post #3 for basic Q&A.
Installation
Make sure you have backup your user data. Make sure your D838 is rooted. Make sure you have turned on USB Debugging option in your D838.
Prepare Windows ADB utility. Currently the Early-ADB installer script is only for Windows command prompt.
Download "EarlyADB.v1.zip" in the download link below, and extract it into the Windows ADB folder. Please do not process the extracted "packs.zip". Keep it unchange.
Connect the D838 phone to your Windows PC through USB cable.
In your Windows PC, open a command prompt and "cd" to your ADB directory. Type "install" to run the Early-ADB installer.
Uninstallation
Walk through the same steps as above Installation 1 to 4.
In your Windows PC, open a command prompt and "cd" to your ADB directory. Type "unins" to run the Early-ADB uninstaller.
How To Use
Power on or reboot your D838.
When you see LG logo, press and hold Volume-Up key. After seeing the screen dims obviously, you can release the Volume-Up key. Now early-ADB daemon is running and Linux init is hold.
Connect D838 to any PC with adb through USB cable.
By using adb shell, run "ea-menu" to backup/restore to/fram internal sdcard, or fix problems manually.
To leave Early-ADB daemon, press and hold power button for at least 8 seconds to reboot the phone.
The internal sdcard is not a safe place for nandroid backup files. Remember to copy them to external sdcard.
Limitations And Known Issues
Only "/system", "/data" and "/cache" are mounted. Manually mount other partitions if required.
The Early-ADB daemon sits in early init stage that many services are not ready to use and some normal adb functionalities cannot work. For examples, you cannot reboot by software commands. You cannot get model name from getprop command. However, you can "push" and "pull" files and access "/system" and "/data" to fix many crash problems.
Don't expect this project as a brick protection. If you destory bootloader, this project can do nothing.
Don't do OTA upgrade. Any system files modification may (or may not, it depends) result in brick.
The Google Music media files are prevented from backup by Early-ADB. Backup them by yourself, otherwise if you recover data partition, you will lose them.
Download
v3: EarlyADB.v3.zip
v2: EarlyADB.v2.zip, obstacle due to SELinux problem. Download it only for research purpose.
v1: EarlyADB.v1.zip, mirror
eladbd daemon source: eladb_mod.zip, modified from https://source.android.com/source/downloading.html branch android-4.4.2_r2, only modified part is included in the zip.
Changelog
v3 (2014/05/21)
BUGFIX: Restore SELinux security contexts if restoring /system, /data or /cache partition.
Add backup/restore kernel (boot.img)
Add backup/restore /sdcard/Android/data contents
Add Tools sub-menu to "Wipe Dalvik cache".
In Tools sub-menu, add fix to common boot-loop problems including "Switch runtime to Dalvik from Art", "Disable Xposed" and "Fix build.prop permission".
In Tools sub-menu, add fix to v2 bug "Restore SELinux security contexts".
Reduce package size by minimizing installer busybox.
Auto mount partitions for backup/restore operations.
Ask user to confirm restore operation.
v2 (2014/05/18)
Run early then v1, right after /system mounted.
Default mount system, data and cache partitions.
Add "ea-menu" to run from adb shell, so you can do nandroid backup/restore for system, data and cache partitions.
Introduce new "SAFE" mount concept by mounting partitions in non-standard /mnt/system, /mnt/data, and /mnt/cache to prevent from accessing accidentally by other unknown background services while restoring.
Build busybox from source code 1.22.1 (source available from http://www.busybox.net)
Build pigz 2.3.1 for using by nandroid backup/restore (source available from http://zlib.net/pigz/)
Build static verion of mksh, so that in SAFE mount we don't have to rely on system partition for shell. (source available from https://source.android.com/source/downloading.html branch android-4.4.2_r2 )
v1 (2014/05/11)
Initial testing release
Thanks
Savoca of directing me to Safestrap and 2nd-init concepts
Hashcode with Safestrap project for concept of hijacking e2fsck
XDA:DevDB Information
Early-ADB, Tool/Utility for the LG G Pro 2
Contributors
pcfree
Version Information
Status: Testing
Created 2014-05-11
Last Updated 2014-05-21
Somthing about this project
HISTORY FOR DEVELOPING THIS PROJECT
After hacking the TOT file format to root D838 with ioroot (see my post [Tutorial] How to root D838 that cannot enter recovery mode), I start thinking of customizing my phone. Without custom recovery, it make me uncomfortable to hack system apks or try out Xposed. This leads to my first attempt.
1st Attempt -- Porting Loki-Friendly aboot.img
Initially, I want to port loki-friendly D802 JellyBean aboot.img to D838. If it successes, we would have custom recovery, custom kernel and custom ROM. Choosing D802 is because they use the same QualComm S800 chip and both com from LG. I studied the bootloader chain and tried to make lokified stock kernel with the help from xda Recognized Developer Savoca. I found the possibly best solution would be install D802 JB aboot.img and laf.img into D838 with a lokified custom-made rebuilt D838 stock kernel. However, I cannot make sure if my phone will survive from brick if the testing is failed.
If D838 KK sbl1.img (1st secondary bootloader) cannot accept D802 JB aboot.img, the phone will enter bulk device mode which can be recovered from brick in Linux PC. On the other hand, if D802 aboot.img is accepted to run but hang up due to other issues, the thing becomes more complicated. My D838 is for my daily work use. Without a backup phone, I am not ready to try the concept. The project is not dead yet, but pending now.
2nd Attempt -- 2ndrec
Savoca also direct me to Safestrap project. As new to Android dev, it is complex for me to port such a job. However, I think it may be possible to run a recovery environment by 2nd-init. Some attemptions were made to port D802 ramdisk of cwm recovery by 2nd-init without success, then I try to study my own "2ndrec" without 2nd-init. I want to make a modified recovery-like program to be injected into Linux init process. Without understanding of displaying things to the framebuffer, I pending this project too.
3rd Attempt -- Early-ADB
As eager to have a fix/recovery environment, I start to focus on adbd (adb daemon). I've found it is much easier to run adbd if I can prepare the basic environment for it and rebuild a custom adbd without unnecessary check. And this the project here.
FURTHER DEVELOPMENTS
You are welcome to provide information for the following subjects
Manually Mount Internal SDCARD
In normal environment (means non-Early-ADB), internal sdcard is a virtual device which is mapped by fuse from "/data/media/0" directory. I don't know if it is a good idea, but you may do the following commands to link it by yourself in adb shell for Early-ADB.
mount -o remount,rw rootfs
rm /sdcard
ln -s /data/media/0 /sdcard
The side effect for the soft link method is all files/dirs created would be root owned. This is different from uid 1023 (media_rw) created by fuse. However, this may not be a problem because in noraml environment fuse oversides all permissions. It means after reboot you can still get full access of all files on fuse mapped virtual sdcard.
Starting from Early-ADB v2, it is not recommanded to link sdcard because SAFE mount makes the internal sdcard path vary.
If you want to do thing such as manually backup "/data" contents to "/sdcard", remember to exclude "/data/media/0" because "/sdcard " is linked to "/data" contents. This is not a problem for "ea-menu" script because it automatically excludes virtual internal sdcard.
Manually Mount External SDCARD
You are welcome to provide information on how to manually mount D838 external sdcard. I know the exact block device of external sdcard is "/dev/block/mmcblk1p1". However, direct mount command does not succeed for my exfat sdcard. If we can mount external sdcard, we can do thing much more for Early-ADB. For example, we can backup and restore "/system" and "/data" partition as custom recovery does. For newer un-rootable stock firmware, you may build custom stock system.img by injecting "su" and "Early-ADB" first, then install it by this project.
Basic Q&A
Can I use Early-ADB to install apks or run adb backup/restore command?
Better not to try. I have not tried it yet. However, many system services do not start up yet. You will probably fail to do these works.
Can I use adb push/pull command to exchange files?
Yes.
Is the Early-ADB daemon rooted?
Yes, the Early-ADB daemon runs as root. After installed, it does not rely on "su" binary. Even if your "su" is deleted suddently, you can use Early-ADB to push it back.
Can I do OTA update after installing Early-ADB?
No, never try it. It depends on OTA update script and update contents, but you never know. Any "/system" partition modification may cause OTA fail if the modified files are in the OTA update list. However, currently we cannot modify bootloader stacks, usually we can flash stock firmware to recover from OTA fail.
By using Early-ADB, you have many ways to manually upgrade stock firmware while keeping root. Since Early-ADB v2, a custom nandroid compatible stock firmware files is also a solution.
May I use the Early-ADB for F350 series G Pro 2?
Some parameters are reterieved from D838. It may or may not works with F350 series. Try at your own risk. Use "install -f" and "unins -f" instead in the last step of installation and uninstallation procedures.
How to use "ea-menu" shell script?
Use "adb shell" to connect to your phone in Early-ADB mode. Then type "ea-menu" to run it. It is a menu-driven script and not too hard to learn how to use it.
Why is the internal sdcard not a safe place to keep nandroid backup files?
The internal sdcard is a fuse device located on data partition. If you do factory reset, you will lose these backup files too. Keep them on external sdcard or other place for safety.
good post, thanks
Early-ADB now upgrades to v2. Now you can use it to do nandroid backup and restore for "system", "data", and "cache" partitions to/from internal sdcard. Thus it may be more useful than just fixing.
With the backup/restore function, you may also safely upgrade to future stock firmware by making custom nandroid archive files from stock firmware while keeping root and Early-ADB.
Release v3. This release includes one bugfix and several improvements:
BUGFIX: In v2, while restoring "system", "data" or "cache" partitions, SELinux security contexts are not processed. Now v3 fix it. If you've ever used v2 to restore partitions, you'd better use v3 new Tools sub-menu => "Restore SELinux security contexts" to fix it. The backup archive files created by v2 are still ok, but you have to use v3 to restore them.
IMPROVEMENTS:
Add backup/restore kernel (boot.img)
Add backup/restore /sdcard/Android/data contents
Add "Wipe Dalvik cache" in Tools sub-menu.
In Tools sub-menu, add fix to common boot-loop problems including "Switch runtime to Dalvik from Art", "Disable Xposed" and "Fix build.prop permission".
Reduce package size by minimizing installer busybox (rebuild).
Auto mount partitions required for backup/restore operations.
Ask user to confirm restore operation.
Hello, so can this make a FULL backup? And a full restore? Essentially using your pc as the recovery?
How to Uninstall Early ADB?
Please help me uninstall EarlyADB so that I can boot into CWM Philz Touch Recovery.
SOLVED
Thanks.!
glasseffects said:
Please help me uninstall EarlyADB so that I can boot into CWM Philz Touch Recovery.
SOLVED
Thanks.!
Click to expand...
Click to collapse
@glasseffects, please, write how you solved your problem?
--==||==--
WySwiftKey'owane i wyTapatalk'owane z mojego LG G Pro Drugiego Wspaniałego.
--==--
Swiftkeyed and Taptalked from my Great LG G Pro The Second
==
TomeG2kc aka Tomasz G.
TomeG2kc said:
@glasseffects, please, write how you solved your problem?
Click to expand...
Click to collapse
That's fairly simple. Follow the post-installation steps to enter the Early-ADB as described in the first post:
1. Power on or reboot your D838.
2. When you see LG logo, press and hold Volume-Up key. After seeing the screen dims obviously, you can release the Volume-Up key. Now early-ADB daemon is running and Linux init is hold.
3. Connect D838 to any PC with adb through USB cable.
Now from the same folder from which you installed Early-ADB, run "unins.bat".
That's it, the Early-ADB system is uninstalled.
Hope this helps.