Root [Custom ROM]-Tagged

[MacFett]

Hashtag I thought I made the mistake too and never mentioned it. But hearing others say the same thing makes me realize it may not have been an accident on my part.

I use nothing of which I know that links data and the sdcard.

Leslie Ann it happened only once. The one time I used your script.

I wish the wipe sdcard option wasn't even on that page.

 

[Hashtag]

Yeah, I checked Leslie's ZIPs.

There is nothing wrong with them. One formats the system, cache and data partitions and the other formats the system and cache partitions. Neither touch the internal sdcard (/dev/block/mmcblk0p15) or external microSD (/dev/block/mmcblk1p1).

Do any of you happen to be using something which links /data to /sdcard?

I don't. It happened fairly late at night(or early in the morning), so it's completely plausible that I went down one or two rungs and selected the wipe sd option. I will make more of an effort to pay attention to what I'm doing.

 

[giantpune]

While the cwm is running, /sdcard has nothing to do with the internal sd card. In order to wipe it, you would have to have it mounted and access it with /emmc or by the /dev/block/mmcblk name. Anything that symlinks /data and /sdcard would have wiped your external sd card while running in cwm, not the internal one.

 

[Hashtag]

While the cwm is running, /sdcard has nothing to do with the internal sd card. In order to wipe it, you would have to have it mounted and access it with /emmc or by the /dev/block/mmcblk name. Anything that symlinks /data and /sdcard would have wiped your external sd card while running in cwm, not the internal one.

Well perhaps I'm just more of an idiot than I'd like to admit to myself.

 

[ktb83]

While the cwm is running, /sdcard has nothing to do with the internal sd card. In order to wipe it, you would have to have it mounted and access it with /emmc or by the /dev/block/mmcblk name. Anything that symlinks /data and /sdcard would have wiped your external sd card while running in cwm, not the internal one.

Good point about /sdcard vs /emmc in CWM.

The ZIPs Leslie posted do specify formatting by mmcblk, it's this simple:

ui_print("Formatting System");
format("ext4", "EMMC", "/dev/block/mmcblk0p12");

ui_print("Formatting Cache");
format("ext4", "EMMC", "/dev/block/mmcblk0p6");

ui_print("Formatting Data");
format("ext4", "EMMC", "/dev/block/mmcblk0p13");

 

[Artine]

There is nothing in those scripts that goes anywhere near the internal sdcard.
However, strange things can and do happen.

I have used them myself and not had an issue, but to be honest, doing it manually is the better way.

In all honesty, every time I have used the scripts this hasn't happened. Maybe I'm one of the lucky ones?

 

[Hashtag]

Does anybody have any idea what would cause CWM to go "SD card volume could not be determined" when i'm flashing scripts? Maybe the cause of this is also the cause of internal SD's being wiped.

 

[Hashtag]

In all honesty, every time I have used the scripts this hasn't happened. Maybe I'm one of the lucky ones?

No, Leslie Ann makes good work. I'm sure it's something we must have done to cause this.

 

[ktb83]

Does anybody have any idea what would cause CWM to go "SD card volume could not be determined" when i'm flashing scripts? Maybe the cause of this is also the cause of internal SD's being wiped.

If you're referring to the message about /sd-ext, that's normal since nothing is mounted there. Otherwise, I have no idea.

 

[Leslie Ann]

No, Leslie Ann makes good work. I'm sure it's something we must have done to cause this.

Believe me, I do make mistakes, but I try and be careful. I really don't like the idea of being even partially responsible for bricking someones phone or even losing data, I'm too empathetic.

Overall though, given some of the things I have done on these phones, I think my record on quality and safety is pretty good.

 

[giantpune]

yeah, i was kinda iffy on that one too. i also didnt like the waiting circle, so I took them out. See the changelog for more details.

To anybody that is on Harmonia, aeneas, or the multiple variants, there is a file in /system/etc/init.d called ext4tuneup. It is a script that was written for a different phone, and as such, our phone does not feel the effects that it could bring. If you open it up, you will see where it says...

target=`getprop ro.product.device`
case "$target" in "shooter")
tune2fs -o journal_data_writeback /dev/block/mmcblk0p23
tune2fs -o journal_data_writeback /dev/block/mmcblk0p24
tune2fs -o journal_data_writeback /dev/block/mmcblk0p25
echo "HTC EVO 3D data_writeback enabled";
;;
esac

This journalism helps to speed up read/write times, but the problem is, our phone doesn't use mmcblk0p23,24, or 25 for the cache,system,data. So, to fix this we have to change the mmcblk0p#'s to match our phones numbers. The correct ones are mmcblk0p6, mmcblk0p12, and mmcblk0p13. After you do that, it should look like this...

target=`getprop ro.product.device`
case "$target" in "shooter")
tune2fs -o journal_data_writeback /dev/block/mmcblk0p6
tune2fs -o journal_data_writeback /dev/block/mmcblk0p12
tune2fs -o journal_data_writeback /dev/block/mmcblk0p13
echo "HTC EVO 3D data_writeback enabled";
;;
esac

In all honesty, it won't hurt your phone to keep it how it is, but if you're like me and you want to squeeze every last drop of performance out of your phone, you'll make the change.

That would have absolutely no effect on our phone. The target=`getprop ro.product.device` will return "m3s" on ours , not "shooter". So that script will do nothing at all. Make it looks something like this if you actually want it to do something.

target=`getprop ro.product.device`
case "$target" in 
    "shooter")
    tune2fs -o journal_data_writeback /dev/block/mmcblk0p23
    tune2fs -o journal_data_writeback /dev/block/mmcblk0p24
    tune2fs -o journal_data_writeback /dev/block/mmcblk0p25
    echo "HTC EVO 3D data_writeback enabled";
    ;;
    "m3s")
    tune2fs -o journal_data_writeback /dev/block/mmcblk0p6
    tune2fs -o journal_data_writeback /dev/block/mmcblk0p12
    tune2fs -o journal_data_writeback /dev/block/mmcblk0p13
    echo "Optimus Elite data_writeback enabled";
    ;;
esac

 

[mcgraham89]

Nice Job HashTag. Just got around to installing this. So far so good. Thanks to you, Giant Pune, Leslie Ann and the others who made this possible.

 

[mcgraham89]

Has anyone had a problem with the Calendar app in this ROM? Every time I try to launch mine I get a "The application Calendar (Process.com android.calendar) has stopped unexpectedly" error. I've wiped the Caches without any luck. Thanks.

 

[Artine]

Has anyone had a problem with the Calendar app in this ROM? Every time I try to launch mine I get a "The application Calendar (Process.com android.calendar) has stopped unexpectedly" error. I've wiped the Caches without any luck. Thanks.

My best bet is that that is caused by his removal of CalendarProvider, but keeping Calendar.

 

[mcgraham89]

My best bet is that that is caused by his removal of CalendarProvider, but keeping Calendar.

Thanks Nice Catch! I used es file explorer to put the original calendarprovider.apk back into the /system/apps folder rebooted and all is well. Appreciate the help.

 

[Artine]

Thanks Nice Catch! I used es file explorer to put the original calendarprovider.apk back into the /system/apps folder rebooted and all is well. Appreciate the help.

I noticed that when I tore apart the build tonight. You just happened to post right after I found that. Glad I could help!

 

[Hashtag]

I think I may offer two versions of this ROM. One that has all the features that a decent amount of people use, and another that is as simplistic and fast with less features(if you want more features, and you'll have to either add them yourself to the slim version, or go to full featured version). Can I have some opinions on this please?

I'm also toying around with the idea of a "Tagged Maintenance Center". This would check for updates to your version of the ROM, and rather than having to download a whole new ROM and flash it, the app will just make the updates itself, like a patch. What do you guys think?

 

[Leslie Ann]

I'm also toying around with the idea of a "Tagged Maintenance Center". This would check for updates to your version of the ROM, and rather than having to download a whole new ROM and flash it, the app will just make the updates itself, like a patch. What do you guys think?

Updates are nice in theory, but are a pain in the neck for devs, which is why very few devs bother with them. Those who do, are usually newer devs who haven't tried it.

Go through a few rom threads, the #1 issue is from not properly wiping before install. Updates are even worse. By doing updates, people are even less likely to wipe what they should and you end up with ten times more problems. Plus, the updates don't always take for the exact same reason.

I've just found it messy and more work.
I build a rom, then I have to make a patch from that to update the older version, it's more work. You end up with people who updated using the whole rom, people who updated using the patch, and people doing fresh installs. All of which you now have to deal with. This is why the first response out of most devs mouths are regarding how you installed and what did you wipe and that they should start over fresh.

As you start to understand how Android works, in particular Dalvik, you start to see why patches can become a pain in your neck. Yes, it's better for everyone because you use less bandwidth initially, but as issues pile up, you have to start wondering how much time, effort and bandwidth you actually end up saving. In the end, any time you save them, will cost you almost as much in support.

 

[Ranhead]

I think I may offer two versions of this ROM. One that has all the features that a decent amount of people use, and another that is as simplistic and fast with less features(if you want more features, and you'll have to either add them yourself to the slim version, or go to full featured version). Can I have some opinions on this please?

Sounds like a great idea to me. I would rather have app choices for things like a power control, calander, alarm clock and even which camera to use.

 

[Hashtag]

Updates are nice in theory, but are a pain in the neck for devs, which is why very few devs bother with them. Those who do, are usually newer devs who haven't tried it.

Go through a few rom threads, the #1 issue is from not properly wiping before install. Updates are even worse. By doing updates, people are even less likely to wipe what they should and you end up with ten times more problems. Plus, the updates don't always take for the exact same reason.

I've just found it messy and more work.
I build a rom, then I have to make a patch from that to update the older version, it's more work. You end up with people who updated using the whole rom, people who updated using the patch, and people doing fresh installs. All of which you now have to deal with. This is why the first response out of most devs mouths are regarding how you installed and what did you wipe and that they should start over fresh.

As you start to understand how Android works, in particular Dalvik, you start to see why patches can become a pain in your neck. Yes, it's better for everyone because you use less bandwidth initially, but as issues pile up, you have to start wondering how much time, effort and bandwidth you actually end up saving. In the end, any time you save them, will cost you almost as much in support.

I see. Well, thank you for saving me a bunch of time Leslie. I really appreciate it

 

[jonny5449]

Wouldn't that break copyright laws?

I don't know? I'm not releasing

 

[Leslie Ann]

Wouldn't that break copyright laws?

They can complain, but if they used any Android scripting, their whole thing is open source.

This is something A LOT of developers seem to forget.

With open source you can fork it, re-use it, whatever. They should get credit and it is frowned upon if you just blatantly pass something off as your own, but in terms of rights, they don't have a whole lot.

What you cannot do, is take open source code, change a small part and then close it off to others. In Android we have closed source drivers, and closed source apps, but none of those are supposed to contain any open source code. If they do, then they are breaking the law. This is how we are forcing phone manufacturers to give us the source to their roms.

 

[reID_entify]

Cant get live wallpapers to work. Itll let me change normal wallpapers but wont let me do anything with live ones.

 

[Artine]

Cant get live wallpapers to work. Itll let me change normal wallpapers but wont let me do anything with live ones.

Live wallpapers don't work because they don't exist in the first place. They were removed from the ROM - something I did in my own, too. It saves space as they are essentially bloat and will eat your battery. If you want live wallpapers, Hashtag I'm sure will either create an optional download of his ROM with them, or you could add them in manually.

Normal wallpapers still exist, however. That is why those work.

 

[Leslie Ann]

Just pull livewallpaperpicker.apk from the stock deodexed rom and copy it to system/app.

You may have to set the permissions depending on the file manager used (ES sFile does it automatically).