IssueTracker

This is a must!

To give a little context to the need for this.  For projects where multiple
applications are involved and they share quite a few custom views, it would be nice
to allow whatever version control software someone is using to dynamically link a
library of these views.  The problem is that you can't just pre-generate the R file
for these custom views since it may overlap with the R file for the application.
Currently, the only way to manage this is to copy files from the library over to the
project needing the custom views.  This is a nightmare for version control.

A simple solution for this would be to allow subfolders.  This would allow, say,
someone using svn to just set externals inside the values folder, so different files
may be included which would be compiled as part of the app's R.java file.

So, this would allow someone to set externals for custom views in the source folder
and then set resource dependencies as externals inside the subsequent res subfolders,
and voila, it would be easier to manage the custom views library and any change to
the library, through svn, would be reflected next time someone syncs with the repository.

This is not a tool issue but a framework issue. That's how the framework and aapt are
designed.

This is ridiculous in massive applications - it's a must.

This should change priority, it's very hard to maintain something with a lots of view, custom or otherwise.

for the love of all that is sane... allow me to organize my large project better and more easily

Please, bump the priority of this feature!

Another use for this would be to have a "master" project with specific projects derived from it. This would be done by linking the master project resource directories into the specific projects' resource directory tree.

In any case, this is a requirement that needs to be urgently addressed.

Agreed

This would also allow the alphabetic ordering to be used for something other than logical grouping.  For instance, our creative department likes to be able to see which source file a particular asset comes from, and likes to have them sorted in such that they are grouped together.  This means they name them things like us001_ic_menu_settings.  When I as a developer try to reference the drawable, I have to either know whether I should be looking for us001 or us002... etc. or I have to tab through all of them until I find it.

Have just began migrating a project from xcode to Android to find this issue... Bad enough having to rename tons of files because of the bonkers "no capital letters" rule, but having to "unorganise" the 1000+ image files I have in the project is simply ridiculous! Come on Android people, help us developers out!

A must!!

There are currently 63 people who have this issue starred, if you haven't commented yet, I implore you to get this "Small Enhancement" the attention it deserves.

An enhancement that makes literally every project, regardless of function, easier to organize, deserves a higher priority. This issue has been noted since 2009, on multiple forums, and it doesn't seem like it's ever going to receive any attention. I'm working on a simple indie project and I already have 50+ drawable resources... I can only imagine how disorganized a professional project would become. I <3 Android, please help me <3 Android Development too!

This would be awesome. I too have tried to use subfolders to no avail... I mean I do not see any problem in declaring more static final subclasses for the subfolders, so why not? Then again I'm not familiar with the internals of Android SDK.. :)

To assume that fixing this would simply be a nice touch to the interface is a glaring disparity between the priorities of the end users and the priorities of google developers.

If there is good reason for not addressing this issue, maybe because the Asset folder already supports subdirectories, or it would make the resource generation code cease to be backwards compatible for some reason, then it should be stated. Recursive iteration through folders should be a solved problem, and organization is a necessity for large scale mobile development.

[Comment deleted]

It is a must for large scale projects. In some offine city guides could have more than 300 images...so it is neccesary.

+1 Really surprised this doesn't exist. It would improve performance of the IDE and the programmer!

THIS IS A MUST FEATURE!
Without this feature, developing enterprise-class app is just a painful work. yeah... I'm on it.
I wonder why low priority given.

[Comment deleted]

Definately a must have for enterprise applications.

a must for keeping applications clean and readable

must have

This is really as MUST. Im developing a app with large number of icons and it's really hard to group them. Please do something ASAP

 must have as soon as possible

MUST HAVE!!!!!!!!!!!!!!!! Plz...

This would be nice for sure

When we work in applications with a high content of Art (in images or animations) we can get 1000+ or more of images, animations, selectors, etc that would really help if we could have sub directories. Please!!!!  

Anybody home? Low priority? My goodness!

yeah, please do support this. it would be very helpful to us developers.

+1: c'mon guys. Don't make the simple things difficult.

I think it's a shame for Google that this feature is not supported yet.

It was reported on feb 2009. How many years it will take to fix this issue?

Priority-Small? I have a few hundred images in drawable and it's a mess!

Bump. I also believe it'd suffice to have even 1 folder-level supported (i.e. res/drawable/folder) and it would also be fine if IDs would be build with folder name (so. i.e.  res/drawable/folder/foo.png would be referenced as R.drawable.folder_foo) to avoid name collisions

I think this is a no-brainer...

150 people have this subject starred. Hopefully you will all see this in your inbox, read this message, and REPOST your grievances against this ridiculous shortfall. I beg anybody working on the android sdk to give me a LEGITIMATE TECHNICAL reason why this has been ignored since 2009. At least then we'd see why this is a "small" priority.

I was thinking about it:
a simple solution that would involve changing little or nothing of the SDK: the compiler (or other build tool) "renames" the files on build time, at the same time moving them to the root directory and renaming them, appending the directory name they wore initially to the name of the image. Than developers would be happy and the R file would be generated as comment 37 suggests.

Example:
/res/drawable/furniture/table.png
/res/drawable/food/corn.png

would turn (only on the "bin" directory and on the R file) to:
/res/drawable/furniture_table.png
/res/drawable/food_corn.png

Name collisions could simply be solved by appending a number to the file name, indicating the collision without compile errors so the developer would see it AND adding a warning on the project on the IDE. Another solution would be simply checking collisions before build and giving a compile error of some kind (better solution in my opinion).

I think that even a ant build or an Eclipse plugin could do that!

I really don't see why implementing this is an issue? My assets for iOS, whilst having naming conventions for different screen resolutions, can be structured into folders, so long as I let the build know where they are. It just makes so much developer sense to be able to organise the code base properly.

Over 3 years later and no solution? This is crazy...

I'm sick and tired of people complaining in a bug report. Bug reports are the place where we are supposed to help the developers solve the problem not sit there complaining saying "Omg, out of the millions of important problems that you have why have you not solved my one" Now, with that off my chest here are two solutions:

The first solution is to check out the android source code and implement it yourself; we are all developers here so we should be able to do it. So, Android developers, if somebody actually implemented this would you accept the patch? Would there be any conditions for acceptance?

The second solution you can do by reimplementing the resources system in your assets directory; the assets directory allows for a nested hierarchy of files so it would be ideal for this purpose. In my own apps I have started using a solution that is partially like this.

So there you have it; two possible viable solutions. If you have any more solutions then post them, if not then either fix it yourself or be quiet, star the issue and just wait for the android developers to find the time for this issue.

It's insane that this wasn't in the original design, and even crazier that this doesn't exist yet.

I would also be happy to see this implemented.

I can´t believe that this issue has a small priority. This issue is a must to manage larger projects.

"I can´t believe that this issue has a small priority."

I disagree.  When bugs go out in Android OS itself users and developers can be stuck with them for a long time.  If you think that buggy releases like 4.0.1 are all replaced by 4.0.4 then you are just looking at the U.S.  And have you looked at new initiatives like Google TV (it is being killed by bugs, IMO)?

I starred this issue because I do care about it, but it is a low priority compared to OS bugs.

(And though r20 was buggy, I think the tools team generally does a good job of fixing bugs and communicating with us.)

Android is not only the OS, it is an ecosystem. I think that the apps are as important or even more important than the OS. Without organization the res folder became a mess and the developers (who indirectly work for Google) make more bugs, work slower and works more unhappy when they work with mess. Without solving this issue they are creating more bugs in their ecosystem and they are making the ecosystem grow slower.


Android is not only the OS, it is an ecosystem. I think that the apps are as important or even more important than the OS. Without organization the res folder became a mess and the developers (who indirectly work for Google) make more bugs, work slower and works more unhappy when they work with mess. Without solving this issue they are creating more bugs in their ecosystem and delaying .

Organization is imprescindible to maintenance. My res/drawable folder has more than 600 files (including .png and .xml files). I have a prefix organization but this is not a solution for year 2012. And believe me that searching a resource (scrolling and scrolling) is annoying

Can I just take a moment to point out that Android is Open Source. The time arguing points could be better spent attempting to make a patch so that this feature exists. Just send an email to the android-developers group and ask: "If I fix this bug here would you accept it or would it be rejected for technical reasons?"

And that is that. Just be the change you seek. There so few Android Developers and so many bugs that they could use all of the help they can get.

Please this is really a must!

I am working on a very large project at work for our customer Verizon and we have total approximately 300 XML files.  About 150 of them are in the "layout" folder and about 120 of them are in the "layout-xlarge" folder.

When I expand either one of these folders, I have to page down three times to view all of the files.  Since I can't subfolder, I have filenames that are 50-60 characters long in order to uniquely identify them.  So when I'm editing files in Eclipse, the filenames begin to get cutoff in the tab.  It's hard to figure out which file is which because I can only see the first 20 characters of the filename which aren't unique at all.

It's also difficult to find the correct layout in the "layout" folder, and then have to find that same file in the "layout-xlarge" folder because they're spaced so far away from each other in Eclipse when both folders are expanded.

I think that when Android first came out, there was no need to sub folder.  You might have had five activities, maybe a couple of list views, and there was no fragments.  And I think that with small projects, hobby projects, school projects... there is no need to sub folder.  But when you have a large project the number of layout files becomes quite large.  I have 37 activity layout files in both the "layout" and "layout-xlarge" folders.  I have about the same number of fragment layout files and custom adapter layout files.  Please help!  Thanks.

Please please add this feature in new version.

I am starting to get far too many xml files in my layout folder...

yes, this feature is a must have. but as i see, after 4 years has no change with this, so i am affraid, it won't be implemented.

Honestly Google you're perfectly happy to warn me not to post a "+1 Me too!" but like #54 said, 4 years later you've done f*ckall? That's pretty shitty. Get your act together and give us this. Who decided on the priority? Get a clue, or hell, reply with  a decision. Do something so we know what you intend doing about this. Don't just ignore this.

#55, and others, it may be worth investigating if this is an IDE issue or perhaps it may be possible in Android Studio

#56, Well I doubt it, Android Studio is based on Intellij and I am using Intellij for some time now for my Android app development and it does not matter wich IDE you use.
And why would it be it has nothing to with this issue.

Guys, they have bigger issues to solve. They have PM's that are making decisions for them too on the direction of Android. They have a great many issues to resolve and, likely, not enough developers on bugfix.

From their perspective, if they implement this it would not fix any broken functionality, it would be a large bit of work that would affect every app out there and it would not give you any functionality that you could not technically do already. In short, if I was a PM on the Android project it would be at the bottom of my pile and I cannot expect anything more from them. Not for such a low priority issue (which they have already marked as such with 'Small').

So, in short, I would recommend that you either:

 - Recreate this folders using underscores in filenames.
 - Write and submit the patch and changeset yourself.
 - Attempt to use the 'assets' directory to accomplish your use case (if you can).

My opinion is this: they are not going to implement this unless a Google developer takes 20% time to make this happen.

But in regards to better resource management and version control, which is pseudonymous with the requests made here; Android Studio may provide assistance with this and it's gradle environment.

Of course, this can work as temporary alternative for now. Something global to the OS would still be appreciated but it has been a long time since this ticket has been reported.

I think Google recent strategy is to consolidate their platform, and
especially on a feature and developer ease point-of-view. I think this
defect is exactly within current google strategy.
This is a terrible item when it comes to "ease of development". And if they
want to keep up the comparison with say iOS, I believe this item is quite
high in the list.
That being said, it is not "blocking" and there are workarounds (like you
mentioned, which is I believe the best workaround). But sure is a pain in
neck and makes large apps weaker because the structure is unclear.

#57, right, it's not about the IDE by itself. But it's about the build system. And from reading the docs about the new Gradle based build system [1] that Android Studio encourages to use for new projects it seems that resource directories are now parsed recursively. In any case with Gradle you should be able to manually add additional resource sub-directories.

[1] http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Project-Structure

[Comment deleted]

[Comment deleted]

Marking this as released. This is largely possible in the Gradle build system as it exists today, and we won't be implementing this for other build systems.

what? duplicate? seriously? this was posted on 2009 while the link you gave was on 2014. nice try closing the thread

is this feature added yet its been almost a decade since a highly useful feature was requested for handling large porjects. If there us a way it would really be helpful

Actually, they should just kill this ticket since modules are supported at this point.with gradle

It's solved?