This is an idea spawned by nubecoder.
The Goal: To collapse full and lite rom versions into a single version, and utilize a configuration file on the sd card to tell the rom how to install itself, creating a standard and simplicity for end-users.
RDU
ROM DEVELOPERS UNITED
AS ONE
CWM ROM Lite/Full Toggle UtilitySupported ROMs:
- RandomROM ThunderHawk 3.3
- Legendary ROM RC 2.2
To Developers: Join me as the RDU, and together we can make rom flashing a more enjoyable experience.
To Users: If you support this idea, contact your favorite devs on their rom threads and let them know! This utility functions around a file created on your SD Card under the clockworkmod folder called 'options.cfg'. This same file is also now utilized in ThunderHawk 3.3 and II to choose whether to install standard or scroll-able toggles, as well as an advanced or a simple power menu.
So here's how it works:
I personally split my rom into a regular version and a slimmed down lite version. Unfortunately, I then have to make sure I regularly update both versions, and then test them both while keeping both on my phone. Since I'm currently maintaining 3 different roms, and 2 different versions of each, this gets to be a handful. So I've coded a mock version of the setup. I've now designed it, with thanks to hoffman, so that the rom or switcher will default to a Full configuration if no config file exists. The config file is safely tucked away under /sdcard/clockworkmod.
Using a single separate flash-able, I can toggle the config file between lite and full simply by flashing it whenever I want to change it. I can set it to lite, and install as many of my roms in a row in lite version without having to do a thing extra.
The Latest Version Here.
The Previous Version Here.
After setting the config file, simply run the rom, and after copying the config_check file into your tools folder and utilizing coding such as the following, it can determine how to install itself:
Code:
#MOVING TOOLS TO PHONE
package_extract_file("tools/config_check", "/tmp/config_check");
set_perm(0, 0, 0755, "/tmp/config_check");
#DETERMINE FULL OR LITE VERSION
run_program("/tmp/config_check","check");
ifelse(
# read the "lite.version" value from the file
file_getprop("/sdcard/clockworkmod/options.cfg", "lite.version") == "yes",
(
# if the value reads yes, enable lite version
ui_print("Lite Version Enabled...");
),
(
# if the value reads no, enable full version
ui_print("Full Version Enabled...");
package_extract_dir("fullpack/system", "/system");
package_extract_dir("fullpack/data", "/data");
package_extract_dir("fullpack/sdcard", "/sdcard");
)
);
UPDATE: (1/06) I have yet further redeveloped the scripting to enhance the capabilities. Previously, this script would read the options file and, assuming that the first line is the "lite.version" property, backup the rest of the file. After which, it would rewrite the file accordingly, and then restore the backed up file info. Should the lite property not be in the first line, the scripting will likely fail. As such, I have rewritten the code in a more elegant way to now properly adjust the options.cfg file without the need to rewrite it. Thus, enabling the file to more safely contain any number of more installation settings, such as Clean Install/Full Wipe.
UPDATE: (12/21) I just rewrote the script further so that it can preserve any additional settings one might want to add (i.e. scrollable/nonscrollable toggles, advanced power menu/simple power menu, etc.) as long as the full/lite setting remains listed first.
UPDATE: (12/15) Okay, so I've tucked the file under Clockworkmod where it should be safe, yet easily accessible. I've also recoded the .zip to us shell scripting to write the file rather than blunt force copying file back and forth over top of each other.
So the idea is that we might be able to standardize something like this across various roms.
I'm currently in talks with earthbound[iap] over a possible app kitchen configuration of sorts to bring this together. Using another cwm script, or android app, or windows app, or manual editing, etc. any number of customizations could be applied this way through this single file.
Further ideas or customizations from fellow rom developers welcome.
Post reserved for more... I don't know.
Awesome!
Sent from my epic that didn't have CIQ before it was cool
Thanks for all your work!
I use an automating script i threw together to merge my package versions allowing me to keep a base package, then separate incremental (the actual updates done to files), extras for the full version, and slim version (which is base+incremental), then zipalign apks/jars, zip, and sign the rom packages, as well as generate the link/filesize/md5 output that i can enter into my rom OP.
This is how i can put out my ROM so quickly day by day, i don't know how everyone else does the grunt work of package release, i noticed most roms are unsigned (or invalidly signed based on other roms), but CWM doesn't check by default anyway.
My original idea was exactly this - one monolithic file that automatically chooses which to install - especially when dealing with Rom Manager for choices, but then decided the file size hit wasn't worth it to some since the slim package is 50MB smaller a lot of people download it - especially direct to phone.
My thinking on the versioning for included extras has instead switched focus to WIPE/NO-WIPE configurations in order to avoid having to backup/restore the data as opposed to leaving the data in place if the FS is already where desired (i.e. on an ext4 ROM, check if rfs, if so, backup and format.) it's a smarter and faster way than just ALWAYS backing up/formatting/restoring. The trick was to make this work in updater-script, testing the fs, though still it would be great to have some sort of interactivity - what is shown here is about as close as we can get to an interactive install.
If anyone is interested i'll clean up the script and post it. It's basically a custom made simplistic ROM Kitchen. in fact, it's written in PHP (with shell_execs for necessary shell commands), which i run in php cli, but can obviously run on a server as a multi choice ROM Kitchen (i'm working on this one now for SleeperROM).
PHP is a fluency so it was quick to put together.
EDIT: i didn't mean to steal any thunder, but since you said you're developing a ROM Kitchen sort of thing with earthbound i felt it necessary to advise on my secret sauce
I have to say that it is always great seeing you guys work together. Good luck. It sounds like a great idea that is way over my head.
Sent from my Epicly Legendary Galaxy S Device or my Galaxy Tab rooted (feels naked without a ROM)
SenseiSimple said:
Thanks for all your work!
Click to expand...
Click to collapse
Any knowledge shared is worthwhile! While 50mb or so is a hit, its relatively inconsequential on 16gb of storage when the advantages are looked at. Faster testing for me and less uploads to manage! But more importantly, I've arranged my rom so that the full version add-ins can be quickly removed via 7zip by a picky user.
The fact of the matter is that I have less than 80 lite downloads as compared to more than 800 full version downloads just on last weeks edition. It seems nearly 90% of downloaders aren't concerned with SD storage usage. Its the phone storage they ought to keep their eyes on ;-).
Id certainly be interested in your kitchen of sorts.
-Sent from my Random Epic.
ERA would be down for sure. know we kind of gave up on making two versions because it takes a lot of testing and what not. I'll see if I can get a hold of Hoff or ksmullins. And we can work together.
Sent from my SPH-D700 using xda premium
stormglove said:
ERA would be down for sure. know we kind of gave up on making two versions because it takes a lot of testing and what not. I'll see if I can get a hold of Hoff or ksmullins. And we can work together.
Sent from my SPH-D700 using xda premium
Click to expand...
Click to collapse
No need... I'm a lurker. >.>
Seems like a great idea... I'll keep checking back on for progress updates. And if anyone needs a hand with anything, just shoot me a PM. I'm more than happy to help out.
I'm a web dev too.. Prefer front end, so if there's some things you need mashed out, gaive me a shout about tht as well. =)
hoffman1984 said:
Seems like a great idea... I'll keep checking back on for progress updates. And if anyone needs a hand with anything, just shoot me a PM. I'm more than happy to help out.
I'm a web dev too.. Prefer front end, so if there's some things you need mashed out, gaive me a shout about tht as well. =)
Click to expand...
Click to collapse
Right now it's a simple flash-able. Flash it once, it writes the config file for Lite version mode. Flash it again, and it writes the config file for Full version mode. And you can do it over and over again until you flash a rom, which then identifies the coding in the config file and acts accordingly.
So, one could feasibly break that rom .zip down into further "variations," although I personally will not be taking this route at the moment. earthbound[iap] is looking into creating a Windows or Android app that would enable you to choose any number of options and write them to that same config file. Then your rom of choice could read all of those options.
But for now, it's just Lite or Full. Speak up if you have any contributions, it would be nice to have this in common amongst multiple roms!
Maybe just change the name of the .zip? And check if its the lite or full, even though you'll still have the same .zip, it changes depending on filename
sent from my always aosp epic
ugothakd said:
Maybe just change the name of the .zip? And check if its the lite or full, even though you'll still have the same .zip, it changes depending on filename
sent from my always aosp epic
Click to expand...
Click to collapse
That could probably work, but would require a person to change the file name manually, on every rom and update they download. Or the dev can do it beforehand, upload identical, differently named roms. But then you still have to upload 2 versions.
My proposal is essentially an on/off switch accessible from CWM. And for a person who only installs lite versions, or only installs full versions, they would only have to do it once. Ever. No matter how many compatible roms they download.
And Earthbound proposes a whole range of customizations.
A standard for Development on the Epic... Indeed a good idea.
This is also how bigger projects (CyanogenMod\MIUI) start. =)
hoffman1984 said:
A standard for Development on the Epic... Indeed a good idea.
This is also how bigger projects (CyanogenMod\MIUI) start. =)
Click to expand...
Click to collapse
Alright, here is where I need help. The switcher feature works perfectly and it's beauty is in its simplicity. However, it's simplicity is the number one problem I can identify.
The switcher and the rom check the config file for a yes or a no. While that works, it fails if the file doesn't exist. Sure, a user can download the file and place it once manually, but that just doesn't sit well with me.
What I would like now, is for the rom and switcher to first look for the file, and if they can't find it, then they should create it with Full install as the default setting. After which, the switcher can once again perform it's duty.
Anyone know a good way to do this?
RandomKing said:
Alright, here is where I need help. The switcher feature works perfectly and it's beauty is in its simplicity. However, it's simplicity is the number one problem I can identify.
The switcher and the rom check the config file for a yes or a no. While that works, it fails if the file doesn't exist. Sure, a user can download the file and place it once manually, but that just doesn't sit well with me.
What I would like now, is for the rom and switcher to first look for the file, and if they can't find it, then they should create it with Full install as the default setting. After which, the switcher can once again perform it's duty.
Anyone know a good way to do this?
Click to expand...
Click to collapse
The only way i can think is maybe include the options.cfg and a script that does the checks for you. If the file doesn't exist, move it from /tmp/ to /sdcard/... Then onto your original script, which SHOULD find the now present options.cfg on the SD. Let me know if i mucked this up. =P
This has not been tested...
Code:
run_program("/sbin/mount","/sdcard");
package_extract_file("scripts/options.cfg", "/tmp/options.cfg");
package_extract_file("scripts/config_check", "/tmp/config_check");
run_program("/tmp/config_check");
config_check
Code:
#!/xbin/sh
#
cfg="options.cfg"
if [ ! -f /sdcard/$cfg ]
then
mv -f /tmp/$cfg /sdcard/$cfg
fi
Then on with your script...
SenseiSimple said:
Thanks for all your work!
I use an automating script i threw together to merge my package versions allowing me to keep a base package, then separate incremental (the actual updates done to files), extras for the full version, and slim version (which is base+incremental), then zipalign apks/jars, zip, and sign the rom packages, as well as generate the link/filesize/md5 output that i can enter into my rom OP.
This is how i can put out my ROM so quickly day by day, i don't know how everyone else does the grunt work of package release, i noticed most roms are unsigned (or invalidly signed based on other roms), but CWM doesn't check by default anyway.
My original idea was exactly this - one monolithic file that automatically chooses which to install - especially when dealing with Rom Manager for choices, but then decided the file size hit wasn't worth it to some since the slim package is 50MB smaller a lot of people download it - especially direct to phone.
My thinking on the versioning for included extras has instead switched focus to WIPE/NO-WIPE configurations in order to avoid having to backup/restore the data as opposed to leaving the data in place if the FS is already where desired (i.e. on an ext4 ROM, check if rfs, if so, backup and format.) it's a smarter and faster way than just ALWAYS backing up/formatting/restoring. The trick was to make this work in updater-script, testing the fs, though still it would be great to have some sort of interactivity - what is shown here is about as close as we can get to an interactive install.
If anyone is interested i'll clean up the script and post it. It's basically a custom made simplistic ROM Kitchen. in fact, it's written in PHP (with shell_execs for necessary shell commands), which i run in php cli, but can obviously run on a server as a multi choice ROM Kitchen (i'm working on this one now for SleeperROM).
PHP is a fluency so it was quick to put together.
EDIT: i didn't mean to steal any thunder, but since you said you're developing a ROM Kitchen sort of thing with earthbound i felt it necessary to advise on my secret sauce
Click to expand...
Click to collapse
This wipe no wipe is a GREAT idea... I'm going to see what i can cook up for Legendary. >.>
Now if only we could build a menu of selections for this into CWM...
-Sent from my Random Epic.
Also... Quick question for Sensei... Did your wipe or not wipe look something like this?
Code:
ui_print("Attempting to mount the Filesystem as EXT4...");
ifelse(
mount("ext4", "EMMC", "system", "/system") == "system",
(
ui_print("Filesystem mounted as EXT4...");
ui_print("Mounting the rest...");
mount("ext4", "EMMC", "data", "/data");
mount("ext4", "EMMC", "cache", "/cache");
),
(
ui_print("File System Not EXT4! Will now convert...");
ui_print("Backing up Data..");
run_program("/sbin/mount","/sdcard");
run_program("/sbin/mount", "/dev/block/stl10", "/data");
run_program("rm", "-r", "/data/dalvik-cache");
run_program("/tmp/data-backup");
ui_print("Formatting file system...");
run_program("/tmp/fsck.ext4", "-fy", "/dev/block/stl9");
run_program("/tmp/mkfs.ext4", "-O", "^ext_attr,^has_journal,^huge_file", "-L", "SYSTEM", "-b", "4096", "-m", "0", "-F", "/dev/block/stl9");
run_program("/tmp/fsck.ext4", "-fy", "/dev/block/stl10");
run_program("/tmp/mkfs.ext4", "-O", "^ext_attr,^has_journal,^huge_file", "-L", "DATA", "-b", "4096", "-m", "0", "-F", "/dev/block/stl10");
run_program("/tmp/fsck.ext4", "-fy", "/dev/block/stl11");
run_program("/tmp/mkfs.ext4", "-O", "^ext_attr,^has_journal,^huge_file", "-L", "CACHE", "-b", "4096", "-m", "0", "-F", "/dev/block/stl11");
)
);
There's obviously some room for error here, but I was going for the basic idea...
hoffman1984 said:
Also... Quick question for Sensei... Did your wipe or not wipe look something like this?
Code:
ui_print("Attempting to mount the Filesystem as EXT4...");
ifelse(
mount("ext4", "EMMC", "system", "/system") == "system",
(
ui_print("Filesystem mounted as EXT4...");
ui_print("Mounting the rest...");
mount("ext4", "EMMC", "data", "/data");
mount("ext4", "EMMC", "cache", "/cache");
),
(
ui_print("File System Not EXT4! Will now convert...");
ui_print("Backing up Data..");
run_program("/sbin/mount","/sdcard");
run_program("/sbin/mount", "/dev/block/stl10", "/data");
run_program("rm", "-r", "/data/dalvik-cache");
run_program("/tmp/data-backup");
ui_print("Formatting file system...");
run_program("/tmp/fsck.ext4", "-fy", "/dev/block/stl9");
run_program("/tmp/mkfs.ext4", "-O", "^ext_attr,^has_journal,^huge_file", "-L", "SYSTEM", "-b", "4096", "-m", "0", "-F", "/dev/block/stl9");
run_program("/tmp/fsck.ext4", "-fy", "/dev/block/stl10");
run_program("/tmp/mkfs.ext4", "-O", "^ext_attr,^has_journal,^huge_file", "-L", "DATA", "-b", "4096", "-m", "0", "-F", "/dev/block/stl10");
run_program("/tmp/fsck.ext4", "-fy", "/dev/block/stl11");
run_program("/tmp/mkfs.ext4", "-O", "^ext_attr,^has_journal,^huge_file", "-L", "CACHE", "-b", "4096", "-m", "0", "-F", "/dev/block/stl11");
)
);
There's obviously some room for error here, but I was going for the basic idea...
Click to expand...
Click to collapse
mine is much simpler but essentially, yes.
Code:
unmount("/data");
run_program("/tmp/busybox", "mount", "-t", "noext4", "/dev/block/stl10", "/data");
ifelse(is_mounted("/data"),(
ui_print("Backing up data, formatting.")
run_program("/tmp/tar-backup","backup");
unmount("/data");
run_program("/tmp/fsck.ext4", "-fy", "/dev/block/stl10");
run_program("/tmp/mkfs.ext4", "-O", "^ext_attr,^has_journal,^huge_file", "-L", "DATA", "-b", "4096", "-m", "0", "-F", "/dev/block/stl10");
),ui_print("Leaving data intact."));
basically unmount > mount anything BUT ext4 > check if mounted (if it did mount, it's rfs or whatever) then backup/format
that only selects how to NOT wipe/ preserve data... leaving the ext4 data intact like that has a weird effect on the first boot of showing the AOSP android logo animation contained in framework-res, but it shows the regular /system/media/bootanimation thereafter... i haven't noticed any ill side effects that weren't a result of my own error while replacing existing data files with new ones in the rom package. so i'd like to provide the option of WIPE BEFORE INSTALL for those who want clean install (right now i just provide a flashable that does the formatting for a clean slate (no 3x wipe/factory reset necessary)
Is_mounted. Interesting... Didn't know that syntax exsisted... I apparently have more homework to do, and maybe ill just stick the to the code I have (as its just a bit different) than the competition.
Anywho, thanks for the point in another direction... I'll definitely be implementing VERY soon...
Sent from my PG86100 using XDA App
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...
Hey Everyone,
I was just wondering that if we have a build to which we have BOTH RamHack kernels and the non-ramhack kernel, would there be a way to write a quick app or script to switch between them.
I guess we could store both kernels on the /sdcard and use a .sh script to flash_image between them, and reboot. I dont believe we can "hot-swap" between kernels, but if anyone knows a method, please respond here
If anyone can think of a better or more efficient method of doing this, I believe the whole community would benefit. Lets see if we can get something like this going....
zimphishmonger said:
Hey Everyone,
I was just wondering that if we have a build to which we have BOTH RamHack kernels and the non-ramhack kernel, would there be a way to write a quick app or script to switch between them.
I guess we could store both kernels on the /sdcard and use a .sh script to flash_image between them, and reboot. I dont believe we can "hot-swap" between kernels, but if anyone knows a method, please respond here
If anyone can think of a better or more efficient method of doing this, I believe the whole community would benefit. Lets see if we can get something like this going....
Click to expand...
Click to collapse
is it really that hard to boot into recovery and flash an update.zip?
I guess this is what you're looking for:
http://wootroot.com/blog/?page_id=1463
Ive seen it implemented on one other rom on xda, but can't remember which one ..
I am trying to make it easier and more efficient to switch between them. The uneek switch seems exactly what im looking for
I put together a version of uneeks script that can be flashed over SuperD or FastTest3.1.
ISSUE THOUGH, I cant get it to flash correctly, as I get the "update-script not found" error, even though I signed it and created the appropriate META-INF directories.
Here is the file, if anyone thinks they can fix it
Uneek Script (needs to be fixed\signed) : http://www.4shared.com/file/257220832/8b6c2940/uneek.html
Alpha release
Here is a very alpha release of a working port of uneek's RamHack/NonRamHack Toggle script ported to SuperD 1.10.2 by myself.
http://www.4shared.com/file/257253893/a61182a2/Uneek_Script.html
Instructions
extract zip file to /sdcard/uneek
Launch terminal
type 'su'
type 'sh /sdcard/uneek/install-uneek.sh' -should see no errors/messages
execute 'uneek' from /system/bin
Chose Ram option or JIT (not tested) options, all others prob dont work as I didnt modify them
reboot (you must do so to see effects take place, the kernel doesn't "hot-swap" :-( )
WiFi still works, CC & Swap work.
Issues
Switch breaks boot screen - not sure why as its stored in framework-res.apk, but still a bug
Leave me feedback\ improvements\whatever......
You still have to boot into recovery so you might as well flash a zip containing a rhack or noram-hack kernel.
I did some scripts based off Kings,
get gscript from the market ( donate if you like it )
and drop script into the gscript folder
with a little uname query you could have just one script, which switches based on the current running kernel
Edit: , actually if your kernel needs different kernel modules, then you will have to build in a copy ( which I suspect is where king got his rwsystem bit from , he copied from a script which updates the kernel modules )
Firerat said:
...<snip>...
my faster, much safer script
Code:
#!/system/bin/sh
if [ -e /data/kernels/full3d.img ];
then
if [ "`md5sum /data/kernels/full3d.img|cut -d " " -f1`" != "061284119d4ce46cbe0b585e0a8b2d0b" ];
then
echo "/data/kernels/full3d.img isn't the version I was expecting"
echo "I'm not going to flash it, as it may have become corupt"
exit 1
else
flash_image boot /data/kernels/full3d.img
echo "full3d Kernel Flashed..."
echo "Rebooting now"
sleep 1
shutdown -r now
fi
else
echo "Sorry, /data/kernels/full3d.img"
echo "seems to be missing....."
exit 1
fi
and yeah, I could never spell corrupt , is it one or two 'r's?
PS , the md5sums in the scripts are for the power off fix boot.img's I did for you guys
if you are wanting to switch to different boot.imgs then update the md5sum its checking for ( or remove the check )
Click to expand...
Click to collapse
If you have an engineering SPL installed, there isn't any need for the recovery partition, so might as well install your second kernel to the recovery partition. Boot normal = normal, boot recovery = ramhack.
lbcoder said:
If you have an engineering SPL installed, there isn't any need for the recovery partition, so might as well install your second kernel to the recovery partition. Boot normal = normal, boot recovery = ramhack.
Click to expand...
Click to collapse
and then have a script switch wlan.ko if incompatible
might as well switch with script and keep recovery for the odd times when you just want to quickly flash some zips from a list and not at your pc.
yeap, I've downloaded and flashed a rom while 'out and about' before.
Firerat said:
and then have a script switch wlan.ko if incompatible
might as well switch with script and keep recovery for the odd times when you just want to quickly flash some zips from a list and not at your pc.
yeap, I've downloaded and flashed a rom while 'out and about' before.
Click to expand...
Click to collapse
If the only difference is ramhack on one but not the other, then the wlan module will be fine -- there is NO REASON to be switching modules around with your kernel unless you use a kernel that is binary incompatible -- which means DIFFERENT VERSION.
lbcoder said:
If the only difference is ramhack on one but not the other, then the wlan module will be fine -- there is NO REASON to be switching modules around with your kernel unless you use a kernel that is binary incompatible -- which means DIFFERENT VERSION.
Click to expand...
Click to collapse
yeap, true but why not keep options open?
What if they decide they want to switch between binary incompatible kernels?
They would need to switch kernel modules anyway.
so get a script that works, and is simple to 'generate'.
I know you are trying to keep it simple, but you are actually needlessly setting up restrictions, which would then require a script to get around.
So why not use a script from the start, keeping the added convenience of a recovery image?
Firerat said:
yeap, true but why not keep options open?
What if they decide they want to switch between binary incompatible kernels?
They would need to switch kernel modules anyway.
so get a script that works, and is simple to 'generate'.
I know you are trying to keep it simple, but you are actually needlessly setting up restrictions, which would then require a script to get around.
So why not use a script from the start, keeping the added convenience of a recovery image?
Click to expand...
Click to collapse
If the only objective is to be able to easily toggle between ramhack and noramhack, then the recovery solution is (1) more reliable, (2) doesn't require reflashing NAND, (3) just easier to activate. With the reflashing approach, you have to either go into recovery and flash something, or pause-and-wait-and-autoreboot.
lbcoder said:
If the only objective is to be able to easily toggle between ramhack and noramhack, then the recovery solution is (1) more reliable, (2) doesn't require reflashing NAND, (3) just easier to activate. With the reflashing approach, you have to either go into recovery and flash something, or pause-and-wait-and-autoreboot.
Click to expand...
Click to collapse
did you ever read anything?
the script is as easy as a couple of taps, maybe home button, swipe tap tap.
( the key app here is gscript )
the flash is over very quickly, it checks md5sum first, it reboots.
you have to reboot with the recovery method anyway
recovery method restricts to binary compatible kernels, or require a script to switch kernel modules.
It is a no brainer imo, keep it flexible and keep the convenience of a true recovery.img
ok, so nand only gets what, on average 10,000 writes, is it really going to reduce its life in practice?
I like your idea, it will work but it just isn't as flexible as a script.
It is however more suited to an mt3g, offering duel ROM
I'm thinking mtdblock3 for one ROM, block4 for the other
errm, data , yeah might need to section that up somehow
any reason why a loopback can't sit on yaffs?
oh, and the ramdisk will need tweaking, obviously.
Sorry back on topic
Guys,
Either will work, if you do have incompatible kernels, and are having problems with scripts just let me know, I can probably make a script to generate a script for you.
1) Booting into recovery to change out your kernel image is totally unnecessary. You can do it via CLI with the flash_image command -- most every modded ROM already includes it.
2) Removing the recovery image just to put up a second install also seems somewhat overkill for devices as heavily limited on storage as most Android phones -- especially the G1.
3) I don't know about loopback on yaffs2 -- but I don't see any reason why it couldn't work.
4) It really seems to me that what we need is some kernel hacker who's familiar with hotswapping patched files -- a la ksplice ( http://www.ksplice.com/ ) -- to hack together a genuine, non-rebooting, RAMhack switch.
5) In all seriousness; what makes gscript superior to ASE ( http://code.google.com/p/android-scripting )?
IConrad01 said:
5) In all seriousness; what makes gscript superior to ASE ( http://code.google.com/android-scripting )?
Click to expand...
Click to collapse
Nothing, apart from its easy, it works and I haven't looked at ase yet
btw , you missed a p/ in that link
http://code.google.com/p/android-scripting/
btw , you missed a p/ in that link
http://code.google.com/p/android-scripting/
Click to expand...
Click to collapse
>_<
Pesky perniciously persistently phantasmagoric P!!!
I just keep on seeing people referring to gScript when ASE is a vastly more robust offering. It can run its scripts as daemons, run in background, run in terminal, it offers the same desktop shortcut option -- and more importantly, it can run Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl, and shell scripts. (It loads the interpreters onto your /sdcard.) I've asked this question more than once before and I've never gotten an answer. It really seems like people just aren't aware of ASE -- which is kinda sad, considering the fact that ASE is still seeing continuing development whereas development ended on gScript sometime at the end of last year.
IConrad01 said:
>_<
Pesky perniciously persistently phantasmagoric P!!!
I just keep on seeing people referring to gScript when ASE is a vastly more robust offering. It can run its scripts as daemons, run in background, run in terminal, it offers the same desktop shortcut option -- and more importantly, it can run Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl, and shell scripts. (It loads the interpreters onto your /sdcard.)
Click to expand...
Click to collapse
no, I am very interested in it,
I have been meaning to have a proper look at it for sometime
, I think I first saw it on @google
gscript is just handy,
unzip this, gscript from market,add, load, tick su, save , tap
But I promise , I will look at ASE
Firerat said:
and then have a script switch wlan.ko if incompatible
might as well switch with script and keep recovery for the odd times when you just want to quickly flash some zips from a list and not at your pc.
yeap, I've downloaded and flashed a rom while 'out and about' before.
Click to expand...
Click to collapse
Glad this is getting your attention....My script was pretty dirty anyways.
Anyway you can package it up in signed-zip format for easy access and modification of boot.imgs. Im having some issues with the update-script portion during the signing process tos keeping me from getting mine to be "flashable"
zimphishmonger said:
Glad this is getting your attention....My script was pretty dirty anyways.
Anyway you can package it up in signed-zip format for easy access and modification of boot.imgs. Im having some issues with the update-script portion during the signing process tos keeping me from getting mine to be "flashable"
Click to expand...
Click to collapse
still having update-script issues?
if you post it, I'll be happy to take a look for you
Oh, I've started a kernel switch script
I'll do some testing when its done and post it here for you
Hey,
I'm about to go to Superlite 5.0. I have only flashed once before on my Rogers 727R to SmoothIce that was GB based.
On the Superlite instructions it says nothing about flashing the modem, but other posts I have read say that you need an ICS modem...?
Can someone give me a hand with Steps?
Do i need to add anything to the instructions here:
.:: install guide ::..
Download superlite-5.0.zip
Reboot to Recovery
Wipe Data/Factory Reset
Under Advanced "Wipe Dalvic Cache"
Under "Mounts and Storage" Select "Format /System"
Install superlite-5.0.zip from sdcard or internal sdcard
Rom is full wipe
Thanks for helping a noob
Just follow the directions he gives. He designed the rom. He knows how it should be installed. But read all the info in that thread first so you will know what to expect.
Just wanted to share also that I've flashed nearly all of the ICS roms now and given each a few days to see how they all run, and this Superlite really seems to be the most bug free for me. Sometimes it seems like even following install directions to the letter will still give different results for different people. Maybe there are so many little factors that can effect the outcome that it can have varied results but this ROM is really not giving me any issue with lag or freeze ups that a couple of the others did right off the bat.
Sent from my SAMSUNG-SGH-I727 using xda premium
That's because MHX created a script that does a superwipe, flash modem, kernel, rom with one zip install package. Here's his change log: http://forum.xda-developers.com/showpost.php?p=24544803&postcount=883
Yeap he does a good job of cleaning the slate before install beings. This is what he does before it installs.
Code:
ui_print("SUPERLITE: formating /system");
mount("ext4", "EMMC", "/dev/block/mmcblk0p24", "/system");
delete_recursive("/system");
ui_print("SUPERLITE: formating /data");
mount("ext4", "EMMC", "/dev/block/mmcblk0p25", "/data");
delete_recursive("/data");
ui_print("SUPERLITE: formating /cache");
mount("ext4", "EMMC", "/dev/block/mmcblk0p26", "/cache");
delete_recursive("/cache");
mount("vfat", "EMMC", "/dev/block/mmcblk0p28", "/emmc");
delete_recursive("/sdcard/.android_secure");
delete_recursive("/sdcard/Android");
delete_recursive("/emmc/.android_secure");
delete_recursive("/emmc/Android");
unmount("/emmc");
ui_print("SUPERLITE: starting install");
Just wanted to say thanks. I would recommend that folks use Darkside Superwipe before flashing the ROM. It didn't work for me until I did.
The ROM looks great and runs smooth as butter. I am still having issues with the hotspot (seems to be a common issue) and the battery life isn't great.
But otherwise slick.
treadlightly said:
Just wanted to say thanks. I would recommend that folks use Darkside Superwipe before flashing the ROM. It didn't work for me until I did.
The ROM looks great and runs smooth as butter. I am still having issues with the hotspot (seems to be a common issue) and the battery life isn't great.
But otherwise slick.
Click to expand...
Click to collapse
+1 for darkside wipe...........especially on ICS ROMs
Just have to say..
Battery life is not great for me. Running an exchange account I am getting about 10 - 12 hours to a charge.
On my GB system I was getting about 28 or 29 hours.
Feels like something is sucking up the battery. When I look at the battery usage it is blaming everything on the screen. But I haven't been staring longlingly at it or anything.
Ideas?
try using betterbatterystats. sounds like u have wakelock issues because of a rouge app
I downloaded bbs. Looked at the Partial Wavelocks. the two biggest users are AudioOut_1 @ 17% and show Keyguard at 14.8%
I realised this morning that I wasn't getting LTE. So I did the *#2263# fix.
Do you think that was causing battery drainage?
if u have poor lte reception, for sure. I suggest using the ics_rogers_base radio by leec, it will greatly helpbur reception and speed
treadlightly said:
Hey,
I'm about to go to Superlite 5.0. I have only flashed once before on my Rogers 727R to SmoothIce that was GB based.
On the Superlite instructions it says nothing about flashing the modem, but other posts I have read say that you need an ICS modem...?
Can someone give me a hand with Steps?
Do i need to add anything to the instructions here:
.:: install guide ::..
Download superlite-5.0.zip
Reboot to Recovery
Wipe Data/Factory Reset
Under Advanced "Wipe Dalvic Cache"
Under "Mounts and Storage" Select "Format /System"
Install superlite-5.0.zip from sdcard or internal sdcard
Rom is full wipe
Thanks for helping a noob
Click to expand...
Click to collapse
yes you need to flash a modem. the GB roms use UCLA3, ICS seems to use UCLA4. Some people have had the note modem UCLA5 work for them (I had no such luck, resulted in a non-responsive ROM).
Coming from NexusMOD GB, this is what i did. i was running on CWM touch 5.8
Reboot into recovery
flash the UCLA4 modem
wipe data x2
wipe cahce x2
wipe dalvik x2
format system, data, cache x2
flash super wipe x2 just to be safe
flash superlite, it'll auto reboot
when it does, let it sit and dont touch it for a few minutes to let it settle.
this should work for you. afterwards, if you want, you can make a backup and try flashing UCLA5. some of the people in the thread had it succeed and they're getting better battery out of it.
edit: grab 5.1. it includes 3 patches including the AOSP browser and MMS. much better.
also, run supercharger v6 -> nitrolag nullifier and 1000HP settings. is awesome.
then go to your build.prop and add the tweaks from the thread in the general section
projectvirtue said:
yes you need to flash a modem. the GB roms use UCLA3, ICS seems to use UCLA4. Some people have had the note modem UCLA5 work for them (I had no such luck, resulted in a non-responsive ROM).
Coming from NexusMOD GB, this is what i did. i was running on CWM touch 5.8
Reboot into recovery
flash the UCLA4 modem
wipe data x2
wipe cahce x2
wipe dalvik x2
format system, data, cache x2
flash super wipe x2 just to be safe
flash superlite, it'll auto reboot
when it does, let it sit and dont touch it for a few minutes to let it settle.
this should work for you. afterwards, if you want, you can make a backup and try flashing UCLA5. some of the people in the thread had it succeed and they're getting better battery out of it.
edit: grab 5.1. it includes 3 patches including the AOSP browser and MMS. much better.
also, run supercharger v6 -> nitrolag nullifier and 1000HP settings. is awesome.
then go to your build.prop and add the tweaks from the thread in the general section
Click to expand...
Click to collapse
Or run team perfection rom, which has all that stuff buily in. MHX's rom are more for people who like touchwiz, and/or those who want an entirel stripped down base
Wicked - I was thinking about giving the Sky Ice Rom a try but I will also look at the Team Perfection. I'm going to give all this a try this evening.
Thanks for all the help. Really appreciate it.
Results?
treadlightly said:
Wicked - I was thinking about giving the Sky Ice Rom a try but I will also look at the Team Perfection. I'm going to give all this a try this evening.
Thanks for all the help. Really appreciate it.
Click to expand...
Click to collapse
Just curious what your results were? I am looking to hop into the ICS game too, as I just bought the skyrocket and am still on stock GB.
Thanks!
Treadlightly, I'm looking at installing either Superlite or Sky ICS this weekend.
I'm also on Rogers, still using gingerbread. I'm a bit nervous about this as some people who were early adopters on the leaked ICS were having trouble with Rogers phones.
I'm not seeing it now, but I'm still nervous. I'd sure appreciate a report after you flash Superlite.
Harry
---------- Post added at 05:35 PM ---------- Previous post was at 05:30 PM ----------
By the way Treadlightly, don't forget to install CWM, you will need that, but once you do, make sure you do a backup using the backup menus that are a part of CWM. It will copy to the SD card or external SD. Copy the backup file to your hard drive before starting the install of ICS.
That's called a Nandroid backup. So if things get screwed up, you can always recover with that backup. Also you may want to use Titanium backup to backup all your user data, so that it can be re-installed, using Titanium Backup, once you've done the upgrade to ICS. Again, you will want to make sure the data is backed up either to your External SD, or even safer, on your hard drive.
Don't back up and restore system programs and files, just third party stuff, contacts, calendar etc.
Background..
With any linux system i build first thing i do is remove the journal from all my EXT4 partitions, to make a long story short ( i wont bore you with details of just how journal writes totally slow disk i/o , google it ) this gave me on average a 25% increase in system speed ( obviously due to the increased i/o rate )
I usually did it with
Code:
mke2fs.ext4 -O ^has_journal ...device...
before installing the distro, now i thought hey maybe this would work on android?
Now mke2fs is not well supported on arm but tune2fs is! in fact its included in TWRP 2.5 so
Code:
tune2fs -O ^has_journal /dev/block/platform/sdhci-tegra.3/by-name/APP
( for the system partition) should work right , and in fact yes it does !!!, tried it from TWRP command line and hey presto %^$%^$^%$ FAST system
This is the code for a recovery script version
Code:
ui_print("test script");
ui_print("");
ui_print("");
ifelse(is_mounted("/system") == "/system", unmount("/system"));
ifelse(is_mounted("/cache") == "/cache", unmount("/cache"));
ifelse(is_mounted("/data") == "/data", unmount("/data"));
ui_print("converting partitions to ext4 minus journal");
ui_print(" ");
set_progress(1.000000);
ui_print("e2fsck system partition");
ui_print(" ");
run_program("/sbin/e2fsck", "-p", "/dev/block/platform/sdhci-tegra.3/by-name/APP");
ui_print("e2fsck data partition");
ui_print(" ");
run_program("/sbin/e2fsck", "-p", "/dev/block/platform/sdhci-tegra.3/by-name/UDA");
ui_print("e2fsck cache partition");
ui_print(" ");
run_program("/sbin/e2fsck", "-p", "/dev/block/platform/sdhci-tegra.3/by-name/CAC");
ui_print("now lets rub out those nasty journals");
ui_print(" ");
run_program("/sbin/tune2fs", "-O", "^has_journal", "/dev/block/platform/sdhci-tegra.3/by-name/APP");
run_program("/sbin/tune2fs", "-O", "^has_journal", "/dev/block/platform/sdhci-tegra.3/by-name/UDA");
run_program("/sbin/tune2fs", "-O", "^has_journal", "/dev/block/platform/sdhci-tegra.3/by-name/CAC");
ui_print("and re-fsck to clean any set bits");
ui_print(" ");
ui_print("e2fsck system partition");
ui_print(" ");
run_program("/sbin/e2fsck", "-p", "/dev/block/platform/sdhci-tegra.3/by-name/APP");
ui_print("e2fsck data partition");
ui_print(" ");
run_program("/sbin/e2fsck", "-p", "/dev/block/platform/sdhci-tegra.3/by-name/UDA");
ui_print("e2fsck cache partition");
ui_print(" ");
run_program("/sbin/e2fsck", "-p", "/dev/block/platform/sdhci-tegra.3/by-name/CAC");
And i include a zip for those who like to test
Ps have not checked the function of this line
Code:
run_program("/sbin/tune2fs", "-O", "^has_journal", "/dev/block/platform/sdhci-tegra.3/by-name/APP");
the bash equivalent is
Code:
tune2fs -O ^has_journal /dev/block/platform/sdhci-tegra.3/by-name/APP
where ^has_journal is a parameter of -O not sure the recovery script is wrapping that correctly, if anyone flashes this script could you please check by typing
Code:
tune2fs -l /dev/block/platform/sdhci-tegra.3/by-name/APP
in the TWRP terminal, scroll upward with an up finger swipe and check has_journal is not in the filesystem properties ( going to do it myself on next system wipe, but just enjoying the speed at the mo !! , am testing it on PRIME 04-20 mildly tweaked by me )
Thanks
Edit ... Since there has been more than passing interest in this obscure piece of code i have decided to tidy this post up
Hence now there are 2 scripts, one to remove the journal from your ext4 partitions, and one to re-instate the journal, this should allow people to test their setup with each without any wiping or reformatting
Instructions.......
( tested with TWRP 2.5+ only )
Flash the bugger
DO NOT WIPE ANYTHING, after flashing, doing so will only reformat the wiped partition with a journal
For us who have no background in Linux. What is this for? Does it just increase system speed? I'm running prime 4/20 as well and would definitely like to test it once I know exactly what it's supposed to do.
JetOhmNet said:
For us who have no background in Linux. What is this for? Does it just increase system speed? I'm running prime 4/20 as well and would definitely like to test it once I know exactly what it's supposed to do.
Click to expand...
Click to collapse
No linux was just for explanation.
But it also work for Android.
So that's a good thing
The script he has posted is for twrp.
JetOhmNet said:
For us who have no background in Linux. What is this for? Does it just increase system speed? I'm running prime 4/20 as well and would definitely like to test it once I know exactly what it's supposed to do.
Click to expand...
Click to collapse
It forgoes recording disk writing (?) operations to a journal and instead writes things directly to disk (or a buffer, if you want to be pedantic).
Instead of going:
Write to journal (I'm doing this write) -> Write to journal (I'm currently doing this write) -> execute operation -> erase entry from journal
It goes:
Execute operation
The end result is greater write speeds, but greater risk of data loss if there is power loss.
If you were in the middle of a write operation when the power goes dead, the journal entry saying that you were doing something will still be there, so the OS can either resume/restart the operation (since it knows it was incomplete) or do some sort of error handling since it knows something went wrong.
For more/related info, see this thread.
[email protected]_OC said:
No linux was just for explanation.
But it also work for Android.
So that's a good thing
The script he has posted is for twrp.
Click to expand...
Click to collapse
I got that much, just wasn't convinced on what exactly this script does.
psyren said:
It forgoes recording disk writing (?) operations to a journal and instead writes things directly to disk (or a buffer, if you want to be pedantic).
Instead of going:
Write to journal (I'm doing this write) -> Write to journal (I'm currently doing this write) -> execute operation -> erase entry from journal
It goes:
Execute operation
The end result is greater write speeds, but greater risk of data loss if there is power loss.
If you were in the middle of a write operation when the power goes dead, the journal entry saying that you were doing something will still be there, so the OS can either resume/restart the operation (since it knows it was incomplete) or do some sort of error handling since it knows something went wrong.
For more/related info, see this thread.
Click to expand...
Click to collapse
And thank you on the specifics and pros and cons. I'll definitely give it a try now and let you know what I think/if i notice any bugs!
Sorry, wrong post!
I was tring to send a message to a Razr owner but i bungled with the XDA app.
Thanks anyway for your reply.
yes will work on any android/linux system using ext4 partitions, in the case of n7 thats only system,data and cache.
But the actual TWRP script needs checking for syntax for every device. ( obviously checked it on the n7 )
I can confirm a MASSIVE speed increase, everything in noticeably smoother and faster, which is to be expected since you have increased disk i/o by at least 25%, especially important in the data and cache partitions.
To really understand whats going on you really must google EXT4 and the journal folk's, a journaling filesystem is a legacy of the linux server heritage, its very useful in a server context, if you have a crash and are running 100+ TB of data, the journal allows you to reboot and instantly be back online ( which is massively important is the server world where seconds offline means millions of dollars ) rather than wait many hours for a fsck to complete. For android it is completely inappropriate! it should be obvious why
Psyren's post is a good simple explanation of the write structure and how removing the journal speeds things up.
If this code goes into anyone's rom please give me some love in the credits
Ps as mentioned in the post there is a line to double check, if your doing it by hand from the TWRP terminal then i can confirm it def works, i have not double checked the script ( except to prove it flashes etc ) and wont for about a week, i am getting ready my own rom that concentrates on improving the linux sub-structure, and that's taking my time
Sorry if this is a stupid question, but does this wipe any partitions or will there be any data loss flashing the zip?
Or does it need to be flashed before flashing Rom?
Sent from my MB865 using xda app-developers app
elfrosto said:
Sorry if this is a stupid question, but does this wipe any partitions or will there be any data loss flashing the zip?
Or does it need to be flashed before flashing Rom?
Sent from my MB865 using xda app-developers app
Click to expand...
Click to collapse
Flashing does not wipe anything, but I also haven't noticed any i/o improvements.
Looks like a very interesting script.. Could we do that from CWM or even from a terminal? If yes what would be the procedure? Thanks for sharing!
JetOhmNet said:
Flashing does not wipe anything, but I also haven't noticed any i/o improvements.
Click to expand...
Click to collapse
Could you please check the journal has been removed with a
Code:
tune2fs -l /dev/block/platform/sdhci-tegra.3/by-name/APP
at the TWRP terminal, thank you ( remember to scroll upwards and look for the line with fs properties )
The script stuffed up my nexus. I had a backup but just letting you know. It booted to the animation but went no further. Any benchmarks?
Sent from my Nexus 7 using xda premium
bcvictory said:
The script stuffed up my nexus. I had a backup but just letting you know. It booted to the animation but went no further. Any benchmarks?
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
Hmm thats interesting, which rom you running ? You using TWRP ( im on 2.5 ) I tried it on my nexus and no problems, even with multi-rom in.
Can anyone suggest an appropriate benchmark prog to use please, ( something that tests io as-well as ui responsiveness ) and i will post results on the next wipe. Like i said i am def claiming a noticeable improvement on Prime 02-04 as far as ui is concerned, eg when i go to playstore and scroll my apps there is no longer any pause in the scroll, lots of other things like that, and all the "pages" of various apps come up faster. But really need a quantitative test.
Thanks
jubei_mitsuyoshi said:
Hmm thats interesting, which rom you running ? You using TWRP ( im on 2.5 ) I tried it on my nexus and no problems, even with multi-rom in.
Can anyone suggest an appropriate benchmark prog to use please, ( something that tests io as-well as ui responsiveness ) and i will post results on the next wipe. Like i said i am def claiming a noticeable improvement on Prime 02-04 as far as ui is concerned, eg when i go to playstore and scroll my apps there is no longer any pause in the scroll, lots of other things like that, and all the "pages" of various apps come up faster. But really need a quantitative test.
Thanks
Click to expand...
Click to collapse
Well can you write a how-to install this? I flashed the zip using Twrp 2.5 over the top of my PA install. Is that what we are meant to do?
If you are claiming io speed then maybe and io tester? (Can't think of one off the top of my head)
And an antutu just for kicks
Maybe a before and after?
Sent from my Nexus 7 using xda premium
So i forgot to run a benchmark prior to flashing this. Silly me. But here are my speeds after flashing. I'm running Prime (4–20) with faux ultimate kernel clocked at 1.7Ghz.
Also here are my Antutu and Quadrant marks:
JetOhmNet said:
So i forgot to run a benchmark prior to flashing this. Silly me. But here are my speeds after flashing. I'm running Prime (4–20) with faux ultimate kernel clocked at 1.7Ghz.
Click to expand...
Click to collapse
cool thanks for that Androbench def best in this category but readings can vary 50% or more per run, eg did 2 runs separated by seconds
run1 sqlite benchmark
insert 1052.63 TPS
Update 789.47 TPS
Delete 348.02 TPS
run2 sqlite benchmark
insert 617.28 TPS
Update 274.97 TPS
Delete 910.87 TPS
Maybe we should ignore " small differences " LOL
On the up side the RD/WRT stats only vary buy about 30% so should be a better guide.
Will have some before/after comparisons for you tomorrow,
On the subject tho should not a benchmark program have exclusive access to the system? ( which is impossible in android ) otherwise isnt it just reading and writing along side all the other system RW calls
PS.. how do you get the screenshots, would be useful for posting benchmarks
bcvictory said:
Well can you write a how-to install this? I flashed the zip using Twrp 2.5 over the top of my PA install. Is that what we are meant to do?
If you are claiming io speed then maybe and io tester? (Can't think of one off the top of my head)
And an antutu just for kicks
Maybe a before and after?
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
Well seems good to me, yes just flash it, do not wipe anything after since TWRP will reformat with a journal. To be honest i have no idea why it failed in your case, thought maybe it is a CM vs AOKP thing but just had a pm from a bloke on a CM clone that flashed great and having good results, so hey cant be that
THe only thing i can think of is the kernel, could be something tweaked in that causing a confusion between ext4-minus-juornal and ext2, that happened on very old linux kernels, but not seen that for years, so doubt that to.
If you can be bothered try again, post if you get the same result and i will give it a go with a PA when finish my little rom
jubei_mitsuyoshi said:
Well seems good to me, yes just flash it, do not wipe anything after since TWRP will reformat with a journal. To be honest i have no idea why it failed in your case, thought maybe it is a CM vs AOKP thing but just had a pm from a bloke on a CM clone that flashed great and having good results, so hey cant be that
THe only thing i can think of is the kernel, could be something tweaked in that causing a confusion between ext4-minus-juornal and ext2, that happened on very old linux kernels, but not seen that for years, so doubt that to.
If you can be bothered try again, post if you get the same result and i will give it a go with a PA when finish my little rom
Click to expand...
Click to collapse
I use M-Kernel. Don't wipe cache and dalvik?
Sent from my Nexus 7 using xda premium
jubei_mitsuyoshi said:
PS.. how do you get the screenshots, would be useful for posting benchmarks
Click to expand...
Click to collapse
Hold the power button and volume down simultaneously.
*DELETED"
*DELETED"
Thyrus said:
DOWNLOAD LINK
DOWNLOADS for Nexus 9 (flounder)
V1 (for Lollipopalooza 2014/11/15 v2)
Click to expand...
Click to collapse
Awesome!!! Downloading now ?
Thyrus said:
DOWNLOAD LINK
DOWNLOADS for Nexus 9 (flounder)
V1 (for Lollipopalooza 2014/11/15 v2)
Click to expand...
Click to collapse
Hi,
I've followed all the steps, there are no errors during install but when the tablet reboots nothing has changed.
*DELETED"
Thyrus said:
Well unless I had a brainfart and uploaded stock APKs into the zip file, it should have worked perfectly.
did you have any "android upgrading" messages upon reboot - you should have had for a couple of apps.
Click to expand...
Click to collapse
No, I didn't had any "android upgrading" messages upon reboot.
I've looked at the updater-script, and there is this line:
run_program("/sbin/busybox", "mount", "/system");
When I look in the sbin directory, there is no busybox there, could that be the problem?
Sorry if it's a noob question.
Edit: So, that was the problem.
I replaced the line:
Code:
run_program("/sbin/busybox", "mount", "/system");
by:
Code:
mount("ext4", "EMMC", "/dev/block/platform/sdhci-tegra.3/by-name/APP", "/system");
in the updater-script, then signed the zip file again and now the theme is working properly.
Thanks for the great theme!
*DELETED"
wow, this will make the tablet even more sexy! thanks!
*DELETED"
Was trying to sign the zip after modding the updater-script and for some reason the new zip still keeps failing verification =/ guess i'll just wait for an updated zip to be posted.
And as soon as i posted this i see the thread was updated lol.
Looks Great! Thanks for bringing this tablet to the dark side.
Thyrus said:
Good find - I will adjust the script and re-upload then. I know that busybox is part of Lollipopalooza, but maybe not symlinked to sbin but xbin, will check later tonight
Click to expand...
Click to collapse
sbin is part of the kernel's ramdisk
not the ROM
B.T.W. awesome Theme
Thyrus said:
Download fixed and added as V2 (script error, thanks again @sasho36 for pointing it out)
Click to expand...
Click to collapse
There is a small typo in the code in the OP :
Code:
adb sideload TBO_Dark_Material_Nexus9[COLOR="Red"]-[/COLOR]V2-signed.zip
should be :
Code:
adb sideload TBO_Dark_Material_Nexus9[COLOR="red"]_[/COLOR]V2-signed.zip
*DELETED"
@Thyrus,
Your theme looks absolutely awesome!
I suffer from a visual impairment. One of the things that it affects is my ability to look at white screens.
I must always run my desktop at work in high contrast mode. I am very thankful for TBO, I use many of their apps.
I plan on getting a N9 this weekend. I truly must have your theme for me to be able to use the tablet efficiently.
I see that your theme is only available for Lollipopalooza.
Will your theme only work with that ROM, or will it work with any AOSP ROM for the N9? I would assume we will get more of them in the future.
Is using the recovery built by the Lollipopalooza developer a requirement for your theme? I see that there is a working TWRP now for the N9.
I SINCERELY appreciate your time and efforts with this project.
*DELETED"
Thyrus said:
Hey Skid,
Well I am honored that I can actually help you - obviously that wasnt my aim, but hey I am stocked it help you even more!
Now to your qs:
1. At the moment threre is only one custom ROM - so that is what i used as a base (and to be frank, the ROM is simply perfect hence I am planning to stick with it.
2.It should work on most AOSPbased ROMs though as the typical issues with "google or normal dialer" dont apply to wifi-only tablets
3. Since I created the thread we now have TWRP custom recovery, so no the OPs recovery is no longer required.
PS: I stumbled across something in the dev options that may be even more helpful to you - i found some more help in the menus - see screenshots (color inversion)
Click to expand...
Click to collapse
Thyrus,
Sadly my eye condition isn't reversible. Although this stinks, it has motivated me to make sure to look into accessibility options on devices. I appreciate you pointing out the options that the N9 has. I do plan on trying out the color correction setting. I also use the magnification option on my G3.
The inversion option although nice, really messes with other parts of the OS. Basically I've got to switch back and forth constantly. Your FABULOUS theme (along with TBO apps) will resolve that issue entirely. You have no idea how awesome your theme is (at least to me).
Hopefully I'll have some time to get the N9 ready for your theme. I've been reading up on ADB/fastboot commands, downloaded the minimal ADB/fastboot tool, and have links saved on how to unlock the bootloader (my 1st Nexus device), root, and install ROM's. Lollipopalooza looks great to me. I have absolutely no qualms with sticking with that ROM.
Craig had posted something in his thread concerning flashing or booting the Q kernel or image (can't remember which) and I'm a little hung up on that. I'm pretty sure that I'll have LRX21R after my N9 gets it's first update.
Again, many, many HUGE thanks for doing this. Seeing your video made me jump out of my chair and yell at my wife, "This is it...this is it!!" This HAS to go on my N9.
Hopefully people with visual disabilities will somehow find this thread.
Skid
*DELETED"
Thyrus said:
I know everything there is to know about Nexus&flashing and all that good stuff, so dont hesitate to reach out to me IF you have any issue!
Click to expand...
Click to collapse
Thanks very much on your generous offer. It's a bit of a pet peeve to see folks just ask for things be given to them without doing any work ie-research in this case. Certainly hope I won't have to. I don't mind reading for weeks if necessary. The benefits will serve me well past the time I'll put into educating myself.
Sorry for the OT chat folks. :good:
I've found a little visual glitch. When your have to enter a wifi password, the text of the checkbook isn't visible (black font on black background).
I've attached a screenshot.