The name is only to identify the AVD. Anything can assigned to it, and it can be changed later. Predefined AVD names can also be changed at the time of creation.

AVD resolution is one of the most important factors for visibility. There are some predefined resolution standards, but they can also be changed. Nowadays, mostly, developers pick resolutions that are widely used on an actual hardware platform.

One more use of resolution is to check and verify the display portability of games. Mostly, games are made in a target base resolution. Then, the game can be tested on various resolutions to check the compatibility.

Normally, multiple resolutions would create any issues if the aspect ratio is the same. However, in the case of Android, we can find multiple aspect ratios for different devices. The resolution factor of AVD helps fit the game and check its compatibility for multiple aspect ratios as well.

This is the visible space or visible display area on an AVD. One high-resolution AVD can have a small display area. It directly implies that the AVD has a high dpi value, which means a higher display quality.

This section of AVD helps ensure the visual quality of the game. However, it is not always possible to set the actual display region in the development system as the development system has its own display limit.

While developing an Android game, the developer needs to limit the API usage to a certain version. The API version can be deprecated in future versions of Android or even discontinued. To check this factor, the developer can set an API version for AVD.

This is the Android version that will be used to run the AVD. This can verify the manifest target Android version and minimum version range.

Android devices mainly use three types of CPU architecture: armeabi, armeabi-v7, and x86. This does not have a direct impact on games. However, the processing speed and quality varies with CPU architecture.

The developer should keep in mind that actual game performance on a real device with a different CPU architecture will always perform differently than an AVD. So, it may give the developer an idea of performance, but it needs to be tested on a real device.

RAM amount specifies the total amount of memory that the AVD has, which can be used to check the memory consumption of the game at various levels.

It is best to predict the memory overflow issue for various devices. By running multiple apps at a time, a real-time clone can be created with the AVD. The default value is set to 66 MB. The developer can set any value according to the requirement.

External storage can be also defined as an SD card for a virtual device.

In Android devices, there can be many types of hardware input distributed within a wide range of hardwires. The most common variations are as follows:

Many hardware platforms have opted for a combination of these variants. An AVD creates a virtual system for all of these input systems.

There are a few other options that are readily available for manipulation. If the development system has a camera attached to it, then the AVD can also use a camera, both front and back.

Additionally, virtual accelerometers, sensors, and so on can be associated with an AVD.

A custom AVD can be made through a modern AVD manager tool. A developer can design a virtual device with a custom look and feel, and with complete custom hardware configuration.