Configurations and Resource Sets

Somehow, we need to be able to tell Android:

• Some resources are to be used for a certain type of configuration, such as “large screens” or “high-density screens” or “uses English”
• Some resources are for some other configuration, for as many different configuration aspects as we wish to support
• Some resources are the default and are valid for any configuration

The way Android currently handles this is by having multiple resource directories, with the criteria for each embedded in their names.

For example, suppose that you want to support multiple languages. You will need to choose some default language, one that will be used if your app winds up on a device whose locale is set to a language that you do not support. For example, you might set your default language to be US English. In that case, your US English strings would go into res/values/strings.xml. If you also wanted to offer a translation in Spanish, you would add a res/values-es/ directory, where es is the ISO 639-1 two-letter code for Spanish. In res/values-es/, you would put your Spanish strings. At runtime, Android will choose which string to use, for a given string resource ID (e.g., @string/app_name), based on the device’s locale(s) and the various translations of that string that you provide.

This, therefore, is the bedrock resource set strategy: have a complete set of resources in the default directory (e.g., res/values/), and override those resources in other resource sets tied to specific configurations as needed (e.g., res/values-es/).