The matter: I used many icons and pictures while developing an android application, later I replaced many of them but kept the old ones in case I would need to use them again. Now I have a huge amount of .png's in my drawable folder, many are now unused and it would take ages to manually sort them out. Is there a way to detect drawables to which no references exist?
You can use Android Lint Tool, follow the link I provide , as an overview it states:
Missing translations (and unused translations)
Layout performance problems (all the issues the old layoutopt tool used to find, and more)
Unused resources
etc.
As an alternative this project might help you (pretty easy to use):
https://code.google.com/p/android-unused-resources/
Hope it's useful...
In my experience, Lint does not detect unreferenced PNGs. It finds unreferenced layouts and drawable XML files like shapes and selectors but not PNGs. I stumbled upon this Python script for removing unreferenced PNG drawables. It worked well with my project but, as the documentation for it says, make sure you are using source control just in case.
https://github.com/instructure/android-ImageSweep
Related
With older versions of Android Studio, all of the drawable bucket folders were created by default (i.e. drawable-mdpi, drawable-hdpi, etc.). In newer versions of Android Studio, it only provides drawable and drawable-v21. Why is that?
Is there a reason that Android (in its infinite wisdom) no longer gives you the separate bucket folders?
Just to note, I know you can just add them manually, but I want to make sure there isn't some new best practice reason to not use those folders anymore.
Thank you to everyone who tried to help. You helped me reach the final answer, but no one solution was quite right. #user3137702 was probably the closest, as it IS related to the whole move to vectors/SVGs. I couldn't find a definitive answer, like something directly from Google (although I imagine it is out there), but from what I've gathered from a bunch of articles, there is probably a reason they are doing this.
For starters, it looks like this started in Android Studio 1.4. I am in 1.5 right now. It seems that Android is moving in the direction of no longer needing you to create your own density folders (i.e. mdpi, hdpi, etc.) for drawables (mipmaps is different, so please don't confuse that with what I am talking about). As of Android Studio 1.4, it will take the SVGs you put in the regular drawable folder (as in not the v21 folder), convert them to PNGs, and place them in auto-generated density folders for you during the build sequence (so Gradle does this for you, essentially) for all versions older than API 21. For 21 and up, SVG is supported different, which is a whole other topic. But this essentially makes SVG support backwards compatible all the way to API 1!!!
HOWEVER, there is a BIG catch. This SVG conversion is not always as successful as you might hope. It only supports a subset of SVG files, so depending on how you save it (i.e. what settings are applied when saving), it may not render properly. Even commonly used settings, such as gradient and pattern fills, local IRI references, and transformations are NOT supported (yet). If you are working with SVG files that you didn't generate, you will likely have problems importing them. If you or someone you work with directly generates them, you may have to experiment with how you save the files, and you should test builds often on older versions of Android to make sure it turned out as expected.
To import SVGs into Android Studio 1.4+, follow these simple steps:
Right-click on the res/drawable folder
Select "New"
Select "Vector Asset"
At this point, you can select a "Material Icon", which works
really well, and there are a bunch of beautiful "free" icons you can
select from. For indie developers, without icon design support,
this is nice!
OR - you can select "Local SVG File"
Then choose an SVG from either option with the "choose" option. WARNING: This is where it could possibly go wrong, if the SVG you import isn't saved properly.
Hit "Next"
Verify it is saving in the right place, and then Click "Finish"
At this point, it is reference-able with: android:icon="#drawable/ic_imagename" (using your image name instead of ic_imagename, of course)
#CommonsWare's response was very helpful in leading to the right solution, but from what I saw, generating several variations of new projects from different template and version support settings, there wasn't any way to actually have the old density folders get auto-generated. There is definitely more going on here than just a different template-version selection. But as he said, depending on what template/version you select, you may end up with a different set of those two drawable folder types. But specific to my question, Android Studio does seem to be putting an emphasis on this new approach of not creating your own individual drawable density folders at all.
It's pretty cool, imo, but it still needs some work. In practical terms, I will likely still need to add the drawable density folders to support all the images I work with, until this mechanism gets a little more supportive of all types of SVG renderings.
And one more tidbit - Because this is all handled through Gradle (the actual generation of the density folders) you can add build settings through the flavor mechanism to limit which density folders you want to generate. So if, for example, you feel mdpi images have reached the end of their usefulness for your particular user base and would like to leave that size/density out of your app to shave a couple MB off the app size, you can set that in the Gradle build flavor.
However this is not a logical question still i am much interested to know if i have any idle file that i am not using in my project.Sometime after a long project we just dont recognize that which is the actual file and which is the copy of it.Sometime we just create some xml files to check the layout and other effects like selector or some custom drawable.I mean though these file never be get executed still it crates logical confusion when we get back to our code about true identity and use of the file.
I read that Proguard removes all unused files before making apk file.Does it remove all these xml files also ?
I am bit new about proguard concept.
Thanks.
You can use AndroidLint, tool who scan your project and return a lot of advices, and then, all unused resources !
http://tools.android.com/tips/lint
- Missing translations (and unused translations)
- Layout performance problems (all the issues the old layoutopt tool used to find, and more)
- Unused resources
- Inconsistent array sizes (when arrays are defined in multiple configurations)
- Accessibility and internationalization problems (hardcoded strings, missing contentDescription, etc)
- Icon problems (like missing densities, duplicate icons, wrong sizes, etc)
- Usability problems (like not specifying an input type on a text field)
- Manifest errors
I've searched for information about this but it's hard when I don't really know what to search for.
I'm working on a few android projects which share a common base (that I put in a few libs). The libs works with both classes and xml-files, and some other resources too. The most common is that I have a drawable xml which gets color information from an xml-file which defines which colors to use, called something like "foobar_colors.xml" or so. The "foobar_colors.xml" in the lib itself defines default colors.
When I use the lib in the projects these colors needs to change (to use the client company colors or so), and I'm not sure how the best way is to accomplish this... The libs uses allot of resorces, their own xml-layouts and such, so I really can't always "declare things stylable".
The way I do it now is include the "foobar" lib in my project, copy the "foobar_colors.xml" to my project resources and change their values there. This works since R.java seems to "overload" values like the lib itself sets "foobar_color1" to be black and the project sets it again to be red (and the projects defines has higher priority).
Now I'm just wondering, is this safe? Is there any better way to do it? Possible problems that might come up in the future?
I'm wondering what some good ways of organizing Android projects are. I'm building a little recipe application and have already made dozens of layouts, drawable resources, menus, etc., not to mention Java source code.
Android does not allow sub-folders for resources, so is there a way to organize them? Right now I'm trying to organize them through naming conventions (e.g. new_list_ingredient_edit) but I'm wondering if there is a better way, as the names will probably get pretty long and cumbersome.
Same thing with resources such as string values. As I understand it, I can create multiple resource files (e.g. strings_new_ingredient.xml, drawables_new_instructions.xml, etc.) but all my resources across files have still have to have unique names, which again is cumbersome.
Although android doesn't allow sub-folders for resources, it does for assets, but this is much more cumbersome to use.
A possible option would be to use a sql database with all of your strings, but this approach is probably too much work and more cumbersome anyway.
Your naming convention method is probably your best option. You could think of some of the seperated words as directories if you want, which should keep it organized enough.
user864684,
I normally try to use heirarchy in my naming. If it is a layout for dialog, i will start with dialog_sharing or something like that.
As for graphics, I will start with btn or bg or txt or ic_menu depending on what they are for. Other than that, you just get used to it as you dev more for Android.
Make sure you also have a support folder on your drive for your local resources. I mimic the android layout so i keep my graphics sorted in res/... on my local drive too. I keep the psd and graphic files there and then just copy the pngs to eclipse.
Hope this kinda of helps. There is no real standard but you will pick up a style.
Specifically with respect to organizing drawable resources, I would advise choosing names that describe the drawables structurally, not functionally.
For example, if you have a gray circle shape resource that you are using as a placeholder for an image, I would avoid naming it *image_placeholder*. Instead, I would call it *gray_circle_1*.
My advice comes from having had the experience on multiple occasions of having given things names like *image_placeholder*, forgetting what they actually contained, and then rewriting the same exact thing in a separate resource file without realizing it.
Don't do what I did.
Five months later, i am near to finish my Android app, but now i noticed that in the folder of resources, i have a lot of non used old XML's and a lot of non used old .png's on the sub-folders LAYOUT and DRAWABLE
Is there a way on eclipse to remove all these unused resources at once?
Eclipse does not have that feature. However, you can try one of this answers to know which resources are unused and remove them manually:
Find out if resource is used