Database Info

how to get animated gifs in webview. (from dev @ google)

you want to work around this with your own Android build, you'll need to modify C++ code, rebuild, and reflash your phone. You'll need to make two fixes to the released sources. 1) edit the function should_use_animated_gif() in external/webkit/WebCore/platform/graphics/android/ImageSourceAndroid.cpp (around line 217). Return true to animate gifs 2) Change setRGBA() in /WebCore/platform/image-decoders/ImageDecoder.h (around line 173) to call*dest = SkPackARGB32(a, r, g, b) *dest = SkPackARGB32(a, r, g, b) instead of instead of*dest = (a << 24 | r << 16 | g << 8 | b) With these changes, gifs will animated correctly on large memory devices like Droid and Nexus One There's no code path for animating gifs in arbitrary applications like Gallery, except by rewriting it to host a WebView modded as described above
Click to expand...
Click to collapse
So, this is from c... on google code. If someone can throw this into a ROM I would be so excited. This has been my biggest gripe with android. I am no coder, but I've been pressuring google for a while.

Sorry for double post. Here is the url to the fix posted by c...
http://code.google.com/p/android/issues/detail?id=3422
His reply with the fix is at the bottom.
Anyone wanna put this in a future rom?

Enable javascript in the Webview, then use it to swap images.
Here is an example:
The Java part:
code.google.com/p/slidetypekeyboard/source/browse/trunk/src/com/latinsud/android/slidetypekeyboard/HelpActivity.java
The HTML/Javascript part:
code.google.com/p/slidetypekeyboard/source/browse/trunk/assets/index.html
(Sorry i cannot post links directly)

Anyone managed to get this into a ROM? My Evo is a week old and only today I learn that it does not support the animated Radar from my favorite weather web page.
The result of this was riding the motorcycle through an downpour because I could not get a good fix on where the storm was headed.
I use animated gif radar for things like...oh say...tornado storms and such since I live in tornado alley. Google's response about memory is crap. My little Raphael has run this animated radar since I got is over a year ago and it is half what my new Evo is. This is a HUGE issue for me as my goal with phones is a traveling package...phone/gps/weather(internet)/and snapshot camera.
The Raphael did all that, but started to die and was so tiny a screen. Cannot believe Evo/Android cannot do this.

they said that animated gifs would be supported in froyo.
I have an incredible, but am upgrading to a droid x on the 15th because of problems with my phone. rumors are circulating that it might ship with froyo.

Yeah...but not sure I am up for customizing this phone...and waiting for Sprint/HTC to push out is...well like waiting on the lotto. They don't do things the way we users would want.

[THEME TOOL IDEA] Copy 9-patch from original files

While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....

erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Huh. I've been wondering if this was possible. I haven't tried this yet but if it works, nicely done! I think that this would be a huge improvement and addition to the themeporter programs that are out there. There is a high demand for this in that area and in the area of HDPI>MDPI/MDPI>HDPI conversion. I'm certainly bookmarking this!

Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.

Daneshm90 said:
Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.
Click to expand...
Click to collapse
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.

erasmux said:
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.
Click to expand...
Click to collapse
Hmm k i'll spend more time with it, perhaps the resizing program im using causes mishaps. Currently when i resize it completely messes stuff up even though the resolution corresponds to a mdpi device.
I'll do the good ol' trial/error n let u know. Thanks for the (proof of concept)
Edit :
Ok so upon using ur code for transferring images of diff sizes u can obviously tell whts up
So one improvement im thinking off, is if the images differ in size, it could draw the border and eliminate anything outside it. Ugh gotta brush up on my java though :S

bump
10 del al char har

bump
I tested it out and it works great! Thanks!

I really hope someone takes this idea and runs with it! If I knew how to code, I would certainly look into this. Maybe I can get one of the Vibrant Devs to look at this....

erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Can U just tell how to use this code for bulk images?????

pratyush.creed said:
Can U just tell how to use this code for bulk images?????
Click to expand...
Click to collapse
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....

erasmux said:
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....
Click to expand...
Click to collapse
Gr8 work...u made themin a kid's job
Sent from my GT-S5670 using XDA Premium App

???
does the original still work cause im on windows 7 64 bit and i was able to copy the changes to original but not it makes no changes at all, so the original file doesnt get the changes...
please help!!

[Release/Dev]Automatic Boot Logo Creator/ApkManager replacement

So first off, the release:
I've created a program (technically a script) written in Python that does all of the tedious work of making a boot logo and getting it on your Droid X or Droid2 phone. Specifically, it does all of the following for you:
1) Takes a 24-bit BMP of size 480px X 182px and flips the canvas horizontally
2) Makes the image the right size by removing the first 54 bytes (after the canvas flip all images are the same size so we don't need to remove the last 2)
3) Reverses all the bytes and writes the image out to a logo file (logo.bin)
4) Puts your created logo into the TBH Logo Replacer flashable zip file
5) Pushes the zip to your SD card
This tool should give anyone who has Clockwork recovery and is slightly familiar with it and knows how to copy, paste, and crop in an image editor the ability to make their own boot logo.
code.google.com/p/android-customization-autotool/downloads/detail?name=AutoBootLogoCreatorV1.1.zip
The project in development:
As you can probably tell from the link above, I'm also working on a tool that I have dubbed the Android Customization Autotool. When completed, it will have all the same functionality as ApkManager, and more. For the most part, I've been using ApkManager and it works fairly well.
However, there are some things that I feel are missing and have added in my tool. Similar to ApkManager, my tool isn't some new method of doing something or some type of breakthrough. It merely takes existing tools that are out there (and some that are not) and packages them up into an "all-in-one" type tool that is easy and efficient to use for beginners and experts alike.
What I'm aiming to do with the tool is quite simple. I'd just taking the significant amount of scattered knowledge on various forums regarding hacks and customizations and automating the whole thing so that people who don't have the know how, or aren't confident in their know-how can have all of the same customization opportunities that the rest of us who know what we're doing have. And for those who do know what they're doing, the tool will save a lot of time and effort.
The project is located at:
code.google.com/p/android-customization-autotool/
If anyone is interested in helping out (note it's in Python) just let me know. I'm also extremely open to any suggestions that people have about what should be supported. There are still a ton of customizations out there that I haven't seen any tools for and it would be nice to cover everything.
For those of you who would like to continue using ApkManager (since right now it's the better choice), I've been designing my tool in a modular way where any functionality that is provided can be forked off into it's own stand-alone application. And since the project is open-source, you can add or strip away as much or as little as you want. If you do make something cool though, please let me know because I'd love to add it to the tool (credit is always due of course).

thank you for sharing

Thank You...

If you guys run into any problems with the code, please let me know via the Issues page at code.google.com/p/android-customization-autotool/issues/list and I'll do my best to fix them. Still working on the all-in-one, but I've made an Update Zip auto creator that generates the META-INF folder, creates a .zip and signs it. More on that later today, sleep time =D

Thank you!!

[Q] edit/update listitems?

hey, i think the title said everything, need to change the values of listitems.
tried it like this:
(App.Current as App).list.ElementAt(index).Replace("", "updated value");
any suggestions?
roqstr

You can get the full item collection from a list, and iterate through it using a for loop (by the way, most collections allow array-style indexing in C#) or simply use an iterator and do remove/replace (if supported) or build a new collection based on the old values and then replace the collection in use.

[DEV][M10] Decompiling M10 (Sense) images

The problem
Since HTC introduced Sense 3.5, themers faced a huge problem. The previously used software "M10Tools" wouldn't work with the new version of Sense.
Flemmard and me tried countless hours decoding the new image format, but without any success. The new image format is totally diferent to anything else previously seen.
I made this thread to search for help from all the awesome devs on XDA, hoping that we might find one who can help.
The history
Let me start this with some introduction to the m10 format itself.
The images I am talking about are parts of one big file - the m10 file. We usually have multiple images per m10 file, but the number doesn't really matter.
Together with the raw image data we get a set of meta information. We are not exactly sure what the values mean, but we can guess the meaning from the history of the old, decodable images.
We used to have information like width, height, payload of the image and an integer indicating what kind of image type we have. We know the actual image type for a few of these intergers, but with Sense 3.5, 3.6 and 4.0 HTC added at least two new types.
The facts
We don't have any hard facts for these image types but looking at the "old" image types, we can guess a few things:
The images are in a format the GPU can render directly (Like s3tc, ATC, QTC, etc) (At least this used to be the case, might have changed)
Images are most likely compressed. The ratio between assumed size (based on meta data) and the actual data size indicates some heavy compression. The data itself obviously looks compressed too.
There are no headers or any other help. It is just raw data.
We don't know exactly how the decoded images actually look like, so we can't say what the images display. However, due to latest archievements we "might" know this for images from Sense 3.5 and 3.6 if needed.
The handling software side is all in a few libs and NOT in smali / java, so we can't look for stuff there, however we have the libs, so if someone is pro with assembler he might find out something
I will provide a download which contains several chunks of image data and the according meta data.
If you consider working on this, please do not refrain from thinking about super simple solutions, we worked so long on this that we might be totally confused.
One thing though, this might sound arrogant, but this here really is only for people who have some decent knowledge about file formats, image compression or OpenGL.
The image types
Here is a list of image type we already know ( remember, we don't know where the numbers come from, might be some enum in native code or so)
Type 4: Raw RGB
Type 6: Raw RGBA (still used rather often)
Type 8: ATC RGB (doesn't seem to be used at all anymore)
Type 9: ATC RGBA Explicit (doesn't seem to be used at all anymore)
As you can see we got types WITH and WITHOUT alpha encoding.
Here is the list of UNKNOWN formats:
Type 13 (used way less than type 14, so maybe no alpha?)
Type 14 (this is the most used type, so I assume this one supports alpha encoding)
When thinking about what the data might be, don't throw away crazy ideas like "The data is S3TC /ATC /whatever but compressed again by some 'normal' compression algorithm". Maybe they just replaced type 8 and 9 with an additional compression on top of these types.
The meta data
Okay, so now lets talk about the meta data we get together with the actual data:
We get 4 more or less known chunks of information per image (plus a few unknown things)
Image type (described earlier) (Example: 6)
Image width (Example: 98)
Image height (Example: 78)
A more complex value containing multiple values at once.
Example: "98:78:0:30576"
We used to know the meaning of three of these values. However we are not sure for the new images. Lets explain the old meaning first:
98: Width, same value as the value above
78: Height, same value as the value above
0: It's always 0, we have no idea what it means, but since it's static we didn't care
30576: this used to be the data size. This image has a resolution of 98*78 = 7644 pixels. With a data size of 30576 that means we got 4bytes per pixel.
Lets take a look at the new images now. We still get the same information, however the meaning seems to have changed a bit:
Image type (described earlier) (Example: 14)
Image width (Example: 997)
Image height (Example: 235)
A more complex value containing multiple values at once.
Example: "1000:236:0:118000"
This is the assumed new meaning
1000: Width, but rounded up to a multiple of 4
236: Height, but rounded up to a multiple of 4
0: It's always 0, we have no idea what it means, but since it's static we didn't care
118000: this value is now exactly half of the rounded resolution (1000 * 236 / 2 = 118000)
This would mean only half a byte per pixel. One big problem here: the actual data size does not match this value at all!
The data is way smaller than this value, which indicates that it got compressed a second time
Now lets talk about some very important piece of information: HTC uses the SAME image formats on BOTH a Tegra 3 and a Qualcomm Snapdragon S4.
This obviously means that both Tegra and Snapdragon need to be able to handle this. However, also keep in mind that HTC bought S3 graphics and thefore might got some advantages here.
You can find a statistic on the used formats in the download, it's an Excel sheet with two diagrams showing the usage.
Now this was a long post, I hope someone is still reading this and might have some ideas about what's going on here.
Feel free to ask any questions concerning this.
I am also available in #virtuousrom on Freenode, per PM here or via email: diamondback [at] virtuousrom [dot] com
Download:
The download contains a bunch of unknown images of types 13 and 14 together with their meta data (like explained above)
Download image pack

Solution
After some digging I estimated that the data is compressed with fastlz [0]. Also so if you decompress it, you get exactly Width*Height bytes of data. I dont know the format this data is in, but i guess its the same the uncompressed data (type 8 or 9 or so?) was. Maybe someone could check up on that.
[0] http://fastlz.org/

onlyolli said:
After some digging I estimated that the data is compressed with fastlz [0]. Also so if you decompress it, you get exactly Width*Height bytes of data. I dont know the format this data is in, but i guess its the same the uncompressed data (type 8 or 9 or so?) was. Maybe someone could check up on that.
[0] http://fastlz.org/
Click to expand...
Click to collapse
You are indeed right. We actually found the same a few hours ago What a weird conincidence... :victory:
Type 4 and 6 are changed, they are zipped now too. Which actually breaks backwards compatibility with older Sense versions...
Inside of the zipped data are ETC images, which also explains how they can use the same on S4 and Tegra 3.
The type 14 actually contains TWO images, both ETC. Since ETC doesn't support alpha one is the image and one is an alpha mask...
Funny trick HTC!