Related
I've followed this guide from loccy, except for the last part where he uses vi editor in order to edit the apps2sd script...
http://forum.xda-developers.com/showpost.php?p=4353332&postcount=68
also when i install a fresh ROM, the app-private directory does not exist to begin with since i don't have any purchased .apk's installed in the /system/sd folder, so i basically just skipped all the steps for modifying the app-private folder... i did however create the proper folders in the /data folder for app-private and followed the corresponding commands... when i try to cp the file information from the SD to /data/app-private folder, i get a no such file or directory exists error, which i'm assuming happens because i have no private apps... i don't know if this is causing my problem, if so please let me know...
since I could never get VI editor to work properly in a windows command prompt, i adb pull the a2sd file from /system/bin and edited the file using notepad++, and adb push the file back... i verified that the file was pushed correctly and edited correctly by pulling it back again and verifying the changes were correctly made... i'm assuming not being able to use VI editor is probably whats causing my problems as i'm running windows 7 RTM, and notepad++ is possibly changing the file structure of the a2sd when i edit it on my machine...
i assumed busybox was installed cause if i run an invalid vi command, i get busybox reference information from the shell returned to me... i even went as far as installing my own instance of busybox to see if that would fix my VI editor problem, but that didn't help either... when i type #VI a2sd to edit the a2sd script file, i only get a partial amount of the actual script, some of it which comes out garbled, and i can't do anything, not press esc, not type an exit/reboot command, press j or k to move up and down... i can however type :q to exit the VI editor instance...
after pushing the a2sd script file after editing it with notepad++, my phone gets stuck on the first splash screen... unforutunately, i don't have a log i can provide to you guys, cause when i run adb logcat when the phone is booting, it just stays at waiting for device...
any help would be appreciated... if possible i would like to get this sorted out so maybe a script can be written for those who want to disable apps2sd like me...
Would be great if someone could upload a modified a2sd file with app2sd disabled, then we only put this file in update.zip file, sing it, and then make a fresh flash... Thats correct? or we need to change the update.zip structure?
ATM i am not at home then i can't try to use VI, but i sure that someone can upload the a2sd file modified
yah... after i finished writing my original post, i tried using VI again and noticed in the header of the a2sd script on jacherorom 1.4 that the a2sd script was written by cyanogen...
so, it was just a matter of taking the a2sd script from cyanogens 4.0.1 release, extracting his update.zip, taking the a2sd file from system/bin, and adb push the file to replace the existing file from your recovery image...
it worked like a charm... i'm currently running 230mb free on a fresh install... already i've noticed that its slightly faster than running off your ext for apps2sd on a class 6, but only time will telll... i'm gonna run this ROM through its courses and post my results... hopefully it doesn't slow down as much as using apps2sd, i'll post my results in a day or two
you can try just removing your ext2/3 partition. if the ROM does not detect a ext2/3 partition, it wont move hte apps to that partition thus no apps2sd.
motivecc said:
yah... after i finished writing my original post, i tried using VI again and noticed in the header of the a2sd script on jacherorom 1.4 that the a2sd script was written by cyanogen...
so, it was just a matter of taking the a2sd script from cyanogens 4.0.1 release, extracting his update.zip, taking the a2sd file from system/bin, and adb push the file to replace the existing file from your recovery image...
it worked like a charm... i'm currently running 230mb free on a fresh install... already i've noticed that its slightly faster than running off your ext for apps2sd on a class 6, but only time will telll... i'm gonna run this ROM through its courses and post my results... hopefully it doesn't slow down as much as using apps2sd, i'll post my results in a day or two
Click to expand...
Click to collapse
But you modified a2sd from cyanogens ROM or what? You put the modified one in the update.zip then fresh flash?
fridlack said:
But you modified a2sd from cyanogens ROM or what? You put the modified one in the update.zip then fresh flash?
Click to expand...
Click to collapse
nope, the a2sd script from cyanogen's 4.0.1 ROM automatically disables apps2sd if your have a fat32 only memory card, thus taking care of having to edit the script myself...
all i did was go into my recovery image, and do the following:
Code:
# go to the tools directory of your android sdk and run a push command
# the format of a push command goes as follows
# adb push <local directory of file> <directory of file on device>
# in my case i would have to type
adb push c:\androidsdk\androidsdk\a2sd /system/bin/a2sd
and thats it
by using the adb push command, i don't have to modify the update.zip file and go through the process of having to resign it... i find it easier to run this command to just replace the one file... i recommend doing this after a fresh install only of course...
motivecc said:
nope, the a2sd script from cyanogen's 4.0.1 ROM automatically disables apps2sd if your have a fat32 only memory card, thus taking care of having to edit the script myself...
all i did was go into my recovery image, and do the following:
Code:
# go to the tools directory of your android sdk and run a push command
# the format of a push command goes as follows
# adb push <local directory of file> <directory of file on device>
# in my case i would have to type
adb push c:\androidsdk\androidsdk\a2sd /system/bin/a2sd
and thats it
Click to expand...
Click to collapse
Thanks for the info, will give it a try
be careful what ROM you use it with... i would only suggest using it with any ROM that utilizes cyanogen's method of a2sd, as using a different one might brick or crash the phone... you can check by
Code:
adb pull /system/bin/ c:\<folder name here>
that will pull all your files to folder of your choice, and you can read the a2sd file by opening it with wordpad and seeing who made it... most likely its cyanogen anyway, but it doesn't hurt to check
Soo,
I want to start a project to make a script which includes the Market in a "bare bone" ROM.
The goal is to have cyanogen to make ROM's without Google Experience and let the user run a script to reinclude the Market.
I have an idea how:
The user has to download a file from the HTC Website: The ADP1 Systemimage.
He places it into a folder in which is a script which unyaffs the image, copys the necesarry files and makes an update.zip out of it which can be flashed over the "bare bone-rom".
I don't know if this legal or not, but Google won't attack the end-user, but the one who provides software illegal.
But HTC has a license, so there shouldn't be a problem.
The end-user does something illegal I think, but he won't get into any trouble with google.
The hardest part is to find the necesarry files.
I diffed the folders of a market and non-market ROM and filtered out some unneeded parts.
Here's the list of which files to copy.
# Apps
cp system/app/BugReport.apk gfiles/app/BugReport.apk
cp system/app/checkin.apk gfiles/app/checkin.apk
cp system/app/Gmail.apk gfiles/app/Gmail.apk
cp system/app/GmailProvider.apk gfiles/app/GmailProvider.apk
cp system/app/GoogleApps.apk gfiles/app/GoogleApps.apk
cp system/app/GoogleContactsProvider.apk gfiles/app/GoogleContactsProvider.apk
cp system/app/GooglePartnerSetup.apk gfiles/app/GooglePartnerSetup.apk
cp system/app/GoogleSettingsProvider.apk gfiles/app/GoogleSettingsProvider.apk
cp system/app/GoogleSubscribedFeedsProvider.apk gfiles/app/xx.apk
cp system/app/GoogleSubscribedFeedsProvider.apk gfiles/app/GoogleSubscribedFeedsProvider.apk
cp system/app/gtalkservice.apk gfiles/app/gtalkservice.apk
cp system/app/ImProvider.apk gfiles/app/ImProvider.apk
cp system/app/MediaUploader.apk gfiles/app/MediaUploader.apk
cp system/app/NetworkLocation.apk gfiles/app/NetworkLocation.apk
cp system/app/SetupWizard.apk gfiles/app/SetupWizard.apk
cp system/app/Street.apk gfiles/app/Street.apk
cp system/app/Talk.apk gfiles/app/Talk.apk
cp system/app/Vending.apk gfiles/app/Vending.apk
cp system/app/VoiceDialer.apk gfiles/app/VoiceDialer.apk
cp system/app/VoiceSearch.apk gfiles/app/VoiceSearch.apk
cp system/app/YouTube.apk gfiles/app/YouTube.apk
# Framework
cp system/framework/com.google.android.gtalkservice.jar gfiles/framework/com.google.android.gtalkservice.jar
cp system/framework/com.google.android.maps.jar gfiles/framework/com.google.android.maps.jar
# Permissions
cp system/etc/permissions/com.google.android.gtalkservice.xml gfiles/etc/permissions/com.google.android.gtalkservice.xml
cp system/etc/permissions/com.google.android.maps.xml gfiles/etc/permissions/com.google.android.maps.xml
Click to expand...
Click to collapse
PLEASE ONLY DEV-TALK!
LINUX
The script for linuxusers is ready. It's attached.
Usage:
Go to the folder
chmod +x extract
./extract
You will need your device connected with a ROM without Google Apps, but root, and you'll need the drivers (usb rules) if it doesn't work from the start.
IT WILL TELL YOU TO DOWNLOAD A FILE, YOU HAVE TO GOOGLE FOR IT!
CUSTOM RECOVERY
Usage:
Place "signed-dream_devphone_userdebug-img-150275.zip" on your sdcard.
Boot into this recovery, adb into the device and run:
sh /sbin/gapps
It will do ALL automatically!
I hope I can later include it in the menu =)
Download: http://www.4shared.com/file/135537189/25541756/recoverynewimg.html
It's based on Amom_RA's great recovery!
Improved list for the backup and restore after flash or leave untouched strategies:
GOOGLE AND HTC STUFF (?)
/system/app/BugReport.apk
/system/app/checkin.apk
/system/app/Clicker.apk
/system/app/Gmail.apk
(easy to substitute with other mail client):
pop.gmail.com port 995 with SSL
smtp.gmail.com port 465 with SSL)
/system/app/GmailProvider.apk
/system/app/GoogleApps.apk
android/cupcake/packages/providers/GoogleContactsProvider is open source
/system/app/GoogleContactsProvider.apk
/system/app/GooglePartnerSetup.apk
/system/app/GoogleSettingsProvider.apk
android/cupcake/packages/providers/GoogleSubscribedFeedsProvider is open source
/system/app/GoogleSubscribedFeedsProvider.apk
/system/app/gtalkservice.apk
android/cupcake/packages/providers/ImProvider is open source
/system/app/ImProvider.apk
/system/app/MediaUploader.apk
/system/app/NetworkLocation.apk
/system/app/SetupWizard.apk
android/cupcake/packages/apps/Stk/src/com/android/stk is open source
/system/app/Stk.apk
/system/app/Street.apk
/system/app/Talk.apk
/system/app/TmoImPlugin.apk
/system/app/Vending.apk
android/cupcake/packages/apps/VoiceDialer is open source
/system/app/VoiceDialer.apk
/system/app/VoiceSearch.apk
/system/app/YouTube.apk
/system/etc/permissions/com.google.android.gtalkservice.xml
/system/etc/permissions/com.google.android.maps.xml
/system/framework/com.google.android.gtalkservice.jar
/system/framework/com.google.android.maps.jar
/system/framework/com.htc.framework.jar
/system/framework/com.htc.resources.apk
/system/lib/libcerttool_jni.so
Other closed source(?) files:
/system/bin/akmd
(/system/etc/AudioFilter.csv)
(/system/etc/AudioPara4.csv)
(/system/etc/AudioPreProcess.csv)
/system/etc/firmware/brf6300.bin
(/system/etc/gps.conf)
/system/etc/wifi/Fw1251r1c.bin
(/system/etc/wifi/tiwlan.ini)
/system/lib/libaudioeq.so
/system/lib/libgps.so
/system/lib/libhgl.so
/system/lib/libhtc_acoustic.so
/system/lib/libhtc_ril.so
/system/lib/libjni_pinyinime.so
/system/lib/libmm-adspsvc.so
/system/lib/libOmxCore.so
/system/lib/libOmxH264Dec.so
/system/lib/libOmxMpeg4Dec.so
/system/lib/libOmxVidEnc.so
/system/lib/libopencorehw.so
/system/lib/libpvasf.so
/system/lib/libpvasfreg.so
/system/lib/libqcamera.so
/system/lib/libspeech.so
/system/lib/hw/lights.goldfish.so
/system/lib/hw/lights.msm7k.so
/system/lib/hw/sensors.trout.so
WAREZ (?)
/system/app/HTC_IME.apk
/system/lib/libt9.so
/system/app/ PDFViewer.apk
/system/lib/libpdfreader.so
/data/app/Quickoffice_HTC_1.0.1.apk
/data/app/teeter.apk
also posted here http://forum.xda-developers.com/showthread.php?t=564303&page=6
Were gonna need Stk.apk it's for the sim card without that it's impossible to make calls.
And vending.apk is for Market and without that it is impossible to download the majority of apps.
I would suggest a different strategy that is even easier. Every user has this
files already on his rom, most (all?) of them are 1.5 based. So before
updating the phone with a cooked rom you have only to backup (tar)
the not redistributable files to the sdcard. After having flashed the coocked rom
you just need to untar them to the flash memory.
Z҉A҉L҉G҉O̚̕̚ said:
Were gonna need Stk.apk it's for the sim card without that it's impossible to make calls.
And vending.apk is for Market and without that it is impossible to download the majority of apps.
Click to expand...
Click to collapse
Stk.apk is for the Sim menu. You can make calls even if you delete it from your rom
farmatito said:
I would suggest a different strategy that is even easier. Every user has this
files already on his rom, most (all?) of them are 1.5 based. So before
updating the phone with a cooked rom you have only to backup (tar)
the not redistributable files to the sdcard. After having flashed the coocked rom
you just need to untar them to the flash memory.
Click to expand...
Click to collapse
The problem with that is that the apk's have odexes and resource id's that must match the build number to actually work even Cyanogen said that.
And regarding the keep-proprietary-apps-on-device-for-custom-rom install, with all the odexing and resource id mismatches... Ugh.
Click to expand...
Click to collapse
I'm building the AOSP android-1.5_r3 now and will load it onto my device and will try to push the files to it.
Please wait for the results.
If I have success, I'll start making a script which automates the process.
maxisma said:
I'm building the AOSP android-1.5_r3 now and will load it onto my device and will try to push the files to it.
Please wait for the results.
If I have success, I'll start making a script which automates the process.
Click to expand...
Click to collapse
Good luck and good speed.
Z҉A҉L҉G҉O̚̕̚ said:
The problem with that is that the apk's have odexes and resource id's that must match the build number to actually work even Cyanogen said that.
Click to expand...
Click to collapse
If i recall correctly JF made a tool to convert odex files to dex files which could then be repacked in the apk. Don't know if this could be run on the phone tough.
SUCCESS! I found the needed files, got market working on AOSP!
It's the list above (first post).
I'm writing a script now ;-)
Edit:
Script for Linux users is done, testing it now and looking for bugs, will then make a windows-one.
Ok, script is in the first post.
Couldn't this script run from within a recovery image with little if no changes?
i.e. consider this install procedure for a new ROM
1) push update.zip for new ROM to SD card
2) push signed-dream_devphone_userdebug-img-150275.zip to SD (I suspect most people would just have it milling about their SD card in the end!)
3) wipe
4) apply update.zip
5) run (obviously slightly modded) script in recovery before rebooting and running ROM for first time
There'd need to be some kind of unzip capacity within the recovery image, otherwise, there doesn't seem to be anything you're doing in your script that couldn't be done on the handset itself.
Loccy said:
Couldn't this script run from within a recovery image with little if no changes?
i.e. consider this install procedure for a new ROM
1) push update.zip for new ROM to SD card
2) push signed-dream_devphone_userdebug-img-150275.zip to SD (I suspect most people would just have it milling about their SD card in the end!)
3) wipe
4) apply update.zip
5) run (obviously slightly modded) script in recovery before rebooting and running ROM for first time
There'd need to be some kind of unzip capacity within the recovery image, otherwise, there doesn't seem to be anything you're doing in your script that couldn't be done on the handset itself.
Click to expand...
Click to collapse
Yeah, you're right!
But the unzip process would last much longer on this little, little handset.
But ok i'll make a script
EDIT:
Have written a script, untested.
# Mounting
mount sdcard
mount system
# Chmod the files
chmod +x sbin/unyaffs
# Unzip Image
mkdir /sdcard/system
mv /sdcard/signed-dream_devphone_userdebug-img-150275.zip /sdcard/system/signed-dream_devphone_userdebug-img-150275.zip
unzip /sdcard/system/signed-dream_devphone_userdebug-img-150275.zip
# Remove not needed files, move & unyaffs the system
cd /sdcard/system
rm boot.img
rm recovery.img
rm userdata.img
rm android-info.txt
./sbin/unyaffs /sdcard/system/system.img
rm system.img
# Copy the needed files & create folders
cd /sdcard
mkdir gfiles
mkdir gfiles/app
mkdir gfiles/etc
mkdir gfiles/etc/permissions
mkdir gfiles/framework
# Apps
cp system/app/BugReport.apk gfiles/app/BugReport.apk
cp system/app/checkin.apk gfiles/app/checkin.apk
cp system/app/Gmail.apk gfiles/app/Gmail.apk
cp system/app/GmailProvider.apk gfiles/app/GmailProvider.apk
cp system/app/GoogleApps.apk gfiles/app/GoogleApps.apk
cp system/app/GoogleContactsProvider.apk gfiles/app/GoogleContactsProvider.apk
cp system/app/GooglePartnerSetup.apk gfiles/app/GooglePartnerSetup.apk
cp system/app/GoogleSettingsProvider.apk gfiles/app/GoogleSettingsProvider.apk
cp system/app/GoogleSubscribedFeedsProvider.apk gfiles/app/GoogleSubscribedFeedsProvider.apk
cp system/app/gtalkservice.apk gfiles/app/gtalkservice.apk
cp system/app/ImProvider.apk gfiles/app/ImProvider.apk
cp system/app/MediaUploader.apk gfiles/app/MediaUploader.apk
cp system/app/NetworkLocation.apk gfiles/app/NetworkLocation.apk
cp system/app/SetupWizard.apk gfiles/app/SetupWizard.apk
cp system/app/Street.apk gfiles/app/Street.apk
cp system/app/Talk.apk gfiles/app/Talk.apk
cp system/app/Vending.apk gfiles/app/Vending.apk
cp system/app/VoiceDialer.apk gfiles/app/VoiceDialer.apk
cp system/app/VoiceSearch.apk gfiles/app/VoiceSearch.apk
cp system/app/YouTube.apk gfiles/app/YouTube.apk
# Framework
cp system/framework/com.google.android.gtalkservice.jar gfiles/framework/com.google.android.gtalkservice.jar
cp system/framework/com.google.android.maps.jar gfiles/framework/com.google.android.maps.jar
# Permissions
cp system/etc/permissions/com.google.android.gtalkservice.xml gfiles/etc/permissions/com.google.android.gtalkservice.xml
cp system/etc/permissions/com.google.android.maps.xml gfiles/etc/permissions/com.google.android.maps.xml
# Put back the ADPimg
mv /sdcard/system/signed-dream_devphone_userdebug-img-150275.zip /sdcard/signed-dream_devphone_userdebug-img-150275.zip
#Push the files to the device & reboot it
cp -r /sdcard/system/* /system/
echo "Please reboot!"
Click to expand...
Click to collapse
Code:
cp system/app/GoogleSubscribedFeedsProvider.apk gfiles/app/xx.apk
cp system/app/GoogleSubscribedFeedsProvider.apk gfiles/app/GoogleSubscribedFeedsProvider.apk
Think there is typo error in the first line.
Could be a good thing to set explicitely the permissions and ownership of the files.
I think the last line should be
Code:
cp -r /gfiles/* /system/
rt ?
Yap, there is 1 line too much @farmatito, thanks, will fix that!
@sureshg:
I rewrite the script for the recovery.. thanks!
Another possible way to do this is to make a script that makes an update.zip file from HTC's yaffs file.
It would only consists of the apk's and libraries we need to modify (market, IM, Maps, whatever) which would make flashing it faster on the device. And it would also be flashable with Cyanogen's bootloader after we flash an AOSP build since we can flash any .zip file with it.
However, I would like to be able to back up the new market and all associated libraries before trying it in case I wanna switch back
@ maxisma: Thanks for taking this in a positive direction. I was thinking along the same lines, and just posted the below to another thread before I saw this thread:
It looks to me as though Google is bluffing. Here is copyright law that, IMHO, gives every user the right to make and use a backup: COPYRIGHT LAW Just because Google say something, doesn't mean it is true.
I believe the solution to this whole mess is very simple. Here is the roadmap:
1) Cyanogen makes a list of all the closed source apps that need to be left out of the ROM.
2) Some kind person(s) write an app that the user can run to backup the list of files, signs and zips it so that it can be flashed later. Let's call that app "GoogleBack," and make it freely available here (and on the Market?).
3) Cyanogen produces each new ROM without the proprietary files that are on the backup list.
4) User runs "GoogleBack" one time and resulting googleback.zip is stored on /sdcard (root directory).
5) User installs new CM update.zip from Recovery as usual.
6) User also flashes googleback.zip while still in Recovery.
7) User reboots as usual, and now has a new ROM, complete with Google's precious proprietary apps.
8) Everybody goes home happy.
Alternatively, Cyanogen could add a step to the reboot process (home+back) that runs a script to copy the backup files from the backup file (and maybe also run fix_permissions if necessary). This would make that first reboot a longer process, but it would get the job done.
We need to get busy on a solution. This whole issue is just a speed-bump on the Android highway.
I think you are absolutely on the right track. Keep up the good work. Thanks also to everyone else who is making this happen.
use of deviceinstalled official rom
Hi,
why not use the already installed software on the user device. The update.zip of the custom rom could rely on the vanilla stock firmware and do all the needed patching and homebrew additions on base of the stock rom during first boot. So enduser has to flash an official rom first, unit is in an well known state and the dev update.zip just does the conversion to the custom rom during first boot.
I think the end user may not be allowed to run these modification software but he won't be punished. Don't know if it is legal to redistribute a rom which does the patching but that would be the same problem of redistributing software which does a merge of two roms on the enduser side.
Greetings Lopiuh
stellarman said:
@ maxisma: Thanks for taking this in a positive direction. I was thinking along the same lines, and just posted the below to another thread before I saw this thread:
It looks to me as though Google is bluffing. Here is copyright law that, IMHO, gives every user the right to make and use a backup: COPYRIGHT LAW Just because Google say something, doesn't mean it is true.
I believe the solution to this whole mess is very simple. Here is the roadmap:
1) Cyanogen makes a list of all the closed source apps that need to be left out of the ROM.
2) Some kind person(s) write an app that the user can run to backup the list of files, signs and zips it so that it can be flashed later. Let's call that app "GoogleBack," and make it freely available here (and on the Market?).
3) Cyanogen produces each new ROM without the proprietary files that are on the backup list.
4) User runs "GoogleBack" one time and resulting googleback.zip is stored on /sdcard (root directory).
5) User installs new CM update.zip from Recovery as usual.
6) User also flashes googleback.zip while still in Recovery.
7) User reboots as usual, and now has a new ROM, complete with Google's precious proprietary apps.
8) Everybody goes home happy.
Alternatively, Cyanogen could add a step to the reboot process (home+back) that runs a script to copy the backup files from the backup file (and maybe also run fix_permissions if necessary). This would make that first reboot a longer process, but it would get the job done.
We need to get busy on a solution. This whole issue is just a speed-bump on the Android highway.
I think you are absolutely on the right track. Keep up the good work. Thanks also to everyone else who is making this happen.
Click to expand...
Click to collapse
This is almost exactly what I was talking about (except I was thinking that the "GoogleBack" zip should be made on a computer since it would be faster to make) and that we could use HTC's official provided yaffs image (because they are licensed to distribute it) instead of the ones from an existing phone.
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.
I made this shell script to automatize the odexing process and maybe it could be useful to someone else.
It should be universal, but I only tested it on my phone.
It's not to re-odex a deodexed rom, but to make stock roms compatible odexed files from deodexed files.
Some mods won't work (signature issues I think)
How to use it:
Extract the attached zip wherever you want on your phone.
In the same directory of the script 'odexer.sh' and the directory 'odextools', make a directory named 'deodexed' (actually, it's already there). Inside 'deodexed' create two directories: 'framework' and 'app'. Put there your modded files, each in the respective directory.
You need the original stock odexed files (apk and odex) and all the '$BOOTCLASSPATH' files (see the note below). The script was intended to be used on odexed rom, but I made it adaptable: in the script change the variable 'moddedpath' with the path to the directory with the original odexed files, each inside 'app' or 'framework (you can directly copy '/system/framework/' and '/system/app/' from a stock rom if you are too lazy).
(I only tested this script on my odexed stock rom using /system as 'moddedpath')
Here how the directory tree should look like:
Code:
/some/random/path/
|-[COLOR="BLUE"]deodexed[/COLOR]
|---[COLOR="BLUE"]app[/COLOR]
|-----[COLOR="RED"]SystemUI.apk[/COLOR]
|---[COLOR="BLUE"]framework[/COLOR]
|-----[COLOR="RED"]framework.jar[/COLOR]
|-[COLOR="GREEN"]odexer.sh[/COLOR]
|-[COLOR="BLUE"]odextools[/COLOR]
|---[COLOR="GREEN"]busybox[/COLOR]
|---[COLOR="GREEN"]dexopt-wrapper[/COLOR]
|---[COLOR="GREEN"]zip[/COLOR]
You need to run the script as root from 'adb shell' or 'Terminal emulator'.
If you put the script in your vfat formatted sdcard, you won't be able to change its permissions, so, in order to run it, you need to pass its path to 'sh' as argument:
Code:
sh /sdcard/somepath/odexer.sh
It will create in the same directory a directory named 'odexed-DD-MM-hh.mm.ss'.
The script will automatically skip files with no odex (framework-res.apk should be always skipped, I think).
It's important to keep everything in the same place, because I used relative paths in the script.
Enjoy
________
To see your $BOOTCLASSPATH files, run from 'adb shell' or 'Terminal emulator:
Code:
echo $BOOTCLASSPATH
or open your /init.rc
Thank you
Thank you for guide. But some points were gone over my head
I found this one. Its one of the simplest method.
forum.xda-developers.com/showthread.php?t=1348062
vishal24387 said:
Thank you for guide. But some points were gone over my head
Click to expand...
Click to collapse
Which point? This?
It's not to re-odex a deodexed rom, but to make stock roms compatible odexed files from deodexed files.
Click to expand...
Click to collapse
loSconosciuto said:
Which point? This?
Click to expand...
Click to collapse
actually I am noob in case of android's coding technical language. Its not ur fault
WARNING: I am not responsible for you breaking your phone, you need to make sure you have a PROPER backup before using this tool, and if you don't know what a proper backup is, then I suggest you do more research before attempting something like this.
ABOUT
This is a bash script I just wrote, it can deodex your entire phone, or just a specified file, it can also restore the original odexed files. You can just drop the files in the working directory, or you can add them to your global $PATH variable, either way it will be able to work (even if you use a symlink for the $PATH variable, it'll still be able to detect where the included smali and baksmali files are).
DEPENDANCIES
Bash (obviously), 7z, adb, and realpath (might not be installed by default on most Linux distros)
Code:
sudo apt-get install p7zip && sudo apt-get install realpath
IMPORTANT
I consider this script to be in Beta, even though I tested it thoroughly on my phone, until more people test it you need to be prepared that it may not work 100% on your phone, and if it doesn't PLEASE copy and paste the command output, I want this script to work on as many devices as possible but that requires people to let me know when it doesn't work for them.
FOR THIS TO WORK PROPERLY MAKE SURE YOU ARE BOOTED TO RECOVERY WITH THE SYSTEM PARTITION MOUNTED
Example Usage
deodex --all
-This will scan your phone for odexed files, pull them, deodex them, push them back, and delete the odex files from the phone
deodex <file_name_without_extension>
-This is not as useful, it does the same thing as the --all option, except it only deodexes the specified file
-Example: deodex SystemUI (notice you leave off the extension, THIS IS IMPORTANT, file name ONLY without extension)
deodex --restore
-This will restore all your original files back to the phone (as long as you didn't delete the original folder that was created when deodexing :silly
The project is located on GitHub:
https://github.com/tgaurnier/UniversalDeodexer