Newer Versions of Android Studio and Only Two Drawable Directory - Drawable and Drawable-V21

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:

  1. Right-click on the res/drawable folder
  2. Select "New"
  3. Select "Vector Asset"
  4. 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!
  5. OR - you can select "Local SVG File"
  6. 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.
  7. Hit "Next"
  8. Verify it is saving in the right place, and then Click "Finish"
  9. 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.

Sample Image
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 in res/drawable-hdpi-v14/

  • Have a light version of the icon as ic_action_heart_white.png in res/drawable-hdpi/

  • Have a drawable alias, named ic_action_heart.xml, in res/drawable-hdpi-v21/, pointing to @drawable/ic_action_heart_white

  • Have a drawable alias, named ic_action_heart.xml, in res/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



Leave a reply



Submit