DISCLAIMER: I am not the author of this tool!
All credits goes to tommytomatoe and you can press thanks in this thread because there is no dedicated thread for DEXO @xda (at least I found none)
theking_13 said:
thiagomme said:
Why does it give better battery life? Thank you.
Click to expand...
Click to collapse
Because it splits the .apk (app package) into two parts, the .apk and a .odex file. Usually, for the phone to use an app, it has to decompile the .apk and get the parts it needs to run the app. With the odex files, which stands for "Optimized Dex" the startup time is much faster since the phone doesn't have to perform any optimizing at startup/runtime, and because of that, it also uses less CPU power, and thus makes it faster, smoother, and battery life is increased.
Click to expand...
Click to collapse
OK. So what is this tool?
This tool doesn’t deal with partially odexed ROMs. This tool is for odexing a ROM that is completely DEODEX.
The benefits? Faster boot, smaller imprint on /data/ partition, overall faster feeling
The myths? I can’t theme ODEX! WRONG! You can theme odex just fine! Just use baksmali and smali.
Click to expand...
Click to collapse
Requirements:Of the author:
adb
Linux, Mac OS X, Windows
Android device with busybox
Four minutes of your day
Added by me:
You have finally settled on a ROM that you want to use for some time without an intention to modify it further
You will need about 100 MB free space on system (my free space decreased from 160 MB to 96 MB after the completion of the process) To free some you can delete some apps from /system/app or move them to /data/app with a root file explorer (do not forget to set the correct permissions afterwards) or even better: to move your /system/lib folder to the lib partition without reflashing the ROM (see below for details)
Tested on Fallout 5.0 and Virtuous Infinity 1.35 with my Tweaked3 8.6 kernel. If you are using this it is at your own will and risk
NOT WORKING on CoolDroid and Sabsa Prime 6.5, probably because they have mixed framework from different Sense versions! Do not do on other similar ROMs only on ones with an original (even modded) framework!
Procedure:Go here and read carefully. It is basically some adb commands.
Out of respect to the author I will not mirror his link nor the instructions----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------How to free about 120 MB space on /system by moving the lib folder to its dedicated partition without reflashing the ROM
This is only for ICS Sense ROMs. AOSP ROMs have enough free space to run the script without issues. I am not sure about the GB Sense ROMs, but if I remember correct they have enough free space on /system too. (if I am wrong please PM me to add GB Sense boot.img)
Requirements:
Bootloader with /system/lib support: 2.xx or 7.xx
150 MB free space on your SDcard
adb drivers installed (link in my signature)
4EXT Recovery (or any other recovery that has a menu entry for mounting /system/lib partition)
good attention while copy/paste the commands from here. One typo will lead to a bootloop
Download Tweaked3: XI_lib_bootimg.zip
md5sum: 1bc1d645b8212cdb2e4e949c6b7b3312
Download Patched: 3089_lib_bootimg.zip
md5sum: f1ae0228eb4057b4e4c4934a1e8a0515The zips contain boot images of my Tweaked3 and Patched kernels with /system/lib support (I am not advertising them but this are the files I have ready, you can use a Stock kernel as well). There are 4 of them:
Sense4_lib_boot.img - for ALL Sense 4 ROMs (except VIrtuous Infinity)
Sense36_exp_lib_boot.img - for custom Sense 3.6 ROMs with experimental WiFi driver (Experimental kernel)
Sense36_lib_boot.img - for custom Sense 3.6 ROMs with stock WiFi driver (Stable kernel)
Virtuous_lib_boot.img - the name speaks for itself
Extract the archive in the folder where your fastboot executable is. This is not a flashable zip!orDownload 2: b2b_lib_bootimg.zip
md5sum: 4bb4d44506eae5f247b69f9c5663e3a8The zip contains boot images of my B2B kernel with /system/lib support (I am not advertising it but this are the files I have ready, you can use a Stock kernel as well). There are 2 of them:
Sense4_lib_boot.img - for ALL Sense 4 ROMs (except VIrtuous Infinity)
Sense36_lib_boot.img - for custom Sense 3.6 ROMs
Extract the archive in the folder where your fastboot executable is. This is not a flashable zip!NOTE: your ROM has to be on the same version of the kernel before the procedure, otherwise your WiFi will stop working. Or you will need to download the zip from the kernel thread and copy the modules to /system/lib/modules manually giving them right permissions (644 or -rw-r--r--)Procedure:# Connect the device to PC, open Command Prompt (cmd) and browse to the folder where are your adb and fastboot executables are (example: cd C:\android-tools)
# Reboot to Recovery (4EXT recommended)
Code:
adb reboot recovery
# Make a Nandroid backup
# Mount manually /system and /sdcard from the "mounts | storage" menu of the Recovery
# Copy the content of /system/lib to the SDcard
Code:
adb shell
mkdir /sdcard/system
cp -r /system/lib /sdcard/system
# Clean /system/lib
Code:
rm -r /system/lib
# Recreate empty /system/lib and set permissions
Code:
mkdir /system/lib
chmod 755 /system/lib
# Unmount manually /system from the "mounts | storage" menu of the Recovery
# Mount manually /system_lib from the "mounts | storage" menu of the Recovery
# Copy the lib contents to /system/lib
Code:
cp -r /sdcard/system/lib/* /system_lib
# Set permissions to /system/lib
Code:
cd /system_lib
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
[I]# Creating symlinks [COLOR=Red]Only for Virtuous Infinity![/COLOR][/I]
ln -s libhtc_ril.so librilswitch.so
cd hw
ln -s copybit.msm8660.so copybit.msm7x30.so
ln -s gralloc.msm8660.so gralloc.msm7x30.so
ln -s lights.msm8660.so lights.msm7x30.so
# Remove the SDcard /system/lib folder
Code:
rm -r /sdcard/system
exit
# Unmount manually /system_lib and /sdcard from the "mounts | storage" menu of the Recovery
# Reboot to bootloader
Code:
adb reboot bootloader
# Flash the boot.img and reboot
Code:
fastboot erase boot
fastboot flash boot XXX_lib_boot.img
fastboot reboot
Now you can use the tool above without concerns about free space
Enjoy!
amidabuddha, thanks for sharing. Have you tried this?
old.splatterhand said:
amidabuddha, thanks for sharing. Have you tried this?
Click to expand...
Click to collapse
Yes of course. Read the Requirements part
Sent from my HTC Desire S
Ok, i need help, cause i don't do this things often:
Fifth step, run it!
Click to expand...
Click to collapse
What and how?
old.splatterhand said:
Ok, i need help, cause i don't do this things often:
What and how?
Click to expand...
Click to collapse
Read further in the instructions, Theres a complete usage example with all the commands
Sent from my Desire S using xda app-developers app
Gonna try it today on CM10.
Tapatalked from Desire S running Andromadus
teadrinker said:
Read further in the instructions, Theres a complete usage example with all the commands
Click to expand...
Click to collapse
Sorry, my fault! I thought this come after the 5 steps.
if a rom is zipaligned, doesn't this mean that there's no need being odexed - kind of same thing? (same performance, battery life...)
i've read that, but i'm no expert...
toxic-hero said:
if a rom is zipaligned, doesn't this mean that there's no need being odexed - kind of same thing? (same performance, battery life...)
Click to expand...
Click to collapse
Zipaligning is about better RAM utilization. Odexing is about reducing the Dalvik VM which in theory should reduce CPU use and make the system run smoothly. You can watch the video, it is made by one of the Elite Recognized Developers of XDA so this guy probably knows what he is talking about. Moreover ALL Stock ROMs are odexed and I am sure that the companies developers are not just too lame to use it for nothing
tried the above...pasted something wrong and now phone stuck on htc screen and can't get into recovery
mackhenri said:
tried the above...pasted something wrong and now phone stuck on htc screen and can't get into recovery
Click to expand...
Click to collapse
Have you provided enough free space on your system partition? Try with a factory reset.
And once again:
If you are using this it is at your own will and risk
Click to expand...
Click to collapse
i think it was due to less space but still will try it once again after making space
Was a hard task to get enough space free.
Let's see how it works now.
old.splatterhand said:
Was a hard task to get enough space free.
Let's see how it works now.
Click to expand...
Click to collapse
Yes this may be an issue with the bigger ROMs. The easiest way is to move some app that you use rarely to /data/apps
The other way is to use the lib partition but this needs ramdisk modification and a hboot that supports it. It is not hard I may add a small how-to if more users want to use this tool
Sent from my HTC Desire S
amidabuddha said:
Yes this may be an issue with the bigger ROMs. The easiest way is to move some app that you use rarely to /data/apps
The other way is to use the lib partition but this needs ramdisk modification and a hboot that supports it. It is not hard I may add a small how-to if more users want to use this tool
Sent from my HTC Desire S
Click to expand...
Click to collapse
Get it on buddy.....I am ready to try whatever u make as you seem to give life to my phone once again and all the devs here and I am become a flashaholic...
Sent from my HTC Desire S using xda premium
amidabuddha said:
The other way is to use the lib partition but this needs ramdisk modification and a hboot that supports it. It is not hard I may add a small how-to if more users want to use this tool
Click to expand...
Click to collapse
This would b great, I did it once for Fallout with one of your kernel ramdisks, but it was not so trivial and a pain in the a** doing this all by hand. Though it worked perfectly, I don't remember every step I did, and mayb I didn't do it the elegant way, as I'm not very experienced.
As far as I remember the complicated part was unpacking kernel+ramdisk, modifing ramdisk, repacking everything and signing it. But this has to be done only once (by one idividual) for every kernel (+ramdisk). The rest ist more or less flashing and copying from /system to /system/lib partition (can be done in recovery easily). The latter mayb realised with one single script installer for every kernel (and rom) I guess. But here I also lack the experince with script installers, elsewise I would have shared the info.
I did it on Windows with bootimg-tools via Cygwin (unpacking, repacking), with SignApk on cmd (signing), in recovery (flashing, copying). For flashing I guess fastboot is more elegant (reflashed whole rom with mod boot.img). For the rest I didn't found something more convinient, but maybe soemone can enlighten me.
HOW-TO move your /system/lib folder to the dedicated partition added to the first post. Tested and verified working. Just copy the commands carefully
Enjoy!
Thx, the new guide worked like a charm for me on Fallout v5.0.0 with your kernel v8.5. I think it is more or less what I did, when it worked for me before. Also the odexing stuff worked well. What I am just wondering about, as this is odexing Rosie, will this affect the Fallout Tweaks for Rosie? And I tended to use Titanium Backup to merge updated system apps (like Facebook) into rom (essentially moving to system I guess), are there any drawbacks doing it with odexed apps?
kwisatz79 said:
Thx, the new guide worked like a charm for me on Fallout v5.0.0 with your kernel v8.5. I think it is more or less what I did, when it worked for me before. Also the odexing stuff worked well. What I am just wondering about, as this is odexing Rosie, will this affect the Fallout Tweaks for Rosie? And I tended to use Titanium Backup to merge updated system apps (like Facebook) into rom (essentially moving to system I guess), are there any drawbacks doing it with odexed apps?
Click to expand...
Click to collapse
All apps will work the same way after odexing. I can confirm all Rosie tweaks in Fallout working.
As per the Titanium stuff I have no idea try it and let us know
Sent from my HTC Desire S
when I am trying to copy /sdcard/system/lib to /system_lib it is showing not enough space....
Also in 4extrecovery - two system_lib are showing...
Any ideas?
BTW I am on Fallout 5.0...
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.
Update (fix for /cache/dalvik-cache 04-26-2010): Really only use this if your having issues using the symbolic link fixes posted by other members or are just out of free space on /cache. First the new issues people are experiencing is in cm-based-kernels from 4.2.15.x and not JIT enabled DalvikVM and people using danger/death spl will experience problems faster. Lack of space on /cache is a problem and will cause market downloads to fail as well as email attachments. The other problem is the kernel fails for various and unknown reasons to mount bind /cache/dalvik-cache to /data/dalvik-cache.
The other issue is the use to dalvik-cache clearing scripts and options in RA recovery, stop clearing your dalvik-cache, the .dex files are created when missing and you do not get any benefits by doing so and cause more wearing leveling of NAND, plus the script in RA recovery doesn't appear to look at /cache/dalvik-cache for dex files. This little update script (when installed correctly).
Understand that /cache/dalvik-cache is a newer option as a means to free up space on /data is by using /cache/dalvik-cache as a first storage of dex files then using the standard /data/dalvik-cache for over flow of dex files and newer installed apps. Somewhere along the way something may throw this and you get douplicate dex files in both locations, one way to check is to boot into recovery and
Code:
mount -a
and check dalvik-cache directories in both /cache and /data for douplicate dex files.
The script will fix these issues, or should at least:
Endless loop FCs on boot
broken /cache/dalvik-cache mount
no binded mount
missing user apps
missing system apps
failed market downloads
non-working symlink patches and installers (no need to run these, they will break this patch)
fixes duplicate dex files in both /cache/dalvik-cache and <target>/dalvik-cache (because it deletes /cache/dalvik-cache)
Will not Fix:
your ignorance
your unwillingness to read
your unwillingness to learn
your compulsive ROM flashing disorder
your compulsive dalvik-cache clearing syndrome
version 1.1.1(updated 4/27/2010 @ 10:10 PM) is current and was slapped together from Phonekenstein, it doesn't look for the existance of /cache/dalvik-cache it assumes it's there and deletes it wether it's a directory, a symlink or a file, re-creates a new empty /cache/dalvik-cache with Android default permissions and mount binds it to /data/dalvik-cache (be it a directory, a symlink or another binded mount) /cache/dalvik-cache will follow the target /data/dalvik-cache (no worries for apps2sd users or non-apps2sd users).
Script will turn on the blue LED when booting so you know it executed (if it annoys you then edit the script and make it pink)
Tested on Cyanogen MOD 4.2.15.1 and SuperD 1.10.3:
with and without apps2sd
with and without a /dev/block/mmcblk0p2 (apps2sd script nulled)
with and without a custom /dev/block/mmcblk0p4
with mount binded /ext/dalvik-cache (mmcblk0p4) to /data/dalvik-cache
with /data/dalvik-cache as a symbolic link to /ext/dalvik-cache (mmcblk0p4)
All scenarios experienced no failures as long as you set your permissions correctly on all targets and files and /cache/dalvik-cache followed and binded flawlessly.
install is simple and can be done through terminal:
1. download 86dalvik-cache-fix <--Long press and chose "save link as" (also attached to this post)
2. open terminal and issue these commands:
NOTE: COMMANDS ARE CASE sensitive in LINUX and as such ANDROID!!!!!!
ALL OFF THESE COMMANDS ARE IN lower case. SO Turn off your Auto-Caps options in your keyboard options. These command assume you downloaded the script using your the web browser on your G1/Magic whatever phone and the file is located in /sdcard/download (the default location for web browser downloads).
Code:
su
mount -o rw,remount /system
cp /sdcard/download/86dalvik-cache-fix.txt /system/etc/init.d/86dalvik-cache-fix
chown 0:2000 /system/etc/init.d/86dalvik-cache-fix
chmod 755 /system/etc/init.d/86dalvik-cache-fix
sync
reboot
Why 86dalvik-cache-fix? We want the script to execute after all scripts in /system/etc/init.d/ including /system/sd/userinit.sh (if you are using one) and before script 99. 86 because in 1987 everything got 86'd.
If you are having a problem getting the script to execute, copy it or merge it into /system/sd/userinit.sh (even if you aren't using a mmcblk0p2(ext partition)) it may make it work with FastTest builds, however the permissions on his builds appear to be root everything and I have problems getting the script to execute out of /system/etc/init.d even with root permissions.
--------------------------------------------------------------------------------------------------------------
Primer: Read this about Dalvik VM http://en.wikipedia.org/wiki/Dalvik_virtual_machine
Read this to: Google Groups post about JIT compiler for Dalvik VM from Android-Platform Link
From the post we see that this particular compiled library is ALPHA, so results can vary, but from reading most posts in this thread the results are right near the talked about 3x faster code, stability is going to vary on what apps and or widgets are running. More Widgets = slower performance as these have processes that are eating cycles. When testing with Linpack wait for the advertisement to load first then tap the benchmark button and remove your finger from the touch screen. Background process such that interrupt or having auto-rotate enabled while testing is going to give you slower benchmarks.
In short your apps should load faster and run faster, particularly 3D games. The web browser is faster and you can actually scroll through pages even while graphics are still loading.
The reboot when enabling it is long even appearing to hang at the G1 Screen for 5 minutes or more but once it starts booting past this you will know that your ROM is compatible. The cause is that the dex files are being optimized, after about a third reboot, your ROM should feel pretty snappy and launching apps should be quicker as well as switching apps. The snappiness lasts as well and as some may have said that it's a placebo effect are wrong. Bench mark readings prove it and more importantly a few ROM builders have included this in their 2.1 ROMs as experimental.
The libdvm.so that t3steve cross compiled for the DROID at the time was for Android 2.0, the library works for with newer ROMs Android 1.6 that have some eclair pieces built into the kernel, CyanogenMOD has been using bits and pieces for a while now, if other ROM builders have been using his kernel and framework than a good chance it will work for your phone as well.
I have nothing to do with the compiling of this or the exact functions of enabling JIT except that I had a hunch that the combo might work and it did, so I'm sharing it.
If you aren't good at typing in commands, or don't know how to extract a zip file and understand that a sub folder may or may not exist where you have extracted said zip file to, well.... you may run into some issues, maybe a video tutorial for basic command line on youtube would be a good place to learn.
I wanted to make a very detailed post on www.andoidonroids.com about how to mash the JIT enabled Dalvik VM library into Android 1.6 Donuts I'm calling the hack "Dusted Donuts" and take from the name for what you will. I have been using the JIT enabled Dalvik VM for about two weeks and i runs decent but not perfect. Anyhow a death in the family Sunday has kept me from making a decent post and haven't had the time to get to the website and post and cross post and give credit where due.
No doubt that aaraya1516 broke the news on http://forum.xda-developers.com/showpost.php?p=5703076&postcount=193 as he was first to break the hack on FastTest, not taking anything away from him on that.
My testing goes back two weeks or more even during the 580mhz & 780mhz hack, I was waiting for someone to compile a boot.img with some 2.x stuff and sure enough the carlospants boot.img from ctso worked with enabling JIT for Dalvik VM, but as we know now the overclocking doesn't work at the moment.
Thank Cyanogen and t3hSteve of which may not know that this was entirely possible. Cyanogen mixed in enough Eclair into his Donuts (he's like Willy Wonka) that makes it possible to use the cross compiled JIT enabled Dalvik VM library from 2.1 for the Motorola DROID 2.0.1 libdvm.so that t3hSteve of www.alldroid.com compiled for the custom roms on Droid.
WARNING: Using other methods supplied from other forum members that include replacing the build.prop may cause problems, using the build.prop from the original VMLIBS.ZIP (which is here for reference and original source for libdvm.so) is definitely going to cause ROM and application problems. Hello....use your head here... the VMLIBS.ZIP is for Motorola DROIDS, why would you put the build.prop file for a DROID on your G1 and expect your apps or ROM to work afterwards? It's so simple, you need 1 file, it's called libdvm.so it goes in /system/lib a file by the same name already exists there and it's in your best interest to at least back it up before overwriting it and gives you the ability in the event that your system doesn't boot up you can restore it through recovery console and get your phone to boot past the G1 screen.
FYI: Some ROMs have the option dalvik.vm.execution-mode=int:fast in the /system/build.prop file, this would need to be changed to dalvik.vm.execution-mode=int:jit or commented out or deleted. If you want to play with advanced options create /data/local.prop and fiddle in there with options available from typing dalvikvm -h in your console or terminal app.
Required:
1. Android 1.6 ROMS with a bit Eclair stuff in the Kernel and framework such as Cyanogen ROM 4.2.x, Super D 1.8 - 1.92, WG Y2.6, FastTest, KingKlick Eclair and more.. This libdvm.so works on Android 2.1 as well as it seems it should.. 1 st bootup is slow and I recommend you let it sit even when desktops are up for a couple of minutes and then reboot it, 2nd and 3rd bootups are faster and smoother response overall even for long durations, days.
FIX YOUR FILE SYSTEM FIRST !!!!!! Got to do it from Recovery Console, It's partly the cause of poorly running ROMS and takes seriously longer to type the command than to fix your unknowingly faulty file system. EXT2 is the worst offender and the built in function to repair falls short, even more so when checking EXT4.
Code:
#e2fsck -fcpDC0 /dev/block/mmcblk0p2
#reboot recovery
For the lazy fingers
#e2fsck -fcpDC0 /*/*/*0p2
#reboot recovery
1. Download www.androidonroids.com/dusted-donuts (File has 3 scripts backup, install, restore, 2 folders, 1 libdvm.so)
2. Extract zip to root of /sdcard or where ever you like (the zip has a folder containing the files named dusted-donuts)
3. Open Terminal or go to Recovery Console
FYI when running the install through Terminal your system may freeze or reboot and if it does I highly recommend that you prepare to enter Recovery Mode and check your file system. EXT2 corrupts quickly choosing this for apps2sd to use is not the best option especially if you are using custom ROMs that may lockup or reboot, basically that's a crash.
Code:
$su
#mount -o rw,remount auto /sdcard
#cd /sdcard/dusted-donuts
#sh backup
#sh install
#sync
#reboot
Check the Dalvik VM execution mode. look at the bottom line with_jit means the it is installed , and look at all of those options that can be jammed into your build.prop and local.prop files
Code:
$su
#dalvikvm -h
Phone won't boot past G1 screen? Go to recovery console and restore libdvm.so (give it at least 5 minutes first before giving up)
Code:
#mount -o rw,remount auto /sdcard
#cd /sdcard/dusted-donuts
#sh restore
#sync
#reboot
---------------------------------------------------------------------------------------------------------------------
prefer to use VMLIBS.ZIP from t3hSteve? This is how you can install using that.
Required:
1. Android 1.6 ROMS with a bit Eclair stuff in the Kernel and framework such as Cyanogen ROM 4.2.x, Super D 1.8 - 19.2, WG Y2.6, FastTest, KingKlick Eclair and more.. This libdvm.so works on Android 2.1 as well as it seems it should..
How to install: (easier to go in recovery mode but can be done through terminal)
1. Download the VMLIBS.ZIP from t3hSteve of allroid.com http://alldroid.org/download/file.php?id=1374
2. You only need the libdvm.so file of which appears to be JIT enabled by default.
3. Backup the original libdvm.so #cp /system/lib/libdvm.so /sdcard/libdvm.so
4. Copy the JIT enabled libdvm.so #cp -f /sdcard/vmlibs/libdvm.so /system/lib/libdvm.so
5. Set permissions on the file #chmod 644 /system/lib/libdvm.so
Optional for disabling: (easier to do vi through recovery console, since the back key escapes out of terminal)
To disable JIT MODE but want to keep the libdvm.so create a local.prop in /data and add dalvik.vm.execution-mode=int:fast
#vi /data/local.prop
press the i key to enter vi interactive mode
type dalvik.vm.execution-mode=int:fast
press back key to exit vi interactive mode
to write the file out and quit vi type :wq
or
restore your backed libdvm.so file from the sdcard.
-----------------------------------------------------------------------------------------------------------------------
Enjoi! the dusted donuts,
-Licknuts (me? I'm like Varuca Salt, I want another pony)
Vendor G1 roms around 1.2 Mflops, Custom G1 roms are around 2.4 MFlops/s and with JIT compiled Dalvik VM 3.6 MFlops/s. At most you will see 3.5 MFlops/s fairly consistently with a minimal load on your system and highs at 3.7 Mflops/s. Test before and after using Linpack from the Market, it's free.
The 13.236 Mflops/s is not normal and you will probably not see with your testing, I have seen 5.x & 7.x but these are far and few between and this took a while with tweaked configurations/settings with a persistent app to kill processes, it is attainable and I hope a ROM developer finds the sweet spot to exploit.
Looks nice.
Pre-JIT enabled: 2.194 Mflops/s
Post-enabled: 3.459 Mflops/s
Not quite getting the results you have there.
Running SuperD 1.9.2 Black W/ Nexus Theme. I copied it twice to make sure that the libdvm.so was copied correctly to the directory. Rebooted the phone, same results. Looks very promising though. If I did something wrong, lemme know.
Managed to get #10 on G1 Benchmarks with 3.583 Mflops/s... still nowhere near 13.~ Mflops/s
same here. Running Super D 1.9 on my magic
before JIT I got 1.xxxx Mflops/s
after i have 2.xxxx Mflops/s
how do you get the 13 Mflops/s ?
-edit-
with swap disabled i'm getting 3.5 Mflops/s
h.nocturna said:
Looks nice.
Pre-JIT enabled: 2.194 Mflops/s
Post-enabled: 3.459 Mflops/s
Not quite getting the results you have there.
Running SuperD 1.9.2 Black W/ Nexus Theme. I copied it twice to make sure that the libdvm.so was copied correctly to the directory. Rebooted the phone, same results. Looks very promising though. If I did something wrong, lemme know.
Managed to get #10 on G1 Benchmarks with 3.583 Mflops/s... still nowhere near 13.~ Mflops/s
Click to expand...
Click to collapse
I got 9 seconds on the pi benchmark
What will this do??
samsara00 said:
same here. Running Super D 1.9 on my magic
before JIT I got 1.xxxx Mflops/s
after i have 2.xxxx Mflops/s
how do you get the 13 Mflops/s ?
-edit-
with swap disabled i'm getting 3.5 Mflops/s
Click to expand...
Click to collapse
So I guess this only works with Swap off?
sabin123 said:
What will this do??
Click to expand...
Click to collapse
Speed your *hit up!
it works with and without swap.
Just the benchmark result is better when swap is turned off.
Got nearly the same as samsara00:
Rom: SuperD 1.9.2
Before (swap off): ~ 2.3 MFlops/s
After JIT enabling (swap off): ~ 3.5 MFlops/s
But the increase to 13.x seems so unreal, why is there only one result that high in the toplist of greene.com!?
Now to find out if this actually speeds up everyday use lol
CM4.2.14.1
Before: 2.3
After: 3.5
Wow! This made my 3G connection faster too. Was only getting 1500kbps before, now getting on average 3200kbps. Awesome. I'm located in Toronto, on Rogers.
Question: Is this Google's JIT? Will Myraids Dalvik Turbo be faster?
Doesn't boot past the G1 screen when using Dwangs 1.17.1 Assume thats because it has no Eclair in it, but it was worth the dream .
Waw!! great works!!
left is before - right one is after
on CM 4.2.14.1, enabled Swap 64MB, CC ON, RAM Hacked
So do we copy the zip to the root of our sd card? Do I extract it first and just copy the one file? The instructions are kind of vague.
G1ForFun said:
So do we copy the zip to the root of our sd card? Do I extract it first and just copy the one file? The instructions are kind of vague.
Click to expand...
Click to collapse
Not to be rude, but if you don't understand those directions, this isn't the sort of thing you should try to do yourself. Wait for a ROM builder to add this in. The directions are perfectly clear, you just need to understand command line use.
If you want to learn something about CLI use, install Linux on your computer and learn to use it without the GUI. If you don't want to do that, google for "cygwin" and use the bash shell they provide for Windows based machines.
Personally, I used adb and just pushed the darn file lol works perfectly fine, like everything else I've ever pushed. Just don't forget to set the permissions for the file.
tried in a terminal and with adb getting read-only file system when trying to copy over the libdvm.so file
SilentTweak said:
Personally, I used adb and just pushed the darn file lol works perfectly fine, like everything else I've ever pushed. Just don't forget to set the permissions for the file.
Click to expand...
Click to collapse
Nothing wrong with adb. Hell, I used SSH to do it. Just about anything will work, you just have to know what you're doing.
Damn.... I just rebooted and it took about half the time it used to.
Tried the Linpack benchmark, getting about 3.5 with SuperD 1.9.2 w/Compcache 16M swappiness=10. Fresh reboot, obviously. Lock your CPU to 528 (min and max) for more consistent results. When I have 128min 528max, it gives different results depending on the current CPU speed. SetCPU or Overclock Widget helps a lot here. No instability noticed yet, but this should probably be considered an unstable hack for now till we all get more experience with it. I know OpenEclair removed the JIT VM because of stability problems.
Sgt.EddieWinslow said:
tried in a terminal and with adb getting read-only file system when trying to copy over the libdvm.so file
Click to expand...
Click to collapse
Do "adb remount" first
ttabbal said:
Not to be rude, but if you don't understand those directions, this isn't the sort of thing you should try to do yourself. Wait for a ROM builder to add this in. The directions are perfectly clear, you just need to understand command line use.
If you want to learn something about CLI use, install Linux on your computer and learn to use it without the GUI. If you don't want to do that, google for "cygwin" and use the bash shell they provide for Windows based machines.
Click to expand...
Click to collapse
Obviously they are not clear to me. Why argue the point?
I have worked plenty with cmd type interfaces...so please...put down your know it all stick and be helpful.
edit: hope this helps somebody else...look better instructions posted in the fasttest thread!
download files here and copy them on the sdcard
created a folder /sdcard/jit and put the three files in it
make a folder /sdcard/dalbk and copy the original files
adb pull /system/build.prop .
Open in WordPad/Textpad and add as the last line: dalvik.vm.execution-mode=int:jit
SAVE IT, copy/push it on the /sdcard/jit folder
Sgt.EddieWinslow said:
tried in a terminal and with adb getting read-only file system when trying to copy over the libdvm.so file
Click to expand...
Click to collapse
Code:
C:\Android\tools>adb shell
# su
su
# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# chmod 777 /system/lib/libdvm.so
chmod 777 /system/lib/libdvm.so
# cp -f /sdcard/vmlibs/libdvm.so /system/lib/libdvm.so
cp -f /sdcard/vmlibs/libdvm.so /system/lib/libdvm.so
# chmod 644 /system/lib/libdvm.so
chmod 644 /system/lib/libdvm.so
# reboot
Damn.... I just rebooted and it took about half the time it used to.
Click to expand...
Click to collapse
Indeed
Licknuts result : 3.1-3.5 (with Super-D 1.9.2)
My method of installing it:
adb remount
adb push libdvm.so /system/lib/libdvm.so
Then open console and type:
su
chmod 644 /system/lib/libdvm.so
reboot
I'm about to try this myself.. has anyone noticed an overall increase in speed? Benchmarks are great but it's all about how it actually performs!
I'll post my own findings in a bit.
23/9/2010 12:00 I've been to the Chinese Mid-Autumn Festival. Who want flashable ROM zip file will be try:http://forum.xda-developers.com/showthread.php?t=742371 or http://forum.xda-developers.com/showthread.php?t=789830, thanks to NeoPhyTe.x360 and robocik!
fastboot video:http://www.youtube.com/watch?v=fipvwzuNyEE
download url:http://www.multiupload.com/AVHZ2WJ4M4
mirror url:http://vipme.com/ROM/desireHD/, thanks to zexbig.
This is NOT a flashable zip file.
It is a file collections for ROM Dev.
09-22 15:48 update patch:fix gps FC & vold issue & Youtube HD no video issue:http://www.megaupload.com/?d=7YJ6B7UR
flash it with ROM Manager or recovery menu.
Known issue:
1.camera can not work
2.Location,CarPanel FC sometimes.
Thanks all Dev from XDA! This file pack is based on DesireHD leaked RUU/Dump.
Requirement:
1.Desire Phone
2.custom recovery(AmonRA,ClockWork)
3.parted SDCARD with ext2/ext3, ext partition size not less than 512M.
4.radio version great than 32.42.00.32U_5.09.00.08
use it with follow step:
1.unzip the ownhere.DesireHD.zip
2.reboot your desire phone to recovery mode,for example:"adb-windows.exe reboot recovery"
3.wipe data,system,sd-ext
4.adb connect to phone, for example:"adb-windows.exe shell"
Code:
mkdir /sd-ext
mount /sd-ext
mount /system
mount /sdcard
5.push ownhere.desirehd.system.tgz,ownhere.desirehd.sd-ext.tgz,ownheredesire_v2.0_acekernel.zip to /sdcard
for example:
Code:
adb-windows.exe push ownhere.desirehd.system.tgz /sdcard/
6.adb connect to phone
Code:
cd /system
rm -r *
tar zxvf /sdcard/ownhere.desirehd.system.tgz
cd /sd-ext
rm -r *
tar zxvf /sdcard/ownhere.desirehd.sd-ext.tgz
sync
lost+found may be error, ignore it.
7.flash ownheredesire_v2.0_acekernel.zip with recovery menu.
8.reboot,the first boot time is long, about 5 mins.
you got it.
removed file:
Code:
Facebook
Twitter
teeter
Metal(skin)
Black(Skin)
Wood(Skin)
Flash
Maps
Quickoffice
all of these files can be found in Market or leaked RUU.
modified file:
Code:
Vending(Market)
/system/lib/hw/
/system/lib/egl/
build.prop
and some files i forgot...
all of these files can be restore from leaked RUU(But may be crash the system)
HOWTO extract file from DesireHD leak RUU 2.15:
run RUU_Ace_HTC_WWE_1.15.405.1_Radio_12.21.60.12_26.02.00.09_M_test_148662.exe in Windows box.Then some dialog appear(which include a 'next' button), look for your windows' temp dir, search the newest dir created by RUU, then copy rom.zip(about 277M) to another dir(or RUU will delete it automaticly).
send this rom.zip to Linux box,
in Linux box, unzip rom.zip, then
Code:
mkdir system
mount -o loop,ro system.img system
all files in system dir. you can simply copy files from it.
Ouch
I was hopeing for a flashable ROM ....
Well thx a lot man, now devs will be able to develop some great HD ROM
Would love to, Except I'm not Brave Enough
Excellent Work, Well Done!
KYI
first!
WELL DONE
edit: wasn't fast enough damn
sweet dude
Wow ! Thanks !!! :d
Thanks for sharing
ash1684 said:
Ouch
I was hopeing for a flashable ROM ....
Well thx a lot man, now devs will be able to develop some great HD ROM
Click to expand...
Click to collapse
It's because he is using the Sdcard as an extended System ftom what i know at least
can someone report if it works before i try
and ownhere take your place amoungst the xda legends
LOL rapidshare is already going 150 secs for a dl... they are getting overtaxed i advise everyone to use Megaupload... only 30 sec wait
Trying this now!
any one installed this ?
apologies for having doubted about you!!!GREATE job!
How is it working?
great now I need to learn adb but thanks now I can laugh at my cousin with cs hd
2
can anyone report on whats working and whats not?
NickChaplin said:
can anyone report on whats working and whats not?
Click to expand...
Click to collapse
according to the op everything works apart from camera app, neo said he will look into fixing it tho
AndroHero said:
according to the op everything works apart from camera app, neo said he will look into fixing it tho
Click to expand...
Click to collapse
am i correct in assuming that this rom doesnt have root access?
please make flashable zip
NickChaplin said:
am i correct in assuming that this rom doesnt have root access?
Click to expand...
Click to collapse
op said it rooted with apps2sd
If you are like me and you like your stock Desire rom, you rooted it using unrEVOked or some other methods, you made some custom adjustment to it and you really don't want to load a fully fledged 3rd party rom but still, you'd like to tweak it a little bit more, you'll quickly realize that you are going to need a working init.d system in order to start custom scripts on boot.
This thread will try to explain how to add init.d support to your rom, without needing to flash a new rom and wipe everything, we're just going to flash a new boot.img.
Requirements
Rooted HTC Desire
New modified boot.img, supported firmware versions: 2.10.405.2, 2.29.405.2/5, check your firmware version here: (Settings -> About Phone -> Software information -> Software number)
Download this one: View attachment boot_2.10.405.2.zip if your "Software number" is: 2.10.405.2
Download this one: View attachment boot_2.29.405.2_5.zip if your "Software number" is: 2.29.405.2 or 2.29.405.5
Make sure you download the one matching your "Software number", the wrong one will cause boot loops and weird behaviors.
ADB shell access
flash_image binary, usually provided by unrEVOked under /data/local/flash_image but if you don't have grab it here: View attachment flash_image.zip
busybox correctly installed under /system/xbin
HOW-TO
NOTE: if your Desire is not S-OFF (meaning you can't write to the /system directory), you'll need to do the whole procedure in recovery mode.
Do a nandroid backup, this in order to save your current boot.img, and also because it's never a bad idea
Make sure the nandroid backup went ok
Check your exact firmware version (Settings -> About Phone -> Software information -> Software number) and download the corresponding modified boot.img
Copy and unzip the downloaded boot.img to your sdcard or wherever you like it
Obtain adb shell access, become root (su) and wipe the existing boot image with:
Code:
cat /dev/zero > /dev/mtd/mtd2
ignore the "write: No space left on device", it's normal.
Flash the new boot image:
Code:
flash_image boot /sdcard/boot.img
where "/sdcard/boot.img" is the path where you copied the downloaded boot.img
Remount the /system partition read-write if you're not in recovery mode:
Code:
mount -o remount,rw /system
or mount it if you are in recovery mode:
Code:
mount /system
Create the init.d directory where all the custom boot scripts will be executed:
Code:
mkdir /system/etc/init.d
and set permissions:
Code:
chmod 755 /system/etc/init.d
Important: unzip and copy the View attachment 99complete.zip script to the newly created /system/etc/init.d/99complete, set permissions:
Code:
chmod 755 /system/etc/init.d/99complete
and ownership:
Code:
chown root.shell /system/etc/init.d/99complete
Failure to do so will cause a boot loops.
Cross your fingers and reboot! If anything goes wrong you can always boot into recovery and fix errors or you can restore the nandroid backup (you can just restore the boot.img if you don't want to do a full restore).
From now on, every script you put inside /system/etc/init.d will be executed at boot before almost any other initializations. Make sure you set the correct permissions to your scripts (i.e. 755).
Thanks to: teppic74 for providing stock roms with init.d support (thread) where I extracted the boot images.
Technical explanation
The provided boot.img are the original HTC provided boot.img with the init.rc script modified to stop the init process until the cm.filesystem.ready property is set to 1:
Code:
start sysinit
on property:cm.filesystem.ready=1
class_start default
where the sysinit service is the service in charge of starting all the scripts inside /etc/init.d:
Code:
# Execute files in /etc/init.d before booting
service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
disabled
oneshot
and the last of this script, 99completed, only sets that property to 1 so the normal system boot can continue:
Code:
#!/system/bin/sh
sync;
setprop cm.filesystem.ready 1;
of course changing init.rc is only possible by flashing a new boot.img with init.rc modified inside the ramdisk because that file, even if you can see it under / will be overwritten at every boot.
Another small modification of the new boot.img is the default.prop, in which rc.secure is set to 0 allowing to gain direct access through "adb shell"
Sounds great
Thx for your work!
So if I get that right, it's the same as if we'd flash teppic74 ROM, and nandrestoring everything except system & boot?
Just our stock ROM with init.d support?
Does that also mean we could flash the optional mods from teppic74 thread like a2sd?
Ty again!
Puenos said:
Sounds great
Does that also mean we could flash the optional mods from teppic74 thread like a2sd?
Ty again!
Click to expand...
Click to collapse
Well you could but effectively all you need is an apps2sd+ script and you can adb push it to the correct location. /system/etc/init.d
Really? I would have tried flashing either a2sd provided in teppic74's thread or even a2sd script by DT? last I would have compared to firerat's script. But if all you need to do is pushing via adb.. Is there a script out for a2sd especially for stock/sense? (like kali advised using firerat with CM?)
Thank you
Not sure to be honest, I haven't used sense for a long time. But assume if the one teppic uses on his, works - it should work for you too.
I'm just using Sense because of it's Mail-widget, haha
But I guess I'll just give it a try then, will report back, when I've managed so set everything up without having my phone exploding, hehe
But thank you very much
exactly this boot.img will just enable init.d support, no need to flash a new system.img but you just need to create the init.d directory and put the 99complete script, after that you can install any mod you like, also the ones provided in teppic74's thread.
You can also try data2whatever by melethron (that's what I'm using), just make sure you have busybox correctly installed.
hope you enjoy it and happy new year!
well I hv software number 2.11.832.3 so what I hv to do...?
r3vb07inf said:
well I hv software number 2.11.832.3 so what I hv to do...?
Click to expand...
Click to collapse
unfortunately I don't have a boot.img for that software number, you'll need to manually extract your boot.img, modify a file (init.rc) and reflash it, if you don't know how to do it I can try to do it for you but I'll need a download link for your original firmware version
You could make a universal (froyo) update zip using Koush's AnyKernel installer, then you're able to update the ramdisk only and add the init.d folder/script. Thats how i did it for CM7.
worstenbrood said:
You could make a universal (froyo) update zip using Koush's AnyKernel installer, then you're able to update the ramdisk only and add the init.d folder/script. Thats how i did it for CM7.
Click to expand...
Click to collapse
interesting, an update script that can extract the boot.img, unpack, change files, repack it and reflash it...is it safe? I may think about building an update.zip this way but I'm pretty scared by how safe it can be to automatically mess with a boot.img..
EDIT: one problem of this is that the init.rc needs to be extracted and modified, but it may be different from one firmware and another
moebius83 said:
interesting, an update script that can extract the boot.img, unpack, change files, repack it and reflash it...is it safe? I may think about building an update.zip this way but I'm pretty scared by how safe it can be to automatically mess with a boot.img..
EDIT: one problem of this is that the init.rc needs to be extracted and modified, but it may be different from one firmware and another
Click to expand...
Click to collapse
Should be the same between all froyo rom's. Check this update zip, it's for gingerbread tho, you have to replace the ramdisk-new.gz with a froyo one (with edited init.rc offcourse). It also contains /system/etc/init.d/99complete.
Edit: Don't be scared, everyone who releases custom kernels uses this method. The other way around then, keep the original ramdisk and merge it with the new kernel.
Hello there
Really appreciate all your efforts
Kindaa feeling real dumb in comparison! lol
Anyways
My Desire specs :
2.2
2.32.415.3
Baseband 32.49.00.32U_5.11.05.27
Now this has built in arabic enabled support and that is the main reason I would like to keep it
Am yet to run into a custom ROM that would provide that without having to downgrade my version
Also, had a lotta fun trying to root, just couldn't root, up untill a few days back when unrevoked came out with thier new 3.3 version
I noticed you had only two software versions from which to start...
So what about my case? could you please help this newbie along?!!
docnasef said:
Hello there
Really appreciate all your efforts
Kindaa feeling real dumb in comparison! lol
Anyways
My Desire specs :
2.2
2.32.415.3
Baseband 32.49.00.32U_5.11.05.27
Now this has built in arabic enabled support and that is the main reason I would like to keep it
Am yet to run into a custom ROM that would provide that without having to downgrade my version
Also, had a lotta fun trying to root, just couldn't root, up untill a few days back when unrevoked came out with thier new 3.3 version
I noticed you had only two software versions from which to start...
So what about my case? could you please help this newbie along?!!
Click to expand...
Click to collapse
Same thing happens to me. My spec:
2.2
2.13.707.1
32.44.00.32U
Can you help as well? Or where or how (from RUU) can I find the ramdisk-new.gz as worstenbrood's mention.
mumu_li said:
Same thing happens to me. My spec:
2.2
2.13.707.1
32.44.00.32U
Can you help as well? Or where or how (from RUU) can I find the ramdisk-new.gz as worstenbrood's mention.
Click to expand...
Click to collapse
Thanks "worstenbrood" then I can extract boot.img from stock rom. Based on the guide, I made a new boot.img. But with this new boot.img, the phone hangs at the first screen(waiting at least for 15 mins). I don't know why. I also did as worstenbrood suggest and the system boot loopless.
Can somebody help?
I attached my boot.img (original and modified) for your information.
mumu_li said:
Thanks "worstenbrood" then I can extract boot.img from stock rom. Based on the guide, I made a new boot.img. But with this new boot.img, the phone hangs at the first screen(waiting at least for 15 mins). I don't know why. I also did as worstenbrood suggest and the system boot loopless.
Can somebody help?
I attached my boot.img (original and modified) for your information.
Click to expand...
Click to collapse
did you create the /system/etc/init.d directory and the 99complete file with the correct permissions? as noted on the OP this is needed because that file will tell the boot process to continue, otherwise you'll be stuck at the boot screen
EDIT: also, do you have busybox installed under /system/xbin?
docnasef said:
Hello there
Really appreciate all your efforts
Kindaa feeling real dumb in comparison! lol
Anyways
My Desire specs :
2.2
2.32.415.3
Baseband 32.49.00.32U_5.11.05.27
Now this has built in arabic enabled support and that is the main reason I would like to keep it
Am yet to run into a custom ROM that would provide that without having to downgrade my version
Also, had a lotta fun trying to root, just couldn't root, up untill a few days back when unrevoked came out with thier new 3.3 version
I noticed you had only two software versions from which to start...
So what about my case? could you please help this newbie along?!!
Click to expand...
Click to collapse
@ moebius83
If you could help, I would really appreciate it...
Please take into consideration That I am more or less android dumb!
I attached the url for my original RUU if that helps?
http://www.mediafire.com/?ih3lbbm7yfag7d2
Would REALLY appreciate your help.
Thanks m8!
mumu_li said:
Thanks "worstenbrood" then I can extract boot.img from stock rom. Based on the guide, I made a new boot.img. But with this new boot.img, the phone hangs at the first screen(waiting at least for 15 mins). I don't know why. I also did as worstenbrood suggest and the system boot loopless.
Can somebody help?
I attached my boot.img (original and modified) for your information.
Click to expand...
Click to collapse
i created a update.zip which replaces the ramdisk only and add /system/etc/init.d/99complete. It should work for every froyo release.
worstenbrood said:
i created a update.zip which replaces the ramdisk only and add /system/etc/init.d/99complete. It should work for every froyo release.
Click to expand...
Click to collapse
great job, I was just going to make the same update.zip, you were faster, I'll link it on the OP, thanks again!