Newer versions of Android Studio add only two drawable directories - drawable and drawable-v21
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.
drawable v21, v24? what is it?
Those drawable folders are actually for providing device compatibility (i.e. to manage different screen densities in android) and different android versions.
Is there any need to use different drawable folder version?
Yes, it's okay to just put all your drawable items in the drawable folder.
You may use these versioned folders (e.g. drawable-v24) to store different drawable items for different API Versions. yet you must have a drawable item with the same name in the simple drawable folder, therefore you won't receive a "Resources Not found" error while your app is running on a device with a lower API level.
Android studio does not create drawable folder density wise
It wants you to create them when you need them, you can create one by right clicking on the res folder and then click on add new resource directory, select the drawable as the resource type and then from the list of available qualifiers chose density and then the >> button, then select the density you want.
I think a reason why it was removed is for consistency because density is just one of the many qualifiers you can add to a resource file.
It also makes the folder structure neat, because you might not be using all the drawable folders.
The reason why it created the mipmap-hdpi, mipmap-mdpi folders is because there is already a file in it which is the default launcher icon for a new app, if there was no item in it it would not have created them.
Use the same drawable for 2 different SDK versions
You want @drawable/ic_action_heart
to resolve to:
- white on < 14
- dark on >= 14 and < 21
- white on >= 21
In that case:
Have a dark version of the icon as
ic_action_heart.png
inres/drawable-hdpi-v14/
Have a light version of the icon as
ic_action_heart_white.png
inres/drawable-hdpi/
Have a drawable alias, named
ic_action_heart.xml
, inres/drawable-hdpi-v21/
, pointing to@drawable/ic_action_heart_white
Have a drawable alias, named
ic_action_heart.xml
, inres/drawable-hdpi/
, pointing to@drawable/ic_action_heart_white
And, of course, you would have the same basic structure in other density buckets (e.g., -xxhdpi
). Since density is more important than is API level, I think you will need to have density-specific versions of the aliases.
Related Topics
Status Bar Turns White and Does Not Show Content Behind It
How to Force a Cache Clearing Using Universal Image Loader Android
Asynctask, Must It Take Such a Performance Penalty Hit...
Android Test Code Coverage with Jacoco Gradle Plugin
Edittext Settext Not Working with Fragment
Using the New "Manifestmerger" Property in Android
What Actually Happens When Persistence Is Enabled in Firebase
Android: Subscribe to Firebase Cloud Messaging(Fcm) Topic
Tapping Form Field in Webview Does Not Show Soft Keyboard
Flutter - How to Pass Custom Arguments in Firebase Dynamic Links for App Invite Feature
Recyclerview Items with Big Empty Space After 23.2.0
Httpclient on Android:Nohttpresponseexception Through Umts/3G
How to Add .So Files to an Android Library Project Using Gradle 0.7+
Can't Handle Both Click and Touch Events Simultaneously
Android Class Parcelable with Arraylist
How to Detect "Recent Apps" System Button Clicks (Honeycomb+)