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.
I searched as best I could, but couldn't find a match to this particular issue.
I do have a rather weird issue with Gallery3D, that I've noticed after switching to OpenDesire, in 4.0.10 and 4.0.15.
Until recently I have been using various Sense based ROMs, where photos taken with the phone are stored in DCIM/100MEDIA and I always just used HTC's gallery app.
Now I'm on OpenDesire 4.0.15, which stores phone photos in DCIM/Camera, and uses Gallery3D to display them.
The thing is, when I try to display photos from DCIM/100MEDIA, taken earlier on various sense ROMs, Gallery3D shows some completely random photos instead. The thumbnails in 100MEDIA display correctly, but when I tap any thumbnail, it expands to the grainy fullscreen version, and is then replaced with a sharp and refined version of *another* picture.
It shows photos that I have taken with this same handset, but imported to my computer and deleted from the phone long ago. That is, photos that aren't even *on* the SD card anymore.
I have tried the following:
1. settings > apps > manage > Gallery3D > force stop + wipe data and settings
reboot
no luck
2. rename 100MEDIA to something else.
repeat 1.
no luck
3. Create new folder DCIM/Test
Copy files from DCIM/100MEDIA to DCIM/Test
The copies in DCIM/Test work well.
Hm.
4. factory reset, wipe cache + dalvik
reflash OpenDesire (4.0.15)
no luck
5. Made a flashable zip with most recent Gallery3D.apk from this thread and flashed it over the one included in OpenDesire 4.0.15
No luck (yes the update succeded, different file size )
Ok, fine, so I kind of solved the problem in attempt number 3, right? Well, yeah, except that I'm uncomfortable about my phone magically raising photos from the dead that I've deleted long ago.
Have you guys got any ideas or input?
Well, your deleted pictures aren't exactly "dead", they just aren't in the master file table of your SD once you hit delete, but they can definetly read. But to avoid going offtopic, you can simply back up your files, format the SD card and restore the files. Everything should be ok.
As to why this happened, it's possible that your Master File Table got corrupted somehow (or Android's MediaManager isn't reading it correctly). But I can't really say much since it's difficult to tell what the real cause is (perhaps you didn't "safely remove"?).
Either way, reformatting should help. And keep using Gallery3D from that post, it's one of the best around
Reason
Even i experienced the same issue,,but couldn't find the solution,,,,but i figured out why it is happening..!!
My gallery 3d app was showing the images i took long back which are no more in the SDcard..!!!how can it be possible..??
The reason is,,
>When we delete the file in the sd card,,the operating system will just mark that that memory location with some special character ,,in fact the data will appears to be deleted but truly i won't ...!!
>when we add new files to the file system that space will be overwritten ,,,by the new file...!!
>So in our case the file which appears as the thumbnail is in exact same memory lactation as the old deleted image....so the thumbnails will be stored in different location as the cache,,,,,
>this is the reason why it show the thumbnail but when we click on that,,, it shows the original data resides there....!!
> its just a bug in the Gallery app
>And it will happen only when we delete the files inside the gallery app...
>Next time try to delete the files in Some file managers like Astro
hey guys i was just browsing through stune trying to see what i could modify and i found this
look at the 7th line (COUNTMAX1=1300)
this file is located in registry in browser of stune. file name is pshsetmemorystatus.ini.
i am on xxjk1 and i tried to modify this setting. it got saved and i went through to the phone settings->memory->memory status->messages->txt messages and it flashed 1500(i changed the value to 1500) for a second then reverted back to default. can somebody please try this on different firmwares and also on original firmware or try and find why it is reverting to default value???
Anyone tried this ?
Any ideas as to why it might be reverting back ?
Anyways great job dude. I will try to raise its limit and then restore my 7000+ SMS and report back.
Thanks again !
Keep exploring
Edit:
Checked it. This file does not set memory. It only gives details about memory status that you see in Settings>Memory>xxx. So even if we set values here they will be reverted back to original. There is some other files which controls memory.
kk thanks for clearing the confusion. i will try to find the file.
btw i have checked every file in registry tab in stune. this is the only file i found regarding sms storage.
Also check System, User, etc. There is also another database of configuration files just like Registry folder only I have forgotten name and currently I don't have Ms.Windows here .
Good Luck !
I've figured out hw to change the Portrait & Landscape BG's for the Search Screen. This requires your device be Unlocked & use of the Windows Phone Device Manager.
Use the built in File Manager to browse to the following folder;
\Application Data\Search\
Inside you'll find 2 images, todayimage.jpg & todayimageL.jpg, L obviously stands for Landscape. Simply copy in your desired images & replace the exiting ones. I recommend renaming the originals for back-up in-case you want to revert to the stock dynamic images.
HTC-only, and you could already do this using one of a couple of filesystem browser apps on the phone. Also, those images get overwritten periodically (daily, I believe). If there's a way to make them persist, that might be of interest.
thanks for the tip
the bing background has been changing steadily lately, when I first got the phone I was so over seeing those dang penguins on my search screen
good work man ..
Hi,
Hoping somebody can help.
Each time i boot my N7100 (stock 4.1.2 but rooted) , a file is generated in /storage/sdcard0 with the name format "Ping_1363794618802-20141". The numbers in the filename change for each new file generated. The files are 62 bytes in size and have a creation date and time to match that at actual system boot time. These files accumulate one after another each boot and don't appear to get automatically deleted.
I have opened a file using text view and the data (as below) is always the same except for the last set of numbers which always match the filename.
3.0.8:_ping:GT-N7100:unknown:4.1.2:1.2.3:English:1363794618802
I have uninstalled many apps trying to get to the bottom of this and just when i think i have removed the offending app, the Ping_ files start again.
Do any others have these files being created during each boot? I never noticed any of these files until a few days ago so it must be a recent thing, since 4.1.2. I can not go back to when they first appeared as i always install apps in one large batch meaning it is difficult for me to eliminate things unfortunately.
tia
DraconianGothic said:
Hi,
Hoping somebody can help.
Each time i boot my N7100 (stock 4.1.2 but rooted) , a file is generated in /storage/sdcard0 with the name format "Ping_1363794618802-20141". The numbers in the filename change for each new file generated. The files are 62 bytes in size and have a creation date and time to match that at actual system boot time. These files accumulate one after another each boot and don't appear to get automatically deleted.
I have opened a file using text view and the data (as below) is always the same except for the last set of numbers which always match the filename.
3.0.8:_ping:GT-N7100:unknown:4.1.2:1.2.3:English:1363794618802
I have uninstalled many apps trying to get to the bottom of this and just when i think i have removed the offending app, the Ping_ files start again.
Do any others have these files being created during each boot? I never noticed any of these files until a few days ago so it must be a recent thing, since 4.1.2. I can not go back to when they first appeared as i always install apps in one large batch meaning it is difficult for me to eliminate things unfortunately.
tia
Click to expand...
Click to collapse
Well i think i've worked this one out after removing/ reinstalling over 80 of my apps. The 'rogue' app appears to be the Argos app, a UK retail store. I did look through all apps on my phone to see if any version numbers matched the entry inside the Ping_ files (3.0.8:_ping:GT-N7100:unknown:4.1.2:1.2.3:English:1363794618802) but somehow missed the version number. The current version of the Argos app on the Google Play UK store is 1.2.3, which matches up. I have now recreated this issue a number of times with the same effect.
Of course, there might be other apps which work in the same way, creating multiple small 'Ping_' files each boot.