yashsingh1/xdaforums huggingface dataset:
[Nexus One Android Development] madmaxx82:
Thank you very much :)

New update: RC4 is online.

Disable progress indicators for tar backup/restore for a bit more speed.

Api extension for md5sum checks inside the app..

Please see changelogs inside the app for a complete changelog :)

New App features too: Check md5sums inside the app instead of in recovery (preventing reboots into recovery only to find out that the backup fails the md5sum check.)

This also prevents situations where you might have wiped before a restore and are now left without a working system (because the backup you wanted to restore fails the check).

Themes: You can now set the colour for the selection bar and also apply transparency to all colours used.

Feature for theme creators: setup all colours until they are how you want them to be and then export those settings to be used in your theme zip.
[Nexus One Android Development] jbbandos:
Hi,

I installed 2.2.7RC3 and as I was going to update a ROM I did a wipe of cache and of dalvik-cache. The big problem is that the wipe of dalvik-cache removed even the directory /data/dalvik-cache, so that when I booted I encountered a boot loop. I tried it twice and had the same result twice.

Is this fixed in RC4, or not yet?
[Nexus One Android Development] madmaxx82:
Hi!

I don't consider this a bug at all, since it has always been like that.

4EXT has been available on the Desire which is nearly the same as your device since some months and there are a few thousands using that.

They never considered that to be a bug.

Even Rom manager does it like that:

cat /data/data/com.koushikdutta.rommanager/files/dowipedalvikcache.sh
#!/sbin/sh
for partition in data cache system sd-ext
do
mount /$partition
rm -rf /$partition/dalvik-cache
done

for partition in data system sd-ext
do
umount /$partition
done

This little script resembles the way how recovery is doing that when you select wipe dalvik manually through the menu.

There are setups where you simply cannot wipe dalvik cache, but that depends on the rom and your scripts. There is no way for recovery to know about what you have flashed and how it was setup by the rom cook!

Many roms only put their dalvik-cache onto /data/dalvik-cache.

If I would change that, then people using those roms could never effectively wipe dalvik!

If there is some other recovery that doesn't do that, then I consider that to be a bug.

Because when I want dalvik to be wiped, I expect it to be clean afterwards!

Or is there a misunderstanding?
[Nexus One Android Development] madmaxx82:
Sorry I had to release RC5, which -for the Nexus One, Inspire 4G, Desire HD, Desire and Sensation- is exactly the same as RC4.

In RC4 -on the myTouch 4G, Desire Z / G2 and Incredible S / 2- I had missed to include icons those devices display when being charged offmode.

It is exactly the same as RC4, but includes those icons for those devices.

For your device, this version doesn't change anything and is no real update.

Just if anyone wonders why there is an RC5.
[Nexus One Android Development] blindndumb:
New Token_Style_Smiling_Love_Theme OUT..

Check It Out :)
[Nexus One Android Development] jbbandos:
Well, the misunderstanding might be that I've been using AmonRa's recovery until now, and that one wipes the contents of $partition/dalvik-cache, while leaving the directory itself. On a MIUI upgrade removing this directory is a sure-fire way of getting a boot loop, as it won't get recreated. On new flash it isn't a problem.

I really don't know how CWM handles it - I gave up on it ages ago, as it would corrupt sd-ext. Maybe part of the problem was exactly that - wiping dalvik-cache, which is essential when changing MIUI ROMs, and very useful even when upgrading the same variant, would make boot loops with CWM recovery, but would work perfectly with AmonRa's.
[Nexus One Android Development] madmaxx82:
The file I posted above is the one Rom Manager uses to wipe dalvik cache. So this directory gets removed.

Another user told me that when he wiped dalvik cache with an amon ra recovery not all files got removed.

I don't think that it is a good decision to leave an empty folder floating around.

I would go as far as saying that this is a bug in MIUI. Because it should never fail only because of that.

When do they create that dalvik-cache folder at all? Do they create an empty folder when the rom is flashed?

I really doubt that. And anyway if this is done when flashing the rom it's a really bad decision to not doing that on first boot or when dalvik needs to be recreated.

It must be created together with dalvik cache contents when the rom is booted for the first time.

And just like wiping the contents of dalvik cache triggers the recreation of the cache on rom boot, the rom should be responsible for creating the folder if it doesn't exist (just like on first boot)

I don't know what side effects it could have when I changed that behaviour given that this works to 100% for all roms (edit: most probably none, but you never know. Don't mess with things that are stable) and yes, also for MIUI on other devices.
[Nexus One Android Development] madmaxx82:
Something else:

If you wipe data with MIUI, the dalvik-cache folder also gets removed completely..

Does that mean you need to reflash the rom? :D
[Nexus One Android Development] k3vink3vin:
If you happen to be using DT's a2sd script like I do, I always wipe dalvik-cache by running "a2sd resetcache" before flashing a new cm7 nightly, instead of wiping using the wipe options in recovery.
[Nexus One Android Development] jbbandos:
Wiping data seems to trigger the re-creation of the /data/dalvik-cache folder. That makes sense, as the directory isn't created by the updater-script or included in the zip.

I need to investigate further if the problem, as it might even be due to the Xpart scripts I am using in my ROM. I haven't yet tried with A2SD, so if it does recreate the dir with A2SD I know where to look. If it fails with A2SD too, then there is nothing I can do, probably, as it will be done inside MIUI's closed code.

---------- Post added at 06:33 AM ---------- Previous post was at 06:31 AM ----------

Does that mean you have the same problem with a2sd, or that you are just being cautious?
[Nexus One Android Development] madmaxx82:
Everything else would be crazy :D

And that's a reason more why I don't get it that they fail to recreate the folder when dalvik got wiped.

However if this is such a big issue I've stumbled upon here, then I could add an on/off switch for that (configurable via the app but also directly by editing 4ext.prop) to tell recovery to always leave an empty folder behind.

Or even check for the device.

Would this solve that "dalvik-cache dir doesn't get recreated on wipe issue" some of you have with MIUI?

Hehe so MIUI really loves empty folders on the Nexus it seems, right?
[Nexus One Android Development] jbbandos:
I guess they check for some indication it is a first boot on a freshly wiped ROM, and in that case create the directory. It would make more sense to check for its existence just before it is needed and create it if missing, but maybe they had reasons no to do that.

The solution you propose (the flag) would solve the problem indeed.

Thanks!
[Nexus One Android Development] heywtf:
Clockworkmod recovery used to have a feature where the user could write to the extendedcommand file, reboot, and have the recovery perform a task before rebooting back into Android. This meant it was possible to schedule automatic nandroid backups using Tasker instead of ROM Manager premium, with all the benefits that brought (more advanced scheduling options instead of just time/day, cheaper, fewer apps involved, etc). Unfortunately recent versions of CWM have removed this functionality.

Can 4EXT do anything like this?
[Nexus One Android Development] madmaxx82:
Then I will do it! :)
[Nexus One Android Development] madmaxx82:
Koush has added a copyright to the use of the extendedcommands api!

That's why I was forced to implement an own solution which is based on an xml file.

However the recovery still supports extendedcommand.

It's just that apps are not allowed to use it without explicit permission from Rom Manager.

It's interesting that you bring this question now as someone else suggested I add that feature for scheduled backups et.c. to 4EXT Recovery Control.

I will certainly do that and also try hard to make this work with tasker :)
[Nexus One Android Development] heywtf:
Awesome :)
[Nexus One Android Development] k3vink3vin:
Just being cautious:), I haven't been wiping caches in recovery for quite some while now.

I just thought that, in my case, dt's a2sd is responsible for moving the dalvik-cache to sdext, it should know better when wiping it.
[Nexus One Android Development] Silverexp:
Any way to make this work with an amend script? It seems all the radio zips are amend. Hate to go fastboot or put RA Recovery just to flash a Radio and then switch back to your app...
[Nexus One Android Development] madmaxx82:
The problem is that amend was dropped by CWMR when gingerbread arrived.

Those zips are 3 years old!

Adding amend would be a pain.

I'm currently working on big updates for the recovery and app which will benefit most users on most devices currently supported.

Amend script support would only affect Desire and Nexus One and also just for the radio zips. This doesn't mean it is not important. But currently I simply cannot look into it.

On all the other devices it is absolutely uncommon to flash a radio through recovery.

This is because parts as critical as a radio should be flashed via fastboot.

Those update-scripts inside those radio zip files however are so simple and consist of only about 3 lines of code.

It would be great if someone had the time to migrate them to edify scripting.

This would be MUCH less work than trying to implement that in 4ext.

BTW: Amend was officially dropped by google with Android 1.5.
[Nexus One Android Development] jbbandos:
Well, this weekend I had some more time to try to find why removing /dalvik-cache from /data or from /sd-ext ended up in that boot loop. As I dug into the xpart script I'm using (based on the Rodriguez script), I finally found the wrong test and fixed it.

So there should be no more need for the flag to keep the dalvik-cache directories when wiping it.

Sorry about all this, at least gave me the incentive to fix that script.
[Nexus One Android Development] madmaxx82:
Thank you!

That's great!

Are you sure it isn't needed any more? Will your fix go upstream?
[Nexus One Android Development] jbbandos:
As far as I know I am the only one currently putting this XPART variant in a ROM. Maybe dRaCID00 can check on his ROM how it behaves, as I think he is using another variant, which is the same as the one on the Desire.

So I am "upstream" for this XPART, at least for now, as Rod abandoned the N1 ROMs a long ago.

If I have some time I'll see how the other ROMs handle dalvik directories and symlinking.
[Nexus One Android Development] madmaxx82:
Thanks! Sorry already at xda's thanks limit/day ;)

From what I gathered, the only rom that had trouble with removing the dalvik-cache dir on wipe was MIUI.

BTW: I have never gotten any reports about that from anyone with a Desire.
[Nexus One Android Development] jbbandos:
Hi,

I've just recommended your recovery on my ROM thread. I've done the realignment of my FAT32 this morning (my XPART scripts already format and align the ext4 partition), and I've tried a few times wiping cache and dalvik just to make sure, and everything is working well. Now I'll see how antutu grades my sd read and (in particular) write speed after aligning... :)

Best regards,
[Nexus One Android Development] madmaxx82:
Thank you very much! :)

BTW: regarding ext4 alignment: any recovery, also 4ext, will reformat any partition on backup restore. So any customizations you use when your rom is flashed, will be gone once you restore a backup or format any partition (ofc)

This happens with any recovery I know of.

If you want to know what 4ext is using in those cases, it's:

-b 4096 -O ^huge_file,^dir_nlink,^ext_attr,^resize_inode,^extra_isize -E stride=64,stripe-width=64 -m 0

Tune2fs: hash_alg=tea

However I'd like to add a feature where you can specify your own parameters which then will always be used: when the user wipes cache, data or restores a backup. Hope to have that finished soon :)
[Nexus One Android Development] madmaxx82:
I got some questions regarding Titanium Backup's new feature: extract from "CWMR5" backups:

This actually means "tar backups", which CWMR5 uses always, and it works exactly the same with 4EXT.

But since in 4EXT recovery you have the choice to switch tar backups on or off, it means you can only use this new Titanium Backup feature for your tar backups!

Tar backups in 4EXT Recovery were disabled by default in earlier versions and are now default. However you might want to check if you have tar backups enabled or not.

You can do this via the App or by taking a look at your 4ext.prop file.

Using the app: select "recovery" and then "recovery settings". There you will find a switch "Use tar backups".

You can also verify whether tar backups are enabled or not if you enter "Manage your backups".

The currently used setting is in the title.. it should read "Backup setting: tar"

Using 4ext.prop:

You can also manually switch tar backups on or off by editing 4ext.prop:

Just open that file inside /sdcard/4ext/ and set "backups.use.tar=yes"

All backups done by 4ext recovery when tar backups were enabled will work for titanium backup's "extract from CWMR" feature.

Note: on the Nexus One and Desire, CWMR5 and 4EXT only backup sd-ext(2) partitions using tar.. yaffs2 partitions like system, data and cache are still backed up with yaffs2. So this Titanium feature is of limited use on your devices :(
[Nexus One Android Development] :
Thank you for this have just downloaded and am going to test further before passing judgment but initially it looks very good regarding the features list and having bought the 4EXT app from market I am very impressed with the ease of flashing the recovery (not like on my old G1! lol). Now with the recovery the pedantic and 'slightly' OCD bit...

It really really winds me up when ALL lowercase letters are used and to me it makes the layout looks lazy and very unprofessional because of this very very very (to any normal person) minor attention to detail. It is obviously a very well supported and excellent piece of coding that deserves major props and the support offered is fantastic so please don't take this as a 'diss' to your work but merely an observation from a broken brain (my mother says its wired wrong :D)

Also on the app side of things I understand you support several devices with varying displays but the 4EXT Recovery Control 2.1.0 menu system could do with a resize as I feel the headers are very large and could do with being toned down a size or two. It just feels 'squashed' with massive header fonts and then tiny descriptions, again I understand this is all purely cosmetic and of no importance at all in the grand scheme of things but observations I thought I would share.

Edit: Small things amusing small minds and all that but love the fact the onscreen soft buttons can be used for navigation, Genius!

Edit 2: Noticed moving around in recovery and running various options it all kind of 'runs' into one, anyway to clean the screen between running each process?
[Nexus One Android Development] madmaxx82:
First, thank you very much for your support and the constructive criticism ;)

Second: I'm very sorry that it took me so long to reply. I've been and still am very busy with 4ext-ng and some other things I got to do at the moment that I missed to reply.

Regarding app design: this needs to be reworked.. it's already on my todo list for the very near future. I also agree that the font size is too large!

Regarding recovery: I'll use some upper case letters ;)

I guess you are referring to the menu items..

@Edit2: what exactly do you mean? The text output? Could do that, but other users might like to be able to read a bit back in history.. so they may not like that so much... hmm.. what do you think?

Anyway, thank you again for your support, this is really very much appreciated and I also really like to get constructive feedback and criticism. This often helps doing a better job.

In general: Regarding any requests, please understand that my todo list is already quite big at the moment and so I can't definitely promise any date as to when I'll be able to actually make any changes requested or add a new feature.
[Nexus One Android Development] heywtf:
I quite like the all lower case look.
[Nexus One Android Development] madmaxx82:
Although you are sending this from your iPhone your preference will honoured :D

I fear we need to make this configurable ;)
[Nexus One Android Development] rolflin:
So due to limitations on tar backups on nexus one & desire...(always done on yaffs), I cannot change a backup to ext4 from yaffs and restore using ext4?

What should be the way to get ext4 fs on nexus one?

I am a little bit confused on this :(
[Nexus One Android Development] madmaxx82:
You cannot change mtd/yaffs2 partitions to ext4 (which the Nexus One, Desire and many other older devices use for system, data and cache). But you can format or convert any sd-ext partitions you might have to ext4 or ext3.

If you use 4ext recovery to change a backup to - for example - ext4 on the Nexus One, only sd-ext partitions (if any) will be effected by that. There is no way to do this for yaffs2 partitions.

Also if you enter the 4ext menu inside recovery and chose to convert a partition to ext3 or ext4, you will only get a list of your sd-ext partitions to chose from if your device uses mtd/yaffs2 for all the other partitions.
[Nexus One Android Development] rolflin:
thanks :)

that's what i've been learning this days ...just needed some confirmation.

I did it with sd-ext , and it worked like a charm
[Nexus One Android Development] madmaxx82:
New app preview version is online:

Download: 2.1.1 Preview

"Preview" because there were a few internal changes and also translations into French and German that might need testing. (you can switch to English again in the settings if you dislike the localized version)

A few little bugfixes and little improvements:

Backups should now be sorted by date, MIUI roms that are quite different in where they put their rom names weren't always detected correctly in the past. This should work the same now as it does for all the other roms.

There are also two new features:

Exported color settings can now be imported again.

And finally there is a new wipe feature for the Desire Z / G2, myTouch 4G and Desire HD:

Wipe EFS partitions. The app will create backups of those partitions just in case. It also won't wipe them if it discovers that the backups weren't created.

But still: BE CAREFUL! This was tested only once so far.

Credits to ghul for telling us about that.

This is not the update I wanted though. There are tons of features that I'd like to implement, however I need to focus somewhere and at the moment this is the upcoming next final version of 4ext recovery.

Please bear with me, I will continue to work on the app again asap :)

Everyone can download and use/test the new app version. It is fully featured until 14th.

I'm planning to release it officially tomorrow on the market/slideme and the official free version too.
[Nexus One Android Development] madmaxx82:
Thank you very much for that great review! Never seen one as extensive as yours!

That the theme is not fully applied (only installing backgrounds and colours) is on purpose because of speed.

However I think with some adjustments it will be possible to apply all of it when using recovery control initiated processing inside recovery.

This is already on my todo list and won't take long ;)

Unfortunately I have no influence on that. This is an issue with Superuser.

For the majority of users this does not happen, although the app is obviously the same and the code that requests root is also the same. The only factor that is not is Superuser/su binary and the overall configuration.

Apps behave a little different when requesting su and this is why you might see differences in that behaviour.

But Recovery Control doesn't use anything exotic. The only call to su that it ever does is su -c /system/bin/sh which is really basic.

I'd love to be able to help this situation where you need to remove it from Superuser on some setups!

Yes of course this is possible and I will do that ;)

I complete agree with you about the theming! I really need to change that :)

Thanks again for that awesome review and that great feedback!

Soon I will release an update that will include those changes regarding themes and your request regarding text output!
[Nexus One Android Development] baseballfanz:
Thank you madmaxx82, great recovery.:)
[Nexus One Android Development] madmaxx82:
Thank you very much for the nice feedback :)
[Nexus One Android Development] blas4me:
Just one thing???????

Can someone tell me were the backups go, I forgot the path when I was performing a backup:eek:. I'm so used to Amon's recovery. I want to flash a update, but before I do, I want to perform another backup, but first I need to copy the first one to my computer so I can delete it off my sd. Thanks in advance.
[Nexus One Android Development] baseballfanz:
Should be a folder label clockworkmod
[Nexus One Android Development] blas4me:
Thanks a bunch for the quick reply. o_OvEnOmO_o
[Nexus One Android Development] Pr0fess0rX:
I want to buy "3EXT Recovery Control" but it's written in the marker "nly for ROOT users with S-OFF devices!" and my N1 is S-ON!

Can I use use? and what does S-OFF/S-ON mean?
[Nexus One Android Development] :
I have S-ON and can use it without problem.

S-ON & S-OFF I've never actually bothered figuring out but I have it to mean Security on or off for writing to nand but I'm probably way off lol

Edit: Here is an extract taken from THIS website. Very easy to find what you want when you get off your lazy arse and search... http://lmgtfy.com/?q=what+is+s-on+and+s-off
[Nexus One Android Development] madmaxx82:
If you are secure on you shouldn't be able to directly write on the recovery partition at least not on the usual HTC Devices.

If you are in doubt, just try the free 4EXT Updater app. If it is able to flash the recovery (OTA install) then it will work for Recovery Control too ;)
[Nexus One Android Development] madmaxx82:
posted instead of edited.. :p
[Nexus One Android Development] Pr0fess0rX:
I installed the free tool and it worked well with me, does this means that I use the paid app?
[Nexus One Android Development] madmaxx82:
Yes, then you can use it without any limitations.

Even if not.. just send me an email, I would refund you immediately.
[Nexus One Android Development] Pr0fess0rX:
thank you, I'm really doing it for the donation only, I'm a big fan of doing the recovery operations from the recovery it self :)

I like the recovery, well done.

---------- Post added at 02:30 PM ---------- Previous post was at 02:28 PM ----------

BTW: When I format /sd-ext partiton with ext4 and the phone does not recognize it, is it something relate to the recovery or the kernel? or should I do something else to get it recognized?
[Nexus One Android Development] madmaxx82:
Thanks very much!

Although you can do some very useful things (and I don't mean the theming options) with the app that you cannot do with the recovery ;)
[Nexus One Android Development] madmaxx82:
It doesn't have anything todo with the recovery.. the recovery just formats it to ext4 if you like (or converts from ext3 without data loss.. depends on what you select).

If the rom does not recognize it then it is not ext4 compatible.. either due to the kernel used or the roms init scripts ;)

You can always convert back to ext3.
[Nexus One Android Development] Pr0fess0rX:
I tried it with CM7 and MIUI but with custom kernels, it might be the kernels are the reason!!
[Nexus One Android Development] madmaxx82:
Great ;)

Yes they are crucial for ext4 filesystem support :)
[Nexus One Android Development] Pr0fess0rX:
this mean I have to stick with their kernels and don't change it. thank you.