Related
Soooo, as many of you have found out, it has been fun watching you guys scratch your heads over this, there is a new file in JF update called framework.cramfs.
Also as many have found out, this complicates making themes for JF 1.51.
So whats the deal?
Well T-mobile has never been one to conserve space and have pushed the internal memory limits of system to the brink, so far that JF had to find a way to make room for all his goodies and T-mobiles goodies.
Jf did this by puttin the contents of framework into a Cramfs file, which is like a zip file of sorts.
Here is more info on them: http://en.wikipedia.org/wiki/Cramfs
This allowed him to keep the contents compressed but still accesible. To do this he has the system mount the image file before accessing it, which is why you can browse through it on Astro and find framework.apk with no problem.
This technique saved us about 10mb's of space in /system
Sooooo......How do you make themes for JF 1.51?
First you need to grab JF's build environment here is where you can get it: http://jf.andblogs.net/wp-content/plugins/download-monitor/download.php?id=17
Next you need to learn about it Check this out:
"In addition to the updates themselves, I am also releasing a build environment that can use to build each update from scratch. You can use these to easily make your own custom updates. It includes some utilities that were built from git source. The binaries are for 32bit x86 linux. If you want to run it on a different platform, you're on your own.
The general idea of the build environment is that it extracts the original files from the official update (or from my original ADP1 update), and then copies over anything from the various ModifiedFiles folders, then packages it all back up into a ready-to-be-applied update.zip. It does this for the boot image, recovery image and system folder. You can also specify files to delete in the various OriginalFilesToDelete.mk files.
Consider anything new that I created for the build environments (the makefiles, etc.) to be in the public domain. Everything else retains its original license of course.
Instructions:
* extract the build environment into a folder
* download the official update that the update is based on, and put it in the root of the build environment
* run make as root. yes, it has to be with root, because the binaries in the 2 cramfs images should be owned by root. (note: I plan on using fakeroot in the future, to workaround the need to be root)
* after make finishes, assuming there are no errors, the update should be in Workspace/update.zip."
Yep thats right! You need linux to do this! I mean come on, Android is not a Microsoft product, it's Linux based....Time to get your hands dirty.
You will need to copy your modified framework-res.apk, which you can pull from your phone while running JF 1.51, into Build/System/framework
Then you will build your update.zip. Not that this will be a full update meaning it will be large.
You can size it down after you build it, but it will create the cramfs image you need with all your changes.
I have not done this! I am not upgrading to 1.51. I will stick with the build I can create and change as I like.
What does this mean?
This means I don't know exactly how to do this, I haven't done this.
I researched this and have posted my findings, this is how you will build a theme template for JF 1.51.
Things are gonna change and get harder as things get more complicated. Be ready for this, be prepared for it.
Also, there is always more then one way to skin a cat.
Good luck guys,
Stericson
woot! guess it's time to start using GIMP instead of Photoshop lol
So as of right now there's no way to do this in linux 64bit? Is there any info on signing updates in linux? Looked around early and didn't see anything.
Look up the original tool for signing files...its a command line based tool...JF released it in his original releases. This works on linux.
Stericson
This is just for the US version of 1.51, right? Or is it also for the UK/EU? Just asking, because my ADP 1.51 JF is good to go, no cramfs!
Thats correct just the US.
You can do this all in windows.. i've posted elsewhere instructions already.. use cygwin.
How about a lite version, or maybe JF can make a non-cramfs(craps) version. As most of us with root have apps 2 SD anyway and don't give a darn about a minor 10megs of phone left. oh well, guess back to adp without latitude.
Shaggy
Shagman68 said:
How about a lite version, or maybe JF can make a non-cramfs(craps) version. As most of us with root have apps 2 SD anyway and don't give a darn about a minor 10megs of phone left. oh well, guess back to adp without latitude.
Shaggy
Click to expand...
Click to collapse
Shagman this doesnt have anything to do with apps on the phone. The partition /system is totally separate from the space that apps are stored on.
If you dont know what your speaking about, don't insult the work of others. The extra 10 megs in /system for t-mobiles build is amazing and crucial for themeing since themes genrally increase the amount of space used in system, so really what JF unintentionally did was give you MORE space for theming, which will lead to bigger and better themes.
Also, yes you can create a Cramfs file using cygwin since it is basically a linux shell. However it will not create the update for you as this build environment will.
Also, thats why I said there is more then one way to skin a cat
Stericson
Stericson said:
Shagman this doesnt have anything to do with apps on the phone. The partition /system is totally separate from the space that apps are stored on.
If you dont know what your speaking about, don't insult the work of others. The extra 10 megs in /system for t-mobiles build is amazing and crucial for themeing since themes genrally increase the amount of space used in system, so really what JF unintentionally did was give you MORE space for theming, which will lead to bigger and better themes.
Also, yes you can create a Cramfs file using cygwin since it is basically a linux shell. However it will not create the update for you as this build environment will.
Also, thats why I said there is more then one way to skin a cat
Stericson
Click to expand...
Click to collapse
I tried Cygwin and it was really easy to use. It allows you to extract the files, manipulate them and you can recreate the cramfs file. Unfortunately, when I signed the zip file and flashed my phone it did not update the framework as I was expecting. I still had the grey status bar. I can't figure it out. Any ideas?
You need a full system update. Use JF build enviro.
Stericson said:
You need a full system update. Use JF build enviro.
Click to expand...
Click to collapse
I don't have Linux. Will it work with Cygwin? Because I don't think Cygwin can be ran as root. (But I just downloaded it today for the first time so I dunno and since I don't have Linux, I'm obviously a Linux noob.)
I already tried swapping out the cramfs file in the full 40 something mb update. I'm trying again just for the heck of it.
why not just use adp? I decided I'll do that, I don't need myfaves on my phone since my 5 never change. What other advantages are there to running the tmo us version other than that app?
Thank you so for this info... I really hate booting into windows xp but im still pretty new to linux so i just learning the good stuff... Again I appreciate anything that makes it were I dont have to boot into windows. Now if I can just sync/backup my wife Blackberry in linux i would be set.
jdwme said:
why not just use adp? I decided I'll do that, I don't need myfaves on my phone since my 5 never change. What other advantages are there to running the tmo us version other than that app?
Click to expand...
Click to collapse
Nevermind... stupid reply. I'm tired. LOL.
I'm using ADP now... but I haven't upgraded to the adp 1.51 US as of yet. So I figure I might as well go CRB43 since I want to update.
Binary100100 said:
I don't have Linux. Will it work with Cygwin? Because I don't think Cygwin can be ran as root. (But I just downloaded it today for the first time so I dunno and since I don't have Linux, I'm obviously a Linux noob.)
I already tried swapping out the cramfs file in the full 40 something mb update. I'm trying again just for the heck of it.
Click to expand...
Click to collapse
Nope, dont think it can be used with cygwin. Yall check these out:
http://wubi-installer.org/
http://lifehacker.com/228956/install-and-run-ubuntu-without-disturbing-windows
http://portableubuntu.demonccc.cloudius.com.ar/
http://www.vmware.com/products/player/
Plenty of easy options guys.
Stericson
Binary100100 said:
Nevermind... stupid reply. I'm tired. LOL.
I'm using ADP now... but I haven't upgraded to the adp 1.51 US as of yet. So I figure I might as well go CRB43 since I want to update.
Click to expand...
Click to collapse
lol I think everyone was tired. I was serious though, I don't see any other advantage to having to tmo stuff. I'm running Dudes build right now, and it's an old build, the .8 version Haven't had myfaves since rc33, but I'm not updating until I finish making my update look how I want it and adp is the way to go for that without having to make it too overcomplicated
Thread bookmarked. I want to learn more about Linux anyway.
Haha, good work JF. I knew something was odd when I saw I had more /system/ space left over when going from ADP 1.51 to US 1.51. Good show indeed.
uberingram said:
Haha, good work JF. I knew something was odd when I saw I had more /system/ space left over when going from ADP 1.51 to US 1.51. Good show indeed.
Click to expand...
Click to collapse
you should be able to do the same on ADP (if needed down the road) for framework.
add the appropriate line to init.rc and roll up a cramfs image and stick it in /system/framework. i assume the kernel will have the module needed to mount loop for cram on ADP.
I just hope ADP stays with uncompressed framework file, or I will just have to wait for someone else to redo my Harley theme for the new compressed format. Better yet, would be cool if someone made a theme editor prog for Windows or Ubutu.
Shaggy
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.
In a lot of the custom roms threads I see that people are always asking the cooks to update the system apps as soon as a new one is released.
Rather than us users constantly hassling the cooks to do this, could somebody post an 'idiots' guide how to update the system apps ourselves?
I have seen a few threads about how to remove apps using adb, but none on how to update them.
Any help would be appreciated, not just by the users, but probably by the overworked cooks too
Cheers.
EDIT: by this I mean a way to update the apk in the system folder rather than the date to save space on the phones memory.
One way is to open the market and click on the 'downloads' link at the top and it will give you a list of installed apps and the ones highlighted in red have updates.
Another way is to search the market or a free app called 'aTrackDog' which will check all your apps for updates.
Thanks, but that is not what I meant. I should have made it clearer in my question.
What I want is this: a way to update the applications so that the updated apk goes into the system folder rather than the data folder. That way the update doesn't take up any more of the precious space on my phone.
I'll edit the OP to show this.
But thanks anyway for your help.
Don't you mean the fact that certain apps included in roms cant be updated. Only possible by flashing an updated version of that rom.
Wrong section.
prodygee said:
Don't you mean the fact that certain apps included in roms cant be updated. Only possible by flashing an updated version of that rom.
Click to expand...
Click to collapse
No, that's not true. Often when a cook produces their own rom they will release an "Update pack" when a system app has been updated (such as Flash or Maps). For an example, see here under 'updated system apps':
http://forum.xda-developers.com/showthread.php?t=773997
What I am asking for is if anybody knows how to use adb to update apps on the system partition. When updating from the market a the update takes place on the data folder, not the system one.
Ta.
scutworker said:
No, that's not true. Often when a cook produces their own rom they will release an "Update pack" when a system app has been updated (such as Flash or Maps). For an example, see here under 'updated system apps':
http://forum.xda-developers.com/showthread.php?t=773997
What I am asking for is if anybody knows how to use adb to update apps on the system partition. When updating from the market a the update takes place on the data folder, not the system one.
Ta.
Click to expand...
Click to collapse
do you mean by example
Code:
adb push Vending.apk /system/app
adb reboot
TomLeeDesire said:
do you mean by example
Code:
adb push Vending.apk /system/app
adb reboot
Click to expand...
Click to collapse
That is something like it. What I want is a guide to what to do to update these apps when an update is out in the market place. Something like being able to update the app from the market, but then move the new apk to the system folder so to save space on data.
Thing is, if you're using a cooked ROM you're likely to be using A2SD+ which makes the need to not have system updates redundant as you've got your EXT partition. The other way would just be to edit the original ZIP file and reflash the ROM without a wipe
EddyOS said:
Thing is, if you're using a cooked ROM you're likely to be using A2SD+ which makes the need to not have system updates redundant as you've got your EXT partition. The other way would just be to edit the original ZIP file and reflash the ROM without a wipe
Click to expand...
Click to collapse
That is not entirely true, even though I sport A2SD+ (and it's 1/3 free) my /data is always begging for room... I'm always at the 15MB-free-limit.
Then you've either got a LOT of apps storing data or something's not right
Small dirty 0.1beta guide
I'll use teppic's update zip as example (hope he doesn't mind), sample of his updateapps.zip can be found in this thread -> http://forum.xda-developers.com/showthread.php?t=773997
1. Install the update from Market, then open Appmonster and backup it on SD. After that, uninstall the update, to free up space.
2. Open the update.zip with WinRar (don't unpack it), you'll see 2 folders
META-INF
system
Open the inside of META-INF till you get to update-script and open it for editing, here's the example:
Code:
show_progress 0.1 0
delete SYSTEM:app/YouTube.apk
delete SYSTEM:app/YouTube.odex
delete SYSTEM:app/Facebook.apk
delete SYSTEM:app/Facebook.odex
delete_recursive DATA:data/com.android.vending
copy_dir PACKAGE:system SYSTEM:
set_perm_recursive 0 0 0755 0644 SYSTEM:app
show_progress 0.1 10
Replace/add/remove .apk's (you can add .apk without .odex) in this list, as those commands will delete existing apps from /system/app on phone
The rest of the script will copy the content of the other folder you saw before (system with subfolder app), so you want to add/remove apk's you like to there. Remember to use WinRar's function to add the file to archive, everything done here's is inside of the archive. When you're done, save the update-script, check everything again and close WinRar.
3. Flash the zip ;]
or do it manually:
h_ttp://forum.cyanogenmod.com/topic/8067-how-to-manually-update-system-apps/
EddyOS said:
Then you've either got a LOT of apps storing data or something's not right
Click to expand...
Click to collapse
I do think A LOT fits (about 300 apps installed)...
That's exactly what I wanted.
Thanks for the help, everybody.
Does this work on a Rooted (Unrevoked) phone with HTC's Original Froyo?
- I've been following teppic74's thread for some time now, and for every app that get an updated I get closer to flashing his ROM... but if I can just update my apps I wouldn't have to go through the process of reinstalling everything else after...
gosa said:
Does this work on a Rooted (Unrevoked) phone with HTC's Original Froyo?
- I've been following teppic74's thread for some time now, and for every app that get an updated I get closer to flashing his ROM... but if I can just update my apps I wouldn't have to go through the process of reinstalling everything else after...
Click to expand...
Click to collapse
Sure thing.
thed0g said:
Sure thing.
Click to expand...
Click to collapse
Nice!
That means my weekend is saved, I 'm gonna give myself some updates!
- Thanks!
One thing...if using the push and pull commands in adb to move the apk files to the system partition, what happens to the .odex files? Do you move them as well?
scutworker said:
One thing...if using the push and pull commands in adb to move the apk files to the system partition, what happens to the .odex files? Do you move them as well?
Click to expand...
Click to collapse
.odex files are only on some custom rom's, you probably dont have them.
Hello again...
I kind of never got around to doing this last weekend - both because lack of time but also because the more I read the more worries I have. (Don't know when I lost my "gung ho" attitude, but age seems to turn me into a chicken...)
Anyway - I wanted to ask one important question.
How do I keep an eye on the space I have available for updating my apps? What if the updates are so much larger than the apps I'm replacing, what will happen then?
I read in teppic74's thread that he recommended some adjustments to save space, but how do I know what I have to "play" with? Is there a good app to read available space in "system"?
Thanks in advance,
gosa
So i am here with a new idea. A rescue.zip which can be used to rescue any android device which have a recovery like the famous cwm.
So here is it..
Some times we people screw up our android os like hell, and to reboot the device we usualy do a recovery flash of a new os, flash back our nandroid backup ( both on worst conditions) or even do permission fix, clean cache or dalvic cache( those in 'not that worse' conditions) . So thats are all the options we got. Rit?
Although flashing recovery backups, new roms can fix all, it will also eatup our apps, current setups, contacts, msgs, etc( in case we dont have backups) and will probably screw us. All we can do is say " WTF..WTF..WTF.."
SO here is my idea,
Find out the causes of what causes a reboot, non-boot, hang,fc etc.
And keep a zip that can be flashed through recovery, that has a solution for our problem. They may be including..
1) fix permission of system, data, and user data.
2) zipalign the apps
3) fix the default clock speed of processor
4) defragment memory
5) flash a new copy of su and busy box
6)wipe data or system or ext or cache or dalvic cache
7) flash a new copy of framework.res, system-ui.apk, settings.apk with default permissions( those files are kept in separate "custom" folder on the zip, so that end user can put their own files to that "custom" folder for flashing., the reason behind it is known to all, yap. Not all devices have them in common, every device have its own files)
These are all i got for now, pls post ur ideas and knowledge for any possible cure about any problem u faced/ cured. So that we can make it an ultimate rescue.zip that have a cure for 99% problems android os have. The rest 1% will go with a clean flash.( well we cant avoid that if we did something that bad).
So my plan is to use aroma installer( now on hard learning to find how it works). Throw in some scripts, files etc. Into the zip.
And since its not a device specific .zip file, i want to know how and why any problems are caused in any device( there are many common problems, but that is not what i ask for. I ask for device/os specific problems, and not for a problem that we can cure after booting, but for a problem that can make the device un-bootable) . So u people may help me to find those problems and cures for it. For my knowledge i have experience with wildfire and hd2.
Well i will keep this thread for a week or two, so that u can post ur knowledge, and info. after that i will release the file for u.
To the admin. Of the forum, pls keep this thread as announcement so that all can take a look.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.
If you plan to do this available to any android device, the file size will be so big that it will become useless. Every phone has different apk, and not only that, but those apk are different in different version of os. For example, CM9 framework should not work on google release. Worst, older CM9 framework might not work on newer CM9 and newer framework might not work on older. Also, one of the cause of bootloop that i have been experiencing since i have my GNexus is data corruption of apps. The only way i had was to wipe data. I dont think there is a way to know if your app are corrupted with script. I also seen a lot of strange problem on SGS II like the kernel being erased. Well, in this case this package would be useless. So i guess that having this package would be awesome, but wont happen. My best advice is that you could create a universal guide on how to recover from bootloop/fc/hang with the minimum of impact on the phone. This is just my opinion tho.
Sent from my Galaxy Nexus using xda premium
You could add using flags in the updates filename, see some roms or themes for the lg optimus 2x for more information. It uses sed. For example, "update-wc-wd.zip" would wipe /data and /cache.
You could also merge these features in a customized clockwork mod recovery, the up side would be that you could automatically make a backup of the last flashed full ROM's systemui etc. this would also allow usage of the touch screen/volume keys to choose an repair option. You could even allow users to backup specific applications along with their data, and let users restore it later on after a fresh flash. I have some basic knowledge in modifying the recovery so I might help you out a little if you're interested.
chadouming said:
If you plan to do this available to any android device, the file size will be so big that it will become useless. Every phone has different apk, and not only that, but those apk are different in different version of os. For example, CM9 framework should not work on google release. Worst, older CM9 framework might not work on newer CM9 and newer framework might not work on older. Also, one of the cause of bootloop that i have been experiencing since i have my GNexus is data corruption of apps. The only way i had was to wipe data. I dont think there is a way to know if your app are corrupted with script. I also seen a lot of strange problem on SGS II like the kernel being erased. Well, in this case this package would be useless. So i guess that having this package would be awesome, but wont happen. My best advice is that you could create a universal guide on how to recover from bootloop/fc/hang with the minimum of impact on the phone. This is just my opinion tho.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
I told it already, the "custom" folder is not filled. It will be kept empty. The user can put a file, which ofcourse is the file of the device he/she have or want to get repaired. All he has to do is copy and paste the file from the working zip( zip file of his currently installed rom, that encounter the problem) of his rom to the custom folder inside the rescue.zip.
And the things that are common will be scripts, but those too will contains device specific mound points, paths, etc. I think that will be common( ie, the working of script, once the mound is done). Am i right?
So all i have to figure out is mount points, paths etc.. i got a couple of them, about 15 or so. And pls help me to find the rest.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.
a good idea to add is a file system chech like windows systems has. By installing a rom the installer should first check for bad sectors and mem blocks before installing the rom. After all blocks and sectors are scanned and the bad ones marked as "bad or corrupt" it should run something like defrag and place the bad blocks at the end of the file table. When all is done .. then the true rom install should start.
This will prevent heaps of problems since the curent installs just write over a bad block or sector creating the most weird problems. A fault checker/repair will take away a lot of strange forced closes and othere software/hardware failures.
Most phones wont last that long so that bad blocks or sectors can occure. But for the flashing junkies among us its a serious problem what can occure. I guess after 1000 or more installs bad sectors or blocks will occure and not all are being able to be repaired
Sent from my Galaxy Nexus using XDA App
Mikevhl said:
You could add using flags in the updates filename, see some roms or themes for the lg optimus 2x for more information. It uses sed. For example, "update-wc-wd.zip" would wipe /data and /cache.
You could also merge these features in a customized clockwork mod recovery, the up side would be that you could automatically make a backup of the last flashed full ROM's systemui etc. this would also allow usage of the touch screen/volume keys to choose an repair option. You could even allow users to backup specific applications along with their data, and let users restore it later on after a fresh flash. I have some basic knowledge in modifying the recovery so I might help you out a little if you're interested.
Click to expand...
Click to collapse
I am totaly newbee to lg. I have experience with htc, few samsung, etc. So can u pm me the details? Also is it usable to create recovery? I think a zip file with selectable options is more friendly. The thing is building a recovery wont make it universal( or atleast common for a couple of devices) and we will have to port them for each and every device. Thats the problem.
But any way i want ur help in building it. Can u pm me an example for mounding script in lg devices? And any thing that may become useful. Thank you.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.
wilwilwel said:
a good idea to add is a file system chech like windows systems has. By installing a rom the installer should first check for bad sectors and mem blocks before installing the rom. After all blocks and sectors are scanned and the bad ones marked as "bad or corrupt" it should run something like defrag and place the bad blocks at the end of the file table. When all is done .. then the true rom install should start.
This will prevent heaps of problems since the curent installs just write over a bad block or sector creating the most weird problems. A fault checker/repair will take away a lot of strange forced closes and othere software/hardware failures.
Most phones wont last that long so that bad blocks or sectors can occure. But for the flashing junkies among us its a serious problem what can occure. I guess after 1000 or more installs bad sectors or blocks will occure and not all are being able to be repaired
Sent from my Galaxy Nexus using XDA App
Click to expand...
Click to collapse
Pls pm me the idea how to make the checking script. Or links that have info in this. Thank u in figuring out such a prob. I am unaware of that.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.
showlyshah said:
I am totaly newbee to lg. I have experience with htc, few samsung, etc. So can u pm me the details? Also is it usable to create recovery? I think a zip file with selectable options is more friendly. The thing is building a recovery wont make it universal( or atleast common for a couple of devices) and we will have to port them for each and every device. Thats the problem.
But any way i want ur help in building it. Can u pm me an example for mounding script in lg devices? And any thing that may become useful. Thank you.
HYPERDROID EXTREEM EDITION-THE NEW BENCHMARK ROM FOR HD2.
Click to expand...
Click to collapse
I'll send this as a PM as well, but people might learn from this. I am not talking about any specific mount points for LG phones, I just pointed out that there are some roms which use sed to check the filename of its update.zip and do tasks according to that, you need to have one line in your updater script to run the script which detects what to do. That way a user of a Galaxy Nexus would rename it to update-maguro.zip and it would know to use mount points for the maguro, while if the exact same update.zip was to be named update-p990.zip, it would know to use the mount points for the LG optimus 2x. This way you could easily keep the zip up to date for any device, because they all use the same update.zip
About the recovery, you would need to build it for every phone once, but you could make one change to the recovery source and easily compile the recovery for all phones which are capable of running CWM. I believe this method to be more user friendly, as a recovery image has support for actually choosing what you want to do, instead of having to rename the file. A recovery image also has a better way of communicating with the user. Where a update.zip can only say "Hey, I had an error and I'm quitting now, I won't give you any details what the problem was because that's just how update.zips roll", a recovery image would be able to give more advanced outputs, like "An error occurred when trying to mount /data." And then give you the option to either try again, manually fix it by using a computer with adb, or quitting.
But that's just my personal opinion. The recovery would be way harder to make, but I was the original porter of CM6, CM7 and HTC Sense to the xperia mini pro and mini back in the days. I also made a custom recovery and roms for the HTC desire Z, maintain a CWM port for the HTC Chacha which I don't even own and have used the LG optimus 2x before. (currently a maguro owner) but I'm trying to say that I've been experimenting a lot with different phones and know what the possibilities of Android are. you could even make a live Android build, tailored for recovering your phone, which is ran by an update.zip! How cool is that? That would be VERY device specific though..
let me know what you think is the best way to do this. I was thinking of making a mobile time machine app for some time so it's good I saw this thread.
!ALWAYS make a databackup.img on your device BEFORE making any changes!
Hi all!
For the past 3 weeks I have been making small changes to the build prop file inside the Android /system folder.
These changes incorporate not only a increase in speed but also stability.
What I would like to see happen is one of 2 things, or both if possible.
1. Incorporate this build.prop file into the various "System_Froyo" builds available, forcing these changes on initial install, or
2. Vogue/Polaris developers browse the file for contradicting information (things that won't work on a Vogue/Polaris) and make appropriate changes.
Improvements include:
ro.ril.disable.power.collapse (prevents sleep of death),
various dalvik vm improvements,
force hardware acceleration and performance tuning,
various telephony enhancements including ring delay time and data speeds.
After making these changes, the phone rings immediately, the UI is much smoother (GUI uses video processor primarily), and data jumped from 1.3Mb/sec to over 3.2Mb/sec, making web pages load faster. (EDIT: The 3.2Mb/sec is the top of the scale, I actually averaged 2.2Mb/sec with average pings between 300-500 across 3 different radio roms).
VOGUE/POLARIS OWNERS!
Please test this file and report findings here.
IF you find you need to remove any lines, please do so before copying the file into /system. This file works well on the AT&T networks (Cingular), but may not have much effect on other networks.
If you have trouble after installing this file, please post your bootlog file.
PoX
So may I know what rom support this?
This has only been tested on a "clean" Froyo build, so I cannot make any assumptions as to if it will work in Gingerbread/Eclair/Donut/etc.
If everyone follows the install guide on the front page, I would assume that it would work worldwide, as long as it's Froyo.
In the future I could try it out on Gingerbread and other builds, but I make no promises as development has all but ended for Android on MSM72**.
I can test this. Perhaps, kaiser on Android could be good for daily use?...
Thanks for sharing
PoXFreak said:
Hi all!
For the past 2 weeks I have been making small changes to the build prop file inside the Android /system folder.
These changes incorporate not only a increase in speed but also stability.
What I would like to see happen is one of 2 things, or both if possible.
1. Incorporate this build.prop file into the various "System_Froyo" builds available, forcing these changes on initial install, or
2. Vogue/Polaris developers browse the file for contradicting information (things that won't work on a Vogue/Polaris) and make appropriate changes.
Improvements include:
ro.ril.disable.power.collapse (prevents sleep of death),
various dalvik vm improvements,
force hardware acceleration and performance tuning,
various telephony enhancements including ring delay time and data speeds.
After making these changes, the phone rings immediately, the UI is much smoother (GUI uses video processor primarily), and data jumped from 1.3Mb/sec to over 3.2Mb/sec, making web pages load faster.
If there is interest in this, please respond to this post. If there is enough interest I will attach it to this post as a .tar file.
Click to expand...
Click to collapse
PoXFreak said:
This has only been tested on a "clean" Froyo build, so I cannot make any assumptions as to if it will work in Gingerbread/Eclair/Donut/etc.
If everyone follows the install guide on the front page, I would assume that it would work worldwide, as long as it's Froyo.
In the future I could try it out on Gingerbread and other builds, but I make no promises as development has all but ended for Android on MSM72k.
Click to expand...
Click to collapse
I'm interested in your new build.prop tar, but I do not understand the thing about the install guide, you mentioned in you second post.
My Kaiser is running CM7 RC3 on haret, so maybe I can do some testing on gingerbread, with you.
Your trials, about tweaking the app download possibility, sound very interesting too, as I read about a tweaked build.prop for a tab that simulates to be a samsung tab in combination with an older version of the app market.
Feel free to PM, although I'm quite a newby to android.
I can build with Fresh Froyo and try it, but not until April sorry.
I am currently traveling and away from a development system.
I have been slowly trying to get a reliable app2sd capability working.
I'd suggest searching old posts for power collapse to see if dzo or others long ago tried this.
It sounds promising.
muckelmaus said:
I'm interested in your new build.prop tar, but I do not understand the thing about the install guide, you mentioned in you second post.
My Kaiser is running CM7 RC3 on haret, so maybe I can do some testing on gingerbread, with you.
Your trials, about tweaking the app download possibility, sound very interesting too, as I read about a tweaked build.prop for a tab that simulates to be a samsung tab in combination with an older version of the app market.
Feel free to PM, although I'm quite a newby to android.
Click to expand...
Click to collapse
The "install guide" I'm referring to is here...
How to replace Windows Mobile with Android (Guide)
There would be a change to the original build.prop file which exists inside the /system folder and would be installed when Android is installed on the Kaiser.
Mind you, I live in a busy city with LOTS of cell towers and, since 3g works on the principle of multi-tower usage, YMMV. If you live way out in the country with maybe 2-3 towers nearby, this may not help you.
Also, this has been tested on a NAND-installed OS, not a HaRet install. I cannot verify or guarantee this will work with a HaReT install as I have no way to test it and I think of HaReT as the "slow cousin" to a NAND install.
On a side note: My Kaiser has not had one sleep of death, hard-lock, white screen or even an FC for 9 days now. Apps running out of memory can be a slight problem but they will just close on their own as opposed to FC-ing. at worst I've had one hot reboot called by the system, and the FCs' are few, even with heavy Facebook and Maps use.
n2, if this works on all Kaisers, is there a way to push it to SF and either add it as a mod or rebuild the "system_froyo" install files and incorporate it within?
I will try in early April. Until then please solicit Vogue and Polaris users to try it.
Sent from my Nexus One using XDA
I am interested and willing to try this out!
Where is your " "Fixed" build.prop file for Kaiser "?
Tarball added to OP, please test and report back. Any problems should be reported here along with the bootlog from your phone.
Hi guys!
Problem occured when moving file to root folder. To solve I tried root explorer and z4root both. CM7 + Krazy-Killa's Kernel on tilt 8925.
Please talk what to do with it!
thanks!
Rename original build.prop file to "build.prop.old" or something you will remember, without the quotes, then paste the new build.prop file into the /system folder... it should go right in with no errors, unless you try it without read/write abilities.
CM7 may already have some of these fixes installed in the existing build.prop file. To check, open this build.prop with a text editor and check the entries under "additional build properties".
n2rjt said:
I will try in early April. Until then please solicit Vogue and Polaris users to try it.
Sent from my Nexus One using XDA
Click to expand...
Click to collapse
Vogue/Polaris users solicited, although I'm not sure if this can be used on a CDMA network. Last count shows about 15-20% of the "other" phones were Vogues, the rest were Polaris users.
It would be nice to start getting good feedback since this would be my first actual "hard" mod (one that is installed with the system, not modded through some other installer/program).
PoXFreak said:
Rename original build.prop file to "build.prop.old" or something you will remember, without the quotes, then paste the new build.prop file into the /system folder... it should go right in with no errors, unless you try it without read/write abilities.
CM7 may already have some of these fixes installed in the existing build.prop file. To check, open this build.prop with a text editor and check the entries under "additional build properties".
Click to expand...
Click to collapse
Can't rename. And can't change file attributions read only to read/write.
ZLodei said:
Can't rename. And can't change file attributions read only to read/write.
Click to expand...
Click to collapse
You probably need to remount /system read/write. I just wish I could remember how. Been a long time since I put my vogue down.
If you can get terminal emulator up on that phone, I believe all you would have to do is type in "su" then "mount /system".
All Kaiser/Polaris/Vogue Android builds are rooted and usually have superuser installed. I will take a look into Scoot's CM7 and confirm this. I know there is an update to superuser that leaves the old binary unable to be updated.
PoXFreak said:
If you can get terminal emulator up on that phone, I believe all you would have to do is type in "su" then "mount /system".
All Kaiser/Polaris/Vogue Android builds are rooted and usually have superuser installed. I will take a look into Scoot's CM7 and confirm this. I know there is an update to superuser that leaves the old binary unable to be updated.
Click to expand...
Click to collapse
Hi! Thank you!
What does exactly I have to do in terminal emulator?
I would hope you have superuser capability, if you don't then use another build that does have them...
Anyway, this is all I could figure out to remount the /system as RW. Type the following below into terminal emulator...
mount -o rw,remount -t yaffs2 /dev/block/mtdblock2 /system
(Where "mtdblock2" has /system, "mtdblock3" has /data, and "mtdblock4" has /cache.)
Hope this helps...
Please correct me if i'm wrong.
I installed this new build.prop from the bootloader using androidupdate.tar.
Because i made a tar archive this way: system/build.prop
Isn't it the easiest method? No mounting and hacking in terminal emulator.
Anyway, do anybody know which ROM contains hungarian language? I gave my Kaiser to my father and it would be great if he could use it in hungarian.
I thought VaniljEclair 11 has it, and it is almost true. It has hungarian language but when i set it nothing happens. Everything is in english as before.
Thanks!
Edit:
You can download it from here:
http://mattempus.sohasenem.hu/pub/androidupdate.tar