Android conventions

A complex environment

Working on a daily basis with Android can be quite hard: it’s a constant battle to find best practices and stay up to date. If you have already worked on backend applications, you might expect to find a framework or a tool that wil guide you toward a better code base. There are some, but none of them are endorsed by Google or any reliable entity and thus maintainable.

Android is a vast land that you have to explore by yourself. Hopefully, since a few years, things are changing and Google realized that everyone might not be able and/or need to do all of this. I think that’s why they are finally providing a helping hand, with some exemple of basic architectures. Yet, you will still have to do a lot by yourself, try and bend them to fit your needs. Some new shiny tools will also help you do that.

However, in my everyday job, a basic thing that really helps me is conventions. There are many things that need conventions on Android, particularly for naming. Using conventions on Android is really helpful and will save you a lot of headaches. Other developpers have come to the same conclusion.

My conventions

Naming views

Naming views on Android can be easier if you follow a simple rule: compress the name of the view and describle its content. Since these ids are mostly used in Java/Kotlin, I use camel case.

An ImageView with cats will be ivCats

ImageView has become “iv”.

A TextView for a cat’s name will be tvCatName

TextView has become “tv” and we use camel case.

A Spinner containing different varieties of cat food will be sCatFood

and so on…

I apply this method to every Android view. This method is not perfect however: there are some conflicts, a Switch will be “s”, like a Spinner. Since these conflicts are not common and their impact is limited, so I simply tolerate them.

Naming translation keys

Another issue programmers often face is how to handle translation keys efficiently. Elements are separated by “_” and description is in snake case.

  1. Name of the activity/fragment.
  2. Then I rate them with one of “info”, “warning” or “error” to help translators.
  3. Finally, I put a description of what the key is being used for.

I group them by 1 and sort them by 2.

This gives us things like:

<string name="login_info_username">Username</string>
<string name="categories_warning_no_category_description">You can add a category in the web application</string>

There are also some special strings that might not fit in this model. Ie keys that are used in every screen of the application. In this situation, I use a “all” element instead of the name of the activity/fragment.

<string name="all_error_invalid_query">Invalid query</string>

Finally, don’t forget to use the “translatable” property which can be really usefull to avoid unecessary work.

<string name="all_info_myapp_name" translatable="false">MyApp</string>

Naming layouts

Naming layouts is easier. I just name them starting with one of the following: “activity_”, “fragment_”, “view_holder_”, “view_”.

Naming drawables

There are many standards when it cames to drawables. What I recommend is to describe what the icon is for instead of what it is being used for.

A pencil icon

Ie: I would rather name this icon “pencil” instead of “edit”

This avoid renaming downloaded resources from websites like Material Design Icons.


A common convention is to start an icon’s name with “ic_”. It’s useful to identify resources that have standard icon sizes (24dp or 48dp). I also add an “_{color}” at the end of the file’s name if it’s any other color than black.


I just prefix them with “shp_”.

Other drawables

All other drawables are prefixed with “img_”. I make no differences between drawables based on their format.


Soon or later in your Android project, you will start to use conventions. If you plan to start a project from scratch or if you want to specialize on Android, have a look on the ones that already exist and appropriate them. This will help you avoid a lot of issues.