IHO Poo Remover rev5 - 20110824 - Optimus V Android Development

IHO Poo Remover rev5 - 20110824 - Optimus V Android Development

Should work for all Optimus V GB ROMs (aosp & IHO variants)
steps to modify:
extract
edit remove.sh script*
zip
sign
*works best in a unix editor. Notepad++ & Windows notepad sometimes screw with shell scripting handles new line something-or-other. In Windows I've used another free app Jedit for editing it and it seems to not give me 'installation aborted' msgs when installing the zip.
IHO Poo Remover rev5 (link updated)
comments on Email.apk: personally, I use it because it not only connects to Exchange servers but Hotmail email/contacts/calendar syncing can be set up directly in account settings with it there. instructions
Pls extract the zip & look at the remove.sh to see what I'm removing because I have my opinions. You can comment out & zip it back up to your tastes. If you have a variant you've made go ahead & post a link to it. Nice to compare what we each prefer.
In regards to ringtones & notifications I remove all but a basic ringtone. You can either add your own into the script- just drop them in the ringtones & notification subfolders or put additional ringtones on your sdcard in a folder made and named 'ringtones'.
Other notes is it removes a bunch of languages & adds a smaller English language.
I left in CMStats because I want Cyanogenmod to know we use it.
Don't know what Pacman.apk is so I have it commented out. May remove it if I figure out what it is.
Source on safe to remove apks and their purpose on Cyanogenmod wiki
rev5-
removed the sqlite tweaks as they didn't really do much on the IHO ROM
added removal of bootsound since it's an annoying idea

That SQLlite binary patch looks interesting. Looked at the source page, and they only have the /system/lib/libsqlite.so included, while your .zip includes /system/bin/sqlite3 too. I don't see a /bin/sqlite3 currently on my phone, what is the 2nd bin for?

jawz101 said:
Don't know what Pacman.apk is so I have it commented out. May remove it if I figure out what it is.
Click to expand...
Click to collapse
Pacman is run one time only. When you first sign into the market. It offers to download all the google apps at once. i.e. Maps, Facebook, Voice, Youtube, etc. I find it useful; since I use most of what pacman offers up. Hope that helps. I'll defiantly have to try poo remover. Love that name BTW.

I guess I left that part out, Whyzor. I'm pretty sure it's useless on its own but among these tweaks is a command that will vacuum the sqlite databases contained on the phone. I guess those that use those scripts would benefit from it most. I may take that piece out since I don't think it's being added completely (maybe not chmoding) because I end up having to run the chmod by hand sometimes. I could be wrong though and it may work.
Anyways, to actually use the sqlite3 you'd need a script like this one from FranciscoFranco, adjusted by mmarz . there's a portion of this script that vacuums the phone's databases. real-world benefits? It's likely negligible at best but I just threw it in there.
If you are ever interested I'd follow anything FranciscoFranco & Ungaze do- they're Optimus One tinkerers but they're obsessed with performance. Really anything they do is applicable to Android in general. Franco's Optimus One ROM is insane (xda) (github source)

I just replaced the /system/lib/libsqlite.so from the source thread you posted, set permission to be same as the other binaries, rebooted. Ran RL Benchmark and got the same, around 93 seconds overall score (using 245-600 ondemand CPU, IHO CM7.1. Are you getting the same performance?
UPDATE: If I overlock to 806 Mhz, was able to drop the overall time to 71 seconds, went back to original libsqlite.so and at the same clock speed, takes about 81 seconds. The performance gain is negligable given the corruption risk (and according to Blarf in the IHO thread, properly written apps won't see much of a benefit anyway).

yeah I'll probably take that out. It gave a noticeable improvement when I ran aosp. May also be that I'm not applying it correctly with this zip.
on aosp the RL Benchmark went from around 80 seconds down to maybe 45 seconds for comparison.
Probably best just have this as purely a bloat remover. Regardless, having it in there isn't messing anything up so this is still safe to use.

First off I love the poo remover. However, every time i edit the script, zip the package back up again, and sign it and then try to apply it the installation keeps getting aborted with CWM.
I have followed the instructions for windows, including using Jedit, and i have even tried with my macbook using a terminal session with pico.
i do sign the zip files also.
should i not include the stock folder META-INF in the altered script?
any help is greatly appreciated

that's usually what gets me is the editor I use to edit it with. I'd assume a macbook would be fine for editing it.
I usually remove these 3 files from the meta-inf folder before resigning as they get regenerated with that signing program (cert.rsa, cert.sf, manifest.mf). I don't know if that would affect anything but I've just been doing that out of habit.
Fortunately we understand what we're trying to do and really the only thing that's hanging it up is whatever the hiccup is.
It came down to making one change at a time until I got install aborted errors to stop

thanks much i will give it a shot

may want to try just unzipping it and rezipping it to see if that works.
Make sure you're zipping up the contents of the iho zip and not the actual folder.
Try it with & w/o signing it. If it works w/o signing it I'd leave that step out just so you can concentrate on editing the remove.sh script.
Possibly use a command line editor if your mac can do that (never used a mac)
issue is with unix line endings vs. windows/mac line endings
just found something if you're using Notepad++ try going to edit- EOL Conversion & switch it to Unix

i will look for another terminal editor and try that too.
i was originally using pico in the terminal.
when i was doing the editing of the remove.sh, i wanted to install the default ringtones and notifications.
do you think the restore that runs at the end of the removal is conflicting with it? I will give everything a shot today and let you know later what happens.

I'd just take those remove lines and audio folder out, put them in that audio folder, or just have a ringtone folder on your SD card
The restore is just adding stuff back

got it working
it was my stupid mistake of zipping the IHO folder and not the contents of the folder
so when i was signing it it created the META-INF folder and a IHO folder
Everything flashed and worked great
thanks again

I was interested in looking at this, but it no longer exists on mediafire. Any chance you can put it back up?
-John

Yeah.I will put it up tomorrow. It's also good to pm on old threads like this

I've been lazy... updated the post with a new link to the file. Sorry... been really slacking lately :/
It's the same poo remover revision5 from before. again, read the stuff at the top if you want to make changes.
I've honestly not been using my script for a long time but it's nice to have around.

Related

applytheme - Tool for universal themes.

I'm working on a tool I'm calling "applytheme". Basically you create a theme.zip, stick it in an archive with the included applytheme binary and update-script, sign it, and it will update the files on any of the Dream firmwares with the ones you've provided.
There are some limitations currently:
It can't yet determine space required before-hand, so you may run out of space in the middle. If you do, you can just restore the original theme with the restoration update.zip.
It can't add files - only replace existing ones.
The original files are stored in /data/original_theme.zip, which will eat your /data space, but only the replaced files are stored.
This version is a test release and may or may not have bugs. Be sure to back up your phone before trying it.
Please consult the example for figuring out what to put in the theme.zip, but it's basically full-path-to-filename-you-want-to-update/full-path-to-file-you-want-to-replace
So if you wanted to replace "assets/images/android_320x480.png" (the boot screen) in "/system/framework/framework-res.apk", you would have a file in your theme.zip called "system/framework/framework-res.apk/assets/images/android_320x480.png".
Case matters - please use the correct case (which is usually all lowercase).
Example theme (replaces boot animation only, with a cupcakedroid):
applytheme-200902090018-example.zip
Restoration update.zip (restores from /data/original_theme.zip then deletes original_theme.zip):
theme_restore-200902090018.zip
Source code (for developers or other curious people):
applytheme-200902090018.tar.gz
EDIT: 200902082117 fixes a couple of stupid bugs in 200902081755 :/
EDIT: 200902082316 removed extraneous/incorrect free space check; noticed that the update script stuff is significantly more stupid than I'd thought - update scripts should work now.
EDIT: 200902090018 close files so space can be reclaimed during patching
Reporting problems
If one of the applytheme updates fails, while still in the recovery mode please do the following:
Press ALT+X to get to the console
Press <enter> to get to the prompt
Type cp /cache/recovery/log /sdcard/recovery.txt
Type df >> /sdcard/recovery.txt
Type reboot to reboot.
Send the recovery.txt from the SD card to zinx <AT> users.sourceforge.net with the subject "applytheme error log"
If I don't have the log (or at least the error message from the log), I can't know why it's failing, and can't do anything to fix it.

I am looking at your post but don't see the benefits of doing it like this. you would still need to do this every time you add a theme or just a image and you still need to sign it or am I just not seeing the benefits of using it

kron2 said:
I am looking at your post but don't see the benefits of doing it like this. you would still need to do this every time you add a theme or just a image and you still need to sign it or am I just not seeing the benefits of using it
Click to expand...
Click to collapse
Current themes replace the whole system.
If you change as single file in /system/app/Browser.apk (say, an icon), you have to replace the whole file.
You don't have to do that with applytheme, so you can replace the icon no matter what firmware is being run.

This would be great themes wont need to be converted any more.

manup456 said:
This would be great themes wont need to be converted any more.
Click to expand...
Click to collapse
Indeed, for example:
More Vintage Less War via applytheme (theme by manup456 )
EDIT: Oh, I should note I tested this one with RC33. Didn't bother to time the progress meter though, so just wait until it tells you to reboot with home+back.

This looks like an amazing tool! I'm surprised more people haven't checked this out.
Let me get a few things straight before I give it a shot.
Let's say I was updating some basic images in the framework-res.apk. All I need to do is:
~Download your applytheme-example.zip
~Open up the theme.zip (remove current folders inside)
~Create the folders system\framework\framework-res.apk\res\drawable\
~Add the icons I've changed, with the exact original names
~rename applytheme-example.zip to update.zip
~load onto SD card and load onto phone as usual
~success?
I don't quite understand the backup system...
When you load the update onto the phone, it backs up the images you're replacing and puts them into a \data\original_theme.zip?
Then, if for some reason you want to revert to the original theme, you simply run the theme.restore.zip on the phone and it grabs all the \data\original_theme.zip images and places them in their original location?
Also, if the theme you're installing is a few megs, then the \data\original_theme.zip will get rather large, no? Will this cause any issues?
Thanks!

The steps are a bit more like this:
Download applytheme-example.zip
create system/framework/framework-res.apk/res/drawable/
add the files you've changed
create a theme.zip with the files above - MAKE SURE IT HAS THE PATH, STARTING WITH system/
replace the theme/theme.zip in applytheme-example.zip with your new theme.zip
sign the applytheme-example.zip with the replaced theme/theme.zip
put it on the SD card as /sdcard/update.zip and update as normal
success! (unless there was a problem during patching, then it may be partially applied and you can use theme_restore.zip to fix it)
MOONSSPOON said:
When you load the update onto the phone, it backs up the images you're replacing and puts them into a \data\original_theme.zip?
Then, if for some reason you want to revert to the original theme, you simply run the theme.restore.zip on the phone and it grabs all the \data\original_theme.zip images and places them in their original location?
Click to expand...
Click to collapse
Yep.
MOONSSPOON said:
Also, if the theme you're installing is a few megs, then the \data\original_theme.zip will get rather large, no? Will this cause any issues?
Click to expand...
Click to collapse
It can get large, yes, but keep in mind that it's only the original files that have changed that get put in it. Most themes right now are much larger .zips than they actually are, because they include much more than what was changed. If it gets too large to fit, the update will just fail part-way, and you can restore using the theme_restore.zip.
You can also delete it if you don't want to restore.
If you have any better ideas for any of this, I'm definitely open to suggestion - It's not anywhere near finalized yet

Great work. Definitely a step in the right direction for generalizing themes and allowing them to work with any build without modification.
Some thoughts for the next steps... Perhaps do a once-over of the files in theme.zip and compare their sizes with the existing files? This would just about double the time it takes to install, but should catch any out-of-space issues before any replacements had been made. Alternatively, perhaps there's a way to detect failures and automatically revert and display an error?

MasterBunnyFu said:
Great work. Definitely a step in the right direction for generalizing themes and allowing them to work with any build without modification.
Some thoughts for the next steps... Perhaps do a once-over of the files in theme.zip and compare their sizes with the existing files? This would just about double the time it takes to install, but should catch any out-of-space issues before any replacements had been made. Alternatively, perhaps there's a way to detect failures and automatically revert and display an error?
Click to expand...
Click to collapse
Automatic reversion can be done.
The update stuff is too stupid to let me display an error (Seriously. There's no way to display a message to the user. All I get is the unchangeable 'Failed on line 3'.) - an error is kept in /cache/recovery/log though.
Checking the file sizes would indeed take twice as long - everything is compressed, so I'd basically be creating every file touched, but discarding the output, then creating it all again. It already takes quite some time, and it should normally have enough space free, so I would prefer to go the automatic reversion route if people don't want to have to use the theme_restore.zip after a partial update.

So I tried throwing in your more vintage theme, but I get the error failed on line 4.
I feel like a leecher posting this message, but explain to me how it's done.

APrinceAmongMen said:
So I tried throwing in your more vintage theme, but I get the error failed on line 4.
I feel like a leecher posting this message, but explain to me how it's done.
Click to expand...
Click to collapse
Should just be putting in it; can you post the /cache/recovery/log from after it fails? May need to copy it somewhere before rebooting.
I expect it's due to lack of space, but it was ok here :x

In an effort to make it a bit easier initially, I've written "toapplytheme". It takes a theme update, the update it was based on, and outputs an applytheme compatible theme.zip - You still have to put in in theme/theme.zip in the applytheme update zip and re-sign it, though.
If you use something other than the update it was based on, you're going to end up with a lot of extra and/or missing files, so don't do it.
Ex:
Code:
toat MyExcellentTheme.zip JFv1.41_RC33_light2.zip theme.zip
toat-200902091613.zip

Worked for me
I have an ADP1 w/the latest JFv1.43h, I extracted Rusty Metal (from the RC33 version, using you tool). Put it there on the example, signed it all and voila...
The only thing I noticed is that the background did not get changed, but that is a minimal issue (and easily fixed).
Great job Zinx, I don't understand why all theme designers don't use this tool.
A matter of time I hope?

DanOtero said:
I have an ADP1 w/the latest JFv1.43h, I extracted Rusty Metal (from the RC33 version, using you tool). Put it there on the example, signed it all and voila...
The only thing I noticed is that the background did not get changed, but that is a minimal issue (and easily fixed).
Click to expand...
Click to collapse
I just applied Rusty Metal to my G1 using the standard way (not this tool) and the background doesn't install with it anyways, so it's not a problem with this tool, but the theme itself simply doesn't include it.

HELP NEEDED: Trying to make my own custom ROM!

Hi,
So, I'm trying to make my own custom ROM. Nothing too fancy, just a couple of simple and easy modifications to fit my needs but there's somethings I don't know how they work nor I understand them and I need some help. The only thing I was able to achieve as of yet was to remove some apps (I only tried to remove "Learn More" and QuickOffice to be honest-- but it worked). I just removed the .apk and .odex file directly from the .zip file, signed it and flashed it as usual. It worked fine.
Now, a few questions...
1) I also tried to add a few apps, just like in MoDaCo Custom ROM (MCR), to the /data/app folder instead of /system/app. Actually, I just copied all of .apk files from MCR /data/app into my own (with same folder structure of course). But they didn't get installed... I know I'm missing something and I can almost bet it has something to do with the /META-INF/com/google/android/update-script file. I tried countless times to search for some guide, how-to or just a piece of documentation about this file but I can't find anything. I don't want to just change it and see if it works and then screw things up. Can anyone give me some hints about understanding this file? It has to do with the fact that my /data/apps weren't installed, right?
2) I don't use the Gmail app, just the HTC Mail one. Is it safe to delete Gmail.apk and GmailProvider.apk? I believe Gmail.apk will be fine, but the provider one, I guess it's used by the data synchronization thing. Maybe it's ok if I don't sync my mail (that's what I want actually) but maybe there's something else that I'm missing and the system will not work properly, somehow, without the GmailProvider.apk or is it safe to remove it?
3) When we first install a new ROM, starting clean, there's an introductory guide allowing to setup some things initially. One of those is the language. There is a bunch of languages, specially like English (A), English (B), English © where the letters represent other languages. I don't need all that, I only need English (Portugal). Is there anyway I could remove the ones I don't want from the ROM or I would need to dig into the Android source for that?
3.1) How about adding my own language? Is there a way I could do that to my ROM?
NOTE: Funny thing, the Android system is localized on my country's language when I first start the device but as soon as I change it to English, I cannot change it back to Portuguese cause that option doesn't exist. How come the device is in Portuguese when I first start it up after flashing a new ROM? This also happens every time I swap the SIM card, but I can never select Portuguese language by myself. Why?
4) I noticed that after flashing my custom ROM, after booting the device for the first time, the mobile network was active. This is not good... For now I have 1 month free of mobile networking but that won't last forever. I don't want to waste money every time I'm trying a new ROM. Is there anyway to disable this thing from automatically starting up connected when I first boot?
For now that's it...

1. You need to edit "META-INF/com/google/android/update-script"

That's what I said... :/ But I also said:
I tried countless times to search for some guide, how-to or just a piece of documentation about this file but I can't find anything. I don't want to just change it and see if it works and then screw things up. Can anyone give me some hints about understanding this file?
Click to expand...
Click to collapse
If anyone knows anything helpful of course...

Nazgulled said:
That's what I said... :/ But I also said:
If anyone knows anything helpful of course...
Click to expand...
Click to collapse
I am also interested in a guide or walk through for making a ROM for the Hero.

1) I also tried to add a few apps, just like in MoDaCo Custom ROM (MCR), to the /data/app folder instead of /system/app. Actually, I just copied all of .apk files from MCR /data/app into my own (with same folder structure of course). But they didn't get installed... I know I'm missing something and I can almost bet it has something to do with the /META-INF/com/google/android/update-script file. I tried countless times to search for some guide, how-to or just a piece of documentation about this file but I can't find anything. I don't want to just change it and see if it works and then screw things up. Can anyone give me some hints about understanding this file? It has to do with the fact that my /data/apps weren't installed, right?
Click to expand...
Click to collapse
You're missing copy_dir PACKAGE:data DATA:, so you're really not writing /data/app even if it's on the package. If you read through the update-script, you'll see that it starts by formating BOOT: and SYSTEM: and later on writes the contents of /system to SYSTEM: (with copy_dir) and writes the raw boot.img to BOOT: (with write_raw_image).
Add the line to the very end of the permissions settings (but before format and write boot, most likely, before the show_progress line). You also need to set a specific permission after writing anything to /data/app from an update-script, otherwise your market won't be able to install anything (as you'll have changed the permissions for /data/app through the update-script).
In all, your update script will look like this (assuming a regular update-script, not the mcr 2.9 one):
Code:
...
symlink toolbox SYSTEM:bin/xxxxyyyy
...
set_perm 0 0 04755 SYSTEM:bin/su
copy_dir PACKAGE:data DATA:
set_perm 1000 1000 0771 DATA:app
show_progress 0.1 10
show_progress 0.2 0
write_raw_image PACKAGE:boot.img BOOT:
show_progress 0.2 10
2) I don't use the Gmail app, just the HTC Mail one. Is it safe to delete Gmail.apk and GmailProvider.apk? I believe Gmail.apk will be fine, but the provider one, I guess it's used by the data synchronization thing. Maybe it's ok if I don't sync my mail (that's what I want actually) but maybe there's something else that I'm missing and the system will not work properly, somehow, without the GmailProvider.apk or is it safe to remove it?
Click to expand...
Click to collapse
It's safe to remove both, though the provider doesn't do much without the app, so it's also safe to leave it there.
3) When we first install a new ROM, starting clean, there's an introductory guide allowing to setup some things initially. One of those is the language. There is a bunch of languages, specially like English (A), English (B), English © where the letters represent other languages. I don't need all that, I only need English (Portugal). Is there anyway I could remove the ones I don't want from the ROM or I would need to dig into the Android source for that?
Click to expand...
Click to collapse
Hero roms take their settings from xml files in /system/customize. You'll see a bunch of xmls in there. Some are references to other xmls to be used (mns_map and cid_map), some are default settings (default.xml, COMMON.xml) and some are carrier specific settings (/CID/HTC_*.xml and /MNS/Lan_*.xml). The files are very redundant, and it's hard to tell which one is being used when, though, as a rule, you should understand that Hero loads a default from the /customize folder and then looks at mns_map and cid_map for the file to use inside /CID and /MNS. I'm not yet aware how it chooses the file, but, if you narrow down it's choices, then you can control which ones it uses and modify the settings there. If you crack open the xmls, you'll immediately see the languages defined in there (en_US, en_GB, etc), so removing languages is a matter of deleting the lang/region and adding your own (en_PL?). Again, there's so many xmls in there that it's hard to know which one to use, so either make your own and delete the rest, or edit them all. I'll give you the batch that I use in my /customize, reading through them should help you understand what's going on with those xmls.
3.1) How about adding my own language? Is there a way I could do that to my ROM?
NOTE: Funny thing, the Android system is localized on my country's language when I first start the device but as soon as I change it to English, I cannot change it back to Portuguese cause that option doesn't exist. How come the device is in Portuguese when I first start it up after flashing a new ROM? This also happens every time I swap the SIM card, but I can never select Portuguese language by myself. Why?
Click to expand...
Click to collapse
Look above, it's because the language is obtained from the carrier and used during first boot, but it's not defined in an xml, so it's unavailable, make it available by adding it to the list.
4) I noticed that after flashing my custom ROM, after booting the device for the first time, the mobile network was active. This is not good... For now I have 1 month free of mobile networking but that won't last forever. I don't want to waste money every time I'm trying a new ROM. Is there anyway to disable this thing from automatically starting up connected when I first boot?
Click to expand...
Click to collapse
This I'm not sure about. You could try emptying your /system/etc/apns-conf.xml so that it won't be able to register to any data service (just leave the <apns version="x"> </apns> tags, remove everything in between).
Good luck.

jubeh said:
You're missing copy_dir PACKAGE:data DATA:, so you're really not writing /data/app even if it's on the package. If you read through the update-script, you'll see that it starts by formating BOOT: and SYSTEM: and later on writes the contents of /system to SYSTEM: (with copy_dir) and writes the raw boot.img to BOOT: (with write_raw_image).
Add the line to the very end of the permissions settings (but before format and write boot, most likely, before the show_progress line). You also need to set a specific permission after writing anything to /data/app from an update-script, otherwise your market won't be able to install anything (as you'll have changed the permissions for /data/app through the update-script).
Click to expand...
Click to collapse
That's what I thought but I'm still missing one thing...
The generic HTC "update.zip" has format: DATA for the last line of the update script, which I suppose will delete everything becuse the copy_dir command was executed before.
Should I not use the format data option? Won't that leave traces of a previous installation if I want to start clean? What's the recommendations or suggestions?
jubeh said:
It's safe to remove both, though the provider doesn't do much without the app, so it's also safe to leave it there.
Click to expand...
Click to collapse
What will happen to the data-sync when i tries to sync the data and finds the provider for gmail is not there? Will it simply be ignored? Will there be any errors changing any of the options (specially the gmail one) on the data synchronization settings?
jubeh said:
Hero roms take their settings from xml files in /system/customize. You'll see a bunch of xmls in there. Some are references to other xmls to be used (mns_map and cid_map), some are default settings (default.xml, COMMON.xml) and some are carrier specific settings (/CID/HTC_*.xml and /MNS/Lan_*.xml). The files are very redundant, and it's hard to tell which one is being used when, though, as a rule, you should understand that Hero loads a default from the /customize folder and then looks at mns_map and cid_map for the file to use inside /CID and /MNS. I'm not yet aware how it chooses the file, but, if you narrow down it's choices, then you can control which ones it uses and modify the settings there. If you crack open the xmls, you'll immediately see the languages defined in there (en_US, en_GB, etc), so removing languages is a matter of deleting the lang/region and adding your own (en_PL?). Again, there's so many xmls in there that it's hard to know which one to use, so either make your own and delete the rest, or edit them all. I'll give you the batch that I use in my /customize, reading through them should help you understand what's going on with those xmls.
Click to expand...
Click to collapse
I'm familiar with XML files and have no problems editing them but this whole thing was a little confused specially because there are no documentation and like you said, it's hard to tell which one is which.
I know you kinda suggested that but I'm no seeing how to do it (maybe with the file you attached?) but, how could I start clean, only have default XML files and nothing else, no carrier specific stuff, no bulk, just plain default settings that I can tweak to my own liking.
Any hints on how to do that, or it's hard to tell and you don't know how to do it either?
jubeh said:
This I'm not sure about. You could try emptying your /system/etc/apns-conf.xml so that it won't be able to register to any data service (just leave the <apns version="x"> </apns> tags, remove everything in between).
Click to expand...
Click to collapse
Unfortunately, this did not work

The generic HTC "update.zip" has format: DATA for the last line of the update script, which I suppose will delete everything becuse the copy_dir command was executed before.
Should I not use the format data option? Won't that leave traces of a previous installation if I want to start clean? What's the recommendations or suggestions?
Click to expand...
Click to collapse
I've never understood why the default update script does that, but yeah, format DATA: will erase userdata available. It might not be such a bad thing if you hadn't written anything to it before. For a wipe before install, move format DATA: (and, optionally, also add format CACHE: ) right after format SYSTEM: and before you start writing anything to disk. It should give you a clean install without having to wipe from the recovery menu.
What will happen to the data-sync when i tries to sync the data and finds the provider for gmail is not there? Will it simply be ignored? Will there be any errors changing any of the options (specially the gmail one) on the data synchronization settings?
Click to expand...
Click to collapse
I've not tried it yet. Worst case scenario, you'll get the current problem we have with eclair builds (sync will just keep running and eat out battery because it's looking for a service). That's why I'd suggest leaving gmail provider there, it's just a broadcast service, but without an app to receive the data, it'll do nothing. If your concern is data usage due to sync, then you should turn off gmail sync in settings, that way only calendar and contacts are synchronized (although you'll still be using data).
I'm familiar with XML files and have no problems editing them but this whole thing was a little confused specially because there are no documentation and like you said, it's hard to tell which one is which.
I know you kinda suggested that but I'm no seeing how to do it (maybe with the file you attached?) but, how could I start clean, only have default XML files and nothing else, no carrier specific stuff, no bulk, just plain default settings that I can tweak to my own liking.
Any hints on how to do that, or it's hard to tell and you don't know how to do it either?
Click to expand...
Click to collapse
The files I attached are pretty generic. It's meant to replace your /customize folder, not add to it, with the exception being /resources inside /customize, that one I use a lighter version (no footprints) but I didn't include it in the archive for size. I have no carrier stuff there, just settings for language (I think I made it all en_US, replace or add what you need) and layouts for the different scenes, some mail app behaviors (added back the Yahoo! mail and AOL mail options, I think), some footprint, stock, and weather information. Again, it's meant to replace your /customize directory and the smaller amount of files makes it way easier to edit.
Unfortunately, this did not work
Click to expand...
Click to collapse
Blame the xmls in /customize for that. I mentioned earlier I don't exactly know how the system picks which xmls to use, I think it looks at your carrier, which is then assigned a number (for example, let's assume T-Mobile is given number 238, so xmls with 238 on them will be loaded). Problem is inside those xmls are also apn settings (which I've removed from the files I provided so that the system looks instead for apn settings in apns-conf.xml in /etc).
You could flash your system erasing the whole /customize directory (and removing all mentions of it and it's sub-directories from the update-script so that install doesn't fail). Doing that will give you ALL languages available to the rom, but you'll also lose all your pre-loaded settings (like scenes, weather locations, footprints, stocks) and HTC Setup will take an ungodly amount of time to start (about 4-5 minutes after it's done dexopting) while it builds it's own default settings. It's another route you could take, though. Experiment and you'll eventually hit what you want/need.

OK, I guess I'll have to waste some time testing all this stuff, but I suppose I'll leave that to some other day and do more basic things for now.
But just to be sure, if I use your "customization" I'm basically starting from scratch (clean, defaults) and I can use the "old" customization stuff to understand how am I supposed to configured everything and adapt the clean customization folder to my needs. Right?
jubeh said:
You could flash your system erasing the whole /customize directory (and removing all mentions of it and it's sub-directories from the update-script so that install doesn't fail). Doing that will give you ALL languages available to the rom, but you'll also lose all your pre-loaded settings (like scenes, weather locations, footprints, stocks) and HTC Setup will take an ungodly amount of time to start (about 4-5 minutes after it's done dexopting) while it builds it's own default settings. It's another route you could take, though. Experiment and you'll eventually hit what you want/need.
Click to expand...
Click to collapse
This gave me an idea, dunno if it could work...
What if I did that, erase everything inside customize, let the system build its own default settings and then access that directory (through ADB maybe?) and see what the system has created. It should be much more cleaned, without all those carrier XMLs and stuff. Then I could start from there, what do you think?
I have a few more questions about the update-script if you don't mind, but I'm very tired to write them and discuss them now. I'll leave them for another day if you don't mind coming back here and help me out some more.
Thanks for all your help so far

I should probably have mentioned, some of the stuff on those xmls is pretty straightforward (setting language, region, weather, footprints, etc), but a lot of it (setting up default shortcuts, default widgets, system settings) requires working knowledge of android, or at least of how activities are handled and how xmls come into play and how android references the different activities in a package.
On a different note, the xmls are read-only configuration files, actually, anything in system is read-only data (program data, configuration data, resource data), so if you don't have a customize directory the system won't recreate it. What the system does do during normal boot (factory) is to take those carrier-specific settings and apply them to a file(s) in /data where configuration settings are ultimately written/re-written and accessed at will. The xmls are just a database of the settings that will ultimately get picked. When you don't have a /customize directory the system writes the settings straight to -rw enabled /data partition based on things like your current carrier, carrier provided information for locale, etc.
I don't think you can take what's written to /data and use it on a default install package, well, you could, but it's much easier (and a more correct approach) to learn how those xmls in /customize work.

jubeh said:
(...)but it's much easier (and a more correct approach) to learn how those xmls in /customize work.
Click to expand...
Click to collapse
I wouldn't mind doing that if there was some kind of documentation... As it is right now, it's too confusing and there are too many XMLs to begin with...
jubeh said:
I've not tried it yet. Worst case scenario, you'll get the current problem we have with eclair builds (sync will just keep running and eat out battery because it's looking for a service). That's why I'd suggest leaving gmail provider there, it's just a broadcast service, but without an app to receive the data, it'll do nothing. If your concern is data usage due to sync, then you should turn off gmail sync in settings, that way only calendar and contacts are synchronized (although you'll still be using data).
Click to expand...
Click to collapse
But if I leave the gmail provider there and do not turn off gmail sync in settings, my e-mail will still be synced right? There's just no Gmail app to view them but they are still going to be downloaded, correct?

Ok, I finally got a change to test the Gmail/GmailProvider thing and it didn't look like there any problems like trying to sync and draining the battery. Actually, if auto-sync was enabled, there was always a message saying the mail was never synced and no matter how many times you check/uncheck it, it wouldn't sync. If auto-sync was disabled, you could press the gmail button many times but nothing happened, no sync at all (of course).
I think this behavior is fine and I can safely delete the Gmail and provider from the phone without worrying that something will go wrong
Ok, now my other questions that I said I was going to post later...
As we talked about, you suggested to add a format data and cache right after a format to system. Comparing that to the MoDaCo ROM (and other ROMs too) it's common for them to, instead of formatting data, they do this:
Code:
delete DATA:app
delete DATA:init.sh
delete DATA:local
delete DATA:dalvik-cache
copy_dir PACKAGE:data DATA:
set_perm 1000 1000 0771 DATA:app
Why are they doing this? If they are not formatting, it means there's something inside data that they want to keep. Have any idea what and why?
The other question I had about the update-script is that the following two lines are found in the original HTC update but not on MoDaCo's:
Code:
symlink dumpstate SYSTEM:bin/bugreport
symlink dumpstate SYSTEM:bin/dumpcrash
Are they relevant somehow? Should I just ignore and leave them there or remove them just as MCR did, for some reason?
There's a file named build.prop inside the system folder. I've already searched countless times and can't find any proper documentation about this file... It seems it can hold various default properties for the system and it would be nice to know what I can configure there. Maybe I could workaround problem #4 (top of the topic) in this file? Maybe some file in the Android source has comments about the possible properties on this file? Do you have any idea?
One last thing...
I've read about odex and dex files but found it a little confusing... All I know is that original HTC updates come mostly with .apk files and a corresponding .odex file. But most (if not all) custom ROM's, do not have the .odex file but have a classes.dex inside the apk. What's the real difference between the two? And why custom ROMs prefer to have the .dex file instead of the .odex, is it better somehow for some reason? If so, what should I do to "change" the .odex files into classes.dex ones and put them inside the .apk files?

As we talked about, you suggested to add a format data and cache right after a format to system. Comparing that to the MoDaCo ROM (and other ROMs too) it's common for them to, instead of formatting data, they do this:
Code:
delete DATA:app
delete DATA:init.sh
delete DATA:local
delete DATA:dalvik-cache
copy_dir PACKAGE:data DATA:
set_perm 1000 1000 0771 DATA:app
Why are they doing this? If they are not formatting, it means there's something inside data that they want to keep. Have any idea what and why?
Click to expand...
Click to collapse
Yeah, I mentioned on the earlier post that doing "format DATA:" and "format CACHE:" would be the equivalent of running "Wipe data/factory reset" from the recovery menu since you mentioned about making a build that installs fresh. Paul's (MoDaCo) roms are no-wipe, so they preserve that program data and instead format all other directories inside /data that might be problematic during an upgrade; his roms use apps2sd, so he assumes that the user's downloaded apps are in mmcblk0p2 (the memory card's ext partition), so by formatting /data/app, he's only erasing the apps he included in his update package, if the user doesn't use a2sd, well, this erases their downloaded apps (one of the reasons I dislike the current a2sd implementation, it's not suited for all situations). Then he deletes data/init.sh, which is basically a script he includes in /data that runs during a rom's boot and starts things like a2sd, compcache, linux-swap, and other custom rom's "advanced" features. DATA:local is also app storage (I believe) and functions much like in windows' /users/x/application data/local, it can be problematic if not done between builds. Last, he erases /data/dalvik-cache, this is where the temporary application code resides (the extracted classes.dex from inside an apk) for rapid execution (for apks that haven't been pre-odexed). If you wish to make your rom no-wipe, add those lines instead of "format DATA:", but I'd remove "delete DATA:app" since it's a bit problematic for people who don't use a2sd.
The other question I had about the update-script is that the following two lines are found in the original HTC update but not on MoDaCo's:
Code:
symlink dumpstate SYSTEM:bin/bugreport
symlink dumpstate SYSTEM:bin/dumpcrash
Are they relevant somehow? Should I just ignore and leave them there or remove them just as MCR did, for some reason?
Click to expand...
Click to collapse
dumpstate is a debugging tool that android uses, but I don't know exactly where or how (I think it's an HTC-specific log for their HTCLog.apk). It contains two tools, dumpcrash and bugreport, much like toolbox is a binary that contains all the tools you see symlinked to it in update-script (bin, df, cp, mv, ls, insmod, etc.). It's not a problem at all if you remove it, but it's not a problem either to leave it there. Whenever something is symlinked, though (if it's something you added, for example, busybox tools), you have to make sure that the binary or a link to it or a previous symlink to it doesn't exist, otherwise your update-script will fail (like symlinking toolbox's insmod and then busybox's insmod, or busybox's ping if a ping binary already exists in the target symlink directory (for example /system/bin)).
There's a file named build.prop inside the system folder. I've already searched countless times and can't find any proper documentation about this file... It seems it can hold various default properties for the system and it would be nice to know what I can configure there. Maybe I could workaround problem #4 (top of the topic) in this file? Maybe some file in the Android source has comments about the possible properties on this file? Do you have any idea?
Click to expand...
Click to collapse
I guess that could work if you modify network type (there's a property somewhere in there about HSXPA, I think), but like you said, there's no documentation so it calls for some experimenting.
Those properties are also overrides, so, for example, if your rom doesn't do adb root (because ro.secure is set to 1 in init.rc), you can add ro.secure=0 in build.prop to enable adb root again.
Most properties are self explanatory, and pretty much, if you can't tell what it is, you probably shouldn't change it (for example, build.fingerprint allows you to change what kind of apps Market presents to you).
I'd say, don't mess around too much with the first batch (default build properties), with the exception of build.fingerprint.
One last thing...
I've read about odex and dex files but found it a little confusing... All I know is that original HTC updates come mostly with .apk files and a corresponding .odex file. But most (if not all) custom ROM's, do not have the .odex file but have a classes.dex inside the apk. What's the real difference between the two? And why custom ROMs prefer to have the .dex file instead of the .odex, is it better somehow for some reason? If so, what should I do to "change" the .odex files into classes.dex ones and put them inside the .apk files?
Click to expand...
Click to collapse
The classes.dex files is the dalvik bytecode for the application. It contains everything inside /appnamespace/src and /appnamespace/R if you're working from the source. It's basically all the java code already compiled for the dalvik virtual machine.
Dalvik doesn't do jit, so the classes.dex have to be extracted (if they're not already) and run through the virtual machine in a process called dexopt that produces code that can be much more rapidly excecuted by the dvm (dalvik virtual machine). The extracted code is then placed in /data/dalvik-cache (mentioned earlier) as [email protected]@[email protected]. All this pre-cached code eats away at your space in your /data partition (where you store your system data, like your email, messages, browser cache, and downloaded applications) and can be quite a big chunk of space gone (framework classes specially, since all jars inside /system/framework are nothing but java code, about 20MB for all framework code).
The solution to prevent usage of /data storage on an initial build is to have the code pre-extracted. This is done at compile-time running the created system through an emulator and then creating the odex files, which is almost exactly the same as the *@classes.dex found inside /data/dalvik-cache except that it's much better aligned to the device's memory configuration and offers (marginally) better excecution, plus when the package manager first encounters the apk, it's first step is to check if an .odex of it is available, if it is, then it skips checking and dexopting a classes.dex inside it and proceeds to the next package.
Odex files increase the space in your /system partition (it was already read-only, so it's not like you're missing out on something) so those 20 MB of framework that would have been tossed into your userdata partition are now out of the way into the useless (in an available-storage sense) /system partition so you have more free space for your apps.
There's a tool that can create odex files for apks that don't have them, it's called dexopt-wrapper and it has to be run from a running phone. However, this tool won't strip the (now unnecessary) classes.dex from inside an apk, so it has to be done manually. Removing the classes.dex once you've created an odex is a good idea merely on the basis of space savings. However, once a classes.dex has been odexed, it's very hard (used to be impossible) to turn it back to a classes.dex and place it inside an apk.
Usually, us rom cooks preffer the classes.dex inside the apk because odexes create conflicts when you try to mix and match apps between builds. Since the odex files are tied to the framework where they were created, adding an apk with it's odex to another framework (even one that's only ever-so-slightly different) will be very problematic (the odex code is no longer protected or verified, so the rom won't even boot because it will fail verification for all available packages).
The tool for reverting odex files is called deodexerant by jesus freke. It requires working knowledge of how the system goes through the dexopting process so you can run it in the proper order.
Another thing to know is that even if your /system is pre-odexed, your downloaded apps will still be run through the package manager and have their classes.dex dexopted and placed in /data/dalvik-cache.
Oh, and never, ever put odexes anywhere but /system/framework or /system/app (or /data/app_s if you use a2sd). The package manager currently can't handle odexes in /data/app or /data/app_private (the other two locations where it looks for packages other than /system/app).
In the end, whether to use/have odexes comes down to personal choice (and available space). There's two hero builds, those based in 2.73.405.61 and 2.73.405.66, that have not been pre-odexed, so they're perfect for experimenting, mix/matching, etc...

jubeh said:
Yeah, I mentioned on the earlier post that doing "format DATA:" and "format CACHE:" would be the equivalent of running "Wipe data/factory reset" from the recovery menu since you mentioned about making a build that installs fresh. Paul's (MoDaCo) roms are no-wipe, so they preserve that program data and instead format all other directories inside /data that might be problematic during an upgrade; his roms use apps2sd, so he assumes that the user's downloaded apps are in mmcblk0p2 (the memory card's ext partition), so by formatting /data/app, he's only erasing the apps he included in his update package, if the user doesn't use a2sd, well, this erases their downloaded apps (one of the reasons I dislike the current a2sd implementation, it's not suited for all situations). Then he deletes data/init.sh, which is basically a script he includes in /data that runs during a rom's boot and starts things like a2sd, compcache, linux-swap, and other custom rom's "advanced" features. DATA:local is also app storage (I believe) and functions much like in windows' /users/x/application data/local, it can be problematic if not done between builds. Last, he erases /data/dalvik-cache, this is where the temporary application code resides (the extracted classes.dex from inside an apk) for rapid execution (for apks that haven't been pre-odexed). If you wish to make your rom no-wipe, add those lines instead of "format DATA:", but I'd remove "delete DATA:app" since it's a bit problematic for people who don't use a2sd.
Click to expand...
Click to collapse
So, to make it clear, I could:
Option A) Add format DATA and format CACHE to my ROM and this would make my ROM to automatically wipe everything and start clean.
Option B) I could not add anything (no formats and no deletes) and warn the users to explicitly perform a wipe before flashing.
Option C) Add delete DATA:local and DATA:dalvik-cache and have a no-wipe ROM where the apps would be preserved from the last ROM, right?
Ok, I don't use a2sd and for now have no intention in doing so. My best guess is to start with option A for now and maybe opt by using some app to backup everything and restore everything back after flashing a wipe ROM. Or I could go with option C and everything could work fine but there's a chance I could run into some issues in the long run.
jubeh said:
The classes.dex files is the dalvik bytecode for the application. It contains everything inside /appnamespace/src and /appnamespace/R if you're working from the source. It's basically all the java code already compiled for the dalvik virtual machine.
Dalvik doesn't do jit, so the classes.dex have to be extracted (if they're not already) and run through the virtual machine in a process called dexopt that produces code that can be much more rapidly excecuted by the dvm (dalvik virtual machine). The extracted code is then placed in /data/dalvik-cache (mentioned earlier) as [email protected]@[email protected]. All this pre-cached code eats away at your space in your /data partition (where you store your system data, like your email, messages, browser cache, and downloaded applications) and can be quite a big chunk of space gone (framework classes specially, since all jars inside /system/framework are nothing but java code, about 20MB for all framework code).
The solution to prevent usage of /data storage on an initial build is to have the code pre-extracted. This is done at compile-time running the created system through an emulator and then creating the odex files, which is almost exactly the same as the *@classes.dex found inside /data/dalvik-cache except that it's much better aligned to the device's memory configuration and offers (marginally) better excecution, plus when the package manager first encounters the apk, it's first step is to check if an .odex of it is available, if it is, then it skips checking and dexopting a classes.dex inside it and proceeds to the next package.
Odex files increase the space in your /system partition (it was already read-only, so it's not like you're missing out on something) so those 20 MB of framework that would have been tossed into your userdata partition are now out of the way into the useless (in an available-storage sense) /system partition so you have more free space for your apps.
There's a tool that can create odex files for apks that don't have them, it's called dexopt-wrapper and it has to be run from a running phone. However, this tool won't strip the (now unnecessary) classes.dex from inside an apk, so it has to be done manually. Removing the classes.dex once you've created an odex is a good idea merely on the basis of space savings. However, once a classes.dex has been odexed, it's very hard (used to be impossible) to turn it back to a classes.dex and place it inside an apk.
Usually, us rom cooks preffer the classes.dex inside the apk because odexes create conflicts when you try to mix and match apps between builds. Since the odex files are tied to the framework where they were created, adding an apk with it's odex to another framework (even one that's only ever-so-slightly different) will be very problematic (the odex code is no longer protected or verified, so the rom won't even boot because it will fail verification for all available packages).
The tool for reverting odex files is called deodexerant by jesus freke. It requires working knowledge of how the system goes through the dexopting process so you can run it in the proper order.
Another thing to know is that even if your /system is pre-odexed, your downloaded apps will still be run through the package manager and have their classes.dex dexopted and placed in /data/dalvik-cache.
Oh, and never, ever put odexes anywhere but /system/framework or /system/app (or /data/app_s if you use a2sd). The package manager currently can't handle odexes in /data/app or /data/app_private (the other two locations where it looks for packages other than /system/app).
In the end, whether to use/have odexes comes down to personal choice (and available space). There's two hero builds, those based in 2.73.405.61 and 2.73.405.66, that have not been pre-odexed, so they're perfect for experimenting, mix/matching, etc...
Click to expand...
Click to collapse
Well, I'm currently basing my ROM on 2.73.405.38 as the .66 one has "test" on the name and it feels like a beta version, which I'd rather not use. The .38 version uses .odex files for most of the packages (only a few has classes.dex inside) and I guess I'll leave them like that. If future ROMs, like that .66 one, comes with classes.dex vs .odex files, well, then I'll just leave it like that...
That looks like a very important thing in Android apps and at the same time something that I should be very knowledgeable about before messing with it, so I'll just stay put
Thanks once again for taking your time with such complete answers

So, to make it clear, I could:
Option A) Add format DATA and format CACHE to my ROM and this would make my ROM to automatically wipe everything and start clean.
Option B) I could not add anything (no formats and no deletes) and warn the users to explicitly perform a wipe before flashing.
Option C) Add delete DATA:local and DATA:dalvik-cache and have a no-wipe ROM where the apps would be preserved from the last ROM, right?
Ok, I don't use a2sd and for now have no intention in doing so. My best guess is to start with option A for now and maybe opt by using some app to backup everything and restore everything back after flashing a wipe ROM. Or I could go with option C and everything could work fine but there's a chance I could run into some issues in the long run.
Click to expand...
Click to collapse
Sounds like you got it.
Well, I'm currently basing my ROM on 2.73.405.38 as the .66 one has "test" on the name and it feels like a beta version, which I'd rather not use. The .38 version uses .odex files for most of the packages (only a few has classes.dex inside) and I guess I'll leave them like that. If future ROMs, like that .66 one, comes with classes.dex vs .odex files, well, then I'll just leave it like that...
That looks like a very important thing in Android apps and at the same time something that I should be very knowledgeable about before messing with it, so I'll just stay put
Click to expand...
Click to collapse
Test only refers to the build being signed with test-keys instead of release-keys. In my testing, it makes no difference whatsoever for a rooted user, and there's many theories floating around about signatures, I haven't researched signatures a whole lot because test-keys have worked fine enough for me, so I'm not so sure, but they seem to be working fine for all.
The reason those releases are un-odexed (and signed with test-keys) is because of the problem with odexes I mentioned earlier. When HTC is testing their rom packages and they need to make, say, a framework change, all the apps with odexes would fail as the framework has changed, so, for testing purposes, it's best to leave the apks and jars in the build full (with classes.dex inside). Once you know your build is solid and you won't be changing much, it's safer to odex the whole thing (sort of like me, I'm waiting for the final release of eclair for ADP1 so I can put out a Dream rom odexed and fully working).
Thanks once again for taking your time with such complete answers
Click to expand...
Click to collapse
No problem, I get bored at work

So, version .66 is not beta or anything? I know MoDaCo has his latest ROM based on that and you're saying they are only different in the signing key, still, it's somewhat a "leaked" build, not quite "official".
But hey, if others are using it without any issues, maybe I should be using it too

On second thought...
1) I can't find a pre-rooted .66 version and I don't know how to root it :/
2) There's lots of files in system/xbin that I don't see referenced anywhere (not even in the update-script) and I don't know what should I do with them.
I'm finding it much more confusing to base my ROM on .66 than on .38...

It is a beta, of sorts, but between it and the final shipping product there's not much difference. It's just much, much easier to work with it.
1.) The simplest form of root is to change ro.sercure to 0 in default.prop in the boot ramdisk. Adding a su binary/Superuser.apk is optional, those you can pull from one of paul's builds.
2.) The system/xbin is added to the boot classpath in the boot ramdisk in init.rc. The only mention of it in in update-script is the permissions for the whole folder and then just a couple permissions for some tools, not all of them.

"Fixed" build.prop file for Kaiser (Attached tarball)

!ALWAYS make a databackup.img on your device BEFORE making any changes!
Hi all!
For the past 3 weeks I have been making small changes to the build prop file inside the Android /system folder.
These changes incorporate not only a increase in speed but also stability.
What I would like to see happen is one of 2 things, or both if possible.
1. Incorporate this build.prop file into the various "System_Froyo" builds available, forcing these changes on initial install, or
2. Vogue/Polaris developers browse the file for contradicting information (things that won't work on a Vogue/Polaris) and make appropriate changes.
Improvements include:
ro.ril.disable.power.collapse (prevents sleep of death),
various dalvik vm improvements,
force hardware acceleration and performance tuning,
various telephony enhancements including ring delay time and data speeds.
After making these changes, the phone rings immediately, the UI is much smoother (GUI uses video processor primarily), and data jumped from 1.3Mb/sec to over 3.2Mb/sec, making web pages load faster. (EDIT: The 3.2Mb/sec is the top of the scale, I actually averaged 2.2Mb/sec with average pings between 300-500 across 3 different radio roms).
VOGUE/POLARIS OWNERS!
Please test this file and report findings here.
IF you find you need to remove any lines, please do so before copying the file into /system. This file works well on the AT&T networks (Cingular), but may not have much effect on other networks.
If you have trouble after installing this file, please post your bootlog file.
PoX

So may I know what rom support this?

This has only been tested on a "clean" Froyo build, so I cannot make any assumptions as to if it will work in Gingerbread/Eclair/Donut/etc.
If everyone follows the install guide on the front page, I would assume that it would work worldwide, as long as it's Froyo.
In the future I could try it out on Gingerbread and other builds, but I make no promises as development has all but ended for Android on MSM72**.

I can test this. Perhaps, kaiser on Android could be good for daily use?...
Thanks for sharing

PoXFreak said:
Hi all!
For the past 2 weeks I have been making small changes to the build prop file inside the Android /system folder.
These changes incorporate not only a increase in speed but also stability.
What I would like to see happen is one of 2 things, or both if possible.
1. Incorporate this build.prop file into the various "System_Froyo" builds available, forcing these changes on initial install, or
2. Vogue/Polaris developers browse the file for contradicting information (things that won't work on a Vogue/Polaris) and make appropriate changes.
Improvements include:
ro.ril.disable.power.collapse (prevents sleep of death),
various dalvik vm improvements,
force hardware acceleration and performance tuning,
various telephony enhancements including ring delay time and data speeds.
After making these changes, the phone rings immediately, the UI is much smoother (GUI uses video processor primarily), and data jumped from 1.3Mb/sec to over 3.2Mb/sec, making web pages load faster.
If there is interest in this, please respond to this post. If there is enough interest I will attach it to this post as a .tar file.
Click to expand...
Click to collapse
PoXFreak said:
This has only been tested on a "clean" Froyo build, so I cannot make any assumptions as to if it will work in Gingerbread/Eclair/Donut/etc.
If everyone follows the install guide on the front page, I would assume that it would work worldwide, as long as it's Froyo.
In the future I could try it out on Gingerbread and other builds, but I make no promises as development has all but ended for Android on MSM72k.
Click to expand...
Click to collapse
I'm interested in your new build.prop tar, but I do not understand the thing about the install guide, you mentioned in you second post.
My Kaiser is running CM7 RC3 on haret, so maybe I can do some testing on gingerbread, with you.
Your trials, about tweaking the app download possibility, sound very interesting too, as I read about a tweaked build.prop for a tab that simulates to be a samsung tab in combination with an older version of the app market.
Feel free to PM, although I'm quite a newby to android.

I can build with Fresh Froyo and try it, but not until April sorry.
I am currently traveling and away from a development system.
I have been slowly trying to get a reliable app2sd capability working.
I'd suggest searching old posts for power collapse to see if dzo or others long ago tried this.
It sounds promising.

muckelmaus said:
I'm interested in your new build.prop tar, but I do not understand the thing about the install guide, you mentioned in you second post.
My Kaiser is running CM7 RC3 on haret, so maybe I can do some testing on gingerbread, with you.
Your trials, about tweaking the app download possibility, sound very interesting too, as I read about a tweaked build.prop for a tab that simulates to be a samsung tab in combination with an older version of the app market.
Feel free to PM, although I'm quite a newby to android.
Click to expand...
Click to collapse
The "install guide" I'm referring to is here...
How to replace Windows Mobile with Android (Guide)
There would be a change to the original build.prop file which exists inside the /system folder and would be installed when Android is installed on the Kaiser.
Mind you, I live in a busy city with LOTS of cell towers and, since 3g works on the principle of multi-tower usage, YMMV. If you live way out in the country with maybe 2-3 towers nearby, this may not help you.
Also, this has been tested on a NAND-installed OS, not a HaRet install. I cannot verify or guarantee this will work with a HaReT install as I have no way to test it and I think of HaReT as the "slow cousin" to a NAND install.
On a side note: My Kaiser has not had one sleep of death, hard-lock, white screen or even an FC for 9 days now. Apps running out of memory can be a slight problem but they will just close on their own as opposed to FC-ing. at worst I've had one hot reboot called by the system, and the FCs' are few, even with heavy Facebook and Maps use.
n2, if this works on all Kaisers, is there a way to push it to SF and either add it as a mod or rebuild the "system_froyo" install files and incorporate it within?

I will try in early April. Until then please solicit Vogue and Polaris users to try it.
Sent from my Nexus One using XDA

I am interested and willing to try this out!

Where is your " "Fixed" build.prop file for Kaiser "?

Tarball added to OP, please test and report back. Any problems should be reported here along with the bootlog from your phone.

Hi guys!
Problem occured when moving file to root folder. To solve I tried root explorer and z4root both. CM7 + Krazy-Killa's Kernel on tilt 8925.
Please talk what to do with it!
thanks!

Rename original build.prop file to "build.prop.old" or something you will remember, without the quotes, then paste the new build.prop file into the /system folder... it should go right in with no errors, unless you try it without read/write abilities.
CM7 may already have some of these fixes installed in the existing build.prop file. To check, open this build.prop with a text editor and check the entries under "additional build properties".

n2rjt said:
I will try in early April. Until then please solicit Vogue and Polaris users to try it.
Sent from my Nexus One using XDA
Click to expand...
Click to collapse
Vogue/Polaris users solicited, although I'm not sure if this can be used on a CDMA network. Last count shows about 15-20% of the "other" phones were Vogues, the rest were Polaris users.
It would be nice to start getting good feedback since this would be my first actual "hard" mod (one that is installed with the system, not modded through some other installer/program).

PoXFreak said:
Rename original build.prop file to "build.prop.old" or something you will remember, without the quotes, then paste the new build.prop file into the /system folder... it should go right in with no errors, unless you try it without read/write abilities.
CM7 may already have some of these fixes installed in the existing build.prop file. To check, open this build.prop with a text editor and check the entries under "additional build properties".
Click to expand...
Click to collapse
Can't rename. And can't change file attributions read only to read/write.

ZLodei said:
Can't rename. And can't change file attributions read only to read/write.
Click to expand...
Click to collapse
You probably need to remount /system read/write. I just wish I could remember how. Been a long time since I put my vogue down.

If you can get terminal emulator up on that phone, I believe all you would have to do is type in "su" then "mount /system".
All Kaiser/Polaris/Vogue Android builds are rooted and usually have superuser installed. I will take a look into Scoot's CM7 and confirm this. I know there is an update to superuser that leaves the old binary unable to be updated.

PoXFreak said:
If you can get terminal emulator up on that phone, I believe all you would have to do is type in "su" then "mount /system".
All Kaiser/Polaris/Vogue Android builds are rooted and usually have superuser installed. I will take a look into Scoot's CM7 and confirm this. I know there is an update to superuser that leaves the old binary unable to be updated.
Click to expand...
Click to collapse
Hi! Thank you!
What does exactly I have to do in terminal emulator?

I would hope you have superuser capability, if you don't then use another build that does have them...
Anyway, this is all I could figure out to remount the /system as RW. Type the following below into terminal emulator...
mount -o rw,remount -t yaffs2 /dev/block/mtdblock2 /system
(Where "mtdblock2" has /system, "mtdblock3" has /data, and "mtdblock4" has /cache.)
Hope this helps...

Please correct me if i'm wrong.
I installed this new build.prop from the bootloader using androidupdate.tar.
Because i made a tar archive this way: system/build.prop
Isn't it the easiest method? No mounting and hacking in terminal emulator.
Anyway, do anybody know which ROM contains hungarian language? I gave my Kaiser to my father and it would be great if he could use it in hungarian.
I thought VaniljEclair 11 has it, and it is almost true. It has hungarian language but when i set it nothing happens. Everything is in english as before.
Thanks!
Edit:
You can download it from here:
http://mattempus.sohasenem.hu/pub/androidupdate.tar

[Q] Specific "bugs" when modifying ICS-based ROM ZIPs

Hi, I've always liked to modify ROM ZIPs by just opening them, and then deleting the stuff I had no interest in (say, for example, DownloadProviderUi.apk), and doing that has always worked just fine after installing it (talking about Eclair and Froyo).
However, since the release of GB/ICS based ROMs, if I go as far as to modify just one file - even simply replacing the bootanimation.zip contained within the ROM ZIP, after it has been installed and rebooted, there's no lockscreen (deactivating and activating it again does nothing) and the HOME button doesn't work - it acknowledges that it's being pressed, but it simply doesn't do anything at all (return and recent do) - trying to change its default behaviour has no effect at all. As far as I'm aware, the problem spans across multiple (all I have tested) GB/ICS ROMs and a few different and completely unrelated (different brand) Android devices.
Also, installing those same ZIPs without making any modifications keeps any issues from ever happening.
I'm aware that they can be removed using ADB after it has been installed, using Root Explorer to mount /system as RW and deleting them manually, using Titanium Backup to freeze or remove, etc...
I'm mostly interested in having some light shed on the above issue. -Why- do those ROMs always fail if the ZIP file is modified in any way? Is there no way around it?
Thanks for taking the time to read
EDIT: Just in case, I've already tried searching for information regarding these problems, and other than unanswered to and very scarce comments, I've been unable to find anything revealing in any way - I'd appreciate if someone could point me in the right direction if there's something I've missed.

Are you signing your apks before trying to install them?

The APKs..? I'm guessing you meant the ZIP - if so, no. I could give that a try later and see how it goes...

No, I meant apks, but only because I've had an experience nearly exactly like the one you're describing and it was from trying to package the rom with an unsigned apk.

Ah. Well, I guess if I tried adding an APK it'd happen as well - my issue is I want to edit the updater-script (extract, edit with notepad++, throw it back in...) and/or remove APKs (for example, I have no interest in /system/app/DownloadProviderUi.apk). Like, fire up winrar or 7zip (tried with both), browse to the file, delete, then copy it over the to device and install the ROM - the bug always shows up.
Uncompressing the entire ROM, modifying away and then creating a new ZIP makes no difference, either...
EDIT: No dice - I've taken Hashcode's latest ROM, just for reference:
Untouched ZIP works flawlessly.
Modified unsigned ZIP doesn't have a lockscreen and the Home button doesn't respond when pressed (though it acknowledges being pressed).
Modified signed ZIP does exactly the same as the unsigned one.

[DEBLOAT] [OOS, Customs] Tomatot Debloater 4.1 (+++Battery, RAM, Privacy)

Hello guys,
Introduction
Today is my first step in the android development world. And I'm starting with something very little. I've created this tool for myself but I thought I could share it, as it could be useful to you as well and you could help me to improve it.
Big announcements
1) Officially supported custom ROMs:
-OmniRom
-LiquidRemix
-Skydragon
-ArrowOS
-AEX
What can you expect from flashing my script?
I think my script is interesting because its utility is completely complementary with a custom ROM or kernel: what it does has nothing to do with the kernel, so it doesn't interfere at all. And it's concrete stuff, not some supposed-to-be optimization where you're not even sure it's going to do something. I'm usually not a huge fan of these apps / modules.
-You'll get more privacy: I've removed Qualcomm telemetry, OnePlus telemetry as well as some Google Telemetry (but you can't expect too much as long as you use gapps)
-You'll get better battery life: less apps running in the background, less wakelocks, less services communicating with servers to send telemetry.
-You'll get better performance: for the same reasons. Don't expect a huge difference as our phone is very smooth already.
-The feeling of having a clean device. And this has no price.
As a proof, see this (both screenshots were taken after a fresh boot):
Extreme script:
https://imgur.com/2O47su8
19 system apps running, for a total of of 31 services running. I'm not counting Google Play services as the number of services running keep changing.
No script:
https://imgur.com/E5cEr7P
36 apps running, for a total of 60 services running! I find the difference quite huge.
What does it do?
The point is to be very very basic. Obviously I don't intend to to share something as powerful and exhaustive as xXx. My objective is to only focus on bloatwares, not features.
Also, I wanted to make a script simple enough so anybody can use it, understand it and modify it depending on your needs.
I think I can call myself a flasholoic, as I flash ROMs quite often, even when I'm happy with the current one. There are many time consuming and boring tasks when it comes to clean flash a new ROM. However, for most of them, there's a solution. For example, Titanium Backup, to mention just one.
With this script, you'll be able to skip the very boring process of removing/freezing all the system apps you don't use.
You can use this script with no worries whenever you flash your new ROM.
Why don't i Freeze apps instead of removing them?
Ideally, I would prefer to only freeze apps so the setup can stick after an update or a dirty flash, however, I don't know how to do it from recovery. Freezing works with the command from package manager "pm disable {package_name}", however, it's only available when the phone is running.
What version should I install?
-Invisible script: Install it, enjoy. I basically removed only apps related to telemetry or that don't have any function. You should still have all the apps you're using and all the features you like.
-Light Script: Invisible + apps that I consider rarely use (because they're useless or because alternatives are much popular). It should fit to 80% people without any change to make.
-Extreme script: Invisible + light + a few Google Apps (most of them can be reinstalled) and features that are not absolutely necessary but useful for some people, like face unlock for example. I wouldn't recommend it to anyone who hasn't check the .txt file first. The light script is almost as good anyway.
How to Install?
Simply reboot to TWRP, flash the zip, reboot and enjoy.
If this doesn't work, you can try three different things:
-Try to use blu spark Recovery instead of other ones.
-Try to mount system in recovery before flashing my .zip.
-Try to install Magisk and this module: https://github.com/Magisk-Modules-Repo/busybox-ndk
-Try to install the script on both slots
At least one of these options should fix things for you.
Known incompatibilities
-If the script doesn't do anything, check installing instructions.
-If an app keeps force closing when you try to open it (for example the Google app, gmail, amazon, etc.), it's because you don't have any webview selected. You can select one in the developer settings and if you don't have any you can install one from the play store (Android System Webview).
-If some apps are remaining, it's because it's system apps you updated and they became user apps. You can just uninstall them like any other user apps and it will completely disappear.
-If an app that is included in the script freezes, but it's also available in the playstore, uninstall it with Titanium Backup, reboot and reinstall the app from play store.
-If you're using substratum, you must edit my script and remove this line: "/system/system/app/OpSkin",
-If your bank app doesn't work, you can try to add back Stk (sim toolkit), as the app helps for authentication.
-In general, search this thread if you want more details / understand why.
F.A.Q.
-I don't want to use this debloater anymore or it broke something I miss, how can I go back to normal?
=> Dirty flash your current setup (ROM, twrp, reboot to twrp, magisk, kernel, anything else you want)
-Does this script work for X or Y ROM? Can you make a debloater for X or Y ROM?
=> If you understand how my tool work, then you will understand that my scripts can potentially work on any ROMs, but each ROM has its specific apps so some bloatware won't be removed, most likely. I won't support any new ROM except if I end up trying it myself. I prefer to avoid to create new scripts blindly especially if I've never experienced the ROM.
-I flashed your deblaoter and now some apps keep force closing
=> "If an app keeps force closing when you try to open it (for example the Google app, gmail, amazon, etc.), it's because you don't have any webview selected. You can select one in the developer settings and if you don't have any you can install one from the play store (Android System Webview)."
Where can I get more info?
Check the .txt file in the download section. It lists all the apps included in the different scripts AND all the apps not included (so you can see what apps you want to potentially add, it's much easier to work like that)
How are the apps sorted in the .txt file?
-First, by categories (each category starting with #) (invisible, light, extreme, etc.)
-Then, they're sorted by their type (reserve / app / priv-app / other)
-Then, simply by alphabetic order.
-At the end of the document file, there are some explanations about some apps that can sound... mysterious about whether it's safe or not to delete them.
How to edit the script and make it work? (TUTORIAL)
Prerequisites
-Root (ideal but not mandatory)
-File manager (ideal but not mandatory, I recommend Amaze https://play.google.com/store/apps/details?id=com.amaze.filemanager&hl=en_AU )
-TWRP
Then you have two alternatives
a) Use your computer (Windows): you will need Zip Builder https://forum.xda-developers.com/an...g/tool-zip-builder-v4-2-1-build-sign-t3739556
b) Use your phone: then you will need MiXplorer ( https://forum.xda-developers.com/showthread.php?t=1523691 )
Steps to follow
1) Download my script.
2) Unzip it. Browse to META-INF\com\google\android and open "updater-script" in a notepad. (I'd recommend you notepad++ ( https://notepad-plus-plus.org/download/ )
3) Add some apps you want to delete, or remove the apps you want to keep. To see what apps are on your device, use a file manager that can use root and check the apps you have in /system/app and system/priv-app. The priv-app are usually more sensitive so be cautious with them.
4) Don't forget that on every line, you need a comma at the end, except for the last app of the list.
5) You don't need to touch any other lines, except if you want to have fun and change what TWRP will display: it's the lines with
Code:
ui_print("")
6) Save your file.
7) a) Windows alternative. Follow instructions to install properly Zip Builder. Then shift + right click on the parent folder of the META-INF folder and click on "Build Zip...". If Zip Builder is set up properly, you will see the option I just mentioned. You can also open the program and browse to the parent folder where META-INF is.
Copy the .zip to your phone and you're good to go!
7) b) Android alternative: Install MiXplorer. Long press on the META-INF folder. Confirm the creation of the archive, pick the name you want and make sure that "store" is selected, below "zip". Then select the newly created zip, and click on the "Sign" option. Choose Testkey. It will create yourzip-signed.zip. That's the file you need to flash in TWRP.
8) Flash in TWRP
Let me know if you need any help or if something is not clear to you.
Downloads, risks, credits, Information
Where to download?
Check the attachments!
What are the risks, or why is it actually pretty safe to use it?
1) If you use my scripts, as I've tried all builds, I can assure you in the worst scenario you will loose a few features you might have wanted to keep.
2) If you try to make your own script:
a) You misspell a system folder: (it's case sensitive, careful): well the script will just ignore it and try to remove a folder which doesn't exist, so no consequence at all, just a useless line in your script.
b) you mess up with how you're meant to write the script: for example, you forget a comma or you leave it on the line of the last app you want to delete. Well, no worries, TWRP will just not flash the script so nothing happens. Just check your code to find the mistake.
c) Your script is fine but delete a core app that the system needs. Again, no worries! You will bootloop. In this case, you need to dirty flash your current setup (for example, flash OOS, flash TWRP, reboot to recovery, flash Magisk, flash your favorite kernel, reboot). Then you can try to find the culprit in your code, remove it, and try again your script.
Just in case, you know the XDA saying: "flash at your own risk!"
Credits!
First of all, I'd like to credit @Primokorn for his tutorial which helped me a lot. Basically everything in my script I owe him. I've just made it even more simple and focused on only debloating. Also, and obviously, it's adapted for our OnePlus 6. Right now, it's optimized for OOS 9.0.3, but depending on how the project evolves and how popular it will get, I could make "special editions" for open betas as well as AOSP ROMs.
I would also like to thank @TKruzze for his amazing tool "Zip Builder", which makes me save a lot of time everytime I want to try / build a new script.
Thanks to @Zios01 for inspiring me about "optimizing" OOS.
Information
"Tomatot- Debloater"
Contributors
@Tomatot-
Source Code: everything is in the zip.
Created 2018-11-20
Last Updated 2019-12-23

Changelog
Tomatot Debloater 4.1 for OOS
-REMOVED FROM THE SCRIPT:
Light:
TeleService (necessary for some operators)
Extreme:
SdCardService (necessary for file managers)
ModuleMetadataGooglePrebuilt (necesary for permissions)
Tomatot Debloater 4.0 for OOS
REMOVED/CHANGED :
- All folders (and there are lots of them) that don't exist anymore (usually they got moved to another path)
ADDED
- "/data/india/india.img"; (let me know if it works)
- A few new apps that are most likely useless.
Previous updates:
Tomatot Debloater 3.3
-All apps in /reserve are now deleted in the invisible script. If new apps are added by OP, they'll be automatically deleted as I added the whole folder (you can check the script to understand). Thanks to @nirogu325 for the idea!
-Moved DiracManager to the light script since some people like using it.
-Added OPWidget, it seems to be a new app added by OP
-Added OPWallpaperResources to the extreme script as I'm not sure what it does
-Removed OPSimContacts since it breaks the OP phone app.
Tomatot Debloater 3.2
-Added amazon apps hidden in /vendor/etc/apps
-Removed Rftoolkit on the Omni script
Thanks to @bojiokia and @nirogu325 for pointing me out they existed and that they were on all devices.
Tomatot Debloater 3.1.1
Thanks to @nirogu325 for his help to figure out how to mount /vendor and how to remove Rftoolkit properly
Removed also a folder that doesn't exist (LiveWallpapers)
Tomatot Debloater 3.1
I have decided to only use " run_program("/sbin/mount", "/system"); " to mount system from now on. It seems to be the most reliable / universal way to do so.
The Omni update has no change except I switched to the new mounting way.
### New entries for Invisible Script
OPCommonLogTool
Traceur
Rftoolkit
### New entries for Light Script
ARCore_stub
CarrierDefaultApp
CtsShimPrebuilt
CtsShimPrivPrebuilt
### New entries for Extreme Script
LiveWallpapersPicker
LiveWallpapers
OPSafe
SdCardService
uimremoteclient
WAPPushManager
DocumentsUI
IFAAService
OnePlusGallery
VpnDialogs
Tomatot Debloater 3.0
-All main scripts that are up to date are now 3.0 for a purpose of clarity.
-Except the LiquidRemix script, no apps have been added/removed from the scripts.
-Omni/Liquid/Skydragon have a similar level of debloating.
-Since a lot of users reported issues of the script not working, I figured out it was because for some reasons some recoveries don't execute busybox commands properly. I switched to edify commands. The main benefit is that it should work for everyone 100% of the time. The disadvantage is that it won't work for other devices. It might be the same path for the 6T but I need people to check. For other devices it won't work 100%. What you can try however, is to mount system before flashing. It should make the script work.
OOS 2.5.2
-Removed DeskClock as it's the clock app that a lot of people need. I thought it was the widget, my bad.
OOS 2.5.1
-Removed WebViewStub from all scripts since it may affect the webview selecting setting.
OOS 2.5
-Added BluetoothMidiService to the extreme script because 99% people won't use it (check Google to check what it is)
-Added ProxyHandler for the same reason
-Added ManagedProvisioning for the same reason, in the light script. ( Work Profile Setup apk. It's useless for most people. Obviously don't delete it if your company gave you this phone, but then you shouldn't flash it in the first place! )
OOS 2.4
-Removed a few useless lines in the script.
-Cleaned up the .txt file, now all packages explained are sorted alphabetically.
-Moved CNEService to the extreme script as it breaks wifi calls.
-Moved HotwordEnrollmentXGoogleWCD9340 to the extreme script as it might break OK Google.
-Moved WebViewStub to the invisible script
-Added YouTube to the light script as it doesn't break YT Vanced.
-Added Chrome to the extreme script. Don't forget to have a working/activated webview!
OOS 2.3
HotwordEnrollmentXGoogleWCD9340 : moved to extreme as it breaks ok google
EmergencyInfo : moved to extreme as it could break double press power button to open camera
datastatusnotification : moved to extreme as it allows the system to cap data.
Added DeskClock to the light script
Added WebViewStub to the light script
OOS 2.2.1 / custom 1.2
-Unified numbers for all OOS sripts / all custom ROMs scripts so it's just easier to follow / maintain.
-OOS: moved OPBackup to the extreme script as it breaks system updates. It doesn't matter since if you have Magisk and TWRP you can't update via OTA but some people like having all settings working so... Now with the light script you shouldn't have any "broken" feature.
-Custom: removed DocumentsUI so it's possible to access external storage.
v2.2
-Removed Chrome from the script as it can break webview. There is not reliable fix as Android system struggles to properly select "Android System Webview". Feel free to freeze or uninstall Chrome as long as you update android system webview and make sure it's selected in developer settings.
-Put back Gmail2 in the script as now installing it as a user app shouldn't break the app anymore.
-Now the script should be completely bug free.
-if you had issues with gmail, dirty flash your current setup first.
v2.1
-Fixed a broken setting on ALL scripts, see this for more info: https://forum.xda-developers.com/showpost.php?p=78287566&postcount=103
-Added setup apps to the light script as I intended in the first place
-If you come from an older script, you should dirty flash your current setup again because otherwise the broken setting won't come back. Sorry for the mistake.
v2.0.2
-Fixed OPFilemanager on light and extreme scripts.
v2.0.1
-Fixed a few mistakes I wrote, extreme script will work now.
v2.0
-Completely resorted the apps so it makes more sense. I have a little more hindsight and for most apps I actually know what they do and if it's dangerous to remove them or not. Hence, the extreme script hasn't changed but the light is significantly different. It will remove more useless apps but not remove apps that most users use. A bit smarter I'd say.
-And I would like to introduce you the invisible script, the ones who really can't deal with making sure the script works for them, they just want to make their phone lighter. Easy peasy, hassle free.
-To see how I resorted apps, please check "List of systems apps SORTED & EXPLAINED v2.0.txt" or just have a look at the end of this post.
v1.8.1
-Removed Rftoolkit as it's a vendor app and I can't make it disappear for some reasons. I'd recommend you to freeze the app.
-Removed "datastatusnotification" as it's necessary to keep track on data usage.
v1.8
-Only the extreme script is updated
-Added a few more apps, including OPSes which sens telemetry I think. I couldn't find anything explaining exactly what it does but I've been running my script for some time now and 0 issue.
-Here is the list:
Code:
"/system/system/app/OPSesAuthentication",
"/system/system/app/SeempService",
"/system/vendor/app/Rftoolkit",
-Yes, changelogs are shorter and shorter
-However, 92 apps included now!
v1.7.2
-Added Music2 to both scripts.
v1.7.1
-Removed from the script OPAppCategoryProvider as it was breaking battery stats.
v1.7
-Only uploaded the extreme version as it's experimental and the light version would be the same
-I'm trying a few more apps that seem useles, but I need more feedback. Some telemetry from Qualcomm should be gone as well.
-Here are the new apps
Code:
"/system/system/priv-app/OnePlusWizard",
"/system/system/app/AutoRegistration",
"/system/system/app/datastatusnotification",
"/system/system/app/PlayAutoInstallConfig",
"/system/system/app/RFTuner",
"/system/system/priv-app/OPAppCategoryProvider",
v1.6
-Added more apps in both scripts
-Now the light script includes this category " #APPS THAT CAN BE FOUND ON PLAY STORE" as you can reinstall them very easily (and you won't even loose them if you updated them once).
-Expect more privacy as I've deleted more telemetry from both OP and Qualcomm.
-Documentation updated
-Here is the list
Code:
"/system/system/app/GoogleContactsSyncAdapter",
"/system/system/app/OpSkin",
"/system/system/app/HTMLViewer",
"/system/system/app/uimremoteclient",
"/system/system/priv-app/CallLogBackup",
"/system/system/priv-app/CNEService",
"/system/system/priv-app/OPAod",
"/system/system/priv-app/SharedStorageBackup",
v1.5
-Fixed a few entries as they were not written properly. So some apps that were already included will actually be removed this time. Thanks to @zyvex_14 for his help and support.
-I've added these apps that can be safely removed.
Code:
"/system/system/app/Account",
"/system/system/app/QdcmFF",
"/system/system/app/WapiCertManage",
"/system/system/priv-app/DiracAudioControlService",
"/system/system/priv-app/OPCellBroadcastReceiver",
-As always, I've updated the advanced documentation.
-You can now download a .txt file with all the documentation: all system apps are sorted and the shady ones are explained.
Now, Tomatot Debloater Extreme v1.5 removes 72 apps and your device still runs perfectly, if not better
Tomatot Debloater Light v1.5 42 apps and you basically don't loose any feature
v1.4
-Quite satisfying build: I feel like the script is almost final.
-Here are the new lines I added, to the different versions.
"/system/system/app/OPBackup",
Code:
"/system/system/priv-app/BackupRestoreConfirmation",
"/system/system/priv-app/Tag",
"/system/system/priv-app/OPFaceUnlock",
"/system/system/priv-app/EmergencyInfo",
"/system/system/priv-app/Turbo",
v1.3
I forgot to update the scripts when they're flashed so TWRP will display "v1.2 when it's actually v1.3, so no worries
-Merged with xXx all the apps where I was sure they could be removed without risks. Still some apps I need to sort out.
-Now I have 2 scripts
LIGHT = SAFE TO DELETE FOR ALMOST EVERYONE + APPS THAT CAN BE FOUND ON PLAY STORE (they will just become user apps if you updated them at least once)
EXTREME= SAFE TO DELETE FOR ALMOST EVERYONE + APPS THAT CAN BE FOUND ON PLAY STORE + SAFE TO DELETE IF YOU USE ALTERNATIVE APPS OR JUST DON'T NEED THE APP + EXPERIMENTAL STUFF SOMETIMES
To see their content, check advanced documentation.
v1.2
-Added OP user apps (that you can uninstall without root when to flash a new ROM). I didn't think of them at first because they're easy to remove and once you do, they don't come back after you reinstall the ROM. However, with the script, they will leave the system partition for good, which is cleaner. And it will be useful for people who didn't delete them already.
-Removed "usb_drivers.iso." it's what makes the windows explorer show the OP6 as a CDROM when you plug it to your computer. So you can have access to drivers. It's pretty useless except for the first time you plug your phone to your computer. And still, there are plenty other ways to install drivers.
-I've updated the list of the apps in the first post.
v1.1
-Fixed the "card" app.
v1
-Initial release

Works like a charm for me, many thanks.
I just had to edit your file for the "card" app, + few others lines I deleted to keep some apps I use, such as 'Duo'.
In your file, it is written "Card", but my app was named 'card' and apparently the C in capital letter makes it not work (for this app specifically).

zyvex_14 said:
Works like a charm for me, many thanks.
I just had to edit your file for the "card" app, + few others lines I deleted to keep some apps I use, such as 'Duo'.
In your file, it is written "Card", but my app was named 'card' and apparently the C in capital letter makes it not work (for this app specifically).
Click to expand...
Click to collapse
Wow, you're already a pro! Well done mate. I don't know if it was your experience with editing a script but if it is, I'm glad my my guide makes sense and that some users already benefit from it. And thank you for pointing out my mistake.
I'm uploading a 1.1 update with the fix.
Don't forget to flash again your script if you update your ROM.

First time I manipulated and edited this kind of file, so many thanks for your tuto, very helpful in my case.
Just one additionnal question, is there somewhere a list of all bloatwares that can be safely removed? Or is your list exhaustive for our OP6?

zyvex_14 said:
First time I manipulated and edited this kind of file, so many thanks for your tuto, very helpful in my case.
Just one additionnal question, is there somewhere a list of all bloatwares that can be safely removed? Or is your list exhaustive for our OP6?
Click to expand...
Click to collapse
Humm usually on different when you search for it on Google, you find threads that explain what services to disable, but 99% of the time they're also device specific.
I've never found a universal list with all the bloatware common to all Android phones. If you have a doubt about an app in particular, google it and you'll have your answer. However, what I've found out trying different scripts is that there are some apps i can freeze without any consequences, whereas if I try to delete them with my script, the phone will end up in a bootloop.
Unfortunately, this project is very recent for me and I didn't do any exhaustive testing so I don't know exactly what apps were breaking my script.
Ideally, i'd have to create another script that bring back the apps I remove so I can try one by one and see which apps are safe to remove. Because right now, everytime, flashing back OOS, rebooting to make sure it works, then going back, flashing my script, checking again, etc. it takes a lot of time so it will take some time before I can be more accurate.
At least right now I have a good base of what apps I'm sure I can remove.
Now when I'll have enough time I could try one by one to delete apps and see how it goes. I just to find a way to not have to reflash the whole system every time.
If anyone has a suggestion he's welcome!
I'd say that @Zios01 knows a lot about the topic since he probably tried himself what apps are safe to debloat.
You can read his script as well to see what apps he removes and you can assume it's safe to add them to my script.

I perfectly understand that you can't try one-by-one all of them, it gonna turn you crazy otherwise to flash-reboot-check and so on...
As you wrote, this is a good start and a good base, let's see also if someone has more experience with the others apps/bloatwares.
Anyway, thanks again for your answers and contact provided, I will try to find his script as well.

zyvex_14 said:
I perfectly understand that you can't try one-by-one all of them, it gonna turn you crazy otherwise to flash-reboot-check and so on...
As you wrote, this is a good start and a good base, let's see also if someone has more experience with the others apps/bloatwares.
Anyway, thanks again for your answers and contact provided, I will try to find his script as well.
Click to expand...
Click to collapse
Here it is.
I had to add the .txt extension to upload it. Also, I changed the name so it won't work. It's just for "science".
You will see he doesn't use the same "language" at all, and it's way more complicated than my script. However, it's not hard to spot the apps he's referring to.
Btw, as I already said, the good thing with this script is that it will ignore errors. So if you add a line to your current script, you can flash it and it will just remove the one app you added. You don't have to make an entire new file for your v2.

OK, so I added several lines based on XxX script.
I did a reboot and no bootloop, that is already a good point .
Now I am going to test my phone and if everything works ok and still flawless, I will share my file.

zyvex_14 said:
OK, so I added several lines based on XxX script.
I did a reboot and no bootloop, that is already a good point .
Now I am going to test my phone and if everything works ok and still flawless, I will share my file.
Click to expand...
Click to collapse
When I did my little experiments and I was deleting the wrong files, it was just not booting, stucking on OnePlus logo. Just once it booted, but shut down immediately and took me to recovery.
So you should be fine. But yeah maybe only after a week or something we'll find out that a tiny but sometimes useful feature doesn't work.

Thanks for your work! I would suggest using Magisk if possible as the changes aren't permanent. Except if you want to achieve that it's permanent

Tomatot- said:
When I did my little experiments and I was deleting the wrong files, it was just not booting, stucking on OnePlus logo. Just once it booted, but shut down immediately and took me to recovery.
So you should be fine. But yeah maybe only after a week or something we'll find out that a tiny but sometimes useful feature doesn't work.
Click to expand...
Click to collapse
Indded, that is what I worry about, that everything looks fine and finally after some days (maybe earlier :crying something doesn't work like it should be.
That is why I would like to test prior sharing my file.

Macusercom said:
Thanks for your work! I would suggest using Magisk if possible as the changes aren't permanent. Except if you want to achieve that it's permanent
Click to expand...
Click to collapse
It does sound like a good idea! I will investigate this possibility and let you know. I'm not sure I have enough knowledge and experience.

https://forum.xda-developers.com/apps/magisk/module-terminal-debloater-debloat-t3584163
So I've found this Magisk Module which seems quite impressive tbh. It seems quite easy to use and safe as well. It's honestly way more advanced than my script.
But at the same time, I feel like it doesn't do much more than a classic freeze with Titanium Backup.
You still have to go every time you install a ROM through all the apps you want to remove. You could write down numbers but it's risky, if you change ROM or even you update your ROM and numbers change, it could mess up everything. So I still think my solution had advantages compared to this Magisk Module.
However, I might use the module to see what apps break the device or not. Then I can improve my script a little. I will also think about making a Magisk Module out of it, but I'm not sure it will make things much better.
My ultimate goal is just to "flash it and forget about it until you flash a new ROM/update". So it wouldn't matter if you can remove it or not.
There are 2 possibilities when using my idea:
1) I (I isn't me, I speak for users in general) am happy with the script, I don't loose any features. So I don't need to touch it. Flashing it once in TWRP isn't a burden at all. Especially since it takes like 2 seconds to flash. Then it's the best solution since, once you have your script you like, you can always keep it.
2) I am happy with the script but I want a few apps back. Sure, having a Magisk module could make things easier as I could just remove the module (considering it has a restore feature), but I would need to edit the module or the script, and then apply it again. It one of the apps break the system and makes the device bootloop, even with a Magisk module, it will be hassle to fix it. It's just more simple to flash the ROM again like I'm doing now.
Now you need to ask yourself this:
1) Do you prefer to have more features at the cost of spending some time setting up your device every time you flash a ROM? Then use Titanium Backup or Terminal Debloater.
2) Do you prefer to take some time once to setup your script properly but then you won't have to care about it for, theoretically, until you get a new device? Then go with my script.
If my script gets some attention, I'm pretty sure within a few weeks I / we will be able to propose enough scripts to make (almost) everybody happy.
Like script 1 extreme debloating
Script 2 medium debloating
Script 3 light debloating
So 99% users are satisfied, and then the pickiest ones can always make their own script since it's very easy to edit my script.
Am I making a point?

What's with the .iso file and /system/reserve?

Tomatot- said:
https://forum.xda-developers.com/apps/magisk/module-terminal-debloater-debloat-t3584163
If my script gets some attention, I'm pretty sure within a few weeks I / we will be able to propose enough scripts to make (almost) everybody happy.
Like script 1 extreme debloating
Script 2 medium debloating
Script 3 light debloating
I think this will be a great way to debloat to each individual preference. Will be watching this thread for these updates:good:
Click to expand...
Click to collapse

Sh0X31 said:
What's with the .iso file and /system/reserve?
Click to expand...
Click to collapse
I didn't know about /system/reserve, thankj you for sharing. From what I understand, it's the apps that come pre installed but are removable. It seems like once you delete them they don't come.baxk after a dirty flash. However I can remove them so the script is useful after a clean flash. Thanks!
What are you referring to with the .iso though?

Tomatot- said:
I didn't know about /system/reserve, thankj you for sharing. From what I understand, it's the apps that come pre installed but are removable. It seems like once you delete them they don't come.baxk after a dirty flash. However I can remove them so the script is useful after a clean flash. Thanks!
What are you referring to with the .iso though?
Click to expand...
Click to collapse
I mean the usb_driver.iso

Sh0X31 said:
I mean the usb_driver.iso
Click to expand...
Click to collapse
What about it?

Sh0X31 said:
I mean the usb_driver.iso
Click to expand...
Click to collapse
Not sure what it is, but xXx has it available for debloat on his room as well

Develop Bugs

welcome