Related
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.
I made this shell script to automatize the odexing process and maybe it could be useful to someone else.
It should be universal, but I only tested it on my phone.
It's not to re-odex a deodexed rom, but to make stock roms compatible odexed files from deodexed files.
Some mods won't work (signature issues I think)
How to use it:
Extract the attached zip wherever you want on your phone.
In the same directory of the script 'odexer.sh' and the directory 'odextools', make a directory named 'deodexed' (actually, it's already there). Inside 'deodexed' create two directories: 'framework' and 'app'. Put there your modded files, each in the respective directory.
You need the original stock odexed files (apk and odex) and all the '$BOOTCLASSPATH' files (see the note below). The script was intended to be used on odexed rom, but I made it adaptable: in the script change the variable 'moddedpath' with the path to the directory with the original odexed files, each inside 'app' or 'framework (you can directly copy '/system/framework/' and '/system/app/' from a stock rom if you are too lazy).
(I only tested this script on my odexed stock rom using /system as 'moddedpath')
Here how the directory tree should look like:
Code:
/some/random/path/
|-[COLOR="BLUE"]deodexed[/COLOR]
|---[COLOR="BLUE"]app[/COLOR]
|-----[COLOR="RED"]SystemUI.apk[/COLOR]
|---[COLOR="BLUE"]framework[/COLOR]
|-----[COLOR="RED"]framework.jar[/COLOR]
|-[COLOR="GREEN"]odexer.sh[/COLOR]
|-[COLOR="BLUE"]odextools[/COLOR]
|---[COLOR="GREEN"]busybox[/COLOR]
|---[COLOR="GREEN"]dexopt-wrapper[/COLOR]
|---[COLOR="GREEN"]zip[/COLOR]
You need to run the script as root from 'adb shell' or 'Terminal emulator'.
If you put the script in your vfat formatted sdcard, you won't be able to change its permissions, so, in order to run it, you need to pass its path to 'sh' as argument:
Code:
sh /sdcard/somepath/odexer.sh
It will create in the same directory a directory named 'odexed-DD-MM-hh.mm.ss'.
The script will automatically skip files with no odex (framework-res.apk should be always skipped, I think).
It's important to keep everything in the same place, because I used relative paths in the script.
Enjoy
________
To see your $BOOTCLASSPATH files, run from 'adb shell' or 'Terminal emulator:
Code:
echo $BOOTCLASSPATH
or open your /init.rc
Thank you
Thank you for guide. But some points were gone over my head
I found this one. Its one of the simplest method.
forum.xda-developers.com/showthread.php?t=1348062
vishal24387 said:
Thank you for guide. But some points were gone over my head
Click to expand...
Click to collapse
Which point? This?
It's not to re-odex a deodexed rom, but to make stock roms compatible odexed files from deodexed files.
Click to expand...
Click to collapse
loSconosciuto said:
Which point? This?
Click to expand...
Click to collapse
actually I am noob in case of android's coding technical language. Its not ur fault
WHAT IS THIS, AND WHAT IS IT FOR?
This is a guide for creating a new odex file from a deodexed file, one at a time – manually, or with the tool provided. There are tools/methods for doing the entire system at once, but I have not had any luck with those. Plus, typically, one does not need the entire system re-odexed. This is more for those who want to personally mod their stock odexed systems, or create an odexed ROM maybe.
For starters, you can get away with modding a lot on an odexed system, without needing to deodex. You really only need to deodex in order to edit the smali files within the classes.dex (which is required to achieve the cooler mods). See cogeary’s great guide for deodexing tips.
-------------------------
SCRIPT METHOD (using the 1by1_ReOdexer):
I made this script to speed up the process a little bit (thanks! to jimbridgman and cogeary for their input).
NOTE: This could hurt your phone if you don't place your original files (the ones that are currently running on your odexed system) in the 'orig-odexed' folder…
Requirements:
Windows OS (for now – Linux coming soon)
odexed system
root
busybox installed
DOWNLOAD the 1by1_ReOdexer_v2.0.zip for Windows
Unzip it on your desktop or other convenient place (with no spaces in the file path), and read the README.txt.
NOTES
-It will show a few failed processes right when the script starts - it's just trying to clean stuff that isn't there..
-This will not push the new modded files to your phone - but, the re-odex process needs to take place in the /system, so this script does a quick switcheroo by pushing the deodexed file to your running odexed system, then replaces the originals (that's why you must place copies of the odexed ones from your system to the 'orig-odexed' folder - I plan on automating that too eventually) - that's also why you may need to reboot afterwards to straighten things out
-It still needs A LOT of work... but it does the job
MAJOR NOTE: The script is currently set up based on Motorola’s ICS bootclasspath.
To change the file name/path and/or the bootclasspath, right-click on the .bat file and open with a text editor (preferably something like Notepad++) and edit accordingly. The bootclasspath was taken from /init.rc.
-------------
MANUAL METHOD:
I will use the services.jar in this example. Just change the file name and path to existing .odex accordingly for other files. (thanks! to jhotmann for helping me to nail down this method)
Requirements:
odexed system
root
adb
busybox installed
dexopt-wrapper
Put this dexopt-wrapper file in /system/bin with 775 permissions:
X X X
X....X
X....X
Put the deodexed services.jar (or other jar/apk file you want to make a new odex of) on the root your /sdcard (on some phones that means internal storage).
Make sure USB Debugging is enabled.
Put your USB connection to MTP or PTP mode.
The bootclasspath is located in the /init.rc file at the root of your phone. Just make sure that all jars listed in init.rc are actually in your /system/framework folder and only include those in your bootclasspath in the command below. The one from Moto A2/Razr/other ICS is used below (minus the extra jar paths). To replace it with that of a different device, change the word bootclasspath with yours, using the path style as shown in the example below: dexopt-wrapper services.jar new.odex bootclasspath...
Connect with adb (do a adb devices check to make sure you're all good).
To create the new odex, enter the following one line at a time:
Code:
adb shell
su
cd /sdcard/
dexopt-wrapper services.jar new.odex /system/framework/core.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/framework-ext.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/apache-xml.jar:/system/framework/filterfw.jar:/system/framework/com.motorola.android.frameworks.jar:/system/framework/com.motorola.android.widget.jar:/system/framework/com.motorola.frameworks.core.addon.jar
To copy the signature from the existing odex (change path to /system/app/.. if necessary):
Code:
busybox dd if=/system/framework/services.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
Done! Rename new.odex (created on your /sdcard) to services.odex since that is your new signed odex file... and move to your phone using the method of your choice.
---------------------
CHANGE LOG:
Code:
11/7/12 (v2.0)
-more automated
-changed the location where the new odex is made
-thanks to [URL="http://forums.acsyndicate.net/showthread.php?113-Re-Odexing-script&p=1369&viewfull=1#post1369"]tanimn[/URL] for the hint
-thanks to [URL="http://forum.xda-developers.com/showthread.php?t=1879128"]alkhafaf[/URL] for his bat files that I got ideas from (his script didn't work for me)
8/25/12 (v1.0)
-initial release
Thanks to the following for testing!:
-A2Trip (formerly DX2Trip) on the A2 ICS
-RETIEF on the RAZR Maxx ICS
-iwabashu on the RAZR ICS
(I tested it on GB - but I am not high-fiving myself :D)
-----------------
Some vague notes on what to do next:
Depending on what you are after by re-odexing, there are different routes. For example, if you only edited or copied smali files, then you only need the new.odex file. Meaning that all of the smali code was inside of that classes.dex of the deodexed file on your sdcard, and you just made that into a new odex file (and copied the signatures from the existing .odex in /system).
If you have a deodexed apk with more edits than just smali (you could really just copy those edits over to your existing odexed apk with 7-zip or similar), but – if you want to, you will need to remove the classes.dex from the deodexed apk, and make sure that the signatures (/META-INF folder) and AndroidManifest.xml are the same as your existing apk (check, and or copy with 7-zip or similar).
.
.
.
Good job on this!
Mods, am I crazy or are we in need of a separate "stickied" section here"?
Please stickify...
An Edit: I'm glad were seeing so many great guides here in this forum, before long, we'll have a directory that other forums will envy -if not already.
Sent from my SAMSUNG-SGH-I747 using xda premium
Updated the tool (not the guide).. eh, it's still a work-in-progress but gets the job done
temporarily "abandoned" .. please use Zep's ultimatic jar power tools instead.
----------------------------------------------------------------------------------------------------------------------------------------------
I hate that Zeppelinrox's thread is being cluttered with OT questions about this.. so opening a new thread. Please post any JellyScreamPatcher.exe questions here. Thanks.
----------------------------------------------------------------------------------------------------------------------------------------------
[experimental] Windows tool for patching services.jar for V6 SuperCharger
Opening note: When replying to this post, please do not quote it!!! Or quote selectively.
For each fully quoted reply a puppy will die somewhere in the world. If you love puppies as much as I do, you'll stop quoting long posts.. thank you
----------------------------------------------------------------------------------------------------------------------------------------------
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.. LOL I guess you knew it already.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because your phone bootloops. Please
* do some research if you have any concerns about features included in my utility
* before using it! YOU and only YOU are choosing to make these modifications.
* I'm providing no ETA's, though usually I'm responding PM's in a timely manner ;)
*
* While the tool provides some backup functionality, allowing you to roll back to
* a working system, feel free to create a nandroid backup trying this ;)
*
*/
For downloads and changelog, see Post #2
----------------------------------------------------------------------------------------------------------------------------------------------
Preface:
Many of us V6 Supercharger users have been flashing nightlies nightly and dailies daily, resulting in the need for a patched services.jar almost daily since the automatic web patcher no longer works for Android 4.1.1 Jellybean files, we had to stick with manually patching this files as described in Zep's guide here. Eventually Zep prepared several versions of the Jelly_Scream_Smali_Patcher_Test_x.sh script, which does the job perfectly, but the user still has to get his services.jar, extract the .smali files, put them to the phone, put the script to the phone, run it in the phone's terminal, copy the patched .smali files back to the PC etc. etc. and for many of us, this is time consuming (and difficult for others). Time is money, right?
Currently, this tool is using a ported version of the ALL_ROMS_Ultimate_Jar_Power_Tools-Jelly_ISCream+Maximum_MultiTasking_Mods-Smali_Patcher_Test_11.sh script for patching.
So... here an automated workflow, which assumes a few things:
you are running a MS Windows operating system (tested on Win7 x64)
you have Java installed. This was tested with Java7, should run fine on Java 6 as well. In the Q&A section below I provide a link to download Java. Make sure that java.exe is accessible from any folder (is in PATH). Some version of Java 7 installs the binaries into the windows/system32 folder, other versions use different folders (e.g. "C:\Program Files\Java\jre7\bin"), so you need to know where the binaries are. Make sure you have that folder in your PATH. If not, just google how to add a folder to the PATH, there are many tutorials on the web.
[optional] you know how to connect your phone to the PC via USB
[optional] you have ADB drivers installed (either via Android SDK or from your phone's manufacturer)
[optional] you know how to enable USB debugging in your phone and did that
[optional] the USB connection mode is NOT "mass storage" (for the online mode) - please set it to "Charge only" or "None" (varies from device to device)
Before you start:
The following needs to be done only once. Of course, when Zeppelinrox updates his shell script, I'll be updating my tool and this guide to provide a new download file.
download the 7zipped tool (single archive) to your PC . Make sure you always download the latest version (link in the changelog)
extract it to an empty folder (e.g. c:/super/ .. just like in the ICS Guide) so that you get a nice folder structure like this - see explanations for the folders as well:
Code:
C:.
│ JellyScreamPatcherV6_0.9.0.6.exe
│
├───adb
│ adb.exe
│ AdbWinApi.dll
│ AdbWinUsbApi.dll
│
├───backup
├───cwm
│ signapk.jar
│ testkey.pk8
│ testkey.x509.pem
│ update.odex.zip.empty
│ update.zip.empty
│
├───dist
├───framework
├───odex
│ dexopt-wrapper
│
├───scripts
│ deodex-pusher.sh
│ dexopt-wrapper.sh
│
└───smali
baksmali
baksmali.jar
smali
smali.jar
version.txt
Before we start, I'll explain the folder structure.
Code:
adb - support folder, includes google's adb tool
backup - this folder will include your old files
cwm - support folder, includes files for generating cwm compatible update.zips
dist - this folder will include the patched files for further processing
framework - this is the working folder, where files will be compiled/decompiled/patched
odex - support folder, includes the binary for odexed ROMs in-phone final patching
scripts - support folder, includes files for online mode
smali - support folder, includes the smali/baksmali tool
How to patch the services.jar file
The following assumes you have a "stock" (or unchanged) services.jar in your phone's ROM or in my tool's framework subfolder .
Note: The current version should still be considered as beta-release. While it works for me (most of the computer stuff works when I'm near it, my family has been puzzled about this since long ago.. LOL), it may not work for you. Please report any bugs you find (thread, PM) and I'll be happy to fix them. Although I inserted many "hit the Enter" prompts into the tool, it's always good to run the tool from a console so that you can keep the output in case you flash through the workflow too fast
Also, the tool maintains an activity.log file where it flushes messages about what's happening. If you encounter a bug, send me this file. Please do not copy/paste the log contents into the thread!!! Attach it. Or upload to any cloud service and send me the public URL.
Click to expand...
Click to collapse
Tip: When running the tool, feel free to enlarge the command prompt window vertically
Click to expand...
Click to collapse
After running the tool and passing the initial screen, you will be presented with a choice between online and offline mode.
Online mode
Online mode assumes that the phone is connected via USB. In this mode, the tool can pull all the information from the phone. Not only the files, but system variables, as well as some debug info (e.g. is the ROM odexed?)
Connect the phone via USB
Enable connection mode "Charge only" or "None". This won't work, if the phone is in "Mass Storage" mode!
Sit back and enjoy (and don't forget to answer the tool's questions!)
After patching there will be a warm reboot
Offline mode
Offline mode means, that there will be no interaction of the tool with the phone via USB. You need to do all the file transfers and in case of odexed ROMs, the final in-phone patching, manually. Also you will have to enter some other information into the tool manually.
make sure to copy your /system/framework/services.jar to the tool's framework folder. If you have an odexed ROM (e.g. stock), copy the whole /system/framework folder contents to the tool's framework folder.
make sure to know your system's version because the tool will ask for it
make sure to know your BOOTCLASSPATH variable. It can be pulled from the phone using the command
Code:
adb.exe set | grep BOOTCLASSPATH
make sure you know if the ROM is odexed or not
After patching, you will need to transfer the patched files to the phone and perform manual patching/replacement:
Odexed ROM:
For odexed ROMs, there is some more patching required that you can do in the phone.
copy services.jar from the 'dist' folder to the sdcard
copy 'dexopt-wrapper' from the 'odex' folder to the sdcard
copy 'dexopt-wrapper.sh' from the 'scripts' folder to the sdcard
Make sure they are in the card's root folder !!
In the phone, open Script Manager or any other app that can run shell scripts with superuser rights.
Open the app, run the dexopt-wrapper.sh script. A warm reboot may occur, since the script will restart the framework
Reboot to recovery, Clean Cache, Clean Dalvik Cache
That's it
Deodexed ROM:
update-signed.zip in the dist folder
Copy this file to your sdcard, then reboot to cwm recovery and install it from there. Then do a Dalvik Cache wipe, Cache wipe and reboot.
services.jar in the dist folder
You can copy this file to phone's /system/framework folder and replace the existing one. Make sure that the new file will have owner/group 'root' and permissions 644. Then reboot to recovery, clean Cache & Dalvik Cache.
Rollback
In case something goes wrong, there should be a message about that in the activity.log file.
Feel free to send this file to me - either attach (not paste!!!) the file to a post in this thread, or upload it to any of the cloud services and tell me the URL. I'll take a look.
Before patching, the tool creates backup of the files as a CWM recovery compatible update.zip file. It will sit in the backup folder. This is your way back to a working system. Of course, you can do a nandroid backup..
So what is the tool actually doing?
Very easy to explain.
it pulls the services.jar (and odex files if needed) from your phone to the working folder (or takes an existing one that you put into the folder)
it uses the baksmali.jar to decompile the services.jar/odex
creates a backup of the unchanged files
it runs a ported perl version (and compiled to exe) of Zeppelinrox's JellyScream patcher script (v6) to patch the .smali files
it uses smali.jar to compile the new classes.dex
inserts the new classes.dex back to the services.jar
[optionally] it pushes the new services.jar back to the phone
[optionally] for ODEXed ROMs, created services.odex from the patched services.jar
[optionally] for deODEXed ROMs, it creates and signs an update.zip that can be flashed in CWM recovery
collects the garbage and exits with a nice message .. LOL
Q&A
Q: It doesn't decompile the services.jar and complains that the .smali files don't exist !!!
A: Yeah, probably your Java is crap. Install Java JRE from Oracle's web (http://java.com/en/download/index.jsp), it will offer you the latest version. I tested with Java 7, but latest releases of Java 6 should work as well.
Q: Getting java errors "not recognized" "not found" and so !!!
A: You probably don't have the java executable in the system PATH. Search the web on how to do this. Example - Java7 installs its binaries to the <system>:\Windows\System32 folder, other versions may act differently and they may have the binaries in a different folder (e.g. "C:\Program Files\Java\jre7\bin") . That folder needs to be in the PATH.
Q: I'm getting bootloops after patching the services.jar with this tool!
A: Make sure to Wipe Cache, Wipe Dalvik Cache and Fix permissions in the CWM recovery. ALso, feel free to send me your original services.jar, I'll take a look. If you have an odexed ROM, send me the whole /system/framework folder and the activity.log file generated while using this tool in "online" mode.
Q: After reboot with the new services.jar file, it says "Android is upgrading" and optimizing apps, even though I did not wipe my dalvik cache.
A: Well, yes that is expected. It will take a while, depending on how many apps you have installed.
Q: Will my phone's memory be blazing fast and effective after this?
A: No, you still have to run the V6 Supercharger script.
Q: Does it run on Linux?
A: Not yet, but it will. I need some more internal testing to release a Linux version.
Q: Does it run on ODEXed ROMs?
A: Yes !!!
Q: Why is the executable so large???
A: Blame PAR long story short, I wrote my stuff in Perl and used Perl to port Zep's stuff as well. Then I compiled the script to exe using the PAR:acker package, resulting in the huge executable. I know, there is another way, to use Activestate's PDK (Perl Development Kit), but the license is approx. $250 and I just don't have that money for spending on a single tool. PDK creates much smaller files (approx. 1/3rd), but for now we have to stick with what we have
Q: Tool fails and in the log I see messages like "failed to copy 'C:/super/backup/services.jar' to '/mnt/sdcard/services.jar': Permission denied"
A: Make sure the USB connection mode is other than "Mass Storage". It can be "Charge Only" or "None", really this is depending on the device you own.
Q: Isn't there a virus included in the executable?
A: LOL.. No. This community gave me a lot since 2007 and I have no intention to harm it in any way. If you are using NOD32 and it starts complaining about the URL to my file I posted above, let me know. ESET support is pretty quick in identifying and fixing false warnings
Enjoy.. and feel free to PM me in case of any questions. I'll keep this post updated all the time.
Thanks
- Zeppelinrox for the V6 Supercharger and the associated scripts/tools
- Rexstor for the ODEX guide
- Android community for all the other tools (smali/baksmali/sign)
- Google for Android... luv ya!!!
If you feel like I deserve a beer for what I've done, feel free to consider donating to Zeppelinrox first as I'm just making his fabulous work a tiny bit more accessible. And if you still think I deserve a beer, you can use the button below.
downloads and changelog
Downloads
http://dev.pepcok.info/jellyscreampatcher/JellyScreamPatcherV6_0.9.0.6.7z
Changelog
0.9.0.6 [2012-09-23]
still using ALL_ROMS_Ultimate_Jar_Power_Tools-Jelly_ISCream+Maximum_MultiTasking_Mods-Smali_Patcher_Test_11.sh
added a proper error reporting when sdcard is not writable in online mode
0.9.0.5 [2012-09-20]
using ALL_ROMS_Ultimate_Jar_Power_Tools-Jelly_ISCream+Maximum_MultiTasking_Mods-Smali_Patcher_Test_11.sh
multiple users with Odexed ROMs have reported this version to work. Feel free to try
with online mode, there is a framework restart after patching, causing warm reboot of the device.
0.9.0.4 [2012-09-13]
using ALL_ROMS_Ultimate_Jar_Power_Tools-Jelly_ISCream+Maximum_MultiTasking_Mods-Smali_Patcher_Test_11.sh
Warning for odexed ROM users - proceed with cautions, many have reported bootloops (even with previous version). Investigating
0.9.0.3c [2012-09-12]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
fixes STUPID bug with storage detection (I hope)
0.9.0.3b [2012-09-12]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
storage detection, as requested by one of the users (thanks Zep for the code! )
fixes in shell scripts for online mode
removal of the -f flag for rm commands
0.9.0.3 [2012-09-11]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
odex: if the baksmali decompile fails (e.g. file missing, although being in BOOTCLASSPATH), the tool will create an alternate BOOTCLASSPATH based on the files that were pulled from the phone and try decompile again. It even this fails, then I guess the world will end in 2012
ui: revamped the whole ui, user is now selecting offline vs online (adb) mode at the beginning
ui: added a proper note for the user to make sure to clean cache/dalvik cache when rebooting for the first time with the new services
ui: added instructions for the user in offline mode (when he wants to do the final steps manually)
internal: added some file exists checking, online (with adb) mode works better now and is prettier
other: as always, please read what the tool says.
0.9.0.2 [2012-09-06]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
instead of using crappy adb commands, the final patching is done via shell scripts in the phone - please help me test that. I already restored my phone's system partition 4 times (since patching a GB MotoDefy+ with ICS HTC Evo services is not healthy, but necessary for my testing), all the final patching seems to work fine here. Tested for both odexed and deodexed files and my phone already hates me
the tool will make a backup of your original services.jar/odex file into a CWM recovery update.zip (will be in the backup folder) .. that's your way back from potential hell
fixed a typo in manual API level selection - thanks for catching
0.9.0.1 [2012-09-05]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
few fixes (shell user detection, trying to implement better /system rw mount )
0.9.0 [2012-09-05]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
initial support for ODEXed ROMs - alpha version. I need testers please ! Since my phone does not have any odexed ICS or JB, I was able to test with sample files from xda fellow members end-to-end, but the real full fledged experience, I can't verify
0.8.9.2 [2012-09-05]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
minor update to capture the system calls, stdout and stderr into the log, for people who have problems with java. Let's see how it works
0.8.9 [2012-09-04]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
updated adb communication
added proper logging
internal preparation for ODEX ROMs (yeah, 0.9.0 will work with ODEXed ROMs !!!)
added framework folder as the working folder (reduces file clutter.. LOL)
0.8.5 [2012-08-27]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
update-binary from Titanium Backup
0.8.4 [2012-08-26]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_8.sh
minor fixes only
0.8.3 [2012-08-25]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_8.sh
this one should work with services.jar files where the smali files don't include debug information
0.8.2 [2012-08-23]
some more checks for "non-compatible" data, will provide warnings to the user in case of "incompatible" services.jar. Users seeing that message should proceed with caution until the next version. Zeppelinrox is aware of the potential problem.
0.8.1 [2012-08-22]
patching based on Zep's v7 script
resolves patching issue with the services.jar from the Alliance 2.1 ROM for Galaxy Note (GT-N7000)
resolves a weird compilation error when running the executable
0.8 [2012-08-22]
First public version, based on Zep's v6 patcher
Good job and thanks.
Sent from my Galaxy Nexus using Tapatalk 2
FYI I added this to Post 2 of the SuperCharger thread...
B) Equally Effective AND EASIER than A) - use the Jelly ISCream Automatic Patcher for Windows!
This does everything that is explained in this very post - from start to finish! Yep... it does Steps 1 to 9!
I know... it's complicated... this is what you do...
1. Plug in your phone
2. Run the Windows exe to patch and install services.jar!
OK?
Click to expand...
Click to collapse
thanks buddy
I guess tomorrow I'll need a guinea pig ... oh... I mean a tester !!! LOL ... for the ODEX stuff.. it looks good locally, just need to close my eyes for a few hours cuz I can't see anything any longer today.
zeppelinrox said:
FYI I added this to Post 2 of the SuperCharger thread...
Click to expand...
Click to collapse
People are still going to get it wrong....
Sent from my Galaxy Nexus using Tapatalk 2
Thanks for this. Trying it now on my GS3 (running a deodexed Touchwiz rom). After hitting [ENTER], the screen hangs on:
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
Click to expand...
Click to collapse
Did I miss something?
jdhas:
The text you pasted is start of the adb server, the next step after that is waiting for device. Did you have the phone connected to the PC via USB, with USB debugging enabled? I should probably add some text saying that it's waiting for the device
pepcisko said:
jdhas:
The text you pasted is start of the adb server, the next step after that is waiting for device. Did you have the phone connected to the PC via USB, with USB debugging enabled? I should probably add some text saying that it's waiting for the device
Click to expand...
Click to collapse
I'm definitely connected, and I definitely have USB debugging enabled. I am, admittedly, trying this from my work computer, which may be too "locked down" for this sort of fun. Will attempt again when I get home.
well, the easiest thing to check (even at work) is to run
Code:
adb devices
manually from the console. This way you can check if adb is seeing the device.
EDIT: What the tool is doing, is the following:
Code:
adb\adb.exe start-server
adb\adb.exe wait-for-device
adb\adb.exe pull /system/framework/services.jar framework\services.jar
so my assumption is, if it fails in the second command, it's waiting for the device.
jova33 said:
People are still going to get it wrong....
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
That's why the next update might have a little surprise if they run the jelly iscream script without the smali files in the same folder... hehehe... makem scream for realzzz
Looking forward to the update....
Sent from my GT-N7000 using Tapatalk 2
Well... here's what may be possible...
http://forum.xda-developers.com/showpost.php?p=31137111&postcount=5066
I just quickly made a new services.jar hack.
Breaking the lowmemorykiller so that it doesn't kill anything was easy... just one simple edit LOL
I'm hoping that increasing max hidden apps from 15 to 50 will work... that would be optimal
===============================
Oh yeah I had used a goo.gl link in Post 2... http://goo.gl/OfOOE+
Already a nice number of clicks lol
Great work. Looking forward to your next update for odexed roms. :thumbup:
Sent from my Pro using xda app-developers app
jdhas said:
Thanks for this. Trying it now on my GS3 (running a deodexed Touchwiz rom). After hitting [ENTER], the screen hangs on:
Did I miss something?
Click to expand...
Click to collapse
USB debugging enabled? Phone plugged it?
Close the win app and try again. It's hung in a couple of spots for me. I just close it and run it again and it'll go through the second time
Sent from my Nexus 7 using Tapatalk 2
I need help. I get the following error message when the patch is running on my computer.
"Important files are missing after decompiling services.jar See the log for details. Exiting..."
Log attached below. The log shows me trying twice with the same error message causing exit. Please advise.
Edit: I'm on Jellybean CM10 with the Droid Incredible.
Do you have java installed on the PC?
Sent from my Galaxy Nexus using Tapatalk 2
jova33 said:
Do you have java installed on the PC?
Click to expand...
Click to collapse
Java6 Update 26 (64-bit) shows as installed under programs.
folks, who have problems with this
Important files are missing after decompiling services.jar See the log for details. Exiting.
Click to expand...
Click to collapse
Can you download the new minor update? I uploaded 0.8.9.2 which adds some more logging and is a bit more "bulletproof" in the system calls.
Please let me know and send (or attach) logfiles if it goes wrong.. Thanks
Good news !!!
I successfully broke my device when I end-to-end tested the ODEX patching on my Motorola Defy+, using test files from a HTC EVO
But that was expected and I did it willingly.
Flashing the stock SBF now, will do one last final test and then (within 1-2 hours) upload the ODEX-capable patcher
Yep, you read that correctly. I have optware, ssh, samba, transmission, and flexget working on my Minix X5 Mini. This should work for any rooted device which has an adb connection enabled. This will work on the original ROM. In fact, I use the stock ROM. For those not using a Minix device this should work on any ARM device. Sorry but all the binaries are built on ARM.
JUST AS EVERY OTHER DEVELOPER: I AM NOT RESPONSIBLE IF YOU BRICK YOUR DEVICE! MAKE A BACKUP!
Requirements:
Linux box with adb (don't ask me about windows, I don't support bad habits)
clockworkmod (for a backup)
root
internet connection
Process:
Make a backup of your ROM!
Download files (gitHub)
You have two options here:
Download the zip via https://github.com/erichlf/AndroidSeedBox/archive/master.zip and unzip it.
Clone the repo using git via 'git clone [email protected]:erichlf/AndroidSeedBox.git'
Make script executable
chmod +x optware-etc.sh
Obtain adb connection to device (covered in another thread)
Gain root access on local machine (adb seemed to require this for things to work)
sudo su
Run script and follow directions
./optware-etc.sh
Use SManager to run /opt/home/root/sysinit at every restart.
Notes:
The script can be modified to change the various programs that I install. You could exchange transmission for deluge for example.
Transmission can be accessed from the minix through localhost:9091 or from some other machine using your ip-address and the port 9091. If that doesn't work you should edit the config file located at /opt/home/root/.config/transmission-daemon/settings.json
username: root
password: you provided this in the install script
Without SManager nothing will start automatically. However, if you have a ROM which has init.d support you can move the scripts in /opt/etc/init.d to /etc/init.d I would suggest maybe linking the two instead of just moving the scripts or possibly adding a script to /etc/init.d which runs the items in /opt/etc/init.d The reason is because when installing things using ipkg the startup scripts will be placed in /opt/etc/init.d and not /etc/init.d However, it is extremely important that optware is started, and this is partly what sysinit accomplishes.
To list available packages
ipkg list
To install a new package use the command
ipkg install <new package>
To remove a package use the command
ipkg remove <package to remove>
cron is weird and I couldn't get it to work like it should, but I got it to work
While on the Android device (ssh or terminal emulator)
Create a .crond file in the home directory of your device (/opt/home/root/) with some schedule in it. Remember to leave a blank line at the end of the file.
Tell cron about the .crond file
crontab -u root /opt/home/root/.crond
Make sure cron sees the cron file
crontab -l
If you want to edit your cronfile use a text editor and edit the file directly and then tell cron about the file again.
Many things are installed in what seem like strange places, so use
which <binary you are looking for>
Feel free to help develop the code. I think what would be best is an update.zip or a CWM flashable zip. Right now I don't know how to do this, but once I get more time I will look into it. So, any help on this front is welcomed.
Enjoy!
I really wish you would have kept the repo up. It seems kind of pointless to go through all that trouble just to delete the repo and leave people wondering what you did.
I have been busy and didn't update this particular post, since there had been no activity on it.
git clone [email protected]:erichlf/androidseedbox.git
https://bitbucket.org/erichlf/androidseedbox/get/master.zip
Sorry, I didn't need to be rude. I was just excited to find this and then sad when it was gone. Thanks for pointing me in the right direction!