Related
I'm working on a tool I'm calling "applytheme". Basically you create a theme.zip, stick it in an archive with the included applytheme binary and update-script, sign it, and it will update the files on any of the Dream firmwares with the ones you've provided.
There are some limitations currently:
It can't yet determine space required before-hand, so you may run out of space in the middle. If you do, you can just restore the original theme with the restoration update.zip.
It can't add files - only replace existing ones.
The original files are stored in /data/original_theme.zip, which will eat your /data space, but only the replaced files are stored.
This version is a test release and may or may not have bugs. Be sure to back up your phone before trying it.
Please consult the example for figuring out what to put in the theme.zip, but it's basically full-path-to-filename-you-want-to-update/full-path-to-file-you-want-to-replace
So if you wanted to replace "assets/images/android_320x480.png" (the boot screen) in "/system/framework/framework-res.apk", you would have a file in your theme.zip called "system/framework/framework-res.apk/assets/images/android_320x480.png".
Case matters - please use the correct case (which is usually all lowercase).
Example theme (replaces boot animation only, with a cupcakedroid):
applytheme-200902090018-example.zip
Restoration update.zip (restores from /data/original_theme.zip then deletes original_theme.zip):
theme_restore-200902090018.zip
Source code (for developers or other curious people):
applytheme-200902090018.tar.gz
EDIT: 200902082117 fixes a couple of stupid bugs in 200902081755 :/
EDIT: 200902082316 removed extraneous/incorrect free space check; noticed that the update script stuff is significantly more stupid than I'd thought - update scripts should work now.
EDIT: 200902090018 close files so space can be reclaimed during patching
Reporting problems
If one of the applytheme updates fails, while still in the recovery mode please do the following:
Press ALT+X to get to the console
Press <enter> to get to the prompt
Type cp /cache/recovery/log /sdcard/recovery.txt
Type df >> /sdcard/recovery.txt
Type reboot to reboot.
Send the recovery.txt from the SD card to zinx <AT> users.sourceforge.net with the subject "applytheme error log"
If I don't have the log (or at least the error message from the log), I can't know why it's failing, and can't do anything to fix it.
I am looking at your post but don't see the benefits of doing it like this. you would still need to do this every time you add a theme or just a image and you still need to sign it or am I just not seeing the benefits of using it
kron2 said:
I am looking at your post but don't see the benefits of doing it like this. you would still need to do this every time you add a theme or just a image and you still need to sign it or am I just not seeing the benefits of using it
Click to expand...
Click to collapse
Current themes replace the whole system.
If you change as single file in /system/app/Browser.apk (say, an icon), you have to replace the whole file.
You don't have to do that with applytheme, so you can replace the icon no matter what firmware is being run.
This would be great themes wont need to be converted any more.
manup456 said:
This would be great themes wont need to be converted any more.
Click to expand...
Click to collapse
Indeed, for example:
More Vintage Less War via applytheme (theme by manup456 )
EDIT: Oh, I should note I tested this one with RC33. Didn't bother to time the progress meter though, so just wait until it tells you to reboot with home+back.
This looks like an amazing tool! I'm surprised more people haven't checked this out.
Let me get a few things straight before I give it a shot.
Let's say I was updating some basic images in the framework-res.apk. All I need to do is:
~Download your applytheme-example.zip
~Open up the theme.zip (remove current folders inside)
~Create the folders system\framework\framework-res.apk\res\drawable\
~Add the icons I've changed, with the exact original names
~rename applytheme-example.zip to update.zip
~load onto SD card and load onto phone as usual
~success?
I don't quite understand the backup system...
When you load the update onto the phone, it backs up the images you're replacing and puts them into a \data\original_theme.zip?
Then, if for some reason you want to revert to the original theme, you simply run the theme.restore.zip on the phone and it grabs all the \data\original_theme.zip images and places them in their original location?
Also, if the theme you're installing is a few megs, then the \data\original_theme.zip will get rather large, no? Will this cause any issues?
Thanks!
The steps are a bit more like this:
Download applytheme-example.zip
create system/framework/framework-res.apk/res/drawable/
add the files you've changed
create a theme.zip with the files above - MAKE SURE IT HAS THE PATH, STARTING WITH system/
replace the theme/theme.zip in applytheme-example.zip with your new theme.zip
sign the applytheme-example.zip with the replaced theme/theme.zip
put it on the SD card as /sdcard/update.zip and update as normal
success! (unless there was a problem during patching, then it may be partially applied and you can use theme_restore.zip to fix it)
MOONSSPOON said:
When you load the update onto the phone, it backs up the images you're replacing and puts them into a \data\original_theme.zip?
Then, if for some reason you want to revert to the original theme, you simply run the theme.restore.zip on the phone and it grabs all the \data\original_theme.zip images and places them in their original location?
Click to expand...
Click to collapse
Yep.
MOONSSPOON said:
Also, if the theme you're installing is a few megs, then the \data\original_theme.zip will get rather large, no? Will this cause any issues?
Click to expand...
Click to collapse
It can get large, yes, but keep in mind that it's only the original files that have changed that get put in it. Most themes right now are much larger .zips than they actually are, because they include much more than what was changed. If it gets too large to fit, the update will just fail part-way, and you can restore using the theme_restore.zip.
You can also delete it if you don't want to restore.
If you have any better ideas for any of this, I'm definitely open to suggestion - It's not anywhere near finalized yet
Great work. Definitely a step in the right direction for generalizing themes and allowing them to work with any build without modification.
Some thoughts for the next steps... Perhaps do a once-over of the files in theme.zip and compare their sizes with the existing files? This would just about double the time it takes to install, but should catch any out-of-space issues before any replacements had been made. Alternatively, perhaps there's a way to detect failures and automatically revert and display an error?
MasterBunnyFu said:
Great work. Definitely a step in the right direction for generalizing themes and allowing them to work with any build without modification.
Some thoughts for the next steps... Perhaps do a once-over of the files in theme.zip and compare their sizes with the existing files? This would just about double the time it takes to install, but should catch any out-of-space issues before any replacements had been made. Alternatively, perhaps there's a way to detect failures and automatically revert and display an error?
Click to expand...
Click to collapse
Automatic reversion can be done.
The update stuff is too stupid to let me display an error (Seriously. There's no way to display a message to the user. All I get is the unchangeable 'Failed on line 3'.) - an error is kept in /cache/recovery/log though.
Checking the file sizes would indeed take twice as long - everything is compressed, so I'd basically be creating every file touched, but discarding the output, then creating it all again. It already takes quite some time, and it should normally have enough space free, so I would prefer to go the automatic reversion route if people don't want to have to use the theme_restore.zip after a partial update.
So I tried throwing in your more vintage theme, but I get the error failed on line 4.
I feel like a leecher posting this message, but explain to me how it's done.
APrinceAmongMen said:
So I tried throwing in your more vintage theme, but I get the error failed on line 4.
I feel like a leecher posting this message, but explain to me how it's done.
Click to expand...
Click to collapse
Should just be putting in it; can you post the /cache/recovery/log from after it fails? May need to copy it somewhere before rebooting.
I expect it's due to lack of space, but it was ok here :x
In an effort to make it a bit easier initially, I've written "toapplytheme". It takes a theme update, the update it was based on, and outputs an applytheme compatible theme.zip - You still have to put in in theme/theme.zip in the applytheme update zip and re-sign it, though.
If you use something other than the update it was based on, you're going to end up with a lot of extra and/or missing files, so don't do it.
Ex:
Code:
toat MyExcellentTheme.zip JFv1.41_RC33_light2.zip theme.zip
toat-200902091613.zip
Worked for me
I have an ADP1 w/the latest JFv1.43h, I extracted Rusty Metal (from the RC33 version, using you tool). Put it there on the example, signed it all and voila...
The only thing I noticed is that the background did not get changed, but that is a minimal issue (and easily fixed).
Great job Zinx, I don't understand why all theme designers don't use this tool.
A matter of time I hope?
DanOtero said:
I have an ADP1 w/the latest JFv1.43h, I extracted Rusty Metal (from the RC33 version, using you tool). Put it there on the example, signed it all and voila...
The only thing I noticed is that the background did not get changed, but that is a minimal issue (and easily fixed).
Click to expand...
Click to collapse
I just applied Rusty Metal to my G1 using the standard way (not this tool) and the background doesn't install with it anyways, so it's not a problem with this tool, but the theme itself simply doesn't include it.
Hi,
So, I'm trying to make my own custom ROM. Nothing too fancy, just a couple of simple and easy modifications to fit my needs but there's somethings I don't know how they work nor I understand them and I need some help. The only thing I was able to achieve as of yet was to remove some apps (I only tried to remove "Learn More" and QuickOffice to be honest-- but it worked). I just removed the .apk and .odex file directly from the .zip file, signed it and flashed it as usual. It worked fine.
Now, a few questions...
1) I also tried to add a few apps, just like in MoDaCo Custom ROM (MCR), to the /data/app folder instead of /system/app. Actually, I just copied all of .apk files from MCR /data/app into my own (with same folder structure of course). But they didn't get installed... I know I'm missing something and I can almost bet it has something to do with the /META-INF/com/google/android/update-script file. I tried countless times to search for some guide, how-to or just a piece of documentation about this file but I can't find anything. I don't want to just change it and see if it works and then screw things up. Can anyone give me some hints about understanding this file? It has to do with the fact that my /data/apps weren't installed, right?
2) I don't use the Gmail app, just the HTC Mail one. Is it safe to delete Gmail.apk and GmailProvider.apk? I believe Gmail.apk will be fine, but the provider one, I guess it's used by the data synchronization thing. Maybe it's ok if I don't sync my mail (that's what I want actually) but maybe there's something else that I'm missing and the system will not work properly, somehow, without the GmailProvider.apk or is it safe to remove it?
3) When we first install a new ROM, starting clean, there's an introductory guide allowing to setup some things initially. One of those is the language. There is a bunch of languages, specially like English (A), English (B), English © where the letters represent other languages. I don't need all that, I only need English (Portugal). Is there anyway I could remove the ones I don't want from the ROM or I would need to dig into the Android source for that?
3.1) How about adding my own language? Is there a way I could do that to my ROM?
NOTE: Funny thing, the Android system is localized on my country's language when I first start the device but as soon as I change it to English, I cannot change it back to Portuguese cause that option doesn't exist. How come the device is in Portuguese when I first start it up after flashing a new ROM? This also happens every time I swap the SIM card, but I can never select Portuguese language by myself. Why?
4) I noticed that after flashing my custom ROM, after booting the device for the first time, the mobile network was active. This is not good... For now I have 1 month free of mobile networking but that won't last forever. I don't want to waste money every time I'm trying a new ROM. Is there anyway to disable this thing from automatically starting up connected when I first boot?
For now that's it...
1. You need to edit "META-INF/com/google/android/update-script"
That's what I said... :/ But I also said:
I tried countless times to search for some guide, how-to or just a piece of documentation about this file but I can't find anything. I don't want to just change it and see if it works and then screw things up. Can anyone give me some hints about understanding this file?
Click to expand...
Click to collapse
If anyone knows anything helpful of course...
Nazgulled said:
That's what I said... :/ But I also said:
If anyone knows anything helpful of course...
Click to expand...
Click to collapse
I am also interested in a guide or walk through for making a ROM for the Hero.
1) I also tried to add a few apps, just like in MoDaCo Custom ROM (MCR), to the /data/app folder instead of /system/app. Actually, I just copied all of .apk files from MCR /data/app into my own (with same folder structure of course). But they didn't get installed... I know I'm missing something and I can almost bet it has something to do with the /META-INF/com/google/android/update-script file. I tried countless times to search for some guide, how-to or just a piece of documentation about this file but I can't find anything. I don't want to just change it and see if it works and then screw things up. Can anyone give me some hints about understanding this file? It has to do with the fact that my /data/apps weren't installed, right?
Click to expand...
Click to collapse
You're missing copy_dir PACKAGE:data DATA:, so you're really not writing /data/app even if it's on the package. If you read through the update-script, you'll see that it starts by formating BOOT: and SYSTEM: and later on writes the contents of /system to SYSTEM: (with copy_dir) and writes the raw boot.img to BOOT: (with write_raw_image).
Add the line to the very end of the permissions settings (but before format and write boot, most likely, before the show_progress line). You also need to set a specific permission after writing anything to /data/app from an update-script, otherwise your market won't be able to install anything (as you'll have changed the permissions for /data/app through the update-script).
In all, your update script will look like this (assuming a regular update-script, not the mcr 2.9 one):
Code:
...
symlink toolbox SYSTEM:bin/xxxxyyyy
...
set_perm 0 0 04755 SYSTEM:bin/su
copy_dir PACKAGE:data DATA:
set_perm 1000 1000 0771 DATA:app
show_progress 0.1 10
show_progress 0.2 0
write_raw_image PACKAGE:boot.img BOOT:
show_progress 0.2 10
2) I don't use the Gmail app, just the HTC Mail one. Is it safe to delete Gmail.apk and GmailProvider.apk? I believe Gmail.apk will be fine, but the provider one, I guess it's used by the data synchronization thing. Maybe it's ok if I don't sync my mail (that's what I want actually) but maybe there's something else that I'm missing and the system will not work properly, somehow, without the GmailProvider.apk or is it safe to remove it?
Click to expand...
Click to collapse
It's safe to remove both, though the provider doesn't do much without the app, so it's also safe to leave it there.
3) When we first install a new ROM, starting clean, there's an introductory guide allowing to setup some things initially. One of those is the language. There is a bunch of languages, specially like English (A), English (B), English © where the letters represent other languages. I don't need all that, I only need English (Portugal). Is there anyway I could remove the ones I don't want from the ROM or I would need to dig into the Android source for that?
Click to expand...
Click to collapse
Hero roms take their settings from xml files in /system/customize. You'll see a bunch of xmls in there. Some are references to other xmls to be used (mns_map and cid_map), some are default settings (default.xml, COMMON.xml) and some are carrier specific settings (/CID/HTC_*.xml and /MNS/Lan_*.xml). The files are very redundant, and it's hard to tell which one is being used when, though, as a rule, you should understand that Hero loads a default from the /customize folder and then looks at mns_map and cid_map for the file to use inside /CID and /MNS. I'm not yet aware how it chooses the file, but, if you narrow down it's choices, then you can control which ones it uses and modify the settings there. If you crack open the xmls, you'll immediately see the languages defined in there (en_US, en_GB, etc), so removing languages is a matter of deleting the lang/region and adding your own (en_PL?). Again, there's so many xmls in there that it's hard to know which one to use, so either make your own and delete the rest, or edit them all. I'll give you the batch that I use in my /customize, reading through them should help you understand what's going on with those xmls.
3.1) How about adding my own language? Is there a way I could do that to my ROM?
NOTE: Funny thing, the Android system is localized on my country's language when I first start the device but as soon as I change it to English, I cannot change it back to Portuguese cause that option doesn't exist. How come the device is in Portuguese when I first start it up after flashing a new ROM? This also happens every time I swap the SIM card, but I can never select Portuguese language by myself. Why?
Click to expand...
Click to collapse
Look above, it's because the language is obtained from the carrier and used during first boot, but it's not defined in an xml, so it's unavailable, make it available by adding it to the list.
4) I noticed that after flashing my custom ROM, after booting the device for the first time, the mobile network was active. This is not good... For now I have 1 month free of mobile networking but that won't last forever. I don't want to waste money every time I'm trying a new ROM. Is there anyway to disable this thing from automatically starting up connected when I first boot?
Click to expand...
Click to collapse
This I'm not sure about. You could try emptying your /system/etc/apns-conf.xml so that it won't be able to register to any data service (just leave the <apns version="x"> </apns> tags, remove everything in between).
Good luck.
jubeh said:
You're missing copy_dir PACKAGE:data DATA:, so you're really not writing /data/app even if it's on the package. If you read through the update-script, you'll see that it starts by formating BOOT: and SYSTEM: and later on writes the contents of /system to SYSTEM: (with copy_dir) and writes the raw boot.img to BOOT: (with write_raw_image).
Add the line to the very end of the permissions settings (but before format and write boot, most likely, before the show_progress line). You also need to set a specific permission after writing anything to /data/app from an update-script, otherwise your market won't be able to install anything (as you'll have changed the permissions for /data/app through the update-script).
Click to expand...
Click to collapse
That's what I thought but I'm still missing one thing...
The generic HTC "update.zip" has format: DATA for the last line of the update script, which I suppose will delete everything becuse the copy_dir command was executed before.
Should I not use the format data option? Won't that leave traces of a previous installation if I want to start clean? What's the recommendations or suggestions?
jubeh said:
It's safe to remove both, though the provider doesn't do much without the app, so it's also safe to leave it there.
Click to expand...
Click to collapse
What will happen to the data-sync when i tries to sync the data and finds the provider for gmail is not there? Will it simply be ignored? Will there be any errors changing any of the options (specially the gmail one) on the data synchronization settings?
jubeh said:
Hero roms take their settings from xml files in /system/customize. You'll see a bunch of xmls in there. Some are references to other xmls to be used (mns_map and cid_map), some are default settings (default.xml, COMMON.xml) and some are carrier specific settings (/CID/HTC_*.xml and /MNS/Lan_*.xml). The files are very redundant, and it's hard to tell which one is being used when, though, as a rule, you should understand that Hero loads a default from the /customize folder and then looks at mns_map and cid_map for the file to use inside /CID and /MNS. I'm not yet aware how it chooses the file, but, if you narrow down it's choices, then you can control which ones it uses and modify the settings there. If you crack open the xmls, you'll immediately see the languages defined in there (en_US, en_GB, etc), so removing languages is a matter of deleting the lang/region and adding your own (en_PL?). Again, there's so many xmls in there that it's hard to know which one to use, so either make your own and delete the rest, or edit them all. I'll give you the batch that I use in my /customize, reading through them should help you understand what's going on with those xmls.
Click to expand...
Click to collapse
I'm familiar with XML files and have no problems editing them but this whole thing was a little confused specially because there are no documentation and like you said, it's hard to tell which one is which.
I know you kinda suggested that but I'm no seeing how to do it (maybe with the file you attached?) but, how could I start clean, only have default XML files and nothing else, no carrier specific stuff, no bulk, just plain default settings that I can tweak to my own liking.
Any hints on how to do that, or it's hard to tell and you don't know how to do it either?
jubeh said:
This I'm not sure about. You could try emptying your /system/etc/apns-conf.xml so that it won't be able to register to any data service (just leave the <apns version="x"> </apns> tags, remove everything in between).
Click to expand...
Click to collapse
Unfortunately, this did not work
The generic HTC "update.zip" has format: DATA for the last line of the update script, which I suppose will delete everything becuse the copy_dir command was executed before.
Should I not use the format data option? Won't that leave traces of a previous installation if I want to start clean? What's the recommendations or suggestions?
Click to expand...
Click to collapse
I've never understood why the default update script does that, but yeah, format DATA: will erase userdata available. It might not be such a bad thing if you hadn't written anything to it before. For a wipe before install, move format DATA: (and, optionally, also add format CACHE: ) right after format SYSTEM: and before you start writing anything to disk. It should give you a clean install without having to wipe from the recovery menu.
What will happen to the data-sync when i tries to sync the data and finds the provider for gmail is not there? Will it simply be ignored? Will there be any errors changing any of the options (specially the gmail one) on the data synchronization settings?
Click to expand...
Click to collapse
I've not tried it yet. Worst case scenario, you'll get the current problem we have with eclair builds (sync will just keep running and eat out battery because it's looking for a service). That's why I'd suggest leaving gmail provider there, it's just a broadcast service, but without an app to receive the data, it'll do nothing. If your concern is data usage due to sync, then you should turn off gmail sync in settings, that way only calendar and contacts are synchronized (although you'll still be using data).
I'm familiar with XML files and have no problems editing them but this whole thing was a little confused specially because there are no documentation and like you said, it's hard to tell which one is which.
I know you kinda suggested that but I'm no seeing how to do it (maybe with the file you attached?) but, how could I start clean, only have default XML files and nothing else, no carrier specific stuff, no bulk, just plain default settings that I can tweak to my own liking.
Any hints on how to do that, or it's hard to tell and you don't know how to do it either?
Click to expand...
Click to collapse
The files I attached are pretty generic. It's meant to replace your /customize folder, not add to it, with the exception being /resources inside /customize, that one I use a lighter version (no footprints) but I didn't include it in the archive for size. I have no carrier stuff there, just settings for language (I think I made it all en_US, replace or add what you need) and layouts for the different scenes, some mail app behaviors (added back the Yahoo! mail and AOL mail options, I think), some footprint, stock, and weather information. Again, it's meant to replace your /customize directory and the smaller amount of files makes it way easier to edit.
Unfortunately, this did not work
Click to expand...
Click to collapse
Blame the xmls in /customize for that. I mentioned earlier I don't exactly know how the system picks which xmls to use, I think it looks at your carrier, which is then assigned a number (for example, let's assume T-Mobile is given number 238, so xmls with 238 on them will be loaded). Problem is inside those xmls are also apn settings (which I've removed from the files I provided so that the system looks instead for apn settings in apns-conf.xml in /etc).
You could flash your system erasing the whole /customize directory (and removing all mentions of it and it's sub-directories from the update-script so that install doesn't fail). Doing that will give you ALL languages available to the rom, but you'll also lose all your pre-loaded settings (like scenes, weather locations, footprints, stocks) and HTC Setup will take an ungodly amount of time to start (about 4-5 minutes after it's done dexopting) while it builds it's own default settings. It's another route you could take, though. Experiment and you'll eventually hit what you want/need.
OK, I guess I'll have to waste some time testing all this stuff, but I suppose I'll leave that to some other day and do more basic things for now.
But just to be sure, if I use your "customization" I'm basically starting from scratch (clean, defaults) and I can use the "old" customization stuff to understand how am I supposed to configured everything and adapt the clean customization folder to my needs. Right?
jubeh said:
You could flash your system erasing the whole /customize directory (and removing all mentions of it and it's sub-directories from the update-script so that install doesn't fail). Doing that will give you ALL languages available to the rom, but you'll also lose all your pre-loaded settings (like scenes, weather locations, footprints, stocks) and HTC Setup will take an ungodly amount of time to start (about 4-5 minutes after it's done dexopting) while it builds it's own default settings. It's another route you could take, though. Experiment and you'll eventually hit what you want/need.
Click to expand...
Click to collapse
This gave me an idea, dunno if it could work...
What if I did that, erase everything inside customize, let the system build its own default settings and then access that directory (through ADB maybe?) and see what the system has created. It should be much more cleaned, without all those carrier XMLs and stuff. Then I could start from there, what do you think?
I have a few more questions about the update-script if you don't mind, but I'm very tired to write them and discuss them now. I'll leave them for another day if you don't mind coming back here and help me out some more.
Thanks for all your help so far
I should probably have mentioned, some of the stuff on those xmls is pretty straightforward (setting language, region, weather, footprints, etc), but a lot of it (setting up default shortcuts, default widgets, system settings) requires working knowledge of android, or at least of how activities are handled and how xmls come into play and how android references the different activities in a package.
On a different note, the xmls are read-only configuration files, actually, anything in system is read-only data (program data, configuration data, resource data), so if you don't have a customize directory the system won't recreate it. What the system does do during normal boot (factory) is to take those carrier-specific settings and apply them to a file(s) in /data where configuration settings are ultimately written/re-written and accessed at will. The xmls are just a database of the settings that will ultimately get picked. When you don't have a /customize directory the system writes the settings straight to -rw enabled /data partition based on things like your current carrier, carrier provided information for locale, etc.
I don't think you can take what's written to /data and use it on a default install package, well, you could, but it's much easier (and a more correct approach) to learn how those xmls in /customize work.
jubeh said:
(...)but it's much easier (and a more correct approach) to learn how those xmls in /customize work.
Click to expand...
Click to collapse
I wouldn't mind doing that if there was some kind of documentation... As it is right now, it's too confusing and there are too many XMLs to begin with...
jubeh said:
I've not tried it yet. Worst case scenario, you'll get the current problem we have with eclair builds (sync will just keep running and eat out battery because it's looking for a service). That's why I'd suggest leaving gmail provider there, it's just a broadcast service, but without an app to receive the data, it'll do nothing. If your concern is data usage due to sync, then you should turn off gmail sync in settings, that way only calendar and contacts are synchronized (although you'll still be using data).
Click to expand...
Click to collapse
But if I leave the gmail provider there and do not turn off gmail sync in settings, my e-mail will still be synced right? There's just no Gmail app to view them but they are still going to be downloaded, correct?
Ok, I finally got a change to test the Gmail/GmailProvider thing and it didn't look like there any problems like trying to sync and draining the battery. Actually, if auto-sync was enabled, there was always a message saying the mail was never synced and no matter how many times you check/uncheck it, it wouldn't sync. If auto-sync was disabled, you could press the gmail button many times but nothing happened, no sync at all (of course).
I think this behavior is fine and I can safely delete the Gmail and provider from the phone without worrying that something will go wrong
Ok, now my other questions that I said I was going to post later...
As we talked about, you suggested to add a format data and cache right after a format to system. Comparing that to the MoDaCo ROM (and other ROMs too) it's common for them to, instead of formatting data, they do this:
Code:
delete DATA:app
delete DATA:init.sh
delete DATA:local
delete DATA:dalvik-cache
copy_dir PACKAGE:data DATA:
set_perm 1000 1000 0771 DATA:app
Why are they doing this? If they are not formatting, it means there's something inside data that they want to keep. Have any idea what and why?
The other question I had about the update-script is that the following two lines are found in the original HTC update but not on MoDaCo's:
Code:
symlink dumpstate SYSTEM:bin/bugreport
symlink dumpstate SYSTEM:bin/dumpcrash
Are they relevant somehow? Should I just ignore and leave them there or remove them just as MCR did, for some reason?
There's a file named build.prop inside the system folder. I've already searched countless times and can't find any proper documentation about this file... It seems it can hold various default properties for the system and it would be nice to know what I can configure there. Maybe I could workaround problem #4 (top of the topic) in this file? Maybe some file in the Android source has comments about the possible properties on this file? Do you have any idea?
One last thing...
I've read about odex and dex files but found it a little confusing... All I know is that original HTC updates come mostly with .apk files and a corresponding .odex file. But most (if not all) custom ROM's, do not have the .odex file but have a classes.dex inside the apk. What's the real difference between the two? And why custom ROMs prefer to have the .dex file instead of the .odex, is it better somehow for some reason? If so, what should I do to "change" the .odex files into classes.dex ones and put them inside the .apk files?
As we talked about, you suggested to add a format data and cache right after a format to system. Comparing that to the MoDaCo ROM (and other ROMs too) it's common for them to, instead of formatting data, they do this:
Code:
delete DATA:app
delete DATA:init.sh
delete DATA:local
delete DATA:dalvik-cache
copy_dir PACKAGE:data DATA:
set_perm 1000 1000 0771 DATA:app
Why are they doing this? If they are not formatting, it means there's something inside data that they want to keep. Have any idea what and why?
Click to expand...
Click to collapse
Yeah, I mentioned on the earlier post that doing "format DATA:" and "format CACHE:" would be the equivalent of running "Wipe data/factory reset" from the recovery menu since you mentioned about making a build that installs fresh. Paul's (MoDaCo) roms are no-wipe, so they preserve that program data and instead format all other directories inside /data that might be problematic during an upgrade; his roms use apps2sd, so he assumes that the user's downloaded apps are in mmcblk0p2 (the memory card's ext partition), so by formatting /data/app, he's only erasing the apps he included in his update package, if the user doesn't use a2sd, well, this erases their downloaded apps (one of the reasons I dislike the current a2sd implementation, it's not suited for all situations). Then he deletes data/init.sh, which is basically a script he includes in /data that runs during a rom's boot and starts things like a2sd, compcache, linux-swap, and other custom rom's "advanced" features. DATA:local is also app storage (I believe) and functions much like in windows' /users/x/application data/local, it can be problematic if not done between builds. Last, he erases /data/dalvik-cache, this is where the temporary application code resides (the extracted classes.dex from inside an apk) for rapid execution (for apks that haven't been pre-odexed). If you wish to make your rom no-wipe, add those lines instead of "format DATA:", but I'd remove "delete DATA:app" since it's a bit problematic for people who don't use a2sd.
The other question I had about the update-script is that the following two lines are found in the original HTC update but not on MoDaCo's:
Code:
symlink dumpstate SYSTEM:bin/bugreport
symlink dumpstate SYSTEM:bin/dumpcrash
Are they relevant somehow? Should I just ignore and leave them there or remove them just as MCR did, for some reason?
Click to expand...
Click to collapse
dumpstate is a debugging tool that android uses, but I don't know exactly where or how (I think it's an HTC-specific log for their HTCLog.apk). It contains two tools, dumpcrash and bugreport, much like toolbox is a binary that contains all the tools you see symlinked to it in update-script (bin, df, cp, mv, ls, insmod, etc.). It's not a problem at all if you remove it, but it's not a problem either to leave it there. Whenever something is symlinked, though (if it's something you added, for example, busybox tools), you have to make sure that the binary or a link to it or a previous symlink to it doesn't exist, otherwise your update-script will fail (like symlinking toolbox's insmod and then busybox's insmod, or busybox's ping if a ping binary already exists in the target symlink directory (for example /system/bin)).
There's a file named build.prop inside the system folder. I've already searched countless times and can't find any proper documentation about this file... It seems it can hold various default properties for the system and it would be nice to know what I can configure there. Maybe I could workaround problem #4 (top of the topic) in this file? Maybe some file in the Android source has comments about the possible properties on this file? Do you have any idea?
Click to expand...
Click to collapse
I guess that could work if you modify network type (there's a property somewhere in there about HSXPA, I think), but like you said, there's no documentation so it calls for some experimenting.
Those properties are also overrides, so, for example, if your rom doesn't do adb root (because ro.secure is set to 1 in init.rc), you can add ro.secure=0 in build.prop to enable adb root again.
Most properties are self explanatory, and pretty much, if you can't tell what it is, you probably shouldn't change it (for example, build.fingerprint allows you to change what kind of apps Market presents to you).
I'd say, don't mess around too much with the first batch (default build properties), with the exception of build.fingerprint.
One last thing...
I've read about odex and dex files but found it a little confusing... All I know is that original HTC updates come mostly with .apk files and a corresponding .odex file. But most (if not all) custom ROM's, do not have the .odex file but have a classes.dex inside the apk. What's the real difference between the two? And why custom ROMs prefer to have the .dex file instead of the .odex, is it better somehow for some reason? If so, what should I do to "change" the .odex files into classes.dex ones and put them inside the .apk files?
Click to expand...
Click to collapse
The classes.dex files is the dalvik bytecode for the application. It contains everything inside /appnamespace/src and /appnamespace/R if you're working from the source. It's basically all the java code already compiled for the dalvik virtual machine.
Dalvik doesn't do jit, so the classes.dex have to be extracted (if they're not already) and run through the virtual machine in a process called dexopt that produces code that can be much more rapidly excecuted by the dvm (dalvik virtual machine). The extracted code is then placed in /data/dalvik-cache (mentioned earlier) as [email protected]@[email protected]. All this pre-cached code eats away at your space in your /data partition (where you store your system data, like your email, messages, browser cache, and downloaded applications) and can be quite a big chunk of space gone (framework classes specially, since all jars inside /system/framework are nothing but java code, about 20MB for all framework code).
The solution to prevent usage of /data storage on an initial build is to have the code pre-extracted. This is done at compile-time running the created system through an emulator and then creating the odex files, which is almost exactly the same as the *@classes.dex found inside /data/dalvik-cache except that it's much better aligned to the device's memory configuration and offers (marginally) better excecution, plus when the package manager first encounters the apk, it's first step is to check if an .odex of it is available, if it is, then it skips checking and dexopting a classes.dex inside it and proceeds to the next package.
Odex files increase the space in your /system partition (it was already read-only, so it's not like you're missing out on something) so those 20 MB of framework that would have been tossed into your userdata partition are now out of the way into the useless (in an available-storage sense) /system partition so you have more free space for your apps.
There's a tool that can create odex files for apks that don't have them, it's called dexopt-wrapper and it has to be run from a running phone. However, this tool won't strip the (now unnecessary) classes.dex from inside an apk, so it has to be done manually. Removing the classes.dex once you've created an odex is a good idea merely on the basis of space savings. However, once a classes.dex has been odexed, it's very hard (used to be impossible) to turn it back to a classes.dex and place it inside an apk.
Usually, us rom cooks preffer the classes.dex inside the apk because odexes create conflicts when you try to mix and match apps between builds. Since the odex files are tied to the framework where they were created, adding an apk with it's odex to another framework (even one that's only ever-so-slightly different) will be very problematic (the odex code is no longer protected or verified, so the rom won't even boot because it will fail verification for all available packages).
The tool for reverting odex files is called deodexerant by jesus freke. It requires working knowledge of how the system goes through the dexopting process so you can run it in the proper order.
Another thing to know is that even if your /system is pre-odexed, your downloaded apps will still be run through the package manager and have their classes.dex dexopted and placed in /data/dalvik-cache.
Oh, and never, ever put odexes anywhere but /system/framework or /system/app (or /data/app_s if you use a2sd). The package manager currently can't handle odexes in /data/app or /data/app_private (the other two locations where it looks for packages other than /system/app).
In the end, whether to use/have odexes comes down to personal choice (and available space). There's two hero builds, those based in 2.73.405.61 and 2.73.405.66, that have not been pre-odexed, so they're perfect for experimenting, mix/matching, etc...
jubeh said:
Yeah, I mentioned on the earlier post that doing "format DATA:" and "format CACHE:" would be the equivalent of running "Wipe data/factory reset" from the recovery menu since you mentioned about making a build that installs fresh. Paul's (MoDaCo) roms are no-wipe, so they preserve that program data and instead format all other directories inside /data that might be problematic during an upgrade; his roms use apps2sd, so he assumes that the user's downloaded apps are in mmcblk0p2 (the memory card's ext partition), so by formatting /data/app, he's only erasing the apps he included in his update package, if the user doesn't use a2sd, well, this erases their downloaded apps (one of the reasons I dislike the current a2sd implementation, it's not suited for all situations). Then he deletes data/init.sh, which is basically a script he includes in /data that runs during a rom's boot and starts things like a2sd, compcache, linux-swap, and other custom rom's "advanced" features. DATA:local is also app storage (I believe) and functions much like in windows' /users/x/application data/local, it can be problematic if not done between builds. Last, he erases /data/dalvik-cache, this is where the temporary application code resides (the extracted classes.dex from inside an apk) for rapid execution (for apks that haven't been pre-odexed). If you wish to make your rom no-wipe, add those lines instead of "format DATA:", but I'd remove "delete DATA:app" since it's a bit problematic for people who don't use a2sd.
Click to expand...
Click to collapse
So, to make it clear, I could:
Option A) Add format DATA and format CACHE to my ROM and this would make my ROM to automatically wipe everything and start clean.
Option B) I could not add anything (no formats and no deletes) and warn the users to explicitly perform a wipe before flashing.
Option C) Add delete DATA:local and DATA:dalvik-cache and have a no-wipe ROM where the apps would be preserved from the last ROM, right?
Ok, I don't use a2sd and for now have no intention in doing so. My best guess is to start with option A for now and maybe opt by using some app to backup everything and restore everything back after flashing a wipe ROM. Or I could go with option C and everything could work fine but there's a chance I could run into some issues in the long run.
jubeh said:
The classes.dex files is the dalvik bytecode for the application. It contains everything inside /appnamespace/src and /appnamespace/R if you're working from the source. It's basically all the java code already compiled for the dalvik virtual machine.
Dalvik doesn't do jit, so the classes.dex have to be extracted (if they're not already) and run through the virtual machine in a process called dexopt that produces code that can be much more rapidly excecuted by the dvm (dalvik virtual machine). The extracted code is then placed in /data/dalvik-cache (mentioned earlier) as [email protected]@[email protected]. All this pre-cached code eats away at your space in your /data partition (where you store your system data, like your email, messages, browser cache, and downloaded applications) and can be quite a big chunk of space gone (framework classes specially, since all jars inside /system/framework are nothing but java code, about 20MB for all framework code).
The solution to prevent usage of /data storage on an initial build is to have the code pre-extracted. This is done at compile-time running the created system through an emulator and then creating the odex files, which is almost exactly the same as the *@classes.dex found inside /data/dalvik-cache except that it's much better aligned to the device's memory configuration and offers (marginally) better excecution, plus when the package manager first encounters the apk, it's first step is to check if an .odex of it is available, if it is, then it skips checking and dexopting a classes.dex inside it and proceeds to the next package.
Odex files increase the space in your /system partition (it was already read-only, so it's not like you're missing out on something) so those 20 MB of framework that would have been tossed into your userdata partition are now out of the way into the useless (in an available-storage sense) /system partition so you have more free space for your apps.
There's a tool that can create odex files for apks that don't have them, it's called dexopt-wrapper and it has to be run from a running phone. However, this tool won't strip the (now unnecessary) classes.dex from inside an apk, so it has to be done manually. Removing the classes.dex once you've created an odex is a good idea merely on the basis of space savings. However, once a classes.dex has been odexed, it's very hard (used to be impossible) to turn it back to a classes.dex and place it inside an apk.
Usually, us rom cooks preffer the classes.dex inside the apk because odexes create conflicts when you try to mix and match apps between builds. Since the odex files are tied to the framework where they were created, adding an apk with it's odex to another framework (even one that's only ever-so-slightly different) will be very problematic (the odex code is no longer protected or verified, so the rom won't even boot because it will fail verification for all available packages).
The tool for reverting odex files is called deodexerant by jesus freke. It requires working knowledge of how the system goes through the dexopting process so you can run it in the proper order.
Another thing to know is that even if your /system is pre-odexed, your downloaded apps will still be run through the package manager and have their classes.dex dexopted and placed in /data/dalvik-cache.
Oh, and never, ever put odexes anywhere but /system/framework or /system/app (or /data/app_s if you use a2sd). The package manager currently can't handle odexes in /data/app or /data/app_private (the other two locations where it looks for packages other than /system/app).
In the end, whether to use/have odexes comes down to personal choice (and available space). There's two hero builds, those based in 2.73.405.61 and 2.73.405.66, that have not been pre-odexed, so they're perfect for experimenting, mix/matching, etc...
Click to expand...
Click to collapse
Well, I'm currently basing my ROM on 2.73.405.38 as the .66 one has "test" on the name and it feels like a beta version, which I'd rather not use. The .38 version uses .odex files for most of the packages (only a few has classes.dex inside) and I guess I'll leave them like that. If future ROMs, like that .66 one, comes with classes.dex vs .odex files, well, then I'll just leave it like that...
That looks like a very important thing in Android apps and at the same time something that I should be very knowledgeable about before messing with it, so I'll just stay put
Thanks once again for taking your time with such complete answers
So, to make it clear, I could:
Option A) Add format DATA and format CACHE to my ROM and this would make my ROM to automatically wipe everything and start clean.
Option B) I could not add anything (no formats and no deletes) and warn the users to explicitly perform a wipe before flashing.
Option C) Add delete DATA:local and DATA:dalvik-cache and have a no-wipe ROM where the apps would be preserved from the last ROM, right?
Ok, I don't use a2sd and for now have no intention in doing so. My best guess is to start with option A for now and maybe opt by using some app to backup everything and restore everything back after flashing a wipe ROM. Or I could go with option C and everything could work fine but there's a chance I could run into some issues in the long run.
Click to expand...
Click to collapse
Sounds like you got it.
Well, I'm currently basing my ROM on 2.73.405.38 as the .66 one has "test" on the name and it feels like a beta version, which I'd rather not use. The .38 version uses .odex files for most of the packages (only a few has classes.dex inside) and I guess I'll leave them like that. If future ROMs, like that .66 one, comes with classes.dex vs .odex files, well, then I'll just leave it like that...
That looks like a very important thing in Android apps and at the same time something that I should be very knowledgeable about before messing with it, so I'll just stay put
Click to expand...
Click to collapse
Test only refers to the build being signed with test-keys instead of release-keys. In my testing, it makes no difference whatsoever for a rooted user, and there's many theories floating around about signatures, I haven't researched signatures a whole lot because test-keys have worked fine enough for me, so I'm not so sure, but they seem to be working fine for all.
The reason those releases are un-odexed (and signed with test-keys) is because of the problem with odexes I mentioned earlier. When HTC is testing their rom packages and they need to make, say, a framework change, all the apps with odexes would fail as the framework has changed, so, for testing purposes, it's best to leave the apks and jars in the build full (with classes.dex inside). Once you know your build is solid and you won't be changing much, it's safer to odex the whole thing (sort of like me, I'm waiting for the final release of eclair for ADP1 so I can put out a Dream rom odexed and fully working).
Thanks once again for taking your time with such complete answers
Click to expand...
Click to collapse
No problem, I get bored at work
So, version .66 is not beta or anything? I know MoDaCo has his latest ROM based on that and you're saying they are only different in the signing key, still, it's somewhat a "leaked" build, not quite "official".
But hey, if others are using it without any issues, maybe I should be using it too
On second thought...
1) I can't find a pre-rooted .66 version and I don't know how to root it :/
2) There's lots of files in system/xbin that I don't see referenced anywhere (not even in the update-script) and I don't know what should I do with them.
I'm finding it much more confusing to base my ROM on .66 than on .38...
It is a beta, of sorts, but between it and the final shipping product there's not much difference. It's just much, much easier to work with it.
1.) The simplest form of root is to change ro.sercure to 0 in default.prop in the boot ramdisk. Adding a su binary/Superuser.apk is optional, those you can pull from one of paul's builds.
2.) The system/xbin is added to the boot classpath in the boot ramdisk in init.rc. The only mention of it in in update-script is the permissions for the whole folder and then just a couple permissions for some tools, not all of them.
Should work for all Optimus V GB ROMs (aosp & IHO variants)
steps to modify:
extract
edit remove.sh script*
zip
sign
*works best in a unix editor. Notepad++ & Windows notepad sometimes screw with shell scripting handles new line something-or-other. In Windows I've used another free app Jedit for editing it and it seems to not give me 'installation aborted' msgs when installing the zip.
IHO Poo Remover rev5 (link updated)
comments on Email.apk: personally, I use it because it not only connects to Exchange servers but Hotmail email/contacts/calendar syncing can be set up directly in account settings with it there. instructions
Pls extract the zip & look at the remove.sh to see what I'm removing because I have my opinions. You can comment out & zip it back up to your tastes. If you have a variant you've made go ahead & post a link to it. Nice to compare what we each prefer.
In regards to ringtones & notifications I remove all but a basic ringtone. You can either add your own into the script- just drop them in the ringtones & notification subfolders or put additional ringtones on your sdcard in a folder made and named 'ringtones'.
Other notes is it removes a bunch of languages & adds a smaller English language.
I left in CMStats because I want Cyanogenmod to know we use it.
Don't know what Pacman.apk is so I have it commented out. May remove it if I figure out what it is.
Source on safe to remove apks and their purpose on Cyanogenmod wiki
rev5-
removed the sqlite tweaks as they didn't really do much on the IHO ROM
added removal of bootsound since it's an annoying idea
That SQLlite binary patch looks interesting. Looked at the source page, and they only have the /system/lib/libsqlite.so included, while your .zip includes /system/bin/sqlite3 too. I don't see a /bin/sqlite3 currently on my phone, what is the 2nd bin for?
jawz101 said:
Don't know what Pacman.apk is so I have it commented out. May remove it if I figure out what it is.
Click to expand...
Click to collapse
Pacman is run one time only. When you first sign into the market. It offers to download all the google apps at once. i.e. Maps, Facebook, Voice, Youtube, etc. I find it useful; since I use most of what pacman offers up. Hope that helps. I'll defiantly have to try poo remover. Love that name BTW.
I guess I left that part out, Whyzor. I'm pretty sure it's useless on its own but among these tweaks is a command that will vacuum the sqlite databases contained on the phone. I guess those that use those scripts would benefit from it most. I may take that piece out since I don't think it's being added completely (maybe not chmoding) because I end up having to run the chmod by hand sometimes. I could be wrong though and it may work.
Anyways, to actually use the sqlite3 you'd need a script like this one from FranciscoFranco, adjusted by mmarz . there's a portion of this script that vacuums the phone's databases. real-world benefits? It's likely negligible at best but I just threw it in there.
If you are ever interested I'd follow anything FranciscoFranco & Ungaze do- they're Optimus One tinkerers but they're obsessed with performance. Really anything they do is applicable to Android in general. Franco's Optimus One ROM is insane (xda) (github source)
I just replaced the /system/lib/libsqlite.so from the source thread you posted, set permission to be same as the other binaries, rebooted. Ran RL Benchmark and got the same, around 93 seconds overall score (using 245-600 ondemand CPU, IHO CM7.1. Are you getting the same performance?
UPDATE: If I overlock to 806 Mhz, was able to drop the overall time to 71 seconds, went back to original libsqlite.so and at the same clock speed, takes about 81 seconds. The performance gain is negligable given the corruption risk (and according to Blarf in the IHO thread, properly written apps won't see much of a benefit anyway).
yeah I'll probably take that out. It gave a noticeable improvement when I ran aosp. May also be that I'm not applying it correctly with this zip.
on aosp the RL Benchmark went from around 80 seconds down to maybe 45 seconds for comparison.
Probably best just have this as purely a bloat remover. Regardless, having it in there isn't messing anything up so this is still safe to use.
First off I love the poo remover. However, every time i edit the script, zip the package back up again, and sign it and then try to apply it the installation keeps getting aborted with CWM.
I have followed the instructions for windows, including using Jedit, and i have even tried with my macbook using a terminal session with pico.
i do sign the zip files also.
should i not include the stock folder META-INF in the altered script?
any help is greatly appreciated
that's usually what gets me is the editor I use to edit it with. I'd assume a macbook would be fine for editing it.
I usually remove these 3 files from the meta-inf folder before resigning as they get regenerated with that signing program (cert.rsa, cert.sf, manifest.mf). I don't know if that would affect anything but I've just been doing that out of habit.
Fortunately we understand what we're trying to do and really the only thing that's hanging it up is whatever the hiccup is.
It came down to making one change at a time until I got install aborted errors to stop
thanks much i will give it a shot
may want to try just unzipping it and rezipping it to see if that works.
Make sure you're zipping up the contents of the iho zip and not the actual folder.
Try it with & w/o signing it. If it works w/o signing it I'd leave that step out just so you can concentrate on editing the remove.sh script.
Possibly use a command line editor if your mac can do that (never used a mac)
issue is with unix line endings vs. windows/mac line endings
just found something if you're using Notepad++ try going to edit- EOL Conversion & switch it to Unix
i will look for another terminal editor and try that too.
i was originally using pico in the terminal.
when i was doing the editing of the remove.sh, i wanted to install the default ringtones and notifications.
do you think the restore that runs at the end of the removal is conflicting with it? I will give everything a shot today and let you know later what happens.
I'd just take those remove lines and audio folder out, put them in that audio folder, or just have a ringtone folder on your SD card
The restore is just adding stuff back
got it working
it was my stupid mistake of zipping the IHO folder and not the contents of the folder
so when i was signing it it created the META-INF folder and a IHO folder
Everything flashed and worked great
thanks again
I was interested in looking at this, but it no longer exists on mediafire. Any chance you can put it back up?
-John
Yeah.I will put it up tomorrow. It's also good to pm on old threads like this
I've been lazy... updated the post with a new link to the file. Sorry... been really slacking lately :/
It's the same poo remover revision5 from before. again, read the stuff at the top if you want to make changes.
I've honestly not been using my script for a long time but it's nice to have around.
I just uploaded tiny noot, a very minimal root tool for the NST glowworm. I think it would probably also work for the simple touch, but I've lent mine out and cannot test it to confirm.
I am basically a cobbler here; many thanks to GabrialD, DeanG and the folks with the minimal touch root tools, which this is based on - and of course to mali100 and the CWR team for getting that on the Touch and Glowworm. Everything below is put together with parts from those projects using what I've learned at XDA and from Dean's nook color repartitioning scripts.
They make it possible for someone like me to knock out a package that's a little more convenient to work from than booting noogie and manually copying in files.
I am using the clockwork recovery zip installation mode for copying in the minimal set of files - I'm not trying to support the google apps or the many interesting screen refresh hacks.
I am not including a modified uRamdisk - the stock uRamdisk supports ADB, and you can get root via adb wireless simply by typing su, so I chose to leave well enough alone.
GabrialD has already released a modified uRamdisk for the glowworm (to support root by default as well as the light) but since stock works for my purposes, I'm not using the modified one.
What it does include:
su and busybox
nook color tools in /system, so that nonmarket apps can be installed
adb wireless
ADW launcher
Amazon appstore, so there's at least once source of "easy" apps
Button Savior
Nook Touch Tools
Supermanager and the Busybox updater interface
The install process is three steps. Four if you decide - and you should - to make a backup of your device before you start. (that process is: make the noogie disk. boot from noogie. connect to your computer. dump the NSTG or NST using dd or another disk imaging tool, and is described in more detail with tips for lots of different operating systems at http://forum.xda-developers.com/showthread.php?t=1142983 That backup will let you restore your entire device to a known working configuration.
Download mali100's nook touch CWR disk discussed in this thread:
http://forum.xda-developers.com/showthread.php?t=1360994
the file itself is here:
http://forum.xda-developers.com/attachment.php?attachmentid=806433&d=1323121269
unzip the file and then write the .img file to an sdcard with your disk imaging tool of choice (dd in linux or win32 disk imager are two I use)
Once you've imaged the SD card, copy in these two zipfiles - leave them zipped:
http://www.mediafire.com/?ig75l5b9c24e7q6
http://www.mediafire.com/?2tfitzt97qqfaw7
Apply 1 of 2, then reboot, then
Apply 2 of 2
then remove your SD card and reboot. Although I have not gotten all the commands to run out of a single zipfile, Zydraka noticed, I think correctly, that you can run first the one and then the second without needing to reboot in between. I have done it that way successfully.
I tried putting all commands (copying the files, then setting permissions) into one file and the rooting process aborted in an ugly way. I ultimately needed to reimage the device to restore the oddly hosed /rom partition. After reimaging I was able to root successfully by running the two clockwork scripts back to back without a reboot.
A (very brief) guide to the CWR interface, for those who don't know it:
You will know your card is made correctly when you put it in your device and power on, and you see a clockwork gear nibbling at a nook N. Be patient while CWR loads; you will get to a screen with selectable menu choices.
Navigate up and down with the righthand buttons; navigate back with the lefthand upper button; choose an item or run a command using the raised n button.
Navigate down to "install zip file from sdcard" and hit N
Hit N again to "Choose Zip File from SDcard"
Navigate down to the first zip (labeled 1 of 2) and hit the n button
navigate to "yes - install"
hit the N button
once the first script is done, use the N button to navigate to and apply zip 2 of 2.
navigate back to the reboot menu using the lefthand side buttons. Once you are at the reboot menu item, you can pull the card, then reboot.
I used a 256 meg sdcard I had in the house for making the CWR disk. I find that to be a very convenient size for these disks - big enough to put a few files onto, not so big I wish I hadn't set it up as a CWR disk.
Thanks roustabout! It works great and it was super easy to do! I just got done installing a bunch of apps from Amazon.
Update: I just posted a tutorial with a video for noobs on my blog.
One thing to note, I didn't do the reboot that you mention in between the 1 and 2 packages and everything worked fine. I just installed 2 right after 1 and haven't had any problems.
Thanks for this, rooted last night everything is as it should be, the only issue I've run into is that I can't seem to install the Kindle app. It's not in the amazon market place, I tried backing up the APK from another device via EStrong and transferring the apk to the microSD, and I get a parsing file error. Any tips?
I have not been able to get Tasker to install yet, either.
One thing which sometimes works where other approaches fail (if you have the .apk file) is to ssh into your device (I use quicksshd) and log in as root, then cd to the directory the APK was copied to and issue the command
pm install blah-blah.apk
I have not yet tried that with Tasker, but it may also help with the Kindle app? I did need to do it for one of the apps I use, although I can't recall which one.
Edit: the 3.1 kindle app Zydraka points out works for me as well.
By default, the Kindle app is pretty unusable, very slow page turns. But by using the gesture-enabled screen refresh hack, it's very useable. (I found that using the no gesture version led to lots of apps just ignoring the hack's presence. I think Renate has a way around that, but I haven't read up on it.)
http://forum.xda-developers.com/showthread.php?p=22800284#post22800284
I got Tasker to install, but needed first to copy in the Maps jar and xml (to framework and permissions respectively) reboot and install via ssh - it might have worked just to reboot.
Since others may want Tasker available, putting the maps.jar and maps.xml files into the tinynooter is trivial, and I'll probably get to it soon.
I found that the older version of the Kindle app works, version 3.1.0.30. There's a donwload for it at Android Freeware. http://www.freewarelovers.com/android/app/kindle
So, after this, will the glowlight work in all apps? I need to make sure that, moon+ reader and EZpdf will glow in the dark, before I purchase the new nook.
thanks.
The glowlight seems to work in all apps. I'm not clear on how exactly it's turned on and off; it might be possible to have an app that uses a long press on the N button for something else, and that might interfere, but so far it works fine in the launcher, in the Kindle reader, in fbreader, in Newsrob (that I know I've tested.) even if you had an app that was doing something funny with that long press, you ought to be able to turn it on from the settings menu that comes up on a short press.
Once the glowlight is on, it seems to stay on until your screen goes to sleep, regardless of what applications you may also be using.
This is part of why I didn't get into the boot environment at all in this approach - I knew from manual rooting that I didn't have to change out uRamdisk so I decided to leave it all alone.
Thanks for tinynoot! It's working well for me, and glowlight behaves normally.
roustabout said:
I just uploaded tiny noot, a very minimal root tool for the NST glowworm. I think it would probably also work for the simple touch, but I've lent mine out and cannot test it to confirm.
I am basically a cobbler here; many thanks to GabrialD, DeanG and the folks with the minimal touch root tools, which this is based on - and of course to mali100 and the CWR team for getting that on the Touch and Glowworm. Everything below is put together with parts from those projects using what I've learned at XDA and from Dean's nook color repartitioning scripts.
They make it possible for someone like me to knock out a package that's a little more convenient to work from than booting noogie and manually copying in files.
I am using the clockwork recovery zip installation mode for copying in the minimal set of files - I'm not trying to support the google apps or the many interesting screen refresh hacks.
I am not including a modified uRamdisk - the stock uRamdisk supports ADB, and you can get root via adb wireless simply by typing su, so I chose to leave well enough alone.
GabrialD has already released a modified uRamdisk for the glowworm (to support root by default as well as the light) but since stock works for my purposes, I'm not using the modified one.
What it does include:
su and busybox
nook color tools in /system, so that nonmarket apps can be installed
adb wireless
ADW launcher
Amazon appstore, so there's at least once source of "easy" apps
Button Savior
Nook Touch Tools
Supermanager and the Busybox updater interface
The install process is three steps. Four if you decide - and you should - to make a backup of your device before you start. (that process is: make the noogie disk. boot from noogie. connect to your computer. dump the NSTG or NST using dd or another disk imaging tool, and is described in more detail with tips for lots of different operating systems at http://forum.xda-developers.com/showthread.php?t=1142983 That backup will let you restore your entire device to a known working configuration.
Download mali100's nook touch CWR disk discussed in this thread:
http://forum.xda-developers.com/showthread.php?t=1360994
the file itself is here:
http://forum.xda-developers.com/attachment.php?attachmentid=806433&d=1323121269
unzip the file and then write the .img file to an sdcard with your disk imaging tool of choice (dd in linux or win32 disk imager are two I use)
Once you've imaged the SD card, copy in these two zipfiles - leave them zipped:
http://www.mediafire.com/?ig75l5b9c24e7q6
http://www.mediafire.com/?2tfitzt97qqfaw7
Apply 1 of 2, then reboot, then
Apply 2 of 2
then remove your SD card and reboot. Although I have not gotten all the commands to run out of a single zipfile, Zydraka noticed, I think correctly, that you can run first the one and then the second without needing to reboot in between. I have done it that way successfully.
I tried putting all commands (copying the files, then setting permissions) into one file and the rooting process aborted in an ugly way. I ultimately needed to reimage the device to restore the oddly hosed /rom partition. After reimaging I was able to root successfully by running the two clockwork scripts back to back without a reboot.
A (very brief) guide to the CWR interface, for those who don't know it:
You will know your card is made correctly when you put it in your device and power on, and you see a clockwork gear nibbling at a nook N. Be patient while CWR loads; you will get to a screen with selectable menu choices.
Navigate up and down with the righthand buttons; navigate back with the lefthand upper button; choose an item or run a command using the raised n button.
Navigate down to "install zip file from sdcard" and hit N
Hit N again to "Choose Zip File from SDcard"
Navigate down to the first zip (labeled 1 of 2) and hit the n button
navigate to "yes - install"
hit the N button
once the first script is done, use the N button to navigate to and apply zip 2 of 2.
navigate back to the reboot menu using the lefthand side buttons. Once you are at the reboot menu item, you can pull the card, then reboot.
I used a 256 meg sdcard I had in the house for making the CWR disk. I find that to be a very convenient size for these disks - big enough to put a few files onto, not so big I wish I hadn't set it up as a CWR disk.
Click to expand...
Click to collapse
You know, it should be nice if before using the packages other people create, for your own project, you asked them for permission to use them, if not, at least create your own scripts.....
Yes I'm refering to me.... thats not cool.
Anyway, the two step process is not necessary here, thats just for preventing some Gapps database corruption, you edited that code away allready and there are no Gapps installed, so add the code to correct the permissions on the first zip, and everything should work fine, no need to rm dalvik either if you arent modifying framework.jar, etc, it should also speed the first boot time.
I apologize - this was intended to be a quick hack and largely for my own use (as I was testing stuff on both my and my girlfriend's glowworms) but I realized there were a lot of folks trying to root their gw's manually. I thought it worked well enough to share.
I didn't intend to present it as original and if I appeared to I apologize.
Say the word and I will yank the thread outright, and I would have no objection to your asking the mods to do so, either.
roustabout said:
I apologize - this was intended to be a quick hack and largely for my own use (as I was testing stuff on both my and my girlfriend's glowworms) but I realized there were a lot of folks trying to root their gw's manually. I thought it worked well enough to share.
I didn't intend to present it as original and if I appeared to I apologize.
Say the word and I will yank the thread outright, and I would have no objection to your asking the mods to do so, either.
Click to expand...
Click to collapse
Don't worry, just stating that before creating a thread with others people work, you should ask them.
Everything is fine, It didn't even pass my mind the idea of reporting it, we are a small niche community, active members must be praised, so dont worry, and I encorage you to keep deving ^^, just that before using other peoples work and starting a thread with it, ask them for permission, no one is gonna deny it and it's the kind way of doing things .
I'm planning to get my hands on a Glow tonight, so over the weekend I should be able to get together a full Nooter for it.
tiny noot - also works for older NST
Just so folks know, I've confirmed that the tinynoot rooter also works on the NST running 1.1.2 firmware.
It will probably work on earlier firmware also, since it is not replacing uRamdisk or framework files.
Are Supermanager and the Busybox Updater supposed to work? Supermanager crashes back to home, and Busybox won't install.
Did you apply both files, and is there an sd card in your device? I just tested the busybox updater and was able to get it to update the installed busybox. It requires that you have an sdcard inserted to work - I remember being puzzled by that the first time I tried using it on a device.
supermanager is crashing. I hadn't tried running it on the device before, and hadn't noticed that.
Looking at logcat, yes, supermanager's crashing in the background quite a bit. It seems to be looking for things which are not available, for instance, a dialer, and erroring out when it can't find them.
roustabout said:
[...] supermanager is crashing. I hadn't tried running it on the device before, and hadn't noticed that.
Click to expand...
Click to collapse
Supermanager has always been a problem, at least for me, using TouchNooter. I believe it's intended to provide file manager capability, particularly for installing APKs on uSD. Once I get Market (Play Store) access, reinstalling supermanager fixes the problem. At that point, I don't need it anymore.
I've always had to work around this when rooting my Touch devices. I'd suggest a basic file manager be provided instead for Day 1.
I'm rooted with tinynoot. Recently I've been experiencing excessive battery drain. I'm eliminating apps I'd installed to if that helps. Wondering if anyone has experience with apps that are problematic in that regard? Dropbox? Amazon Appstore? Facebook? 1Mobile Market? I assume nothing that was provided by default with tinynoot. Thanks.
Hi Glowco,
I'd suggest installing task management apps to get a view of what is actually running (not all processes relate to an installed app icon that you can uninstall). I use Advanced Task Manager to view running apps, and Autorun Manager to control what processes start up at boot time.
Ian
Thanks, I'll keep that in mind. In the meantime, as an experiment I uninstalled several apps including Amazon Appstore, 1Mobile Market, FB, and Wireless ADB. Good result - my battery charge hasn't decreased in an hour and a half. If I decide I miss them I can try adding them back and use your method.
That's good news!
I'd suggest that Wireless ADB is not to blame, since it does not stay resident once it's closed and in any case does nothing until you click the big red button
Of the others, I have Amazon Marketplace installed and I don't experience any battery issues (I'm Glownooted not Tinynooted but don't think that's relevant in this discussion), but I can't speak for the other two apps. If I were paranoid (and I am! ) I would point at Facebook, since it's purpose is marketing and wants to follow your every move
Ian
Hello guys,
I've just flashed the Paranoid Android ROM by WOH (http://forum.xda-developers.com/showthread.php?t=1912187&page=111) and I really like it.
However, I'm having some kind of issue with the PA engine settings.
The problem goes like this:
1. When I set the global UI settings, I'm asked to reboot, but the settings are back to defaults after the reboot.
2. When I edit the preferences for a particular app, I'm only able to make it work by setting and applying the needed values followed by using the launch button, which finally makes the changes effective. These changes are, however, also reset after rebooting the phone.
I did some searching and found this hint (http://www.paranoid-rom.com/forum/guides-references/256-hint-pa-prefs-does-not-save-changes) which seems to deal with this problem, but haven't had any luck with it. In the terminal, when trying to run the commands, I get an error saying my file system is mounted read only. So I tried modifying the file perimissions in the ES file manager (which also didn't work on some occasions, but sometimes it did), then running the terminal commands successfully, but without any effect on the PA preferences bahaviour after rebooting.
I ended up editing those files manually and removing the backup file (which, I thought, was overwriting the preferences file, reverting the settings to defaults). The ES file manager also behaved very oddly when trying to manipulate those files, once I was not allowed to delete those files, than they disappeared on their own, same goes for renaming.
Finally, I think, the problem is being caused by the properties file being overwritten with the defaults on every boot. So far I've been unable to determine the cause of this behaviour, so I hope perhaps some of you have come across this problem and know the solution. Thanks in advance for that.