Related
Just throwing an idea out there, and since it's for developers (specifically people who make their own recovery images) I assume this is the right section.
Since we have 'control' over the recovery image on our phones, would it not be possible to add a little script to an update.zip that a suitably modified recovery image could extract and run to interactively prompt the user for various Rom options? I'm thinking specifically of kernel choices, but it could be extended to almost anything that needs to be done prior to booting the installed image.
Imagine installing a rom, and during the install you got a little menu like this:
1: RamHack, BFS Kernel
2: RamHack, CFS Kernel
3: No-RamHack, BFS....
etc...
inefficient, it adds extra baggage to rom, and more things can go wrong. what would you rather downlaod a 90mb file or a 110 mb file.
Which would you rather download, one 110MB ROM or 2 90MB ROMS?
I'm pretty sure there's more than a few people who'll download different variations of the same ROM so they can see which is faster, how much easier would it be to just download one thing and then choose which options you want in there without downloading anything else.
I believe it is entirely possible. As a matter of fact, I was working on a ROM project that would have an interactive installer from the update.zip that would selectively install different features, apps, customization, themes, etc., based on the recovery menu application. It would use a lot of the /cache for temp space, though, as the installer application and its resources and configuration file, and later, the necessary parts of the ROM itself, would need to be unzipped before the install can run, if I recall correctly.
Does anyone have a good link to a reference for the command syntax for the /META-INF/com/google/android/update-script file? I'll go search for it in a few moments myself. I could probably make a simple ROM installer that chooses between ROM X and ROM Y based on a key input, as a proof of concept. I'll test it myself, I don't really mind half-bricking my device for science. (As long as I don't need to touch the SPL/Radio, that is.)
Update: Some creative searching finds me this:
JesusFreke said:
Assuming you mean update-script in an update.zip update, you will need to either look at existing update-script files for an example of the syntax, or look at the source of the recovery program in the android source
Click to expand...
Click to collapse
There's also a "make-update-script.c" file I'm seeing here and there, I'm trying to find the file in the Android source.
Update 2: From install.c at donut from cyanogen's android_bootable_recovery:
Code:
#define ASSUMED_UPDATE_SCRIPT_NAME "META-INF/com/google/android/update-script"
#define ASSUMED_UPDATE_BINARY_NAME "META-INF/com/google/android/update-binary"
and in commands.c, toward the bottom at register_update_commands is all the commands defined, and above that are all the functions they carry out.
sorry about that deicist i was sleepy when i wrote that so i must have been cranky yea i guess that is a fine idea, with just 30 more mb you have like 300mb worth of stuff. and you can pick which 90 mb you want.
markolo25 said:
sorry about that deicist i was sleepy when i wrote that so i must have been cranky yea i guess that is a fine idea, with just 30 more mb you have like 300mb worth of stuff. and you can pick which 90 mb you want.
Click to expand...
Click to collapse
Well, on the 32B platform with the Death SPL (my phone) we have the following partitions of the internal NAND memory (mtdblock*) from the df and mount command:
NAND 3: /system 92160kb - OS partition, static and read-only
NAND 5: /data 91904kb - User, system config, app config, and apps (without a2sd)
NAND 4: /cache 30720kb - OTA cache, Recovery/update config and temp
And I'd assume NAND 1 and 2 are the kernel, ramdisk, and bootloader config.
So the ROM wouldn't exceed 92MB installed (most leave some room in /system for hacks and updates). And the update process doesn't ever really "flash", per se; it just formats, copies files, and sets permissions and initialization configs, like Windows or Mac.
So the files that are common to the different ROMs being packaged don't need to be duplicated, only the ones that are changed (like a boot.img, or 32A/B compatibility, or different apps). The update script and chooser menu will decide which files to copy. Meaning the ROM package in and of itself shouldn't really need to exceed 128MB, even if choosing from a wide variety of platforms. And upon installation, the system might take less than 32 MB.
yeah, what he said ^
The scenario I was thinking about specifically was SuperD. If you look here:
http://forum.xda-developers.com/showthread.php?t=613809
There's 8 different downloads there. How many files are actually different between those 8? I guess the themes mean a lot of application files are different (due to having different resources in them) but the underlying framework files will be pretty much the same I think.
Deicist said:
yeah, what he said ^
The scenario I was thinking about specifically was SuperD. If you look here:
http://forum.xda-developers.com/showthread.php?t=613809
There's 8 different downloads there. How many files are actually different between those 8? I guess the themes mean a lot of application files are different (due to having different resources in them) but the underlying framework files will be pretty much the same I think.
Click to expand...
Click to collapse
I could download them all, and find the differences of each. It would be cool if a ROM like this were available in a single download, from which you would choose the content from the device before flashing.
Also, inspired by talking about this, I wrote up a guide on the update-script in the package file. It's still not finished, but it'll be the only guide available for that syntax yet (trust me, I couldn't find one myself ). Link's in my sig.
I'm surprised that nobody's mentioned the Droid... the sholes.info rom (now called droidmod) have used a .tgz archive instead of a .zip, the .tgz installs have always allowed this customization, droidmod makes one of the most common recovery's AND rom's. (SPRecovery/Droidmod).
It give you the option to choose what launcher to install, what theme, what apps to remove.
page here: http://droidmod.org/news/droidmod-v1-0-is-out/
how big of a ROM are you thinking about?
There are roms (WG etc...) that offer more than one kernel as update.zip you can flash over an existing installation of your rom instead of adding all the stuff to one big file. also you can download themes for several roms/for metamorph.
so why would you want some big install script instead of just downloading the files you like and flash it?
jmhalder said:
I'm surprised that nobody's mentioned the Droid... the sholes.info rom (now called droidmod) have used a .tgz archive instead of a .zip, the .tgz installs have always allowed this customization, droidmod makes one of the most common recovery's AND rom's. (SPRecovery/Droidmod).
It give you the option to choose what launcher to install, what theme, what apps to remove.
page here: http://droidmod.org/news/droidmod-v1-0-is-out/
Click to expand...
Click to collapse
Is the Droid's recovery image capable of running on the G1, and/or is it open-source enough to be cross-built to the G1? If so, we could port it here. Only problem there though, is that all the roms are in update.zip format for the G1 already, we'd need to make it dual-compatible if we don't want to split the community and annoy generally everyone ("My rom only supports TGZ recovery!" "ROMs are in ZIP format, and I will not make a TGZ one for those unfortunate enough to use the other Recovery!")
domenukk said:
There are roms (WG etc...) that offer more than one kernel as update.zip you can flash over an existing installation of your rom instead of adding all the stuff to one big file. also you can download themes for several roms/for metamorph.
so why would you want some big install script instead of just downloading the files you like and flash it?
Click to expand...
Click to collapse
Well, for one, devs need to host one file only, and users need to download one file only. The file won't be much bigger or more complex at all, really. And the way things look on the recovery side, we could probably put a selection of themes in with the updater and patch them in post-install with a Metamorph script straight from recovery. That way, the rom is as you want it out-of-the-box, no multiple reboots, etc.
Also, those scripts that usually run on first-boot, like zipalign, dexopt, apps2sd etc. should run from the recovery environment, instead of before the Android bootanimation (I do get tired of hearing "This ROM will take a LONG time on the first boot. If it's stuck at the G1 screen, just wait 10-30 minutes.")
So what would you rather have, one single ROM (G1_Android_ROM_v1.17.zip) for each version released,
or six different ZIPs to flash (G1_Android_ROM_10MB_CFS.zip, G1_Android_ROM_Greentheme.zip, G1_Android_ROM_Bluetheme.zip, G1_Android_Nowipe_GApps.zip)?
Would you rather select what you want to include at flash (and be able to change things like themes or features after flashing), or have 20 different files to choose from, wiping and flashing on each?
I am aware of the no-wipe upgrades for many ROMs, but they can get confusing (I once flashed a CFS_10MB.zip that was for a Hero ROM, stupidly thinking that it might have been for the Eclair that I just downloaded.) Needless to say, I had to wipe and reflash. Again.
TylTru said:
Is the Droid's recovery image capable of running on the G1, and/or is it open-source enough to be cross-built to the G1? If so, we could port it here. Only problem there though, is that all the roms are in update.zip format for the G1 already, we'd need to make it dual-compatible if we don't want to split the community and annoy generally everyone ("My rom only supports TGZ recovery!" "ROMs are in ZIP format, and I will not make a TGZ one for those unfortunate enough to use the other Recovery!")
Well, for one, devs need to host one file only, and users need to download one file only. The file won't be much bigger or more complex at all, really. And the way things look on the recovery side, we could probably put a selection of themes in with the updater and patch them in post-install with a Metamorph script straight from recovery. That way, the rom is as you want it out-of-the-box, no multiple reboots, etc.
Also, those scripts that usually run on first-boot, like zipalign, dexopt, apps2sd etc. should run from the recovery environment, instead of before the Android bootanimation (I do get tired of hearing "This ROM will take a LONG time on the first boot. If it's stuck at the G1 screen, just wait 10-30 minutes.")
So what would you rather have, one single ROM (G1_Android_ROM_v1.17.zip) for each version released,
or six different ZIPs to flash (G1_Android_ROM_10MB_CFS.zip, G1_Android_ROM_Greentheme.zip, G1_Android_ROM_Bluetheme.zip, G1_Android_Nowipe_GApps.zip)?
Would you rather select what you want to include at flash (and be able to change things like themes or features after flashing), or have 20 different files to choose from, wiping and flashing on each?
I am aware of the no-wipe upgrades for many ROMs, but they can get confusing (I once flashed a CFS_10MB.zip that was for a Hero ROM, stupidly thinking that it might have been for the Eclair that I just downloaded.) Needless to say, I had to wipe and reflash. Again.
Click to expand...
Click to collapse
You could just have flashed the original rom without wipe.
Would be a step forward if you could simply put roms and additional files in folders... maybe even whole zip files containing some updates and an xml like file to describe them. This would guarantee compatibility with earlier boot images (just unpack the updates in the zip). Tar might work better than zip as it is not compressed thus faster afaik.
http://droidninja.com/?p=26334
We got ninja'd. Apparently the Droid Does exactly this.
So let's get to work on porting it! Like this comment says, I'm working on finding the source code to a good Droid recovery image (sadly Droid hasn't its own forum here), and if it's closed source, I'll get on reverse-engineering a .tgz rom to see exactly how it works.
TylTru said:
http://droidninja.com/?p=26334
We got ninja'd. Apparently the Droid Does exactly this.
So let's get to work on porting it! Like this comment says, I'm working on finding the source code to a good Droid recovery image (sadly Droid hasn't its own forum here), and if it's closed source, I'll get on reverse-engineering a .tgz rom to see exactly how it works.
Click to expand...
Click to collapse
This is pretty awesome. I was going to say, we could easily run bash scripts but this is so much better.
This needs to be merged with both Amon_ra's recovery and the new 2.x based recovery...
Hi, I am a relative newbie to ROM flashing and the like. Additionally I dont have a very deep computer knowledge base. I have rooted my Samsung Captivate and have flashed a ROM (which flashed properly, but didn't quite work). I have three questions about ROM usage and such:
1. I know kernels basically add aspects to the ROM you are running, but when should you flash these? How do you flash them (same process as with ROMs? do you just do it over-top of the Rom you currently have loaded? etc...)
2. If a newer version of the ROM you have running comes out, do you have to start over and completely wipe the device over again and do the whole process from start, or can you load a newer version of your current ROM over the one you have?
3. I have been hearing/reading about some problems with the Android Market disappearing on certain ROMs when the market updates, how can i avoid this/fix this?
Thanks. Sorry the basic/stupid questions.
1. Yes
2. There are WIPE versions and NO WIPE version. Usually you can use the NO WIPE version and keep everything. But sometimes if the roms are too different you get problems and errors, then it is recommended to flash a WIPE version.
3. Hm did not experience this yet, but there are fixes somewhere .
Whats up... No question is a stupid one buddy.... (Sometimes )
To answer your first question about kernels. Flashing kernels aren't a must. You don't have to flash them really, unless there is a need. Kernels for the most part can often change the way Android handles stuff like memory management, battery resources and even multitasking. They change (tweak) the way the Android OS itself interacts with the phones hardware. That's all a kernel is really. So read up on them before flashing them because each has their advantages and disadvantages. For example, the kernel I use gives me a good RAM boost and much better battery life but it suffers on the multitasking side and I have to do other stuff to compensate for that. That's how it is. As far as flashing them is concerned. That depends. Usually, you just flash them through recovery (Like a ROM) but I would suggest you follow the instructions they give you (if it exists).
Your second question is simple. Just follow the instructions they give you for installation. Some ROMS require a full wipe and others don't. It just depends on the ROM. When in doubt, follow the instructions (again if it exists).
Your third question is a weird one, I've never heard about that really. BUT.... Some ROMS may or may not include the GAPPS applications (Google Apps).
If the ROM you flash doesn't have Google Apps built in, it would literally be missing. You would have to flash it separately. Usually in those cases though, at the download location for that ROM, they would also provide links for GAPPS zip files to flash separately so you can have the option to go with Android Market, Gmail and such OR you can use an alternative. Short of that..... never heard of that issue before..... If the issue is happening after the Market app updates, in that case it might be some type of ROM issue, you'll probably have to somehow get the updated Vending.apk (Android Market) remove/backup the original and reinstall it manually (the way you would a regular apk). I'm guessing though....
Don't you just love research........
Thanks. And now, inevitably, answers lead to more questions.
With regards to kernels, how do I know which one's do what, are compatible with which ROMs etc. I feel like its the kinda thing that needs a giant database for them, but i know there isn't.
Also, is the process for flashing other .zip files the same (though either Rom manager or a built in Recovery option). For example, a bootanimation.zip?
Ultimately I hate the idea of asking overly simply questions, but I just don't know what I dont know, nor what is supposedly implied. Thanks.
Don't sweat it...... I'm in the same boat so I have no hangups....
I think I know what you mean when it comes to kernels. Ultimately, learning about kernels requires a lot of reading in many forums (Just like this one)... Why?.... Because in many instances the persons posting the kernels might not always give you an exact breakdown on exactly what it does..... so I understand. Your best bet would be scanning XDA. I've found all sorts of really excellent kernels lying around and the devs here love documentation so there is a good chance you'll know what it does...
You could also try DroidBasement: http://droidbasement.com/db-blog/
They actually have just what you wanted, a database....kind of. They have a very large variety of kernels for different devices so its a good place to start as well.
They also tend to do a breakdown of what each kernel is capable of, the device it should be used on and so on.
About flashing zip files. Generally speaking, most zip files are flashed through recovery but its not written in stone. Following the instructions concerning said zip files are always very important. Always look for instructions before you do so at least at first. In the case of bootanimation.zip.... They are not always flashable. But if it is flashable, you can flash it through recovery which would be the best method....
If you want though, you can replace the original bootanimation.zip file with the new one manually, once you have root and some type of root explorer (for example RootExplorer for Android).
Generally, the boot animation directory is usually, /System/Media so you can check to see if its there and if it is, just backup the original and replace it with the new one.... That should work... Always nandroid before doing so though.... before doing anything really....
Thanks. I actually had a question about nandroid but forgot. Basically, what is it. I realize contextually that it's a backup program and apparently works through the recovery menus. I read a ROM flashing step-by-step that mentioned it but couldnt figure out where to get it (not in the market unlike Ti-bu which i use currently).
Nandroid is a backup program that basically creates a flash image of your phone... If you've ever heard of "Ghosting" or "Imaging" a Hard Drive, its exactly the same thing.
Its really as good as it gets as far as data backup is concerned. Its also a low level backup, so even file structures would be recorded.. In other words, you can completely screw up your phone (file partitions everything!!!!) but once you can boot to recovery, your phone can be restored. That's why its so important because its your safety net....
Its not something that you can install like an apk, so its not in the market.
You would have to flash a custom recovery. If you have one already, it should be located in one of the menus (It changes depending on the type (brand) of recovery).
If you don't see the option in your recovery then its probably not custom and you're going to have to do some digging on these forums and maybe a bit of googling for instructions on exactly how to do so. Because it could change from device to device.
Nandroid also allows you to backup your sd-ext partition as well, so if you switch cards, you can restore to another card.... Its really incredibly handy and I wouldn't suggest you do anything until you can create nandroid backups....
Now, I'm having an interesting problem I posted this same thing in general Captivate forums but maybe someone who is looking at this/answering me knows. here's what i posted there:
have a Captivate that I recently flashed Di11i's 7.1.1 to, before that I had flashed my first ROM which was Serendipity 6.2. Both times I have found that I don't get incoming calls. People calling me get 2-3 rings, and then a traditional "busy signal" sound. On my end, either the phone vibrates once but the screen doesnt change from whatever screen I'm on. Or, The screen goes black like its going to the incoming call screen, but the black screens only flashes and goes away, as does a force close message box that goes away quickly without me clicking it.
Everything else on my phone works as far as I can tell, I've been running my current ROM for about 5 days without issues other than this one. This same exact problem also happened when I flashed Serendipity 6.2 (which I only kept for like a day because of this problem)
Ok....I currently use a G1 and most of my experience has been on HTC Devices. I'm not sure of how to reply to this as I have never really modded Samsung devices before. So I'm not really familiar with software and hardware differences (Like Bootloader, Recoveries, Radios and such). But based on what you're describing.... It sounds like a ROM or maybe a radio issue. Maybe its an issue with the phone app itself. If the app is somehow buggy then thats exactly what would happen. When the phone rings the phone app would try to run but then force close....
I'm guessing here, but it could also be a radio issue because you're getting a busy tone as well which is not good. Maybe the ROM requires a specific Radio version BEFORE its flashed.... Check the source of the download and determine if it requires a specific Radio version.
In my experience though, if the correct radio version isn't used for a ROM that requires it, the phone just won't boot..... but then again, I don't know what would happen on a Samsung Captivate.... Not sure if I can help on this one because I don't have any info on that type of hardware. I don't own one you see.....
What about if you found out a new kernel isn't as good as the old kernel, how would you go on to take away the new kernel to replace it with the old kernel? Is it the same process or even harder?
vlen22 said:
What about if you found out a new kernel isn't as good as the old kernel, how would you go on to take away the new kernel to replace it with the old kernel? Is it the same process or even harder?
Click to expand...
Click to collapse
NOW THIS IS ANNOYING..
u have to flash ur rom again..
but fortunately u dont need to do and wiping data or partitioning sd card.. jus flash rom..
Its not something that you can install like an apk, so its not in the market.
zeemar007 said:
NOW THIS IS ANNOYING..
u have to flash ur rom again..
but fortunately u dont need to do and wiping data or partitioning sd card.. jus flash rom..
Click to expand...
Click to collapse
The rom kernel that I downloaded, or flashing clockwork recovery mod? Like adrenylyne's kernel for the thunderbolt.
EDIT: Never mind, I found out. I didn't mean any harm if MY POST was annoying.
If you have two kernels, in a flashable zip, you can just flash them over each other to exchange them (turn off any modification the kernel did befor though, like lagfix).
New question, I had an app (quick office) that came on my captivate. Now that I've flashed di11i's 7.1 I don't have it anymore. This is particularly peculiar because all the other native apps are still here:samsungs media player from example. How do I go about getting this missing app back on my phone. I have all the backup files on my computer so I should have the .apk (although I'm not entirely sure how to install those properly) thanks
Sent from my SAMSUNG-SGH-I897 using XDA App
DON'T FLASH ON CM9 YET, OP WILL BE UPDATED WHEN YOU CAN
Dalvik Optimizer Beta 0.1
Note: This WILL work with Team Win Recovery Project 2.x(TWRP Touch Recovery) and ClockWorkMod (CWM)
Disclaimer
This is for the Galaxy S 4G, or SGH-T959V, if you don't own this phone, don't use this.I am not responsible if you hard or soft brick (damage/make unusable) your phone in any way. I suggest that you know how to flash recovery zips like roms and such, and have a way to recover like a backup or have the original rom in case something doesn't work or interrupts your flash. I also am not responsible but I'll feel bad for you if you get a heart attack, seizure, or any medical illness because of this flash. e.g, If the phone is too fast for you. I don't care if you go crazy and spend all your time on this phone causing you to break up with your wife, husband, children, family, girlfriend, boyfriend, or fiance. I will laugh at you if you start to make out with your phone though .
What is this?
This is an optimizer that improves the performance of an MTD roms like CyanogenMod 7, or moKeeOS, or DianXinOS, or Shendu OS, or JoyOS, or MIUI, or any other Team Acid, Team Kick Ass or Team NoOb.LuLz MTD rom that may release in the future.
What does this do?
1. This Re-Odexes your system.
-An Odex file is basically a dalvik executable that the phone reads upon boot. Stock roms like those released from Google, or Samsung are Odexed (as far as I know). Custom roms are often De-odexed in order to make their roms customizeable from the developer's point of view. Note: This will not effect Theme-Chooser or any other built in theming app
2. It changes the Dalvik VM heap size to 128m.
-This is the maximum allowable memory for each Dalvik Virtual Machine heap. Basically, increasing the size prevents your phone from having to clear it so often which runs your battery(the default size is 42m I believe).
3. I don't know yet, this is just the beta, this may be the final release, but I'll probably add more.
Advantages
1. Boot time is decreased
2. Scrolling is faster, less lag
3. Better battery life
4. Faster phone(quadrant scores may actually be lower)
5. More /data space because dalvik doesn't have to use /data to copy the classes.dex files over for itself.
Disadvantages
1. If you were to dump your system partition and edit apk files, you'd have to reodex them for certain modifications. This is a lengthy and tedious process usually, unless you use a program, which still takes >25 minutes unless you have a computer with a boat load of ram. (Those are usually pretty expensive)
Credits
1. zman0900 from the epic4g forum- I ported his odexer
2. Team Acid - CM7
3. Team Kick Ass - Motivation for the whole community
4. Google - Android
5. Samsung - This phone
6. My dad - Buying me this phone.
does this fix the camera?
sklassy said:
does this fix the camera?
Click to expand...
Click to collapse
No.
Sent from my SGH-T959V using XDA
Airfluip can you please explain the benefits of odexing?
I have never understood it even after reading about it online.
Sent from my SGH-T959V using xda premium
Did you create this tool? If not you should put this in the general forum instead.
EDIT
For those of you who don't know about dex files
http://www.talkandroid.com/guides/misc/what-do-odex-and-deodex-mean-the-all-inclusive-explanation/
Yeah, but I based it of other scripts I had seen.
Sent from my SGH-T959V using xda premium
The main benefit in ODEXing for our phone, which has very limited /data partition, is that all system apps and the framework itself are already precompiled and ODEX files are left in /system. They don't take space in Dalvik cache in /data. In the end you can leave more of your apps in /data and not move them to SD so they load faster.
Also faster boot time,
Battery and speed is better too.
My findings are, dalvik doesn't have to crack open every app, also dex is dalvik executable. Odex is optimized hence the "o"
Sent from my SGH-T959V using xda premium
I have learned a lot of practical things, thank you!
Worked for me. Boot-up is noticeably faster. Thank you.
Will this work on the new MoKeeOS port? It looks like its CM7 based MTD ROM. Thanks.
It may if the build prop has ro.cm.device and it's galaxys4gmtd.
Sent from my SGH-T959V using xda premium
I wanted to add that I used this on Miui-revenge, worked fine.
Sent from my SGH-T959V using XDA
Basically if there is a rom with the basic cm7 structure, then it will work.
Sent from my SGH-T959V using xda premium
Go for it people, new release and TWRP support
airfluip1 said:
Dalvik Optimizer Beta 0.1
Note: This WILL work with Team Win Recovery Project 2.x(TWRP Touch Recovery) and ClockWorkMod (CWM)
Disclaimer
This is for the Galaxy S 4G, or SGH-T959V, if you don't own this phone, don't use this.I am not responsible if you hard or soft brick (damage/make unusable) your phone in any way. I suggest that you know how to flash recovery zips like roms and such, and have a way to recover like a backup or have the original rom in case something doesn't work or interrupts your flash. I also am not responsible but I'll feel bad for you if you get a heart attack, seizure, or any medical illness because of this flash. e.g, If the phone is too fast for you. I don't care if you go crazy and spend all your time on this phone causing you to break up with your wife, husband, children, family, girlfriend, boyfriend, or fiance. I will laugh at you if you start to make out with your phone though .
What is this?
This is an optimizer that improves the performance of an MTD roms like CyanogenMod 7, or moKeeOS, or DianXinOS, or Shendu OS, or JoyOS, or MIUI, or any other Team Acid, Team Kick Ass or Team NoOb.LuLz MTD rom that may release in the future.
What does this do?
1. This Re-Odexes your system.
-An Odex file is basically a dalvik executable that the phone reads upon boot. Stock roms like those released from Google, or Samsung are Odexed (as far as I know). Custom roms are often De-odexed in order to make their roms customizeable from the developer's point of view. Note: This will not effect Theme-Chooser or any other built in theming app
2. It changes the Dalvik VM heap size to 128m.
-This is the maximum allowable memory for each Dalvik Virtual Machine heap. Basically, increasing the size prevents your phone from having to clear it so often which runs your battery(the default size is 42m I believe).
3. I don't know yet, this is just the beta, this may be the final release, but I'll probably add more.
Advantages
1. Boot time is decreased
2. Scrolling is faster, less lag
3. Better battery life
4. Faster phone(quadrant scores may actually be lower)
5. More /data space because dalvik doesn't have to use /data to copy the classes.dex files over for itself.
Disadvantages
1. If you were to dump your system partition and edit apk files, you'd have to reodex them for certain modifications. This is a lengthy and tedious process usually, unless you use a program, which still takes >25 minutes unless you have a computer with a boat load of ram. (Those are usually pretty expensive)
Credits
1. zman0900 from the epic4g forum- I ported his odexer
2. Team Acid - CM7
3. Team Kick Ass - Motivation for the whole community
4. Google - Android
5. Samsung - This phone
6. My dad - Buying me this phone.
Click to expand...
Click to collapse
and install it on my phone I do not see the instructions..?
Wow did you really feel a need to quote the entire op?
+1 shortbus, and yes you install it. In the disclaimer I said assume that you know how to flash zip files.
Sent from my SGH-T959V using xda premium
Just a note... when I tried to flash both CM7r11twrp and this in the same boot, the phone never got to the lockscreen. When I flashed CM7r11twrp, booted to lockscreen, waited 10, rebooted to recovery, flashed this, booted to lockscreen, waited 10... worked great.
Might have just come up with some great way to break it or had a bad flash, but thought I'd note it in case other people tried the same and had issues. Thanks for the update to make it work easily with TWRP, btw.
Nice work on this! defiantly faster boot time. Now to give it a day or two to see if it noticeably improves battery performance.
The question has been asked several times. Recently a senior member asked a similar question and was told to read post two of a thread. That post did not answer the question but created more doubt. So Im going to steal some information from various posts to hopefully clarify this. Please if I get anything wrong let me know so I can correct it. But most of this will be stripped from various posts.
What is a partition?
A partition is an area of allocated space, a division of the whole overall area of space. In this case our partitions on the Epic 4G are /System, /Data, as well as /Cache. All with set permanent sizes.
What is a partition map?
A partition map is the configuration of our partitions, it's what in a vagueness sets our required sizes for the divisions of our nand also known as flash memory. A partition or partition map should not be confused with a file system. An example would be BML and MTD.
What is a file system?
A file system resides on the partition map and governs the data being read/wrote/moved/etc by the Operating System, in this case Android. Changing a file system is less complex than an overall change in partition mapping. They again, are not the same thing.
What is MTD?
MTD is an Open Source Partition map. It allows those who are using it control over how their partitions are sized and how much space is allocated here and how much space is taken away from there. Currently on MTD we have 689 megabytes of space allocated to our /data partition allowing more to be downloaded from the market as an example. MTD as a partition config has YAFFS2 as a file system residing on it governing how data is transferred and the speed of which it is done. EXT2 through 4 aren't possible on the MTD platform, just as YAFFS2 may not be possible on the BML proprietary platform.
What is BML?
BML like MTD is a partition map, however it is proprietary in nature, Close Source if you will. The size for /System /Data /Cache is set and permanent and makes opening up space more of a task for Developers. Stock the Epic 4G comes on BML, and is running RFS as it's file system, once rooted you can leave RFS for EXT4 (Journaled or Un-Journaled) as long as the kernel you use allows for EXT4. But in the end, changing a file system on BML does not lessen or enhance the control you have over your partitions.
What does it mean for me as an end user?
As an End User, MTD is an opening to a new life for the Galaxy S 4G. Things like ICS, more space in data or system, are more within our reach and grasp due to the nature of Open Source MTD is immersed in. We're closer to the Captivate, Fascinate, Vibrant, and Galaxy S international by being on MTD, we have that new freedom they've had for a long time. Not to say things like ICS aren't possible on BML but with this we're at a better standing point.
Click to expand...
Click to collapse
Basically, the internal storage on your phone is a flash device.
BML and FSR (aka XSR) acts as a software-based FTL (Flash Translation Layer).
This allows you to put filesystems like fat or ext4 on a flash device.
Hardware FTLs are everywhere. Look at your memory stick for instance. There is an FTL between the usb device controller and the nand flash chips that actually store the data. You can format your memory stick with ext4, btrfs, ntfs, whatever...
Samsung decided to go further down the rabbit hole with RFS, which is basically a modified version of FAT(32?) with ACLs and Journalling. IMO, silly.
BUT, fsr/rfs are proprietary modules and are built with a kernel that has a set of symbols exposed. If I disabled debugging (like I did) and something in one of those fsr/rfs modules depended on it, then the fsr/rfs modules wouldn't load (unless you trick it).
Moving to controlling the flash on the phone (in which the flash type on this phone isn't nand, but OneNAND-Flex) with MTD gets us away from the proprietary modules, but introduces a new problem. Can't use ext4 for /system, /data, and /cache anymore. Instead you have to use a flash filesystem, like yaffs2 (which is what the CM supported Samsung phones use). I would like to see a test on this phone with UBI/UBIFS though. I think that might have better performance then yaffs2 or jffs2 (but almost everything, including my grandma is faster then jffs2... seriously).
Click to expand...
Click to collapse
Mtd is the open source partition system used by aosp. Doing so allows more flexibility in porting roms and building from source. The proprietary stuff can be removed and get away from having to keep things like VVM for voicemail **.
This also moves us more towards vanilla android experience. Getting rid of proprietary file systems and and apps and various things to work properly.
Stolen from this thread and this post.
**note Antonx has found a way to remove the requirement for VVM. But is still working out if removing the code will break VVM for those people that use it.
I suggest we put BML to MTD and MTD to BML guides in the stickies. I know this info exists, but having it in the stickies will save many noob disasters and questions as this is getting more and more popular.
Sent from my SGH-T959V using xda premium
itzik2sh said:
I suggest we put BML to MTD and MTD to BML guides in the stickies. I know this info exists, but having it in the stickies will save many noob disasters and questions as this is getting more and more popular.
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
BML -> MTD will be a non-issue now since as of the latest commits I made to the CM7 update system (and whatever MTD roms base themselves off of that) we will be able to flash using only the rom.zip. You no longer need to fiddle with the efs backup/restore since the rom.zip will take care of it for you. The basic procedure will be
Reboot to RED cwm
Flash rom.zip
You will be rebooted to BLUE cwm
Flash rom.zip again
I just tested this myself from a completely stock KJ6 install and got onto a working CM7 install using a build I just made (with working IMEI/network/data) using those exact steps.
EDIT
Going back to BML will require a one-click for the time being until we can find a better solution, preferably one that involves CWM
One thing I didn't understand - why do we need a separated one click flash just for bootloaders? Can't it be done on the same time?
2nd, do we really need the bootloaders flash if we move from GB MTD to GB BML?
I assume I can odin just the kj1 kernel after the stock one click, just to get root. Do we have an odin version of AntonX's 1.1.0 kernel?
Sent from my SGH-T959V using xda premium
Well the bootloaders aren't a problem if the person is already on gingerbread. I had been messing with flashing bootloaders via CWM a while back but that just got my phone bricked. Until someone with unbrickablemod helps me test this or I get my own phone ubm'd, we'll have to do it this way.
No, you don't need to flash bootloaders all the time. The only times you need bootloaders are from GB -> Froyo or Froyo -> GB.
You should look into making your own custom one click, it's as easy as opening the .jar file in a program like 7-zip and extracting the files within, then you can recompress them. You can customize exactly what gets installed. I say you start with bhundven's kj6 one click and replace the kernel with your favorite custom one.
The files that get flashed from a one click are these:
one-click.jar/com/AdamOutler/HeimdallOneClick/resources/ROMPackage/HeimdallPackage.tar.gz
If you open that, you'll see all the files that get flashed, particularly zImage and zImage-1.
zImage gets flashed into the KERNEL partition
zImage-1 gets flashed into the RECOVERY partition
As it stands now, both zImage and zImage-1 should be identical since we don't have any recovery images and we have to use a kernel image instead.
Hello Galaxy S users,
Specifically, in this forum, it's Galaxy S 4G.
I know you've been watching T.V., and know (maybe... well here in E-merica) a little about universal health care... well I have something totally unrelated to talk with you about. [word this sentence with Steven Colbert's voice]
Universal Recovery.
As it stands, our bootloaders know nothing about the silly recovery partition on our devices.
And on stock roms, it is a total waste of good space we could put to any other partition (mostly data).
When this topic first reared it's ugly head, I thought to myself about just incorporating the unused space to data. But no! I have seen the light. And it is good!
There are a few different recoveries out there that are mostly a preference thing.
Stock Android Recovery (think the "3e" thing...) (totally friggin stock. No modifications)
ClockworkMod Recovery (cwm)
ClockworkMod Touch Recovery (cwm-touch)
TeamWin Recovery Project (twrp)
manual partition magic (that really only devs know about... [Bryan Jedi waves his hand in your face] forget I said anything here.)
... to name a few. Granted I will not support/help you on the first or last versions of recovery mentioned above.
I would like to use the recovery partition to unify the storage of the recoveries.
As we have seen with the radio partition... On stock, it is a bml partition without rfs. The modem.bin is written (redbend_ua) directly to the bml12 partition and read back by /system/bin/rild
On (Gingerbread(mtd)/CM7/ICS(mtd)/CM9) MTD based roms, the radio partition is a yaffs2 formated partition in which modem.bin's are simply copied to. A symlink (/dev/block/bml12) to allow rild to work correclty... (well and a nasty hack on SGS4G to pad the modem.bin with zeros, because the rild reads more then the size of the modem.bin but less then the size of bml12)
Lets say we format the recovery partition as yaffs2 (or either vfat or ext4 on bml roms), and store ramdisk-recovery-<version>-<fstype>-<recovery-type>.img files there.
Examples:
ramdisk-recovery-gb-bml-cwm.img
ramdisk-recovery-ics-mtd-twrp.img
Then create a cwm update.zip that allows you to switch your recovery based on what is in the /recovery partition.
The title of this post is [RFC]... This is a Request For Comments.
As an amendment to this RFC, I would also like to have universal updater.sh and updater-script files to be created so that one could say, flash:
stock bml gb (cwm) -> ics mtd (cwm-touch)
ics mtd (twrp) -> stock bml gb (twrp)
ics mtd (cwm) -> gb mtd (cwm-touch)
gb mtd (twrp) -> stock bml gb (cwm-touch)
gb mtd (cwm-touch) -> ics mtd (cwm)
...without ever needing to go to download mode to run a oneclick or odin.
This thread should eventually turn into a development thread containing the results of this discussion.
...
A little while back, I started a poll.
The results of the poll, and comments lead me to believe that users are more interested in obtaining root and having the latest version then anything else.
All of these recovery methods should provide root access to install which ever rom you want (rooted or not rooted) and whatever recovery you want to use.
Goals (no particular order):
Run an updater.zip OR run an android app to change the current version of recovery.
Unify the updater.sh and updater-scripts for our roms, so you guaranty that you can flash from any rom to any rom (unless it has not been updated to use this new standard)
Do something with the lost 6-7M of unused space currently known as 'recovery'.
Let me know what you think. I already have a WIP, but it only supports cwm (at the time of this writing. cwm-touch and twrp coming soon...).
I am working on minimal environments (android manifests) to build each specific recovery nightly so that these will always stay up to date with what is in our repositories.
Being an RFC thread, please provide some helpful feedback.
ALSO, I leave this open to other Galaxy S phones as well!
You too have a device with this stupid recovery partition.
If all Galaxy S phones used the same codebase for updater.sh and updater-scripts and for setting the currently used recovery, it would be a win for everyone.
OK, Technical section:
--------------------------------------------------------------------------------------
On the latests CM10, a patch was applied by pawitp a little while back to allow a simpler packing of ramdisk and recovery.
Because of this, you can basically repack the initramfs with a different recovery.
If we changed our stock bml gb kernel, cm7 (and other mtd based kernels) to use a similar recovery method, we could unify the way we change between recoveries.
--------------------------------------------------------------------------------------
...Comments go here VVVVVVVVVVV
As we were discussing on #teamacid, I think I can help with figuring out the mtd -> bml portion of this since most of my previous work has been with installer scripts and the recovery environment.
Bryan was telling me that it should just be a matter of flashing the bml zImage and to reboot and continue the install.
I definitely think that storing the recovery.img files in /recovery would be a great solution. It'll keep the kernel/boot.img files leaner and allow us to update the recovery without messing with the kernel.
FBis251 said:
As we were discussing on #teamacid, I think I can help with figuring out the mtd -> bml portion of this since most of my previous work has been with installer scripts and the recovery environment.
Bryan was telling me that it should just be a matter of flashing the bml zImage and to reboot and continue the install.
I definitely think that storing the recovery.img files in /recovery would be a great solution. It'll keep the kernel/boot.img files leaner and allow us to update the recovery without messing with the kernel.
Click to expand...
Click to collapse
Essentially, yes. There are two "universal"s here.
Universal recovery selection
Universal updater.sh and updater-script usage
And, yes, kind of... the reservoir may also be apart of the big problem here.
There is much experimentation and discovery to happen before anything really results from this thread.
I definitely support the movement. What can I do to speed up the process or help with this development?
Sent from my SGH-T959V using Tapatalk 2
I'm interested in the implications this could have to the S devices with a flash counter.
Sent from my SGH-T959V using xda premium
GreyDark said:
I'm interested in the implications this could have to the S devices with a flash counter.
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
I know that the sgs4g has a flash counter, but it never increments.
I think it was something they were thinking about, but never got working for the release.
VillaCastana321 said:
I definitely support the movement. What can I do to speed up the process or help with this development?
Sent from my SGH-T959V using Tapatalk 2
Click to expand...
Click to collapse
I just need to finish my WIP and let other devs at it so they can make changes to it.
The WIP is driven by what is in the OP of this thread. It is not written very well and not very detailed.
I hope that changes over time with feedback.
Having botched my share of kernel/recovery flashes, this would be very interesting if I could always access something that would let me flash a known-good kernel/recovery from microSD when I next mess up.
Admittedly, I could stop flashing unknown kernel/recovery when I'm not within reach of Heimdall, but...
So the SII can use triangle away for the flash counter while with the SIII it's still usable yet not recommended from what I saw. By using dd to get the recovery in, the SIII dodges the counter again, (first time by using Odin to get root) but there can always be people who might even do that wrong. I don't know about the other S devices, but if there was an easy way to get root and a custom recovery, definitely a plus for average users.
Sent from my SGH-T959V using xda premium
I think its a very good idea. It makes perfect sense, I don't see a downside and see its possible. It would be great actually
Sent from my SGH-T959V using xda app-developers app
This sounds awesome... would b willing to test.....
sent from my t959w running RemICS, Voodoo sound, Rom Toolbox pro.
Fun starts in a month or so.
Wait... For... it.
bhundven said:
Fun starts in a month or so.
Wait... For... it.
Click to expand...
Click to collapse
Patiently waiting... teeth clenched....staring at my screen,watching for that post up..... LOL
sent from my t959w running RemICS-UX, Voodoo sound, Rom Toolbox pro
abonides said:
Patiently waiting... teeth clenched....staring at my screen,watching for that post up..... LOL
sent from my t959w running RemICS-UX, Voodoo sound, Rom Toolbox pro
Click to expand...
Click to collapse
So you are told to wait about a month, and you are spazing after six days? Wow, really patient.
Cooptx said:
So you are told to wait about a month, and you are spazing after six days? Wow, really patient.
Click to expand...
Click to collapse
I think he was joking
pisherthefisher said:
I think he was joking
Click to expand...
Click to collapse
I hope so
SMH
Sent from [CONTET DELETED]
love the idea <3
Sorry,my sick twisted humour cannot b appreciated via text.
sent from my t959w running RemICS-UX, Voodoo sound