Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for 9-patch drawables #2

Closed
GoogleCodeExporter opened this issue Mar 13, 2015 · 15 comments
Closed

Add support for 9-patch drawables #2

GoogleCodeExporter opened this issue Mar 13, 2015 · 15 comments

Comments

@GoogleCodeExporter
Copy link

9-patch data is written directly into an image binary, it is somewhat harder 
to get it and this data is currently not decoded. apktool modifies names of 
9-patch files to normal .png, so they are acceptable by aapt, but then they 
will stretch like a normal images.

Currently there is workaround for this: after apk building you could copy 9-
patch images from original to new apk. Of course you need to modify names, 
as apktool did.

Original issue reported on code.google.com by Brut.alll on 2 Mar 2010 at 10:40

@GoogleCodeExporter
Copy link
Author

Apktool 1.0 automatically workarounds this issue, but 9-patch images are still 
undecoded.

Original comment by Brut.alll on 2 Apr 2010 at 7:06

@GoogleCodeExporter
Copy link
Author

I was just thinking about this, would it be possible to skip 9 patch 
altogether? Or is that going to create problems?

Original comment by master.h...@gmail.com on 11 Jun 2010 at 1:48

@GoogleCodeExporter
Copy link
Author

What do you mean by "skip"? Just unpack them as any other image? Then aapt will 
throw errors, because it will find *.9.png files without 9patch borders.

Original comment by Brut.alll on 11 Jun 2010 at 7:14

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

Let me know, how it works. If there will be some errors, then you will have to 
wait for fix or move back to 1.2.0. There is no way to disable this feature.

Original comment by Brut.alll on 12 Jun 2010 at 7:38

  • Changed state: Done

@GoogleCodeExporter
Copy link
Author

As I can see, it creates .9.png files in main res tree, instead of separate 
9patch dir.
Can anyone explain what for?
In any way it works well, as it did before. I fully decoded and rebuild rom 
without any problems.

Can anyone point me to good info about 9patch? (don't understand how it works)

Original comment by stari...@gmail.com on 12 Jun 2010 at 8:09

@GoogleCodeExporter
Copy link
Author

http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch

Later apktool didn't support decoding these files, so you couldn't modify them. 
9patch dir was a workaround, now you could use these files, as you would be an 
author of an app.

Original comment by Brut.alll on 12 Jun 2010 at 8:18

@GoogleCodeExporter
Copy link
Author

*Later -> Earlier ;-)

Original comment by Brut.alll on 12 Jun 2010 at 8:21

@GoogleCodeExporter
Copy link
Author

Thanks for the link.
Now I see those stretch/padding markers.
Great job!

By the way, I decoded legend rom without any problems too.
1.3 rocks!

I didn't try repacked rom on the real device yet. Hope there won't be any 
surprises.

Original comment by stari...@gmail.com on 12 Jun 2010 at 8:44

@GoogleCodeExporter
Copy link
Author

When you will be testing it, look for some visual artifacts, especially in 
buttons, etc. Unfortunately potential issues are "hidden", because they don't 
simply FC, but may change a look a little.

Original comment by Brut.alll on 12 Jun 2010 at 8:56

@GoogleCodeExporter
Copy link
Author

Seems there are some misunderstandings related to 9patch images, so I copy my 
msg from private discussion:

*.9.png files could be in two forms: "source" (9patch data stored as 1px 
borders) and binary one (9patch data stored as hidden, binary data). When you 
create your own app with 9patch images, you create them in "source" form, you 
could easily modify 9patch data using draw9patch tool or any image editor. When 
you build this app, all 9patch images are compiled to binary form - borders are 
removed. Then you can't easily modify 9patch data, because it's binary - you 
would need hex editor and quite good hacking skills to do it.

Apktool 1.2.0 couldn't decompile binary 9patch images to source ones, so:

  * they had to be renamed to *.png, so aapt won't try to compile them second time. It would throw errors.
  * you couldn't modify 9patch data easily
  * you couldn't modify these images at all, because they must be in source form to modify them.

Apktool 1.3.0 can decompile binary 9patch images to source ones (it adds 
borders where they should be), so you can do everything with them. Also there 
is no need for hacking and doing workarounds - all works as you would have 
sources of an app.

Original comment by Brut.alll on 12 Jun 2010 at 9:43

@GoogleCodeExporter
Copy link
Author

And if you read some guides for themers, there are usually warnings like "Don't 
touch *.9.png files!". If you try to modify not decompiled 9patch image, then 
you would probably have problems. Now themers can modify them, thanks to 
apktool :-)

Original comment by Brut.alll on 12 Jun 2010 at 9:45

@GoogleCodeExporter
Copy link
Author

Thank you for sharing your knowledges. It's really interesting.
And of cause thank you for your great work.

I'll pay extra attention to UI. And it's ability to stretch =)

Original comment by stari...@gmail.com on 12 Jun 2010 at 11:09

@GoogleCodeExporter
Copy link
Author

One day left. Everythong is fine. Don't see any UI problems.

Original comment by stari...@gmail.com on 13 Jun 2010 at 5:13

@GoogleCodeExporter
Copy link
Author

Thanks for info :-)

Original comment by Brut.alll on 13 Jun 2010 at 5:30

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant