[CUSTOM RECOVERY] Integrate GoogleApps into ROM's w/o Google Experience/AOSP =) - G1 Android Development

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.

Related

[HOW-TO] ROM-HACKING: init.rc ext2-auto-mount / ROM Signing / ROM Kitchen

AS MENTIONED IN THE INTRODUCTION TEXT THIS HAS ONLY BEEN TESTED ON AMON RA ROM 1.6.2 BUT SHOULD REALLY WORK ON ANY ROM THAT HAS NO EXT2 AUTO-MOUNT. AND YEAH THIS WHOLE PROCESS HAS BEEN DONE ON A 32a BOARD. FOR THOSE THAT TRY THIS ON OTHER ROMS LET ME KNOW HOW IT GOES.
I've searched and shuffled through the entire forum and made inquiries to ROM authors without much light being shed on this issue. I doubt I am the only one who has been looking for a way of doing this so I decided to do a small HOW-TO. Here I will explain step by step as to how you can implement a script to be part of your ROM that will auto mount an ext2 partition on boot up if such partition is present. I have included all the tools I've used in order to pull this off, and as the title suggests this has only been done on Amon Ra's latest 1.6.2 ROM. In order to follow these instructions you are expected to allready have set up an adb enviroment on your linux box and for the signing process to work you must have sun-java present, the gnu java wont work. And of course a microSD card with an ext2 partition
1. Download install.sh to your home directory
Code:
wget http://www.grindhouse.no/androidtools/install.sh
chmod a+x install.sh
2. Now execute the install.sh script which will create a directory to work in and download a tool and script package and unpack it.
Code:
./install.sh
When the install.sh script is done you need to move the mkbootimg preferebly to your tools directory of your SDK.
Code:
mv toolstomove/mkbootimg <path/to/sdk/tools/mkbootimg>
3. Unpack the RA1.6.2 ROM into a directory in your home dir. In this HOW-TO we will use directory name "ra1.6.2" as an example through out the entire process.
4. Copy the boot.img from ra1.6.2 to the ROM-cooker dir
Code:
cp $HOME/ra1.6.2/boot.img $HOME/ROM-cooker/boot.img
cd $HOME/ROM-cooker
5. Use unpack.pl to extract the ramdisk from the boot image. I've modified the script a little so it automates the entire process and decompresses the ramdisk to a directory
Code:
./unpack boot.img
6. Now you can either replace the init.rc file here with the one I've included in this package or you can add these lines by yourself. In wich case do the following
Code:
cd boot.img-ramdisk
pico init.rc
Press CTRL+w and then CTRL+t and input 27. hit enter. This will take you to line 27 of init.rc so you can add a line right before the init process remounts the rootfs in read-only mode. Add following line:
Code:
mkdir /sdext2 0771 system system
Now scroll down to the end of the init.rc file and add the following:
Code:
service mountsdext2 /system/bin/mountsd
user root
group root
oneshot
7. You have now edited (or replaced) your init.rc file and prepared it to execute a script on boot that will detect an ext2 partition and boot it if there is one to be found. Now you have to make the mountsd script a part of the ROM. Do the following:
Code:
cd $HOME/ROM-cooker
mv toolstomove/mountsd $HOME/ra1.6.2/system/bin/mountsd
rm -rf toolstomove
8. Now that the init.rc file is sorted out and mountsd has been placed in /system/bin of the ROM so it is time to re-pack the boot.img:
Code:
cd $HOME/ROM-cooker
./repack boot.img-kernel boot.img-ramdisk boot.img
rm $HOME/ra1.6.2/boot.img
mv boot.img $HOME/ra1.6.2/boot.img
9. Your ROM now has a new boot image with an updated init.rc and the /system/bin dir has the script needed to auto-mount the microsd ext2. Now you must re-zip the ROM and sign it. Do the following:
Code:
cd $HOME/ra1.6.2
zip -r update.zip *
mv update.zip $HOME/ROM-cooker/update.zip
cd $HOME/ROM-cooker
./sign.pl update.zip
10. The ROM is now signed and you now have a file called update-signed.zip. Connect the phone to your computer and execute thus:
Code:
./push update-signed.zip
11. Now you are ready to flash the modified ROM which will auto-mount an ext2 partition on your microSD. There is no need to wipe before flashing. If you have no prior experience with ROM flashing or whatever just backup your current install. If you're using OpenHOME or anything similar, nothing will be changed or damaged but if you're using MontAlbert's themes with the ROM you will have to flash them again after flashing this modified ROM.
Code:
adb reboot recovery
12. Flash from choose zip and of course choose update-signed.zip. Reboot. After the system boots up again you can now check whats what with either one of the commands:
Code:
[email protected]:~$ adb shell mount | grep sdext2
/dev/block/mmcblk0p2 on /sdext2 type ext2 (rw,noatime,nodiratime,errors=continue)
[email protected]:~/boot$ adb shell busybox df -h | grep sdext2
/dev/block/mmcblk0p2 893.7M 13.0K 846.0M 0% /sdext2
13. Voila! Your RA 1.6.2 ROM now detects and mounts your microSD ext2 partition on boot. Woohoo?
I hope the HOW-TO was easy reading and that you have succeeded in hacking up your ROM. I know that certain ROMs have this as a built-in function but Amon Ra's does not. But since alot of people including myself use his ROM because of the high speed and stability I thought I should contribute to his project and add a cool (and missed?) function to it.
Mind you that you can use the ROM-cooker set to further adjust and hack up the ROM as you see fit. Happy learning!
Very nice!
Now the question many people will ask : why would you automount ext2 if you don't use apps2sd ?
I personally have ubuntu on my ext2 And besides this approach can be used for a number of things, people who have had the need, or wanted to experiment with init.rc doing things on boot, the mountsd script can easily be altered to do what ever needed.
For me its been a learning curve finding these things out, so by sharing it I may spare some people breaking their backs over this whole init.rc thing. people may want to modify init.rc for whatever reason, so I'm sure people wont have a problem finding a way of putting this to use, and its a subject that isnt all that covered on the forum .. and hey .. at least they get a rom kitchen out of the whole shabang
Very interesting! Thank you.
I used your unpack-program to unpack a recovery-image. It seems to work fine. What I am trying to do is change the state the recovery-image returns the phone to. Would it be possible to just replace your mountsd-script with, for example, a script that installs apps? Or is there a better way to do what Im trying to achieve?
Cheers,
edit: I noticed that on the emulator it is sufficient to just place an apk-file in "data/app" to get it installed. Could it be possible that this is all I need a script to do? :O or could I hurt my poor phone by doing so you think?
sandis84 said:
edit: I noticed that on the emulator it is sufficient to just place an apk-file in "data/app" to get it installed. Could it be possible that this is all I need a script to do? :O or could I hurt my poor phone by doing so you think?
Click to expand...
Click to collapse
That's indeed all you need to do.
Hi!
So I tried to create a signed update.zip, but it failed. It didnt create a "update-script"-file, so my device refused to install it. I wrote my own "update-script"-file, but then it complained "no digest" for the file. How do I solve this?
post the contents of your script people might see whats up
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
sitimber said:
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
Click to expand...
Click to collapse
Says where its at in the first line : )
Code:
wget http://www.grindhouse.no/androidtools/install.sh
But now that I checked, I have to apologize, I see I have a missed payment with my hosting, I'll fix that within the day. Also sorry I havent been answering the few questions here I've been afk cause of surgery.
sitimber said:
post the contents of your script people might see whats up
Click to expand...
Click to collapse
well, I looked in another "update-script" file and found this:
assert compatible_with("0.2") == "true"
assert getprop("ro.product.device") == "dream" || getprop("ro.build.product") == "dream"
show_progress 0.5 0
write_radio_image PACKAGE:radio.img
show_progress 0.5 10
Click to expand...
Click to collapse
So I figured that nothing was essential other then the line "write_radio_image PACKAGE:radio.img". Also ofcourse I made sure it contained the name of my image-file instead of "radio.img". This gave me the "no digest" message, so now I feel unsure on how to create a working update.zip.
edit:
SOLVED! How silly of me. When you sign the update, a hash of each file is put in manifest.mf. Since I added the update-script after signing the file, ofcourse the digest(hash) was missing. Now everything works alot better and I can proceed... until I get stuck again
Cheers,
edit2:
Just to get a better understanding, what exactly does each line do here? Or where can I read about this?
Code:
service mountsdext2 /system/bin/mountsd
user root
group root
oneshot
edit3:
Ok, so I have experimentet, but I still dont manage to solve those last steps. I tried to edit init.rc and just add "mkdir /testdir 0000 system system" where the other directories were created. I then repacked it, zipped it, signed it, put it on my sdcard, started up a custom recovery, installed the update and rebooted. Everything seems to work fine. But when I start adb and check around, I dont see the "testdir"-directory. Also when I check in init.rc my line is gone. Do you guys have an idea of where I went wrong?
sitimber said:
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
Click to expand...
Click to collapse
it doesnot necesarily have to be linux ...you can also do it in windows using cygwin and dsxda's android rom kitchen

[Tutorial]Deodexing + Zipaligning Galaxy Gio GT-S5660

Advantages or disadvantages
- Odexed ROMs are slightly faster, deodexed ROMs are slightly slower
+ You can make custom themes for your ROM
+ Performance los is negligible.
Requirements
xUltimate - http://www.droidforums.net/forum/xeudoxus/47283-release-xultimate.html
Busybox installed
Root
Automatic deodexing - Method 1, by r33p
1. Connect phone to computer
2. Start xUltimate, we will now get the required files from our phone to deodex and zipalign it which we will describe in the 3rd step.
3. Select option #15 then "do it all".
Deodexing (little harder, but contains useful information for your future Galaxy Gio modding experience)- Method 2, by me
1. Connect phone to computer
2. Start xUltimate, we will now get the required files from our phone to deodex and zipalign it which we will describe in the 3rd step.
3. On the main menu of xUltimate, choose option 5 (Pull and deodex all). Everything will be done for you here. Don't worry. You will see all your finished files in the folders 'done_app' and 'done_frame' which are located in the installation directory of xUltimate.
4. move folders 'done_app' and 'done_frame' folders to your sdcard, you can find these folders in the directory of xUltimate as described in the previous step.
5. Make sure the sdcard is not mounted to pc anymore
6. Open Windows Command Prompt and type the following commands.
adb shell
su
stop
mount -o remount,rw /dev/block/stl12 /system
rm /system/app/*.odex
rm /system/framework/*.odex
busybox cp /sdcard/done_app/* /system/app/
busybox cp /sdcard/done_frame/* /system/framework/
chmod 644 /system/app/*
chmod 644 /system/framework/*
mount -o remount,ro /dev/block/stl12 /system
sync
reboot recovery
Click to expand...
Click to collapse
7. Now data and cache reset in the recovery menu...
8. reboot
If one of the commands, for example 'cp' is not found, try putting busybox in front of the command:
eg: busybox cp /sdcard/done_frame/* /system/framework/
How to odex again
This may put you in the right direction. You may need to edit some steps.
http://forum.xda-developers.com/showthread.php?t=1124034
If you like my work please donate
Paypal:
Bankaccount: in private message
Updated my tutorial. Now everything works.
What does this do to my gio?
// Thanks from the noob
why the hassle? just let xultimate do it all automatic -> select option #15 then "do it all"
yep
Thanks.. ;-)
Would it work with others samsung devices?
Gonna try with 5510
Sent from my GT-I9100 using Tapatalk
dann3_86 said:
What does this do to my gio?
// Thanks from the noob
Click to expand...
Click to collapse
I am curious to
I suggest you google deodexing and zipaligning.
Deodexing in short means that it will allow you to have custom themes.
Zipaligning improves performance of the apk/jar files when reading
There is a lot of information you might want to look up!
I just added r33p's suggestion. Thanks!
Dhuu, just google it.............
I did, but it gives no answers.
I thought it was about the holy grail, or the fountain of youth..............
But no..........
But comes close
So tell me, does it works on the fly or must you reboot to aply changes?
I tiedy this metod and it works. Tank you
I'm having a problem..
I'm on xUltimate, I go to the advanced menu (15) and I type 1 (Do everything) and then it says that I don't have files in done_app folder.
Please help
Edit: I have rooted my phone, it's on Gingerbread.xxkpo. Do I have to Un-Root my phone and then do this ? Also can I root it back when the ROM is on ?
Please reply fast :S
I'm having this issue,,, what does it mean? i pulled out all the files with the automatic process and went fine. But then in the deoxed process:
How can i solve it? Thanks :3

[Recovery][WIP] ARecovery

DO NOT FLASH ANYTHING FOUND HERE YET!!!
FOR DEVELOPMENT AND SHARING PURPOSES ONLY
if you flash anything before we say it's ok to, we take no resopnsibility...​
the purpose of this thread is to get all of the devs together and working on this. this is a great method of getting us a fully functional recovery without needing the bootloader unlocked. this will work on a number of motorola devices as well.
Preface
ok, the bootstrap recovery works, however, without being able to boot directly into the recovery from a power up state, it makes actual "recovery" difficult. the bootstrap recovery is great, and nitro did an awesome job with it as well as adapting it to the atrix 2 with ninja-like quickness. but i would like to build onto his awesome work and expand it's functionality.
the purpose of ARecovery is to provide a fully functional recovery that you can boot directly into, like you can with any clockworkmod recovery device that has a locked bootloader.
there has been a couple different ways this has been achieved on other devices, some will actually use an sdcard as a recovery partition, others have used a hijacked boot file to launch recovery. the hijacked boot file worked great on the xperia line of phones, so this is the method i am using.
i have had some help from doomlord putting this together, and he is one of the top xperia devs. he has given me some guidance on how the hijack boot could work on the atrix 2 and i am in the process of putting this together. so whatever comes of this project, we owe it all to doomlord
The Plan
what i plan to do, is actually use nitro's bootstrap recovery to initially flash the ARecovery package, this will move the files i plan on using for the hijack boot.
The files that will initially be flashed will be the hijacked boot file, the redirected file and the arecovery package.
the hijacked boot file is emc_mgt_tool, this file is called early on in the boot sequence in init.mapphone_utms.rc. this file will be replaced with this code (which is a work in progress and i will update this script as i work on it):
Code:
#!/system/bin/sh
cat /dev/input/event3 > /dev/keycheck&
sleep 3
kill -9 $!
if [ -s /dev/keycheck ]
then
# remount rootfs rw
mount -o remount,rw rootfs /
# Umount MTDs
umount -l /cache
umount -l /data
# Mount recovery partition
cd /
rm -r etc
# stock files will need to be added to arecovery.tar
rm -r /sbin
# stock files will need to be added to arecovery.tar
tar -xf /system/xbin/arecovery.tar
# Umount /system
umount -l /system
# chroot
chroot / /init
fi
# Continue normal booting
/system/bin/enc_mgt_tool2
exit
this script at boot will be activated with a hardware keypress, if triggered, the ARecovery process will start. if not triggered, boot will continue by being passed to the redirected file.
Progress
Pretty much where i am at right now, is still pretty much the beginning. stock system files need to be added to the arecovery.tar and the hijack script needs work. i will continue working on this until an sbf is found. when the sbf is found, i will start testing this.
doomlord has pretty much said that when we get an sbf, let him know and he'll help put this together.
and again, this will work on a number of motorola devices, so the more devs in on this, the better.
i attached arecovery_flash.zip. this is the initial flash package that contains the ARecovery stuff.
DO NOT FLASH THIS!!!​
do not flash
version .01 download
Change Log:
11-16-2011
The start
11-16-2011 version .01
added stock sbin and etc to recovery.tar
added redirect file
Take a look at this a see what you think?
http://hash-of-codes.blogspot.com/p/how-to-safestrap.html
JRW 28 said:
Take a look at this a see what you think?
http://hash-of-codes.blogspot.com/p/how-to-safestrap.html
Click to expand...
Click to collapse
even this would need to be built basically the same way as we are doing here

[DEV][SCRIPT] First-Boot App Install

First-Boot Install System​
I have searched Far and wide for something like this since i first put out SleeperROM in November and always come up empty.
So with the latest release, i decided it was finally time to do it myself.
All you have to do is, using the following package as a template either on its own or in your ROM, make sure your batch folder with the .apk's to install are in /data/.firstboot/
Why
Some apps like QuickPic, ConnectBot, TinyFlashlight, Flash, Google Goggles and others that rely on linked libs don't like to simply be copied to their install dir because many won't install their own libs unless the PackageManager does it and/or they won't add themselves to the packages list (like QuickPic). The old solution is to include the lib either in the /data/data/appdir/lib with the rom install OR in /system/lib but this is quite wasteful especially in the case of big apps like Flash where including the libs separately from the app effectively doubles the space taken up on the rom by that single app since the apk still contains the lib files within.
So the solution is to install on first boot by including the apps in a batch folder for the script to process.
How it works
What it does is run from the init scripts, as one of the last scripts to run, it waits until the Android core system is up (checks to be sure by waiting for the SystemUI process is running then waits for an additional 10 seconds)
Then runs /data/.firstboot.sh, which is where you should put your first boot routines. Included in this script is the batch app installer which looks for the apps in /data/.firstboot/ and stores temporary app backups in /cache/tmp -- so be mindful that on MTD roms, the cache partition is smaller so may have to modify the $tmp variable to wherever you want to store temporaries
After installing, it sleeps for a proportional number of seconds (5 seconds per app installed) to ensure there is no race condition between installs or the final permissions_fix, zipalign and tmp cleanup. The /data/.firstboot.sh script removes itself when everything is complete.
The remaining components are kept in there for additional use by the /etc/init.d/Y02firstboot script in the future, so then all that needs to be put on the phone is a new /data/.firstboot/ dir and replacement /data/.firstboot.sh to run a batch of updates.
The Apps MUST be named by their package name.
I.e. Titanium Backup MUST be named com.keramidas.TitaniumBackup.apk
the file name must correspond with the name of the data dir in /data/data/ the script is lazy in that way, i didn't feel like keeping a file manifest of installs, instead just like to drop in apps to install.
The installer
consists of the following components:
- /system/etc/init.d/Y02firstboot
- /system/xbin/rsync
- /system/xbin/fix_permissions
- /system/xbin/batch_zipalign
- /system/xbin/sleeperlog (echos, logcats, and writes a log of activity to /sdcard/sleeperlog.txt)
- /data/.firstboot.sh
- /data/.firstboot/ (batch app directory)
- NOT INCLUDED, there must be a busybox bin somewhere in $PATH - this is not a problem for most roms
See the package link for a ready to use first-boot installer [CWM] flashable. Just drop your apks into /fs/data/.firstboot/ for a batch app updater
Download the template/usable package
DOWNLOAD MOD_CWM-FirstBoot-20120112.zip
File size: 341.07 KB / MD5 23d88c349b8d2fa3cd2f9958ae99a1f6
​
THE MAIN COMPONENTS:
/system/etc/init.d/Y02firstboot
Code:
#!/system/bin/sh
# execute post-install script on First boot
# 01022012 SENSEISIMPLE
SLEEP=3
FBSCR="/data/.firstboot.sh"
BB="busybox"
pg () {
$BB ps | $BB grep "[email protected]" | $BB grep -v "$( echo $BB grep [email protected] )"
}
if [ -f "$FBSCR" ]; then
#install apps on first boot after system services have started
sleeperlog "Found $FBLOC"
sleeperlog "Waiting for system"
$BB chmod 0755 $FBSCR
while : ; do
if pg systemui; then
$BB sleep 10
sleeperlog "system loaded."
log -p i -t boot "Executing $FBSCR script"
sleeperlog "Running FirstBoot init"
$FBSCR
break
fi
sleeperlog "WAITING FOR SYSTEM SERVICE: sleeping for $SLEEP s..."
$BB sleep $SLEEP
done
fi
/data/.firstboot.sh
Code:
#!/system/bin/sh
#
# 20120107 - SENSEISIMPLE
#
log -p i -t init:firstboot "INIT.firstboot BEGIN: USER SCRIPT $FBLOC.sh"
sleeperlog "FirstBoot Script OK TO RUN"
FBLOC="/data/.firstboot"
tmp="/cache/tmp/firstboot"
bak="$tmp/bak/data/data/"
BB="busybox"
RM="$BB rm"
CP="$BB cp"
MV="$BB mv"
MKDIR="$BB mkdir"
LS="$BB ls"
CHMOD="$BB chmod"
SLEEP="$BB sleep"
GREP="$BB grep"
pg () {
$BB ps | $BB grep "[email protected]" | $BB grep -v "$( echo $BB grep [email protected] )"
}
$CHMOD 0777 /data
#install apps on first boot
if [ -d $FBLOC ]; then
sleeperlog "Found $FBLOC"
if [ "$($LS $FBLOC)" ]; then
cd $FBLOC
$MKDIR -p $bak
for pkg in *.apk; do
log -p i -t init:firstboot "INIT.firstboot INSTALLING: $pkg"
sleeperlog "PREPARING: $pkg"
pkgname=${pkg%.*}
sleeperlog "BACKING UP APP DATA - $pkgname"
#back up data, delete the original data dir to prevent install errors (pm isn't very good at what it does)
if [ -d /data/data/$pkgname ]; then
$CP -a /data/data/$pkgname $bak/$pkgname
$RM -rf /data/data/$pkgname
fi
#WAIT, then install, then WAIT SOME MORE
$SLEEP 2
sleeperlog "INSTALLING $pkgname"
pm install -r $FBLOC/$pkg &
$SLEEP 10
#REIntegrate application data
if [ -d "$bak/$pkgname" ]; then
sleeperlog "\nSYNCING APP DATA \n\n$(/system/xbin/rsync -auv --exclude=lib $bak/$pkgname/ /data/data/$pkgname/)\n"
fi
i=$((i+1))
#Move the install .apk to tmp
if $LS /data/app | $GREP "$pkgname"; then
sleeperlog "Package appears to have installed."
$MV "$pkg" $tmp/
fi
#If the firstboot batch dir is empty, delete it now
! [ "$($LS $FBLOC)" ] && $RM -rf $FBLOC
done
#WAIT for [#ofapps x 5 seconds each] to avoid a race condition
waitsecs=$(( i * 5 ))
sleeperlog "Waiting for ${waitsecs}s before Fixing Permissions"
$SLEEP $waitsecs
sleeperlog "Fixing Permissions $(/system/xbin/fix_permissions)"
sleeperlog "Running batch zipalign \n\n $(/system/xbin/zipalign)"
sleeperlog "Clearing tmp $tmp"
fi
fi
sleeperlog "FIRSTBOOT SCRIPT COMPLETE"
log -p i -t init:firstboot "INIT.firstboot SELF DESTRUCT FIRSTBOOTSCRIPT"
if ! [ "$($LS $FBLOC)" ]; then
$MV $0 $tmp/.firstboot
# COMMENT THIS OUT FOR DEBUGGING, TO NOT REMOVE THE TMP DIR
$RM -r $tmp
echo ""
fi
echo -e "#\n#COMPLETED ON $(date)\n#" >> $0
sleeperlog "FirstBoot Apoptosis"
log -p i -t init:firstboot "INIT.firstboot END: USER SCRIPT $FBLOC.sh"
THANKS
CyanogenMod team for the Fix_permissions script
DarkyROM for the Batch Zipalign script
Saving this seat . . .
does this work with a bml rom?
^^^^In theory, it would work with an NTFS rom, if one existed - different filesystems don't [usually] create any changes on the surface... if you try to copy a file from a partition of any file system to a partition of any other file system, you don't have to explicitly tell the system the fs types involved. I haven't looked through the entire script, but if there are any commands that must specify the partition type, it would be a simple matter of changing any occurances of EXT4 to YAFFS2, etc.
This could be a great way to make a clean reinstall with all of your apps intact (minus app data, do a separate backup with your backup app of choice) - first, backup your installed apps by copying them to the appropriate directory, then do a full wipe and install, with the script automatically reinstalling your apps on first boot...
EDIT: I just looked through the script more closely. First, it appears that data is backed up. Second, I can confirm that the standard, non-file system-specific linux commands are used for file operations (cp to copy, etc), so this script shouldn't need any adjustment to accomodate different file systems
Sent from my SPH-D700 using XDA App
Is it possible for someone to develop an application to backup your personal apps and then running a script in clockwork or on first boot that does the same thing as this, alllowing for personal apps to be in the rom directly after flashing. I understand that sometimes apps may not be compatible, but can randomroms rdu script be modified to choose to do this?
Sent From My Cyan4g
Good looking script SenseiSimple!!
Okay, I'm trying to use this script, but you said to put the apps in fs/data/firstboot/ but where is "fs"? I found the "firstboot.sh" file, but I'm sure I can't put the apk's in there...
In loving memory of my son "Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 :'(
sniperkill said:
Okay, I'm trying to use this script, but you said to put the apps in fs/data/firstboot/ but where is "fs"? I found the "firstboot.sh" file, but I'm sure I can't put the apk's in there...
In loving memory of my son "Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 :'(
Click to expand...
Click to collapse
If you look at the folder structure inside the SleeperROM zip, you'll see he uses an fs directory to hold his system and data folders for installation. If you're developing a ROM, you can adapt the script to point to wherever your data folder is (most other ROMs just have system and data in the root directory of the zip, so the path would just be data/firstboot/).
EDIT: no need to look in SleeperROM zip, the firstboot zip in the OP has the same folder structure. It just doesn't seem to have the firstboot directory inside data. You'll need to add that.
Sent from my SPH-D700 using XDA App
bbelos said:
If you look at the folder structure inside the SleeperROM zip, you'll see he uses an fs directory to hold his system and data folders for installation. If you're developing a ROM, you can adapt the script to point to wherever your data folder is (most other ROMs just have system and data in the root directory of the zip, so the path would just be data/firstboot/).
EDIT: no need to look in SleeperROM zip, the firstboot zip in the OP has the same folder structure. It just doesn't seem to have the firstboot directory inside data. You'll need to add that.
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Thanks for the reply buddy, so what I THINK your saying is to create a folder called "first boot" in my data folder?
In loving memory of my son" Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 - RIP :'(
sniperkill said:
Thanks for the reply buddy, so what I THINK your saying is to create a folder called "first boot" in my data folder?
In loving memory of my son" Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 - RIP :'(
Click to expand...
Click to collapse
Are you trying to do this in a ROM or on the phone? Sorry if that's a dumb question, but I just want to be sure we're on the same page.
Sent from my SPH-D700 using XDA App
sniperkill said:
Thanks for the reply buddy, so what I THINK your saying is to create a folder called "first boot" in my data folder?
In loving memory of my son" Jeffrey Ryan Giles" 11/17/1992 to 11/25/2011 - RIP :'(
Click to expand...
Click to collapse
bbelos said:
Are you trying to do this in a ROM or on the phone? Sorry if that's a dumb question, but I just want to be sure we're on the same page.
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
i hadn't noticed my zip routine apparently skips empty .folders
in the zip, there SHOULD have been /fs/data/.firstboot into which you place whatever apk files named according to their actual package name i.e. com.keramidas.TitaniumBackup.apk for Titanium Backup, com.alensw.PicFolder.apk for QuickPic and so on...
you can find out this info in Titanium Backup by finding the app in the list and tapping its name to show the data store location.
it HAS to correspond to the actual package name in order to properly back up the data files because the package manager binary as run from a script won't overwrite the data dir so the old data has to be synced back into the new install (rsync)
I am currently refactoring the script to reduce the number of dependencies... the system will then consist of the init.d script, zipalign and rsync bins, and the /data/.firstboot.sh, /data/.firstboot dir all in one place rather than scattered throughout the system.
irule9000 said:
Is it possible for someone to develop an application to backup your personal apps and then running a script in clockwork or on first boot that does the same thing as this, alllowing for personal apps to be in the rom directly after flashing. I understand that sometimes apps may not be compatible, but can randomroms rdu script be modified to choose to do this?
Sent From My Cyan4g
Click to expand...
Click to collapse
it would be possible to create an app to do this, and i considered it because of the need to make sure the android system is fully loaded for package manager to work, but given the requirement for full root access to start running before the system is up without having to worry about android permissions or getting SuperUser approval it's easier/more effective to do it as part of the system init in a script.
as far as randomking's rdu script, they would be compatible, but they exist separately as in one shouldn't interfere with the other, because the firstboot script runs long after install once the system is up and running.
you could modify the rdu setup to include/exclude the /data/.firstboot dir and .firstboot.sh script based on the selected config, since the init script does nothing if it doesn't see the /data/.firstboot.sh file, and the .firstboot.sh script does nothing if it doesn't see the .firstboot dir
SenseiSimple said:
it would be possible to create an app to do this, and i considered it because of the need to make sure the android system is fully loaded for package manager to work, but given the requirement for full root access to start running before the system is up without having to worry about android permissions or getting SuperUser approval it's easier/more effective to do it as part of the system init in a script.
as far as randomking's rdu script, they would be compatible, but they exist separately as in one shouldn't interfere with the other, because the firstboot script runs long after install once the system is up and running.
you could modify the rdu setup to include/exclude the /data/.firstboot dir and .firstboot.sh script based on the selected config, since the init script does nothing if it doesn't see the /data/.firstboot.sh file, and the .firstboot.sh script does nothing if it doesn't see the .firstboot dir
Click to expand...
Click to collapse
Expanding on the rdu script idea, how about a prop variable in the config to specify a user apps directory on the sdcard (best if standardized)? The user can store the apks to be installed after a clean flash in this directory. The rdu script would be modified to copy those apks to the firstboot directory. Although how to handle data? Maybe another script to be run before flashing that checks the apks in the sdcard folder, and copies the current data folder to the sdcard. This data is then restored somehow with the firstboot script. This all can be in addition to the firstboot apps included with the rom.
Sent from my SPH-D700 using XDA App
app
I honestly have no developing experience. To clarify, I was I simply asking if the app could back up the users personal apps/data to the specified folders, to make this script fool proof. Then when a rom is flashed the randomromkings rdu script which currently decides on lite roms or full roms could be modified to either install apps or not install apps depending on the rom compatibility. Finally data is wiped, rom flashes, and your script runs on boot allowing the apps to all be there. Expanding on that if the ROM allows apps to be re installed via your script, through the modified rdu, your script could be moved from one directory to another allowing the process to happen and at the end moves itself back to the original directory. This means that the end user who has no clue how to do anything but flash roms (like myself, but I want to learn) has done nothing accept backing up their apps. I know this is all hypothetical, but would this be possible, and also I have another idea that is probably impossible. If a script could be written so that the apps are backed up when the rom flashes, then the rom automatically does a factory restore and wipes the various caches, meaning that less people are going to have force close issues or other avoidable bugs because they didnt wipe. thanks for all your hard work
Clear Me Here !!
You said that the script (.firstboot.sh) removes itself, but does it remove Y02firstboot script from init.d?? I don't think so, also, there are no disadvantages of this after first boot, as it won't find .firsboot.sh and skip the operation, but why shud it execute unneccesarily everytime??
@OP--Plz. tell me if i am right or wrong.......If right, plz. add a function to remove that script from init.d. However files in /xbin are OK though, so no need to remove them............
Everybody is writing and making this appear as complicated as possible! So let me clarify what I believe the idea is here. First of all, the 'RDU script' I assume you're referring to is simply a flash-able zip to set you phone for a lite or full installation. It sets a config file. I use it in my rom, and I also currently use that config file to set several other features upon installation, and changeable at anytime one of my themes is flashed.
RDU was simply meant to jump start the idea of developers making installations more uniform. Which has happened to various extents, for example, I've used this first-boot install to solve my quickpic(I love the app) and flash pre-install problems. It also fixes usb tether, vlingo, terminal, etc.
SO, what are we saying here? We'd like to be able to backup our apps to the sd card, as many apps can do for us. Then, we'd like to either:
A. Build a script into a rom to restore these apps prior to or upon installation.
or
B. Build a separate script which would be run AFTER a rom installation to restore these apps from CWM.
Yes?
P.S. I see this is very late to the game, didn't realize this thread was being revived...
Still. Neat idea, sorry I hadn't noticed it yet.
+1 Thanks
After integrating this into my custom ROM, my phone (Galaxy S 4G) would only install the first .apk file in the .firstboot directory. After I removed the code which tells it to backup/restore the /data/data directories, it worked fine. I won't need that code since the ROM does a full wipe of /data every time anyway, but I'm not sure why it doesnt work when it's there. I'm not well versed enough with Java's syntax yet to comprehend why.
Also, your first post says that it should record logs to \sdcard\sleeperlog.txt but the script tries to record it to \sdcard\sleeperromlog.txt and neither one of those files actually appear on the sd card.
Edit: I had to remove the check to make sure the .firstboot directory is empty before deleting it, but it works fine on my Galaxy S 4G ROM as long as there are no /data/data directories for the programs I am installing.
does anyone still have a template of this? The link is down.
Edit: nevermind I don't need it anymore.

[MOD] Enable Stock Hotspot on Verizon

I have gotten the built-in wireless tether to work. I know there's been some discussion about getting Wireless tether without FoxFi and similar.
Since we cannot use the recovery method directly, you can still use the tools and everything from it.
So to begin:
Obviously, you must have root for this to work.
1) Download the patch.zip from the original thread. [here: http://forum.xda-developers.com/showthread.php?t=2768837 ]
2) extract the zip to somewhere on sdcard. I extracted mine to the Download folder. You may need to edit the script below to reflect your locations.
3) okay, this part gets a little weird, but bear with me...
Save this code as run.sh in Download folder or wherever you extracted. You can over-write the old run.sh if you save it in toggle folder where original was located-- BE SURE TO EDIT AS REQUIRED
Code:
#!/sbin/sh
cp /mnt/sdcard/Download/toggle/sqlite3 /data/local/tmp/sqlite3
chmod 0777 /data/local/tmp/sqlite3
mount -o remount,rw /dev/block/mmcblk0p23 /system
cp /system/framework/framework-res.apk /system/framework/framework-res.apk.bak
cp /mnt/sdcard/Download/system/framework/framework-res.apk /system/framework/framework-res.apk
/data/local/tmp/sqlite3 /data/data/com.android.providers.settings/databases/settings.db < /mnt/sdcard/Download/toggle/toggles.sql
4) now open up adb on pc (preferred!!! So you can still see progress and if necesary you can undo/alter/fix things) or terminal emulator (untested but should work, may be weird since you have to reboot phone while it's interface is locked up)
Run:
adb shell
su
sh /mnt/sdcard/Download/toggle/run.sh [or where ever you saved it]
5) Your phone will probably lock up now because you've just replaced the framework-res.apk while the system was running.
adb reboot or reboot by other methods.
6) Profit ;]
I DO NOT WARRANTY OR GUARANTEE THIS METHOD. USE AT YOUR OWN RISK
I believe the sqlite edits serve the purpose of showing the icon in the quick settings pull down. Otherwise, just replacing the framework-res.apk with the correct changes is enough: See this thread for the changes needed:
http://forum.xda-developers.com/showthread.php?t=2759119
Incidentally, I was attempting to make the changes on my own and recompile the framework-res.apk, and I must've done something not quite right because the phone hung at the verizon logo. Thankfully adb was up so I was able to remount system as rw to replace the edited framework-res.apk from the original thread OP linked. Interestingly enough, as soon as I finished copying the edited file, the phone continued booting just fine, and I'm posting from the native tethered connection now.
Edit: I was able to do the changes on the framework-res.apk extracted/decompiled from my phone after all. I'm guessing that the phone didn't like deflate method as opposed to store method (no compression) on the resources.arsc file in the apk file. Had to use the 7zip command line tool to save the modified resources.arsc file without compression to the original apk:
7z u -mx0 framework-res.apk.zip resources.arsc
where -mx0 means no compression (copy)
Got it enabled by just replacing the framework-res.apk, and noticed speeds were really slow. I get 1.88mbps on LTE at home (so-so coverage), but only .15mbps on my iPad connected to my phone via Wi-Fi.
I did this: http://forum.xda-developers.com/showpost.php?p=53431713&postcount=9
SO MUCH EASIER than what you guys were doing. :good:
Droid_Evo_8 said:
I did this: http://forum.xda-developers.com/showpost.php?p=53431713&postcount=9
SO MUCH EASIER than what you guys were doing. :good:
Click to expand...
Click to collapse
It's a manner of preference. In terms of overhead, this native method should technically be quicker to enable, as it does not have to wait for the exposed module to intercept the call and return an empty array of apps to execute for the provision check. That being said, we're probably talking miliseconds at most. While I use xposed for other modules sometimes, others might prefer not to, and this native method does not require it.
vacaloca said:
It's a manner of preference. In terms of overhead, this native method should technically be quicker to enable, as it does not have to wait for the exposed module to intercept the call and return an empty array of apps to execute for the provision check. That being said, we're probably talking miliseconds at most. While I use xposed for other modules sometimes, others might prefer not to, and this native method does not require it.
Click to expand...
Click to collapse
I don't know much about adb or terminal emulator so I'm fine with it. :good:
Here's to hoping for an easy tethering mod!
fillyo said:
Here's to hoping for an easy tethering mod!
Click to expand...
Click to collapse
I'm not sure how easier it can get than installing xposed framework + X Tether mod and rebooting, or replacing the framework-res.apk file on your phone with the one listed in the OP... either will work. This of course assumes you have the Verizon model. Replacing the premade framework-res.apk on any other S5 model would probably cause issues and wouldn't solve anything .
I just made it 'harder' on myself by deciding to copy the original framework-res.apk from my phone, and using the latest apktool and aapt to extract the apk, make the modifications, rebuild it, and replace it on my phone (after renaming the original to .bak). I mostly did this to refresh my memory on how to do it as I had done the process with another phone a while back to do the same mod. As I mentioned earlier, the sqlite stuff is only necessary if you want a toggle in the quick settings bar... otherwise you can just go into settings menu and enable it that way.
vacaloca said:
I'm not sure how easier it can get than installing xposed framework + X Tether mod and rebooting, or replacing the framework-res.apk file on your phone with the one listed in the OP... either will work.
Click to expand...
Click to collapse
I don't see the framework-res.apk file in OP, am I missing something? I have no idea how to decompile mine to make changes.
fillyo said:
I don't see the framework-res.apk file in OP, am I missing something? I have no idea how to decompile mine to make changes.
Click to expand...
Click to collapse
It's linked to in step (1). It's inside the zip file that's meant to be flashed in a recovery... however, because our bootloader is still locked, we cannot flash a recovery, so the way to do it is by replacing the framework-res.apk file as the filesystem is live, which as the OP mentions, will trigger a soft reboot as this file is used extensively by Android apps.
vacaloca said:
It's linked to in step (1). It's inside the zip file that's meant to be flashed in a recovery... however, because our bootloader is still locked, we cannot flash a recovery, so the way to do it is by replacing the framework-res.apk file as the filesystem is live, which as the OP mentions, will trigger a soft reboot as this file is used extensively by Android apps.
Click to expand...
Click to collapse
I got the framework-res apk from the zip package, I guess I am a little nervous since this is from a dev edition, correct? Anyone else successfully just replace framework-res from the zip package on their retail Verizon GS5?
fillyo said:
I got the framework-res apk from the zip package, I guess I am a little nervous since this is from a dev edition, correct? Anyone else successfully just replace framework-res from the zip package on their retail Verizon GS5?
Click to expand...
Click to collapse
The OP (presumably), user in post #3, and myself before I did the changes manually.
SO I followed these instructions and this is what i get both from adb and Term Em.
mount: No such file or directory
: Read-Only file systemramework-res.apk.bak
: Read-Only file systemramework-res.apk
/mnt/sdcard/download/toggle/run.sh[8]: /mnt/sdcard/download/toggle/sqlite3: can't execute: permission denied
I use the same folder structure you did, created a download folder and extracted the zip...
Thoughts?
tangoboyz said:
SO I followed these instructions and this is what i get both from adb and Term Em.
mount: No such file or directory
: Read-Only file systemramework-res.apk.bak
: Read-Only file systemramework-res.apk
/mnt/sdcard/download/toggle/run.sh[8]: /mnt/sdcard/download/toggle/sqlite3: can't execute: permission denied
I use the same folder structure you did, created a download folder and extracted the zip...
Thoughts?
Click to expand...
Click to collapse
Seems at least like 2 errors... the mount command can't find the input or output directories, thus you attempt to copy the files and get read-only file system, and it looks like sqlite3 needs to be changed to executable... chmod +x sqlite3
Also make sure you're running as root, obviously.
I saw a similar post int the android development subforum, and they seem to believe you will bootloop if you try to overwrite your framework-res. I chickened out and just did the xposed and x tether mod.
vacaloca said:
Seems at least like 2 errors... the mount command can't find the input or output directories, thus you attempt to copy the files and get read-only file system, and it looks like sqlite3 needs to be changed to executable... chmod +x sqlite3
Also make sure you're running as root, obviously.
Click to expand...
Click to collapse
I am rooted. Here's what i had in my run.sh:
#!/sbin/sh
cp /mnt/sdcard/Download/toggle/sqlite3 /data/local/tmp/sqlite3
chmod 0777 /data/local/tmp/sqlite3
mount -o remount,rw /dev/block/mmcblk0p23 /system
cp /system/framework/framework-res.apk /system/framework/framework-res.apk.bak
cp /mnt/sdcard/Download/system/framework/framework-res.apk /system/framework/framework-res.apk
/mnt/sdcard/Download/toggle/sqlite3 /data/data/com.android.providers.settings/databases/settings.db < /mnt/sdcard/Download/toggle/toggles.sql
NOW does this look right??
#!/sbin/sh
cp /mnt/sdcard/Download/toggle/sqlite3 /data/local/tmp/sqlite3
chmod +x 0777 /data/local/tmp/sqlite3
mount -o remount,rw /dev/block/mmcblk0p23 /system
cp /system/framework/framework-res.apk /system/framework/framework-res.apk.bak
cp /mnt/sdcard/Download/system/framework/framework-res.apk /system/framework/framework-res.apk
/mnt/sdcard/Download/toggle/sqlite3 /data/data/com.android.providers.settings/databases/settings.db < /mnt/sdcard/Download/toggle/toggles.sql
I'm sorry as I'm very new to this.
tangoboyz said:
I am rooted. Here's what i had in my run.sh:
#!/sbin/sh
cp /mnt/sdcard/Download/toggle/sqlite3 /data/local/tmp/sqlite3
chmod 0777 /data/local/tmp/sqlite3
mount -o remount,rw /dev/block/mmcblk0p23 /system
cp /system/framework/framework-res.apk /system/framework/framework-res.apk.bak
cp /mnt/sdcard/Download/system/framework/framework-res.apk /system/framework/framework-res.apk
/mnt/sdcard/Download/toggle/sqlite3 /data/data/com.android.providers.settings/databases/settings.db < /mnt/sdcard/Download/toggle/toggles.sql
NOW does this look right??
#!/sbin/sh
cp /mnt/sdcard/Download/toggle/sqlite3 /data/local/tmp/sqlite3
chmod +x 0777 /data/local/tmp/sqlite3
mount -o remount,rw /dev/block/mmcblk0p23 /system
cp /system/framework/framework-res.apk /system/framework/framework-res.apk.bak
cp /mnt/sdcard/Download/system/framework/framework-res.apk /system/framework/framework-res.apk
/mnt/sdcard/Download/toggle/sqlite3 /data/data/com.android.providers.settings/databases/settings.db < /mnt/sdcard/Download/toggle/toggles.sql
I'm sorry as I'm very new to this.
Click to expand...
Click to collapse
The original script should work assuming the files are in the right path... when I mentioned make sure you are running as root meant, make sure you run the 'su' command and get the # prompt before you run the script, otherwise the script won't run with root permissions and will fail.
For the third line, you (and the OP) can replace the mount command with:
Code:
mount -o,remount rw /system
----
As an aside, the chmod 0777 part in the original script already does mark the file as executable... chmod works with generic +rwx (read,write,execute) distinctions or the regular numbering permissions (777 means rwx for everyone)
Edit: the last line of the script should start with: /data/local/tmp/sqlite3
because that's the one that you set the permissions to rwx, not the one in your sdcard
vacaloca said:
The original script should work assuming the files are in the right path... when I mentioned make sure you are running as root meant, make sure you run the 'su' command and get the # prompt before you run the script, otherwise the script won't run with root permissions and will fail.
For the third line, you (and the OP) can replace the mount command with:
Code:
mount -o,remount rw /system
----
As an aside, the chmod 0777 part in the original script already does mark the file as executable... chmod works with generic +rwx (read,write,execute) distinctions or the regular numbering permissions (777 means rwx for everyone)
Edit: the last line of the script should start with: /data/local/tmp/sqlite3
because that's the one that you set the permissions to rwx, not the one in your sdcard
Click to expand...
Click to collapse
Hmm still no dice... Something isn't working right. Really I wanted the Hotspot in the pull down menu. I am currently paying for hotspot anyway....
Just found that wanam xposed has an option to skip provisioning check. Anyone tried this yet? Seems to enable native tethering but doesn't give a quick settings button.
dlscott1111 said:
Just found that wanam xposed has an option to skip provisioning check. Anyone tried this yet? Seems to enable native tethering but doesn't give a quick settings button.
Click to expand...
Click to collapse
Yes, we have tried it and it works. The quick settings button, as I have mentioned earlier in this thread, is what the sqlite3 executable and the file commands it takes in (just a simple text file of DB commands) take care of. You could also just get sqlite editor ($3 from the play store, IIRC) and do them manually if you don't like command line tools. it's basically adding "WiFiHotspot" to system -> notification_panel_active_app_list_for_reset and notification_panel_default_active_app_list in the settings.db file in /data/data/com.android.providers.settings/databases/
Or you could just do it the free with the command line sqlite3 using the tools already at your disposal

Categories

Resources