Develop Bugs

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.

How do I remove stock HTC Wallpapers from the EVO ???

I never use them so I want to get rid of them. I went into system/customize/resources folder and deleted them....but then in wallpapers, the HTC WALLPAPERS showed 25 black empty boxes.
How do I make it so that they are deleted and no longer showing up?

I think you would actually have to remove the entries in /system/customize/MNS/default.xml
I am not sure, but I think the customization settings in the file only get processed when you first install a rom. You could try removing the entries and rebooting the phone. Other than that, there may be a command to do an oobe setup again without having to reinstall the whole rom.

Necro-bump.
It seems even when flashing a ROM update, changes to default.xml do not take. I have to flash to a completely different ROM and then my cooked ROM for new wallpapers to show up.
Anyone have any ideas?

Help with sense clock background

Ok, I am so flippin' confused right now!
I am running redemptive revolution rom and noticed that the background for the clock is "missing" (or just transparent).
I have looked at the png files inside the apk for htcclockwidget but can't seem to figure out what is changing the color!
I've even tried pushing the htcclockwidget.apk file from other roms to the phone but they never work. (always end missing from the widget adding screen) even after changing permissions with root explorer the widget never shows up after numerous restarts!
Anyone have a suggestion that I might not have tried?

ok, feel free to delete this.....I tried flashing a new clock via recovery and it actually worked that way!
*EDIT*
Also, I think I would have been fine replacing it with root explorer too but needed to go into programs and find HTC Sense and clear data! (just in case someone else runs into the same problem I had)

[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.

[SOLVED] My status bar has disappeared

I'm running Xylon 2.1.1, which is based on 4.2.2
I recently thought it would be great to copy the systemui.apk file, change some of the icons and replace it. It didn't work and somehow it made my status bar disappear. I put the original file back, but that didn't fix it. I then wiped the cache, did a dirty flash of the same ROM and wiped the cache again, and I still have the same problem.
Also I'm using a system theme (Flow) and it's not really applied properly, some interfaces aren't themed, if that helps.
Anything I can do short of doing a factory reset? I know I haven't enabled expanded desktop or anything.

I've reinstalled different versions of the same ROM multiple times and it still hasn't fixed the problem, I'm starting to think there's a bigger problem here. Could I have downloaded a virus? I'm always careful about installing apks but still...
Also is it possible that when I messed with systemui.apk I broke something else?

A re-flash of the ROM should have fixed it so I dont know what to tell you there. As far as replacing system files, make sure you set the permissions to what they are supposed to be or else they mean nothing to the OS. And if your systemui.apk file isnt working right, I would think more than just your statusbar would be messed up.

I'm not entirely sure what you mean by setting the permissions, I did "fix permissions" a few times in TWRP. And it does seem like my systemui is completely borked actually:
-No status bar
-No navigation bar (I usually have it disabled because I use gestures, I tried to enable it and nothing happened)
-Aforementioned theme problem
-Can't change the wallpaper from the default phase beam one
I'm getting worried that it's some kind of virus that's sneaked its way in to my other apps. I've tried going through /system/app and /data/app but I haven't seen anything that I don't remember installing. I might try an antivirus but the ones on Android seem to be more focused towards real-time protection and that kind of thing, rather than getting rid of things that are already there.
Anyway thanks for your reply

I fixed it! I'll post what I did in case someone has this problem in the future:
Settings - apps - all - SystemUI
For me there was an option to "uninstall updates" which I'd never seen before, so I hit it and after a reboot everything is fine. I was getting pretty worried there...

You arent going to just get a virus out of nowhere. Contrary to what people believe, viruses are pretty rare on Android. So dont worry so much about Viruses.
You not knowing about changing permissions is most likely what happened. Most file browsers will let you change permissions to a file if you have root access. I use Root Explorer and its pretty easy. Whatever file you make changes to need to have the same permissions the other apk files in that folder in the end.
But I'm glad you got it working.